#ubuntu-devel 2005-02-21
<doko> lamont: do we get in trouble uploading new gcc-3.[34]  packages before gcc-4.0 hasn't built on powerpc?
<dholbach> sleep tigh everyone... i'm off to bed
<Kamion> enrico: Debian does indeed have /etc/lsb-release, if you install the lsb-release package
<mako> jdub: damn straight
<mako> jdub: IRT to jordi's daddy
<jdub> i hear you've been slipping the blue gold
* mako has experienced the blue gold once or twice
<Mithrandir> blue gold?
<Kamion> enrico: BTW, the more standard way to do what dholbach quoted above is 'lsb_release -r'
<enrico> Kamion: oh, cute!
<Kamion> http://refspecs.freestandards.org/LSB_2.0.1/LSB-Core/LSB-Core/lsbrelease.html
<Hwolf> Is there a problem with the mailing list?
<Hwolf> I keep getting all the mails multiple times.
<Kamion> I believe that's due to one particular subscriber's broken mail configuration; this happens sometimes on big mailing list
<Kamion> +s
<Hwolf> What kind of configuration would be broken? Bouncing back all mails to the list?
<Kamion> mdz: apt-setup> feel free; please run debconf-updatepo after editing apt-setup.templates
<Kamion> Hwolf: yeah, the usual case is that somebody is treating the To: header as if it were the address to which the mail should be forwarded
<Kamion> Hwolf: so they get To: ubuntu-users@lists.ubuntu.com, and forward it back to us
<lamont> doko: only if gcc-4.0 is providing things that used to come from 3.4
<lamont> sladen: no clue
<Hwolf> kamion: Isn't that easily detectable? The list software would get a load of mails from that person right, all identical?
<Kamion> Hwolf: usually the breakage is such that it defeats the usual loop detection
<Hwolf> kamion: obviously. :-)
<Kamion> the second and subsequent mails aren't looping in this case, but the first one isn't stopped
<Hwolf> kamion: You've got a piont. Just wanted to check if it was the list or my settings. Had some difficulties with gmail and pop-retrieval in the past.
<Hwolf> I'm off to bed. later
<Kamion> speaking of loops ...
<sivang> Kamion: lol
<sivang> ha!
<sivang> jdub: would you refer me to a good source about the desktop files? I searched over fd.o, and googled and found nothing, also I suppose there is some lib to access them programtically from within gnome/gtk code where would I find it?
<jdub> i forget which lib is most useful these days
<jdub> libgnome-desktop does part of it
<jdub> it's murkyish
<jdub> ask in #g-h
<daniels> Kamion: UNROLL THEM
<sivang> jdub: thanks
<sivang> oh here we go again...
<sivang> :(
* mode/#ubuntu-devel [+o daniels]  by ChanServ
* mode/#ubuntu-devel [+b *!*@pound.ifndef.com]  by daniels
<spiv> Hmm, there's no python-gamin package.  :(
<jdub> spiv: BONG
<jdub> spiv: i will fix that right now
* jdub hangs up, shoots the phone -> "boring conversation anyway"
<sivang> daniels: thanks
<HrdwrBoB> haha I just had a call who I accidentally hung up on
<lamont> doko: bad build-deps
<HrdwrBoB> if you hit 'transfer' and then enter the wrong number, apparently there's no going back
<doko> lamont: no, libmpfr-dev not in main
<lamont> After installing, the following source dependencies are still unsatisfied:
<lamont> libmpfr-dev(missing)|libgmp3-dev(inst 4.1.4-5 ! << wanted 4.1.4-3)
<lamont> Source-dependencies not satisfied; skipping gcc-4.0
<lamont> doko: ah, ok.  tell me when it is, and I'll kick it
<TreadingSoftl1> Hi folks. I'm trying to install Beagle on Ubuntu Hoary according to these instructions: http://www.ubuntulinux.org/wiki/HoaryBeagleInstallHowto . However, when it comes to running autogen for gsf-sharp it complains about not being able to find packages monodoc and gtk-sharp-2.0. Where can I get gtk-sharp-2.0?
<doko> lamont: ok, I'll wait with 3.3 and 3.4 uploads then.
<crimsun> TreadingSoftl1: I believe tseng has a repo with gtk#-2.0
<TreadingSoftl1> crimsun: do you mean i need to install the whole of gtk? Will that break my Gnome packages?
<crimsun> TreadingSoftl1: no, just dependencies..
<crimsun> TreadingSoftl1: (and no, they won't break your gnome packages)
<ajmitch_> ah, I should probably get libgsf-cil uploaded now..
<crimsun> thanks, ajmitch_. :)
<TreadingSoftl1> crimsun: cool ... so exactly what would I download from cvs and where?
<ajmitch_> crimsun: I'll have to check it over a lot first
<ajmitch_> crimsun: when I built it I didn't see a gtk# 2.0 requirement, so I'd better find out why :)
<TreadingSoftl1> ajmitch: ah... would a libgsf-cil package solve my problem?
<ajmitch_> TreadingSoftl1: it'd mean that you wouldn't have to build gsf-sharp from source
<ajmitch_> jdub: how was that beagle love coming along?
<TreadingSoftl1> ajmitch_: cool
<jdub> ajmitch_: haven't really looked at it for a bit, might later
<ajmitch_> TreadingSoftl1: where'd you get gsf-sharp source from?
<TreadingSoftl1> ajmitch_: um ... hold on
<TreadingSoftl1> ajmitch_: svn co svn://svn.myrealbox.com/source/trunk/gsf-sharp
<ajmitch_> yeah, that's what I thought
<TreadingSoftl1> ajmitch_: ?
<ajmitch_> I don't see the gtk-sharp-2.0 dependency you were talking about, which is why I'm curious :)
<TreadingSoftl1> ajmitch_: see it where? Does your source compile without it?
<ajmitch_> let me just copy my debs somewhere for you to test
<TreadingSoftl1> ajmitch_: oh bother... i'm really sorry ... it's gst-sharp i'm having trouble with - please excuse my idiocy - i'm getting the gs*-sharp s confused
<ajmitch_> ah...
<TreadingSoftl1> ajmitch_: so it's svn co svn://svn.myrealbox.com/source/trunk/gst-sharp 
<TreadingSoftl1> ajmitch_: presumably that makes more sense?
<ajmitch_> yeah, that will require gtk-sharp-2.0 
<ajmitch_> crimsun: are you in the mono MOTU team?
<ajmitch_> if there is one :)
<crimsun> ajmitch_: I don't believe there is one, but I'm definitely interested.
<TreadingSoftl1> ajmitch_: i pulled the gtk-sharp-2.0 source off mono cvs ... but when i ran autogen it said:  Optional assemblies included in the build: / * art-sharp.dll: yes / * gnomevfs-sharp.dll: yes / * gnome-sharp.dll: no / * glade-sharp.dll: yes / * gda-sharp.dll: no / * gnomedb-sharp.dll: no /  * rsvg-sharp.dll: no / * gtkhtml-sharp.dll: no / * vte-sharp.dll: no / * panelapplet-sharp.dll: no / NOTE: if any of the above say 'no' you may install the / cor
<TreadingSoftl1> But I don't know what to do about this?
<ajmitch_> crimsun: it's probably a good idea, might be good to have some place to have team review of packages & an svn or arch repository 
<ajmitch_> have you looked for tseng's mono repository?
<ajmitch_> I would but google hates me :)
<TreadingSoftl1> ajmitch_: if i pull those other packages off mono CVS, does it pose any significant risk for the rest of my Ubuntu system? (I don't know what they do.)
<crimsun> ajmitch_: good idea. Oliver sent out a [couple]  messages regarding MOTU wiki pages; we should get that up and running. [I have to create one for XFce anyhow.] 
<ajmitch_> TreadingSoftl1: no significant risk that I'm aware of
<ajmitch_> I haven't yet built beagle
<TreadingSoftl1> ajmitch_: cool ... and ... oh
<ajmitch_> so <insert standard disclaimer>
<TreadingSoftl1> ajmitch_: if it breaks Beagle that's okay ... I just don't want it breaking the whole of Hoary :)
<lamont> someone remind me how to boot a G3 from cdrom...
<Kamion> lamont: try holding down c at boot
<lamont> thanks
<Kamion> lamont: if that doesn't work, cmd-opt-o-f and type 'boot cd:' at open firmware
<Kamion> mm, that's "hold down cmd-opt-o-f simultaneously during boot"
<lamont> was c, iirc
* lamont tries to remember what module the ia64 needed to have loaded for the atapi cdrom to be found.,
<lamont> Kamion: was C
<lamont> S48 console screen segv's on G3 - is that known?
<lamont> 2005-02-08 daily
<sivang> hey jinty \
<jinty> hoi sivang
<jinty> sivang: hey again
<sivang> jinty: heh, what's up?
<jinty> not much, been trying to get distutils and schooltool kiss and make up
<sivang> jinty: hehe, they have a dispute? 
<jinty> they never got along well, had many arguments
<jinty> but now they are almost married:)
<sivang> jinty: whoo, so you could be a very good matchmaker if so :)
<jinty> And on your side?
<mdz> Kamion: still here?
* mode/#ubuntu-devel [-o daniels]  by daniels
<Kamion> mdz: just about
<Kamion> mdz: in house accounts resolution hell
<mdz> Kamion: how many housemates?
<Kamion> three
<mdz> ick
<Kamion> but I just had to do the maths for one moving out and another moving in, including the mistake I made at the time of assuming rent was in arrears not in advance
<mdz> I wanted to talk about the Win-FOSS stuff when you have a moment
<jdub> 12:58 < hou5ton> my son installed Ubuntu on this laptop for me, and I later
<mdz> whether you think we should suck it in automagically, etc.
<jdub>                  went into Computer > System Config > Users and Groups and
<jdub>                  changed the user name he had entered (user) to a new one
<jdub>                  (hou5ton). But now the machine won't let me open a root
<jdub>                  terminal or sudo.
<jdub> 
<mdz> ARGH
<Kamion> so I am filling out a very large pile of double-entry columns at the moment
<mdz> another "shoot me in the foot" desktop feature
<jdub> yeah
<jdub> we should not allow user name changing
<jdub> it's doooooomed
<Kamion> mdz: well, it's only i386, I assume?
<jdub> gnome doesn't handle it well at all
<mdz> even more so than uid changing
<mdz> Kamion: correct
<Kamion> mdz: so I'm happy to suck it in automagically
<mdz> Kamion: for Warty at least, we didn't include all of it, and stripped some bits out
<mdz> so we might need a filter in the middle this time as well
<jdub> mdz: group sudo rights does help this a little bit
<Kamion> I'll have a look at a Warty CD and "make it look like that" for now
<mdz> jdub: this zen linux iso is going to take all night to download
<Kamion> assuming that's kind of plausible
<mdz> jdub: "where did my mail go??"
<jdub> mdz: they should find a cosmonaut to sponsor fat bandwidth
<jdub> mdz: ie. not moving home directory?
<mdz> "why do all my prompts say /home/olduser now instead of "~"??"
<jdub> oh, mail spool?
<jdub> heh
<mdz> nothing but badness
<jdub> the system really should be robust enough to handle it though
<mdz> Kamion: that sounds vaguely plausible
<Kamion> jdub: the home directory is set in /etc/passwd anyway, so unless that got changed but not moved ...
<mdz> Kamion: for some reason the tarball is way larger than I expected
<Kamion> mdz: I was also surprised by the size, although I guess it doesn't compress very well
<mdz> Kamion: the compressed tarball is _much_ larger than the stuff currently on the Warty CD, even though celestia is already excluded
<mdz> oh, no it isn't
<mdz> I just mis-remembered
<mdz> oh, yes it is
<mdz> well, the compressed tarball is about the size of the uncompressed stuff on the Warty live CD
<mdz> warty-live: 116M    total
<mdz> at any rate, no crisis here, move along
<jdub> Kamion: hrm, can i check a possible germinate bug with you?
<jdub> $ apt-cache rdepends libmad0 | awk '/^  / {print $1}' | xargs apt-cache show | grep ^Filename | grep "pool/main"
<jdub> Filename: pool/main/s/swfdec0.3/libswfdec0.3_0.3.2-2_i386.deb
<jdub> Filename: pool/main/libm/libmad/libmad0-dev_0.15.1b-1_i386.deb
<jdub> now, arts and kdelibs we can fix
<jdub> Filename: pool/main/a/arts/libarts1_1.3.2-2_i386.deb
<jdub> Filename: pool/main/k/kdelibs/kdelibs4_3.3.2-1ubuntu6_i386.deb
<jdub> 
<jdub> swfdec0.3 though;
* jdub double-checks germinate output
<jdub> aha
<jdub> mozilla-dev
<jdub> grr.
<Kamion> jdub: still a bug to be investigated?
<Kamion> jdub: if so, please point me to which seed is involved and what output you're looking at
<jdub> http://people.ubuntu.com/~cjwatson/germinate-hoary-output/desktop.build-depends
<jdub> mozilla-dev                  | mozilla               | swfdec0.3 (Build-Depend)
<Kamion> that would appear to be correct?
<jdub> Build-Depends: binutils (>= 2.15-4), libgtk2.0-dev, debhelper (>= 4.1.16), zip, libjpeg62-dev | libjpeg-dev, libungif4-dev, libz-dev, autoconf2.13, bzip2, patch, sharutils, docbook-to-man, libfreetype6-dev, libxft-dev (>= 2.1-6), libfontconfig1-dev (>= 2.1-13), gcc (>= 3.3) [!amd64] , g++ (>=3.3) [!amd64] , libidl-dev (>= 0.8), po-debconf, libxp-dev, libxt-dev, gcc-3.4 [amd64] , g++-3.4 [amd64] 
<Kamion> whose build-deps are those?
<jdub> mozilla
<Kamion> you have it the wrong way round; look at swfdev0.3's build-deps, you'll find mozilla-dev
<jdub> bong
<jdub> ok, so it's just arts
<Kamion> the third column in a germinate output file is a more-or-less-randomly-selected reason why the package is there
<jdub> heh
<Kamion> for a list of all the reasons, see the relevant file in rdepends/
<jdub> weird, that doesn't mention arts
<jdub> no, no
<jdub> never mind
<jdub> of course swfdec rdepends doesn't mention arts ;)
<Kamion> http://people.ubuntu.com/~cjwatson/germinate-hoary-output/rdepends/libmad/libmad0 is presumably the file you're looking for
<jdub> yes
<jdub> i led myself up the garden path *twice* then
<jdub> but looking at that now, will see if it's easily fixable
<jdub> Kamion: ah, no, so, there is a problem
* jdub rattles sense out
<jdub> Kamion: i can only get swfdec out of main if i disable gstreamer0.8 build-depend on it?
<Kamion> so you want swfdec out as well as libmad0? (why?)
<jdub> because swfdec depends on libmad in a way that wouldn't be useful to disable
<Kamion> anyway I don't see a build-depends from gstreamer0.8 listed, I'm guessing you mean gst-plugins0.8
<jdub> sorry, yes
<mdz> Kamion: regarding the apt-setup stuff...I really think it should work a bit differently.  I don't recall if we talked about this before
<mdz> but I think it should be possible to end with network sources in sources.list, without downloading from them during the install
<mdz> and that should be the default
<Kamion> mdz: we haven't discussed that as far as I can remember
<jdub> amu, haggai: around?
<Kamion> mdz: that change sounds reasonable though; can I let that percolate overnight and see if I can think of any problems?
<Kamion> because my brain is too full of numbers right now for anything much to make sense
<mdz> Kamion: want a reminder email?
<Kamion> mdz: yes please
<Kamion> actually perhaps a bug report
<mdz> hmm, there might be one
<mdz> I'm sure I've talked about this someplace
<mdz> oh bugzilla, how I hate thee
<Kamion> if there is, I don't *think* it's on my list
<Kamion> although with 141 bugs I could have missed it
* Kamion sighs
<mdz> #2757 is relevant
<Kamion> I think some of jbailey's recent work has killed a batch of my bugs, so I need to triage
<mdz> but not the same
<Kamion> #2757 looks almost entirely orthogonal
<Kamion> I mean, apart from disk space required to do the download
<Kamion> I suppose it's connected in that the disk space recommendations would be different if they took downloads into account
<mdz> well, the basis for my proposal is that downloading packages during a CD installation is almost never the right thing
<mdz> and in the same thread on -devel someone mentioned the problem of running out of disk space due to downloading packages during the install
<Kamion> ah
<mdz> I'll file a bug
<Kamion> the reason I wanted to do it that way in the first place was so that you weren't installing stuff we knew to be insecure (because we'd released a security update)
<Kamion> if you think people will be happy with us telling them that they need to update immediately after installation ...
<mdz> that happens anyway if they say "no"
<mdz> (the insecure system)
<mdz> and update-notifier makes it pretty painless to notify the user
<Kamion> which is why yes is the default :)
<mdz> I think it's better to have the system up and running completely, and then updates can be applied
* jdub agrees with mdz.
<Kamion> OK, update-notifier does alleviate my concerns somewhat
<jdub> ui > di ;-)
<mdz> our security policy makes the window of insecurity fairly irrelevant
<mdz> except in the case of remote kernel vulnerabilities, in which case they're screwed from booting the CD anyway
<Kamion> jdub: screw you, hippy ;-)
<mdz> if we do an apt-get update at the end, then if they install anything which listens, they get the secure version
<jdub> :-)
<Kamion> ok, I'll see if I can figure out how many bits of base-config need to be rearranged to make that work
<Kamion> mdz: oh, while I remember, there were a bunch of debconf template translation fixes in various bits of d-i mass-uploaded to Debian recently; I'd like to merge those translation fixes when time permits, if that's OK
<mdz> Kamion: certainly
<mdz> I don't suppose any of it is imported into rosetta yet...
<Kamion> mdz: ho ho
<Kamion> mdz: I'm quite tempted to ask the guy who posted asking about translating the installer into Polish to download the assembled .po file from http://people.ubuntu.com/~cjwatson/installer-po/ and translate that
<Kamion> because it is not clear to me that anything else will be available in time
<lamont> Kamion: so what must the kernel/whoever do to get cmd64x.ko into the initrd?
<lamont> (so we can find the cdrom on ia64...)
<Kamion> lamont: as far as I can tell, it already is in the initrd ...
<Kamion> debian/d-i/ia64/modules/ia64/ide-modules:8:drivers/ide/pci/cmd64x.o
<Kamion> (linux-source-2.6.10)
<Kamion> build/pkg-lists/cdrom/ia64.cfg:9:ide-modules-${kernel:Version}
<Kamion> (debian-installer)
<Kamion> cjwatson@little:~/cdimage/ftp/dists/hoary/main/installer-ia64/current/images/cdrom$ grep ide-modules initrd.list
<Kamion> ide-modules-2.6.10-3-itanium-smp-di 2.6.10-15
<lamont> deb file:/mnt hoary main restricted
* lamont stares and tries to figure out what's wrong with that
<daniels> lamont: file:///mnt ?
<lamont> daniels: tried that too.
<Kamion> grr, I can't mount the initrd on powerpc; wrong endianness ...
<lamont> it parses fine, but doesn't find anything to upgrade
<jdub> are we supposed to be getting gpg 1.4.1?
<lamont> module is not loaded, and find /lib doesn't find it.
<lamont> livecd from 8fenb
<lamont> 08 feb 2005
<jdub> or does it not matter?
<Kamion> lamont: hm, module indeed not actually in the initrd
<lamont> Kamion: kinda need that to boot.. :-(
<Kamion> oh, I wonder if this is a kernel-wedge bug
<Kamion> the contents of the udeb stop at drivers/ide/pci/amd74xx.ko (not present)
<lamont> in any case, how hard is this to hack around locally?
<Kamion> who will be doing the next kernel upload?
<lamont> that's because we deleted that beast because it's evil
<lamont> Kamion: somehow, I think that might be me...
<lamont> unless zul or t-bone really wants it...
<Kamion> lamont: ah, fabbione forgot to remove it from debian/d-i/ia64/modules/ia64/ide-modules too
<lamont> should that fix things/
<lamont> ?
<Kamion> lamont: edit that file, remove the amd74xx line; yes, that'll fix it
<Kamion> it's a bug that the build succeeded anyway, though
<lamont> that matches what got on the CD pretty well...
<lamont> anything else that it needs?
<Kamion> don't think so; I'm just poking at the build log now
<Kamion> oh, hm, there's another bug
<Kamion> bloody fabbione put || true after kernel-wedge check :(
<Kamion> lamont: ok, just that change for now, then we'll see how things look
<lamont> debian/d-i/ia64/modules/ia64/ext2-modules.lnk:common/ext2-modules
<lamont> that'll get me ext2?
<Kamion> lamont: ext2 should already be done; note that that problem in ide-modules probably had a huge knock-on effect
<Kamion> as in, it caused copy-modules to exit early
<Kamion> lamont: oh yes, please remove ext2-modules from debian/d-i/ia64/package-list, though; that will make germinate a *whole* lot happier :)
<Kamion> lamont: as in, remove it from kernel-image's Provides ...
<lamont> Package: kernel-image
<lamont> Provides: rtc-modules
<lamont> like that?
<Kamion> right
<Kamion> fabbione meant to do that in the last upload, but it got lost by accident
<lamont> yeah - there's a lying changelog entry there...
<lamont> changelog, drop amd74xx.o from ia64/modules, drop ext2-modules from provides in ia64/package-list
<lamont> copy 00list-15* -> 00list-16*
<lamont> and I think that's all.
<lamont> any other changes, oh master of d-i?
<Kamion> you might want to test-build on ia64; I'm not sure if the rest of the bits are OK
<Kamion> if you do, throwing a build log in my direction would be good :)
<Kamion> but if you'd rather just upload to fix the boot issue and worry about the rest later, that's fine too
<lamont> how long you going to be around?
<Kamion> few minutes
<lamont> it build-deps xorg, which is out of date on my mirror, and therefore unistallable...
<lamont> I could just upload, or deal with it tomorrow sometime...
<lamont> I think I may just upload it...
* lamont is pretty sure he really doesn't want to know _WHY_ xorg is needed to build a kernel, mind you.
<daniels> the kernel build-deps xorg?!?!?!?!
* lamont spews
<lamont> The following NEW packages will be installed:
<lamont>   bzip2 debconf-utils debhelper defoma docbook docbook-dsssl docbook-utils
<lamont>   dpatch ed file gettext gettext-base gs gs-common gs-gpl gsfonts html2text
<lamont>   intltool-debian jadetex kernel-package kernel-wedge libgcrypt11 libgimpprint1
<lamont>   libgnutls11 libgpg-error0 libice6 libjpeg62 libkpathsea3 liblzo1 libmagic1
<lamont>   libncursesw5 libopencdk8 libosp4 libostyle1 libpaper1 libpng12-0 libpopt0
<lamont>   libsgmls-perl libsm6 libsp1 libt1-5 libtasn1-2 libwww-ssl0 libx11-6 libxaw7
<lamont>   libxext6 libxmu6 libxpm4 libxt6 lynx mime-support module-init-tools openjade
<lamont>   po-debconf sgml-base sgml-data sgmlspl sharutils sp tetex-base tetex-bin
<lamont>   tetex-extra texinfo transfig ucf whiptail xlibs-data xml-core xorg-common
<dredg> sweet zombie jesus.
<lamont> uh, yeah.
<daniels> oh
<Kamion> gs, at a random guess?
<daniels> tetex-bin contains an xaw app
* lamont sighs
<daniels> we have a sweet build-dep loop between tetex-bin and xorg
<Kamion> gs dep gs-gpl dep <world>
<daniels> xaw is a complete horror
<daniels> why does the kernel dep ghostscript, out of curiousity?
<lamont> Kamion: I imagine that it's several of those packages
<lamont> daniels: nfc
<Kamion> daniels: doc-building, I guess
<lamont> but that's the only reason that would make sense...
<Kamion> daniels: it deps tetex-bin via docbook-utils -> jadetex -> tetex-bin (at least)
<daniels> sweet jesus
<daniels> docbook considered harmful
<Kamion> the world needs to get over its XML fixation :P
<jdub> yeah
<jdub> we should write documentation in debconf
<daniels> yeah, if we all used tetex, this problem would have just gone away
<daniels> oh, hey, wait ...
<Kamion> groff!
<Kamion> world deps groff anyway ;)
<daniels> dude, everyone knows groff is dead
* jdub will raise his docbook refentry plans again at some stage. :-)
<Kamion> blah, you just don't know a good language when you see onw
<Kamion> one
<jdub> spelling is a good prerequisite though
<daniels> Kamion: well, x is dead also :) everyone uses y or directfb.  so sometimes 'dead' isn't so bad.
<Kamion> for values of everyone of ...?
<daniels> Kamion: no-one
<Kamion> jdub: :P
<Kamion> daniels: ah-ha, a common value
<lamont> Kamion: so you think I can just upload it?
<lamont> or will it have other issues:?
<Kamion> lamont: I'd say go for it, I don't know of others - but I haven't been listening for others either :)
<lamont> uploading
<lamont> feh
<lamont> 4 hour build time
<lamont> Kamion: you want to kick an ia64 d-i and livecd run when you wake up?
<Kamion> lamont: ok, will do
<lamont> thanks
<lamont> there's no way in hell it's going to make the normal runtime
<Kamion> when's the d-i build cronned for?
<lamont> 0615
<lamont> livecd runs at the same time
<Kamion> ok. you won't need a new livefs build though
<Kamion> unless there's some other reason ... all the kernel stuff goes in udebs and is outside the livefs
<lamont> cool
<Kamion> at least all the kernel stuff that's relevant here ... :)
<lamont> sorry - d-i run on the buildd, and livecd generation on your side
<lamont> was what I meant to ask for ...
<Kamion> ah, right, sure, I can do that
<lamont> is there anything that is in the daily d-i build that winds up inside the livecd cloop?
<Kamion> god, I hope not, that would just be way too confusing
<lamont> well, if it was, we couldn't cron them together like we have... :-)
<lamont> hence the question
<Kamion> I'm not aware of anything, although I haven't read the cloop script; but it would have taken some work to do that, you wouldn't have done it by accident
<lamont> it's (basically) a debootstrap and apt-get install
<Kamion> yeah, very unlikely then
<lamont> and run a few commands, etc.
<Kamion> you'd have had to convince apt-get to install udebs. :)
<lamont> speaking of which...
<Kamion> lamont: mind you, there is debian-installer-manual.deb, which comes out of the daily d-i build
<lamont> Kamion: yes.  every _STINKING_ day...
<lamont> with no changes. 
<Kamion> that's in ship but not in live - I recommend not putting it in live
<lamont> agreed
* lamont points Kamion at the other window
<Kamion> why don't you build just binary-arch in the daily run?
<lamont> it is binary-arch
<Kamion> er, damn, so it is
<Kamion> if I provided a separate target for just the images, could you use that?
<mdz> lamont: did elmo happen by to process ubuntu-live before the cloop builds?
<Kamion> apparently not
<Kamion> mdz: I'm kicking off new builds tomorrow morning anyway, so I'll do livefs as well
<mdz> ok
<mdz> not that you'll be awake before noon tomorrow :-)
<Kamion> mm, yeah, speaking of which
<Kamion> GOOD NIGHT :-)
<lamont> g'night to you then
<Kamion> all hail the feature freeze
* lamont plays another 6
<mdz> Kamion: night
<mdz> lamont: 6?
<lamont> mdz: ma0 ref
<mdz> ah
<mdz> fabbione: good morning
<lamont> mdz: he's awake?
<mdz> he just uploaded the kernel, I hope so
<lamont> me
<lamont> -16 is mine.
<mdz> oh, never mind ;-)
<lamont> if he was awake, I'd be giving him grief, you see... :-)
<lamont> oops
<lamont> Changed-By: LaMont Jones <lamont@debian.org>
<lamont> I hate that
<mdz> I have separate dch scripts for Debian and Ubuntu which set $DEBEMAIL appropriately
<lamont> me too
<lamont> but the uch script forces an ubuntu version number, which linux-source doesn't use
<lamont> must remember to always use uch for ubuntu, and fix the version, rather than the other way around.
<mdz> I just do the version manually
<lamont> yeah - that's what I was just reminded of, albeit a day late and all that
<lamont> OTOH, I expect we'll have -17 before we ship... :-)
<lamont> :-(
<lamont> should our pop-con Recommend an MTA, or just not even suggest it?
<mdz> I think it shouldn't even look at an MTA
<lamont> was kinda thinking that too, but wanted to check 
* lamont pounds head on desk
* lamont tries to understand why his mail was from katie, but everyone else is from them...
<mdz> whitelisting?
<lamont> dunno
<mdz> jdub: ping?
<jdub> mdz: ready when you are
<mdz> jdub: cool, just a few minutes
<jdub> mdz: if you're claiming phonebills, calling this way would be handy; not sure how much time i have left on my card, and difficult to get another right now
<mdz> jdub: number?
<jdub> wiki ;)
<Rotund> Does anyone know how good of a job X.org's built-in autoconfiguration works?
<daniels> jdub: do you need a card?  i have a $10 globaldial that i'm not using
<daniels> Rotund: 'very bad'.
<Rotund> okay.  A friend of mine used it and said it did an okay job (though I think he still tweaked it afterwards
<daniels> it wasn't usable as the base for hoary's x autoconfiguration
<Rotund> daniels: okay.  Did you get the AMD64 stuff figured out?
<Rotund> also, would a "flicker" for each video output be not suggested?
<daniels> Rotund: a) not yet, I have other things to do, but it's on my TODO (and will be non-trivial), b) what's a 'flicker' in this context?
<Rotund> the -xprobe
<Rotund> x -probeonly
<daniels> in an ideal world, it wouldn't happen
<daniels> but you do need it for laptops
<Rotund> mine does it currently as well
<daniels> having it happen for CRTs is suboptimal and I'm still convinced that the best solution is just to make ddcprobe a part of vbetool, and make vbetool use x86emu so it's portable to all architectures which support VBE
<Rotund> does hoary user discover1-data 1.2004.11,27ubuntu2?
<Rotund> s/user/use/
<daniels> erk, glibc ftbfs on i386, breaking locales
<fabbione> morning
* daniels STARES at his amd64.
<daniels> now it's not booting.
<dilinger> daniels: a watched pot never boils
<HrdwrBoB> dilinger: it does!
<HrdwrBoB> it just takes a little bit longer!
<lamont> fabbione: good morning.
<lamont> fabbione: btw, -16 uploaded
<lamont> fabbione: do we have a repository for the source somewhere that I should commit to?
<fabbione> hem no
<fabbione> and i had local changes too
<lamont> I'll mail you the (trivial) diff
<fabbione> ah i see.. you did the same changes as i had in my local tree
<fabbione> ok.. that's fine
<fabbione> 2.6.10 is go for the team
<fabbione> i am finishing 2.6.11 for ppc
<fabbione> it's the only arch that is still FTBFS
<lamont> diff sent, fwiw
<fabbione> no problem.. i can just grab the sources
<fabbione> same changes = no need to get crazy
<fabbione> lamont: did you try to access vultus5?=
<lamont> and kamion will kick a d-i rebuild and livecd cdrom process so that we have an ia64 livecd/installcd to play with later.
<fabbione> cool
<lamont> hrm.. knew I was supposed to do something in that regard...
<fabbione> ahha
<fabbione> don't worry
<fabbione> there is no rush
<fabbione> as i wrote.. i don't expect you to do everything for me
<fabbione> just to keep an eye ;)
<lamont> Permission denied (publickey).
<fabbione> to which machine?
<fabbione> from where?
<lamont> trider-g7 from mix.mmjgroup.com
<daniels> morning fabbione
<fabbione> hmmm
<fabbione> why is you key so different from the others?
<fabbione> lamont: are you sure you did send me the public key?
<fabbione> lamont: there is definetely something wrong
<Rotund> how do find the NV # of your video card (like NV25 or whatever)
<lamont> fabbione: mailing you the ssh2 key.
<fabbione> lamont: ok
<daniels> Rotund: lspci, and again, tihs is probably more on-topic for #xorg
<lamont> fabbione: which gpg key are you using these days?
<fabbione> lamont: all of them are active
<lamont> @c.c
<fabbione> use the one you prefer
<Rotund> daniels: sorry.  It's not in discover1-data.  I'm adding a bug report to add the line to the pci.lst
<daniels> Rotund: the warty or hoary version?
<lamont> fabbione: gotta remember that .identity is ssh1... :-(
<Rotund> I think it's hoary
<fabbione> ehehe
<fabbione> lamont: try now
<lamont> much better
<fabbione> no doubts :-)
<lamont> and in on vultus5
<fabbione> cool
<lamont> looks like most everything just runs, yes?
<fabbione> exactly
<lamont> so I should really just log in every so often to make sure that it's alive, etc.
<fabbione> it's enough you check the build logs
* lamont has a sparcstation 20 in his office now
<fabbione> and you can do that via imaps :-)
<fabbione> but you can login in case
<lamont> xorg:                   05:12:55 (2 entries, sigma 00:34:12)
<lamont> ouch
<fabbione> yeah
<lamont> fabbione: never used imap - I'll have to figure out how to get mutt to do that...
<fabbione> i don't have too much disk space for ccache
<lamont> ah, that'd explain part of that
<lamont> hppa does it in 3 hours..
<fabbione> lamont: you can use thunderbird as temporary solution
<fabbione> unfortunatly i forgot the 18GB disk in another sparc
<fabbione> that is turned off under the desk of a friend of mine
<lamont> oops
<fabbione> yeah
<lamont> likewise for logs, I can just login and rummage around in ~/logs, etc.
<fabbione> when i will be back from the honeymoon i will switch to hoary
<fabbione> and add disks and lvm
<fabbione> yeah
<fabbione> usually there is no need to trash the logs
* lamont has baby sat buildd's where he _only_ got mail before... not having any is about the same level of pain, only somewhat different...
<fabbione> the only time i run out of space was because of langpacks
<lamont> rummage == look
<fabbione> you still get them via email :-)
<fabbione> i reenabled the sendmail functionalities
<fabbione> that's why i said that imap will give you a good overview
<fabbione> lamont: 2.6.11 will be FTBFS on hppa
<fabbione> at least on version 0.1
<fabbione> ggg didn't upgrade f11, so i couldn't create the configs
<fabbione> s/create/update/
<lamont> fabbione: np.   I'll pester him to get something that runs well again.
<fabbione> that'd be cool
<fabbione> but there is no rush my side
<fabbione> i need to write the docs
<fabbione> upload 11-0.1
<lamont> he was out of town until about 10 hours ago or so
<fabbione> and after that the team will have some fun :-)
<daniels> fuck.  clearing the cmos hasn't helped.
<lamont> fabbione: night then
* lamont falls over
<fabbione> night lamont
<daniels> fabbione: morning
<fabbione> sup?
* fabbione kicks ppc right in the processor
<fabbione> drivers/scsi/ips.c:214:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms"
* fabbione sighs
<glyph> Hello there developers
<glyph> The dependencies in the package for 'straw' are wrong - it doesn't Depends: python-gnome2-extras but it does require gtkhtml2 bindings
<glyph> also I tried to report it using reportbug, but it crashed :)
<fabbione> glyph: use bugzilla.ubuntu.com please
<glyph> fabbione: Thanks.
<fabbione> to report both bugs
<fabbione> wecome :-)
<fabbione> welcome
<pitti> Morning
<fabbione> hey pitti
<thully> hi - does anyone know if CDs are supposed to appear on the desktop when inserted, or if this has been changed from Warty?   I was going to report this as a bug but wondered if it was a feature...
<pitti> thully: this was supposed to work for Warty, too
<pitti> fabbione: hey, my cronjob worked. This could be interesting for you, too: http://people.ubuntu.com/~pitti/ubuntu-cve.html
<fabbione> SWEEEEEET!!!!!!
<crimsun> pitti: what's new in hardened-1-...2.6.10-3?
<pitti> crimsun: just updates to latest crack and some bugfixes
<crimsun> pitti: ok, thanks. I'll pull it in a sec.
<pitti> fabbione: hey, just noticed a bug in the script (it does not catch the second and further CAN in one line)
<thully> No - it worked in warty, doesn't seem to in hoary though
<crimsun> thully: works on my hoary system
<daniels> pitti: nice!
<pitti> daniels: that summary already helps me a lot :-) it was overdue
<thully> maybe dist-upgrading will fix this...
<pitti> thully: hmm, please find/file a bug (against gnome-volume-manager)
<thully> so, is the feature freeze in full effect?
<mdz> such as it is
<thully> If not, I was going to suggest that w/kdelibs in main, k3b should also be considered (because Ubuntu really lacks in CD burning capabilities without using universe)
<thully> well, I'll dist-upgrade later and then try again...
<thully> I noticed that netapplet is in Hoary's universe now... so far, looks good (but I have yet to try a wireless connection with it)
<thully> out of curiosity, why wasn't this considered back when NetworkManager was being considered a couple months ago? Was it not out then?
<mdz> thully: it was; it has been in development since that time
<thully> OK - well, at least it's in universe 
<thully> well, leaving now - bye
<jdub> pitti: rad!
<pitti> jdub: what?
<jdub> pitti: cve page
<pitti> jdub: ah, that one :-)
<IRCMonkey> testing...
<pitti> jdub: I want to extend it a bit to also support manuall additions (where a CAN is not mentioned or gets assigned later)
<pitti> mdz: still awake?
<mdz> pitti: yes
<dholbach> good morning
<pitti> mdz: I cleaned up and improved hpoj a bit; do you want to test it or shall I just upload it?
<pitti> Hi dholbach 
<dholbach> hi pitti :-)
<mdz> pitti: what did you change?
* fabbione larts powerpc and ponders releaseing 2.6.11 without
<pitti> mdz: create/remove user "hpojlp", use that instead, added README.Debian, removed configuration from postisnt, fixed package cleaning
<pitti> mdz: nothing that should really break your changes, but should be done for a supported package
<mdz> pitti: sounds fine
* pitti spanks fabbione with his ibook
<pitti> mdz: I'd say for now I upload it without a seed change, so that it can receive some testing
<mdz> ok
<pitti> mdz: do we need an upload for a seed change to become active?
<pitti> mdz: or can we just promote an existing version into supported?
<pitti> Hi mvo_ 
<dholbach> morning mvo_
<pitti> mvo_: would it be possible to fix your Ubuntu CD hal script to ignore live CDs?
<mvo_> hi pitti, hi dholbach, hi all
<mvo_> pitti: this came up before and I thought kamion would fix it (so that no empty Packages files are generated on the live-cd)
<jdub> mvo_: i think it makes sense to pop up that dialogue for any cd with packages files on it (good for third parties), but testing for zero length might be a quick way around it ;)
<mvo_> jdub: I agree. I use apt-cdrom for the detection so I would have to teach apt-cdrom about this
<pitti> mvo_: hmm, I just inserted a current daily hoary cd, but still it downloads the packages from the net :-(
<zerokarmaleft> hi all...i'm doing some package upgrading atm, and there's a couple of gcc 4.0 libs (libgcc1, libobjc1)...is hoary taking the leap to gcc 4.0?
<mvo_> pitti: all packages? or only the packages that are more current than on the cd?
<pitti> mvo_: I suppose only the newer ones
<pitti> mvo_: but it downloads 134 packages
<pitti> mvo_: seems that yesterday had an upload rave
<pitti> s/had/was/
<pitti> mvo_: I check that
<mvo_> pitti: I see 187 updates on my machine
<mdz> pitti: hmm
<mdz> pitti: I just tried to scan something, and it is not working anymore
<mdz> my scan test may have been faulty
<pitti> mvo_: e. g. sound-juicer_2.9.91-0ubuntu3_i386.deb is on the CD, but it still downloads it off the net
<pitti> mvo_: that's bad :-(
<pitti> mvo_: I hoped that it would be enough to update the daily CD and upgrade from it, rather than downloading the new stuff twice
<mdz> pitti: I think it may be related to permissions in /proc/bus/usb
<pitti> mdz: ah, right; I think there even as a bug about that
<fabbione> later fellas
* fabbione &
<pitti> mdz: is the device root:root?
<pitti> mdz: I thought libsane had a hotplug usermap which changes the permissions?
<pitti> mdz: s/permissions/owner, group/
<mdz> pitti: apparently it does not set the permissions for my device
<mdz> pitti: at any rate, it goes through hpoj
<mdz> which runs as group lp, not scanner, currently
<mdz> I assume that with your changes, we could add the hpoj user to scanner
<pitti> mdz: right, I just thought the same
<pitti> mdz: it might be necessary to modify the daemon to use setgroups()
<mvo_> pitti: hrm ... so it does not install anything from the cd? or only a random selection is taken from the net instead of the cd?
<pitti> mvo_: hard to see in synaptic, during installation the progress bar does not show the number of packages
<pitti> mvo_: it might be a race between CD and network when the same version is available from both
<mvo_> pitti: uncheck "Settings/Preferences/Apply changes in terminal window" (so that you see the packages during install) and click on the "details" expander to see details during download
<pitti> mvo_: okay, I do that tomorrow on next upgrade
<mvo_> pitti: I'll see if I can reproduce the problem here
<pitti> mvo_: btw, I do see the changes in a terminal window
<mvo_> pitti: that why I asked you to change the preference :) the old default was "apply changes in terminal" the new is to only show a progress bar
<mdz> pitti: hmm, something is not right with hpoj
<mdz> I will need more testing before we can upload the changes, I think
<pitti> mdz: too bad, I already uploaded it :-(
<mdz> hehe
<pitti> mdz: however, I will fix the package to use the scanner group in addition
<mdz> I'm not sure why it is breaking now, I was sure it was working earlier
<pitti> mdz: (add hpoj to scanner and use setgroups() )
<pitti> mdz: then we only need to fix libsane to set correct device permissions
<pitti> mdz: so the libsane usermap script is buggy?
<mvo_> jdub: do you have contact to icon designer? #6370 asks for a new icon for update-notifier 
<mdz> even if I start ptal-printd as root, it doesn't work
<jdub> mvo_: yeah, i've been thinking about that
<pitti> mdz: oops?
<jdub> mvo_: it's on my list for our icon designer
<pitti> mdz: you derooted root? :-)
<mvo_> jdub: wonderfull, thanks
<mdz> Feb 10 00:33:10 localhost ptal-mlcd: ERROR at ExMgr.cpp:3762, dev=<mlc:usb:officejet_5500_series@/dev/usb/lp0>, pid=30197, e=1, t=1108024390         Couldn't claim interface=2!
<mdz> USB error: could not claim interface 2: Operation not permitted
<pitti> mdz: EPERM for root? that's odd
<mdz> pitti: chmod +w on /proc/bus/usb/*/* lets it work
<mdz> (running as daemon/lp nowR
<mdz> s/R/)/
<mvo_> mdz: did you had a chance to look over the apt-listchanges diff I send you? 
<mdz> mvo_: not yet
<doko> lamont: the glibc build succeeded using only one CPU ...
<haggai> morning
<mvo_> morning haggai 
<haggai> an mvo_.  How's your UI? :)
<mvo_> good I hope :)
<haggai> heh
<dholbach> hi haggai
<pitti> mdz: ok, that's a libusb issue
<mdz> pitti: yes, it was hidden by the fact that hpoj ran as root
<mdz> Bus 001 Device 062: ID 03f0:3a11 Hewlett-Packard
<mdz> that's my device
<mdz> pitti: unfortunately, there are probably many related bugs
<mdz> we would need to collect a list of all hpoj devices
<mdz> daniels: why does hpoj hate you?
<TreadingSoftl1> Hi folks. I'm trying to autogen gtk-sharp from the mono repositories, with the ultimate aim of getting Beagle up and running. Autogen says that the following packages - gnome-sharp.dll gda-sharp.dll gnomedb-sharp.dll rsvg-sharp.dll gtkhtml-sharp.dll vte-sharp.dll panelapplet-sharp.dll - are "optional assemblies" that haven't been "included in the build". Then it says: "you may install the corresponding development packages for them, rerun autoge
<Treenaks> TreadingSoftl1: you can just apt-get install libgtk-cil
<TreadingSoftl1> Treenaks: no... my libgtk-cil is already the newest version
<Treenaks> TreadingSoftl1: install other packages, look at:
<Treenaks> apt-cache search -cil$
<TreadingSoftl1> Treenaks: E: Opening configuration file il$ - ifstream::ifstream (2 No such file or directory)  ???
<Treenaks> uh
<Treenaks> apt-cache search -- -cil$
<Treenaks> sorry
<TreadingSoftl1> Treenaks: np
<TreadingSoftl1> Treenaks: ah ... that looks helpful
<bob2> did something lately nuke nautilus icons?
<Treenaks> bob2: not that I know.. I still have them
<TreadingSoftl1> Trenaks: apt-get install couldn't find lib-gnome-cil or lib-gmime-cil; other than that all those packages were the "newest version"
<TreadingSoftl1> Treenaks: ^^^
<Treenaks> TreadingSoftl1: don't but a "-" between lib and gnome
<Treenaks> or lib and gmime
<TreadingSoftl1> Treenaks: ah, thanks
<TreadingSoftl1> Treenaks: ok ... those were the newest version too
<pitti> mdz: can you please send me the relevant sysfs directory? we could change the libsane script to use sysfs too (similarly to the libgphoto script)
<Treenaks> TreadingSoftl1: then you don't need to build gtk-sharp -- you already have it
<TreadingSoftl1> Treenaks: Hmm... but when i try and autogen gst-sharp I get "configure: error: Library requirements (gtk-sharp-2.0 >= 1.9) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them."
<Treenaks> ah ok
<Treenaks> then the version in ubuntu is too old
<TreadingSoftl1> Treenaks: that's what i had assumed. That's why I'm trying to build gtk-sharp from the mono repository. I just don't understand what i'm supposed to do to include gnome-sharp.dll gda-sharp.dll gnomedb-sharp.dll rsvg-sharp.dll gtkhtml-sharp.dll vte-sharp.dll panelapplet-sharp.dll in gtk-sharp.
<Treenaks> TreadingSoftl1: install libgnome-dev, libgda-dev, libgnomedb-dev, etc.
<sivang> Morning all!
<TreadingSoftl1> Treenaks: ah, okay, thanks
<mdz> pitti: sent
<dholbach> TreadingSoftl1: you also could   apt-get build-dep gtk-sharp
<Treenaks> dholbach: oh nice one ;)
<dholbach> hi sivang
<Treenaks> hey sivang
<sivang> hey dholbach, Treenaks 
<TreadingSoftl1> dholbach: that will be a new version?
<dholbach> TreadingSoftl1: no, it will give you the build's dependencies
<dholbach> TreadingSoftl1: at least those of the "old" package
<dholbach> so that's a start
<TreadingSoftl1> dholbach: i think i see ... thanks
* sivang got his first set of cds today, yay!
<sivang> (finally, damn custom department)
<dholbach> sivang: :-)
<Treenaks> sivang: Israeli customs take that long to precess a few CDs?
<sivang> dholbach: you should note that I am very calm with my reaction, ask others when they got their's ;-)
<Treenaks> process
<sivang> Treenaks: don't ask, let's say some people here invented buracracy :)
<dholbach> sivang: i noticed :-)
<dholbach> sivang: i thougth that's what they say about germans? :-)
<sivang> dholbach: naaahhh, you're way cool, believe me, although pitti noted something very bureaucractic about your passports or something?
<Treenaks> sivang: oh I believe that
<doko> daniels: ping?
<TreadingSoftl1> Hi guys: the helpful advice of dholbach and Treenaks has solved the problem for all packages except this one: panelapplet-sharp.dll
<TreadingSoftl1> update: ah, got that with panel-applet
<mjt> so, what a problem was yesterday with MD5Sum mismatches in hoary repo?
<dholbach> TreadingSoftl1: if you look for packages or files which may be in a package go and install yourself  apt-file
<dholbach> TreadingSoftl1: apt-file search filename.bla   helps then
<pvh> Is a Hoary gdesklets problem something worth filing a bug over?
<mdz> gdesklets is in universe
<pvh> Yes, I wouldn't want to support it either.
<dholbach> pvh: it conflicts with liferea or something?
<pvh> But it's very popular, so I thought there might be some unofficial concern.
<pvh> dholbach: It might, but I don't have liferea installed on this machine.
<pvh> dholbach: It just doesn't have access to any sensor information.
<dholbach> pvh: ah ok
<TreadingSoftl1> argh... trying to checkinstall gtk-sharp; got this as reason unable to not install package: "libgtk-cil conflicts with gtk-sharp ... gtk-sharp (version treadingsoftly-1-1) is to be installed ...  conflicting packages - not installing gtk-sharp"
<pvh> dholbach: I know gdesklets uses 'sensor' in a non-standard way. I mean that it can't seem to detect cpu usage or other statistics.
<dholbach> pvh: i just saw something about the packaging
<pvh> dholbach: I suspect an unfulfilled python dep.
<dholbach> pvh: maybe it's a case for an upstream bug
<pvh> dholbach: I can paste you a relevant bit of my log if you'd like.
<TreadingSoftl1> do i just apt-get remove libgtk-cil?
<dholbach> pvh: i dont understand anything about sensors
<pvh> dholbach: No worries.
<dholbach> pvh: so i wouldnt be of any help :-)
<ogra> dholbach: i think he means the gdesklet sensors (its just a python snippet gdesklet uses, they call it sensor for whatever reason)
<pitti> ogra: ping
<ogra> morningg
<pitti> Hi ogra
<TreadingSoftl1> if i apt-get remove libgtk-cil it wants to remove libgecko-cil libglade-cil libgnome-cil libgtk-cil libgtksourceview-cil libvte-cil
<TreadingSoftl1>  too... but aren't those needed to build gtk-sharp?
<pitti> ogra: cool that it works now :-) Stupid bug...
<pvh> ogra: Aye.
<dholbach> ogra: ok... i see
<ogra> pitti: so how does it look (seen my mail ?)
<dholbach> ogra: i just saw a packaging issue, funnily gdesklets conflicted with gdesklets
<pitti> ogra: of course you can change debian/control, but you should keep the patch separate (we apply it in-line instead of in debian/patches)
<dholbach> ogra: i'll have a look at it
<pitti> ogra: did not yet look at the code
<pitti> ogra: ahem, your new mail (AARGH) does not contain any patches
<dholbach> good morning seb128
<pitti> Hi seb128 
<seb128> hello
<pvh> dholbach: Any advice on how to debug the possibility of a missing python module from the deps?
<pvh> dholbach: I'm a perlnerd, and my python experience is limited.
<pitti> ogra: ah, just saw your second mail
<dholbach> pvh: give me your ouput in a query... maybe i see something about it
<ogra> pitti: hmm... then i'll send this one in the end, a recommends to dmidecode and to hwdb-client should be in too... 
<sivang> seb128: bon jour :)
<pitti> ogra: <nitpick>your Makefile.am patch changes only whitespace, could you fix that?</nitpick>
<ogra> pitti: huh ? +       linux/lsb_release.h             linux/lsb_release.c             \ ?
<pitti> ogra: you must not close both handle and fds[0]  (these are just aliases)
<pitti> ogra: yes, the addition is okay, but not the change of the previous line
<ajmitch> hi
<pitti> ogra: I don't think that closing the descriptor two times hurts, but it should be fixed
<pitti> Hi ajmitch 
<ogra> pitti: ah, now i see.... (Makefile.am)
<pitti> ogra: otherwise it really looks good now :-)
<ogra> yay !
<pitti> ogra: sorry for being so picky, but one should be proud of his code :-)
* ajmitch sees confusions over gtk# above - there are both 1.0 & 2.0 of gtk# :(
<ogra> pitti; i'll update it and send number two from the office then....
<ogra> pitti: without that we would have crappy software and i would still not write better code ;)
<ogra> pitti: please be aspicky as you can !!
<sivang> pitti: I thank you'r nitpicking also, made my patches really clean :)
<pitti> ogra: that's the point, if you learn something from it, it's the best I can achieve :-
<TreadingSoftl1> ajmitch: hello again
<ajmitch> hi
* dholbach will now have that stupid song "Hello again" for the rest of the day *shudder*
<TreadingSoftl1> ajmitch: do you what to do when checkinstalling my gtk-sharp compilation conflicts with libgtk-cil?
<ogra> dholbach: at least it is from an southafrican ;)
<dholbach> ogra: is it? i never realized
<ajmitch> TreadingSoftl1: sorry?
<ogra> dholbach: yup, the guy is .za's biggest export of the 80's
<ogra> dholbach: but i dont think he is popular anywhere out of germany....
<mjg59> fabbione: Argh why must you assign me Eugenia bugs?
<ogra> lol
<ajmitch> TreadingSoftl1: I'm going to install beagle myself & see what happens :)
* mvo_ chuckles
<dholbach> ogra: that makes me think: were "modern talking" germany's biggest export of the 80's? *shudder even more*
<Kamion> mvo_: oops, sorry, I forgot about that live CD Packages thing; I've stuck it in ~/ubuntu/status now so I won't forget again
<ogra> dholbach: did anybody out of germany hear them ?
<TreadingSoftl1> ajmitch: i compiled my own gtk-sharp from the mono depository. But when I tried to checkinstall it, the resulting package conflicted with libgtk-cil and wouldn't install.
<dholbach> ogra: hmmm... i never investigated :-)
<ogra> Kamion: any feedback from lamont about gparted etc. ?
<ajmitch> TreadingSoftl1: because you may have grabbed a different gtk# than what is intended?
<ajmitch> I'm not sure as I haven't looked at it
<Kamion> ogra: he said it was fine, I'll mention to mako when he gets up
<ogra> Kamion: wow, great.... dholbach will be a big help for us :)
<TreadingSoftl1> definitely the standard gtk-sharp: followed instructions here: http://www.mono-project.com/contributing/anoncvs.html
<dholbach> kamion,ogra: WOW cool! :-)
<Kamion> ogra: this was just for membership BTW
<ajmitch> TreadingSoftl1: yes, which is already on your system
<ajmitch> gsf-sharp appears to need gtk-sharp 2.0
<ogra> Kamion: urgs, why that ?
<Kamion> ogra: that's all that was being voted on? let me go check
<TreadingSoftl1> ajmitch: yes but libgtk-cil is an earlier gtk-sharp. The CVS ought to be a newer gtk-sharp...
<Kamion> ogra: oh, damnit, I completely misunderstood what was going on
<ogra> Kamion: i'm wondering why packages get reviewed for membership now....
<ogra> lol
<Kamion> ogra: (membership involves contribution to the community)
<Kamion> *sigh* ok, let me go look myself
<ajmitch> you're right, it does appear to be
<Kamion> dholbach: what's the package into which you've put most effort, which you'd say is the best showcase?
<TreadingSoftl1> Is there a way to create a checkinstall package without actually installing the package?
<dholbach> Kamion: gparted is a good one, timer-applet too
<ogra> Kamion: dholbach already maintains several packages in universe .... its just the missing upload status....
<ogra> dholbach: or bluefish....
<dholbach> Kamion: altough i had more work with libg*mm (which was superseded by btb@debian.org's ones)
<dholbach> s/was/were
<ajmitch> TreadingSoftl1: in an hour or so I'll have downloaded the needed parts to build it ;)
<TreadingSoftl1> ajmitch: cool
<Kamion> dholbach: was gparted packaged from scratch? I notice stuff in the NEWS file about other packagings
<dholbach> Kamion: packaged from scratch, their "packaging" wasn't worth it at all
<Kamion> dholbach: heh, ok
<Kamion> dholbach: hm, there are patches to generated files there (Makefile.in, configure) without corresponding patches to the source (Makefile.am, configure.in/configure.ac). What's that about?
<zul> hey
<Kamion> dholbach: (also, "partition table" rather than "partitiontable" in debian/control)
<Kamion> (or "tables", whatever)
<dholbach> Kamion: i nicked the description of their webpage but i'll correct that
<Kamion> dholbach: also, you should get amu to stop putting "NMU" in your changelogs, if it's him :)
<Kamion> we don't really have NMUs in Ubuntu
<ogra> lol
<dholbach> Kamion: yes.. i'll tell him
<dholbach> Kamion: we should have our own lintian then ;-)
<Kamion> we do already, sort of
<ogra> Kamion: this should get patched out of lintian
<Kamion> maybe I should modify it further, yes
<ogra> dupload/dput would also need such a patch....
<Kamion> why?
<ogra> to piont to upload.ubuntu by default ? 
<zul> fabbione, how is it going?
<dholbach> i also generalized dh-make, if someone would review the patch and mind an upload :-)
<jdub> Kinnison: send SIGUSR2 to the server
<Kinnison> jdub: okay
<jdub> Kinnison: or a specific client that is giving you problems
<ajmitch> ogra: it'd save people accidentally uploading to debian? :)
<Kamion> ogra: hm, well that's entirely different, but arguably yeah
<ogra> Kamion: my first upload went to debian....
<Kamion> yeah, but you have to get the distribution wrong *as well* for that to matter :)
<Kinnison> jdub: can I then tail -f the log file and do stuff?
<jdub> yeah
<ogra> Kamion: heh, remember my first package ? the distibution was wrong ;)
<jdub> another ubuntu koan
<Kinnison> Right, that log indicates that gam_server's event dispatch stuff is definitely broken from the filename PoV
<jdub> "NMU is a four letter word."
<jdub> Kinnison: hrm, and updates are working here... :|
<ajmitch> jdub: about evo-sharp on the list, I've got it mostly packaged, can't test it until I get beagle built :)
<dholbach> see   http://moz.gotdns.org/dh-make.lsb.patch   for that :-)
<Kamion> ew, dh-make
<jdub> ajmitch: write code to test it ;)
<ajmitch> jdub: the main problem is that I don't use evo..
<Kamion> doesn't everyone make packages by hand based on the last similar package they did? :)
<jdub> ajmitch: doesn't it have testy scripts and stuff?
<jdub> ajmitch: ah
<jdub> Kamion: and with cdbs! :)
<ajmitch> mutt is the MUA for me
<dredg> Kamion: yeah, using cdbs
<ajmitch> Kamion: well, yeah
<ogra> Kamion: to fiddle hours with the leftovers ?
* Kamion makes the sign of the cross at jdub and dredg
<jdub> ajmitch: you know you want to write a mutt plugin
<Kamion> ogra: doesn't take remotely that long, more like five minutes
<dholbach> hihi
<Kinnison> jdub: I guess I could get the source and do some manic debugging later
<ajmitch> jdub: oh yeah, might as well write an imap server plugin :)
<jdub> ajmitch: and make it so you can open specific msgids and maildir files from the mutt command line
<Kinnison> jdub: I'll get back to you when I have moreinfo (or ideally a patch)
<jdub> Kinnison: ok, thanks
<ajmitch> most of my mail is still in massive (>100MB) mbox files
<ogra> Kamion: i nnoramlly run dh_make and copy over the useful bits :)
<jdub> Kinnison: you've killed gam_server and nautilus?
<Kamion> dholbach: ok, so most stuff is fine, what about the generated files thing?
<Kamion> in gparted
<dholbach> Kamion: i'll investigate it... it must be something about the ./pixmaps i added
<ajmitch> I'm sure that the worst thing about lca 2006 will be the lack of bandwidth
<Kinnison> jdub: yeah, I tried that deep
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<Kamion> dholbach: ok, basically those changes should always be made to configure.in/ac rather than configure, etc., and the autotools re-run; if that's too hard or produces too huge a diff (for example because you have very much different versions of the autotools to upstream), then ...
<Kinnison> jdub: Interestingly your 0.0.23 upload hasn't built yet
<jdub> Kinnison: oh
<Kamion> dholbach: ... a common approach is not to patch the upstream build system at all, but just to build what you need directly from debian/rules
* jdub checks
<jdub> *boggle*
<jdub> successful on everything *but* i386
<jdub> you have *got* to be joking
<jdub> that is unnatural
<dholbach> Kamion: you reckon i'd better use dpatch for that?
<Kinnison> jdub: missing dep or something? because I've just built it on my i386 laptop
<jdub> checking for python... no
<jdub> on i386
<Kamion> dholbach: no, personally I *much* prefer monolithic diffs; they're far easier to read and review
<jdub> even though it installed python2.4, python2.4-minimal, python2.4-dev
<Kamion> dholbach: i.e. the way you currently have it
<Kinnison> jdub: boggle
<seb128> sjoerd: around ? :)
<jdub> checking for python... /usr/bin/python
<jdub> Found Python version 2.4
<jdub> ^ powerpc
<Kamion> dholbach: oh, in the "nitpicky" department, remove usr/sbin from debian/dirs if you don't need it. :) (both gparted and timer-applet)
<jdub> YOUR MOTHER
<jdub> lamont: dude?
<dholbach> Kamion: thanks for that
<jdub> http://people.ubuntulinux.org/~lamont/buildLogs/g/gamin/0.0.23-0ubuntu1/
<TreadingSoftl1> what's the easiest way to create a .deb package (for personal use) out my gtk-sharp compilation ... without installing it?
<jdub> lamont: wtf?
<seb128> daniels: what is /etc/X11/Xsession.d/75dbus-1-utils_dbus-launch for ?
<sjoerd> seb128: pong
<jdub> seb128: session dbus, innit?
<seb128> jdub: who should stop it when you log out ?
<pitti> jdub: the user's dbus instances are not killed on session end
<Kinnison> jdub: I'll investigate later
<ajmitch> jdub: isn't /usr/bin/python in the python-minimal package, not the 2.4 package?
<dholbach> Kamion: so i take care of mentioned things, let someone do the upload and haggai, lamont and you get together again?
<jdub> Setting up python2.4-minimal (2.4dfsg-1ubuntu2) ...
<jdub> ajmitch: ^
<ajmitch> jdub: that's what I mean
<ajmitch> python-minimal, not python2.4-minimal
<jdub> cripes, it is too
<spiv> jdub: That would install /usr/bin/python2.4, not /usr/bin/python...?
<Kamion> dholbach: timer-applet's diff adds completely new config.guess and config.sub files; perhaps that bit in debian/rules isn't needed, since upstream obviously doesn't use those files? I'd remove that bit from debian/rules and both the config.guess and config.sub files
<doko> elmo: ping?
<jdub> but it's the same package on ppc!
<Kamion> dholbach: go ahead and fix those, but I'm happy enough with what I've seen to ack you for MOTU
<jdub> and powerpc doesn't install python-minimal
<ogra> YAY !!!
<dholbach> YAY! YAY! YAY! :-)
<ajmitch> dholbach: so this is welcome to the club :)
<spiv> jdub: ...does powerpc install "python"?
* dholbach does the funky Ubuntu MOTU dance
<doko> jdub: why?
<jdub> spiv: nup
<Kamion> elmo,mako: ^-- ogra also approved dholbach for MOTU, could you arrange that with him?
* dholbach gives high fives to ogra and ajmitch
<ogra> finally we have a gtkmm guy to poke on bugs 
<TreadingSoftl1> congratulation dholbach
<jdub> doko: http://people.ubuntulinux.org/~lamont/buildLogs/g/gamin/0.0.23-0ubuntu1/
<jdub> doko: weirdness :-)
<ogra> hehe
<dholbach> TreadingSoftl1: thanksssssssssss :-)
<spiv> jdub: Hmm, so I see in the log.  Bizarre :)
<seb128> jdub: same about gam_server, who should stop it ?
<jdub> dholbach: i will only congratulate you on first upload ;-)
<dholbach> jdub: first mis-upload to debian, hm? :-)
<Kamion> dholbach: sorry I didn't get round to it earlier; feature freeze has been keeping me very busy last couple of days
<jdub> seb128: i think we should distribute a little buddy jesus to stop errant daemons on our user's machines
<doko> jdub: no, it doesn't build depend on python
<jdub> seb128: he can be all, "THOU SHALT STOP! Hey, how's it going' honey?"
<seb128> ahahah :)
<dholbach> Kamion: i completely understand... there were other guys, who could have done it too :-)
<jdub> doko: sure, but how is it that everything but i386 succeeds?
<spiv> jdub: Regardless of why it succeeded or failed on individual platforms, shouldn't the configure be checking for python2.4 not python?
<jdub> spiv: configure checks for python, then figures out what it is to do the right thing
<ajmitch> spiv: that'd break once py 2.5+ came out
<jdub> spiv: sorry you've had to wait - perhaps you should think about investing in a second class architecture ;)
<spiv> ajmitch: Well, I was assuming the packaging was hard-coded to installing to /usr/bin/python2.4 anyway, but I really should just shut up because I don't actually know anything about packaging :)
<spiv> (er, /usr/lib/python2.4
<spiv> )
<seb128> grumpf, /me bug flooded by "you should change this label, this windows doesn't look nice, ..."
<ajmitch> spiv: possibly, which is why we're having fun changing a bunch of packages in universe for python 2.4 :)
<ogra> seb128: yeah, make it more greenish in the lower right corner and a red dot in the beginning of the label would be fine too.... :-P
<pvh> ajmitch: Broken 2.4 stuff?
<pvh> ajmitch: Like, say, gdesklets?
<jdub> yeah man
<ajmitch> pvh: sure, I'll try & take a look..
<jdub> python upgrades make baby jdub cry
<pvh> ajmitch: Because if someone with a Clue is already aware of this, maybe I should stop.
<ajmitch> just give me a few hours or a few Mbps of bandwidth :)
<ogra> seb128: dont you refuse to take such bugs ?
<pvh> ajmitch: /usr/lib/gdesklets/libdesklets/__init__.py
<pvh> amitch: I'm getting a lot of "AttributeError: 'module' object has no attribute 'sys'"
<seb128> ogra: no, I don't refuse bugs, but dunno what to do with all that
<jdub> doko: so best practice is to build depend on python and python2.5-dev?
<ogra> seb128: thats something for upstream...or not ?
<ajmitch> pvh: ok, this is in universe?
<seb128> ogra: that's something from the documentation team guys
<pvh> ajmitch: Aye.
<ogra> seb128: ouch
<seb128> ogra: but I would prefer to get them dealing with upstream directly
<ajmitch> seb128: you seen problems with gdesklets?
<ajmitch> I just noticed your name in changelog :)
<seb128> what kind of issue ?
<ajmitch> see pvh's errors above
<TreadingSoftl1> what do you package creating guys use if you just want to make a .deb package for your own use?
<ajmitch> I just noticed that configure.in has python 2.3 in it
<jdub> http://www.flevour.net/var/flinux_4.jpg <- ubuntu shirt IN ACTION
<jdub> doko: or should i build depend on python-dev?
<ogra> TreadingSoftl1: a package creation tool ?
* jdub does that instead
<ogra> TreadingSoftl1: (dh_make and the other debhelper scripts are a good start to look at)
<TreadingSoftl1> ogra: cool - i'll look into dh_make
<ajmitch> jdub: where can we get such shirts? ;)
<jdub> cafe press for now
<jdub> we're working on other stuff
<jdub> ajmitch: i'm going to do gnome tshirts for lca
<jdub> ajmitch: i might do ubuntu ones
<ajmitch> sweet
<ajmitch> bank balance isn't looking healthy for LCA
<jdub> we can be a gang
<jdub> and chace old grannies
<ogra> yeah
<jdub> chase
<pvh> TreadingSoftl1: I've heard people speak well of checkinstall
<ajmitch> btw you may need to fixup the rss reader (CMFSin?) on the frontpage, /. is blocked
<jdub> fabbione: WHERE IS YOUR UBUNTU SPARC BLOG? :-)
<seb128> jdub: what do you think about #6376 ?
<ajmitch> jdub: it just looks a little messy saying that slashdot has banned us :)
<jdub> ajmitch: shift-reload
<jdub> it hasn't been on the front page for at least a week now :)
<ajmitch> shocking
<jdub> seb128: WONTFIX
<ajmitch> to think that firefox would cache for that long
<seb128> jdub: I think so, thanks
<jdub> seb128: and i don't know how to say "no" to that politely
<jdub> seb128: so i will leave it in your capably french hands :)
<seb128> I'll close it as NOTWARTY and say that's an upstream decision :p
<TreadingSoftl1> pvh: thank you ... i usually use checkinstall ... however not installing the package when creating it is an option only in the new beta... so i'm looking for some way to create the package but not install it.
<jdub> hrm, we can't really use that as an excuse
<jdub> oh seb128 
<jdub> dude
<jdub> "Don't be fatuous, Corey."
<jdub> ^ perfect WONTFIX comment
<seb128> go for it :)
<jdub> ;)
<seb128> you have found it, you have won the right to use it :)
<pitti> elmo: xview sync, please
<pitti> elmo: pdftohtml sync, please
<seb128> pitti: evince sync too please (if you have not synced it yesterday)
<pitti> seb128: I can't *whine*
<seb128> oups
<seb128> s/pitti/elmo :)
<pitti> but I don't want to be substituted by elmo 
<seb128> you should :)
<seb128> you could make a good elmo, I'm sure :p
<pitti> :-)
<pitti> I don't even like English tea so much
<seb128> bah, I don't care as long as you sync evince now :p
<seb128> :)
* pitti tries really, really hard to sync evince
<pitti> seb128: hmm, he's marked as away
<pitti> Huh, seb128, have you forked?
<bob2> this is linux, clone()
<pitti> Does that mean you now can double your upload rate? :-)
<seb128_> grumpf, dsl hangup
<seb128_> pitti: this evince has a bonus for you
<seb128_> pitti: "Fix the fix for CAN-2004-0888" according to the changelog
<seb128_> SECURITY ISSUE
<seb128_> SYNC THAT NOW PITTI
<seb128_> correct :)
* pitti really wants to
<ogra> pitti: lets fork elmo if this works :)
<pitti> seb128_: I add it to my "to sync" list
<seb128_> so stop beeing lazy and do it :p
<pitti> seb128_: added to my list
<seb128_> thanks :)
<Kamion> elmo: bash: line 1: /home/archvsync/release-sync: No such file or directory
<Kamion> elmo: that's from syncproxy I think
<ajmitch> hi azeem 
* seb128 grumpfs
<bob2> hey ajmitch, congrats
<seb128> why the documentation guys just fill a ton of bug on strings 2 days after the string freeze
<pitti> dholbach: congrats for being a MOTU now :-)
<ajmitch> bob2: thanks
<bob2> seb128: they love you
<rubenv> dholbach: you're in? congrats!
<seb128> I'm tempted to close all the bug in a row
<Treenaks> seb128: bugs where? gnome bz or ubuntu bz?
<seb128> ubuntu bz
<seb128> but if we change a string at this level we throw away the translations
<mvo_> dholbach: congrats from me too!
<jdub> seb128: although rosetta can pick those up
<jdub> seb128: although that will infuriate the gnome i18n team
<jdub> seb128: etc. ... ;)
<seb128> we will not reach the upstream level for hoarry
<seb128> hoary
<dholbach> thanks pitti, thanks rubenv, thanks mdz and thanks mvo_ - i'm so glad "playing with you" (citing sabdfl) :-)
* rubenv should ask Mark someday where he got the sabdfl nick
<seb128> jdub: do we have something for bugs like #6386 ? That's an improvement request, but I don't want to get it assigned to me :p
<seb128> jdub: I've nothing against the idea, but ETOOMANYBUGS, it'll stay here for ages I'm pretty sure
<jdub> seb128: mmm
<jdub> seb128: hopefully malone will alleviate this in the future
<jdub> seb128: for now, we have to suffer open bugs :)
<jdub> seb128: click them down to enhancement, and make your default query ignore them ;)
<seb128> jdub: we could have a component "ideas to contribute" ? :)
<seb128> jdub: yeah, my only concern is that it'll stay ignored for ages here :p
<jdub> :)
<seb128> jdub: and having a pool of tasks to contribute could be nice
<seb128> with the "please package this" too
<jdub> heh
<haggai> dholbach: congrats :)
<jdub> yo haggai 
<haggai> Kamion: thanks for checking dholbach
<haggai> hey jdub
<jdub> seb128: probably best to keep these with their proper component though
<jdub> seb128: but yes, that's something we need to solve
<seb128> I don't want to change the component
<seb128> just the assignement
<jdub> why?
<seb128> because nobody will have a look to my bug
<seb128> and people will forget about it
<dholbach> haggai: i'm happy too
<sivang> seb128: what bug? :)
<seb128> getting a "I_want_to_contribute" assignement could be nice :)
<dholbach> seb128: b.g.o already has a flag like MINOR_FIX_FOR_BEGINNERS - but i feel like "look at the lists or bugzilla" doesnt help beginners to get involved
<rubenv> gnome-love!
<rubenv> we should have one of those too for ubuntu
<dholbach> yeah and according wiki-pages
<sivang> i think jdub is planning something like that
<sivang> don't recall for when it's schedules
<rubenv> nicely :-)
<sivang> jdub: ? ;-)
<dholbach> we should brainstorm on it in one of the meetings
<jdub> rubenv: next week, actually
<jdub> rubenv: sending announce tonight or tomorrow :)
<sivang> jdub: yay!
<rubenv> jdub: sweet, I'll start by removing it from the ideapool :-)
<Mithrandir> pitti: 6360 should be closed, right?
<pitti> Mithrandir: right, I already fixed Warty and Hoary yesterday
<Mithrandir> ack
<pitti> Mithrandir: I put the changelog there and close it
<Mithrandir> pitti: oh, ok.  I just closed it.
<Mithrandir> sorry :/
<pitti> ok, no problem :-)
<ajmitch> jdub: how effective has gnome-love been?
<jdub> pretty good
<jdub> got a bunch of new people grokking stuff
<sivang> ajmitch: It's been very much, note the applet and yelp love days :)
<rubenv> ajmitch: also: better something then nothing
<rubenv> I like gnome-love
<ajmitch> sivang: I only recently migrated back to gnome from kde :)
<jdub> ajmitch: kinda lacking in terms of superhacker involvement, but that won't be too much of a problem for us
<ajmitch> there's plenty of packages in universe that people can help out with, I'm sure :)
<sivang> ajmitch: ah, well, I did then about 1.5y ago :)
<ajmitch> sivang: I used to use gnome around the 1.0 & following days
<ajmitch> and then again after the 2.0 release
<ajmitch> things have changed a bit :)
* dredg made gnome usable by replacing metacity with xfwm4
<dredg> mmm edge flipping
<dredg> mmm gnome applets :)
<dredg> what a deal :)
<ajmitch> morning jbailey 
<jbailey> g'm Andrew!
<Mithrandir> hi jeff
<jbailey> Andrew, Tollef!
<dholbach> hi jbailey :-)
<jbailey> Err..  Whups.  I thought Andrew said hi in a different window. =)
<jbailey> dholbach: Hello
<ajmitch> heh, not today :)
<jbailey> Mithrandir: Are you open to the idea of including an exim4 config snippet to drop into place for mailman?
<Mithrandir> jbailey: I've thought about it, yes.
<Mithrandir> jbailey: it'd be kinda cool
<jbailey> Mithrandir: I have a friend who's put together the config snippet, apparently.  I can ask him to send it to you - Where would you like it?
<Mithrandir> jbailey: wishlist bug in debian bts would work fine
<jbailey> Mithrandir: Cool, thanks.
<Mitario> aloha
<Gagatan> Mithrandir: any updated info regarding kickstart-examples?
<Mithrandir> Gagatan: got a mail from Yngve, but nothing from Knut yet.
<Gagatan> Mithrandir: the kickstart-setup from the evalkit-installation would be nice to have if possible
<Mithrandir> Gagatan: which evalkit-installation?
<dholbach> wb ogra
<Gagatan> Mithrandir: Rander and I customized kickstart , so salespeople could use it :) they used to send evaluation-racks (6 servers, 2 switches and 1 kvm-switch) to possible customers for evaluation purposes
<Mithrandir> Gagatan: ah; I have no idea if that's what Kamion got.  It's probably easier for you to talk with him and see if we've gotten the right thing and if not help him get it. :)
<TreadingSoftly> ajmitch: how's that Beagle build coming along?
<Mithrandir> dholbach: welcome as MOTU :)
<dholbach> Mithrandir: thanks a lot :-)
<ajmitch> TreadingSoftly: works fine, haven't built gst-sharp
<ogra> pitti: dropping all the headers in my patch was not a good idea....
<pitti> ogra: which headers?
<TreadingSoftly> ajmitch: ah
<ogra> pitti: stdio.h unistd.h etc....
<pitti> ogra: you don't need them in the header file
<pitti> ogra: if the .c file needs them, put them into the .c file, not into the .h
<ogra> pitti: and the definition for the non exported functions from my .c file too ?
<pitti> ogra: the best is to define functions before you use them
<ogra> oki
<pitti> ogra: but if you define them later, you must at least declare them at the top
<pitti> (define = with body, declare = just signature)
<jdub> ahr!
<ogra> pitti: ok...i thought we were done with the first one....so i'll send another one
<ogra> *sigh*
<lamont> doko: so I guess we need an upload of new glibc source that fixes the issue, eh?
<pitti> ogra: did you fix the other two small issues (whitespace patch and close) too?
<pitti> Hi lamont
<Kamion> ogra: you might like to use gcc's -Wstrict-prototypes option
<doko> ok, will do. setting NJOBS unconditionally to 1
<Kamion> ogra: that will enforce that any non-static functions have a prototype (i.e. a declaration); that's stricter than you actually need, but it's a good check on errors
<ogra> pitti: yep, in the patch i sent you before driving to work....
<lamont> jdub: it's possible that something wierd happened... dunno
<ogra> Kamion: great tip, thanks :)
<lamont> morning pitti
* Kamion finishes off support for the live seed in germinate, and heads off to talk to his bank; back in a couple of hours
<Kamion> elmo: if you update germinate now you'll get support for the live seed, so ubuntu-live should get pulled in automatically
<zul> hola
<zul> er...hey
<seb128_> Mithrandir: any progress on evolution/amd64 ?
<fabbione> elmo: ping
<seb128> Mithrandir: it's broken for 2 weeks, amd64 users keep crying
<zul> hey fabbione 
<fabbione> hey zul
<zul> how is it going
<fabbione> pretty good
<fabbione> i have the last bit for ppc to fix
<fabbione> and i am done
<zul> goody
<zul> then you'll be ready to hand it off?
<zul> per se
<fabbione> yeah
* dholbach applies a full set of thom's kicks on dia
<trulux> back!
<trulux> dholbach: hey! what's new on Dia?
<lamont> glibc:                  06:17:40 (3 entries, sigma 00:00:26)
<lamont> sigh
<dholbach> trulux: it keeps on rearranging the layer order, doesn't revert changes properly and misbehaves in an awful lot of ways
<fabbione> FUCK
<fabbione> i just deleted all of the xorg sparc build
* lamont hands fabbione a crowbar to use in bludgeoning ppc
<lamont> fabbione: I'll be that freed up some disk space...
<trulux> dholbach: Oh, i'm a concerned Dia user now :)
<zul> see thats why backups are good for you
<zul> keeps you from saying profaniiteis
<fabbione> it's nothing to do with backpus
<trulux> ops, I got a job proposal from http://www.deimos-space.com/Eng/main.html :O
<fabbione> it was the buildd stuff
<dholbach> trulux: it's a really nice piece of software generally
<zul> ouch
<trulux> dholbach: yeah, too useful for papers
<doko> Mithrandir: is it intended that newly compiled amd64 binaries do have an RPATH set to /usr/lib64?
<dholbach> trulux: i'm working on my thesis, but i'm somehow losing my patience... :-)
<Mithrandir> doko: no
<tritium> Good morning, trulux 
<ajmitch> hi trulux 
<trulux> hey ajmitch
<trulux> tritium: hey!!
<trulux> tritium: I've read the ieeetran howto, now I think i can many more things without wasting your time :)
<tritium> trulux, it was no waste of my time ;)
<jdub>      - The handling of dav:// and http:// changed with this release.
<jdub>      If you use http:// the http-mehtod will be in http-only
<jdub>      mode and won't try to retrive file information through webdav.
<jdub>      Be sure to use dav:// and davs:// for webdav resources!
<jdub> 
<jdub> yay!
<zul> fabbione: new itonify patch
<fabbione> zul: good prepare it and coordinate for the next upload
<zul> k
<zul> somehow i knew you were going to say that
<fabbione> ;)
<fabbione> and test it
<fabbione> zul: just go ahead with stuff.. and coordinate with lamont and T-Bone for who does what
<fabbione> don't wait for me
<fabbione> i am on .11-0.1 right now
<fabbione> .10 is out of my business for a while
<fabbione> ehehe
<doko> seb128: the whole gnome libs and binaries have a runtime path compiled into the shared libs ... :-(
<doko> at least on amd64
<Mithrandir> doko: it's not a big deal, though; it just shouldn't be there.
* Mithrandir goes to hack on evo
<Mithrandir> seb128: do you have the evo packaging in arch somewhere?
<Mithrandir> (or any other VCS)
<jdub> mdz: around?
<lamont> jdub: I'd expect him to be sacking z's
* lamont takes kids to school
* lamont sometimes doesn't like being a single dad this week
* Mithrandir prods seb128 
<trulux> ajmitch: what has been done in Hoary right now?
<trulux> ajmitch: are the selinux patches included now?
<ajmitch> trulux: that's not up to me :)
<trulux> ajmitch: ok, I will ask mdz
<trulux> mdz: there?
<pitti> trulux: he's asleep
<ajmitch> night all
<elmo> the machine formerly known as archive.u.c; anyone with a broken DNS server that ignores TTLs may see it disappear
<elmo> s/;/is going down for 10-15 mins;/
<fabbione> elmo: please please please fix the ftpd on jackass
<Mithrandir> fabbione: s.u.c seems to be missing locales?
<fabbione> Mithrandir: no idea... i did a dist upgrade this morning and it was ok
<fabbione> probably something wrong in the rsync script?
<Mithrandir> don't you have arch: all packages?
<fabbione> not locally
<fabbione> i mirror sparc.u.c back at home
<Mithrandir> does sparc.u.c have arch: all packages?
<elmo> fabbione: I'd love to, but a) it's got a workaround, b) it's not my code that's broken it's the zope3 ftpd code
<fabbione> Mithrandir: yup
<fabbione> elmo: but i remember it was fixed somehow...
<elmo> fabbione: we thought Steve fixed, turned out I was fooled by lftp's silently retrying the uppload when it failed
<fabbione> hmmm does dput use lftp?
<elmo> nope
<elmo> the retry isn't a good thing, btw it'll just fail in a loop
<fabbione> because when i did the tests i used dput
<fabbione> and it was ok
<fabbione> anyway
<TreadingSoftly> er ... what am i doing wrong here: "env CFLAGS='-march=pentium-m -mtune=pentium-m' prints a list of variables including CFLAGS; but when i then go echo $CFLAGS it prints nothing ....?
<tritium> trulux, please send me a copy of your final draft?
<trulux> tritium: the finished paper or the current paper with the new look and feel?
<fabbione> YAY
<fabbione> ppc ftbfs is fixed
<fabbione> missing to update the config
<tritium> trulux, definitely the finished paper.  If you want to send the new look and feel, that would be great too.
<trulux> tritium: Oh, ok, sure I will send it to you when i finish it
<tritium> trulux, great, thanks
<sivang> does anybody have a problem updating from security.ubuntu.com or is it just me?
<tritium> sivang, yes, I do too
<pitti> sivang: this morning I got a mail from a guy who could not download a security udpate as well
<trulux> tritium: how can i switch to bold the section titles?
<trulux> this is a big pile of info now :)
<pitti> sivang: he complained about a missing file, however, I checked and it was there for me
<tritium> trulux, probably need to modify your \renewcommand{\thesection}
<trulux> yep
<sivang> 3189B/s
<trulux> tritium: how to put bold in it? what's the tag? /b?
<sivang> and it's stuck
<tritium> \textbf{This text in bold}
<sivang> pitti: I am trying to download from 82.211.81.138
<sivang> and it seems it doesn't respond in a timely manner or something
<pitti> me too
<trulux> tritium: okay dockey
<trulux> thanks
<tritium> :)
<zul> fabbione: gimmme gimme gimme :)
<fabbione> zul: almost done :-) 
<dholbach> bbl
<Keybuk> gtimelog (0.0+svn42-1) hoary; urgency=low
<Keybuk> ugh, gtimelog (~svn42-1) looks so much sexier
<fabbione> ehhehe
<Keybuk> "Text BACK THE TILDE to 84022"
<daniels> doko: pong
<daniels> seb128: uhm, a session dbus?
<fabbione> dpkg-deb: building package `linux-image-2.6.11-1-amd64-generic' in `../linux-image-2.6.11-1-amd64-generic_2.6.11-0.1_amd64.deb'.
<zul> sweet
<fabbione> mput linux-source-2.6.11_2.6.11*
<fabbione> 54105281 bytes transferred in 2 seconds (31.41M/s)                           
<fabbione> Total 4 files transferred
<fabbione> GET THE CRACK!
<zul> plumbers?
<zul> hey lamont
<fabbione> hey lamont
<lamont_r> yo
<fabbione> ARGH
<fabbione> i am an ass
<fabbione> no
<fabbione> never mind
<lamont_r> fabbione: make up your mind...  are you or are you not an ass??
<lamont_r> :-)
<sivang> lamont_r: lol
<fabbione> lamont_r: well 50%/50% :)
<tseng> i guess its too late to put hal back in gnomevfs?
* fabbione waits patiently for katie to send him a mail
<fabbione> linux-source-2.6.11_2.6.11-0.1_source.changes is NEW
<pitti> yay for 2.6.11
<fabbione> elmo: i know you are busy, but do you mind some blessing?
<fabbione> pitti: calm down.. it's 0.1
<fabbione> it's not a full .11
<pitti> fabbione: I know, it's not yet officially release, is it?
<fabbione> nope
<fabbione> it's a bk snapshot from 2 days ago
<pitti> fabbione: how many patches could you drop with this?
<fabbione> tons
<fabbione> 2.6.10: 248 -> 2.6.11 47
<fabbione> erh
<fabbione> 67
<fabbione> and with this
<fabbione> i am odd
<fabbione> ahha
<fabbione> oh god
<fabbione> i am off
<pitti> you mean, from 248 down to 67 patches?
<pitti> rock
<pitti> fabbione, master of backporting :-)
<fabbione> call me god
<daniels> haha
<daniels> fabbione: your package is tiny, kid :P
<pitti> fabbione: no I won't, god is not almighty
<sivang> pitti: lol
* daniels shuffles off to bed, feeling very tired.
<pitti> fabbione: god can't make a stone as heavy so that he can't lift it any more
<fabbione> pitti: forwardport please :P
<sivang> night daniels !
<fabbione> daniels: X is for script kiddies
<pitti> fabbione: whereas you can make a patch so big so that you can't fix it any more :-)
<pitti> SCNR
<fabbione> daniels: night dude
<pitti> no dude, seriously, great work
<pitti> daniels: night
<fabbione> pitti: thanks!
<fabbione> but it was easy after i spent sometime cleaning 2.6.10
<fabbione> with all the patch renaming and so on
<sivang> pitti: that a very nice phylosophical issue :)
<fabbione> but ppc is still a porting bitch
<fabbione> i could have done yesterday morning if it wasn't for 3 damn liners
<fabbione> http://people.ubuntulinux.org/~fabbione/powerpc-fix-ftbfs.dpatch
<fabbione> i mean
<fabbione> look at this
<pitti> sivang: /me loves logic :-)
<fabbione> it fix FTBFS on 6 kernels
<fabbione> each one has its stupid interaction with the one before
* fabbione heads off
<sivang> pitti: I know :) 
<pitti> sivang: however, don't kill me for blasphemy :-)
<lamont_r> fabbione: if X is such wimpy stuff, why do you build-depend on it then, huh???
<fabbione> can you actually boot your machine without a kernel? ;)
<fabbione> i really need to run
<fabbione> cya tomorrow or late this evening
<pitti> fabbione: cu
<Treenaks> fabbione: bye
<lamont_r> later fabbione 
<sivang> pitti: never! heheh, and I don;t think anything you say can actually be blasphemy as considered by me :)
<lamont_r> ouch.
<lamont_r> vendor called back with a price for the automatic-eject shore-line connector for my wife's van... USD 200.  now we gotta decide if/when to get it.
<daniels> fabbione: seeya dude.  good work. :)
<Treenaks> lamont_r: auto-eject shore-line connector?
<Treenaks> lamont_r: sounds dangerous
<lamont_r> 120 volt plug to hook the vehicle up to house power.  when you start the engine, it is automatically ejected.
<lamont_r> so that you don't drive off with the cord still plugged in, which is embarassing and annoying.
<Treenaks> ah
<lamont_r> wife does it about twice a year...
<Gagatan> haha :) sounds classic
<lamont_r> replacement/repair takes about 30-45 minutes, and about $15...  But that's partially because she hasn't damaged the body of the vehicle yet...
<lamont_r> Gagatan: yeah, it is.
<lamont_r> then again, it's also so considerably off topic,...
<Mithrandir> lamont_r: put something in the driver's seat when the house power is plugged in.  Or get a longer power cord and some sirens or something. :P
<lamont_r> Mithrandir: she tends to optimize..
<Mithrandir> sounds like suboptimisation to me.
<lamont_r> that'd be red-head irish artist optimization, not the kind we're accustomed to
<daniels> lamont_r: you're married to Kamion?
* daniels takes off for bed, not before time.
<lamont_r> daniels: gonna have to beat you now.
<lamont_r> once I stop laughing
<lamont_r> daniels: Kamion is mild compared to mitzi
<mpathy> Hi there..
<lamont_r> Kamion: speaking of you, should I bother to download the ia64 live/install cd's yet?
<Kamion> lamont_r: I did the d-i build before I left for the bank; just got back
<lamont_r> woot
* lamont_r is busy snatching missing mirror files right now
<Kamion> lamont_r: no ubuntu-live in the archive yet, though, so I can't kick the livefs build
<lamont_r> Kamion: livefs script still doesn't use it
<Kamion> the d-i build needs byhand lovin'
* lamont_r plans to wait for it to be in the archive before he changes the script...
<pitti> Mithrandir: btw, did you find the cause of the libc FTBFS?
<Kamion> 03:53 < mdz> lamont: did elmo happen by to process ubuntu-live before the cloop builds?
<Kamion> 03:54 < Kamion> apparently not
<Kamion> 03:54 < Kamion> mdz: I'm kicking off new builds tomorrow morning anyway, so I'll do livefs as well
<Kamion> I'll not do livefs then :)
<Kamion> lamont_r: I did fix germinate this morning so that it would tell anastacia to add ubuntu-live to main
<Mithrandir> pitti: I agree with doko's analysis that it's probably a race condition.
<pitti> Mithrandir: that was my impression, too
<pitti> Mithrandir: I cannot imagine how your patch should cause the race, though
<lamont_r> Kamion: ok.  you may want to kick me and remind me to make the change
<pitti> Mithrandir: will a mere give-back help?
<elmo> kamion/lamont: hmm, do I need to do something?
<lamont_r> pitti: could be a race condition else where, and we just hit it...
<pitti> Hi elmo!
<pitti> lamont_r: this sounds much more plausible
<Kamion> elmo: ubuntu-live universe->main please, if you update germinate it should say that
<lamont_r> pitti: I'm reluctant to play dice with FTBFS issues...
<Mithrandir> pitti: it probably didn't, it was just a race wanting to happen
<elmo> Kamion: prommise it won't break anything else? ;)
<Mithrandir> pitti: just forcing NJOBS to 1 should work
<elmo> pitti: hey
<lamont_r> elmo: and ubuntu-live NEW love, and d-i BYHAND love, and that should make Kamion come yell at me
<lamont_r> Mithrandir: it did work for doko
<doko> elmo: and libmpfr-dev universe -> main ;)
<Kamion> elmo: output with -c main,restricted was identical before/after the big change
<doko> elmo: we did miss you :)
<Kamion> elmo: so I'm pretty sure it's safe
<lamont_r> so the choices are (1) make somechange somewhere that convinces the uploader that they've fixed the parallel build issue, or (2) do an upload with NJOBS=1
<pitti> elmo: if you have a a minute, I have a buch of sync stuff: xview (sid) pdftohtml (sid) mailman 2.1.5-6 (incoming)
<lamont_r> Kamion: guess I should go change the livecd build script, eh?
<Kamion> go for it, ladude
<doko> lamont_r: (2) already done
<doko> and built
<lamont_r> woot
<lamont_r> Kamion: livecd script will now install ubuntu-desktop+ubuntu-live
<rcliii> hey all, I've found a but that has been reported as #3196 -- it's status is NEEDINFO and I am wondering if there is anything specific I can provide.
<lamont_r> Kamion: it still does the locale-gen crap, I'll drop that later today
<rcliii> It appears to be assigned to Kamion
<Kamion> one sec
<Kamion> rcliii: if you see "Input/Output Error", either your media or your drive is faulty, or you might find that it's the DMA-on-CD-ROM-drives problem which is fixed in Hoary
* lamont_r keeps wanting to mistype ubuntu-live... maybe it could Provide: ubuntu-love? :-)
<rcliii> Kamion: I'm using Array 4...
<lamont_r> Kamion: is that on ppc?
<elmo> fabbione: is 2.6.11 for main?
<Kamion> every time that's happened to me it's been a faulty burn
<Kamion> lamont_r: which?
* lamont_r sees the same thing.  But then he sees mucho wierdness on his ppc
<lamont_r> I/O error on cdrom
<lamont_r> was figuring it was probably a hardware issue, actually.
<Kamion> I have one CD-RW drive that doesn't want to burn valid CDs any more; 'md5sum /dev/cdrom' fails with I/O error halfway through, while the same disk burnt in my laptop works fine
<lamont_r> ew
<rcliii> well, it won't hurt to burn the CD again and give it another shot.  Strange that it happens with the shipit CD's and Array 4 in the same predictable way...
<Kamion> there have been a few dodgy shipit CDs, but in that case it sounds more likely that your drive is a little out of spec
<Kamion> the shipit CDs are duplicated from images that we know successfully install on a lot of systems, or we wouldn't have released them :)
<rcliii> that makes sense
<rcliii> what is it about FC3
<Kamion> pressed CDs are normally *more* reliable ...
<rcliii> that lets my wacky drive work?
<Kamion> that would certainly be interesting to know; they may have kernel tweaks
* Kamion <- not kernel guru though
<rcliii> thanks for looking into it.  I'll mess around a bit more and see if I can't get something to work
<elmo> Kamion: what's better to test on our servers, array-4 or daily?
<Kamion> elmo: I can't vouch for the current daily's state; go for array-4
<elmo> doh
<elmo> that's 60 seconds of downloading I'll never get back ;p
<mako> Kamion: i got the message re dholbach
<dholbach> mako: is there anything i still have to do?
<mako> dholbach: i haven't checked my mail yet.. di dyou mail me a signed CC?
<mako> dholbach: is your key signed by another key in the strongly connected set
<mako> ?
<elmo> bah, where do errors with 'Write to a disc' go?
<dholbach> mako: yes... 9 days ago or something :-)
<dholbach> mako: and we already found we just had one hop between us ;-)
<lamont_r> Kamion/elmo: I don't suppose there is a web page somewhere that is nothing more than a list of the current binary/source package names and their versions for each release?
* lamont_r bets 'no'
<elmo> dpkg-deb (subprocess): failed in buffer_write(fd) (5, ret=-1): failed to write to pipe in copy: Broken pipe
<elmo> dpkg-deb: subprocess paste returned error exit status 2
<elmo> uh
<elmo> lamont: no that I know of no
<Kamion> elmo: 60 seconds> I feel for you, dude
<Kamion> lamont_r: zcat Packages.gz | grep-dctrl ... | awk ...? :-)
<lamont_r> Kamion: yeah...  actually, zcat Packages.gz | awk and just assemble the package list that way - much simpler...
<Kamion> I use grep-dctrl practically reflexively. best thing Antti-Juhani ever did :-)
<lamont_r> ah, ok.
* lamont_r only recently discovred it, and had an awk habit by then
<elmo> hmm
<elmo> dpkg: error processing /var/cache/apt/archives/locales_2.3.2.ds1-20ubuntu8_all.deb (--unpack):
<elmo>  short read in buffer_copy (backend dpkg-deb during `./usr/share/i18n/charmaps/GB2312.gz')
<Kamion> elmo: can I assume that CC.archive.ubuntu.com will always be accessible using /ubuntu/ as the path?
<elmo> we still aren't md5sum checking /var/ache/apt/archives/ I guess
<elmo> Kamion: yes
<Kamion> elmo: ok, good. I'm going to ignore ftp for now
<elmo> Kamion: fine by me
<Kamion> $ ./ubuntu-country-mirrors.pl | grep -c ^Site:
<Kamion> 240
<Kamion> wow. massive instamirrornetwork
<lamont_r> Kamion: how many of those are the same machine?
<elmo> lamont: shush
<srbaker> uh
<srbaker> are there mime type issues in hoary?
<srbaker> i'm getting "no element present to handle type audio/mpeg" when i try to stream radio paradise from whithin rythmbox
<srbaker> rhythmbox even
<lu|game> install the mad gst-plugin
<lu|game> IIRC
<srbaker> oh, okay, thanks
<mako> dholbach: oh right.. yes.. i checked that.. i have everything i need from you
<dholbach> mako: cool :-)
<lamont_r> Kamion: livecd ready yet?
<snaggen> I'm working of fixing the tvout on totem by reworking the nvtv package. What is the normal working order to modify an existing package in hoary/universe. And what do I do to get it in to main?
<netdur> I don't know if you noticed yet but doing Places -> Desktop display error says "Cannot display location 'file:///home/adel/Desktop'" and "Details: There is no default action associated with this location.", I'm got this error after recent update (today morning)
<tseng> he needs to login again
<ogra> snaggen: you become a MOTU or find a MOTU willing to upload to universe for you https://www.ubuntulinux.org/wiki/MOTU
<dholbach> wow... i installed language-pack-ar* just for fun - and now it generated like 15 locales
<dholbach> tseng: or to   update-mime-database /usr/share/mime
<tseng> or that
* dholbach gets his  chili con carne  going
<ogra> dholbach: where does it go ?
<tseng> in the pod.
<tseng> *pot
<T-Bone> w00sh. dist-upgrade -> 114MB of extra space will be used ;P
<Kamion> lamont_r: damnit, I never did that build, working now
<lamont_r> dholbach: I'm always amused by 'chile con carne with beans'.
<Kamion> elmo: there should have been another d-i build for ia64; did it get lost between the buildd and the archive?
<elmo> there's nothing left in BYHAND
<elmo> (i.e. yes)
<elmo> meh array 4 spasses out with bad clock
<dholbach> lamont_r: amused? i think, i didnt get the funny part :-)
<lamont_r> Kamion: it's a feature of wb and friends.
<lamont_r> you'll need yet another new d-i build
<lamont_r> want me to launch it, or you?
<lamont_r> elmo: pb is that w-b/archive has ....0.20050209, and the buildd --takes ...0.20050210, then cron.daily runs and resets things because I can't possibly want something newer than what's in the archive.
<lamont_r> so then Kamion runs the script a second time, and ...0.20050209 is still the version there,and we pick the same version number for the next run...
* lamont_r isn't sure what the right fix for that is...
<lamont_r> because they're all eveil
<Kamion> lamont_r: go ahead, I don't understand this so I'll let you do it
<lamont_r> launched.
<Kamion> elmo: bad clock> that the gpg thing?
<lamont_r> Kamion: it comes down to quinn-diff? stomping on the state that the buildd left lying around for itself in w-b...
<lamont_r> the sequence must be: build, byhand, build, byhand
<lamont_r> build, build, byhand doesn't like life
<elmo> Kamion: yes
<elmo> reset time in bios, reinstalling..
<Kamion> elmo: ... or a daily :->
<Kamion> at least I think I've got all those cases
<Kamion> lamont_r: oh, I see, ok
<elmo> Kamion: you told me I wasn't cool enough to use them
<Kamion> elmo: you aren't. doesn't mean you might not have to. ;)
<elmo> cdimage.u.c/releases.u.c going down for reboot..
* lamont_r wimpers
<wasabi> rebooty call
<elmo> it'll make things better, I promise ;)
<elmo> can abort if it's really problematic tho
<lamont_r> nah - I still have over an hour just need to make sure I don't loose the prior image
<lamont_r> go for it
<thom> elmo: he won't recognise you now anyway, so you're safe ;)
<Kamion> what has elmo done to himself?
<thom> i think he went to close to a farmer during sheep shearing season
<Kamion> scary
<Kamion> I freaked first time I saw joeyh with short hair
<lamont_r> elmo: so say when it's back up...
<thom> yeah, it's about the same level of freakiness as joey's
<thom> (looks good though)
<lamont_r> elmo: say you didn't shave your head...
<lamont_r> just shortened things...
<elmo> lamont_r: mirnyy's back
<elmo> those it's in degraded/recovery mode disk wise, so the betterness I promised may not be apparent just yet
<lamont_r> 'sok
<elmo> Kamion: I will pay you $$$$ to get rid of that incredibly redudant, "are you in the UK or Belfast??? P.S. WHO CARES? ITS THE SAME TIMEZONE" question
<elmo> Kamion: and more seriously, it seems to just hang for me on "Testing network repository" - where does the output for that go?  it doesn't seem to be on console 3
<pitti_> argh, this bloody inotify did it again
<Kamion> elmo: that's a bloody slow step, haven't managed to progress-bar it yet
<Kamion> elmo: erm, I think it currently goes to /dev/tty or something helpful like that
<Kamion> elmo: I probably could, but then all the people in Belfast who Do Not Live In Britain would lynch me ;)
<Kamion> or kneecap me or something pleasant like that
<elmo> boggle, dude, I'm on the LAN - why is that step slow?
<Kamion> yeah, I know, no idea ... the output appears to go to `tempfile` if you want to hunt for it
<elmo> oh, meh, would help if the machine was plugged in
<elmo> do we have a generic "nic has a link" testability yet?
<Kamion> netcfg already tries
<elmo> "I have a cable" or "I have a link"?
<Kamion> it attempts ethtool and MII
<elmo> hmm, both those say no link, but I didn't get any grief from the installer?
<elmo> just the usual "dhcp not found" which I'd get even if i had a link :)
<Kamion> might only be for selecting the default interface or something
<Kamion> netcfg hurts my BRANE
<zul> brain?
<Kamion> zul: yes (deliberate misspelling, kind of traditional)
<zul> ah
<zul> elmo: do you know if fabbione uploaded linux-source-2.6.11-01 yet?
<elmo> zul: yes
<tseng> he said he dput it
<zul> k
<tseng> but no accepted message
<tseng> he mustve miffed something
<elmo> Kamion: other than the gpgv thing and other stuff I mentioned install went fine btw
<elmo> (that's on a HP DL380 G4 in 'legacy' (i.e. i386) mode)
* lamont_r idly wonders if elmo byhand'ed the latest ia64 d-i, and if Kamion did the livecd build
<elmo> lamont: ain't got nothing to byhand
<elmo> oh, nm, wrong user
<elmo> byhanded
<Kamion> ok, I'll kick little when that makes it to the archive, thanks
<seb128> elmo: could you sync gazpacho, gthumb and gstreamer0.8 from incoming ?
<elmo> pitti_: ?
<elmo> seb128: done
<seb128> thanks
<bluefoxicy> http://rafb.net/paste/results/mz5xkO17.html
<bluefoxicy> scanning 127.0.0.1
<ogra> hmm, is gluck down ? i cant get to p.d.o ....
<tseng> bluefoxicy: none of those are insatlled by default
<tseng> besides maybe cups
<bluefoxicy> tseng:  cups and whatever that mail daemon is are gone scanning 192.168.0.2
<tseng> because they only listen to localhost
<bluefoxicy> tseng:  I'm not sure where the heck I got postfix :P
<tseng> as is the policy in defaults apps
<tseng> postfix is default, but its not listening to remote addresses
<bluefoxicy> ubuntu-base depends on postfix
<tseng> only local deliver
<tseng> y
<bluefoxicy> tseng:  ah
<tseng> ill bbl
<elmo> Kamion: same install in non-legacy (amd64/em64t) mode went fine, modulo post-install breakage due to polypaudio (which isn't your problem)
<Kamion> elmo: kewl, thanks
<ogra> elmo: could you sync phpbb2, phpbb2-languages and phpbb2 ?
<ogra>  the version in universe is insecure ....
<elmo> phpbb2 twice?
<ogra> elmo: oh, is this one source packager ? then only once :)
<ogra> -r
<elmo> ogra: and please only list source packages to sync
<ogra> elmo: ok...
<ogra> elmo: so only phpbb2 please, sorry :)
<elmo> done
<elmo> gone, bbl
<ogra> wow, thanks
<bluefoxicy> yay
<bluefoxicy> xorg 6.8.2 is out
<bluefoxicy> now if you hurry, you may be able to get a package compiled before Hoary's release
<bluefoxicy> :P
<pitti_> elmo: back
<pitti> pitti: what's up?
<ogra> ogra ?
<Kamion> pitti: uh ...
<pitti> darn
<pitti> elmo: what's up?
<kent> pitti, talking to your self? ;)
<dholbach> pitti: seems you missed him
<pitti> kent: yes, when nobody else does :-)
<dholbach> let's all chat a bit with pitti :-)
<dholbach> pitti: seems you were right in talking to yourself :-)
<pitti> ;-)
<ogra> pitti: but while you are not chatting, did you find time to look at the latest changes to the lsb patch ?
<kent> pitti, out of curiosity (i cant spell that word, grr), what is it you are responsibel for in Ubuntu?  If i may ask.. 
<pitti> ogra: oh sorry, will do it now
<ogra> kent: he is Mr. Secure
<pitti> kent: hmm, let's see
<pitti> kent: security support, proactive security, language packs, hotplug stuff
<kent> ah, nice. 
<pitti> kent: and a bunch of stuff we all do (fixing bugs, testing, etc.)
* kent is only responsibel for taking up developers time on irc, and reporting a bug time to time.
<kent> ;)
<ogra> kent: as long as you pay the time with bugreports ;)
<sivang> kent: are you an ubuntu user?
<mdz> jdub: pong
<pitti> Hi mdz 
<mdz> hi
<pitti> mdz: I uploaded an updated hpoj with scanner group support
<pitti> mdz: however, I can't test libusbscanner (setting the correct permissions of the USB device)
<pitti> mdz: could you please try that again?
<mdz> yes
<Kamion> lamont_r: ia64/live up
<lamont_r> woot
<mdz> pitti: zsh: exit 1     sudo /etc/init.d/hpoj start
<mdz> pitti: /etc/ptal/ptal-printd-like is still owned by daemon
<pitti> moment pls, phone
<pitti> mdz: you mean there is a conffile owned by daemon?
<mdz> pitti: /etc/ptal/ptal-printd-like is a file which is created/chowned by the init script, and then passed as an argument to ptal-printd as an example of the permissions for the FIFOs
<mdz> pitti: see line 214 of the init script
<pitti> mdz: ah; I probably forgot to change that; that was probably one of your changes
<pitti> sorry
<mdz> I think we need to move the chmod/chown out of the block
<mdz> I thought I had done it, yes
<mdz> but maybe it was only locally
<pitti> mdz: I can't find any occurrence of "daemon" other than the variables in the init script
<LarryT-ubuntu> hi ! I 'm looking for some help about live cd remastering (i get an error message when mkisofs )....
<LarryT-ubuntu> Who may i join ?
<Kamion> lamont_r: daily install's been building for a bit; give it 50 minutes or so
<mdz> LarryT-ubuntu: what is the error message?
<LarryT-ubuntu> mkisofs: Volume ID string too long 
<LarryT-ubuntu> at the very last step :(
<mdz> how odd
<LarryT-ubuntu> just when i paste the mkisofs ....etc  from the doc : https://www.ubuntulinux.org/wiki/LiveCDCustomizationHowTo
<mdz> cat extracted_cd/.disk/info
<mdz> what does that show?
<LarryT-ubuntu> gonna try :)
<LarryT-ubuntu> Ubuntu 5.04 "Hoary Hedgehog" - Alpha i386 Binary-1 (20050204)root@ws016:~ #
<LarryT-ubuntu> is it all right ?
<LarryT-ubuntu> oh : damn : i must go :( ----> i 'll be back in 20 minutes : i am really sorry :(
<LarryT-ubuntu> hope you ll be there :p
<mdz> LarryT-ubuntu: I've updated the example
<mdz> LarryT-ubuntu: it should work for you now
* lamont_r heads home to test the ia64 cd
<doko> does somebody remember which one of the wxwindows/wxwidgets guys said that 2.6 would be released in January?
<Kamion> lamont_r: daily install's been building for a bit; give it 50 minutes or so
<Kamion> damnit, already said that in this channel. a combination of ssh, screen, and suspending my laptop in the middle is confusing me
<zul> heh
<zul> you might want to try a pdp-11 then 
<Kamion> lamont: daily install built
<LarryT-ubuntu> mdz : i am back sorry :( and i have time :)
<LarryT-ubuntu> mdz : LarryT-ubuntu: I've updated the example -----> i am going to see :)
<Kamion> amu: could you put kde back into the kubuntu-hoary desktop seed, please? the way it works with ubuntu-desktop is that we generate the ubuntu-desktop metapackage automatically from the seed, so just because something is depended on by ubuntu-desktop doesn't mean that we remove it from the seed; it would be good if kubuntu-desktop worked the same way
<LarryT-ubuntu> mdz : this time it works :))))
<mdz> LarryT-ubuntu: great
<LarryT-ubuntu> could you tell me why
<dholbach> hi azeem
<LarryT-ubuntu> if i can understand :/
<LarryT-ubuntu> mdz if i can understand :/
<amu> Kamion: letme check, i did last hours some fine tuning .
<amu> yep, it's in, i'm still waiting for the kubuntu meta-package :( 
<doko> fabbione/lamont: please could you let me know, if the gcc-4.0 package builds on sparc/hppa?
<LarryT-ubuntu> mdz i still have a question :)
<LarryT-ubuntu> mdz my iso is 637mo. i have removed openoffice and evolution, and added k3b, and few libraries to run gparted testing 
<LarryT-ubuntu> mdz how is it possible that the iso is so big ???
<mdz> LarryT-ubuntu: when you install packages according to the instructions, it tells you how much additional space will be occupied.  did you pay attention to this?
<LarryT-ubuntu> i thing i did
<LarryT-ubuntu> removing openoffice and evolution leave about 200mo !
<LarryT-ubuntu> this is why i am so suprised
<restrex> hi guyz I think there's an error on ubuntu.... when I mount a partition on /media the icons to access them from Desktop or Computer are not appearing...
<LarryT-ubuntu> mdz is there any command i can run to know how much place i used ?
<LarryT-ubuntu> mdz : i mean on the next cutomcd
<mdz> LarryT-ubuntu: did you remember to run apt-get clean, as in the instructions?
<restrex> hi guyz I think there's an error on ubuntu.... when I mount a partition on /media but the icons for access it from Desktop or Computer isn't appearing...
<LarryT-ubuntu> mdz i did but it runs about 3 seconds ...???
<mdz> LarryT-ubuntu: if you ask on #ubuntu, someone may be able to help you find out the reason, but unfortunately I have too much other work to do
<LarryT-ubuntu> mdz it doesn't matter anyway : i succeed ,thanks to you and it is fine :)
<LarryT-ubuntu> mdz : ok, and thank you . I am happy :P :)
<amu> Kamion: guess without the metapackage it make no sense to rerun germinate now
<dholbach> re
<sivang> re dholbach 
<restrex> hi guyz I think there's an error on ubuntu.... when I mount a partition on /media but the icons for access it from Desktop or Computer isn't appearing...
<kent> sivang, (i saw your post to me earlier) yes, i use Ubuntu (Hoary).
<sivang> kent: ah ok :) it was long ago :)
<sivang> err, I am getting some strange behavior , my whole desktop freezes from time to time without any apprent reason
<sivang> has anyone else seen it?
<dholbach> sivang: no, not really 
<kent> sivang, my computer have crashed a bit last night and today. but i think it has to do with heat-issues and a bad fan.
<sivang> kent: err, I hope it's not the case here.. I have an geforce2 card that's getting a bit old now, I hope it's it's fan failing..
<mdz> gah
<mdz> lamont: did we not do a cloop build last night?
<mdz> lamont: the current one is still broken
<lamont> mdz: we tried one, I noticed
<mdz> the one included in the daily live image has 2.6.10-2-386 modules on it
<lamont> mdz: whole lot of uninstallable world last night
* lamont kicks another livecd
<lamont> rootfs that is
<mdz> ick
<mdz> thanks
* lamont considers draging the "which is better, evolution or apache" debate over to this channel, decides not.
<sivang> grrr, upgrade crashed g-v-m
<sivang> lamont: apache is a webserver, evolution a groupware client, how do you decided which is better?
<lamont> The following packages have unmet dependencies:
<lamont>   ubuntu-desktop: Depends: evolution-webcal but it is not going to be installed
<lamont> sivang: stop introducing facts into the argument
<sivang> lamont: heheh
<lamont> mdz: much closer...
<mdz> grr
<mdz> seb128: ?
<HrdwrBoB> haha yeah I am migrating from evo to mut
<HrdwrBoB> mutt
<seb128> mdz: yep ?
<mdz> seb128: evolution-webcal is uninstallable
<mdz> seb128: does it need only a rebuild?
<mdz> libecal1.2-1 -> libecal1.2-2
<seb128> mdz: ups, yep, probably eds soname change
<seb128> I'll fix it now
<mdz> thanks
<seb128> np
<lamont> HrdwrBoB: no, no, no, you should migrate from apache to evo! :)
<HrdwrBoB> oooh!
<HrdwrBoB> my bad :)
<zul> apache is fun..
<seb128> HrdwrBoB: tomorrow you migrate from firefox to lynx ?
<HrdwrBoB> seb128: well I migrated from xchat to irssi
<seb128> you should remove --purge xfree/xorg
<HrdwrBoB> no, xorg is my window to many many terminals
<HrdwrBoB> :)
<mjt> xorg 8.6.2? uh-oh... ;)
<mjt> er
<mjt> s/8.6.2/6.8.2/ ofcourse
<goedson> ogra: I've just received your response about uploading to universe.
<goedson> ogra: You said I need a valid and signed gpg key. 
<goedson> ogra: Who should sign my key?
<dholbach> goedson: you also need to set yourself on the list on http://wiki.ubuntu.com/MaintainerCandidates
<goedson> dholbach: I've just done it.
<ogra> goedson: hi
<dholbach> goedson: as a DD you must already have a signed key? :-)
<ogra> goedson: your key must be signed by someone else with a signed key to proof that your key is trustable
<ogra> goedson: regulary this means you must meet someone with such a key in person and exchange keys while you show each other your id cards
<goedson> ogra: Which is the current set of "signed keys"?
<ogra> goedson: do you have a LUG near you anywhere ? normally you will find someone there
<goedson> ogra: My key is signed by some DD.
<goedson> ogra: Benjamin Hill, for example.
<ogra> goedson: yeah, that enough
<ogra> goedson: the set of signed keys (at least for universe) is any trustable key on the keyservers ;)
<ogra> http://keyserver.mine.nu/
<mvo_> mdz: #5879 is a bug about the slow pulse intervall of the acquire interface of apt. would you accept a patch that makes it configurable? or do you feel we are too late for that now?
<goedson> ogra: Where should I send my key.
<ogra> goedson: nowhere yet, you will need to sign the code of conduct with it and send this to mako to express your will to become a member and to respect the CoC
<dholbach> goedson: http://www.ubuntulinux.org/community/conduct/document_view :-)
<ogra> goedson: after you have done that, make some kind of contribution.... a howto page, a wallpaper, a bugfix, whatever you like or matches your talents
<jdub> GOOD MORNING FREEDOM LOVERS!
<tseng> hi jdub 
<jdub> fabbione: around?
<jdub> morning tseng 
<goedson> ogra: OK. Thanks.
<dholbach> morning jdub :-)
<ogra> GOOD MORNING JDUB
<jdub> ogra: dude, i love waking up and unlocking my desktop with your sexy unlock dialogue :-)
<tseng> ogra: indeed, nice work on taht
<ogra> yay :)
<sivang> jdub: good morning freedom lover!
<tseng> now if you can get rid of that stupid jumping cow
<wasabi> i dont have a sexy unlock dialog now. =(
<jdub> tseng: it's not on by default, is it?
<tseng> it is
<wasabi> hmm i do have an update-manager that keeps quitting.
<dholbach> tseng: i dont have that jumping cow anymore :-(
<tseng> the default is random screensavers
<tseng> i set it to blank screen
* dholbach was rather of it
<tseng> to avoid mr. cow
<dholbach> ... fond ...
<ogra> dholbach: it requires GL
<jdub> yeah, but only random among a group we've selected 
<dholbach> ogra: hmm, strange, some weeks ago, it bounced, bumpy, but it bounced :-)
<ogra> dholbach: software rendered.....
<dholbach> ogra: was good enough for me
<ogra> dholbach: hmm, maybe a nv bug, since we have similar HW setup and it worksforme.....with nvidia driver
<dholbach> ogra: i'll check it later
<mvo_> ogra: it looks very cool!
<ogra> thanks :)
<dholbach> ogra: WAY cool :-)
* ogra blushes in facing so many compliments
<mdz> mvo_: yes, sounds safe to me
<jdub> heh
<jdub> en locale generation
* jdub covers his eyes
<dholbach> jdub: how many do you have? ;-)
<jdub>   en_AU.UTF-8... done
<jdub>   en_BW.UTF-8... done
<jdub>   en_CA.UTF-8... done
<jdub>   en_DK.UTF-8... done
<jdub>   en_GB.UTF-8... done
<lamont> dholbach: I expect all of them.
<jdub>   en_HK.UTF-8... done
<jdub>   en_IE.UTF-8... done
<jdub>   en_IN.UTF-8... done
<jdub>   en_NZ.UTF-8... done
<jdub>   en_PH.UTF-8... done
<jdub>   en_SG.UTF-8... done
<jdub>   en_US.UTF-8... done
<jdub>   en_ZA.UTF-8... done
<jdub>   en_ZW.UTF-8... done
<jdub> 
<jdub> i also install zh for testing
<lamont> jdub:  you saying that package should be split up?
<jdub> which is pretty chunky, but only has three locales
<sivang> jdub: how do you copy paste so fast?
* dholbach had 15 arab ones today plus the germany ones :-)
<tseng> its very important to have the NZ translations
<tseng> austrialian or british just wont do at all
<jdub> lamont: dunno. the only suboptimal bit is the locales generation, really.
* jdub coughs "even when you can't spell australian" ;-)
<dredg> tseng: feh. IE. :)
<sivang> dholbach: install the hebrew one as well :)
<tseng> dredg: whats IE short for?
<jdub> $ sudo apt-get install language-pack-zh language-support-zh
<jdub> ...
<jdub> Need to get 32.9MB of archives.
<jdub> After unpacking 89.3MB of additional disk space will be used.
<jdub> 
<dredg> tseng: ireland
<dholbach> sivang: you should teach me your letters first :-)
<jdub> (though that doesn't include the language packs, which are already installed)
<tseng> dredg: hmm, a stones throw
<tseng> pitty they cant handle the same translation
<dredg> tseng: yes, but euro symbol by default, as well as others :)
<jdub> mdz: putting language-support-* for bigten on the cd is going to bite
<sivang> dholbach: I will then, we will have something on the web sometime :)
<elmo> Kamion: hmm powerpc cd isn't going to boot to serial console by default is it?
<dredg> actually, i wonder if my gf would be interested in testing ga_IE...
<dredg> or helping me with translations. or just doing the translations cos that's what she does for a living...
<sivang> dredg: ah nice, what languages is she working with?
<tritium> why would libnautilus-burn1 not replace libnautilus-burn0 ?
<dholbach> elmo: did you find the time to arrange the final part of my MOTUness? :-)
<tseng> i found a notary, meant to do that today
<dholbach> tritium: they seem to be installable parallel, because the API/ABI changed
<dredg> sivang: irish mostly, though she knows french and some others
<tritium> dholbach, okay.  Thanks.
<sivang> dredg: irish to english?
<dredg> sivang: and english to irish
<dredg> as a nation we tend not to speak irish over here.
<dredg> `date' works anyway :) Dar Feabh 10 22:01:27 GMT 2005
<dredg> i would say that ga translations do not exist for most things though
<dholbach> dredg: well get involved :-)
<dredg> dholbach: i cannot speak the language :)
<dholbach> dredg: then your girlfriend should :-)
<dredg> dholbach: and my poor gf spends all day every day translating.. the last thing she'd want is to do it in her spare time :)
<mdz> jdub: ping?
<dholbach> oh, i see
<dredg> i'll annoy her though and see if she would mind helping out.. i know there is a translation project for kde, i don't think there's a gnome one
<dholbach> dredg: there is
<dholbach> http://l10n-status.gnome.org/HEAD/ga/index.html
<jdub> mdz: pong
<dredg> dholbach: oh, nice one
<jdub> of course there is a translation project for gnome :)
<elmo> fuck - stupid g5's don't come back cleanly if you rip their video card out
<elmo> dholbach: err, I didn't realise you were in the queue - did you send me your key id, email etc.?
<dholbach> elmo: i sent them to mako
<elmo> dholbach: mako only needs the CoC; I need your keyid + email (as per the docs on the wiki, WRT uploads)
<dredg> jdub: yeah, i knew there was a gnome translation project, i was unaware of an irish translation project :)
<dredg> no T?
<lamont> hrm ... magenta on blue.. I should really get a better monitor
<lamont> mdz: fwiw, livecd on ia64 fails to find the network, and then dies with 'device /dev/vc/1 does not exist'
<lamont> of course, that's probably related to having the wrong modules
<jdub> ok, so, /u/b/python is in python-minimal
* lamont launches new livecd rootfs build on the assumption that seb is done fixing evo-webcal
<jdub> but nothing depends on it if you pull python2.4-dev
<lamont> and the simple knowledge that it fails quickly if he's wrong
<jdub> but that still doesn't explain i386 being out of sync with the other arches
<lamont> jdub: that is correct
<jdub> lamont: did you see this?
<jdub> http://people.ubuntulinux.org/~lamont/buildLogs/g/gamin/0.0.23-0ubuntu1/
<lamont> didn't look at it, no.
<jdub> total bongness
<lamont> but python-foo-dev doesn't depend: python
<lamont> nor should it
<lamont> and the chroots haven't been taught that python-minimal is essential
<jdub> not that i should really be relying on that
<lamont> eep.  gotta go get kids
<jdub> so i should b-d on: python-dev (>= 2.4),
<jdub> python-dev (<< 2.5)
<lamont> and then run python2.4.  If you want to run 'python', you need to build-depend python (I think... python-minimal might get you there)
<lamont> almost certainly does
* lamont runs - 15 min to drive 20 min away
<jdub> ok, so i should stick to the same thing but run python2.4
<fallker> ping
<doko> kamion: ping?
<doko> jdub: but if you use dh_python, you need to depend on python anyway.
<jdub> python-dev depends on python
<seb128> jdub: oh, inotify 0.19 out and gamin updated for it :)
#ubuntu-devel 2005-02-22
<thully> Well, I've been experimenting - and I now see why netapplet is "not ready for prime time" - it crashed when I resumed from suspend and always shows my wi-fi signal as 0%.. works OK though
<jdub> seb128: yeah, noticed -> been pinging fabbione :)
<seb128> ;)
<jdub> d'oh, and he just uploaded a kernel
<thully> seb128: I saw your somment on my suggestion wrt multisession support in nautilus, and I looked at the upstream report - that's a lame excuse for not having multisession support
<tseng> jdub: thats a .11, i dont think it will be the "default" for a bit
<jdub> ah, yeah, good point ;)
<tseng> needs l-r-m l-m and all that
<seb128> thully: feel free to argue upstream, I'm not going to fork ncb
<thully> "CDs are cheap" - yes, but writing a whole new CD each time you want to add a 2MB file - that's plain stupid
<jdub> thully: got a patch?
<thully> no - I'm not much of a programmer, unfortunately
<thully> anyone know if any type of more advanced CD burning will be in hoary/main, or if this is being pushed to hoary+1
<tseng> thully: its feature freeze and coaster or similar still arent in
<tseng> id say that pushes to +1
<tseng> coaster might make universe for hoary with some luck
<sivang> thully: if we do it all in one time for hoary, what would be left to do afterwards? ;-))
<jdub> seb128: patch works against current kernel, may as well upload it now :)
<seb128> rock
<seb128> thully: ncb rocks
<thully> well, it doesn't have audio CD or multisession support currently... 
* jdub does rapid-fire gamin uploads
<seb128> thully: audio CD is an issue, I'm waiting to get that from rhythmbox :)
<seb128> thully: but multisession ...
<jdub> once it has multisession support, it should probably do that by default
<thully> Also, on the Hoary features front: I know ifplugd, netapplet, ... have been pushed to +1 , but have any simpler solutions been considered (like having an option for DHCP to load on bootup but not hold up the system boot
<seb128> jdub: multisession has been closed as wontfix by hadess
<jdub> seb128: for reasons other than "i'm not going to do it"?
<seb128> <thully> seb128: I saw your somment on my suggestion wrt multisession support in nautilus, and I looked at the upstream report - that's a lame excuse for not having multisession support
<seb128> that's the reason :p
<seb128> ups
<seb128> <thully> "CDs are cheap"
<seb128> let me find the bug
<seb128> jdub: http://bugzilla.gnome.org/show_bug.cgi?id=120384
<thom> that sounds like hadess... typical lazy frenchie ;-)
<seb128> ------- Additional Comment #2 From Bastien Nocera  2004-05-11 12:05 -------
<seb128> Multisession support is not being considered (given the price of a blank CD,
<seb128> these days...).
* seb128 slaps thom, fix firefox dude instead of speaking like that :p
<HrdwrBoB> that said, CD-RW's are also cheap
<thully> but - you have to rewrite the whole thing even if you want to add a 2MB file... not ideal by any means
<HrdwrBoB> true
<thom> seb128: there's nothing wrong with firefox, you just need to learn how to use cursor keys
<seb128> thom: teach me :)
<seb128> thully: take an another disc to copy the 2M file :)
<thom> well, you see those two arrow keys on your keyboard? one is a left arrow, and that makes your cursor go left. the other is a right arrow, and that makes your cursor go right
<thom> it's pretty easy really
* thom goes to bed before seb kills him
<dredg> feh, use a usb pen drive for the 2M file :)
<thom> or the internet, there's a shocking thought
* seb128 kicks thom
<dredg> noooo. too new fangled. it'll never catch on
<sivang> thully: so that randomly relocating cursor thing is a feature ? :)
<dredg> next you'll be suggesting tha some company has come up with a way of 'searching' the internet
<HrdwrBoB> this internet thingy is only for geeks
<thully> sivang:?
<sivang> thully: opps sorry
<sivang> thully: that was for thom 
<thom> sivang: geez, we need to put on "how to use your cursor" classes, don't we
<jdub> seb128: (i think that's pretty silly, really)
<thom> it works fine for me
<seb128> jdub: to be honest, me too :)
<fabbione> re
<sivang> thom: maybe :) put on a wiki page , I swear to read it before I whine again
<thom> unless i have like a two point font, in which case i can't tell anyway
<seb128> (but I don't record a lot of CDs out of plain ISOs so I just ignore it for the moment)
<thom> (and yes, it's a known bug; problem with pango)
<sivang> thom: thing is, I happily move the cursor through a text line, and it automatically jumps to it's end ..no way to mark that text unless using the mouse
<thom> so in the end, IZ GTK BOOG anyway
* seb128 slaps thom again
<seb128> PANGO is not GTK
<jdub> thom: is .fr boog
<fabbione> elmo: ping?
<thully> As for multisession - telling people to use the internet or a USB key wouldn't be ideal if they were burning things intended for a non-internet linked machine and didn't have a USB key..)
<seb128> jdub: that's an evil comment
<thom> it's all the same thing
<elmo> fabbione: ?
<sivang> jdub: hehehe
<jdub> fabbione: duderino, want inotify 0.19? :)
* seb128 too
<fabbione> elmo: i received some NEW messages on some sparc packages, is that correct? even for the kernel?
<fabbione> jdub: you are talkign with the wrong person :-)
<thully> or the machine could have a slow connection, or you could be adding winmodem drivers to the CD for use on a fresh Linux install :)
<fabbione> elmo: and if you can bless 2.6.11 it would be nice
<jdub> fabbione: i am? :)
<elmo> fabbione: yes
<elmo> and I did 2.6.11 already
<fabbione> jdub: yes.. no more 2.6.10 for me
<elmo> fabbione: NEW works by package name, the sparc kernel udebs have a unique name.. -> NEW
<fabbione> elmo: thanks :-) you rock
<fabbione> hmm strange.. i didn't get the email on other versions
<fabbione> just the normal ACCEPT
<dholbach> i'm off to bed before my head is going to explode
<ogra> guys, have you read this highly technical article about sabdfl ? http://www.iol.co.za/index.php?set_id=1&click_id=139&art_id=vn20050209102227763C337661
<ogra> *g*
<jdub> hahahaha
<dredg> highly insightful piece
<dredg> yes, i can really see the point
<ogra> lol
<jdub> oh man, i have to fix my latest UBU now
<dredg> hmm, perhaps i should follow their advice... i mean, i'm not a billionaire or anything but still, you gotta have goals
<sivang> interesting
<sivang> :)
<thully> I wondered.. is there any way ifup could be modified not to stall the entire system on boot trying to get a net address w/DHCP?
<thully> meaning, modified in Ubuntu
<dholbach> *wave*
<dredg> night dholbach 
<dholbach> bye dredg
<thully> My particular situation is: I have a wireless card, and want to be online when my system sees an access point, but don't want DHCP stalling the boot process when I'm not at an access point - could something be done about this in hoary?
<fabbione> no
<fabbione> you can't
<fabbione> dhcp needs to timeout nicely
<thully> it can't run in the background?
<fabbione> no
<fabbione> that would be worst 
<fabbione> for example if you have services that needs network
<fabbione> and don't recongnize when new ifaces are up
<fabbione> than you are doomed
<thully> as this would be nice for people who have a network interface that is used a lot, but not 100% of the time
<dredg> fabbione: well, would it be possible to boot with e.g. network=off? 
<thully> The ideal solution would be something like ifplugd/waproamd, but as to my knowledge this has been pushed to hoary+1
<thully> One thing that may be useful - start/stop wi-fi and start/stop ethernet buttons in the system tray for configured interfaces
<jdub> daniels: ping
<mdz> lamont: are we cloop-build-capable yet?
<thully> Would it be feasible to include network start/stop options on one of the GNOME menus/system tray in Hoary? 
<seb128> there is the network-admin tool for that
<thully> yes - but opening it, entering the password, clicking on the interface, and pushing activate just to connect to a wi-fi hotspot hardly seems intuitive..
<tritium> In hoary, perhaps hdparm should start later so that cdrom modules can load before hdparm tries to set dma.
<Menaherann> hello guys.. i have a problem with my laptop, and the guys tahat i've talked to in the regular ubuntu channel don't have a clue on how to help me....
<tritium> Menaherann, you haven't asked.
<Menaherann> since you guys are"the laptop division"
<Menaherann> ok.... here it is:
<Menaherann> i can't pass the login screen
<Menaherann> once i input username/pasword the computer deosn 't load anything....
<Menaherann> thanks to other user's experiments i know now that the os is not frozen, since i can log in the console
<Menaherann> but the problem is with the GUI
<zul> hey
<Menaherann> gnome is giving my shit!
<zul> oka
<zul> okay even
<Menaherann> note rthat i;m a newbie and don';t know what's going on....
<Menaherann> sorry for that shameful typing....
<tseng> do you get a splash screen at all?
<Menaherann> thye yellow -like ubuntu screen that ask me for username/password?
<tseng> no.
<Menaherann> well that's the last thing i se with color
<tseng> whats the next thing you see?
<Menaherann> after i put everithing what i get is ablack screen
<jdub> Menaherann: this would be better discussed in #ubuntu
<Menaherann> and the arrow of my mouse.
<jdub> Menaherann: #ubuntu-devel is for developer discussion
<tseng> clearly
<Menaherann> oh...
<Menaherann> ok.... didin;'t know that
<tseng> jdub: he tried to lead on he had a specific laptop question.
<tseng> oh well.
<Menaherann> [sigh]  so back to the ubuntu channel?
<tseng> or the forums, wiki, other numerous forms of user support
<Menaherann> all right.
<tseng> thanks, good luck
<Menaherann> thanks though..
<seb128> usually GNOME not loading is due to the loopback interface not working correctly
<thully> yes - I've had some problems with that before.. currently the live CD does that if you have a wi-fi card but aren't in range of a network
<tseng> ogra: ping
<ogra> tseng: pong 
<tseng> ogra: you answered my own question before i even asked it
<tseng> ogra: good work.
<tseng> (wanted to add things to the motu teams)
<ogra> hmm
<ogra> ah, yeah, go n :)
<ogra> s/n/on/
<lamont> mdz: all 4 architectures have current cloops
<sladen> jdub: http://lwn.net/Articles/122943/ you might want to reply to the ''if only they supported sparc'' comment
<mdz> lamont: great, thanks
<jdub> Kamion: around?
<jdub> sladen: thanks :)
<lamont> mdz: let me know when there's an ia64 image, and I'll test it
<mdz> lamont: still no ubuntu-live yet, right?
<lamont> mdz: ubuntu-live is in it
<lamont> x4
<mdz> ah, ok
<mdz> it seems to be missing its depends, though
<mdz> due to my mistake
<tseng> jdub: any ideas on the industrial cursor bug?
<lamont> Setting up ubuntu-live (0.28) ...
<lamont> mdz: bummer
<tseng> jdub: i cant think of a clean way to wedge that stuff back in =/
<jdub> mdz: why is libgnome2-perl in supported seed?
<mdz> lamont: does this mean we're missing language-support-en?
<jdub> tseng: yeah, i'm dealing with it upstream
<tseng> maybe a seperate pack for industrial icon theme
<mdz> jdub: dunno, is it new?
<tseng> jdub: ah, cheers
<lamont> mdz: the string 'language-' does not appear in the output
<mdz> mvo and I talked about it, but I don't remember adding it
<lamont> but we do still generate english locales
<mdz> lamont: ubuntu-meta 0.29 uploaded
<jdub> mdz: doesn't appear to be in warty
<lamont> gah - and in 56 minutes, we can churn another livecd rootfs
<jdub> mdz: it was added for the debconf gnome frontend, which i'm writing a mail about now
<mdz> lamont: new casper doesn't seem to be built yet anyway
<jdub> mdz: (saying no)
<mdz> jdub: let's talk about that
<mdz> I know you don't like the UI
<jdub> mdz: (saying let's discuss it, my opinion is no)
<mdz> but the current UI is "WTF the installation stalled with no feedback"
<jdub> or using the vte terminal
<mdz> the terminal window is hidden by default now
<mdz> which is nice
<jdub> yeah, and mvo can't find a way to pop it up when input is required
<mdz> it's likely to be impossible
<mdz> without some new communication channel
<jdub> so i'm happier with showing vte and fixing this properly in hoary+1
<jdub> instead of adding a whole chunk of stuff to main, and in particular, the desktop
<jdub> 1.8MB packed, 6.3MB unpacked
<mdz> that's nothing, space-wise
<mdz> though it is a chunk more packages to support
<jdub> yes
<jdub> that is what i am mostly worried about
<mdz> wel,l it would be if it weren't already in supported
<jdub> only as an explicit seed addition
<jdub> in hoary
<sladen> LD_PRELOAD and grep for read() on fd==0  && raise ?
<jdub> always up for a nasty hack, sladen ;-)
<tseng> ew, LD_PRELOAD
<sladen> btw, is  sulogin  failing with  root:!:...   a known issue (the result of  passwd -l  which is what's becoming recommended to users to undo their root passwd damage) ?
<restrex> https://bugzilla.ubuntu.com/show_bug.cgi?id=6433
<lamont> mdz: we have casper love yet?
<mdz> lamont: yep
<mdz> lamont: cloop builds in 6 minutes?
<tseng> restrex: all bugs go through mdz and he assigns them properly
<tseng> restrex: no need to spam them here.
<lamont> about 6-7 min more for ubuntu-meta love
<restrex> tseng It's realley a but man
<tseng> there are plenty of real bugs.
<restrex> well
<tseng> they will be fixed in order of severity
<tseng> just be patient please :)
<restrex> it's on a trivial bug...
<mdz> restrex: you only filed that bug an _hour_ ago
<restrex> yea >P
<HrdwrBoB> restrex: it's also a duplicate
<lamont> restrex: people actually use icons on the desktop??? :-)
<lamont> HrdwrBoB: meaning it's actually more than an hour old, eh?
<restrex> jeje the icon is an access to /media
<mdz> HrdwrBoB: please mark it as such, if you would
<HrdwrBoB> mdz: doing so
<sladen> restrex: related to that bug.  If you insert a drive of photos and then click 'Cancel' to the import question, the icon is not displayed either
<restrex> sladen I haven't any drive of photos, so I don't know
<lamont> in any case, it belongs in #ubuntu
<sladen> lamont: it's okay.  he posted it there *aswell* :)
<restrex> !!
* lamont sighs
<restrex> so in #ubuntu nobody knows that
<restrex> :)
<tseng> restrex: as a tip for the future, please carefully search bugzilla before filing bugs.
<lamont> restrex: many developers are in #ubuntu as well
<restrex> lamont
<lamont> #ubuntu-devel is the place to discuss your code change that will fix the problem
<restrex> I-ve been all the day questionung that thing
<restrex> and nobody gave me an answer
<restrex> really
<HrdwrBoB> it's a dupe of 4066
<lamont> restrex: and the bug that it's a duplicate of has been in the bts for far more than a day...
<HrdwrBoB> a day?
<mdz> lamont: ubuntu-live ready to go?
<restrex> lamont i don't understand your question :S
<HrdwrBoB> 2005-01-03
<HrdwrBoB> it's two months old, that said, it is annoying to find
<mdz> bugzilla's search functionality is less than ideal
<mdz> at any rate, the situation is resolved now, and we can all get back to ubuntu-devel matters :-)
<lamont> mdz: launched
<mdz> thanks
<mdz> lamont: ping me when it's safe to start the CD builds
<restrex> lamont I don-t understand your question...
<mdz> restrex: he isn't asking you a question; the conversation has ended
<lamont> zul or t-bone around?
<marcin_ant> hi
<marcin_ant> do you guys know why bitmap fonts - such as MiscFixed - are not available in font selector in gnome?
<sladen> marcin_ant: the short answer is because they look ugly, don't scale, don't anti-alias and look even worse printed.
<marcin_ant> sladen: sorry but it is really annoying that someone wants to decide what should I use
<marcin_ant> sladen: misc fixed maybe is ugly
<marcin_ant> sladen: but it is perfect font for coding/hacking
<tritium> marcin_ant, bitmap fonts in general
<marcin_ant> sladen: and this font is very fast
<marcin_ant> sladen: while those blurry aliased and scaled fonts are pretty on desktop - but annoing when you want to read code
<marcin_ant> marcin_ant: I had misc fixed for years in my xterm, aterm whatever
<lamont> marcin_ant: so fire up a terminal specifying that font
<marcin_ant> lamont: and?
<marcin_ant> lamont: btw what do you mean terminal?
<marcin_ant> lamont: I don't want this font on terminal
<lamont> xterm, gnome-term, whatever
<lamont> then whatever app.
<marcin_ant> lamont: I want this font in eclipse
<lamont> I think they all take -fn options, no?
<tseng> this isnt an ubuntu specific issue afaict
<sladen> marcin_ant: look in  /etc/fonts/local.conf  for the line that says  <!-- Uncomment below to enable bitmapped fonts -->
<lamont> tseng: I really doubt that it is
<lamont> it's most likely a gnome issue
<tseng> yep.
<tseng> gnome-font-sel, if you want to fight about it, see upstream
<sladen> marcin_ant: and please file a FAQ on the wiki when you have it working
<sladen> marcin_ant: (run  sudo fc-cache )
<ogra> sudo dpkg-reconfigure fontconfig
<marcin_ant> sladen: thank you very much
<ogra> asks about bitmap usage
<jdub> daniels: ping
<marcin_ant> sladen: do I need to relogin to gnome session?
<sladen> marcin_ant: I think the changes are dynamic, but I'm sure you'll find out when you try!   (and please follow this up on #ubuntu)
<marcin_ant> sladen: ok - I'll try to restart my session
* mjg59 figures out Eugenia's bug
<jdub> morning mjg59 
<mjg59> Oh lord I have to sleep
<mjg59> I've been fighting postscript for the past 5 hours
<lamont>   ubuntu-live: Depends: language-support-en but it is not going to be installed
* lamont glares
<lamont> (ia64 only)
<mdz> others still going?
<lamont> yeah
<lamont>   language-support-en: Depends: openoffice.org-hyphenation-en-gb but it is not going to be installed
<lamont> well, that would explain it
* lamont fixors
<lamont> are the language-support-* packages autogenerated, or manually, I wonder?
<lamont> mdz: should that be [!ia64] , or should it be [i386 powerpc amd64]  ??
<lamont>   * Automatic update to latest translation data.
<lamont> well, that answers taht
<lamont> oh pitti....
<lamont> mdz: new livecd rootfs build going on ia64 with ubuntu-live dropped for now
<lamont> and filing a bug for pitti
<mdz> lamont: are the others finished?
<lamont> no
<mdz> the cloop builds seem to take longer than a test install from CD
<mdz> I guess the actual cloop bit takes forever
<lamont> i386 was doing the partimage things
<lamont> mdz: i386 done, ppc and amd64 compressiong
<lamont> amd64 done
<thully> Hi - is the plan for Hoary to use kernel 2.6.10, or 2.6.11 when it comes out?  Just wondering- because there is some enhancements to mouse drivers in 2.6.11 I may be interested in...
<mjg59> Almost certainly 2.6.10
<lamont> 2.6.10
<mjg59> If there's specific stuff in 2.6.11 you want, it might be possible to get it backported
<lamont> all the good stuff has been backported, fwiw
<lamont> for some definition of 'all'
<lamont> the patch count with 2.6.11 drops from ~270 down to ~70
<lamont> mandb: warning: /usr/share/man/man1/ckeygen.1.gz is a dangling symlink
<lamont> mandb: warning: /usr/share/man/man1/conch.1.gz is a dangling symlink
<lamont> mandb: warning: /usr/share/man/man1/tkconch.1.gz is a dangling symlink
<lamont> mandb: warning: /usr/share/man/man1/btcompletedir.1.gz is a dangling symlink
<lamont> tsktsk
<thully> well - I was specifically talking about trackpoint support - I don't know if it'll be in 2.6.11 or not, but there was a thread on LKML about it
<spiv> lamont: Three of those would be the python-twisted-conch package.
<zul> thully:definently 2.6.10
<lamont> spiv: bad python-twisted-conch
<lamont> zul - evening
<zul> lamont: heh how is it going?
<lamont> insane as usual
<mdz> lamont: ppc done yet?
<zul> lamont: sounds exciting :)
<lamont> mdz: barely
<mdz> lamont: hmm?
<lamont> well, 5 min ago
<thully> although trackpoint scrolling can be done a total of 3 ways: 1)wheel emulation in X 2)tp-scroll daemon, which simulates a wheel mouse 3)trackpoint kernel patch, which I think is under discussion for 2.6.11
<mdz> ok, kicking off cd builds
<mdz> we can get ia64 later when it's done
<lamont> mdz: thanks
<lamont> it shouldn't be too much longer
<lamont> zul: looking at the KernelTeam page - it needs some heading love.
* lamont updates
<zul> lamont: go right ahead
<zul> lamont: you know most of the kernel bugs doesnt have any details of the users hardware
* bluefoxicy will be back in a bit
<lamont> zul: yeah - makes it more fun... and gives you a good first question for the submitter... :-(
<sladen> thully: it's still a problem that you have to scarifce one button.  the best I've seen is middle=scroll and enable chording to still get the middle button
<thully> yes - if you use the other 2 solutions that isn't a problem - although I did see a couple postings on the X.org mailing list about something in CVS that lets you set a threshold to determine what's a click and what's a scroll
<sladen> interesting, I wonder how that works in xpdf (middle button to scroll)... but as long as the 2d scrolling took over at that point, it would be fine.
<mdz> zul: ogra's work should make that easier
<zul> mdz: sweet!
<lamont> mdz: ia64 would be making better time if it weren't for the gcc-3.4 build that's running on the same machine...
<mdz> amd64 daily-live looks good
<zul> night
<robertj_> can someone take a lookt at #6390 and tell me if this is suggesting a course of action that will leave users without security updates by default if the install is done without the network connection active?
<daniels> jdub: pong
<robertj_> daniels: is that pong related to my question or am I just being self-absorbed ;)
<jdub> daniels: got time for a phone call?
<daniels> robertj_: i missed your question; i was responding to jdub's ping
<daniels> jdub: sure, mobile on wiki
<robertj_> daniels: ahh, basically if I'm reading #6390 the current suggestion is to not add security sources if no network connection is detected at install
<wasabi> packaging question: Is there some magic formula to make a postinst script run a command only once for the invocation of dpkg.
<wasabi> I have an update-* style script which doesn't need to be run 5 times for the 5 packages it's attached to. =/
<robertj_> wasabi: i'm a total newb here, but based on the fact that passwd doesn't use something of that sort to run newaliases but apparently waits for some other script to call it, my guess is no
<daniels> robertj_: i don't know; it's not my arena.  i think it was discussed in here the other day
<bob2> wasabi: not yet
<bob2> wasabi: scrollkeeper uses a horrible hack to do it, you could steal that if it's a huge deal
<bob2> (but it's probably not horribly annoying enough to bother)
<robertj_> scrollkeeper makes me thing...couldn't this be done in the background on first boot
<robertj_> err think
<bob2> if you send a patch to the bts, it could be considered
<jdub> scrollkeeper needs to be replaced
<bob2> even better
<robertj_> jdub: but am I reading that bug correctly?
<robertj_> #6390
<jdub> if it says, "scrollkeeper is naff and should die", then probably
<jdub> no that's not right
<robertj_> jdub: no, I think it says that the plan is to not add security sources and not prompt to add them if no network is detected
<jdub> we just wouldn't be installing the updates during base-config
<jdub> well, yes, all network sources would be disabled if there were no network available
<jdub> not just security
<jdub> i don't think i agree with that, myself
<robertj_> yeah, that's what I was getting at
<mdz> robertj_: there is no way to install security updates without a network
<mdz> there is nothing to be done about that
<robertj_> mdz: why dont we just default on and then worry about patching apt to behave more intelligently for grumpy?
<jdub> mdz: i think it's mostly that the network sources would not be enabled by default
<jdub> mdz: not anything to do with security
<jdub> mdz: this means that even if the user configures their network post-install, update-notifier won't work, etc.
<robertj_> if synaptic is doing updates when you start it anyway, it should kick out the bad sources regardless
<jdub> however, to fix it, we need to make handling inability to connect nicer in all the frontends
<robertj_> oh, I thought it just timed out eventually and went on
<mdz> robertj_: I don't follow
<mdz> it does just time out and go on, but that's not terribly friendly, and it would be irresponsible not to report it as an error
<jdub> mdz: example -> os x doesn't give a rats arse if you had a network connection during install or not, it will still handle doing updates nicely when you have a connection :-)
<robertj_> mdz: yes, but it's not as bad as not doing security updates ever
<mdz> jdub: how?
<jdub> networkmanager will help a bit with this, but the apt configuration has to be network source aware
<jdub> mdz: because it doesn't disable network sources if you don't have a network connection during install (to put it in the apt context)
<mdz> robertj_: fortunately, no one is suggesting that
<robertj_> mdz: that's what I got out of the bug report
<mdz> honestly, the change I have suggested doesn't make any difference whatsoever on this point
<mdz> currently, you get security updates if you answer 'yes' to the question
<jdub> it's colin's summary, second last paragraph that we're talking about
<mdz> you can't answer 'yes' to the question if you aren't connected to the Internet
<mdz> ergo, you don't get security updates if you aren't connected to the Internet
<jdub> no problems with the change you proposed at all
<robertj_> mdz: which be a bad thing if you later get on the internet
<mdz> all I'm talking about is smart defaults
<jdub> see the second last paragraph for the point we're discussing
<jdub> which is not a smart default
<mdz> I wrote that
<mdz> and I think it is
<jdub> ok, so
<jdub> scenario
<jdub> i am installing ubuntu on a plane coming back from LWE
<jdub> no network, so it doesn't bother asking to update, and it disables the network sources
<daniels> yes, because everyone does that :P
<jdub> two months later, after having used the laptop at home, at work, at wireless cafes, and in the sidecar of my butch step-sister's motorcycle while wardriving,
<jdub> i realise that i haven't had any updates
<mdz> ok
<jdub> so i uncomment those lines (through the prefs dialogue, not vi), and update
<mdz> now walk through exactly the same scenario with a Warty CD
<mdz> and with array 4
<mdz> and with my proposed changes
<mdz> realize that the result is identical
<jdub> i know
<jdub> we're not talking about previous releases
<jdub> we're talking about the plan described in that bug
<mdz> so why are you guys talking about my proposal as if it makes any difference in this matter?
<jdub> and one very specific clause
<jdub> again, second last paragraph
<jdub> let's not make that mistake again
<robertj_> jdub: or more fun, later that night, you go back to the hotel and install sshd because you want to leave it on and sftp stuff from work the next morning. You go to work the next morning and you can't log in. 
<mdz> the entirety of that bug report is included in "my proposed changes"
<mdz> and everything that I said still stands
<mdz> why am I not getting through?
<jdub> because we are talking past each other
<sladen> is this similar to the NTP thing;  it's an interface coming up that should enable enable the update-notifier 
<jdub> In fact, I think that if we get it just right, we can skip the question
<jdub> entirely, and if the network test fails, silently leave the network sources
<jdub> disabled and continue.
<mdz> I know what I wrote
<jdub> everything up to the third comma we *totally agree with*
<mdz> now you explain to me why you think that paragraph changes the behaviour of the system as a whole
<mdz> because it doesn't
<jdub> we are talking about the clause *after* the third comma
<jdub> no, i'm not, and have said so numerous times now
<robertj_> mdz: i don't know how it currently behaves so I don't know if its a change
<jdub> totally agree with the proposal
<jdub> fundamentally
<jdub> it is the right thing to do
<jdub> etc., etc. say it again
<robertj_> mdz: but it should be enabled by default
<jdub> except for the clause after the third comma in the second last paragraph
<jdub> which is the entirety of what we've been discussion
<mdz> ok
<mdz> now
<mdz> <mdz> now you explain to me why you think that paragraph changes the behaviour of the system as a whole
<robertj_> because in that aformentioned usage scenario you can install sshd the next day and get your box rooted by a known esxploirt
<mdz> that is true whether or not you include the clause that jdub is protesting
<mdz> this is the crux of my proposal
<jdub> i don't think it is
<mdz> that there is no point in asking the question whatsoever
<robertj_> mdz: not its not
<jdub> dude
<jdub> holy shit
<jdub> YOU ARE ABSOLUTELY RIGHT ON THAT POINT
<robertj_> we understand that
<jdub> we are not even coming close to disagreeing with that
<robertj_> but that security sources should be enabled no matter what
<jdub> we are saying, quite clearly i think,
<mdz> the problem with this is
<jdub> that all the network sources should, ideally, be enabled by default whatever happens during installation
<robertj_> if you change silently disabled to silently enabled by default
<mdz> that you are arguing against something which would not change as a result of my proposal
<jdub> that is the only thing we are talking about
<mdz> then you are talking about something completely orthogonal to my proposal
<jdub> yes, we are
<mdz> because it has the same characteristics as the current method in that respect
<robertj_> mdz: indeed!
<jdub> that's right
<mdz> then why do you keep saying that you disagree with the second-to-last paragraph?
<mdz> because it is a no-op
<jdub> we are only talking about the minor point after the third comma in the second last paragraph
<robertj_> no-op?
<mdz> this is ridiculous, I am going to call jdub on the phone and straighten this out
<jdub> heh
<jdub> cool
<robertj_> basically our point is the whole thing is a moot point because security sources belong no matter what
<robertj_> no need to ask a question, run any tests, or whatnot, just add the sources and let update-notifier do its job on the first boot
<robertj_> things getting clear?
<mdz> ok
<mdz> I think so
* jdub pulls down his wifi interface ;)
<mdz> jdub: that's not the same thing :-)
<mdz> here is the difference between what I am talking about and what you guys are talking about
<mdz> I am talking about fixing the bug that installation takes an inappropriate length of time if there are network updates available
<mdz> and you guys are talking about a feature whereby the network sources could be enabled unconditionally and the frontends would behave intelligently
<jdub> oh man
<jdub> this is so reasonable
<jdub> ugly, but reasonable
* mdz pulls his ethernet cabl
<mdz> cable
<jdub> http://people.ubuntu.com/~jdub/screenshots/synaptic-without-internet.png
<mdz> ok, I have clicked reload in synaptic
* Treenaks sees the new xscreensaver password dialog.. WOW
<mdz> and it is showing me a progress bar with no activity
<mdz> it will do this for the next 60 seconds or so, with no feedback whatsoever
<jdub> yeah
<mdz> this is so not reasonable
<tritium> Treenaks, I like it too.
<jdub> mine happened nice and quick (no default route)
<lamont> mdz: ia64 is done
<robertj_> mdz: err, could that be fixed?
<mdz> lamont: I uploaded a new casper, so I'll roll a full set of CDs including ia64 when it's built
<robertj_> I mean, couldn't the timeout be like, 5 seconds?
<mdz> robertj_: no, it couldn't
<lamont> mdz: cool - holler when
<mdz> making the system less robust is not a reasonable tradeoff
<mdz> hey, the progress bar moved
<mdz> now it's on 2 of 10
<mdz> and will spend another 60 seconds timing out
<robertj_> ahh
<mdz> look, I completely agree with you guys that it would be uber cool to enable the network sources all the time
<mdz> but it's something that would build on top of my proposal as an incremental improvement
<jdub> not happy with synaptic's handling?
* tritium is curious about the "Turn on VGA" icon on jdub's desktop
<mdz> but I don't think that it should stop us from implementing my proposal, _including_ disabling the network sources by default, because my proposal is itself an incremental improvement on what we have today
<jdub> tritium: i855crt script, which changes the icon and stuff. pretty cute.
<mdz> and it doesn't stop us from making it better later, if we can fix the remaining issues
<tritium> jdub, ah, cool
<jdub> mdz: we were not suggesting, at any stage, that it stop us from implementing your proposal :)
<mdz> I don't think we can enable the network sources unconditionally until we fix the UI problems that would cause
<mdz> jdub: ALL OF IT :-)
<jdub> ok, agree
<jdub> yes, even the orthogonal bits ;)
<mdz> including the last clause of the penultimate paragraph
<mdz> wonderful :-)
<mdz> jdub: I also take issue with the fact that the Reload button gives no indication whatsoever that it is something which requires Internet access
<mdz> in fact it doesn't look like what it does at all
<jdub> it should be a picture of a bum with a fist coming out of it
<robertj_> How difficult an issue would it be patch synaptic to check for internet access and allow it to skip all http/ftp repos?
<mdz> robertj_: it would be a feature, and we are in feature freeze
<mdz> setting aside the issues with determining whether we have internet access or not
<robertj_> mdz: I thought it was more of a slush at this point ;)
<mdz> it is a freeze with well-defined exceptions
<mdz> it is the point where, though we continue to dream up new ideas for features to implement, we stop adding to the list
<mdz> (the Hoary list)
<robertj_> yeah
<robertj_> understood, but to me this seems like a security deal
<mdz> we have survived the past 10 years with this behaviour, and we can survive another 6 months I think
<daniels> mdz: is ddcprobe-on-amd64 still viable for hoary?
<daniels> mdz: (obviously post-usplash)
<robertj_> at the very least a warning "If you continue to install without network access your machine will not receive security updates until you do the following: "
<mdz> daniels: makes me nervous
<mdz> robertj_: sure, a paragraph in the installation guide would be good
<robertj_> mdz: noone reads those things though
<mdz> no one reads dialogs in the installer either. point?
<mdz> if there is only one button at the bottom, "OK", it doesn't get read
<robertj_> well maybe keeping the question isn't such a horrible thing then
<daniels> mdz: mmm.  if we do it under x86emu, we gain the advantage of rolling it into vbetool, and we gain ddc-on-amd64, because lacking it sucks.
<daniels> mdz: i was hoping to do it last week, but unfortunately delays with bits for my amd64 and then ubuntu13 threw that right out, and now usplash ...
<mdz> daniels: it would invalidate all the X autoconfig testing we have done on amd64
<mdz> would it not?
<mdz> jdub: I just remembered another problem which would need to be fixed
<mdz> jdub: if you have never been connected in the first place, you don't have copies of the Packages files at all
<sladen> daniels: setup.S records the DDC and edid data whilst in 16-bit code, no idea where it dumps them
<mdz> and apt-get etc. will print errors every time they start up
<sladen> daniels: s/setup.S/video.S/
<jdub> mdz: that's a good excuse to bail out ;)
<mdz> jdub: no it isn't; they can still install things from CD
<jdub> true
<daniels> mdz: not really, since there's no arch-specific code in there, apart from stubbing all the functions
<jdub> those are stupid errors anyway ;)
<mdz> maybe, but they're there
<daniels> mdz: whether not ddc succeeds or fails on amd64 doesn't impact the autoconfig testing, and I think it would be a massive win to have it available
<daniels> sladen: i take it this is isolinux?
<mdz> and my whole point is that there are several issues, including ones we haven't even thought about yet, which would need to be addressed in order to enable them unconditionally
<daniels> or syslinux
<mdz> daniels: what if it hangs the system?
<daniels> mdz: then we're fucked, to borrow some popular vernacular
<daniels> mdz: in that case, the vesa driver and probably the vga driver would be unusable on that machine
<jdub> NOOOOOOOO!
<mdz> jdub: what's your opinion on amd64 DDC?
<daniels> mdz: and I believe the Windows installer uses VESA these days
<sladen> daniels: kernel, arch/i386/boot/video.S
<daniels> so I doubt that any cards are screwed like that with VESA ;) it's only really VESA POST that sucks, and that's because they don't expect you to ever call it
<mdz> daniels: I could have given you an account on the test box here months ago if you wanted to work on this
<daniels> sladen: hm, cool; i'll check it out, thanks
<daniels> mdz: mm
<jdub> mdz: i'd defer to you and daniels on this one, anyway
<mdz> jdub: coward
<jdub> i can say no if it makes you feel comfortable
<daniels> i think it would be well wikkid, but it's not a showstopper
<mdz> I think so too
<daniels> it seems that most of the mum-and-dad pcs are still i386 anyway, so asking that question on amd64 isn't too tragic
<mdz> and I would have been all over it a month ago
<daniels> by the time hoary+1 rolls around, we'll totally need it, though
<mdz> but why bring this up now?
<jdub> because he just got an amd64 ;)
* jdub deep-sixes with style!
<daniels> mdz: because I now have a machine I can do this on, and I'm not nearly as busy with general xorg stuff as I was beforehand
<mdz> I think usplash is about a billion times more important
<mdz> and that by the time you're done with usplash, it will be even more too-late for this than it is now
<daniels> fair call
<daniels> hoary+1 it is
<robertj_> hehe, I need to get off my butt and file bugs for my laptops, both which refuse to sleep properly
<daniels> with our BATSHIT INSANE CRAZY reconfiguration structure
<robertj_> daniels: grumpy groundhog is still the name right?
<daniels> (terms and conditions: reconfiguration structure may not be batshit insane crazy)
<sladen> so, regarding the problem of needing DDC/EDID to decide on the vesa mode to pass to the kernel... ;-)
<mdz> daniels: if someone else could work on it while you work on usplash...
<mdz> robertj_: no, it isn't
<mdz> but its true name shall not be spoken
<daniels> mdz: mjg59's capable of doing so
<jdub> robertj_: it's officially known as 'hoary+1'
<daniels> sladen: hm.  well, I'll check it out this weekend :)
<jdub> until mdz can come to terms with the real name
<jdub> and finally let me announce it
<Rotund> GRAPE APE
* spiv votes for grody ;)
<sladen> MingingMunter
<sladen> collectively know as a Herd
<mdz> jdub: that, or I find a way to install a content-mangling proxy on all of sabdfl's computers
<jdub> haha
<mdz> so that we can use a less awful name
<robertj_> jdub: I kinda like grumpy, but it's different, it's not as image invoking as the previous ones
<daniels> sladen: so when people install it, they're getting munted?
<robertj_> how about Dandy Dolphin?
<jdub> robertj_: yeah, and still dispositive (which we want to get away from)
<sladen> daniels: maybe they'll get screwed... :)
<mdz> daniels: remind me, why can't we just assume that some low-res vesa mode will just work?
<mdz> jdub: you should check out the latest live CD with ejection love
<robertj_> daniels: cus then you can't get the pretty modes for usplash ;)
<daniels> mdz: we *should* be able to, but I want to see if we can first (i.e. get some wider testing)
* robertj_ ponders the merits of brunching bovine
<lamont> robertj_: you mean 'bouncy bovine'
<robertj_> should the be animals found in Africa?
<robertj_> I like brunching better
<robertj_> It's not quite breakfeast...it's not quite lunch...
<sladen> mdz/daniels: for the livecd I'm tempted to do  vga=... (640x480)  Fallback is plain vga16.  Correct mode loaded at X.   For install I'm tempted with result of debconf:xserver-xorg/.../video-mode matched to the nearest vesa mode and then set in menu.lst for next reboot
<Rotund> What image was Hoary supposed to invoke?  It just meant I had to spell it to everyone
<robertj_> Old, and battle-hardened, well as much of a battle as one can be in without opposable thumbs
<Rotund> hmmm.. interesting
<Rotund> sladen: you working on usplash?
<sladen> mdz/daniel: LiveCD/ppc, work with what you're given.  install/ppc, work with what you're given.
<robertj_> Maybe Elequent Elephant, in which many of Hoary's rough edges are cleaned
<sladen> for comparision.  Knoppix (IIRC) hard-code to 1024x768 on LiveCD.  Xandros to 320x200.
<robertj_> sladen: 320x200 is what XP does
<sladen> robertj_: I think it might even do 320x400x4-bit (also == 64kB)
* robertj_ wouldn't feel bad about having to have an i_am_doing_something_odd_or_my_monitor_is_a_piece_of_crap
<robertj_> just tack that on the end of grub and there you go...
<sladen> robertj_: and the LiveCD case (you need to have decided the mode before you load the kernel)
<robertj_> what % of machines cannot jive with 1024x768x16 these days?
<robertj_> I know there have to be some, I had to toss out an Apple monitor the other day because it wouldn't play nice
<robertj_> but I didn't feel bad in the least about doing it ;)
<Rotund> robertj_: Some laptops would be 800x600
<sladen> robertj_: that's the tack of Knoppix:  http://www.bouissou.net/knoppix-mib/doc-html/Knoppix-Mib.html#display_or_graphics_problems
<robertj_> Rotund: are any modern laptops 800x600?
<Rotund> 800x600 would also be the case w/ older projectors
<Rotund> some of the sub-notebooks
<Rotund> I'm not necessarily saying new, but still in use, yes
<robertj_> Rotund: hrmm, I thought they would be at a wide-aspect or half 1024
<mdz> what causes people to randomly use the 'branding' keyword?
<mdz> I am thinking of deleting it because it is not particularly useful in the first place, and I have never seen it used properly
<Rotund> robertj_: Some of the old 12" were 800x600 too
<Rotund> 640x480 would be for people that would output to a TV
<robertj_> Rotund: even if the bootsplash doesn't work, X will as long as their TV doesn't die
<Rotund> would it fall back to text?
<robertj_> Rotund: why should it? The display mode would change to whatever they have configured X to be
<robertj_> so if they take their laptop and hook it up to a TV, it's going to not work until they use xrandr to change it
<robertj_> there is a decent chance that if its hooked up to a TV even the lower vesa modes wont work
<robertj_> there are like 3 resolutions my TV syncs at and that's it
<Rotund> there are desktops that use only a TV as an output
<robertj_> and none are standard VESA res/refresh rate combos
<Rotund> they use converter boxes
<Rotund> that take 640x480x60Hz and convert it to NTSC
<Rotund> rare, yes.  None, no.
<robertj_> Rotund: there's always going to be something wierd going on that will prevent some new feature from working
<Rotund> I agree w/ the "detect it"
<robertj_> but my TV aint gonna work with any vesa mode
<Rotund> it would w/ a converter box
<robertj_> not it wont
<robertj_> well maybe it if did something hideous
<Rotund> it underscans a bit
<robertj_> I dont consider that working
<robertj_> there are lots of modes that will give me nice little moving lines
<Rotund> it's mainly used for presentations and people w/ very bad vision
<Rotund> no.  As in it doesn't fill the screen completely
<robertj_> If you have bad vision, the lack of a bootsplash isn't likely to bother you that much
<robertj_> Just because you are probably much more patient than the majority of individuals because you probably sit around a great deal of the time wishing you could actually read the manual someone takes the time to write
<Rotund> huh?
<robertj_> Sorry, random rant ;)
<robertj_> Anyway, theres always going to be something not supported. 
* mpt_newjersey wasn't aware people read manuals, let alone wished they could
<Rotund> okay.  I was confused.  and I read and write manuals at work all the time
<robertj_> Rotund: I was just saying that I bet people who are visually impaired would probably value manual reading more than the average joe
<robertj_> that's all.
<Rotund> ahh.  yeah.  Does it affect the install at all?
<robertj_> Rotund: usplash doesn't affect anything unless it kills your equipment
<Rotund> =)
<robertj_> which at this point I just consider natural selection ;)
<Rotund> I mean I don't need 1024x768 to run the installer.
<robertj_> no
<robertj_> usplash takes care of the bit between grub and X
<Rotund> is the new installer X-based?
<robertj_> no
<robertj_> but it's not there if X is not there
<Rotund> I know warty asked questions during that time the first time one booted
<robertj_> anyway, no, it wouldn't matter as long as your monitor did not explode
* lamont declares bedtime
<fabbione> morning
<fabbione> hey lamont
<lamont> yo
<Rotund> Oh yeah... Quantum Leap 2!  They're gonna bring back QL
<pitti> morning
<fabbione> hey pitti
<fabbione> [ANNOUNCE]  hotplug-ng 001 release
<fabbione> this sounds cool
<fabbione> too bad it was announced one day after Feature Freeze
<jdub> fabbione: heh
<fabbione> jdub: i read the 0.19 announce
<fabbione> it looks like it has several bug fixes
<sladen> robertj_: it's more important than that.  casper/d-i ask questions and use the framebuffer to do so
<jdub> mmm
<fabbione> but it breaks the ABI
<jdub> i've uploaded a gamin that supports it
<jdub> it breaks API not ABI according to the announce
<fabbione> you dream
<fabbione> and it is not good that you patch your stuff and desync with the kernel
<fabbione> otherwise we will land in the same situation like for ndis
* dilinger notes rc2 randomly stopped working yesterday, even unloading the module didn't fix it.  ended up having to reboot.
<fabbione> dilinger: the kernel team is taking over 2.6.10
<fabbione> so i guess you can ask zul, T-Bone
<fabbione> i am working on .11 pre right now
<fabbione> but i can break rules on pre
<jdub> fabbione: the gamin patch is compatible
<jdub> fabbione: because, as the announce says, the ABI is compatible ;)
* LarryT-ubuntu few bugs with ubuntu hoary nstalled : 
<fabbione> LarryT-ubuntu: please reporte them via bugzilla.ubuntu.com
<fabbione> and before that, try to check if they have not been reported already
<LarryT-ubuntu> fabbione okey thx
<fabbione> no problem
<LarryT-ubuntu> fabbione there also is a problem with fr-latin9 keymap : no altgr keys :(
<fabbione> LarryT-ubuntu: please same as above
<fabbione> not all developers are awake now
<LarryT-ubuntu> fabbione report to the same ?
<LarryT-ubuntu> ok
<LarryT-ubuntu> bye :)
<fabbione> cya
<fabbione> thom, elmo: can you please the incoming dir from all the X trash please?
<fabbione> there were leftovers from a ftpd timeout
<fabbione> (sparc related)
<LarryT-ubuntu> fabbione please : for a fr-latin9 keymap problem : what kind of package is it ? :)
<LarryT-ubuntu> fabbione i mean to report a bug
<fabbione> xlibs
<fabbione> or xorg
<fabbione> the maintainer will take care of reassigning to the proper one
<LarryT-ubuntu> fabbione so i leave the field empty ?
<fabbione> you can't leave it empty
<LarryT-ubuntu> fabbione thx
<fabbione> write xorg in the component
<LarryT-ubuntu> fabbione ok
<fabbione> no problem
<mdz> good night
<jdub> night
<fabbione> night mdz
<d3vic3> how do I get all packages that depend on libflac4 in universe ? 
<jdub> d3vic3: apt-cache rdepends libflac4
<fabbione> d3vic3: apt-cache rdepends
<jdub> d3vic3: still a few left ;)
<d3vic3> tsk 
<d3vic3> Reverse Depends:
<d3vic3>   rezound
<d3vic3>   muine
<d3vic3>   mpd
<d3vic3>  ....
<d3vic3> is this the correct output ? 
<jdub> yeah
<d3vic3> what does Reverse Depends mean axactly ? 
<Treenaks> d3vic3: "packages that depend on this package", instead of "packages this package depends on"
<Treenaks> afaik
<d3vic3> d'accord 
<d3vic3> tsk 
<d3vic3> I mean, I see, thanks 
<pitti> elmo: xtrlock sync, please
<dholbach> morning
* fabbione needs more coffee
* dholbach too
<fabbione> hey enrico 
<enrico> ciao fabbione !
<fabbione> enrico: do you have 2 secs to talk about docs?
<enrico> fabbione: sure
<fabbione> cool
<fabbione> i am not sure you know that we are building up the kernel team
<fabbione> but as a team we need a bunch of wiki docs
<fabbione> and we would like to involve the doc team to write them in a proper way
<fabbione> do you think it is something your team can help us with?
<enrico> fabbione: not before hoary for sure :(
<enrico> At the moment there are 3 active people committing to the repository
<fabbione> hem.. we were talking for a few drafts within the next week ;)
<fabbione> we don't need translations
<fabbione> just to put down the basic scheletons for a good doc structure on the wiki
<enrico> fabbione: you can post something about what you'd like to have in the docteam mailing list, to see if some unexpected lurker turns active
<enrico> Considering the already active people, I'm pessimist; however, sometimes something wakes up unexpectedly, so I welcome events that can make it happen
<fabbione> enrico: since you already know the team.. can you ask around for volunteers to contact me/lamont?
<fabbione> i don't really have the time for another mailing list :(
<fabbione> lamont is one of the new kenrel team leaders
<enrico> fabbione: just put up like 5 lines with what you need and post it there, or post it to me and I'll post it there
<fabbione> so that would kinda help
<fabbione> what i wrote above is fine..
<fabbione> later we will ask for proof-reading and stuff like that
<fabbione> for now starting with a simple structure will be more than fine
* helix likes proofreading :)
* enrico hugs helix
<helix> enrico! :) *hugs*
* enrico hugs helix compulsively in any channel she shows up
<helix> heh
* Treenaks hates Perl a bit more today
<helix> you're supposed to be using python anyway, traitor!
<enrico> fabbione: but what kind of wiki docs would you need?  So far it's a bit generic
<amu> moins
<enrico> like, what do you want to document about the kernel anyway?
* enrico moins at amu
<Treenaks> helix: well, yes.. but unfortunately I get paid for writing perl
<fabbione> enrico: we need to write procedures/policies/todo/team struct(partially done)
<helix> Treenaks: well, it's not that unfortunate. :)
<fabbione> stuff that a new team member needs to know
<Treenaks> helix: that's true..
<enrico> fabbione: oh, so it's not docs for users
<Kamion> morning
<enrico> fabbione: I can replicate the structure of the docteam pages for you, if you want
<fabbione> enrico: they will come later on
<Treenaks> fabbione: so "This [picture]  is Fabbione. Worship him as a god." should be enough?
<fabbione> enrico: that would be nice yet
<fabbione> yes
<fabbione> hey Kamion 
<amu> enrico: salut
<fabbione> Treenaks: ehehhe
<ogra> morning
<dholbach> hello ogra! :-)
<pitti> Hi ogra
<pitti> ogra: will there be more patches today? :-)
<jordi> jamesh: ping
<ogra> pitti: depends on you ;) is the lsb patch ok ?
<pitti> Didn't I already reply?
<ogra> nope
<pitti> ogra: oh, sorry. I will answer ASAP, just finishing my current task
<ogra> pitti: at least not on the last changes :)
<ogra> yup :) take your time
<pitti> ogra: there were so many mails, I just review the latest one, right?
<ogra> yup
* netjoined: irc.freenode.net -> benford.freenode.net
<jamesh> jordi: yeah?
<seb128> jamesh: hey. have you looked on the battstat patch update ? (I've not updated my laptop yet)
<jamesh> seb128: not yet.
<seb128> k
<jdub> jamesh: dude, people keep bugging me about some libglade related api/abi bug
<Kamion> jdub: hm, how do you propose to write a pygtk frontend to perl debconf?
<Kamion> jdub: that would suck major nuts internally
<jdub> Kamion: We must be proactive, eternally vigilant, forever fighting, overwhelmingly clever and handsome.
<Kamion> the direction Debian is going is in replacing perl debconf with cdebconf
<Kamion> (probably)
<fabbione> jdub: can i say that i am your friend? ;)
<Kamion> but it's a boatload of work and half of it isn't done yet
<ogra> Kamion: i would fear the changes to the packages (adjusting all these questions) more then the changes to debconf
<jamesh> jdub: yeah.  looking at it.
<Kamion> ogra: what changes to packages?
<Kamion> well, anything that depends on debconf should depend on debconf | debconf-2.0
<Kamion> but they can do that already :)
<seb128> jdub: what do you think about the new trash icon ? (https://bugzilla.ubuntu.com/show_bug.cgi?id=6391)
<seb128> jdub: same about #6393
<ogra> Kamion: i dont think that the questionnaire the packages provide through debconf can be made HIG compliant without changing (od suppressing parts of) the questions....at least this will be a hadr task...
<jdub> seb128: i like the new trash icon, certainly fits in more than the old one - but we're going to have a new icon theme for hoary anyway :)
<ogra> s/od/or/
<jdub> seb128: we need to ask corey not to file so many insubstantial bugs
<seb128> yeah, he opened like 30 such bugs in 2 days
<seb128> dunno what to do with all these stuff
<Kamion> jdub: I would be happy for us to put effort into improving cdebconf's gtk UI, which needs to be done for the graphical installer anyway; a pygtk frontend would be pointless duplicated work over that though; and if we want to switch to a totally different debconf implementation in hoary+1, there's a lot of preparatory work that needs to be done now for hoary in order not to screw upgradability
<ogra> seb128: make him a MOTU to solve the bugs himself ;)
<Kamion> ogra: breaking the debconf protocol is out of the question
<ogra> Kamion: then we should stick with what we have ;)
<Kamion> well, that's what I favour
<seb128> ogra: no no no, I don't want him to slay the new icons
<Kamion> crap, uninstallable CD
<ogra> lol
<jamesh> seb128: tell him to take it up with jimmac
<jdub> Kamion: to do the installer properly, we can't rely on pure generated debconf frontend
<seb128> jamesh: that's an idea
<Kamion> jdub: yes, which is why custom widgets are on the GraphicalInstaller wiki page
<jordi> has anyone tried upgrading from woody to warty/hoary?
<jordi> is it possible without major problems?
<fabbione> jordi: yes
<fabbione> at least to woody
<jordi> to warty you mean?
<fabbione> and there is an Howto somewhere with the things that should be done manually to complete
<Kamion> jdub: frontend-independence remains very important, though
<fabbione> from woody to warty
<ogra> jordi: http://ubuntulinux.org/wiki/WartyUpgradeNotes
<jdub> Kamion: this is a bigger discussion than we can manage over irc
<jdub> Kamion: luckily, UDU is right at the beginning of the devel process ;)
<Kamion> well, we've had the discussion before :)
<jordi> ogra: thanks
<Kamion> jdub: what I'm saying is that if you want a pygtk frontend to debconf in the next release, you probably need a full python implementation of debconf, and (a) that's shitty pointless rewriting work :-) (b) if that is a requirement for hoary+1 then work must be done now, not after UDU
<jdub> Kamion: sounds insane. let's talk about the options at UDU.
<Kamion> ok
<ajmitch> jdub: is UDU near the time of the hoary+1 kickoff?
<enrico> fabbione: can you point me to the pages about the kernel team that have already  been created?
<fabbione> enrico: one it's in the team page
<jdub> ajmitch: it's right after lca, so two weeks after the final release of hoary
<Kamion> jdub: (admittedly, the urgency w.r.t. the graphical installer is alleviated by having all the questions in the first stage ...)
<fabbione> the other ones i GUESS in the wiki
<fabbione> but i didn't have time to check yet
<Kamion> so only one debconf implementation :)
<ajmitch> jdub: yeah, I just wasn't sure when the kickoff meeting was meant to be :)
<jdub> ajmitch: dunno, but UDU will be a big part of the kickoff ;)
<enrico> fabbione: ok, I'll look around
<enrico> can you point me at the team page if it's not in the wiki?
<ogra> http://www.ubuntulinux.org/wiki/KernelTeam
* Mithrandir finally gets around to ordering tickets for UDU
* rburton considers mailing jdub every hour to get a response
<jdub> yo rburton 
* ajmitch considers trying to save for tickets to UDU
<rburton> hey jdub
<ogra> rburton: use an sms gateway that sends notifications to him ;)
<jdub> rburton: i will now :)
<rburton> ogra: oh oh good plan.
<rburton> thom: you'll know jdub's mobile number
<rburton> ogra: i live in the GMT. HE WILL GET NO SLEEP
<rburton> (hm, remove "the")
<ogra>  rburton: hehe GTM+1 here
<rburton> maybe i should start the Distributed Annoy Jeff Scheme
<ajmitch> ogra: only 12 hours behind me :)
<ogra> rburton: lets package it and attach it to reportbug ;)
<jdub> rburton: it already exists
<jdub> rburton: it's called "GNOME"
<rburton> haha
* Kamion ups the urgency of getting better bandwidth; my Debian/Ubuntu mirror job is still running, having started seven hours ago
<ogra> lol
<rburton> Kamion: there is some company whose name i can't recall who will sell 8mb/s adsl for 30quid/month
<Kamion> are they on crack?
<rburton> possibly
<enrico> ogra: thanks
<ajmitch> rburton: not bad, I'm still waiting for my upgrade to 256Kbps
<rburton> it may have been 40/month
<rburton> but that's still obscene
<Treenaks> Kamion: that's (converted to euroa) a normal price here in .nl as well..
<Treenaks> Kamion: for 8mbit
<Kamion> Zen do 1mb/s at 30/month and I believe are not on crack
<Kamion> not on crack is more important to me than 8mb/s :)
<mjg59> Zen aren't /great/
<mjg59> I'm happier with Metronet than I was with Zen
<Kamion> oh yes, metronet was the one you mentioned
<jamesh> my ISP is offering 8mb/s now too
<jamesh> if they have their equipment installed at your exchange
<pitti> ogra: the patch should now be buffer overflow free
<pitti> ogra: however, I still spotted two memory leaks
* ajmitch feels like moving to .au to get decent bandwidth
<jamesh> AU$50 a month for 10G peek + 10G off peek
* Mithrandir pays somewhere around 30 quid for 2.6/768
<mjg59> ajmitch: That's sort of like cutting off your genitals in order to get better sexual stimulation
<Mithrandir> with no capping
<ajmitch> mjg59: well it'd be better than what I can get here
<ogra> pitti: where ?
<pitti> ogra: hmm, I just reply to your mail
<Mithrandir> ajmitch: move to Norway, land of free bandwidth and expensive beer. :P
* fabbione does the .11-0.2 buildd dance
<rburton> man, 23 for 512kbps is looking crap
<ogra> pitti: ok, thanks
<pitti> ogra: sent
<jamesh> the plan closest to 30 quid is 20G+20G (with rate limiting if you go over the limit)
<Treenaks> or the Netherlands, where you get uncapped 8mbit :)
<mjg59> 8mbit is available on exchanges which aren't purely BT now
<jamesh> I'm happy with rate limiting (some ISPs like Telstra charge 15c/MB excess, which adds up very quickly)
<mjg59> Which ought to include mine at some point this month
<jamesh> of course, telstra is offering 500MB plans ...
<YokoZar> How do I get CVS diff to acknowledge a deleted file?
<jamesh> YokoZar: get write access to the repository, and then do a "cvs rm filename" before doing the diff
<jamesh> YokoZar: alternatively append the output of "diff -u filename /dev/null" to the end of the patch
<YokoZar> ahh yeah that's what it is
<YokoZar> Thanks
<YokoZar> Err wait
<YokoZar> That'll just make a patch saying the file should be blank won't it?
<YokoZar> Will that delete it when committed?
<jamesh> by default, patch will remove files that are empty after patching 
<YokoZar> Ah ok that makes things easier.
<jamesh> the maintainer would need to run "cvs rm" when applying though, so you should probably mention that you deleted a file.
<fabbione> hmmm
<fabbione> elmo: is there something wrong with davis?
<fabbione> gcc keeps hanging in different places
<pitti> hmm, ENOELMO
* fabbione disables ccache
<fabbione> it was ccache
<fabbione> weird
<ogra> pitti: fixed and sent :)
<enrico> fabbione: what are the shortcomings of the current KernelTeam page, and what would you want those pages to accomplish?
<fabbione> very short coming = TODO list
<fabbione> next will be procedures/policies
<fabbione> the rest will be done by the new Team
<enrico> ok
<fabbione> i need to write the TODO before i leave
<fabbione> but i am sure Chuck already wrote something
<fabbione> dunno the page name tho
<ogra> http://www.ubuntulinux.org/wiki/KernelTeam
<enrico> I'm working on it
<fabbione> ogra: thanks
<pitti> ogra: you forgot g_free(key) :-(
<pitti> ogra: do it immediately after the g_utf8_strdown
<ogra> pitti: gah
<ogra> pitti: one second....
<enrico> fabbione: have a look at wiki.ubuntu.com/KernelTeam now: is that what you wanted?
<fabbione> checking now
<fabbione> enrico: yup!
<ogra> pitti: btw, the lag on hald startup (0 devices in lshal for a minute) let device-manager crash until there is at least one device
<fabbione> perhaps linking the Todo List in the right place...
<seb128> Mithrandir: here ?
<fabbione> but we can do that.. i guess..
<enrico> fabbione: I have no idea where the TODO list is...
<ogra> pitti: fixed, tested and sent...
<fabbione> right at the bottom in the subtopics :-)
<Mithrandir> seb128: pong
<enrico> oh, silly me
<Mithrandir> seb128: it seems evo segfaults before even _init has run
<seb128> Mithrandir: yeah, an user made the same comment
<enrico> fabbione: fixed
<seb128> Mithrandir: http://bugzilla.ximian.com/show_bug.cgi?id=71776 ... should I close the bug saying that's a build chain issue on the distro side ?
<fabbione> enrico: thanks!
<enrico> fabbione: work, FAQ, news and hot issues you'll take care of it yourselves
<fabbione> enrico: sure! you already did a lot
<pitti> ogra: okay, the patch is GO :-)
<fabbione> saving us plenty of time learning wiki ;)
<ogra> YAY YAY YAY !!!
<pitti> ogra: :-)
* ogra dances around extatically
<pitti> ogra: however, I'd like to accumulate your other patches before upload
<pitti> ogra: do you agree now that C just sucks? :-/
<ogra> pitti: sure, i'll send you the corrected procfs patch today...
<ogra> pitti: nah, if you know it like you do it cant ;)
<Mithrandir> seb128: wait
<pitti> ogra: it does suck
<pitti> ogra: just because I _usually_ know which errors you can make, I still do them from time to time
<ogra> pitti: if i wouldnt make this beginner mistakes it would be even better :)
<pitti> ogra: if one is used to python/perl string handling (or just about any other sane language), C is just insane...
<ogra> pitti: hehe
<ogra> pitti: wait for the dmidecode patch.....
<pitti> gulp
<ogra> pitti: g_pattern_match_simple  ....
<fabbione> thom: ?
<thom> yes?
<fabbione> thom: mind to clean the incoming dir on jackass from X sparc trash?
<ogra> pitti: but dmidecode will still need half a day or so, because i havent got the dmi-wrapper code in yet....
<pitti> ogra: sure, then just start with the procfs patch
<ogra> yup, thats nearly in shape....
<pitti> indeed that should be very similar to the cpuinfo patch
<ogra> pitti: they are the same....(/proc/cpuinfo)
<pitti> argh, yes
<ogra> pitti: even dmidecode will be similar, just more string pattern matching
<pitti> Hi elmo
<thom> fabbione: there's nothing in there?
<pitti> elmo: may I bomb you with some sync requests?
<fabbione> thom: ah ok.. probably katie REJECT did the clean too
<fabbione> thom: thanks for checking
<elmo> pitti: if you want
<pitti> elmo: mailman xtrlock xview sword (all from sid), please
<fabbione> hey elmo
<dholbach> lamont: ping
<fabbione> dholbach: he is asleep
<elmo> [NOT Updating - Modified]  mailman_2.1.5-5ubuntu1 (vs 2.1.5-6)
<elmo> pitti: okay to override?
<pitti> elmo: ack; same security fix as I did, and some RC bugs
<dholbach> fabbione: he can ping me back, but thanks :-)
<elmo> pitti: xview does seem to be in sid?
<pitti> er, yes?
<pitti> elmo: version 3.2p1.4-19
<elmo> oh, well that version's already in hoary universe
<elmo> (I meant xview doesn't seem to be newer in sid, sorry)
<elmo> hi fabbione
<fabbione> elmo: still at the dc?
<elmo> yeah
<fabbione> elmo: are you aware of any problems with ccache on davis hoary's chroot?
<fabbione> it keeps hanging
<fabbione> if i remove ccache it goes ok
<pitti> elmo: oops, ok
<pitti> elmo: I did not yet apt-get update today :-(
<elmo> fabbione: nope, not aware of anything like that - sorry
<fabbione> elmo: ok thanks
<dholbach> hi elmo, did you receive my mails? sorry for posting one of the twice, but i had the headache from hell last night and was kind of stupid
<elmo> dholbach: yes - I'll do it a bit later, I have to work on some servers at the moment
<enrico> elmo: https://docteam.ubuntu.com gives connection refused :(
<elmo> enrico: uh
<mvo_> any recommondations for the ppc live cd? should I use array 3.5? or daily?
<dholbach> elmo: alright, thanks
<amu> mvo_: daily 
<dholbach> hi mvo_
<elmo> enrico: fixed - checking why/how it happened
<enrico> elmo: thanks!
<mvo_> hi dholbach 
<mvo_> thanks amu 
<thom> mvo_: 4?
<thom> mvo_: array 4, even
<mvo_> thom: right :) 4 or daily? how good/bad is daily. I want to win a friend over from macos to ubuntu.
<thom> i'd use 4, i think
<elmo> I installed 4 on a G5 most-of-the-way yesterday, and it WFM
<elmo> and 4 on i386/amd64 all the way, and it also worked fine, FWIW
* mvo_ downloads array4 now
<fabbione> damn new gcc
* fabbione hates invalidating the ccache each time
<fabbione> thom: it's all your fault
<fabbione> you should have never told me about ccache
<thom> haggai: ping?
<thom> screw it, it reads ok to me
<haggai> thom: (pong)
<thom> haggai: new universe text on https://bugzilla.ubuntu.com/enter_bug.cgi?product=Ubuntu
<thom> look alright?
* haggai looks
<haggai> thom: hmm, reports are likely to get lost on -users.  Can we not have a package name such as universe in bugzilla, where all bugs should go?
<haggai> thom: or is that much more effort?
<Kamion> space after "Please note:"
<dholbach> thom: and write it in BOLD letters :-)
* Mithrandir blames daniels 
<thom> haggai: ogra asked  for it on -users
<thom> haggai: until malone is ready
<haggai> thom: ah, I'll take it up with him then. The text is fine by me then, thanks
<thom> cool
<thom> Kamion: fixed, thanks
<haggai> thom: do you know, would a universe package be a lot of effort (if orga was happy with it)?
<Kamion> the bug list on a universe package would get totally insane, surely
<haggai> yes, but would IMO be easier to track than random posts to -users
<thom> haggai: it'd be horrific i think; that's why ogra wants to wait for malone
<thom> which *should* be close
<haggai> hmmkay
<thom> dholbach: done
<Kamion> mvo_: is there any way to tell apt-cdrom to just totally ignore signature checking?
* fabbione sighs and fixes kernel doc build
<mvo_> Kamion: you mean, ignore any Release.gpg files it may find on the cd? I can add this, what would you use it for?
<dholbach> thom: i'd have used more bold text - but it's ok :-)
<Kamion> mvo_: I just want to be able to do it optionally, for when (as right now) I'm working on a deliberately hacked CD and therefore the Release.gpg sig is broken
<Kamion> at the moment it is excruciatingly painful to attempt to modify the install CD :(
<mvo_> Kamion: file a bug about it please and I'll add the option
<Kamion> mvo_: ok
<Treenaks> hmmm... why is there no python2.4-serial
<Kamion> deb http://gb.archive.ubuntu.com/ubuntu/ hoary main restricted
<Kamion> deb-src http://gb.archive.ubuntu.com/ubuntu/ hoary main restricted
<Kamion> rock
<elmo> woo
<Kamion> still an issue with the first-stage debconf db being visible while asking second-stage questions from the first stage, though
<Kamion> (as in, it isn't)
<pitti> cool, de.archive.ubuntu.com works as well
<Kamion> so it will take a little more time to make that work properly
<pitti> bah, it's the same IP
<Kamion> pitti: pittis-private-mirror.archive.ubuntu.com works too
<pitti> darn, I thougt it was similar to ftp.de.debian.org
<Kamion> it can be eventually; us.archive.ubuntu.com is already distinct
<dholbach> is kubuntu-base == ubutun-base?
<Kamion> dholbach: yes; kubuntu-base should not exist, in fact, that's a bug I think
<Kamion> since debootstrap totally ignores it :)
<dholbach> that#s what i thought
<pitti> aaargh
<Kamion> amu: ^--
<pitti> haggai: ping
<dholbach> what are the plans on those kubuntu-* packages?
<pitti> doko: ping
<Kamion> dholbach: they'll be installed by Kubuntu CDs
<dholbach> ah kubuntu cds... i see
<dholbach> thanks Kamion
<amu> Kamion: have to check 
<doko> pitti: pong
<haggai> pitti: pong
<sivang> Morning all!
<dholbach> hellas sivang!
<sivang> dholbach: hey daniel, what's up?
<sivang> hey seb128 
<dholbach> dholbach: not much... working on my thesis - how are you?
<seb128> hi sivang 
<dholbach> sivang: not much... working on my thesis - how are you?
<pitti> Hi sivang
<sivang> dholbach: fine, thanks.
<pitti> dholbach: hah, you are doing that, too! talking to yourself :-) 
<dholbach> :-)
<amu> dholbach: debootstrap --exclude=udev,kubuntu-base hoary $ROOT $MIRROR
<sivang> Hey pitti, what's up?
<dholbach> pitti: it's terrible - i'm already thinking about caffeine injections
<dholbach> amu: you exclude udev?
<pitti> sivang: for(;;) { fix_security_bug(); }
<sivang> pitti: hehe :)
<sivang> pitti: Ok, then that means you are pretty busy :)
<pitti> sivang: what does your second g-s-t patch do? (Administrator profile)
<Kamion> amu: hm, you actually need a different base system?
<amu> Kamion: right, -base is desktop independ, is it a real problem to have both? 
<pitti> sivang: I did not yet upload your first patch since I wait for that one
<amu> Kamion: no the base is also fine for me
<Kamion> amu: yes, it is, kubuntu-base cannot be used without a different debootstrap; I did mention this in the meeting
<Kamion> amu: if you want that, it can be done, but I think in that case we would really want to fix our base system so that it works for both, since that's a lot less work :)
<Kamion> of course, some derivatives will need a different base system, so I guess the work will have to be done eventually
<Kamion> I was hoping to postpone it though :)
<sivang> pitti: I am going to fix the other one two now, and make a new 2 pkgs (since the frontends and the backends are now seperate pkgs)
<sivang> pitti: (I already did the fix I told you about wrt rebranching the uid change code so it would get even executed when we are modifying an existing user)
<Kamion> amu: (well, just the presence of kubuntu-base doesn't break anything as such - kinda redundant though)
<amu> Kamion: i think the base should be desktop independent, at the moment it is, i've no idea how it will be in feature, no problem, i can change my package  
<Kamion> amu: yeah, I was kinda wondering about your --exclude=udev above; if udev really doesn't work for you we do need to fix that
<seb128> jdub: what do you think about yelp 2.6/2.9 ?
<sivang> pitti: err, correction, so it WONT get executed when modifying an existing user :)
<Mithrandir> I assume we don't have any real snapshotting of the archive so I can ask for the archive on a given date?
<amu> Kamion: i'll try it at weekend 
<Mithrandir> (apart from ripping apart daily cds or something)
<Mithrandir> Kamion: do we have daily images more than a week back?
<Kamion> Mithrandir: no, sorry
<jdub> seb128: let's ship 2.10
<Kamion> Mithrandir: they get purged after four days or so
<jdub> seb128: a11y is not a high priority for us atm
<Kamion> Mithrandir: there's morgue.ubuntu.com though, for old packages in general?
<jdub> seb128: i think bill is being pretty unreasonable about that whole problem
<jdub> seb128: sun ship mozilla, and it's not as if it's accessible yet
<Mithrandir> Kamion: I would _really_ want something debootstrappable; _something_ has changed which has broken evolution, and evo links to about 90 libraries, so it's painful to debug.
<jdub> sun shining from orifices, etc.
<Mithrandir> Kamion: it seems to SIGFPE before getting to _init even
<seb128> jdub: k
<Kamion> Mithrandir: try old array cds? we keep those
<Mithrandir> Kamion: yeah, I'll do that
<Mithrandir> oh well, I do at least get around 2MB/sec to cdimage.u.c now
<Kamion> elmo: did you ever track down why apt-cdrom was hanging yesterday?
<elmo> Kamion: yeah, the cable was unplugged :)
<elmo> sorry, maybe I didn't make the link explicit; that's why I was asking for a "you don't have a network cable, you spethial muppet" prompt in the installer
<elmo> s/cable/link/
<fabbione> FLY CONCORDIA!
<fabbione> elmo: please be careful not to unplug concordia 
<fabbione> i am at the end of a fix for FBTBFS
<fabbione> FTBFS
<mantiena> Hi all
<amu> Kamion: could you please restart germinate
<rcaskey_> morning all
<rcaskey_> what's germinate?
<sivang> rcaskey_: I think it's the program the "expands" seeds into pkgs
<sivang> (IIRC,AFAIK)
<amu> rcaskey_: it generate a output ex. which you find at http://people.ubuntulinux.org/~cjwatson/germinate-hoary-output/
<Kamion> also see http://www.ubuntu.com/wiki/SeedManagement
<Kamion> amu: running
<amu> Kamion: thx
<sivang> amu: that's basically seed packages and their dependencies right?
<mantiena> anyone could tell me where to look for ubuntu-installer documentation ? I wanna to write one component, which simply copies files from one partition to another instead of installing new system from debian packages
<lamont> good morning world
<thom> hey lamont
<dholbach> hai lamont
<dholbach> lamont: i just saw that mplayer could do with just a recompile (because of the libavcodec-transition), but even as a MOTU i couldnt upload it, so would you do it, if you find the time?
<dholbach> (not that i use it, but i noticed... :-))
<fabbione> ok world
<fabbione> 2.6.11-0.2 is on the way to the archive
* lamont has about 30 seconds until he is supposed to run out the door.. but then the girls aren't quite ready yet.
<fabbione> and i am off 
<fabbione> cya sometime on monday
<pitti> see you fabbione!
<pitti> fabbione: have a nice weekend
<fabbione> from Ruined people's planet :)
<Treenaks> fabbione: cya
<lamont> later fabbione 
<fabbione> pitti: tomorrow i am getting married...
<fabbione> nice and married don't fit in the same weekend :)
<Treenaks> fabbione: good luck then :)
<pitti> fabbione: optimist...
<fabbione> cya
<lamont> dholbach: libavcodec transitioned this week, eh?
* fabbione &
<dholbach> lamont: seems so
<dholbach> fabbione: all the best! :-)
<pitti> fabbione: have fun at the party
* pitti waves to fabbione 
<lamont> dholbach: 'k
<lamont> later fabbione 
<rcaskey_> btw Kamion, sivang, thanks for the explination
* rcaskey_ has been playing with Apple Remote Desktop 2
<ogra> fabbione: good luck :)
<sivang> fabbione: congretulations :)
<thom> darklight: have fun
<thom> uh, fabbione 
<thom> even
<Kamion> amu: (finished a while ago)
<Kamion> fabbione: have fun :)
<Kamion> mantiena: you'd have to replace base-installer, I guess
* thom finishes his mad wiring spree
* lamont sympathizes with thom, but runs out the door to take kids to school
<Treenaks> thom: what/who did you wire?
<thom> Treenaks: my ia64, sparc and alpha
<mantiena> Kamion, I think too, amu you agree with us ?
<Kamion> well actually I know you either have to replace base-installer or significantly hack it internally
<Kamion> the latter might be easier, not sure
<ogra> pitti: procfs patch is in your inbox
<amu> Kamion: think, it's a kind of hack
<Kamion> amu: hm?
<elmo> what's with the "APPROVED" newness in xscreensaver?  it sounds like something from some 80's sci-fi film
<elmo> and god how I hate how xscreensaver unconditionally enables new hacks
<ogra>  elmo: hope you dont mean my lock window hack....
<thom> ogra: the modes in xscreensaver are called hacks
<sivang> ogra: how do I get your screen saver? ;-)
<ogra> elmo: btw, a sync of ion3 would make a lot users happy (regarding the flood of requests in my inbox)
<ogra> argh...to slow
<thom> yow; that APPROVED thing is terrifying indeed
<ogra> sivang: make sure your system is up to date and lock your screen....
<sivang> ogra: wowow!
<Treenaks> ogra: yeah, that rocks :)
<sivang> ogra: so coool
<ogra> sivang: i patched the password dialog....didnt write a xss
<sivang> ogra: how did you make it look so good :)
<sivang> ogra: yeah I recall you showed bits of code that looked like chineese to me at mataro :)
<ogra> sivang: the beautification was rather simple....
<Treenaks> sivang: ah, jwz-code :P
<thom> ogra: are you planning to leave the APPROVED thing? it's rather in-your-face
<Treenaks> Mithrandir: I think I'll have a working, very very basic dbus client/server with GPS stuff tonight
<ogra> sivang: i found a patch to add xpm to the window (thats what you saw in mataro)
<thom> besides that, good work
<sivang> ogra: ah cool
<ogra> sivang: the real hard stuff was to rip out every sign of X fonts and inject xft there instead
<Mithrandir> Treenaks: yay!
<ogra> elmo: btw, a sync of ion3 would make a lot users happy (regarding the flood of requests in my inbox)
<elmo> and that's why I hate it.. 'cos 3d's so often randomly broken.  meh.
<Treenaks> Mithrandir: I was thinking of a small command-line tool "whereami", analogous to "whoami"
<sivang> Treenaks: jwz code?
<elmo> ogra: I don't want to sync stuff just because it would make people happy.  if you've checked it and approve the sync, then please just ask for it
<Treenaks> sivang: j/k
<Treenaks> sivang: jwz is xscreensaver upstream
<ogra> thom: depends on the time i have left after i finished the hwdb-client work....
<ogra> elmo: ok, then please sync it :)
<Mithrandir> Treenaks: whereami is already a package.
<Treenaks> Mithrandir: hm..
<Treenaks> Mithrandir: then I need a better name for the demo command-line client
<Mithrandir> "where" ?
<Treenaks> Mithrandir: hm.. point :)
<Mithrandir> or gpswhere or something
<Treenaks> I'll think of something ;)
<elmo> ogra: done
<ogra> elmo: thanks :) 
<thom> lamont: how's the ia64 installer looking?
<ogra> thom: the APPROVED thing.... i was planning to make the white overlay behind the font a bit transparent, so the big font wont matter this much anymore....
<thom> ogra: i'm not sure why it needs to say anything if you succeed
<mantiena> amu, I think it would be wise to use some usefull functions from base-installer udeb, like check_target or update_progress in liveCD installer, what you think ?
<ogra> thom: the original dialog does thos too, but instead of an overlay it responds in the password input field....this would be an option too...but as i said, everything depends on hwdb, which is my prio 1
<thom> ogra: nod
<Kamion> mantiena: er, ok, I didn't know this was the live CD installer, I think this requires rather careful design rather than hacking if you plan to use d-i for it, but I'm going for lunch now
<mantiena> Kaloz, hehe, tell me when you come back
<Kaloz> mantiena: i will be back in a half an hour or so... i'm mostly gone due that i don't have mobo :p
* Kamion suspects mantiena meant me
<Kaloz> oh, okay
<Kaloz> :P
<mantiena> Kamion, yes, I mean you
<mantiena> Kaloz, sorry, XChat "improved" completion with tab in some 2.x version...
<lamont> thom: was testing things with the livecd, I'll see about an install CD today
<lamont> but ISTR that the install CD was working, except for maybe the final step.  livecd wanted help
<thom> lamont: well, i can test livecd if that is more useful?
<lamont> thom: I'm 20% of the way through the live ISO download...  if you wanted to test the install CD, that'd be way cool
<thom> lamont: daily?
<lamont> yeah
<lamont> all the others have known b0rkage
<thom> k
* netjoined: irc.freenode.net -> benford.freenode.net
* lamont wanders off for a few minutes waiting for his download
<seb128> lamont: could you kick lilypond build ?
<Kamion> mdz: I've changed the boot name in the live CD's isolinux.cfg from 'linux' to 'live', to better support install/live DVDs
<jdub> :-)
<thom> ber, another hour for ia64 install cd
<Kamion> thom: has the apache thing on cdimage.ubuntu.com been fixed yet? if I start building install/live DVDs now, we'll definitely hit the 2GB limit on all architectures big-style
<thom> no, working on it currently
<thom> i'll let y ou know
<Kamion> ok, thanks
<pitti> ogra: why do you need config.h in procfs_info.h? (well, it doesn't hurt, though)
<mantiena> Kamion, so, you have some  time to help me design liveCD installer ? I'm main developer of Baltix, which is debian based installable live CD, which is very popular in Lithuania (selled by some computers selling companies with new computers)
<mantiena> Until now Baltix uses Morphix framework, but I think, that ubuntu framework is better
<jdub> mantiena: cool :)
<mantiena> I just need a possibility to install to hard disk
<Kamion> mantiena: ok, so the question is whether d-i is the right thing to use
<Kamion> the first question, at least
<pitti> ogra: Ahem: "int fds[0] ;"
<Treenaks> pitti: nice one
<Kamion> currently, d-i's components really like to run in their own totally guaranteed environment; I wonder if you're prepared to deal with the issues that would result from trying to run them outside of that
<Kamion> if not, then it might be easier to write something that just blats the contents of the live CD's ramdisk onto a disk and fiddles with a few files until it looks right
<Kamion> which I guess is roughly where I came in :)
<Kamion> I guess it's worth noting that the Ubuntu live CD already runs much of d-i (although not all of it) in the process of bringing up the live environment
<Kamion> you'll have to deal with partitioning somehow, but given that you've got GNOME available you almost certainly shouldn't be attempting to use the installer's partitioner right now anyway
<mantiena> Kamion, I talked with amu and we think, that d-i is good for this task
<Kamion> what are your reasons?
<mantiena> Kamion, main reasons are, that liveCD installer does most same tasks like debian-installer
<dholbach> bbl
<Kamion> all the hardware detection has already been done by the time the live installer would start
<Kamion> the tasks that remain are:
<Kamion>  - partitioning (you'd want to use a graphical interface, not d-i's partman)
<Kamion>  - actually putting the files on the disk (works in a completely different way to d-i, is a single stage rather than two stages (base and desktop))
<ogra> pitti: these two are the only errors you found ?
<Kamion>  - bits like timezone configuration and apt configuration (some done already, others I can see you having to do yourself)
<pitti> ogra: some more, I mailed you
<ogra> pitti: thanks :)
<pitti> no worries :-)
<ogra> pitti: sorry for the lag, i was downstairs in the lab
<Kamion>  - final cleanup pre-reboot (much of this is already done by casper, and I'm guessing the rest will be different since you won't want to run base-config post-reboot)
<pitti> ogra: if there is any security bug in this code after the upload, I buy you a box of beer :-)
<Kamion> so, while I can see the initial appeal of using d-i as the live installer, I have great difficulty seeing how it'd actually be practical in reality
<ogra> hehe
<Kamion> at least not without some pretty major reengineering
<ogra> pitti: i'll not try to introduce a hidden one ;)
<mantiena> Kamion, don't forget bootloader installing ;) I'm using morphixinstaller + partitionmorpher or gparted now for these tasks, but lots of morphixinstaller code is crap, and I should rewrite lots of components, for example I already included os-prober from debian-installer into morphixinstaller ;)
<Kamion> mantiena: ok, that's true; that's the only top-level component I can see you including more or less unmodified
<Kamion> mantiena: but really I think you will want a totally new framework to wrap around those few components
<mantiena> Kamion, there are already working debian-installer components for all liveCD installer tasks, except file copying
<Kamion> mantiena: do you have the framework (i.e. main-menu and udebs) working?
<Kamion> mantiena: and are you using udebs pretty much as they stand, or repackaging?
<ogra> pitti: afaik the info.bus=unknown is needed if you have no bus to assign to
<mantiena> Kamion, I'm only in planing phase ;)
<ogra> pitti: but i'd be happy to be proven wrong ;)
<pitti> ogra: I really don't know it; if it's necessary, just keep it
<pitti> oh, phone
<ogra> k
<mantiena> Kamion, amu told me, that it's 15 minutes job to make liveCD installer from debian-installer components
<Kamion> mantiena: ok, then, I think I'd be inclined to write something new rather than a hack to base-installer; only a very few utility functions are useful, and those can safely be copied
<Kamion> mantiena: I am amazed, and would love to see that demonstrated
<Kamion> are you planning to reboot into the installer, or run it from GNOME?
<ogra> does anyone here know a case in linux where procfs is mounted but cpuinfo or meminfo are not there ?
<Kamion> or KDE, or whatever
<mantiena> Kamion, I too, but amu doesn't have free time for this :(
<Kamion> mantiena: I suppose udpkg *might* work on a live system, maybe
<Kamion> don't try it on one you intend to use afterwards, but that concern doesn't apply to the live CD ;)
<Kamion> but you wouldn't be able to install cdebconf
<Kamion> (it's not coinstallable with debconf)
<mantiena> Kamion, so, I think it would be easier to come back into d-i mode ;)
<Kamion> so you would have to get over cdebconf/debconf incompatibilities, like the lack of progress bars in debconf
<Kamion> mantiena: you can't without rebooting
<pitti> ogra: just exit the function gracefully if fopen() returns NULL
<Gagatan> Kamion: gotten any further with kickstarting?
<Kamion> the d-i initrd has gone away by that point
<pitti> ogra: instead of assuming anything :-)
<ogra> pitti: okiedokie :)
<Kamion> Gagatan: not in the last couple of days, I have several other things I'm responsible for and working on concurrently
<mantiena> Kamion, why ?
<Kamion> mantiena: I suppose you might be able to construct a little d-i system in a chroot, and run it from there, rather than attempting to run it in the base live environment
<Kamion> mantiena: I think that would be by far the safest option
<Gagatan> Kamion: are there any notes on the initial work/thoughts I can read?
<Kamion> Gagatan: only in source package form, I'm afraid
<Kamion> Gagatan: (kickseed and system-config-kickstart, both in hoary)
<Kamion> mantiena: why has it gone away? to save memory, I think
<Kamion> mantiena: ask mdz about that @_
<Kamion> :)
<Gagatan> Kamion: is there a cvs/svn-repostory for this?
<mantiena> Kamion, ok
<Kamion> Gagatan: kickseed is in arch (colin.watson@canonical.com--2005/kickseed--mainline--0, http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005); the system-config-kickstart work I've done is not
<Gagatan> ok
<Kamion> but the latter is uninteresting from your point of view, I think
<lamont> seb128: kicked
<mantiena> Kamion, you are d-i developer ?
<Kamion> mantiena: yes
<ogra> pitti: procfs_refresh_info doesnt need to be exported ? how do i act if i want to poll the data to have constant updates ? if i call procfs_info_init, it will create 2 new devices on every poll
<mantiena> Kamion, respect ;)
<Kamion> thank you :)
<ogra> pitti: that was the reason why i diverted the two functions at all....
<pitti> ogra: phone
* lamont watches his livecd download bounce between 400kbps and 5mbps, at least according to rsync
<ogra> pitti ok.... s/diverted/separated/
<mantiena> Kamion, for my goals it's better to run installer from GNOME, for example in chroot, as you told, but I don't know how to start it and how to deal with devfs problem :(
<Kamion> run udev in the chroot with devfs rules?
<Kamion> hoary's installer no longer requires actual devfs, merely devfs paths
<mantiena> hehe, nice to hear ;)
<seb128> lamont: thanks
<seb128> Mithrandir: around ?
<pitti> ogra: why would you want to poll /proc/cpuinfo?
<Kamion> the devfs paths can probably go away eventually but that's a somewhat longer-term piece of work; in particular some of the bootloader installers do stuff like walking over /dev/discs, which is very convenient
<pitti> ogra: it shouldn't change
<ogra> pitti: sure it does... meminfo too
<pitti> ogra: whoa, my cpu changes while the computer is running?
<ogra> pitti: cpuinfo only shows the mhz value 
<Kamion> pitti: cpu frequency scaling
<pitti> ah, ok
<ogra> pitti: ... that was set when hald was started
<pitti> ogra: okay, that's a valid reason
<ogra> pitti: the same goes for meminfo.....
<pitti> ogra: however, I did not see any external reference to this function
<pitti> ogra: so if you want to poll for it, don't you need to hook it into some timer ?
<ogra> pitti: even polling is not on my list yet, it would be nice to have the function for it in place i thought ;)
<pitti> ok
<ogra> pitti: something i can play with hoary+1 then 
<pitti> ogra: okay, fine for me
<ogra> good...
<mantiena> Kamion, I noticed, that udev-udeb_0.050-3ubuntu4_i386.udeb uses udev with devfs rules as default, I'm right ?
<Kamion> mantiena: yes
<lamont> ion3 needs build-dep love for xorg
<ogra> lamont: i'm on it
<ogra> lamont: its just a build-dep on libxinerama-dev
<lamont> woot
<lamont> Totals by arch:  amd64:16 i386:13 powerpc:12 ia64:69 
<lamont> ia64 wins by a mile
<lamont> Kamion: shame we can't tell your script to ignore OO.o/ia64
<Kamion> lamont: well, they *are* uninstallable ...
<lamont> on the bright side, I only had to download 175MB to freshen the livecd..  which brought my bandwidth usage right back to on-track for barely staying under quota again this month. :-)
<lamont> Kamion: yeah, but we know that... and they clutter up the report. :-)
<lamont> and it's not like we're going to _FIX_ it...
<Kamion> you guys like your stats, I guess ;)
<lamont> if I uploaded oo.o just to /Archit/s/any/i386 powerpc amd64/, I'd have to hunt myself down and kill me.
<Kamion> lamont: at least the first step wouldn't take so long
<lamont> but it would be a slow and painful death, I can promise you that... :-)
<lamont> I could always upload an ia64-openoffice.org package that was nothing but meta data... :-)
<lamont> but then mdz would hunt me down and kill me.
<thom> lamont: just fix ooo2 to work everywhere and then we can use that ;-)
<daniels> thom: hahahahaa
<lamont> thom: sure - send me your patch.
<thom> lamont: qsee, that's why i said "fix" not "apply my patch"
<lamont> heh
<pitti> lamont: btw, nice topic; will a language-support dependency "Depends: oo.o [i386 powerpc amd64 sparc] " do what we want?
<lamont> thom, even apache is better than oo.o :-)
<Kamion> pitti: no, that doesn't work
<Kamion> pitti: you have to generate the Depends: field in debian/rules for that (e.g. use substvars)
<pitti> Kamion: but the package is arch-all
* thom throws rocks at lamont
<Kamion> pitti: but the []  syntax is not understood in Depends:
<pitti> hmm, what a pity
<lamont> Kamion: it's starting to sound like an oo.o upload to fix the depends is in order maybe?
<lamont> bah - same issue there
<lamont> pitti's issue is all depends all depends partially-populated-arch
<pitti> lamont: oh, right. that means ia64 would have just an empty oo.o metapackage?
<lamont> pitti: in which case, I may as well upload a dummy ia64-oo.o package that just provides the dummy metapackages
<lamont> because it's vile, sick, evil and wrong any way you go at it.
<lamont> <Kamion> pitti: but the []  syntax is not understood in Depends:
<pitti> lamont: hmm, an integration into the main oo.o package sounds better to me (although an upload just for that is kind of a waste)
<lamont> can we fix that? :-)
<lamont> pitti: and I already promised to hunt myself down and kill me if I do it...
<Kamion> lamont: -> Keybuk ;)
<pitti> lamont: hmm, but whether we do the per-arch dep in OO.o metapacakge or in l-s-* is not really a difference :-(
<lamont> Keybuk: please support [arch]  in Depends:   kthxbye
<lamont> pitti: how large are the l-s-* packages?
<pitti> tiny
<pitti> just empty metapackages
<pitti> same as openoffice.org
<lamont> yeah - but your source is smaller...
<Keybuk> lamont: substvars, kthxbye
<pitti> but oo.o is easier to fix since it comes from a normal source package, not from an autogenerated one
<lamont> couldn't they all be one source package that autogenerated boatloads of binaries?
<Kamion> Keybuk: EARCHALL
<lupus_> daniels, #include <X11/Xmu/WinUtil.h> in which package is that file? I need to install it
<pitti> lamont: right, but this overthrows half of langpack-o-matic :-(
<lupus_> gnome-utils seems to not check if the file is installed while it is needed so is there a .pc file for it?
<lamont> lupus_: libxmu-dev, it says here
<pitti> lamont: if nothing else helps, I will extend it to support per-arch deps, though
<Kamion> wouldn't be so bad in l-s-* as it would be in l-p-*
<pitti> *sigh*
<lamont> pitti: lets kick it around with mdz and see which option is considered least evill
<pitti> ok
<pitti> lamont: "not break big things at friday evening" :-)
<lamont> although I think it's varying shades from 99.9 to 99.99% black.. :-)
<daniels> lupus_: livxmu-dev, yes
<daniels> er, libxmu-dev
<lamont> daniels: just wasn't sure how recent my Contents file was...
<Kamion> Keybuk: (it only gets built once, so substvars don't help)
<Keybuk> you know, I don't actually think there's a bug filed with that particular use case
<elmo> eh, I'm sure there is
<elmo> s/is/must be/
* lamont grumbles./
<lamont> Starting Ubuntu
<lamont> exec of '/sbin/init' failed: Input/output error
<lamont> System halted
<lamont> thom: if you want to try a livecd, you need the magic invocation
<thom> lamont: i'm grabbing install cd
<lamont> casper/enable=true casper-udeb/snapshot/backing-file=/cdrom/casper/filesystem.cloop
<mantiena> Kamion, could you tell me how to start a debian-installer from chroot ? I'm not d-i guru, only trying to become d-i guru ;)
<zul_> fabbione: ping sorry i was in meetings all morning but i did get 2.6.11
<zul> bah..now i have another meeting
<Kamion> mantiena: check out the 'demo' target in the debian-installer source package (build/Makefile) and follow what it does
<Kamion> mdz: hm, do you actually use archive-copier's prebaseconfig stuff in casper any more? I hope not, since I merged the prebaseconfig script into its postinst :)
<lamont> Kamion: why isn't casper-udeb/snapshot/backing-file defaulted to the right value?
<Kamion> lamont: 'cos the location's controlled by debian-cd ...
<Kamion> I guess defaulting it would be OK, though
<mantiena> Kamion, thank you very much
<Kamion> mdz: I'm pretty sure you aren't, actually, so removing it from the casper seed (it's causing germinate problems to have it there without anything that provides mounted-partitions)
<thom> and finally the ia64 cd finishes downloading
* thom burns
<Kamion> mdz: you're not using prebaseconfig either any more, are you?
<snaggen> I'm trying to set up an apt archive using apt-ftparchive release but apt-get update complains about the releasefile not containing MD5Sum entry. Any ideas? (I have generated a Packages and a Source file, and the Release file contains MD5Sums for all three files).
<Kamion> snaggen: in which directory did you run apt-ftparchive release?
<snaggen> I ran it in the same dir as the packages and the Package and Source file.
<Kamion> in Ubuntu, the release file goes in dists/hoary/Release but the Packages files are in dists/hoary/main/binary-$ARCH/Packages
<Kamion> so if you have any kind of hierarchy like that then you'll need to adjust to cope ...
<snaggen> Well I have set up a dir ubuntu on my own web, then I just dropped all files in that dir
<snaggen> No file hirarchy at all
<lamont> Kamion: my fingers get tired, you see...
<mantiena> Kamion: I put summary of our discusion into http://www.gnoppix.org/wiki/index.php/LiveCDInstaller ;)
<mdz> Kamion: unless archive-copier itself created a /usr/lib/casper symlink, I wasn't using it
<mdz> (likewise for everything else)
<pitti> Morning mdz
<mdz> morning
<pitti> mdz: new hpoj ready for you to be tested :-)
<Kamion> mdz: excellent
<thom> lamont: i assume an ia64 will boot off cd without too much coercion?
<Kamion> mdz: removing prebaseconfig from casper seed too, then
<mdz> sounds fine
<lamont> thom: almost none: tell it to go into the efi loader or whatever
<lamont> then find the cd in the list
<mantiena> hi mdz 
<lamont> fs0: (s/0/whatever/)
<lamont> elilo
<mdz> hi
<thom> lamont: cool, lets see how well this works
<sivang> hi mdz 
<dholbach> bye everyone... i'm off
<thom> well, no framebuffer but at least it boots
<mantiena> mdz, you are main live CD developer ?
<lamont> mdz: so the ia64 livecd gets up to the point where it fails to exec /sbin/init... :-(
<mdz> mantiena: yes
<mdz> lamont: fascinating
<lamont> mdz: that's one word for it.
<mdz> lamont: if you either bump the priority down to low, or switch consoles and SIGSTOP it before it does that, you should be able to poke around the system on /target and see what's wrong
<lamont> mdz: and that's assuming that I didn't typo 'casper/enable=true casper-udeb/snapshot/backing-file=/cdrom/casper/filesystem.cloop'
<mdz> it would have failed earlier if you typo'd that
<lamont> mdz: I'll add that to the list for 'after the patch review'
<lamont> kewl;
<Kamion> I'll be working tonight, but may be offline for a good deal of it; babysitting
<mantiena> mdz, I think we should increase ramdisk_size from 65536 to at least 131072
<mantiena> because ubuntu live CD crashes very often if ramdisk_size is 64Mb
<mdz> mantiena: I agree, but not for that reason
<lamont> mdz: maybe let the ramdisk have 1/2 of memory?
<mdz> because it doesn't crash very often for me
<mdz> it doesn't crash at all
<Kamion> well, I can bump it up now
<mdz> lamont: unfortunately it's set on the kernel command line, so we don't know
<mdz> but
<mdz> I think it's in units of virtual memory
* lamont makes a note to not test new livecd's in less than 256MB systems
<mdz> so we could set it to a gig if we wanted
<lamont> ah, that's not so bad then
<mdz> and then I can limit the actual usage inside casper easily if desired
<Kamion> lamont: oh, hm, have you set ramdisk_size on the command line too?
<mantiena> mdz, how long do you work from CD ?
<Kamion> lamont: you may need to do so
<mdz> mantiena: it doesn't matter how long you work, but rather what you do
<lamont> Kamion: would having it too small cause /sbin/init's exec to fail???
<mdz> installing packages uses a lot of space, e.g.
<Kamion> lamont: might cause the cloop not to be unpacked properly I guess, dunno
<mdz> lamont: entirely possible
<mdz> if it's too small, the preparatory stuff could fill the ramdisk
<mdz> though it seems unlikely
<mdz> now that the locale stuff is pre-generated, it shouldn't take much space
<Kamion> mantiena: I've bumped the ramdisk size up to 131072 for now (not on ia64 yet though, haven't made the changes to debian-installer to allow debian-cd to control that)
<mdz> what's the default ramdisk size?
<lamont> Kamion: so add 'ramdisk_size=131072'?
<elmo> binaries are a lot bigger for ia64, fwiw
<Kamion> lamont: yeah
<elmo> (IIRC)
<mantiena> mdz, yes, for example I can crash ubuntu live CD in 5 minutes, just uncoment universe from /etc/apt/sources.list and do apt-get update && apt-get install some packages
<mdz> last I checked, the total size utilization going all the way into GNOME startup was about 6M
<lamont> mantiena: that's unsurprising
<mdz> mantiena: then don't do that
<mantiena> mdz, so, ubuntu is about "dont do that" ? :-P
<mdz> mantiena: no, just this particular conversation
<mantiena> mdz, with morphix live CD I can do whatever I want
<mantiena> and it doesn't crash
* lamont waits for post-hoary-release, when people are apt-get upgrading the livecd to hoary+1
<mdz> mantiena: that is funny
<mdz> because mini_fo causes crashes for hundreds of Ubuntu users
<mdz> which is why we don't use it
<mdz> if you run apt-get update on the Ubuntu 4.10 live CD, which is based on Morphix, the kernel panics randomly
<mantiena> mdz, hehe, Morphix uses minifo only in new beta versions ;)
<mdz> mantiena: and what does it use in stable versions?
<mdz> symlink trees, I suppose
<mantiena> mdz, and Ubuntu 4.10 is based on very unstable Morphix base version, you are right, it crashes very often
<mdz> there are many problems with symlink trees
<mantiena> mdz, older morphix versions (0.4-1x) uses transluency, not symlink trees
<thom> configuring postfix... this looks pretty good
<lamont> thom: the last run I know of got right up to making the disk bootable and was missing something critical at that point.
<lamont> mdz: so your thoughts on the language-support-en/oo.o/ia64 issue?
<mdz> lamont: my thoughts are that ia64 is not making the cut :-/
<mdz> is it installable, apart from the oo.o issue?
<lamont> mdz: should we (a) make language-support-en be Arch: any, or (b) provide dummy meta-only oo.o packages for ia64
<lamont> mdz: well, we know that. :-)
<lamont> (c): just not include ubuntu-live on ia64
<mdz> I don't really want either of us to spend cycles on it at this point
<lamont> or change ubuntu-live to not include l-s-* on ia64
* lamont isn
<lamont> 't
* lamont switches to the ia64 keyboard when the computer tells him to take a typing break, but ignores it otherwise
<mdz> Kamion: ramdisk_size=1048576 works fine on my 256M test system
<mdz> Kamion: let's use that
<thom> lamont: yeah, it bombs out in the elilo installer
<lamont> thom: yeah - that's it
<thom> how do i install a bootloader manually?
<lamont> hrm... monitor on the ia64 box can't handle that screenrate
<elmo> thom: with great pain and suffering
<elmo> ia64 boot loaders are ritualisticly stoopid
<thom> oh, goody
<elmo> "yeah, we're Intel's cutting edge, wave of the future, etc. platform.  To prove this we're gonna use the keenest, most leet filesystem EVAH for our bootloader.  Yes, that's right.. FAT!  woo woo"
<lamont> mdz: fwiw, livecd boots with ramdisk_size=262144 on ia64
<thom> rofl
<elmo> freaks
<lamont> thom: modprobe vfat, make sure that's there, 
<lamont> and then it's either a seed issue, or something else :-)
<thom> how can people use bastard us keyboards? they're more horrible than french ones
<thom> lamont: it's there
* lamont has no clue how to actually do that step manually...
* lamont grabs food, and then plans to ignore irc for several hours while he works on patch-diffs
<thom> um, oh good
<mantiena> btw, where are liveCD's CVS or SVN ? I don't find this info in ubuntu.com :(
<mdz> mantiena: there isn't any CVS or SVN; it is all in the Ubuntu package archive
<mantiena> :(
<mdz> ?
<mdz> mantiena: is there something you would like to do which is more difficult this way?
<mantiena> so where Kamion bumped ramdisk_size ?
<mantiena> if there are no CVS or SVN ?
<sivang> mantiena: what would CVS or SVN allow you to do that you cannot do now with casper, cloop and the installable pkgs from the archive?
<mantiena> sivang, CVS would allow to work together
<mdz> mantiena: Kamion maintains scripts for building all CDs, live and install
<sivang> elmo: just seen your preview comment regarding the highly advanced fat system => rofl
<mdz> mantiena: http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2004/
<mdz> mantiena: but that is only tangentially related to live CD development
<elmo> Kamion: #deb file:///cdrom/ hoary main restricted
<jordi> mdz: did you talk to bubulle about an apt-listchanges upload?
<elmo> Kamion: that's at the top of my sources.list after array 4 install?
<mdz> jordi: he pinged me on IRC while I was asleep
<jordi> mdz: he wants to ask you permission to upload a new one
<jordi> a few translations (guess what, including Catalan) were forgotten, + Italian fucked up
<mantiena> mdz, casper doesn't have CVS or SVN too ?
<mdz> mantiena: apt-get source casper
<mdz> mantiena: that is where all development happens
<mdz> jordi: that is fine with me
<jordi> mdz: ok, will forward :)
<mdz> mantiena: I intend to set up an arch repository, but so far there has been no need.  can you tell me why it is a problem for you that it does not exist yet?
<mdz> I tend to make small changes, test and upload them to hoary
<mantiena> mdz, I have some casper improvements
<mdz> mantiena: that's great; can you send me your patches?
<mdz> Keybuk: is it possible yet to create an arch archive based on a sequence of source packages?
<Keybuk> no, not yet
<Keybuk> that's what the goal of next week is
<mdz> Keybuk: casper would be a nice and simple test case ;
<mdz> ;-)
<mantiena> mdz, I can, but I don't know if you want them ;)
<mdz> mantiena: I am interested in seeing them even if they are not finished
<mantiena> mdz, I think, that into target/etc/fstab should be added all hard partitions, like in knoppix and morphix
<mdz> mantiena: yes, this would be nice (both for the installer and live CD)
<mdz> we have a bug open about it
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=669
<mantiena> mdz, thanks
<mdz> mantiena: there is code in the installer (os-prober) which examines partitions and determines if they contain Ubuntu, Windows, etc.
<mantiena> mdz, yes, I know os-prober
<mdz> I would like to extend and use that code, so that the partitions can be mounted with useful names
<mdz> rather than hda1, hda2, etc.
<mantiena> mdz, yea, this would be ideal
<mantiena> for example win_partition1 or windows_drive1
<elmo> whoever add /usr/bin/time to base, you rock
<thom> heh
<mdz> I didn't even know that was there
<sabdfl> hey guys when last was Kamion around?
<elmo> 17:16 UK time
<elmo> (i.e. 50 minutes)
<mantiena> mdz, there is one problem with os-prober - it tries to mount every partition as every possible filesystem type :( I think there should be better way, for example by using `parted /dev/hdx print`
<mdz> mantiena: or even file(1)
<mdz> seb128: ping?
<mantiena> mdz, btw, I found one bug in os-prober (xfs filesystem is missing in /usr/lib/os-probes/init/10filesystems), should I report this bug into ubuntu bugzilla or into debian ?
<seb128> mdz: pong
<mdz> seb128: did you receive my email about suspend/hibernate?
<mdz> mantiena: ubuntu bugzilla, please
<seb128> mdz: bugzilla comment or mail ? no mail afaik
<mdz> seb128: email
<mdz> hmm, I wonder if my mail is being delayed
<seb128> perhaps I've dropped it with some spams
<seb128> or I've not got it
<mdz> I sent a message some days ago and received no reply, so I sent another
<seb128> send it again please
<mdz> it was to ubuntu-devel, CC you
<seb128> oh
<mdz> forwarded a copy to you directly
<seb128> right, so it's probably in my ubuntu-devel box
<mdz> it is about the gdm suspend/hibernate stuff
<seb128> what about it ? 
<mdz> when we talked before, I think that you said it would be easy to set up
<mdz> I would like to have it set up :-)
<seb128> thom said one or two days ago that he was doing the backend to call
<seb128> I'll have a look on the UI soon
<mdz> thom: ?
<seb128> fv 08 13:14:06 <thom>  for hibernate and suspend actions on the logout menu
<seb128> fv 08 13:14:19 <seb128>        yeah, I've a bug open about this
<seb128> fv 08 13:14:23 <thom>  yes
<seb128> fv 08 13:14:31 <thom>  i'm working on the code to let you do it ;-)
<seb128> fv 08 13:14:36 <thom>  (the backend code)
<seb128> that's it
* mvo_ is playing hockey now, bbl 
<mantiena> mdz, ok, another bug - I'm not 100% sure, but I think, that parted-udeb should depend not only on libc6 but also on libparted, right ?
<mdz> mantiena: possibly; Kamion can confirm if so
<mantiena> Kamion
<mantiena> ;)
<mantiena> mdz, btw, if I report a bug to ubuntu bugzilla when this bug will be fixed in debian unstable ?
<pvh> Is there any highlevel subsystem documentation around?
<pvh> For example, a document explaining what mechanisms are involved in the standard ubuntu configuration for audio, printing, &c
<mdz> mantiena: Kamion regularly merges Debian and Ubuntu installer components
<shaya> has gnome printing changed in 2.9 such that it wont pick up the foo2zjs print drive?
<mantiena> mdz, a wishlist to liveCD - hwclock (/etc/adjtime) should be set to LOCAL, because liveCD is mostly targeted to Windows users, right ?
<mdz> mantiena: the live CD is intended to be universal, for all users
<shaya> or put it this way, if a package in hoary suggests a broken package in universe where does one file a bug?
<mdz> shaya: we don't have a bug tracker for universe yet
<mdz> it's coming
<shaya> yes, hence the Q
<mdz> hence the A :-)
<shaya> gnome print doesn't show my printer, even though the foo2zjs package is installed
<mdz> I'm not familiar with that driver
<shaya> for minolta printers
<lamont_live> definitely need a new monitor for this machine... 800x640 scuks
<shaya> hmm, see ms that it doesn't install the ppd file
<shaya> source package has it, lets see what happens now
<elmo> daniels: ?
<mantiena> mdz, I understand that live CD is intended to be universal, but you know, that majority systems, on which liveCD will be uses, runs M$ evil OS...
<seb128_> mdz: got the mail this time
<mdz> seb128_: ok, there was nothing more to it than we discussed here :-)
<mdz> I was just concerned that my mail was being lost
<seb128_> yep
<seb128_> I put that on the top of my todolist
<mdz> thanks
<seb128_> np
<seb128_> BTW a amd64 guy should really look on the evolution breakage. It's broken for 2-3 weeks now, that bother users and ximian guys (I've got some mails about it)
<mdz> seb128_: have you talked to Mithrandir?
<seb128_> yeah, pinged him 4-5 times this week
<seb128_> but he was busy with other stuff, had kernel issues and no news since
<mdz> ah
<Nafallo> this CC.archive.ubuntu.com doesn't work yet, right?
<elmo> it "works" as in "doesn't break"
<elmo> it may not work as you expect tho
<mdz> us.archive DTRT at least
<Nafallo> elmo: oki. was a bit confused when se.a.u.c ended up in england and de.a.u.c ended up in us (mtr)
<Nafallo> :-)
<Nafallo> the big question would be if I should sync against one of them instead of tu-dresden.de for my homemirror.
<elmo> uh?
<elmo> the only in the us is us.a.u.c
<elmo> right now, it's a wildcard, so anything except 'us.archive.ubuntu.com' points at the same place as archive.ubuntu.com which is in the UK
<Nafallo> hmm, I got when I try it now it points right.
<Nafallo> s/I got//
<Treenaks> ogra: ping?
<ogra> Treenaks: pong
<Nafallo> de was 66.154.103.47 says me bash-history :-)
<Treenaks> ogra: uh.. python-serial (pyserial) isn't available ina "python2.4" flavor yet
<Treenaks> ina=in
<ogra> hmm
<Treenaks> ogra: how can we fix that?
<ogra> Treenaks: i'm currently fighting with ion3 which seems to have a own license for every line of code...
<Treenaks> ogra: ugh..
<Treenaks> ogra: I'll try to build deps.. I think it's just a recompile
<ogra> Treenaks: i can either put it on my list, but it will have to wait some days or you could fix it if you like
<Treenaks> ogra: I'll try to see how easy it is
<ogra> Treenaks: since you are still missing your first upload ;)
<Treenaks> ogra: if it's just a recompile it's easy :)
<Treenaks> ogra: yeah :)
<Treenaks> ogra: never mind my stupidity
<Treenaks> ogra: dpkg -L python-serial
<Treenaks> /usr/lib/python2.4/site-packages/serial/serialposix.py
<ogra> heh
<Treenaks> ogra: next time I'll look before I shout ;)
<mdz> amu: ping
<amu> mdz: pong 
<mdz> amu: why is 'kde' not in the kubuntu desktop seed?
<mdz> amu: or kdm?
<amu> .. cause it's in the metapackage, i'm not sure if we need it twice  
<mdz> amu: I guess I didn't communicate clearly enough when we talked about this
<mdz> the metapackage is supposed to be generated from the seeds
<mdz> but instead you edited it by hand
<mdz> so it doesn't match
<amu> oh, i'll fix this 
<bluefoxicy> how do I make iptables rules restore at boot
<mantiena> mdz, what you think about default resolution in live CD ? I think 1280x1024 is not good
<sivang> bluefoxicy: make it a /etc/init.d script, and give it a number low enough you it would be executed in the right time, on my router I have an /etc/init.d/firewall.sh and in /etc/rc2.d/S12router which is a symlink to the /etc/init.d file
<bluefoxicy> sivang:  this isn't yet standard in ubuntu?
<bluefoxicy> sivang:  on gentoo, there's a nice script, 'iptables', that's in /etc/init.d/, that /etc/init.d/iptables save saves your rules; on restart, it restores them (i.e. at boot) :)
<bluefoxicy> sivang:  perhaps  ishould port the script to ubuntu
<lamont> bluefoxicy: I don't restore them at boot.  I install them.
<bluefoxicy> log_error_msg?
<mdz> mantiena: the default mode is determined by a probe
<mdz> e.g., on my laptop it is 1024x768, on my desktop 1600x1200
<amu> Added gedit to desktop-i386, desktop-amd64, desktop-powerpc, desktop-ia64, desktop-sparc
<amu> mdz: in this case i add gedit to the blacklist 
<amu> +?
<mdz> amu: why?
<amu> mdz: i dont want it on the desktop-i386 
<mdz> amu: does something in the seed depend on it?
<mdz> I don't see it in the germinate output
<amu> mdz: check today the seeds, and another guy from kde said it's gnome free now.
<mdz> amu: http://people.ubuntu.com/~cjwatson/germinate-output/kubuntu-hoary/all
<amu> ... there are some more gnome apps
<mdz> gedit is not there
<mdz> the blacklist is for packages that we do not want in main
<mdz> it should be identical in kubuntu and ubuntu
<mdz> (for now)
<mantiena> mdz, but on most my tested systems (17' CRT monitors) ubuntu live starts in 1280x1024 resolutions, which is really not good for these monitors
<mdz> amu: please chmod -R g+rwX /home/warthogs/archives/kubuntu-devel@lists.ubuntu.com
<amu> mdz: let me explain what i did, i uploaded the seed and waited till the changes are on the web, than i run update from the meta package and a lot of gnomepackages are added
<mdz> amu: and set your umask on chinstrap to 002
<amu> umask done; permission are set to cjwatson, so i cant change 
<mdz> thanks
<mdz> don't forget your umask, so that it doesn't happen again
<thom> mdz: sorry, throwing dinner down my neck and going out to meet friends. i'll get with seb on monday and we can get some working code together
<amu> mdz: added it to my profile
<mdz> thom: ok, have a good weekend
<thom> thanks, and you
<thom> (it should be pretty trivial to implement, btw)
<mdz> I thought so, which was why I was surprised that it wasn't already there before feature freeze
<thom> well, the interface itself was quite hard; the gnome stuff to use it should be easy
<mantiena> mdz, agains which Product (LiveCD or Ubuntu) and package (gues xserver-xorg ) should I report default resolution bug ?
<mdz> mantiena: xserver-xorg
<mdz> mantiena: include copies of /var/log/Xorg.0.log and /etc/X11/xorg.conf
<mantiena> mdz, thanks
<mdz> mantiena: the resolution is too high or too low?
<mantiena> mdz, should I use livecd keyword ?
<mdz> mantiena: no; exactly the same thing will happen on an install
<mantiena> mdz, but on most my tested systems (17' CRT monitors) ubuntu live starts in 1280x1024 resolutions, which is really not good for these monitors, most people use 1024x768 or 1152x864
<mdz> if the monitor supports it, and at a reasonable refresh rate, then I wouldn't consider it a bug to use that mode by default
<mdz> the user can select a different one if they like
<mdz> amu: ok, I have added kde and kdm to the kubuntu desktop seed
<mdz> amu: once elmo resyncs the archive, I will upload a new kubuntu-meta generated exclusively from the seeds
<mantiena> mdz, hehe, fonts are very small when using 17 CRT monitor on 1280x1024 resolution and refresh rate is 60 or 75 Hz, which is really bad
<mdz> mantiena: 75Hz is a fine refresh rate
<mdz> I am at 75Hz right now
<mantiena> mdz, you are using CRT or LCD monitor ?
<mdz> CRT
<mdz> LCDs don't have refresh rates
<mantiena> mdz, so, you eyes are crying
<mdz> you are incorrect
<mantiena> I don't think so
<Mithrandir> seb128_: pong
<seb128_> Mithrandir: ximian guys start to mail me because of the amd64 issue in hoary since users bug them ... any way to solve that ?
<Mithrandir> seb128_: I'm binary searching through the versions from array 3 until now.
<Mithrandir> seb128_: evo links again every library on earth, so it takes a little while
<seb128_> according to the comments on different bugs, some users get it working with a rebuild
<Mithrandir> could you give me a reference?
<amu> mdz: strange,i added with patch-6, kdm and kde to the kubuntu desktop seed, saw you did with patch-7 excatly the same, i confused now 
<ogra> Mithrandir: https://bugzilla.ubuntu.com/show_bug.cgi?id=5870 comment 5, 8 and 9
<Mithrandir> ogra: not really useful -- "I built them by hand and they work".  They should tell a bit more about their installed stuff than just gcc version
<seb128_> Mithrandir: https://bugzilla.ubuntu.com/show_bug.cgi?id=5870
<ogra> Mithrandir: 8 is more interesting....
<Mithrandir> ogra: that just means the build-deps are right -- evo build-deps against god know what libraries.
<Mithrandir> ogra: (yes, I'm whining; I just need to know exact versions for it to help me)
<ogra> Mithrandir: i know, i tried to build it here too ;) (didnt work btw)
<Mithrandir> binary searching should work, it just takes time.
<Mithrandir> evo's not the lightest app to build there is.
<ogra> heh...surely not
<elmo> seb128: dude, is there a bug about this gaim/metacity/whatever, "gaim doesn't pop up, like I asked, begged, bribed, etc. it to" bug?
<mdz> also known as "why did the gnome-terminal I just opened appear behind the old one"
<ogra> the new metacity pop-under feature
* lamont takes a sanity break
<seb128_> elmo: http://bugzilla.ubuntu.com/show_bug.cgi?id=3159
<seb128_> elmo: that's a global bug about focus issues with the new metacity, just list here your issues
<lamont> firecall
<Mithrandir> seb128_: hmm, the bug was filed jan 25th.  array-3, which works, was released jan 20th.
<Mithrandir> seb128_: so the bug is probably in between there somewhere.
<ogra> Mithrandir: i have version 2.1.3.2-0ubuntu2 locked and working fine here...
<ogra> Mithrandir: anything later segfaults
<elmo> ok, gaim's on there
<netdur> hey, I see there OOo 1.9x... it is installable? I want to test it!
<Mithrandir> ogra: 2.1.3.2-0ubuntu3 works here.
<ogra> Mithrandir: weird
<Mithrandir> ogra: going from evo libcamel1.2-1_1.1.3-0ubuntu10, evolution-data-server_1.1.3-0ubuntu8 and evolution_2.1.3.2-0ubuntu3 to libcamel1.2-2_1.1.4.1-0ubuntu1, evolution-data-server_1.1.4.1 and evolution_2.1.4-0ubuntu1 breaks.
<Mithrandir> s/evo//
<Mithrandir> *sigh*; new upstream versions. :(
<Mithrandir> I need to diff those, go through the changesets and see what might have broken
<mantiena> mdz, according pretty old TCO99 standard minimal mandatory vertical refresh is 85 Hz, recommended is 100 Hz, look at http://www.tcodevelopment.com/pls/nvp/Upload.Show?CID=776&MID=141 
<ogra> Mithrandir: hmm, dont they test build on amd64 at ximian
<seb128_> Mithrandir: the issues has started with ximian connector before evolution IIRC
<Mithrandir> ogra: it might be something else, somewhere which triggers the problem.
<mantiena> mdz, so, I'm correct :-P
<Mithrandir> seb128_: I'm not sure the connector problems are related.
<seb128_> k
<Mithrandir> seb128_: I'm not saying they aren't, I'm saying I'm not sure, mind. :)
<seb128_> yeah
<mdz> mantiena: at 75Hz I have no flicker and no eye strain, so I'll be the judge of my own comfort, thanks
<Mithrandir> evo 2.1.4 seems to be the first which used libdb4.2 in the build-deps; I'll make sure the libdb I have on the system is ok; amd64-wise
<mantiena> mdz, hehe, try to work at 100 Hz for about 1-2 months, then try 75Hz and you notice the difference ;)
<Mithrandir> mantiena: it really depends on the monitor -- a lot of older monitors are fine at 75Hz since their phosphor is slower.
<mantiena> Mithrandir, i have old monitor, but 75 Hz is very very bad for me
<mantiena> but if I work some time on 75Hz my eyes don't notice difference between 75Hz and 85 or 100Hz
<Mithrandir> seb128_: bah, I'm too tired to hack on this now; I'll look at it tomorrow, but now we know between what versions stuff broke.
<Mithrandir> ogra: I'm also a bit concerned about "works by accident"
<seb128_> k
<Mithrandir> seb128_: is the upstream delta between the versions I wrote above large?
<seb128_> dunno
<seb128_> there is something like 15 days before releases, so probably not huge
<seb128_> s/before/between/
<zul> later..
<restrex> hi guyz .. what option on freetype at hoary is enabled at this shot? http://restrex.dotgeek.org/ I ask it 'cause the fonts look cool !
<marcin_ant> restrex: you need to improve your statistics right?
<website> marcin_ant, i think hte same
<restrex> marcin_ant gos is looking this..
<restrex> God
<marcin_ant> restrex: ?
<restrex> yes
<restrex> I've been 3 days asking the same
<restrex> :(
<marcin_ant> restrex: what do you want?
<restrex> I don't know what it's called the option of freetype that's enabled now on hoary
<restrex>  I don't know How is called the option of freetype that's enabled now on hoary
<restrex>  http://restrex.dotgeek.org/hoary.png  http://www.freepgs.com/juan-pablo/ubuntu.png
<restrex> here is the difference
<restrex> it the first shot it's enabled
<restrex> on second it's disabed..
<restrex> the first is hoary the second warty
<marcin_ant> restrex: ok now we can see
<restrex> :D :P
<marcin_ant> restrex: url in your first question was wrong...
<restrex> ohhh sorry ys :(
<marcin_ant> restrex: I think that the difference is from antialiasing
<restrex> yes :/
<restrex> ok
<restrex> :/
<marcin_ant> Desktop -> Preferences -> Fonts
<marcin_ant> Font rendering
<restrex> mmmm I'm gonna see it now.... but I tried it before and nothing happened
<restrex> I want to aply the 'antialiasing' on warty...
<restrex> apply* (sorry my english please) :)
<marcin_ant> restrex: you can take a look at "details" section in this "Fonts" preferences dialog
<restrex> ok
<sabdfl> guys, netapplet is crackful
<marcin_ant> restrex: you need to click "details" button
<restrex> ok ;)
<restrex> I power on the computer .. :P
<marcin_ant> restrex: anyway for me unfortunately all these "default" fonts aren't good
<marcin_ant> restrex: and I use tahoma
<marcin_ant> restrex: maybe you should try some "propietary" fonts too ;)
<restrex> oh ok thanks for help me ;)
<restrex> jeje
<marcin_ant> restrex: np
<restrex> I friend said me
<restrex> apt-get source freetype and read the code...
<restrex> :/
<bluefoxicy> OK
<bluefoxicy> so firestarter is pretty
<bluefoxicy> but it breaks things
<bluefoxicy> I now can't get my dcc to work, as the ip_nat_irc and ip_conntrack_irc modules are loaded, yet the firewall disallows any DCC
<bluefoxicy> iptables -F doesn't really flush the firewall either, it simply breaks it completely, leaving about 5 custom chains empty too (instead of flushing them out wtf)
<sivang> bluefoxicy: firefox really annoyed me when I used it..about a year ago..
<mdz> sivang: firefox != firestarter
<bluefoxicy> sivang:  firewalling
* bluefoxicy is quite annoyed.
<mdz> we looked at firestarter for Ubuntu, and came to the same conclusions. that's why it's in universe
<bluefoxicy> yeah
<bluefoxicy> it's nice, easy to use, but damn
<sivang> bluefoxicy: ops sorry
<sivang> I meant firestarter
<sivang> mdz: ;)
<bluefoxicy> mdz:  but at the same time, some users are going to want to use their machine as a router, hence why Windows comes with point and click "internet connection sharing"
<bluefoxicy> you can make the iptables rule yourself now, but then you have to write a script to load the rule on boot, yourself.
<sivang> bluefoxicy: which usually never works (from people I have helped with that) and is really fragile
<bluefoxicy> that's fine for me
<bluefoxicy> but I don't know very many people (even linux users) who can actually use iptables
<bluefoxicy> much less write an init script to set up iptables for them
* bluefoxicy doesn't know where the hardware router went
<sivang> bluefoxicy: I am thinking of adding a briding capability to network-admin (this yet pending discussion with upstrea) which if we got it right, would allow us to use ubuntu system as nice net sharing devices, as I am using my system here manually (it's a bridg for 2 other machines)
<bluefoxicy> heh
<sivang> bluefoxicy: for internet sharing purposes, briding is so cool if have a nice set dhcp server , although this may not be the use case for most of the users...
<sivang> bluefoxicy: s/dhcp server/router and firwall/
<sivang> s/briding/bridging/
<sivang> bluefoxicy: briding capabilty to g-s-t might get me in the wrong places :))
<bluefoxicy> there
<bluefoxicy> I've griped at ubuntu-devel and the author
<restrex> marcin_ant
<restrex> I have to enable that <match target="font">
<restrex>    <edit name="autohint" mode="assign">
<restrex>      <bool>true</bool>
<restrex>    </edit>
<restrex>  </match>
<restrex> <fontconfig> 
<restrex> :D
<restrex> that worked ;)
#ubuntu-devel 2005-02-23
<restrex> on /etc/fonts/local.conf
<lamont> sivang: my internet connection is through a linux box
<lamont> routing is rock solid
<lamont> then again, I roll my own scripts...
* lamont goes back to heads-down mode
<sivang> lamont: I have my routing and internet connection through a p100 56M 800MB 52MB machine, but insie the lan I am using one machine to bridge the network for two others
<sivang> lamont: and right, routing is rock solid :)
<Kamion> mdz: ramdisk_size bumped
<mdz> Kamion: thanks
<Kamion> mantiena: yeah, parted has some rickety packaging in places, I should probably fix that
<Kamion> mantiena: I've fixed the os-prober thing in my local tree
<Kamion> thanks
<marcin_ant> restrex: hmmmm
<marcin_ant> restrex: interesting
<marcin_ant> restrex: and what exactly is the difference?
<restrex> !
<restrex> the hint of the fonts
<restrex> ;)
<restrex> http://restrex.dotgeek.org/hoary.png  http://www.freepgs.com/juan-pablo/ubuntu.png here's the difference
<restrex> :P
<marcin_ant> restrex: I need to try...
<restrex> ok
<restrex> try
<restrex> uncomment 
<restrex> on /etc/fonts/local.conf
<restrex> :P
<marcin_ant> restrex: and what next?
<marcin_ant> restrex: I know where
<restrex> restrex I have to enable that <match target="font">
<restrex> restrex    <edit name="autohint" mode="assign">
<restrex> restrex      <bool>true</bool>
<restrex> restrex    </edit>
<restrex> restrex  </match>
<restrex> restrex <fontconfig> 
<marcin_ant> restrex: I had to edit this file to enable bitmap fonts yesterday
<restrex> uncomment that
<marcin_ant> restrex: yest
<restrex> ok
<mantiena> Kamion, thanks
<marcin_ant> restrex: and what next?
<restrex> well that worked to me
<marcin_ant> restrex: restart session or something?
<restrex> excatly
<restrex> :P
<restrex> exactly
<mantiena> Kamion, as I understand I shouldn't report a bug against parted-udeb about dependancy on libparted, you already know this ?
<Kamion> mantiena: well I haven't fixed it yet, so feel free to report :)
<mantiena> Kamion, hehe, maybe better fix it, it's not hard ;)
<Kamion> mantiena: re #669 it really needs to be hooked into the way partman-target already creates /etc/fstab, so I'm not sure something totally generic to both install and live is immediately possible
<Kamion> mantiena: I'm afraid that I have a number of other things to do tonight :P
<mantiena> Kamion, about 669 - I think it would be not hard to write separate script, which adds more entries to fstab
<mantiena> this udeb could be used on both - install and live CD's
<Kamion> perhaps; I haven't yet looked. I recommend looking at partman-target if you have not done so already
<marcin_ant> restrex: sorry I cannot see any difference
<restrex> oops
<restrex> I friend could see the difference
<restrex> :)
<marcin_ant> restrex: hmm or mayve
<marcin_ant> s/mayve/maybe
<marcin_ant> a little
<restrex> yeah
<restrex> :)
<restrex> I think that rocks
<marcin_ant> fonts are bigger and little sharper
<restrex> I like it a lot
<restrex> :P
<restrex> yes
<marcin_ant> but I cannot tell if they are really better
<marcin_ant> I think that it can depend on what font you use
<restrex> oh that's is your opinioon
<restrex> :)
<marcin_ant> you know
<marcin_ant> they are really better with
<marcin_ant> "slight"
<marcin_ant> hinting (in "Font rendering details")
<restrex> jeje
<restrex> I'll try too
<restrex> :P
<T-Bone> yummy, booted ubuntu with a ppc64 kernel ;)
<mdz> T-Bone: mmm, nice
<T-Bone> mdz: actually it happened by mistake: I booted my gentoo kernel with the ubuntu rootfs ;)
<T-Bone> noted a couple of ioctl errors (not that surprising: some missing clue for 32bit calls i guess) but it booted fine anyway
<T-Bone> s/clue/glue/
* T-Bone is exhausted, calls it a night
<bluefoxicy> uh
<bluefoxicy> ok
<bluefoxicy> somebody tell me what's going on with my cd rom drive.
<bluefoxicy> there's nothing in my cd rom drive, i ahve one cd drive
<bluefoxicy> BUT 
<bluefoxicy> I can mount it
<bluefoxicy> it has files on it
<bluefoxicy> oh!
<bluefoxicy> holy crap I"m shelled into another machine somewhere, no wonder
<tseng> bluefoxicy: knock it off.
<bluefoxicy> tseng:  you're just jelous 'cause I sound like a rock star
<tseng> or just tired of the low signal/noise ratio
* bluefoxicy was trying to get data to reply to something on ubuntu-devel@
<tseng> the devs like to keep this channel low traffic, high signal/noise
<tseng> so if you could think out loud somewhere else, im sure everyone would appreciate it.
<jbailey> jdub: http://bugzilla.ximian.com/showattachment.cgi?attach_id=13548 might be a solution for Ubuntu BZ#2752
<jbailey> jdub: And 2725 can be closed. =)
<jbailey> jdub: I'm looking at doing an evo-exchange upload, mind fi I just deal with these?
<jdub> please do
<jdub> there's no BML here ;)
<jbailey> BML?
<jdub> jbailey: big maintainer lock ;)
<jbailey> *lol*
<jbailey> jdub: True, but since it's actually assigned to you, I figure it'd polite to mention before I steal them.
<jdub> STEAL MY BUGS
<jbailey> You'll have to flog me for it later. =)
<jdub> UDU dude
<jdub> beers and flogging
<jbailey> Sweet.
<jbailey> Maybe it's best that my wife couldn't make it. =)
<jdub> heh
<jdub> i don't have a wife now, but i will then ;)
<jbailey> I remember that.  I met your lady in Brazil.
<jdub> oh cool, didn't know you were there
<jbailey> She asked me strange questions like whether I would be more likely to come to some conference if it were in .nz instead of australia.
<jdub> and now you're working for SSDS ;)
<jdub> oh
<jdub> you know why?
<jdub> linux.conf.au 2006 is going to be in New Zealand - announced only last week :)
<jbailey> Yeah, life works in strange ways. =)
<jbailey> Oh lovely. =)
<tseng> jbailey: did she mention anything about loving pants?
<jbailey> tseng: Errr....
<jdub> dear elmo,
<jdub> dear elmo, please install xplanet on rookery, kthxbye. love, jdub.
<jdub> i've just used gnome as a guinea pig for a fun feature for ubuntu
<jdub> http://live.gnome.org/GnomeWorldWide
<jbailey> I have an urge to do some ugly hack of hideous proportions.
<jbailey> It's the Hurd hacker in me trying to get out. =)
<jdub> of course, it's easier with gnome's wiki
<jdub> fie zwiki, fie!
<jbailey> GAH, why is firefox a higher priority for x-www-browser than ephy?
<jbailey> The default installed browser should never be a higher priority than anything else.
<jdub> haha
<jdub> you will comply!
<jdub> that's a good bug to fix though
<jbailey> Hmm, I guess I vaguely qualigy as a GnomeWorldWide person, I guess.
<jdub> yeah, add yourself to the russian wastelands
<jdub> oh
<jdub> other wastelands
<jbailey> No.  I'm just outside of the US. =)
<jdub> the pseudo french ones
* jbailey hides.
<ajmitch_> hey jeff & jeff :)
<ajmitch_> jbailey: I hope you will come to lca2006
<matt__> Anybody know who did the new xscreensaver 'unlock' dialog?
<jbailey> ajmitch_: I think it's as unliekly as me going to FOSDEM ever.
<jbailey> ajmitch_: It's just way too long of a trip for a short period of time.
<jdub> matt__: ogra
<ajmitch_> jbailey: hmm, you've got 11 months to save :)
<matt__> I like it :-)
<jdub> it's rad
<jdub> now it doesn't skewer out my eyeball and roast it on the fires of hell
<jdub> which was tiring
<jdub> and gave me a headache
<matt__> yeah, the old one was fugly as hel
<matt__> it's the little things that count
<jbailey> ajmitch_: Save?
<jbailey> ajmitch_: Oh, it's not the money.  It's that I don't like travelling that much (despite the fact that I do alot of it)
<jdub> you are pudding!
<jbailey> Ooo, the new unlock box is nice.
<jbailey> I should roll up my sleeves and hack it to do Xinerama.
<jbailey> Perhaps I'll be lazy instead.
<jdub> yeah, probably not worth it
<jdub> we'll most likely have a proper gnomey one next time around
<ajmitch_> I can appreciate xinerama now that I have a 2nd monitor, although my hoary X display is just in an Xnest
<jbailey> ajmitch_: I suck for work without xinerama.
<jbailey> I usually have both monitors full and my laptop with a screen going.
* ajmitch_ wonders what to work on next
<jbailey> ajmitch: You looking for tasks?
<ajmitch> jbailey: maybe.. :)
<jbailey> ajmitch: I had a vague thought that C# bindings for a translator might be cool.
<ajmitch> yeah
<mdz> jbailey: the new unlock box is nice except for the MovieOS "APPROVED"
<ajmitch> what sort of translator?
<mdz> ACCESS GRANTED CLEARED LEVEL ONE
<ajmitch> mdz: flashing green?
<jbailey> mdz: True.  But the graphics are now actually better than I can produce.  The previous ones, I'm less sure.
<jbailey> ajmitch: I was thinking just the ability for an app to land on a translator and provide status information.
<jbailey> ajmitch: Even something simple like a libapache2-mod-status
<jbailey> ajmitch: Go through and collect stats information on web server internals in a /proc or /sys like setup
<jbailey> ajmitch: There's no rason to do that in anything as low level as C or C++.
<ajmitch> hurd?
<jbailey> ajmitch: Do translators run anywhere else?
<ajmitch> no, but I thought you might have been suggesting something ubuntu-related :)
<jbailey> Ah, no. =)
<jbailey> I'm still too new with Ubuntu to have a long list of tasks that I want to do but will never get to. =)
<jbailey> Gimme another 4 months.  Hanging out with people at UBU should probably do it. =)
<ajmitch> heh
<ajmitch> I'm still hopeful of getting there
<jbailey> Cool.  It would be lovely to meet you finally. =)
<ajmitch> yeah, I'm just not sure about LCA still
<jbailey> Yeah, I'm not going to that.
<ajmitch> dunedin->sydney isn't too expensive :)
<ajmitch> I'd better install hoary on my laptop by then though
<Mithrandir> hi Jeff, ajmitch 
<ajmitch> hi Mithrandir 
<Mithrandir> ajmitch: what's your real name?
<jbailey> Heya Tollef.
<ajmitch> andrew mitchell
<Mithrandir> ajmitch: ah, ok.  I wasn't sure and instead of making a fool of myself guessing wrong, I went for the IRC nick. ;)  I just like knowing people's real names.
<ajmitch> plus tab-completion is easier :)
<Mithrandir> that's true
<Mithrandir> I also like to have a face to connect with the IRC nick, tho
<ajmitch> going to UDU?
<Mithrandir> yes
<Mithrandir> possibly also LCA; I just need to decide first.
* ajmitch checks out flights to sydney
* lamont runs an errand in town
<jdub> hrm
<jdub> the volkswagen song
<jdub> s/da da da/ubuntu/
<dholbach> re
<zul> hey
<mdz> what's the right build-depends expression for something which in Ubuntu build-depends on libxinerama-dev, but should also build on Debian?
<jdub> xlibs-dev | libxinerama-dev
<jdub> probably better the other way around
<mdz> thanks
<mdz> though
<mdz> xlibs-dev doesn't depend on libxinerama-dev
<jdub> bummer
<jdub> perhaps libxinerama is separate anyway
<mdz> no libxinerama-dev in Debian
<bluefoxicy> mdz:  when you're free can we discuss something from ubuntu-devel@?
<mdz> bluefoxicy: if it's the live CD installer thing, not tonight
<bluefoxicy> mdz:  alright.  I'm gonna leave a reply anyway though on the list, but another day.
<mdz> elmo: not sleepy?
<elmo> mdz: hmm.  i was.  but I got distracted by my dead computer
<elmo> "auto restart after AC power loss" == love
<mdz> defaults of "power off after AC power loss" == death
<mdz> I have a machine here which defaults to power-off, and the option isn't visible in setup unless you install a h4x0red BIOS
<elmo> yeah - I'm imaging how screwed I would have been had this happened when I was in .es or even .au
<elmo> mdz: eww
<daniels> mdz: libxinerama-dev | xlibs-static-dev
<bob2> mutt gets kinda slow with 40 000 messages in one folder
<mdz> daniels: | xlibs-static-dev (<< 6.8.1-1) is what I decided on
<mdz> because current xlibs-static-dev doesn't seem to include the same stuff as old xlibs-static-dev
<jdub> bob2: header caching!
<mdz> jdub: mbox!
<mdz> (doesn't header caching only work with maildir?)
<jdub> and imap
<bob2> haha, I have headercache with maildir
<bob2> so it opens pretty quick
<mdz> 40k messages in one folder is insane anyway
<mdz> unless it's all spam
<jdub> it is insane
<bob2> but if you modify it while it's open, mutt spends > 20minutes restating it
<jdub> we're going to have to see your doctor again, bob2 
<daniels> mdz: ah, yeah.  phat.
<bob2> mdz: forget to reenable my archivemail cronjob
<jdub> DOKTOR FEEL GUT
<jdub> yeah, that sucks in my sent folder
<jdub> "forward this mail i sent to someone else"
<jdub> ...
<jdub> ..
<jdub> ..
<jdub> bong
<bob2> hahaha, yeah
<bob2> I should rotate my sent folder weekly or something
<helix> is there anything to filter outgoing mail?
<mdz> mutt send-hooks
<helix> I knew that
* helix crawls back into her hole
<jdub> mutt has send-hooks, which are kinda like that, or you could send all your outgoing mail through procmail ;)
<helix> it's actually quite silly that I asked considering I *have* send-hooks in my .muttrc
<helix> anyway, the hole.
<mdz> jdub: even I am not that extreme about procmail
<mdz> helix: no, come back!
<helix> anything for mdz
* mdz plays the flute and makes hypnotic motions
<jdub> helix: send hooks are there so you don't even have to think about them
<helix> jdub should belly dance
<helix> jdub: true. I think I stole mine from your .muttrc
<jdub> heh
<jdub> man
<jdub> i should so update that
<mdz> I should publish my dotfiles
<helix> I changed the email addresses
<zul> helix: no nightmares tonight thansk
<bob2> jaq's is pimper
<helix> mdz: you SHOULD
<jdub> bob2: only because he updates it
<helix> mdz: especially your zsh stuff
<mdz> they frighten people :-(
<bob2> thom's zshrc is pretty impressive
<daniels> i like my zshrc
<mdz> my zsh is not as scary as my procmail
<helix> my procmail is totally basic
* mdz hugs setopt DVORAK
<daniels> helix: you don't want to see jdub bellydancing
<daniels> mdz: CRACK
<helix> daniels: why not?
<jdub> even pipka is using procmail now
<helix> mdz: sicko
<mdz> mizar:[~]  cat .procmailrc* |wc -l
<mdz> 3059
<zul> holy crap
* helix blinks
<jdub> mdz: that means you're crap at procmail ;)
<zul> popular guy arent you mdz
<mdz> jdub: it might seem that way to the uninitiated
<mdz> jdub: but in fact this is not the case
<mdz> I apply different keyword filters to different mailing lists
<helix> mine is a whopping 292
<helix> I wonder what kind of crack mdz is on
<mdz> and I generate the whole mess with m4
* mdz hides
<jdub> ah, if it's generated, that's reasonable
<zul> helix: mine is 82
<helix> ugh, but he willfully uses m4
<jdub> i have never used m4 willfully
<jdub> i've used it with incredulity a couple of times
<mdz> I really want something better than procmail
<jdub> something that groks list headers already
<mdz> sometimes I am >< this close to using gnus
<mdz> but then I try it
<bob2> the clarity of m4 with the simple syntax of procmail
<jdub> mdz: tried wanderlust?
<bob2> you really have the best of both worlds, mdz 
<jdub> mdz: gus raves.
<mdz> jdub: no, I haven't
<daniels> mdz: WITH M4?!?
<mdz> bob2: so how are you enjoying being part of the arch team?
<helix> :( no wanderlust in debian
* mdz cackles evilly
<bob2> rofl
<bob2> mdz: you're evil
<helix> I have a daniels quote about m4
<bob2> helix: wl.
<helix> but it's durty
<jdub> helix: wl
<bob2> jdub: too slow.
<helix> wl?
<jdub> wander
<jdub> lust
<jdub> wl
<jdub> :-)
<helix> I knew that
<mdz> helix: daniels is a potty mouth
<jdub> you were just testing us
<helix> he is
<ajmitch> hi jeff
<helix> I want to see if I can prove something
<helix> jbailey: do you like m4?
<mdz> I never said I _liked_ m4
<jbailey> Heya Andrew
<helix> mdz: hush
<jbailey> helix: Errr..   It's good for some things.
<mdz> but it was not an unreasonable tool for this job
<jbailey> helix: I'd rather maintain my sendmail config with m4 than by hand.
<zul> hey jbailey 
<jbailey> helix: I think that a less sucky tool could've been chosen for autoconf.
<helix> see, only crazy people like it
<bob2> if you have a sendmail config to maintain at all, YHL, HAND.
<ajmitch> selinux policies use m4 :)
<helix> when mdz outcrazies a hurd hacker...
<mdz> helix: you were going to use his answer in support of your position regardless of its content :-)
<mdz> I'm onto you
<helix> maybe! I should be a lawyer
* helix skates off into the sunset
<jbailey> mdz: The fact that I prefer sendmail also seems to make me as less crazy.  Go figure =)
<mdz> sendmail is teh sux
<ajmitch> bbl
<mdz> I have broken almost all of my hysterical raisin habits
<mdz> m4 is the last bastion I think
<helix> you had raisin habits?
<jdub> jbailey: you prefer sendmail?
<jbailey> jdub: Yeah.
<jbailey> jdub: Although postfix seems to be nice for a small system.
<helix> "why did we hire this guy?!"
<bob2> haha
<jbailey> jdub: exim4's config make sendmail's look simple.
<bob2> I'm pretty sure there's a clause about this sort of thing...
<jdub> jbailey: exim is wank
<helix> jdub likes ezmlm
<jdub> postfix is great for huge systems
<jbailey> jdub: I don't know the slang.  Is that 'wank' like, don't do this in public, or 'wank' like it feels good?
<jdub> don't give postfix that pat-on-head little-boy business!
<jdub> jbailey: wank like wanker
<jbailey> It didn't look possible to configure rewrite rules that get triggered when certain headers are set in an email.
<jbailey> Sadly, something the two main systems I used to work on need.
* jdub celebrates postfix's regularness.
<jdub> tables, not mini languages :-)
<jbailey> Lovely, until you're running a multi-thousand domain hub. =)
<jdub> i've never needed a mini language in my big installations
<mdz> Good evening folks, and welcome to #ubuntu-devel Weekend Edition
<mdz> this week, MAIL
<jbailey> One thing I did like with postfix is that it was far easier than sendmail to have multiple alias files.
<jdub> always felt like murky bad hack poo to me
* ..[topic/#ubuntu-devel:jdub] : Ubuntu Development WEEKEND EDITION | #ubuntu for support and general discussion | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals
<bob2> this is like the SMH/Sun Herald difference?
<helix> that topic is funny looking
<jdub> bob2: i hope so!
<jdub> i mean
<bob2> haha
<jdub> i don't know what you mean
<bob2> jdub: you may have noticed subtle difference between the two newspapers
<jbailey> And thinking of obscure nastiness, get it while it's hot people.  Grub2 for ppc compiled as a .deb: http://people.ubuntu.com/~jbailey/grub2/
<jdub> boobies
<helix> where is grub for sparc?
<jdub> jbailey: is grub cool?
<jdub> grub2
<jdub> like, this one's actually cross-platform?
<jbailey> helix: The openfirmware stuff is working well enough for PPC, so the ugliest of the porting is done.
<mdz> grand-er and unified-er?
<helix> woo!
<helix> silo-b-gone
<jbailey> Probably have some 64bit suckage to dealwith on ultrasparcs.
<helix> foo, that's what I have
* jdub calmly waits for colo-b-gone before blessing grub2 ;-)
* helix offers it for sacrifice
<jbailey> jdub: Yeah, they've done a passable job of keeping bits separate.  They have a module based system, and you just link in the modules that you want (filesystems, etc).  I haven't inflicted it on my PC yet, but I've been using it on my PPC for about 2 weeks.
<jbailey> I got the menu running about 20 minutes ago.
<jdub> nice
<jdub> let's ship it with hoary
<jdub> WELCOME TO WEEKEND EDITION!
<jbailey> jdub: It's already in universe.
<jdub> where the laughter is non-stop!
<jdub> so bill maher is not on tv anymore?
<jdub> oh
<jdub> down season
<mdz> yeah
<mdz> mythtv is ready to pounce when he comes back
<jdub> :)
<jdub> i was hoping to subscribe to new rules rss
<jdub> but there doesn't appear to be a feed
<helix> mmm, feeds
<helix> syndication is yummy
<jbailey> Yay!  Angie has arrived safely in Cuba.
<jbailey> Whups, ECHAN.
<helix> jbailey: yay anyway :)
<jbailey> helix: =)
<jdub> mdz: is mythtv shippable?
<jdub> hrm, n/m
<jdub> seriously
<jdub> if we let ogra loose on all the shitty little embarrassing ui bits
<jdub> we're going to have MovieOS in *no* time
<ironwolf> MovieOS bad.
<bob2> no way
<bob2> I've always wanted a 3-d file manager on IRIX.
<Treenaks> bob2: that's SO Jurassic Park 
<bob2> this is unix, I KNOW THIS.
* lamont sleeps
<Treenaks> g'night lamont 
<thully> Hi - I'm not going to have much time to respond/follow up on my bugs in bugzilla for a few months - what should I do?
<YokoZar> Would it be wrong to associate Wine with all of the MIME types here: http://filext.com/detaillist.php?extdetail=EXE
<YokoZar> In particular I'm concerned about "application/octet-stream" - are there thing that use that mime type that aren't windows executables?
<bob2> yes
<bob2> you can't associate that with wine
<rubenv> YokoZar: octet-stream is used pretty commonly for sort of unknown binary files
<rubenv> e.g. CHM files
<YokoZar> Ok, but what about the rest of them?
<YokoZar> application/x-msdownload, application/exe, application/x-exe, application/dos-exe, vms/exe, application/x-winexe, application/msdos-windows, application/x-msdos-program, application/x-zip-compressed seem to be good, yes?
<rubenv> do those mime types even appear on linux?
<bob2> I don't know that trying to run stuff in wine automatically is a great idea
<YokoZar> (x-zip-compressed is for self extracting things)
<YokoZar> When opened by double-clicking?  Why not?
<bob2> a) it may not work, b) how often is that actually useful?
<ajmitch> some of those may be associated with mono as well
<YokoZar> Hmm...
<YokoZar> Mono is a problem...
<rubenv> most wine things provide wrappers (as mono does)
<bob2> do people really want to run random windows crap by double-clicking?
<rubenv> bob2: or worse, unsuspectingly from their emails
<ajmitch> I think mono may pass things over to wine if it's not an IL executable
<YokoZar> Yes, actually.  I got a few letters from users kind of impressed about how they could download and run an exe and double click it and go, heh.
<bob2> I'd hope evolution/etc are smart about that.
<ajmitch> I thought wine used to use binfmt-support?
<YokoZar> Yeah Wine does that too.  
<YokoZar> I'm mostly interested in what happens when I click one on Firefox
<YokoZar> The "open with wine (default)" thing should happen
<bob2> that seems horribly dangerous
<YokoZar> Or, rather, be given as an option (with save to disk being the other)
<YokoZar> Well the alternative is to require the user to save to disk, open up a terminal, navigate to the exe, and do "wine program.exe"
<bob2> yeah
<YokoZar> Since oftentimes the executable bit isn't set on the file (hence you can't make much use of binfmt)
<bob2> I'm still amazed people are really running random windows programs on ubuntu
<YokoZar> Wine's getting mighty good.  A user told me about being able to just click and download the party poker installer, double click it, and have it put an icon right on his desktop after installing.
* rubenv certainly doesn't want that in main :-)
<YokoZar> What's the "vms/exe" mime type?  I've never seen it prefaced by vms (usually application)
<YokoZar> rubenv: Why not?  When Wine gets good enough to run stuff, of course ;)
<rubenv> YokoZar: because wine brings in bad ideas, by basically stufing random executables in home dirs etc
<rubenv> well, it's not wine's fault, it's the whole bad windows logic
<YokoZar> Well, to be fair, you can always restart by nuking ~/.wine
<YokoZar> I would like to eventually see wine in main though, if for no other reason than it will allow us to port open source windows programs with winelib and make them into packages as well
<rubenv> still gives me the creeps :-)
<YokoZar> Wine will never get into main until we can make it secure, heh.  Then again day we start seeing winelib viruses rather than microsoft ones will be the day Linux has secured world domination
<bob2> are there any useful FS windows programs that don't have ports already?
<bob2> aside from maybe virtualdub
<rubenv> yeah, I see more light in just building alternatives
<rubenv> then running slow wine progs
<YokoZar> Yeah, eMule
<YokoZar> Things like that
<YokoZar> Lots of OSS is developed on Windows (DC++ comes to mind as well).  Miranda Instant Messenger is another popular one (which we have gaim, of course, but it would be a cool universe package)
<YokoZar> And you should know better than to say that wine progs are slow.  Wine is not an emulator :p
<YokoZar> In theory, though, a very working Wine in main would allow people to just pop in a software CD (say, Half Life 2) and start going like it wasn't anything special.
<bob2> emule is already on linux
<bob2> dc++ is already on linux
<YokoZar> amule is not like emule (it misses the serverless network and lots of features) - the DC++ client is a lot better than the Direct Connect linux clients.
<YokoZar> And, of course, running them in Wine only lets you do it on i386 architecture (we could get eMule running in PPC if we recompiled it with winelib)
* enrico hugs helix
<helix> haha
* helix hugs in three channels
* Mithrandir wonders why xorg asks all its questions.  Twice.
<Mithrandir> three times.
<dholbach> hai
<ajmitch> hi dholbach 
<daniels> Mithrandir: wtf?
<daniels> Mithrandir: worksformehthkthxbye
<daniels> oops, forgot hand
<dholbach> hi ajmitch!
<dholbach> damn... spamassassin on my router doesnt work anymore :-(
<mdz> Mithrandir: in what context?
<_mvo_> mdz: what do you think about #2281 ("apt: if cdrom not found then use online files")? save enought to merge or rather leave it for later?
<dholbach> hellas _mvo_
<_mvo_> hi dholbach 
<justdave> I had that same thing happen when I updated the other day
<justdave> debconf asked me all the xserver-xorg questions three times in a row
<daniels> justdave: huh
<daniels> please both of you file a bug with as much info (xserver-xorg/* from /var/cache/debconf/config.dat et al) as you can possibly muster, severity major, package xserver-xorg, assigned to daniel.stone@ubuntu.com
<justdave> I asked in #ubuntu at the time and it was blamed on upgrading apt at the same time because the new apt asked the questions at a different point in the install process. (or so I was told :)
<daniels> won't look at it for a few days though
<daniels> justdave: hm
<daniels> mdz: ?
<daniels> hm, I know what it might be
<daniels> please file the bug and include this line so I can remember -- I think it's checking the wrong variable for reconfigure-or-not
<mdz> daniels: ?
<justdave> ok, it's bug 6484
<mdz> _mvo_: hmm, isn't there a bug (both in the old and new code) in the case of EOF on stdin?
<mdz> there are other places in the code which had similar problems in the past
<daniels> mdz: see justdave's comment
<mdz> ah
<mdz> what's the question for me?
<mdz> (or did you mean something other than his coment with the bug number)
<mdz> justdave: apt asking questions at a different point?  sounds like more urban legend
<daniels> mdz: ok, so it's just random bong :)
<_mvo_> mdz: yes, I'll fix that. do you feel that a bug-fixed version is save :) ?
<justdave> found it in scrollback, mebaran151 was the source of the silly apt excuse :)
<dholbach> mdz: i could imagine the questions were asked for xserver-common xserver-org and maybe a third package too
<mdz> _mvo_: I think it is probably safe, but would prefer to hold off on any further feature work until after Hoary
<mdz> _mvo_: and rather spend the time stabilizing existing features (update-*, gnome-app-install, etc.)
<_mvo_> mdz: agreed, it's just a nice to have. we can easily defer it if you feel uncomfortable about it
<_mvo_> mdz: stabilizing is my next goal. I will have to ask jdub about his plans for gnome-app-install, I'm not really involved there (apart from providing the backend)
<mdz> _mvo_: has the update-notifier hook facility been tested?
<YokoZar> Holy crap, I segfaulted gcc
<mdz> _mvo_: it would also be good to test CD-based upgrades
<YokoZar> When I uupdated the latest Wine package for the new wine release I now get a segfault in the compiler when it's building
<YokoZar> (this is building on Warty) - does Hoary have a later GCC?
<_mvo_> mdz: I tested it localy while developing it. but IIRC the utf-8 installer is the first "real" application that uses it
<mdz> I thought I saw the utf8 migration tool uploaded, but I can't find it now
<_mvo_> mdz: read cd based upgrades will only work when update-notifier is runing. for the warty-hoary upgrade cd-based upgrades will be not-overly-nice because the cd is mounted noexec and the user will have to either add the cd with synaptic by hand or run "python /cdrom/cdupgrade" :/
<mdz> _mvo_: yes, but it will be nice for hoary->hoary+1 upgrades
<mdz> but only if it is tested before hoary releases :-)
<_mvo_> mdz: yes :) 
<dholbach> hi pitti
<pitti> Morning
<mdz> night
<_mvo_> night mdz 
<daniels> mdz: 'night dude
<enrico> Hello.  Question about bugzilla: when someone reports a problem with the docteam, bugs get assigned to my e-mail address.  However, that gives the impression that I'm taking care of them, which is not necessarily true.  Is there a way to assign the bugs to "nobody", so that it's clear that they are there to be picked up?
<dholbach> "morning" ogra ;-)
<ogra> moin
<YokoZar> Hey.  New version of Wine is out...trying to get my package to build, but GCC seems to be segfaulting at random parts.  If I do get it to compile, though, can I have you put it up in universe after I upload it to winehq.org?
<daniels> YokoZar: stop overclocking and/or get better memory
<YokoZar> No overclocking here, though that might explain it. Maybe I should turn up my processor fan.
<YokoZar> I think I ran memtest earlier.  It could just be a GCC bug (it's been updated minorly from warty to hoary and I'm compiling on Warty at the moment)
<ogra> YokoZar: if you want to be a MOTU, you should track the ubuntu-users list.... there is a long thread from tonight where someone needs wine help :)
<YokoZar> I hope he's not running the really old universe packages, heh
<YokoZar> Thanks for the tip, I should subscribe, heh
<ogra> YokoZar: probably....but as you have updaqted ones in your repo, you could point there
<ogra> YokoZar: to have someone in the community testing them ;)
<YokoZar> most of my testers write to the Wine users list, heh
<ogra> YokoZar: oh, and till malone is ready, the ubuntu-users list is our bugtracking systen :-P
<ogra> for universe....
<YokoZar> Sounds reasonable.  
<mantiena> daniels, hi, I wanna talk about best default resolution, do you have some time ?
<YokoZar> The problem is... I don't know the answer to his question
<daniels> mantiena: no time right now, sorry
<YokoZar> http://lists.ubuntu.com/archives/ubuntu-users/2005-February/022096.html
<daniels> mantiena: but i did seem to notice that you filed the bug about 85 or 100hz twice?
<YokoZar> I've gotten several reports about the winehq apt repository being screwy, but I think this has to do with sourceforge being unreliable more than anything else
<daniels> mantiena: (6470 and 6480)
<mantiena> daniels, yes, I accidently pressed refresh button this morning to view new comments, but firefox filled new bugreport instead :(
<amu> enrico: probably the best, if the docteam define an mailalias where the new bugs goes to, assigned to noone isnt a good idea, practically bugs are lost in nirwana, elmo can change your assignment.
<daniels> mantiena: ah, right
<mantiena> daniels, should I close duplicated ?
<daniels> mantiena: please close 6480 as a duplicate of 6470, yes
<mantiena> daniels, ok, when you will have some time to talk just do /query mantiena ;)
<ogra> YokoZar: have you seen the initial mail on this thread ? the OP wants to run VB scripts under wine....is that possible ?
<daniels> probably not until next week
<enrico> amu: good idea.  Is it possible to have mailaliases defined like @docteam.ubuntu.com ?
<daniels> but see my comments in #6470
<enrico> Or maybe we could just set that to the ubuntu-doc mailing list.
<mantiena> daniels, ok, as I understand xresprobe does resolution selection, right ?
<daniels> mantiena: yes, the smarts are in ddcprobe.sh
<amu> enrico: you should ask elmo, with the kubuntu, we defined an external alias 
<enrico> Let's try to see what happens assigning to the ubuntu-doc list
<mantiena> daniels, thanks for info
<daniels> np
<YokoZar> ogra: Ahh, guess I wasn't looking closely.  You can do it if you install the visual basic runtime (which most apps which use it seem to do)
<amu> enrico: everyone think, the other one already take care care ? ;) 
<dholbach> is a warning like  libtool: link: warning: `/usr/lib64/libgtk-x11-2.0.la' seems to be moved  considered to be ok?
<enrico> amu: at the moment everyone things I already take care :)
<ogra> YokoZar: ah, ok... 
<amu> enrico: heh
<daniels> dholbach: how on earth did you get /usr/lib64 in the first place?
<enrico> amu: uhm... reassigning to the list seems to be a problem, as the list is not subscribed to bugzilla.  Is it too impolite to subscribe it?
<amu> daniels: did you found same time for the keyboard bug (remember no @ and | with a german keyboard)  
<ogra> daniels: amd64, i get the same warniongs here
<daniels> amu: not at all
<daniels> amu: and not until next week, sorry
<daniels> i suspect the problem is pc104 vs pc105
<dholbach> daniels: i wanted to have a look at what's going wrong with evolution on amd64 and built it with pbuilder
<daniels> it'll make it in for hoary, but probably not even next week
<amu> enrico: think so, probably you should discuss it with your team, before assigning them to the list.
<enrico> amu: I wanted to try that out before discussing, so that we'd have something to discuss about
<enrico> amu: however, I'm not the moderator and the bugzilla mail isn't reaching the list
<amu> daniels: np, whenever you've time for it. I'm wondert about other langs, they have not this problem 
<daniels> amu: sure ... i'll check it out as soon as i get some time, but i'm swamped for a while, sorry :\
<amu> enrico: as i said, practically, everyone think, the other one already take care ;)
<amu> enrico: no prob, the moderator can define a whitelist entry for the entry.
<enrico> amu: sure, but I can't get to the moderator right now :(
<ogra> enrico: malone should be ready soon (referring to bradb) we are waiting for it for MOTU....probably something to consider for the doc stuff too...
<enrico> ogra: after hoary maybe?  We fear changes before deadlines
<ogra> ah, ok...
<sivang> Morning all!
<dholbach> hi sivan!
<sivang> dholbach: hi daniel, 'sup?
<ogra> morning sivang
<amu> hey sivang 
<dholbach> <- shower
<sivang> hey amu :)
<zul> morning
<dholbach> elmo: ping
<dholbach> elmo: alright... just read my mails :-) THANKS!
<Mithrandir> daniels: when upgrading with a hand-changed xorg.conf
<Mithrandir> seb128: you've broken nautilus as well now. :(
<daniels> Mithrandir: bong.  i'll check it out next week.
<daniels> Mithrandir: if you want to solve that itmt, sweet deal
<seb128> Mithrandir: what with nautilus ?
<Mithrandir> seb128: segfaults on startup on amd64; I haven't traced it any more than that yet.
<seb128> do you have a backtrace ?
<Mithrandir> not yet.
<seb128> k
<Mithrandir> I'm going to try find what the problem with evo is first.
<Mithrandir> ogra: do you have problems with nautilus falling over ATM?
<ogra> nope
<Mithrandir> are you up-to-date?
<ogra> as far as i can....(i version locked the evo package and some libs.... which affects gnome-panel, the address lookup applet and some others)
<Mithrandir> can you do it in a chroot or something, possibly?
<dholbach> Mithrandir: i have the most recent nautilus on amd64 too
<Mithrandir> dholbach: and it works?
<dholbach> Mithrandir: yes
<Mithrandir> hm
<dholbach> Mithrandir: do you have a "crash-test-case" for me?
<Mithrandir> dholbach: "starting nautilus". :P
<dholbach> Mithrandir: works fine :-)
<Mithrandir> it works if I run it without any WM, though.. :P
<ogra> Mithrandir: tried a new user ?
<Mithrandir>                http://www.scottybob.com/video/customer.videos/paul.k.mov
<Mithrandir> sorry, wrong paste.
<Gagatan> hehe
<Mithrandir> seems like pasting from inside an Xnest is icky.
<Gagatan> Mithrandir: ubuntu-people not interested in telemark? ;)
<daniels> Mithrandir: ... yes
<marcin_ant> hi developers - any "java on ubuntu" here?
<Mithrandir> Gagatan: it's not really relevant for Ubuntu development, no. :P
<Anubis> I have to simple issues that no one on the board or #ubuntu seems to be able to answer
<Anubis> I understand there is some problme with udev?
<Gagatan> Mithrandir: right.. more an issue with _sn_frix ;)
<Anubis> my /dev/cdrom and /dev/dvd symlinks keep disappearing at boot
<Anubis> breaking the eject cmd
<Anubis> I have to eject /dev/hdd
<Anubis> or such
<Anubis> the other issue
<Anubis> I can't seem to be able to enable hdparm's dma on my cdroms at boot
<Anubis> how do you guys do it in Ubuntu
<Anubis> my hard drives have dma at boot
<Anubis> but not my rom devices
<Anubis> do you use a kernel cmd?
<Anubis> a script for hdparm at boot?
<Anubis> I tried the hdparm script but it returns errors on boot
<Mithrandir> dholbach: do you have any shares on the desktop?
<dholbach> Mithrandir: no
<Anubis> I'm about ot continue my research
<Mithrandir> try adding one
<Mithrandir> seb128: it tries to allocate about half a gazzillion terabytes of memory, which fails.
<Mithrandir> 1844674407117266544 bytes, to be exact.
<dholbach> Mithrandir: you mean gnome-user-share?
<Mithrandir> dholbach: the "connect to server" thingy.  I have a few SSH shares on my desktop
<dholbach> Mithrandir: ok... i already have such a share
<seb128> Mithrandir: urg, weird
<Mithrandir> seb128: you want the bt in /msg?
<Mithrandir> (it's 14 steps deep)
<seb128> Mithrandir: k
<Mithrandir> seb128: already pasted.
<seb128> Mithrandir: could you do the same with nautilus-dbg installed ?
<Mithrandir> sure
<seb128> and paste it on http://rafb.net/paste/ rather
<Mithrandir> what's the right way to make sure I use the debug package?
<seb128> look on the backtrace :)
<seb128> or attach the process with gdb and look if it finds the symboles or not
<Mithrandir> it found them
<Mithrandir> seb128: http://rafb.net/paste/results/G6xz9R37.html
<seb128> Mithrandir: thanks
<seb128> Mithrandir: does it crash if you run it in --no-desktop ?
<Mithrandir> seb128: nope, looks happy then
<Kamion> Mithrandir: wow, 1.6 exabytes, nifty
<Mithrandir> Kamion: I'm cheap and don't have that amount of memory in my desktop system. ;)
<Mithrandir> elmo: could you please sync db4.1?
<elmo> done
<Mithrandir> thanks
<zul> anyone got a recommendation for an rss reader?
<dholbach> zul: liferea
<zul> dholbach, thanks
<seb128> Mithrandir: it crashses since the update ?
<Mithrandir> seb128: I updated my desktop this morning; I guess I haven't updated in a week or so (150MB-ish download), so I'm not sure what the old versions were.
<seb128> Mithrandir: could you try to downgrade to the previous nautilus version ? 
<Mithrandir> sure
<Mithrandir> upstream version or debian revision?
<LBM> zul: blam is quite good
<mantiena> Kamion, hi
<dholbach> good bye guys... i'm off until tomorrow - partying :-)
<seb128> Mithrandir: previous package which is the previous upstream version
<Mithrandir> ok
<Kamion> mantiena: hi, but bye, I promised to mow the lawn today ...
* Mithrandir goes hunting in the morgue
<bob2> crazy norwegians!
<zul> oh if anyone read the new linux journal there is a review about ubuntu
<Anubis> please
<Anubis> what happened to /dev/cdrom?
<Anubis> what happened to /dev/cdroms/cdrom0?
<Anubis> what happened to /dev/dvd?
<Anubis> don't I NEED these?
<azeem> Anubis: try in #ubuntu
<Anubis> azeem, no seems to be able to answer this
<Anubis> thats why I'm asking the guys who know
<azeem> then ask the question in #ubuntu again later 
<Anubis> my contact in #ubuntu is away crimsun
<Anubis> he usually helps me
<azeem> roughly the same people are in both chans anyway
<zul> then ask someone else in #ubuntu
<zul> lamont: is that kernelpage valid?
<zul> er...in the wiki
<amu> seb128: gnome i18n will be extracted to the language-packs? 
<lamont> zul: dunno
<zul> works for me atleast 
<seb128> amu: ?
<seb128> amu: the mo files ? They already are in the packs
<amu> seb128: ok, the problem is about 180mb kde-i18n which is a real waste of diskspace
<Kamion> urgh, I never noticed that system-config-kickstart failed to build, damn
<Kamion> hopefully fixed
<seb128> amu: is that a way to say that kde is crap ? I know about it :p
<seb128> amu: gnome has not global i18n package, every tarball include its translation
<amu> Kamion: small problem, user install kubuntu, let's say he use the great german lang, how d-i knows that he should install kde-i18n-de ?    
<Kamion> amu: it doesn't, yet
<Kamion> we can fix that though - but not now :)
<Kamion> s/now/today/
<amu> seb128: hehe, finally it's the same, doent matter if your have i18n in a tarball or a sperate package :)
<seb128> amu: it's really not the same, if you want to change 1 translation in kde-i18n you have to upload the whole stuff, that's insane
<amu> Kamion: sure not today.   
<Kamion> seb128: ... welcome to language packs :P
<Mithrandir> seb128: old version works fine
<amu> seb128: but after a release the langpacka and packages are static, means they will never change
<seb128> amu: I was talking out of the language packs
<seb128> amu: you don't have to deal with the 180M of kde-i18n with them
<amu> seb128: sure, i'm talking also about langs stuff, i get a releae, and kde-i18n will be packaged. It will not updated anymore      
<seb128> I think I don't get the question in fact
<amu> let's say you have gnome 2.8 which is in warty.    
<amu> lets say i have kde 3.2.3 in warty 
<amu> it's the same size, if i have sperate i18n files compared to the i18n inside a package.     
<seb128> correct
<mantiena> Kamion, did you fixed bug "parted-udeb should depend not only on libc6 but also on libparted" ?
<amu> the only possibility is, if we ship the d-i supported langs, guess it will be less than 50mb   
<mantiena> amu, yea, ship at least d-i supported languages, lithuanian language is very important and takes little space ;)
<amu> Kamion: could we speak monday afternoon about it?
<amu> mantiena: if d-i supports *eg* 
<mantiena> amu, do you think I told this if lithuanian language isn't in d-i ?
<mantiena> :-P
<Simira> smurfix: ping
<smurfix> Simira: pong (, even)
<goedson> I've just tried to upgrade my machine from warty to hoary and I'm not able to boot it anymore.
<goedson> It isn't possible to run any program when try to boot it.
<goedson> I get "Can't run /sbin/shutdown" when I hit CTRL+ALT+DEL on the console. 
<goedson> Any ideas?
<Kamion> mantiena: I have not been at my computer very much since last night. It's a weekend.
<Kamion> amu: sure
<mantiena> Kamion, ok, so I must report a bug ?
<Kamion> 23:30 < Kamion> mantiena: well I haven't fixed it yet, so feel free to report :)
<mantiena> Kamion, long memory ;)
<Kamion> that said, I can fix libparted-udeb's provides now, which might fix it as a side-effect
<Kamion> did somebody already mention to haggai that openoffice.org2 needs to be rebuilt against current libedataserver?
* Kamion is trying to get germinate warnings down to the point where they're actually useful
<Kamion> mantiena: ok, I've just uploaded a fix to parted-udeb's dependencies
<Mithrandir> seb128: the evo bug seems to be a bug not in evo, but something else involving libroken
<seb128> any idea of what ?
<Mithrandir> not sure, just linking something against eshell and roken triggers it.
<seb128> k
<Mithrandir> but then, linking against eshell means you link against 87 of the 90 libs evo links against. :P
<Mithrandir> lamont: please adjust PaS to build avifile on amd64 as well
<lamont> Mithrandir: done - now you just need elmo to sync pas...
<Mithrandir> lamont: he does that once in a while by himself, or?
<lamont> generally he gets nudged - although he may well get notified anyway
* Kamion goes, likely for most of the rest of the evening; may check in once
<Mithrandir> elmo: please sync PaS. :)
<lamont> later Kamion 
<T-Bone> hmm, today's iso seems to work fine on zx2000. let's see if elilo works as well
<zul> T-Bone: how is it going?
<T-Bone> zul: 'copying remaining packages' atm
<zul> vool
<T-Bone> without having to press 'ok' for a bogus reason at any time
<T-Bone> which is pretty nice ;)
<zul> worked on any ppc stuff?
<T-Bone> no
<T-Bone> had no time
<zul> ok
<T-Bone> hmm. Things aren't as smooth as it seems
<T-Bone> the installation process went back to the general menu after setting up a normal user
<T-Bone> 'configure apt' doesn't work. Nor does 'install bootloader' ;(
<zul> hey mdz
<mdz> hey
<mdz> brb
<Mithrandir> seb128: this is fun.  Link something with libroken and libpthread.
<Mithrandir> on AMD64, it goes boom!
<T-Bone> how bizarre. If i stick a 'set -x' in elilo-installer.postinst, the bootlaoder installs fine ;P
<T-Bone> https://bugzilla.ubuntu.com/show_bug.cgi?id=1619 <- zul: is that actually a "bug"?
<T-Bone> mdz: re what was said on u-devel: shouldn't 3281 be marked as NEEDINFO? it has remained without answer for several months, if we want not to forget it when sending reminders, maybe that kind of bugs should be tagged NEEDINFO?
<mdz> T-Bone: bugzilla doesn't allow you to reassign a bug and mark it NEEDINFO in one step
<mdz> so if they report against the wrong component, it generally won't be marked NEEDINFO
<T-Bone> hmm. so we just let these bugs out in the void?
<T-Bone> mptscsih issue on zx6000. gack
<zul> T-Bone: not sure what to make of it
<T-Bone> zul: 'it' ?
* Mithrandir decides to blame doko
<Mithrandir> seb128: why is kerberos support in evo enabled?
<zul> 1619
<T-Bone> ah ok
<Mithrandir> at least, why is kerberos4 support enabled?
<bluefoxicy> mdz:  you busy?
<T-Bone> zul: the problem is that among the huge number of bugs, seems that quite a lot are somehow 'irrelevant' (missing information, not for us and so on...) (not to mention what was said on u-devel: some needinfo bugs never got any additional feedback...)
<T-Bone> zul: if we don't decide to take action on these somehow "dead bugs", the bug count will never decrease...
<T-Bone> hmm, so as i suspected, Debian loads mptscsih at the same time it loads mptbase: from initrd
<zul> T-Bone: i realize that my suggestion is see if there is any response to the bug and wait a couple of more days if there isnt a response then mark it as needinfo, users can re-open it
<T-Bone> zul: ok, i roger that for 1619 (even tho the report is already several months), but if you look at 3281, last request for data is also several month old, without feedback...
* T-Bone grabs linux-meta source to check what goes on ia64 initrd
<zul> T-Bone: yeah its a needinfo
<mdz> T-Bone: what "void"?
<T-Bone> mdz: have you looked at 3281?
<T-Bone> as zul noted, i think it should be tagged needinfo
<mdz> T-Bone: of course.  If you look at the bug activity, you will see that I have looked at it several times.
<T-Bone> yes.
<mdz> you are both absolutely right that it should be marked NEEDINFO, and zul has actually marked it as such
<T-Bone> several month ago. Hence my suggestion to mark it 'needinfo' so that when we'll start sending out advice before closing bugs for lack of feedback, it doesn't get forgotten
<T-Bone> heh ;)
<seb128> Mithrandir: why not ?
<T-Bone> is there an easy way to netinstall Ubuntu? I mean *without* booting from CD
<T-Bone> everything being done from network
<mdz> yes, of course
<T-Bone> mdz: can you educate me about that?
<mdz> T-Bone: it is documented in the installation manual
<mdz> and there are howtos in the wiki
<T-Bone> hmm
<T-Bone> on FrontPage, if i click on "Installing Ubuntu" it sends me to a rev search on "FirstSteps" but not to the FirstSteps page
<Mithrandir> seb128: because libroken is broken.
<seb128> Mithrandir: in fact evolution-exchange was built with it and not evolution/eds first, which breaks evolution-exchange
<Mithrandir> it redefines h_errno, which breaks with pthread
<seb128> hum
<seb128> why does it break only on amd64 ?
<Mithrandir> grep for "checking for h_errno" in the krb4 configure logs.
<Mithrandir> anyhow, since I've tracked it down, I'm goddamn going to fix it as well
<seb128> thanks!
<sladen> T-Bone: if you ask on #ubuntu I can send you a tarball with all the necessary
<mantiena> Kamion, so, no need to report parted dependancies bug :)
<Mithrandir> this is fun:
<Mithrandir> configure:34949: checking for h_errno
<Mithrandir> configure:34973: gcc -o conftest -g  -g conftest.c -lresolv  >&5
<Mithrandir> collect2: ld terminated with signal 11 [Segmentation fault] 
<zul> later..
<T-Bone> sladen: are you being sarcastic?
<sladen> T-Bone: to be fair, it would save me the hassle if you didn't ask :)
<T-Bone> sladen: may I ask you what makes you being so downlooking at me?
<T-Bone> hmm, in fact i don't care. I'll just ignore you from now on.
<mdz> bluefoxicy: my followup to the list should adequately explain my position
<bluefoxicy> mdz:  kay.
<bluefoxicy> mdz:  the one to paul sladen?
<mdz> no
<bluefoxicy> ok.  *waits for his mail server to catch up then*
<wasabi> package versioning question: I have an upstream which is versioned at 0.7.1pre3. I suspect they will release that as 0.7.1
<wasabi> I thinking about this ~ thing I've been hearing about. Is this a good use for it? 0.7.1~pre3?
<wasabi> i dont know if that's even good for ubuntu at this point though. ;l)
<T-Bone> zul, lamont: ping?
<sladen> mdz: mkisofs knows about shareing files between HFS/ISO volumes, I didn't look at intra-volume.  What's important for cloop is just the offsets, the actual 'file' can/could be the ISO device itself with cloop told to skip the first X sectors find its offset table at point N
<mdz> sladen: right, hardlinks are sharing entire files under different names; you're talking about using pieces of multiple files at different offsets in a different file
<mdz> anyway, off to SCALE
<sladen> mdz: yup. (which is what the HFS/ISO sharing is, same sectors, different FS tables)
<Mithrandir> checking for h_errno... yes
<Mithrandir> checking if h_errno is properly declared... yes
<Mithrandir> yay
* Mithrandir notes the patch to achieve that is around 1.8MB
<AndyR> lo all
<AndyR> can anyone please help me with a Xorg resolution prob using nv server, im only able to get 640x480
<T-Bone> fabbione: ping, maybe? :)
<thom> T-Bone: he's currently getting married, AIUI
<T-Bone> thom: lol, true :)
<daniels> yeah, fabbione is unpingable for a while
<thom> so, unlikely to be available on irc
<HrdwrBoB> apparently also IRCing on your honeymoon is bad form
<T-Bone> hehe
<thom> HrdwrBoB: yeah, i've heard that too
<daniels> HrdwrBoB: hey, you can if you want ...
<zenrox> but thay dont recomend it
<daniels> taking your ps2, gta:sa, and a laptop for irc on your honeymoon cruise is generally considered bad form
<HrdwrBoB> :/ that was what ambr said not me
<zenrox> lol
<T-Bone> anyone knows zul's email?
<daniels> zul@gentoo.org
<T-Bone> thx
<mantiena> amu, still alive ?
<mjg59> Hmm. Warty->Hoary upgrade is prompting me on a load of config files
<haggai> Kamion: I'm doing a new OOo2 upload anyhow
<Hwolf> haggai: Do you use OOo2?
<amu> mantiena: yep
<lamont> T-Bone: moo
<haggai> Hwolf: not as much as I need to to find all the bugs :)
<T-Bone> lamont: groo! Got mail
<lamont> yeah - just reading it
<Hwolf> haggai: Do you know how to have OOo2 put out a decent .doc?
<haggai> Hwolf: I don't know what you mean.  I haven't tried exporting many .docs, only importing them
<Hwolf> haggai: I need to do the exact oposite and send something I made to one of the poor sheep in this world that believes that word is the awnser for the world's problems.
<Hwolf> haggai: and unlike in OOo1, in 2 I haven't had any luck.
<opi> Hi there :)
<haggai> Hwolf: I'm just uploading a new milstone, your problem could be fixed in there already
<Hwolf> haggai: i'll try using it and reporting the bugs. I'm the guy whose mail you awnsered.
<Hwolf> I feel that this one open bug for OO2 is lonely, it'd be rude to leave it so
<jdub> good morning freedom lovers!
<Hwolf> jdub, last time I checked, it was 11:36 pm
<amu> moin jdub 
<opi> Hwolf, mind a different time zones ;)
<opi> hi jdub 
<Nafallo> evening jdub :-)
<Hwolf> opi: I'm reminding jdub of those. :-)
<Mithrandir> ogra: around?
<ogra> Mithrandir: yup
<opi> I'm using Freesbie now, and I must say they did a nice job on FreeBSD/LiveCD
<Nafallo> I just installed warty on my server (reinstalling now)
<opi> it's not as good as Ubuntu :-> but still useful
<opi> smurfix, ping
<smurfix> opi: 
<Nafallo> base-config looped at first boot see ;-)
<Mithrandir> ogra: could you test the nautilus stuff for me?  I think I have a fix.
<opi> smurfix, hi. So, can we talk about setting up moinmoin under ubuntu-pl.org? :)
<Mithrandir> ogra: it requires you to upgrade to the broken version and installing http://err.no/tmp/libroken16-kerberos4kth_1.2.2-11.1ubuntu1_amd64.deb
<Mithrandir> ogra: if that works, we're in business.
<opi> smurfix, unless your package is still not ready :)
<ogra> Mithrandir: okay
<Nafallo> like "info: something about ISO-8859-1\nstarting base-config" and those lines looped ;-)
<Mithrandir> ogra: if that doesn't work, but evo starts, we're halfway there. :)
<smurfix> opi: Sure. No it isn't ready but that doesn't stop me any more, I've hacked an installation on my system anyway.
<opi> smurfix, ok, what should I provide you with? :)
<Nafallo> the only thing I can think of that I didn't do was that I skipped copying the cd to harddrive. might that be the reason for this behavior?
<haggai> Hwolf: ah, ok thanks
<smurfix> opi: an ssh pubkey, in gpg-signed email
<Hwolf> Haggai: will OOo2 be a replacement for 1 in the final hoary?
<opi> smurfix, well, d'oh! I need to google how to set gpg for Thunderbird
<Mithrandir> opi: install m-t-enigmail
<Mithrandir> Hwolf: I doubt it.
<opi> Mithrandir, thanks
<opi> I need to write it down
<haggai> Hwolf: hopefully but it does need to be reasonably stable
<opi> smurfix, I'll write you back.
<Hwolf> haggai: then why is OOo1 in warty? :-S
<Mithrandir> haggai: how does ooo2 look 64bit-wise?
<haggai> Mithrandir: apparently there are enough patches working now to be able to start it without it crashing :-/
<Mithrandir> that's a start..
<Hwolf> haggai: Intel is starting to enable it on it's celerons, and it's in that state... :-S
<ogra> Mithrandir: you won 
<ogra> Mithrandir: :-D
<Mithrandir> ogra: it worked completely?
<ogra> Mithrandir: it not only starts....it also works ;)
<Mithrandir> _YAY_
<Mithrandir> that rocks.
<ogra> YEP
<Hwolf> haggai: so you don't know about word-compatibility?
<T-Bone> lamont: any feedback on what I said in the mail?
<lamont> T-Bone: uh.. none yet :-)
* lamont sends email
<T-Bone> lamont: lol. I'd especially like some feedback about the last question ;)
* lamont giggles that problem is abreviated pb in .fr as well
<lamont> aucun?
#ubuntu-devel 2005-02-24
* T-Bone tssks lamont 
<T-Bone> lamont: 'none'
* T-Bone sends lamont back to his French lessons :)
<lamont> dude that was like long ago.
<lamont> before you were born, I expect
<lamont> lessee....
<Nafallo> yikes! thanx T-Bone. I had forgot my homework again :-P.
<T-Bone> Nafallo: lol
<T-Bone> lamont: you're *that* old? :^)
* T-Bone ducks
<lamont> would have been the 1979-1980 school year
<T-Bone> indeed
<T-Bone> i was being conceived ;)
<lamont> well, at least someone was having fun that year.
<T-Bone> LOL
<Nafallo> GAAH! why can't I install warty on my server?
<smurfix> opi: Wiki is set up. Please register and tell me your WikiName.
<smurfix> bah, he's gone
<YokoZar> haggai: I've got a new Wine package uploaded and ready, is there a way you could put it into universe for me (and/or sign my key so I can do it? I could put my pubkey on the Wine website or something.)
<Nafallo> dooh! must have been /tmp I couldn't mount with noexec then :-P
<ajmitch> good afternoon
<haggai> YokoZar: I'm really sorry, I'm just winding down for the evening.  I need to review your work and I can't do that before Monday
<YokoZar> Aww...  Is the key signing thing a possibility though?  
<haggai> YokoZar: the holdup is in reviewing those changes for universe, signing an upload circumvents that
<YokoZar> Oh yeah, heh.  Just thinking ahead, though :)  I suppose in the meantime I can write that scrollkeeper OMF file for Wine I've been meaning to.
<haggai> YokoZar: keysigning is for proving your identity (ie meeting face to face) and isn't used to grant upload permissions
* haggai yawns and goes to bed, wishing YokoZar lots of fun with OMF files
<jdub> YokoZar: is it still one monolithic package?
* jdub steals haggai's pants
<YokoZar> Ahh, ok.  That means I'll need to take quite a drive down to the next LUG meeting, or grab some ID scans in the mail, heh
<YokoZar> jdub: It's split into wine and wine-dev (headers/includes)
<jdub> YokoZar: as well as libwine*, wine-doc, etc?
<haggai> jdub: now how am I gonna upload the new oo2 without any pants?
<jdub> freely :-)
<YokoZar> jdub: No, much of that splitting in the debian packages was both unneeded (Wine can autodetect most of its sound servers), confusing (the package didn't depend on them) and broken (Wine gets confused if it's missing files it always expects to have)
<jdub> YokoZar: splitting the libraries is very important
<jdub> YokoZar: splitting out the sound server stuff means you're not stuck with unnecessary depends (arts!)
<jdub> (jack!)
<jdub> probably best to start with the debian layout and fix the problems
<YokoZar> I tried that, but there were so many archaic hacks and stuff in the code that it really was causing more problems than it was worth. I understand the importance of splitting libs, but the libwine library can really only be used by Wine and the wineserver
<jdub> it does need to be split, though
<YokoZar> The files that were once included in the libwine-sound* packages are no longer really even seperable from Wine - it's hardly even any space saved
<YokoZar> jdub: It's impossible to run winelib-compiled files without the wine binaries though.  In effect everything would be in the libwine package.
<jdub> YokoZar: no, libwine would depend on wine :)
* jdub upgrades to the latest wine, checks it out
<YokoZar> Well, ok then.  But having two packages depend on eachother is more or less the same thing as a monolithic package, no?
<jdub> YokoZar: like libhowl requires mdnsresponder to work, so it depends on it
<jdub> YokoZar: no
<YokoZar> How's it different if they'll always be installed (and upgraded) together?
<jdub> means you can track library changes more sanely
<jdub> worth reading debian policy on this
<YokoZar> I have.  The trouble is that different winelib compiled programs (of which we don't yet have any...) all need to run off the same library through the same wine binary and the same wineserver - the normal differentiation you can get with different soname versions for different software just doesn't happen
<jdub> there doesn't seem to be any depends
<YokoZar> It's almost like a kernel/module type thing rather than a library.
<YokoZar> Wine doesn't really have any hard dependencies other than I guess glibc.  It can run in an X-less server terminal for DOS console apps, heh.
<jdub> but there are also no suggests...
<jdub> or recommends...
<YokoZar> Whoops, I probably wanted to put winetools into suggests.  Msttcorefonts should be in suggests already
<jdub> yeah
<jdub> so the big problem here
<jdub> is that this is a significant package fork from debian
<jdub> which we'll have to maintain indefinitely
<jdub> unless we rejoin
<jdub> we're hoping to avoid a lot of that
<ajmitch> ogra: ping
<ogra> ajmitch: pong
<ajmitch> ogra: see post on planet.debian.net on ubuntu & debian (3rd from top)
<jdub> yeah
<YokoZar> jdub: Correct, it is different, but it wasn't done without reason.  I'm willing to maintain it. We had to fork the package for some very good reasons, one of which was the outdatedness and presence of many old hacks in the Debian ones.  We were getting _many_ support requests in the user channel, email lists, and newsgroup all related to the weird brokenness of the Debian ones.  Our first support question became "Are you a Debian user?  
<ogra> ajmitch: ouch
<ajmitch> yeah, we need to do something about tracking changes I think
<jdub> YokoZar: the old hacks let you upgrade sanely
<ogra> ajmitch: hmm, but that change was senseless for debian...
<jdub> YokoZar: so we fix the problems with the current packages and contribute them back
<ajmitch> I think he was talking about the other changes aside from the build-depends
<YokoZar> jdub: I'm talking about old hacks like changes to Wine's sourcecode that were breaking things upstream, heh.
<ogra> ajmitch: it was my change
<ajmitch> maybe this is something that we have to do when malone is usable for universe
<ajmitch> ogra: that's why I pinged you :)
<jdub> YokoZar: so we fix the problems
<jdub> YokoZar: far cheaper to do that than maintain a fork
<ajmitch> am I allowed to upload new upstream versions of my apps, or should I ask for a sync?
<YokoZar> Not for me it wasn't.  Maintaining my Wine package has been only a couple hours of work or so every month.  Trying to get the obstinate Debian maintainer to write/commit patches himself, on the other hand, was an exercise in futility.
<YokoZar> I wouldn't even be consdering doing the Ubuntu MOTU route unless things were practically impossible in breaking through Debian beaurocracy.
<jdub> YokoZar: yes, those aren't going to be problems
<jdub> YokoZar: but maintaining a significant package for is something to be avoided
<YokoZar> True.  Frankly, things would be a lot easier if I were the Debian maintainer (packages would certainly be released within days, rather than months), but as long as Debian gives its maintainers total control over their packages and allows them to block the work of others (say, me), it's jut not going to happen.
<jdub> it can happen in ubuntu
<jdub> that's what we're here for
<YokoZar> And that's why I've fallen in love with Ubuntu, and want to contribute Wine to it :)
<lupusBE> gnome-nettool is now only depending on gconf :D
<lupusBE> and gtk :)
<jdub> ogra: i really liked the previous ACCESS DENIED :-)
<lupusBE> in what kind of freeze is gnome at the moment?
<wasabi_> So I'm looking for a good utility of some sort to get some sort of load graph for each of my HDs... suggestions?
<wasabi_> graphical, etc.
<lupusBE> jdub, ping
<jdub> yo
<wasabi_> fsrtmot
<wasabi_> darnit
<wasabi_> how do i keep typing in the wrong window
<wasabi_> sorry about that
<lupusBE> jdub, I have started removing libgnome code from some projects 
<lupusBE> but gnome_help is the most frequent used gnome function that is still not replaced by a gtk counter part
* T-Bone calls it a night
<lupusBE> do you know someone working on a replacement?
<mjg59> jdub: Dude, what's up with patches getting back into Debian?
<jdub> mjg59: lamont's working on it
<jdub> mjg59: i'm going to reply to norbert's post
<jdub> lupusBE: probably anders/owen/jrb
<jdub> lupusBE: kinda relies on the help system not= being a murky mess
<lupusBE> are there logs or mails about discuttions about this ?
<lamont> mjg59: and working, and working...
<mjg59> lamont: Haha
<jdub> lupusBE: no idea
<lamont> there's a boatload of 'em...
<mjg59> If it's just a technology thing, that's good
<lamont> and finding the ones that aren't there yet can be a pain.
<lupusBE> and what do you mean by murky mess?
<lamont> but filing bugs with all the full diffs in them would just tend to annoy folks more
<robertj_> heya all, are xdevconf logs available anywhere?
<lamont> nobody wants a bug with part of the diff being a s/Debian/Ubuntu/g :-(
<lamont> xdevconf?
<lamont> the package buildLogs?
<mjg59> X development conference
<robertj_> lamont: irc logs
<mjg59> But, uh, the only person here likely to know is daniels...
<mjg59> Hmm. I've just upgraded a clean Warty install to current Hoary. Quite a few config file change prompts.
<mjg59> On the other hand, I did accidently kill it part way through, which may have something to do with it
<robertj_> lamont: noone seems to be logging #xdevconf :(
<jdub> mjg59: the only non-technology issue is making sure our MOTU are doing the right thing ;)
<mjg59> jbailey: Hmm. We're going to need some way to auto-fill the RESUME field.
<ogra> jdub: no need to apply it if you dont like.... :) thom asked for a change ...
<ajmitch> jdub: just whip them into line
<lamont> speaking of diffs... /me goes heads-down for a while
<lamont> so do we want to file all the bugs for migrating to python2.4?
* lamont assumes "no"
<mjg59> APPROVED
<mjg59> Oh man
<mjg59> I love the screensaver stuff
<jdub> MovieOS in three releases!
<mjg59> Hrm.
<mjg59> Warty->Hoary update doesn't result in power button hibernation love.
* mjg59 goes to investigate
<jdub> hmm
<jdub> i'm going to install warty on my ibook and do an upgrade
<mjg59> I recommend doing so
<mjg59> Someone should write something to install a random set of packages from main on warty and then do an upgrade
<jbailey> mjg59: auto-filling the resume field?
<jbailey> mjg59: Err.
<mjg59> jbailey: On install, at least
<mjg59> Ideally on upgrade
<mjg59> But install has to have it
<jbailey> I thought that the kernel automatically DTRT when there was only one swap partition.
<mjg59> Nope
<ajmitch> afternoon jbailey  :)
<mjg59> Unless there's a resume= line, it won't resume
<mjg59> (Or the equivilent)
<jbailey> mjg59: Oh. hmm.
<jbailey> I was going by what mdz had said.
<jbailey> S3 works on my laptop now, so I never bothered with the rest of it.
<mjg59> jbailey: Suspend will work without a resume parameter, but I don't think resume will
<jbailey> Lemme ping mdz..  He never sleeps. =)
<mjg59> Hang on, let me play
<mjg59> So, S3 and StD both work perfectly on this Sony
<ajmitch> almost time to test it on my antique dell
<daniels> 'std' just sounds so wrong
<jbailey> daniels: STDs are good to avoid.
<jbailey> As a certified sexual educator, I recommend it.
<mjg59> jbailey: Ok, just let me regenerate my initrd and test this
<mjg59> But if there's no resume entry on the kernel command line and no RESUME in the initrd conf, what's it going to echo into /sys/power/resume ?
<mjg59> Mm. If $resume isn't set, it won't try to resume (and we'll just end up with a useless swap partition)
<jbailey> I'm just trying to find where mdz claimed it did it automatically.
<mjg59> jdub: Feature request for the screensaver:
<mjg59> For full movieos compliance, typing OVERRIDE should result in the screen unlocking
<jdub> haha
<jbailey> from mdz in bugzilla: Interesting...swsusp happily suspended for me even though I didn't have a
<jbailey> resume= in /proc/cmdline, so I assumed it had some sane default
<jbailey> mjg59: That's what I was thinking of, oh well.
<mjg59> Yeah. It'll suspend, but not resume.
<jbailey> What an amusing misfeature. 
<YokoZar> MoFOS: http://www.somethingawful.com/articles.php?a=112
<jbailey> What are the requirements?  Just that the swap have enough space free to drop the contents of ram in it?
<YokoZar> The Movie Fake Operating System
<mjg59> jbailey: Pretty much
<jbailey> That's gotta be a bitch to guarantee.
<mjg59> Yeah. The installer makes bigger swap partitions on laptops by default now.
<jbailey> I'm thinking even making sure they're not using all of the swap.
<jdub> mjg59: elite
<jdub> mjg59: "size of memory"?
<ajmitch> odd, I get unable to mount root device with the latest live cd
<mjg59> jbailey: In general, there's so much cache that it's not an issue
<mjg59> But yes, we can't guarantee it. Which is a bitch.
<jbailey> Is the right thing on laptops to have a spare swap partition just for suspending?
<jdub> would be ideal to use a swap file
<jbailey> Oh generate one on a loopback device or something?
<jbailey> s/Oh/Or/
<jbailey> jdub++
<jdub> loopback? ouch :)
<mjg59> swsusp2 has swapfile support, but it's nasty
<jbailey> jdub: Dude, it's been a long time since I had a swap"file" =)
<mjg59> You need to be able to find the start of the swapfile without mounting the filesystem
<jbailey> And I imagine it has to be contiguous.
<mjg59> Easiest is probably a list of block offsets dumped in swap...
<jbailey> Although grub and such can find the file for you.
<jbailey> How does the resume process actually work?
<jdub> mjg59: could grub store it?
<jbailey> Does the kernel just detect that there's an image to resume when you poke the magic into /sys/power/resume ?
<jdub> /sys/power/resume doesn't seem to exist on the laptop i just switched off
<jdub> ;)
* jbailey tosses jdub a nickel
<jbailey> Here, kid, go buy yourself a real computer.
* jdub pats the 220R
<jdub> :-)
<daniels> jbailey: he spent plenty of those, and got a dell.  can't legislate against bad taste.
<jdub> stfu!
<mjg59> jbailey: The kernel reads the start of the partition that you shove in there, and if it's got the right signature resumes from it
<mjg59> Oh, that's true. grub ought to be able to pass an offset to the kernel.
<jbailey> Should it need it?
<jbailey> At that point, you presumably have drivers and such loaded.
<jbailey> Mount the partition read only and just get the swapfile information then.
<mjg59> You can't mount the partition read onkly
<mjg59> Remember, it hasn't been cleanly unmounted. If the kernel mounts it, it'll play back the journal.
<jbailey> Ugh, yeah.
<zul> jdub: is sleep working on your ibook?
<wasabi_> Is ubuntu accepting packages with ~ in the version?
<daniels> woah
<daniels> Kamion: fucking up password verification (enter mismatching passwords) has a bad bad failure mode in the installer
<daniels> Kamion: you never get reprompted, so it just drops you back to the root menu of tasks, and hitting set up users and passwords doesn't re-prompt
<AndyFitz> jdub, you can update human off this package http://gnome-look.org/content/show.php?content=19853   next week ill be working on it fulltime to get the remaining application / mimetype icons up to scratch
<daniels> Kamion: the passwords probably need a db_reset if verification fails
<bluefoxicy> I take it gtk+ needs work?
* bluefoxicy is looking at 2 windows which exist but have nothing in them.  They became blank when the processes owning them died, yet the windows didn't vanish.
<daniels> yes, it's a fundamental flaw in gtk+, it's not actually able to close windows by itself
<daniels> no-one can be bothered fixing it
<bluefoxicy> yeah, I clicked the X but gnome can't get rid of the windows
<bluefoxicy> apparently that "Force quit" thing that kills the process. . . umm.  Needs a process to kill.
<toresbe> bluefoxicy: run xkill?
<daniels> bluefoxicy: in any case, inappropriate for #ubuntu-devel -- please use #ubuntu
<bluefoxicy> k
<jdub> AndyFitz: ok, ta
<jdub> AndyFitz: good timing, before lunch had half mail written to you re: coverage of the last drop :)
<AndyFitz> jdub: cool,  well this is till not complete mate but I've put away time to make sure it gets there before march as mentioned
<jdub> rockin'
<Keybuk> are there any known issues with ipw2100 in hoary at the moment?
<mdz> yes
* smurfix wonders why these drivers aren't in the main kernel yet
<Keybuk> drops connections all the time issues?
<daniels> Keybuk: i got that all the time with ath, then i discovered it was just that turning the acx111 in my desktop on had a habit of killing the entire network for everyone
<Kamion> daniels: hm, d'oh, must've screwed that up recently - will investigate
<daniels> Kamion: actually, it did that too from today's daily when I didn't fuck up my password
<Kamion> thought I'd fixed that, hmm
<Kamion> rsyncing today's daily now
<ajmitch> time to see if today's live cd boots
<Kamion> daniels: oh, crap, I probably know what it is
<Kamion> fortunately that means it's a one-line fix
<Kamion> well, that will fix the general failure in "configure apt" anyway, there'll be some other problem in passwd.config
<daniels> Kamion: heh
<sabdfl> hi all
<ajmitch> hello
<daniels> 'morning sabdfl ;)
<HrdwrBoB> oh 
<HrdwrBoB> I don't know if this has been fixed
<HrdwrBoB> but the ubuntu installer not only didn't have support for badblocks
<HrdwrBoB> thhe badblocks binary was missing
<Kamion> not surprised
<Kamion> doesn't parted have that functionality as part of 'check'?
<Kamion> ped_geometry_check (PedGeometry* geom, void* buffer, PedSector buffer_size,
<Kamion>         ped_timer_set_state_name (timer, _("checking for bad blocks"));
<Kamion> [...] 
<HrdwrBoB> probably, after things failed automatically I copied badblocks to a CD and then onto the install setup, used mkfs and it was fine
<Kamion> daniels: hm, did you select 'go back' after the password mismatch? if you select 'continue', it works fine; if you select 'go back', it loops.
<daniels> Kamion: i never got prompted about it; after entering the password (both fine and not, separate installs), it looped
<daniels> kami	this was the daily i386 as of ... about 8h ago?
<daniels> maybe 6?
<Kamion> daniels: I see (and have reproduced) a possible loop in the backup case; fixing that, anyhow
<Kamion> the way it drops back to the main menu when you enter matching passwords was a bug in apt-setup-udeb
<daniels> ah, cool
<daniels> cheers :)
<rubenv> jdub: ping
<ogra> morning
<mdz> night all
<daniels> mdz: g'night
<Treenaks> hey mdz 
<ogra> night mdz
<ogra> jdub alive ?
<daniels> ogra: he's gone for the night
<ogra> ah, ok
<ogra> daniels: thanks
<sivang> morning all!
* ogra tries to find out what else he did to ion3 beside forgetting -i in dch
<trulux> heya
<trulux> http://www.antena3.com/a3n/a3n_contenidos/contenidos/3/3/omnha3168-00547.jpg
<sivang> hey trulux 
<trulux> Windsor building burnt last night
<trulux> I was writing the paper when it happened :(
<trulux> hey sivang
<trulux> it's like the movie "Colossus burning" (or on fire, dunno how's the name in US)
<sivang> trulux: this was what I saw alst night (which scared me hell) on tve???
<trulux> sivang: yep
<sivang> trulux: man, what was that building for?
<Keybuk> Hmm, why do I get lots of "The following packages are not AUTHENTICATED" messages from APT?
<trulux> sivang: business and hotel AFAIK
<trulux> sivang: http://www.elmundo.es/elmundo/2005/02/13/madrid/1108282580.html
<lunitik> Keybuk: because not all archives have gpg keys yet... Ubuntu ones should though...
<sivang> boy, looks like madrid has much action laterl...
<lunitik> Keybuk: someone should get on others to do so... will be good when sid gets 0.6x in  :)
<lunitik> (or has it?)
<Keybuk> these are the Ubuntu archives themselves
<Keybuk> don't have any others in my sources.list
<trulux> sivang: yeah, it was like "heh, someone was partying and he didn't noticed me"
<Keybuk> which is why I noticed it as odd
<trulux> at least it seems not a terrorist attack
<lunitik> Keybuk: hmm... I've not seen that on official archives... that is weird  :o
<sivang> hey Keybuk , 'sup?
<Kamion> Keybuk: fresh install?
<Kamion> can someone fix the bunch of stuff in hoary that explicitly depends on gs? should be gs-esp | gs or something like that
<Kamion> explicitly depending on gs causes apt to pull gs from the network at installation time; doko fixed this pre-warty, but it has regressed
<Keybuk> Kamion: yeah, Array 4
<Kamion> apt-cdrom in array 4 didn't do the Release.gpg copy properly, but dunno if that's the cause; I worked around that in archive-copier
<sivang> back for some more time
<Keybuk> I've removed the cdrom line and updated since then though
<Kamion> elmo: could you update your copy of germinate please? I've added support for the casper seed.
<Kamion> (and want to be able to remove some corresponding junk from the installer seed)
<mantiena-baltix> amu, hi, are you online ?
<Kamion> mdz: the next live CD build should use the casper seed, which'll save 5-10MB depending on the architecture
<mantiena-baltix> Kamion, where are difference ?
<Kamion> mantiena-baltix: removes a bunch of stuff only needed on the install CD
<Kamion> e.g. all of partman
* Kamion wanders off
<mantiena-baltix> Kamion, my partman :(
<mantiena-baltix> how I make installer now ?
<mantiena-baltix> :(
<Kamion> if the live CD installer needs something, it should be added to some seed
<Kamion> but partman is not used in the casper bootstrap process and therefore is not in the casper seed
<Kamion> you should stop taking things as policy decisions when they aren't :)
<Kamion> anyway, gone
<mantiena-baltix> Kamion, hehe, this is joke
<mantiena-baltix> :-P
<tseng> hey, should linux-headers Makefile be patched with EXTRAVERSION matching the associated linux-image?
<tseng> some external modules seem to install into the wrong modules dir, i believe because of this.
<daniels> tseng: quite possibly, yes
<daniels> ah, no, I see
<daniels> daniels@brainfreeze:~% grep -r -- -amd64-k8 /usr/src/linux-headers-2.6.10-3-amd64-k8/
<daniels> /usr/src/linux-headers-2.6.10-3-amd64-k8/.extraversion:-3-amd64-k8
<tseng> oh
<tseng> is that common?
<daniels> dunno
<tseng> ivtv just calls modules_install in linux-headers
<daniels> your investigative abilities are doubtless as good as mine in this arena
* daniels drums his fingers on the desk and waits for the mirror to sync properly.
<tseng> yeah the Makefile doesnt touch that, ivtv certainly doesnt.
* tseng will file a buglet
<Hwolf> daniels, couldn't all that syncing trouble be avoided if users wouldn't be able directly to sync from the master mirror? IE, have a master that you upload to, and a master's deriviate that syncs with the master every once, just like other mirrors do now?
<sivang> hey again all, does anybody know if I am going to expect probleams trying to install hoary snapshot on a rocklacke D865PERL intel mb with SATA? ;-)
<daniels> Hwolf: er, maybe if you have the entire thing in RAM -- think about the I/O fun you'll have with every user trying to rsync everything
<maswan> daniels: As I read it, it was more a split of ftp-master and the publically accessable archive.
<daniels> oh, 'wouldn't' be able to sync
<daniels> i believe that's what we're moving to, yes
<sabdfl> sivang: there used to be a bug related to machines that had all SATA drives, and an older PATA cdrom
<maswan> ah, ok
<Astharot> hi
<sivang> sabdfl: Hey mark! Ah ok, well, I have 1 PATA hd here and going to integrate one SATA one, together with 2 PATA cdroms, hope it'll work :)
<maswan> daniels: It would be nice to have something I (as a mirror admin) could have proper access to, so I could do more frequent updates without getting flooded with "refused due to too many active rsync connections"
<sabdfl> sivang: i'd be interested in hearing about success or failure, good luck
<thom> sivang: what mobo? i have 1 pata disk, 2 sata and 2 pata cds; works fine
<daniels> maswan: yeah, i believe that's what the model is moving to
<daniels> maswan: everything in good time
<maswan> daniels: Good, I wish to be as good a mirror as possible. :)
<froud> http://www.inwords.co.za/ubuntu/ubuntu-hoary-update-reg-error.png What is the meaning of this error displayed while doing an update via Ubuntu Update Manager on Hoary
<froud> and where do I find gst-register?
<sabdfl> froud: it seems to be in package libgstreamer0.8-0
<sabdfl> not sure why it would be triggered by the update manager
<sabdfl> unless it has to do with playing a sound
<sabdfl> try asking on #ubuntu, or on one of the gstreamer channels
<froud> sabdfl, and where to find gst-register so I can run it?
<sabdfl> install the package libgstreamer0.8-0 then type gst-register
<sabdfl> froud: ^
<mjg59> Hmm.
<froud> sabdfl,  libgstreamer0.8-0 is already installed by when I run gst-register I get "sudo gst-register command not found"
* mjg59 hacks the driver lightly
<mjg59> sabdfl: Vaio support looks good - I'm just trying to integrate hotkey support
<sabdfl> mjg59: fantastic. is there any sanity to the whole hotkey situation or does every vendor do it differently?
<tseng> froud: its gst-register-0.8
<tseng> tab complete is cool.
<mjg59> Every vendor does it differently, except in the cases where they've bought designs off another vendor
<sabdfl> froud: try not using sudo, just typing gst-register-0.8
<mjg59> Lots of machines use the acer protocol, but it's entirely insane and I'm not going to touch it with a bargepole
<sabdfl> they don't make bargepoles long enough these days
<mjg59> Whoops.
* mjg59 crashes the machine
<mjg59> Maybe still a couple of bugs here, then...
<froud> sabdfl, seems to have rebuilt the registery without problem. Thanks
<website> hi to all
<sabdfl> froud: and solved the problem?
<website> i saw in /var/cache/apt/archives that deb packages are not removed after a complete upgrade by apt-get or synaptic utility.. why not make that apt utilities clean the archive after each upgrade?
<froud> sabdfl, system seems the same, everyting worked prior and after, so there was no problem just this error :-)
<jbailey> Now that we've got Python in essential, are we moving debconf there too?  I see that it's the first goal under EssentialPython
* T-Bone is having issues with ia64 livecd...
<mjg59> hkey ACPI 00000001 00000022
<mjg59> Rock
<mjg59> Only problem now is that it's binding to every single unclaimed ACPI device, which is a bit of a pain. Hm.
* Keybuk pokes pins into a voodoo doll of mjg59 
<Keybuk> your bloody suspend-to-disk stuff left me with a corrupt swap
<Keybuk> and I only just noticed
* Keybuk wondered why he's been having OOM-roulette all day
<mjg59> Corrupt swap?
<mjg59> A failed resume will result in it not rewriting the swap signature, which swapon will then be unhappy about...
<usual> is nautilus crashing X a known bug in hoary?
<Keybuk> it didn't even try to resume, iirc.
<mjg59> Hrm.
<mjg59> Need more debugging.
<mjg59> If it doesn't successfully resume, then the swap signature won't be fixed
<Keybuk> indeed, and you won't notice until some days later when you're wondering why the laptop can barely run xterm and emacs
<mjg59> swapon should check if there's a suspend signature, and if so mkswap it
<mjg59> sony/hotkey SPIC 00000001 00000001
<mjg59> Hurrah
<mjg59> Keybuk: Does hotplug actually use drivers.isapnpmap ?
<mjg59> s/drivers/modules/
<Keybuk> mjg59: I don't think so
<mantiena-baltix> Kamion, I already started d-i in chroot - simply started make demo_hd-media ;)
<mjg59> Keybuk: Interesting. Any idea why? It'd solve a load of the My sound doesn't work on my ancient laptop issues
<Keybuk> maybe it does work
<mjg59> There seems to be an isapnp.rc
<mjg59> But no isapnp.agent
<mjg59> Is there still any chance of moving stuff from universe into main?
* mjg59 engages in hot Vaio suspend/resume action
<mjg59> thom: Ping?
<zul> lamont: ping
<thom> mjg59: ack
<T-Bone> zul: ping?
<mjg59> thom: I've got some more hotkeys for you
<mjg59> And we also need to figure out some way to autoload sonypi at appropriate moments
<zul> T-Bone: about the altec support did it patch cleanly ?
<zul> mjg59: there was some sonypi patches it bitkeepr this week as well
<mjg59> zul: Yeah, they're not very relevant
<mjg59> But I need to dig throug hthem
<zul> k i have them it you need them
<mjg59> zul: Do you have a Vaio?
<zul> heh i weish
<zul> wish even
<mjg59> Heh. I don't :)
<thom> why would anyone wish for a vaio?
<zul> i was going to include them into -17 but i wouldnt mind a second opinon
<thom> mjg59: we really ought to get you upload perms
<zul> thom: because its better than the one i have now
<mjg59> zul: My stuff adds support for passing hotkey events through /proc/acpi/events so we can hook it in with the rest of the hotkey infrastructure
<thom> but ok, mail me hotkeys; is there anyway to detect sonypi existence or should we just try and load the module during acpi startup?
<mjg59> There actually is - we can walk through /sys/bus/pnp and look for a SNY6001 device
<mjg59> Weirdly, there doesn't seem to be any hotplug support for doing that yet
<tseng> mjg59: hah, convince gregkh to add it.
<mjg59> We'd also need the kernel to generate the maps
<mjg59> I don't actually know if we have devices that can bind via the pnpbios stuff
<thom> mjg59: so just check ids for SNY6001? should be doable
<thom> cool
<zul> damn it guinea pig peed on my desk
<mjg59> thom: Yeah
<trulux> ajmitch: ping
<mantiena-baltix> herzi, hi
<zul> mjg59: you can get the patches from http://zulinux.homelinux.net/ubuntu/kernel/patches/acpi/
<herzi> mantiena-baltix: hi
<dholbach> hai
<mjg59> Who should I be sending kernel patches to at the moment?
<zul> lamont is uploading and tbone and i are pusing patches to him 
<zul> so i guess you can send them to me if you want
<mjg59> Ok. What's the best address to use?
<zul> zul@gentoo.org
<Kamion> website: apt-get clean
<Kamion> website: it's not done automatically because it can often save you a batch of downloading if you keep the cache, which dialup users like
<T-Bone> zul: it's definitely better that you collect all x86 stuff, i don't have an x86 box, actually ;)
<website> Kamion, yes i know
<Kamion> website: (remember that you might remove the package and install it again; that's quite common while debugging stuff)
<T-Bone> and i'm clueless toward anything x86-related
<zul> T-Bone: ok sounds good, ill take care of x86 if you want to collect the weird ass architecutres ;)
<T-Bone> Kamion: did you see my answer? Isn't it weird that it works when adding 'set -x'?
<T-Bone> zul: lol
<Kamion> T-Bone: I really don't believe that's going to be connected, sorry
<website> Kamion, but most users don't remember to do apt-get clean and.. after upgrade most of them will not came back to the previus version
<website> i've to put ubuntu in my school
<Kamion> website: *shrug* there's a clean button in synaptic iirc
<Kamion> website: if you have a problem in a large deployment, you can always run apt-get clean from a cron job
<website> Kamion, where is that button?
<T-Bone> Kamion: what would you suggest?
<Kamion> T-Bone: I don't know, that's why I want 'set -x' output from the *first* run
<mjg59> zul: Ok, sending now
<Kamion> I don't believe in debugging by voodoo :)
<zul> mjg59, ok great!
<website> Kamion, found there is a sections about that on prefeerencies
<T-Bone> Kamion: ah ok! I didn't understand it that way. Well, i guess i'll have to re-re-re-re-reinstall :P
<Kamion> website: indeed, had to go look myself
<Kamion> maybe it could be more obvious, dunno - wishlist bug :)
<zul> mjg59, got it
<mjg59> zul: Look roughly sane?
<zul> yep
<zul> ill add it to the build im doing right now
<zul> then push the patches to lamont so he can include it in the next upload
<mjg59> Cool, thanks
<mjg59> Arse.
* mjg59 makes the irritating discovery that there's no way to get interfaces to stay static over suspend/resume without pain and misery
<zul> arse
<mjg59> I suppose I /could/ save the MAC->name mappings and then restore them once all the hardware exists again. Hmm.
<ogra> mjg59: just make /etc/iftab used by default everywhere :)
<mjg59> Haha
<mjg59> That would be the best solution, yes
* mjg59 realises he /could/ do an acerhk hack
<mjg59> But the only Acer I have is currently lacking a PSU.
<diego> sorry to annoy you development gods, but is swsusp in the hoary repos?
<tseng> http://higgs.djpig.de/ubuntu/www/
<mjg59> diego: Yes
<mjg59> Just edit /etc/mkinitrd/mkinitrd.conf and set RESUME, then rebuild your initrd
<diego> rebuild my initrd :/ are there instructions for this?
<Hwolf> diego, you could easily check if it is in...
<mjg59> mkinitrd -o /boot/initrd-whatever
<diego> mjg59: ah good game
<mjg59> Anyone here running on an Acer laptop?
<zul> tseng: yeah looks good
<diego> mjg59: is RESUME in mkinitrd.conf the same as resume2 in grub?
<mjg59> diego: No
<mjg59> resume2 is for swsusp2, which we don't use
<diego> ohhhh....well that explains very much of my confusion then
<diego> is it safe to have resume= my regular swap partition, or would that create problems?
<diego> nvm, i shouldn't be asking this here
<mjg59> diego: It should just be your swap partition, but yeah, #ubuntu is better for this
<mantiena-baltix> herzi, are you doing something with ubuntu ?
<sivang> rehi all
<zul> hey Simira 
<ajmitch> morning
<zul> doh...sivang
<sivang> hey zul, ;'sup?
<zul> not much u?
<sivang> zul: fine, just doing some system renovations :)
<zul> nifty
<ajmitch> sivang: format & reinstall? :)
<sivang> ajmitch: almost :) just thinking how would be best to move out of an old 30MB hd into a 120MB SATA  (the system is spanning 2 HDs, 40MB, and 30MB)
<ajmitch> ah yes :)
<ajmitch> I'm moving my laptop to LVM & installing hoary
<ogra> sivang: you should get some recent disks
<sivang> ogra: just got one :)
<ogra> sivang: i think the MB hdd aera is over ;)
<ajmitch> I wouldn't think you could fit much in 120MB
<ogra> *g*
<sivang> ogra: hrm, just noticed :) hehehe I meant GB :)
<ogra> sure
<sivang> ogra: I just miswrote the acronym 
<mdz> Kamion: cool
<herzi> mantiena-baltix: i use it as a development platform with bleeding edge gnome technology
<mantiena-baltix> herzi, cool, which technology ?
<ajmitch> mdz: you've changed the ramdisk on the livecd recently, right? kernel can't mount root fs here
<sabdfl> mjg59: RESUME should be the swap partition?
<mjg59> sabdfl: Yup
<mjt> ..and it can't work when swap is in a file, not in a raw partition.. ;)
<mjg59> I've been talking to Jeff about this - it ought to be done automatically on install in the next version
<mjt> (there where so much talks about "we don't need swap partitions anymore" ;)
<mdz> ajmitch: the ramdisk used on the daily live CD is built from scratch each day
<mdz> ajmitch: Kamion made some changes to the way it is built yesterday
<mjg59> sabdfl: If you're running Hoary and have RESUME set (and a ramdisk generated after it's been set), Fn+F12 should suspend to disk
<sabdfl> mjg59: i'll test it now. last time i tried it seemed to work at going to sleep, but then booted the normal way
<mdz> ajmitch: what kind of hardware, and how much RAM?
<ajmitch> mdz: x86 laptop, 128MB RAM
<ajmitch> and same in qemu
<sabdfl> mjg59: why can't it automatically find the swap partition in /etc/fstab? or from the running kernel?
<mjg59> sabdfl: On wakeup, it can't read any of your files, otherwise it'll alter the disk state
<mdz> ajmitch: does it work if you specify ramdisk_size=65536?
<ajmitch> mdz: I'll give it a go if I can recall all the other kernel options
<mjg59> Then it'll put your old memory contents back, you'll have an inconsistent view of the disk and get filesystem corruption
<mdz> ajmitch: you don't need them all; it appends
<ajmitch> ok
<mjg59> What /could/ be done would be to write a new grub setup on suspend
<mdz> "live ramdisk_size=65536"
<sabdfl> ah. you're going to make my skull explode.
<ajmitch> mdz: that works fine in qemu, testing on laptop now
<mdz> strange
<mdz> I tested the current settings on my laptop, and they worked fine
<mdz> it's packed up at the moment, though, so I can't test on it
<ajmitch> 64MB ramdisk works on the laptop
<mdz> ajmitch: can you try ramdisk_size=524288?
<ajmitch> it's an old pII
<mdz> that works for me in qemu
<ajmitch> sure, just a minute
<ajmitch> that work
<mdz> ok, we'll drop it down to 512M
<mdz> this is very strange, though
<mdz> I tested ramdisk_size=1048576 on my laptop with 256M and it worked fine
<mdz> but it fails in qemu with 256M
<ajmitch> hmm, doesn't look like it picked up the nic
<mdz> anything else?  Colin allowed the set of installer modules on the live CD to be more minimal
<ajmitch> not sure
<mdz> so casper's dependencies need to be more accurate
<mdz> I've added configured-network
<ajmitch> the cd sounds like it's about to self-destruct
<ajmitch> the laptop has wireless & a 3com card, both modules are loaded but dhcp is only tried on wireless
<ajmitch> wireless needs a WEP key before it can do anything on this network
<mdz> oh, maybe configured-network isn't the problem, then
<mdz> have you tested a Hoary live CD on this system before?
<ajmitch> nope
<mdz> oh
<mdz> well this is an awkward one to try, then :-)
<ajmitch> it takes too long to rsync usually :)
<mdz> we just changed a couple of major things yesterday
<ajmitch> I've got one from last week I can burn
<ajmitch> s/last week/jan 31
<mdz> ajmitch: if the last one you tried was from January, the live CD has been adapted to be much more rsyncable since then
<mdz> though, if you don't rsync for a few days, it builds up
<ajmitch> on a 128Kbps line it still can take a little while
<mdz> I suppose so
<ajmitch> I appreciate what you've done to make it rsyncable though
<mdz> please file a bug about the interface thing
<ajmitch> certainly
<mdz> it should try each one in turn, and proceed when it gets one to work without asking any questions
<mdz> Package: netcfg, Keyword: livecd
<mdz> there wase much Ubuntu love at SCALE
<mdz> s/wase/was/
<sivang> mdz: what is SCALE ?
<ajmitch> hey jordi 
<mdz> http://www.socallinuxexpo.org/
<sivang> mdz: very cool, what has been worked on?
<mdz> sivang: it is not a working sort of conference, mostly meeting people and learning about their open source projects
<sivang> mdz: very nice, I especially got interested in the flight gear booth :)
<mdz> it is impressive
<mdz> they are interested in making a flightgear demo live CD
<ogra> WOW
<sivang> mdz: we push ubuntu live as a base :)
<sivang> should, even
<mdz> I talked with them
<mdz> I think "push" is the wrong word :-)
<sivang> hehe ok, taking back, what would be the right word? 
<smurfix> Gaah. Last week the laptop's hard disk got scrambled. Coming back from vacation, everybody's sick. The laptop doesn't boot from USB and the desktop's CD burner doesn't want to burn.
* smurfix wonders what else could *possibly* go wrong
<sivang> (hhmm, nice to see they have the video streams of the embedded programming lectrues)
<ogra> smurfix: a lightning in your power line ?
<smurfix> ogra: The power lines are all underground around here, haven't had that kind of problem in the last 15 years
<sivang> hmm, I want to install grub on my second hd (hdb1) as I am taking out the first one,  so grub-install /deb/hdb1 is the way to go?
<ogra> smurfix: oh... i'm livint in the part of germany where they still are overground
<ogra> s/livint/living/
<smurfix> ogra: s/over/above / ;-)
<ogra> :)
<ogra> thanks
<ogra> smurfix: if you ever need to move to the eifel, get a good UPS ;)
<smurfix> ogra: Thanks, but I already have one.
<diego> mjg59: after i rebuild my initrd, i can just reboot and then give swsusp a try, right?
<mjg59> diego: Yup
<diego> cool, i'll do that and let you guys know how it goes then
<sladen> smurfix: net boot
<mjg59> Hrm. I could have sworn I had a Windows CD of some description around here.
<diego> hmm..my laptop really didn't like that new initrd
<diego> i started booting (for the first time) and it was all like "beep beep" followed by black screen and now it hasn't done anything since
<diego> now that i'm restarting my filesystem is having a fun, lengthy time fixing all its errors...ooh fsck failed...gg
<diego> good thing i keep my data on another partition
<diego> wait a second, would it have failed because i use reiserfs?
<edd> mjg59: interested in experiences with acpi-support on a tosh portege r100?
<mjg59> edd: Indeed
<mjg59> edd: Also, does your Vaio's sleep button generate an event by default?
<diego> i <3 filesystem corruption
<mjg59> diego: beep beep?
<diego> the internal speaker beeped twice
<edd> mjg59: right now on the tosh i'm getting to a cycle of sleep / resume / hibernate / sleep on the tosh. it's weird
<diego> it doesn't do that anymore, now when i boot it says the filesystem is corrupt and i need to run something with --rebuild-tree
<mjg59> edd: Ok, that's a known issue. Next upload of acpi-support ought to fix that (acpid has support now)
<mjg59> If you're running latest hoary, then:
<edd> mjg59: on the vaio, no i've got a version of jdmouse to pick up the key combo and run the sleep.sh script
<edd> mjg59: yes, the tosh is running hoary
<mjg59> Oh, argh. Hang on, I don't have the right machine booted. Anyway, if you run strings over acpid then it'll have the name of a lock file - touch the lock file at the start of suspend, and remove it at the end of resume (and get rid of the acpid start/stop stuff)
<mjg59> edd: sonypi loads ok on your machine?
<edd> mjg59: it does. sometimes after resume i recall having to rmmod and modprobe it again
<mjg59> Ok - I've just added support to get it to push hotkey events to acpid
<edd> mjg59: in fact, i have a script i run from prepare.sh and resume.sh to make sure jdmouse and sonypi come u p
<mjg59> Is sleep Fn+Escape on yours?
<edd> yes it is. but i'm running warty on the vaio
<mjg59> Yeah. Ought to work out of the box with Hoary, then.
<edd> That's awesome work!
* mjg59 got his hands on a Vaio yesterday, so has been hacking on it today
<mjg59> Can you do grep SNY6001 /sys/bus/pnp/*/id on the Vaio at some point and check that there's a device with that name?
<mjg59> Uh, /sys/bus/pnp/devices/*/id (sorry)
<edd> hmm, i don't see one
<diego> when it's telling me "Filesystem seems to have fatal corruptions. Running with --rebuild-tree is required.", what command is it referring to with the --rebuild-tree option?
<diego> oh nvm
<diego> fsck.reiserfs
<edd> mjg59: i see only PNPxxxx and one INTxxxx style device
<mjg59> edd: On the Vaio? Hrmph. That's a pain.
<mjg59> Oh, hang on - is that still 2.6.9?
<edd> yeah
<mjg59> Ok, you probably don't have acpipnp
<mjg59> Is your DSDT around somewhere?
<mjg59> edd: In any case, the lock file thing ought to stop the resume->hibernate cycle
<mjg59> It resumes fine other than that?
<edd> yes, with XFree86 using the vesa driver.
<edd> i've not retried with Xorg yet
<edd> mjg59: the only other thing is that the toshiba_acpi modules fail to load
<mjg59> edd: Yeah, it's likely that it's not a real Toshiba
<mjg59> A lot of the ultraportables are made by different companies to the rest of the range
<edd> mjg59: No, it used to load. 
<mjg59> Oh, did it? That's interesting.
<edd> mjg59: I get "Badness in remove_proc_entry at fs/proc/generic.c:688"
<mjg59> Does dmesg give any errors, or just enodev?
<mjg59> Ah - that's kinnison's fault
<mjg59> He's working on it - if you harass him, he'd probably be glad for extra testers
<edd> Hokay, which product to file the bug on?
<mjg59> It's filed already - hang on a sec...
<mjg59> https://bugzilla.ubuntu.com/show_bug.cgi?id=6197
<edd> ok, i'll add my report into there.
<mjg59> edd: Could you put a copy of /proc/acpi/dsdt from the Vaio up somewhere?
<edd> mjg59: get it from http://starway.heddley.com/~edmundd/vaio_tr1mp_dsdt
<mjg59> Thanks, grabbed
* ogra wonders if any native english speaker would say that defaced == deformed 
<sladen> that's a point, I packaged the iasl stuff somewhere
<ogra> (since my dictionary translates this different)
<mjg59> Ok, cool, you have a SNY6001 device
<sladen> ogra: deformed == out of shape.   defaced == vandelised and deformed (comes from soliders removing the *faces* of statues as they were deemed iconic in Churches)
<ogra> sladen: thanks, thats what i thought
<edd> mjg59: strings acpid reveals only /var/run/acpid.socket, no lock file
<mjg59> edd: Hm. Hang on a sec.
<mjg59> edd: Should be /var/lock/acpid
<mjg59> Thom uploaded that a couple of weeks ago - acpid 1.0.4-ubuntu3
<edd> mjg59: gar! i have mine stuck at 1.0.4-1ubuntu1+mjg59-1
* edd installs the right package
<edd> for some reason apt thinks it's a downgrade to go to the ubuntu3 version
<mjg59> Mm. Yes, I think I fucked up the versioning.
<zul> hey seb128 
<edd> mjg59:  ok, almost there. now i notice on the r100 that power.sh is being run every 2 seconds or so
<edd> mjg59: /var/log/acpid is receiving some BAT events. i have two batteries in here, i think maybe one of them's drained?
<edd> mjg59: nope, it's not to do with batteries draining. just that the system's always spewing battery events
<jlj> seb128: I'm running hoary with latest updates, when I connect a usb drive I have to kill gnome-vfs-daemon to get the drive to show up on the desktop. is this a known issue? if not, any tips on how to debug this?
<seb128> evening
<seb128> jlj: there is a bug about it in bugzilla, no real idea on the issue right now
<jlj> ok, thanks
<seb128> np
<trulux> tritium: heya!
<tritium> hey there
<zul> mjg59: your sonypi patch applied cleanly
<jdub> ogra: pong
<ajmitch> morning jdub 
<ogra> jdub: i just wanted to know what you wrote to norbert.... but inbetween i contacted him myself...
<Simira> yay, a jdub
<jdub> ogra: oh, i was going to write a blog entry about ubuntu/debian patches and so on in general
<ogra> jdub: oh, i understood you wanted to mail him....
<dholbach> are there any plans to get some general approach to ubuntu-patches?
<ogra> jdub: btw, its quite interesting how one can change the whole meaning of a mail conversation in one blog sentence 
<ajmitch> dholbach: I'd suggest each MOTU or maintainer tracking them in malone once it's up
<dholbach> ajmitch: hmmm, it should be tracked somewhere... of course, but having "open" bugs... hmmmmm :-)
<ajmitch> whatever works & keeps the flames away :)
<dholbach> we could brainstorm on this topic in one of the next meetings and put it on the wiki, to let the suggestions settle :-)
<ajmitch> I thought of having a UniverseBugs page on the wiki in the meantime
<ajmitch> but that's more for keeping a note of bugs in packages than patches :)
<ogra> ajmitch: i thought about that too, but the list would get very long very fast.....
<ajmitch> which could be a problem
<dholbach> i should start  wiki/AdvertisingUbuntuPatchesToTheRestOfTheWorld
<ogra> hehe
<ajmitch> zdiff or interdiff is useful for looking at changes between two .diff.gz files
* dholbach starts taking notes ;-)
<ajmitch> and debdiff which looks at control file differences or package contents :)
<jdub> dholbach: lamont is working on it
<ajmitch> what parts? bug or patch tracking for universe?
<dholbach> jdub: do you know more about the project?
<jdub> the merge-o-matic spits out patches
<jdub> lamont is going through them atm
<ajmitch> lovely
<jdub> it's going to be a bit closer to home for the next release though
<dholbach> cool :-)
<dholbach> am i "allowed" to remove /CVS/-directories from cvs checkouts to build and *orig.tar.gz?
<azeem> sure
<ajmitch> I use cvs export to get a tarball
<dholbach> ajmitch: oh yes...
<dholbach> azeem: i'm not sure, if you received, what i told you in a query
<azeem> yeah, I did
<dholbach> azeem: just wanted to make sure... about multisync
<dholbach> oh ok
<azeem> multisync just needs a recompile, right?
<dholbach> azeem: yes... exactly
<ajmitch> btw hi azeem 
<azeem> hey
<dholbach> oh yes ajmitch you're right... i was being impolite :-)
<dholbach> hi azeem, how lovely to meet you again, how are you? :-)
<azeem> you Ubuntu guys are too happy
<azeem> :P
* azeem goes back to #hurd
<ajmitch> heh
<ogra> lol
* dholbach comforts azeem and gives him a nice cup of tea. ;-)
<ajmitch> going back to the flames..
<dholbach> my amavis/spamassassin has been acting oddly the last week
<dholbach> found spam but didnt change the mails header
<azeem> 23:17 < mateo> im so happy
<azeem> hah, there are happy users in #hurd as well 
<ajmitch> azeem: that's an odd comment from there
<dholbach> jdub: couldnt you go and get azeem something from the funky-ubuntu-dance--department?
<dholbach> :-)
* azeem is currently dancing to Public Enemy, so no worry
<ajmitch> azeem: started work on an ubuntu gnu/hurd yet? :)
<azeem> we got a couple of new guys working on debian gnu/hurd now, so it would be awkward to move to ubuntu now
<ajmitch> azeem: no point forking
<mjg59> edd: Some systems will emit an event every time the charge changes at all
<edd> mjg59: Aha. The disk access every 2 seconds is a bit annoying, that's all.
<mjg59> Our power.sh should probably be less stupid.
<mjg59> The other problem is that acpid will log it...
#ubuntu-devel 2005-02-25
<zul> hmm...there seems to be people refering to ubuntuforums in gentoo's bugzilla
<sivang> zul: hehe
<edd> mjg59: hmm, i get nonrepeatability of sleep/resume with acpi-support which doesn't occur if i just use plain ol' echo 3 >/proc/acpi/sleep. i'll try and track down what's causing it, but i'm guessing some module removal/reinsert 
<edd> mjg59: (on tosh r100)
<mjg59> Hm. Interesting.
<haggai> jdub: ping?
<zul> hey tseng you might want to remove yourself from the community council agenda
<tseng> oh.
<zul> unless if you still want to be talked about
<dholbach> tseng: did it an hour ago :-)
<tseng> dholbach: thanks much.
<dholbach> zul: i bet tseng enjoys that :-)
<tseng> sure do
<dholbach> tseng: oh no... i removed myself from it :-)
<tseng> all the time people say stuff like: "someone should make an up to date mono repo for ubuntu"
<zul> heh
<tseng> done.
<jdub> tseng: you've done 1.1?
<tseng> jdub: no, its on the list for debian-mono dudes
<tseng> jdub: working together with debian = rad
<dholbach> i'm off to bed - sleep tight everyone
<tseng> jdub: i passed one last tiny patch to the muine maintainer and he is getting ready to hopefully push muine + gtk-sharp2 to experimental. mono 1.1 comes after 1.0.5 in sarge
<tseng> that little talk we had with miguel is just now hitting the pkg-mono list.. we'll see where that leads
<jdub> tseng: haha, cool
<mjg59> evolution sharp would be nice...
<jdub> someone's done it
<jdub> i have to check over it
* ..[topic/#ubuntu-devel:daniels] : Ubuntu Development UP LATE | #ubuntu for support and general discussion | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals
<sivang> does anybody know where can I download hoary daily builds through a torrent? (has anoyone got a url)
<daniels> er, i don't think we do torrents for daily builds
<sivang> daniels: ah ok then , I'll rsync, surely the rsync daemon is running for daily's right?
<tseng> that wouldnt make sense, youd have few seeds.
<sivang> (wanting it mainly to be able to continue an interrupted download)
<ajmitch> sivang: rsync does that though
<daniels> sivang: it runs over all of a.u.c/cdimage.u.c
<sivang> daniels: cool, just before warty preview
<daniels> sivang: hm?
<daniels> sivang: where are you rsyncing from?
<sivang> daniels: as in location?
<daniels> yeah
<sivang> daniels: oh, israel, have we got a mirror over here already?
<daniels> oh, sorry, i meant which host
<daniels> but cdimage.u.c::cdimage should have it
<sivang> daniels: ah ok will do , thanks.
<crypto-working> who does one contact to become a us mirror?
<zul> hey mdz
<mdz> hi
<cryptoknight> anyone know?
<zul> cryptoknight, have you checked the wiki?
<cryptoknight> i did
<cryptoknight> i could not locate information on this subject
<whiprush> "If you set up a new mirror, please add it to this page and send contact information to  mirrors@canonical.com"
<whiprush> http://www.ubuntulinux.org/wiki/Archive
<cryptoknight> thank you
<doko> good morning
<Gagatan> HcE :)
<HcE> Gagatan: =)
<fabbione> morning
<fabbione> daniels: ping
<mdz> morning
<fabbione> hey mdz
<fabbione> daniels: WAKE UP MY LITTLE YOUNG FRIEND!
<dilinger> fabbione: aren't you supposed to be getting married or something?
<fabbione> i did
<fabbione> last saturday
<fabbione> what was the name of the software to create galleries on the fly?
<fabbione> i have a bunch of pics already
<Treenaks> fabbione: php? "gallery" :)
<fabbione> Treenaks: doesn't matter the language
<fabbione> Mithrandir was mentioning something you just run the pic dir
<fabbione> and it will create the thumbs and the html
<Treenaks> oh.. galrey
<fabbione> thanks
<fabbione> jdub: ping?
<pitti> Hi guys
<pitti> Happy valentine's day :-)
<fabbione> hey pitti
<pitti> fabbione: Congratulations for your marriage! I wish you all the best
<fabbione> thanks man
<pitti> fabbione: recovered from the long party? :-)
<mvo_> hi pitti!
<pitti> Hi mvo_ 
<mvo_> congrats fabbione 
<mvo_> :)
<fabbione> pitti: + or -
<fabbione> mvo_: thanks
<pitti> fabbione: huh, you mean your marriage is signed now?
<fabbione> doko: ping?
<doko> fabbione: yes, congrats!
<fabbione> doko: thanks.. gcc-3.3/3.4 question
<fabbione> i can't build 3.4 on sparc 
<fabbione>   gobjc-3.3: Depends: libobjc1 (>= 1:3.3.5-8ubuntu2) but it is not going to be i
<fabbione> now.. 3.3.5-8ubuntu2 has built fine
<doko> yes, built by gcc-4.0
<fabbione> but there was no libobjc1 with ubuntu2 version
<fabbione> ahhh ok
<fabbione> gcc4 is still building
<fabbione> gotcha
<fabbione> thanks
<doko> should work, built it last week
<fabbione> doko: yes, sparc is lagging a bit
<fabbione> i had a problem with the local mirror (+2 days of lag)
<fabbione> and i did something totally stupid (+1 day of lag)
<fabbione> so it's recovering slowly
<doko> stupid? ehh, you regret the wedding that soon? *duck and run*
<fabbione> ahahhaha
<fabbione> i did already 20 minutes after :-)
<fabbione> http://www.fabbione.net/wedding/IMG_0854.html
<fabbione> just to give you an idea of the weather
<pitti> elmo: awstats sync please (Ubuntu override ok)
<Treenaks> fabbione: 1 word: thumbnails :P
<fabbione> Treenaks: go to the index
<zenrox> yes
<fabbione> and you get the thumbs
<Treenaks> fabbione: ah cool :)
<fabbione> you can't see snow in the thumbs
<Treenaks> fabbione: cool picture though :)
<mdz> good night
<fabbione> night mdz
<mvo_> night mdz 
<Astharot> bonjour
<Treenaks> does anyone here know what those pictures with letters in them (on web forms, "type the letters from this picture") are called?
<ogra> pitti: ping
<pitti> ogra: pong
<ogra> had som time to look over the last procfs patch from friday ?
<pitti> not yet, sorry
<pitti> but I will look at it ASAP
<ogra> ah, ok... take your time
<Mithrandir> fabbione: I mentioned curator, or you could use imageindex
<pitti> ogra: btw, did you know that you can put printf macros in HAL_ERROR() and the like?
<pitti> ogra: thus you could do HAL_ERROR (("cant open file in /proc")); -> HAL_ERROR (("cannot open %s", path))
<ogra> pitti: oh, no, thats new to me....
<ogra> great
<pitti> ogra: it helps to improve the usability of debug messages a lot
<ogra> yup....even if i wouldnt expect cpuinfo or meminfo to b there on every linux ;)
<ogra> as long as proc is mounted
<pitti> ogra: I know, but in general it is nice to know
<pitti> ogra: btw, there are cases when /proc is not mounted
<ogra> pitti: i will adjust it
<pitti> ogra: think of testing hal in a chroot
<ogra> pitti: thats why i left the osspec check there
<pitti> ogra: patch looks fine
<ogra> pitti: yay
<ogra> pitti: see, youre a great techer :) thanks.....
<ogra> s/techer/teacher/
<pitti> ogra: so the still missing patch is dmidecode?
<fabbione> Mithrandir: i used galrey
<fabbione> Mithrandir: pretty ok for simple stuff
<fabbione> Mithrandir: http://www.fabbione.net/wedding/
<pitti> ogra: shall I upload a new hal with these two patches in the meantime?
<ogra> and some device-manager stuff.... (the new features shall have icon too)
<fabbione> Kamion: ping?
<ogra> pitti: yeah
<ogra> fabbione: may i send you my best wishes....
<pitti> ogra: are you interested in creating the new package yourself? (patches, autofoo patch, etc.)? or shall I do it?
<fabbione> ogra: thanks dude...
<ogra> pitti: you are more familiar with it.... but you could leave me the neyt one if i'm lless busy ;)
<ogra> s/neyt/next
<pitti> ogra: okay, then I will do the package today and upload it
<ogra> yippie
<ogra> at least soething positive after a weekend with debian flames for me....
<pitti> ;-)
<ogra> pitti: seen this ? http://www.inittab.de/blog/2005/02/13#20050213_ion3-update
<pitti> ogra: *chuckle*
<ogra> yup.... btw... i said defaced....and he ripped the whole conversation out of context in ths one sentence....
<ogra> profilneurotiker.....
<pitti> :-)
<Keybuk> ok, weird; when I plugged in my iAudio, the window appeared
<ogra> but he also showed me the dark side....ther was not one sentence in our conversation where he didnt rant about apt 0.6
<Keybuk> but now I can't find it in Desktop, Places, Computer, etc.
<Keybuk> yet is still mounted in /meda
<pitti> Keybuk: could be a cause of the broken inotify
<ogra> ....which indeed was totally unrelated to the conversation....
* ogra wonders how mdz bears these rants....
<Keybuk> pitti: does inotify affect hal's detection of filesystems?
<pitti> Keybuk: no, it doesn't
<Keybuk> because it doesn't appear as a filesystem in the open dialog, etc. either
<pitti> Keybuk: inotify only affects the gnome stuff
<pitti> Keybuk: is the file system recognized in hal-device-manager?
<Keybuk> there's a block volume in there, yeah
<pitti> Keybuk: and device and fstype are correct?
<jdub> fabbione: pong
<fabbione> jdub: thanks.. i have done :-)
<haggai> jdub: I never got an ACCEPT mail, I guess it didn't like me uploading the .orig.tar.gz from a different IP
<dholbach> hai!
<Keybuk> pitti: I think so.  so "iz gtk bug" ?
<pitti> Keybuk: as long as hal reports it fine and gvm mounts it, the Utopia part seems to work
<pitti> Keybuk: I have the same odd behavior sometimes, though
<pitti> Keybuk: devices are still displayed as mounted, although they were unmounted long ago, and similar thinkgs
<Mithrandir> fabbione: congrats. :)
<fabbione> Mithrandir: thanks :-)
<Mithrandir> seb128: the evo segfaulting on amd64 bug should be fixed now
<jdub> Mithrandir: yay!
<Mithrandir> jdub: it was a problem with pthreads and krb4...
<jdub> ouch
<seb128> Mithrandir: rock, thanks!
<Mithrandir> just a broken configure script, but evo is library hell so it took a while to track down.
<Mithrandir> seb128: I haven't closed the bugs, but you might want to do that.
<seb128> k
<Mithrandir> gotten any further on the nautilus problem?
<seb128> Mithrandir: no yet, but the diff between both version is not huge, I'll probably send you a patch to try today
<Mithrandir> ok
<mvo_> seb128: do you have a idea why metacity ignores "gdk_window_raise()" for top-level windows? is this the new focus-stealing stuff?
<Kamion> fabbione: yo
<seb128> mvo_: probably yep
<fabbione> hey
<pitti> ogra: ping
<mvo_> seb128: do you know if there is a way to work around it ;) ?
<seb128> mvo_: what are you trying to do ?
<mvo_> seb128: if there is a synaptic already runing and it's started again, bring it in the foreground
<mvo_> (the runing one)
<ogra> pitti: pong
<seb128> and that doesn't work ? or you just don't get the focus on it ?
<mvo_> seb128: it does not work (no raise). it works with xfce though
<pitti> ogra: never mind, had some troubles with autoconf, but solved it
<ogra> ah, ok
<ogra> pitti: caused through me ? (i mean do i have to regard anything special in the next patch ?)
<pitti> ogra: no, caused by the gazillion different version combinations of libtool/automake/autoconf/autofuck/whatever
<ogra> hehe... thats what i ran into when i tried it.....hal uses 1.9 apparently
<seb128> mvo_: dunno, seems to be a bug yep
<mvo_> seb128: I guess I need to recompile metacity to get all the nice "meta_verbose" messages?
<ogra> pitti: that was why i asked you about special magic in one of my mails ;)
<pitti> ogra: that's why I package the makefile updates as a patch instead of calling autofuck in debian/rules
<ogra> yup... i understand that
<seb128> mvo_: yep. I can ask to one of the metacity guy on IRC you want, that's probably faster (though he's not connected atm)
<mvo_> seb128: that would be very nice, thanks
<seb128> np
<mvo_> seb128: just checked with the old metacity (warty version), seems to work with it
<dholbach> bbl
<pitti> ogra: this is the first time I actually _see_ your changes in h-d-m. Looks nice :-)
<ogra> hey, thanks...
<ogra> pitti: wait for the bios stuff ;)
<pitti> ogra: ugh, the autoconf patch is 1.7 MB
<ogra> argh
<ogra> for only 2 additional lines in Makefile.am .... thats impressife
<seb128> mvo_: yeah, but the focus stealing prevention change a lot of stuff on this plan
<ogra> s/f/v/
<ogra> pitti: in my tests there was a .deps dir or something created i think.... there were a lot of .obj files....are these needed ?
<pitti> ogra: the patch doesn't contain them
<pitti> ogra: it contains only Makefile.in changes and configure changes
<ogra> oh, and still 1.7 MB
<ogra> pitti: sure these are only my changes ?
<pitti> ogra: it doesn't really matter how much you change the *.am files
<pitti> ogra: this is just the totally ridiculous principle of automake/autoconf
<pitti> ogra: hal_0.4.7-1ubuntu4_source.changes ACCEPTED
<ogra> HOORAAY
<ogra> :-D
<Kamion> make sure you're using the same version of automake as was quoted in the original .in file
<Kamion> or at least the same X.Y version
<ogra> Kamion: hal uses 1.9.4 i think.... unbuntu has 1.9.5 afaik
<Kamion> ogra: there automake1.4 | 1:1.4-p6-8 |         hoary | all
<Kamion> automake1.6 |   1.6.3-11 |         hoary | source, all
<Kamion> automake1.7 |    1.7.9-6 |         hoary | source, all
<Kamion> automake1.8 |    1.8.5-2 |         hoary | source, all
<Kamion> automake1.9 |    1.9.4-1 |         hoary | source, all
<Kamion> pick one
<Mithrandir> Kamion: don't you love automake? :)
<Kamion> and preferably invoke it by 'automake1.9' or whatever if you want to be sure
<ogra> hehe.... yes, i already ran into this....
<ogra> i guess this has been aske a thousand times already.... shouldnt automake just link to the newest version....
<ogra> s/aske/asked/
<Kamion> it generally *does*, via alternatives
<Kamion> alternatives are not the most reliable system on the planet though
<ogra> hmm, so mine are broken it seems
<Kamion> no idea, try 'update-alternatives --display automake'
<Kamion> actually automake1.4 seems to have a higher priority
<ogra> yup ...
<Kamion> I assume there's a good reason
<mantiena-baltix> Kamion, I have one question to you, as d-i developer, do you have some time to aswer ?
<Kamion> mdz: please always run debconf-updatepo after changing template text, so that translation indexes get updated properly (e.g. anna)
<Kamion> mantiena-baltix: don't ask to ask, just ask. :)
<mantiena-baltix> ;)
<mantiena-baltix> Kaloz, in ubuntu live cd casper udeb mounts filesystem.cloop on /target. debian-installer mounts newly created partitions also on /target :(
<mantiena-baltix> it's not good for liveCD installer
<Kamion> fix your tab completion, too :)
<Kaloz> :D
<Kamion> casper has already run pivot_root by the time your live CD installer would run
<mantiena-baltix> Kamion, evil xchat
<Kamion> the mount on /target is no longer relevant
<Kamion> mantiena-baltix: try typing 'Kam' rather than 'Ka' before hitting tab. :P
<mantiena-baltix> Kamion, too many typing ... ;)
<Kamion> how much more typing is used by not watching what goes into the channel and having to deal with a conversation about it afterwards?
<Kamion> but anyway, I don't see that the /target mount should be a problem
<mantiena-baltix> I know, that casper does pivot_root, but I'm trying to make universal installer, which works in both modes - text mode without starting liveCD filesistem and in gui mode after liveCD (with GNOME environment) is started
<mantiena-baltix> Kamion, so, /target is problem
<Kamion> oh, I see; talk to mdz then
<mantiena-baltix> Kamion, I don't want to duplicate casper's scripts in installer
<Kamion> he's the casper guru :)
<Kamion> I don't think moving /target elsewhere for casper would be a problem
<mantiena-baltix> Kamion, I too ;)
<mantiena-baltix> mdz, what you think ?
<Kamion> (note mdz's asleep right now, I imagine he'll read scrollback though)
<mantiena-baltix> hehe, different timezone ;)
<mantiena-baltix> Kamion, what folder name you suggest for casper ? I'm coding installer right now ;)
<Kamion> no idea :)
<Kamion> pick one, I'm sure it will be utterly trivial to change later
<mantiena-baltix> ;)
<jbailey> Would you mind emailing them to me?
<jbailey> ECHAN
<dholbach> re
<low> hi there
<low> i think i've found why raid soft doesn't work while installing hoary (3&4)
<low> anyone ?
<Treenaks> just state the problem and your fix ;)
<Treenaks> I guess
<low> Treenaks: i've not yet the fix
<low> but, /dev/md* nodes do not exist
<Kamion> we use devfs device paths
<Kamion> I imagine they're just called something else
<pitti> should be /dev/md/n
<Kamion> like /dev/md/
<low> Kamion: hmmmm w8 a bit, i take a look at the other box
<Kamion> also make sure that the relevant kernel modules are loaded
<low> ok no suc /dev/md, /dev/raid or whatever
<low> modules, taking a look...
<low> raid[015] , md are loaded
<Kamion> that might suggest that there are no md partitions on the system, then?
<Kamion> elmo: please sync partman-md 20; just translation fixes
<low> i've created partitions that are to be glued into md
<low> but, but wanting to create the md node, it complains it can't find any raid autodetect partition
<low> hmmm i'll try to boot with "devfs=nomount", brb
<Kamion> no, don't bother
<Kamion> you'll be wasting your time
<Kamion> we do not use devfs itself, but udev in devfs compatibility mode
* Kamion duplicates the problem, and investigates
<low> Kamion: current config: a64, 4 sata disks on sata_sil, 1 on sata_nv
<Kamion> doesn't seem to be particularly dependent on configuration
<mjg59> thom: We need to shift the sleep scripts to using acpid locking
<low> Kamion: agreed, was just to let you know
<thom> mjg59: yes
<ogra> thom: i wrote a xscreensaver patch that beautifys the lock-win response... sent it to jdub....he did like the old behavior with big fonts better.....
<ogra> thom: so he is the one to argue with then... ;)
<thom> i shall lay the smackdown on him, then
<ogra> thom: since my part is done...yes... i dont really care which way it works, although i like it better without "verifying" and "approved"
<ogra> thom: but jeff loves the "denied" part very much :)
<Kamion> low: ok, think I might see the problem; partconf-find-partitions looks broken
<thom> ogra: heh
<ogra> pitti: ping
<jbailey> ogra: Hu?
<pitti> ogra: bong
<thom> jbailey: EWRONGJEFF
<jbailey> Lovely, /me crawls back to the other IRC tab.
<ogra> pitti: i just heard that other people have the hal-slow-startup problem too
<pitti> ogra: probably due to a particular piece of hardware I don't have
<ogra> pitti: it seems only to occur on amd64
<pitti> ogra: for which versions does this happen?
<pitti> ogra: ah, arch-specific may explain it, too
<pitti> ogra: already for warty?
<ogra> pitti: for me since your udev fix... i suspect udev responds very slow
<ogra> pitti: nope, hoary
<low> Kamion: ok. i'd be happy to test a fixed iso asap
<pitti> ogra: ah, right. Yes, we call "udevstart" in the postinst
<pitti> ogra: however, this should not affect _every_ startup
<pitti> ogra: just upgrades
<ogra> pitti: i found that my patches are the only thing that keep h-d-m from crashing, because they are there immediately :)
<pitti> cool
<ogra> pitti: it affects every startup here....
<pitti> ogra: I did not touch /etc/dbus-1/event.d/20hal
<pitti> ogra: and this file does nothing with udev
<pitti> ogra: it just starts the hal daemon
<ogra> hmm, but dholbach had the problem too, just a minute ago....
<ogra> pitti: but i have no idea wher to look at in a bit more specific way...
<pitti> ogra: maybe you can start hald in debug mode to see what takes so long?
<ogra> i'll do....
<pitti> ogra: sudo killall hald; sudo hald --verbose=yes --daemon=no --drop-privileges :-)
<ogra> and probably a gdb in front if i dont see anything ;)
<pitti> ogra: this will print out all the HAL_ERROR/HAL_INFO/whatever to the console
<pitti> ogra: so you see at which device it hangs
<ogra> Timeout (10000 ms) for callout 40-hal-hotplug-map.hal
<ogra> ouch
<ogra>  Cannot find callout for terminated child with pid 14046
<ogra> pitti... just piping it to a file... i'll send it
<ogra> pitti: http://www.grawert.net/hal.log
<pitti> can you please see why the childs terminate prematurely? 
<zul> hey
<pitti> hi zul
<zul> hey pitti how is it going?
<enrico> Hello.  What distribution do I put in the changelog for Hoary?  Just "hoary" ?
<Mithrandir> yes
<dholbach> yes
<dholbach> if someone bothered uploading my dh-make--patch... :-)
<enrico> thanks!
* dholbach advertises it once again: http://moz.gotdns.org/dh-make.lsb.patch
<thom> dholbach: jbailey could just upload it now :P
<dholbach> thom: i found out dh-make was in main
<trulux> heya
<trulux> pitti: hey!
<trulux> tritium: back from school
<tritium> trulux, hello
<trulux> tritium: howya?
<jbailey> thom: Are you're point at me, why? =)
<tritium> trulux, Just arrived at the office a bit ago.  Still drinking my coffee :)
<jbailey> Oh, I see. =)
<Kamion> dholbach: please use the lsb_release program rather than parsing /etc/lsb-release yourself
<Kamion> i.e. lsb_release -c
<tritium> trulux, working on it now
<zul> lamont: ping
<jbailey> "lsb_release -cs" looks exactly like what you want.
<dholbach> Kamion: alright, i'll take care of it
<trulux> tritium: I love coffee, it's reason why I can be still awake in the deep night 
<trulux> ;)
<Kamion> hm, yes, what jbailey said
<lamont> zul - running out the door to take kids to school (late) back in about 90 minutes
<zul> k
<dholbach> Kamion, jbailey: so would you test for   -e /bin/lsb_release  ?
<dholbach> Kamion,jbailey: i wouldn't let dh-make depend on lsb-release or anything
<jbailey> dholbach: That sounds reasonable to me.
<dholbach> alright
<dholbach> jbailey, Kamion: fixed it
<pitti> trulux: hi
<pitti> ogra: cool, just saw the new xscreensaver when I returned
<pitti> ogra: looks much better
<ogra> pitti: iand i just saw that we both missed a line in my lsb patch...darn...
<pitti> ?
<ogra> pitti: either lsb adds the data to a nonexisting root device (its to fast) or i must set a callout in the end of the code....
<ogra> pitti: t seems its actually triggered by the lsb patch....
<pitti> hmm
<pitti> EWORKSFORME
<ogra> hmm
<Treenaks> smells like a race somewhere?
<ogra> Treenaks: happens only on amd64
<mjg59> http://linux.slashdot.org/comments.pl?sid=139381&cid=11666527 - quality
<fabbione> daniels: ping?
<mvo_> ping lamont 
<HrdwrBoB> fabbione: I have a suspicion he is in bed
<mvo_> lamont: I would like to know if you still can reproduce #5666?
<fabbione> HrdwrBoB: no. he should be around anytime soon
<HrdwrBoB> ah ok
<HrdwrBoB> I was just adding up time spend awak vs time sleeping and came up with sleep
<ogra> mjg59: they mispelled mandela
<zul> fabbione: i pushed some patches this weekend to lamont for uploading this week or something like that
<zul> its still too early
<fabbione> zul: cool
<zul> oh and i have 2.6.11 as well
<fabbione> zul: cool, does it work?
<pitti> fabbione: 2.6.11 works fine for me, too
<fabbione> sw33tn3ss
<zul> fabbione: havent had a chance to try it yet, there is a couple of bug reports already about it
<fabbione> it took me more time to figure out why arch all couldn't build than anything else :-)
<Kamion> low: ok, I think I have most of it figured out now (and a test installation running), but I'm going out for a bit now
<fabbione> zul: 2.6.11 -> experimental as mdz said
<fabbione> zul: bugs are good, but they don't need to be prioritized
<fabbione> not until we have a real 2.6.11
<Kamion> elmo: please sync mdcfg 1.09; just translation fixes
<opi> Hi there 
<opi> I've been playing with a LiveCD customization
<opi> I wonder (I don't have USB Key yet) is there a chance to install Ubuntu on USB, but not as LiveCD (ie. read only) but with ability to RW
<enrico> Hello.  Question about packaging: I'm packaging the Ubuntu Docteam things (svn co https://docteam.ubuntu.com/repos/trunk) and it's various xml files with some common entities
<enrico> I would like to make 3 packages out of that, as it's 3 pieces of documentation.  If you checkout the repository you'll find that the .deb packaging is done already
<enrico> Now, I'd like to package the xml, and it appears it would be better if all the three packages install things in /usr/share/doc/ubuntu-docs instead of a different usr/share/doc/ directory each
<enrico> the deal is that I can put the xml common entities in the ubuntu-docs package, then make the other packages depend on it, and let them install things in /usr/share/doc/ubuntu-docs as well
<low> Kamion: ok, thanks a lot. any idea when the next test iso will be out ?
<enrico> I don't know however how much that is doable (policy wise and debhelper-wise)
<Kamion> low: daily builds
<daniels> fabbione: heheh :) patience, jedi
<Kamion> low: assuming I get it all uploaded today of course, which I don't guarantee
<ogra> pitti: the only thing i find ... lseek(7, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
<Kamion> low: the next test release is planned for Wednesday
<eruin> are any of you aware of hdparm -d (dma) bug reports?
<fabbione> daniels: shut up padowa :P
<low> Kamion: ok, i'll dl the next one on wednesday then. thx again !
<Kamion> ok, I had to tweak grub a bit by hand, but other than that the install seems to have worked
<daniels> fabbione: haha
<enrico> Ok, forget about what I said.  Short version: I need a hand with packaging some documentation.
<Kamion> /dev/md0              15954944    716888  14427584   5% /
<ogra> pitti: this is in lsb.... and i have no idea who calls lseek...
<enrico> Could please someone who did some scrollkeeper do "svn co https://docteam.ubuntu.com/repos/trunk" and join #ubuntu-doc ?
<pitti> ogra: "in lsb" means, this is in your module?
<pitti> ogra: understandable, you cannot seek pipes
<daniels> lamont: ping
<ogra> pitti: yes, in the end of the lsb call in my strace....
<ogra> pitti: i'll upload the strace....wait a sec
<ogra> pitti: http://www.grawert.net/hal.strace
<pitti> ogra: okay, this is fdopen()'s fault
<ogra> gah
<ogra> but why does it only happen on amd64 ?
<pitti> wait, I try that out on my box, too
<pitti> I think it surely happens here
<ogra> then its not the bug ...
<pitti> ogra: in theory the program should just continue to run
<pitti> ogra: i. e. ignore the lseek
<ogra> ok...
<pitti> bah, we should disable this stupid fstab-sync
<ogra> yup
<ogra> it only throws spam out...
<pitti> ogra: however, no Timeout message for me
<ogra> hmm
<enrico> Question: can I install symliks in /usr/share/doc/ubuntu-docs pointing at /usr/share/ubuntu-docs?
<low> see ya !
<ogra> pitti: kernel bug ?
<pitti> hmm, no I don't think so
<ogra> what else ?
<ogra> since it must be arch specific
<pitti> ogra: can you please wrap the callouts into a script calling gdb/strace/whatever?
<pitti> ogra: I think it is dependent on some hw or processor speed
<ogra> hmm
* enrico hates to be totally ignored like this
<Mithrandir> Keybuk: do you have pkg-config in arch somewhere?
<Keybuk> nope
<jordi> enrico: yes, you can
<jordi> enrico: at least following debian-policy
<enrico> jordi: thanks!
* enrico rejoices
<Mithrandir> Keybuk: any other VCS?
<enrico> jordi: and can different packages all install stuff in /usr/share/ubuntu-docs?
<jordi> enrico: sure. s$ubuntu-docs$/gnome/help$
* enrico hugs jordi
<enrico> thanks a lot!
<jordi> enrico: np :P
<jordi> that should have read s$ubuntu-docs$gnome/help$ though :)
<lamont> moo
<lamont> zul: will fetch your patches
<fabbione> hey lamont 
<fabbione> i might need some changes to the kernel pretty soon
<fabbione> mind to wait to upload?
<lamont> fabbione: I suppose we could...
<lamont> you changing 2.6.10?
<lamont> daniels: sup?
<fabbione> lamont: daniels is
<lamont> ah, ok
<fabbione> he will give you the patch
<lamont> oh, ok. 
<lamont> so  it's "wait for daniels' patch", not "let fabbione upload a new kernel"
<lamont> got it
<daniels> lamont: hi! :)
<Keybuk> Mithrandir: it's in freedesktop.org CVS
<fabbione> lamont: exactly
<Mithrandir> Keybuk: found it.
<daniels> lamont: i'll bounce you the interdiff for an evdev patch, which is just adding one already-built module to input-modules*.udeb
<daniels> lamont: and there's one trivialish thing to be done too -- where we have CONFIG_DRM=y, change to CONFIG_DRM=m, and add drm.ko (or drm-core.ko, whatever) to l-i where needed, although it should just drop straight in
<daniels> lamont: sent
<lamont> daniels: woot
<fabbione> pitti: ping?
<pitti> fabbione: pong
<fabbione> pitti: for curiosity.. how does pmount decide under what user to do the mount?
<pitti> fabbione: getuid()
<fabbione> hmmm
<pitti> fabbione: any better idea?
<fabbione> so if i plug my usb whatever storage device...
<fabbione> how does it detect the user?
<fabbione> becuase i think there is a possible flaw there
<pitti> fabbione: #4021 ?
<pitti> fabbione: indeed, if more than one user is logged in, the wrong one might get the drive
<pitti> fabbione: or, rather, if more than one user has a g-v-m instance running (not affecting console-only users)
<fabbione> yes
<fabbione> i think that needs to have a higher severity
<pitti> fabbione: hard to decide for multi-X logins
<fabbione> it is clearly a security flaw
<fabbione> pitti: not really...
<fabbione> pitti: you can use 2 approaches
<pitti> fabbione: any idea how this could be solved? it is undecidable by design, I think
<fabbione> one is to isolate certain usb hubs/addresses to a specific $DISPLAY
<pitti> how should that work?
<pitti> if two people use a common machine, but two heads?
<fabbione> with a config file?
<fabbione> i can tell that user on head one has this usb hubs dedicated
<fabbione> same goes for the other head
<fabbione> if the head is not local.. no mount
<fabbione> or something like that
<fabbione> or perhaps
<fabbione> even better
<pitti> you mean if $DISPLAY contains a hostname, g-v-m does not call pmount?
<dholbach> erm... does anyone know charles majola's irc nick? 
<pitti> no, that doesn't work
<fabbione> you can also prompt for the user password in order to verify WHO actually connected the device is who claims to be
<sjoerd> a lot of monitors have usb hubs these days, so that sounds nice ;)
<thom> dholbach: d3vic3
<fabbione> pitti: why not?
<dholbach> thom: thanks
<pitti> fabbione: ssh X-forwarding, there DISPLAY is a local port
<pitti> (I think, might be wrong)
<fabbione> hmm true
<ogra> thom: shouldnt that be PythoNpackageMachin3 ?
<pitti> fabbione: however, if two g-v-m instances ask for a password, you have the same race
<HrdwrBoB> pitti: it's very high though, 11 iirc
<pitti> fabbione: whoever types faster gets the drive
<pitti> HrdwrBoB: right, it starts from 10
<fabbione> pitti: but that require userA to know userB password
<pitti> HrdwrBoB: but basing the decision on display numbers seems too fragile
<pitti> fabbione: no, I mean if A types his password, but B types B's password faster, B will get it
<fabbione> pitti: right
<pitti> fabbione: I think the problem is not the authentication
<pitti> fabbione: but the assignment of an USB device to a head
<pitti> fabbione: however, if two people share the same physical host (including USB hubs), then there is no obvious "owner" of the device
<fabbione> pitti: and if there is such mapping somewhere+?
<pitti> fabbione: you had to map that manually
<fabbione> pitti: let say that USB hub1 is assignined to head1
<pitti> there is no "obviously right" mapping which could be decided automatically
<fabbione> pitti: clearly
<fabbione> pitti: i agree
<fabbione> but AGAIN.. let say there is a mapping
<pitti> then this mapping could be used, yes
<lamont> zul??
<fabbione> pitti: how complex would it be?
<pitti> fabbione: you mean a mapping between USB ports and user names?
<HrdwrBoB> USB ports and heads would be better
<fabbione> a mapping between usb ports and head/display on the machine
<pitti> HrdwrBoB: define "head" in terms of sysfs 
<doko_> elmo: ping?
<HrdwrBoB> well $DISPLAY
<pitti> but $DISPLAY changes every time
<pitti> we need a static map
<fabbione> pitti: no it doesn't change everytime
<HrdwrBoB> why would it change?
<pitti> HrdwrBoB: hmm, right
<lamont> HrdwrBoB: the alarm goes off at 1300UTC, whether I like it or not.
<lamont> but the day begins with an hour to drive the kids to school (at 1345UTC)
<HrdwrBoB> USB ports are physical devices, so map them to $DISPLAYS, which should be also physical
<HrdwrBoB> lamont: ah damn, we just have a kitten who likes to sleep on our heads
<pitti> HrdwrBoB: that doesn't work, we _have_ to map to user names, not to $DISPLAY values
<pitti> HrdwrBoB: every user can alter the $DISPLAY which pmount is called with
<HrdwrBoB> hm true
<HrdwrBoB> could g-v-m provide it's $DISPLAY?
<HrdwrBoB> its
<pitti> no, that doesn't work
<pitti> g-v-m is entirely user-privilege
<pitti> d
* fabbione -> brb
<pitti> we need something that pmount can check with its root privileges
<pitti> a property an user can't change
<HrdwrBoB> check it's $DISPLAY, check it's UID
<HrdwrBoB> then check for an the correct X server with that UID?
<lamont> HrdwrBoB: DISPLAY is completely user controlled
<pitti> bah, checking for X servers in a low-level program like pmount is UGLY
<HrdwrBoB> lamont: yeah but you can take that and verify it's correct
<pitti> in particular since pmount does not only work for X
<HrdwrBoB> well if $DISPLAY is undef it doesn't use it
<pitti> HrdwrBoB: this stuff must work on the console, too
<lamont> zul??
<HrdwrBoB> it's ugly but mapping to usernames is not really optimal
<pitti> HrdwrBoB: you cannot tell _anything_ from DISPLAY, you just cannot rely on it
<sjoerd> pitti: fear... pam_console :)
<pitti> sjoerd: how should that help?
<HrdwrBoB> user1 changes console and suddenly his USB devices no longer work
<lamont> ENOZUL
<pitti> if user1 usually works on head1, but now on head2, he can't use the _same_ usb port any more?
<pitti> that doesn't sound like our users would understand
<sjoerd> pitti: dunno if pam_console can do that.. or something like it.. But you could change some properties at login time..
<pitti> bah, but whicever user calls pmount first, gets the device
<lamont> mvo_: that's after upgrading apt, yes?
<pitti> sjoerd, HrdwrBoB: pmount should be entirely self-contained
<lamont> mvo_: and which version of apt?
<sjoerd> pitti: then it's a social problem and you can't fix it :)
<mvo_> lamont: yes, I suspect it only happens with one of your apt-options
<pitti> indeed
<mvo_> lamont: any version, I don't think it's fixed, I just can't reproduce it
<pitti> sjoerd: if two people share physical access to the same computer, there is not a big security issue anyway AFAICS
<pitti> fabbione: ^
<sjoerd> right
<HrdwrBoB> pitti: I was just thinking of the 441 style systems
<HrdwrBoB> if you had a usb port on each head
<sjoerd> i used a shared gid to mount our camera when my parents and me were working on the same box
<sjoerd> local and remote X..
<lamont> mvo_: in 0.6.31, inside the chroot (no options), update works fine..
<HrdwrBoB> you would want it per $DISPLAY, with four users it could get messy
<fabbione> pitti: there is still the fact that i can plug my gpg private key and i don't want it mounted as the other user
<pitti> fabbione: yes, I see that
<sjoerd> fabbione: then you'll probably want it encrypted and impossible for somebody else to mount
<mvo_> lamont: so #5666 (with a identical deb and deb-src line and a Release,Release.gpg file) does not fail for you anymore? sounds like we can close this bug then :)
<sjoerd> as in, not even possible for them to use if that have it in there hands :)
<sjoerd> s/that/they/
<lamont> mvo_: hrm... sec
<fabbione> sjoerd: if the encrypted device is still mounted under the wrong user, it will be impossible for me to loopmount it properly
* lamont recreates the needed conditions
<lamont> and fails
<ogra> python2.2-xmlbase: Depends: python2.2 (= 2.2.3-10) but 2.2.3-10ubuntu0.1
<sjoerd> fabbione: with the ideas we had for encrypted stuff, it shouldn't be possible for somebody to mount it without a password..
<ogra> ubuntu0.1 ???
<pitti> fabbione: how that problem would look like if people work on a console rather than under X?
<pitti> fabbione: i. e. if you don't have $DISPLAY (which cannot be trusted anyway)
<sjoerd> HrdwrBoB, pitti: for 441, you should be able to do it at a gvm level (so only one person has it automagically mounted).. if people do it manually with pmount then it's a social problem imho
<HrdwrBoB> sjoerd: yeah
<HrdwrBoB> I think it's a g-v-m problem
<pitti> but checking at the g-v-m level does not increase any trust (security-wise)
<fabbione> pitti: on console hmmm 
<fabbione> you don't have that problem on that environment
<pitti> the check must be done within pmount
<HrdwrBoB> pitti: it's not trustworthy anyway since you can simply pmount it
<fabbione> because only one user can have console
<HrdwrBoB> it just means that my default it won't automount other peoples stuff
<HrdwrBoB> by
<sjoerd> pitti: it depends on what problem your solving.. just the usability one or do you also want the same security as in a real seperated situation
<dholbach> -> dogwalk
<pitti> sjoerd: I think you really can't have the same security
<HrdwrBoB> the security has to be in pmount or not at all
<HrdwrBoB> otherwise you can always call it manually
<sjoerd> pitti: correct.. i don't think you can solve the last problem
<lamont> mvo_: does not reproduce with 0.6.29 for me.
<pitti> fabbione: if we drop the security issue and just concentrate on the correct (untrusted) mapping, is that sufficient?
<fabbione> pitti: for me it would be sufficient to get the correct icon on the correct dekstop
<sjoerd> if you have a fool mounting your usb stick before you, just whack him on the head :)
<pitti> fabbione: then we can just map $DISPLAY -> USB hub in g-v-m
<mvo_> lamont: cool, thanks. I close it then. If you see it again, please just let me know
<fabbione> pitti: ok.. that makes sence to me
<fabbione> pitti: can you hint me on how to do that?
<pitti> fabbione: or, rather USB hub -> display
<lamont> ok.
<fabbione> pitti: remember that i can use hotplug to generate proper events
<pitti> fabbione: I can implement it, but we have to precisely define where and what we map (and where to configure it)
<fabbione> and i have THAT power
<lamont> daniels: how hot and heavy are you to get your evdev fix?
<fabbione> lamont: ASAP
<lamont> yeah - thought so...
<lamont> one of zul's patches is 403, was hoping to get that in as well.
<lamont> ZUL!!!
* lamont tries yelling for him
<jinty> mdz: ping
<dholbach> re
<Kinnison> Hi, are there known issues with nautilus and the 2.6.8.1-4-686 kernels in warty?
* Kinnison keeps getting nautilus stuck in futex_wait
<Treenaks> Kinnison: log out once, with "save my settings" checked
<Kinnison> what does that do for me?
<pitti> Hi Astharot 
<Astharot> bonsoire
<Astharot> hi pitti 
<Treenaks> Kinnison: it saves your session in some way
<Treenaks> Kinnison: and it tends to un-break nautilus
<Kinnison> Okay, I'll try that later when I don't have so much context waiting
<trulux> pitti: how's going the work on hardened kernels?
<pitti> trulux: it's next to zero, I don't have enough time for it
<trulux> pitti: then you could give me the task
<pitti> trulux: sure, go ahead
<pitti> trulux: right now there are two major issues:
<pitti> trulux: the kernel images don't contain firmware images (so many device drivers won't work)
<trulux> I have experience with it: http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/kernel-2.6.7-dh/
<pitti> trulux: and the vesa framebuffer is broken
<trulux> pitti: why?
<pitti> trulux: if I knew why, I had fixed it :-)
<trulux> what happens to vsefb.c?
<pitti> well, I didn't investigate it
<trulux> vesafb.c
<trulux> pitti: what happened to it?
<pitti> dunno, I did not mess it up deliberately
<pitti> maybe the grsecurity patch affects it
<trulux> yeah, but it depends 
<pitti> trulux: you can take the source packages from people.ubuntu.com/~pitti/linux-hardened/
<trulux> grsec itself has nothing to do with low level drivers
<pitti> trulux: or just branch my arch repo
<trulux> ok
<trulux> pitti: I'm still not a Ubuntu maintainer, but I've read the policy and such
<trulux> pitti: http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/kernel-2.6.7-dh/HARDENING?rev=1.3&content-type=text/vnd.viewcvs-markup
<trulux> pitti: that's how *we* must handle hardened kernels
<trulux> we *must* specify in sources what changed
<trulux> from vanilla
* lamont watches another test build...
<trulux> pitti: who would want to sponsor me in fron of the board to be a maintainer candidate?
<pitti> trulux: you need to do some uploads before I can do that
<pitti> trulux: i. e. if Ubuntu gets ssp pacakges or improved hardened kernel packages
<pitti> trulux: then I can sponsor you
<mdz> morning
<mdz> jinty: pong
<pitti> Hi mdz
<jinty> hey mdz
<jinty> morning!
<jinty> it's about the schooltool packages...
<trulux> pitti: ok, give me a roadmap and I will fill it
<T-Bone> lamont: ping?
<trulux> better, I will remove entries from it
<lamont> T-Bone: ack
<pitti> trulux: there is no roadmap
<pitti> trulux: do whatever you like (fix the hardened kernels, e.g.)
* T-Bone points lamont at the other window
<jinty> mdz: later sometime then, cheers
<mdz> jinty: what about them?
<marcin_ant> hi - any Eclipse user here?
<jinty> wait, i think doko may take care of it for me, I'll come back if i need something else
<trulux> pitti: we need a roadmap
<trulux> we need to know where our feet should walk
<trulux> or we will get lost
<pitti> trulux: well, fix the outstanding issues, upload into universe soon
<pitti> trulux: they should be uploaded very quickly, we are already past feature freeze
<pitti> trulux: but since the packages are in universe, we can still add new ones
<pitti> trulux: once they are in universe, the outstanding issues shuold be fixed
<pitti> mdz: what do you think about uploading the hardened kernels and linux-hardened-support into universe?
<mdz> pitti: as long as no changes to packages in main are required, universe can still receive new packages and features
<pitti> mdz: no, the pacakges are entirely self-hosting
<pitti> elmo: ping
<pitti> mdz: btw, could you test the latest hpoj crack?
<mdz> pitti: is there a version newer than 0.91-3ubuntu3?
<pitti> mdz: no, I mean that one
<zul> ok im back...problems with users at work
<pitti> mdz: that was the version that installs the usermap and hotplug script
<mdz> pitti: that's the version I tested
<mdz> it works fine
<pitti> cool
<pitti> mdz: time for main then?
<mdz> pitti: yes
<pitti> mdz: okay, I update the seeds.
<pitti> supported, I think, right?
<mdz> yes
<mdz> maybe we can find a way to move it into desktop post-hoary
<mdz> mvo_: ping?
<mvo_> mdz: pong
<mdz> mvo_: hpoj gave me an idea
<mdz> mvo_: there are some pluggable devices which require/recommend certain software to be used
<mdz> mvo_: we could set up a hotplug script so that when one of these devices is connected, it creates an update-notifier hook which invites the user to install the necessary package(s)
<mvo_> mdz: that sounds pretty cool
<trulux> pitti: OK, so, in short, tell me what exactly needs to be fixed in hardened kernels
* lamont was fighting with hpoj over the weekend trying to talk to his PSC2410
<pitti> trulux: I already did? vesa framebuffer and firmware inclusion
<mvo_> mdz: it should be pretty easy with the current infrastructure, synaptic supports non-interactive installs via script and update-notifier can display the needed information. very cool indeed. do we have a list about such devices?
<pitti> lamont: did it fail because of the derooting? or in general?
<lamont> pitti: failed to bind kind of bitchiness
<lamont> what do I need to do to re-root it?
<pitti> lamont: install the sid version
<lamont> this is a new printer, so no clue what the root cause is...
<pitti> lamont: well, grab 0.91-3 from the morgue
<mdz> lamont: please help work out the issues rather than re-rooting it
<trulux> pitti: what's needed for the firmaware inclusion?
<lamont> mdz: not what I meant.
<pitti> lamont: sure; I just mean, if -3 works, but 3ubuntu3 not, we should fix that
<lamont> once I have it working _AT_ALL_ then I can figure out what change breaks it
<pitti> trulux: dunno, the default kernel ships firmware images, but mine doesn't
<pitti> trulux: it must be somewhere in the docs (or packaging)
<trulux> pitti: who is the guy that maintains those images? elmo?
<pitti> trulux: I did not deal with that, I was just notified that they are missing
<lamont> mdz: printing works just fine, it's scanning that's still nonexistant in the house
<pitti> trulux: fabbione 
<trulux> pitti: ok
<trulux> fabbione: ping
<pitti> lamont: has the device in /proc the right permissions? I. e. 0660 root:scanner?
<tritium> trulux, hello
<mdz> lamont: printing and scanning are working for me; maybe the test used to set perms doesn't work with your model
* lamont discovers that the morgue, while nice to have online, is not very searchable online
<trulux> tritium: hey!
<lamont> pitti: which file?
<mdz> haggai: ping
* lamont has _never_ successfully configured a scanner on linux
<pitti> lamont: /proc/bus/usb/<hub>/<device>
<pitti> lamont: find it out with lsusb
<tritium> trulux, did you like the figures?
<pitti> lamont: s/hub/bus/
<elmo> pitti/kamion: done
<pitti> elmo: done what? (try to remember my sync request...)
<elmo> awstats
<trulux> tritium: yeah, you did a great job
<pitti> ah, thanks
<lamont> sane-find-scanner 
<lamont> found USB scanner (vendor=0x03f0, product=0x3611) at libusb:001:003
<lamont>  ls -l /proc/bus/usb/001/003 
<lamont> -rw-r--r--  1 root root 170 2005-02-11 22:50 /proc/bus/usb/001/003
<lamont> sudo chgrp scanner /proc/bus/usb/001/003 
<tritium> trulux, thanks :)
<pitti> elmo: can you please sync the following packages, too? netkit-rwho zhcon newspost playmidi
<trulux> tritium: I've added also the correspondiong info in Ack. about your new contrib.
<lamont> scanimage -L still says no scanner identified
<pitti> lamont: chmod 660 ?
<elmo> pitti: done
<pitti> thx
<tritium> trulux, cool, thanks
<lamont> pitti: still no love with 664
<trulux> tritium: you're welcome again :)
<lamont> or even 666
<pitti> lamont: hm, then it seems it's not a deroot problem...
<pitti> lamont: the whole point of the usermap and hotplug stuff is to set the permissions
<lamont> pitti: well, it didn't recognize the device, which would make it the problem if things were otherwise working...
* lamont heard that libusb was b0rked in sarge, fixed in latest sid... that didn't seem to help either
<pitti> hmm, that requires knowledge of the sysfs attributes then
<lamont> pitti: where do I change to fix the usermap/hotplug stuff?
<pitti> lamont: /etc/hotplug/usb/hpoj (script) and hpoj.usermap (device filter)
<tritium> trulux, send me the latest revision, if you don't mind
<lamont> hrm... as root, sane-find-scanner is a bit more verbose:
<lamont> found USB scanner (vendor=0x03f0 [hp] , product=0x3611 [psc 2400 series] ) at libusb:001:003
<lamont> but even as root, scanimage -L is unhappy
<pitti> lamont: you need the interface id/version (in sysfs)
<pitti> lamont: the usermap filters on it
<pitti> lamont: or maybe from lsusb -v
<pitti> lamont: bInterface{Class,SubClass,Protocol} presumably
<trulux> tritium: sure
<lamont> interesting... scanner doesn't show up in lsusb output...
<trulux> tritium: let me finish some stuff
<tritium> okay, please email it since I'm not always at the computer
<seb128> mako: around ?
<lamont> sorry - case issues
<lamont>       bInterfaceNumber        0
<lamont>       bInterfaceClass       255 Vendor Specific Class
<lamont>       bInterfaceSubClass    204 
<lamont>       bInterfaceProtocol      0 
<lamont>       bInterfaceNumber        2
<lamont>       bInterfaceClass       255 Vendor Specific Class
<lamont>       bInterfaceSubClass    212 
<lamont>       bInterfaceProtocol      0 
<lamont> #1 is the printer, #3 is the mass-storage
<pitti> #3?
<pitti> #2 you mean?
<lamont> it has a camera flash thing
<lamont> no, there are a total of 4
<lamont> I just didn't bother to paste #1 or #3
<lamont> just 0 and 2
<pitti> lamont: hm, we don't have 255/212/0
<pitti> lamont: look in hpoj.usermap for the recognized combinations
<lamont> 0 and 2 are almost certainly the scanner and the fax, in some order
<trulux> tritium: ok
<pitti> lamont: _if_ your scanner works, then 255/204 and 255/212 (in hex) should be added to the usermap
<lamont> hpoj claims to support it - I'm tempted to blame udev next. :-)
<pitti> hm, could you please add this combination to the usermap then? and check that it works?
<lamont> Feb 12 10:22:37 mix ptal-mlcd: ERROR at ExMgr.cpp:3762, dev=<mlc:usb:probe@/dev/usb/lp0>, pid=28506, e=1, t=1108228957         Couldn't claim interface=2!
<lamont> Feb 12 10:22:37 mix ptal-mlcd: ERROR at ExMgr.cpp:2559, dev=<mlc:usb:probe@/dev/usb/lp0>, pid=28506, e=25, t=1108228957         Couldn't set up MLC interface!
<lamont> that's what I was getting saturday
* mvo_ is away for swiming, bbl
<lamont> pitti: what should the line look like?  no clue what number is what?
<pitti> lamont: copy&paste an existing line
<lamont> hpoj             0x0701      0x03f0   0x0000    0x0000       0x0000    0x00         0x00            0x00            0xff            0xd4    0x00               0x00000000
<pitti> lamont: the number 0xff is the INterface Class
<lamont> that sure looks like 255/212
<pitti> s/0xd4/hex(212)/
<pitti> oh, it is?
<pitti> hmm
<pitti> indeed
<pitti> sorry
* pitti can't calculate hex
* lamont boots up the laptop to debug things
<pitti> lamont: can you put some logger debug statements into /etc/hotplug/usb/hpoj?
<pitti> lamont: to see whether it is called and whether the DEVICE is right?
<lamont> ok
<mdz> amu, haggai, Riddell: did you guys read my mail to -devel about the packages which want to move to main for Kubuntu?
<mdz> amu,haggai,Riddell: I'd appreciate input from one or all of you on this subject
<Riddell> mdz: ubuntu-devel or kubuntu-devel?
<mdz> Riddell: ubuntu-devel
<mako> seb128: yes
<mako> seb128: whats up
* lamont upgrades his laptop, installs hpoj
<mdz> mako: dude
<mdz> mako: I made a rad contact this weekend on computer recycling stuff
<mako> mdz: dude
<mako> mdz: oh yeah?
<mdz> totally
<mako> let me hear
<mdz> can I hand him off to you?
<mako> yeah, that sounds awesome
<mako> man.. i love computer recycling..
<lamont> daniels: should the xorg debconf question about xkb really say "most users should enter 'xfree86'"??
<mako> free software + computer recycling + grants/cheap/free computer is like pornogrgraphy for me
<amu> mdz: 4674     Feb 11 Matt Zimmerman  ( 107) Kubuntu packages to be promoted to main 
<lamont> mako: recycling as in finding new homes for old hardware?
<mdz> amu: yes, that is the thread
<elmo> grr, WTH is vi-ese for M-% ?
<pitti> elmo: what does M-% do?
<thom> what does M-% do?
<pitti> :-)
<ogra> M = meta ?
<thom> ogra: yes
<elmo> M-x query-replace
<pitti> yes, but %?
<Treenaks> elmo: %s/something/somethingelse/gc ?
<thom> :%s/foo/bar/gc
<crimsun> :%s/foo/bar/g
<elmo> i.e like, s/foo/bar/, but interactive, asking at each occurence
<Treenaks> the "c" does that
<crimsun> ah, you need 'c'
<elmo> aha, thanks
<mdz> mako: ok, sent email
<mdz> mako: basically this guy has a facility set up in LA where they handle inventory of donated hardware, they refurbish machines, and people can come and receive both the machine, and have someone show them how to use it
<mdz> mako: and he seems to have information about a lot of related organizations, both in the US and internationally
<mako> lamont: sort of.. sometimes it actually involves breaking it down and recovering metals
<mako> lamont: but usually taking old machines, refurbishing them into new, good machines
<lamont> kewl
<mako> lamont: there are *so* many old machines.. you'd be amazed at how picky you can be
<lamont> mako: where do you think I get _my_ hardware?
<mako> lamont: there is this awesome place in portland that takes the old machines, has volunteers take a class where they learn to build computers by building computers.. then they build 10 and take the last one home
<mako> lamont: me too.. also my furniture
<lamont> mako: if you toss me contact info for them, I think my brother (in portland - well beaverton) might be interested in getting involved
<mako> lamont: http://www.freegeek.org/
<mako> they stick a debian-based on them, train people on it, before they sell it
<mako> they have multiple isp's in portland officially supporting debian now as a result!
<mako> it's like a solid waste recylcling + computer shop + vocational training + computer give-away + free software advocacy organization
<mako> it's totally awesome
<mako> there are a few other freegeek's now i think too.. and some other recyclers are looking at free software as well
<amu> mdz: i was never in a closer touch with them, only as a kde build depends, except gpgme, which is a part of Aegypten2, and activ maintained ex. by Werner Koch and Intevation     
<mdz> amu: please follow up to the list
<mantiena> Hi all
<mantiena> mdz, I just lost network connection, so it seems didn't got all your messages
* lamont screams
<lamont> pitti: works just &T*&) fine on my laptop.
<pitti> lamont: well, that's at least partly good news :-)
<mdz> mantiena: no, I didn't say anything more to you
<lamont> pitti: yeah, something like that
<lamont> it means that I keep the scanner
<pitti> lamont: you mean that the same scanner works on a different computer?
<pitti> okay, THAT's really odd
<mantiena> mdz, so, how you suggest to test my d-i component ?
<lamont> pitti: the desktop is (1) not fully current hoary :-(, and (2) has really funky USB
<crimsun> elmo: would it be possible to sync rox-filer from Sid please?
<mdz> mantiena: you asked how I did my testing, and I told you that I boot d-i to test
<mantiena> mdz, hehe, this is too slow for me, I'm not debian-installer guru
<mantiena> Kamion, maybe you could help me to test my d-i component, which replaces base-installer ?
<mdz> Kamion also uses d-i to test d-i components
<mantiena> mdz, it's ok to use d-i to test d-i components, but I have problems with starting d-i from chroot environment
<seb128> mako: any news about https://bugzilla.ubuntu.com/show_bug.cgi?id=5330 .
<seb128> ?
<mako> seb128: hm... yes i think we can fix it with fonts and fonts alone let me revive my discussion i was having on this
<seb128> mako: k, thanks
<mantiena> mdz, btw, there is one problem with casper - currently cas[er select same folder (/target) for mounting filesystem.cloop like d-i. It's not good for installing live CD,  could you use another folder ?
<mdz> mantiena: no, not without modifying the other d-i components which use /target
<mdz> it was not an arbitrary choice; casper uses /target because it invokes other parts of d-i which expect /target
<mdz> mantiena: over the weekend, I wrote several messages to ubuntu-devel about installing from the live CD; you should read those if you are planning to work on it
<Mithrandir> thom: re the size of the component selector;  couldn't it be possible to use mod_gzip for the .js files?
<thom> Mithrandir: i was wondering about deflating them
<mdz> lamont: what's the status of the patch review?
<lamont> doh - was going to send out a status saturday night, and fell over into bed.
<lamont> I have looked at about 50% of the patches, and divided them up into various buckets
<lamont> those buckets include "ask so and so", as well as NOBUGFILED, BRANDING, INIT, etc
<lamont> the interesting ones are the NOBUGFILED and XXXPENDING (which could mean NOBUGFILED, or not...)
<mdz> lamont: have you started filing bugs for the ones which need it?
<lamont> no - was hoping to progress faster, and wanted to get a first sweep through - I'll file bugs today
<Kamion> ok, car successfully jump-started, and now off to karate - *sigh* what a day
<lamont> http://people.ubuntu.com/~lamont/patch-status
<ajmitch> yay, got dsl back after 18 hours
<lamont> meanwhile, kernel test build looking pretty good so far - hope to upload that shortly
<Kamion> mdz: sorry if you called me and I missed it, today has been ueber-complicated
<mdz> Kamion: no problem; if you're free later, let's try to connect then, otherwise tomorrow
<lamont> very interesting... xchat grabbed focus, and I can't make it give it back...
<Kamion> mdz: ok, will be back at 10ish so we'll see then
<Kamion> (er, 2200 UTC)
<lamont> but whacking metacity helps...
* dredg kills all focus stealing apps in the face
<mdz> the only focus stealing that happens to me is metacity's attempt at focus-stealing-prevention
<mdz> which has the opposite effect
<dredg> in other news /me  cdbs. that is all.
<lamont> mdz: gconf edit, set it to 'strict'
* lamont hugs his sledgehammer that seb128 gave him
<Mithrandir> seb128: any progress on nautilus?
<jbailey> dredg: Aww, a heart for cdbs on valentines day.  That's sweet ;)
<seb128> Mithrandir: not yet
<mdz> lamont: we can't tell our users that
<Mithrandir> seb128: have you started debugging or should I
<Mithrandir> ?
<dredg> jbailey: yeah, elsewhere i've outlawed valentine's day :)
<lamont> mdz: very true
<lamont> mdz: and the good news is that the stealing code is getting better at not stealing when it shouldn't, for most use cases.
<seb128> Mithrandir: I've some idea on which commit could do that, but there is probably not a lot of changes between both version, so if you want to have a quick look feel free
<seb128> mdz: when does it happen ?
<Mithrandir> seb128: ok, I'll take a look
<mdz> seb128: I commented on the bugzilla bug
<mdz> with two examples
<seb128> k
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=3159#c15
<dredg> i think the only single app that ever made me want to cry wrt focus stealing was gaim
<lamont> what was the meatcity hotkey to iconify everything?
<lamont> hrm.. that was painfully reproducible
<seb128> mdz: right, gaim issue is due to gaim and I don't get the gt one as said on the bug
<lamont> seb128: I'll update my system before I bitch about my pain... :-)
<seb128> k :)
<mantiena> mdz, which emails I should read ? "Merging Live and Install CDs" ?
<mdz> seb128: I wasn't CCed on the bug, so I didn't see
<mdz> mantiena: yes
<seb128> mdz: k
<mdz> mantiena: ignore the ones which are about crazy designs, and focus on the other subthread :-)
<mdz> seb128: I cannot reproduce it anymore after a crash+reboot yesterday, perhaps my metacity was old
<seb128> mdz: k, so we just have "gaim is crap" :)
<seb128> that's not that bad
<mdz> what is gaim doing wrong?
<ogra> stealing focus
<mdz> I have the opposite problem
<seb128> mdz: by default metacity doesn't raise nor give the focus, apps have to ask for it
<mdz> I have people asking me why I am not responding on jabber, and it is because the jabber window is hidden behind something else, and I never sa wit
<mdz> saw it
<ogra> no sound notification ?
<mantiena> mdz, I don't find any reasons which forbids mounting filesystem.cloop on other folder than /target
<mdz> ogra: sound notification only works if I am listening at the exact moment the message arrives
<mdz> mantiena: I explained that to you less than an hour ago, in this channel
<ogra> mdz: hm, sure...
<elmo> jesus christ, the component selectors at almost a Mb
<pitti> elmo: ah, that's the reason it takes ages with a modem
<mantiena> mdz, you don't explained, at least I don't see any reasons. you don't need to modify any d-i components, only AFAIK casper mounts filesystem.cloop could you give some example which component should be modified if you change filesystem.cloop mount point to other folder ?
<mdz> mantiena: localechooser
<mdz> mantiena: netcfg
<mantiena> mdz, these components runs before casper
<mdz> mantiena: you may find this difficult to accept, but I do know what I am talking about with regard to casper
<mdz> repeatedly telling me that I am wrong does not help you to understand
<mantiena> mdz, I understand, that you know all about casper ;)
<mdz> look at /usr/lib/casper/pre.d
<mantiena> mdz, I looked at this
<mdz> if you looked at it, you would have seen that /target is used in the localechooser and netcfg scripts, at least
<mantiena> mdz, hehe, there are no such scripts in casper-udeb, because of this I don't find reasons ;)
<mdz> they aren't in casper-udeb
<mdz> they are in localechooser and netcfg
<mantiena> mdz, now I understand
<dredg> :q
<mantiena> mdz, it seems ubuntu-installer is more different than debian-installer
<dredg> argh
<mantiena> s/than/from
<mdz> mantiena: casper does not even exist in Debian
<mantiena> mdz, I know, I thought that d-i and ubuntu-installer's components are almost identifical, only casper is added in ubuntu ;)
<mdz> elmo: look on the bright side
<mdz> elmo: dan jacobson will never be able to use our bugzilla
<thom> *giggle*
* lamont lunches, albeit very late
* mjg59 watches the Warty livecd break the craptop
<thom> Mithrandir: in answer to your question; no, we can't deflate the javascript
<Mithrandir> thom: why not?
<thom> Mithrandir: just tried it and it broke horribly
<Mithrandir> thom: how so?
<thom> no products
<Mithrandir> that's kinda bad.
<Mithrandir> or a feature, depending on your point of view.
<thom> well, it got a lot faster
<mantiena> mdz, I've read your emails in ubuntu-devel, but don't find info which I should care :( maybe you could point me on needed letters ?
<trulux> sivang: hey
<mdz> mantiena: never mind; I don't have time to spend on it.  this feature is something that I am interested in working on for hoary+1, but right now I need to focus on hoary
<jdub> ogra: so with the xscreensaver patches
<ogra> yup
<jdub> ogra: the only bad bit about the old one is that it flashes a bit going from password entry to VERIFYING to APPROVED
<ogra> yup, exactly...
<jdub> perhaps if it only switched once to either ACCESS DENIED or PASSWORD ACCEPTED (ha ha), it would not be so flashy
<thom> could it not say anything for accepted
<thom> pretty please
<ogra> jdub: i thought about merging them... but currently mdz owns all my spare time ;)
<mdz> thom++
<mdz> "accepted" is when it gives you your desktop back
<thom> persactly
<ogra> did you guys see the new patch ?
<ogra> jdub: did you send it around ?
<mdz> thom: I don't see how we can ship netapplet in its current state
<mdz> thom: please give me some good news
<Keybuk> netapplet is better than the "LOOK AT ME!  LOOK AT ME!  LOOK AT ME!" network monitor
<jdub> ogra: oh, no, i didn't upload it
<ogra> jdub: i didnt mean did you package it ;)
<ogra> jdub: i think replacing the verifying part wirt the faded dots would be a good thing.... leaving the DENIED as it is and dropping the APPROVED in favor of switching directly to the desktop after the dots fadet
<ajmitch> ogra: spicing it up even more?
<ogra> ajmitch: dunno if i'll find the time, just trying to find the right way _if_ i got some time left....
<zul> later
<dholbach> bye zul
<ogra> ajmitch: since the flickering isnt to beautiful....
<thom> mdz: i know, i'm working on it
<thom> mdz: what specific complaints do you have currently?
<jdub> ogra: ok, cool
<mdz> thom: switching between interfaces or wireless networks seems to stall frequently, with no user feedback
<ogra> jdub: ok, i'll put it on my list this way... lets see about my time....
<thom> mdz: nod
<bluefoxicy> does anyone know of a resource for how to make debs with complex dependencies
<bluefoxicy> I don't see it in the debian new maintainer's guide section 4.1
<ajmitch> what do you mean by complex though?
<mdz> elmo: apparently, logging into the website doesn't work on ubuntu.com, only ubuntulinux.org
<mdz> at least that's my experience
<bluefoxicy> I want to do something like DEPENDS:  ((policy-grsec && policy-grsec-mypackage-1.0) || !policy-grsec), ((policy-selinux && policy-selinux-mypackage-1.0) || !policy-selinux)
<Keybuk> bluefoxicy: it's called "you can't do that"
<dholbach> hi azeem
<azeem> hi
<jdub> mdz: what's the cost of setting up a new germinate?
<bluefoxicy> Keybuk:  damn
<bluefoxicy> Keybuk:  I want it so that if I install policy-grsec, every package with a grsec policy demands that I install th egrsec policy; and if I remove policy-grsec, every package demands that i remove the policy
<bluefoxicy> witohut making the packages depend on policy-grsec
<mdz> jdub: I think it's pretty cheap; check with Kamion
<Keybuk> bluefoxicy: there's no way to represent that
<bluefoxicy> Keybuk:  damn.
<Keybuk> however
<Keybuk> make all the package grsec policy packages depend on policy-grsec and provide grsec-policy
<Keybuk> make policy-grsec depend grsec-policy
<Keybuk> make all the packages suggest their grsec policy
<Keybuk> actually, the middle is probably a Recommends
<mantiena> mdz, btw, why en_ZA.UTF-8, en_GB.UTF-8 and en_US.UTF-8 locales are generated every time when liveCD starts ? it wastes a lot of time on average computers (~1 Ghz, 256 RAM) :(
<bluefoxicy> Keybuk:  I want a hard dependency
<Keybuk> sorry, I'm too busy smirking to answer that :p
<bluefoxicy> in a system with grsecurity, policy-grsec would be what allows programs to actually run; without the policy fragment for the package, no user (even the administrator) could run the program
<mantiena> I think we should simply generate needed locales in filesystem.cloop when building CD and /usr/lib/casper/pre.d/15localechooser should just check for missing locale (if user chooses another language) and generate only not already generated locale
<bluefoxicy> so the problem of course is that it's really a dependency, not a recommendation (as much as libc6 is a dependency and not a recommendation)
<Keybuk> then make it a dependency
<bluefoxicy> whereas in an SELInux system, policy-selinux would be enabled, but would be ahard dependency too
<Keybuk> or just include the policies in the package
<bluefoxicy> too/instead, depending on if your admin is insane
<bluefoxicy> Keybuk:  yeah, I thought of including it in the package.  It's possible, but even security devs fuck up
<bluefoxicy> imagine "the openoffice policy fragment is fucked.  releasing openoffice.org-2.0-1 with new policy, 180M download"
<bluefoxicy> plus that means you can't actually . . .not install the policy
<bluefoxicy> which was my goal :)
<Keybuk> what's the drawback of installing the policy when you don't need it?
<bluefoxicy> just space usage really, unless you're experimenting in  maintaning your own policy (for academic purposes)
<bluefoxicy> though, there's LIDS, SELinux, GrSecurity, and RSBAC
<bluefoxicy> and DiSec I dunno how they do their policy
<Mithrandir> bluefoxicy: that's like "ooo maintainer script is fucked up, 180M download".
<bluefoxicy> Mithrandir:  yeah exactly.
<Keybuk> make the policies config files
* lamont uploads 2.6.10-17
<bluefoxicy> heh
<jdub> lamont: any movement on inotify crasher?
<bluefoxicy> Keybuk:  i don't want to force install 10 policies for 10 macs  :)
<lamont> jdub??
<lamont> new inotify patch from zul, if that's what you mean
<jdub> ok
* jdub is slightly more interested in "fixes crasher" than "new patch" ;-)
* lamont dunno about crasher...
<pitti> hey, there really is somebody whose machine _didn't_ crash due to this? :-)
<jdub> yay, grumpy editor likes gthumb
<ogra> crash ?
<Mithrandir> pitti: what bug?
<pitti> ogra: yes, the machine randomly freezed when doing something (or sometimes when doing nothing) with removable drives
<pitti> Mithrandir: ^ that one
<Mithrandir> I don't use many removable drives on this laptop, so.
<ogra> pitti: ah, ok... didnt know it....
<lamont> pitti: what's a removable device? :-)
<lamont> bad cdebconf
<Mithrandir> lamont: hotplug SCA drives.
<ogra> hehe
<pitti> lamont: one you can bite in without breaking your back when you lift it :-)
* lamont looks around for doko so he can hit him with cdebconf
* ogra has seen SCA drives that had nearly broken it :)
* lamont grumbles at elmo for changes mail now coming from katie instead of the uploader
<lamont> heh.  sometimes
<amu> hmm daily-live ( i386 ) has some trouble with booting, Kernel Panic - nit syncing: VFS: Unable to mount root fs on unknown-block(8,3) 
<amu> s/nit/not
<jdub> seb128: eeek, that crazy screen fadeout thing is in our gksu?
<seb128> jdub: yep, but that's easy to change if you want
<seb128> we can drop the patch
<sivang> hey all
<jdub> seb128: would prefer we lost it, it's really extreme ;)
<seb128> we have added it because some people were complaining in bugzilla and the list
<seb128> now you want to drop it
<seb128> grrr :p
<seb128> (I don't like it to be honest)
<seb128> jdub: BTW since you are here, file monitoring doesn't work with gamin ....
<seb128> jdub: ie: try to clear the recent documents in the place menu, or add a gtk bookmark
<ogra> jdub: the one from the logout dialog 8O
<ogra> n, do not show window decorations, us ??
<jdub> seb128: i'll upload without the 0.19 support patch
<jdub> seb128: actually
<jdub> seb128: have you seen mvo's workaround for single file monitoring?
<jdub> seb128: perhaps that's the problem with .recently-used
<seb128> jdub: nop, heard about it, but not read the code yet
<seb128> jdub: file monitoring is not working
<seb128> jdub: that's the issue with recently-used, that's the issue with the bookmarks, etc
<jdub> it's working here...
<seb128> seriously ?
<jdub> i am serious
<jdub> i shit you not
<seb128> have you tried to clear the recent documents ?
<mvo_> jdub: my workaround shouldn't be used :) it's really a hack 
<seb128> mvo_: bad guy
<jdub> seb128: yeah
* mvo_ blames gtk
<jdub> seb128: however
<mvo_> oh, wait
* mvo_ blames inotify
<seb128> mvo_: you should kick jdub do get gamin fixed instead of cheating
<jdub> seb128: now that i test in /tmp, it is not working
<seb128> ah ah
<jdub> seb128: but it works on stuff in my nfs-mounted homedir :)
<jdub> i will remove that patch and see what happens
<seb128> perhaps that's a local fs specific bug :p
<seb128> I don't think that's the patch
<jdub> whatever it is
<seb128> mvo pointed the issue with 0.21 or 0.22
<jdub> it's caused by the french ;)
<seb128> jdub: true :p
<seb128> mvo_: BTW metacity doesn't raise your window because that's evil, the goal is to avoid beeing annoyed by app like yours acting in a bad way :)
<jdub> no, see, if i restart nautilus after i restart gam_server
<jdub> it's fine
<jdub> i get notifications in /tmp, for recent documents, etc.
<Hwolf> Is there any way to couple two windows together in one virtual window? 
<seb128> hum
* Kamion gets back
<Kamion> jdub: what do you want out of germinate?
<mvo_> seb128: actually I think my use-case is a valid one. I only want a single instance of a application. if that application is already runing and the user tries to start it twice, instead of opening up a new window it opens a existing one. not too evil :)
<jdub> Kamion: was wondering what the cost of setting up a new one, alongside ubuntu and kubuntu would be, but only for a livecd (this is not at all crucial)
<seb128> mvo_: yeah, but you should give the focus too, so you don't use the right function with gdk_raise_window () :)
<jdub> mvo_: i agree
<mvo_> jdub: I noticed that too, if the gam_server is killed/restarted it seems to work again
<mvo_> seb128: I with gtk_window_present() now :)
<jdub> mvo_: monitoring in general, or the single-file monitoring bug you had?
<seb128> jdub: killall gam_server gnome-panel doesn't fix it here, and running GAM_SERVER=1 gnome-panel should that it doesn't get an event on the clear 
<mvo_> jdub: the single file case IIRC (but I tested it last week, I may be wrong)
<Kamion> jdub: "new germinate" <- EPARSE
<Kamion> jdub: I think you mean "a new set of seeds"?
<seb128> mvo_: correct, I just asked why raise_window () doesn't raise it (BTW that's written in the API, for a top_level windows that's decided by the wm)
<jdub> Kamion: sure
<seb128> jdub: I'm speaking about monitoring *one* file (ie .recently-used or .gtk-bookmarks)
<seb128> jdub: nautilus works fine
* sivang ---> install hoary on a new SATA disk.
<jdub> seb128: oh man, i've already cleaned out my recent documents
* jdub opens random documents
<Kamion> jdub: have a look at what the arch revision kubuntu-devel@lists.ubuntu.com/seeds--hoary--0--base-0 did; it's about that expensive plus ten minutes of my time setting up mirroring and stuff
<jdub> seb128: yeah, worked again
<seb128> doh
<seb128> my box is cursed
<Kamion> jdub: (with the proviso that modifying the base seed is, for the moment, not useful)
<jdub> heh, ok
<seb128> I'm sure that's a bug fr_FR specific, you hate french
<seb128> (vuntz has it too)
<jdub> Kamion: what will it take to start doing livecd builds from different seeds?
* mvo_ needs to go to bed now
<Kamion> jdub: you mean the Hoary live CD, or something else?
<Kamion> (the Hoary live CD already uses the casper and live seeds to do different stuff from the install CD)
<jdub> seb128: running 2.6.10-16?
<jdub> Kamion: new, not-entirely-ubuntu livecd builds from those different seeds
<jdub> Kamion: mostly concerned about resources
<Kamion> jdub: lamont will need to do different rootfs builds off the different seeds (either different metapackage or just a big apt-get install)
<seb128> jdub: 2.6.10-3-k7
<Kamion> jdub: and then cdimage needs to do daily builds, etc., so a couple of GB/day churn
<jdub> seb128: but -16 package version?
<Kamion> jdub: we're not really set up for massively parallel CD building just yet
<jdub> Kamion: mmm
<Kamion> in particular cdimage really doesn't do proper locking yet ;)
<jdub> Kamion: how long does it take to build a rootfs atm?
<seb128> jdub: ups, yep
<Kamion> jdub: dunno, lamont would probably know
<Kamion> the log file doesn't have timestamps
<Kamion> daily-live builds on cdimage take ~5 minutes
<jdub> ah well
<jdub> thanks
<Kamion> np
<Kamion> in general I'm happy to extend germinate to do pretty much whatever ... I want it to be general. *at the moment* I think it has enough to do all the seeds we might want, but it might not in the future :)
<whiprush> jdub: heh, all the ltsp stuff here is running on ubuntu
<ogra> troll alert in #ubuntu
<pitti> argh
<ogra> could someone ban that guy
<jdub> whiprush: rockin' :)
<jdub> whiprush: at the ltsp booth?
<whiprush> yeah, then they're feeding OOo, GNOME, and a few others' thin clients
<whiprush> I'll get a coolio Ubuntu desktop pic
* Mithrandir gets a headache
<jdub> whiprush: wow, nice one :-)
<jdub> whiprush: up for doing an ubuntu report? ;)
<whiprush> from here? sure.
* Gagatan gives Mithrandir a pill
<jdub> whiprush: and one for gnome too? ;)
<Mithrandir> CRRAAAAACCCKKK
* Mithrandir wonders if his nautilus bug is really a bug in Xlibs
#ubuntu-devel 2005-02-26
<whiprush> jdub: I'll do a big blog post.
<Hwolf> whiprush, what are you talking about?
<zul> hey
<jdub> whiprush: sweet ;)
<zul> lamont: thanks for doing the upload
<Keybuk> can we put figlet into ubuntu-base? :p
<smurfix> What's with d-i(ubuntu11)'s build/Makefile? installing a nonexistent trc.sh seems not to work particularly well ...
<Kamion> I just made my fiancee laugh with figlet "Happy Valentine's Day!" | cowsay -n
<smurfix> ah, my fault
* smurfix bad
<Kamion> <cjwatson@cairhien ~/src/ubuntu/debian-installer/debian-installer-20041227ubuntu
<Kamion> 11>$ grep trc build/Makefile
<Kamion> <cjwatson@cairhien ~/src/ubuntu/debian-installer/debian-installer-20041227ubuntu
<Kamion> 11>$
<smurfix> Kamion: my fault, I misapplied a local patch
<zul> mjg59: ping when you get a chance there are some ibm thinkpad acpi suspend patches that you can look at for me
<smurfix> Anybody know if/when mdz'll be back?
<Mithrandir> seb128: it wasn't a nautilus bug at all -- it was a bug in openbox which set the _NET_WORKAREA to insane values.
* Mithrandir thinks he should get a bit drunk soonish
<mjg59> zul: Hi
<zul> mjg59: http://zulinux.homelinuz.net/ubuntu/kernel/patches/acpi
<Mithrandir> hm, I need an ia64 to try to reproduce this problem.
<zul> mjg59: its the thinkpad_suspend patches
<zul> mjg59: they were taken from the ac tree
<Gagatan> Mithrandir: want a beer? *cheers*
<seb128> Mithrandir: oh ok
<Mithrandir> Gagatan: I'm going home for some whisky, I think.
<ogra> Mithrandir: so thats why i never saw it in metacity :)
<seb128> Mithrandir: that explains why there is no bug in bugzilla :p
<Mithrandir> seb128: it got triggered by the 64 bit fixes in nautilus, though.
<Gagatan> just finished the bottle of Noilly Prat with some iced tea
<Mithrandir> ogra: yup, metacity is fine -- it uses a long * instead of a guint32 *
<seb128> Mithrandir: yeah, I was thinking to the 64bits/desktop patch 
<Mithrandir> seb128: it just triggered it; I've got insane values like this for _NET_WORKAREA:
<ogra> heh
<Mithrandir> _NET_WORKAREA(CARDINAL) = 0, 768, 0, 768, 0, 768, 0, 768, 0, 768, 0, 768, 0, 768, 0, 768, 0, 768, 0, 768, 0, 177, 2531391064, 2531391064, 768, 1, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0
<Mithrandir> I wonder how it has _ever_ worked, tho
<seb128> yeah
<zul> mjg59: if they were ok i was going to add them to -18
<mjg59> zul: Hm. I thought we had those already.
<zul> lemme check
<mjg59> zul: Yeah, they're in already
<zul> ok cool
<mjg59> I picked those up a while ago - they're needed to get interrupts working after swsusp resume
<zul> gotcha
<zul> bbl
<lamont> jdub: about 45 min to build the rootfs
<pitti> night everybody
<jdub> lamont: ah, ta
<jdub> lamont: on superdooper hardware, i guess?
* mjg59 gets the craptop to do something other than reboot on resume
<mjg59> Hrmph.
<mjg59> No, that time it just rebooted again.
<mjg59> Bah. Seems to have been a freak occurance.
<lamont> jdub: that's on the data center machines, yes
<lamont> but for local hackery, you can skip a couple steps, and then it's just time to debootstrap+apt-get install ubuntu-desktop+about 5 minutes for locales
<lamont> if you have a local mirror, it's not bad at all.
<lamont> we burn about 15 minutes in the name of rsync-ability
* lamont realizes that his wife gets home tomorrow, curses
<lamont> too many honey-dos to do today
<jdub> lamont: aha
<jdub> lamont: ok, i might be able to build them here then
<jdub> lamont: got the rootfs script handy?
<Mithrandir> daniels: the docs for XChangeProperty is wrong, or the implementation is.
<sivang> just installed installed a new hoary daily build, worked as a charm - does anybody know why it seems to not allow me to put grub onto the SATA /dev/sda ? (first SATA disk)
<sivang> (maybe grub won't ever boot from a sata drive)
<Mithrandir> sivang: grub is happy with SATA drives
<sivang> Mithrandir: hmm, then maybe a too-much-autoconfiguring d-i ? ;-)
<Mithrandir> no idea. :)
<sivang> it said something like "are you happy with installing the boot loader to the first drive's master boot record"
<sivang> and I answered yes, as in "sure, this is my SATA drive currently" and he ended it up in /dev/hdb weird :)
<Mithrandir> it depends on the order of the drives in your bios
<sivang> Mithrandir: hmm, interesting. I explicitly made the SATA one boot first , oh well, never mind, I'll put grub on the SATA drive manually :)
* ogra sees the hoary backports forming in #ubuntu
<ogra> :(
<Mithrandir> ogra: hopefully, they'll go away once hoary is actually out.
<ajmitch> they're complaining about not having the latest software in hoary already :)
<Mithrandir> and it's part of the "price" way pay for the community -- some do what the developers consider unwise, but there's nothing we can do to stop them (and it's probably not worth the effort)
<ogra> Mithrandir: <BockBilbo> but in this period of "featurefreeze" there is no oportunity to have the latest software
<Mithrandir> which software is he missing?
<ajmitch> he was wanting php5
<ogra> Mithrandir: the latest ;)
<Mithrandir> uhm, uhm.
<Mithrandir> that has nothing to do with feature freeze, really, but more that php5 isn't really ready.
<Gagatan> php5 is in "new packages" back in debian iirc... /me seconds Mithrandir on that one
* sivang is glad seb128 is not here to hear all this "not current enough software in hoary" whine :)
<ogra> Mithrandir: but if it gets released one day before hoary, you got your first backports candidate
<ajmitch> Gagatan: maybe, just maybe it could go into universe, if we're allowed :)
<Mithrandir> Gagatan: I'm talking with \infty at least once a day and he's grumpy enough about php4. :P
<Gagatan> Mithrandir: hey, who isn't ;)
<dholbach> re
<ajmitch> wb dholbach 
<Mithrandir> ajmitch: people would start using it despite it not being supported, security-wise and all
<Mithrandir> hiya Daniel
<ajmitch> Mithrandir: and you'd be lucky to find a MOTU willing to support it, I think
<Mithrandir> true
* Mithrandir notes it's about 01:47 and decides to go to bed, having fixed one RC bug today.
<ajmitch> it's a package that I would like, but I don't know it well enough to support
* ogra applauds Mithrandir
<dholbach> what package are you talking about?
<ajmitch> php5
* dholbach missed a bit of the conversation
<dholbach> ah ok
<mdz> Kamion: still up?
<dilinger> Mithrandir: funny, the impression i get from infinity is that he's having lots of fun w/ php4 :)
<zul> hey dilinger 
<ogra> mdz: 5870 was closed yesterday.... just no bug update yet
<dilinger> zul: hello
<lamont> hrm... guess I should fix mplayer for folks...
* lamont tries to remember who told him about that originally
* lamont beats daniels with the thrice-asked xserver-xorg questions on apt-get dist-upgrade
<zul> heh
<lamont> I mean, they seem to be the same questions we did or didn't ask in the first place....
* lamont reboots
<thully> hi - any plans to improve userland wireless support in Hoary?  I've had some major problems getting my wireless to work well using only the default tools.
<zul> eventually i guess
<thully> I've logged bugs on a few - including the fact that configuring my wi-fi in GNOME causes the entire system to wait for a wireless network for 20sec on boot...
<dholbach> i'm off to bed happily - just did my first 3 uploads ;-)
<dholbach> sleep tight everyone
<lamont> firecall
<mdz> lamont:    http://bugzilla.ubuntu.com/show_bug.cgi?id=6484
<wasabi> Are versionings containing ~ allowed in Ubuntu at this point?
<wasabi> s/versionings/versions/
<zenwhen> i just wanyted to tell you all that Ubuntu runs perfectly on this old P2266Mhz laptop with 160MB of ram using XFCE.
<zenwhen> Everything "just works".
<zenwhen> wanted*
<zenwhen> Hoary
<helix> every time I look in here I see usual's quit message
<kent> helix, perhaps you live in a timezone which most other dont? so you always get here when we go to sleap ;)
<helix> maybe
<dilinger> helix: it's a sign.  watch more kevin smith movies.
<helix> nooo
<jdub> okay
<jdub> something is pushing my clock forward an hour
<jdub> and no reboot is involved
<jdub> ntpdate fixes it up
<jdub> not running ntp
<HrdwrBoB> that happened to me after I upgraded to hoary on the weekend
<HrdwrBoB> I put it down to bizarre space aliens tampering with DST
<lamont> mdz: cool
* lamont wonders why he has to click in the border of a window to raise it now, instead of just anywhere in the window...
<lamont> hrm... sound is busted
<lamont> hrm... scanner works on the laptop, but not when connected to the desktop (which has cupsys configured to talk to the printer...)
<wasabi> Is ~ allowed in the Ubuntu archive?
<wasabi> It's very useful. =)
<wasabi> (versioning)
<lamont> wasabi: pretty sure the answer is 'not yet', if you're talking about version numbers
<wasabi> Yeah, i am.
<wasabi> So, any suggetsions on this version number? I have a package, gjdoc.... It's a CVS checkout. It is labeld 0.7.1pre3. My checkout is post pre3, but pre pre4 (or release).
<wasabi> Was going to do 0.7.1~pre3.20050212 which is very clear and very useful... but apparently not. =)
<infinity> 0.7.0.99pre3.20050212
<wasabi> oh hi. =)
<wasabi> thx for your help on the other side heh.
<infinity> I'm stalking you.  <nod>
<infinity> Mithrandir : php5 for hoary would be a mistake.  php5 in debian is still a mystery right now (what's in queue/new almost certainly shouldn't be there)
<fabbione> morning guys
<mdz> kent: helix lives in a time zone apart from the rest of the world ;-)
<helix> my timezone is awesome
<mdz> you're somewhere in the middle of the pacific I think
<helix> I wish
<mdz> or perhaps you're in Antarctica, and can just run around the pole and change time zones at will
<helix> I live in an igloo and frolic with polar bears
<farruinn> in antartica?
<helix> yes
<mdz> there are no polar bears in Antarctica
<helix> have you ever been here?
<mdz> no, I wish
<farruinn> and the Inuits live in the arctic as well
<farruinn> (although I'm sure you could build igloos in antarctica if you wished)
<mdz> building polar bears is trickier
<helix> mdz: could I call myself an antarctist?
<mdz> helix: I suppose you could say you practice antarcty
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development UP ALL NIGHT | #ubuntu for support and general discussion | http://www.ubuntulinux.org/wiki/DeveloperResources | http://www.ubuntulinux.org/wiki/HoaryGoals
<helix> heh
<fabbione> ehehe
* mdz puts on boomtown rats
<helix> what kind of music is that?
<mdz> cheesy 80s tunes
<mdz> specifically "up all night"
<helix> I like lionel richie's "fiesta" for those kinds of moods
<helix> I think it's lionel richie
<jdub> billy ocean
<helix> nah, it's lionel richie
<helix> "all night long"
<helix> billy ocean sang that o/~ get outta my dreams, get into my car o/~ song
<fabbione> daniels: ping?
<daniels> pong, yo
<daniels> i'm just eating lunch, be with you in a sec
<fabbione> daniels: sure
<fabbione> enjoy :-)
<daniels> pasta :)
<fabbione> ehehhe
<mdz> I bet fabbione's pasta could beat up your pasta
<daniels> hey, don't hate on my pasta
<daniels> gnocchi is love
<daniels> as is sugar.  mmm, sugar.
<mdz> I don't like sugar
<mdz> I like starch
<helix> mmm, potatoes
<mdz> and protein, mm, protein
<mdz> glorious legumes
<crimsun> gotta control my carb intake
<helix> legumes++
<helix> mdz: you're ruining my fast ;(
<fabbione> pasta++
<mdz> helix: serves you right for having an eat-a-thon without me
<helix> dude, that's so unfair
<fabbione> http://people.ubuntulinux.org/~fabbione/pasta/
<helix> I begged you to come
<mdz> and I told you I had a prior engagement :-(
<daniels> mdz: sugar is wakey
<mdz> there is so much good food in nyc
<helix> mdz: yeah, but those are mostly gone
<helix> and I'm there for 10 days!
<daniels> fabbione: i'll chuck all my stuff on chinstrap in a sec, just need to clean up this script
<helix> that's like, forever
<helix> stuff could move into debian testing in 10 days
<fabbione> daniels: sure. i am digging into esd stuff... do you know what starts it?
<mdz> hahaha
<fabbione> daniels: i can't find any reference in /etc
<daniels> fabbione: i assume it's started by gnome-session
<mdz> helix: in this case there is this heavy soname transition going on
<helix> word to sonames
<helix> mdz: wait, and you're involved in it?
<mdz> helix: booo
<helix> :)
<helix> mdz: I'm still not seeing the problem. pretty much all of NYC has a wireless connection.
<helix> you could work anywhere!
<fabbione> daniels: hmm and where do we tell gnome-session to start esd?
<mdz> helix: this is a personal trip, not a professional one
<mdz> I'm visiting my family
<daniels> fabbione: i don't know sorry ... ez gtk boog
<helix> I'll keep trying
<daniels> fabbione: you'd really have to ask seb or jdub on this one
<mdz> my mother has been sick :-/
<daniels> mdz: hope everything turns out ok
<jdub> fabbione: gnome-session does it itself, see sound properties
<helix> mdz: oops :( *hugs*
<mdz> I don't think she's dying, but I can never get the truth out of her over the phone
<daniels> jdub: what we need to do is have esd start with a variable device
<fabbione> HMM
<fabbione> there is also the problem that esd is limited
<mdz> speaking of sonames, /me uploads flac
<mdz> where all _four_ of its shared libraries have been incremented this time
<helix> * the_world waits in horror
<crimsun> mdz: 1.1.2?
* daniels weeps.
<mdz> crimsun: yes
<crimsun> mdz: joy!
<jdub> daniels: aha
<jdub> mdz: is charles going to hate you for this?
<mdz> jdub: well, I'm only uploading it to Debian so far
<mdz> I don't see any particular justification for a FeatureFreeze exception in Ubuntu
<helix> oh, nice. "in case it breaks, muahahaha"
<mdz> though, it does fix a versioning error
<mdz> 1.1.1 changed ABI without a soname increment in one of the libraries
<mdz> i don't think it's used in Ubuntu main
<crimsun> I've triggered the id3v1 tag bug that's fixed in 1.1.2, actually
<crimsun> but I'll deal :)
<mdz> jdub: I think charles has only done a couple of packages so far
* fabbione sighs
<fabbione> daniels, jdub: sometimes between today and xmas? :P
* daniels frowns.
<daniels> Kamion: ping?
<_mvo_> daniels: he's very likely sleeping
<daniels> mmm, true
<daniels> mdz: do you know how to get a mini.iso out of the daily build?
<mdz> daniels: it's in there somewhere
<daniels> mdz: i'm kicking cron.daily by hand, and no mini.iso is forthcoming
<mdz> http://archive.ubuntu.com/ubuntu/dists/hoary/main/daily-installer-i386/current/images/netboot/mini.iso
<daniels> mdz: right, but I need to kick my own
<daniels> mdz: need a cd with l-i -17 installed
<mdz> make netboot_blah_blah
<mdz> daniels: install or live?
<mdz> isn't -17 the current version in hoary?
<daniels> mdz: install
<mdz> I could roll a build on little for you
<daniels> mdz: i have cdimage access to little, dude
<mdz> so what do you need exactly?
<daniels> mdz: i kicked a build with cron.daily and environment variables up the hizzay, but /srv/cdimage.u.c/scratch doesn't have a mini.iso
<mdz> a fresher d-i build?
<mdz> dude, you are in the wrong place
<daniels> yeah, a mini.iso built for i386 with what's in the archive now
<mdz> mini.iso is built by d-i
<mdz> you're at the debian-cd level
<daniels> d'oh
<mdz> I can kick off a d-i build (for reference, so can lamont and Kamion)
<daniels> that would be awesome, thanks
<daniels> just as long as I can get my hands on a mini.iso with l-i -178
<daniels> er, -17
<lamont> daniels: it'll take a while to get to -178, I hope... :-)
<daniels> heh
<mdz> daniels: building now
<daniels> mdz: thanks a lot
<bluefoxicy> any reason mono isn't available on amd64
<bluefoxicy> -rw-r--r--  1 bluefox users 12701 Nov 13 19:28 amd64-codegen.h
<daniels> bluefoxicy: because it only really works with mono 1.1, which requires a complete packaging.  it's in universe, so if you want to totally repackage that and line it up with motu, that'd be great, thanks.
<lamont> bluefoxicy: I expect it's because I have to bootstrap it
<lamont> if someone tells me that what's in the archive should actually work, I'll turn the crank - but it'd be nice to know that before I spend time on it...
<bluefoxicy> hmm
<bluefoxicy> daniels:  not tonight, and i really have nfc what I'm doing anyway
<daniels> lamont: nope, needs repackaging
<bluefoxicy> but if you want to walk me through it tomorrow some time (3:30p EST I have an interview)
<bluefoxicy> it may provide a good learning experience.
<bluefoxicy> once I learned to write ebuilds on gentoo I brushed 'em up and tested patches at my liesure, and also wrote a few to contribute
<bluefoxicy> nothing says I won't do the same if I can get past dpkg's learning curve
<daniels> no, i really do not have the time; there is some excellent documentation on www.debian.org/devl/newmaint/ that have served fine for around 1000+ new maintainers
<daniels> er, /devel/newmaint/
<bluefoxicy> ok
<bluefoxicy> well, i"m the hands-on type.  More like I'm lazy; my idea of documentation is "Here we will do X and there we tell you what you're doing.  Build X, read the other real docs, and you should know exactly what your'e doing and have a process to modify for everything else"
<bluefoxicy> but eh
<bluefoxicy> not your job to babysit me
<daniels> there's a difference between being hands-on and having a bash at things (which is also my style of learning) and needing to be spoonfed
<bluefoxicy> I know.
<bluefoxicy> like I said, lazy.
<bluefoxicy> I'll read the first line of documentation and then drop straight to the bottom of the screen like "blahblahblah where's the part that tells me to put files somewhere and enter some command"
<daniels> that's probably an attribute you'll want to work on
<bluefoxicy> ya think?
<bluefoxicy> I did actually build some debian packages a while back
<bluefoxicy> which is worrisome:  my character's gotten bad over time.
<bluefoxicy> I like contributing, but I'm so damn anal I annoy the shit out of everyone, and when they give me something to do I don't do it o.O
* helix is shocked
<bluefoxicy> and I'm flooding the channel again
<bluefoxicy> I should shut up now.
<mdz> daniels: build is finished
<mdz> daniels: it'll need elmo love in order to get into the archive
<mdz> but lamont might be able to snatch it from the jaws of the buildds
<daniels> ok, thanks
<daniels> uncle laamoooonnnnttttt ... :)
<fabbione> lamont: -17 has changed the ABI?
<da_bon_bon> hi all
<da_bon_bon> updated to hoary
<da_bon_bon> how do i know whether udev is runing or no ?
<fabbione> lamont: ?
<da_bon_bon> how do i know whether udev is runing or no ?
<lamont> fabbione: I don't believe it has?
<fabbione> it did.. probably due to inotify update
<lamont> daniels: shortly after it d-i finishes uploading, it goes *poof*
<fabbione> lamont: i guess you are going to sleep soon, aren't you?
<lamont> yeah
<fabbione> ok
<lamont> fabbione: GAH! - scream at zul, eh?
<da_bon_bon> fabbione, lamont: how do i know whether udev is running ?
<fabbione> lamont: i need to revert one patch at a time to figure that out...
<fabbione> lamont: can i go with -18 if i find the change and it is undoable?
<fabbione> lamont: if the security patch changes the ABI than we need to do it properly
<lamont> fabbione: sure
<fabbione> ok
<lamont> fabbione: out of curiosity (and because I _should_ know in the future) what made you realize that the abi had changed?
<fabbione> modprobe nvidia
<fabbione> :-)
<fabbione> to test the ABI you install the new kernel without rebooting
<fabbione> and try to load a module
<fabbione> if the module will load the ABI is the same
<fabbione> or it is supposed to be the same
<fabbione> if it doesn't the ABI is broken
<lamont> ah, cool
* lamont will remember
<dholbach> morning guys
<daniels> lamont: so when does mini.iso hit cdimage.u.c?
<dholbach> hi d3vic3
<d3vic3> hi
<lamont> daniels: as soon as elmo puts it in the archive
<lamont> assuming it's built as part of the build.
<lamont> OTOH, I do have the tarball still sittinga round on the buildd, I expect...
<daniels> ah, so it's byhanded
<daniels> if I could get at the mini.iso at all, that would be fantastic
<doko> good morning all
<dholbach> hi doko
<_mvo_> hi doko 
<mantiena> Kamion, hi
<tuo2> brb
<pitti_> Morning
<pitti_> fabbione: bah, 2.6.11 reproducably crashes on my desktop
<fabbione> lamont: still around?
<fabbione> pitti_: it's not a case it is in universe
<fabbione> + it's a bk snapshot and not a full 2.6.11
<pitti_> fabbione: I know, I just thought you were interested in hearing reports
<fabbione> pitti_: just open a bug in bugzilla for now
<pitti_> fabbione: it crashes always at exactly the same time (already under Gnome), I still suspect inotify
<fabbione> try to boot with noinotify
<pitti_> fabbione: I'll open a bug if I have something to write into
<fabbione> and see if it still crashes
<pitti_> okay, I'll do that at next boot
<fabbione> ok
<fabbione> lamont: -18 uploaded. I had to revert the security fix and the inotify update
<pitti_> lamont: why the security fix?
<fabbione> pitti_: the sign patch changes the kernel ABI
<fabbione> and it needs to be handled properly
<pitti_> ah, ok
<fabbione> -18 is a temporary kernel while the team will take care of getting it right in -19
<fabbione> since it takes a while to sync everything
<pitti_> elmo: htdig sync, please
<ajmitch> latest daily install cd won't install base, missing memtest86+, what's the bugzilla product to report against?
<pitti_> lamont: still here?
<pitti_> elmo: ping
<mantiena> Kamion, maybe you could help me to test my d-i component, which replaces base-installer ? I have troubles with runing d-i in chroot :(
<smurfix> fabbione: A good test WRT "same kernel interface" is to check if the generated Module.symvers file is identical (or rather "sort +1 Module.symvers | cut -f 1-2")
<smurfix> fabbione: Just installing a module or two risks missing something
<daniels> Kamion: have another bug :) if you enter the root password wrong (expert mode), you only get prompted to re-enter it
<daniels> i.e. only the second question gets asked, so you have to reproduce the typo you made the first time
<Treenaks> nice one
<_mvo_> ping haggai 
<pitti_> elmo: mnogosearch sync, please
<Kamion> daniels: for a mini.iso, it's way easier to just build it yourself!
<daniels> Kamion: yeah, didn't know it came from d-i ... such is life
<daniels> i assumed it was part of the d-c build process
<Kamion> daniels: get the debian-installer source, cd build, set up sources.list.udeb.local with stuff like 'deb http://archive.ubuntu.com/ubuntu hoary main/debian-installer', 'fakeroot make rebuild_netboot'
<daniels> which we all know makes an ass out of u and some dude called med
<daniels> Kamion: phat
<Kamion> mantiena: could you put the source package somewhere and I'll have a look when I get a chance? now is not an excellent time but if you give me the URL then I can have a look later
<haggai> _mvo_: pong
<Keybuk> pitti_: [feature request]  pumount /media/*
<mantiena> Kamion, it would be better if you tell me how get d-i menu working in chroot. I analyzed Makefile's demo target as you told and started d-i with command: sudo chroot $TREE bin/sh -c "export DEBCONF_DEBUG=5 ; /usr/bin/debconf-loadtemplate debian /var/lib/dpkg/info/*.templates; exec /usr/share/debconf/frontend /usr/bin/main-menu"
<Keybuk> (ie. don't bitch that /media/sda1 isn't under /dev)
<Kamion> mantiena: well, that would be what I'd try first, and then debug it into existence from there
<mantiena> Kamion, before this I mounted proc and dev: sudo /bin/mount -t devfs dev $(TREE)/dev
<mantiena> sudo /bin/mount -t proc proc $(TREE)/proc
<Kamion> don't use devfs
<Kamion> mount --bind /dev $(TREE)/dev
<Kamion> $TREE/dev in fact, given that you aren't in make
<mantiena> Kamion, yes, I'm starting from simple shell script
<mantiena> Kamion, I grabed  "sudo /bin/mount -t devfs dev $(TREE)/dev" from Makefile ;)
<mantiena> demo target
<pitti_> Keybuk: pumount /media/* shall unmount all devices?
<Kamion> mantiena: yeah, it's probably wrong, the switch to udev is an Ubuntu change and I won't guarantee that everything has been updated
<Keybuk> pitti_: no, just pumount /media/sda1 shall unmount that
<Keybuk> (at the moment it complains that /media/sda1 isn't under /dev)
<pitti_> Keybuk: hmm, this should actually work
<pitti_> Keybuk: can you please check what it does with pumount -d /media/sda1?
<mantiena> Kamion, thanks, I'm trying now without devfs
<Keybuk> ubuntu mango-sorbet# pumount -d /media/cdrom0
<Keybuk> resolved /media/cdrom0 to device /media/cdrom0
<Keybuk> Error: invalid device /media/cdrom0 (must be in /dev/)
<pitti_> Keybuk: just to be sure, you are using latest Hoary version?
<Keybuk> pitti_: yeah, give or take a day or two
<pitti_> Keybuk: hmm, this works for me for USB devices
<Kamion> mantiena: you haven't told me what went wrong with your approach though
<pitti_> $ pumount -d /media/Pitti\ Drive/
<pitti_> resolved mount point /media/Pitti Drive/ to device /dev/sda1
<pitti_> resolved /dev/sda1 to device /dev/sda1
<pitti_> policy check passed
<pitti_> Executing command: /bin/umount /dev/sda1
<pitti_> Keybuk: I'll take a look at it
<Keybuk> weird
<Keybuk> it works with the usb device
<Keybuk> maybe I'm being dumb
<pitti_> Keybuk: no, I think it may be a bug if the device is in fstab
<pitti_> Keybuk: I get the same for cd-rom
<Keybuk> ah, yes, cdrom is in fstab
<mantiena> Kamion, without devfs is same problem than before - I get only blue screen and process "/usr/share/debconf/frontend /usr/bin/main-menu" uses ~90% of my CPU :(
<Kamion> I'll have to investigate that later then
<mantiena> Kamion, after few minutes this process eats almost all my memory: 946m  VIRT and 625m RES :(
<Kamion> you know how to use strace and gdb, right? :)
<Kamion> 'cos that's where I'd start ...
* Kamion expects developers to be competent debuggers too
<mantiena> Kamion, ok, I try to do this, but notice, this is not because of my component, I just trying to start standard d-i from ubuntu
<Kamion> yes I'm aware of that
<mantiena> Kamion, I build d-i with make demo_hd-media
<Kamion> I've never tried to run the demo target in Ubuntu though :)
<mantiena> Kamion, how you are building and debuging d-i ?
<Kamion> demo, in itself, is not all that useful for installer development
<Kamion> I build either netboot images or CD-ROM images and boot into those
<mantiena> Kamion, you are rebooting every time when you need test ?
<low> howdy !
<low> Kamion: around ?
<Kamion> mantiena: depends on what I'm doing
<Kamion> mantiena: but, for the installer itself (as distinct from your live CD installer), there are many things that you cannot usefully do while just chrooted
<Kamion> low: yes
<low> Kamion: i've tried daily/current amd64 iso from this morning. two problems appeared: 1st, network card isn't recongnized anymore (forcedeth), 2nd, when coming to raid config, it says the kernel doesn't support MD devices
<Kamion> I was only working on i386; I'll try amd64 later
<Kamion> the forcedeth thing surprises me but is really a job for the kernel guys to analyse
<low> that was ok when running array4 test iso
<low> Kamion: i suppose your fixes about md configuration are applied to x86/x86_64/ppc/etc ?
<Kamion> they were not architecture-specific in the least, as far as I know
<Kamion> anyway, I have to go and apply for a notice of marriage
<low> Kamion: ok, who do i have to talk with about kernel problems ?
<daniels> Kamion: poor soul (i mean, good luck!)
<Kamion> low: currently, lamont's probably the best candidate
<low> ok thx Kamion !
<Kamion> low: for the MD problem, have a look to see (a) does /proc/mdstat exist? (b) are modules md, raid0, raid1, raid5 available/loaded? (they should have been loaded automatically)
<low> checking...
<low> hmmm nothing, trying to load modules by hand...
<low> modprobe all these, keeps complaining: "invalid module format"
<low> checking iso md5
<ajmitch> low: just burnt it, I get the same thing
<Kamion> invalid module format? odd
<ajmitch> it won't load networking modules nor lvm
<Kamion> anything interesting on tty4?
<low> Kamion: anyway md5 isn't correct
<ajmitch> nothing interesting as such, just modprobe complains
<low> Kamion: checking (box is in another room, brb)
<Kamion> low: that might explain some of it; I'm surprised that it booted that far though
<ajmitch> checking md5sums here
<low> Kamion: nothing special in tty4
<ajmitch> md5 checks out ok
* ajmitch throws cd on the coaster pile :)
<low> 0983640d59a6f44653a247c80120d807 then ?
<Kamion> apparently linux-source-2.6.10 2.6.10-17 broke the module ABI
<Kamion> that might be part of it
<Kamion> -18 fixes it
<low> hmmm 2.6.10-3 here !?
<ajmitch> Kamion: alright, yesterday's image seems to have missed memtest86+ installation, which broke it
<daniels> lamont: if you want to just abi-bump l-r-m when you do -19, i'd love you forever
<low> gah i'm in the bad dir
<Kamion> low: that's the module ABI version, not the kernel package version.
<daniels> lamont: (and also do the CONFIG_DRM thing we discussed in l-s)
<Kamion> ajmitch: "missed"?
<daniels> things that are shit include: discover1
<low> Kamion: ok, md5 is good here
<ajmitch> Kamion: not sure, but apt complained about ubuntu-base's missing dependency
<Kamion> ajmitch: what arch?
<ajmitch> i386
<Kamion> will investigate later
<Kamion> must go
<ajmitch> ok
<low> see ya Kamion 
<daniels> Kamion: miastill around, perchance?
<daniels> Kamion: if so, how does one pick up on a switch passed on the command line?  e.g. debian-installer/multiseat=true
<Mithrandir> it's in /proc/cmdline
<Kamion> daniels: debconf question, db_get
<Kamion> don't use debian-installer/* please though
<Kamion> multiseat-udeb/somethingorother
<ajmitch> memtest86+ looks to be on the cd, retrying install..
<dholbach> re
<Kamion> env2debconf maps */*=* into debconf questions
<daniels> Kamion: ah cool, thakns dude
<thom> oh dear god kill me now
<thom> #6577
<ogra> thom: poor guy....
<ogra> thom: solve it by a disk monitor that pops up a warning ;)
<smurfix> thom: Debian #275726
<smurfix> thom: tagged fixed-upstream
<seb128> thom: http://lists.alioth.debian.org/pipermail/pkg-mozilla-maintainers/2005-January/000006.html
* thom steals the patch
<seb128> thom: wait before doing an upload, I've perhaps an another bug for you (#5992)
<thom> gee, thanks
<seb128> thom: and about the jumping cursor ? let me know if you need any help on this, I would like to get it fixed to enjoy replying in bugzilla again :p
<daniels> thom: psst, if you want to get him back, he can have anything on my bug list
<thom> seb128: i might turn pango off to see if that fixes the problem
<seb128> thom: I'm going to run a firefox build to try something for #5992, do you want me to turn it in the same build ?
<seb128> daniels: any news on the xkb issues ?
<thom> seb128: please do
<seb128> k
<ajmitch> Kamion: ok, forget that semi-bug about ubuntu-base dependencies - tried again with same settings, same cd, and it's all installed, somehow
<daniels> what's the best way to count numbers of lines in shell?
<daniels> assuming that busybox's wc seems to be crap enough to print all the spaces before the number
<daniels> ${#FOO} only counts numbers of characters
<daniels> seb128: none ta all, sorry, been way too busy with other stuff
<jdub> POO=0 while read foo; do POO=$(($POO+1)); done < file
<jdub> ?
* daniels vomits.
<seb128> daniels: k, np
<jdub> hey, if your wc is screwed, anything's game :)
<daniels> jdub: it's not my wc, it's busybox's
<AndyFitz> okay, which guy broke my gnome    ;-)
<daniels> seb128
<mantiena> Kamion, hehe, I got working d-i in chroot - simply unpackged and mounted initrd.gz from CD ;)
* AndyFitz wonder if package maintainers can hear users applaud or cry all over the world
<seb128> AndyFitz: we don't even know what you are talking about
<AndyFitz> since upgrading to the new ubuntu-base and restarting i havent been able to log into gnome. i have no idea how that works since i thought ubuntu-base was an empty package with lots of depends
<AndyFitz> this really belongs in #ubuntu
<Md> is a version of ongoing-merge for hoary available?
<daniels> Md: as in, the actual merge tool?
<Md> daniels: no, the .diff files from the debian version to the ubuntu/hoary version
<daniels> http://people.ubuntu.com/~scott/ongoing-merge/ has interdiffs, i believe
<Md> or is 0.0.20040329-15ubuntu3 really the latest hotplug version in ubuntu?
<Md> daniels: I know, but they look old. the hotplug diff there has been generated in november
<Keybuk> 16ubuntu11 is current
<Keybuk> the ongoing merge tool only takes diffs at merge-point
<Keybuk> (so 16ubuntu1 through 16ubuntu11 aren't represented there)
<Md> so I need to generate it manually?
<Keybuk> currently, yes
<seb128> thom: #5992 reassigned, crappy patch in fact
<thom> seb128: ok, thanks
<thom> did killing pango fix your problems, or didn't you try?
<seb128> nop
<daniels> oh my god, posix shell is broken to shit
<daniels> FOO="   I run the risk of letting this entry run rather melancholic, so I'll leave you with a picture of my titties.
<daniels>      er
<jdub> ha ha ha ha
<daniels> imagine that I just pasted some random crap from LiveJournal instead of hitting the space bar :)
<seb128> thom: I still get the jumping cursor without the pango option to the configure
<jdub> yay for daniels livejournal girlfriend!
<thom> seb128: no to which
<daniels> so let's try that one again
<daniels> jdub: not my girlfriend, dude
<jdub> the boobies are attached to a he?
<daniels> FOO="        x"; if [ "${FOO## }" = "x" ] 
<daniels> this will return false
<daniels> FOO="        x"; if [ ${FOO## } = "x" ] 
<daniels> this will return true
<smurfix> daniels: Ouch
<daniels> in the first case, the ## isn't actually doing anything, it's still       x
<mjg59> Yay for shell
<smurfix> daniels: In the second case, the ## still isn't doing anything I suspect
* daniels puts something else into his cut buffer
<daniels> smurfix: well, "${FOO## }" == $FOO
<seb128> thom: hum, removing the configure option is enough ? or should I turn it to the opposite ? it's still linked with pango
<daniels> smurfix: the substitution happens without the "" though; don't know what shell it is (posh?), it's whatever one is in the installer
<thom> seb128: i think it defaults true, so you'll need to reverse it
<smurfix> daniels: aren't the spaces swallowed by the standard whitespace skippage?
<seb128> thom: right, I've screwed so :p
* Md still can't see the point of bothering with posh
<thom> seb128: d'oh
<thom> you do use ccache, right?
<daniels> smurfix: all I know is that my postinst was broken for that very reason ("      4" != "4") until I fixed it
<daniels> smurfix: and the trace was showing it comparing "      4" vs "4"
<daniels> in "${FOO## }" = "4", where $FOO="      4"
<smurfix> daniels: exactly. Without the quotes, shell word expansion ditches the whitespace.
<smurfix> daniels: bash doesn't understand ##<whitespace> either
<daniels> smurfix: oh, hm. 
<daniels> smurfix: weird
<seb128> thom: nop
<smurfix> daniels: anyway, that's not a bug. The thing after ## is suppose to be a (pathname-style) pattern.
<elmo> smurfix: dpkg-checkbuilddeps: Unmet build dependencies: python-dev (>= 2.4dfsg-1)
<elmo> smurfix: python-dev | 2.4-0ubuntu6 |         hoary | all
<smurfix> elmo: I noticed -- will upload -2 later today
<daniels> smurfix: ok, thanks for the heads-up
<smurfix> elmo: after I replaced the hard disk in my laptop :-/
<smurfix> daniels: If you use exactly as many spaces as there are in $FOO, it works.
<daniels> smurfix: bleh.  isn't ## supposed to be a greedy match, though?
<elmo> drwxr-xr-x root/root         0 2005-02-15 11:58:43 ./usr/share/dotnet/mono/gac/evolution-sharp/1.0.0.0__457eed85bd9370df/
<elmo> ... nice.
<daniels> smurfix: i.e. if you have xxxxxy, shouldn't ${FOO#x} give you xxxxy, and ${FOO##x} give you y?
<smurfix> daniels: it's shortest/longest matching pattern, not matching repetition of that pattern.
<daniels> smurfix: blegh
<smurfix> daniels: Unfortunateky it's also shell filename pattern, not regexp, so ... :-(
<thom> seb128: oops
<Md> who should be credited for the beautiful hotplug.init shell hack? mdz?
<mantiena> Md, not I ;)
<dholbach> jdub: still there?
<jdub> yo
<jdub> briefly
<jdub> must sleep
<jdub> or at least, i must attempt to portray sleep
<dholbach> jdub: you read mary gardiner's mail concerning offlineimap breakage?
<jdub> nup, where abouts?
<dholbach> jdub: ubuntu-users - the MOTU team (including me) wants to get 2347346 of python universe packages sorted out and i wanted to reply to get some enthusiasts about it together on #ubuntu-love day
<jdub> ah, rocking
<dholbach> jdub: since i dont know about your exact plans, i wanted to ask you before replying
<jdub> good call
<jdub> please do
<jdub> i'm going to put up a page about it and activities tomorrow
<dholbach> cool
<jdub> please Cc me on that one :)
<dholbach> jdub: and thanks for the congratulations ;-)
* jdub has not been reading u-u recently :|
<jdub> dholbach: :-)
* jdub goes to bed
<bob2> dholbach: it's fixed in sid
<bob2> I meant to bug you about that
<pitti> night jdub 
<dholbach> bob2: oh cool
<dholbach> jdub: sleep tight
<dholbach> elmo: could you please sync offlineimap from sync then?
<bob2> we're past upstream freeze
<bob2> get permission from jeff and matt
<dholbach> bob2: it's in universe
<jk> hrmpzgrmbl #^&$%&# php &#*$^*&%^
* infinity looks askance at jk.
<bob2> it didn't move to supported, again?
<dholbach> apt-cache show offlineimap   told me
<bob2> I know how to find it out
<dholbach> bob2: sorry... i just wanted to state, i didn't know of any plans about re-supporting it and just consulted apt-cache
<mjg59> jbailey: Any progress with setting RESUME by default?
<jbailey> mjg59: None.  On my todo list today to talk to you about.  I'm not sure of the logic to figure it out, or where it should go.  Should I just drop the only swap partition into the config file when I'm installing for the first time?
<jbailey> initrd-tools isn't essential, so I could debconf it in the event that I've got multiple choice or just pick the biggest one.
<mjg59> If there's only one swap partition, use it. If there are two, use the biggest.
<mjg59> If they're equal, just use the first
<zul> hey
<zul> fabbione: ping
<sivang> Hi everybody!
<Treenaks> hey sivang 
<dholbach> hi sivan!
<sivang> hey Treenaks , dholbach 
<lamont> zul: morning - about 2 minutes before I need to run out the door
<lamont> fwiw, I think we want to let -18 stand today, and plan on uploading -19 after array 4 is out the door tomorrow.
<lamont> (since -17 broke all the isos...)
<zul> lamont, k
<low> lamont: great. i'll test it tomorrow
* lamont is out today
<lamont> wife comes home this afternoon, gotta make the house ready for her so that I can sleep in my bed tonight... :)
<zul> awww isnt that sweet :)
<lamont> low: I expect that Kamion will burn a new CD collection with -18 on them...
<tritium> nvidia is broken with -18
<lamont> tritium: broken how?
<Kamion> lamont: that's the plan, yeah
<lamont> all?? kernel modules are broken with -17....
<tritium> lamont, couldn't load the module.  Had to boot into 2.6.10-2.  Similar to what happend around 2.6.10-7 and -8 or so
<lamont> tritium: right. you have -17, not -18
<tritium> lamont, no, I got -18 this morning
<zul> wtf?
<Kamion> tritium: did you reboot into -18?
<lamont> that would be annoying
<dholbach> bbl
<Kamion> tritium: or are you running a -17 kernel and trying to load -18 modules?
<Kamion> lamont: just waiting for ia64 to finish building -18 ...
<lamont> Kamion: lets hope that is the issue...
<lamont> Kamion: linux-source-2.6.10_2.6.10-18_20050215-0838 07:33:26 (4 entries, sigma 00:02:29)
<lamont> start without it
<tritium> Kamion, let me reboot to double-check
<lamont> Kamion: unless you really have 2 hours to kill.
<tritium> before I say any more
<Kamion> lamont: ok
<lamont> Kamion: and then if you want to build a new set of ia64-only CD's somewhere around 1630 your time, it might be ready for you
<Kamion> I'll just hold my debian-installer upload until ia64 makes it, I think
* daniels waves at Kamion.
<daniels> Kamion: thanks a lot for your help :)
<ogra> hmm, pmount locks my terminal :(
* lamont heads out the door
<tritium> Kamion, I'm a moron this morning
* sladen ponders answering the bootsplash thread and hmmms.
<sivang> daniels: do you know if we have il archives already? the hoary build I installed with has "il.archive.u.c" 
<sivang> hey tritium 
<tritium> sivang, hello
<sivang> tritium: how are you ?
<daniels> sivang: i don't know, sorry, but iirc there's a *.a.u.c wildcard pointing to the master server
<tritium> sivang, fine, thanks.  How are you?
<sivang> daniels: ah cool, thanks :)
<sivang> tritium: fine, copying last settings from my old hd to a new sata :)
<Kamion> daniels: np
<tritium> sivang, new hardware - cool!
<sivang> tritium: yeah, it's always a refreshing feeling.
<mantiena> Kamion, it seems I found one error in cdrom-retriever :)
<Kamion> mantiena: oh?
<mantiena> Kamion, line 47 of cdrom-retriever is "        if db_get mirror/suite; then"
<mantiena> it should also check if return value isn't empty
<mantiena> maybe check for empty $RET should be in line 48  ?
<Kamion> mm, perhaps; although an environment that doesn't set mirror/suite before calling cdrom-retriever is itself buggy
<mantiena> Kamion, in any case, I think it's not hard to make chech for empy ;)
<eruin> debian sid bugs are automatically imported to ubuntu, right?
<Kamion> (note that cdrom-detect sets mirror/suite
<Kamion> )
<Kamion> eruin: only release-critical ones
<Treenaks> and only on main
<mantiena> Kamion, not always, when I copied CD to hard disk it doesn't set ;) I think if $RET is empty then we should do suite=stable :)
<eruin> Kamion: so should I bugzilla this ( http://lists.debian.org/debian-apache/2005/02/msg00090.html ) for ubuntu or track the debian bug?
<Kamion> mantiena: *you* should set mirror/suite in that case
<Kamion> mantiena: no, I want to get rid of the 'stable' symlink in dists
<thom> eruin: no, it'll be fixed in about 10 minutes
<eruin> thom: heheh, thanks
<Kamion> mantiena: mirror/suite should always be set; it's a bug not to :)
<Kamion> mantiena: (I'm fixing cdrom-retriever upstream now anyway, though, thanks)
<mantiena> Kamion, it seems you always take the best decision ;)
<Kamion> maybe I should just zap the stable symlink now to "encourage" fixing code ... nah, maybe not
<mantiena> Kamion, btw, what you call "upstream" ? ubuntu or debian-installer SVN ?
<Kamion> Ubuntu is clearly not upstream
<Kamion> debian-installer svn
<Kamion> code flows downstream from original authors to distributors
<mantiena> Kamion, ok, nice to hear ;)
<Kamion> eruin: in general if you want a bug in Ubuntu then either (a) ask mdz, who operates debzilla, or (b) file a bug and set the debNNNNNN alias on it where NNNNNN is the Debian bug number, wait, and shortly afterwards the bug history will be imported for you
<mantiena> Kamion, I can run d-i in chroot only when I choose English language in language-choose, if I choose Lithuanian then frontend eats all me memory :)
<Kamion> interesting
<mantiena> yea, but if I run d-i in real environment, not in chroot then Lithuanian language works fine ;)
<infinity> eruin : thom is rolling new apache2 packages to fix that based on Debian's -4 packages which fixed it.
<infinity> eruin : Oh, and I missed where thom already told you that.  Nevermind.
<eruin> infinity:)
<svenl> hi.
<sivang> hey svenl 
<svenl> hi sivang 
<sivang> svenl: it's been some time since we last talked ;-)
<svenl> sivang: remember me who you are ?
<sivang> svenl: just one user of your nvidia howto on debian, remember the issue with the nvidia installer and debian ones not agreeing on stuff ? 
<svenl> sivang: ah ...
<svenl> zul, lamont: ping ...
<daniels> Kamion: is having my udeb install stuff into prebaseconfig.d a Bad Thing?
<Kamion> daniels: not necessarily, just take account of what else is there and what order you need to be at
<daniels> Kamion: rad, thanks
<svenl> Kamion: hi.
<Kamion> hello
<Kamion> daniels: (in particular, you can't call apt-install after 10; it's usually better to call apt-install much much earlier, if you need to)
<svenl> Kamion: i tried a daily-hoary-netboot install, and there seems to be some kernel/module troubles,
<Kamion> svenl: yeah, known, being fixed now ...
<daniels> Kamion: ah, hmm ... not much I can do there since the udeb's at 30 by design
<Kamion> the kernel ABI broke
<svenl> modprobe telling me invalid module format and such,
<svenl> Kamion: guessed so.
<Kamion> daniels: that's xb-installer-menu-item, not prebaseconfig order
<Kamion> svenl: there's already been a kernel upload to fix it, it just has to propagate everywhere
<svenl> Kamion: daily isos will work though ?
<svenl> Ah.
<Kamion> svenl: yesterday's daily ISO should work, today's is broken
<daniels> Kamion: oh, right -- I assumed you meant 'earlier than prebaseconfig' for 'much much earlier', but come to think of it, that doesn't actually make any sense
<Kamion> I'm building fixed ISOs now
<svenl> Kamion: oh well.
<svenl> Kamion: what about netboot ?
<Kamion> daniels: if you need to install extra packages into /target, you can call apt-install anywhere from startup to prebaseconfig.d/10
<sivang> Kamion: the one before also installed without any fuss, excluding the vauge question about the place where to put the boot loader ;-)
<Kamion> svenl: installer-*/ is fine, dunno status of daily-installer-*
<Kamion> sivang: I'd prefer bug reports about things you think are vague, instead of vague reports on IRC :-)
<low> Kamion: which arch are you fixing ?
<svenl> Kamion: remember me the path to installer-*
<Kamion> low: all except ia64 (kernel package not built yet on ia64)
<Kamion> svenl: http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-powerpc/ etc.
<low> Kamion: great :) available tomorrow i suppose ?
<Kamion> svenl: although, since there was a period when the kernels in the archive were broken, you might well just try whatever image you used before once again
<Kamion> low: building *now*, they don't take a day :)
<sivang> Kamion: ofcourse :-) just trying to finish setting up my system (something which is being delayed since last night) and then I will do some buracracy ;-))
<low> Kamion: sweet :) please tell me when it's ok so i can dl and try !
<svenl> Kamion: mmm, http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-powerpc//powerpc/netboot should be ok ?
<Kamion> ETA half an hour or so
<Kamion> svenl: http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-powerpc/current/images/powerpc/netboot/
<svenl> Kamion: i mean, they will be compatible with the module .udebs in the archive ?
<daniels> Kamion: mmm, I need to throw in a couple of files to /target also
<Kamion> svenl: should be
<daniels> Kamion: so pbc might be easier
<Kamion> daniels: that's fine before prebaseconfig.d/95umount
<daniels> Kamion: right
<Kamion> daniels: many udebs have both a main portion that runs early on, and a prebaseconfig script
<Kamion> daniels: there's nothing at all to prevent you doing both
<mantiena> Kamion, debian-installer in sarge sets utf8 locales for all by default like ubutu hoary or not ?
<zul> ,48,2)
<zul> dang
<smurfix> Kamion: I need to generate the keymapping file from tmp/*/tree/usr/share/console/lists/console-keymaps-*. Where's the best place to put a rule for that?
<smurfix> Kamion: s:tmp/*:tmp/whatever, of course
<daniels> Kamion: yah, 'swhat I'm doing :)
<daniels> Kamion: shotgun pbc.d/09
<dholbach> re
<Kamion> mantiena: no, d-i in sarge does not do that, it's an Ubuntu change to localechooser
<svenl> zul: hi.
<Kamion> smurfix: build-depend on console-data and pick it out of that?
<svenl> zul: i hear that you are on the ubuntu kernel team, and that you need a powerpc maintainer or something ? 
<mantiena> Kamion, are there any plans to make UTF8 locales in sarge as default ?
<svenl> mantiena: definitively not.
<zul> svenl, we already have t-bone working on powerpc but he might like some help
<mantiena> svenl, :(
<svenl> zul: ah, ok.
<Kamion> mantiena: sarge is FROZEN
<svenl> zul: well, i will ask him. as said i do the powerpc kernels for debian, so ...
<Treenaks> Kamion: and has been for about a year now, afaik
<Kamion> Treenaks: base has been frozen for about six months.
<Treenaks> Kamion: one of the reasons I switched to ubuntu
<Kamion> Treenaks: but the installer was not frozen at that point; since rc2, though, there have been few substantive changes
<smurfix> Kamion: I need to process exactly those keymaps available at install time into one file. for i386 that would be the i386 and mac subdirectories, each of whom has their own udeb
<Kamion> smurfix: can't you generate it at run-time then? that would be much safer
<smurfix> Kamion: generation is rather time-consuming, needs Python unless I spend two weeks rewriting the thing in C
<Kamion> ugh
<thom> yes! someone found me the bug in upstream for the RtL crasher in mozilla
<Kamion> smurfix: you need to copy kbd-chooser's lists of which udebs are used, then
<sivang> thom: wooo, what's the bug who found it?
<Kamion> smurfix: BTW you know cdebconf failed to build?
<smurfix> Kamion: umm, no. Where's the log? I'll look at it
<mantiena> Kamion, thanks for onfo
<thom> except it doesn't ahve a patch or any useful data
<thom> bugger
<fabbione> zul: pong
<svenl> hi fabbione 
<fabbione> hi svenl
<Kamion> oh god, you did awful things involving autoconf!
<fabbione> damn you found me!
<Kamion> don't do that!
<svenl> fabbione: you still around ? Should you not be busy with otherstuff right now ? 
<Kamion> smurfix: http://people.ubuntu.com/~lamont/buildLogs/c/cdebconf/0.74ubuntu5/cdebconf_0.74ubuntu5_20050214-2059-i386-failed
<fabbione> now i can't talk bad about you anymore :P
<zul> fabbione, unpong
<fabbione> zul: ok
<Kamion> smurfix: please please generate configure statically at build-time rather than depending on random versions of autoconf on the buildds
<fabbione> svenl: i will be around until thursday -> then honeymoon
<tseng> d3vic3: if you didnt catch it your last mono update ftbfs
<tseng> d3vic3: muine rather.
<Kamion> smurfix: I'll fix it up
<svenl> fabbione: hehe.
<smurfix> Kamion: OK. Sorry about that.
<d3vic3> tseng, what ? 
<svenl> fabbione: i was wondering if the powerpc ubuntu kernel could also add the mkvmlinuz magic to the packages ? 
<d3vic3> what is ftbfs ?
<Kamion> smurfix: oh, we should work out a cdebconf custom widget API based on your detect_keys thing; ultimately I'd like it to be the first example of a custom widgets
<tseng> d3vic3: fails to build from source
<svenl> fabbione: i can provide a patch for it if needed.
<Kamion> widget
<tseng> d3vic3: http://people.ubuntulinux.org/~lamont/buildLogs/m/muine/0.6.3-5ubuntu1/muine_0.6.3-5ubuntu1_20050214-1507-i386-failed
<daniels> hmmm
<daniels> lamont: when are you planning the next kernel upload?
<Kamion> smurfix: (and sorry, I should be calmer :-))
<daniels> lamont: i have one more tweak for you :)
<fabbione> svenl: i am out of the kernel team until i am back from the honeymoon
<fabbione> svenl: but we are in feature freeze. so no new things go in now
<fabbione> svenl: new devel will start after hoary
<smurfix> Kamion: That makes sense. cdebconf should also report its availability when asked. Of course, if you have a not-implemented error code that actually gets returned to the caller, that tends to help too ;-)
<Kamion> smurfix: indeed :)
<fabbione> svenl: but you are welcome to discuss the patch in the meanwhile so it can get scheduled
<svenl> fabbione: oh well.
<svenl> fabbione: it is no kernel patch, just a couple of .o that gets copied to /lib/kernel/something.
<svenl> fabbione: absolutely no effect on the vmlinux so this argument doesn't stand :)
<fabbione> svenl: better.. just talk with the kernel team and let them decide :-) they need to strech their wings on the package :P
<zul> fabbione: yeah and not break it :)
<d3vic3> tseng, thanks,will look at it 
<tseng> d3vic3: thanks.
<fabbione> zul: before you or the team will upload -19 you need to bump the ABI
<Hwolf> daniels: is there any place on the web where one can get an idea where the linux desktop is going? xorg and freedesktop don't really provide a vision / roadmap
<fabbione> and coordinate all the bits required for it
<fabbione> zul: so please take 2/3 days before doing so
<svenl> fabbione: like said, i volunteer to be part of the kernel team for ppc.
<Kamion> definitely wait 'til after array cd 5 for that
<zul> fabbione: how?
<fabbione> svenl: welcome! add your name to the wiki and start the job :)
<fabbione> zul: how what?
<zul> fabbione: check the abi
<fabbione> svenl: it's easy :P
<fabbione> zul: smurfix has a very technical method
<fabbione> i use to check via modprobe/rmmod
<Kamion> smurfix: cdebconf changes look good otherwise though, hope to try them out soon (although I hope after array cd 5, too :))
<fabbione> zul: check the irclogs from this morning (my time)
<zul> k
<svenl> I guess i have to join and login first though.
<Kamion> smurfix: fix uploaded; will merge a couple of things upstream now
<smurfix> Kamion: Anyway, the idea seems to be to have console-tools prebuild the necessary keymap files. I guess I can do that; combo things like mac+i386 can be handled as a special case, there shouldn't be too many of those.
<Kamion> smurfix: yeah, that would work too, have the prebuilt bits shipped in the udeb?
<Kamion> udebs
<smurfix> Kamion: hmm, which udeb should the combined i386+usb keymap be in?
<Kamion> smurfix: oh, no way to have one per console-keymaps-* udeb?
<smurfix> Kamion: If I do that, I have to ask the architecture question beforehand
<Kamion> smurfix: ok, how about making the console-data source package spit out a new udeb with the appropriate prebuilt files for each architecture, looking at the keymaps as per kbd-chooser/Makefile?
<smurfix> Kamion: yeah, that would probably work best
<Kamion> then your keyboard selector udeb can depend on that new udeb
<Kamion> and we suck them both into the initrd at the same time
<svenl> mmm, fabbione any coordination mailing list for the kernel team
<svenl> ?
<fabbione> svenl: ubuntu-devel and add [kernel]  in the subject
<fabbione> if there will be enough traffic we will create our own ml
<smurfix> Kamion: I need to touch console-data anyway, some keymaps lack keys like "e"
<smurfix> Kamion: ... because it's there anyway
<smurfix> Kamion: ... unless you've been using Dvorak
<tseng> Treenaks: is xine-lib known broken elsewhere?
<Treenaks> tseng: I don't know...
<tseng> I see.
<Treenaks> tseng: I just spotted it because I wanted to install muine, and looked at the build log
<thom> seb128: i think your bug is https://bugzilla.mozilla.org/show_bug.cgi?id=207186
<thom> have fun ;-)
<tseng> we could opt to sync the debian package, which is using gstreamer
<tseng> or rush my 0.8.2 packages.
<svenl> fabbione: ok.
<Kamion> smurfix: heh, ok
<Kamion> low: new daily CD up
<low> Kamion: already dling it, ETA 8 minutes :)
<Treenaks> tseng: why rush them? are they broken?
<daniels> Hwolf: not really, sorry
<tseng> Treenaks: they arent in debian experimental even
<tseng> Treenaks: they work fine, however
<Treenaks> tseng: could I try them in ~ 2 hours (when I'm  home)
<tseng> yes
<Treenaks> tseng: ok
<Treenaks> tseng: how/where? :)
<tseng> http://getsweaaa.com/~tseng/muine/
<seb128> thom: that's bidi text ?
<Hwolf> daniels: is there anything on the horizon at all? Lots of fud about next-gen os's, but there is more about osx / lonhorn, nothing about tux
<thom> seb128: i'm pretty sure that having pango turned on means that it gets used that way all the time
<seb128> thom: do we have any improvement by turning pango on ?
<thom> turning pango off, you mean?
<thom> oh, ISWYM
<thom> yes, bidi text everywhere else seems to work better
<daniels> Hwolf: i dunno, i'm not a visionary, i just package stuff and work on x (mainly the build system, even, not anything hugely exciting)
<daniels> ask havoc or nat or someone ;)
<Treenaks> tseng: it needs new versions of all that -cil stuff?
<tseng> Treenaks: yes
<Treenaks> tseng: scary :)
<tseng> not really, it uses gtk 2.4 widgets
<Hwolf> daniels: visionary != goodlooking-desktop-lover :-P
<daniels> Hwolf: sure, but I don't know what it's going to be; like, I love Tomboy, right, but I wouldn't have been able to predict its existence :P my only prediction for the desktop is that Composite will get usable because we'll throw XAA away, and maybe people will actually use it, but it's a little offtopic for #u-d
<svenl> Mmm, ubuntu kernel has some troubles with the marvell gigabit ethernet controller driver.
<Hwolf> daniels: I'll take it to google. :)
<Treenaks> daniels: throw away XAA?
<Kamion> svenl: strange; that's what I have here and it works fine (though only in 10Mb/s mode I think)
<daniels> Treenaks: the current acceleration architecture, which is crap and the main thing making composite so goddamn slow
<Treenaks> daniels: ah, so it'll replaced by New Cool Acceleration, and we won't have unaccelerated X where the slowness of composite is no longer noticable because the rest is slow too :P
<Hwolf> Is there are target system for development? Gnome is already slow, imho. :-S
<daniels> lamont: see your mail -- these NEED to merged for -18, which would ideally happen ASAP
<svenl> Kamion: on the pegasos ? 
<tseng> Hwolf: this stuff is really off topic imo.
<svenl> Kamion: the mv643xx_eth driver it is.
<Kamion> svenl: no, the amd64 to my right
<Kamion> svenl: oh, different driver
<Treenaks> we need #coolnewstuff
<svenl> Kamion: it is a different driver, the amd64 stuff is just a marvell phy or something, while the pegasos gige port is builtin the northbridge.
<Kamion> yeah
<daniels> lamont: (we need the mouse stuff to do multiseat-udeb properly)
* sivang wonders who is Monika
<daniels> mmm, marvell phys definitely work fine
<ogra> sivang: mdz's GF afaik
* daniels looks at the netinst happening over a Marvell PHY right next to him.
<sivang> ogra: ah ok, I saw this https://www.ubuntulinux.org/wiki/MonikaWebsiteContent
<Kamion> daniels: -18's already happened
<daniels> Kamion: with the new ABI?
<ogra> sivang: yeah... nice new structure
<Kamion> daniels: no, fixing the ABI change inadvertently introduced in -17
<daniels> Kamion: oh, right
<daniels> lamont: -19, then
<fabbione> yeah but wait for -19
<zul> daniels: what changes if you dont mind me asking
<fabbione> since you have to change the ABI
<fabbione> you can pull in safely N changes
<fabbione> zul: all the package naming
<fabbione> 2.6.10-3 will be -4
<fabbione> and so on
<fabbione> so everything needs to be rebuilded
<Kamion> fabbione: we need this stuff before the ABI change, and separate from it
<fabbione> and the user MUST reboot to use the new kernel
<Kamion> mantiena: try 'export LANG=C.UTF-8' in that demo thing (say, just after exporting DEBCONF_DEBUG); works much better
<low> Kamion: same errors: invalid modules format, forcedeth, md, etc
* fabbione is lost
<zul> ah k
<fabbione> Kamion: what do you need asap?
<Kamion> low: gah, exact reverse problem; we got an initrd build with -17
<Kamion> fabbione: 15:23 < daniels> lamont: see your mail -- these NEED to merged for -18, which would ideally happen ASAP
<Kamion> fabbione: 15:24 < daniels> lamont: (we need the mouse stuff to do multiseat-udeb properly)
<fabbione> ah shit
<daniels> zul: CONFIG_DRM y -> m, adding mousedev and psmouse to input-modules*.udeb
<fabbione> ok
<zul> ok
<low> Kamion: :( just to be sure, that was the iso from http://cdimage.ubuntu.com/daily/20050215.2/
<fabbione> daniels: we can do it with -19 today
<low> how can i verify the build ?
<Kamion> low: yeah, I know, just checked
<fabbione> but elmo will kill us
<Kamion> low: don't need to, I've verified the problem
<low> ok.
<Kamion> low: I'm going to execute plan B now
<fabbione> lamont: are you around?
<low> Kamion: which is ?
<zul> i dont think he is fabbione 
<Kamion> low: building with an older initrd from the last time I uploaded debian-installer by hand
<mantiena> Kamion, ok, thanks again
<daniels> fabbione: mmm, if you could, that would be fantastic, thanks
<low> Kamion: ok. i'm still at work for, hmmm, 1 hour and a half. hope i'll have time to test tonight, or i'll try tomorrow
<svenl> Kamion: netboot installing now.
<Kamion> low: you might do, just about
<Kamion> mantiena: trying that with Greek, I've got the demo up as far as the partitioner
<svenl> Kamion: upto what point is it synced with d-i ? I guess i will have to hand-boot the thing with grub2, like i did with the installer.
<low> Kamion: you're great !
<Kamion> svenl: whenever upstream version freeze was, see HoaryReleaseSchedule
<mantiena> low, agree
<fabbione> daniels: no i am not going to do -19 now. i need to leave and i will be back for the meeting
<Kamion> plus bits and pieces
<svenl> Kamion: you have nobootloader too, right ? 
<fabbione> daniels: i will see later with lamont
<svenl> Oh well, i will see after the install.
<Kamion> nobootloader |       1.02 | hoary/main/debian-installer | all
<Kamion> (i.e. yes)
<tritium> trulux, looks good, but I think you should remove table of contents, list of figures, and list of tables
<svenl> cool.
<svenl> Kamion: i guess you don't have real time for pegasos support stuff, right ? 
<svenl> Kamion: i will be doing some OF hacking on thursday/friday, and intent to have yaboot and grub2 working once i am done with this.
<svenl> this mean that pegasos support probably needs either only the new OF, or also a yaboot upgrade.
<svenl> and probably some yaboot-installer work.
<Kamion> svenl: sadly not really, I have a million and one scheduled things to do before the next release still
<Kamion> I can do some little bits of integration help and merging and stuff but that's about it
<svenl> Kamion: well, i booted the initrd.gz and vmlinux with grub2, and am doing the install.
<svenl> Kamion: i can follow the rest of it, and fill bugs or patches or whatever if needed.
<mantiena> Kamion, it seems after fixing suite I can test my installer at least ;) only one problem - "Abort the installation" item from debian-installer menu doesn't work, so I can't exit :( :(
<daniels> fabbione: yeah, that's fine, thanks
* daniels -> zzzz
<daniels> night all
<mantiena> bye daniels 
<madduck> what does the D-BUS acronym stand for?
<svenl> Mmm, i am trying to register myself on the wiki, but when trying to log in, using my luther@debian.org address, it tells me the account already exists, and i see no way to send me the passwd or something.
<svenl> hi madduck 
<Kamion> mantiena: do not expect demo to work for you without *substantial* hacking. It's a demo. I didn't suggest it to you with the aim that you use it, I suggested it as an example of some of the things you have to do
<svenl> Mmm.
<Kamion> mantiena: also nobody's put any kind of significant work into the demo for months and months
<mantiena> Kamion, it seems here is the main problem ;)
<svenl> Kamion: neat, all worked.
<Kamion> mantiena: yeah, but it's not intended to be used for production
<svenl> Kamion: is there some post-reboot install needed too ? 
<Kamion> svenl: same as Debian
<Kamion> same kickoff procedure, anyway
<svenl> Kamion: ah.
<mantiena> Kamion, I try to make it more stable ;)
<Kamion> mantiena: please write something new instead
<Kamion> using those ideas
<mantiena> Kamion, instead what ?
<Kamion> instead of trying to abuse the demo for things that it was never intended to do
<svenl> Kamion: if i want a user without root access, it is best to create a second user without sudo access ? 
<Kamion> svenl: yes
<svenl> Kamion: mmm.
<svenl> Kamion: seems a bit convoluted as approach (is that even an english word ?)
<mantiena> Kamion, I'm not trying demo, I simply use unpacked and mounted initrd.gz from live CD :)
<Kamion> mantiena: ok
<Kamion> mantiena: but I think that that's still pretty inappropriate, you don't want to execute most of the early stuff there
<svenl> Damn, didn't copy the name of the kernel :/
<Kamion> I tried to tell you this the other day but I didn't seem to be getting through
<Kamion> that early code has already been run, and should not be run again
<mantiena> Kamion, I understand this
<mantiena> Kamion, I think I find the way how to prevent unneeded d-i modules from starting ;)
<mantiena> maybe udeb_exclude ?
<svenl> video/win 33
<Kamion> mantiena: the right way is to build an image that actually matches what you need, not to abuse some other image
<Kamion> mantiena: (then, for example, you could include di-utils-exit-installer rather than di-utils-reboot)
<mantiena> Kamion, my goal is to make simple d-i component which can work in liveCD text mode, so people could install live CD without starting X and gnome
<Kamion> yes, I know
<mantiena> Kamion, thanks
<Kamion> the debian-installer source package already spits out quite a few source packages. yours may have to behave rather differently though, since it's running in a chroot rather than being there from system startup
<Kamion> s/quite a few source packages/quite a few images/
<mantiena> Kamion, I think modifying udeb_include and udeb_exclude is pretty good way, I'm right ?
<Kamion> no
<Kamion> apart from anything else it will not help for anything that runs before anna
<Kamion> and it's really not particularly what you need
<Kamion> you should seed the cdebconf database in the chroot with the cdebconf database from the live CD startup phase, to start with
<Kamion> that will help a bit
<Kamion> but you may need to remove some things from that
<mantiena> Kamion, thanks again, I try to preseed cdebconf database, I saw some info how to preseed into d-i documentation
<Kamion> I wouldn't call it preseeding as such
<Kamion> the d-i documentation will probably not be helpful to you in this area, because it's focused on people doing automatic installs, which is very different and isn't what I was driving at
<Kamion> basically all you need to do is get a copy of the cdebconf database from when casper was running, and shove that into your chroot
<haggai> lamont: ping
<mantiena> Kamion, problem is, that cdebconf database, like all other data is erased after casper finishes and Ubuntu starts from livefilesystem
<Kamion> mantiena: casper could easily be made to copy it into the live system, in the same way that the installer copies it into the installed system
<Kamion> mantiena: in fact, casper *already* does so
<Kamion> look in /var/log/casper
<thom> Kamion: if you look at people.ubuntu.com/~thom/ does hoary-install-ia64.iso look the right size and stuff to you?
<Kamion> although it would probably also need to copy templates.dat
<mantiena> Kamion, all answers are in questions.dat.gz ?
<Kamion> thom: yeah, that looks about right, 100MB difference which is probably just down to 1000 vs. 1024
<thom> cool
<Kamion> mantiena: yes
<thom> now to see if this stays stable :-)
<mantiena> Kamion, you are very good helper ;)
<mantiena> Kamion, without your help my coding was four times slower
<mantiena> I'm very happy
<svenl> fabbione: what is the status of the marvell_pegasos patch in the ubuntu/hoary 2.6.10 kernel ? 
<madduck> what does the D-BUS acronym stand for?
<madduck> distributed? data? dorky?
* sivang notes that 3ddesk is just *awesome* , would love to see a verion that takes your currently opne windows and make a carousale out of them :)
<Kamion> low: ok, try this latest cd
<mjg59> sivang: Played with Looking Glass+
<mjg59> ?
<svenl> Oh well, how comes i have a vmlinux.coff installed in /boot ? 
<low> Kaloz: ok thx :)
<svenl> and it doesn't even include the initrd, no way this file will ever work.
<low> Kamion, even
<Astharot> ciao
<ogra> mjg59: did you already try it ?
<Kaloz> low: np, we like xchat :p
<Kaloz> ogra: hello. i was missing due to upgrading my workstation.. now i'm waiting for a new kernel to be able to use it, hehe :p
<elmo> can w3m be told to auto-reload a page every n-minutes?
<ogra> Kaloz: join us in #ubuntu-motu ;)
<Kaloz> okie :)
<mjg59> ogra: I've played with it at an expo
<svenl> Mmm. is there a way to create a base-only ubuntu install ? without X and all the stuff ? in expert mode maybe ?
<thom> Kamion: you should have cdimage DVD love now :-)
<sid77> ciao
<low> Kaloz: yep, still not used to new completion :S
<low> gah, Kamion , one more time :)
<Kamion> thom: awesome
<Kamion> thanks :)
<thom> np
<Kamion> svenl: that's "custom" in warty or "server" in hoary
<Kamion> no need for expert mode
<low> Kamion: well, i leave work, will tell you tomorrow mornin
<seb128> smurfix: here ?
<smurfix> seb128: yep
<seb128> smurfix: the confile bugs ... what's needed to fix it ?
<smurfix> seb128: I'm insufficiently experienced with dpkg to answer that question. :-/
<ogra> mjg59: ah, i thought you already tried it on ubuntu ;)
<seb128> smurfix: k
<svenl> Kamion: euh ?
<svenl> Kamion: where do i specify server ?
<mjg59> ogra: Hell no - it's in Java and scares me too much
<smurfix> seb128: offhand, I'd guess a Replaces: on the package which owned it previously
<ogra> mjg59:  hehe
<svenl> Kamion: oh, i guess it is some special yaboot target, will look at the yaboot.conf on the iso i just downloaded.
<Hwolf> daniels: You around?
<svenl> Kamion: indeed, nice it is just a preseed thingy.
* svenl wonders where i have to preseed it from on netboot :
<svenl> )
<Kamion> svenl: oh, yeah, need to fix that up
<Kamion> svenl: in the meantime, 'echo d-i base-config/package-selection string >> /var/log/debconf-seed' from tty2 at some point in the installation should do most of the job
<svenl> Kamion: i guess i can just grab the server.seed file and move it to a local http server and use it with preseed/url will work too ? 
<wasabi> see. =(
<wasabi> oops.
<Kamion> svenl: should work, yeah
<Hwolf> hm. After upgrading ubuntu-desktop/base, I've lost the system sounds.
<smurfix> Hwolf: You mean the login/logout ones?
<Hwolf> Yup
<svenl> Kamion: well, X is hosed on the pegasos, it seems
<Kamion> svenl: :(
<svenl> Ok, fixed.
<svenl> Seems like UseFBDev should not be used.
<mako_> sivang: around?
<svenl> I don't know what is going on with UseFBDev and RadeonFB, but it seems that the mode that the X server requests are not accepted by radeonfb, it has been so for a while.
<svenl> mako_: hi, i sent you mail, jbailey suggested i should do it like that, but am not convinced it is the right way.
<mako_> sivang: i'm contacted by an israeli computer shop that wants to distribute preinstalled computers
<mako_> svenl: about cds?
* Treenaks just received 200x Warty Goodness
<mako_> Treenaks: nice :)
<jbailey> svenl: What I told you was that it's how I did all of my installs but one. =)
<Treenaks> Just in time for tomorrow's ubuntu-nl meeting :)
<jbailey> svenl: It's not without pain, but it's less pain than I watched you go through this morning. =)
<svenl> mako_: about the code of conduct stuff, and maybe about how to access the wiki, since it seems luther@debian.org seems already registered, but i have no password for it.
<svenl> jbailey: well, i did a true d-i install, not the debootstrap way like you did.
<mako_> svenl: whoa? really?
<svenl> Only 3 issues ?
<svenl> 1) need grub2 to boot the stuff since yaboot won't do it from net or CD.
<mako_> svenl: let me chase this one down
<svenl> => could be solved by adding the mkvmlinuz magic at least for netboot.
<mako_> svenl: can you have it email you a new password?
<svenl> 2) meed to set MODULES=dep in /etc/mkinitrd/mkinitrd.conf, or the initrd is too big for grub2.
<svenl> 3) this X issue.
<svenl> mako_: i didn't find how to do it.
<svenl> BTW, does the wiki registration also allow to access the bugzilla ? 
<Kamion> no, bugzilla's separate as far as I know :-/
<haggai> what does 'dpkg-architecture -qDEB_HOST_ARCH' report on amd64?
<dholbach> haggai: amd64
<haggai> dholbach: thx
* haggai enables the OOo2 64 bit patchset
<svenl> oh well, DRI seems to not be enabled in hoary/radeon.
<pitti> fabbione: ping
<fabbione> pitti: fast pong.. i am on the way out
<svenl> ah, need to force pci mode.
<svenl> daniels: you there ? 
<bob2> it's 0430 here
<bob2> so, "probably not"
<svenl> daniels: X needs Option "BusType" "PCI" on pegasos and radeon.
<fabbione> svenl: send him the info that includes how to identify that it is a pegasos
<svenl> fabbione: oh well.
<Kamion> what's happened to the icons in the top panel that used to be there on a fresh installation?
<svenl> $ more /proc/cpuinfo
<svenl> machine         : CHRP Pegasos2
<svenl> obviously.
<Kamion> (and should whatever it is be fixed by array cd 5?)
<T-Bone> svenl: ping?
<svenl> T-Bone: pong.
<T-Bone> svenl: so you want to hack on ubuntu's kernel as well? :)
<svenl> I hear that you are part of the ubuntu kernel team, and doing powerpc, but the powerpc porter is listed as vacant on the wiki, and i was thinking of going for it.
<T-Bone> well tbh i din't take time to touch the wiki
<T-Bone> sure you can do it. Dunno how lamont and zul want to handle that, tho. Maybe you push patches up to me and i get them merged with lamont?
<T-Bone> svenl: have you looked at ubuntu's linux package? It's pretty different from the debian one...
<zul> T-Bone: hola
* dredg coughs... ip address: 10.50.65.67, netmask 255.255.240.0 does not give a broadcast address of 10.255.255.255
<dredg> well, it does, but it shouldn't :)
<T-Bone> hey zul!
<dredg> (unless this is still 1987 and we're waiting for classful addressing to go away)
<bob2> haha
<dredg> i assume that ifupdown is the package to file a bug against?
<svenl> T-Bone: i know about ubuntu's kernel packages.
<svenl> (sorry, am cooking at the same time, so ...)
<svenl> T-Bone: there are some stuff missing in them, like the mkvmlinuz support stuff.
<svenl> T-Bone: but basically they are single package, and have a different set of patches applied, no ? 
<T-Bone> svenl: i think that the idea is not to have mkvmlinuz, as it shouldn't be needed,
<T-Bone> and if you think about Pegasos, jbailey has a solution in progress ;)
<svenl> T-Bone: i know about the grub2 work, but what about netbooting, which is much nicer with the zImage.initrd stuff, and what about things like prep ? 
<T-Bone> svenl: it's a megapackage with all patches in it, including d-i stuff. The current scheme has a "team leader" (currently lamont, zul and me) doing main uploads, and a set of "porters" and "subsystem guys" doing patches and pushing them to us
<T-Bone> svenl: prep isn't supported (yet) afaik
<svenl> T-Bone: the reason why there is no mkvmlinuz support, is simply because the ppc port originated on pmacs which where able to use yaboot.
<Kamion> if we were to support prep we'd have to have reliable testing for it; can't release untested stuff
<T-Bone> svenl: as Kamion said
<svenl> T-Bone: i have a prep, support could as easy as making sure the kernel boots on it.
<svenl> Kamion: bah, whatever.
<svenl> Ok, back in a bit, the kitchen calls.
<Kamion> make that "making sure the release works on it from start to finish", no half-measures :)
<T-Bone> svenl: 'testing' means more than a single configuration
<T-Bone> Kamion: the latest ISO roll has -18 on them, right?
<svenl> Kamion: hoary+1 i think anyway.
<svenl> T-Bone: come on, what are you trying to tell me ?
<Kamion> T-Bone: for all arches except ia64, since ia64 hadn't quite built it yet; I have another set of ISOs building now to pick up the ia64 change
<T-Bone> ah ok cool
<T-Bone> i'll wait a bit then
<sivang> morning mdz 
<T-Bone> i'd like to make sure i've fixed the zx6000 issue, and then report to you for the elilo bug :)
<svenl> T-Bone: i have access to 4 different powerpc subarches here, not counting the quad power5 at augsburg, so i don't understand the problem really.
<mdz> morning
<T-Bone> svenl: Kamion explained it fairly well. If you can cope with that I have nothing to say
<T-Bone> svenl: I'm not omniscient, I can't *guess* what hardware you've got access to
<svenl> T-Bone: i am just saying that i volunteer to jump in as powerpc porter, not getting into details like that.
<T-Bone> svenl: what details?
<svenl> T-Bone: those you agressed mewith :)
<T-Bone> o_O
<svenl> no seriously, i perfectly know what is needed, and the stability standard i will be hold too, so ...
<T-Bone> svenl: i don't think i've "agressed" you in any way, and please excuse me if I did so. All I did was stating a few facts on how we work here, and what it takes to add a supported architecture. Merely important stuff imho, not details
<svenl> T-Bone: i know what jbailey has been doing with grub2.
<svenl> T-Bone: ah, you missed the smiley :)
<T-Bone> svenl: i know that you know, hence the 'smiley'
<svenl> T-Bone: prep was just an example, a detail. yaboot is clearly not the solution to all, and grub2 probably won't in the near future,
<T-Bone> svenl: that doesn't change a thing to how we work. We're not going to add stuff we don't need until we need it. For now, only macs are supported, and yaboot is a "just fine" solution for macs. Please don't reverse-solve problems
<svenl> T-Bone: so what ? did i say i would force it in or something ? the fact that i still think it is a good idea to have it in (and fully orthogonal to the yaboot stuff), has nothing to do with my ability to do the necessary job for ppc porting.
<T-Bone> i never said anything like that
<svenl> T-Bone: read your above sentence please and repeat me that.
<T-Bone> svenl: I never said anything related to your ability to do the necessary job for ppc porting. I merely told you how we work here, for I'm not assuming you already know how Ubuntu works compaired to Debian.
<T-Bone> Please don't make me say what I'm not :P
<T-Bone> I know that you are perfectly able to do a fine job, as you already do with Debian.
<svenl> T-Bone: well, i know how you work, i have been doing d-i work with Kamion since >1year, and interacted with other ubuntu guys about various issues, and also understand the comercial need for staibility, and short release cycle needs
<T-Bone> then it's all fine :)
<svenl> T-Bone: as you said.
<T-Bone> now if you'd excuse, i have to run out for a short while, be back in ~ half an hour
<T-Bone> +me
<svenl> T-Bone: except that your wiki thinks luther@debian.org  is already registered.
<T-Gone> i don't own a wiki
<T-Gone> ;P
* T-Gone runs for good
<sivang> does anybody know if we have a "you need to install this stuff" wiki page for people wanting to do pkg/code development on their system?
<mantiena> Kamion, still online ?
<tseng> sivang: DeveloperResources, i just added some more docs last night
<dholbach> tseng: oh cool, rocking!
<dholbach> tseng: just in time for valentine's erm ubuntu-love day :-)
<sivang> tseng: cool, I just thought to "port" some stuff from the NM guide to a page for us, but since you arealdy did it- cooool
<tseng> sivang: actually i just linked to it
<mako> can i get a german speaker to help me with some info mail?
<mako> info@ubuntu
<tseng> its still valid imo
<dholbach> mako: i can help you
<amu> todays-live, still doesnt boot, crash while booting with kernel panic 
<amu> mako: you are all times welcome 
<sivang> tseng: DeveloperResources seems to have no specific pkgs you need to install, am I missingn anything?
<mantiena> amu, really ?
<tseng> sivang: yes, read the NM
<tseng> sivang: and you shall be enlightened
<tseng> section 1.1
<tseng> build-essential plus anything else mentioned there
<sivang> tseng: I read it, but everytime I set up a new system (just moved to my new SATA) I need to reinstall the devel packages, would be good to have a short list with pkg names only to copy paste install :)
<tseng> build-essential !
<sivang> tseng: okok :)
<elmo> crimsun: ?
<elmo> dholbach: done (offlineimap)
<tseng> sivang: also.. when working on package foo you can apt-get build-dep foo
<dholbach> elmo: rocking
<amu> mantiena: yep
<sivang> tseng: eh, right, then it will grab each one's depends , cool enough - thanks.
<mantiena> amu, with Kamions help I got running installer from liveCD chroot and I'm testing liveCD installer now ;)
<amu> mantiena: rocks
<Kamion> mantiena: yes
* Kamion causes great steaming pain to udev
<Kamion> create my md device, damn you
* mantiena thinks, that udev sometimes is bad kid
<elmo> "steaming pain"? that's an interestingly mixed metaphor
<mantiena> Kamion, maybe you know why language packs aren't included in hoary live CD ?
<Treenaks> hm.. udev not creating Md devices? :P
<pitti> Treenaks: his last revenge :-)
<pitti> Treenaks: s/last/latest/
<Kamion> mantiena: they're not seeded yet
<pitti> mantiena: this topic is discussed in today's TB BTW
<svenl> hi amu ...
* bluefoxicy sneezes
<Kamion> T-Gone: ia64 iso up now
<amu> svenl: *waves*
<svenl> amu: did you ever get my emails about the pegasos offer last year ? 
<amu> svenl: sure and answered them :)  
<whiprush> aanyone seen mako?
<svenl> amu: mmm, never reached me though.
<mako> whiprush: he's around :)
<whiprush> bring more CDs, I've given away all mine. ;)
<mako> whiprush: are you in LWCE?
<whiprush> yeah
<whiprush> gnome booth
<whiprush> with havoc
<mako> whiprush: i'll get into town tonight
<mako> whiprush: i really don't have as many left as i thought
<mako> grr..
<mako> i'll order more for myself now and bring all i have.. i have enough
<sivang> whiprush: LWCE is a linux event?
<mako> sivang: linuxworld
<sivang> mako: oh. 
<sivang> mako: where is it held this time ?
<mako> sivang: boston
<mako> i'll leave immediately after the TB meeting today
<T-Bone> Kamion: roger that, rsync in progress
<fabbione> re
<fabbione> lamont: ping?
<T-Bone> hey fabbione!
<fabbione> hi T-Bone 
<T-Bone> how's the bride? :^)
<fabbione> sleeping
<T-Bone> lol
<fabbione> she just crashed in the bed
<fabbione> and i was close to
<T-Bone> hehe! Congrats anyway!
<fabbione> thanks :-)
<zul> heh...your freedom is gone now...its all down hill from here
<dholbach> ok... i'm off - have a nice evening everyone
<fabbione> zul, T-Bone: do you have daniels email about the required changes for the kernel?
<fabbione> i  know he was asking for a couple of things like DRM=m
<fabbione> and there were 2 other things
<seb128> elmo: hicolor-icon-theme sync please
<zul> fabbione: dont think so let me check
<elmo> seb128: done
<seb128> thanks
<T-Bone> fabbione: nah I don't have this one
<zul> nope
<fabbione> ok
<AndyR> lo all
<fabbione> ok
<fabbione> preparing -19 to fix daniels crack
<fabbione> after that the kernel is back to the team
<smurfix> fabbione: Is that the "how many kernels packages can we do in a day" contest?  ;-)
<T-Bone> fabbione: heh. Weren;t you supposed to let us deal with 2.6.10? :^)
<fabbione> smurfix: no.. i would win that easily
<T-Bone> lol
<fabbione> T-Bone: yes. but emergency > *
<T-Bone> heh. Fair enough :)
* AndyR had a problem with X freezing in hoary today after update
<fabbione> AndyR: it's a GTK bug
* fabbione hides from seb128 
* T-Bone tssks fabbione :)
<zul> T-Bone: let it go :)
<AndyR> fabbione, thank you
<fabbione> AndyR: no sorry.. i was just kidding
<seb128> :p
<T-Bone> zul: hehe ;)
* fabbione starts to emit his own light in sign of magnificence
<zul> *cough* full of it *cough*
<T-Bone> fabbione: looks like your wedding got to your head. Get some cold shower to cool it down ;^))
<fabbione> ahha
<fabbione> that's nothing
<fabbione> it's more fun when i play pinhead or God
* T-Bone gets scared ;)
<zul> i was the same way when i had my wedding
<fabbione> nahhh
<fabbione> i did that way before i decided to get married
* fabbione is sick in his mind
<smurfix> elmo: please de-NEW keymapper
<T-Bone> zul: see, fabbione is a long-time nuthead :^)
* T-Bone ducks!
<zul> no he said pinhead 
<Kamion> smurfix: (hope you're not expecting keymapper in array cd 5 BTW)
<T-Bone> hmm true ;)
<Kamion> smurfix: does it have priority optional or extra?
<fabbione> T-Bone, zul: i think you need to see the movies Hellraiser to understand what i mean
<smurfix> Kamion: Awww... 
<smurfix> Kamion: optional
<T-Bone> fabbione: aaaaah
<zul> hehe
<Kamion> smurfix: ok, fine
<Kamion> smurfix: (we need array cd 5 to be really stable)
<smurfix> Kamion: as I understand, extra wouldn't be a good idea for something that's ultimately needed to build the installer
<Kamion> smurfix: optional or extra doesn't make the slightest bit of difference
<smurfix> Kamion: Hmm, so why did you ask?
<Kamion> smurfix: the only thing that makes a difference to d-i is whether it's >= standard or < standard
<Kamion> smurfix: I asked "does it have priority optional or extra" as opposed to standard, important, or required :)
<Kamion> >= standard udebs get used by default
<Kamion> some < standard udebs get used by default too, but that's by virtue of being in the initrd
<smurfix> Kamion: ah ;-)   No, the thing doesn't need to be installed anywhere except on the system that builds the console-data udebs
<Kamion> or for other reasons
<Kamion> smurfix: the udeb needs to be installed eventually, though; but it'll go in the initrd
<smurfix> Kamion: sure
<Kamion> smurfix: oh, is this just a build system helper? I thought it was the udeb
<smurfix> Kamion: The additional udeb will be built by console-data as soon as I'm done with it, which should be RSN
<smurfix> Kamion: ... which I'll (obviously) hold off on until after elmo has processed keymapper.
<Kamion> ok, right, as long as *that* udeb is priority < standard then I'll be happy :)
<mdz> tech board meeting in #ubuntu-meeting in 5 minutes
<T-Bone> feh, just in time :)
<fabbione> ok the kernel -19 is going up now
<fabbione> now.. 
<T-Bone> GO TO BED! :)
<fabbione> Dear Kernel Team,
<fabbione>  please take over
<fabbione>  and let me go in honeymoon
<T-Bone> will do, until your next upload :)
<fabbione> 
<fabbione> Kthxbye,
<fabbione> Fabio
<T-Bone> have a nice a sweet time!
<fabbione> i am looking forward to thursday :-)
<T-Bone> lol
<fabbione> and to next monday when i will be swimming with the Galapagos Penguin
<T-Bone> Damn!
<T-Bone> heading to the Galapagos heh?
<fabbione> yup
<kent> fabbione, have a nice wedding! :)
<T-Bone> lucky guy!
<fabbione> kent: hem.. that's late for that ;)
* fabbione wants honeymoon
<T-Bone> fabbione: enjoy it, and forget everything else.
<kent> fabbione, oh, haha, i dont know you, so i just assumed you were getting married, but perhaps you already are now? :)
<T-Bone> if you don't get 200% into it, you'll regret it :)
<fabbione> T-Bone: yeah i know
<fabbione> kent: i got married last saturday
<T-Bone> fabbione: heh, that (hopefully) happens only once in a lifetime! You'd better not miss that time ;)
<fabbione> T-Bone: yeah once for each wife :P
<T-Bone> LOL
<T-Bone> shaaaaaaaaaaaaaaaaame on you, you nasty boy ;)
<T-Bone> ARG! Kernel bug strikes back
<T-Bone> lamont, Kamion : ia64 won't find its cdrom again
<Kamion> sigh
<Kamion> please investigate
<T-Bone> if only I knew where to look
<T-Bone> last time it was fixed in the next ISO i tried...
<T-Bone> and i never found out what was wrong
<T-Bone> i don't know whether that's something you change in d-i or some ABI breakage in the kernel...
<fabbione> T-Bone: just wait -19 to be around tomorrow
<fabbione> and that everything is synced again
<T-Bone> fabbione: i guess so
<fabbione> i am pretty sure -17 has been used for some stuff
* T-Bone looks at the change message to see what fabbione changed
<fabbione> ence the breakage
<T-Bone> fabbione: i'm using kamion latest roll with -18 on it
<T-Bone> and last time i hit that bug was 1 or 2 weeks ago
<zul> *sigh*
<T-Bone> indeed :(
<fabbione> there was also a report for sparc not recognizing the netcard
<fabbione> that it is kinda weird
<fabbione> so perhaps it is not necessarely the kernel at fault here
<T-Bone> that's why i'd like to know whether d-i has changed lately ;)
<T-Bone> it's kinda weird that I had the bug, then it vanished, and now it's back again :P
<Kamion> T-Bone: I thought I remembered it being a kernel problem
<Kamion> T-Bone: there have been no relevant changes in d-i
<Kamion> +  * ia64
<Kamion> +    - Remove amd74xx from debian/d-i/ia64/modules/ia64/ide-modules
<Kamion> that was what fixed it
<T-Bone> nah. That fixed the error prompt
<Kamion> T-Bone: no, it fixed much more than that
<T-Bone> ?
<Kamion> T-Bone: our kernel packages do not check the return code from kernel-wedge (which I think is a clear and severe bug in our kernel packages, but Fabio disagreed last time I mentioned it, so I dropped the issue)
<Kamion> T-Bone: kernel-wedge stops copying modules when it encounters a module name that it's been told to copy but that it couldn't find
<T-Bone> hmm
<Kamion> T-Bone: so everything following amd74xx in debian/d-i/ia64/modules/ia64/ide-modules was totally missing (including isofs.ko), and a number of other udebs were empty
<fabbione> Kamion: no. i didn't disagree
<T-Bone> Kamion: ah ok.
<fabbione> Kamion: but kernel-wedge breaks in other interesting ways i had no time to figure out
<T-Bone> Kamion: something strange: if i look in dmesg output, tho ide-cd is loaded, i don't see the "Uniform CD-ROM driver loaded"
<T-Bone> Kamion: when i modprobe -r the module, it says "Uniform CD-ROM driver unloaded", but if i modprobe it back, nothing happens...
<fabbione> T-Bone: try to modprobe cdrom
<fabbione> ide-cd is only one of the mods you need
<T-Bone> fabbione: cdrom is loaded when modprobing ide-cd
<T-Bone> i rmmod'd both of them before loading ide-cd
<T-Bone> i'm also quite suspicious at the number of IDE interface reported to be probed: 6
<T-Bone> i don't think there's that many in the box
<Kamion> T-Bone: I'd suggest diffing udeb contents from -16 to -17 to -18
<fabbione> skip -17
<fabbione> and go directly for -19
<T-Bone> Kamion: any easy way to do that?
<Kamion> -18 is what is on the current CDs
<Kamion> T-Bone: debdiff?
<T-Bone> doh
<fabbione> T-Bone: you can add to the kernel TODO list to remove the || true on kernel-wedge call
<fabbione> T-Bone: and fix either kernel-wedge or the kenrel package
<fabbione> depending is in the worst shape ;)
<T-Bone> heh
<T-Bone> fabbione: i've pointed lamont at some other likely bug too
<fabbione> T-Bone: we need the fixes.. not the bugs :-)
<T-Bone> fabbione: i have a life, too, you know? :)
<fabbione> T-Bone: that's what you believe
<fabbione> not after you offered volunteer for the kernel team
<fabbione> :P
<T-Bone> lol
<T-Bone> Kamion: that's either a kernel bug, or a module init bug, or something related to that. /proc/interrupts shows no trace of the ide interfaces, while it does on the installed ubuntu system
<T-Bone> looks like the probing simply fails
<T-Bone> PCI table screwed?
<T-Bone> i don't know well enough how hotplug works alas :(
<Kamion> look at modules.pcimap and see if it's sane
<zul> T-Bone: you have been asimilated your gf will understand
<T-Bone> zul: i don't think so. And even if she does, you'd have to convince my boss as well to explain him why i'm sleeping at work ;)
<T-Bone> Kamion: what's the filetype for boot.img?
<T-Bone> s/file/filesystem /
<Kamion> for ia64 it's FAT of some kind
<Kamion> created with mkfs.msdos
<T-Bone> ah ok thx. I was trying cramfs ;P
<Kamion> T-Bone: not unless somebody taught EFI to understand cramfs ;)
<T-Bone> hmmm. I guess i'm not looking at the right place. modules.pcimap is in the kernel package source i suppose ;P
<T-Bone> Kamion: heh, don't even think of it :)
<Kamion> T-Bone: no, it's generated by depmod
<Kamion> T-Bone: /lib/modules/blah
<T-Bone> ah
<T-Bone> found it
<Kamion> T-Bone: in this case it's generated (a) during the debian-installer initrd build process (b) by various d-i modules after new module udebs are installed
<T-Bone> arg
<T-Bone> so i want to look at it on the booted media?
<Kamion> T-Bone: yes
<T-Bone> sigh
<Kamion> at the point of failure
<zul> T-Bone, well your boss isnt my problem :)
<T-Bone> zul: somehow i knew you would say that
<T-Bone> zul: but it extends to me lacking sleep in unhealthy fashion, unfortunately :P
* T-Bone has the defect of needing long nights to hack efficiently
<T-Bone> i'm almost certain the issue is pcimaps
<T-Bone> Bingo
<T-Bone> Kamion: grep generic modules.pcimap yields no result
<T-Bone> hmmm WTH
<T-Bone> CONFIG_FUSION=m !?
<T-Bone> uname -a: Linux (none) 2.6.10-3-itanium-smp #1 SMP Mon Feb 7 15:49:57 UTC 2005 ia64 unknown ???
<T-Bone> Kamion: i rsync'd that ISO, what's wrong?
<Kamion> I had to drop back to an old debian-installer build to make shit work at all
<Kamion> because today's daily d-i build was built with -17
<T-Bone> Grrr
<Kamion> T-Bone: ok, that'll be fixed sometime tomorrow then
<Kamion> T-Bone: sorry, it was you or everyone else
<Kamion> I forgot about the fusion thing
<T-Bone> :(
<fabbione> argh
<T-Bone> Kamion: it's not a fusion problem
<fabbione> you mean FUSION should have been =y ?
<T-Bone> Kamion: you apparently picked up the d-i version that already failed for me last week, that's all
<Kamion> that was fixed in -17
<T-Bone> so the issue i've been investigating since my dinner is a non-issue :(
<Kamion> T-Bone: yes, I know. sorry :(
<Kamion> T-Bone: everyone else was on my back for a fixed ISO though
<T-Bone> *sigh*
<Kamion> consider it an object lesson for the kernel team on what happens if you break the ABI ... :)
<fabbione> T-Bone: well tomorrow there will be -19
<T-Bone> Kamion: i understand. It's just that if you'd said so a bit earlier, I'd have been sleeping already by now :}
<Kamion> T-Bone: sorry, I just didn't catch on that that was the issue
<T-Bone> heh
<Kamion> fabbione: without ABI change, I hope ...
<fabbione> Kamion: i fixed the ABI with -18 :-)
<fabbione> -19 is a requirement for some other modules in a udeb
<Kamion> fabbione: I mean without deliberate ABI change
* T-Bone calls it a night and curses a bit fabbione Kamion and others for killing his nights B-] 
* fabbione inflicts endless pain to T-None 
<T-None> fabbione: there's no bigger pain for me than a shortenned night. Come back tomorrow :)
<zul> T-None: *whine* *whine* :)
<ogra> moquist: ping
<T-None> zul: heh. I think I can :)
* T-None really gets to bed now. bye all
<Kamion> damn, must not accidentally upload packages to Debian as cjwatson@ubuntu.com
<fabbione> night ladies
<ogra> night fabbione :)
<sivang> night fabbione , congerts
* fabbione &
<pitti_> night fabbione 
<Kamion> damn, every time someone says something like "fabbione &", I think "huh? demon? where?"
<smurfix> elmo: please sync yapps2
<ogra> hehe
<smurfix> elmo: (needed for keymapper)
<fabbione> hmm that's more like fabbione's fork in background ;)
<fabbione> ehheh
<ogra> Kamion: normally he switches to pinhead mode before becoming a daemon ;)
<Kamion> ogra: well, it wasn't that kind of daemon I was thinking of; suffice to say I've played too much nethack
<ogra> lol
<Kamion> elmo: please sync os-prober 1.03
<sivang> anybody know where boot admin went? (I think it's part of g-s-t)
<tseng> its always been patched out afaik
<mantiena> sivang, yes, it's part of g-s-t
<sivang> tseng: ok, thanks.
<mantiena> Kamion, when your's today fixed cdrom-retriever will be available at archive.ubuntu.com pool ?
<sivang> seb128: is there anything wrong with boot-admin that we put it away?
<Kamion> mantiena: I only committed the change upstream, I didn't upload it anywhere
<Kamion> you should be setting mirror/suite so you shouldn't need it urgently
<mantiena> Kamion, ok
<ogra> dredg ?
<dredg> ogra
<mantiena> Kamion, how many hours you are working ?
<ogra> are you going for MOTU ?
<mantiena> per day
<Kamion> mantiena: way too many :)
<Kamion> certainly at least 9-10 on average
<dredg> ogra: yes... but soon
<mantiena> Kamion, you could have a dog, then you should go to walk with a dog every day ;)
<dredg> ogra: why do you ask?
<Kamion> mantiena: my fiancee already has a snake; I think one pet between us is enough for now. However, walking the snake is not so easy. :)
<ogra> dredg: you already linked your wiki page on MaintainerCandidates ? (we are cleaning up tha page currently and i suspect you got deleted, since i dont see you there)
<dredg> ogra: did i?
<mantiena> mdz, still online ?
<dredg> eep. i don't recall
<mdz> mantiena: yes
<ogra> dredg: dunno, thats why i asked....if you want to be a MOTU, this is the first step to take ;)
<mantiena> mdz, why en_ZA.UTF-8, en_GB.UTF-8 and en_US.UTF-8 locales are generated every time when liveCD starts ? it wastes a lot of time on average computers (~1 Ghz, 256 RAM) :(
<Hwolf> mantiena: gnome isn't build for average computers anyway. :-S
<pitti> mantiena: because we decided to generate all relevant language locales when isntalling a language pack
<mdz> mantiena: they are not supposed to be; the language support package should be preinstalled in the cloop image
<mdz> lamont: ^^^ please check
<Kamion> the -en one is, like, massive overkill though :)
<pitti> not my fault that there are so many english speaking countries...
<mdz> oh, lamont is away today
<pitti> ;-)
<dredg> ogra: i was looking around a fair bit, and kicked off a page yes... i *may* have accidentally linked myself in there (it was around 4am), and yes i do intend going for MOTU... just not right yet :)
<pitti> Kamion: of course I can special-case this, but to what?
<Kamion> pitti: I'm not all that bothered
<bluefoxicy> freedoom depends on prboom or doom-engine
<bluefoxicy> freedoom depends on prboom or doom-engine
<ogra> dredg: we are in a fast maintainer approval process until hoary is released....so this is the best time to start 
<bluefoxicy> ^^^  freedoom depends on prboom, twice :)
<mantiena> mdz, I think problem is in casper/pre.d/15localechooser script - it uses locale.gen instead of localedef 
<pitti> Kamion: it's primarily a live cd issue, installation won't see it often
<bluefoxicy> out of academic curiousity, why do some dependencies show up more than once?
<pitti> Kamion: in fact only once
<mdz> mantiena: this was working in the past; it probably broke as a result of the transition from special-case code in the live cd build, to the language-support-en package
<dredg> ogra: noted :) sorry if i caused any confusion
<ogra> dredg: i already saw you made some packages, so polish them for universe inclusion ;)
<mantiena> mdz, it works, but does unneeded work, I  can patch casper/pre.d/15localechooser script to use localedef instead of localegen if you would accept my patch
<dredg> ogra: that's my intention :)
<ogra> great :)
<mdz> mantiena: talk to Kamion about it; that is his domain
<mdz> but this used to work, so I doubt that changing localechooser is the correct fix
<Kamion> I don't see why it should use localedef
<Kamion> locale.gen is correct and integrates properly with the rest of the system
<ogra> dredg: if you got questions regarding the motu process or organizational stuff, feel free to join #ubuntu-motu
<Kamion> locale-gen, that is
<Kamion> and locale-gen does very little more work than equivalent localedef on an initial run
<dredg> ogra: oh excellent. will do
<dredg> ogra: thanks :)
<ogra> dredg: youre welcome :)
<mantiena> Kamion, locale-gen regenerates all locales, it not checks if they are already generated
<mantiena> Kamion, when starting from live CD regenerating already generated UTF-8 locales (en_US, en_GB and en_ZA) wastes pretty long time
<Hwolf> 64% cpu-usage by gam-server, is that normal?
<Kamion> mantiena: oh, I see. However, if all the locales for a language are already generated then localechooser's script should do nothing
<Kamion> or at least not call locale-gen
<Kamion> I think the right answer is to make sure that all the English locales are pre-generated in the cloop image so that localechooser doesn't run
<Kamion> locale-gen
<mdz> mantiena: the localechooser script already does that check
<mdz> it's just a bit picky about it
<mdz> if all of the needed locales exist, it doesn't call locale-gen
<mdz> mantiena: /etc/locale.gen on the cloop image seems to be missing the ones you mentioned
<mdz> lamont will need to fix it
<mdz> thanks for finding it
<Kamion> localechooser doesn't check for things like en_ZA though
<Kamion> it only cares about the exact locale you selected
<Kamion> I guess it depends which locale you ended up with
<mdz> oh, I see the problem
<mdz> we added language-support-en to the live seed, but not language-pack-en
<mdz> language-pack-en does the locale generation
<mdz> fixing
<mdz> live_seed++ for making this trivial to fix :-)
<ogra> bah, the new gksudo without borders is soo ugly...
<Kamion> mdz: aha, good call
<Kamion> and l-s-en only recommends l-p-en
<tseng> ogra: agreed.
<mdz> jdub: how is polypaudio treating us so far?
<Kamion> mdz: I should make germinate spit out informational .recommends files with all the unsatisfied recommendations in each seed
<mdz> Kamion: I was just thinking that
<mdz> Kamion: if it's trivial, sure, otherwise add to the never-ending germinate todo
<Kamion> I think that might not be too hard
<Kamion> there's a never-ending germinate todo? where?! :-)
<mdz> jbailey: ping?
<zul> later
<Hwolf> Is jeff waugh still here?
<mdz> Hwolf: I have not seen jdub yet today, but he should be around soon if he is not so already
<Hwolf> mdz: I take it that 100% cpu-usage from gamin is something he'd like to hear about?
<mdz> Hwolf: I'm pretty sure I saw a bug report about that already
<ogra> Hwolf: i think "like" is the wrong term here
<mdz> Hwolf: but if there isn't, filing a bug would be the thing to do
<Hwolf> mdz: that's why I'm asking, because I have no idea where it is coming from. :-)
<seb128> sivang: boot is not built by upstream, we don't change the options
<sivang> seb128: ah ok, unmaintained or something ? It used to work pretty well for me 
<seb128> sivang: ask carlosg, I'm not upstream
<sivang> seb128: right :-)
<mxpxpod> is there a reason I'm getting a BADSIG on the hoary-security and hoary-release gpg keys on the powerpc archives?
<crimsun_> which key signs? 0x437D05B5?
<crimsun_> (from apt-key list)
<mxpxpod> yeah
<crimsun_> looks to be perhaps a ppc-specific issue?
<crimsun_> ppc archive, that is
<crimsun_> looks fine for i386
<mxpxpod> is anyone here running hoary on an ibook g4 with benh's sleep patch applied to the kernel?
<mxpxpod> I've got an issue where I wake my ibook up after a long sleep and then try to pop my email using evo and my laptop freezes
<amu> mxpxpod: probably pitti, i'm not sure if he use the patches 
<mxpxpod> it's really strange
<pitti> mxpxpod: no, I don't use the patch
<mxpxpod> pitti: ibook g4?
<pitti> mxpxpod: I tried it once but it did not work
<pitti> mxpxpod: yes, a pretty new one (Jul 04)
<amu> pitti: mxpxpod: i think the latest sleep patches arnt applied to the hoary kernel also
<mxpxpod> amu: I use 2.6.9
<mxpxpod> benh doesn't have a patch for 2.6.10
<mxpxpod> which is a shame
<pitti> mxpxpod: according to the logs, much of the stuff was merged into 2.6.11 upstream
<mxpxpod> oh??
<pitti> mxpxpod: however, hoary's current 2.6.11pre kernel doesn't work for me
<mxpxpod> that's cool
<mxpxpod> what's this? we're not using esound anymore?
<ogra> polypaudio :)
<mxpxpod> what's that?
<ogra> the esd replacement
<mxpxpod> is it any good?
<amu> mxpxpod: same here, using also 2.6.9 patched myself 
<ogra> i have installed it since about an hour.....
<mdz> mxpxpod: nah, we think it's pretty crap. that's why we selected it :-)
<sivang> mxpxpod: you should have seen the love letter jdub wrote the mdz when polyaudio were GO, I was here when it happened :)
<mxpxpod> mdz: :P
<ogra> its misconfigured, but works fine after some tweaking....
<sivang> ogra: do I need to explicitly install it or it's been auto upgraded ?
<mxpxpod> ogra: hmm
<mxpxpod> amu: what machine?
<ogra> sivang: i have explicitly installed it....
<sivang> btw, the topic is timezone unfriendly ;-)
<mxpxpod> polyp is getting installed with ubuntu-desktop now
<amu> mxpxpod: pb-g4
<mxpxpod> amu: hmmm, do you remove modules before you go to sleep?
<jdub> GOOD MORNING FREEDOM LOVERS!
<pitti> Hi jdub 
<sivang> morning jdub !
<sivang> we were just talking about you :)
<ogra> GOOD MORNING JDUB
<mxpxpod> I'm scared to install polypaudio
* dredg boinks jdub in the capslock
<mxpxpod> does it work with libgnome*?
<amu> mxpxpod: yeah
<tseng> hi jdub, mxpxpod 
<mxpxpod> amu: what modules do you remove?
<jdub> mxpxpod: polypaudio supports the esound unix socket and tcp protocols
<mxpxpod> tseng: hey... did you ever get that tomboy thing fixed?
<amu> mxpxpod: alsa, hwclock
<mxpxpod> amu: no usb stuff?
<tseng> mxpxpod: no =/
<azeem> mxpxpod: polypaudio is binary compatible to esound, TTBOMK
<amu> mxpxpod: no 
<tseng> i did try installing the pixmaps by hand to the right places but no love
<mxpxpod> amu: hmm
<mxpxpod> amu: what about bluetooth stuff?
<mxpxpod> azeem: ah, ok... thanks
<amu> mxpxpod: with my own pachted 2.6.9 everthing works fine
<tseng> as i recall the strace wasnt very useful either
<ogra> mxpxpod: i had to start it manually with polypaudio -nF /etc/polypaudio/default.pa to make rhythmbox happy
<amu> mxpxpod: i do not use bluetooth 
<Hwolf> jdub, can you help me check why gamin is using up 100% of my cpu?
<mxpxpod> ogra: that's crap
<ogra> mxpxpod: just a wrong default config, i guess that will be sorted soon...
<mxpxpod> I hope
<ogra> mxpxpod: it only affected RB here
#ubuntu-devel 2005-02-27
<ogra> mxpxpod: ad the login/logout sounds
<ogra> s/ad/and
<mxpxpod> amu: could you email me the patch you use and the config as well?
<mxpxpod> ogra: hmm
<mxpxpod> ogra: so, g-s-d needs to start polypaudio instead of esd
<amu> mxpxpod: for 2.6.9, sure
<mxpxpod> amu: yeah
<tseng> ogra: seems to work here
<tseng> (rb polyp)
<ogra> mxpxpod: thats already done by default...
<mxpxpod> tseng: is esd still running?
<tseng> i ran esd, set gstreamer to esound, and ran rb
<tseng> no, i dont run esd normally
<dholbach> re
<ogra> tseng: how can esd be there if ppaudio conflicts with it ?
<tseng> ogra: um.. paudio provides an esd
<tseng> polypaudio: /usr/bin/esd
<jdub> esd just runs polypaudio
<ogra> tseng: ah, well...i saw polypaudio in my processlist...
<tseng> jdub: right, but it tricks gnome into running it in lieu of esound
<jdub> seb128: xchat plays sounds correctly with esound-clients installed?!
<seb128> jdub: here it does
<jdub> tseng: that's the idea, yeah :)
<jdub> seb128: that is complete bong
<jdub> that is so much complete bong
<seb128> it call esdplay
<seb128> that's the default command in the properties
<jdub> xchat isn't exactly a bastion of sanity
<seb128> right
<seb128> gnomechat rulez ? :)
<jdub> but that is so much crack and bong and wack
<jdub> seb128: perhaps we should install polypaudio-clients and switch it to use paplay by default :)
<seb128> that's bong too :p
<ogra> but more consistent :)
<seb128> right
<jdub> seb128: that's forced bong
<seb128> yeah
<dredg> xchat? sounds? sweet zombie jesus.
<jdub> xchat makes us use the bong
<sivang> jdub: are you using xchat at the momnet?
<seb128> jdub: BTW what sort of debug output would you need for gamin ? Since it seems to be broken for everybody expected out
<seb128> jdub: I've booted with noinotify for the moment, works fine now :)
<jdub> so
<jdub> uh
<mxpxpod> strange... polypaudio dies for me
<jdub> i guess everyone's heard about hula by now
* jdub boggles at pgo
<seb128> he he
<jdub> sivang: man, i don't use xchat
<seb128> a guy already mailed ubuntu-devel list about it
<jdub> seb128: so new inotify is elb0rk, or gamin is b0rking it?
<seb128> men, ubuntu-devel turn beeing a bug list atm
<mdz> Mithrandir: ping
<seb128> jdub: dunno what is broken, but monitoring of a single file doesn't work whatever I do (and that's the same for Vincent and random bugzilla submitters)
<mdz> haggai: ping
<mdz> haggai: (oo.o2 FTBFS)
<mdz> Mithrandir: (UTF8MigrationTool)
<seb128> jdub: with dnotify I can clear the recent documents, add a gtk bookmark
<seb128> jdub: and according to pitti the device pop correctly on the desktop when he boots with noinotify
<seb128> s/device/devices
<jdub> seb128: reckon we should disable inotify support in gamin again? :)
<tseng> jdub: =/
<seb128> that's my opinion
<sjoerd> seb128, jdub: in debian gamin seems to stop doing it's stuff after a while too.. where there is certainly no inotify
<seb128> sjoerd: saying that we should roll back to fam ? :p
<sjoerd> seb128: no we should fix gamin :)
<jdub> ok, i'm going to upload a --disable-inotify build
<seb128> jdub: any hint to figure if that's an inotify or gamin issue ?
<jdub> the freezing computer stuff is inotify ;-)
<seb128> jdub: you are running a standard hoary kernel ?
<jdub> the monitoring one file stuff is probably gamin
<mxpxpod> jdub: what freezing computer stuff?
<sjoerd> although gamin 0.0.23 has some deadlock fix which isn't in debian ;)
<seb128> (just trying to figure why "clear recent documents" works for you)
<jdub> seb128: yes, though haven't rebooted since last update
<sivang> jdub: :)
<seb128> jdub: what do we win with the inotify backend ? Just trying to figure if we should rather try to get this fixed, or if switching to dnotify is alright
<sivang> pitti: regarding #6092, I want to have some message when someone tries to modify a user and see he cannot change the uid, what do you think would be a good thing to say "Changing UID is not allowed when modifying an existing user" ? (this would be a label, not a window or a pop up of some sort)
<jdub> seb128: you can unmount devices that are being monitored
<seb128> and you can freeze your kernel :p
<zul> jdub: my bad about the inotify patch
<ogra> sivang: why is it possible at all to change the uid ? what is the usecase for that ?
<tseng> zul: meh, you arent the first guy to break it!
<sivang> ogra: read the bugtrail, it's and old discussion already :)
<zul> tseng: still my bad
<dredg> seb128: ah, the freeze is inotify and not flaky usb-storage? :)
<mxpxpod> jdub: could that be part of my problem when waking up my ibook? the inotify stuff?
<jdub> zul: ;)
<jdub> mxpxpod: doubt it
<zul> if you upgraded to -17 today maybe..
<mxpxpod> jdub: hmm
<mxpxpod> and why is ubuntu-desktop on powerpc still dependant on apmd
<thom> because it's an extremely low priority problem, if indeed it's a problem at all
<Kamion> because we need to make that seed arch-specific; doing now
<Kamion> um, at least I assume it needs to be arch-specific
<Kamion> thom?
<thom> Kamion: idunno
<thom> certainly mjg59 was saying that not all ppc stuff uses pmu
<thom> so it's not outside the realms of possibility it's needed on some ppc stuff
<Kamion> mm, we don't really support non-Macs yet though
<thom> true enough
<thom> guess we can just reseed if and when
<Kamion> mxpxpod: does apmd break stuff for you?
<mxpxpod> Kamion: I'm not sure
<mxpxpod> I just don't think it's needed
<robtaylor> hmm, can anyone think of a good reason my PRO/Wireless 2100 doesnt work under hoary atm?
<thom> robtaylor: you have any logs, owt in dmesg?
<Kamion> mxpxpod: well, sounds like it is needed on some powerpc hardware, just not Macs
<thom> certainly as of yesterday's kernel mine does
<Kamion> I suppose we could have d-i install it depending on the hardware, though that kind of seems like crack
<robtaylor> thom: hmm, just upgraded and rebooted.. i'll check my dmesg
<jdub>    * debian/patches/02_menuspeed.patch:
<jdub>      - patch to speed up the menu opening (Hoary: #5643).
<jdub> seb128: !!!
<jdub> seb128: you fixed gtk boog!
<sivang> seb128: coool
<ogra> jdub: what about gksudo ? will it stay this ugly and undecorated ?
<seb128> in fact that's an upstream patch with this comment:
<robtaylor> thom: hmm ,nothing useful, i get "ipw2100: Detected Intel PRO/Wireless 2100 Network Connection"
<seb128> "With this patch, please pay attention to submenus. Are they slow to appear or not?"
<jdub> ogra: what kind of ugly?
<seb128> so feedbacks are welcome :)
<jdub> seb128: :)
<daniels> seb128: one down, four thousand to go
<robtaylor> thom: kernel is 2.6.10-3-386
<Kamion> jdub,seb128: what's up with the top panel launcher icons being missing on a default install?
<thom> robtaylor: just upgrading to todays kernel and will try
<robtaylor> thom: cool, thanks :)
<ogra> jdub: if i got a window with lots of gray areas open, i normally miss it popping up for example...because of the missing borders it just sinks visually into the app... quite annoying and a usability bug i think
<seb128> Kamion: is that a new bug ?
<sivang> seb128: my system has gone strangely faster, including menus :)
<jdub> ogra: ah
<zul> thom: heh we didnt touch wireless
<Kamion> seb128: I think it's relatively recent, last week or two?
<jdub> seb128: ogra's bug, related to the crazy effect patch ^
<seb128> jdub: I know, I've noticed it, but I'm not sure on what should be done exactly, issue beeing worked :)
<mxpxpod> ogra: is there a way to decorate a window w/o the titlebar, but just the border?
<ogra> mxpxpod: i dont think so... 
<tritium> jdub, mdz have either of you seen this yet: https://bugzilla.ubuntu.com/show_bug.cgi?id=6582 ?
<mdz> tritium: that bug is less than a day old, please be patient
<ogra> mxpxpod: you will always have at least a close button and titlebar, i dont know of any way to avoid that....
<mxpxpod> heh
<seb128> Kamion: k, I'll look on that tomorrow
<mxpxpod> later guys
<Kamion> seb128: thanks
<Kamion> I wasn't sure if it was a deliberate change or not
<seb128> no, but default launcher were using the old applications:/// stuff, and they have changed link to a real filename in 2.9.91
<tritium> mdz, sorry, my intention was not to pester
<seb128> perhaps the links are not correct somewhere, I'll check
<Kamion> ok
* thom reboots on young kernel
<robtaylor> thom: thx!
<ogra> sivang: i read the whole bug, but i still dont see any use case ....
<mjg59> thom: I know of no PPC hardware that uses apm natively
<mjg59> But pmu can emulate apm
<thom> robtaylor: new kernel seems fine
<thom> i have ipw2100 loe
<thom> love
<thom> mjg59: cool
<robtaylor> thom: hmmm, oddness
<zul> brb kernel rebbot
<sivang> ogra: well, there is not really one currently, that's why I am blocking this option - however I do think the user deserves to have a msg of some sort as pitti noted it's rather confusing having a spin button that doesn't respond.
<Kamion> mjg59: so should we get rid of apmd from the powerpc desktop?
<mjg59> Kamion: If it's not being used on pmac, then yes
<Kamion> I guess there might be some programs that rely on the apm interface, or something
<mjg59> But I don't know if all power management stuff is done through pmud, or whether apmd is calling some necessary scripts
<mjg59> /dev/apm should still exist even if apmd isn't there
<ogra> sivang: i meant its rather confusing to have a optin there at all... why not just show a label with the uid, this makes it very clear you cant change it
<sivang> ogra: changing this would be too intrusive as the dialog is used both for new and existing users, plus could cause trouble when interface files change upstream.
<ogra> sivang: ah, ok, i didnt know about the dialog recycling there...then i'll shut up ;)
<thom> i'm hesitant to remove apmd from ppc for hoary, tbh
<thom> i think this is way past the point to do it
<sivang> ogra: ;-) I appriciate your remarks 
<ogra> sivang: but if they are based on wrong knowledge i doubt they are usefull, heh
<Hwolf> seb128: If the desktop menu is renamed to system, will applications > system tools move there too? Seems rather logical to bundle it all
<seb128> Hwolf: dunno, ask jdub
<seb128> Hwolf: not my idea
<seb128> but I don't think so
<Hwolf> seb128: pity, this seems illogical.
<tseng> wow at hula "first post" on -devel
<usual> hey seb128 did they do anything exciting in gstreamer for dvd playback?
<jdub> Hwolf: the name of the system tools menu is illogical, not its placement
<usual> hi jdub 
<Hwolf> jdub: I feel the entire array of many different small tools to administer the system is confusing. I'd rather see something more osx/winxp like, but I'll shut up about it 
<magnon> how is osx/winxp any different?
<magnon> they also have small tools
<magnon> the difference is that they put the index in an iconed window
<Hwolf> magnon: It somehow feels better to bundle it all together that way. 
<seb128> usual: dunno, dvd playing seems to work fine here
<usual> seb128, slows my whole x session down :(
<seb128> xorg issue I guess
<seb128> whatever an app do that should not happen
<daniels> ez gtk boog
<seb128> ah ah
<seb128> you wish :p
<daniels> and of course it should happen
<Hwolf> daniels: is that lingo i haven't heard of, or just english? 
<daniels> if you're doing colourspace conversion in realtime, your entire cpu will slow down, and take every app with it
<daniels> and if you're slamming a hojillion frames into the x server per second (given that the rgb->rgb delta is huge compared to yuv->yuv), your server will slow down also :P
<daniels> Hwolf: 'is gtk bug'
<usual> I still have issues with X crashing randomly through nautilus use
<daniels> the issue is probably tha tyou're using xlib directly, and you should be feeding the yuv stream straight into xv
<daniels> usual: cool, what sort of card?
<Hwolf> daniels: thanks. I take it gtk is a buggy bitch then?
<usual> daniels, Nvidia Geforce4
<usual> nvidia drivers
<daniels> usual: ok, bug in the nvidia drivers
<daniels> Hwolf: yeah, it keeps causing all these things that people think are x bugs
<usual> daniels, ok, but I find that hard to believe, so many people use the binary nvidia drivers in many dists and I havn't heard anyone related to my issue
<usual> not doubting it, but curious
<daniels> usual: conversely, I haven't heard of random Nautilus usage crashing X outside of nVidia, and certainly haven't seen it
<Hwolf> daniels: that raises the question why such an essential lib is full of bugs? :-)
<daniels> if you can reproduce it with nv, then I'm interested; else I just can't debug it or work out where it is
<daniels> Hwolf: i don't know, ask seb128
<usual> daniels, yeah, it was fine until a little bit ago when I first mentioned it to you, maybe something in hoary changing?
<seb128> Hwolf: it would be funny without that :p
<daniels> usual: dunno, x hasn't changed in a while now
<usual> daniels, kernel has changed alot
<usual> along with the binary nvidia drivers
<daniels> er, the binary nvidia drivers haven't changed in months
<daniels> when they released 1.0.6629, at which point we had 2.6.8.1
<daniels> the only thing that's changed since then is patches from nvidia to make it compile on new kernels
<jdub> Hwolf: the list of stuff in system tools is crap for various reasons; we'll fix most of it for hoary
<daniels> jdub: would it be possible to get nvidia-glx in ship, if it's not already?
<Hwolf> jdub, ok
<seb128> jdub: oh, speaking about menu entries
<seb128> jdub: is that ok to move the screen resolution stuff to preferences rather than administration ?
<seb128> jdub: apparently we moved it the other way for warty, dunno why (or perhaps that's a side effect of the new menus, but that's a patch)
<jdub> daniels: i don't think we want to do that, do we?
<daniels> jdub: we sure do
<jdub> seb128: we chose to move it to system configuration in warty
<jdub> daniels: i'd be happier if this were brought up on u-d or TB meeting
<seb128> jdub: any rational ? http://bugzilla.ubuntu.com/show_bug.cgi?id=6545 
<daniels> jdub: yeah, unfortunately I couldn't manage to drag myself up for TB
<jdub> seb128: 'rationale' -> i am usually rational ;)
<seb128> ah ah
<thom> jdub: you ARE?!
<daniels> jdub: except when you have NO PANTS
<dholbach> jdub: at what time of the day? :-)
<Hwolf> poor jdub
<jdub> seb128: commented
<ogra> jdub: when are you 'usual' ?
<seb128> k
<seb128> thanks jdub :)
<usual> ogra, hey now
<ogra> usual: heh
<seb128> jdub: I see now, indeed you can be rational :)
<thom> rational all the way to the W
<thom> what is that W, jeffyweffy?
<Hwolf> seb128, is there anything in gnome-panel like a seperator? something to keep 2 launchers apart. 
* dholbach sings: "Happy birthday to you! Happy birthday to you! Happy birthday, deeeeeeeeaaaaaaaaaar oooooooograaaaaaaaaaaa, happy birthday to you!"
<seb128> Hwolf: I don't get the question. You can to add a separator to a menu ? I think you need to change the code for that atm
<ogra> dholbach: heh, thanks...
<thom> seb128: he wants to seperate two icons on the panel itself
<thom> ie, the evolution launcher and the firefox launcher
<thom> i think
<seb128> oh
<seb128> I don't think so
<Hwolf> thom: yup. atm I just put them a little bit apart, but that isn't really sexy. 
<jdub> HiddenWolf: eugenia has a crackrock applet for doing that
<HiddenWolf> jdub: can you say that again in english?
<jdub> that was english
<seb128> jdub: dude, start speaking correctly now :p
<HiddenWolf> jdub, have pity on me
<jdub> seb128: i can't speak the language of diplomacy ;)
<seb128> :p
<thom> jdub: i think you should start speaking latin
<thom> and give me back my CURSORS
<seb128> speaking about CURSOR thom :)
<thom> mouse cursors
* HiddenWolf wants his pretty cursor theme back also. :-)
<seb128> firefox cursor ?
<thom> piss off with your crackpot epiphany whining :-)
<seb128> rooohhhhhh
<jdub> i would like to use my browser for text entry again :)
<seb128> bad thom 
<thom> my browser works fine for text entry
<jdub> see my bug?
<thom> (in other news, i'll be turning off pango tomorrow)
<seb128> jdub: nobody reads your bugs dude
<jdub> aha :)
<sivang> heheh
<thom> jdub: which one of the many i've been ignoring?
<jdub> i refuse to write bugs in french
<thom> ;-)
<seb128> and that's why we don't read them
<thom> oh, wait
<seb128> :p
<thom> it's bugs from elmo i ignore
<jdub> oh man, hula is a whole sticky stack that sucks in smtp, imap, etc., etc.
<thom> yup
<thom> it's sticky sack o' crack
<tseng> jdub: it says you can easily use your own mta
<thom> i only want it for caldav love
<jdub> I HATE PLONE
<ogra> hula looks really cool
<jdub> look at planet ubuntu
<jdub> stupid, stupid plone
<sivang> jdub: slow, hw consuming?
<ogra> jdub: yay, nice one :)
<jdub> tseng: you can use your own mta with exchange, too ;)
<thom> yes, all that in spades
<mjg59> YAY PLONE
<tseng> jdub: hula is surely less crack than exchange
<tseng> jdub: im excited about the idea.
<jdub> sure, i'm excited
<thom> GO PLONE IYB
<jdub> but when you have everything stickily integrated
<jdub> it gets icky, fast
<tseng> whatever kills exchange, dude
<jdub> no
<jdub> the ends do not justify the means
<jdub> look at it this way
<mjg59> jdub: campd says they're happy to accept patches which make stuff less static
<jdub> in hula, the following objects are no longer as they were:
<jdub> - users
<jdub> - mailboxes
<jdub> - imap server
<jdub> - smtp server
<jdub> etc.
<tseng> smtp can be worked around, and using /etc/passwd is on the shortlist
<jdub> there's going to be all kinds of adaptering going on to use normal unix stack stuff
<jdub> tseng: you said the right two words -> "worked around"
<mjg59> It's a piece of Novell software. The fact that it runs on Linux at all is a miracle.
<jdub> i'm not saying this is bad
<mjg59> It's going to take it a while to make it a happy community member, though.
<jdub> but i am pointing out the obvious suboptimal ickiness
<tseng> i think the novell-ness will wear off with some community scrutiny
<ogra> jdub: added it to UniverseCandidates
<thom> it needs to play with apache also
<jdub> thom: i'm thinking... modmodweb :)
<thom> in fact, apache may become the best place for it to be at the community level
<thom> mod_hula :P
<mjg59> It needs a fucking syncml server
<jdub> thom: asf goon!
<jdub> mjg59: that'd be nice
<mjg59> That way we can sync with it nicely with existing code
<jdub> ogra: (i kinda think hula would *not* be a good MOTU target, but anyway...)
<mjg59> Currently, the only free syncml server is in PHP (and not very spec compliant)
<thom> jdub: fsf mafioso
<daniels> well, hula would actually fit nicely at a low level in a2
<jdub> i am not, and have never been, a member of the fsf ;)
* jdub coughs into the microphone
<daniels> jdub: prove it by giving me free beer tonight
<thom> jdub: only cos they lost your bribe money
<tseng> it would doing only ldap calender/contacts and shipping mail off to postfix
<sivang> jdub: please stop, you're killing me :-))
<daniels> jdub: none of this free speech crap, prove you're all about the free beer
* ogra waits for jdubs karaoke
<jdub> daniels: i will buy you one beer tonight.
<daniels> ogra: don't encourage him ;)
<daniels> jdub: word
<ogra> hehe
<thom> (i was semi serious about it being a logical member of the Apache software ecosystem)
<daniels> thom: i think it makes sense
<thom> i doubt the big N will buy that though
<daniels> ... just as long as it revolves entirely around D-BUS
<daniels> given it's bias-declaration o'clock
<thom> dbus, smeebus. it needs to use DOORS
<daniels> doors?
* thom fanboys solaris for a second or two
<jdub> has anyone itped it yet?
<daniels> thom: OMG AND THEN WE CAN MAKE IT USE DTRACE TOO
<daniels> thom: GOOD IDEA
<jdub> thom: man, just watching the checkout -> ha ha port to apr
<mjg59> Joerg on openbsd-hackers was the best thing ever
<daniels> jdub: no
<daniels> mjg59: i heard about that
<daniels> mjg59: do you have an account on fd.o?
<mdz> thom: I am getting that infuriating scroll-wheel-quits-randomly problem in firefox again
<mdz> thom: does that happen to you?
<mjg59> daniels: I don't /think/ so
<thom> mdz: it never stopped happening for me :(
<jdub> mdz: yes, that happens to me
<thom> mdz: i reported it upstream, they said "oh yes, so it does" and then buggered off
<daniels> mjg59: oh, they created the page
<mdz> it seemed to stop for me for some time
<daniels> mjg59: freedrtools.fd.o
<magnon> ich
<sivang> never stopped happening for me also
<magnon> imagemagick is compiled against xorg
<thom> jdub: see, that would be rad
<thom> cross platform for free
<jdub> so you can run it on AIX and OSF/1
<thom> mdz: nothing has changed recently in mouse handling stuffs
<thom> jdub: and OS/390!
<thom> and OS2 WARP
<thom> IMPORTANT PLATFORMS
<ogra> thom: no BeOS ?
<HiddenWolf> Are there any plans to do for xfce what is being done for kde right now?
<thom> ogra: that;s not as marginal as os2 :-) (but yes, apr supports beos)
<ogra> HiddenWolf: talk to crimsun, he is the xfce MOTU
<daniels> magnon: ... yes
<jdub> HiddenWolf: i've been talking to some of the xfce guys about it
<magnon> daniels: would be nice to have the ability to only install the console tools on a server
<HiddenWolf> jdub: cool
<sivang> magnon: isn't this already possible with the "custom" install target?
<magnon> sivang: the _imagemagick_ console tools :)
<jdub> heh, from hula build:
<jdub> Phase I: Reading & interpreting template
<jdub> Phase II: Checking template
<jdub> Phase IIIa: Loading language strings
<jdub> Phase IIIb: Loading language images
<jdub> Phase IV: Compiling name tables
<jdub> Phase V: Storing static template data
<jdub> Phase VI: Compiling template files
<sivang> magnon: didn't even know something like this existed. well, my bad agian :)
<jdub> Phase VII: Storing static pages
<jdub> Phase IX: Cleaning up
<jdub> 
<sivang> it's ratehr, high leve?
<sivang> ;-)
<magnon> sivang: Gallery uses it exstensively.
<sivang> magnon: to produce server side imanges on the fly?
<magnon> no, to make thumbnails etc.
<sivang> like charts and etc
<sivang> ah ok
<sivang> sounds cool
<dholbach> 'convert' is part of it
<dholbach> and it rocks
<jdub> Agent HULAIMAP.NLM has already been started in the last 300 seconds.  Waiting to load again.
<jdub> YES!
<jdub> YES!
<jdub> give me that nlm loving!
<daniels> .nlm?
<jdub> very netware
<magnon> care to inform me what hula is?
<jdub> hula-project.org
<jdub> you've been in #g-h dude
<daniels> not since fridayish
<daniels> oh, him
<thom> .NLM RUN AWAY
<thom> screaming!
<magnon> yeah, I've seen hula tal
<ogra> magnon: http://www.hula-project.org/
<magnon> k
<dholbach> Netware Loadable Module :-)
<magnon> never seen what it is though
<magnon> jdub: oh! nice!
<thom> i are reminded heavily of my first job
<dredg> hmm, me too
* dredg quite liked netware
<magnon> jdub: I'll have to look at that. Some other time, but still. That looks darn nice.
<magnon> eventually will look nice
<magnon> caldav will mean that it works with the ogo connector then
<whiprush> DUDES. We did good today, got about 50 ubuntu CDs out to the worthy today.
<whiprush> mako is bringing in a resupply.
* thom sleeps
<thom> night dudes
<sivang> night thom 
<jdub> whiprush: rockin'!
* jdub plays with hula
<magnon> is hula, uhm, stable enough?
<magnon> well, if I'm willing to install it on my server to try it, the demands on stability aren't that high anyway :>
<jdub> i'd recommend a test box to start with
<magnon> seems like a thing that'd update a lot, I'd like it to work after each update I do
<mdz> jdub: didn't we decide to fix gdm so that it beeps instead of playing the annoying sound?
<jdub> mdz: i thought we decided to remove it completely?
<mdz> jdub: or that
<jdub> :)
<mdz> jdub: either way, please make sure that happens
<jdub> yep
<mdz> thom: netapplet just crashed on me during logout; was unable to get to the "inform developers" button and get a trace due to the logout process finishing
<mdz> thom: however, it is reproducible every time
<mdz> jdub: why is it that the login/logout sounds do not play under polypaudio?
<jdub> mdz: dunno, been investigating that
<ogra> jdub: running it manually like: polypaudio -nF /etc/polypaudio/default.pa makes it work here
<jdub> yeah, saw someone mention that before
<jdub> total crack
<ogra> jdub: it also solves the rhythmbox problem
<jdub> rhythmbox problem?
<ogra> jdub: cant connect device or something.... i had it here and its also mentioned on the list
<jdub> haven't had that myself, gstreamer configured to use esd works fine
<jdub> mdz: i think it could be delayed loading of the alsa modules
<mdz> jdub: that might explain startup, but shutdown?
<ogra> jdub: i never touched the gstreamer config here....and as i said, the above command solved both problems
<jdub> mdz: if they're unloaded at shutdown...
<thom> mdz: yes, know about that one
<azeem> ogra: woot, thanks
<jdub> ogra: had you restarted your session?
* azeem hugs rhythmbox again
<ogra> jdub: yup
<ogra> jdub: even the system since i had a kernel upgrade
<Kamion> night all
<ogra> night
<daniels> Kamion: 'nacht
<sivang> 'nacht ogra 
<ogra> daniels: wow without any accent.... perfect german ;)
<daniels> heh :)
<ogra> sivang: i was saying it to Kamion ;)
<jdub> hrm, lots of nice startup failures
<sivang> ogra: hmm, then maybe I should say good night to myself :)
<WW> Does anyone know what the story is with the recent kernel upgrade and linux-restricted-modules?
<mdz> WW: there is no story as far as I am aware
<sivang> damn this not willing to unpatch libtool..>:-<
<WW> mdz: Hmm...  When I try to upgrade in Synaptic, it refused to install linux-restricted-modules-2.6-686 and linux-restricted-modules-2.6-686-smp. I currently have linux-restricted-modules-2.6.8.1-4-686 and linux-restricted-modules-2.6.8.1-686-smp installed.
<WW> When I tried to reboot after the upgrade, gdm would not start.
<WW> ..."no screens"
<WW> See also: http://ubuntuforums.org/showthread.php?t=15563
<WW> ...and http://ubuntuforums.org/showthread.php?t=15541
<tseng> WW: see #ubuntu with that nature of stuff
<ogra> WW: sad that people are discussing it, agree that its a bug, but nobody seems to have filed it....
<WW> tseng: Yes, I know this isn't exactly the right place... on the other hand, it appears to be broken kernel upgrade.  That's pretty serious stuff, and I haven't heard about any forthcoming fixes.  mdz apparently didn't even know about it.
<tseng> oh man, if mdz doesnt know it must be end of the world!
<tseng> heh.
<WW> :)
<jdub> mdz: ahr, esd sample caching problems.
<WW> Sorry, one more post: https://bugzilla.ubuntu.com/show_bug.cgi?id=6617
<daniels> l-r-m needs an update
<mdz> it was updated
<mdz> but it failed to build
<mdz> the headers weren't available yet
<daniels> hooray!
<mdz> it should only need a retry
<daniels> ah
<mdz> but I don't know of anyone who can do that besides lamont and elmo
<mdz> lamont is not here today, and elmo is likely asleep
<jdub> oh man
<jdub> no esd sample caching problems
<jdub> it has a problem with the file size it seems (affects native and esd interfaces)
<sivang> hmm, what's the adm group for? (related to raid stuff?)
<maswan> daniels: sorry for bothering you in here, but I'm curious, does the x300 se pcie card work well with current x, or is it work in progress? I just saw that you got one, not how it turned out from your blog entry (pretty much what what's easily found by google too).
<daniels> maswan: 2d works out of the box, never tried fglrx
<maswan> daniels: ah, great. thinking of getting a new box, and these pcie mbs seem neat. :)
* maswan doesn't care about 3d either, so.. :)
<daniels> well, i care about 3d, just not with this card
* maswan nods
<daniels> this card was just the cheapest way to get 1600x1200, plus DVI and dual-head
* maswan nods
<maswan> Well, I might eventually some day have need of 3d, but that day...
<daniels> maswan, halflife2.  halflife2, maswan.
* daniels bought it months ago, but is waiting until his shiny new card arrives to install it.
<maswan> Isn't that one of those first person thingies? I've never gotten along with those.
<mjg59> daniels: Are you going to play it on a nasty closed-source OS?
<daniels> mjg59: as opposed to a nasty closed-source hostile fork of an emulation of a nasty-closed-source OS?  probably, yeah.
<tseng> daniels: good one.
<jba> hehe
<jba> got him yes, goooonee!!!
<daniels> 'right off the mea ... er, right off the vegetable of the bat'
<jba> what's wrong with the meat of the bat?
<jba> you gotta eat lamb I tell you !!!!
* WW laughs and says to himself, "So this is what they *really* talk about over in ubunt-devel."
<mjg59> WW: You should see a typical conversaion in debian-devel...
<daniels> jba: not me, I've got a tongue piercing ;)
<mjg59> (Actuallym you really shouldn't)
<zul> mjg59, gentoo-dev is worse :) well not really
<jba> daniels, no piercings here. so it's all meat for me
<jba> what do you think about 20-20's ?
<daniels> and this is where I fail to understand, but I suspect we're desperately off-topic anyway
<jba> new 20 over matches
<jba> shorter one dayers, as far as I'm concerned the shorter a game of cricket is, the better :)
<daniels> oh, twenty20
* daniels shrugs.
<mjg59> daniels: So, any cool stuff come out of xdevconf?
<daniels> mjg59: tentative but awesome moves on the release manager front (i'm standing aside), hopefully getting shared administration for gnome/kde/fd.o, possibly combining all the translation efforts from gnome and kde under fd.o
<daniels> mjg59: a definite move towards modularisation and a plan on how to get there; process for x11r7 beginning
<daniels> i'm sure there was other stuff, but i've forgotten
<mjg59> Rocking
<mjg59> Any discussion on the shift to mesa-based rendering?
<mjg59> (Or if that's even been decided as the way forward now)
<daniels> it's basically been deferred until mesa-solo is finished, which is chugging along nicely
<daniels> mesa has been undergoing some serious renovations lately
<mjg59> Cool
<dholbach> guys... i'm off to bed
<dholbach> sleep tight everyone
<mjg59> What's the situation in terms of hardware that doesn't have a 3D engine?
<daniels> dholbach: g'night
<dholbach> bye daniels
<daniels> mjg59: so the way forward in terms of xgl is undecided; either you could use mesa's software renderer, or have xgl as just another output driver, so you can still use standard 2d acceleration
<daniels> mjg59: whether xgl will be It or not is uncertain (right now, kdrive isn't near usable, and probably will never be), but yeah, several have stated that we cannot and will not deprecate support for non-3D cards
<mjg59> Is there any way to provide 2D acceleration through Mesa?
<mjg59> Hmm. I guess it's difficult to expose stuff like Xvideo through that.
<daniels> well, obviously there's mesa's software renderer, but i don't know how effectively you can accelerate it when you need to be converting 3d primitives into 2d primitives
<mjg59> Mm. It's a bit of an awkward bugger.
<daniels> aye
<daniels> so some of us are wondering if we wouldn't be better off writing a drivers/gl for the current xorg infrastructure
<mjg59> Yeah
<mjg59> Then default to that on hardware that has decent Mesa support?
<daniels> or something, yeah
<dholbach> *wave*
<daniels> no-one's really clear at the moment, because we have staggeringly more important things to do (modulaisation), and the gl stuff is blocking on mesa-solo
<mjg59> My only concern with the mesa-solo stuff is that Jon Smirl seems convinced that it's possible to POST all video hardware
<ogra> night dholbach
<daniels> bleh.  modularisation.  m12n.
<daniels> mjg59: it's ok, there are some incredibly talented (and sane) people on mesa as well
<daniels> mjg59: anholt and ajax understand the realities of modern-day hardware, and they've been doing a *lot* of good things
<daniels> mjg59: jon's great, but he exists in a world where everyone has these amazing flawless video cards that do stupid fast 3D, and there are no BIOS flaws ever
<daniels> so he does a lot of good things, but needs a good grounding in reality every now and then
<mjg59> Haha
<mjg59> Xgl is very, very cool though
<sladen> and so much cooler than Cairo
<jdub> ahr, no seb
<jdub> Unable to open desktop file /usr/share/mozilla-firefox.desktop for panel launcher: Error reading file '/usr/share/mozilla-firefox.desktop': File not found
<jdub> Unable to open desktop file /usr/share/evolution-2.2.desktop for panel launcher: Error reading file '/usr/share/evolution-2.2.desktop': File not found
<jdub> Unable to open desktop file @DATADIR/yelp.desktop for panel launcher: Error reading file '@DATADIR/yelp.desktop': Invalid URI
<jdub> 
<jdub> sladen: it's completely different to cairo, and not cooler
<jdub> mdz: was it you that mentioned the panel icons missing?
* jdub files
<daniels> cairo is rad also
<jdub> heh
<jdub> um
<jdub> daniels: is d-bus 0.23.1 love?
<daniels> 0.23.1?
<daniels> i think i may have missed something
<jdub> perhaps beagle is asking for > d-bus 0.23 ;)
<daniels> jdub: ahr, yeah, it is love; the update should be fairly trivial if you want  to do it
<jdub> daniels: including dbus-cil?
<daniels> jdub: apt-get source dbus-mono, hand-apply all the changes to the *.cs files
<daniels> i can probably do it tonight, since i'll be away from my ghetto development system
<jdub> not a massive priority at all
<jdub> unless there are fixes in it we need
<jdub> just noticed new beagle needs it
<daniels> 'kay
<daniels> well, looking at it, it seems that 0.23 is broken to shit
<daniels> i might prepare new packages on the plane
<daniels> otoh, i might not :)
<jdub> gar
<zul> heh
<jdub> man, this polypaudio sample stuff is cheesing me off
<helix> gah, I caught usual's message again
<mjg59> helix: Caught?
<Clint> she's psychic
<helix> mjg59: every time I look in this channel I seem to see that stupid quit message
<mjg59> Haha
<mjg59> Your life is miserable
<helix> talk to me about ACPI, make it WORSE
* jba would love to know if there is some sort of gui to configure acpi in ubuntu
<helix> jba: mjg59 can be bribed
<jdub> argh
* sivang goes to bad/bed crying, after gtk_widget_hide/show worked on previous patch attempts and now it just WON'T! argh
<sivang> shutting down, night all
<mjg59> helix: So, have I told you what ACPI stands for?
<jba> wast
<helix> does this mean I get to make an educated guess?
<sivang> helix: btw, I also see this rather bothering message, guess there is no rule yet against logout messages
<jba> was trying to explain to my wife why acpi wasn't working untill i had support for a custom dsdt, and she just told me to s h u t up
<helix> mjg59: argh christing puce idiocy?
* sivang --> hibernate mode.
<jdub> jba: drop a compiled dsdt aml into /etc/mkinitrd/DSDT
<helix> that's my guess about acpi
<jba> jdub, i know dude, you already explained it to me 2 weeks ago, remember we have the smae machine
<jba> i was just trying to exlpain that to my wife
<jdub> oh yeah
<jba> hehe
<mjg59> helix: Somethng like that
<jba> it was basially an exercise in tediosity, cause she didn't really care in the first place
<Mithrandir> mdz: pong; but can you drop me an email rather?
<helix> jba: why did you try to explain it then?
<Mithrandir> hiya helix
<helix> hey
<mjg59> Right. Sleep.
<jba> i don't know, I've been married for 18months now and would like for her to at least appreciate what it is about OSS that makes me want to come home from work and turn on yet another computer
<helix> jba: acpi is not the way, trust me
<helix> :)
<jba> hehe
<Mithrandir> mjg59: bah, and you're one timezone behind.
<mjg59> helix: If you had a laptop, you'd love ACPI
<mjg59> Mithrandir: I've a meeting in 7 hours
<helix> mjg59: I'd love you too
<Mithrandir> mjg59: I'm supposed to meet my supervisor in six.
* jba doesn't sleep these days, new born baby sleep deprivation
<mjg59> helix: You're far too easily bought
<helix> mjg59: well, most people get loved for free..
<helix> it's that you're exceptionally unworthy
<mjg59> You're such an ACPI hater
<jba> aint nothing wrong with being loved for money
<Mithrandir> most people with laptops'd love mjg59 
<mjg59> My ACPI skills get me all the women
<Mithrandir> helix: bah, mjg59++
<mjg59> (Possible lie)
<helix> Mithrandir: he's misunderstanding me on purpose
<helix> I said *explaining* ACPI to jba's wife is not the way to get her to love free software
<daniels> mjg59: no, they do, but you just don't pay attention when they declare their interest in you
<daniels> mjg59: that girl at the pub totally knew you were the acpi mastah
<Mithrandir> helix: he's a man, what do you expect?
<mjg59> daniels: Shame I never saw her
<helix> Mithrandir: I expect for him to misunderstand me so I can emasculate him
<mjg59> I've been back to that pub twice since then
<mjg59> helix: Why do you wish to emasculate me?
<helix> I thought that's what you wanted?
<Mithrandir> daniels: I'm a bit scared of coming to .au, considering that ThongMaster has threatened to drown me in beers.  (Because I fixed evo on amd64)
<mjg59> Since when?
<helix> you're the masochist screwing around with ACPI, this is a perfectly logical conclusion
<daniels> Mithrandir: 'TongMaster'
<Mithrandir> daniels: sorry; same difference; I'm fairly drunk. :P
<HrdwrBoB> helix: haha my fiance nods and smiles
<HrdwrBoB> so I got to explain things
<thully> mjg59: any progress on T42 suspend?
<mjg59> thully: Nope
<mjg59> There are weird kernel issues to deal with. I might have some more information after FOSDEM.
<helix> I think the men I meet tend to explain all the wrong portions of free software to their non-tech wives and girlfriends
<Mithrandir> helix: they should just get techie wives and gfs.
<helix> Mithrandir: ...where?
<mjg59> helix: Pff. My desire for ACPI to hurt me doesn't mean that I never want to be able to screw around in future
<Mithrandir> helix: I found both my current and my previous in this place at university called "The Software Workshop".
<helix> I don't want details, matthew
<helix> Mithrandir: ah, ok. not all people are at university though.
<Mithrandir> helix: they should be.  No human is complete without some university education.  IMO, at least
<helix> Mithrandir: what if they're out of school?
<helix> there are single people over 24 :)
<Mithrandir> helix: never too late to be a student.  And I'm sure LUGs and such would work.  Or something.  But again, don't listen to me, I'm a bit intoxicated.
<helix> Mithrandir: well, maybe norway is different
<mjg59> helix: You don't want details because you'd prefer to have your own version of reality?
<helix> Mithrandir: none of those are heavily populated with females here. and going back to school to find a wife is silly :)
<helix> mjg59: maybe
<Mithrandir> helix: possibly, I haven't studied elsewhere.
<mjg59> helix: Haha
<daniels> (wildly offtopic)
<helix> right, back to my hole. sorry channel :)
<jba> guys i don't know how it is every where else in the world, but here in .au not many good looking (or even any regular) women hang around engineering campuses
<mjg59> Now, really, sleep
<jba> infact, at UTS, where i studied, i would go so far as to say none
<jba> the engineering faculty was all men
<Mithrandir> jba: you're in the wrong continent.
<jba> or the right continent, depending on how you look at it
<jba> .au is the "ass end of the world" after all
<jbailey> mdz: Just got back from my class.  What's up?
<jdub> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
<jdub> yay!
<mdz> jdub: hah, it's obsolete before we even got around to using it
* mdz crosses a feature off the apt todo list
<jdub> :-)
<jdub> mdz: finding lots of nice sample caching related bugs
<mdz> jdub: which apps use sample caching?
<jdub> mdz: gnome sounds
<jdub> mdz: this is basically the background for the startup/shutdown sound problems
<jdub> mdz: if you play cached samples in a 1s loop, they're reliable (apart from the first few)
<jdub> mdz: if you play them in a 5s loop, you hear nothing :)
<jbailey> Where do we announce our security updates?  I had missed the awstats update from a couple days ago, and it was kindly pointed out to me by an end user. =(
<mdz> jbailey: ubuntu-security-announce
<mdz> and also UT
<jbailey> Cool.  I had missed that list.  Thanks! =)
<jdub> hrm
<jdub> my desktop's clock goes out of sync pretty quickly
<jba> bad crystal?
<jdub> proprietary crystal, probably (stupid nvidia...)
<jdub> ;-)
<jdub> mdz: there?
<mdz> jdub: yes
<jdub> mdz: cliff's machine is stuck in dvorak
<mdz> jdub: have him reboot it; the default layout is us
<jdub> ok
<mdz> I must have forgotten to change it back when I was over there last
<mdz> next time I guess I should learn how to use the multi-layout magic in gnome
<jbailey> mdz: Keyboard layout stuff is really easy.  You can set a keyboard sequence to reset or have an applet to click on.  I set af riends' keyboard for English/Russian last weekend.  I was really surprised.
<mdz> jbailey: the last time I tried it, I got a different layout when using the dvorak mode of a switchable layout, than when using plain dvorak
<jbailey> Oh nasty.
<jbailey> "No! No!  The *other* dvorak!"
<jdub> i have heard of some dvorak related bugs during 2.9
<mdz> the problem is that dvorak isn't a complete layout; it's just an arrangement of the alpha/punctuation keys
<mdz> the layout I actually have is us(pc104)+dvorak(basic)
<mdz> but GNOME doesn't let me say that
<jbailey> Bed time.  See y'all in 7.5 hours.
<sulkd> hi
<jdub> mdz: hrm, what crazy crack did you set up for cliff?
<mdz> jdub: diversions + symlinks
<jdub> that makes it very hard for me to understand what's going on :|
<mdz> in hindsight I would have copied the stuff into `/.themes, ~/.icons and crap if I had known about them
<jdub> why so complicated? all this stuff can be done in the home directory
<mdz> if you can walk him through that easily, go for it
<jdub> aha
<mdz> if not, seems like a waste of time since what he has, works
<mdz> unless he needs to add new files, I suppose
<jdub> that's the thing
<jdub> he'll be regularly updating stuff
<mdz> ask him if he found the password to his router
<mdz> I wanted to set it up so I could ssh in and fix stuff
<jba> autolunching gthumb when connecting a digital camera to usb is a great idea
<jba> but it doesn't leave you with a "Camera" icon on the desktop to eject
<jdub> mdz: nup
<jba> and if you manual umount it, you hang ubuntu completely
<dilinger> jba: i haven't actually seen it work right yet
<mdz> the next time I go over there I'll try to recover the password
<jba> dilinger, works great, just have to get use to simply unplugging the cable without umounting
<jdub> jba: i would regard the lack of icon when doing gthumb/camera stuff as a bug
<jdub> jba: if it's not filed already, please file it
<jba> jdub sure thing
<mdz> the hang is just inotify sucking
<mdz> jdub: what are the odds of inotify getting un-fucked for hoary?
<mdz> I thought that thing was totally on track to go upstream, and it has turned out to be in terrible shape
<jba> jdub, is that just not mounting it with a user (or something) attribute ?
<jba> bugzilla.ubunutu.com not having valid certificate
<jdub> mdz: relatively good, considering that rml is paying attention
<jdub> mdz: though switching aroudn kernel maintainers has not been so good for it
<jba> jdub, this is part of the bug: https://bugzilla.ubuntu.com/show_bug.cgi?id=2741
<jdub> jba: different issue
<jba> just realized, it was warty related so yeah, it's diff
<jba> jdub, this is my freezing bug. I also have a olympus (micro300) https://bugzilla.ubuntu.com/show_bug.cgi?id=6317
<jba> the actual error is if you umount while gphoto is still running
<jba> or unplug while it's still running
<jba> wow that bug is duplicated all over the place
* ajmitch returns, after some silly person cut the string connecting dunedin to the world
<sulkd> anyone want to sneer at a patch and tell me how much it sucks right before I send a mail ?
<fabbione> morning
<jdub> jba: inotify prob
<lamont> moof
<sulkd> oh well.. I'll just mail then..
* lamont sleeps
<fabbione> night lamont
<lamont> night fabbione - I'll probably poke you when I awake to see where 2.6.10 is at
<fabbione> there is also a little bug, on exit the daemon should clean .esd/
<fabbione> ops
<fabbione> lamont: -19 is the last one i uploaded yesterday
<lamont> ok
* lamont really sleeps
* sulkd makes lamont call sched_yield()
<sulkd> is anyone else having problem with Gnome's input widgets lately? like when I'm in Epiphany and I'm googling for something, and then click in the input box and want to seek by pressing the right arrow and it either jumps over each word or straight to the end
<da_bon_bon> why doesnt hoary update to OOo 1.1.4 ?
<da_bon_bon> or better still, 2.0 ?
<crimsun_> well, 2.0's not out yet; 1.9 is there.
<da_bon_bon> 2.0 devel = 1.9 ?
<crimsun_> apt-cache policy openoffice.org2
<crimsun_> our OOo maintainer is extremely busy
<da_bon_bon> crimsun_: thanks. u a developer too ?
<crimsun_> not for ubuntu or canonical, no
<da_bon_bon> ok..
<da_bon_bon> and kernel maintainers are doing a gr8 job - updates twice a day
<crimsun_> there were rather critical bugfixes in them
<da_bon_bon> right - .17 hanged so often...
<da_bon_bon> and anyway, do u use OOo 1.9 ? is it stable enough ?
<crimsun_> I use OOo on Warty, actually
<da_bon_bon> crimsun_: oh, no hoary ?
<crimsun_> the few times I've used OOo on Hoary have been fine.
<crimsun_> let's take this back to u
<crimsun_> (#u)
<da_bon_bon> ok.
<Gagatan> Simira :)
<Simira> morn :) Up already?
<Simira> there's another. Mornin HcE.
<HcE> Simira: =) had a little "case" with autofs upgrade
<Simira> I noticed
<Simira> well, have to go. Back in 30 mins.
<dholbach> hai
<sulkd> konnichiwa
<dholbach> hellas mvo_!
<mvo_> hi dholbach 
<mvo_> morning all
<pitti> Hi everybody
<dholbach> hi pitti!
<fabbione> hey pitti
<low> mornin'
<low> Kamion: around ?
<d3vic3> doko, ping 
<doko> d3vic3: here
<pitti> amu: ping
* mvo__ is runing on modem now to reproduce #6575
<mvo__> slow, _so_ slow
<Keybuk> aww, poor thing
<mvo__> yeah, pity me :)
<Keybuk> hmm, nah
<sid77> hi
<low> anyone working on isos ?
<Keybuk> so we've changed the name of the Jeff menu again?
<jdub> Keybuk: upstream chose a different name, so after ui freeze, we changed it to what we decided originally
<Treenaks> The Jeff Menu?
<Keybuk> Treenaks: the third menu, one day we're going to wake up to see "Applications  Places  Jeff"
<Treenaks> Keybuk: ah.. *shudder*
<Keybuk> which would actually be good, jdub will click Jeff and be able to configure his identity and preferences, switch between other logged in users, see friends online is his contact list, etc.
<jdub> Keybuk: i've been talking to jimbob about that
<jdub> Keybuk: not sure i'm fully behind it yet
<Kamion> low: yo
<Kamion> mvo_: FYI, I've removed empty Packages files from the live CD
<mvo_> Kamion: great! thanks a lot
<low> Kamion: ok. tested 4th iso from yesterday. improvements: i can now access to choice of partitions etc when configuring raid0/1/5
<low> Kamion: bugs: /dev/md* are not created, modules are loaded
<low> just dled today's iso. any idea if it has been fixed ?
<Kamion> low: I fixed a load of that kind of stuff yesterday
<Kamion> mdrun should now actually look in /dev/md/ properly
<low> Kamion: ok, today's iso is burning, will test very soon
<Kamion> and create devices there
<low> Kamion: btw, /dev/md/ doesn't even exists
<low> brb, testing :)
<Kamion> low: yes, I know, I fixed that too :)
<low> Kamion: sweet, so it /should/ work now :-)
<low> ha, burning is finished, really off for a couple minutes now
<svenl> hi all.
<ajmitch> hi svenl 
<svenl> Mmm, so who should i ask for unbreaking my wiki logon ? Either i already registered with my @debian.org address some time back and forgot the password, which could have happened, or something is fishy.
<svenl> Didn't see any remember password thingy though.
<low> YAY ! thx Kamion ! i've been able to create a raid0 array, raid 1 and 5. now waiting for disk partionning tool to launch. it's hard really long
<low> s/hard/
<Treenaks> low: that sounded like copy/paste from some spame :P
<Treenaks> spam
<low> lol Treenaks 
<low> hmmm examining disks phase seems to be stuck, no hd access, 41% waiting and waiting
<sladen> jdub: I know the difference xgl vis. Xr...
<low> Kamion: ok i know why it's stuck. "ataX: command 0x25 timeout, stat 0x50 host_stat 0x64 " and s/0x64/0x4
<Kamion> not my fault then :)
<low> Kaloz: another msg is "program parted_devices is using a deprecated SCSI ioctl, please convert it to SG_IO"
<low> Kamion: agreed, not yours :)
<dholbach> i'm out with my dog - bbl
<low> gah, i've been xchat completion hit again
<low> so Kamion: another msg is "program parted_devices is using a deprecated SCSI ioctl, please convert it to SG_IO" (bis:)
<low> least important imho (until this ioctl is really cut off sources:)
<Kamion> just a warning, and the actual problem is somewhere deep inside parted
<low> Kamion: i'm a bit afraid it come from libata/sata modules
<low> it may comes
<low> Kamion: would it be a real pain for you to build an iso with 2.6.11-rc4 ?
<Mithrandir> elmo: please sync mini-dinstall
<low> (or too time consuming or something)
<pitti> elmo: toolchain-source sync, please
<Kamion> low: yes
<Kamion> (a real pain)
<Kamion> I'm trying to get array cd 5 out today, and I don't have 2.6.11-rcwhatever convenient in .deb and .udeb form
<low> ok, hmmmm i'll try disabling acpi and all then, to see if that can solve the problem
<pitti> AAARGH
<pitti> http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
<Mithrandir> pitti: AAAAAARG indeed
<low> oh sh*t
<low> no more md5, no more sha1...
<pitti> indeed, yes
<pitti> we need a HASH
<low> gpg keys like the ones given with linux sources ?
<low> bbl, testing and tesing
<Mithrandir> pitti: sha256, sha512
<low> s/tesing/testing
<low> hmmm i should put off my winter gloves ;)
<low> C ya
* haggai settles down to wait for the buildds to think of new reasons to reject OOo2 on every architecture
<low> hmmm silly question, what does the skullhead means in partitionning menu ? i've put ext2 on a raid0 volume, for /boot
<low> Kamion: looks loke noapic nolapic solves the problem
<low> raid1, not raid0, sorry
<dholbach> re
<Kamion> low: cool
<Kamion> low: the skull means "pay attention, this partition was formatted and is being reformatted"; see the "Help on partitioning" text
<dholbach> hai seb128
<dholbach> seb128: would you mind, if i'd upload a just-rebuilt gdeskcal (to get python-transition further)
<low> Kamion: ok thx
<seb128> dholbach: not at all
<dholbach> seb128: nice
<pitti> Kamion: is there any reason why lesstif-dev is in the supported seed?
<pitti> lesstif1 is a mess, and it's abandoned upstream
<Kamion> pitti: general policy of supporting -dev and -doc of stuff we use, except that we don't actually appear to use lesstif1 otherwise
<pitti> Kamion: we use lesstif2/lesstif2-dev for xpdf, that's okay
<Kamion> erm, the same source package ships both lesstif-dev and lesstif2-dev
<pitti> Kamion: but lesstif1 is vulnerable against three old CANs which aren't fixed in Debian and upstream does not support it any more
<Kamion> I have no problem with removing it
<pitti> Kamion: the problem is that a 2000 line patch had to be manually applied to a totally mangled source
<pitti> Kamion: hrm, s/had/has/ (for Warty)
<Kamion> sure, I understand
<pitti> this is a giant job and not really appropriate for a safe security update, but somehow I need to fix that
<pitti> but at least I'd like to put and end to this madness at Warty
<Kamion> it probably has to stay supported in warty now that it's there
<Kamion> but we can kill it from hoary
<pitti> yes, that's what I'm aiming at
<Kamion> removing
<pitti> shall I update the seeds or are you alraedy at it?
<Kamion> I'm doing it
<pitti> okay, thanks
<Kamion> committed
<pitti> Kamion: I'd like to defer the lesstif1 upgrade a bit until Debian and we found/reviewed a proper patch?
<pitti> so I only fix lesstif2 for now
<Kamion> sounds reasonable; as I say, though, they're in the same source package
<pitti> yes, I know
<Kamion> lesstif1 has no rdepends other than lesstif-dev in warty either
<pitti> that's the problem, we have to do a totally messy update although no app really uses it :-(
<low> Kamion: grub doesn't boot correctly on raid1 arrays ? :(
<low> btw, the magic trinity is noapic nolapic noacpi so everything works ok
<Kamion> low: arse, I thought that'd been fixed. should just be a matter of editing its 'root' command though?
<low> Kamion: ok i'll try it after lunch. hope it didn't install it on /, only /boot is raid1
<low>  / is raid5
<low> bbl
<Treenaks> we need RAID5 capable grub ;)
<Mithrandir> Treenaks: patches accepted.
<Mithrandir> :)
<Treenaks> Mithrandir: grrr
<Kamion> oh, damnit, no lilo on amd64
<Kamion> Mithrandir: does lilo fundamentally not work on amd64, or do we just not build it at the moment?
<Mithrandir> we just don't build it
<Kamion> Mithrandir: I need it for LVM
<Simira> :)
<Mithrandir> it might need a few patches to use -m32 where appropiate, but that should in the debian-amd64 patch directory.
<Mithrandir> hiya Simira 
<Kamion> elmo: could you PaS lilo to i386 amd64 rather than just i386, please?
<Kamion> Mithrandir: apparently not, no changes in debian-amd64
<Mithrandir> ok, guess the maintainer has accepted the patches, then. :)
<Kamion> no -m32 in the source either though
<Kamion> it's possible nobody cared
<Mithrandir> I'm test building it now
* Kamion yays for an LVM-capable installer rescue mode
<Mithrandir> Kamion: it uses bin86 and builds fine at least
<seb128> Kamion: just uploaded a new gnome-panel that should fix the icons in the default config
<Kamion> seb128: thanks!
<seb128> you're welcome :)
<dholbach> does anyone know what going wrong here?
<dholbach> cd python && xvfb-run -a python setup.py clean
<dholbach> /usr/bin/xvfb-run: line 19: 0: command not found
<dholbach> and line 19 of xvfb-run is:           XVFBARGS=-screen 0 640x480x8
<Kamion> wasn't that fixed in Debian recently?
<Kamion>   * Remove spurious quotes from variable expansions of $XVFBARGS and
<Kamion>     $LISTENTCP in xvfb-run.  Thanks to Jeff Lessem for the patch!
<Kamion>     (Closes:# 286181)
<dholbach> unfortunately not fixed on my box... which is recent hoary
<pitti> Hi Astharot 
<Astharot> hi pitti
<Astharot> I just replied to your mail :P
<pitti> Astharot: this is exactly the no-ob patch
<seb128> jdub: around ?
<Astharot> what do you mean with "no-ob" ? :P
<pitti> Astharot: it does not change anything
<low> Kamion: well, the problem is, after reboot, i get "L 99 99 99 etc"
<Astharot> depth is only incremented after the recursion and the check (depth>10) will never be true
<Kamion> low: you need either a LILO expert or a RAID expert, neither of which is me :)
<low> Kamion: to sum up, i have: /dev/sdX1, ~100MB, ext2, raid1, md0. /dev/sdX2, 400MB, swap, raid0, md1. /dev/sdX3, remaining space, xfs, raid 5, md2
<low> Kamion: hmmm it is grub right ? :)
<Kamion> "L " anything is LILO
<Kamion> perhaps you are not booting from where you think you're booting from
<low> Kamion: hmmm aybe an old install then ?
<pitti> elmo: bmv sync, please
<low> there was a mdk 10-rc on it before
<Kamion> low: you'll have to debug that locally I think
<Kamion> figure out why grub did not overwrite that bootloader
<low> Kamion: ok, i'll search for it
<low> thx again !
<pitti> elmo: f2c sync, please
<ogra> morning
<pitti> Hi ogra
<ogra> pitti: i will change the order of the patches, since mdz urges me to get the basic work of the client in....so i'll have to do the device-manager first (i need a button there)....
<pitti> ogra: why do you want to change the order then?
<pitti> ogra: well, the patches are independent, aren't they? (manager and backend)
<ogra> pitti: because i suspect that the dmi patch takes as long to get in as the other two.... device-manager is python/glade.... so the possibility of buffer overflows is less ;)
<pitti> ogra: okay
* ogra really loves the new polypaudio system beep :)
* HiddenWolf is thinking polyaudio isn't much of an improvement yet
<sivang> morning all!
<dholbach> hi sivan!
<pitti> Hi Sivan
<sivang> Hi martin, dholbach 
<ogra> moin sivang
<sivang> ogra: Moins! ;-)
<elmo> pitti/kamion: done
<pitti> thanks
<elmo> Mithrandir: ok to override ubuntu changes?
<mjg59> I am so in love with that patch to make sudo do readahead
<Mithrandir> elmo: yes
<Mithrandir> I've pondered hacking readahead a bit more and giving it an init script, possibly together with some evil kernel magic.
<elmo> pitti: btw, if you're bored and/or already talking to him, please beat some sense into the toolchain-source maintainer
<elmo> he's using .tar.gz instead of orig.tar.gz
<pitti> elmo: oh, a native package?
<elmo> yes
<elmo> and the tar ball is not small
<pitti> bah
<pitti> well, I'm not exactly bored and I did not yet talk to him, but I will open a bug report
<Mithrandir> so it'd start at the beginning and collect file names (through some /proc interface or something) and then write that list at the end of the boot.  Reuse list at next boot.
<ajmitch> pitti: what's the deal with security updates for warty universe packages? :)
<elmo> pitti: thanks
<pitti> ajmitch: send a patch to security-review@lists.ubuntu.com
<pitti> ajmitch: then I take a look at it and upload it
<pitti> ajmitch: Astharot has a lot of experience with that :-)
<ajmitch> pitti: alright, thanks
* ajmitch will get a-patching
<pitti> cool
<ajmitch> the version in hoary is ok, so I guess I'll have to grab just security fixes from there?
<pitti> sure
<pitti> or from upstream cvs, or woody security updates, or ...
<ajmitch> yeah, I've got access to cvs, no problems with that ;)
<mjg59> So, uh, what's this "suspend" option that's appeared in the logout menu?
<sladen> mjg59: can we do the opposite of XP  ---have S4 by default and show S3 if you hold down shift
<Treenaks> 
<Treenaks> hm
<mjg59> sladen: Or have a GUI to enable it
<mjg59> It'd be a trivial application to do that
<jdub> seb128: back
<jdub> good morning freedom lovers
<seb128> jdub: hey
<ajmitch> morning jeff
* jbailey pokes ajmitch 
<seb128> jdub: we really want to switch admin and preferences menus ? There is no nice way to do that atm, that's alphabetic order
<jbailey> ;P
<Mithrandir> mjg59: what's the plan wrt swsusp and swap files?
<jdub> seb128: would really like to, yes
<mjg59> Mithrandir: Unsupported
<seb128> jdub: k
<Mithrandir> mjg59: bah, boring.  We could do Magic with devmapper, I think.
<jbailey> mjg59: I still need guidance from you (or someone) and how to pick the resume partition if someone has more than one swap file.
<mjg59> There's some code floating around, but nothing doing before Hoary+1 at least
<ajmitch> jbailey: yes? ;)
<dholbach> jbailey: ajmitch is pythoneering - so don't poke him :-)
* jdub ughs at the esound package
<daniels> jdub: PHREEDOM
* dredg likes jwz's response to hula: http://www.livejournal.com/users/jwz/444651.html
<ogra> jdub: any idea about the wine stuff ? i would like to trigger a debian sync if we dont include the winehq packages nobody seens to find time to review....
<jdub> dredg: that was a conversation he had with nat *before* hula
<jdub> ogra: unfortunately, scott's packages are a significant fork away from the debian packages
<dredg> jdub: ug, indeed. rearrange my sentence so that it makes sense....
<ogra> jdub: yep, thats why i'm asking...
<jdub> ogra: sync is fine
<ogra> jdub: since even the reviewer will need deep insight in wine 
<ogra> ok
<Mithrandir> Keybuk: any thoughts on http://arch.err.no/index.cgi/tfheen@idi.ntnu.no--2005/pkgconfig--multiarch--0--patch-1 ?
<mjg59> jbailey: Pick the largest, or if they're the same pick the first
<jbailey> mjg59: Yezboss.  And should I poke that value into /sys at install time right away so that someone could suspend anytime after that?
<low> Kamion: ok, i'll wiped all hd mbr to be sure, reinstalled, now when the box boots, it's stuck with a blinking cursor, not even telling me "insert a system disk" or whatever
<Keybuk> Mithrandir: meh, pkgconfig
<low> s/i'll/i've
<mjg59> jbailey: Hrm. Best not to poke it into /sys at install time.
<Mithrandir> Keybuk: else, it'd possibly be pkg-pkg-config.
<jbailey> mjg59: Yezboss.
<mjg59> Argle. Do we know what the swap partitions are at the point that initrd-tools is installed?
<Keybuk> Mithrandir: I think I might pretend I'm not the maintainer of that
<jbailey> mjg59: I'd hope so.  The questions is can I get to that information without depending on parted? =)
<mjg59> Does the installer build a ramdisk on install?
<moquist> ogra: you pinged a while back...if you still have anything to say ATM please try a PM.
<moquist> ogra: I'm at LinuxWorld in Boston, so I can't watch IRC regularly.  :)
<mjg59> jbailey: Presumably initrd-tools will be installed in stage 1? I don't think there's any reason to support suspend at that point (and it wouldn't work anyway), so setting RESUME so that stage 2 is suspendable would probably be the best plan
<Mithrandir> Keybuk: apart from the name, any thoughts? :)
<ogra> moquist: we were reviewing the MaintainerCandidates page yesterday, and tried to separate the Member candidates form the MOTU candidates.....
<ogra> moquist: which category are you in ? 
<moquist> ogra: sorry, what's MOTU?
<ogra> moquist: universe package maintainer
<ogra> moquist: https://www.ubuntulinux.org/wiki/MOTU
<moquist> ogra: MOTU, though I don't have any package(s) (yet)
<ogra> moquist: we are currently in a speedup of the approval process until hoary is released, so if you want to participate it is the best time to get in now
<martinal> hi
<ajmitch> moquist: and you even get fame & glory thrown in for free :)
<martinal> could someone explain the sound server situation to me? it all seems so complex...
<moquist> ajmitch: heh
<martinal> i've heard of alsa, osd, esd, esound, polypaudio
<moquist> what I'm really really really interested in is education-related stuff - getting LTSP on Ubuntu, for starters
<moquist> I know that the nfs-swap problem is holding back a 2.6 LTSP kernel, which would of course be preferable to the 2.4 kernel currently in use.
<moquist> anybody interested in working with me on that?
<ogra> moquist: i think sivang expressed interest in ltsp....
<moquist> ogra: yes, sivang and I have chatted a few times; i'll ping him
<sladen> moquist: can the swap be done using network block device rather than swapfile on NFS?
<mjg59> Ok, I've got another ACPI patch that needs to go in
<moquist> sladen: I don't know...I'm not sure how much easier that would be
<martinal> why do yo uneed a networked swapfile at all?
<martinal> i thought the idea of terminal services was that everything was on one centralized server
<moquist> martinal: for thin clients with <32MB of memory, swap -- even over the network -- is better than no swap
<Treenaks> moquist: thin clients only run an X server. No swap necessary
<moquist> martinal: you don't need disks anywhere but on the central server, but the thin clients need enough memory to handle their X session
<rcaskey_> martinal: I don't know about osd but it kinda goes esd -> alsa or dummyesd -> polypaudio -> alsa I believe
<rcaskey_> so that way you can replace esd wit polypaudio and your esd apps don't b0rk
<moquist> Treenaks: I know this is necessary because I hung out at the LTSP booth at LW in Boston yesterday, and Jim McQuillen (sp?) said this is what's holding the 2.6 kernel back
<rcaskey_> mjg59: does it have a bug#?
<mjg59> rcaskey_: Nope
<moquist> Treenaks: also, this has been mentioned on the Ubuntu devel mailing list
<mjg59> rcaskey_: Well, yes - there's at least one filed bug that it'd fix
<Treenaks> moquist: it's weird..
<rcaskey_> mjg: hehe, what's it do?
<moquist> Treenaks: heh - definitely.
<zul> hey
<mjg59> rcaskey_: Fixes implicit truncation of ACPI buffers
<rcaskey_> yeah, that's not mine ;)
<moquist> apparently Jim himself has been porting the nfs-swap patch forward through the 2.4 kernels, but 2.6 changed too many things, so he's looking for help
<mjg59> zul: Hey - I've got an ACPI patch to feed you
<rcaskey_> mdz reassigned my UNKNOWN bug against acpid but the more I think about it it may be hotkeys ;)
<zul> mjg59: okies you know what to do :)
<mjg59> rcaskey_: What's the #?
<rcaskey_> let me look it up
<mjg59> zul: Address again?
<zul> mjg59: zul@gentoo.org
<ogra> zul: gah... that should be zul@ubuntu.com ;)
<zul> it should
<ogra> zul: it will be  :)
<zul> my ring of trust is quite small actually for my gpg key
<mjg59> zul: Sent
<Treenaks> zul: where in the world are you? :)
<zul> k thanks ill take a look at it tonight
<zul> Treenaks: canada
<Treenaks> zul: hm, not near here..
<zul> im close to where jbailey is
<zul> but its still like a 4 hour drive 
<Treenaks> zul: going to conferences helps :)
<rcaskey_> mjg: ahh, it got nixed. Was 6625, duplicate of 3256
<zul> Treenaks: yeah but all the conferences are in europe
<zul> or australia
<Treenaks> zul: or the US
<zul> still if one is still getting out of debt for not working for two months last year
<ajmitch> zul: or nz! :)
<Treenaks> zul: hmm.. that's bad
<zul> bah...no one goes to new zealand :)
<rcaskey_> mjg: ooh, it's even got a proposed fix
<rcaskey_> mjg: and it's proposed by...you
<ajmitch> zul: just you wait ;)
<rcaskey_> http://lists.ubuntu.com/archives/ubuntu-users/2004-November/010581.html'
<rcaskey_> (woops, nix the ending ' of course)
<Mithrandir> Keybuk: actually, it's pkgconfig since the debian package is called pkgconfig
<zul> mjg59: got it thanks ill include it the next set
<mjg59> rcaskey_: We'll have a neater solution in the default scripts for Hoary
<rcaskey_> mjg59: so it's coming post freeze?
<mjg59> zul: Rock
<mjg59> rcaskey_: Yeah, it's for support of a HoaryGoal, so we can do that sort of thing
<rcaskey_> ahh, cool
<rcaskey_> then I guess I need to get off my buttt and figure out the 2 problems that keep S3 from working then since S1 will work ;)
<mjg59> What are your problems with S3?
<mjg59> (And are you using the suspend script?)
<rcaskey_> mjg: using whatever is a dep for desktop base
<rcaskey_> but it's spewing errors about orinoco and some sort of lock
<rcaskey_> I don't have the machine in front of me
<mjg59> Oh, blah, yes
<mjg59> Irritatingly, I haven't been able to reproduce that
<sivang> pitti: so, for #6092 would you think a label with a note that the uid cannot be changed on an existing user is good?
<rcaskey_> mjg: I've got an inspiron 2650 with external dlink 802.11 adapter and your welcome to have a go at it over ssh this evening if you'd like
<ogra> elmo: please sync wine
<mjg59> rcaskey_: Hmm. By external do you mean USB or PCMCIA?
<rcaskey_> PCMCIA
<pitti> sivang: hm, just don't allow it :-)
<sivang> pitti: ah ok, then it's better, becasue I recall you told me it was somewhat a confusion for the user that tries to change the uid on the spin box and get's nothing :)
<mjg59> I've got a machine with PCMCIA and an orinoco device for testing, and I'm utterly failing to manage to get it to happen
<mjg59> Which is a pain :)
<sivang> pitti: (less patching overhead)
* mjg59 goes to get lunch
<ajmitch> night all
<Treenaks> night ajmitch 
<Keybuk> Mithrandir: no, like I say, I'm considering orphaning it
<sivang> night ajmitch 
<ogra> ajmitch: night
<seb128> elmo: here ?
* ogra applauds the MOTU team that managed to fix more then 80 python packages the last days
<Treenaks> don't forget gpsd.. it contains python bits as well
<ogra> Treenaks: did you already upload it ?
<Treenaks> no
<Treenaks> no time (at work now)
<dholbach> bbl
<elmo> seb128: ?
<elmo> ogra: done
<ogra> elmo: thanks
<daniels> e to the lmo
<seb128> elmo: just wondering if pyphany is in NEW or somewhere, I've not get any NEW mail afaik
<seb128> I've uploaded it yesterday
<seb128> jdub: speaking about polypaudio, what's going on with it in debian ? getting it in debian would get the gst-plugins for free
<elmo> seb128: it's in NEW yah, I'll process it now
<seb128> k, thanks
<jdub> seb128: the gst polyp plugin is b0rk
<seb128> k
<seb128> elmo: could you sync gazpacho and gok from incoming too ?
<elmo> seb128: ok to override ubuntu changes to gok?
<seb128> elmo: hum, I'll merge it in fact, thanks for noticing
<elmo> why do gnome packages so often check for a fortan compiler, anyways?
<daniels> elmo: because it's CUTTING-EDGE TECHNOLOGY
<daniels> the big language debate is between java, c#, and fortran
<seb128> no idea
<jdub> heh, seb128 
<jdub> * python/tests/level.py: reproduced the damn "Desktop doesn't refresh"
<jdub> bug
<jdub> * server/gam_poll.c: fix fo the bug
<jdub> ^ latest gamin checkin :)
<daniels> ez gtk boog
<pitti> very verbose...
<daniels> i like 'fix fo the bug'
<daniels> it be representin'
<sivang> daniels: heheh
<jdub> i have observed
<jdub> that angry frenchmen don't tend to use a lot of words
<daniels> dv?
<jdub> uh huh
<seb128> jdub: I don't get this Desktop refresh bug here, but I'll close the upstream bugs on nautilus, thanks :)
<jdub> seb128: seemed ok with inotify, hey?
<jdub> seb128: i'm not too happy that the two backends duplicate so much
<seb128> yeah, me neither
<Mithrandir> Keybuk: upstream or just the Debian package?
<Sysace> hey guys.. somebody in #ubuntu suggested I check here.. need ppc support.. here's the story:  I've completed the first stage of the install, when asked to reboot, I get yaboot, choose gnu/linux, choose Linux (Linux/old are the options), then i get error:  /pci@80000000/pci-bridge@d/pci-ata@1/@0/disk@0:11,\\linux:  No such file or directory
<Keybuk> Mithrandir: both, simultaneously
<Mithrandir> Keybuk: I could pick it up
<Mithrandir> if you want to give it to me
<Mithrandir> it seems to be a fairly simple package.
<daniels> Mithrandir: i'm not sure i trust you enough to give you an fd.o account
<Mithrandir> daniels: :P
<Sysace> nobody?
<Mithrandir> Sysace: it
<sivang> pitti: Martin, closing #6092 and half of #1849 ==> http://muse.19inch.net/~sivan/g-s-t/
<Mithrandir> Sysace: it's an #ubuntu question, not related to development, or?
<sivang> pitti: (the other half of #1849 is in system-tools-backends, working on it now)
<Sysace> Mithrandir:  ppl in #ubuntu suggested I check here.. nobody there could help...
<Mithrandir> Sysace: hm, ok.  I'm not a ppc guy, so I can't really help you, tho
<zul> svenl: ping can you try to help out sysace you are a ppc guy
<jdub> daniels: er, bandwidth hogging for a bit; just updating ppc and i386 install/live images
<jdub> daniels: let me know if it's hurting and i can kill it
<Keybuk> Mithrandir: do you want it upstream as well? :p
<Keybuk> it means dealing with freedesktop.org :p
<daniels> jdub: nah, 'sfine
<Mithrandir> Keybuk: apart from the occasional breakin, is that a problem? ;)
<thom> Keybuk: giving away pkgconfig?
<daniels> Keybuk: well, very soon you won't have to be dealing with me, so sweet deal
<Keybuk> daniels: you're leaving fd.o?  how comes?
<Keybuk> thom: I just don't have time for it
<Sysace> I guess nobody here that can offer any ppc help huh?  Well thanks anyways.. maybe I'll check back l8r..
<Mithrandir> Keybuk: seriously though, is fd.o a pain in any way?
* thom giggles at pitti : "Grumpy^W Bbb..., Bbbenn..., Hoary+1 "
<svenl> zul: ok.
<svenl> Sysace: what is your problem ? 
<daniels> Keybuk: already given release manager away, working on giving admin away; i'd just much rather be spending the limited time i have there hacking on modular x, rather than adding accounts and changing permissions
<pitti> thom: I want Grumpy Groundhog back! Poor Grumpy...
<daniels> Keybuk: plus, i'm terrible at being fd.o rm
<Sysace> svenl: here's the story:  I've completed the first stage of the install, when asked to reboot, I get yaboot, choose gnu/linux, choose Linux (Linux/old are the options), then i get error:  /pci@80000000/pci-bridge@d/pci-ata@1/@0/disk@0:11,\\linux:  No such file or directory
<thom> pitti: yeah, me too
<Keybuk> Mithrandir: not especially, no
<daniels> Mithrandir: not at all, we just leave you alone
<daniels> you need stuff, email sitewranglers@, someone will do it
<svenl> Sysace: Mmm.
<Keybuk> thom: I'm also _seriously_ considering orphanining Libtool
<Mithrandir> daniels: sounds good to me.
<svenl> Sysace: i need a bit more background info.
<daniels> right now, that's 'me', hopefully in the future that will be 'not me'
<daniels> Keybuk: !
<Mithrandir> Keybuk: sure, I'll take it upstream as well.
<svenl> Sysace: what hardware do you have ? and what are you installing ? 
<Mithrandir> Keybuk: (no, not libtool, pkg-config only :)
<Keybuk> aaww
<Keybuk> daniels: well, probably RFA to make sure someone sane takes it over
<Sysace> svenl:  it's a b/w g3, 1 hd.. osx dual-booting.. boot partion is 11, / is 12 and swap on 13.  Any other specific info, please ask away
<svenl> zul: BTW, what is the right way to get the wiki stuff sorted out ? I hear i have to ask sm about this, any idea on when he shows up.
<daniels> Mithrandir: email sitewranglers@l.fd.o your gpg key, ssh key, username, real name, email address, say that you'd like to be added to pkgconfig and that both myself and scott have oked it
<zul> sm?
<zul> svenl: sm?
<svenl> Sysace: i am no yaboot expert, but i feel something is wrong here.
<Treenaks> daniels: mother's maiden name, social security number?
<svenl> zul: well, whoever i have to ask for wiki related things.
<zul> svenl: dont know probably one of the doc team members
<ogra> Treenaks: shoe size
<mjg59> thom: What's the suspend option in the logout menu doing currently?
<Treenaks> ogra: no, that's too obvious
<Sysace> svenl:  yup.. something definately wrong.. lol.. just wish I knew hat
<svenl> zul: in particular, when i try to register, it tells me that the email address is already used, but i cannot get the password it used, and there is no email link on the page to ask.
<zul> svenl: i dont know ask one of the docs people
<daniels> Treenaks: if he wants to give them to me, sure
<daniels> Treenaks: (bearing in mind that sitewranglers has a public archive)
<svenl> Sysace: can you reboot into the installer and look at installed system ? 
<svenl> zul: ok.
* svenl wonders who the docs people are, probably listed on the web page or something.
<svenl> Sysace: let me boot the ibook.
<Sysace> svenl:  partition table's u mean?
<zul> svenl: are you can try #ubuntu-docs
<thom> mjg59: /usr/sbin/pmi action suspend
<svenl> zul: oh, cool.
<zul> svenl: you might want to try messaging sysace so you dont flood the channel
<svenl> Sysace: now, i want to know both : 1) how does the partition table look, preferably if you can get the ...
<svenl> Sysace: let's go talk alone in our corner.
<thom> mjg59: which runs /etc/acpi/sleep.sh on acpi machines, and does pbbuttonsd magic on ppc
<Mithrandir> daniels: done.
<daniels> Mithrandir: word
<mjg59> thom: Rock
<mjg59> How about hibernation?
<thom> `pmi action hibernate` does the right thing; 
<thom> pmi capabilities to query what's available
<mjg59> Excellent
<mjg59> So, do we want some sort of interface to enable/disable sleep?
<Mithrandir> thom: what package is pmi in?
<mjg59> I still tend towards enabling suspend by default, but not enabling sleep
<mjg59> s/suspend/hibernate/
<ogra> Mithrandir: power-management-interface
<thom> mjg59: i think we do (want an interface to do it); and yes, agree with hib, no susp
<mjg59> I don't think we can support S3 on AMD64 yet, either
<mjg59> thom: Ok. Should we try to integrate this into an existing app?
<Mithrandir> ogra: hmm.  Not in Hoary?
<thom> mjg59: i suppose a new g-s-t frontend/backend would be reasonable? (note that on ppc AIUI it's pretty much boolean - either you get working suspend or you get working hibernate)
<thom> Mithrandir: universe for now
<mjg59> thom: I don't think we have ppc hibernate patches in our kernel, do we?
<daniels> hm, g-s-t
<mjg59> And I wasn't sure if we had sleep patches for newer machines
<daniels> that's something i totally forgot about for fd.o
<thom> mjg59: hrm, did they get ripped out? elmo certainly has hibernate love
<mjg59> Oh, they're in? Are you sure he wasn't building his own kernel?
<thom> dunno
<mjg59> thom: g-s-t makes sense, but I'm not keen on building an entire new app just for two tickyboxes
<thom> mjg59: i don't know where else it fits
<elmo> the patch doesn't apply for 2.6.10 :(
<mjg59> Let me take a look at what we have...
<mjg59> elmo: Yeah, that's what I thought
<thom> that answers that one
<mjg59> We should harass benh for sleep love, at least
<elmo> we need to beg/bribe BenH to update if hoary is going to have any ppc hibernate love
<daniels> benh is still on semi-holiday mode, iirc
<svenl> hi elmo 
<daniels> he's not been doing much radeon stuff
<mjg59> thom: Do we ship boot-admin?
<thom> not that i'm aware of
<zul> there was a radeon patch in linus' bk yesterday
<thom> mjg59: it looks disabled
<mjg59> thom: Mm. Yeah, ok, it doesn't look like it's going to fit into any of the shipped ones
<mjg59> So it'll have to be a new one. Sigh. Can you think of anything else we should put in there while we're at it? :)
<thom> mjg59: locking of screen
<mjg59> Oh, yes
<mjg59> We also need to fix that so it actually works
<thom> yeah
<mjg59> So this is going to be three ticky boxes on 386, and two on amd64 and ppc
<thom> yep
<svenl> Mmm, anyone has ubuntu running on a powermac and can tell me if the yaboot.conf stuff got moved somewhere ? 
<sivang> pitti: ah network lost again?
<pitti> sivang: no, this time I just logged out/in for some test
<sivang> pitti: ah ok, did you get my last message?
<mjg59> thom: Any g-s-t hacking experience?
<svenl> zul: well, it seems his installation didn't install any kernel.
* mjg59 goes cherry picking through the Suse kernel
<mjg59> Haha
<mjg59> They ship my resume-from-initrd patch
<sladen> hehe :) ...are they using it though
<fabbione> mjg59: no suprise since they steal stuff from our kernels
<rcaskey_> "steal"?
<fabbione> take
<fabbione> whatevert
<fabbione> i am too tired to discuss spelling right now
<sivang> rcaskey_: steal ==> the open source term for adopt, learn from, take ideas from :)
<mjg59> sladen: Not at the moment
<thom> mjg59: not since it was x-s-t
<svenl> Mmm, it seems like Sysace installed from Preview powerpc Binary1 (20041020), and there doesn't seem to be any kernel installed (at least /boot doesn't have them).
<svenl> is this preview binary version known to have such problems ? 
<mjg59> thom: Hmm. Well, we'll just have to fight about who's going to write this, then :)
<thom> i am currently packaging rpm for scott
<thom> there is only so much pain i can take in one go; however if you don't get to it by the weekend i'll take
<Kamion> svenl: no.
<svenl> hi Kamion 
<sivang> hmm, does hdparm make much sense on SATA drives?
<Mithrandir> sivang: it can't talk to them yet.
<sivang> like in enabling DMA mode etc..
<svenl> Kamion: i think you better take over, i really have no idea why Sysace didn't get any kernel-image installed.
<Kamion> I mean it's possible, but I don't remember it, and I have absolutely zero intention of trying to debug warty preview
<Kamion> sorry, today is very very busy for me
<sivang> Mithrandir: meaning we are using those in poorer proformance then in win32 with mfct. drivers?
<svenl> Kamion: supposedly you can just install stuff.
<sivang> /dev/sda1:
<sivang>  setting 32-bit IO_support flag to 1
<sivang>  HDIO_SET_32BIT failed: Invalid argument
<sivang>  IO_support   =  0 (default 16-bit)
<svenl> Kamion: well, the funny thing is that the released version is dated the same as this preview.
<Mithrandir> sivang: oh, why?
<Kamion> oh, release was mistakenly labelled preview
<mjg59> Ok, nothing PM-related worth stealing from Suse
<Kamion> nevertheless, sorry, today everything else I have to do is already top priority
<svenl> Kamion: possibly, i have no idea.
<svenl> Kamion: hehe.
<sivang> Mithrandir: because we don't have anything to enable it's DMA and 32bit modes...but I'm far then expert in this..
<Mithrandir> sivang: you can't have SATA without DMA.
<svenl> Kamion: anyway, is it best he does reinstall, or just try to install the kernel.
<Mithrandir> sivang: and 32 bit transfer mode doesn't really mean anything
<sivang> Mithrandir: ah ok, see I told you I knew nothing about it, so I don't need to do anything special when using a SATA drive? I just get the performance blast automagically?
<svenl> ok, see you later ...
<Mithrandir> sivang: yes, you should
<Kamion> Sysace: I'd need to see /var/log/syslog from your installer (/var/log/debian-installer/syslog after installation) to have any chance of working out why the kernel didn't get installed
<Sysace> Kamion:  I've already tried re-install.. not trying to install kernel manually.. I've found kernel-source.2.6.8.1 and kernel-............  ok.. I'll try to get the log
<Sysace> not = now
<Sysace> 1 sec
<Kamion> it's not kernel-*, it's linux-*
<Kamion> but please file a bug or something, I can't help in real-time on IRC today
<jdub> yay powerpc install! :-)
<sivang> Mithrandir: tnx
<mjg59> Grngk.
<Sysace> Kamion:  the syslog looks real weird at the bottom... is there somewhere i can paste it?
<Sysace> Kamion:  k.. sorry for taking your time.. thanks anyways
<mjg59> benh's sleep patch hasn't been update since last year, and so still includes huge gobs of unneeded crap
<mjg59> Doesn't even come close to applying. Sigh.
<mjg59> Oh, no, hang on
<mjg59> The Gentoo people have one which does apply
<mjg59> Now we just need a test machine
<zul> heh..
<zul> good luck on that 
<zul> mjg59: why check the gentoo forums for opinnons on it 
<mjg59> zul: It seems to work for people
<mjg59> The issue is, it's a 230K patch
<mjg59> 30K of that is absolutely necessary. The other 200K is a massive update of the PPC framebuffers.
<zul> bleah
<mjg59> Without the framebuffer updates, sleep won't work.
<mjg59> From an x86 viewpoint, I don't care - we don't support framebuffers
<haggai> lamont: was http://people.ubuntu.com/~lamont/buildLogs/o/openoffice.org2/1.9.76-0ubuntu2/openoffice.org2_1.9.76-0ubuntu2_20050216-1036-amd64-failed an OOM condition?
<mjg59> But I'm worried about it being a regression on other ppc hardware
<zul> break it up maybe rather than one big patch small chunks of it
<mjg59> zul: None of it's useful without the rest
<zul> true
<mjg59> How would people feel about putting it in, seeing if anyone bitches and then pulling it?
<mjg59> We've got a reasonable number of people with Macs...
<zul> but im not saying dump the frambebuffer im saying to split the patch
<zul> ask t-bone he is doing ppc
<mjg59> zul: Split the patch to what extent?
<mjg59> I can split the FB updates out, but I can't break them down to lower than the file level
<zul> mjg59, like from 200k chunks to 2 100k chunks
<mjg59> Sure, that can be done
<mjg59> It doesn't make it much more readable, though :)
<mjg59> T-None: Ping?
<zul> heh...no my problem its t-bone's ;)
<mjg59> (when you're around)
<lamont> haggai: you think it needs to be kicked?
<zul> hey lamont 
<lamont> morning zul
<ogra> elmo: no trace of wine yet....
<lamont> fabbione: you still around?
<fabbione> lamont: yes
<lamont> or zul - what's the status of 2.6.10 after yesterday?  (that is, what's -19, and do we still need to do the abi roll and upload -20?)
<fabbione> lamont: yes, but not before tomorrow
<lamont> rgith
<zul> cool
<lamont> fabbione: ok.  I'll start pasting that together, along with wearing my daniels hat (no lice, right daniels??) to do lrm
<zul> lamont: i have a usb bk snapshot that im working on but its not ready or anything like that
<lamont> ok
<fabbione> guys since you are going to bump the ABI
<fabbione> use this opportunity to pull in as many changes as you can
<lamont> fabbione: all the more reason to wait until after this week's array CD set releases....
<fabbione> lamont: mostlikely yes
<mjg59> zul: http://linux.bkbits.net:8080/linux-2.5/gnupatch@42010137eNuC9Fwegxk1MrsprC9BEg is the sleep stuff on its own
<zul> lamont, can you pull in what mjg59 said as well
<lamont> fabbione: and one of pitti's changes is also waiting for the abi roll?
<lamont> inotify + that-one-of-pitti's?
<lamont> mjg59: that's ready to pull into 2.6.10?
<fabbione> lamont: i had to revert both of them. so once you readd one you need to readd the other
<lamont> ok
<mjg59> lamont: That provides sleep support for newer Macs, but breaks sleep support on all Macs at the same time
<mjg59> We need framebuffer updates to go with it
<lamont> mjg59: I see...
<Keybuk> oh, man!  epiphany++
<lamont> if you want to send me a list of things you assert will work if added, I'll include them in -20...  Tomorrow or Friday...
<Keybuk> "an external program is needed to view ftp sites"
<Keybuk> and launches Firefox
<mjg59> lamont: Sure
<mjg59> lamont: I'm somewhat fucked by not having test hardware here, though kamion ought to be able to check whether it works
<Kamion> not today, but yes
<mjg59> Ok. I think we should push it for -20 and then revert if it breaks working hardware.
<lamont> I plan to use much of this morning working on the patches that need to go to debian, and then some of this afternoon/tomorrow working on getting another kernel ready to upload
<mjg59> lamont: I'll feed you patches later on today, then
<lamont> cool
<Kamion> elmo: please sync os-prober 1.03
<thom> Keybuk: *giggle*
<zul> mjg59, the patch you sent me may might not get into -20 but ill give it a shot
<Mithrandir> daniels: mail to sitewranglers seems to be held for approval.. isnt't that a bit backwards?
<mjg59> lamont: Ok, I've got 6 bitkeeper patches for you that all look reasonable
<lamont> mjg59: cool - email por favor
<mjg59> lamont: zul: http://www.codon.org.uk/~mjg59/tmp/ppcpatches
<mjg59> Or I can grab and mail them if you'd prefer
<mjg59> Looks like this stuff will be getting into 2.6.11 in any case
<haggai> lamont: I was wondering if you could see an oom message in the logs.  I have 2 more fixes I have to make so I need to upload new source anyway today, so don't worry about kicking that version again.
* lamont demonstrates his excellent cat5-cable skillz for the cats, who are, as always, unimpressed.
<lamont> haggai: will look
<haggai> lamont: thanks
<mjg59> lamont: Did you want them emailed as well?
<bluefoxicy> are there any bugs I should know about pertaining to gnome or gtk?
<bluefoxicy> I just closed a file roller window, and the other file roller closed too
<lamont> haggai: Feb 16 10:44:22 yellow kernel: typesconfig[32441] : segfault at 0000000000000000 rip 0000000000401065 rsp 0000007fbfffca80 error 4
<lamont> Feb 16 10:44:22 yellow kernel: typesconfig[32442] : segfault at 0000000000000000 rip 000000000040109e rsp 0000007fbfffca80 error 6
<bluefoxicy> and so did rhythmbox-
<bluefoxicy> and xmms
<lamont> that's the only things in the log from during the build
<bluefoxicy> err, xchat
<bluefoxicy> and firefox, and gaim
<haggai> lamont: hmm, odd.  Thanks for looking
<bluefoxicy> none of them segfaulted or anything (says dmesg), they just closed
<bluefoxicy> it was like clicking the X on the file roller window sent the signal to all the other apps I was running except gnome-terminal and thunderbird
<lamont> haggai: that'
<haggai> lamont: ah, typesconfig is part of OOo, that must be the problem
<lamont> s looking in syslog
<lamont> well, /var/log/messages, 
<haggai> lamont: hmm, no it wasn't that problem.  Its a second problem actually.. :)
<haggai> aaaah
<haggai> Build killed with signal 15 after 150 minutes of inactivity
<lamont> haggai: so it should _do_ something. ;-)
<fabbione> elmo: ping?
<fabbione> elmo: please process NEW :-)
<zul> bbl lunch
* Kamion waits for fabbione to get the "are we there yet" badge
<Kamion> hm, now who's using sed in a silly way in d-i startup
<Kamion> never noticed that error before because only qemu was slow enough to display it
<sivang> Kamion: isn't it a bit early for that ? ;-)
<Kamion> for what?
<sivang> Kamion: for the "are we there yet" badge
<sivang> :-)
<Kamion> erm, missing the point I think :)
<mjg59> elmo: Around?
<mdz> morning
<sivang> morning mdz 
<mvo_> morning mdz 
<mdz> pitti: here?
<mdz> is the warty-security kernel issue fixed?
<mjg59> thom: Looks like we may be able to manage PPC hibernate, though I'm not touching that until we've got the sleep support in and tested
<thom> mjg59: oh, cool
<mjg59> Someone's updated benh's patch to apply to 2.6.10
<thom> nice!
<mjg59> http://honk.physik.uni-konstanz.de/~agx/linux-ppc/kernel/swsusp-2.6.10-rc2.diff
<mjg59> Needs a small amount of massage, but other than that should apply fine
<Kamion> difference between sleep and hibernate?
<mjg59> RAM and disk
<Kamion> oh, cool
<mjg59> thom: But by the looks of it, it does currently disable StR
<mjg59> Oh, maybe not
<mjg59> It's more that StR doesn't use /sys/power/state on PPC
<thom> hrm, +#if 0/* this breaks suspend to ram until the dust settles... */
<mjg59> thom: We can drop that hunk
<mjg59> The new radeonfb code ought to manage
<thom> ok
<mjg59> And the other #if 0 needs to be changed to #ifdef CONFIG_PMAC (or whatever)
<thom> mjg59: nod
<pitti> Hi mdz 
<sivang> anybody seen a bug with the latest esound-daemon?
<sivang> it won
<sivang> let some progs start ..
<pitti> mdz: yes, it is fixed for now; however, this may happen again, please see my bug followup
<srbaker> okay.  i upgraded from warty to hoary.  is there a doc on how to replace xfree86 with xorg, and make sure xfree86 is gone?
<mjg59> srbaker: It ought to Just Happen during the upgrade
<sivang> mjg59: it happened that way for me
<srbaker> okay.
<srbaker> i did an upgrade last night and it seems to have broken a lot of gnome icons and themey things
<mjg59> sivang: Yeah, and me (did this last weekend)
<srbaker> so i ahve to sort that out first
* sivang --> reboots.
<Keybuk> daniels: failed X startup on Jane's laptop with hang when you try to view the log
<mjg59> Keybuk: How come every laptop you touch turns to shit?
<Keybuk> "could not open default font 'fixed':
<Keybuk> I strongly suspect Mr Stone has been over-trimming
<mjg59> Keybuk: Mm? How was it installed?
<Keybuk> Hoary Array 4, and update
<mjg59> xserver-xorg doesn't depend on anything that provides fixed, because it could be coming from a font server
<mjg59> Is xfonts-misc installed?
<mjg59> Uh, I don't mean that. Now, what do I mean?
<mjg59> xfonts-base
<Keybuk> yeah, first thing I checked
<Keybuk> hmm, all of the font directories are missing fonts.dir
<Keybuk> that's the second time I've seen this problem with Array 4, X-related postinst not being run
<fabbione> seb128: what did you break this time?
<fabbione> i can't even login after today upgrade
<fabbione> :-)
<seb128> fabbione: what's happening ?
<silbs> <kb> her X session immediately logs out
<silbs> fab: any ideas?
<jdub> fabbione: did you recently upgrade esound?
<sivang> bah! xorg won't start anymore :-(
* lamont decides that he's glad he did his upgrades yesterday, not today
* sivang cries
* HiddenWolf did an update today and is still very happy
<sivang> HiddenWolf: do one again, let's see if you're still happy? ;-))
<fabbione> silbs
<fabbione> silbs: same problem here
<silbs> fabbione: gee, thanks
<HiddenWolf> sivang: Can I cry on your shoulder if it doesn't?
<silbs> :)
<fabbione> jdub: i usually do a dist-upgrade
<fabbione> because i kinda TRUST people around that have root on my machines
<sivang> HiddenWolf: hmm well, then don't. it appears something b0rked my system , it started with different apps not wanting to fire up anymore...
<jdub> uh
<jdub> dudes
<jdub> um
<HiddenWolf> sivang: what's causing it?
<jdub> downgrade your esound
<jdub> see if that helps
<jdub> :-)
<sivang> jdub: hrm, I can recall I saw esound there on the upgrade list, I sure do hope so it's not my recent upload of g-s-t and s-t-b
* Kamion produces a program one of whose possible outputs is "Can't count up to 3!"
<silbs> jdub: esound isn't installed.
<silbs> (at least one mine)
<jdub> silbs: libesd0 is the problem package upgrade
<jdub> erm, ahem, s/is/could be/
<Kamion> oh, no, I think I might need to teach it how to count up to 5 or so
<silbs> pinhead: hmmm
<sivang> jdub: it removed ubuntu-desktop, and now only esound is removed and all of the poly audio are gone, rebooting.
* ogra hides
* pinhead sends jdub to hell so that he can enjoy the pleasure of pure pain
<sivang> s/removed/installed
* sivang reboots and avoids the heat :)
<fabbione> silbs: do this
<fabbione> lftp http://archive.ubuntu.com/ubuntu/pool/main/e/esound/
<jdub> fabbione: you've verified it?
<silbs> fabbione: we've just downgraded to array 4
<fabbione> mget *0.2.35-2_*
<fabbione> dpkg -i what is needed
<fabbione> jdub: yes
<jdub> great, new package coming shortly
<fabbione> jdub: next step was to check who destroied my laptop
<fabbione> jdub: and send him to hell :P
<silbs> fab: <keybuk> I just used aptitude to select the version on the cd and downgrade it
<sivang> grr no go :-/
<seb128> jdub: dude you broke GNOME
<seb128> jdub: I don't feel alone doing this now :p
<sivang> seb128: heheh
<jdub> seb128: iz esound boog :)
* sivang ROTFL
<fabbione> eheheh
<sivang> seb128: so downgrading esound is the remedy?
<seb128> dunno, I've not updated
<jdub> yes, it is
<seb128> I don't trust jdub's upload usually :)
<jdub> ;-)
<sivang> heheh
<sivang> ok, fix this after dinner.
<Keybuk> sivang: yeah, downgrade libesd0
<Keybuk> plushie jeff dolls will be available for voodoo later :p
<sivang>  if only we were in the same room.....;-))
* ogra would buy one
<jdub> silbs: jdub voodoo dolls on the merchandise list?
<Simira> jdub: I'd go for that!
<mdz> why go to the trouble of making dolls; we can just stab jdub with pins
<mdz> we could run a booth at LCA
<mdz> "POKE JDUB $5"
<jdub> you misspelt "KISS"
<sivang> hehe
<Simira> lol
<jdub> and by lca
<jdub> it'll be $10
<jdub> i'll be a married man ;)
<Kamion> jdub: I guess I need to hold Array CD 5 for this sound fix?
<jdub> Kamion: yes please! DICKHEAD ALERT!
<Kamion> I'm writing tedious publishing helper scripts in the meantime
<Simira> what? More weddings? When, jdub?
<jdub> Simira: april 17th
<Simira> jdub: cool. So your honeymoon goes to Ubuntu Down Under, then?
<jdub> Simira: hoary-final... wedding... lca(+birthday)... udu...
<fabbione> jdub: good luck
<fabbione> you will explode
<Simira> haha
<fabbione> i had bday+wedding+multiarse+honeymoon and i am already dead
<fabbione> actually
<fabbione> s/+honeymoon//
<jdub> i'm planning to not celebrate my birthday in any useful manner
<fabbione> i still need to start it :-)
<jdub> (which is not unusual anyway)
<Simira> fabbione: leaving tomorrow, aren't you?
<fabbione> jdub: so did i.. i was too busy trying to kick relatives and parent out of my house
<fabbione> Simira: that is the correct answer
<Simira> bdays do kinda come in the background compared to some other things...
<sivang> fabbione: for the islands? ;-)
* Simira is going to debconf on her bday
<maswan> jdub: I think this is an appropriate way of celebrating birthdays: http://www.acc.umu.se/~maswan/recept/25/
<fabbione> sivang: yeps
<thom> maswan: i don't think you have enough cake
<sivang> fabbione: yay for you! bon voyage
* jdub fears swedish conspiracy birthday
<jdub> maswan: whoa! rad :)
<maswan> thom: Yes, this was a concern of mine, I didn't get up to the 25 planned cakes. :)
<fabbione> ehehhe
<Simira> maswan: you can come here to complete it on Tollef's birthday?
<Simira> maswan: your hereby invited
<maswan> Simira: If he/you turns up next sunday around here, you're welcome to cake. :)
<maswan> Simira: When is it?
<Simira> maswan: I think he's in Brssel next sunday. He's 25 on June 8th.
* maswan nods
<jdub> so fabbione 
<jdub> the end result of all this stupidity
<jdub> is that
<jdub> ESPEAKER=localhost:2323 gst-launch-0.8 filesrc location="/usr/share/sounds/shutdown.wav" ! wavparse ! esdsink
<jdub> works
<jdub> :-)
<jdub> it would have been easier to fix it in gstreamer
<jdub> but also wrong
<jdub> because deep down
* ogra turned 35 today and feels very old now after all this mentioning of 25
<jdub> we would have known that esound was a pile of shi-- oh, we already knew that
<fabbione> ogra: really?
<fabbione> ogra: you kidding.. 
<thom> ogra: happy birthday dude!
<ogra> thanks :)
<fabbione> ogra: you look much younger than that
<mvo_> hey ogra, happy birthday!
<jdub> ogra: dude! happy birthday!
* maswan tries dcc:ing ogra some cake :)
<maswan> happy birthday!
<ogra> hey, thanks all :=)
<lamont> ogra: happy bday
<doko> ogra: happy birthday!
<Simira> ogra: happy birthday. Good to have some older, responsible people at this place...
<Simira> uhm...
<ogra> heh
<Simira> *looks around and walks into a corner*
<Mithrandir> ogra: congrats. :)
<Simira> now, where was I... Rosetta
<ogra> Mithrandir: you will be at fosdem ?
<Mithrandir> yes
<Mithrandir> you too?
<ogra> i hope so... depends on my time .... but i was planning it
<mvo_> mdz: around?
<mdz> mvo_: mostly
<Kamion> http://cdimage.ubuntu.com/daily/current/ <- pretty web index now generated automatically
<zul> sweet
<thom> Kamion: nice
<Nafallo> I think I've found a bug (not sure, so asking). my menu.lst has vmlinuz.old as default (named Previous) and vmlinuz-2.6.10-3-amd64-k8 as 3 and 4. bug?
<Mithrandir> mdz: you pinged me yesterday about some utf8-migration-tool things?
<mdz> Mithrandir: yes; what is the status of the package? I thought you had uploaded it, but I can't find it now
<elmo> mdz: it's in universe
<elmo> oh and FTBFS ;)
<elmo> utf8-migration-tool |        0.1 | hoary/universe | source
<mdz> ah, the FTBFS bit explains it
<Mithrandir> bah, silly me
<Mithrandir> it's broken anyhow, due to gdm and python's configparser disagreeing on the format of .ini files
<Kamion> which reminds me, could I have system-config-kickstart in main now that it no longer FTBFS?
* Mithrandir kicks debhelper
* T-Bone tries today's ISO on ia64
<elmo> anastacia makes me cry ATM due to the kde half-in-main business
<trulux> Try `head --help' for more information.
<trulux> dpkg: error processing /var/cache/apt/archives/postgresql_7.4.7-2_i386.deb (--unpack):
<trulux>  subprocess pre-installation script returned error exit status 1
<trulux> oops
<smurfix> elmo: sync of yapps2 ?
<elmo> Kamion: done
<Kamion> thanks
<Kamion> elmo: oh, and did you get my earlier sync request?
<elmo> smurfix: done, sorry
<elmo> Kamion: nope, done now
<Kamion> elmo: ah, thanks
<Kamion> mdz: oh, FYI, you shouldn't ever need to munge DI_TYPE again to get the newest of installer/daily-installer
<elmo> I wish there was some way of doing a 'rootro', i.e. could read _any_ file, but not have root write/create/modify etc. privs
<ogra> elmo: any idea where wine hides ? 
<jdub> ogra: what are you looking for?
<elmo>       wine | 0.0.20040914-1 | hoary/universe | source, i386
<elmo> ogra: ?
<mdz> Kamion: cool; it picks the one with the most recent timestamp?
<elmo> that's what was synced today
<ogra> elmo: i asked for a sync....and you said: done
<elmo> ogra: ... ?
<Kamion> mdz: whatever dpkg --compare-versions says is newest, actually
<Kamion> (on the directory name)
<elmo> oh
<elmo> ogra: meh, sorry it went to the wrong directory.  really done now
<Kamion> elmo: tell your editor to be read-only? 'sudo view' would do, for example ...
<ogra> [14:54]   <ogra> elmo: please sync wine
<ogra> [15:30]  <elmo> ogra: done
<ogra> elmo: heh, ok...
<elmo> Kamion: it's not for editing files, but backup related stuff
<Kamion> elmo: ah
<Kamion> elmo: mount --bind -o ro? :-)
<Kamion> (that should actually work, I think ...)
<mdz> chrooted into a read-only bind mount...
<elmo> I'd eah
<elmo> err
<mdz> I bet root could remount it r/w though
<Kamion> can you take CAP_SYS_MOUNT away from root?
<Kamion> or whatever it is
<mdz> should be possible
<mdz> or you could drop to non-root and retain CAP_DAC_OVERRIDE or whatever
<mdz> oh, hey, even better
<mdz>    and directories, including ACL restrictions if [_POSIX_ACL]  is
<mdz>    defined. Excluding DAC access covered by CAP_LINUX_IMMUTABLE. */
<mdz> #define CAP_DAC_READ_SEARCH  2
<mdz> gah
<Kamion> hm, you have to take away CAP_SYS_ADMIN judging from include/linux/capability.h
<mdz> anyway, CAP_DAC_READ_SEARCH should give you read-only on everything
<Kamion> ah, much neater
<elmo> so how would I give a user a capability?  I thought it was more process orientated
<Kamion> you give it to the executable don't you?
<mdz> yes, it's at the process level
<mdz> typically you use a setuid wrapper, and drop privs from there
<mdz> but there might be a PAM module to do it as well
<Kamion> also setcap(8)
<Kamion> although I guess that needs filesystem support
<Kamion> getcap <executable> seems to say function not implemented for me
<mvo_> ping carlos 
<mjg59> Is power-management-interface in the archive yet?
<ogra> mjg59: yup
<mjg59> ogra: What section?
<ogra> mjg59: omit the first dash...
<mjg59> Ah!
<mjg59> Hmm. Universe?
<schweeb> universe
<ogra> Section: universe/admin
<mjg59> That probably needs to be rectified...
<elmo> ... by someone seeding it, for starters
<T-Bone> Kamion: where's the "please kill fabbione" button? :P
<elmo> Kamion: anastacia wants to demote autopartkit - ok?
<T-Bone> CONFIG_FUSION=m
<mjg59> thom: Get powermanagement-interface seeded, y'bugger
<T-Bone> somebody deserve some heavy trout slapping for that
<zul> hey T-Bone 
<mjg59> elmo: With luck, we'll have StD and StR for PPC
<elmo> mjg59: I thought they didn't mix?
<T-Bone> wow
<T-Bone> Kamion: "Invalid Release file: no entry for restricted/binary-ia64/Packages.gz"
<mjg59> elmo: The only real sticking point is in the framebuffer driver, and we've got a fixed one of those now (with luck)
<T-Bone> end of installation :P
<elmo> mjg59: sweet
<mjg59> Fucking SMS spam
<T-Bone> Kamion: any clue what's going on?
<Kamion> elmo: yes, that's fine
<Kamion> T-Bone: one sec, doing other urgent stuff then I'll look
<T-Bone> ok
<sivang> mjg59: I get it all the time..:-/
<sivang> mjg59: *so* annoying
<elmo>    o console-keymaps-dec
<elmo>    o discover1-data-udeb
<elmo>    o discover1-udeb
<elmo> Kamion: them too?
<zul> mjg59: oh yeah your acpi stuff that you sent me does cleanly apply to vanilla source ill massage it tonight
<Kamion> elmo: yep
<mjg59> zul: Cool, thanks
<Kamion> T-Bone: hmm, apparently the restricted Packages file is empty on ia64 so my fix for the live CD helpfully removed it; I'll see if I can fix that
<elmo> Kamion: tnx
<Kamion> I'll just conditionalise the removal on CDIMAGE_LIVE for now
<T-Bone> Kamion: ok. I'll re-fix kernel asap too. Sadly i can't go up to the elilo stage, anyway :P
* T-Bone goes grab some food for dinner, bbiab
<Kamion> T-Bone: erm, the current kernel has CONFIG_FUSION=y for all ia64
<Kamion> 2.6.10-19
<T-Gone> Kamion: the kernel i just booted has it =m
<zul> oh i suck at wiki
<T-Gone> Kamion: 2,6.10-3-itanium-smp built on Feb 15 ("-3"??)
<Kamion> T-Gone: that's too old, where did you get that?
<T-Gone> Kamion: is d-i kernel updated?
<Kamion> oh, maybe this morning's CD build doesn't have the newer kernel yet
<T-BOne> Kamion: i got it 20mn ago when rsyncing :)
<Kamion> ok, rebuilding
<T-BOne> Kamion: it's noted as being built Feb 15 14:25 UTC
<Kamion> no need to diagnose further :)
<T-BOne> i'm quite surprised that such a recent build has such an old kernel :)
<Kamion> that's because I deliberately set it back
<Kamion> this morning's build does not yet quite have everything reset to normality
<Kamion> the one I'm doing now should
<Kamion> hmm, although according to this it was using -18
<Kamion> well, whatever, I'll rebuild for the Release file fix anyway
<Kamion> T-BOne: "-3" is the module ABI
<Kamion> you should know this, as somebody on the kernel team ... :)
<T-BOne> yeah I thought so but wasn't sure
<T-BOne> ;)
<T-BOne> (and past a certain hungryness, my brain doesn't compute ;)
<mjg59> Hmm. pmi capabilities says I can suspend and hibernate, but the logout menu isn't giving me that option
<zul> Kamion: heh we didnt know this :)
<mjg59> thom: Around?
<trulux> tritium: ping
<trulux> tritium: there? new paper revision for you, also doubts on how to wrote matrix definitions with latex
<tritium> trulux, I'm here
<trulux> I need to make a one for explain further the LaPadula MAC model
<trulux> tritium: :D heya!
<trulux> tritium: ok, dcc'ing, wait
<tritium> ok
<trulux> tritium: here we go! :)
<trulux> fabbione: ping
<fabbione> trulux: pong
<trulux> fabbione: heya! I was talking to pitti on the kernel abi firmware stuff
<trulux> fabbione: I want to make the firmware stuff available for the hardened kernels
<trulux> fabbione: can you redirect me to somewhere with documentation on how ubuntu handles it?
<fabbione> trulux: it's in the kernel source
<fabbione> Documentation/something
<trulux> fabbione: nah, that doesn't fill my needed knowledge and info. bar
<trulux> fabbione: I *need* to know how *you* handle it
<fabbione> i do not handle anything dude
<fabbione> read the firmware class documentation
<fabbione> that's all it is used
<trulux> fabbione: then what do you do with the packages? ;D
<fabbione> trulux: what do you mean?
<trulux> fabbione: pitti commented to me that you handle the firmware pkgs, and the hardened kernel packages didn't have it
<trulux> and that was a thing I could fix
* Kamion rebuilds the live CD rootfs for today's GNOME/sound fixes
<trulux> at least from the upstream side, but I lack of the info. on how ubuntu handles the independent firmware
<Kamion> /usr/lib/hotplug/firmware/
<Kamion> or /lib/hotplug/firmware/, or I think somewhere else
<fabbione> trulux: no, i think you really misunderstood what pitti said
<trulux> fabbione: then put me on the right way, what's up with it?
<fabbione> trulux: pitti told me that hard kernel couldn't load firmware
<fabbione> that's all i know
<trulux> fabbione: oh, that's quite different then, OK
<fabbione> i must go now
<trulux> fabbione: so, he didn't exposed details?
<trulux> ok
<trulux> have a nice time
<fabbione> good night
<T-Bone> Kamion: how long does it take to rebuild the ISO?
<zul> night fabbione 
<rburton> is the current hoary livecd usable?
<zul> mmmm....skittles
<mjg59> Whee!
* mjg59 does the happy suspend/resume dance
<T-Bone> lol
<mjg59> Haha
* T-Bone guesses that makes the patches worth a merge then ;)
* mjg59 notices swsusp: Resume mismatch: version
<mjg59> T-Bone: I'm only testing that it doesn't break x86 at the moment - I don't have a Mac to test
<T-Bone> ah
<T-Bone> unfortunately i don't have a mac laptop (yet) either
<mjg59> Heh. Newworld desktop is also good.
<T-Bone> errr. Unless it screws everything, which I can't allow either ;)
<T-Bone> i've never used susp/res feature TBH. Are there risks for the fs?
<rcaskey_> Tbone: my g3 ibook started to play nice yesterday
<rcaskey_> it did fail one to resume alst night though
<edd> mjg59: Kinnison ever around these parts?
<T-Bone> rcaskey_: ok. My question is precisely "what happens on failure? Is my root filesystem at risk?" :)
<T-Bone> if it's just a crash i don't care. If it can screw things enough to kill journaled FS, i *do* care ;)
<mjg59> edd: Not usually - #debian-uk is a better bet
<rcaskey_> T-Bone: I don't know any particulars, I just know a reboot made it work fine.
<T-Bone> ok
<T-Bone> svenl: ping?
<svenl> T-Bone: pong.
<T-Bone> svenl: still willing to be the ppc porter? ;)
<svenl> T-Bone: yep.
<T-Bone> svenl: then there's work for you ;)
<svenl> T-Bone: but i will be offline the next two days.
<rcaskey_> T-Bone: yesterday was when I knew I was a dork, when I was testing to see if my laptops were suspending properly and I was using two different ones from the cna
<svenl> T-Bone: ah ? 
<rcaskey_> err can
<T-Bone> http://www.codon.org.uk/~mjg59/tmp/ppcpatches <- this is a list of patches that needs to be merged in our 2.6.10 line
<T-Bone> rcaskey_: ok
<T-Bone> svenl: 2.6.10 is in 'bugfixes only' mode, and these patches fall in that area as it seems
<svenl> T-Bone: T-Bone ok.
<svenl> T-Bone: what is the deadline ? 
<T-Bone> svenl: yesterday? :)
<svenl> T-Bone: as said, i will be offline tomorrow andfriday, so this WE should be cool.
<T-Bone> svenl: roger that. This week end will do
<svenl> T-Bone: would a patch for the pegasos gigabit ethernet controler be considered also for inclusion ? 
<T-Bone> hmm
<T-Bone> I think it would go into 2.6.11 instead. Pegasos is not yet supported
<svenl> T-Bone: bah.
<svenl> T-Bone: fabbione told me most of the pegasos patches are in, and ubuntu mostly works on it.
<svenl> T-Bone: but in d-i the loading of the module fails for some missing symbols.
<T-Bone> then it's definitely a no go
<svenl> T-Bone: you have a pegasos even, you could try it yourself :)
<T-Bone> no breakage before hoary releases
<T-Bone> sure :)
<rcaskey_> Why would anyone want a Pegasos machine?
<T-Bone> rcaskey_: it's actually an interesting concept.
<rcaskey_> T-Bone: what is?
<svenl> T-Bone: huh ? You mean we know it is broken, there is probably an easy fix, but we are not going to fix it ? 
<T-Bone> and it has a few niceties
<svenl> T-Bone: it used to work in the 2.6.8 ubuntu kernels.
<ajmitch> morning
<T-Bone> svenl: no. I mean I won't merge a patch that introduces any (known) breakage
<svenl> T-Bone: you are not listening.
<T-Bone> svenl: feel free to send it to me, i'll test it and try to debug it, but i won't merge it
<svenl> T-Bone: or i am speaking klingon or something.
<T-Bone> <svenl> T-Bone: but in d-i the loading of the module fails for some missing symbols.
<T-Bone> this is breakage to me
<svenl> T-Bone: *the current ubuntu 2.6.10 kernel is broken*.
<T-Bone> so you must be speaking Klingon ;)
<svenl> T-Bone: the patch is already in there.
<svenl> T-Bone: or the module support or whatever.
<svenl> T-Bone: just it is borken.
<svenl> broken even.
<Kamion> T-Bone: about an hour for all four architectures
<Kamion> T-Bone: (it's built now)
<svenl> T-Bone: what i am speaking is a patch to fix that breakage.
<T-Bone> Kamion: ia64 is built?
<Kamion> ===== Syncing Ubuntu mirror =====
<Kamion> Wed Feb 16 20:00:54 GMT 2005
<Kamion> [...] 
<T-Bone> svenl: ah ok. Well then it might be merged then ;)
<Kamion> ===== Finished =====
<Kamion> Wed Feb 16 20:50:31 GMT 2005
<Kamion> T-Bone: yes
<svenl> T-Bone: in a module which will never be loaded on any arch that has not a marvell discovery III northbridge.
<T-Bone> Kamion: yay!
<svenl> T-Bone: will see next week what i can do about this.
<Kamion> T-Bone: /dists/hoary/restricted/binary-ia64/Packages is definitely back now
<T-Bone> svenl: ok. The patches i listed are top priority for they fix bugs on macs
<Mitario> hello everyone
<T-Bone> Kamion: cool. I'm rsyncing
<Mitario> I was wondering wether Ubuntu has some kind of changelog writing policy or package description policy
<svenl> T-Bone: i can only test them on my ibook though, or maybe on my pegasos with the 7447A cpu.
<T-Bone> svenl: test on whatever you can. As long as it works for you, i'll take care of testing on whatever I can on my side as well
<Kamion> Mitario: not explicit, but we kind of hope for common sense and slap people who're unclear
<svenl> T-Bone: BTW, what is this pmac only policy ? I think it would be a good thing for ubuntu to support the pegasos in hoary.
<svenl> T-Bone: especially as it is almost there.
<Mitario> Kamion, hehe :)
<svenl> T-Bone: and there may be chances for mass ubuntu on pegasos install if it happens.
<T-Bone> svenl: i'm not the one deciding that
<T-Bone> svenl: ask the release managers
<Mitario> but do we think changelog should be directed at the end user? or for fellow package maintainers/overall techies
<svenl> T-Bone: who is it ? Kamion ? 
<Kamion> no
<svenl> Kamion: hehe :)
<Kamion> there is no pmac-only policy, but obviously making sure stuff that works keeps working has a higher priority than supporting new stuff
<Kamion> I don't see a problem with integrating safe patches that are non-crackful
<Kamion> but you have to accept that the definition of safe gets very strict as we get closer to release
<svenl> Kamion: even to the point that it takes me 10 minutes to explain i propose a patch that fixes a breakage in a orthogonal module to any pmac hardware ? 
<svenl> Kamion: i understand.
<dholbach> re
<Kamion> and the installer experience must be good
<metalikop> Is there a problem with dput or have I broken something?
<Mitario> hmm, does anyone here think that it's usefull to show the current "tech" changelogs in update-manager?
<svenl> Kamion: i intent to fix pegasos OF for yaboot support tomorrow, and then pegasos support should be there without the grub2 hack i resorted.
<svenl> or whatever, i let you work, more on that later.
<Kamion> svenl: will it be possible to install yaboot automatically, i.e. nvram writing from userspace?
<Mitario> I would love to see nice formatted changelogs entries such as the mac os x software updates have, but that's just my opinion
<Kamion> I'd be so happy with that
<T-Bone> svenl: what you have to understand, is that as the release time gets closer, we (kernel leaders for instance) are far less prone to take time to figure out whether your patch, being orthogonal or not, *is safe* (according to us). And you also have to understand that if we merge something *supposedly safe* that eventually breaks some corner case (Murphy's law is everywhere), it'll be too late to fix it.
<Kamion> "install" => "make bootable with"
<Kamion> svenl: it seems to me, though, that T-Bone simply misunderstood early on and thought you were saying that your patch introduced some breakage
<T-Bone> Kamion: right. My bad.
* mvo_ goes to bed now
<zul> night mvo
<Mitario> mvo_, btw replied to your email :)
<Mitario> send a new one even ;)
<Mitario> gn!
<mvo_> Mitario: oh, I'll have a look then :)
<Mitario> mvo_, hehe ok
<Mitario> mvo_, i have some ideas/stuff I'd like to discuss, but we'll do that tomorrow then :)
<mvo_> Mitario: I uploaded two mockups for #6631
<Mitario> mvo_, ah cool. where?
<mvo_> Mitario: if you have time tomorrow that would be nice. I'm around all day. 
<mvo_> Mitario: I attached them to the bugreport
<Mitario> ok
<dholbach> mvo_: about to go?
* Mitario takes a look
<metalikop> Could someone possibly help me out with dput?  I'm experiencing an odd issue I haven't had with other repos.
<mvo_> dholbach: yeah, going to bed (or rather have a bath first, then go to bad). I debugged the ppp stuff in g-s-t. I need to wash aways that perl feeling ;)
<dholbach> mvo_: you rock! :-)
<zul> ooh...sacrilege
<mvo_> Mitario: what is your idea about? Maybe you tell me so that I can think about it a bit
<dholbach> mvo_: drink a beer and make the perl-age go away :-)
<svenl> Kamion: nope.
<Mitario> mvo_, about some layout changes with the changelog and description formatting and such
<svenl> T-Bone: what good is it for me to help out on powerpc kernels, if you don't thrust me, and it is clear by your attitude toward me that you don't thrust me.
<Mitario> mvo_, IMO the current tabs don't look 'nice' for a newbie end-user
<svenl> err, not attitude, but the way you speak to me, both yesterday and today.
<Mitario> mvo_, well, anyways, the changelog should be formatted a bit, and maybe we could merge the description and changelog into one page
<mvo_> Mitario: sounds interessting
<sulkd> you want him to "thrust you" in exchange for kernel work? :D
<T-Bone> svenl: you have a problem with leadership maybe? I never said i don't trust you. I said we had a policy, and answered your questions by respecting that policy.
<svenl> Kamion: err, i mean nvram setting will not be fixing tomorrow, too dangerous right now since the.
<Mitario> mvo_, maybe i'll just branch svn now, and go playing on a bit in my own branch :)
<T-Bone> if you disagree with that policy, that's up to you.
<mvo_> Mitario: formating a GtkTextView is a bit of a pain (creating the tagtable and stuff) :)
<svenl> T-Bone: yes, but you imply that i will break that policy before i even have a chance to do anything.
<Mitario> mvo_, oh and i've send you an e-mail about future of update-manager releases and such
<mvo_> Mitario: go for it, but tell me where I can check the result :)
<T-Bone> svenl: no. Again, you asked me about including a patch, and I answered you what it takes to include a patch.
<Mitario> mvo_, yeah ok :)
<Mitario> mvo_, have you got my second mail?
<svenl> T-Bone: this is no leadership issue, it is patronizing attitude on your part, and i believe it is against the ubuntu code of conduct even if i read it right.
<mvo_> not, not yet
<Mitario> mvo@canonical.com?
<mvo_> michael.vogt@canonical.com
<T-Bone> svenl: since i misunderstood what you said first, i told you i couldn't include your patch. That was wrong of me, and I corrected myself afterwards.
<svenl> T-Bone: you didn't even listen to what i said and said probably not.
<Mitario> ahhh
<mvo_> Mitario: :)
<svenl> T-Bone: exactly, you misunderstood because you didn't listen, and had a negative a priori.
<svenl> T-Bone: this was clear in the way you spoke to me yesterday and how you reacted today.
* T-Bone gives up. zul, lamont, it seems that I'm having a "patronizing attitude", according to svenl. Can you deal with that?
<Mitario> mvo_, ok, sent :)
<sulkd> svenl, dude.. it's like this in any opensource project.. it's not what you got, it's who you know.. cliques.. so you can either try to work your way into one, or fight it and lose..
<sulkd> svenl, sad but it's the way it is
<zul> svenl: send me your patches and ill have a look ok?
<svenl> sulkd: i must not have read the same code of conduct as you did.
<mvo_> Mitario: got it, thanks
* mvo_ really leaves now
<mvo_> night all
<zul> svenl: ok enough send me your patches and i will have a look at them if you dont mind. zul@gentoo.org thx
<Kamion> svenl: nvram setting> ok ... as I've probably said before, I think that's a pretty major usability problem in any Pegasos installer right now; but I realise that there are hardware constraints
<sulkd> svenl, it's not in the code of conduct.. it's imprinted in all those guys' insecurities and need for having a support system made up of their friends
<lamont> sulkd: I'll have to disagree with you on that
<lamont> given a patch, we're happy to review it for inclusion
<T-Bone> we are just being picky on whether to actually include it or not, depending on the timeline (as I understand it, of course)
<zul> right i have to go home
<HrdwrBoB> that said building friendships and trust is not a bad thing at all
<svenl> sulkd: bah, i have known these guys like you said sinc a long time, even T-Bone 
<svenl> Kamion: well, the nvram thing is complicated, i have an idea to fix it, but right now touching the flash, which may kill the firmware, is a big nono.
<svenl> Kamion: and seriously setting a couple of env variables by hand is not all that complicated, even my grand-mother could do it.
<Kamion> svenl: at nCipher, where I last worked, that got solved a long time ago; there are two regions in flash which get written separately, so no individual power failure can kill both regions
<lamont> the question right now on accepting things in the kernel is "is this a new feature?"  If the answer is yes, then it probably waits until after hoary ships
<Kamion> svenl: it's a lot more thought than any one of Ubuntu's other supported architectures; remember I have to justify every new question the installer asks to Mark. :)
<svenl> Kamion: sure, and this is how i want to do it, too, but as you said, no major change before a new release.
* Kamion nods
<svenl> Kamion: well, compared to having to install a half working grub2, and hand typing the grub commands by hand, writing a note for an obscure subarch should not really be a problem :)
<svenl> Kamion: but like said, if i reach the point where pegasos is not officially supported, but is installable with an unnofficial 5 lines HOWTO, then i am happy.
<Kamion> right, and for the record I think pegasos is probably on this side of the "supportable" line with a bit of work, although I wouldn't be happy to say that about all powerpc subarches
<Kamion> I'm not really very happy with the mkvmlinuz approach though, it's a lot of space usage on the CD
<svenl> Kamion: the mkvmlinuz is a lot of space usage on the CD ? 
<Kamion> with a single CD we cannot afford to splurge out megabytes on different kernel formats
<svenl> Kamion: ah, you mean the lot of different kernels on the CD. Why do you think i am going to fix the OF ?
<Kamion> we have one CD, and roughly the same selection of software on each
<Kamion> powerpc is the biggest by far, which means that it acts to constrain the amount of software that we can include on *all* our CDs
<svenl> Kamion: but the only thing i am arguing for is including the mkvmlinuz support file in the kernel-image, not using them to build thousands of CDs.
<Kamion> thus adding more kernel formats to the CD means that we'd be reducing the amount that can go into Ubuntu CDs in general
<Kamion> svenl: I certainly don't have a problem with supporting all sorts of stuff for netboot
<Kamion> physical restrictions mean that we do have to be pretty careful about the CD though :)
<svenl> Kamion: so, see, exactly what i was arguing yesterday.
<Kamion> ok, no problem then
<Kamion> (at least from my point of view as installer/cdimage guy)
<svenl> Well, it is not all that easy, since it needs some modifications of the kernel build stuff.
<svenl> which could be problematic, but well.
<svenl> Maybe it would be possible by splitting another package with the object files, this would be the least disruptive.
<svenl> Kamion: and notice that i am working to get those object files included by default by kernel-package in debian.
<svenl> ok, have to go now, train will be early tomorrow.
<Kamion> svenl: *nod*
<daniels> Mithrandir: i moderated it through
<daniels> Kamion: hang when you try to view the log?
<Mithrandir> daniels: yeah, I have an account now, thanks.
<daniels> cool
<daniels> who created it
<daniels> ?
<Mithrandir> infty, I think
<Mithrandir> yeah, adconrad@tycho is the sender
<Kamion> daniels: hm what?
<daniels> Kamion: jane's weird crash
<daniels> Mithrandir: cool
<svenl> daniels: BTW, on the subject of pegasos support, i needed to tell it to use the Option "BusType" "PCI", apart from that everything worked fine.
<daniels> svenl: cool
<svenl> daniels: could it be possible to set the Option "BusType" "PCI" automatically in some (maybe post-release) future ? 
<Kamion> daniels: I didn't actually look at that log ... I think it was Keybuk doing most of that debugging
<infinity> What sorts of hours does pitti keep?
<daniels> Kamion: aha
<daniels> svenl: no
<HrdwrBoB> \] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] 
<HrdwrBoB> hhhhhhhhhhjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
<HrdwrBoB> jjjjjjjjjjjjjjjjjjjjjjjjjjjjjj
<Kamion> infinity: German business hours, more or less, I think
<toresbe> HrdwrBoB: interesting...
<ogra> infinity: UTC+1
<dredg> HrdwrBoB: here kitty kitty
<infinity> Hrm.. Kay.
<infinity> I need to strangle him a little bit when he's around.
<daniels> svenl: you should never need to set that option; if you do, something is badly busted with your agpgart and needs to be fixed there.  i've never heard of someone needing to use that option in ubuntu before now.
<Kamion> infinity: heh
<T-Bone> hmm, i'll have to add the cpu frequency integer overflow on g5 fix to the next kernel upload as well
<dholbach> daniels: what can i do about this:  cd python && xvfb-run -a python setup.py clean      ===>     /usr/bin/xvfb-run: line 19: 0: command not found
<daniels> dholbach: not a lot
<daniels> dholbach: ('fix xorg')
<dholbach> daniels: Kamion said there already was a fix
<ogra> daniels: dont say that to loud.... last time he fixed gtkmm to try a coaster build
<ogra> ;)
<dholbach> (12:43:41) Kamion:   * Remove spurious quotes from variable expansions of $XVFBARGS and
<dholbach> (12:43:41) Kamion:     $LISTENTCP in xvfb-run.  Thanks to Jeff Lessem for the patch!
<dholbach> (12:43:41) Kamion:     (Closes:# 286181)
* dholbach blushes :-)
<daniels> dholbach: there's a fix, yeah, but uploading the entirety of xorg for that one fix seems a bit harsh
<daniels> i haven't had time to get to it right now
<dholbach> daniels: yes of course
<dholbach> daniels: ok... just wanted to make sure you knew
* dholbach has other things to do meanwhile :-)
<Kamion> dholbach: although I have to say I'm not totally sure that that fixes your bug
<dholbach> Kamion: well, it's in the "clean"-part of diacanvas2 - so it must have worked a couple of times :-)
<daniels> Kamion: https://bugzilla.ubuntu.com/show_bug.cgi?id=5531
<srbaker> is it a safe day to upgrade to hoary?
<srbaker> from a fresh install of warty?
<jdub> sure!
<sivang> srbaker: I even installed from hoary to hoary :)
<kent> srbaker, just answere no to the quistion about world war, and you should be fine. 
<srbaker> well, i did a hoary->hoary upgrade earlier today, and all of my icons broke.
<srbaker> and my gnome theme settings
<srbaker> maybe it was just me
<Kamion> dholbach: er ... not diacanvas2, I mean the xvfb-run thing
<svenl> daniels: the pegasos agp is a pci-x bus disguised as agp, so yes, i need it :/
<svenl> daniels: furthermore, every motherboard without agpgart module would need it too.
* daniels vomits on svenl.
<daniels> svenl: not really, in that case it will just fail to initialise agp and fall back
<dholbach> Kamion: ah ok
<daniels> honestly dude, you know I've seen a lot of X problems, right, and this is the first time I've ever, ever, seen anyone need to force PCI mode on a Radeon
<svenl> daniels: debian's XFree86 know how to fall back on pcigart when there is no agpgart, but x.org simply fails.
<daniels> svenl: er, are you sure?  or is it that the kernel here is pretending to offer agpgart, but it's broken?
* T-None calls it a night
<svenl> daniels: you never saw X running on a kernel where agpgart was not present ? 
<svenl> T-None: night ...
<daniels> svenl: actually, I have
<T-None> night
<svenl> daniels: yes, i am pretty sure.
<svenl> daniels: the x.org code may fail for those.
<daniels> svenl: i will try it out and come bcak, but i think you're very, very wrong
<svenl> daniels: well, i can assure you it fails on pegasos.
<svenl> daniels: if you don't want to fix it this near the release, i understand though.
<daniels> i don't have the time to be chasing stuff like this up right now for hoary, sorry
<svenl> daniels: understood, this is why i asked in some future.
<svenl> daniels: post-hoary and such.
<svenl> ok, night all and good hacking.
<daniels> sure, I'll look into it, but I think it's agpgart here that's broekken, not xorg
<Kamion> argh
<Kamion> elmo: please add amd64 to lilo-installer in PaS
<enrico> Hello.  Is perl in the hoary build-essential, or do I have to build-depend on it?
<Kamion> it happens to be build-essential, but only indirectly due to other stuff; if you're using perl (as opposed to perl-base) directly then it's good practice to b-d on i
<Kamion> it
<Kamion> enrico: is it just /usr/bin/perl you need, or do you need a batch of modules too?
<mxpxpod> is anyone having problems with polypaudio bailing out with an assertion?
<enrico> Kamion: /usr/bin/perl and File::Basename
<enrico> I can do without File::Basename, thoug
<Kamion> perl-modules: /usr/share/perl/5.8.4/File/Basename.pm
<seb128> elmo: libgtkhtml2 sync please
<Kamion> enrico: ok, so you should build-depend on perl I thiknk
<Kamion> think
<enrico> Kamion: if it does not need File::Basename, can I do with what's in perl-base?
<Kamion> enrico: sure, but why bother? extra build-deps aren't bad
<Kamion> and using more modules to make your code clearer is a good thing
<enrico> Ok, I quite agree with you
<enrico> Kamion: the ubuntu-doc packages are in a really good shape, then!
<Kamion> the explicitly build-essential things are libc-dev, gcc, g++, make, dpkg-dev, same as in Debian; there are a couple of extra bits in our buildd chroots
<Kamion> cool
<enrico> Kamion: the package sources is the trunk of the docteam repository (wiki.ubuntu.com/DocteamRepository)
<enrico> you get the trunk and debuild it
<Kamion> not right now :)
* Kamion is building/testing array cd 5
<enrico> well, anytime you want :)
<enrico> it's there for you
<Kamion> ok
* Kamion does a successful software RAID install on amd64
<mxpxpod> amu: ping
<amu> mxpxpod: peng
<mxpxpod> amu: have you upgraded to polypaudio?
<amu> nope running kde atm 
<mxpxpod> blah.. you're no help
<daniels> arts, yo
<amu> mxpxpod: :)  
<mxpxpod> amu: hmm, I need someone to test this
<mxpxpod> amu: pa keeps bailing out on my machine
<amu> mxpxpod: did you tried my config? 
<lamont> fire call
<mxpxpod> amu: no, I talked to benh and figured out my problems
#ubuntu-devel 2006-02-20
<HiddenWolf> *grumble*
<HiddenWolf> why can't launchpad just send its mails from malone-deamon@launchpad.net
* HiddenWolf messes with mail filters some more
<Burgwork> HiddenWolf, rather than as the person?
<mjg59> Subject: xserver-xgl_7.0.0-0ubuntu1_source.changes is NEW
<HiddenWolf> Burgwork: now I have to do a filter like "IF not from $list-of-bugzilla-emails AND  subject is [Bug $something"
<Burgwork> HiddenWolf, I filed a bug on the stupid email behaviour
<Seveas> HiddenWolf, filter on headers....
<Seveas> Every malone mail has malone headers...
<HiddenWolf> Seveas: got a point there.
<HiddenWolf> mjg59: you rock
<Seveas> which is quite useful
<HiddenWolf> mjg59: murphy's law that you upload them when I probably won't have time to test for a week, but you rock still. :)
<Seveas> mjg59, you're insane too by the way for doing it this quick :)
<Seveas> thanks!
<Seveas> This will make quite a few people switch to dapper for testing...
<HiddenWolf> Seveas: shush, if it helps shut up the noobs, that's cool.
<HiddenWolf> Seveas: switch to dapper, rather than gentoo. Looks good to me. :)
<Seveas> :D
<Burgwork> mjg59, once it gets through new and is test installed, you should send something out via -devel-announce
<sebest> ajmitch_ bug 6509
<Ubugtu> malone bug 6509 in avahi "Daemon fails to refresh network services after connecting to wlan" [Normal,Fix released]  http://launchpad.net/bugs/6509
<ajmitch_> ok
<elmo> what was the default postfix config for breezy - does anyone know?
<infinity> elmo: Other than "not installed", you mean?
<elmo> really?  ok, so this must be a hoary box
<elmo> what was the default postfix config for hoary - does anyone know?
<elmo> :P
<infinity> Listening only on localhost, local and remote delivery...
<elmo> hmm, ok, so this box being in 'noconfig' state is unusal
<elmo> and I suppose bombing out when even 'lo' is not configured/present isn't entirely unreasonable
<elmo> NOOOOOOOOOOOOOO
<elmo> ps auxfw no longer works in dapper?!
<infinity> Works here...
<mjg59> elmo: If you can shove xserver-xgl through NEW, billions of forum users are going to shut up and leave me alone
<elmo> mjg59: COO's laptop trumps xgl
<mjg59> elmo: Damnit.
<bj_> haha
<mjg59> elmo: I bet Mark would disagree :p
<elmo> infinity: cough, don't mind me
<elmo> so, hum, at refuses to configure if at is already running - is that reasonable?
<Seveas> elmo, how did you create a system where postfix is unconfigured, at is running but not configured and ps auxfw does not work? :)
<infinity> elmo: ... Really?  I see no such evil in the postinst...
<elmo> infinity: it runs /etc/init.d/atd start, that breaks if atd is running
<infinity> Oh, yes, it does do invoke-rc.d atd start
<infinity> Which it should.
<infinity> So the real problem is that the init script should exit 0 when starting if it's started already...
* infinity fixes that right now.
<elmo> yikes dapper is very mouse-overy
<Seveas> Somehow I think Ubuntu is going in the completely wrong direction...
<Seveas> Accepted twisted-words 0.3.0-2ubuntu1 (source)
<elmo> and very dark
<elmo> why is the screen so dark
<ajmitch_> Seveas: why is that bad?
<Seveas> ajmitch_, How is accepting twisted words good?
<Seveas> (sorry if the 1am humor does not come out right?
<Seveas> s/\?/)/
<ajmitch_> have you not met some of the developers? very twisted indeed
<infinity> elmo: On battery?  The defaults for backlight scaling seem a bit off.
<elmo> nah, it's plugged in
<infinity> Well, could still be the same thing. :)
<elmo> the brightness controls work, so it's trivial to fix, just seems a bad default
<infinity> Yeah.
<elmo> ok, the magic appearing cog wheels thing is teh ugly
<mjg59> "Appearing cog wheels thing"?
<elmo> at the gdm login screen, Options in the bottom left is strangely indented to the right
<elmo> 'cos when you mouse over, a red set of cog wheels appearsnext to it
<infinity> elmo: at init script bug(s) fixed.  Thanks for the heads up.
<elmo> infinity: cheers
<elmo> doko: btw, why is it C+R?  if it's just file-overwrite it should only be R?
* infinity really thinks --oknodo should be the default to start-stop-daemon, since almost everyone wants it, but no one knows they do...
<infinity> I've given up on expecting maintainers to read the s-s-d manpage, I think. :/
<doko> elmo: hmm, correct. will change it for the next upload
<mjg59> ARGH I HATE THIS SOFTWARE
<HiddenWolf> mjg59: care to vent your frustration?
* floam guesses it might have something to do with xgl
<mjg59> Cocking thing has suddenly decided to build a different library
<sebest> this one is really nasty ( bug 31429 )
<Ubugtu> malone bug 31429 in udev "ethernet device name has been changed." [Normal,Unconfirmed]  http://launchpad.net/bugs/31429
<hyperactivecrond> if i want to test out kubuntu is the daily release or the 3rd flight cd better off testing?
<hyperactivecrond> o' dapper
<infinity> Testing dailies is always appreciated.
<hyperactivecrond> alrite.  will do 
<Kyral> Do the Daily builds of the LiveCDs have the new installer on them?
<honkzilla> Bug, feature, or user bone-headedness: An SMC2632W (not V2 or 3) 802.11b wireless card does not work correctly with the orinoco_cs driver that is loaded by default.  I have tried with and without the hermes module.  eth1 is present, and iwconfig can read some information about the card, but cannot set anything other than essid, and the card never associates.
<honkzilla> If anyone has some experience with such a card, I'd appreciate some guidance.
<wasabi> One of these days I need to go read wtf malone is
<LaserJock> wasabi: is the Ubuntu bug tracker. http://launchpad.net/malone/
<Chipzz> rofl :)
<Chipzz> (closes: Matthew Garrett's mouth).
<Lathiat> haha
<Lathiat> whats that in
<Chipzz> mesa (6.4.1-0ubuntu3) changelog entry
<Lathiat> haha
<desrt> wobbly windows are fun.
<Chipzz> I'm laughing at anyone, just at that entry :)
<Chipzz> errr
<Chipzz> +not
<Chipzz> :P
<Chipzz> lol at udev (079-0ubuntu12) changelog entry too :)
<Chipzz> reading changelogs can be amusing sometimes ;)
<desrt> right.  so it's becoming important to me again
<desrt> how do i draw alpha using gtk?
<desrt> like if i want to make a gtkwindow with a background colour of (255,255,255,0.0)
<theball> hi
<theball> is anyone available for a few questions on dapper?
<mpt_> Kamion, ping
-RobLevin:#ubuntu-devel- We are doing some upgrades you might want to type /server irc.freenode.net to the newer servers. Thanks.
<sivang> morning all
<HiddenWolf> good morning
<sivang> hey HiddenWolf , are you running xgl already? :)
<HiddenWolf> sivang: waiting for mjg59's crack to get past new. :)
<HiddenWolf> sivang: I should really be writing a business plan and preparing a statistics examination, but well... :)
<sivang> HiddenWolf: who wants to that that , anyways ? :)
<sivang> HiddenWolf: ah, so it's already fixed and uploadeD?
<HiddenWolf> sivang: mjg pasted the subject of his acceptance mail in the channel yesterday about 1am
<HiddenWolf> sivang: and well, there are about three parties I could attend today and tomorrow, and a band playing. :)
<HiddenWolf> sivang: murphy's. When the cool thing happens, you're otherwise occupied. :)
<pitti> Hi
<HiddenWolf> Good morning pitti
* sivang hugs pitti 
<sivang> HiddenWolf: indeed :)
<pitti> hi sivang
<sivang> pitti: did you get my email regarding volume.disc.capacity namespace ? 
<pitti> infinity: yay new enigmail :)
<sivang> pitti: there's an upstream fix in CVS, that adds this property. It would be very helpful to have ti fro HOmeUserBackup, seb128 also mentioned you might want to ask UVF excemption for the new hal when it hits debian?
<pitti> sivang: uh, no, I didn't get it - where did you send it to?
<sivang> pitti: martin.pitt@ubuntu.com
<virogenesis> has anyone else been experiencing 9 floppy drivers when running breezy?
<sivang> morning mvo 
<virogenesis> morning
<mvo> hey sivang
<mvo> how is HUB coming along?
<pitti> sivang: hm, odd, which subject?
<sivang> pitti: can't recall :-/
<sivang> pitti:them email was asking if we could create a patch from the upstream CVS for it.
<pitti> sivang: hm, I didn't get any mail
<sivang> pitti: okay. nevermind. mind if I explain ?
<pitti> sivang: ah, got it now
<sivang> pitti: upstream fixed fd.o bug #2233, which is about adding disc capacity probing in the linux2 backend, if we could pull this update and incorporate it in our hal it would be great for HomeUserBackup, will allow me to do automatic slicing based on the inserted CD's capacity. Could we have this as a patch if you're not syncing the next hal from debian?
<pitti> sivang: it was hanging around in the postfix queue
<Ubugtu> malone bug 2233 in gnomebaker "Gnomebaker blanking fail under breezy" [Normal,Fix released]  http://launchpad.net/bugs/2233
<sivang> pitti: ah, cool :)
<pitti> sivang: ah, I remember that bug
<pitti> sivang: I had a similar problem with n-c-b
<pitti> sivang: I hope that we can upgrade to 0.5.7
<Seveas> sivang, try "freedesktop bug 2233" if you want to keep ubutu happy ;)
<Ubugtu> freedesktop bug 2233 in hald "Add capacity property for CD/DVD volumes" [Normal,New]  https://bugs.freedesktop.org/show_bug.cgi?id=2233
<pitti> sivang: but if not, pulling that patch is easy
<sivang> pitti: cool, even I could od it :)
<sivang> pitti: when will we know if mdz approves it?
<sivang> Seveas: fd.o is shorter to type :)
<pitti> sivang: hal upstream is imported into bazaar.ubuntu.com, that's where I usually grab patches from :)
<sivang> pitti: even cooler, that makes it even easier :)
<infinity> pitti: even better when it builds everywhere. :)
<pitti> infinity: oh, if you need to upload another version, could you add the CVE number to the changelog?
<infinity> pitti: It's in there.
<infinity> pitti: The changelog includes the changelog entry from the breezy-security upload.
<pitti> infinity: oh, ok, I didn't see it on d-changes
<pitti> ok, I must have been blind then :)
<infinity> Nah, I didn't get it in the .changes, you're not blind. :)
<infinity> The .changes included everything > breezy-security
<pitti> ok *phew* 
<Mithrandir> maswan: care to take a look at ravel?  Seems not to be ponging
<Alinux> guteb morgen pitti , guten morgen all! :)
* pitti waves to Alinux 
* Alinux Alinux don't understands the meaning of the word :)
<Alinux> looolz
<Alinux> 2 mal :)
<Kamion> Kyral: yes, but not widely advertised yet - that'll change over the next couple of days
<Kamion> mpt_: yes?
<pitti> hey dholbach 
<Kamion> mjg59: it's kinda weird how much crap is in the xserver-xgl .diff.gz (like Makefile.in files)
<dholbach> hey pitti
<fabbione> hey dholbach 
<dholbach> hey fabbione
* dholbach hugs fabbione
<fabbione> Dear Desktop Team, please make gconf2 sucks less on amd64
<fabbione> dholbach: :)
<Mithrandir> s/on amd64//
<Kamion> (but accepted anyway, looks fine)
<Lathiat> so is novell actually shipping this?
<mpt_> Kamion, how's the Espresso GUI going? I'm wondering if it would be ok to change one of the mockups to help answer the oft-asked question "why wasn't I asked for the root password?"
<Kamion> mpt_: "in progress"
<Kamion> mpt_: feel free to change that mockup, yes; I haven't turned the Guadalinex UI into that screen yet
<mpt_> ok
<Kamion> although I do reserve the right not to copy the text verbatim :)
<Kamion> (if we get user-setup improvements upstream that deal with the root password thing, as we should do soon, then I'll prefer that text because we'll have translations of it
<Kamion> )
<mpt_> fair enough
<sivang> mvo: oh just now saw your lines, I've almost finished the backend stuff (now working on the BackupEngine class which is the last one) I have cool progress indication propogation using generators, and now waiting for our hal to report volume.disc.capacity, workarounding the fact dar would backup only from one source path at a time, writing the cd burning support and see how I translate to the GUI the incermental backup and restore features of dar
<HiddenWolf> Lathiat: looks like they're shipping it.
<jsgotangco> ?
<siretart> morning
<jsgotangco> hi!
<pitti> hi siretart 
<siretart> hi pitti 
<siretart> elmo: could you please sync dssi_0.9.1-2 from unstable? thanks
<Mithrandir> seb128: you're aware that serpentine is uninstallable due to python-gst0.10 being in universe?
<seb128> Mithrandir: yep, nothing I can do
<seb128> I don't have promotion foo
<Mithrandir> seb128: is a main inclusion report needed or can we just promote?
<seb128> just promote
<Mithrandir> source's not in main, though.  Newer version?
<ogra> which we cant apparently
<ogra> Mithrandir, namechange due to version name in binary ...
<Mithrandir> ogra: we can't what?  promote packages?
<ogra> yes
<ogra> apparently .
<Mithrandir> why's that?
<ogra> dunno ...
<dholbach> ogra: What problem are you specifically referring to?
<ogra> we can, but it maight be in elmos hands or in soyuz teams hands and teakes time ... inputattach *was* promoted ...
<ogra> dholbach, read above
<ogra> dholbach, all CDs breake due to python-gst0.10 being not in main ...
<Mithrandir> grr, so we can't just prod Kamion for it?
<ogra> Mithrandir, he'll point you to elmo, or soyuz or whomever ...
<seb128_> re
<seb128_> <seb128> that's python-gst new version
<seb128_> <seb128> that has been discussed yesterday, but I think Kamion doesn't have the runes for it neither
<seb128_> <seb128> we need to ask elmo
<tepsipakki> yay, xserver-xgl built successfully :)
<HiddenWolf> now we wait for mjg59 to gather more bugs than daniels ever did. ;)
<sivang> xgl is go?
* sivang can't wait to break his office station
<HiddenWolf> how bad can it break? :)
<seb128_> that's not a such good idea to ship new cracks like that :p
<sivang> seb128_: don't be a party breaker /me hugs seb128_ 
<seb128_> people will flood the lists and launchpad of questions and bugs about them
<sivang> :)
<seb128_> no, no hug
<seb128_> I'm not joking ....
<HiddenWolf> seb128, it's a worse idea to let the random noob get it from some apt-get.org archive
<HiddenWolf> seb128, at least this way you can have some influence on how they fuck up their systems.
<seb128_> when they get apt-get.org we can reject the bugs and say the list is not right place
<seb128_> ie: if you install broken stuff by yourself you take your responsability :)
<ogra> seb128_, +++++++ from me 
<sivang> seb128_: maybe we can setup special lists and channels for that :) but seriously, you're probably right, it will cause some overhead, but then how otherwise the new crack will get stable and old ?
<ogra> i agree its a really bad idea
<seb128_> dapper is not meant for new crack
<seb128_> we should focus on stabilize
<sivang> oh right! "stable and boring"
<seb128_> stable is not really boring
<sivang> it was just mark's words :)
<seb128_> I'm happy to have a stable box
<sivang> in a joke, ofcourse
<seb128_> rather than a fun box crashing every 5 min
<ogra> and 3 years of bugreports for broken crack we cant fix are no fun either
<sivang> seb128_: right , that is a good point.
<dholbach> it's in universe, relax
<HiddenWolf> obviously
<seb128_> dholbach: I'm somewhat happy we ship it, some crack addict will want to try it :)
<ogra> dholbach, as the 2.6.11 kernel snapshot was ... (yes i know it appeared like an update there... but still)
<seb128_> but people start abusing ubuntu-devel list about it
<sivang> so maybe we can tell people that u-d ML is not right place for universe stuff, but u-m is possibly better, will that solve that?
<ogra> sivang, does it matter which ML you spam with it ? 
<seb128_> people don't listen when you say that
<dholbach> the u-d mailing list is not the right place for bugs
<ogra> it produces noise *anywhere*
<dholbach> it's a madhouse at the moment
<seb128_> anyway that's the same issue than backport
* ogra slaps his fingers that he couldnt resist to reply to the totem thread ...
<seb128_> we have a class of users which just want to try everything new and who complains 2 days after the stuff are here if it's not packaged
* ogra thinks gaim 2.0 ...
<seb128_> on what list?
<seb128_> totem?
<ogra> yes... u-d
<ogra> yesterday ...
<sivang> seb128_: what would you think would be a better approach? not provide even through universE? wait for it to stabilize?
<seb128_> sivang: ship stuff when they are ready to be used
<WaterSevenUb> Kamion, dapper yesterday build. I choose Portuguese via F2 in the first splash screen and I proceed with installation. At a certain point I'm forced to choose I guess Brazilian Cities, in timezone configuration.
<ogra> sivang, not for a 3 year frozen release 
<seb128_> doko: you broke gnome-python!!
<WaterSevenUb> Kamion, and that does not happen pressing enter and then choosing the language. Is this expected ?
<ogra> yoou can do that with a normal release ... and make a VERY BIG POINTER TO USE AT YOU OWN RISK
<Kamion> WaterSevenUb: file a bug report on debian-installer with full directions on how to reproduce the bug please
<WaterSevenUb> kamion, ok
<Kamion> Portuguese is an awkward case
<tepsipakki> arf, the ia64 build of xgl is still pending
<tepsipakki> is floe so much slower?
<seb128> maybe a question for #launchpad
<seb128> if you have a buildd issue
<seb128> but I would suggest to have a bit of patience
<tepsipakki> seb128: no issue, just impatient ;)
<seb128> tepsipakki: please express your impatience somewhere else so :p
<seb128> that's not the place
<tepsipakki> ok, sorry :)
<mjg59> Kamion: The orig.tar.gz is the CVS
<mjg59> Kamion: It needed some heavy re-autotooling
<WaterSevenUb> Kamion, #31477, hope it's clear.
<Kinnison> Kamion: wiki updated.
<Treenaks> mjg59: it's known that the just-built xserver-xorg tries to access a non-existing dlopen: /usr/lib/xorg/modules/xgl/libxglx.so ?
<mjg59> xserver-xorg?
<Treenaks> mjg59: uh.. xserver-xgl
<mjg59> Treenaks: The wacom-tools build is nasty and I don't understand it. I'll look again later on.
<mjg59> Treenaks: What version?
<Treenaks> mjg59: 7.0.0-0ubuntu1
<lixus> hello, is this the correct channel to ask questions about  http://cdimage.ubuntulinux.org/daily/current/dapper-install-powerpc.OVERSIZED ?
<Treenaks> when I built it myself it sort-of worked (though compiz broke with "GLX_EXT_texture_from_pixmap is missing"); autobuild of the same package seems broken
<ogra> lixus, its to big for the iso size ... thus the OVERZIZED file ...
<mjg59> Treenaks: Now that's odd. I uploaded 7.0.0-0ubuntu2 (and have the .uploaded file to prove it), but it seems to have vanished
<lixus> ogra, thanks. that explains why i got read errors during install
<ogra> lixus, for the install isos its helpful to have a look at report.html ... if thats empty for powerpc, its more likely to work ...
<Treenaks> eaten by the launchpad
<ogra> mjg59, is it NEW ?
<lixus> btw the "current" link in the URL makes not much sense as it got re-linked while i was downloading overnight and therefore i ended up in broken iso
<Treenaks> ogra: it was
<mjg59> ogra: I uploaded a version that went into NEW. I then uploaded another version.
<ogra> mjg59, did it get processed in the NEW queue ? 
<ogra> note that we have some other stuff sitting there as well 
<lixus> ogra, will it work to burn that oversized iso to a DVD ? or are there differences between DVD ISOs and cdrom ISOs ?
<mjg59> ogra: There wouldn't be any versions built otherwise
<ogra> mjg59, binary NEW :)
<Treenaks> mjg59: did you upload the second version before NEW was processed?
<mjg59> Treenaks: Yes
<mjg59> I believe
<Treenaks> maybe that's the bug
<ogra> lixus, thats really a matter of luck ... i saw some that worked from DVD ... i guess it depends on the amount of oversizedness ...
<Kamion> mjg59: fair enough
<Kamion> lixus: burning to DVD should be just fine
<Kamion> I don't think it's a matter of luck unless we manage to oversize things by about 4GB
<lixus> Kamion & ogra thanks, i'll try with a DVD.
<ogra> yeah it might be additional breakage i was hit by ...
<Treenaks> mjg59: so you're re-uploading 0ubuntu2? or are you fixing more stuff and skipping to 0ubuntu3?
<mjg59> Treenaks: I've just re-uploaded 0ubuntu2, because Launchpad dropped it on the floor
<Treenaks> go launchpad!
<HiddenWolf> Treenaks: hey, even NASA can't get them up all the time.
<Treenaks> HiddenWolf: that's because NASA is populated with old men :P
<ogra> Kinnison, mjg59, do you also think that we should set the defaults for "on battery" and "on ac" to "never" in g-p-m ? on battery is currently set to 20min and causes some surprises for user that arent aware of the switch to g-p-m
<Kinnison> what defaults would you suggest?
<ogra> never 
<ogra> if a user wants to tweak it, he can ...
<pitti> ogra++
<Riddell> mvo: ping
<mammadori> hi all, I would like to help ('cause of master thesis in IT engineering) in development of the LiveCD, where I could start watching devel tools, sources and coordination?
<Kinnison> you mean 'never' for the autosuspend?
<Riddell> mvo: http://muse.19inch.net/~jr/tmp/gnome-app-install.diff
<ogra> but if you get switched over silently it doesnt just suspend
<Kinnison> ogra: or for some other config?
<Riddell> mvo: quite a broken clean rule that package has
<ogra> Kinnison, look at the power preferences
* Kinnison is mid dist-upgrade or he would
<Kinnison> I got upstream to accept our use-case for lock-only btw
<ogra> there are sliders for "on ac power" (thats "never" by default) and for "on battery" thats "20 min" by default
<ogra> cool :)
<Kinnison> ogra: right, so you're talking about the autosuspend on inactivity
<Kinnison> ogra: yeah, i think the default for on-battery should be 'never'
<ogra> yup
<ogra> oki ... setting that ...
<Kinnison> You're preparing another g-p-m upload?
<ogra> you can do it if you want ... the settings are in data/gnome-power-manager.schemas.in
<ogra> also what do we do about notifications ? 
<Kinnison> I was thinking about that one
<Kinnison> I think having a "show notifications" option which defaults to 'on' would be nice
<ogra> there is one for "fully_charged" (which makes sense imho) and one for "ac_unplugged" (which doesnt imho)
<Kinnison> I found the ac_unplugged one useful just yesterday
<ogra> since i *know* i just umplugged the power
<Kinnison> rob tripped over my power cable and unplugged it from the power brick
<ogra> it helps on power outeages indeed :P
<Kinnison> and since I have the brightness set the same on both, I noticed
<Kinnison> only because I had the notification
<ogra> Kinnison, did you note silbs problem with brightness ? 
<mjg59> The problem with putting a default for sleep on battery is that it won't work on all machines
<Kinnison> ogra: which bug number is that?
<Kinnison> mjg59: aye, so defaulting to never seems sane
<mjg59> Also:
<ogra> ot was set to 7% or something after the upgarde .... being on ac
<ogra> Kinnison, no idea if there is a bug number
<mjg59> Doing anything that enables sleep should pop up a dialog saying that it's experimental and may not work
<mjg59> (Possibly with a "Go away and don't tell me again" box)
<mjg59> I think we need to indicate that it's potentially dangerous
<mammadori> I would like to help LiveCD development, any advices?
<Kamion> the live CD is built automatically from normal Ubuntu packages; there aren't many pieces that are specific to the live CCD
<Kamion> er, CD
<Kamion> this channel and the ubuntu-devel mailing list are good places to start out watching development
<Kinnison> ogra: I certainly believe we should default the brightness to 100% in all cases too
<mammadori> Kamion: I would like to help on automatic tools, not on packaging or similar, initramfs, unionfs, squashfs, casper-cow and so on 
<ogra> Kinnison, hmm, it saves a lot of battery if you turn it lower on battery ...
<ogra> i'd suggest 60% on battery and 100% on ac
<mammadori> (bad comma I wrote); so I would like to help in the many specific LiveCD areas
<ogra> or 70% on battery 
<Kinnison> ogra: if that's easy to express in the default schema then cool
<Kinnison> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=331164 btw
<Ubugtu> gnome2 bug 331164 in gnome-power-manager "No facility to lock the screen on lid closure" [Enhancement,Unconfirmed]  
<ogra> the schema has defaults for both ...
<ogra> Kinnison, oh thats a duplicate
<pitti> on the same topic, the screensaver still gets active right after resuming, which is a big annoyance
* infinity rejoices at the "Lock Screen" option.
<ogra> Kinnison, Bug 29881
<ogra> thats the older and original one ...
<infinity> pitti: Due to clock skew, I assume, though some may see it as a feature anyway.
<pitti> ogra: heh, ubugtu minds capitalization :)
<ogra> Kinnison, silly Ubugtu bug 29881
<Ubugtu> malone bug 29881 in gnome-screensaver "Closing the lid should lock the screen if locking is activated in gnome-screensaver" [Normal,Fix released]  http://launchpad.net/bugs/29881
<pitti> infinity: well, real time indeed progressed half a day when I resume my laptop
<infinity> pitti: Exactly.
<ogra> Kinnison, ah, oh, yours is upstream :)
<pitti> infinity: well, it should either lock the screen before going to sleep, or not get active at all
<pitti> right now, it's just silly
<Kinnison> ogra: aye :-)
<ogra> haha
<infinity> pitti: I'd be fine with activating/locking before sleeping.
<ogra> Kinnison, look at the schemas file and dig for "LCD" 
<pitti> infinity: as a default, agreed, if it can be turned off easily
<Kamion> mammadori: generally the best approach is just to dive in on stuff that interests you; sending patches for existing bug reports is often a good place to start
<Kamion> s/place/way/
<infinity> pitti: And yeah, I see the point.  If you don't want it to lock, we should have a way to tell the screensaver on resume "hey, I just came back from resume, ignore that 5 day clock skew"...
<ogra> Kinnison, on ac: <default>7</default>, on battery <default>3</default>
<ogra> Kinnison, thats percent ....
<pitti> infinity: right; I don't need my screen locked if I just keep my laptop in my room
<ogra> Kinnison, ah, see bug 31490, silbs just filed it 
<Ubugtu> malone bug 31490 in gnome-power-manager "Default settings need review" [Normal,Unconfirmed]  http://launchpad.net/bugs/31490
<Kinnison> ogra: If you take on the g-p-m stuff, I can finish my acpid patches
<ogra> oki
<siretart> elmo: please sync u++_5.3.0-1 from unstable, ok to override ubuntu changes
<fabbione> siretart: isn't that an UVF exception too?
<siretart> fabbione: we already have 5.3.0 in dapper, as 5.3.0-0ubuntu1
<siretart> fabbione: we updated ahead of debian
<sivang> pitti: http://bazaar.ubuntu.com/hal@arch.ubuntu.com/ <== branch from here if I want to grab the patch?
<pitti> sivang: yes
<fabbione> siretart: ok
<sivang> pitti: thx
<mjg59> How often do packages get picked up by the buildds?
<Treenaks> mjg59: should 0ubuntu2 fix the GLX_EXT_texture_from_pixmap thing from compiz too?
<Treenaks> or is that a compiz bug?
<ogra> seb128, how do i reset my gconf user defaults for one specific app without wiping all my settings with the new %gconf-tree.xml implementation ??
<mjg59> Treenaks: Upgrade mesa
<seb128> ogra: gconftool-2 --recursive-unset /apps/app
<ogra> thanks :)
<seb128> np
<Treenaks> mjg59: to what? I have the newest
<mjg59> Treenaks: Ah. In that case, make sure that compiz links itself against Mesa, not the ATI libGL
<mjg59> LD_LIBRARY_PRELOAD is probably the easiest way to do that
<Treenaks> mjg59: nvidia, but yes
<mjg59> Treenaks: BTW - does radeonfb work on your laptop?
<Treenaks> mjg59: which laptop? the one with broken X ?
<mjg59> Treenaks: Yeah
<Kinnison> mjg59: before I make my first unsponsored upload, can I get you to review the diff (s'tiny)
<Treenaks> mjg59: I'll try when I'm back home
<Kinnison> mjg59: acpid, fixes bug 31407, http://people.ubuntu.com/~dsilvers/acpid-8-9.diff
<Ubugtu> malone bug 31407 in acpid "powerbtn.sh incorrectly looks for PowerManager" [Normal,Unconfirmed]  http://launchpad.net/bugs/31407
<infinity> Kinnison: Oh, just upload.  You can always upload again if you were wrong! ;)
<Treenaks> mjg59: about compiz, this means the universe one doesn't work out of the box..
<infinity> Kinnison: Besides, I hear that soyuz thingee needs as many uploads as possible to stress test it.
<mjg59> Kinnison: It should also check for the KDE equivalent
<fabbione> Kinnison: looks good to me.. screw KDE :P
<mjg59> Treenaks: I'll think about ways around that
* Riddell bops fabbione 
* fabbione hugs Riddell 
<Kinnison> mjg59: I thought the dcop thing was the KDE one
<mjg59> Kinnison: No, that just sends a message to KDE to log you off
<Kinnison> mjg59: Oh, it's not interactive ?
<mjg59> Kinnison: If there's a KDE power policy manager running, it probably ought to be in charge
<Kinnison> mjg59: right, do you happen to know the name of such?
<mjg59> Kinnison: Not off the top of my head - Riddell?
<Riddell> Kinnison: it'll be kded for now, may change to kpowersave soon
<mjg59> Treenaks: I guess it's possible to just add a wrapper that makes sure it links against the right library
<Kinnison> Riddell: so if I make it drop out if kded or kpowersave is seen, that'll do the trick?
<Riddell> Kinnison: actually  `dcop kded | grep klaptopdaemon`
<Riddell> Kinnison: yes
<Kinnison> umm
<mjg59> Treenaks: Where does mesa end up on an nvidia sysem?
<Kinnison> Riddell: I don't understand dcop so can you construct for me a shell fragment to DTRT?
<Kinnison> Riddell: and pastebin it or something?
<Riddell> Kinnison: if  `dcop kded | grep klaptopdaemon`  return klaptopdaemon then it's running, else it's not
<Kinnison> Riddell: if [ "x$(dcop kded | grep klaptopdaemon)" != x ] ; then \n exit\nfi
<Kinnison> Riddell: ?
<Kinnison> Riddell: and for kpowersave?
<Treenaks> mjg59: uh, which file?
<Treenaks> mjg59: I have libGL.so.1.2.xlibmesa in /usr/lib/nvidia
<Riddell> Kinnison: look right yes.  just pidof kpowersave would work
<Kinnison> Riddell: righty
<mjg59> Treenaks: So it gets moved there when you install the nvidia drivers?
<Treenaks> mjg59: /usr/lib/libGL.so.1
<Treenaks> diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.xlibmesa
<Treenaks> /usr/lib/libGL.so.1.2
<Treenaks> diverted by nvidia-glx to: /usr/lib/nvidia/libGL.so.1.2.xlibmesa
<mjg59> Treenaks: Ok, thanks
<Riddell> _mvo_: ping
<mvo> Riddell: pong
<Riddell> 11:07 < Riddell> mvo: http://muse.19inch.net/~jr/tmp/gnome-app-install.diff
<Riddell> 11:07 < Riddell> mvo: quite a broken clean rule that package has
<Kinnison> Riddell: I've updated the diff I listed above, can you check it out?
<Riddell> Kinnison: good for me thanks
<Kinnison> Riddell: cool, ta
<infinity> mjg59: I don't think there's much hope for Xgl working with fglrx/nvidia... Preloading the mesa libGL will hideously break the custom libGLs, which will break GL rendering, which would sort of defeat the purpose of Xgl...
<pitti> infinity: in that case, having xgl doesn't make much sense at all? how did the novell guys solve that?
<pitti> infinity: I have yet to see an OSS driver which provides the necessary performance...
<infinity> pitti: Hrm?  It'll work fine with free OpenGL implementations, of which we have many.
<mjg59> infinity: Xgl uses the custom libGLs, but then any clients use Mesa
<mjg59> infinity: It works fine
<pitti> infinity: well, hw opengl works OOTB on my laptop at least, but it's performance is still pretty poor
<infinity> pitti: the radeon driver has pretty decent OpenGL performance on most cards except for the shiniest and newest.
<pitti> infinity: hm, if 'shiniest an newest' includes cards which are two years old ...
<Treenaks> pitti: Radeon 9600 works fine with the 'radeon' driver for me
<infinity> pitti: No... Shiniest and newest is pretty shiny and new... radeon works well with full accel on my X300.
<Treenaks> pitti: (+ accelerated OpenGL on)
<pitti> Treenaks: cool, that didn't yet work half a year ago even
<infinity> mjg59: Hrm.  Alright.
<Treenaks> pitti: no, it's a Dapper Exclusive ;)
<pitti> Treenaks: the only driver that really works on my flatmate's breezy is vesa :(
<HiddenWolf> pitti: I guess there is some sense to novell shipping this crack
<Treenaks> pitti: yeughrgh
<pitti> Treenaks: (he has some 9600ish card, too)
<infinity> mjg59: Should I "fix" LRM to divert libGL.so.1.2 to the same location for both hfglrx and nvidia, so you can do hideous preload hacks on it.
<infinity> mjg59: ?
<pitti> HiddenWolf: right, that's why I'm interested in how the heck they got decent drivers 
<mjg59> infinity: That would possibly be helpful
<mjg59> pitti: It works "acceptably" with the open drivers on my (quite slow) i855
<pitti> nice to hear
<HiddenWolf> pitti: throwing a lot of effort into it, and having some kind of check "if you use X or Y driver, enable, otherwise print bad luck"
<pitti> so it seems that the radeon driver guys really did some great work recently :)
<infinity> Yeah, it's not mind-blowingly fast here either, but it does work.  And, entertainingly, is a bit more stable than fglrx.
<mjg59> The expose effect is nice
<mjg59> Especially with wobbly windows
<infinity> mjg59: Right now, they're diverted to /usr/lib/{nvidia,fglrx}/libGL.so.1.2.xlibmesa
<mjg59> infinity: Thanks
<infinity> mjg59: So, aside from the obvious path diffence, it's reasoanably standard.
<mjg59> infinity: Can probably deal with that
<infinity> mjg59: I could change them to both go to /usr/lib/lrm or something...
<mjg59> infinity: If you feel like some misery :) To be honest, having two locations to check isn't too much pain
<infinity> mjg59: Of course, this all falls apart when users install binary drivers by hand anyway (and lots of them do... ubuntu-users and the forums are filled with people doing it daily)
<mjg59> Well, they get to keep both halves
<mjg59> If they overwrite Mesa, well
<infinity> mjg59: Apparently, it's more fun to download binary drivers yourself than to install ones that Just Work.
<mjg59> Yay it's queued now
<HiddenWolf> infinity: don't forget things like that automatix crap
* sivang wonders when bazaar.ubuntu.com will be ported to bzr instead o of baz.
<Kamion> ogra: I can process NEW just fine, you don't need to bug Kinnison about it :)
<ogra> Kamion, i didnt, he showed up himself ... asking :)
* ogra guesses Kinnison highlights on soyuz :)
<ogra> oh, and i was wrong, its about promotion to main, not NEW ... *sigh*
<Kamion> indeed, that part I can't do
<carlos> pitti: hi
* pitti hugs carlos, hello!
<carlos> pitti: could you join #launchpad?
<Mithrandir> seb128: what's the reason for glade Recommending automake1.4?  Can we up it to something a bit more recent, like 1.9?
<siretart> ** (gnome-power-manager:13117): WARNING **: gpm_brightness_level_update_hw: No reply within specified time
<jeroenvrp> please devels, look at bug #6608
<Ubugtu> malone bug 6608 in Ubuntu Dapper "Sound not enabled (muted) and sound applet showing headphone (not volume)" [Normal,Unconfirmed]  http://launchpad.net/bugs/6608
<siretart> anyone has a clue what this could come from?
<jeroenvrp> https://launchpad.net/distros/ubuntu/+bug/6608
<Ubugtu> malone bug 6608 in Ubuntu Dapper "Sound not enabled (muted) and sound applet showing headphone (not volume)" [Normal,Unconfirmed]  
<jeroenvrp> it's about the sound in dapper
<jeroenvrp>  please look at my last comment in that bug btw
<seb128> Mithrandir: I don't know, probably for the autogenerated code stuff, but nobody uses it
<sebest_> mjg59,  hello, i can comfirm that for xgl and nvidia i must adjust LD_LIBRARY_PATH=/usr/lib/nvidia for compiz, after having linked libGL.so.1 -> libGL.so.1.2.xlibmesa
<Mithrandir> seb128: mind if I nuke it?
<seb128> Mithrandir: not at all, does it hurt? Maybe move it as Suggests rather than dropping it?
<mjg59> sebest_: Does LD_PRELOAD not work?
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 3 released | If your initramfs is broken in any way, please save a copy for infinity
<Mithrandir> seb128: it made me upset, does that count?  :-)  I'd just be bumping it to automake 1.9 instaead.
<Mithrandir> instead, even
<seb128> dunno if that works with 1.9, that would require some playing with it
<seb128> but as said nobody uses it and I don't think we should bother
<seb128> drop or update the version as you prefer
<Mithrandir> ok, I'll drop it then.
<seb128> k
<sebest_> mjg59,  i'll test now
<tepsipakki> mjg59: how to use LD_PRELOAD? for compiz only or also for Xgl?
<mjg59> tepsipakki: Only for compiz
<sebest_> tepsipakki, only for compiz
<tepsipakki> ok, thanks
<sebest_> mjg59, it works
<tepsipakki> sebest: how did you use it?-)
<sebest_> for people interested in xgl with nvidia: http://pastebin.com/555795
<tepsipakki> sebest: thanks! Mine just crashes while writing the LD_PRE...
<tepsipakki> ;)
<tepsipakki> I had Xgl running from gdm
<sebest_> with this script i have Xgl running perfectly
<Treenaks> My compiz crashes
<sebest_> tepsipakki, do you start it from a shell?
<sebest_> i mean a console
<sebest_> i stop gdm and the like
<tepsipakki> gdm starts another server, which is Xgl, but I'll try running it directly
<mjg59> Right, fixed compiz uploaded
<mjg59> (Should avoid the need to LD_PRELOAD)
<sebest_> the script that i paste bien, must be run when no other server X is running
<sebest_> mjg59, so on next compiz update, no need for the PRELOAD?
<mjg59> Correct
<sebest_> i also noticed that i mustn't use the "gconf" plugin otherwise the gnome-window-decorator doesn't work
<mjg59> If you use the gconf plugin, you have to specify modules in gconf rather than on the command line
<sebest_> mjg59, yes, but if i combien gconf + the plugin name on the command line the decorator doesn't work
<sebest_> this issue is documented here: http://gentoo-wiki.com/HOWTO_XGL
<sebest_> s/combien/combine
<mjg59> sebest_: Yes. If you use the gconf plugin, you have to specify modules in gconf rather than on the command line.
* Kinnison lunches over a workrave break
<Treenaks> sebest_: I get find_mesa_visual returned NULL for visualID = 0x002c
<Treenaks> sebest_: now
<HiddenWolf> Good luck guys =)
<sebest_> Treenaks, what program display this message?
<sebest_> Xgl, compiz, the decorator?
<infinity> mjg59: Why is compiz built against QT4?
<Treenaks> sebest_: compiz, I think
<Treenaks> sebest_: no, Xgl.. compiz just segfaults
<mjg59> infinity: kde-window-decorator support
<sebest_> Treenaks, what is your hardware?
<infinity> mjg59: Which QT3 didn't have?
<mjg59> infinity: It seemed happy building against QT4 and didn't seem happy building against QT3
<infinity> Fair enough. :)
<mjg59> I prefer not to get QT on me, so, well
<Treenaks> sebest_: Nvidia GeForce 7800 GTX (PCI-E)
<mjg59> Treenaks: Which Xgl package are you using?
<Treenaks> mjg59: hm.. good point
<Treenaks> mjg59: I _was_ using a custom-built 0ubuntu1, it seems
<sebest_> Treenaks, also make sure that you are using the nvidia proprietary drivers
<sebest_> that dri and GLcore are commented
<sebest_> and that glx is loaded
<Treenaks> sebest_: ah,, commented.. good point
<Treenaks> sebest_: those aren't commented, glx is loaded
<sebest_> and that you have the restricted drivers installed
<infinity> mjg59: Should xserver-xgl recommend or suggest compiz?
<sebest_> and that the nvidia module is loaded
<Treenaks> sebest_: it is
<Treenaks> sebest_: I think it's the X config thing
<mjg59> infinity: I'm not sure
<Treenaks> infinity: it works without compiz, just not in 'l33t mode' (right?)
<mvo> infinity: I get a conffile prompt on /etc/mkinitramfs/initramfs .conf on breezy->dapper upgrade. is this a pknown problem?
<infinity> Treenaks: Hence a suggest or recommend, not a dependency.
<infinity> mvo: Yes, I'll fix it in my next upload.
<mvo> infinity: thanks
<infinity> mvo: I don't suppose you have a breezy system where you can get me dpkg's idea of the md5sum of that conffile?
<mvo> infinity: in a couple of minutes (~30m)
<Kyral> Morning
* infinity wonders why he doesn't get "karma" for fixing bugs, but he does for trivial things like adding comments and marking as duplicates...
<infinity> Bizarre system.
<ogra> yes, i didnt even get karma for adding bzr branches ...
<ogra> (that should raise it by 1000 for every branch :) )
<infinity> I guess my mistake is always closing bugs and putting the comment in the close bit.. I'd have karma through the roof if I'd commented on every bug I closed before I closed it. :)
<infinity> Oh well.  Here's hoping no one uses karma for anything useful.
<Menoz> hi all! I'm trying to set up an ubuntu repository, but when I try to make an update from a client, I get (sometimes, not alwais) this error:
<Menoz> apt-get update
<Menoz> Err http://192.168.2.10 breezy Release.gpg
<Menoz>   Bad header line
<Menoz> Hit http://192.168.2.10 breezy Release
<Menoz> Ign http://192.168.2.10 breezy/main Packages
<Menoz> Ign http://192.168.2.10 breezy/universe Packages
<Menoz> Hit http://192.168.2.10 breezy/main Packages
<Menoz> Hit http://192.168.2.10 breezy/universe Packages
<Menoz> Failed to fetch http://192.168.2.10/ubuntu/dists/breezy/Release.gpg  Bad header line
<Menoz> Reading package lists... Done
<Menoz> E: Some index files failed to download, they have been ignored, or old ones used instead.
<Menoz> can someone hel me?
<mvo> Kamion: are you interessted in flight3 install reports from users? 
<ogra> Menoz, this is not a support channel, please ask in #ubuntu
<Kamion> mvo: bug reports as usual
<Menoz> I thought that "setting up an ubuntu repository" was a devel problem
<Kamion> mvo: sure, as long as they don't mind many of them being marked as duplicates
<Menoz> pardon
<mammadori> kamion: tnx for answer, there is a livecd bugs page?
<Kamion> mammadori: there are bug lists for each of the individual components
<mammadori> Kamion: ubts, malone or what?
<Kamion> stuff like unionfs and squashfs generally belongs along with kernel bugs, of course
<Kamion> malone
<mammadori> Kamion: tnx
<Kamion> janimo: I meant to ask you, how come the libxfce4mcs in NEW builds libxfce4mcs-client3 and libxfce4mcs-manager3 while the current binaries in the archive are libxfce4mcs-client-2 and libxfce4mcs-manager-2 (note the dashes)?
<Kamion> is that an error?
<janimo> Kamion, with the new uploads I made the binaries conform to the lib packaging guid
<janimo> and follow sonames
<infinity> Yeah, the new ones look correct to me.
<janimo> I talked to debian packagers and they said they'll do the same
<Kamion> ok, if you've coordinated it then that's fine
<janimo> btw are you handling NEW?
<janimo> infinity for the xf packages which currently picked up 4.2 libs do I need new uploads with build1 versions to pick upu the new depends?
* janimo slaps himself for failing to mention the binary names change in the changelog
<pitti> Kamion: can you please accept language-pack-ka and language-pack-gnome-ka for breezy-updates? the last langpack update broke these
<infinity> janimo: Yes, you'll obviously need new builds to build against the new libs.
<Kamion> janimo: yes, working on NEW
<Kamion> janimo: I was surprised to see them built against the old libs, certainly; I was expecting a build-dependency to ensure the outer packages didn't build until the inner ones were accepted
<Kamion> pitti: any idea how I do breezy-updates at the moment? it's soyuz now, right?
<janimo> Kamion, that's because I frogot to explicitely dep on newer libs (pending upload)
<Kamion> right
<Kamion> libxfce4mcs accepted anyway
<janimo> and thought that just retriggering the builds in LP will do 
<janimo> thanks
<pitti> Kamion: no idea, I uploaded it to the jackass queue (as directed)
<janimo> so islibxfce4util right? that changed binary name as well
<janimo> I saw it built yesterday
<Kamion> that looked ok, I processed it yesterday
<Kinnison> Kamion: as I understand it, source uploads for -updates should go to upload.ubuntu.com
<Kamion> or the day before, or something
<pitti> Kamion: hm, it's not in jackass' accepted, and ISTR that somebody said they are already handled by soyuz
<Kamion> Kinnison: yeah, but do I approve them in katie or in soyuz?
<Kinnison> Kamion: but binaries won't be built until another rev of the codeline on drescher due to a bug which cprov has recently fixed
<Kinnison> Kamion: the approval would be in soyuz
<Kinnison> Kamion: katie is only used for security
<Kamion> Kinnison: nothing in the unapproved queue though
<Kamion> damnit I need a madison for soyuz that isn't potentially six hours out of date
<Kinnison> Kamion: queue -R breezy -Q unapproved info \*
<Kamion> aha; would be nice if there were some way to get a report for all distroreleases
<Kinnison> Kamion: the queues are currently split by distrorelease (known issue, being worked on)
<Kamion> what do I do, queue -R breezy -Q unapproved accept?
* Kamion lunches
<Kinnison> Kamion: ar
<Kamion> is that a yes? :)
* Kinnison nods
<Kinnison> Sorry, I was unclear
<Kamion> pitti: ok, done
<Kamion> thanks Kinnison
<dholbach> infinity, lamont: could you please give back opal?
<pitti> thank you
<Kamion> this workflow is quite good actually
<dholbach> infinity, lamont: it's in MANUALDEPWAIT
<Kamion> ok, any pending promotions-to-main/demotions-to-universe people need?
<siretart> Kamion: yes, the libxine-extracodecs stuff
<siretart> but thats a universe/multiverse demotion
<pitti> Kamion: mysql-dfsg-4.1 to universe would be nice
<pitti> Kamion: and mozilla, if that's already possible (enigmail built successfully, so it should actually)
<Kamion> I don't have an anastacia yet
<pitti> mysql was ready to go even before the soyuz switch, that shuold be ok
<pitti> Kamion: oh, current tool doesn't do sanity checking?
<ogra> Kamion, python-gst0.10 indeed :)
<Kamion> pitti: no
<Kamion> ogra: cprov did that one
<pitti> Kamion: rdepends looks good, though
<Kamion> pitti: including libmysqlclient14{,-dev}?
<pitti> Kamion: yes, mysql is safe
<pitti> Kamion: I meant, rdepends for mozilla-dev
<Kamion> I might see if I can hack together a really crappy version of anastacia that doesn't need the archive database
<ogra> Kamion, ah, nice :)
<Kinnison> mjg59: I've been sorting out the acpid bugs, I'm down to two, one of which I'm unconvinced is a bug, the other is the adm permissions thing
<mjg59> Kinnison: adm permissions?
<Kinnison> mjg59: One solution to the "logfile should be group 'adm'" bug is presented in http://people.ubuntu.com/~dsilver/acpid-9-10.diff which adds a logfilegroup argument to acpid which defaults to 'adm' and which fchown()s the log on acpid startup
<mjg59> Ah
<mjg59> Ok
<Kinnison> https://launchpad.net/distros/ubuntu/+source/acpid/+bug/28352
<Ubugtu> malone bug 28352 in acpid "log file should be gid: adm" [Normal,Unconfirmed]  
<Kinnison> Do you think this is a good solution?
* Kinnison is still feeling his way around the preferred ways to fix these kinds of issues
<mjg59> I'd have thought the ideal solution would be to shift to syslog, but...
<Kinnison> hmm, not sure that'd be neat. would syslog automatically provide a split out logfile?
* Kinnison has never used syslog in anger
<Kamion> no, if you made it facility daemon then it'd go to daemon.log though
<Kinnison> currently it's quite nice to have the acpid log split out
<Kamion> hmm, I find that a hindrance often
<Kinnison> Kamion: Oh?
<Kamion> when trying to figure out where the heck something logs, the fewer choices the better
<Keybuk> mvo: I thought you fixed update-notifier? :)
<Kamion> and with syslog, then it often ends up in multiple places (e.g. /var/log/syslog as well as everywhere else), which is good for findability
* Kinnison sees your argument
* Kinnison hmms
<Kamion> but it depends exactly how verbose acpid can be, I guess; for example it's pretty obvious that apache logs should be split out
<Kinnison> It can be quite verbose
<Kamion> the question is whether acpid is more like dhcpd, sshd, smartd - or more like apache, exim, innd
<Kamion> IMO
* Kinnison sees an average of approx 1 line of log per second
<Kinnison> (in batches of 15 lines or so, every 15 seconds or so)
<Kamion> urgh, that's loads
<Kinnison> depending on the battery states etc, charging vs. discharging etc
<Kamion> is that in some special debug mode?
<Kinnison> no, that's standard logging as we do in the package currently
<mvo> Keybuk: fixed what in update-notifier? the "it eats my cpu" problem?
<Kamion> ok, in that case I can see that it should be a separate log
<Kamion> file
<Kamion> I'd also argue it should be made less obnoxiously verbose by default though
<Kinnison> heh
<Kinnison> It's not consistent
<Kinnison> E.g. since I booted this morning I've had ca. 60k lines
<Kinnison> It depends on when events come in basically
<Kinnison> I can certainly see an argument for simplifying and shrinking the default log output
<Kinnison> However it still deserves its separate logfile in the short term I feel
* Kamion nods
<Kinnison> I'll send 0ubuntu10 to the archive and file a bug on simplifying the log output
<Kinnison> Umm, 1ubuntu10
<Kinnison> I know what I mean, oh yes
<spacey> Diziet: ping
<Kamion> siretart: libxine-extracodecs | 1.1.1+ubuntu1-1 | dapper/multiverse | amd64, i386, powerpc
<Kamion> siretart: it was that way already - is there something else that needs to be moved?
<siretart> Kamion: seems to be sorted out, I will as slomo again
<siretart> Kamion: he asked me some days ago to write an email to you/elmo because of that
<Kamion> pitti: mysql-dfsg-4.1 demoted I think, change-override.py is, er, rather quiet by default
<pitti> thanks
<pitti> Kamion: what do we do about mozilla? wait for your anastacia?
<siretart> Kamion: ok, sorry for bugging about xine, everythings allright about that.
<Kamion> wait for *an* anastacia if not mine, anyway
<Kamion> siretart: ok, no problem
<Kinnison> what did anastacia do?
<ogra> http://people.ubuntu.com/~mdz/anastacia.txt
<ogra> throw out that file above
<siretart> Kamion: ah, if you have madison at hand, could you please tell me, in what component the binary package 'libxine1c2' is?
<Kinnison> ogra: is that essentially a diff between the component overrides and germinate's output?
<siretart> Kamion: If it is still in universe, it needs to go to multiverse
<ogra> Kinnison, i dont know the internals ... i just know the output ...
<lamont> Kinnison: do we have a buildd-mgmt ui yet?
<Kamion> libxine1c2 | 1.1.1+ubuntu1-1 | dapper/universe | amd64, i386, powerpc
<Kinnison> lamont: ask someone working on soyuz :-)
<Kinnison> lamont: E.g. cprov
<lamont> right.  my bad
<Kinnison> although he just went for lunch :-)
<Kamion> siretart: moved to multiverse
<Kamion> Kinnison: diff> yes
<Kinnison> Kamion: right
<Kamion> although phrased as human-reviewable instructions of what to do to bring the overrides into sync with germinate
<siretart> Kamion: thanks!
<Kinnison> Kamion: did anastacia work from projectB or from the archive?
<Kamion> Kinnison: projectB
<Kinnison> :-(
<Kamion> right, I was going to have a brief look at temporarily porting it to use Packages/Sources, but I think I have too much else to do
* Kinnison nods
<dholbach> janimo: is the ruby thing on revu something xfce-related?
<janimo> dholbach, nope
<janimo> oh wait what ruby thing??
<janimo> you mean lua? I don;t remember any ruby package
<dholbach> janimo: ah no, sorry *lua*
<janimo> yeah the other obscure lil language :)
<dholbach> :-p
<janimo> well I mean to do some lua bindings to xfce in the future so it's indirectly related
<janimo> it'd be nice to have gtk-lua in dapper though
<dholbach> janimo: Kinnison will be delighted.
<janimo> I suppose :)
<janimo> dholbach, do you have time for REVU besides doing the gnome uploads? :)
<janimo> gotta sell me some time management tips
<dholbach> janimo: GNOME upload is done. bug triage is pending. but today it REVU day, so... :-)
<janimo> I actually enjoyed those lua-gtk bindings, I started learning gtk using them since the C api is too messy at first
* Kinnison wonders why everyone assumes he's in love with lua
<janimo> because you are? :)
<pitti> Maintainer: Daniel Silverstone <dsilvers@debian.org>
<janimo> oh that would also mean Ian is in love with firefox ;)\
<dholbach> janimo: He loves it in a very special way. :-)
<Kamion> Mithrandir: something's wrong with debconffilter startup after merging that espresso change
<Kamion> Mithrandir: it starts up user-setup on the autopartitioning page
<Mithrandir> not with the latest merge
<Mithrandir> revno: 729
<Mithrandir> committer: Tollef Fog Heen <tfheen@golem>
<Mithrandir> branch nick: trunk
<Mithrandir> timestamp: Wed 2006-02-15 15:24:21 +0100
<Mithrandir> message: more named constants
<Mithrandir> that one fixes it for me
<Kamion> I have that
<Mithrandir> hmm, weird
<Kamion> also you don't use BREADCRUMB_* anywhere
<Mithrandir> then your merge is botched
<Kamion> bugger
<Mithrandir> what does gtkui.py:192 look like for you?
<Mithrandir>             if self.current_page == STEP_USER_INFO:
<Mithrandir> is what I have.
<Kamion> yes, same
<Mithrandir> uh, sorry.-
<Mithrandir> mea culpa, I shelved
<Mithrandir> and forgot to unshelve
<Mithrandir> that is, something ate the .rej
<Mithrandir> ok, pushed, same location
<Kamion> re-merged, debconffiltering still screwy
<Kamion> I'll investigate
<Mithrandir> it works for me, so.
<Mithrandir> try rsyncing down the tree and diff-ing them?
<Kamion> :q
<Kamion> er
<Kamion> Mithrandir: could you chmod go+r debian/changelog espresso/frontend/gtkui.py in your branch on rookery please?
<Mithrandir> Kamion: done
<janimo> Kamion, a bzr get http://people.ubuntu.com/~cjwatson/seeds/dapper gives 404 on a specific weave did something change lately?
<janimo> I haven't merged the seeds in a while. Both pull and merge give the same error
<janimo> and pull corrupted a working dir
<janimo> I am using a 0.8pre from jbailey's daily but of a few weeks ago if that helps
<Kamion> janimo: try disabling your HTTP proxy if you're using one
<Kamion> a local bzr get on people.ubuntu.com works fine
<janimo> Kamion, I have tried a get with bzr 0.7 (dapper version) and it works, let's see about the merge. sorry for the noise, it may be some bzr incompatibility
<janimo> and the proxy thing I recall giving problems earlier but only by not showing updates not corrupting stuff
<janimo> I guess there's no way of fixing an archvive on which bzr check reports errors
<Kamion> Mithrandir: not done
<Kamion> cjwatson@rookery:/home/tfheen/public_html/bzr/espresso/trunk$ find ! -perm +044
<Kamion> ./debian/changelog
<Kamion> ./espresso/frontend/gtkui.py
<Kinnison> Kamion: that's a known bzr merge bug
<Kinnison> Kamion: the conflict resolution sometimes buggers up the perms
<Kinnison> mjg59: As a techboard person can you please set up a poll on ubuntu-dev about changelog formats for closing bugs in malone?
<Kinnison> mjg59: the formats we've come up with so far are: 'closes: malone#nnnn' 'malone: #nnnn' and 'launchpad: #nnnn'
<dholbach> and please include the changelog of the upload as a comment in the bug! :)
<Kamion> Kinnison: well, I need it fixed manually
* Kamion promotes mysql-common back to main (WHY ON EARTH did it end up in universe?!) which should fix desktop installability
<Kamion> change-override scares me
<seb128> Kinnison: I do use "Ubuntu: #nnnnn" :)
<seb128> hum, I've to run for half an hour, bbl
<Kinnison> seb128: Hmm
<Kinnison> mjg59: any ideas about bug 31251
<Ubugtu> malone bug 31251 in gnome-power-manager "[Dapper Flight 3]  The consumption of energy of the monitor with use of the battery is not reduced" [Normal,Unconfirmed]  http://launchpad.net/bugs/31251
<mjg59> Kinnison: Brightness change should be automatic on ac switch
<jono> hi all
<mjg59> We don't have any code to control that on Compaqs
<mjg59> jono: You've got your Xgl
<jono> mjg59, yeah Treenaks was just saying :)
<Treenaks> mjg59: I'm getting this when I run Xgl:
<Treenaks> No matching visual for __GLcontextMode with visual class = 1 (32774), nplanes = 32
<mjg59> Treenaks: Yeah, somebody else had that. No idea why.
<Treenaks> and any attempt to draw on it gets me: X Error of failed request:  BadAlloc (insufficient resources for operation)
<Kamion> Mithrandir: ping? help
<Treenaks> mjg59: oh, and when I get the BadAlloc, the Xgl window closes and re-opens, and I get this message: 
<jono> I am still getting initd errors when I boot dapper in vmware
<Treenaks> mjg59: find_mesa_visual returned NULL for visualID = 0x002d
<jono> I submitted a bug some time ago, but it still seems to plague dapper
<Kinnison> mjg59: is that no code *yet* or no code at all expected?
<mjg59> Kinnison: It's "I don't have this hardware and have no idea how to speak to it"
<Kinnison> mjg59: fair enough, thanks
* Kinnison will tidy the bug report a little and then leave it be
<Kinnison> There, bug 31251 has a slightly better title/description now
<Ubugtu> malone bug 31251 in gnome-power-manager "Lack programmatic support for brightness adjustment of compaq laptops" [Normal,Needs info]  http://launchpad.net/bugs/31251
<Kinnison> I think I'll pass it over to hal too
<Kinnison> pitti: merry xmas
<mjg59> Kinnison: Yeah, either hal or the kernel
<Kinnison> I've given it to hal pending any better idea
<Kinnison> seb128: I'm trying to track down what puts gnome-power-manager into the default session
<Kinnison> seb128: any ideas?
<Kinnison> mjg59: I have some acpi-support changes. Do you want them or should I upload?
<Riddell> mvo: did you upload app-install-data?
<mvo> Riddell: yes
<mvo> Binary: app-install-data gnome-app-install
<mvo> Architecture: source
<mvo> Version: 0.1.11
<mvo> the package is NEW so it may take a bit
* Kamion notices ubuntu-desktop installable and kicks off live filesystem builds
<mjg59> Kinnison: I trust you
<Riddell> mvo: yep, was just wondering why it wasn't on https://launchpad.net/people/mvo/+packages
<Riddell> I'm sure I've seen other NEW packages on those pages
<Kinnison> mjg59: mostly it's s.xscreensaver.gnome-screensaver.
<mjg59> Kinnison: Uhm. Shouldn't be necessary (and probably won't work properly)
<mjg59> gnome-screensaver-command needs dbus
<mjg59> So you need to set the dbus bus address variables
<mvo> Riddell: it's in there under "uploaded" 
<Kinnison> mjg59: Arse, I'd have found that the moment I tested, but I hadn't got that far yet
<mjg59> Which are "awkward" to get hold of
<Kamion> mvo: *clicketyclick* not any more
* Kinnison nods
<mjg59> Kinnison: I'd suggest just dropping the screensaver stuff
<mvo> Kamion: thanks :)
<Kinnison> mjg59: make the tosh lock button useless
<mjg59> Let the user agents deal with it
<Kinnison> mjg59: unless I can make it make a fake keypress I guess
<mjg59> Kinnison: No, that ought to be generating a KEY_COFFEE keycode now
<mjg59> (Did I not upload that? Bad me)
<seb128> Kinnison: does it put a .desktop to /usr/share/autostart?
* Kamion fails to believe all the "Bugs: 0" lines in https://launchpad.net/people/kamion/+packages
<Kinnison> seb128: aha, it does, thanks
<Riddell> it would be very cool if those +packages pages had build status on them
<seb128> Kinnison: np
<Kinnison> mjg59: I'll do that then
<mjg59> Kinnison: Then we need gnome-settings-daemon to do the right thing
<Kinnison> mjg59: aye
<dholbach> lamont, infinity: could you please give back opal
<Kinnison> mjg59: bizarrely acpi_fakekey 152 (coffee) doesn't result in an event which xev can spot
<robertj> I did a sudo apt-get install pbuilder && sudo pbuilder create and it was doing good when I went to bed, but  I just checked in on it and it says that it has unmet deps
<mjg59> Kinnison: Ah. KEY_COFFEE probably doesn't appear in the default keymap.
<mjg59> Kinnison: Minor kernel hackage required - alternatively, setkeycode a random scancode to it for now, and see if that works
<Kinnison> mjg59: recommended keycode to map it to?
<mjg59> Kinnison: The keycode has to be KEY_COFFEE
<mjg59> As far as scancodes go - one that's not currently mapped to anything?
<Kinnison> the scancode is key_coffee
<mjg59> No
<Kinnison> assuming i'm reading this right
<mjg59> That's the keycode
<mjg59> The scancode is what comes off the keyboard
<seb128> elmo: could you sync gtk-doc (from incoming)?
<mdz> has anyone else seen a problem where gnome-screensaver activation results in screen corruption?
<mdz> permanent corruption, even
<mjg59> mdz: No, but does it only happen with 3D screensavers?
<Kinnison> mjg59: KEY_Q == 16, which is the *scancode* for the Q key
<Kinnison> mjg59: according to showkey -s anyway
<mjg59> Kinnison: That may be true for low-numbered keys
<Kinnison> aah
<mjg59> It's the higher ones, where there isn't a 1:1 mapping, that are the problem
<Kinnison> right
* Kinnison sees
<mdz> mjg59: unknown; I go to sleep, wake up, and it's fucked
<mdz> on my desktop (radeon RV100 QY)
<mjg59> mdz: Ah. Hm.
<mjg59> No, haven't seen that. My suspicion would be X.
<sebest_> does compiz could work without xgl, but with just composiste accelerated by exa?
<mdz> it presumably came in with some other random stuff in 7.0.0-0ubuntu1
<mjg59> sebest_: No
<sebest_> mjg59, compiz is only for opengl compositing?
<mjg59> sebest_: Yes
<sebest_> what exa will be usefull for? basic compositing (transparency / shadow)?
<Kinnison> mjg59: This is rather odd then, KEY_COFFEE generates nothing, not scan or keycode on its own, and I can't work out therefore what the kernel would want from me in order to map it to a keycode
<mjg59> Kinnison: Just any scancode that currently isn't used
<mjg59> The problem is that the kernel drops keycodes on the floor if it doesn't think the currently attached keyboard could generate them
<mjg59> (Which seems mad, but)
<Kinnison> mjg59: Aye, but my issue is that I can't work out how to find the scancode which I need to map
<Kinnison> mjg59: given that converting 152 to hex didn't work
<Kinnison> mjg59: nor did prefixing that with e0
* Kinnison isn't good at this very very low level guff
<mjg59> Kinnison: Really. Any scancode.
<mjg59> As long as it's not currently used by anything, you can use any of them
* Kinnison is confused
<mjg59> Nothing's actually going to generate that scancode
<Kinnison> so I just pick J-random scancode out of my arse
<Kinnison> right
* Kinnison tries
<mjg59> We just need to get the keycode into the kernel's idea of what the keyboard can generate
<Kinnison> right, okay, so having done that, it maps to X keycode 146
<Kinnison> which has no sym
<mjg59> Yes, that's fine
<mjg59> It should now also be appearing on dbus, but that's less of an issue
<Keybuk> coo ... the Windows XP setup doesn't know about SATA ... "Disk 0 at Id 0 on bus 0 on atapi" (twice)
<Kinnison> bwahaha, if I set the relevant keycode in gconf to 0x92 (screensaver in gnome-settings-daemon) then I can lock screen
<Kinnison> mjg59: right, should acpi-support pluck a scancode out of its arse to use or is this a 'file a bug on benc' situation?
<mjg59> Kinnison: There you go
<mjg59> Kinnison: Iz kernel boog
<Kinnison> yup, okay, I'll move on, ta
<Keybuk> mjg59: while you're here ... any particular opinion on the increasing number of "I have a system with two cards, the drivers for which conflict" bugs?
<Keybuk> ie. a sound card which ALSA can support, and an onboard sound chip which only OSS can
<Keybuk> or a sound card and a TV tuner
<mjg59> Keybuk: Why's that a problem?
<mjg59> ALSA and OSS can coexist
<mjg59> (I believe)
<Keybuk> loading OSS kinda kicks out ALSA's OSS emulation <g>
<BenC> mjg59: but there's the case where two sound cards use the same "chip id", but one only works with the oss driver, and the other only with the alsa driver
<mjg59> Oh, right
<mjg59> Fix the ALSA driver :p
<BenC> or one is part of a tv-tuner where the alsa/oss driver is built into the same "video+sound" driver
<mjg59> No, I don't think there's a good answer in that case
<BenC> yeah, it's a matter of too many ppl working on the same thing, they just need to collaborate and consolidate
<sivang> re
<sivang> mjg59: how is xgl ? :)
<mjg59> sivang: Fine
<mjg59> Kinnison: You suck :p
<Kinnison> mjg59: I do?
<mjg59> Kinnison: s/unstable/dapper/
<Kinnison> mjg59: what have I buggered up now?
<Kinnison> mjg59: d'oh
* Kinnison changed that once
* Kinnison blames debian-changelog-mode
<Kinnison> sodding thing
<sivang> heh
<seb128> Kamion: volume.label = '/ for ubuntu' (string) ... is that the installer setting such label?
<seb128> Kamion: is there some case for the label? we have #31443 saying that "ubuntu" should be "Ubuntu"
<Kamion> seb128: I certainly don't remember branding that
<Kamion> which would have been necessary
<Kamion> the installer does allow the user to enter it by hand though
<Kamion> seb128: oh, it could be generated from the hostname, which is lower-case ubuntu
<Kinnison> mjg59: bug 31534
<Ubugtu> malone bug 31534 in linux-source-2.6.15 "KEY_COFFEE needs a scancode" [Normal,Unconfirmed]  http://launchpad.net/bugs/31534
<Kamion> seb128: I can't find it in hal, but the hostname would be my guess
<HiddenWolf> key_coffee?
<Kinnison> Kamion: what time is the distro team meeting tomorrow?
<Keybuk> HiddenWolf: "Press the coffee key"
<HiddenWolf> Keybuk: what is a coffee key?
<HiddenWolf> is it an expression I missed out on?
<Keybuk> HiddenWolf: a key that gets you coffee?
<Kamion> Kinnison: 1400 I believe
<jono> hi all
<Keybuk> it's the moniker for lock-screen/take-a-break/etc. keys usually
<HiddenWolf> Keybuk: pc's make coffee?
<Kamion> Kinnison: are you subscribed to ubuntu-devel-announce@?
<HiddenWolf> ah
<HiddenWolf> thank you Keybuk
<jono> Kamion, any kind of loose ETA when a flight CD will be released with the GUI installer?
<Kamion> Kinnison: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-February/000078.html
<jono> I need to write the installation chapter sometime soon
<Kinnison> Kamion: right, I didn't know that was the "Dapper status update meeting"
<Kinnison> Kamion: thanks
<seb128> Kamion: the bug is #31443 and the guy installed with hoary
<Kamion> jono: this week, but if you write a book based on how it looks now I have no sympathy ;)
<seb128> Kamion: it was in case you have an idea from where the label comes
<sivang> jono: ubuntu hecks? 
<mdz> jono: I highly recommend waiting for it to be written before writing about it
<jono> Kamion, mdz, totally agree, but the deadline of the end of the month is looming - any idea (approx) when the UI will be settled?
<Kamion> as fast as I can
<mdz> jono: UI freeze is 9 March
<jono> I understand
<Kamion> UI freeze is the deadline, see wiki.ubuntu.com/DapperReleaseSchedule
<jono> 9 march
<mdz> jono: but given the priority of this work, we'll easily make exceptions for it if necessary
<jono> I will talk to my publisher
<jono> mdz, understandable
<jono> sivang, this is the Official Ubuntu book
<mdz> jono: it really isn't wise to put this in a book until dapper
<sivang> jono: ah :)
<siretart> Kinnison: wtf is a Coffee key?
<Kinnison> siretart: as keybuk said -- 'tis the screenlock key
<jono> because its the official guide, I really need to cover the new dapper UI, but there is no way other than just waiting for it
<jono> I know Kamion works the day of a thousand men :)
<siretart> hrhr
<Burgwork> jono, having fun working under the gun?
<jono> Burgwork, its interesting
<jono> Keybuk, lunch this week?
<Keybuk> ya know, I think Ubuntu should use the same model of Region/Language/Keyboard option selection that the Windows XP installer does ... our "two questions" is just too few, we should have eight hidden options amongst three different dialog boxes like Windows has
<Keybuk> jono: I don't see why not, sure
<jono> Keybuk, cool, I am free tomorrow and friday, your choice :)
<Keybuk> jono: friday would be best
<Kinnison> seb128: the autostart .desktop files -- are they considered on every startup, or just the first one before you have a session?
<seb128> Kinnison: every login
<Kinnison> seb128: thanks
<seb128> Kinnison: that's why the g-v-m one uses "--sm-disable"
<Kinnison> seb128: yeah, which is why g-p-m uses --sm-disable
<Kinnison> seb128: only --sm-disable breaks g-p-m
<Kinnison> seb128: because at one point it tries to ask the session to present a logout dialog and explodes
<seb128> ah ..
<seb128> we can use the old method other way
<Kinnison> How do you mean?
<seb128> don't ship a .desktop and modify the default session by patching gnome-session
<seb128> that was the only way until one month ago
<seb128> (the autostart stuff is new)
* Kinnison could instead make it so that it's safe to start it twice
<Kinnison> I.E. a second startup is ignored
<seb128> /usr/share/gnome/default.session
<seb128> that too
<Kinnison> seb128: which do you think is better?
<Kinnison> personally I'd rather keep the crack inside the g-p-m package
<seb128> fixing g-p-m to work with --sm-disable
<Kinnison> hmm, I can look at that, but it has to as the session to present its logout dialog
<Kinnison> I don't think you can do that in sm-disable mode
<seb128> what kind of dialog does it want to run?
<Kinnison> the logoutish one
<seb128> you should not get random question to log off
<Kinnison> currently it gets the six-icon logoff one
<Kinnison> it's on power-button press
<seb128> ah, ok
<seb128> hum
<Kinnison> it copes with being run more than once in the session cleanly
* Kinnison just tested
<seb128> so just drop the --sm-disable from the .desktop
<Kinnison> so I propose to remove the --sm-disable from the .desktop
<Kinnison> cool you agree
<Kinnison> :-)
<seb128> :)
<Kinnison> thanks seb
<jono> Keybuk, cool
<Keybuk> jono: usual place, 1pm?
<seb128> np
<jono> Keybuk, sounds good :)
<shaya> mjg59: you here?
<mjg59> shaya: Hi
<shaya> rgb path in Xgl is wrong
<shaya> your Xgl is searching for /usr/share/X11/rgb
<shaya> ubuntu doesn't store it there
<shaya> gives me this error on startup
<shaya> Couldn't open RGB_DB '/usr/share/X11/rgb'
<shaya> emacs refuses to run (for instance) now.
<shaya> restarting X with a hack to make it work for now.
<mjg59> shaya: Ok. Please file a bug.
<shaya> ok, just wanted to explain the issue, figured might be clearer than in email
<HiddenWolf> mjg59:  quick question, why does compiz depend on both gtk and qt? is it needed?
<jono> mjg59, good work on the xgl server in dapper btw :)
<mjg59> HiddenWolf: Yes
<mjg59> jono: Ta
<HiddenWolf> mjg59: hm. :) someone was already asking for an -gtk and -qt version
<mjg59> HiddenWolf: I know
<mjg59> HiddenWolf: But right now, anyone who is excessively concerned about that sort of thing really shouldn't be running it
<HiddenWolf> mjg59: i'll do some reading, Was just wondering why it's needed. Thanks anyway, I won't bug you. :)
<mdke> mdz, just saw your email re: flash - fyi there are loads of screenshots on the wiki page, not sure how useful they can be tho
* BenC wonders what KEY_COFFEE is supposed to do
<mjg59> BenC: Lock the screen
<HiddenWolf> <Keybuk> it's the moniker for lock-screen/take-a-break/etc. keys usually
<BenC> mjg59: as in "taking a coffee break, lock my screen"?
<mjg59> BenC: The actual problem is that the input layer won't pass through keycodes unless they're in its idea of a keymap
<BenC> ah
<mjg59> Which is a one line fix
<mjg59> Hang on
<HiddenWolf> mjg59: regarding xgl, wouldn't it be a good idea to set up a wikipage with known to work, known to break, this is how you do it safely kind of info?
<mjg59> HiddenWolf: It would, yes
<HiddenWolf> I'll see if I can come up with something.
<HiddenWolf> Guess that'd take a few questions off you as well.
<mdke> mdz, also I guess it might be worth thinking about translation ASAP?
<mjg59> BenC: line 77 of drivers/input/input.c
<mdz> mdke: yes, that's part of what I was trying to suss out: how many screenshots they needed for each sequence, and what they should look like
<mdz> mdke: the longer term strategy is for them to do their own screenshots, since they'll know what they need and what can be animated
<mdke> mdz, sure. well if those are helpful, then great, if not, they can make more, or we can help
<mjg59> BenC: Basically, the test_bit code isn't needed in that line (AFAICT)
<mdke> mdz, for some screenshots it might help if we do them, or tell them how to work around bugs which affects the screenshot
<mdz> mdke: sure
<mdke> mdz, do you think translation can wait a while?
<mdz> mdke: I think we need to finalize the screenshots and text before we start translating
<mdke> mdz, sure, before we start translating. I was just thinking about how we are gonna go about it
<mdke> anyhow, it's down the road
<BenC> mjg59: ok, thanks
* mvo is away for dinner
<psusi> is it just me or is the nav bar on the fridge messed up today?  and where do you report bugs on the web site?
<jpatrick> psusi: been like that for ages
<psusi> the nav bar is being rednered down at the bottom of the screen rather than the top... it's floating over top of the test plans and hug day article... it wasn't like that the other day
<jpatrick> it's been like that for two weeks now (over here)
<psusi> wow... so where do we report this bug to get it fixed? ;)
<psusi> not malone right?
<Nafallo> psusi: try fridge-devel@lists.ubuntu.com
<Nafallo> (no need to subscribe)
<psusi> anyone know what the difference is between this xgl everyone is talking about and the normal X server?  is it supposed to be faster?  how?
<psusi> Nafallo: ahh... ok...
* Kinnison heads off
<Kinnison> ciau
<Nafallo> X GL, everything is GL-rendered if I understood it right.
<Treenaks> but at the moment, for me, it just crashes (but that might be my weird video driver ;))
<HiddenWolf> psusi: this is not a support channel
<psusi> HiddenWolf: I'm aware of that... and not asking for support... trying to learn more about how X works internally
<HiddenWolf> psusi: you're one of a million at the moment. try #xgl
<psusi> I've been wondering for some time why X seems to be so slow at repainting the uncovered areas of the screen while you drag a window... even with accelerated drivers...
<psusi> you'd think DRI would take care of taht
<Burgwork> Kinnison, did you just upload support for those random keys in Toshiba?
<HiddenWolf> * Kinnison heads off
<HiddenWolf> <Kinnison> ciau
<sistpoty> motu-meeting just about to start in #ubuntu-meeting
<seb128> jordi: around?
<seb128> hum
<dholbach> hey Mitario
<Mitario> dholbach, heya
<seb128> how is alsa-utils supposed to set volume on startup? using udev?
<sistpoty> mjg59: do you mind if I touch xserver-xgl?
<mdke> dholbach, if you're on Ekiga this evening, how about giving it a more user friendly menu entry? I can file a bug if you prefer
<dholbach> mdke: might make sense to file it upstream
<mdke> yes, but it would be a string change :/
<dholbach> yeah, i guess this will mean collecting translations on our own (like in breezy)
<Burgwork> dholbach, upstream must be interested and it is not too late in the release cycle to change that
<dholbach> Burgwork: i guess they'd very much be interested (they're just in string freeze)
<Burgwork> dholbach, yes, but not hard yet
<mdke> what's a decent menu entry? I can't think of anything good
<sivang> mjg59: so are the xgl packages ready fro testing?
<dholbach> can we please have a #ubuntu-xgl or something?
<dholbach> :)
<sivang> dholbach: it was only one quesiton, honest, with a yes / no answer :)
<HiddenWolf> sivang: they're not ready, but people are testing by the masses :)
<sivang> HiddenWolf: join #ubuntu-xgl
<HiddenWolf> sivang: yeah, but you must be the 1001st person today to ask something xgl-related. :)
<dholbach> sivang: yeah, like all the other yes/no questions :)))
<mdke> dholbach, so what's the verdict on Ekiga? upstream and hope for astring freeze exception, or Ubuntu?
<dholbach> mdke: we can do both.
<mdke> ok, i'll do the bug upstream, if there isn't one already
<dholbach> mdke: If we're going to include our own string and translations, we have 8-9 weeks time 
<mdke> dholbach, Burgwork, any ideas for a good menu entry?
<dholbach> mdke: i had a quick look, doesn't seem so
<Burgwork> mdke, thinking
<dholbach> Ekiga VoIP <something>? (since that's something everybody understands nowadays)?
<sivang> mjg59: if you want to join us, you're welcome :)
<Burgwork> not a bad fallback
<dholbach> but maybe that's too techspeak for some
<Burgwork> voip is now being advertised on TV in Canada
<mdke> i think a bit tecky
<mdke> Ekiga Video Conferencing?
<Burgwork> ie, they are using the term voip
<mdke> does it do video?
<dholbach> :-)
<zul> Burgwork: it has been for a while..
<Burgwork> zul, yes, but I was mentioning that they are using the term voip
<mdke> telephone and video conferencing is a bit long
<Burgwork> so we even need the name Ekiga in there?
<Mithrandir> ekiga internet phone
<Mithrandir> or just internet phone
<seb128> what is wrong with the new name?
<seb128> upstream had that discussion
<mdke> seb128, it's just "Ekiga"
<Burgwork> seb128, nothing, it just doesn't say anything
<seb128> they picked "Ekiga Softphone"
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=329622
<Ubugtu> gnome2 bug 329622 in general "Change name on the GNOME applications menu" [Enhancement,Resolved: fixed]  
<mdke> oh, that's an improvement
<mdke> although dubious use of english :)
<Burgwork> better to followup upstream, as it gets us their translations
<seb128> better suggestion is welcome
<Burgwork> and softphone isn't bad
<seb128> but read the upstream bug
<seb128> they don't want misleading term
<seb128> not too many words for it
<mdke> for me it's fixed the bug, np
<seb128> cool
<Mithrandir> softphone is a terrible word, IMO.  Internet phone explains it better -- it's obvious that's it's not a hardware phone
<seb128> no need of internet to use it though
<Burgwork> seb128, umm
<Mithrandir> seb128: true, but if you have a pbx you'll generally know it, I'd imagine.
<seb128> anyway if you want to argue I've pointed the GNOME bug
<seb128> that's the right place for that :)
<Mithrandir> sure, and I can't really be bothered to argue with upstream.  Less work to just ignore it for me.
<seb128> I don't care enough to argue neither
<Mithrandir> heh :-)
<Burgwork> softphone gets more hits than internet telephone
<Burgwork> http://www.phonegnome.com/store/detailSOFTG.html <-- funny
<psusi> Mithrandir: have you heard anything more from upstream about the header conflicts in e2fsprogs that prevented defrag from building?
<Mithrandir> psusi: no, haven't heard anything.  I guess I should prod them again
<Mithrandir> Burgwork: but will more people understand softphone or internet telephone?
<Burgwork> Mithrandir, no idea
<psusi> hrm...
<Mithrandir> there's no way to translate softphone into Norwegian for instance either.  You'd have to translate it to software telephone (programvaretelefon)
<dholbach> lamont, infinity: if somebody could give back opal, I'd be very happy.
<Burgwork> Mithrandir, does internet telephone work?
<Mithrandir> Burgwork: "internettelefon"; that translates just fine.
<dholbach> :-)
<Mithrandir> Burgwork: I have no idea how softphone would work for, say, italian or spanish though, but I suspect it might be harder to translate without expanding the abbreviation.
<Burgwork> yes
<Mithrandir> Burgwork: or you'd end up with the term untranslated, which kinda sucks.
<Burgwork> Mithrandir, indeed. commenting as such on the upstream bug report
<Mithrandir> Burgwork: thanks
<mjg59> sistpoty: As long as you know what you're doing :) The interactions between things are really quite complicated
<sistpoty> mjg59: actually I only want to add --with-rgb-path=/etc/X11/ to configure-call... (but I'll need to test it at first)
<rehpotsirhc> hey, i'm on dapper and i just installed glx. anybody know what i can do with it?
<sistpoty> mjg59: xosview is lacking appropriate colors (imo because of wrong directory)
<mjg59> rehpotsirhc: #ubuntu-xgl
<mjg59> sistpoty: Sure, go ahead
<mjg59> Test before upload :)
<sistpoty> mjg59: sure, will do... (will test after motu-meeting)
<alexr> Can anybody tell me whether the Dapper Live CD will be similar to Breezy?
<alexr> Is this page still valid for Dapper? https://wiki.ubuntu.com/LiveCDCustomizationHowTo
<tseng> similar in what way
<alexr> casper-based and all that?
<tseng> not really
<alexr> I know Hoary live CD was different from Breezy.
<tseng> the livecd system was rewritten again
<alexr> Oh boy.
<tseng> the installer is also incorporated in the livecd
<tseng> 'espresso'
<alexr> Any pointers on how to modify it?
<tseng> maybe post release you can write them
<tseng> the page you just linked was community-written
<alexr> I know. Is there any docs by ubuntu devs on this?
<tseng> i am guessing the process is familiar, but the fs of the loopback is different etc
<tseng> alexr: only the design specs
<alexr> tseng: I suppose I could help testing the rough spots if I knew the inside.
<tseng> alexr: and code
<alexr> That would be good. What do I look at? espresso is a package, isn't it?
<tseng> https://wiki.ubuntu.com/LiveCDUnionFS?highlight=%28livecd%29
<tseng> hm where are the rest
<alexr> So Tollef Fog Heen is the main guy on Live CD, right?
<tseng> alexr: espresso is just the installer portion
<Mithrandir> yes, I am
<tseng> hm he is for this version
<Mithrandir> if you want to customise the live cd, but not the installer, just ignore espresso
<alexr> Mithrandir: I am thinking of adding a few packages.
<tseng> https://wiki.ubuntu.com/SimplifiedLiveCD?highlight=%28livecd%29
<tseng> mm this is what i was looking for
<Mithrandir> alexr: sure, that's easy enough.  Download the live cd, mount the image, mount -o loop -t squashfs casper/filesystem.squashfs /somewhere, copy that to a temporary directory, chroot into it and install packages, run mksquashfs on /somewhere and put the resulting squashfs as /casper/filesystem.squashfs on the cd.  Burn.
<alexr> With Breesy, I unpacked casper and installed my packages, then packed things up and wrote CD image.
<alexr> OK, so it's the -t squashfs that is new.
<Mithrandir> yeah, and you have to copy it out, since squashfs is read-only.
<alexr> used to be regular iso.
<Mithrandir> if somebody who's better at writing docs than I am would like to write that up on the livecdcustomizationhowto page, I'd be very grateful.
<Mithrandir> it's a regular iso, but there's a file inside that which is the live file system
<alexr> I'll try and if I succeed then I will write it up.
<alexr> Right.
<Mithrandir> if you want the "check integrity check" to work correctly, you need to update /md5sums.txt in the iso image too
<alexr> Yes, makes sense.
<alexr> What about manifest?
<alexr> in breezy there was casper/filesystem.manifest
<Mithrandir> it's not used by anything.
<alexr> OK, so I don't have to regenerate it now, do I?
<Mithrandir> so you can just ignore it or update it as you please.
<alexr> OK, thanks.
<Mithrandir> you didn't have to in breezy either, iirc
<alexr> Are you usually on this channel?
<alexr> In case I see some problems, can I bug you later?
<alexr> We're using Ubuntu for Linux Genealogy CD, gramps-project.org
<alexr> Our users tend to be older people with not too much computer experience.
<alexr> They love live CD>
<Mithrandir> I'm here too many hours a day and my IRC client is here always, so just prefix anything you want me to see with Mithrandir and I'll see it.
<alexr> with Gramps already installed.
<Mithrandir> cool
<alexr> Sounds good, thanks a lot!!!
<Mithrandir> np, have fun.
<alexr> Will do, thanks. See you later.
<seb128> does anybody knows a bit about hplip here?
<seb128> gnome-cups-manager has a "hp no_device_found" listed
<bmon> seb128: check to see if /dev/usb/lp0 exists
<seb128> /dev/usblp0
<bmon> thats the prob
<seb128> I've that one
<seb128> udev bog?
<bmon> i filed a but about it
<bmon> either udev needs to create it in /dev/usb/lp0 or hplip needs to find it at /dev/usblp0
<seb128> do you have the bug number?
<bmon> just a sec
<bmon> bug 28797
<Ubugtu> malone bug 28797 in hplip "hplip only searches for printers in /dev/usb/*, but the device is /dev/usblp0" [Normal,Fix released]  http://launchpad.net/bugs/28797
<bmon> looks like scott took care of it
<seb128> thank you
<seb128> I'll make sure it's fixed for dapper :)
<bmon> cool :)
<sivang> seb128: I've gathered all the xgl crwod in #ubuntu-xgl :)
<Mithrandir> have they started having competitions on who can throw their windows farthest off-screen?
<sivang> Mithrandir: not yet :) we're in the "make the package require less manual scripting work" phase :-)
<sivang> Mithrandir: are xgl people having such contests? sweet
<Mithrandir> sivang: I'd imagine so.  Or that might just have been luminocity.
<HiddenWolf> sivang: Mithrandir, LOL
<geneo93> anyone know if seamonkey is going to be in dapper soon
<Kamion> so, stupid question, but ... how do I get espresso to make an icon appear on the GNOME desktop
<Kamion> ?
<Kamion> i.e. how do I install the .desktop file? copying it to ~/Desktop/ doesn't seem sufficient
<Kamion> ... but dragging it to the desktop does. I'm so confused
<seb128> how is copying the .desktop not enough?
<seb128> works fine for me
<Kamion> it doesn't appear on the desktop - when I copy-drag it to the desktop, ~/.nautilus/ gets updated though
<Kamion> is there something I need to poke to make nautilus re-read the directory?
<sistpoty> elmo: please sync allegro4.2 (2:4.2.0-1) from unstable, which is not yet in ubuntu
<seb128> Kamion: no, it should use gnome-vfs which use inotify for that
<seb128> Kamion: if you cp something else than a .desktop does the desktop change to list it?
<ajmitch_> morning
<Kamion> seb128: no
<Kamion> (cp TODO ~/Desktop/)
<Kamion> seb128: this is with nautilus 2.13.90-0ubuntu1 BTW
<Kamion> ... in vmware
<seb128> maybe inotify doesn't work in vmware?
<seb128> we didn't get any bug about notification not working with nautilus for some time
<Kamion> ok, as long as dropping it into ~/Desktop/ is enough then I can ignore the problem since I'll be copying it in before nautilus starts anyway
<seb128> yeah, copying is enough
<sivang> Kamion: if I make a one liner patch to culmus font package, which will render hebrew fonts usable on dapper , could you review the debdiff and upload the package on my behalf?
<Kamion> sivang: sure, mail me
<sivang> Kamion: thanks, I'll mail you the details then :)
<sivang> weird, getting secret key not availabe although it is when debuild -S
<AndyFitz> mjg59: ping   http://www.brisgeek.com/screenshot.jpg  ;-)
<sivang> Kamion: kamion@ubuntu.com is okay?
<Kamion> sivang: no, cjwatson@ubuntu.com
<sivang> ops
<sivang> okay
<lifeless> Kamion: you gotta get an alias ;)
<sivang> yeah :)
<mlistus> hi all
<sivang> Kamion: sent 
<mlistus> i need to make a custom install cd for breezy.
<mlistus> i've dfsbuild, but it gets a copy of my running system.
<sivang> Kamion: lemme know if reached you
<mlistus> i want an nearly exact copy of official debian cd
<mlistus> can anyone give me pointers?
<mlistus> hello?
<sivang> mlistus: I belive most of the people who can help at the moment are away or busy , might be good to try search for some docs on the wiki
<Kamion> mlistus: http://wiki.ubuntu.com/InstallCDCustomizationHowTo
<Kamion> sivang: yes, I have two mails from you
<sivang> Kamion: two? so kamion@ubuntu.com works ? :)
<Kamion> sivang: no, you sent two different mails
<Kamion> sivang: oh, right, go figure, it does work
<Kamion> didn't expect that, I guess that's due to my launchpad name
<sivang> Kamion: and I thought it was getting to late for me :)
<seb128> Kamion: is that ok if I update nautilus-python to 0.4.2, there is 3 changes, 2 are already shipped with the 0.4.2 package as a patch and the other one is "Make debugging messages a run-time option"
<Kamion> seb128: that's part of the GNOME desktop isn't it?
<Kamion> or close enough
<mlistus> Kamion: that's what i needed.
<mlistus> Kamion: thanks!
<seb128> not a part of the desktop but done by pygtk/pygnome upstream 
<Kamion> seb128: I think that should be fine, anyway
<seb128> k, thank you
<mlistus> next, i need to know about the status of via support in ubuntu's xorg.
<mlistus> will there be hw support?
<mjg59> AndyFitz: Rock!
<HiddenWolf> AndyFitz: nice artwork. :)
<AndyFitz> mjg59,  rock but  my kernel isn't spawning gettys
<AndyFitz> know anything about that :)
<mjg59> AndyFitz: None
<AndyFitz> bugger,  when I ALT+CTRL+F(x)   I get a blank screen
#ubuntu-devel 2006-02-21
<AndyFitz> HiddenWolf,  thanks ,  my latest piece is called " when XGL goes wild"
<mjg59> AndyFitz: You can boot in recovery mode, presumably?
<Mithrandir> dholbach: ekiga is broken for me. :-(
<dholbach> Mithrandir: i know
<dholbach> i asked to give back opal 3 times already
<Mithrandir> dholbach: it's broken after I fixed it so it compiles locally too.
<AndyFitz> oh wait I got gettys
<dholbach> Mithrandir: broken in what way?
<AndyFitz> mjg59 yeah I can
<Mithrandir> dholbach: fails to actually connect a call
<AndyFitz> but I mean ..   why are they dead to me 
<dholbach> Mithrandir: hrm, sounds like an upstream bug would be in order :/
<Mithrandir> dholbach: first, registration fails due to a timeout, but retrying from the "accounts" place works
<HiddenWolf> AndyFitz: It's art, true art. :)
<Mithrandir> hmm, now it works to call out.
<AndyFitz> HiddenWolf,  it speaks of our generation... broken but experimental..  ugly because it aspires  to be beautiful... deep
<AndyFitz> freakin black text on a black console in a black getty
<HiddenWolf> AndyFitz: what tells you that I'm not retired? ;)
<AndyFitz> ./me infers technology generation
<HiddenWolf> Good point.
<AndyFitz> damn dot came out of nowhere
<HiddenWolf> It's too late for deep thoughts.
<AndyFitz> agreed  ( spoken at 9:11am brisbane time )
<HiddenWolf> It's a quarter past midnight, and I racked up a grand total of six hours of sleep so far this week.
<HiddenWolf> I'm entitled to my stupidity tonight. :)
<ajmitch_> Kamion: zope3 (in main) need python-mechanize pulled in from debian to be installable, email doko & mdz/yourself about it?
<Burgwork> mjg59, if you post to -devel-announce now, you might still get mad LWN weekly news coverage
<mjg59> Burgwork: I'd rather not :p
<mjg59> But yeah, I guess.
<Kamion> ajmitch_: fairly sure it's in NEW, but I'm off to bed now
<Kamion> I'll look at it tomorrow morning
<ajmitch_> ok, thanks
<ajmitch_> Burgwork: the world can only take so much shiny
* ajmitch_ just switched back to regular  :)
* Burgwork hasn't tried Xgl yet. After the book is written
* AndyFitz wishes xcompvis used metacity themes.  why do you need a 1px black outline when you already have a drop shadow
<AndyFitz> it looks silly 
<Burgwork> ajmitch_, yes, but think of the mad marketing win for having .debs for ubuntu already
<ajmitch_> oh sure
<mdz> ajmitch_: colin and me
* Burgwork is turning into a sad sad marketing and sales wonk
<sebest> anyone using svn.debian.org could give me a hand?
<sebest> i've an account on alioth, and i'm trying to checkouting with svn+ssh
<sebest> but it doesn't accept my credentials
<sebest> i'm trying this: svn --username "sebest-guest" co svn+ssh://svn.debian.org/svn/pkg-utopia/packages/unstable/
<doko> seb128, Riddell: please could you have a look at http://lists.freedesktop.org/pipermail/xdg/2004-August/004489.html ? Can we support that please?
<LaserJock> sebest: I had to wait a day for my svn.debian.org after I was approved on alioth, could that be your problem?
<sebest> laserjock i waited one day already :)
<LaserJock> sebest: I also changed the subversion conf file
<sebest> it seems it doesn't take into account "--username" or something
<LaserJock> well, I think there is the subversion username and ssh username
<sebest> ah, they are not the same?
<LaserJock> well, if you change one you don't necessarily change both
<sebest> and the passwords, should i type it twice?
<sebest> one time for svn , and one time for ssh?
<LaserJock> yeah, I think so
<LaserJock> I edited the subversion conf file to have alioth = $SVN_SSH ssh -l laserjock-guest
<LaserJock> and then I due svn+alitoh:// instead of svn+ssh
<LaserJock> I don't know if all that is necessary because I was doing this before I waited a day :-)
<sebest> LaserJock i think the SVN_SSH did the trick , thanx
<LaserJock> np
<Riddell> doko: that sounds like the Portland proposal from the desktop architects meeting
<doko> just found it in /usr/lib/openoffice2/program/senddoc
<doko> Riddell: ^^^
<Riddell> hmm, interesting
<sivang> anybody know if subprocess.Popen.poll() can use a pid ?
<sivang> (the reference seem not tomention it)
<Kamion> sebest: it's more traditional to use svn+ssh://sebest-guest@svn.debian.org/...
<Kamion> then you don't need the SVN_SSH and subversion configuration hacks
<sebest> Kamion: i think that the fact that i was asked 2 passwords misleaded me
<sebest> i thought i was typing it wrongly
<mlistus> thanks for helping, good night
<dholbach> good night
<sebest> dholbach: good nifht
<sebest> night
<dholbach> night sebest :)
<sivang> Kamion: do you recall how to check for EOF in python file obejct?
<Kamion> searching for EOF in http://docs.python.org/lib/bltin-file-objects.html suggests various methods
<sivang> hrm, I was looking at http://www.python.org/dev/doc/devel/lib/os-fd-ops.html, thanks then
<failure> someone who is in charge of security.ubuntu.com?
<failure> or someone of the ubuntu security team?
<Kamion> failure: Martin Pitt's in bed if he has any sense
<Kamion> hmm, note my lack of sense. /me -> bedm really this time
<Kamion> s/bedm/bed,/
<Keybuk> http://people.ubuntu.com/~scott/bootcharts/quest-dapper-20060216-1.png
<Keybuk> ^ I think I shall show that to ogra in the morning, just for amusement value
<failure> well, the problem is that security.ubuntu.com is not up-to-date
<failure> respect to archive.ubuntu.com
<failure> compare ftp://archive.ubuntu.com/ubuntu/dists/breezy-security/main/binary-i386/
<failure> with ftp://security.ubuntu.com/ubuntu/dists/breezy-security/main/binary-i386/
<failure> for example
<failure> so if someone could report this...
* Keybuk joins the ranks of the sensible
<failure> I've emailed Martin Pitt
<failure> Well, time to go to bed
<alexr> Mithrandir: are you there?
<doko> lamont: please check if bind9 builds correctly on powerpc with gcc4, the bug should not be present anymore in Ubuntu's gcc-4.0
<doko> Diziet: please could you reenable -fno-strict-aliasing for firefox on amd64? trying to work around some crashes. a test build looks more stable
* sladen wonders what 'gnome-cups-icon' is doing that requires CPU when it isn't visible...
<dilinger> oh no
<dilinger> " Matthew Garrett was briefly my hero today (taking over from Iain Holmes) for uploading into Dapper xserver-xgl and Compiz. Very nice it is too, but it's a bit too crashy on my laptop for any real work."
<dilinger> must.. resist.. eye.. candy..
<ajmitch_> nah, just get it over & done with
<Kyral> lol
<Kyral> dilinger: This is why I'm pinning the Clearlooks package with Cairo enabled :P
<ajmitch_> dilinger: I tried it, admired the nice shinines, and I'm over it now
<Kyral> how do you activate it anyway?
<Kyral> Anyway Transset and Cairo is nice enough for me :D
<dieman> mjg59: you are my hero (re: xgl)
<sladen> dilinger: :)
<sladen> mjg59: thinkpad-keys hint
<sladen> mjg59: and if you can't sync it, just do a manual upload... :)
<fabbione> mdz: ping?
<fabbione> Kamion, mdz: permission to upload partman-auto-lvm-9ubuntu1. It is a UVF break but there are only white space cleanup and update translations in the release. All the bug fixes in pal-9 from Debian were already present in our 8buntuX release
<fabbione> mdz, Kamion: permission to upload redhat-cluster-suite, new CVS snapshot from STABLE (bug fixing only branch).
<neuralis> marilize: ping
<marilize> neuralis: hi
<neuralis> marilize: hello. any chance i can get around ~100 CDs shipped to massachussetts in the next week or so? it's for an unanticipated talk.
<marilize> neuralis: ok, just place an order on shipit, put my name in as reason, and i'll make sure it goes out asap.....will take a few days to reach you
<pitti> Good morning
<neuralis> marilize: you rock. thanks.
<marilize> neuralis: :)
<mdz> fabbione: both partman-auto-lvm and redhat-cluster-suite OK
<mdz> fabbione: please mention the exception in the changelog
<Mithrandir> mdz: permission to upload squashfs-utils 3.0 instead of 2.1?  According to BenC it means using a bunch of newer code paths in the kernel which fixes some of the oopses we've seen.
<mdz> Mithrandir: have you tested it with the live CD?
<Mithrandir> mdz: BenC has
<mdz> do you know which architecture(s) he tested?
<fabbione> mdz: meh ok.. i already have everything signed and ready...
<mdz> fabbione: no need to rebuild then, but please remember in the future
<Mithrandir> mdz: ppc at least.  I can test on i386 and amd64 today.
<fabbione> mdz: ok thanks
<mdz> fabbione: it helps keep everyone informed of the workflow
<mdz> Mithrandir: please test first, but if your tests are successful, I have no objection to the upgraed
<mdz> upgrade
<Mithrandir> mdz: ok, thanks.
<fabbione> mdz: sure..
<fabbione> mdz: i am hounestly just lazy enough to rebuild them...
<viviersf> sorry to ask this
<viviersf> but who does initrd.gz ?
<pitti> hi carlos 
<carlos> morning
<fabbione> OH CRAPTASTIC
<viviersf> what fs format does the initrd.gz on dapper use ?
<Mithrandir> it's an initramfs, which means it's one or more cpio archives.
<viviersf> :(
<viviersf> so you changed
<viviersf> it
<jsgotangco> xgl and compiz weee
<viviersf> :(
<dholbach> good morning
<pitti> hi dholbach 
<pitti> morning mvo
<dholbach> hey pitti
<mvo> good morning dholbach, pitti, * :)
<lixus> hello, how/where do i report problems about http://cdimage.ubuntulinux.org/daily/current/dapper-install-powerpc.iso
<pitti> lixus: the CD doesn't work in general? or a bug in a specific package?
<pitti> lixus: generally, you should report bugs to https://launchpad.net/bugs
<lixus> pitti, no it works in generall, but there are some pitfalls.
<pitti> lixus: can you please search in the existing bugs before? maybe they are already filed, and there might be workarounds in the bug comments
<lixus> sure
<pitti> thank you
<highvoltage> not strictly a devel issue, but have anyone seen http://www.ubuntu.co.za
<highvoltage> who can i mail to get rid of that!?
<fabbione> ahhaha
<fabbione> running on a m$ server
<highvoltage> just did a whois, turned out it has nothing to do with ubuntu, shew!
<ompaul> http://www.ubuntu.co.za/  HTTP 403.6 - Forbidden: IP address rejected
<ompaul> highvoltage, mail canonical they deal with copyright abuse which we might think that is - what is on the page given I am prohibited from looking at it
<ompaul> highvoltage, perhaps a chat in #ubuntu-offtopic
<highvoltage> ompaul: a microsoft IIS error
<highvoltage> ok, thanks
<jsgotangco> highvoltage, oh wow nice catch
* Mithrandir wonders where his panel went
* mvo reboots
<Kamion> ompaul: I doubt it's copyright abuse, seeing as "ubuntu" is a Bantu word and that's an African web site
<Kamion> ompaul: they were there first ;)
<Kamion> IIRC they already existed when Ubuntu the distribution was named, but I could be wrong
<jsgotangco> it was a good chuckle though :D
<jsgotangco> mmm today's build looks good
<viviersf> Kamion, no offence, but dont use the word : bantu
<viviersf> as its regarded as a racist word in africa
<ompaul> Kamion, ahh
<jsgotangco> is it? i thought it meant the family of languages
<ompaul> Kamion, it obviously too early in the morning I read that as nz not za (double, quadrupal doh etc)
<Kamion> viviersf: er, ok - I was using it in the sense of http://en.wikipedia.org/wiki/Bantu_languages rather than as a racial classification
<jsgotangco> ahhh i see it now
* jsgotangco understands now
<Kamion> I understand it's offensive when applied to people ...
* ompaul slopes back under the rock he had been under for a while 
<pitti> yay - langpack support for .server files works! that completes another spec
* pitti does the Dapper dance
* seb128 hugs pitti
<seb128> rock!
<pitti> well, zyga did the bulk work, I just made his patch not break the API and crash gnome :)
<viviersf> Kamion, i know im just saying :)
<lucas> I have a problem with suspend to disk (it worked with breezy, not with dapper) : when I resume, the screen only shows strange squares and colored lines
<lucas> against which package should I report this ?
<ogra> Kinnison, whats a KEY_COFFEE event ??
<Kinnison> ogra: lock-screen
<ogra> heh
<ogra> funny name 
<ogra> :)
<ogra> Kinnison, http://mail.gnome.org/archives/gnome-power-manager-list/2006-February/msg00025.html
<ogra> seen that 
<ogra> do we want a UVF exception (would mean to merge a lot of our changes manually :/ )
<Kinnison> ogra: Hmm
<Kinnison> ogra: Might be worth it
<ogra> the translations seem tempting, yes
<pitti> hey ogra
<pitti> ogra: HAPPY BIRTHDAY!!!
<ogra> hey, thanks :)
<Kinnison> ogra: aye, although the "no lid action on AC" seems odd and strange
<ogra> absolutely ...
<Kinnison> I for one would file a bug against that
<Kinnison> but he hasn't merged the 'lock' action yet
<ogra> we should probably only merge the translations ...
<ogra> it appears to be less work ... i dont see anything that would be *really* intresting in the rest of the changelog
<JaneW> **Reminder** Dapper Dev Status Update meeting today at 14:00UTC in #ubuntu-meeting
<Mithrandir> ogra: it seems gnome-screensaver doesn't allow empty password.
<Mithrandir> +s
<ogra> Mithrandir, neither does xscreensaver ...
<ogra> we had a patch in xss for the livecd ... i'll look if it can be ported to gss
<Mithrandir> ogra: uh, what kind of patch?
<Mithrandir> just fix it to allow empty passwords.
<ogra> one that forbid locking if a certain value in gdm was set
<Mithrandir> that's silly.  The ubuntu password on the live cd is now blank and choosing "lock screen" to turn on the screensaver is perfectly reasonable
<ogra> we did set this value on the old livecd ...
<Mithrandir> it should allow blank passwords _anyway_.
<Mithrandir> I have that for my test user, for instance.
<ogra> hmm
<ogra> i'll look into it ...
<ogra> but not today ...
* ogra makes a note
<Mithrandir> I'll reassign the bug to gss and you. :-)
<ogra> oki
<Mithrandir> done, bug 30118 is yours
<Ubugtu> malone bug 30118 in gnome-screensaver "LiveCD: default user password, lock screen problem" [Normal,Unconfirmed]  http://launchpad.net/bugs/30118
<sivang> morning all
* sivang hugs pitti 
<pitti> hi sivang 
<sivang> ogra: HAPPY BIRTHDAY !
<ogra> sivang, thanks :)
<HiddenWolf> ogra: Happy birthday!
<ogra> thanks :)
* HiddenWolf gives ogra much cake and presents
<ogra> hehe... 
<Kinnison> ogra: Yeah, I'd say the better help and the extra translations would make it worthwhile for either you or me to ask for UVF exception
<mvo> ogra: HAPPY BIRTHDAY
* Kinnison hugs ogra too
<ogra> mvo, thanks :)
<ogra> thanks all :)
<jsgotangco> whoa
<jsgotangco> happy birthday ogra 
<ogra> thanks :)
* sivang hugs Kinnison , ogra , Kamion and others
<mjg59> elmo: Can hotkeys-setup get synced?
<Mithrandir> mjg59: compiz segfaults on amd64. :-(
<mjg59> Mithrandir: Yes, I know
<mjg59> Mithrandir: I'll look into it
<Mithrandir> mjg59: -> #ubuntu-xgl
<apokryphos> hm, #xgl-ubuntu too
<Kinnison> mjg59: that Xgl stuff is, erm, interesting
<Kinnison> a wee bit over-bling
<Kinnison> and when I tried to reduce the bling it crashed, but I'll play again tonight I think
<Treenaks> Kinnison: For years you've had _no_ bling, now you're just getting it all at once ;)
<Kinnison> Treenaks: heh
* Kinnison dislikes the fact that Xgl doesn't seem to support a 2d desktop layout
<Kinnison> I have 8x3 desktops for a reason :-)
<Treenaks> Kinnison: think 3d first :)
<Treenaks> Kinnison: map them to a polyhedron :)
<Kinnison> Treenaks: an interesting idea
<HiddenWolf> I'd get so lost. :)
<Kinnison> But it *is* cute
* Kinnison likes it a lot
<HiddenWolf> Kinnison: 8x3?
<Kinnison> HiddenWolf: eight desktops alone, three down
<Treenaks> HiddenWolf: what? on a ball-like structure with 20 desktops on it? :P
<HiddenWolf> A different terminal on each window? :)
<Treenaks> HiddenWolf: no way you'd get lost :P
<HiddenWolf> Treenaks: true, i'm not hardcore, but I mostly only use 2, three if i"m working.
<Kinnison> HiddenWolf: nope, topleft == mail, one across from that is IRC, one down from IRC is terminals for current context work, one to the right of that is editors, up from that is web (one right of irc)
<Kinnison> HiddenWolf: etc
<HiddenWolf> Kinnison: what screen resolution? :)
<Kinnison> HiddenWolf: 1024x768 (12" laptop)
<HiddenWolf> ah :)
<Kinnison> HiddenWolf: although I do the same on my desktop which has 1280x1024 (LCD panel)
<Kinnison> And I did the same when I had a 1600x1200 display at work
* Kinnison is a creature of habit
<Kinnison> and those habits formed when I was about 15
<HiddenWolf> I'm using 1920x1200, so I cram two windows next to eachother. So one window for work, one for irc/gaim, and one for mail. :)
<HiddenWolf> with rhythmbox all over the place, obviously. :)
<Kinnison> most I cram next to each other is an emacs window and a terminal with vim in it
<Treenaks> HiddenWolf: 1920x1200 is pure love :)
<HiddenWolf> Treenaks: I haven't craved for a bigger screen since I bought it, which is an entirely new level of bliss. :)
* Kinnison mostly feels small is love
<Kinnison> Hence I changed from a CRT to an LCD on my desktop even though it offers less screen realestate
<Treenaks> Kinnison: also since you were 15? :P
<Kinnison> Treenaks: *fnar fnar*
* Kinnison makes a mental note to reduce treenaks' beer token stack by one
<Kinnison> Treenaks: will you be at fosdem?
<Treenaks> Kinnison: probably not
* HiddenWolf either. :(
<Treenaks> HiddenWolf: neither, though
<Kinnison> :-(
<Treenaks> Kinnison: I'll be at LugRadio Live..
<Kinnison> Treenaks: when/where is that?
<HiddenWolf> Treenaks: argh
<Treenaks> Kinnison: Wolverhampton
<sivang> Treenaks: how come ? :)
<Kinnison> sivang: when?
<Treenaks> Kinnison: 22/23 July
<Kinnison> sivang: ignore that :-)
<Kinnison> Treenaks: Hmm, I might be able to make that
<Treenaks> Jono somewhat expects me to speak about the crack that'll be going into dapper+1
<Kinnison> heh
<sivang> Kinnison: you also didn't hug me back when I hugged you this morning :) oh well, taking me for granted..
<Kinnison> so you'll be at the post-dapper devel conference?
<Treenaks> Kinnison: when's that? :)
<Kinnison> sivang: I am a cad and a bounder and you may bite your thumb at me
<Kinnison> Treenaks: early may I imagine
<Treenaks> good point :)
<sivang> where is LUgRadio location?
<Treenaks> sivang: http://www.lugradio.org/live/2006/index.php/Main_Page
<Treenaks> sivang: 'Sat 22nd and Sun 23rd July 2006 - Wolverhampton University Students' Union, Wulfruna Street Wolverhampton WV1 1LY'
<sivang> Treenaks: ah too far for me date wise, I'll probably be in EU ealier though
<sivang> Kinnison: /me tries to parse :)
<Kinnison> sivang: cad == vulgar or mean person
<Kinnison> sivang: bounder == one who is morally reprehensible
<Kinnison> sivang: to bite your thumb at someone == to insult them in a similar way to giving them the finger
<dholbach> Kinnison: is that last expression still used today? :)
* dholbach is heavily reminded of Shakespeare. :-)
<Kinnison> dholbach: No it's not
<Kinnison> dholbach: the entire phrase is old-world
<Kinnison> dholbach: along with "I bite my thumb sir, yes sir I bite my thumb, but I do not bite my thumb at you sir, on no, not at you sir"
<dholbach> I'm glad I don't feel too bad for my (lack of) colloquial english today. :-))
<dholbach> Kinnison: Right. :-)
* Kinnison hugs dholbach event hough it's not hug day
* dholbach doesn't mind.
* dholbach hugs Kinnison back. :-)
<ogra> Kinnison, every day is a hugday ;)
<Kinnison> yay
<Kinnison> sivang: are you in on the LP meeting? (just starting)
<doko> seb128, Riddell: please could you have a look at http://lists.freedesktop.org/pipermail/xdg/2004-August/004489.html ? Can we support that please?
<doko> just found it in /usr/lib/openoffice2/program/senddoc
<seb128> why do you need that for?
<Riddell> doko: I've had it added as an existing solution to the Portland task description for opening urls
<Kamion> er, did kbd-chooser start ignoring preseeding?
<Mithrandir> I don't think so?
<Kamion> try booting with debian-installer/locale=pt kbd-chooser/method=pt-latin1
<Kamion> watch it pick a Brazilian keymap
<HiddenWolf> Keybuk: I just updated bug 29789, blacklisting the module doesn't work
<Ubugtu> malone bug 29789 in udev "tv card audio not working" [Normal,Needs info]  http://launchpad.net/bugs/29789
<Keybuk> does the module get loaded even if blacklisted?
<Mithrandir> Kamion: blame localechooser
<Kamion> !
<Mithrandir> hmm, or actually possibly not.
<Kamion> it doesn't touch keymaps
<Mithrandir> localechooser thinks we're in .br, though
<Keybuk> ogra: http://people.ubuntu.com/~scott/bootcharts/quest-dapper-20060216-1.png
<HiddenWolf> Keybuk: yes
<Keybuk> HiddenWolf: meh ... it shouldn't :)
<Kamion> Mithrandir: yeah, that's a sort of slightly independent bug
<Kamion> working on that too
<ogra> Keybuk, WOAH
<ogra> initramfs looks really nice there :)
<Kamion> you can try debian-installer/locale=pt_BR kbd-chooser/method=pt-latin1 if you prefer, should exhibit the same bug
<Keybuk> HiddenWolf: can you cat /sys/bus/pci/devices/*/modalias for me and paste it somewhere
<Keybuk> ogra: the nice thing is that the time from usplash to gdm is only just over 10s
<HiddenWolf> Keybuk: http://paste.ubuntu-nl.org/8730
<ogra> and you beat me with 2seconds, bah ... http://people.ubuntu.com/~ogra/edubuntu/dapper-20051212-1.png
<Keybuk> ogra: yes, and yours is a heavily stripped system :)  mine's a standard, fresh, dapper install <g>
<ogra> heh ... yup
<Keybuk> I've just got to get used to fhe fact that it sounds like a coffee machine, rather than a jet engine
<Kamion> Mithrandir: BTW did you mean to leave all that debugging code in there?
<Mithrandir> Kamion: no
<ogra> Keybuk, just put in a jet engine then ...  the volume will overrule the coffe machine i guess :)
<lucas> I have a problem with suspend to disk (it worked with breezy, not with dapper) : when I resume, the screen only shows strange squares and colored lines. Against which package should I report this, or whom should I talk to ?
<ogra> lucas, are you sure you dont use the nvidia driver ? its normal behavior for it ...
<Kamion> Mithrandir: I think we should probably skip all the default-setting code in kbd-chooser/method if it's already set; although we would need to take care that backing up and repeating kbd-chooser still works
<lucas> ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] 
<Keybuk> ogra: my laptop suffices for that
<lucas> so I don't think so :)
<Keybuk> ok, so today my wireless signal drops out if I type
<ogra> lucas, but i guess acpi-scripts would be the right package for power-management issues
<Keybuk> and comes back as soon as I take my hands away from the keyboard
<Kamion> Mithrandir: although actually backing up doesn't work properly at the moment - note how if you boot with the parameters above and go back to kbd-chooser, it ignores you even at low priority
<Mithrandir> Kamion: yeah, I just noticed
<Kamion> pain in arse :)
<ogra> Keybuk, i'm on dialup as well, seems my ISP united with yours ...
<sladen> Keybuk: check your antenna hasn't fallen off the card
<doko> fabbione: icon: * Use default gcc-3.4 on sparc to get 3.3 out of main.  "default gcc-3.4" ???
<doko> seb128: just look: /usr/lib/openoffice2/program/senddoc
<fabbione> doko: i meant to say use gcc-3.4 to build icon on sparc.
<fabbione> doko: nothing more
<sladen> Keybuk: is the first 4 seconds (which are blank) the kernel executing before it start the initramfs
<fabbione> doko: i will try with the new gcc soo to see if the ICE is fixed and we can switch it to 4.0
<fabbione> doko: i just had no time for it
<Mithrandir> Kamion: I'm wondering if default_keymap can just return the preseeded value if it's set.
<Keybuk> sladen: yeah, pretty much it seems; it doesn't feel like 4s though
<Keybuk> I assume bootchart takes its "uptime" scale from the kernel's internal clock
<sladen> Keybuk: could get the bootloader to whack the usplash graphic up before it loads the kernel... (a la syslinux/gfxboot)
<sladen> Keybuk: I like the fact you've moved the networking startup to after GDM, I'd been waiting for somebody to accept that as being "acceptable".  It's also what XP does
<Keybuk> sladen: it's not actually "after" so much, it just starts when convenient as it doesn't share any resource block with anything else
<Keybuk> but it is shoved down the priority stack
<Keybuk> and doesn't block anything non-networky
<Keybuk> it's a nice machine :)  I'm happy with it
<sladen> Keybuk: is this the HP laptop, or a supped up amd64 power house?
<Keybuk> Alienware Aurora 7500 - Dual-core ~5Ghz AMD64, 2GB RAM, 10kRPM SATA drives, dual GeForce 7800 GTX SLI cards, etc.
<Mithrandir> probably not ~5GHz amd64.
<Keybuk> that's their estimate thing
<Keybuk> Linux sees it as two 2.5Ghz processors
<Kinnison> so "enough" processing power 
<Mithrandir> Keybuk: so it's a dualcore 2.5GHz, not a 5GHz. :-P
<Keybuk> Mithrandir: right, amd describe it the other way, and I'm not totally an expert on this stuff yet :)
<Mithrandir> they do?  Silly people.
<Kamion> Mithrandir: that looks like it could work too, yeah
<Nafallo> morning :-)
<Mithrandir> Kamion: we should redesign kbd-chooser or drop it, it's a mess, really.
<Mithrandir> Kamion: very, very brittle
<Keybuk> Mithrandir: I think Intel do too with their "Hard Core" processor, so is probably the new marketing game
<Keybuk> "if you get a dual-core it's twice the speed" ... "no, it behaves like two things running at the same speed ... the different is subtle, but important"
<Mithrandir> yup
<Mithrandir> and you can't uniformly say one is better than the other.
<Kamion> Mithrandir: mm
<Mithrandir> Kamion: can a filteredcommand get to the gtk object tree somehow?  I need to plumb a TreeModel in there.
<Mithrandir> Kamion: actually, that'll probably break horribly with the qt frontend.
<Mithrandir> Kamion: any idea how to do this without violating all kinds of abstractions?
<Mithrandir> Riddell: ^^ you might want to comment on this, since it'll affect you.
<jsgotangco> good evening
<HiddenWolf> Keybuk: is that pastebin of any help?
<Keybuk> HiddenWolf: yup, that's fine
<Kinnison> ogra: Who should I ask about a UVF exception for g-p-m?
<pitti> Kinnison: Kamion or mdz
<ogra> Kinnison, mdz/Kamion
<Kinnison> pitti: thanks
<Kinnison> Kamion: g-p-m released a new version recently, which includes a lot of improved help and a lot of translation work. I'd like to update to that (plus our patches)
<HiddenWolf> Groetjes terug. :)
<Kinnison> Kamion: would that be acceptable?
<HiddenWolf> damn, wrong channal
<HiddenWolf> sorry
<ogra> Kinnison, using debian/patches this time would probably be helpful for next upstream merges neither you, nor mjg59 or me used patches ;)
<Kinnison> ogra: yeah, probably. I need to learn how on earth one does that
<ogra> use cdbs-edit-patch ;)
<ogra> its very very easy ... silly me didnt ue it from the start ...
<ogra> *use
<Kinnison> I'll have to look into how one does that
<Kinnison> ogra: if Kamion agrees to the UVF exception I'll do it
<pitti> Kinnison: works very similar to dbs-edit-patch or dpatch-edit-patch
<ogra> you need a debian/patches dir first ...
<ogra> then just: cdbs-edit-patch XXyour_patch_name 
<Kinnison> pitti: I've never had a package complex enough to warrant cdbs/dbs/dpatch
<pitti> oh, interesting
<ogra> where XX is a number for the order it gets applied
<seb128> cdbs-edit-patch is quite basic
* pitti couldn't live without a patch system nowadays
<seb128> doesn't cope with conflicts
<seb128> and doesn't ignore .orig .rej when doing the diff
* Kinnison was pondering using hct for it
<ogra> do we have HCT already anywhere ??
<Kinnison> does anyone here use hct for managing a patch-based package?
<pitti> right, simple-patchsys is very - well - 'simple' :)
<Keybuk> HCT is still waiting on a long list of Launchpad features to be complete
<Kinnison> Keybuk: does it not work in standalone mode at all?
<ogra> thats what i thought
<Keybuk> Kinnison: it doesn't *have* a standalone mode
<Kinnison> Keybuk: fair enough
<Kinnison> seb128: So what would you recommend instead of cdbs?
<azeem> cdbs can use several patches systems, like dpatch, quilt and its own simple-patchsys
<seb128> Kinnison: I do recommend CDBS, almost all the GNOME packages use it
<Kinnison> seb128: you just recommend against simple-patchsys?
<seb128> Kinnison: I was just speaking about cdbs-edit-patch that could use some extra work
<pitti> Kinnison: by using cdbs and gnome.mk, you will automatically get some goodies like good langpack support
<seb128> yep
<seb128> you just have to put a diff to debian/patches and you are done
<pitti> Kinnison: cdbs works with dpatch as well (or quilt)
<Kinnison> pitti: right, so I should use gnome.mk -- I agree it sounds sane for gnome-power-manager
<ogra> Kinnison, i just switched g-p-m to cdbs with last upstream to make it easier for debians gnome team to adopt it ...
<sivang> pitti: langpack suppose made it to upstream cdbs?
* Kinnison is gonna assume Kamion will say "yes" and will get on with it because it'll be a learning experience even if he says no
<pitti> Kinnison: in particular, it will automatically update the POT file (for translation templates) and update .desktop/.server files accordingly
<ogra> (to make seb128 happy ;))
<sivang> s/suppose/support/
<pitti> sivang: no, just into Ubuntu's
<pitti> it's not really a proper cdbs feature, gnome.mk is just misplaced in the cdbs package
<pitti> it should actually belong into some gnome-package-tools or whatever
<pitti> wb mvo
<sivang> pitti: ah, cool. you did it I assume? :)
<pitti> yes
<mvo> hello pitti. my wireless is the suck currently :)
<ogra> hmm, we ship a grub splash now ? 
<ogra> was that planned ? 
<mvo> ogra: yes
<HiddenWolf> do we? not on upgrades?
<ogra> mvo, where was that specced ? i didnt know about it ... 
<mvo> ogra: got a mail about it this morning that we want to enable it for testing in dapper
<mvo> ogra: I didn't too until this morning :)
<ogra> *sigh* 
* ogra grabs edubuntu-artwork via ISDN ....
<JaneW> sivang/ Lathiat/ mjg59 : ping, are you planning to attend the Dapper Status meeting in 35 mins? If not please send a status update to me by e-mail or PM. Thanks.
<ogra> JaneW, has mjg59 anything lft now that Kinnison has power management assigned ? 
<ogra> *left
<Kinnison> ogra: god yes
<Kinnison> ogra: I don't know anywhere near enough to take on mjg59's full set
<mvo> ogra: isdn?
<JaneW> ogra: er I heard about Kinnison doing power management... but it's still listed as mjg59 on the report, is it officially changed then?
<ogra> mvo, yup... my DSL broke last night ...
<JaneW> oooh when did the LP fonts change?
<mvo> Kinnison: gnome-power-manager is working nicely on my box, good job. the default value for the display brightness is a bit low though (but I'm sure that was reported before)
<ogra> JaneW, i guess Kinnison might take the spec with mjg59 doing his usual work on it ...
<Kamion> Kinnison: can you send mail with the changelog please?
<viviersf> infinity, ping
<ogra> mvo, i changed it yesterday
<mvo> ogra: thanks :)
<ogra> mvo, can you look up at how many percent it sits now ? 
<JaneW> Kinnison: can I reassing spec to you? https://launchpad.net/distros/ubuntu/+spec/power-management-configuration
<Kamion> Mithrandir: add a method to the frontend to do whatever you need, call it from the filteredcommand subclass
<ogra> mvo, should be 100% for AC and 70% for battery
<Kinnison> JaneW: assignee? sure
<Kamion> Mithrandir: there are several examples already down near the bottom of gtkui.py
<ogra> (it was originally at 7% and 3% :) )
<Kamion> e.g. set_autopartition_choices
<mvo> ogra: when I installed it last night it was still 7 and 3 :)
<Kinnison> Kamion: http://mail.gnome.org/archives/gnome-power-manager-list/2006-February/msg00025.html is the release announce
<Kinnison> Kamion: do you need more than that?
<mjg59> Kinnison: There's an issue with the new release
<ogra> mvo, oh, then you got the older version ... was fixed in ubuntu8
<Kinnison> mjg59: go on... ?
<mjg59> Kinnison: In that it makes changes orthogonal to your lid locking
<Kinnison> mjg59: yes I know
<mjg59> That is, the lid action now only occurs on battery
<Kinnison> mjg59: I expect I'll be reverting that bit
<mjg59> Which leaves us moving lock on lid close preferences back to g-s-s (or adding more UI elements to g-p-m)
<Kinnison> g-p-p should have a lid action for ac and for battery if this guy is serious
<Kamion> Kinnison: fine if you discuss/resolve the lid/battery issue with mjg59
<Kinnison> Kamion: thanks
<Mithrandir> Kamion: hm, 'k
<ogra> mjg59, Kinnison, cant we just omit that change and go on using Kinnisons change ? 
<Kinnison> mjg59: it's a small change to revert that bit of the upgrade
<JaneW> Kinnison: done
<ogra> its the more sane approach i think
<Kinnison> mjg59: isolated to one function in gpm-manager.c and I can see how to revert it cleanly for now
<ogra> Kinnison++
<mjg59> I think the upstream change makes sense, though
<Kamion> Riddell: anything for me to merge yet for the Qt espresso frontend?
<Toma-> just an idea here... but would it be possible to take a desktop snapshot on shutdown and convert it to a usplash boot image? so that when the machine reboot, an image of your desktop pops up...?
<Kinnison> mjg59: if you feel it makes sense, then I can adjust my lid patch to match
<Kinnison> mjg59: So it won't lock if you're on ac
* ogra doesnt feel that makes sense ...
<mjg59> Kinnison: No, I think locking should happen regardless of ac. I think sleep should only happen when on battery.
<ogra> yes 
<Kinnison> mjg59: right, I can do that
<ogra> but keep the locking as is  ...
<mjg59> Kinnison: Which means they can't be part of the same UI element
<Kinnison> it'll need a larger patch but I can do that
<mjg59> Since semantically it's "Do this when on battery and lid is closed"
<Kinnison> mjg59: richard and I have discussed making the locking separate from the action
<mjg59> Kinnison: Yeah
<Kinnison> mjg59: but it'll be a while before upstream gets there
<mjg59> Kinnison: But that's going to be a pain to describe in the UI
* mjg59 still thinks it should just go in g-s-s, but...
<Kinnison> http://bugzilla.gnome.org/show_bug.cgi?id=331164
<JaneW> Kinnison: any chance you could get that spec out of drafting?
<Ubugtu> gnome2 bug 331164 in gnome-power-manager "No facility to lock the screen on lid closure" [Enhancement,Unconfirmed]  
<Kinnison> JaneW: not by 1400utc
<JaneW> Kinnison: heh, I mean in the next week ;), but by the time I send out the report tomorrow would be even better ...
<JaneW> Kinnison: it would move your goal out of red ... and rem Green is good
<Kinnison> JaneW: I'll do my best
<tseng> can anyone clear banshee and beagle from NEW?
<sladen> Toma-: dithered in fablous 14-colours!
<janimo> are package builds labeled with MANUALDEPWAIT  in LP getting given back daily by somebody?
<ogra> mjg59, as long as its tied to the action, i still think it should be in the ui where the action is defined ...
<Toma-> sladen, oh... usplash is 14 colours? :|
<Keybuk> seb128: could you duplicate your alsa udev rule, and put something like "ls /dev/snd >> /var/run/test.log" in RUN instead ... I have a hunch that your controlC0 appears before your mixer <g>
<Toma-> sladen, i thought it would use fb?
<mjg59> ogra: But then we have difficulty explaining it
<sladen> Toma-: it does.
<ogra> janimo, did you note,  we need grub images now for derivative artwork 
<Toma-> doesnt fb go up to 64k?
<seb128> Keybuk: sure, should I reboot or just udev restart then?
<mjg59> Toma-: vga16 doesn't, no
<Toma-> at least with the vga= options is does...
<janimo> ogra, the gfx boot stuff you mean?
<Toma-> oic
<Keybuk> seb128: reboot I suspect, so just do it when you have a moment and nothing important
<Keybuk> it's a "minor"ish bug
<janimo> or regular grub splashes
<seb128> it's quite annoying :)
<ogra> mjg59, yes, i know, but its tied to the lid actions ... so i'd make it configurable as a lid action ... gss has no actions at all ..
<ogra> janimo, the latter
<janimo> ogra, so they're no longer considered harmful for some boxes?
<ogra> janimo, see mvo's last grub upload ...
<ogra> janimo, ask sabdfl ;)
<janimo> ogra, thanks
<Riddell> Kamion: nothing that's worth it yet I think
<Toma-> I had an awesome idea today that from grub, the users pseudo desktop would appear and have a loading throbber in the middle, and once its all done, the desktop would take the images place... maybe ill just keep dreaming :)
<theCore> does the bootscripts have been updated in Dapper ?
<mjg59> ogra: If "Lid action" in g-p-m is defined as "What happens when the lid is closed and you're off AC", how do you describe "Lock screen on lid close"?
<mvo> janimo: we want to try it out and see how well it does 
<janimo> ogra, is it ok if I go ahead with using the gdm derivative theme alternative already (i.e before edubuntu)
<ogra> mjg59, as you just did ...
<janimo> mvo, thanks
<mjg59> ogra: But then people will think it means "Lock screen when lid is closed and you're off AC"
<ogra> mjg59, "Lock screen on lid close" ... not tied to AC or batt ...
* Kinnison needs to look at the new gpp dialog
<mjg59> ogra: But you've previously defined "lid close" as only being relevant when on battery
<ogra> not if the other menu items talk about AC or batt
<janimo> mvo, which package contains the splash for ubuntu, so I have a model
<mjg59> ogra: It would suck as a UI
<ogra> hmm
<mvo> janimo: ubuntu-artwork, it uses the alternatives system so it's easy to provide a differnt one
<theCore> janimo, usplash 
<ogra> mjg59, probably the ui should change then ...
<janimo> mvo, great xubuntu already has that package for the usplash image
<Toma-> is vga16 any good with greyscale?
<janimo> theCore, thanks
<mjg59> Toma-: You get 16 colours
<theCore> janimo, np
<mjg59> They can be whatever you want
<Toma-> mjg59, ok :(
<ogra> mjg59, having a general checkbox "always lock on lid close" or something like that
<mvo> janimo: you can't have more than 14 colors
<mjg59> You also get 640x400
<mjg59> ogra: But then that sounds like unchecking it is "Sometimes lock on lid close"
<raphink> mjg59: I'm currently testing Xgl
<raphink> and I've got a few issues
* Keybuk wonders how *not* getting annoying startup and bingle-boingle sounds can be considered "annoying"
<raphink> say I'm not able to start gdm or kdm
<janimo> mvo, same with usplash ?(iirc that has 16 colors - 4bit png)
<ogra> mjg59, "only lock on lid close" ?
<Treenaks> ogra: 'Lock on lid clode'
<infinity> viviersf: pong.
<raphink> argh
<theCore> it is impressive what you can do with only 16 colors
<mjg59> ogra: That would mean "Don't ever lock unless the lid is closed"
<ogra> Treenaks, that brings up the question: who is clode ?
<jdub> mjg59: should i be testing/using n-m on atheros?
<Treenaks> ogra: some French guy, probably
<raphink> mjg59: when I start kdm/gdm with Xgl a
<ogra> mjg59, thats evil to discuss with a native speaker :P
<mjg59> ogra: Right, as a native speaker, I can't think of any way to disambiguate this
<raphink> mjg59: I get a turning wheel over a black screen, then nothing
<Toma-> rhgb uses an X server... maybe my dream can come true if i compile rhgb for ubuntu :P~
<raphink> 
<mjg59> jdub: No idea. Ask Scott or Adam what the situation is with madwifi-ng
<jdub> mjg59: ok, ta
<mjg59> I've heard nothing since the sprint
<jdub> Keybuk: pingalingaling
<raphink> mjg59: any idea what that might be?
<mjg59> raphink: What hardware?
<raphink> mjg59: ATI Radeon 9200
<mjg59> None
<jdub> mjg59: btw, Xgl sits with thinking cursor before gdm loads on my ati (using fglrx or ati)
<Treenaks> raphink: I have the same on fglrx on an x700
<raphink> Treenaks: same error?
<mjg59> jdub: As in it never goes past that?
<jdub> mjg59: yeah
<mjg59> jdub: No idea
<Treenaks> raphink: I use this .xsession, and the 'normal' /usr/bin/X
<Treenaks> raphink: http://paste.ubuntu-nl.org/8709
<raphink> Treenaks: I'm on irssi :s
<janimo> Treenaks, do you have ati r300 accelerated on the x700 ?
<Keybuk> jdub: 'sup?
<Treenaks> raphink: it's crashy, and wobbly gets annoying quickly
<raphink> Treenaks: ok
<Treenaks> janimo: no, i'm using fglrx
<Treenaks> janimo: I have other problems with ati, which I'll debug this weekend
<seb128> Keybuk: no log, no log when restarting udev neither
<seb128> Keybuk: that's like the rules were not used
<janimo> Treenaks, ok. I just get r300 errors in xorg.log and no DRI from the free driver
<jdub> Keybuk: n-m + atheros - happy couple now?
<Treenaks> janimo: I have that working on a M10 (Radeon 9600 or something)
<Keybuk> jdub: no, only madwifi-ng works
<Keybuk> seb128: interesting
<Keybuk> seb128: don't suppose you could do something like init=/bin/sh ... start loopback, checkroot, mountall ... then do "udevd --daemon", "udevmonitor -e >/some.log &", "udevplug" ?
<mjg59> Keybuk: What's the situation with getting madwifi-ng into l-r-m?
<mjg59> We need it for hardware support in any case
<seb128> Keybuk: I'll do that after distro team meeting or I'll be late for it :)
<fabbione> Devel Meeting in -7 
<Keybuk> mjg59: nobody came forward to help test it on amd64
<Keybuk> so "not for dapper" at this point
<Keybuk> upstream have pretty solidly said it won't work there
<janimo> pitti, when you have time can you please review xfdesktop, it's the official upstream code with official debian packaging
<janimo> as opposed to what we had so far
<JaneW> doko,  iwj, lathiat, sivan, Kinnison : ping - meeting in 5 mins in #ubuntu-meeting
<pitti> janimo: yes, I scheduled some main inclusion reviews for tomorrow morning
<janimo> thank you. it is the last piece of xubuntu
<janimo> significant piece that is, still in universe
<jdub> ahr
<sladen> Keybuk: I always press the hardware mute button on my Thinkpad after turning it on.  It would be quite refreshing to ditch the startup sounds
<Keybuk> . o O { ya know, it's almost worth doing udevmonitor around the initial udevplug anyway ... just for debugging log purposes }
<mjg59> Keybuk: So no n-m?
<sladen> ogra: what I actually want is "Lock if lid is closed for more than NN seconds" (eg. 30).  If I close it to adjust the power cable, I don't want it locked
<mjg59> Keybuk: If you can get me an Atheros, I can test on amd64 (and probably get the driver working, assuming that the issue isn't in the HAL)
<Keybuk> mjg59: n-m will be supported, but not installed by default
<ogra> sladen, thats nothing g-p-m offers yet ...
<Keybuk> even if madwifi-ng were in dapper, n-m would still not be in desktop
<Keybuk> it's just too fucking unreliable
<seb128> Keybuk: why not by default?
<seb128> bah :/
<Keybuk> because they only appear to have tested it on centrino cards
<Keybuk> on almost every, single, other, driver it fucks up
<Keybuk> usually *badly*
<mjg59> seb128: It can't be in by default if it fails to work on common hardware
<mjg59> Keybuk: What are the failures you're seeing?
<mjg59> It /is/ tested on a much larger range of hardware than that
<seb128> mjg59: my impression was it is working quite ok on most of common cards in fact
<Keybuk> mjg59: failure to scan, failure to lock onto networks, failure to manage dhcp properly, getting wedged in stupid states that require killing of n-m
<Kinnison> mjg59: My proposal for the lid action stuff is to perform the lock action always (if selected) but to only perform suspend/hibernate in case of battery -- sound okay?
<Keybuk> it worked for very few of *us* at the sprint
<mjg59> Kinnison: No, that's insane
<janimo> does no other distro ship n-m by default?
<jdub> janimo: none
<Kinnison> mjg59: Hmm
<Kinnison> mjg59: My other proposal is that if locking is enabled in g-s-s, you lock on lid closure, and if the user therefore selects 'no action' then it'll still lock
<mjg59> Kinnison: The UI element should be consistent. If it has "lid action", everything in that dropdown has to act under the same circumstances
<janimo> and the one that suse ships (network applet) does that suck too?
<Kinnison> mjg59: making it look as though g-s-s is locking the screen on lid closure
<mjg59> Kinnison: Hmm. I suppose, yes.
<janimo> not sure if it's called that
<jdub> janimo: they ship n-m now 9but yes)
<Keybuk> I think we definitely want n-m in main, and maybe even in ship, because when it does work, it's great
<Keybuk> and does exactly what it says it should
<mjg59> seb128: It's useless on Atheros hardware without madwifi-ng
<Keybuk> it's just that when it doesn't work, it requires rather a lot of technical skill to rescue your network connection
<sladen> Kinnison: g-p-m is lacking the option to suspend on critical battery, hibernate is bit too much
<pitti> Keybuk: can we make it ignore devices in /e/n/interfaces?
<mjg59> sladen: No, critical battery is the point where your hardware is telling you that it'll crap out any second
<mjg59> sladen: Suspend isn't a sensible option there
<janimo> Keybuk, arent't those skills needed anyway if you don;t use n-m? does it make things worse when it fauils?
<Keybuk> pitti: it does here, I absolutely promise that it gets uploaded today <g>
<Keybuk> honest
<pitti> Keybuk: cool, thanks
<Kinnison> mjg59: So are we agreed that we'll lock on lid closure if g-s-s has lock enabled, and leave it at that?
<Keybuk> janimo: not particularly, and not outside of laptops
<mjg59> Kinnison: Yeah
<Kinnison> mjg59: thanks. I'm useless at UI so having you sanity check is really useful for me
<pitti> Keybuk: then I don't see any problem with putting it into desktop (apart from the fact that it probably should replace the old network applet)
<sladen> mjg59: it's a very sensible option.  My Thinkpad will sleep for about 18hours with 5% battery.  More than enough to find a plug!
<Keybuk> pitti: it's not an applet, so it's damned hard to replace that
<pitti> Keybuk: right, we have a similar problem with the old battstat vs. g-p-m
<mjg59> sladen: 5% is not critical battery
<sladen> mjg59: (or rather this is precisely how I've operated with my R31 for 2.5years and I like the behaviour;  I know it gives me another 20minutes after the battery gets to zero
<Keybuk> pitti: and then I'm worried everyone will wonder what the applet does, when everything under it is disabled
<mjg59> sladen: Mine claims that 1% of design capacity is critical
<sladen> mjg59: according to g-p-m it is (those are the out of the box settings).  
<Keybuk> click ... Wired Network (manually configured) ... Wireless Network (manually configured) ... etc.
<mjg59> sladen: Then g-p-m is wrong
<mjg59> That's an entirely different bug
<pitti> Keybuk: hm, of course it would just rock if n-m would call ifup/ifdown on the interfaces in /e/n/i, but I guess that's too much work?
<Keybuk> pitti: I don't see how that would help
<seb128> Keybuk: could you make n-m not destroy resolv.conf when using a static config? :)
<pitti> Keybuk: well, I could upgrade from breezy and control my already configured eth0/wlan0 without breaking the configuration in /e/n/i
<Keybuk> seb128: it doesn't here (cf. promise I'll upload it today <g>)
<seb128> nice :)
<Keybuk> pitti: but then it'd ignore the wireless_essid rules, etc. that you have configured
<pitti> Keybuk: i. e. right now I'm typing sudo ifup eth0 whenever I plug in my eth cable
<seb128> Keybuk: btw the /var /tmp fix works just fine :)
<pitti> Keybuk: oh, how that?
<Keybuk> it's a replacement for ifupdown, making it integrated is kinda against the idea
<jdub> Keybuk: mandatory settings :-)
<Keybuk> seb128: oh, good
<mjg59> pitti: The n-m UI assumes it's entirely under the control of the applet
<seb128> Keybuk: and I fixed your hplip upload, you didn't list the patch to 00list :p
<pitti> Keybuk: right, that's what I mean with 'too much work'
<Keybuk> seb128: doesn't dpatch-edit-patch do that automatically? :p
<mjg59> pitti: Trying to remove that assumption destroyes the entire UI
<pitti> right
<seb128> Keybuk: no, but it should probably :)
<Keybuk> gah
<Keybuk> thanks
<pitti> hmm, then the only other sane option is to just install it for new installations? (not sure how we'll do that, though)
<mjg59> Keybuk: Ok. In that case we need to talk about how networking works at some stage
<Keybuk> mjg59: we do, yes
<mjg59> Keybuk: Since I'd been assuming that we could rely on n-m to bring back interfaces after suspend
<Keybuk> "how networking works" is an annoyingly tricky one ... because the nice bits aren't finished enough yet
<Keybuk> mjg59: ifdown -a / ifup -a as well should be ok ... as the two are mutually exclusive
<mjg59> Keybuk: No, that's not good, since we should restore to the suspended state
<mjg59> And right now devices still sometimes come up in a different order over suspend/resume
<Keybuk> well, you know what I mean :)  parse ifstate, bring down interfaces and remember them, bring them up again
<janimo> infinity, please give back xfdesktop4 if you do that kind of thing. it is MANUALDEPWAIT in LP. thanks
<Keybuk> fabbione: quick question ... how do I limit the refresh rate in X ... it's using "75Hz", I only want it to use "72"
<fabbione> Keybuk: add VertSync to your monitor section
<ogra> Keybuk, reducing hsync vertrefresh
<Keybuk> ah, of course
<infinity> janimo: Which arch?
<janimo> i386 mostly
<janimo> I think the others are in dep too
* infinity looks.
<infinity> janimo: given-back...
<janimo> infinity, thank you
<infinity> janimo: buildd maintenance is a bit bumpy right now (the LP guys are working hard to make things better, mind you), so if you could keep an eye on packages you care about (like the whole xfce stack) and mail me if things seem "not quite right", that'll save me from having to do the same. :/
<infinity> janimo: Since you tend to upload about 50 packages at once in massive batches, and they all interdepend, I expect you're going to be in a bit of a tangle right now.
<Kamion>  +- mozilla-dev
<Kamion>  |  * Reverse Build-Depends:
<Kamion>  |   +- enigmail
<Kamion>  |   +- enigmail
<Kamion> pitti: ^--
<Kamion> like I say, dunno if that's real
<pitti> Kamion: hm, the new packages built everywhere...
<pitti> Kamion: maybe it's looking at SOE packages?
<infinity> Kamion: Could be an SCC arch?
<fabbione> possibly
<janimo> infinity, ok thanks. I think the hardest part is over, I won;t upload so many interdependent packages at once
<fabbione> neither sparc or hppa are in the archive
<Kamion> no, those particular germinate runs only look at i386
<infinity> Oh, hrm.
<Kamion> (which is why they aren't quite as reliable as anastacia)
<infinity> Odd.  The new enigmail source definitely doesn't build-dep on mozilla-dev
<doko> iwj: please could you reenable -fno-strict-aliasing for firefox on amd64? trying to work around some crashes. a test build looks more stable
<infinity> enigmail-mailnews does, but it should be heading to universe.
<Kamion> mozilla-thunderbird-enigmail's in the supported seed
<Kamion> which comes from the enigmail source
<pitti> that should be fine
<fabbione> Diziet: what doko said for sparc too please.
<infinity> Kamion: And the enigmail source no longer build-depends on mozilla-dev...
<Kamion> let me look at this post-meeting
* infinity nods.
<seb128> Diziet: do you have some standard reply for firefox bug? Like getting a backtrace is standard gdb use, or is there some variable to set or instructions specific to it?
<janimo> Kamion, are you doing promotions to main?if so when is a good time to ping you about the xfce lot?
<seb128> Diziet: I would sometime puts the useless bug needinfo while assigning them but I'm not sure of what kind of details are useful for it
<Kamion> janimo: after we have anastacia again so that I don't break stuff
<Keybuk> mjg59, infinity: random ... with madwifi-ng, can I wlanconfig ath1 up, and have that locked onto a different wireless network to ath0? :p
<Keybuk> and route/forward between them? :p
<infinity> Keybuk: I have no idea.  Maybe?
<pitti> Kamion: btw, today's ppc install and live CDs work fine
<infinity> Keybuk: I have no ath hardware in my hands anymore.
<pitti> Kamion: will test amd64 later today, too
<janimo> mvo, does language selector have a kubuntu equivalent? 
<Riddell> janimo: no
<infinity> Keybuk: I also got a lot of "doesn't work for me, EEK, IT'S BROKEN" reports on madwifi-ng (and a lot of users that use it on amd64, apparently), so unless we're prepared to get in elbow deep and fix a mess of bugs, I think we're stuck with madwifi-old for dapper...
<janimo> Riddell, does kubuntu need one though?
<mvo> janimo: I *think* it has nothing gnome specific in it, you could use it too
<janimo> mvo, yes I saw it is gtk only :)
<Keybuk> infinity: agree (see above)  I think madwifi-ng has missed the dapper boat
<Riddell> janimo: it would certainly be great to get one of course
<infinity> Keybuk: Or I could mangle things and ship both, with some hackery, like we do with the nvidia binary stuff.
<Keybuk> unless we can package it as an alternate?
<janimo> mvo, as in dependencies, but is it looking for gnome langpacks only or anything lang related?
<Keybuk> yeah, I'd like to do that if possible, with the old madwifi as the default
<mvo> Riddell: it should be easy to port
<infinity> Keybuk: I'll look into it.
<Riddell> janimo: there you go, easy, fancy doing it? :)
<mvo> janimo: it looks for everything, so it will work for kde as well
* mvo goes back to his meeting
<janimo> Riddell, I might neved done qt so far so it would be cool :)
<Kamion> pitti: great, thanks
<doko> Kamion: talked with Riddell, please remove knetworkconf and sanekonsole
<janimo> mvo, good, as I am putting it in xubuntu-desktop
<Kamion> doko: have you/Riddell checked for reverse-dependencies? the archive tools to do that check don't work yet
<Kamion> infinity: oh, haha
<Kamion> "$HOME/germinate/germinate.py" -m http://jackass/ -s "$NAME" -d "$DIST" ${COMPONENTS:+-c "$COMPONENTS"} > _germinate_output
<Kamion> spot the mistake
<janimo> mvo, I was scared for a while of looking at you bzr archives since you have 'classic'  archive names ;)
<mvo> Riddell: I would do it myself if you could give me a tour to pyqt
<infinity> Kamion: Whoops. :)
<mvo> janimo: old habbits die hard :)
<doko> Kamion: none, knetworkconf is now built from kdeadmin, so its just a source removal
<Riddell> Kamion: both packages are unused, sanekonsole obsolete by kde 3.5 and knetworkconf source by kdeadmin
<Riddell> Kamion: also lipstik source package can be removed (now built from kde-style-liptick)
<Kamion> sanekonsole | 0.2-0ubuntu4 |        dapper | amd64, hppa, i386, ia64, powerpc, sparc
<Kamion> sanekonsole | 0.2-0ubuntu5 |        dapper | source
<Kamion> so all the binaries there should die too?
<Riddell> Kamion: yes
<Kamion> should konsole perhaps conflict/replace it?
<Kamion> or provide?
<Riddell> Kamion: it doesn't include any of the same files (same code right enough)
<doko> Kamion: more removal training ;)  cyrus22-imapd (universe), including binaries. new packages have new names (maybe sit in NEW)
<Riddell> it was only a temporary package while kde 3.4 konsole didn't have the functionality needed
<infinity> seb128: My goofy progress bars in thunderbird magically fixed themselves.  I assume that was due to your gtk2-engines-* upload?
<seb128> infinity: could be yep, as said it was either a gtk or a theme issue .. 
<seb128> good to know it's fixed :)
<infinity> seb128: Do you want me to reassign the bug so you have a mental placeholder for it (especially if you update gtk2-engines again and it comes back...), or just close it?
<seb128> infinity: reassign to gtk2-engines please, and set the severity to minor, thank you
<infinity> seb128: Will do.
<seb128> cool
<infinity> seb128: I'll attach my screenshot as a reminder of the goofiness.
<seb128> k
<Kamion> Riddell: all yours done
<Kamion> doko: just processing the stuff in NEW then I'll do your removals
<alexr> Mithrandir: are you there?
<Kamion> doko: done
<Kamion> seb128: any idea why firefox doesn't appear in the top panel on a fresh install any more?
<Mithrandir> alexr: yes
<alexr> I tried squashfs last night.
<Kamion> janimo: you might want to look at "Subject: [dapper]  busted!" on ubuntu-users if you haven't already
<seb128> Kamion: no, but pitti mentionned that already for liveCD (it was working fine for install when he did), I'll give it a try soon ... the profile didn't change so it's weird
<janimo> Kamion, I haven;t thanks
<Kamion> janimo: looks like a missing Replaces
<alexr> Mithrandir: Do I understand it correctly that I need to mount and extract the data from it, then chroot to this new dir, add whatever, and then mksquashfs and pack things up?
<Kamion> seb128: anything I can investigate for you here?
* pitti checks his fresh ppc install again
<Mithrandir> alexr: sounds right.
<seb128> Kamion: do you have a gconf /apps/panel/default_setup/objects/firefox_launcher ?
<alexr> Mithrandir: Now, with breezy and cloop, one needed to do some tricks. E.g. once you delete something from the cloop filesystem, you need to clean the deleted blocks.
<seb128> browse it with gconf-editor, you can search for a key with firefox as value
<alexr> Mithrandir: I don't need to do anything like this now, do I?
<alexr> Mithrandir: because I have normal dir and not mounted fs>
<Mithrandir> alexr: no, no tricks like that any more.
<alexr> Super!
<alexr> OK, what's with the isolinux -- is everything the same there as it was last time around?
<alexr> E.g. splash, boot sector, etc?
<Mithrandir> if you just take the isolinux files which are on the cd already, you should be fine.
<Mithrandir> if you use the old stuff, just make sure to pass boot=casper to use casper
<alexr> Mithrandir: path boot=casper to mkisofs?
<redisdead> hello
<Mithrandir> alexr: no, on the isolinux command line
<Kamion> seb128: no, only browser_launcher
<Kamion> which points to epiphany
<redisdead> I think there is a broken dependency in dapper : linux-2.6.15-* should depend from udev
<Mithrandir> alexr: just look at the current isolinux.cfg
<alexr> Will do, thanks!
<Kamion> only keys with firefox in the value are /desktop/gnome/url-handlers/{http,https}/command
<alexr> Mithrandir: all in all, looks like it's easier to modify the LiveCD now.
<alexr> Mithrandir: if only you have suaqshfs-capable kernel :-)
<pitti> Kamion, seb128: confirmed, I do get a ffox icon in a fresh ppc install; it's just missing in the live session
<Mithrandir> alexr: yes, it should be much easier.  You need both squashfs and unionfs in the kernel, though.
<alexr> Mithrandir: why unionfs?
<seb128> Kamion: is that a desktop or a laptop ?
<Kamion> seb128: vmware
<Mithrandir> alexr: because you need a writable file system on top of the read only fs.
<Kamion> on a desktop
<seb128> Kamion: so desktop according to laptop-detect?
<alexr> Mithrandir: I didn't have unionfs, and here's what I did last night:
<Mithrandir> alexr: earlier, you got that by having a writable block device and devmapper snapshots.  Now you get it through having a writable file system on top of a read-only fs.
<Kamion> laptop-detect exits 1, so yes
<alexr> Mithrandir: (1) mount squashfs (2) rsync it to a regular directory (3) modify (4) mksquashfs
<Kamion> Mithrandir: still no /usr/sbin in my default $PATH
<Mithrandir> alexr: correct.
<alexr> Mithrandir: So no unionfs?
<seb128> Kamion: HOME=/root sudo gconftool-2 --direct --config-source=`gconftool-2 --get-default-source` --load /usr/share/gconf/schemas/panel-default-setup.entries
<seb128> Kamion: does that makes any difference to the default profile?
<alexr> Mithrandir: or would I not have to rsync and then mksquashfs if I had unionfs?
<Mithrandir> alexr: unionfs is used by the live kernel and set up as part of the boot process.
<seb128> Kamion: you may need to create a new user to try
<alexr> I see. So I don't need it to add packages.
<seb128> or rm -rf ~/.gconf if that's a stock install and don't care about it and restart the panel
<Mithrandir> alexr: correct, as long as you use the default kernel you don't have to worry.
<alexr> Mithrandir: It's only needed for live system, not for my system.
<Mithrandir> alexr: it'll be a lot easier to customise the live cd a little bit later in the cycle.
<Mithrandir> correct.
<alexr> Mithrandir: here's the thing -- I run Debian, not ubuntu.
<alexr> Mithrandir: so my kernel is not ubuntu default.
<alexr> Mithrandir: but last time it worked just fine.
<Mithrandir> alexr: I'm talking about the kernel on the live cd, not the kernel on your running system
<alexr> Mithrandir: Got you, thanks.
<Mithrandir> Kamion: investigating
<Kamion> seb128: created test user, was hosed ("Could not load icon" "Details: Icon 'gnome-logout' not found")
<Kamion> (and Icon 'evolution')
<Kamion> still no firefox icon
<Keybuk> BenC: ping?
<BenC> Keybuk: pong
<seb128> Kamion: interesting ... I've an ideea, I'll investigate and let you know in a couple of min
<Kyral> Whoever posted those Xgl instructions on -devel-announce, thanks.
<Kamion> seb128: also did rm -rf ~/.gconf, logged out, logged in, nope
<alexr> Mithrandir: looking at the isolinux.cfg: GFXBOOT bootlogo
<seb128> Kamion: I bet if you do that with /usr/share/gconf/schemas/panel-default-setup-laptop.entries you have it?
<alexr> Mithrandir: what is bootlogo and how does one tweak it?
<Kamion> alexr: that comes from gfxboot-theme-ubuntu
<seb128> Kamion: same line as before but with -laptop
<alexr> Kamion: OK, thanks
<Riddell> mdz: http://kubuntu.org/~jriddell/tmp/adept-notifier.png
<seb128> (should add an extra battstat tto)
<seb128> too
<Keybuk> BenC: so, what do you know about PCI Express, specifically the kernels implementation of it
<Keybuk> I have a box here, and it looks rather like everything on that bus just shows up on the PCI bus
<BenC> Keybuk: pretty much zero
<Kamion> seb128: hang on, when I did rm -rf ~/.gconf the panel hung, I had to ctrl-alt-bksp to get out, and now my desktop is fucked and won't start up properly
<Keybuk> /sys/bus/pci_express/devices contains a bunch of symlinks (all with the same two filenames - which is rather amusing) which all point to devices on the PCI bus
<Keybuk> ah, do you know who would?
<BenC> as far as I know, the pci subsystem just tries to make it work like other PCI devices
<alexr> Mithrandir, Kamion: thanks! See you later.
<Mithrandir> alexr: have fun
<Keybuk> ok, that sounds like what I'm seeing
* Kamion kills all processes with great prejudice
<Keybuk> I want to make sure we don't suddenly get bitten in dapper when in two years time, everything has PCI Express, and suddenly nobody's IDE/SATA/SCSI/etc. drivers get loaded <g>
<ogra> Kamion, wouldnt reboot be easier ? 
<Kamion> ogra: shrug
<BenC> Keybuk: are the PCI Expresse devices working?
<ogra> heh
<Keybuk> BenC: I assume so, they include the video card and stuff :)
<BenC> or are all those devices just regular PCI devices on a PCI-E bus?
<Keybuk> they're definitely PCI-E devices
<BenC> ok, yeah, I think we are ok
<Keybuk> X can see the video card and use it
<Mithrandir> Kamion: what do your /etc/environment look like?
<Kamion> Mithrandir: no PATH
<Keybuk> I think the ethernet and sound cards are also PCI-E
<Mithrandir> Kamion: and your live fs is not ancient?
<Keybuk> (they're on 0000:05)
<Keybuk> and linux seems happy with box
<Kamion> Mithrandir: this is a fresh install not a live CD
<Keybuk> uh, with both
<Mithrandir> Kamion: ah, ok.  d-i install, not espresso?
<Kamion> Mithrandir: yes
<Kamion> today's daily install CD
<infinity> Keybuk / BenC: The kernel handled PCI express internally and exposes it as PCI with extensions.
<Kamion> seb128: yes, with -laptop I get a firefox icon
<mdz> Riddell: which icon activates it?  the /!\ ?
<BenC> infinity: yeah, that's what I figured
<BenC> just like AGP
<Keybuk> infinity: what symlinks do you get in /sys/bus/pci_express/devices ?
<infinity> Keybuk / BenC: For most cases, it "Just Works", for cases where you might want somehting fancy (like wankloads of bandwidth to a video card), you can either address it as "plain old slow PCI", or write to it as a scary fast PCI express device.
<Riddell> mdz: how do you mean?  it shows that icon when there's updates, clicking on it brings up the adept-updater tool
<Kamion> Mithrandir: I note that your && || precedence is screwy in libpam-modules, although that wouldn't cause this bug
<seb128> Kamion: could you edit /usr/share/gconf/schemas/panel-default-setup.entries, replace epiphany.desktop by firefox.desktop and try again the first variant?
<infinity> Keybuk: pcie0[023]  -> ../../../devices/pci...
<Kamion> should be ... && (... || ...) not ... && ... || ...
* BenC is about to become a beta-tester for Xgl on ppc
<seb128> Kamion: I think that this changed has been dropped by mistake
<Keybuk> infinity: do you get multiples of each filename?
<infinity> Keybuk: Yes.
<Keybuk> heh, me too
<Keybuk> BenC: don't suppose you could tickle someone into fixing that?
<pitti_live> Mithrandir: hm, still the wrong resolution on amd64/live, do you want to debug this with me?
<Keybuk> it makes readdir/readlink loops damned hard <g>
<BenC> Keybuk: can you send me a ls -l of the files in question?
<Mithrandir> pitti_live: does sudo ddcprobe give you anything useful?
* infinity dumps it to -kernel
<pitti_live> Mithrandir: yes, it looks pretty nice, I'll /msg
<Keybuk> pasted to -kernel
<pitti_live> Mithrandir: whoops, this user is not reg'ed, did you get /msg?
<Mithrandir> pitti_live: yes, I got it
<Kamion> Mithrandir: hmm, I have a feeling d-i might be clobbering /etc/environment
<seb128> Diziet: did you read my question before?
<Mithrandir> Kamion: I can't see anything wrong in my code, for once, so I suspect so. :-/
<Kamion> because 'sudo /var/lib/dpkg/info/libpam-modules.postinst configure ""' makes it work
<Kamion> seb128: BTW any reason why panel-default-setup-laptop.entries uses file:///usr/share/applications/*.desktop while panel-default-setup.entries just uses *.desktop?
<Kamion> seb128: yes, works after that change, thanks
<seb128> Kamion: for the path no, -laptop is a copy of the .entries for some time ago and we didn't merge some cosmetic change like that
<seb128> I'll fix the epiphany/firefox now
<Kamion> thanks
<Kamion> Mithrandir: yeah, it's localechooser's fault, fixing now
<Mithrandir> Kamion: thanks.
<Kamion> hm, damn, will need a d-i build
<carlos> pitti: hi
<pitti_live> carlos: hey
<carlos> pitti_live: Could you give me an URL to download your pkgstriptranslation updated packages?
<seb128> Kamion: gnome-panel fixed version uploaded
<carlos> pitti_live: celso and I are going to test the new soyuz version and need it to test the Rosetta integration
<Riddell> Kamion: I should start testing CDs for flight 4 now yes?
<Kamion> Mithrandir: could you push your casper trunk branch please?
<Kamion> Mithrandir: have a bug to fix :-/
<Kamion> Riddell: yeah
<pitti_live> Kamion: amd64/live works well, btw
<Kamion> although I think I'll be respinning, but you might as well see if there are any issues we haven't found yet
<Kamion> seb128: thans
<Kamion> +k DAMN eyboard
<seb128> np
<seb128> :)
<pitti_live> carlos: I didn't put them online so far, will do ASAP
<pitti_live> carlos: 20 minutes?
<Mithrandir> Kamion: pushed.
<Mithrandir> (I thought I did so this morning?)
<carlos> pitti_live: we have 1 hour until celso is back, so it's ok
<Kamion> Mithrandir: hm, changelog still says UNRELEASED
<Kamion> oh, no, pulled again, I think my HTTP proxy is sucking again
<Mithrandir> Kamion: ahkay.
<Keybuk> that's weird
<Keybuk> apt-get update was successfull, but half the lists were missing and/or incomplete
<Keybuk> did I hit the archive at a bad time?
<Kamion> Mithrandir: then if you could merge/upload http://people.ubuntu.com/~cjwatson/bzr/casper/espresso-desktop again I'd be grateful
<seb128> Kamion: I've planned to follow the gnome-vfs2 binary split from Debian (breaks circular Depends on provide extra debug stuff), better to do that after flight4, right?
<Kamion> seb128: yeah, if you could wait - hopefully shouldn't be long
<seb128> there is no hurry at all, I'll wait for after flight4
<Kamion> Keybuk: the publisher just finished, so I guess it's possible
<Keybuk> Kamion: I didn't think the archive was supposed to *have* bad times
<Keybuk> Kinnison: launchpad publisher moves the new packages files into place by writing them elsewhere and rename()ing over the top, right?
<Keybuk> (and not something silly like just writing the file over the top a chunk at a time)
<Mithrandir> Kamion: just merge and upload?
<Kinnison> Keybuk: essentially yes
<doko> Kamion: please demote libstdc++6-dev and g++-3.4 to universe
<Keybuk> "essentially" ?
<Kinnison> Keybuk: we write an entire new dists/ tree which we replace over the top
<infinity> Which does allow a tiny window of "bad", but not much...
<Keybuk> how do you replace it over the top?
<Kamion> Keybuk: launchpad publisher does but archive.ubuntu.com is still a mirror
<Keybuk> Kamion: ah, true
<Kamion> Keybuk: mv dists dists.old; mv dists.new dists; rm -rf dists.old
<Keybuk> heh
<Kamion> so there's a brief race with no dists, but only buildds care
<elmo> the archive uses --delay-updates, it's essential the same thing
<Kamion> still a window when rsync is in the middle of updating though
<Kamion> Keybuk could have caught that
<mdz> seb128: copy/paste behaviour in gnome-terminal seems to have changed
* Kamion grins at the phrase "a little more atomic" in rsync(1)'s description of --delay-updates
<mdz> seb128: I now get different things with shift+insert vs. middle-click
<seb128> mdz: shit-insert bug?
<Keybuk> is that atomic as in "boom" ?
<mdz> seb128: oh, just a bug? good
<seb128> s/shit/shift
<seb128> yep
<ogra> lol
<Keybuk> Mithrandir: I'm ready for you now ...
<ogra> hmm, my DSL seems to be back ... :)
* ogra quickly starts to rsync
<Kamion> gar, I wish screensavers didn't kick in in vmware
<Kamion> it makes my host machine totally unusable for tens of seconds while vmware figures out how to stop the screensaver
<seb128> mdz: not clear if that's a bug: http://bugzilla.gnome.org/show_bug.cgi?id=123844
<Ubugtu> gnome2 bug 123844 in VteTerminal "Select after copy overwrites clipboard contents" [Enhancement,Reopened]  
<ogra> Kamion, hmm, i dont see a solution for that ... users might actually want screensavers in vmware
<Kamion> Mithrandir: yeah, if you could
<mdz> seb128: IT IS A BUG ;-)
<seb128> mdz: basically "Shift+Insert pastes CLIPBOARD" (coherent with GNOME) and "Ctrl+Shift+Insert paste PRIMARY"
<Kamion> ogra: unconvinced, but up to you I guess
<Kamion> if there's a way to make it non-GL screensavers only, that would help
<dholbach> seb128: Treenaks filed it in launchpad as well.
<seb128> dholbach: I know, that's the upstream bug you pointed from launchpad
<Kamion> I'm not entirely sure it's GL screensavers that make it slow as molasses but it seems like a fair guess
<mdz> seb128: whatever, so long as there is a checkbox for it so that it can act like xterm
<ogra> Kamion, hmm ... hard to do with gnome-screensaver alone ... thats why the hacks are in two different packages ...
<seb128> mdz: yeah, they are discussed a gconf key or an option for that
<mdz> ctrl+shift+insert is very hard to type
<Fitzsimmons> it is?
<Mithrandir> Kamion: done
<pitti_live> mdz: on the kinesis? :)
<Mithrandir> Keybuk: I'm on my way out the door, tomorrow instead?
<Keybuk> seb128: btw, is there any particular reason why we still don't have an "OK" button on the gdm theme?
<Keybuk> Mithrandir: sure
<mdz> pitti_live: yes
<seb128> Keybuk: artwork is jdub's is a good reason? :)
<mdz> I need the foot pedal
<Keybuk> seb128: not particularly ... jdub: can we put one on there please
<seb128> Keybuk: we said we would put one, dunno what jdub has planned to change for dapper and when
<Keybuk> (I've just had to explain for the dozenth time to a new user that they can just press the Enter key -- it seems that only power users ever think of that)
<Keybuk> it seems that Enter usually does something dangerous in Windows, like make the dialog box vanish
<mdz> mjg59: did something happen to make laptop-mode less scary?
<Keybuk> this user did try Tab, but that doesn't do anything
<seb128> Keybuk: tab is supposed to work for some time, weird
<seb128> and it does work for me
<Keybuk> they could have been lying ;)
<seb128> (just tried)
<seb128> gdm (2.8.0.0-0ubuntu1) breezy; urgency=low
<Keybuk> we do need a big clickable button there though
<seb128>     - <Tab> validate the username (Ubuntu: #9777).
<Keybuk> hmm, does it work on the password field too?
<seb128> yep
<mjg59> mdz: What I discussed in that email
<Keybuk> probably just the user lying then
<seb128> or using hoary?
<Keybuk> hmm, could be hoary actually
<Keybuk> I don't remember sending them breezy CDs
<Kamion> Mithrandir: thanks
<Keybuk> I'll have to ask next time
<pitti> Kamion: the keyboard selector in the installer gfxboot has no effect; known or do you want a bug report?
<Keybuk> I just noticed the button still wasn't there after installing quest as well
<Kamion> pitti: that's the kbd-chooser preseeding breakage that Mithrandir and I were discussing this morning
<Kamion> there's no bug report about it yet though AFAIK, feel free to file one so we remember
<pitti> ok, thanks
<mdz> mjg59: that email?  I was just reading dapper-changes
<mjg59> mdz: Ah - ubuntu-devel
<mjg59> mdz: Basically (since I've never been able to reproduce this), I'm working on a hunch
<tseng> Kamion: have a minute? I am pretty stuck on where to go from here with mono ppc
<mjg59> mdz: My /guess/ is that the issue is caused by the APM command being sent at around the same time as the BIOS reduces the spin speed on the CD drive
<mjg59> mdz: Which would then result in the IDE bus hanging
<tseng> Kamion: we've been highly unsuccessful in reproducing it on anything outside the canonical data center
<Kamion> tseng: did anyone analyse the traces I sent?
<tseng> Kamion: yes
<Kamion> I'm fairly sure it just needs a multi-processor machine ...
<tseng> Kamion: "it cant possibly crash there"
<Kamion> it STINKS of a threading race
<mjg59> mdz: So for now I've just delayed the sending of those commands
<tseng> slomo: feel free to chime in re: multiprocessor machine
<tseng> Kamion: there is a debian buildd with dual g4
<tseng> slomo_ rather.
<Kamion> IIRC BenC's G5 is dual, might be worth asking him when he reappears
<tseng> mm that is a good lead
<Kamion> I might be wrong there
<Kamion> yes, voltaire.debian.org is a dual G4
<slomo_> when will he be back?
<Kamion> reasonable US working hours I assume
<tseng> i am working in the us, reasonably :)
<Kamion> voltaire doesn't seem to have user chroots though
<slomo_> voltaire built mono fine
<Kamion> dunno then, /me <- not BenC's keeper ;)
<slomo_> http://buildd.debian.org/fetch.php?&pkg=mono&ver=1.1.13.1-1&arch=powerpc&stamp=1137306831&file=log&as=raw
<Kamion> I'm more than happy to carry out further debugging
<Kamion> or if there's a way to make mono only use one processor, perhaps that would be a workaround
<tseng> the problem is we dont need to waste all your time on it
<Kamion> further debugging> under instructions that is, I don't have time to go off on my own
<tseng> and the trace left no obvious lead
<Amaranth> isn't there a way to set processor affinity or whatever it's called in linux?
<Kamion> at this point I'd be happy if there were some big-hammer workaround
<slomo_> Kamion: there's no way to do it afaik... is there a utility to bind a process to one cpu?
<tseng> binary upload has always been a sufficient hammer
<tseng> its tons easier to find a box that does build mono than one that doesnt
<Kamion> that one's not happening ...
<Kamion> even less likely to happen with soyuz than it was with katie
<slomo_> if there's a way to bind a process to one cpu i guess we could hack the build system of mono to do it
<Kamion> sched_setaffinity(2)?
<Kamion> can't see a handy user command for it
<Kamion> would need testing on davis first though
<Diziet> seb128: Thanks for your effort.  I'm dreaming up a wiki page that will have these kind of questions answered; it'll be done in a bit.
<slomo_> Kaloz: thanks... hm, shouldn't be too hard to add a hack for this in mono for ppc... tseng can you take a look at it? should be only one position where this function needs to be called... in main() of the JIT probably
* tseng gets sources
<slomo_> probably mono/mini/main.c
<tseng> wait a second, do you remember if it dies on internal mono or the bootstrapped version
<tseng> ok, mini
<tseng> haha
<tseng> main (int argc, char* argv[] )
<tseng> { return mono_main (argc, argv);
<tseng> }
<slomo_> there is no internal JIT, only an internal mcs which is cli
<slomo_> yes... nice thing ;)
<tseng> easy enough
<slomo_> just add it before and give it Kamion to test on davis
<tseng> when he said  (2) did that mean the literal argument
<slomo_> but please... use dpatch's ability to apply patches only on one architecture or do it in rules via sed or something ;)
<slomo_> http://www.die.net/doc/linux/man/man2/sched_setaffinity.2.html
<Kamion> no that's standard notation for man page sections
<tseng> yeah that was the other choice
<Kamion> foo(2) => man page foo in section 2
<Kamion> i.e. system call
<slomo_> man $section $page iirc
<tseng> but
<Kamion> yes
<tseng> No manual entry for sched_setaffinity in section 2
<Kamion> install manpages-dev
<tseng> danke
<slomo_> i hope there's no forking in there...
<slomo_> but doesn't look like it from a fast look in mono_main()...
<Keybuk> ooh, nice gtk/X boog ... it thinks my "Pause" key is "Print" and my "Print" key is "Pause"
<tseng> mm it wants the pid
<slomo_> tseng: 0 for current process
<ogra> Keybuk, thats just wrongly printed on your keyboard :P
<tseng> handy
<slomo_> tseng: or get_pid()
<Kamion> getpid()
<Kamion> #include <sched.h> ... { unsigned long mask = 1; sched_setaffinity(0, sizeof(mask), &mask); }
<elmo> would hoary have allowed to login if you don't own ~/.ICEAuthority ?
<ogra> nope
<ogra> we had a ton of bugs about that ... k3b rewrites it as root on first start
<tseng> Kamion: ive rolled a patch here for safekeeping, do you need to me roll the source package
<ogra> (k3bsetup to be precise)
<tseng> Kamion: or can you just throw that in a chroot and test?
<tseng> probably just a ./configure; make will do
<elmo> is it possible mvo's upgrade tool does so too?
<ogra> hmm ... good question 
* ogra didnt try it yet
<Kamion> tseng: no, just mail me it
<tseng> Kamion: np
<ogra> elmo, but it saw a good amount of community testing already, i guess someone would have noted it
<elmo> ogra: I guess so
<slomo_> tseng: thanks... let's hope it works :)
<Keybuk> brb
<carlos> pitti: hi, do you have that package ready?
<pitti> carlos: sorry, emergency, later
<carlos> ok
<Keybuk> weird, I couldn't get ssh X forwarding to do the right thing
<Keybuk> oh well, vnc works :)
<seb128> Keybuk: udev.log on chinstrap for you
<seb128> Keybuk: 
<seb128> UEVENT[1140106469.632521]  add@/class/sound/controlC0
<seb128> ...
<seb128> UEVENT[1140106469.632531]  add@/class/sound/mixer
<seb128> so right, controlC0 is added before the mixer
<Keybuk> I wonder whether that's important
<ogra> Keybuk, crimsun could tell 
<seb128> $ cat /etc/udev/rules.d/85-alsa.rules
<seb128> KERNEL=="controlC[0-7] ", ACTION=="add", RUN+="ls /dev/snd >> /var/run/snd.log"
<seb128> KERNEL=="controlC[0-7] ", ACTION=="add", RUN+="/etc/init.d/alsa-utils start %n"
<seb128> Keybuk: and I've no /var/run/snd.log
<Keybuk> oh, you won't have ... sh -c ' ... ' around it ;)
<Keybuk> sorry, should have made that a bit more clear
<seb128> lemme try again :)
<Kamion> Mithrandir: I don't see any casper upload from you?
<tseng> Kamion: am i right that davis has 64 bit kernel 32 bit user?
<Kamion> tseng: yes
<tseng> Kamion: and at one point it was 32/32?
<tseng> Kamion: (when we could actually build mono)
<Kamion> tseng: er, might've been, elmo would know
<tseng> also, how much change of someone getting a chroot
<seb128> bah, no change
<seb128> imho it's not runned
<Kamion> I think it's impossible for non-employees I'm afraid
<Kamion> or at least deeply contrary to the datacentre security policy
<Keybuk> UDEV  [1140106470.218685]  add@/class/sound/controlC0
<Keybuk> so udev is processing it
<seb128> but it seems it doesn't run 85-alsa
<Keybuk> wonder why I just put [0-7]  in there
<Keybuk> seb128: add a different rule to the top?  maybe just RUN+="/bin/touch /var/run/YES_I_RAN"
<seb128> KERNEL=="controlC[0-7] ", ACTION=="add", RUN+="/bin/touch /var/run/YES_I_RAN" ?
<seb128> or just the RUN part?
<sladen> I make some space, then haha, it tells me it's now 95% full.  stupid program
<Keybuk> both, with different filenames
<seb128> k, brb
<slomo_> Kamion: can you also try with only this patch applied: http://primates.ximian.com/~lupus/ppc-atomic-barrier.diff  ?
<Kamion> slomo_: looks promising, will do once this build finishes
<slomo_> Kamion: so it works with that setaffinity patch? cool... at least a known workaround now...
<Kamion> slomo_: don't know yet, hasn't finished
<Kamion> and in any case this tree still has my debugging hacks in it, whoops; might build anyway
<tseng> Kamion: i mailed you a second patch from upstream
<slomo_> tseng: i've already given him the url some seconds ago ;)
<tseng> haha "oh"
<Kamion> whaddaya know, setaffinity worked
<Kamion> trying atomic-barrier in a clean tree now
<Keybuk> atomic barrier? affinity?
* Keybuk gets scared what Kamion's secret project is
<Kamion> mono, see above
* tseng passes Keybuk the mono pipe
<seb128> Keybuk: 
<seb128> $ cat /etc/udev/rules.d/85-alsa.rules
<seb128> RUN+="/bin/touch /var/run/YES_I_RAN_simple"
<seb128> KERNEL=="controlC[0-7] ", ACTION=="add", RUN+="/bin/touch /var/run/YES_I_RAN"
<seb128> KERNEL=="controlC[0-7] ", ACTION=="add", RUN+="sh -c 'ls /dev/snd >> /var/run/snd.log'"
<seb128> KERNEL=="controlC[0-7] ", ACTION=="add", RUN+="/etc/init.d/alsa-utils start %n"
<seb128> $ ls /var/run/snd* /var/run/YES_I_RAN*
<seb128> ls: /var/run/snd*: Aucun fichier ou rpertoire de ce type
<seb128> /var/run/YES_I_RAN  /var/run/YES_I_RAN_simple
<ogra> tseng, you and your strange drugs ....
* ogra shakes head
<Keybuk> seb128: oh, /bin/sh would probably help that ;)
<seb128> $ cat /var/run/snd.log
<seb128> controlC0
<seb128> pcmC0D0c
<seb128> pcmC0D0p
<seb128> pcmC0D1c
<seb128> pcmC0D2p
<seb128> timer
<seb128> on an udev restart
<Kamion> Mithrandir: didn't see a casper upload from you so I just did one, hope that's not too inconvenient; committed and pushed to my espresso-desktop branch
<Kamion> Mithrandir: also there was a bin/casper-to-usb script in your 1.31 tarball that apparently never got added to bzr
<Keybuk> seb128: ok, well so far I don't see any reason your mixer settings aren't being restored
<Keybuk> OH WAIT!
<Keybuk> brain just kicked in
<Kamion> (so it's not in my upload)
<Keybuk> guess where alsa stores the mixer settings
<seb128> /var
<Keybuk> bingo
<seb128> grumpf
<seb128> you should not have a separate /var nowadays :p
<seb128> Keybuk: right, it's /var/lib/alsa/asound.state ... :)
<Keybuk> yeah, a bunch of stuff uses /var as if it were /etc
<Keybuk> alsa happens to be one of them
<seb128> so what would be the right way to fix that? 
<seb128> move the file to etc?
<Keybuk> move the file onto the root filesystem
<Keybuk> oh look, it's a debian patch to move it *to* /var
<seb128> jordi: !!!
<Mithrandir> Kamion: casper-to-usb is unfinished, so that's ok.  I should add it to bzr, though.
<seb128>         patches/10_move_asound_state_to_var.dpatch: Move the default
<seb128>         asound.state from /etc/ to /var/lib/alsa/ (Closes: #106244)
<seb128> hum
<Keybuk> because having hardware-related stuff on your root filesystem is just asking for it to work
<Keybuk> or something
<Kamion> slomo_,tseng: still breaks with ppc-atomic-barrier
<Keybuk> I guess I agree that it probably doesn't belong in /etc either though
<tseng> Kamion: ack
<slomo_> Kamion: ok, thanks for testing
<slomo_> Kamion: we'll send it up with setaffinity then for now
<Keybuk> we need a variable state directory on the root filesystem
<Kamion> trying the sched_setaffinity thing again just to make sure my old tree wasn't busted
<Kamion> you should put #ifdef __powerpc__ / #endif around the setaffinity changes obviously
<slomo_> Kamion: ok... if it was busted it would be really interesting to know what you changed there ;)
<Kamion> bit late :(
<seb128> right, /etc is not the right place for that neither
<seb128> and alsa will probably not the only one in that case ...
<Keybuk> seb128: I actually can't think of anything else off the top of my head that needs a hardware configuration file to hang around after a reboot
<Keybuk> it's kind of "saved settings"
<Keybuk> so it's a bit like /etc as it's card configuration, but a bit like /var because it's machine-managed
<pitti> seb128: !
<seb128> pitti: !!
<pitti> seb128: quick, quick, which package has the 'Desktop' translation?
<pitti> seb128: i. e. is that a .desktop file or a .mo file?
<seb128> Keybuk: better to use /etc so, that would fix my bug :)
<seb128> pitti: what "Desktop"? The places menu one? gnome-panel (.mo)
<Keybuk> seb128: /etc/var/alsa ? :p
<seb128> lol
<pitti> seb128: yes, places
<pitti> seb128: changing gnome-panel-2.0.mo doesn't work
<Keybuk> at least that makes it obvious
<seb128> pitti: panel-menu-items.c:                             Q_("Desktop Folder|Desktop"),
<pitti> seb128: 'k, thank you a million
<seb128> np
<Kamion> slomo_: BTW I don't think all powerpc systems have lwsync so that would break pre-power4, surely?
<Kamion> you need sync on older chips
<slomo_> Kamion: no idea... i'll ask the mono guys
<Kamion> slomo_: and wouldn't it need to apply to the other Interlocked* functions?
<Keybuk> seb128: don't suppose you know the bug#?
<seb128> Keybuk: https://launchpad.net/malone/bugs/31564
<Ubugtu> malone bug 31564 in alsa-utils "sound muted on started" [Normal,Unconfirmed]  
<Kamion> also lwsync isn't really a lock, not in the same way LOCK is on x86
<Kamion> it just makes sure all memory operations before lwsync have been completed before proceeding
<slomo_> Kamion: <lupus> slomo: yes, but that one is used to implement the lock() operator
<slomo_> Kamion: <lupus> slomo: could you tell him to make it use sync instead of lwsync and retry?
* slomo_ plays proxy today
<slomo_> Kamion: <lupus> slomo: that is the intended behaviour
<slomo_> Kamion: <lupus> the lock is implemented with the compareexchange, not with the lwsync, of course
<jdub> Keybuk: sorry, missed the context of your "put one on there" request?
* Kinnison takes his workrave break which he was denied earlier
<Keybuk> jdub: an OK button on the gdm theme for people to click after typing in their username or password
<Kamion> ok, I'll try sync instead; but I'll have to go in 20 minutes so you might not get the answer for a while
<jdub> Keybuk: ah, yeah - i also want to put username/password on the same screen
<HiddenWolf> Keybuk: hm, did people really not figure out the enter?
<ogra> jdub, two entry boxes ? 
<Keybuk> HiddenWolf: yup, apparently pressing Enter in Windows almost always does the wrong thing, so people don't try it
<HiddenWolf> Keybuk: shame, I liked the cleanness of the theme.
<Keybuk> seb128: can you try the alsa-utils package on http://people.ubuntu.com/~scott/ and see if that fixes it :)
<jdub> ogra: yeah
<ogra> eeek
<ogra> jdub, thats evil and ugly ... why do you want to do that ? 
<Keybuk> HiddenWolf: a theme with just a slowly pulsating "username?" in the middle, with no text box, and movie-os style animated backdrop would be even cleaner
<ogra> (i agree that a ok button might make sense)
<Keybuk> but we'd have 90% of users sitting there wondering *where* they type their username
<jdub> ogra: much clearer, based on user testing
<ogra> hrm...
<jdub> ogra: easier to fix mistakes, etc.
<ogra> Keybuk, in the field where "username" is written on ? 
<Keybuk> ogra: read the line above too
<ogra> i find it very intuitive to have one field that changes the label ... 
<Keybuk> ogra: it seems that a lot of our users don't
<Keybuk> find another example of that elsewhere in the interface
<ogra> its emptied ... 
<Keybuk> dialog boxes have eight fields, not one that changes as you type into it
<ogra> the label should be bigger and clearer
* Kinnison 's mother fell foul of the gdm screen
<Kinnison> she typed her username in and then asked me "so where do I type my password in, and what do I click on to continue?"
<Keybuk> ogra: first rule of UI design ... users don't read ... no matter how big the text
<ogra> hrm 
<Keybuk> how many times have you signed the date box, or the "print your name here" box on forms, etc.? :p
<ogra> i dont like the idea nontheless ...
* Kinnison thinks two fields and a button will make life easier for our users
<Keybuk> the Royal Mail "Special Delivery" form gets me every damned time
<Keybuk> especially as they like delivering at about 5am
<Keybuk> I always sign in the wrong box
<Kinnison> Keybuk: I almost signed in the date field on the most recent paperwork for selling my house
<Kinnison> but that was a really poor form
<Keybuk> ogra: clever/shiny/clean is secondary to usable :)
<Keybuk> . o O { oh, so that's why sudo is asking me for my passphrase too much }
<Kinnison> okay so pbuilder is confusing me
<Kinnison> how do I make it build my source tree?
<Keybuk> Kinnison: buggered if I know, I've never used it
* Kinnison is half tempted to have a launchpad install on his laptop for test-building
<Keybuk> hmm, I want to install ia32-libs, don't I?
<Keybuk> and probably linux32
<Mithrandir> Keybuk: you do, probably.
<Keybuk> Mithrandir: what's the collection of useful amd64 gadgetry that I should install on this?
<Keybuk> I'd quite like to have an i386 chroot, etc.
<Mithrandir> Keybuk: i386 chroot?  debootstrap's generally useful for creating such.
<Kamion> slomo_,tseng: right, sched_setaffinity definitely works, trying lupus' suggestion now (but as I say, going in five minutes or so)
<Kamion> debootstrap --arch i386
<Keybuk> right, I know how to *make* it :)  but not how to run shit in it <g>
<Kamion> linux32 chroot /blah
<slomo_> Kamion: ok, thanks... i'll upload with that patch for now... we can replace it with something better in the future :)
<Kamion> even without linux32 it'll work
<Mithrandir> Keybuk: bind-mount /tmp and /home and you'll be able to run X programs in there too.
<Kamion> slomo_: right, as long as it gets #ifdefed to powerpc
<slomo_> Kamion: it's #ifdef __powerpc__ now
<Kamion> good
<Keybuk> what does linux32 do, then?
<Kamion> I'll let you know what happens with the sync business
<Kamion> Keybuk: sets kernel personality
<Mithrandir> Keybuk: makes uname return stuff as if you were a 32 bit platform.
<Kamion> so uname says i686, e.g.
<pitti> yay, network is back
<Keybuk> ok, I guess in theory just running an ia32 binary works, but it'd still think it was running on "amd64" ?
<pitti> Kamion: FYI, today's amd64 install/live are good
<Mithrandir> Keybuk: yes.
<Kamion> pitti: great, thanks
<Keybuk> ok
<Kamion> slomo_: s/lwsync/sync/ still breaks
* Kamion runs
<Kamion> er s/lwsync/sync/g that is
<Keybuk> Mithrandir: so ia32-libs are the common deps of 32-bit apps?
<slomo_> Kamion: ok
<pitti> carlos: http://people.ubuntu.com/~pitti/packages/
<Mithrandir> Keybuk: it's a subset which covers at least a base set, yes.  It's not a full 32 bit environment
<carlos> pitti: thanks
<pitti> carlos: sorry for the delay, a super-urgent emergency task popped up in between
<carlos> pitti: don't worry
<Keybuk> right, so other than linux32 or ia32-libs, anything else I might want/need/find useful?
<pitti> carlos: that's the new version I'll upload as soon as you give me the ok
<carlos> pitti: ok
<pitti> carlos: do you need anything else?
<carlos> nothing, thanks
<pitti> carlos: btw, that's the version I created the pmount test build with
<carlos> ok
<Kinnison> hmm, no seb
<Keybuk> no, he ran off ~15 mins ago
<Kinnison> do you happen to know if we honour /etc/xdg/autostart/*.desktop ?
<Keybuk> no idea
<ogra> theer he is :)
<Kinnison> seb128: do you happen to know if we honour /etc/xdg/autostart/*.desktop ?
<seb128> Keybuk: slightly better
<Keybuk> seb128: did that work?
<Keybuk> "slightly" ?
<seb128> Keybuk: it doesn't find amixer because /usr is not mounted *g*
<Keybuk> seb128: I'm going to deck you
<seb128> lol
<Keybuk> what's amixer?
<seb128> Kinnison: no, the spec seems stupid to me, I've changed to /usr/share/autostart and I'm in discussion with upstream
<seb128> Keybuk: something that /etc/init.d/alsa-utils starts complain if you don't have it
<Kinnison> seb128: okay, I'll try and persuade this to install the .desktop there
<seb128> I've init=/bin/sh and tried it
<Keybuk> seb128: ok ... it doesn't seem to actually use it for this job, so we can fix that :p
<Keybuk> I assume if you comment that out, it's fine?
<seb128> Keybuk: right, alsactl is /sbin
<seb128> Keybuk: I've not tried in fact, will do at next boot :)
<seb128> but it should
<Keybuk> hang on
<Keybuk> yeah, it looks like amixer is needed for this
<seb128> Kinnison: http://bugzilla.gnome.org/show_bug.cgi?id=330397
<Ubugtu> gnome2 bug 330397 in gnome-session "autostart uses config_dir instead of data_dir" [Normal,New]  
<seb128> Keybuk: moving it to /bin ? :p
<dan_t> hello. i have a problem on dapper. nautilus does not refresh properly the x root window. the desktop background is corrupted
<Keybuk> seb128: no, /sbin
<Keybuk> I'm glad we have *someone* who's put everything possible onto seperate filesystems, anyway
<seb128> :)
<Keybuk> you clearly like having to do "df | less" :p
<seb128> I like to get a pile of "low disk space" bubble on GNOME login :p
<jdub> crash test sebby :-)
<hunger> Keybuk: is having 22 local partitions mounted not the norm here?
<Keybuk> hunger: only if they're tmpfs and bind mounts
<hunger> Keybuk: 5 of them are set up for you by ubuntu anyway;-)
<Keybuk> 5?  4!
<seb128> $ mount | wc -l
<seb128> 16
<Keybuk> unless you're counting the root filesystem?
<seb128> *g*
<hunger> Keybuk: Oh, right... where did the tmpfs for the restricted modules go?
<Keybuk> actually, I guess if you're being accurate, Ubuntu mounts 8
<Keybuk> hunger: *g* hidden
<Keybuk> actually it just needs adding to mtab
<Keybuk> (it gets mounted before there's a writable root filesystem)
<Keybuk> hmm
<hunger> Keybuk: then it is 8 mounted and set up by ubuntu.
<hunger> So it is only 14 for my normal FS:-)
<dan_t> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-nv/+bug/6120 i'm experimentin this bug (but with a radeon video card on an ibook) . can i help to fix it?
<Ubugtu> malone bug 6120 in xserver-xorg-driver-nv "[Dapper]  Screen corruption on Gnome desktop with nv driver" [Normal,Needs info]  
<Keybuk> /proc, /sys, /dev, /dev/.bootchart, /var/run, /var/lock, /lib/modules/*/volatile, /dev/.static/dev, /dev/pts, /dev/shm, /proc/sys/fs/binfmt_misc, /proc/bus/usb
<Keybuk> that's 12 ...
<hunger> Keybuk: That is my laptop... no idea how many I have on my servers:-)
<slomo_> ubuntu-artwork is currently broken with no grub installed... e.g. on ppc ;)
<slomo_> update-alternatives: unable to make /boot/grub/default-splash.xpm.gz.dpkg-tmp a symlink to /etc/alternatives/grub-artwork: Datei oder Verzeichnis nicht gefunden
<dan_t> slomo: same for me :)
<seb128> slomo_: ping mvo 
<slomo_> mvo: ping
<mvo> hello
<mvo> *grumpf*
<seb128> hey mvo :)
<mvo> thanks
<slomo_> hi mvo ;)
<mvo> slomo_: got your message
<Kinnison> ogra: ping
* jdub loves hearing the ubuntu drumbeats or login sound at conferences :)
<ogra> Kinnison, pong
<Kinnison> ogra: so http://people.ubuntu.com/~dsilvers/gvm-nuv/
<Kinnison> ogra: Can you please have a play with that, I need to go out, mail me any issues
<ogra> Kinnison, ok, i can do it only later, in a meeting in #ltsp currently ...
<Kinnison> ogra: of course, enjoy
<ogra> :)
<ogra> Kinnison, err, 404
<Kinnison> http://people.ubuntu.com/~dsilvers/gpm-nuv/
<Kinnison> sorry
<Kinnison> *power* not *volume*
* Kinnison roars
<Kinnison> (quietly)
* Kinnison heads off
<elmo> umm, what's X's support for FireGL ATI cards like?
<Kinnison> Diziet: see you in about 2h I guess
<elmo> with free drivers
<Keybuk> General Purpose Mouse?
<Kinnison> Keybuk: gnome-power-manager
<mjg59> elmo: depends on which one, but ought to be "ok"
<mjg59> As long as they're not r500 based
<elmo> V3100 128Mb PCIe
* Kinnison really does go this time
<mjg59> elmo: That's an rv370
<mjg59> elmo: Basically a slightly nicer X300. Should work.
<elmo> mjg59: excellent, thanks
<Burgwork> Keybuk, the issue with NM and atheros is dropping off due to scanning?
<mjg59> Burgwork: Yes
<siretart> how do I check if my dbus is still working correctly?
<Burgwork> mjg59, I wonder if it is just specific chipsets of Atheros, because I have not been noticing that with my atheros
<siretart> g-p-m doesn't change display brightness correctly after suspend, and I suspect dbus having problems with supend to ram on my machine. how to check?
<Keybuk> Burgwork: run "sudo iwevent"
<Keybuk> and leave it for a few minutes, paste its output
<Burgwork> Keybuk, I will email you tonight (don't have my laptop at work with me)
<Keybuk> I don't have e-mail
<Burgwork> Keybuk, then I will PM you
<hunger> Is it possible that the partition mounted on /boot is not listed on "mount"?
<janimo> X people, shouldn't  /usr/bin/X be setsuid ? In a default install I need to chmod +s it so I can startx without gdm
<Keybuk> seb128: new alsa-utils to test if you want
<janimo> otherwise it says it cannot write /var/Xorg.logs
<seb128> Keybuk: sure
<Keybuk> seb128: source at same location with same filenames :)
<Keybuk> you can probably just grab the diff
<mjg59> siretart: "dbus having problems with suspend"?
<mjg59> It's more likely that g-p-m has just got confused
<janimo> elmo, can you please sync/override exo and thunar. They got UFV exception permission. thank you
<janimo> ogra, are you ok with calling the alternatives name for the derivative /etc/alternatives/gdm-config-file ?
<siretart> mjg59: well, I'm seeing that it doesn't change screen brightness after suspend anymore
<ogra> janimo, sure ... pleaswe talk to seb128 about the target of the link ... he's thinking about moving all config to /usr/share
<janimo> seb128, ping ^
<janimo> oh, he's gone
<mjg59> siretart: Doesn't change screen brightness in what way? The slider doesn't work, or it doesn't do it automatically?
<janimo> ogra, you mean movind what's in /etc/gdm ->/usr/share ?
<mvo> slomo_: ubuntu-artwork should be fixed
<ogra> janimo, yes, he's still thinking about it
<slomo_> mvo: thanks :)
<seb128> Keybuk: still muted, I've to go now but I'll have a look after diner and let you now later or tomorrow
<Chipzz> an alternative for gdm.conf ? get off the bong allready :P
<mvo> slomo_: thanks for reporting!
<janimo> Chipzz, an alternative to a conf file which has priority over gdm.conf actually
<slomo_> mvo: np
<janimo> invoking with gdm --config alternative-gdm-conf
<janimo> so derivative distros can override the default gdm greeter theme
<Chipzz> then they should alter the default gdm.conf
<Chipzz> isnt this taking it a little bit to far?
<janimo> and what to do with the default one?
<Chipzz> for crying out loud...
<Chipzz> it gets to be the default one... it's called "branding"
<janimo> alternate distros is a bit innacuarte: different packages to suppply diferent confs
<siretart> mjg59: before suspend, the slider changed the brightness instantly. after suspend, the slider doesnt change anything
<mdz> seb128: what happened to the swfdec gstreamer plugin when we moved to 0.10?
<janimo> Chipzz, this is the cleanest way we found so far
<Chipzz> just think about it... this is total and utter abuse of alternatives
<siretart> I just upgraded g-p-m and g-s-s, lets try again
<janimo> Chipzz, propose a cleaner way
<mjg59> siretart: What hardware?
<Chipzz> janimo: why would you want to do that anyway? (provide an alternate gdm.conf)
<mxpxpod> what would make syslogd spawn 9 new processes of itself after resuming from sleep?
<dholbach> mdz: he went for a bit of swimming, i'll try to find out
<janimo> Chipzz, read again what I said earlier :)
<mdz> dholbach: thanks
<siretart> mjg59: gnarf. after upgrade, I cannot reproduce the problem anymore.. this is a thinkpad r40
<Chipzz> janimo: not sure... about another approach
<Chipzz> but using the an alternative feels so wrong and dirty
<Chipzz> janimo: also, this sets a precedent that we may not want to set
<Chipzz> of you start doing this, who's to say not every single thing that can be themed will be using this system?
<Chipzz> like provide a seperate theme package for every theme, and use an alternative for the default theme?
<Chipzz> I guess what feels most wrong about it is that alternatives have been used mostly for user-visible things (things a user will execute/access, like binaries or man pages)
<Chipzz> janimo: btw, another solution just popped to mind... use debconf ?
<janimo> Chipzz, please let it be, it';s fine like it is now\
<Mithrandir> pitti: what kind of gfx card do you have in your amd64?
<dholbach> mdz: I just had a chat with slomo_. It seems that swfdec is part of gst0.10-bad, which is not packaged yet, because "bumpy" would still be an euphemism for the state of things there. :-/
<mdz> dholbach: that's odd
<mdz> dholbach: ds told me that it worked fine with gst0.10
<dholbach> mdz: http://cvs.freedesktop.org/gstreamer/gst-plugins-bad/ext/swfdec/ is the CVS location. I can't speak for the build-ability - I didn't toy around with gstreamer yet.
<dholbach> slomo_: when did you last try to build it?
<slomo_> 0.10.0 release... that's the newest tarball of -bad... but i didn't try to swfdec plugin (but iirc it built fine) only faad, faac, mpc and wavpack... and they were unusuable at that point
<dholbach> I read the bad-README in CVS, saying you shouldn't expect much of the whole bunch. :/
<slomo_> so maybe we could package a cvs snapshot of the swfdec plugin... or hope that it moves to good or ugly soon
<Keybuk> that was neat
<Keybuk> wireless dropped because the smoke from the kitchen occluded the signal
<ds> yo
<Keybuk> 802.11 clearly has practical fire alarm potential
<mdz> dholbach: still here?
<dholbach> mdyes
<dholbach> mdz: yes
<mdz> dholbach: ds says that swfdec for 0.10 should be fine
<dholbach> ds: we were just talking about swfdec in gstreamer 0.10
<ds> right now, swfdec (the package) has an internal swfdec element
<ds> which is nearly identical to the one in -bad
<ds> it can conceivably be moved to -good, but nobody has worked on verifying it yet
<slomo_> ds: can you try to push it to -good?
<ds> yes
<dholbach> woah, that'd be great
<dholbach> slomo_: i think we should get it from cvs (as soon as it's in good) and get it tested
<dholbach> slomo_: of course talk to seb before ;)
<slomo_> dholbach: sure... np :)
<dholbach> thank you, ds - i just heard about the general state of -bad and packaging attempts and lost a bit of faith :)
<ds> well, whomever decided that not packaging -bad was a good idea is dumb :)
* HiddenWolf puts on his helmet
<HiddenWolf> ds: I would duck if I where you. ;)
<slomo_> ds: well, with 0.10.0 the faad, faac, musepack and wavpack plugins were not really usuable for me thus i decided against packaging... if the overall state of the plugins has changed we could obviously package it :)
<HiddenWolf> -h
<mdz> jdahlin: ds mentioned that the problem might be related to xvimagesink
<jdahlin> mdz: You could try using my script and change it to ximagesink
<mdz> jdahlin: that works a lot better
<mdz> jdahlin: it still only uses half the window
<mdz> but no more corruption
<jdahlin> ds: I thought playbin added colorspace elements
<mdz> what would the syntax be to force ximagesink with gst-launch?
<jdahlin> mdz: filesrc location=... ! swfdec ! ximagesink
<jdahlin> you could also try ! ffmpegcolorspace ! xvimagesink
<Mitario> BenC, hi, any date/time for the new kernel upload?
<mdz> omg
<mdz> jdahlin: that works perfectly
<mdz> except no sound
<jdahlin> that's a bit tricker, I can't remember the exact syntax to do that
<jdahlin> but since sound worked when you used playbin it should work fine
<mdz> so apparently, ximagesink works much better for me than xv, and gst-launch better than flashplayer.py
<mdz> kiko: we have made some progress here
<kiko> I am overjoyed to hear that
<BenC> Mitario: any day now
<Mitario> BenC, cool, thanks :)
<kiko> mdz, what appear(s) to be the issue(s)?
<mdz> kiko: <mdz> so apparently, ximagesink works much better for me than xv, and gst-launch better than flashplayer.py
* ds wanders off for a few minutes
<mdz> kiko: the video corruption was fixed by using ximagesink, and the window sizing by using gst-launch
<mdz> ds: thanks for your help
<kiko> aha
<mdz> so I can finally see swfdec working
<kiko> what is ximagesink?
<jdahlin> kiko: it's the element responsible for rendering the content on your display
<kiko> and xv?
<mdz> gst-launch-0.8 filesrc location=/tmp/userfriendly.swf \! swfdec name=demuxer \! ximagesink demuxer. \! esdsink
<jdahlin> there's an alternative called xvimagesink, which is faster on compatible hardware
<mdz> that gives me a very functional player wiith sound
<kiko> ERROR: pipeline doesn't want to play.
<mdz> it is mystic runes I extrapolated from examples
<mdz> in the man page
<jdahlin> mdz: try gst-launch-0.8 filesrc location=userfriendly.swf swfdec name=swfdec ! { queue ! ffmpegcolorspace ! ximagesink }  { swfdec. ! queue ! alsasink }
<kiko> ERROR: from element /pipeline0/thread1/alsasink0: Could not get/set settings from/on resource.
<mdz> could gst-launch possibly use MORE SHELL METACHARACTERS?
<jdahlin> gst-launch-0.8 filesrc location=userfriendly.swf swfdec name=swfdec ! { queue ! ffmpegcolorspace ! ximagesink }  { swfdec. ! queue ! alsasink device=hw:0 }
<jdahlin> it's for developers :)
<tseng> Kamion: great, at least we have a work around.
<mdz> jdahlin: ERROR: pipeline doesn't want to play.
<tseng> Kamion: thanks for testing
<jdahlin> kiko: try that one, it works around stupidness in alsasink
<mdz> jdahlin: developers don't use the shell?
<kiko> ERROR: from element /pipeline0/swfdec: Internal GStreamer error: pad problem.  File a bug.
<kiko> Additional debug info:
<kiko> gstpad.c(3377): gst_pad_pull: /pipeline0/swfdec:
<kiko> pull on pad swfdec:sink but it was unlinked
<kiko> Execution ended after 1 iterations (sum 1220000 ns, average 1220000 ns, min 1220000 ns, max 1220000 ns).
<mdz> (gst-launch-0.8:16011): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `SwfdecObject'
<mdz> (gst-launch-0.8:16011): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject'
<mdz> (gst-launch-0.8:16011): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed
<jdahlin> mdz: they use a sane shell
* jdahlin runs
<SAAD3000> How come i can connect to the internet thru xp/suse and not thru ubuntu and i configured ubuntu exactly like suse & xp, and it tells me about fixing my proxy?
<SAAD3000> i think you guys are the one that can help.
<mdz> jdahlin: bash is for wimps
<dholbach> SAAD3000: that's more of a #ubuntu question
<dholbach> SAAD3000: or http://launchpad.net/support
<SAAD3000> dholbach trust me no one knows
<SAAD3000> its weird
<kent> SAAD3000: file a bugreport.
<SAAD3000> kent what bug? there was no bugs
<mdz> kent: not unless he's isolated the problem
<mdz> the bug tracking system is not for support; we do have a support tracking system
<kiko> jdahlin...
<SAAD3000> i really like this distro
<kent> mdz: oh, didn't know about that. :)
<SAAD3000> but why its doing this does i have to update the kernel to -10?
* ds back
<mdz> ds: the swfdec piece of this is looking good
<kiko> the alsasink part of it is a disaster :)
<mdz> it seems we just need to figure out how to drive gstreamer and upward appropriately
<mdz> kiko: yes
<ds> flashplayer.py appears to be broken
<kiko> ds, of course it is, check the author!
<mdz> kiko: with 0.10 we could use autoaudiosink I think
<ds> er, maybe it's a swfdec element problem
<jdahlin> ds: I think it's playbin that's broken
<pitti> Mithrandir: re
<jdahlin> since using playbin from gst-launch didn't work
<pitti> Mithrandir: nVidia GeForce FX 5200 (nv34 chipset)
<ds> ennyweys, the pipeline used by swfdec-mozilla-player works
<ds> jdahlin: indeed
<Mithrandir> pitti: thanks.
<ds> hrm, swfdec-mozilla-player uses playbin
<ds> and it seems to be failing now
<xerox_> Hi.
<kiko> ds, playbin hangs for me..
<xerox_> I hope this is the right place to ask, finally... anybody knows about libsvg-cairo?  I can't find it anywhere!  I'm looking forward to find it packaged for ubuntu or package it somehow.
<dholbach> xerox_: #ubuntu-motu might be a better place, if you want to package it.
<ds> kiko: swfdec-mozilla-player in the swfdec package is generally the most reliable player, so that should be the first place to check for bugs
<xerox_> dholbach: I was just redirected here to ask if somebody was knowing about it, or even working on the library.
<LaserJock> dholbach: lol, I sent him here because I thought one of the X devs would know
<xerox_> :-)
<kiko> ds, well:
<kiko> kiko@beetle:~$ swfdec-mozilla-player userfriendly.swf 
<kiko> Segmentation fault
<kiko> that's breezy however
<dholbach> LaserJock: rsvg is #ubuntu-desktop rather - i don't think anybody is working on it, that's why i said #-motu :)
<mdz> kiko: in dapper, it doesn't segfault, but it doesn't work euither
<mdz> either
<LaserJock> dholbach: ah, thanks. I just had no idea.
<mdz> (swfdec-mozilla-player:4598): Gtk-WARNING **: Attempting to add a widget with type GtkAlignment to a GtkWindow, but as a GtkBin subclass a GtkWindow can only contain one widget at a time; it already contains a widget of type GtkAlignment
<mdz> and a gstreamer pipeline error in the window
<xerox_> You probably know about this <http://battlehorse.homelinux.net/w/Wiki.jsp?page=Xgl> -- it *has* a libsvg-cairo package, so I wonder what is exactly going on about it.  Also, it has no -dev one, unfortunately.
<mdz> ds: failed to set pipeline to PLAYING
<xerox_> Thanks for the informations, I'll try asking on #ubuntu-desktop later.  G'day.
<_blaat> hi there
<dholbach> xerox_: no -dev is bad
<_blaat> http://rafb.net/paste/results/OM403091.html
<_blaat> has anybody seen problems similar to that before?
<_blaat> this is fresh after a ubuntu server install, I was able to use networking, and then I cant remember what other actions I did
<dholbach> xerox_: sounds like a good idea to package it properly
<_blaat> but next time I ran dhclient I get the above
<kiko> hmmm
<kiko> I installed swf-player but firefox doesn't pick it up
<dholbach> xerox_: although there's only time until Feb 23rd
<Keybuk> _blaat: weird, pitti ?
<_blaat> keybuk: I dont understand, what's pitti?
<HiddenWolf> _blaat: pitti is a person
<HiddenWolf> _blaat: one of the developers
<_blaat> oh
<Keybuk> specifically the person who took dhclient's root privileges away :p
<_blaat> ah yep I see
* pitti wavees to _blaat 
<_blaat> I doubt it'd be involved with taking root privelages away
<_blaat> unless it drops privs/uses another user to acquire the network address
<pitti> yes, it usually does
<pitti> however, I newer saw that
<_blaat> oh, alright :)
<_blaat> yeh, this was working fine up until a few days back, then I have nfi what else I did but dhclient just keeps giving the below
<pitti> _blaat: ls -l /lib/dhcp3-client/call-dhclient-script
<_blaat> I think I messed around with iwconfig stuff for a lil bit, that's about all
<ogra> pitti, i get that if i uncleanly wiped a chroot that had /proc mounted ...
<pitti> _blaat: did you set a manual script in dhclient.conf?
<_blaat> ok, I can do all debugging stuff, but I have booted into windows since I cant get network addys etc. under nix
<ogra> then the main system has permission denied errors
<_blaat> so If you give me a list of things to try I'll give u an update in a sec
<ogra> Keybuk saw it in london
<_blaat> nope, no manual script in dhclient.conf
<pitti> _blaat: ok, so I need the output of that command, and your /etc/dhcp3/dhclient.conf file
<_blaat> everything is straight after a default ubuntu server install
<pitti> hm, ok
<_blaat> sure thing
<_blaat> mind if  i reboot and get that for u now?
<pitti> _blaat: moment, please, before you logout
<_blaat> ok
<Keybuk> ogra: on mdz's laptop
<ogra> Keybuk, nope on mine ...
<ogra> i came to you with it ... and you told me you wouldnt know what that is ...
<ogra> i found then that it was caused by a broken ltsp client chroot ... that influenced the main system via either /var/run /var/something or /proc
<pitti> _blaat: please do 'sudo strace -o dhclient.trace -f /sbin/dhclient eth0' in addition and send me dhclient.trace, too
<_blaat> ok no probs
<ogra> after i unmounted these three, and rebooted the error was gone
<ogra> (unmounted in the chroot)
<pitti> _blaat: thanks
<Keybuk> oh was it?
<ogra> yup
<janimo> hmm I get connection refused when trying dput, anything known?
<dholbach> janimo: yes, it's known and worked on
<janimo> dholbach, ok thanks
<janimo> same reason why LP is down?
<jpatrick> upgrade?
<kiko> nope
<kiko> DC crash it appears
<__blaat> hmms, pitti left for good?
<__blaat> ah
<__blaat> speak of the devil :)
<__blaat> *devel even ;)
<pitti> __blaat: not yet :)
<pitti> __blaat: there's not much difference :)
* pitti just tried Xgl on his two boxes
<ogra> pitti, crazy you ...
<HiddenWolf> ogra: it works fine here. :)
<HiddenWolf> minor glitches notwithstanding
<tseng> pitti: i tried it on 3
<tseng> pitti: only 1 works perfectly
<pitti> ogra: it even works flawlessly on the ibook :)
<pitti> well, some flicker
<pitti> and on the amd64 xgl even starts with the nvidia driver
<__blaat> pitti: can u accept dcc? the output from strace is a bit too large for pastbein
<__blaat> *pastebin
<pitti> however, when calling compiz, the WM goes crazy
* ogra wont try it ... i'm to annoyed by all the sidetracking through crack stuff currnetly ...
<pitti> __blaat: no, doesn't work here
<ogra> i'll test next month or so 
<pitti> __blaat: martin.pitt@ubuntu.com
<pitti> ogra: yes, better; the advantage is that on ppc I don't have these psychedelic colors any more :)
<__blaat> http://rafb.net/paste/results/bDpyIx41.html
<__blaat> sure thing
<ogra> pitti, hehe
<ogra> port the fix to xorg then :)
<pitti> __blaat: what did the ls -l show for you?
<__blaat> the /etc/resolv.conf exists
<__blaat> it is writeable by root
<__blaat>  - /etc/resolv.conf-{blah} didnt exist
<__blaat> I touched the file and set it world writeable as a test
<__blaat> but I still get the same messages
<pitti> __blaat: I mean ls -l /lib/dhcp3-client/call-dhclient-script
<pitti> __blaat: should be -rwsr-xr-- 1 root dhcp 4336 2006-02-01 18:49 /lib/dhcp3-client/call-dhclient-script
<__blaat> ah, I didnt check
<pitti> __blaat: oh, if you should boot another time
<pitti> __blaat: I need that, and ls -ld /var/lib/dhcp3/
<__blaat> sure
<pitti> __blaat: and ls -l /var/lib/dhcp3/
<Keybuk> bah, I wanted a UK +44 555 number
<pitti> hey zyga 
<Keybuk> and nobody's allocating them yet
<__blaat> pitti: thanks v. much for your help
<__blaat> it turns out my call_xxx script was not suid
<pitti> __blaat: hm, did the package installation fail or so?
<__blaat> (I had removed suid on everything a few days before, so it rang a bell when u said that)
<pitti> aaaah :)
<__blaat> nah, it was my doing
<__blaat> probably why dhclient worked one day, and stuffed up the next :)
<pitti> yes, it needs that suid helper to call the /etc script
<pitti> so that the actual daemon can run as unprivileged user
<pitti> __blaat: part of my paranoid derooting rave :)
<__blaat> it's definately goo
<__blaat> *good
<__blaat> ok, I'm going to go play on the ubuntu box now
<__blaat> thanks again :)
<pitti> and yet another happy user :)
<ogra> heh
<ogra> pitti, "this is not a support channel" :P
<ogra> ;)
<pitti> well, it seemed to be a bug...
<Keybuk> meh, still some "pitiful font deuglification" to do, but getting there
<Keybuk> seb128: ping?
<seb128> Keybuk: pong
<Keybuk> seb128: did you get round to trying that new alsa-utils yet?
<seb128> Keybuk: I'm just back, the package with the sbin change still gives me muted sound
<seb128> I was going to reboot now to give a try from init=/bin/sh :)
<Keybuk> ok
<Keybuk> brb
<Keybuk> let me know how it goes
<jpatrick> pitti: you're wanted in #ubuntu-meeting :)
* pitti joins
<Keybuk> holy crap!
* Keybuk files an installer bug
<ogra> ?
<Keybuk> in fstab I have /media/cdrom1 through 8 ... all pointing at /dev/hdb
<Keybuk> and /media/floppy0 through 7 ... all for /dev/fd0
<ogra> thats an old one ...
<ogra> look for it ...
<alexr> Hi there 
<alexr> Anybody is a gfxboot wiz here by any chance?
<seb128> re
<Q-FUNK> update-alternatives: unable to make /boot/grub/default-splash.xpm.gz.dpkg-tmp a symlink to /etc/alternatives/grub-artwork: file not found.
<seb128> grumpf, Keybuk just parted
<Q-FUNK> ubuntu-artwork (0.2.28-1)
<seb128> mvo already did fix that one
<seb128> update
<Q-FUNK> ah
<Q-FUNK> I just did
<seb128> wait for the build and update so
<Q-FUNK> update && upgrade
<Q-FUNK> ok
<Q-FUNK> any idea about whether my gnome-screensaver desktop file to make an ubuntu floater was ever merged into ubuntu-artwork, btw?
<seb128> mdz: the swf plugin is to gst-plugins-bad0.10 (which we don't package atm)
<seb128> that's a question for ogra
<ogra> Q-FUNK, as i said, its on my list ... 
<ogra> it has to be discussed first  and has still time until artwork freeze ... there is no hurry
<seb128> mdz: sorry about the mail, there was no context and was looking like a "please update the packages to include those translations for dapper" so I didn't give it top priority (according to dholbach we should have done so)
<Q-FUNK> ogra: ok. fair enough. I just wanted to point out that it might be easier to include the desktop file and SVG logo into ubuntu-artwork than to patch gnome-screensaver.
<mdz> seb128: no, don't worry about it
<ogra> yup, might be ... but as i said, its artwork stuff, so has time until artwork freeze ... my prio is coding until feature freeze ... then i'll look at other tasks like artwokrk 
<mdz> seb128: it was a last-minute thing and I thought you were online so I could explain
<mdz> seb128: I sent out all the mails and then talked to people
<seb128> mdz: my mail is probably lagging so, I get it around 5pm (ie: one hour after the missing) and I was around since this morning until 7pm (out of some reboot for udev/alsa debug)
<seb128> ok
<seb128> mdz: for gst0.10-swf, -bad are the "not nice code, or no maintainer responsive for the code" stuff ... I can try to figure with upstream what's going on with it if you want
<psusi> who was it that I was speaking to a few weeks ago around here who is the tar guru?  think he said he was an upstream maintainer for tar as well?
<seb128> Keybuk: wb
<Keybuk> seb128: any luck?
<seb128> Keybuk: guess what ... those alsa stuff link to libasound which is /usr/lib ... :)
<Keybuk> *sigh*
<mdz> seb128: those translations were actually for hoary ;-)
<mdz> seb128: it was a one-off demo
<mdz> seb128: ds (swfdec upstream) was in here saying that it worked just fine with 0.10
<Keybuk> seb128: so I guess we need to move libasound to /lib ?
<mdz> seb128: and that he would try to move it to -good
<Keybuk> seb128: did you try that?
<seb128> Keybuk: I guess so
<seb128> Keybuk: no, I've reboot to build it on a proper system
<kiko> hey crimsun?
<seb128> and I'm replying on other stuff on IRC atm, will give it a try in a few min
<seb128> mdz: ah, would be nice :)
<crimsun> kiko: hi
<ogra> shudder ... kubuntu discusses klik inclusion in -meeting ...
<kiko> crimsun, do you have any idea why the mixer doesn't work on the mac mini?
<Keybuk> seb128: I'm starting to think this approaching "too much effort and too much likely to go wrong"
<mdz> seb128: if you could monitor the swfdec stuff and make sure it gets into dapper, that would be excellent
<crimsun> kiko: benc's hacking that iirc
<kiko> it doesn't do anything -- aumix's controls are locked, and the gnome mixer is fubar
<Keybuk> it's easier to deal with a known bug ("mixer settings not restored if you have /usr or /var on separate partitions") then miriad unknown bugs by moving all this stuff around
<seb128> Keybuk: do you think we should just put the init.d standard startup instead of using udev?
<kiko> crimsun, oh, really? so it's a kernel support issue?
<seb128> mdz: ok, will do that
<crimsun> kiko: well, what do amixer and alsamixer provide?
<ogra> kiko, try switching the pcspeaker checkbox off and on again in the mixer ... WFM
<Keybuk> the init.d standard startup doesn't work ... because there's no init.d point we can say "we have sound cards now"
<seb128> Keybuk: so you just want to say "if you have /usr or in a separate partition no sound luck for you"? 
<Keybuk> seb128: you noticed it too late ;)
<seb128> nah nah nah
<Keybuk> moving libasound into /lib will break a lot, won't it?
<Keybuk> that's transition-level
<kiko> hmmm
<kiko> crimsun, ogra: it appears mpg123 is using oss output, not alsa.
<kiko> this is breezy, though
<ogra> oh
<seb128> Keybuk: $ apt-cache rdepends libasound2 | wc -l
<seb128> 183
<crimsun> kiko: mpg123-oss or mpg321 (with alternative set to mpg123)?
<seb128> yeah, not good
<kiko> hmmm, just mpg123
<Keybuk> seb128: I'm going to suggest something
<Keybuk> how about a "while [ ! -d /usr/bin ] ; do sleep 1; done"
<Keybuk> at the top of the alsa start script
<seb128> Keybuk: is there a way to do an ugly preload hack?
<kiko> crimsun, let me try mpg321
<seb128> Keybuk: like copying it to /lib too and preload?
<Keybuk> I'd rather avoid those kinds of things, tbh
<seb128> Keybuk: that's quite ugly too but that would work ...
<kiko> crimsun, it works!
<kiko> rock!
<crimsun> kiko: excellent.
<tommie-lie> don't know if I'm on-topic here, but could anybody tell me if I can append "ubuntuX" to the version string of all packages specifically intended for Ubuntu, or only to those packages that are made to be included in universe?
<Keybuk> what's ~/.wapi ?
<Keybuk> tommie-lie: it's appended to the versions of packages modified for and packaged for Ubuntu, no matter whether main, universe, etc.
<seb128> Keybuk: the sleep trick works for me, I've no better idea atm
<dholbach> everybody added something to  http://wiki.ubuntu.com/UbuntuBugDay ?
* dholbach writes reminder
<tommie-lie> Keybuk: also for packages for a completely private repository, i.e. that will never make it to archive.ubuntu.com?
<Keybuk> tommie-lie: that's up to you
<tommie-lie> Keybuk: okay, thanks for the info!
<slomo_> Keybuk: ~/.wapi is used internally by mono
* Keybuk wonders how he ended up with /root/.wapi
<Keybuk> seb128: of course, this presents another problem
<Keybuk> how to make the script wait, without udev waiting for the script <g>
<seb128> start &
<seb128> ?:)
<slomo_> Keybuk: did you start mono as root? or maybe a broken package which doesn't set MONO_SHARED_DIR correctly build as root and not with fakeroot? no idea ;)
<Keybuk> seb128: yeah, but with start-stop-daemon and stuff
<seb128> grumpf
<seb128> Keybuk: make alsa-utils mount /usr and unmount it when it's done? :p
<seb128> or do we lack some drivers at that point that could be needed?
<Keybuk> we could lack the /dev node for the /usr filesystem ;)
<alexr> Anybody know the details of gfxboot ?
<psusi> anyone know who the local tar guru was?  I was speaking to someone a few weeks ago here who was also an upstream maintainer for tar... but I forget who
<HiddenWolf> psusi: why don't you google for tar, figure out the upstream site, find the name, and call out for the person?
<ds> mdz, seb128: I'm not entirely sure anymore that swfdec (the element) works correctly with gstreamer-CVS
<HiddenWolf> psusi: or check who last touched tar in debian or ubuntu.
<seb128> ds: you have one month to fix it :)
<seb128> ds: thank you :)
<mdz> seb128: feature freeze is in one week ;-)
<ds> mdz: the feature is there, it's just buggy :)
<seb128> mdz: it's a GNOME stuff ... :)
<ds> ah
<janimo> seb128, ogra said  you want to move etc/gdm configs to usr/share did I understand right?
<seb128> yeah, let's ship the broken one before feature freeze and call it a bug fix then :)
<seb128> janimo: no
<janimo> what then?
<seb128> janimo: upstream did that, that's not something I want
<ogra> janimo, i said he thinks about it :)
<seb128> custom is to be changed and to /etc
<Keybuk> seb128: ok, another alsa-utils source uploaded for you to test
<janimo> ogra, you can read his mind ? ;)
<seb128> the distro file is static and to /usr/share
<seb128> Keybuk: k
<janimo> seb128, so gdm config stays as is for dapper then?
<janimo> so I go ahead and do that conf override thing for the  xfce theme
<ogra> janimo, only if my mindrays reach to france ... thats really weather dependent :P
<seb128> janimo: no
<seb128> janimo: it'll be moved to /usr/share as due
<seb128> I'm just not sure yet how to migrate user configuration
<janimo> but at least gdm.conf has to stay in etc right?
<seb128> no
<seb128> did you read what I just said?
<janimo> yes, but apparently I did not understand
<seb128> the custom is for etc
<janimo> you said: the distro file is static and to /usr/share
<seb128> the gdm.conf is for /usr/share
<janimo> so the custom file is staying where the init scrips is currently looking for it?
<seb128> what about you reading the package changelog?
<seb128> or the upstream NEWS which has all the explanation :)
<janimo> going there now :)
<seb128> "    - Because the main gdm.conf file is now read-only, contains distro
<seb128>       defaults and is not to be edited by the user, the file has been
<seb128>       moved to ${datadir}/gdm/defaults.conf (also factory-gdm.conf is
<seb128>       now %{datadir}/gdm/factory-defaults.conf)."
<janimo> I have just read it
<janimo> and it seems /etc/gdm/gdm-cdd.conf  is ok so that part is not affected right?
<seb128> hum
<seb128> static configuration is moved to /usr/share
<seb128> it will probably change for /usr/share/gdm-cdd.conf
<janimo> what is static configuration then?
<seb128> is that clear now?
<seb128> something shipped by a package
<janimo> clearer
<seb128> to opposite to something written by gdmsetup
<ogra> janimo, it might move to /usr/share but it isnt yet
<ogra> and thats what seb128 is considering, since i gave no requirement when he asked me 
<seb128> I want to follow upstream move, it makes sense
<seb128> I'm just not sure on how to migrate datas on update
<seb128> brb, trying alsa changes on startup
<mjg59> Keybuk: http://xbox-linux.org.nyud.net:8090/mactel/index.php/Main_Page
<mjg59> Keybuk: So we need to get hold of one of these fast :)
<mjg59> Ha!
<mjg59> They're still Broadcoms
<Keybuk> Jane says it's ordered
<Burgwork> mjg59, doable for dapper?
<mjg59> Keybuk: Any estimated delivery time?
<mjg59> Keybuk: Also, iMacs are possibly easier to obtain
<Keybuk> mjg59: no idea
<mjg59> Looks like their hacked framebuffer does nothing other than grab the linear framebuffer left behind by EFI
<mjg59> I'd be surprised if it's actually using vesafb as such
<seb128> Keybuk: that alsa-utils works fine :)
<Keybuk> seb128: cool, I'll upload that one then
<seb128> thank you for the work on that :)
<seb128> nice to not have every single audio source muted at every startup :p
<dholbach> good night guys
<Florob> Sorry, to bother all of you, but could somebody possibly clear up the issue in the following forum thread, which keeps people from updating: http://ubuntuforums.org/showthread.php?t=131445
<Seveas> Florob, it's an attempt of one of the developers to be funny 
<HiddenWolf> Florob: it says "my previous upload did not work, so let's do it again"
<HiddenWolf> Florob: where "did not work" means "did not hit the archive"
<Florob> I know that and posted it but nobody wants to believe it ;)
<HiddenWolf> If people want to be stupid, they will be. :)
<Florob> I'll point them to the logs, lets see if people on #ubuntu-devel mean more to them, thanks anyway
* mvo reboots to test grub
<seth> oh rolleyes, looky Seveas et al: https://launchpad.net/distros/ubuntu/+source/linux-meta/+bug/31698
<Ubugtu> malone bug 31698 in linux-meta linux-image-2.6-386 "linux-image update description fishy and suspicious" [Critical,Unconfirmed]  
<Seveas> 
<Seveas> bug 31698
<Ubugtu> malone bug 31698 in linux-meta linux-image-2.6-386 "linux-image update description fishy and suspicious" [Minor,Rejected]  http://launchpad.net/bugs/31698
<Seveas> spot the difference ;)
<seth> :D
<HiddenWolf> LMAO
<HiddenWolf> Sweet
<seth> people sometimes, I tell ya
<seth> oh well
<HiddenWolf> It was unprofessional
<HiddenWolf> He should at least have copied part of the original changelog. :)
<Seveas> yes, but it's a development version ffs
<HiddenWolf> *chuckle*
<mjg59> Seveas: No, that looks like a security update
<HiddenWolf> People are smart, groups are dumb. :)
<mjg59> (For Breezy)
<Seveas> ah right...
<mjg59> We're somewhere past -10 on Dapper...
<Seveas> ok, then someone should punish the kernel team
<HiddenWolf> 2.6.15-16 or so
<dieman> hrm
<dieman> the new ipw2200 driver seems to be working better with wpa
<dieman> (1.1.12)
<dieman> )  oh no, take that badck, it just did its paus
<dieman> e thing again
<dieman> just had to wait for me to say its working better
<dieman> 1.0.11, rather
<Keybuk> http://people.ubuntu.com/~scott/network-manager/
<Keybuk> seb128, pitti, etc. ^^ please test and let me know how you get on tomorrow
<Keybuk> (am about to go offline while I play myself)
<seb128> ok
<seb128> will do that :)
<seb128> maybe it'll stop playing with my resolv.conf :)
<Keybuk> yes, it should
<Keybuk> also note that it won't touch (or even acknowledge the existance of) interfaces listed in /etc/network/interfaces
<seb128> cool
<seb128> atm it lists my 2 cards (only one activable)
<seb128> I don't get why it doesn't activate the only available one by default
<Keybuk> I haven't worked out how to make cards appear, but not be activatable yet
<Keybuk> or, more to the point, how to make cards appear without network manager cheerfully tearing down the interface first
<seb128> I'll play with the new version so we can talk tomorrow about it does exactly after the upgrade :)
<Keybuk> yup
<Keybuk> right, back tomorrow
#ubuntu-devel 2006-02-22
<mjg59> crimsun: Around?
<mjg59> sladen: Are you collecting mechanisms for signalling tablet rotation?
<sladen> mjg59: trying, it needs tying into gdm, so that GDM shows a on-screen keyboard in flipped mode
<ajmitch> morning
<sladen> mjg59: I couldn't find it on the tosh I was hunting down---any suggestions
<sladen> mjg59: windows seems to know the difference
<mjg59> sladen: Portege? Yeah, I've got code somewhere
<mjg59> Or rather, elmo has it right now
<mjg59> sladen: Needs to listen for an ACPI signal (that isn't currently passed through by the kernel, so I was using /dev/acpi) and then read a bit from memory to get the status
<sladen> mjg59: ah.  Sounds like you got that one covered then...
<jsgotangco> morning
<mjg59> sladen: With some amount of pain, yeah. May just end up writing a small kernel module (once I get the machine back)
<mjg59> sladen: But in general I think we want it to be something that hal can notice and set on the screen device
<mjg59> Hrm. Despite all the ac97 registers being identical over suspend/resume, this machine refuses to make any noise through the speakers afterwards
<mjg59> But will still work through headphones
<mjg59> If it needs some sort of hardware magic, I will be very unhappy
<sladen> mjg59: what type of machine is it?
<sladen> mjg59: hint, thinkpad-keys, I had to downgrade it for a demo yesterday of that fact that Ubuntu 'just worked'...
<mjg59> sladen: This? HP 6220
<mjg59> sladen: I've requested a sync
<mjg59> I'm not going to upload an identical package
<sladen> elmo: plz syncage hotkey-setup, matthew will get turned on
<xerox_> Is there any documentation about making ubuntu .debs from the ground up?
<neuralis> xerox_: debian new maintainer's guide, MOTU school, etc
<sladen> xerox_: http://fridge.ubuntu.com/node/208
<xerox_> Thank you.
<SAAD3000> Developers in the next release of ubuntu i would suggest to work on the network flows that it suffers in 5.10
<sladen> mjg59:  http://www.paul.sladen.org/ubuntu/upload/ibm-zoom.sh  if you can work out how to map the keypress to executing /etc/acpi/ibm-zoom.sh
<mjg59> With pain
<mjg59> Really needs to be done by something in the user session
<daemon2> Good evening
<daemon2> or night
<daemon2> or whatever
<daemon2> I have a RTL 8139 network card, onboard in an ASUS 5028, if I reboot from XP to Linux it works OK, but if I shut down, and then turn it on it is not working. Can not figure it out why. Autonegotiation does not succeed. already tried fixed 10/100 HD/FD modes manually. No luck. The machine on the other end of the cable says Network Cable unplugged.
<Burgwork> daemon2, that is a #ubuntu question. Please ask it there
<daemon2> From a cold start it sometimes works, sometimes not
<daemon2> for example today in the morning worked like a charm
<Burgwork> daemon2, -devel is for your general solution to a specific bug, not that the bug itself
<daemon2> oj
<daemon2> oh
<daemon2> sorry
<Burgwork> daemon2, no problem
<tseng> infinity: awakeish?
<tseng> infinity: we could use some mass give-backs on things waiting for mono on ppc
<tseng> infinity: probably mono-jit actually
<fbond> siretart: you there?
<infinity> tseng: Yeah, we sure could.  Do you have a list of package you're specifically interesting in seeing given back?
<tseng> infinity: hm let me see
<tseng> infinity: is there a better way to approach this than apt-cache rdepends mono-jit
<tseng> infinity: and cut that down into sources
<infinity> tseng: Shell loops and grep-dctrl tend to be my friends.
<infinity> I can do it in a bit, but right now I'm a bit swamped.
<infinity> So whatever you can do to get there faster, the better.
<ogra> hmm
<jsgotangco> ogra!
<ogra> no /sbin in path on the install CD ...
<ogra> i thought that was liveCD specific
<mdz> ogra: please file a high-priority bug and assign to tollef
<ogra> mdke, he is aware of it, was working with Kamion on it today  ... but i didnt know it also occurs on the install cd ... will look for the bug and follow up
<ogra> s/mdke/mdz/
<mdz> if it's not fixed soon, we will need to roll back that feature
<mdz> it has been weeks
<ogra> oh, i didnt know ...
<mdz> it was broken at the sprint
<ogra> mdz, what do you think about always defaulting ltsp-build-client to i386 on amd64 ... i think we can ignore it for now and i dont need to fiddle with preseeding for amd64 CDs ...
<mdz> ogra: defaulting to i386 on amd64 sounds reasonable
<ogra> fine :) will add that to ltsp-build-client then :)
<mdz> ogra: by the way, please don't waste time on powerpc until the targets for dapper are all complete
<mdz> those are much more important
<ogra> it broke the CD and i had it locally anyway ...
<ogra> the last upload was only copy and paste
<ogra> launchpad builds feel a lot slower than the old buildds ... i guess that due to the different crontab runs ...
<infinity> Yeah, the whole process is a bit slower.
<infinity> 60 minutes cron.daily instead of 30, plus a few other delays.
<ogra> yup...
<ogra> will that speed up at some point ? 
<mdz> ogra: yes
<infinity> Well, I'm campaigning for ACCEPTED autobuilding, which we kinda need for dapper-security, but I wouldn't hold my breath on it happening really soon.
<infinity> I understand that cron.daily is supposed to happen more frequently, though.
<mdz> but meanwhile, functional problems are higher priority than perceived slowness
<ogra> then i'm fine ... its hard to do planning if you want to do a cdimage run ...
<mdz> infinity: I thought soyuz built from accepted naturally
<infinity> mdz: Then it has a funny idea of "accepted", compared to dak.
<mdz> infinity: I thought source could be built as soon as it was accepted, rather than needing to wait to be published in the archive
<mdz> s/to be/for it &/
<infinity> mdz: In theory, it could be (since it's pushed directly to the buildds, not downloaded from an archive), but the build queues are built by cron.daily.
<mdz> infinity: then so long as they're built after accepting packages in the cron.daily run, we should get the desired behaviour
<infinity> But the real interesting use case for ACCEPTED autobuilding isn't "build source from ACCEPTED" (though that's a useful side effect), it's "build source against binaries that are in ACCEPTED"
<infinity> And it certainly won't do THAT.
<mdz> true enough
<infinity> (That's required for multi-binary, inter-dependant security releases, as well as just plain old faster turnaround on mass uploads)
* mdz shakes a fist at l-r-m
<infinity> Watch it, LRM fights back.
<tseng> infinity: can i /msg you my list?
<infinity> tseng: Please do.
<ogra> mdz, bug 31716 filed 
<Ubugtu> malone bug 31716 in Ubuntu "PATH only contains /bin:/usr/bin on new installs" [Critical,Unconfirmed]  http://launchpad.net/bugs/31716
<infinity> mdz: Speaking of LRM, can we get yet another UVF exception for yet another fglrx update?  hey released a new one about two days after mt last upload.
<tseng> infinity: thanks muchly
<infinity> s/hey/They/
<infinity> tseng: I'll unmangle all this stuff in the next hour.  Thanks for tracking it down.
<ajmitch> infinity: thanks for sorting that
<tseng> thanks ajmitch for the grep-dctrl schooling
<ogra> do i smell a mono for my ibook ? 
<tseng> ogra: yeah you do
<ogra> YAY !!!!
<tseng> ogra: send your love to Kamion 
<tseng> ogra: for the hack of the day
<ogra> f-spot finally beck in the archive :)
<ogra> *back
<tseng> seb wants to put it in desktop asap
<ogra> once you used it you get addicted :)
<infinity> tseng: so, colour me curious, what was broken with mono on ppc64?
<ogra> i really cant manage my pics with gthumb anymore :)
<tseng> infinity: parallelism issue only on 64 bit smp
<jsgotangco> that's really nice
<tseng> infinity: still no lead on the real cause
<jsgotangco> f-spot+compiz drool
<tseng> infinity: we are doing sched_setaffinity to avoid the second cpu
<tseng> infinity: in mono-mini, its just for bootstrapping
<ajmitch> ogra: hopefully f-spot 0.1.9 once it gets a UVF exception
<ogra> jsgotangco, if you point the edubuntu liveCD to people, you should probably tell them where they find it there are only working daylies  ;)
<ajmitch> jsgotangco: what overlap could there be with f-spot & compiz though?
* ajmitch did see something about f-spot & gnome-screen-saver mentioned
<jsgotangco> ogra, oh yeah....
<jsgotangco> ogra, i think the guy tried getting the meta
<ogra> jsgotangco, yup 
* jsgotangco forgot...replied that email at 7am
<ogra> the current daily is fine for all arches ... install amd64 and ppc are broken but i386 is good ...
<jsgotangco> ajmitch, just more bling for the endless quest of the perfect bling desktop
<jsgotangco> ogra, yeah amd64 install is still oh well
<jsgotangco> i'll rsync an i386 later
<ajmitch> jsgotangco: heh
<ogra> jsgotangco, yes, i missed that linux-image-amd64 doesnt exist ... it must be amd64-generic ... 
<ogra> silly mistake 
<jsgotangco> ubuntu amd64 is going well though
<ogra> and already fixed ... i'll trigger a new install build after i got up tomorrow, that should at least unbreal ltsp chroot builds for all arches
<ogra> *unbreak
<jsgotangco> hmmm
<jsgotangco> the initial f-spot folder search doesn't play nicely with expose though (compiz)
<mdz> infinity: yes
<ajmitch> jsgotangco: no surprise, there are plenty of bugs in compiz :)
<jsgotangco> yeah
* ajmitch hopes that metacity will support all that functionality for dapper+1
* ajmitch reads through last night's devel status update
<jsgotangco> ajmitch, this would still look good for the school talk next week heh
<ajmitch> sure
<ajmitch> I guess the init patch won't be done by end of work today, and no net access over the weekend
<Riddell> Kamion: all 6 kubuntu CDs from 2006-02-16 are good 
<jsgotangco> Riddell, i've tested kubuntu amd64 last night btw, its good
* ogra throws envious looks to Riddell 
<jsgotangco> (install/live)
<Riddell> jsgotangco: great thanks
<ogra> infinity, could you push the button for a fresh edubuntu livefs build ?
<infinity> Any particular arch you're testing on?
<infinity> (note that the dailies will build in about 3 hours anyway)
<ogra> powerpc was oversized, i shuffled the langpacks over the arches a bit
<ogra> hmm, the livefs gets built after the daily-live CD ?
<infinity> Just before, in theory.  Unless someone's cron-fu has gotten messed up...
<ogra> the got build 3h ago according to the timestamp of the isos
<ogra> and i want to stanr a fresh iso if i get up ...
<ogra> *start
<ogra> god, my typing gets wonky ...
<infinity> Oh, they're staggered.
<infinity> I never checked the crontab on little...
<infinity> I should stagger the livefs builds to match the ISO builds, I guess.
<ogra> heh, yes, would make sense ...
<ogra> even though i belive tollef does them manually anyway ...
<infinity> Well, we all do the occasional manual livefs build when testing stuff, but the dailies are still built for a valid reason.
<infinity> And when Tollef isn't doing livecd stuff 24/7 (which will hopefully be soon), he'll have less motivation to do 12 manual builds per day. :)
<ogra> heh
<infinity> Anyhow.  I'll thwack some edubuntu builds for you now.
<ogra> thanks ... take your time ...
<ogra> i'll need them in 6-8h ...
<ogra> as long as the current seeds are on them :)
<infinity> Err, how current?
<infinity> (And did you update edubuntu-meta?)
<ogra> http://people.ubuntu.com/~cjwatson/seeds/edubuntu-dapper/live
<ogra> for live ? 
<ogra> this current ...
<infinity> We use the metapackages in the livefs builds, we don't use the seeds directly.
<infinity> This is kinda intentional, to make sure the meta packages aren't broken. :)
<ogra> ARGH ... i'm to tired
<ogra> i'll do that now ...
<jsgotangco> ogra, you gotta sleep man
<infinity> Sleep is for the weak!
<ogra> jsgotangco, yes, but i want at least have everything prepared for tomorrow :)
<jsgotangco> oh my
<ogra> and what infinity said :)
<jsgotangco> i smell flight4
<infinity> Hrm, I have an initramfs fix to get in before flight4.  Thanks for the reminder.
<ogra> i'm just waiting for ltsp 0.74 to get copied in the archive to trigger a new install CD ...
<jsgotangco> ogra, if a build can be triggered in a few hours...i can grab the image
* infinity goes to do that now.
<ogra> jsgotangco, it still wont fix amd64 ... i have no clue why its oversized ...
<ogra> and if i cant sort it out tomorrow, edubuntu flight 4 wont have a proper amd64 ..
<jsgotangco> 9 issues with amd64....
<jsgotangco> hmmm debhelper is new
<ogra> in fact there are 10 ... i removed apache2 already
<ogra> which was only for testing ...
<infinity> What's wrong with apache2?
<jsgotangco> live looks fine though
<ogra> nothing
<jsgotangco> eekk ppc live is oversized
<ogra> infinity, the amd64 install CD is oversized and usually things like apache fall off in report.html ...
<infinity> Ahh, just oversize issues.  I see.
<ogra> jsgotangco, already fixed ... just waiting for a fresh metapackage and build
<jsgotangco> ok
<ajmitch> ogra: and you're already using 700MB images, right?
<ogra> yup
<ogra> but amd64 chokes at 690 ... and i have no idea why
<jsgotangco> ogra, ok do you still need test results? x86 looks ok though...
<ogra> so lets see if i busted amd64 and i386 live now :)
<ogra> x86 was fine here too ... i added some language packs now ...
<ogra> lets see how that evolves :)
<ogra> gah ... still no ltsp 0.74
* jsgotangco will wait
<ogra> i could fly to london, copy it on a floppy and carry it from the buildd to the archive in that time ...
<ogra> 2.5h since upload ...
<ogra> it even fits on a floppy ..
<jsgotangco> are you still on isdn?
<ogra> nop
<ogra> i wouldnt do iso stuff on isdn ...
<ogra> but a flight to london takes 1h from here ... 
<infinity> It built, so I dunno why it's not in the archive yet...
<ogra> the cronjobs are a lot slower ... 
<ogra> all of them ...
<infinity> mdz: Still around?  How do you feel about me merging initramfs-tools with Debian, which is finally close to in sync with us?
<ogra> i noted that before and try not to complain to much :)
<ajmitch> ogra: no new binaries?
<ogra> nope
<ogra> 0.73 was uploaded 30min before ... they are in the archive already ...
<ogra> (longer than 30min though)
<ajmitch> trying to get access to the data centre at this hour might take a bit longer though 
<ogra> true ...
<infinity> It looks like it's in the archive to me...
<ogra> but would be worth a try ... if only to see elmos face if i ring him out of bed to hand out a floppy with 4 binaries :)
<infinity> http://archive.ubuntu.com/ubuntu/pool/main/l/ltsp/
<ogra> yup
<ogra> since <2min 
<ogra> great ...
* ogra logs in to little ...
<ogra> infinity, can you wait with the livefs until -meta has built ? 
<infinity> s/wait/try again/  Yeah.
* ogra guesses in ~3h :)
<ogra> oki, night all ...
<ogra> jsgotangco, there should be new install crack to test in about 20 min if you want :)
<jsgotangco> would x86 suffice?
<infinity> Any testing is better than no testing.
<jsgotangco> it seems we'll still have amd64 oversizing
<ogra> sure, but that would only be regression testing ...
<ogra> which is unlikely to happen, but you never know :)
<jsgotangco> okay
<jsgotangco> ogra, hmmm i see a 17.1 now
<jsgotangco> ogra, i'll update to 20060217.1 it seems to be available now
<dholbach> good morning
<Burglaptop> morning dholbach
<dholbach> hey Burglaptop
<pitti> Good morning
<ajmitch> morning
<Burglaptop> morning] 
* infinity blinks.
<infinity> Who broke utmp handling in dapper?  Both "w" and "who" tell me there's no one logged in on my machine.
<robitaille> infinity:  works fine here
<infinity> Bizarre.
<jsgotangco> hmmm
<jsgotangco> confirmed
<jsgotangco> cool im a ghost
<robitaille> humm..that's weird. works here.  And I'm up to date
<jsgotangco> i'm using yesterday's build then updated
<robitaille> maybe it's an access problem with /var/log/wtmp ?
<infinity> It's readable for me, which is all one should need.
<dholbach> infinity: works for me too
<janimo> pitti, if you get to xfdesktop within the next hour or two please take it directly from pool as it did not build yet so apt-get source would get you the old package.
<jsgotangco> infinity, 16:02:53 up  8:50,  0 users,  load average: 0.44, 0.42, 0.34
<janimo> maybe you always take from pool in which case I shut up ;)
<pitti> Hi janimi
<pitti> janimo even :)
<janimo> :)
<pitti> janimo: funny, I was just looking for you
<pitti> yes, I'm just looking at it
<dholbach> janimo: could it be that xubuntu is in a state of limbo atm?
<janimo> I must have sensed it
<pitti> janimo: any idea about this:
<janimo> dholbach, 100% true
<dholbach> janimo: that's what i thought :)
<pitti> gtk2-engines-xfce |    2.2.8-1 | dapper/universe | source
<pitti> gtk2-engines-xfce | 2.3.0cvs20050306-2 | dapper/universe | amd64, i386, powerpc
<pitti> janimo: ^ where is the latest source?
<janimo> pitti, hmm let me check
<pitti> oh, so xfdesktop 4 is FTBFS?
<pitti> I can't approve it that way
<janimo> pitti, I just uploaded a fix , but it's ok to wait till it works then
<pitti> ok, WFM
<pitti> +       pkill -USR1 -f xfce-mcs-manager || true
* pitti doesn't like such things in maintainer scripts
<janimo> pitti, that's what the debian maintainers put in.
* janimo washes hands
<janimo> that snippet is in many xfce packages to restart the config manager to reload settings
<pitti> well, if it restarts automatically, it's probably ok
<janimo> pitti, yes it's a restart not a real kill AIUI
<janimo> pitti, how did you get those gtk-engines info? which command?
<pitti> janimo: madison
<pitti> janimo: you can get something similar with apt-cache madison gtk2-engines-xfce
<janimo> thanks
<pitti> (only for your architecture, though)
<pitti> ah, wait
<pitti> it seems that the source has been renamed
<pitti> or so
<pitti> gtk2-engines-xfce | 2.3.0cvs20050306-2 | http://archive.ubuntu.com dapper/universe Packages
<pitti> gtk-xfce-engine | 2.3.0cvs20050306-2 | http://archive.ubuntu.com dapper/universe Sources
<pitti> that seems to match
<janimo> I think I did not touch that package so far 
<janimo> you can skip it then while I look at it, thanks
<pitti> yep, package rename
<pitti> fine then
<janimo> it seems it's another non-essential package which is form the non-debian upstream since hoary
* pitti fixes report page and approves
<vmlintu> hi pitti, ogra on the #ltsp channel said to ask you for more information about alsa file pipes and how to use them in network setting
<pitti> vmlintu: uh, ALSA is not really network-capable
<pitti> s/really/at all/
<vmlintu> pitti: that was my understanding also, but he was talking about some weird possibility of piping the alsa traffic to a file and piping that through an ssh tunnel to a remote host
<pitti> vmlintu: yes, that was a pretty crackful idea we talked about in some LTSP BoF
<pitti> vmlintu: but I thought esd worked much better?
<vmlintu> pitti: the reason I'm asking is because I need to get remote sound working for java
<vmlintu> pitti: I was working on esd plugin for jre but this sounded like it could fix some other applications as well
<pitti> vmlintu: well, I never tried this idea, it just came to my mind back then, but I discarded it as too crackful
<pitti> however, feel free to try it, maybe it works ;)
<vmlintu> pitti: maybe I pass for now, it sounds just too extreme right now :)
<vmlintu> pitti: getting java sounds working in ltsp is enough for me now
<pitti> Riddell: keep is not in ubuntu ATM, so I can't approve it
<janimo> pitti, thanks a lot for the reviews :)
<pitti> you're welcome
<phlaegel> anybody know what kind of shape the recent daily install cds are in? I'm going to do a fresh install tomorrow...
<pitti> phlaegel: I tested ppc and amd64 yesterday, went smoothly
<phlaegel> yesterday being the 16th?
<janimo> should be good as flight 5 is approching
<pitti> 4 :)
<Mithrandir> flight 4, but yeah
<pitti> phlaegel: yes
<fabbione> sladen: please stop filing duplicate bugs. kthxbye
<phlaegel> sounds good enough for me... I'll give the daily a shot. thanks
<janimo> well flight 5 is approaching too it's only further away ;)
<Mithrandir> janimo: silly you. :-P
* Kamion goes to cut down the size of the daily install CDs
<minghua> Does flight CDs have a fixed release schedule?
<minghua> I can't find related information
<Kamion> no, they don't
<Kamion> we generally shoot for every two weeks and hit about every four ;-)
<Kamion> (just because preparing them is so time-consuming, and dependent on the archive being sane)
<minghua> oh, nice plan :-)
<minghua> thanks Kamion
<pitti> janimo: gqview has a patch which does s/firefox/mozilla-firefox/; can you please revert that?
<janimo> pitti, ok will do
<pitti> janimo: (it's in the package diff.gz, which is pretty messy)
<pitti> thanks
<janimo> pitti, I haven't touched that package :)
<pitti> I know, I didn't blame you :)
<janimo> it;s not xfce per se just the most appropriate gtk viewer so far :)
<pitti> janimo: I'm just throwing the fixing work at you :)
<janimo> good
<pitti> yes, it's slim, uses gtk2, and faaast
<janimo> there's another gimageview which some people proposed, nice too
<jsgotangco> ogra, hmmm edubuntu amd64 looks good it went past chroot...now installing
<jsgotangco> 20060217.1
<ogra> yay
<ogra> at least my bugfix worked :)
<ogra> even i still dont know why its oversized ...
<jsgotangco> is it?
<ogra> there is still cruft in the report.html file
<jsgotangco> 9
<jsgotangco> hmmm lsb
<ogra> yup.... the typical mess of an oversized iso ... alien, debhelper ...
<jsgotangco> ahh
* jsgotangco understands it better now
<jsgotangco> ogra, can you release an oversized iso for milestone?
<ogra> jsgotangco, if it installs i dont care... but it would be nicer to not have it oversized
<jsgotangco> i think this will be successful already at 50% installing
<Kamion> oversized up to 700MB is fine for milestones, but beyond 700MB isn't
<Kamion> >700MB vastly reduces the number of people who'll actually be able to burn it
<jsgotangco> ahh
<ogra> Kamion, any hint why that happens ? 
<ogra> its 690MB 
<jsgotangco> 690MB at the moment
<ogra> and i cant see anything that might cause 10MB
<jsgotangco> PPC is 1MB less
<ogra> i even dropped a bunch of stuff ...
<jsgotangco> 61%....
<Kamion> ogra: you can investigate as well as I can
<Kamion> I have a lot of other things to do, and I'm afraid I don't have time to investigate Edubuntu things on top of everything else
<ogra> oki, i'll try to find out ..
<Kamion> look in the CD build logs, search for "CD 2"
<JaneW> does anyone know if CACertInclusion is something that is still wanted? https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/CACertInclusion
<ogra> thanks ... thats the hint i needed :)
<JaneW> a spec stub was created at UDU, but it hasn;t been fleshed out further since...
<pitti> JaneW: sounds interesting
<jsgotangco> JaneW, that guy was from sydney i remember him
<ogra> yup
<Kamion> grr, Keybuk rsync-pushed to the seeds and broke stuff
<ogra> he handed out certs to everybody
<JaneW> pitti: someone is interested in getting involved with it...
<jsgotangco> its about adding the root cert to firefox or something i think
<jsgotangco> err not root
<Kamion> bzr get dapper dapper-fixed; mv dapper dapper-broken; mv dapper-fixed dapper
<Kamion> there
<jsgotangco> ogra, stage 1 done
<HiddenWolf> who patched in the grub artwork?
<ogra> HiddenWolf, mvo
<ogra> jsgotangco, yay
<jsgotangco> ogra, amd64 is in business
<ogra> cool :)
<HiddenWolf> ah, great, now I can't use grub anymore. ;)
<Treenaks> HiddenWolf: why? your nvidia is acting up?
<HiddenWolf> Treenaks: garbled colors
<Treenaks> HiddenWolf: buy proper hardware :)
<HiddenWolf> Treenaks: looks like an lsd-trip
<Treenaks> HiddenWolf: I have no idea, how do those look?
* HiddenWolf shoots Treenaks
<jsgotangco> heh
<Treenaks> HiddenWolf: just because I'm telling you the truth about proper hardware?
<HiddenWolf> Treenaks: no, because I feel like it. ;)
<fabbione> seb128, dholbach: ping?
<dholbach> fabbione: pong
<Treenaks> HiddenWolf: CoC :P
<HiddenWolf> Treenaks: you love me anyway. :) And my hardware is perfectly proper. :)
<fabbione> dholbach: problem: fresh i386 dapper install. /home on local fs -> gdm login ok.
<seb128> fabbione: pong
<fabbione> dholbach: mount /home from server. -> gdm login goes on.. it starts to load nautilus. everything stops loading.
<ogra> wow ...
<fabbione> seb128 as above
<ogra> jsgotangco, have a look at the new liveCD 
<fabbione> dholbach, seb128: note: this works from the dapper amd64 install i have on the other disk and it has been working for about... 7 yeras
<jsgotangco> ogra, ok
<fabbione> what do you need to understand why something is hanging?
<dholbach> fabbione: does strace or gdb say anything interesting?
<fabbione> dholbach: strace or gdb of what? gnome spawns 248756746547 processes
<ogra> jsgotangco, its shrinked so it even nearly fits on 650MB :)
<dholbach> fabbione: you referred to nautilus, that's the first I thought of
<jsgotangco> hmmm
<jsgotangco> nice....
<jsgotangco> ppc is still oversided...
<jsgotangco> s/oversided/oversized
<fabbione> dholbach: i see on the progress load bar: loading nautilus... and it stops there. nautilus in a POLL loop. If i try to kill it, it will restart.
<ogra> huh ? 
<ogra> jsgotangco, where do you look ?
<jsgotangco> 17.1
<jsgotangco> oh wait there's no report
<ogra> jsgotangco, ppc is at 683MB and has no OVESIZED tag
<ogra> liveCDs have no report :)
<jsgotangco> no installables
<jsgotangco> heh
<ogra> jsgotangco, its fine :)
<ogra> if they run we're ready to go with these ...
<janimo> fabbione, doesn't  /usr/bin/X have to be suid root? I cannot startx as normal user without that
<seb128_> grumpf, dsl
<seb128_> <seb128> when "everything stops loading", what do you have on the screen?
<seb128_> --- Disconnected ().
<fabbione> seb128_: i have the rectangle load progress bar.
<pitti> Kamion: can I upgrade gpg to 1.4.2.1? it fixes a security issue and adds a test case for it, nothing else
<fabbione> ok i excluded nautilus
<fabbione> it's something that loads after that
<pitti> Kamion: I'd be fine with just applying the security patch, but having the test case would be nice IMHO
<fabbione> if i replace nautilus with /bin/true it still hangs
<seb128_> your home is on nfs ?
<fabbione> seb128: yes
<fabbione> but it has been working for a looooong time
<Kamion> Riddell: I'm cutting back Kubuntu language packs
<seb128_> fabbione: since when does it happen?
<Kamion> ogra: you can't totally rely on the OVERSIZED tag
<fabbione> seb128: since today?
<Kamion> ogra: especially not on Edubuntu install CDs
<seb128_> fabbione: what did you upgrade?
<fabbione> seb128: i did try a test install right 30 minutes ago.
<seb128_> hum
<fabbione> seb128: fresh dapper install
<Kamion> ogra: because if the CD gets too big, debian-cd shifts stuff beyond 700MB or so onto a different CD and you just get silent breakage
<fabbione> seb128: the other disk with warty -> dapper upgrade across years, still works fine :)
<Kamion> ogra: searching for "CD 2" in the CD build log is a reliable way to detect that
<Kamion> pitti: yes
<seb128_> fabbione: maybe you can try to move /usr/share/autostart/*.desktop out of the way, but I don't think that's it ...
<Kamion> pitti: if that's the only change
* fabbione tries
* jsgotangco reboots
<ogra> Kamion, yup, understood ... i just have some problems handling w3m currently ... no direct connection to the DC from germany ... but i'll get there ...
<fabbione> seb128: no difference
<seb128_> so that's not that new feature
<seb128_> fabbione: do you have any user process still running from your first login without nfs?
<seb128_> like gconf, or orbit stuff
<fabbione> seb128: no, but i can test again
<fabbione> seb128: gonna try to reboot to be 100% sure
<fabbione> brb
<fabbione> seb128, dholbach: same story
<fabbione> even after a reboot
<seb128> it hangs on the splash?
<seb128> is "lo" correctly configured?
<seb128> doko: should #3074 be closed? several people stated it works fine for them now
<fabbione> seb128: yeah the load progress bar thingy.. splash
<fabbione> seb128: yup.. network is up
<fabbione> seb128: and configured properly
<fabbione> as i said before.. login using the local disk does work
<seb128> fabbione: maybe you can try to strace gnome-session to see what is it up to
<fabbione> as soon as i repluged my /home.. bam
<seb128> the stuff started by gnome-session are listed by /usr/share/gnome/default.session
<seb128> you may want to move update-notifer, vino, etc out of the way to be sure they are no to blame
<fabbione> seb128: *cough* there is no gnome-session ?
<fabbione> as a process i mean
<seb128> x-session-manager
<seb128> that's an alternative
<fabbione> it's just there waiting/doing nothing
<seb128> fabbione: blocked on what?
<fabbione> seb128: on nothing.. it's doing poll(
<fabbione> i assume a select( or something
<seb128> I tend to blame one of the stuff it tries starting
<seb128> next you can try to move update-notifier, etc as I said
<fabbione> seb128: i am alredy working on it :)
<seb128> you have nothing useful to ~/.xsession-error?
<seb128> GNOME put debug stuff to it
<fabbione> ahhh
<seb128> ?
<fabbione> don't you have anything in /query ?
<fabbione> it's gnome-panel
<fabbione> Unknown option --profile
<fabbione> testing one at a time..
<seb128> no
<seb128> but I got my nick back
<seb128> without the _
<seb128> and are you identified?
<fabbione> yup
<seb128> no query from you
<seb128> fabbione: do you have a ~/.gnome2/session* ?
<fabbione> seb128: checking...
<HiddenWolf> mvo, ping
<fabbione> seb128: yes, there is a session file..
<fabbione> let me guess.. move it out of the way :)
<seb128> yeah
<fabbione> and restore the original default.session
<fabbione> eh?
<seb128> I would have started by that
<fabbione> damn i feel clever :)
<seb128> but you said that's a stock install :p
<seb128> keep the stuff you move for debug purpose
<fabbione> seb128: yes and as i said i replugged my /home from the server :)
<fabbione> ok
<fabbione> now we start to talk the same language
<fabbione> but you can expect this kind of problems also on upgrades
<fabbione> note that i did never ever touched .gnome2/ manually...
<fabbione> brb from X
<seb128> re fabbione
<seb128> can you mail me or put the session somewhere? :)
<fabbione> meh.. brb (again)
<fabbione> sure.. in a second
<jordi> seb128: what's wrong about /var this year?
<jordi> last year, /etc was bad for asound.state
<fabbione> re
<seb128> jordi: /var not mounted when udev events arrives and alsa-utils is runned
<seb128> jordi: if you have a different partition for it ...
<seb128> jordi: keybuk fixed it by making alsa-utils waits until /var and /usr are mounted
<jordi> seb128: nod
<Kamion> using /var was ok before alsa-utils was run from udev
<Kamion> because it was run after partitions were mounted
<seb128> right
* pitti switches back to a sane X server, brb
<jordi> I see. I guess we want that patch in Debian as well.
<seb128> but now it's not since there is no point where we are sure the card is up
<Kamion> jordi: Debian doesn't run alsa-utils from udev yet does it? (although it would do no harm)
<fabbione> seb128: http://people.ubuntu.com/~fabbione/gnome2-session
<Kamion> I mean, the patch would do no harm
<seb128> fabbione: thank you :)
<seb128> vuntz: did panel use to have a --profile option?
<jordi> Kamion: yeah. We might want to merge with ubuntu entirely, I mean
<seb128> Kamion, mdz: could any of you accept nautilus 2.12.1-0ubuntu1.2? It fixes a crasher and is waiting for one month ...
<pitti> Kamion, mdz: ^ waiting in jackass' accepted/ for a while, does this need a re-upload to LP?
<doko> seb128: just checked on amd64, doesn't work for me
<Kamion> please don't go randomly reuploading stuff - all that stuff from jackass should be migrated over en-masse
<seb128> doko: oki
<Kamion> elmo: can we dump everything from jackass' queue/accepted that's targeted at breezy-updates into drescher's breezy unapproved queue somehow?
<Kinnison> Kamion: No, there's no such queue
<Kamion> is too
<Kamion> Listing ubuntu/breezy (UNAPPROVED) 2/2
<Kinnison> There's no queue which would accept binaries into -updates other than the buildds
<Kamion> at least some of them are only source uploads, including the one seb128 is requesting
<pitti> pitti@jackass:/srv/ftp.no-name-yet.com/queue/accepted $ grep 'breezy-updates;' *source.changes|wc -l
<pitti> 12
<pitti> there's a fair amount of unprocessed stuff
<Kamion> in fact, all of them are only source uploads
<Kinnison> the source uploads can just be punted at upload.ubuntu.com
<Kamion> shall I do that en-masse now, then?
<Kinnison> sure, it can't harm things I guess
<pitti> Kamion: please skip linux-source-2.6.12_2.6.12-9.24_source.changes:
<Kinnison> the binaries won't build until cprov has tested and deployed the changes to the buildd master
<Kamion> ok, let's get this over with in one go
<Kamion> linux-source-2.6.12       | 2.6.12-9.24       | source | 4 months old
<Kamion> germinate                 | 0.3.1             | source | 3 months old
<Kamion> gok                       | 1.0.5-1ubuntu5    | source | 3 months old
<Kamion> language-pack-kde-af      | 20051018          | source | 3 months old
<Kinnison> I believe he is aiming to deploy before the end of the day
<Kamion> language-pack-kde-af-base | 20051018          | source | 3 months old
<Kamion> evince                    | 0.4.0-0ubuntu4.1  | source | 2 months old
<Kamion> libgnome2-canvas-perl     | 1.002-1ubuntu0.1  | source | 2 months old
<Kamion> ubuntu-docs               | 5.10-7            | source | 2 months old
<Kamion> evms                      | 2.5.2-1ubuntu1.1  | source | 1 month old
<Kamion> gnome-python-extras       | 2.12.0-0ubuntu1.1 | source | 1 month old
<Kamion> totem                     | 1.2.0-0ubuntu3.1  | source | 1 month old
<Kamion> nautilus                  | 2.12.1-0ubuntu1.2 | source | 1 month old
<Kamion> any of those objectionable?
<pitti> as I said, linux-source
<pitti> it's superseded
<Kamion> then presumably it'll be rejected
<Kamion> (I'd rather there were a record of that)
<pitti> Kamion: no, please don't
<pitti> it would create a branch in breezy-updates
<Kamion> Kinnison: will soyuz reject breezy-updates < breezy-security?
<pitti> and we don't want to care for that branch
<Kamion> linux-source-2.6.12 | 2.6.12-9.23 |        breezy | source, all
<Kamion> linux-source-2.6.12 | 2.6.12-10.28 | breezy-security | source, all
<Kinnison> Kamion: no not currently
<Kinnison> Kamion: those rules haven't been taught to the policy engine yet
<pitti> Kamion: would also be nice to push xine-lib and evms for hoary-updates
<Kamion> don't seem to have a helena -m hoary
<pitti> $ grep 'hoary-updates;' *source.changes
<pitti> evms_2.5.1-1ubuntu4.1_source.changes: evms (2.5.1-1ubuntu4.1) hoary-updates; urgency=low
<pitti> xine-lib_1.0-1ubuntu3.4_source.changes: xine-lib (1.0-1ubuntu3.4) hoary-updates; urgency=low
<Kamion> I've punted all the breezy-updates uploads and moved them to ~katie/old-breezy-updates/
<Kamion> I'll wait to see how soyuz deals with those, and then punt the hoary-updates ones too
<Kamion> oh, er, crap
<Kamion> uploaded linux-source-2.6.12 by mistake
<Kamion> it'll land in unapproved though, I'll reject it
<Kamion> (assuming I can)
<Kamion> Kinnison: ?
<Kinnison> Kamion: should be able to
<Kinnison> queue -R breezy -Q unapproved reject <foo>
<Kamion> pitti: please note UVF exceptions in the changelog
<Kinnison> ogra: What did you think of that package?
<Kamion> Kinnison: can I not give a reason?
<Kinnison> Kamion: no, known bug, irritating eh?
<Kamion> just a bit
<Kamion> shall I file it?
<Kinnison> I think it's a known, but feel free to file it
<ogra> Kinnison, i had a 404 and you were gone already ...
<Kamion> ok, hoary-updates punted too
<ogra> can you send the url again ?
<Kinnison> ogra: You had a 404? 
<ogra> yes
<ogra> with the url you pasted
<Kinnison> with the second url I pasted?
<ogra> hmm, you pasted a second one ?
<Kinnison> 17:57 < Kinnison> ogra: so http://people.ubuntu.com/~dsilvers/gvm-nuv/
<Kinnison> 17:59 < ogra> Kinnison, err, 404
<Kinnison> 18:00 < Kinnison> http://people.ubuntu.com/~dsilvers/gpm-nuv/
<Kinnison> 18:00 < Kinnison> sorry
<ogra> ouch, missed ... i was a bit sidetracked yesterday, sorry
<Kinnison> heh, fair enough
<Kinnison> no biggy
<ogra> so you left the lid action ?
<ogra> ahh
<ogra> (sorry just saw the second line :) )
<ogra> Kinnison, i still disagree about gss, but you two overruled me, so lets go with that ... want me to do a test 
<ogra> ?
<Kinnison> ogra: please
<pitti> Kamion: ok, will do next time, sorry
<tepsipakki> Kamion: have you had time to review #29646?
<tepsipakki> malone 29646
<Ubugtu> malone bug 29646 in apt-setup "support for multiverse" [Normal,Unconfirmed]  http://launchpad.net/bugs/29646
<Kamion> tepsipakki: not yet, sorry, I've marked it as targeted for dapper so I remember
<tepsipakki> Kamion: ok, good to hear
<WaterSevenUb> kamion, F2 selection of Pt & pt_Br patches working great, thank you. Other thing now, if you select Portuguese (or other language) via F2 key, the language is not passing to, for example, "cdrom-checker" (I guess). Should I file a bug against what pkg?
<Kamion> WaterSevenUb: do you mean the "check CD-ROM integrity" boot option?
<Kamion> glad to hear my fixes worked
<WaterSevenUb> kamion, yes
<Kamion> WaterSevenUb: bug against cdrom-checker then, please
<Kamion> WaterSevenUb: (please use the "mark as duplicate" thing when you find a duplicate bug rather than adding a comment)
<WaterSevenUb> kamion, I didn't know I had permissions to do that. I will from now on.
<WaterSevenUb> kamion, plus, I don't know where the bug is correctly filed:)
<Kamion> well, assuming you have permissions to do so anyway
<Kamion> more specific's usually better - plus if I file an installer bug it's normally in the right place :-)
<WaterSevenUb> kamion, eheh:)
<slomo> Kamion: please remove banshee from NEW... it's currently on NEW because i splitted off one plugin to another binary package and the current version in the archives can destroy ipods under certain circumstances :/
<ogra> Kinnison, i have no lid option at all in gpm ...
<Seveas> WaterSevenUb, everyone has permission to edit bugs - I really miss the editbugs privilege thing bugzilla had - users like to make a mess out of their own bugs..
<Kinnison> ogra: nothing at all?
<tseng> infinity: can you please give back ikvm on ppc
<ogra> Kinnison, nope
<Kinnison> ogra: bizarre
<tseng> infinity: also poke depwait for gmime2.1, beagle, banshee, evolution-sharp .. beagle build-deps on gmime2.1 so it might need kicked twice, not sure how that works
<Kinnison> ogra: if it doesn't show the lid combo then hal thinks you don't have a lid button
<ogra> Kinnison, it thought that before i upgraded to your new package :)
<Kinnison> I'm just upgrading my laptop, once it's done I'll compare the code between the old and new for the prefs screen
<ogra> Kinnison, and the device manager shows a lid button
<Kinnison> interesting
<ogra> that cant be it
<tepsipakki> seb128: is there anything anymore that calls gnome-session-save directly? Gnome-panel seems to have it's own logout-dialog nowadays..
<seb128> tepsipakki: no
<tepsipakki> seb128: that's great, because I made a simple patch that finally fixes gnome-session-save (it presented a gui, always)
<Kinnison> ogra: why do you say that?
<seb128> tepsipakki: you don't want to present a gui always for it
<tepsipakki> seb128: yes, but it used to do just that =)
<seb128> no
<ogra> Kinnison, if hal device manager shows me a lid button it cant be hals fault
<tepsipakki> seb128: I mean, now it shows the gui when you run gnome-session-save --kill, with or without --gui
<tepsipakki> seb128: with my patch it shows it only if --gui is set
<seb128> I'll not accept a such patch
<seb128> it should not show the gui without --gui
<tepsipakki> that's what I'm fixing =)
<seb128> ah, good
<tepsipakki> wait a sec
<seb128> I'm not sure anyone use gnome-session-save anyway
<Kinnison> ogra: Oh right
<tepsipakki> it's useful for gnome-screensaver
<seb128> and gnome-session API has some function that do the job without open a dialog
<tseng> infinity: er.. njb-sharp has to be kicked from binary NEW first for banshee
<seb128> tepsipakki: gnome-screensaver should use the C API and not do a system call to gnome-session-save
<seb128> like gnome-panel
<tepsipakki> seb128: there's a bug open on launchpad, I'll comment there
<Kinnison> ogra: I'm just rebooting post-upgrade and then I'll prod about in the source
<seb128> tepsipakki: thank you
<Kinnison> ogra: the reason it's odd is because I have a lid button too and it displays for me
<ogra> hum
* Kinnison is gonna verify the mechanisms are the same between the two UVs
<ogra> whee ... big rant on the g-s-s mailing list ...
<Kinnison> ogra: so the version in the archive and this new version decide in exactly the same way whether or not you have a lid button
<ogra> thats weird
<Kinnison> In fact I'd go so far as to say that the code is unchanged
<ogra> hmm ... the UI is translated now ... might be that it doesnt show untranslated strings 
<ogra> but that would be even more odd
<Kinnison> the widgets should be present
<ogra> yup
<Kinnison> check in gconf-editor that your lid action isn't set to "lock"
<Kinnison> because that doesn't exist any more and could be confusing things
<ogra> ahhh
<ogra> ok
<ogra> that will be it ...
<Kinnison> change action_button_lid to 'nothing' and try again
<ogra> i just wiped the g-p-m user config 
<ogra> hmm ...
<ogra> button_lid is set to suspend by default and still doesnt show up ...
<ogra> even with "nothing" it doesnt appear
<Kinnison> okay that's very odd
<Kinnison> can you screenshot the bit of devicemanager showing your lid button and dump the png on p.u.c?
<janimo> anybody knows when is anastacia back so promotions can be done?
<mjg59> How about just using hal-device rather than hal-device-manager?
<mjg59> Then you can just pastebin it...
<Kinnison> mjg59: mostly because I have no clue about the UDI of a lid on an ibook :-)
<ogra> http://pastebin.com/559326
<ogra> but i can look it up :)
<Kinnison> ta
<Kinnison> what UI does it show?
<ogra> ??
<ogra> can you elaborate ?
<Kinnison> can you screenshot each of the first two panes and dump the pngs on p.u.c ?
<ogra> of the power management settings ? 
<Kinnison> yes
<Kinnison> just the first two
<ogra> Kinnison, http://people.ubuntu.com/~ogra/gpm1.png http://people.ubuntu.com/~ogra/gpm2.png
<Kinnison> "Wenn der laptop geschlossen wird" == "when the laptop wants to be suspended"?
<ogra> nope 
<ogra> when the lid is shut
<Kinnison> so how is that not the lid action dropdown?
<ogra> thats the lid action dropdown ... activated
<Kinnison> yes, looks right to me
<ogra> but there is no lock option as you can see
<Kinnison> indeed not
<Kinnison> look at the changelog
<ogra> thats not how i undestood it ...
<ogra> so i have to repoen the sabdfl bug :(
<mjg59> ogra: ?
<mjg59> The screen now locks if the locks screen toggle is set in g-s-s
<ogra> https://launchpad.net/distros/ubuntu/+source/gnome-screensaver/+bug/29881
<Ubugtu> malone bug 29881 in gnome-screensaver "Closing the lid should lock the screen if locking is activated in gnome-screensaver" [Normal,Fix released]  
<mjg59> ogra: That's what it does
<mjg59> If it doesn't, that's a bug
<ogra> it doesnt if i'm on AC and i cant select it at all 
<Kinnison> there's no option for it
<mjg59> Why would you need to select it?
<Kinnison> it's hardcoded in the code
<mjg59> Kinnison: It should be doing it on ac, though
<Kinnison> mjg59: it bloody well does on my laptop
<ogra> it doesnt here
* Kinnison literally just demonstrated it to himself
* ogra as well 
<mjg59> ogra: And on battery? (With sleep disabled)
<Kinnison> ogra: I'm going to ask a very silly question now...
<ogra> nope
<Kinnison> ogra: did you kill the old gnome-power-manager binary and run the new one?
<ogra> yup
<ogra> thats why you see everything translated ...
<ogra> the old one was english only
<Kinnison> that's gnome-power-preferences
<Kinnison> not gnome-power-manager
<ogra> i killed that as well 
<Kinnison> humour me and kill it again
<Kinnison> just in case
<ogra> ah, damned ... locking wasnt checked in gss
<ogra> thats confusing as hell 
<ogra> if i activate it in gss, it works with "do nothing" on ac and battery
<ogra> so users have to jump around the different UIs ... :/
<mjg59> ogra: That's correct behaviour
<Kinnison> which is the expected behaviour
<ogra> yup :(
<mjg59> It's a screensaver setting, not a power setting
<Kinnison> ogra: the idea is to make it look like g-s-s is locking on lid close
<Kinnison> without having to make g-s-s listen to hal etc
<ogra> i understand ... i just dont like it ...
<ogra> but it works apparently ...
<sivang> hi all
<Kinnison> ogra: thanks for testing
<Kinnison> for a UVF exception, should I put something like "UVF Exception granted by Colin Watson" in the changelog?
<sivang> hmm, Scott not around? I have soem annoying problem with udevd on -15 , on ocassional boots on this laptop (inspiron 8200) boot process stops "Cannot kill /usr/sbin/udevd" and halts
<ogra> just upload, he granted it and he has to wave it through the queue anyway
<ogra> so he'll already know about it ;)
<sivang> hey pitti_ 
<pitti_> hi sivang
<sivang> pitti_: any news about the new hal?
<pitti_> grmpf network
<sivang> :-)
<pitti> sivang: 0.5.7 was not yet released
<pitti> sivang: and I didn't get to extract your patch yet
<pitti> or do you have it handy somewhere?
<mjg59> Kinnison: g-p-m needs to ignore a power button event if it comes immediately after resume
<sivang> pitti: I will extract it today then, and send you by email
<fabbione> Kinnison: yes.. according to mdz it's better to add who gave permission for UVF breakage
<Kinnison> mjg59: I need to work out if it's g-p-m which should be doing that, or hal
<Kinnison> personally I think it ought to be hal
<Kinnison> but it may be easier to do in g-p-m
<mjg59> Kinnison: I think hal probably ought to report what it gets
<mjg59> But yes, I see your point
<Kinnison> basically I think hal should be swallowing the spurious power event like we had acpid do
<Kinnison> but since I've never hacked on hal I don't know how easy it'd be to do
<pitti> sivang: maybe you can already apply it against the current dapper version to check whether it works
<lemsto> when i launch a program, the window is never on top of the others?! is it a bug or a bad configuration i made?
<sivang> pitti: this is what I will do first, yes
<pitti> great, thanks
<sivang> pitti: if ti works for me I'll send to you for review
<sivang> pitti: np , will be my pleasure :)
* sivang grumpfs at bzr's slowness
<viviersf> infinity, ping
<infinity> viviersf: pong... ish.
<viviersf> lol
<viviersf> hello
<viviersf> infinity,  got 5 mins to help with initramfs stuffs ?
<infinity> If it's really just 5 minutes.  I'm trying (without much success, obviously) to not work this weekend. :)
<viviersf> heh
<viviersf> i know the feeling
<viviersf> i built the initramfs like you said
<viviersf> renamed it to gz
<viviersf> so when i boot the cd
<viviersf> i get an error : /dev/ram does not exist 
<viviersf> the initrd is skrewed by the look of it
<infinity> Or your isolinux setup it confused.
<viviersf> using the isolinux setup from a ubuntu live cd
<infinity> You might try seeing if Mithrandir has some spare moments, since he actually BOOTS lvecds, I just build the filesystem. ;)
<viviersf> kk
<viviersf> Mithrandir = tollef ?
<Mithrandir> viviersf: 'sup?
<Mithrandir> yes
<Mithrandir> I am
<viviersf> kewl kewl
<infinity> I can tell you that what we do, though, is copy out the vmlinuz and initrd from the installed filesystem (which I build more or less in the fashion I instructed you), then Kamion/Mithrandir work magic to make that kernel/initrd pair boot.
<viviersf> Mithrandir, im trying to build an impi live system for dapper
<viviersf> i built everything 
<viviersf> but it wont boot
<Mithrandir> are you passing boot=casper on the kernel command line?
<viviersf> im rebuilding the iso quick
<viviersf> i think that was the problem 
<viviersf> ok thx Mirv 
<viviersf> * Mithrandir 
<viviersf> it fixed the problem
<seb128> mdz: 
<seb128> <CIA-1> behdad * vte/ (ChangeLog src/vte.c): 
<seb128> <CIA-1> * src/vte.c: Make shift+insert paste PRIMARY and ctrl+shift+insert
<seb128> will make you happy :)
<Mithrandir> viviersf: for testing, you might want to just put your casper/ on a vfat volume, it'll be a fair bit quicker than burning DVDs all the time.
<Treenaks> seb128: \o/
<viviersf> Mithrandir, i was using qemu
<viviersf> its jut slow
<viviersf> what you meen on a vfat system ?
<Mithrandir> vfat as in FAT file system
<Mithrandir> viviersf: I'm going to redo how live images are built early next week, so you might want to watch out when the next casper lands.
<viviersf> i know what vfat is
<viviersf> Mithrandir, i will
<seb128> fabbione, infinity, pitti: should /usr/bin/X be setuid?
<seb128> it's not at, and startx doesn't work due to that
<fabbione> seb128: hold on a sec...
<seb128> "X: unable to open wrapper config file /etc/X11/Xwrapper.config
<seb128> Xof: user not authorized to run the X server, aborting
<pitti> seb128: no, it shouldn't
<seb128> Xof: sorry, auto completion ...
<seb128> should be "X:"
<ogra> pitti, it was in breezy 
<fabbione> seb128: yes it should
<seb128> pitti: it used to be though
<fabbione> seb128: if you have a fix go ahead and upload
<pitti> why does it need to be?
<seb128> fabbione: no, but I've just fixed an another xinit issue, I'll do that one as well
<fabbione> pitti: because X access * 
<seb128> pitti: read what I just copied?
<fabbione> and needs root to read from /dev/kmem or something
<fabbione> seb128: yes i saw your upload.
<pitti> well, it's usually started by the root user
<pitti> and it works fine here without setuid
<fabbione> pitti: yes but you can also start it as "user"
<pitti> (not that I would have touched it)
<seb128> pitti: startx works for you?
<seb128> gdm works for me, but not startx
<pitti> startx won't probably
<fabbione> pitti: startx ..
<seb128> don't ask why ...
<pitti> seb128: gdm runs as root
<seb128> good point
<seb128> pitti: we can't let startx broken though
* sivang reboots to see if changes fixed sound problem
<seb128> if you have a better idea than the setuid let me know
<pitti> if it was setuid before, it's probably fine
<seb128> it was yep
<seb128> k, thank you
<pitti> I wasn't aware of it at all
<fabbione> pitti: yes it was and it should be
* pitti doesn't use startx
<fabbione> pitti: slaker :)
<pitti> fabbione: I need to test gdm for stability :)
<fabbione> pitti: i already do it on 6 arches.. go back to startx .. no excuses :P
<seb128> next question for you guys ... should xvfb Depends on xauth?
<fabbione> no idea :)
<seb128> k, I'll do the change, if somebody disagree feel free to revert
<seb128> it has a:
<seb128> "if ! which xauth >/dev/null; then
<seb128>     error "xauth command not found"
<seb128>     exit 3
<seb128> fi"
<seb128> which breaks pygtk build atm
<seb128> so I take the easy way and put it as a Depends for now
<ogra> sounds reasonable
<fabbione> seb128: works for me
<ogra> *sigh* 
* ogra twiddles thumbs waiting for edubuntu-meta ...
<BenC> should I be concerned about launchpad sending me an upload confirmation for linux-source-2.6.12-9.24 that I uploaded 4 months ago?
<dholbach> something to -updates?
<sivang> does anyone  have idea about why I have no sound events sound on the desktop? everything else works just fine, including playing media etc. has anything changed in sound support in metacity possibly?
<BenC> yeah
<pitti> BenC: yes, it was re-uploaded to launchpad accidentially, and rejected (I hope)
<BenC> pitti: it said ACCEPTED
<pitti> BenC: it just sat in accepted/ forever, since it was superseded by a security update
<Riddell> Kamion: what's the status of flight 4?
<BenC> ah, ok
<pitti> Kamion, could you reject that LP upload of the ancient b-updates kernel?
<dholbach> sivang: metacity?
<dholbach> sivang: what does system -> preferences -> audio say?
<sivang> dholbach: I don't have audio.
<dholbach> sivang: nothing there to configure sound?
<sivang> dholbach: In sound , there's a V for ESD, and V for "play system sounds"
<dholbach> do you have esd? is it running?
* sivang checks
<sivang> dholbach: I have polyaudio instead :)
<sivang> dholbach: but I can't see esd running
<sivang> dholbach: should I install esd instead ?
<sivang> ( only have -common pkg for esd)
<pitti> sivang: ditch polypaudio
<pitti> sivang: ditch esd as well if you don't need it :)
<sivang> pitti: I must use it , it's a soft-card :-/ (82801CA/CAM AC'97 audio controller)
<pitti> hm?
* sivang distech polyaudio
<pitti> polypaudio/esd doesn't have any drivers
<sivang> pitti: the sound card doesn't do multiplexing on it's own
<sivang> pitti: it used to do it with esd, though.
<pitti> sivang: and alsa dmix doesn't work?
<pitti> sivang: anyway, current dapper tries alsa dmix, and if that doesn't work, falls back to esd
<sivang> pitti: okay, for some reason I don't have dmix installed. I will loose both esd and poly and install it manually.
<pitti> sivang: you don't need to 'install' dmix
<pitti> sivang: it's a module in the alsa lib that is automatically used on cards where it's known to work
<pitti> sivang: please try:
<pitti> aplay /usr/share/sounds/login.wav
<pitti> wait a second
<pitti> erm
<pitti> again
<pitti> aplay /usr/share/sounds/login.wav &
<pitti> wait a second
<pitti> aplay /usr/share/sounds/login.wav
<pitti> sivang: if you hear both sounds at the same time, dmix works for you
* sivang tries
<sivang> works ! :)
<sivang> how come polyaudio wasn't removed when I dist-upgrade to dapper?
<ogra> polypaudion was never used officially ...
<sivang> ah, okay. then my bad, I probably intalled it manually
<ogra> it was switched back to esd very early during breezy development
<ogra> even it once was a dependency of -desktop for a short period
<sivang> still , I don't recall that I Installed it manually, though so that is why I wondered.
<ogra> it might be pulled in by the mentioned -desktop dependency 
<ogra> gah ... still no edubuntu-meta on the builds page ... 1.5h since i uploaded :(
<sivang> maybe. 
<sivang> pitti: hrm, trying to remove esound-common wants to take half my desktop down...
* ogra sses another nightshift to get flight4 ready ...
<ogra> *sigh*
<tseng> yay flight4
<pitti> sivang: no, you need -common
<pitti> sivang: you can even leave esound installed, it'll not be used if dmix works
<ogra> tseng, :(
<tseng> ogra: *hugs*
<sivang> pitti: k, cool. can also leave the "sound" props to "enable sound software mixing" ?
<pitti> yes, it'll be a no-op for most users now
<Keybuk> pitti: did you get a chance to play with the new n-m packages?  http://people.ubuntu.com/~scott/network-manager/
<viviersf> Mithrandir, ping
<pitti> Keybuk: sorry, not yet, swamped in security stuff
<Keybuk> that's ok
<Keybuk> seb128: did you yet?
<sivang> Keybuk: I've been hacing occasional "Cannot kill /usr/sbin/udevd" halts, known?
<Mithrandir> viviersf: yes?
<pitti> Keybuk: I'll try it on my laptop; let's see how long it lasts without oopsing my kernel :)
<Keybuk> sivang: no, not known
<sivang> Keybuk: that's only on this laptop (dell lappie, bad acpi machine by design)
<viviersf> Mithrandir, wouldnt it be possible in casper, to make the autologin use another method for choosing between kde and gnome
<sivang> Keybuk: when I re-reboot, it goes away, until next time.
<mjg59> sivang: What machine?
<Mithrandir> viviersf: you don't have input, so you'd need to do it from the bootloader.
<viviersf> yeah
<Keybuk> sivang: what is trying to kill udevd?!
<viviersf> Mithrandir, ok nm i still got a problem, that wont help
<viviersf> Mithrandir, we gonna use gdm, but i need a way to let gdm choose gnome or kde :(
<Mithrandir> viviersf: don't use autologin, then?
<viviersf> Mithrandir, i know heh but casper does auto login
<Mithrandir> viviersf: change casper, then?
<ogra> nah, change the alternative for x-session-manager 
<viviersf> ogra, good idea :P
<ogra> gdm will pick up the default
* ogra curses the launchpad buildds
<Kinnison> ogra: Curse the build queue builder
<Kinnison> it's taking far too long
<ogra> Kinnison, yes :(
* Kinnison is prodding gently at it right now to see if he can work out why
<ogra> 3h for a package from upload to archive best case ... i've also had longer ones 
<jsgotangco> ogra, wha?
<jsgotangco> get a plane to london :D
<ogra> thats really hard for flight preparation ... my nerves are starting to make noises from being strain ..
<Kinnison> ogra: I agree
<Kinnison> ogra: It should be building stuff now
<ogra> jsgotangco, this change is even more trivial than the one that kept me up until 5am last night 
<jsgotangco> arghhh
<ogra> Kinnison, thanks a lot
<Kinnison> ogra: I agree that the delays are seriously unacceptable
<ogra> Kinnison, mdz said its a trade for reliability ... i'm fine with that as long as my next workstep doesnt depend on the package ...
<Kinnison> ogra: aye
<ogra> i prefer a reliable system :)
<seb128> Keybuk: I installed on my box, but it's not really an interesting configuration for it (2 wired eth, no wireless card)
<seb128> Keybuk: it doesn't overwrite the resolv.conf by a blank one and let the interface correctly configured (which was not the case of the previous version)
<seb128> Keybuk: but clicking on it doesn't list any connection, where the previous one was listed my 2 eth config (on greyed because no cable connected probably and the active one)
<seb128> Keybuk: the .desktop for autostartup works fine too
<HiddenWolf> guys, did evolution recently stop autocompleting email adresses?
<seb128> HiddenWolf: not for me
<HiddenWolf> seb128: odd
<HiddenWolf> seb128: It's also only showing a partial list of my contact book when I press "to"
<seb128> seems your contacts list is broken so
<Kaloz> seems like the guy who added that ubuntu splash thing to dapper forgot about smart people who have a seaparate /boot
<Kaloz> :p
<seb128> Kaloz: that guy is mvo and he's not working today so probably something you should put on launchpad :)
<Kaloz> :)
<Kaloz> well, you know i didn't want to submit a ticket about it
<Kaloz> imho there are at least 100 other people who will do so :)
<HiddenWolf> seb128: right, it's only not completing for some adresses. :/
<seb128> I'm not sure so many people have a separate /boot actually but yeah, you can wait on it
<ogra> Kaloz, thats great, so they can find yours and follow up
<seb128> HiddenWolf: special chars to those?
<ogra> Kaloz, just go ahead
<HiddenWolf> seb128: most exotic is an underscore, 
* Kaloz has to admin he isn't used to launchpad :p 
<Kaloz> i check it
<ogra> Kaloz, http://launchpad.net/distros/ubuntu/dapper/+bugs
<HiddenWolf> seb128: one of the broken ones is souljar777@domain.com
<sivang> mjg59: Dell Inspiron 8200
* sivang is just back after a couple of failing grub boots. maybe the disk is dying...
<mjg59> sivang: Ah. Reasonably old?
<sivang> mjg59: sort 'o, 3 years at least
<sivang> (maybe some more)
<mjg59> Ok
<HiddenWolf> seb128: opening and saving the contacts did the trick, probably just a glitch.
<seb128> k
<HiddenWolf> seb128: can you patch rhythmbox with the fix for http://bugzilla.gnome.org/show_bug.cgi?id=330784 
<Ubugtu> gnome2 bug 330784 in User Interface "Notification bubble shows empty" [Trivial,Resolved: fixed]  
<sivang> pitti: I can't hear system events still, I have ditched polypaudio and done the dmix test again
<seb128> HiddenWolf: it's already filled to launchpad and I've already commented and putting it as dapper target
<HiddenWolf> must've missed that. You're a hero. :)
<seb128> np ;)
* ogra dances wildly 
<ogra> http://cdimage.ubuntu.com/edubuntu/daily/20060217.2/report.html
<ogra> finally its empty 
<Treenaks> ogra: that means it's beer o'clock! ;)
<ogra> Treenaks, far from that, now i need to rsync and run a full test .... for all arches
<Treenaks> ogra: good luck then
<ogra> but the idly waiting is over ...
* Mithrandir guesses he should wait until next week before uploading the new casper shiny.
<Mithrandir> modular live cd, anyone? :-)
<ogra> Mithrandir, if my tests show no regression i have my flight4 now ... give me 1-2h for the live tests... i think ubuntu and kubuntu were fine already for flight 
<Mithrandir> ogra: this might not be dapper material at all, I'll need to chat with mdz.
<ogra> oooh, ok
<infinity> Mithrandir: We'll need mangling of the buildds anyway, so...
<Mithrandir> infinity: yup
<Mithrandir> infinity: that too.
<Mithrandir> infinity: and I'm not sure if mdz is confident about unionfs and squashfs yet or not.
<ogra> i left unionfs out of ltsp for dapper ... even it highly desired ...
<ogra> but i'm a sissy
<Kaloz> hmz.. still waiting for the registration mail :p
<Kaloz> sometime si hate the fact that i need to greylist :p
<infinity> Well, ltsp and the livecd have drastically different target audiences, too.
<Mithrandir> ogra: it's needed for live cds, but you probably know that already.
<Mithrandir> that too
<infinity> Most people don't expect a livecd (at least, not our desktop-oriented livecd) to be up and running for days/weeks at a time.
<ogra> Mithrandir, yes and it would improve the situation of ltsp clients a lot as well
<ogra> Mithrandir, my fs is also readonly ...
<infinity> So if it's not rock solid, it may not be the end of the world for a livecd, but could suck for ltsp.
<ogra> and i mount a ton on top to be rw ... the mount command fills more than page on the console
<Kamion> 12:19 < ogra> just upload, he granted it and he has to wave it through the queue anyway
<Kamion> ogra: if you don't know the answer to a question authoritatively, I'd really prefer if you didn't answer
<Kamion> ogra: especially when mdz said the exact opposite last night, and I'd said the exact opposite this morning
<ogra> Kamion, ok
<Kamion> Kinnison: in general, please mention in the changelog that a UVF exception has been granted, so that people are aware of the workflow
<Kamion> you don't have to say whom by
<Kamion> (unless you care)
<Kamion> Ubuntu and Kubuntu need rebuilds before Flight 4; I'll work on that shortly
* Kinnison put "* UVF Exception granted by Colin Watson" in his changelog
<Kamion> thanks
<hunger> How can I stop g-p-m from offering the hibernate option?
<Kinnison> hunger: I've been looking into that
<Kinnison> hunger: Why should it not display it?
<hunger> Kinnison: Because my laptop has no swap partition it can use to hibernate.
<Kinnison> that's a good reason
<hunger> Kinnison: It does have a swap partition, it just is not suitable for hibernation:-)
<fabbione> hunger: well.. just don't use it :)
<Kinnison> hunger: so g-p-m only presents the choice of hibernation if hal says that the laptop can hibernate to disk
<Kinnison> hunger: so what we need to do is make hal not claim that in your case
<mjr> 35
<hunger> fabbione: I won't... if I do not accidentally hit that button;-)
<fabbione> hunger: ehehe
* hunger is afraid of useful icons next to certain-doom icons.
<hunger> Kinnison: So how can I get hal to not make such a bold claim?
<Kinnison> hunger: Right, that's the question
<ogra> gpm has a commandline option to supress the actions in the menu 
<ogra> but that wont prevent them from showing up in the preferences
<Kinnison> hunger: if we can work out how to determine if the machine can hibernate, we can somehow feed that info to hal
<Kinnison> hunger: then gpm won't display the options
<Kinnison> hunger: So what we need is a programmatic way to determine if hibernation should be possible
<hunger> Kinnison: There is a swap partition that probably looks suitable to hal... 
<Kinnison> hunger: hmm
<hunger> Kinnison: And this laptop is supposed to be able to hibernate... it is just that the swap is encrypted and so the wakeup fails.
<Kinnison> hunger: aye
<Kinnison> hunger: Give me a few mins to ponder
<infinity> There must be a away to determine at runtime that the swap is encrypted, no?
<hunger> Kinnison: The pragmatic way would be to have a gconf key or something:-)
<Kinnison> infinity: Well, you'd think so
<Kinnison> infinity: so what I'd do is write a little tool for hal which let hal guess if hibernation was likely to succeed and change the can_suspend_to_disk to false if it think it would fail
<hunger> Kinnison: A encrypted swap does not necessarily break hibernation...
<Kinnison> hunger: I was thinking of checking /etc/default/acpi-support
<ogra> Kinnison++
<infinity> Which should be done anyway...
<Kinnison> infinity: aye, but hal currently doesn't
<hunger> Kinnison: Good idea!
<hunger> Kinnison: Ooops... I had hibernate set to true in there since the last update. Maybe that was causing this. Let me check.
<infinity> hunger: What do we need to get your swap to actually work for hibernation?  Do I need snazzy support for your encrypted swap in the initramfs?
<ogra> infinity, size ...
<infinity> ogra: No, hal should already be checking swap size.
<ogra> ah
<ogra> thats new then 
<infinity> Note the "should"
<ogra> heh
<infinity> Kinnison: Care to double-check that while you're diving in? :)
<Kinnison> infinity: hmm?
<infinity> Kinnison: Have hal check swap size against RAM size and make sure there's enough swap to enable hibernation.
<hunger> Kinnison: Hibernate is still listed by hal.
<ogra> i had a patch to hal that checked /proc/meminfo, but i moved that functionallity into hwdb-client in breezy
<infinity> Kinnison: So, even if the user says "yes, I'd love to hibernate!" in default/acpi-support, we can tell them to piss off cause it won't work.
<hunger> Kinnison: Make that RAM size + display memory.
<ogra> since it was a PITA to apply it over and over 
<mjg59> Display memory?
<mjg59> That doesn't get saved
<mjg59> On average, hibernation will require less swap than you have RAM, but it's not hugely predictable
<mjg59> When we shift to doing stuff in userspace, this ought to get more managable
<Seveas> mjg59, I have 512 ram and 512 swap - If i try to hibernate with OO.o open it runs out of space. OO.o is hell...
<Kinnison> Seveas: this doesn't crash though right? Just returns you to the desktop having tried?
<Seveas> it crashes
<Seveas> hard lockup
<Seveas> (but this is breezy)
<Kinnison> Hmm
<Kamion> BenC: yeah, I didn't mean to have the linux-source-2.6.12 upload land in soyuz' breezy-updates unapproved queue, but it does no harm as long as it's unapproved
<Kamion> BenC: I'll reject it in a moment, as long as you don't mind the reject coming without a reason
<BenC> Kamion: ok
<Kamion> done
<Kamion> Riddell: I'm rebuilding images to pick up the base-installer change I made earlier today, which fixes conffile prompts along with infinity's initramfs-tools; don't really want to release images without that
<Kamion> or rather with only half of that
<Kamion> edubuntu's already up-to-date on that I think
<Kamion> please test the current Ubuntu images; those are Flight 4 candidates
<Kamion> Riddell: also, this Kubuntu rebuild should fix your oversizing, since I removed some language packs
<BenC> Kamion: nah, reject away
* seb128 kicks jordi
<Riddell> Kamion: ok, thanks
<Kinnison> Can anyone see if there's a good reason why powermanagement-interface's depends doesn't include the shlib depends for gdm-signal?
<Kamion> Riddell: kubuntu install rebuilt, don't *think* I need to rebuild live as well but let me know (and/or do it yourself) if you do
<Riddell> Kamion: ok, I'll test those now
<Riddell> Kamion: how would I know if the live CDs needed rebuilding?
<Kamion> Riddell: if they don't work? :-) or if there have been important changes on dapper-changes since the live filesystem was built
<Kamion> the latter's how I normally tell anyway
<Riddell> ok
<Kamion> from a brief glance, you're probably ok
<Kamion> seb128: why would I get a padlock icon above and to the right of the "Install System Permanently" icon on live CDs?
<Kinnison> is pitti not around today?
<Kamion> (which is ~/Desktop/espresso-gtkui.desktop)
<jpatrick> Kamion: not ready yet?
<Kamion> jpatrick: hmm?
<jpatrick> never mind
<seb128> Kamion: because the file is read-only?
<Kamion> ah, it's owned by root
<Kamion> thanks
<seb128> np
<Kamion> Mithrandir: please merge http://people.ubuntu.com/~cjwatson/bzr/casper/espresso-desktop/ yet again to fix the above (no hurry to upload, though)
<flujan> hi guys, I need a backport of the xorg 6.9 or 7.0. I have a intel 915M laptop and need 1280*800 configuration. 
<flujan> is there such back-port?
<flujan> hello?
<Kamion> I think it's unlikely, since it's such a huge task
<Kamion> but you could try #ubuntu-backports (at least I think that channel exists)
<lakin> What is the package in dapper which provides the popup-notification about low-disk space on my home partition?
<Kamion> or https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
<Mez> Kamion, the list is always the best :D
<Mez> because noones in the channel
<Mez> flujan, theres no way we're going to be able to backport X.org
<flujan> hum... so I need to wait dapper if I want a stable system?
<flujan> :(
<Kamion> it'd probably be a mistake to backport anyway - we're still fixing stuff up in dapper due to the /usr/X11R6 -> /usr move
<fabbione> flujan: yes, you will have to wait.
<fabbione> it's only 2 months away...
<ogra> Kamion, for some obscure reason edubuntu-server doesnt get installed
<ogra> (on  edubuntu install)
<Kamion> which boot option?
<ogra> default
<ogra> preseed seems ok 
<Kamion> put /var/log/installer/syslog somewhere I can see?
<ogra> i'm just doing a i386 install, to investigaet more ... funnily ltsp-server is there ...
<Kamion> the syslog will be sufficient, probably
<ogra> wait a sec, i can only get the ppc file
<Kamion> that'll do
<Kinnison> hunger: ping
<ogra_> grmbl
<Kinnison> hey ogra_ 
<Kinnison> ogra_: I have a patch for the hal package which uses the pmi tool to query the capabilities according to userspace and sets the power_management.can_suspend_to_* appropriately
<Kinnison> http://people.ubuntu.com/~dsilvers/pmi-support.diff
<dilinger> how are you supposed to hibernate in dapper?
<Kinnison> what do you think?
<Kinnison> dilinger: pretty much the same as before I though
<dilinger> Kinnison: seems the gnome logout page has changed
<dilinger> there's suspend but no hibernate
<Kinnison> dilinger: right-click on the battery icon -- there should be hibernate there
<Kinnison> dilinger: gnome-power-manager can trigger a hibernate
<dilinger> nope
<Kinnison> perhaps your system doesn't believe it *can* hibernate
<Kinnison> load the device manager and look for power_management.can_suspend_to_disk
<dilinger> what's odd is that from gdm, there's a hibernate option
<ogra_> Kinnison, neato ...
<dilinger> but it just ignores me when i click it :)
<ogra_> thats really small :)
<Kinnison> ogra_: yeah, the next stage is to get powermanagement-interface to be more reliable about what it claims for suspend/hibernate
<Kinnison> ogra_: but I think that's pretty much the right patch for hal
<Kinnison> ogra_: It used to be smaller and not need an additional script, but then I realised that hal's privsep meant I couldn't query pmi from the right part of hal
<ogra_> Kamion, http://people.ubuntu.com/~ogra/syslog
<Kamion> ogra_: (weird that you still have a busted locale there)
<ogra_> Kamion, german installer, no german langpack on the CD 
<ogra_> it persists over all flights so far ...
<Kamion> no Task: edubuntu-server on the CD
<Kamion> the package is there but task names aren't generated
<Kamion> my bug
<ogra_> ah, k
<ogra_> i can live with it for flight 4
<ogra_> since i'm really happy that ppc is the first time installable :) 
<ogra_> Kinnison, i'd say add it ... but you should talk to pitti additionally, he's the hal master
<Kinnison> ogra_: I think I'll mail pitti
<ogra_> yup ... he'll unlikely come back this evening
<Kamion> I don't get it though, the override file is fine
<Kamion> oh, SMEG
<Kamion> forgot to update debian-cd for the scratch directory rearrangement
<Kamion> ogra: 17:20 < Kamion> oh, SMEG
<Kamion> 17:20 < Kamion> forgot to update debian-cd for the scratch directory rearrangement
<Kamion> ogra: thanks for letting me know, this affects all derivatives and requires a rebuild
<ogra> oki ... tell me if i can trigger one 
<Kamion> no, I'll trigger them all en-masse
<ogra> oki
<kagou> hi
<ogra> Kamion, apart from that all arches install images are fine 
<ogra> (edubuntu)
<Kamion> mm, they'll need a full retest I'm afraid :(
<Kamion> the Task and Priority fields were all potentially bogus
<Keybuk> seb128: still working ok for you?
<kagou> mjg59: if you had time we can try to resolv #31502
<seb128> Keybuk: yep
<Keybuk> yeah, is doing the right things for me too
<Keybuk> ok, into the archive with it then
<seb128> Keybuk: did you get what I said that afternoon
<Keybuk> seb128: no, I missed stuff
<Keybuk> can you re-paste?
<seb128> <seb128> Keybuk: I installed on my box, but it's not really an interesting configuration for it (2 wired eth, no wireless card)
<seb128> <seb128> Keybuk: it doesn't overwrite the resolv.conf by a blank one and let the interface correctly configured (which was not the case of the previous version)
<seb128> <seb128> Keybuk: but clicking on it doesn't list any connection, where the previous one was listed my 2 eth config (on greyed because no cable connected probably and the active one)
<seb128> <seb128> Keybuk: the .desktop for autostartup works fine too
<Kamion> CD image rebuilds running
<Keybuk> seb128: ok, sounds like it's behaving then ... it's deliberately backing off those interfaces because they've got configuration in /etc/network/interfaces
<ogra> Kamion, no problem ...
<ogra> i start getting used to it :)
<seb128> Keybuk: would it be complicated to set a static connection using interfaces data?
<Keybuk> seb128: how do you mean?
<Keybuk> it would only enable that static connection if you selected that interface
<seb128> right, no real point
<Keybuk> exactly
<ogra> Keybuk, no sound on recent ppc installs ...
<seb128> the system does that fine alone
<Keybuk> if you clicked another interface, then it'd bring down the static
<Keybuk> ogra: iz kernel bug
<seb128> Keybuk: it's just weird to have the applet saying I've no connection when I'm connected :)
<ogra> Keybuk, cant be ... there was no kernel update between the isos i tested ...
<ogra> last one (from friday last week) worked fine 
<seb128> Keybuk: maybe the tooltip should be changed to mention "no network connection or using a static one" or something like that
<seb128> but that's a detail
<Keybuk> ogra: *shrug* then elaborate on "no sound" and tell me whether it's "no driver loaded", "sound muted on install" or "driver loaded but sound card not found"
<Keybuk> seb128: yeah, it's bloody hard to do
<Keybuk> network-manager's code is like a cross between those 1980s adventure games where you were in a twisty maze of passages, all heading East; and Sierra adventure games where every wrong thing you do results in your death
<ogra> Keybuk, i'll have to do another testrun later ... will report back (or file a bug if you're gone)
<LaserJock> Kamion: alsa-tools seems to have built on the 3rd (successfully on all arch except ia64 which has a dep wait) but it hasn't hit the repos yet. Is that something you can take care of?
<Keybuk> ogra: it's almost certainly not a udev bug :)
<Kamion> LaserJock: yes, it's in NEW, I've been ignoring most things that aren't THE SKY IS FALLING urgent in there until I get flight-4 sorted
<ogra> Keybuk, i think its been muted ...
<Keybuk> seb128: out of interest, did it give any possible interfaces when you clicked on it?
<ogra> but i cant confirm 100% currently
<Keybuk> I was kind of hoping that I could just make the icon hide if everything was in /etc/network/interfaces
<Keybuk> ogra: then check your sound state was saved correctly, that you have a /var/lib/alsa/asound.state, that "/etc/init.d/alsa start 0" doesn't unmute the sound, etc.
<seb128> Keybuk: as said, before the update it was listing my 2 static connections configured from interfaces (one greyed which is a broken card with no cable plugged) 
<ogra> Keybuk, i'm talking about a frech install ...
<ogra> *fresh
<seb128> Keybuk: now it says "not network interface detected" (I've the french version so the translation might be slightly different)
<LaserJock> ogra: or is that a french install ;-)
<Keybuk> ogra: hmm, did you make either /usr or /var separate partitions to / ?
<ogra> heh
<ogra> Keybuk, nope, all on /
<Keybuk> seb128: ah, yeah, that could be improved
<Keybuk> ogra: then I don't have any immediate idea what it could be
<Keybuk> ogra: which alsa-utils version?
<ogra> ii  alsa-utils     1.0.10-1ubuntu ALSA utilities
<ogra> 7me grrs at dpkgs column width
<ogra> Keybuk, alsa-utils_1.0.10-1ubuntu7
<Kamion> seb128: when's that xorg thing a regression from?
<Kamion> i.e. is it something I need to rebuild install CDs for?
<seb128> Kamion: no need to rebuild a CD, that breaks "startx" and that's probably since we have modular server
<Kamion> ok
<seb128> no issue with gdm as it runs as root
<seb128> so feel free to ignore it, that's a detail :)
<Kamion> surprised the fix was in xorg not xorg-server
<Keybuk> ogra: hmm, pipe it to less ;)
<Kamion> surely it's xorg-server that ships the actual binary
<seb128> hum
<ogra> Keybuk, see above
<seb128> Kamion: I've changed /usr/bin/X which fixes the issue
<Kamion> that's a symlink
<Keybuk> ogra: ok, no idea; need more debugging when you have the machine in front of you and can reboot it
<seb128> Kamion: 
<seb128> $ ls -l /usr/bin/X
<Kamion> oh, er, no
<seb128> -rwxr-xr-x 1 root root 18262 2006-02-14 12:57 /usr/bin/X
<seb128> $ dlocate /usr/bin/X
<seb128> x11-common: /usr/bin/X
<Kamion> ah, ok, sorry, you're quite right
<seb128> np
<dilinger> so my coworker brought up an awesome idea
<dilinger> is there a livecd (flight or whatever) that uses xgl instead of normal x?
<seb128> dilinger: xgl is pretty new, so probably not yet
<dilinger> seb128: is anyone working on it?
<seb128> not afaik
<seb128> but I'm not really following those xgl stuff, maybe ask on #ubuntu-xgl
<Kinnison> dilinger: giving Xgl is universe currently, it's doubtful that anyone from the core team would be doing it
<dilinger> i would love to play around w/ xgl, but i don't want to break X on my dapper system (i rely on it for work too much)
<dilinger> Kinnison: ok
<seb128> you can have both installed
<Kinnison> dilinger: it's really easy to try it, and switch back to normal xorg
<seb128> that's easy to switch between them
<ogra> +and thats really more appropriate for #ubuntu-xgl
* sivang wonders why grub's list does not come up anymore and all screen is filled with garbag chars as background for the first kernel boot messsage.
<Kinnison> dilinger: mjg59's mail to ubuntu-devel-announce explains
<Burgwork> sivang, in dapper they just turned on a grub background image
<sivang> Burgwork: ah, thanks for letting me know - it doesn't work over this werid laptop, I'll go disable it :)
<tepsipakki> is the date for next CC meeting set?
<sivang> Burgwork: do you know also if "Multimedia System Selector" was removed from the "System" menu?
<ogra> grmbl ...
<ogra> rsync doesnt let me update the isos
<Burgwork> sivang, hidden
<sivang> Burgwork: ah, bad, where is it hidden?
<Burgwork> sivang, open the menu editor and unhide it
<sivang> Burgwork: okay, will do thanks! :)
<Burgwork> sivang, hidden as part of DapperDesktopPlan
<Keybuk> hmm, anyone know how to make update-notifier notice a new note placed in its user.d directory?
<sivang> Burgwork: do we have only one MM system now that we do not need the menu item anymore?
<shaya> is malone having issues?
<shaya> can't file a bug
<shaya> when I try to look at gnome-power-manager, I get "Sorry, you don't have permission to access this page. "
<Kinnison> shaya: out of interest, since I'm currently looking after gnome-power-manager, what is the problem you're having?
<ogra> Kinnison, launchpad/malone bug
<ogra> i had the same today ...
<shaya> Kinnison: brightness controls dont work on my t42p
<ogra> shaya, try to append +bugs to the url ...
<Kinnison> shaya: Hmm, right, one sec, let me look at what it should be trying
<shaya> /proc/acpi/ibm/brightness
<sivang> bah, can't find the menu itme there to unhide it
* sivang tries the terminal approach
<Kinnison> shaya: g-p-m uses hal's lcd controls
<Kinnison> shaya: so if g-p-m can't control your brightness, it's actually a bug in hal
<shaya> ok
<Kinnison> shaya: thanks, and good luck
<shaya> might not be a bug in hal directly
<shaya> might be a permission issue
<Kinnison> shaya: possibly
<Kinnison> shaya: take a look in /usr/share/hal/scripts
<Kinnison> shaya: there's lcd control scripts in there
<shaya> no, not a permission problem
<Kinnison> shaya: check that they would be doing the right thing
<shaya> even with that fixed it works right
<Kinnison> pardon?
<shaya> doesn't work right
<shaya> Q.
<Kamion> please retest current install CDs for all derivatives
<Kamion> Riddell, ogra: (kubuntu and edubuntu rebuilt too, for the Task/Priority field breakage ogra brought up above)
<ogra> Kamion, rsync crashes for me ... 
<ogra> i'm already trying to get the latest
<Kamion> will be rebuilding ubuntu live (and edubuntu if you want) for several espresso bugs
<Kamion> I'm having issues with my DVD burner, so at present I may only be able to test i386 in VMware
<ogra> hmm ... they were fine last try ... not sure i want to risk that ...
<ogra> anyway, go ahead ... :)
<ogra> not risking something is for loosers :)
<Kamion> ok, not mandatory, we just need to tell people not to try espresso on edubuntu ;-)
<Keybuk> whoah
<Keybuk> when packaging goes wrong
<shaya> argh
<ogra> nomeata, go ahead :)
<Kamion> because it will result in an unbootable system if they try the autopartitioner
<Keybuk> -rw-r--r--  1 scott scott 5.2M 2006-02-14 10:04 update-notifier_0.41.7.tar.gz
<shaya> shift-backspace in Xgl is evil
<ogra> GRRR 
<ogra> Kamion, no, go ahead 
<Kamion> Keybuk: seb128 filed a bug about that
<Kamion> ok
<shaya> Kinnison: well, advantage of killing X, when I restarted with the changed perms, it now works
<Keybuk> Kamion: heh
<shaya> so I guess this is a bug against ibm-acpi
<shaya> only root can write to brightness
<shaya> does that make sense?
<Kinnison> shaya: the hal helpers should be running as root
<seb128> Keybuk: the source package has like 15 versions of the .tar.gz :p
<Keybuk> seb128: not to mention at least one deb
<seb128> Keybuk: and some .deb and other stuff too
<shaya> hmm
<seb128> yeah :)
<shaya> let me try putting perms back
<shaya> and see if it was just a change in version for it
<Keybuk> quest ubuntu% tar tzf update-notifier_0.41.7.tar.gz | grep "\.deb"
<Keybuk> update-notifier/libgnomeui-dev_2.10.0-0ubuntu1_i386.deb
<seb128> :)
<Keybuk> methinks mvo needs a holiday ;)
<ogra> is anybody else able to rsync currently ?
<Kamion> he's on one
<seb128> Keybuk: svn update from it :)
<shaya> hmm
<Keybuk> rofl
<shaya> I guess new version fixed the problem
<ogra> Kamion, he's moving house ... 
<shaya> it works fine now
<ogra> not *really* my definition of holiday :)
<Keybuk> ooh, it contains an unpacked copy of an older version of its own source code too
<dholbach> Keybuk: mvo asked me to strip cruft from his upload - do you want to do it or shall I? :)
<seb128> mvo probably has a too fast internet upload
<Kamion> ogra: did you happen to notice in your tests whether bug 31716 is fixed?
<Ubugtu> malone bug 31716 in Ubuntu "PATH only contains /bin:/usr/bin on new installs" [Critical,Fix released]  http://launchpad.net/bugs/31716
<seb128> he would have noticed other way :)
<Keybuk> dholbach: you can do it :)
<dholbach> ok
<Keybuk> I'm just going to upload this package, then tidy up before the other half arrives and complains about how messy I am
<dholbach> Keybuk: so you will do it?
<Keybuk> dholbach: uh, I'm going to upload *network-manager* ... you can do update-notifier ;)
<dholbach> okok
<ogra> Kamion, sorry didnt check yet ... i wanted to do more testing on the i386 install i stopped whne you rebuilt the isos ... will follow up and close the bug if it works
<Kamion> Tollef already closed it, I'm just checking up
<Keybuk> Kamion: out of interest, do you know how to fix that on an installed system?
<ogra> oh, k
<Kamion> Keybuk: sudo /var/lib/dpkg/info/libpam-modules.postinst configure ''
<Keybuk> ah, "put PATH back in /etc/environment" ? :)
<Kamion> yep
<Kamion> did you remove it, or was this a recent-ish fresh install?
<Keybuk> recent fresh install
<Keybuk> how come that got added there?  what put sbin in the PATH on breezy?
<Kamion> it was hardcoded in everything that started a session
<Keybuk> ah
<Kamion> we've moved it to just one place
<Keybuk> why does nothing bother reading ENV_PATH from login.defs?
<Kamion> https://launchpad.net/distros/ubuntu/+spec/one-true-path
<Kamion> because login.defs is a private configuration file and there's no stable way to access it
<Kamion> /etc/environment is read by pam_env
<Kamion> so it's more convenient anyway
<Keybuk> *nods*
<Keybuk> seems fair
<Keybuk> "upload error made it out of the main loop"
<Keybuk> "GENTLEMEN!  OUR FUGITIVE IS AN UPLOAD ERROR!  ESTIMATED SPEED ON FOOT IS THREE TO FOUR MILES PER HOUR"
<sivang> heh
* Kinnison tickles keybuk
<sivang> Burgwork: btw, I could find the itme to unhide it in the menu editor
<sivang> Burgwork: the only hidden item there is GNOME control center
<Keybuk> Kinnison: the uploader should recognise common mistakes, and just reply "uploading to unstable?  are you SURE you want to be on the distro team?"
<ogra> giggle
<Burgwork> sivang, you certain?
<Kinnison> Keybuk:  well, that particular uploaderror should be converted to a reject
<Kinnison> Keybuk: and a snarky message could ensue as a result
<Keybuk> elmo had a good stock of them in jennifer
<LaserJock> or you could just send it to unstable, I'm sure Debian wouldn't mind ;-)
<Keybuk> "changelog mentions YOUR MOM!"
<Keybuk> springs to mind
<Kinnison> Keybuk: one issue is that the uploader has to be sane for derivatives too
<sivang> Burgwork: yes
<sivang> Burgwork: I just wanted to select multimedia system for crying out loude :-) It's not much I think..
<Mithrandir> mdz: got a minute?
<Burgwork> sivang, just run gnome-multimedia-selector from the cli
<sivang> Burgwork: ah nice,I don't have this program on disk. /me goes to fetch it
<shaya> here's another Q, is gnome-terminal having issues on dapper?  at least w/ compiz+Xgl multiple tabs in a gnome-terminal behave badly, but can open as many single tab terminals as I want
<mdz> Mithrandir: yes
<shaya> trying to figure out what could have caused this regression
<shaya> as it was working fine at one point
<ogra> shaya, please take that to #ubuntu-xgl
<shaya> ogra: don't know if its an Xgl issue
<shaya> hence the Q, does anyone else see it
<Mithrandir> mdz: espresso needs a way to install -desktop without live.  I've added experimental support to casper for supporting "stacks" of filesystems where you'll have base + desktop + live being the live cd.  We'll need some changes to the build process, but that shouldn't be much of a problem.
<Mithrandir> mdz: If we go this route, we're well into unionfs land with no return path.
<Keybuk> damn, my office is warm
<Mithrandir> mdz: as I'm a bit worried about just doing it, I wanted to bounce it off you so you can ack or nack it or come up with another suggestion.
<Kinnison> dinner time
<Kinnison> ciau
<Kamion> Mithrandir: speaking of kbd-chooser verbosity as we were the other day, taking the set -x out of S55kbd-chooser would be much appreciated
<Kamion> it's ugly on boot
<Mithrandir> Kamion: you want me to walk through and rip it all out?
<Kamion> yeah, if you have time
<Kamion> I mean all the debugging in our diff against Debian, rather than all the debugging total
<Mithrandir> sure, but not today.
<Mithrandir> obviously. :-)
<Mithrandir> I forgot to take it out before uploading, that's all
<Kamion> fairy nuff
* sivang morns the death of gnome-multimedia-selector.
* Treenaks gives sivang gconf-editor
<sivang> Treenaks: should I search for the key controlling the MM system used and change it there instead? :)
<mdz> Mithrandir: that sounds more complex than removing -live afterward
<mdz> which isn't trivial, but isn't unreasonable either
<Treenaks> sivang: don't worry, it's a usability improvement :P
<Mithrandir> mdz: Kamion was not happy with removing -live.  I have this code implemented and it works at least in my testing.
<Mithrandir> mdz: it'll make customisers life easier and can make building CDs a whole lot faster too.
<Mithrandir> (that's some of the other upsides)
<mdz> Mithrandir: we need to be conservative; this is the theme for the entire release
<Mithrandir> mdz: yes, that's part of the reason I'm asking you about this rather than just blasting through. :-)
<mdz> this is not the time to make this type of infrastructure change
<mdz> Mithrandir: my feeling is that we should keep it simple, even at the expense of some elegance, for dapper
<mgalvin> so does everything on the default desktop install require gstreamer 0.10 (no more 0.8 by default)?
<mdz> mgalvin: yes
<mgalvin> mdz: thnx
<Mithrandir> Kamion: ^^ what do you think?
<mdz> let's review the issues with removing -live
<mdz> the very worst I can think of is that we end up storing in the filesystem the list of packages to remove
<ogra> sivang, whats wrong with running gstreamer-properties manually ?
<mdz> which really isn't very bad at all
<infinity> mdz: We also need to make perfectly sure that all those package purge cleanly (a goal anyway, to be certain, but we know we're not always bug-free there), so an espresso install and a "normal" install are essentially the same.
<mdz> it's something for live CD customizers to trip over, but we have documentation for them, and it's a minor use case compared to installing the system
<Mithrandir> on the other hand, we're already fairly screwed if unionfs doesn't work.  This is just using more than one ro-fs.
<mdz> infinity: I think the bugs we'll encounter there, if any, will be shallow
<infinity> mdz: The stacked unionfs thing is actually simpler in comparison, since we know exactly what the user will get after they click "install"
<Mithrandir> it'll make custom addons absolutely trivial to make, though.
<infinity> mdz: (I'll bet jbailey likes knowing exactly what users will have installed and in what state, too)
<mdz> custom addons are not a goal for dapper however
<Mithrandir> I made a 02_language_pack_nb.squashfs today, took about five minutes.
<Mithrandir> so it'll make customising the live cd a lot easier
<mdz> it's tempting, but we can't be tempted by unplanned features which involve adding complexity
<mdz> espresso is risk enough as it is, but it's a risk we planned and evaluated well in advance
<mdz> I like the idea, and it has a feeling of elegance to it, but it's something we should experiment with early in a 6-month release, not midway through development of a 5-year release
<janimo> infinity, any idea why xfdesktop4 is not in the archive yet even if it was build successfully 9-10 hours ago? other packs I uploaded well after it are in the archive.
<mdz> s/6/18/ BYKWIM
<mdz> janimo: new binary perhaps?
<Mithrandir> mdz: I see your point, yes.
<janimo> mdz, not AFAIK
<janimo> hmm
<janimo> mdz, but could be indeed
<mdz> Mithrandir: I don't expect you'll be reorganizing a lot of code in casper at this point, so the branch shouldn't be hard to merge later on
<Mithrandir> mdz: nah, it'll be simple enough; I'm not worried about that.
<janimo> I always forget to think NEW binary when things dont't show up
<mdz> so there's no rush
<sivang> ogra: what was so wrong with g-m-s ??
<ogra> sivang, what is g-m-s ?
<sistpoty> btw.: is there any ETA when requested syncs will be progressed again? I'm a little bit tempted to manually upload a sync (with the version just right below the actual synced version)
<Burgwork> sivang, it lead people to royally screw things up
<janimo> mdz, not new binary, but not the same either.
<janimo> binary name is same, source is different from hoary/breezy but same as in warty
<janimo> maybe this confused LP
<janimo> xfdesktop4 vs xfdesktop
<mdz> janimo: "new" means "wasn't built by the version of this source package in the archive"
<mdz> (not really, but that's close enough)
<mdz> it doesn't matter if it built it back in warty
<mdz> someone should get mail about it, though
<mdz> either infinity or you
<janimo> well so far I only got mail if NEW source
<janimo> never for binaries
<janimo> mdz, http://archive.ubuntu.com/ubuntu/pool/universe/x/xfdesktop4/
<mdz> janimo: yes, that was the case with katie
<janimo> neither souce nor binary seem NEW, they were in warty. or I really don;t understand NEW
<mdz> see above
<janimo> so every new version
<janimo> of source make binary NEW?I did not know that
<mdz> if the package builds binary foo
<mdz> then stops building it for a year
<mdz> then builds it again
<mdz> it's new
<janimo> aha 'a year' that's the key word
<mdz> you said warty
<janimo> yes, but you did not say anything about time :)
<janimo> passing and being taken into account
<mdz> even if it's a week, I expect it would be new
<mdz> as soon as the binary goes away
<mdz> if there is no binary foo in dapper, and you start building foo in dapper, that's new
<ogra> janimo, are you sure the binary was called xfdesktop4 not just xfdesktop in warty ? 
<janimo> ah so it's purged from the archive. I thought if it's on the web it;s there
<janimo> ogra, see link above, it's the same debian package
<janimo> only since hoary did we go with a different one which changed the source pkg name
<ogra> ah, yes, i see
<Kamion> mdz: belatedly, the customisation case was the main one I was worried about, but if you don't think that's a big deal then fair enough. I can easily generate the set-difference of desktop and desktop+live using germinate and stick it on the CD somewhere; any suggestions for how that could be done in a way obvious to customisers?
<janimo> I see now too. I was confused since it's at http://a.u.c I thought it;s in the archive NOW
<Kamion> janimo: NEW <= "name of entity you just uploaded is not in the override file"
<Kamion> ... for this release
<janimo> Kamion, I don't know what the override file is but I am convinced now :)
<Kamion> the override file is the list of source+binary packages the archive knows about for a given release
<janimo> I wish LP showed what's in new ...
<Kamion> there's one per component actually, but never mind that
<janimo> and mailed me for binary NEW
<infinity> It doesn't currently mail anyone about binary NEW.  That's yet to be written, AFAIK.
<Kamion> mdz: (taking into account that espresso needs to figure out how to subtract language-{pack,support}-* and dependencies from that set-difference)
<tseng> infinity: did you get my mess of messages early, or should i clean the up as an email?
<infinity> tseng: I got it.  We're working on a bit of a soyuz oops where the njb-sharp powerpc upload mysteriously took a dive, then we should be back on track.
<tseng> infinity: great, thanks alot
<infinity> tseng: Thank Kinnison when he rescues njb-sharp. :)
<mdz> Kamion: I really don't think that customization is the main case, and it's easily accounted for in a simple and documentable (though unintuitive) way
<mdz> Kamion: we could even generate the list during the livefs build process
<mdz> rather than calculating it
<mdz> to ensure that it matches what was actually installed
<mdz> we could seed the language stuff seprately if that's problematic
<Kamion> I thought that's what I meant ...
<Kamion> oh, I guess, germinate != livefs-build, fair enough
<mdz> Kamion: I was suggesting recording package installation rather than calculating set differences
<mdz> but either way works
<Kamion> I'm concerned about reworking the language stuff at this point, for pretty much the same reason you're concerned about unionfs
<mdz> so long as they're in sync
<mdz> how does it work now?
<Kamion> it's infrastructure and there are lots of complex warts in there that basically work now
<Kamion> luck and judgement
<mdz> I'm serious
<Kamion> yeah, just trying to figure out where to start
<Kamion> actually, I guess it isn't too bad for the live seed - the ship seed is the difficult case
<ogra> Kamion, am i assumin right that the next livefs builds will wait for the two uploads you just did ? 
<mdz> if it's that big a deal, we can ditch langpacks from the live CD
<Kamion> for the live seed they just end up as dependencies of ubuntu-live
<Kamion> we generally only have language-pack-en there anyway, but I don't want to remove that and then have to reinstall it
<Kamion> and I think we do need to keep language-*-en on the live CD
<Kamion> powerpc has some more language packs; again they're handled by *-meta
<Kamion> so yeah, I take it back, it isn't too complicated to rework, but would need coordination between seeds and live CD build script
<Kamion> I'll chat with infinity about it when he's next awake
<infinity> Kamion: Mail me about it, I have a date with livecd.sh coming up anyway.
<Kamion> 'k, will do
<janimo> do you know when main promotions will be doable?
<sivang> Burgwork: I see, so the new approach assumes the multimedia system works flawlessly out of the box, okay, I can understand that better.
<mdz> they're already doable
<Kamion> they're doable but need great care without anastacia
<sivang> ogra: gnome-multimedia-selector
<mdz> though the dependency checks aren't done automatically yet
<ogra> sivang, dont know that ... is that another name for gstreamer-properties ?
<sivang> ogra: apparently yes, when I run g-p I get the multimedia system selector :)
<ogra> Kamion, gah, obvously the last build of install CDs is borked ... libgl1-mesa is broken
<tseng>   * Migrate to my own style of packaging.
<Kamion> ogra: syslog again?
<tseng> Keybuk++
<ogra> thats in the ltsp chroot building ... but i suspect it will happen in normal X installs as well ...
<Keybuk> tseng: wrong trab?
<Keybuk> uh, tab
<janimo> so is it better to wait for anastacia in order to promote the xfce lot?
<tseng> Keybuk: i was enjoying your changlog ^
<Keybuk> n-m one?
<tseng> yeah i wasnt digging the bzr patch thing
<ogra> Kamion, weird errormessage ... "short read in buffer_copy (backend dpkg-deb during './usr/lib/dri/trident_dri.so')
<ogra> Kamion, i'll let it finish to see if it also happens in the normal X install and have a syslog then
<ogra> (ltsp client builder isnt logged)
<Kamion> ogra: that smells of a CD build error
<Kamion> er, burn error
<Kamion> or possibly out of disk
<ogra> might be related to the multiple rsync breakages i had
<ogra> nope, it has a free 10Gig partition 
<ogra> let me try i386 ... thats amd64 ...
<Keybuk> tseng: I've been trying to use bzr here, but haven't got on with it yet
<Keybuk> it's doo tricky to flip between patches
<ogra> Kamion, mjg59 did a mesa upload to add xgl support to it between the two builds
<tseng> the beagle maintainer had it all split out into like 10 tla archives
<tseng> it was so hard to use
<Kamion> I doubt any normal upload could trigger that error
<ogra> i suspect its package breakage ... but lets see, i386 started ...
<Kamion> you would have to be building the filesystem tarball in the deb by hand, or else assume a serious buildd glitch
* ogra goes to get some food
<Keybuk> tseng: in theory I have a bzr archive for each patch there, but I have a bad habit of just editing the last one in the list and then trying to make the patch properly after :)
<infinity> ogra: If you suspect it's a broken package, download it from the archive and "dpkg -i" it by hand.
<infinity> ogra: I suspect if it was a broken package, mesa would already have a few bugs filed on it, and there'd be posts to ubuntu-users to the effect of "OMG, DAPPER IS BROKEN!!111ONE"
<Kamion> has anyone tested current amd64 and powerpc install CDs
<Kamion> (Ubuntu)?
<Keybuk> not today's, no
<Keybuk> downloading isos on someone else's bandwidth seems cheeky :)
<ogra> Keybuk, that'd be "last hours" rather
<Kamion> yes, I do mean very current
<ogra> Kamion, i'll grab them if i'm through with edubuntu
<ogra> infinity, Kamion seems youre right ... mesa is fine on i386
<infinity> ogra: Being fine on i386 doesn't mean the amd64 package isn't broken.  Please download it from the archive and try installing it to a chroot.  It is is broken, we need to rebuild it.
<ogra> infinity, given that my amd64 currently installs a i386 iso i cant ...
<ogra> but will do tat later
<zyga> hi, could someone suggest any gtk+ debugger similar to ddd? I googled but I don't believe there is none
<Keybuk> zyga: the one built in to anjuta?
<zyga> Keybuk: thanks, worth a try
<zyga> but I preffer stand-alone stuff, vim is my ide
<Keybuk> if you like vim, surely gdb itself is enough? :)
<Keybuk> I keep trying to ween myself off emacs and gdb to something like anjuta, or even just use emacs's internal gdb modes, but never have any luck
<zyga> Keybuk: I always use 'bare' gdb but this time I need to go thru lots of data at runtime and I remeber a co-worker using a qt-based visual debugger - I kind of a liked that
<Keybuk> I tried a KDE IDE once ... I didn't get along with that either
<Keybuk> you know what I really really really really want?
<Keybuk> The old Borland IDE, but done GTK+ style
<Keybuk> the one that kept well out of your way until you needed it
<zyga> Keybuk: arrrr... you speak well mate
<zyga> rhide 
<ogra> pide is a cool vim based IDE
<zyga> with nice breakpoints and usefull text gui
<ogra> (we should consider it as idle replacement once)
<zyga> ogra: :-) checking!
<zyga> no package :/
<Keybuk> at some point I might do it as a project, but not today
<zyga> ogra: is pide non-english based?
<zyga> ogra: I cannot find any homepage that I'd understand
<ogra> dunno, i never looked for webpages, i just installed it from universe ;)
<zyga> ogra: hum? there is no such package
<ogra> in dapper
<zyga> yes in dapper 
<ogra> err, sorry
<ogra> its called pida
<zyga> aaah :)
<zyga> that's more like it :)
<ogra> its a while ago that i tested it ... but was very convincing
<zyga> looks nice
<ogra> yup ... the gazpacho interface isnt done yet, but it integrates nicely with a python execution environment and the debugger
<ogra> and you can use vim :)
<zyga> I'm trying to run the debugger from there
<jbailey> Keybuk: Y'know, when I thought of "old Borland IDE", my first though was Turbo Pascal... ;)
<zyga> pastebin interface! :)
<ogra> :)
<zyga> jbailey: that's how many people touched programming, including me :-)
<zyga> ogra: integrated python shell! :)
<Keybuk> jbailey: indeed, or Delphi
<jbailey> zyga: It wasn't my first contact with programming, but it was my first IDE.
<zyga> I'm younger probably
<jbailey> Electric Pencil can only take you so far. =)
<zyga> hehe
<cfk> what is the rsync for daily-dapper-server?
<cfk> and whos idea was it to make the filename the same as.. not-server ?
<jbailey> mdz: Around?
* Burgwork remembers being subjected to borland c++ at school
<mdz> jbailey: yes
<jbailey> mdz: The old debbugs imports into bugzilla got openned as separate tasks.  When the Ubuntu tasks get closed, the debian tasks stay open and it causes the bug to still show up in subscription lists.  Can we consider asking the Launchpad folks to just delete the old Debian tasks until they get synchronisation working again?
<mdz> jbailey: I've talked with kiko about this
<mdz> jbailey: let's ->#launchpad
<sivang> okay, what package should I file a bug with gnome events sounds not working against?
<LaserJock> who would I need to talk to to get a package moved from multiverse to universe?
<sivang> (I've exhusted all possibilities, I think)
<zyga> sivang: ask seb128 in -desktop probably
<sivang> zyga: he's not here, keep it for monday probably :)
<zyga> ah :)
<sivang> zyga: do you happen to know how the gnome "desktop" plays it's event sounds, that is, which tool it uses to do so ?
<ogra> gah where is keybuk ...
<zyga> sivang: probably builtin api 
<ogra> grmpf 
<zyga> (like: no external binary to play sounds)
<sivang> yes, I understodo the first time :)
<ogra> Kamion, apart from ltsp being totally broken on the current install, edubuntu itself installs fine :(
<ogra> i386 that is
<ogra> but the system insists that no package named ldm exists ... grmpf
<ogra> infinity, mesa is fine in the chroot ...
<ogra> (amd64)
<jdong> is it true that Metacity will have a compositing manager built in?
<tseng> its an option
<tseng> that doesnt mean it will ship like that
<jdong> tseng: interesting... will we opt for it?
<Kyral> Nice job with the Installer guys
<tseng> we dont have compositing on by default in X, either
<tseng> jdong: i doubt it, ask seb128 
<jdong> tseng/seb128: will our metacity have the gconf option for compositing?
<tseng> who said anything about gconf
<tseng> i am talking about build time
<jdong> tseng: http://www.gnome.org/~davyd/gnome-2-14/images/compositing-manager-large.png
<jdong> I don't expect composite features to be enabled by default
<tseng> yes I have seen this page
<jdong> just wondering if our metacity will have support for it
<tseng> sigh
<ogra> its a build option patch ...
<tseng> if you dont compile it in
<tseng> it doesnt matter if it is enabled or whatnot by default, its just not there.
<tseng> is what im trying to get across
<tseng> i dont expect we will do this
<jdong> ok; does applying the composite patch do anything negative to non-composite operation?
<tseng> "introduces untested code late in the cycle"
<tseng> at the very least
<ogra> yay
<ogra> and live with it for 3 years :)
<tseng> compositing will mostly pan out in dapper+1, we are on the tip of the iceberg
<tseng> there are no solutions that are ready for dapper
<jdong> ok, understood
<seb128> jdong: depending of upstream, dapper is supposed to be stable and will be, so no new bugged crack by default, there is no point to that
<Kamion> Kyral: which one? :-)
<jdong> alright, understood; I'll stop bugging you guys now
<Kamion> Kinnison: any idea what's happened to espresso builds for !i386? i386's built, everything else is needs-build ...
<ogra> Kamion, see #c 
<ogra> Kamion, seems to be a serious problem currently ...
<Kamion> well, it's not immediately clear it's all the same issue
<ogra> nope ...
<ogra> but likely that its related 
<ogra> i'd really like to get this ltsp fix into flight4 ... else ltsp will be unusable ...
<jordi> seb128: what did I do this time?
<Kyral> Kamion: Espresso
<Kyral> Kamion: I dl'd a daily build and loaded it in VMWare
<seb128> jordi: that was from chpe, you ship the bugged adblock with epiphany to Debian
<jordi> I know. :)
<seb128> jordi: I said to not ship it and now upstream is bugged because of you
<jordi> next upload disables it
<jordi> damn
<Kamion> Kyral: excellent, glad you like it
<Kyral> Kamion: you want me to put the console dump someplace?
<Kamion> still a lot to go in, but it's starting to come together
<seb128> jordi: there is nothing to win to bother upstream :)
<Kyral> Yah, can I make a few suggestions?
<Kamion> Kyral: sure - it does witter a bit, chiefly in partman
<Kamion> Kyral: preferably in bug reports
<Kyral> kk
<jordi> seb128: was he very pissed?
<Kamion> certainly what we have now is by no means final or untouchable
<Kyral> I know
<Kamion> in fact it's more "we need to get something out there ASAP"
<seb128> jordi: I don't think so, just a bit surprised that Debian ship it :)
<jordi> nod
<Kyral> Just what jumped out at me was there is no way to it 'cept via CLI
<jordi> I've wanted to upload a fix for this for months
<jordi> sigh
<Kamion> Kyral: that's fixed
<Kamion> current dailies have a link on the desktop
<seb128> jordi: 
<seb128> <chpe^2>        jordim packages adblock for 1.8??
<jordi> I'm seriously swamped
<Kamion> (per the specification)
<Kyral> Kamion: Okay I'll download a new daily
<seb128> <chpe^2>        seb128: next time you'll meet him, give him a good paddling :P
<seb128> jordi: that's all :)
<jordi> X)
<Kamion> Kyral: might want to apt-get upgrade a daily before running espresso, there are fixes I'm trying to get in
<Kamion> but the Launchpad buildds hate me today so it's delayed
<Kyral> Kamion: like the Kernel bug?
<Kamion> nah, espresso 0.99.14
* Kyral falls down
<Kamion> you'll get an unbootable system otherwise if you use the autopartitioner
<Kyral> ah
<Kamion> (hosed /etc/fstab => hosed /boot/grub/menu.lst)
<Kyral> yah I know
<Kyral> I was referring to he bug hitting both Dapper and Sid
<ogra> Kamion, postpone to monday ?
<Kamion> no idea what that is
<Kyral> Lemme snag the LP bug
<Kamion> ogra: not if I don't have to; feel free to mail me any outstanding issues on your side and I'll make sure they get resolved
<ogra> Kamion, i'll do the install image tests for ubuntu as well ... 
<Kamion> thanks, I can only do i386 at the moment
<ogra> but i'd really like t see the ltsp fix in ... and it doesnt look like that will happen today
<Kamion> ogra: have you managed a source upload of it?
<Kamion> i.e. are you just waiting for binaries, or is the source upload broken too?
<ogra> Kamion, nope, that was the weird reject error i spoke about
<ogra> in #c
<Kamion> could you put the upload somewhere so I can try reuploading it?
<ogra> yup
<ogra> do you have dirct access to drescher ?
<Kamion> yes
<Kamion> what version of ltsp?
<ogra> 0.75
<ogra> just poshing it to rookery ...
<ogra> *pushing
<Kamion> while I realise this is a cop-out, have you tried just uploading again?
<ogra> http://people.ubuntu.com/~ogra/
<ogra> nope, i'll do ...
<Kamion> please
<jordi> seb128:    #352850: Epiphany crashes when closing
<jordi> seb128: this sounds like it too, right?
<wickers> question: how much of novell's code will ubuntu be using? with their changes to gnome, xgl, compiz?
<seb128> jordi: there is a combinaison of firefox and epiphany fixes, I don't think we should fix it while we build with mozilla but ask to chpe
<seb128> wickers: you want to join #ubuntu-xgl, and most of the xgl stuff are already to dapper universe
<jordi> seb128: I mean, if those "crwash when exiting" is caused by adblock.
<wickers> yeah, but i'm mostly intersted in novell's changed to gnome
<seb128> wickers: we will not use them by default for dapper though (too young, dependant of good videos performances, driver, etc)
<jordi> I was under the impression it is. Do you know if it's a different bug?
<seb128> jordi: there was one of those yeah, but dunno if that changelog entry is the same one
<wickers> They have done a lot of work in useability with NLD10's gnome interface...
<seb128> there may had been different crashes on exit
<jordi> I only started to see them with adblock tho
<sivang> seb128: has people reported they don't have gnome events sounds? pitti told me to ditch polypaudio and I did so, I also used gst-properties to set everythignt to ALSA. I gett _all_ other sounds. What else can I do to have the login sound and other events back? (when running gnome-sound-properties I get '/usr/bin/esd' not found on the terminal)
<seb128> wickers: like the panel applet? is there any code public yey?
<Kamion> ogra: it worked this time
<ogra> no mail yet ...
<seb128> sivang: install esound
<Kamion> Listing ubuntu/dapper (ACCEPTED) 1/2
<Kamion> ---------|----|----------------------|----------------------|---------------
<ogra> Kamion, YAY 
<wickers> seb128, they say that they hope gnome developers use their code.
<Kamion>     3184 | S- | ltsp                 | 0.75                 | 40 seconds
<Kamion>          | ltsp/0.75 Component: main Section: misc
<wickers> so I suspect it's open
<ogra> just got it
<Kamion> ---------|----|----------------------|----------------------|---------------
<seb128> wickers: yeah, but just not now, it's too early for that, I'm not sure there is any code public yet
<seb128> wickers: withing 6 months maybe
<wickers> mm
<Kyral> finally found the bug
<Kyral> https://launchpad.net/distros/ubuntu/+bug/31347
<Ubugtu> malone bug 31347 in ubuntu-docs "2.6.15-15.21_i686 does not boot (depmod not found)" [Normal,Unconfirmed]  
<Kamion> ogra: https://launchpad.net/products/launchpad-upload-and-queue/+bug/31820
<Ubugtu> malone bug 31820 in launchpad-upload-and-queue "mysterious exception during accept on ltsp 0.75" [Normal,Unconfirmed]  
<ogra> Kamion, thanks 
<sivang> seb128: thanks, pitti told me I do not need esd because dmix takes care of it now.
<seb128> sivang: that's true but libgnome use esound for sound events, so you need esound for those
<seb128> if you don't need sound events, you don't need esound
<sivang> seb128: thank you very very much. also, for explaining this.
<seb128> np
<sivang> :)
<ogra> seb128, i still wonder if its really that hard to change it to gstreamer 
<seb128> ogra: depending of "that hard", probably some hundreds of line of code, like 1 week of work for somebody having some gst clue to get it working and tested
<ogra> wow, i wouldnt have guessed in hundrets
<seb128> ogra: http://bugzilla.gnome.org/attachment.cgi?id=38115&action=view
<seb128> ogra: that's a first untested patch for libgnome for upstream
<seb128> there is some libgnomeui and some g-c-c patching required too
* ogra notes that most of the lines start with -
<sivang> yeah, looks like quite some work 
<ogra> but untested is untested 
<seb128> yeah, imho that's not really hard task once you know what to change
<seb128> and how to change it
<ogra> still rather dapper+1 ...
<ogra> execpt you know it in and out ...
<seb128> probably
<seb128> the patch is for gst0.8 anyway
<seb128> so somebody needs to write a gst0.10 one
<seb128> and get testing, debug, feedback, etc
<ogra> yup
<seb128> ogra: one other issue is that libgnome would Depends on gst ...
<ogra> is that bad ? we have it installed anyway ... are there usecases where people install libgnome standalone ?
<seb128> as far as I'm concerned that's fine
<seb128> but dunno about xfce guys by example
<ogra> yes ... even KDE depends on gst now
<ogra> at least in kubuntu :)
<seb128> (not true for dapper)
<ogra> oh ? i thought they wanted 
<seb128> (since they didn't port to gst0.10 yet and we moved gst0.8 to universe)
<ogra> ah
<ogra> yeah, i remember ...
<ogra> wow, i wasnt aware that you end up with a complete gnome if you only apt-get install gdm on a clean chroot 
<seb128> ogra: you don't
<seb128> ogra: do you install Recommends or what?
<ogra> seb128, i have this prob in ltsp clients currently ... one of the debian guys added x-display-manager as an alternative dependency to ltsp-client ... it pulls in gnome-session
<ogra> from gdm depends:  gnome-session | xterm | x-window-manager | x-terminal-emulator
<ogra> it will take the first one available ...
<seb128> right
<seb128> but gnome-session is far to grab the whole GNOME
<ogra> took me a while to find out why my thin client chroots had control-center and the like installed
<ogra> and ldm got dropped from the edubuntu CD since gdm already provides x-display-manager ...
<ogra> crazy bug ...
* Kinnison returns and looks at njb-sharp and espresso
<ogra> Kinnison, on ltsp as well please 
<Kinnison> one at a time eh?
<ogra> yeah ....
<ogra> but espresso and ltsp are flight 4 stuff ...
<Kinnison> I've just unstuck all the builders
<Kinnison> all but i386 were marked failed
<Kinnison> probably internal network hiccough in the DC
<ogra> yup
<ogra> its a bad time for preparing a flight release ...
<ogra> but looks like we're nearly done ...
<ogra> i had surely none yet that was this tricky to prepare ...
<Kinnison> Yes it's just unfortunate
<Kinnison> this DC move has caused/exposed issues
<ogra> yup
<ogra> but it puts extra pressure on elmo and Znarl as well ... thats sad ...
<Kinnison> The buildd master should be able to recover from this situation
<Kinnison> I've proposed a way to recover
<Kinnison> we just need to code it
* Kinnison notes that the buildds have almost caught up
<ogra> Kinnison, you didnt reject bug 31822 ?
<Ubugtu> malone bug 31822 in gnome-power-manager "Please restore suspend lid action" [Normal,Unconfirmed]  http://launchpad.net/bugs/31822
<Kinnison> I didn't reject it because personally I don't agree with upstream's decision
<Kinnison> we'll see what happens when I punt users at that bug in gnome
<Kinnison> if upstream stick by their decision then I'll reject the bug
<ogra> yup
* Kinnison investigates libnjb-cil
<Burgwork> Kinnison, as long as resume is fast from suspend, there is no reason why we shouldn't suspend all the time
<Kinnison> Burgwork: there's a very good reason
<Kinnison> Burgwork:  you may have a process which is actively talking to the network
<Kinnison> Burgwork: suspending would fuck that up
<Kinnison> personally I never suspend on lid action
<Kinnison> because I think that's crackful
<Kinnison> but hey :-)
<ogra> me too
<Burgwork> Kinnison, if you have a running process, why are you closing the lid?
<ogra> i want my mail to still be delivered
<Kinnison> Burgwork: maybe I'm about to get up and walk from one room to another
* Kinnison closes the lid to make it more convenient to carry his laptop
<Kinnison> Burgwork: maybe I'm closing the lid so as to not be distracted while someone speaks to me
<Kinnison> Burgwork: I can think of a bajillion reasons
<Burgwork> yes, but the most common I suspect is to carry it around
<Kinnison> indeed
<Kinnison> and I don't want to drop off irc while I move from room to room
<Burgwork> and then you do want to suspend, as you are not using it
<Burgwork> that is a bug in the irc client, imho
<Kinnison> what? it's a bug in the irc client that you've disconnected it from the network so it can't talk?
<ogra> heh
<Burgwork> Kinnison, no, that it didn't come back from suspend
<Kinnison> that's like saying "It's a bug in linux that it doesn't run updatedb while the computer is off"
<Kinnison> Burgwork: TCP timeouts
* Burgwork notes that the gnome bugzilla got it correct with regards to commenting automagically cc's you
<Kinnison> yes
* ogra hugs Kinnison 
<ogra> thanks for speeding up ltsp :)
<Kinnison> y'welcome
<typonaise> does anybody know what happened to the debian/ubuntu-hardened project and where trulux and company hang out now?
#ubuntu-devel 2006-02-23
<aquarius> Is there any way of getting the upstream URLs for a bunch of packages without parsing them out of debian/copyright? I can't find any listed in packages or on Launchpad.
<lifeless> uscan's data file
<aquarius> ah, nice. Didn't know about uscan.
<aquarius> How does the data file stay up to date?
<minghua> aquarius: debian/watch
<aquarius> ah, it doesn't have a data file per se, it uses debian/watch. Cool.
<aquarius> That's very useful. One other thing: if I wanted to read the watch files for all the packages in the archive, would I need to get the sources of all of them and look in debian/watch for all of them?
<anibal> aquarius: not every package has a debian/watch file
<aquarius> anibal: yep, I'm just discovering that :)
<anibal> aquarius: for package pbzip2 you could try http://dehs.alioth.debian.org/maintainer.php?name=pbzip2 to see the uscan information of package pbzip2
<aquarius> anibal: ah, interesting
<aquarius> Would hitting that page once for every package be considered bad?
<anibal> aquarius: not at all
<anibal> aquarius: but, you could sleep a few seconds before between hits
<aquarius> anibal: oh, certainly I'd do that. :)
<wasabi_> So should python-uno be working?
<ogra> Kamion, edubuntu daily 20060217.4 and daily-live 20060218 tested on all arches, all gold and ready for flight 4
<ogra> Kamion, rsync for ubuntu daily 20060217.2 is running, will test these as soon as i got up ...
<LaserJock> can apt handle checking for local installations (i.e. from a source tarball) of a package to satisfy deps?  I imagine not but I though I'd ask
<dabaR> Does anyone know why bob2 is never coming to freenode any more, or at least that he is fine and well?
<zakame> hi devs :)
<shadeofgrey> okay...
<shadeofgrey> i know im not supposed to be here
<shadeofgrey> but i have a gripe
<shadeofgrey> actually
<shadeofgrey> id rather take this opportunity to grovel
<shadeofgrey> would one of you cool, awesome, brilliant coder folks write like 3 lines of code and find a way to make either the abiword or the openoffice cursor a full square?
<shadeofgrey> im going blind gradually over tiume, and its now almost impoosible for me to work on my novels without spending hours re-editing huge portiohs of text because i canbt see the damn cursor
<shadeofgrey> im handicapped.  i have one good arm, and four fingers on my lefty hand that work well enough to tuype with
<shadeofgrey> i now have glaucoma and will be blind in less than two years
<shadeofgrey> i REALLY need to hurry and get some stuff written before i cant see and have to stop and spend a year teaching my dumb ass braille
<Kyral> ...
<shadeofgrey> yeah its dumb
<shadeofgrey> i know
<Kyral> Come back sober yes?
<shadeofgrey> i am sober
<shadeofgrey> what, you think im kidding?
<Kyral> I could swear you said you were drunk in #ubuntu
<shadeofgrey> okay.
<shadeofgrey> whaztever
<shadeofgrey> why does the fact that i drink in any way belittle my perdicament?
<Kyral> no
<shadeofgrey> have i made a request you couldnt honestly fill?
<shadeofgrey> ive come here many times and thanked EVERYBODY here for what they do
<shadeofgrey> now im asking for legitimate help
<shadeofgrey> if i should be doing so in a different place, byu all means, shove me in thre right direction
<shadeofgrey> .....im on four wheels
<shadeofgrey> gravity and the laws of motion take care of most of it. all you need is a direction to send me
<shadeofgrey> 'are you important?
<shadeofgrey> do you make the decisions?
<shadeofgrey> is it a matter of money?
<shadeofgrey> id gladly make a $100 donation to the ubuntu team or whatever in exchange for a hand
<shadeofgrey> c'mon dude...  SAY SOMETHING
<Kyral> Most of us are asleep
<Kyral> or going to
<shadeofgrey> okay
<shadeofgrey> whens a good time to come back and grovel
<Kyral> also...we don't control AbiWord
<shadeofgrey> fine
<shadeofgrey> what text editor capable of handling 300 pages at a time has a cursor thats a square and has the ability to adjust its font size
<shadeofgrey> obviously....  the words have to be big or im ....  shit out of luck.
<Kyral> Use a Screen Magnifier
<shadeofgrey> is thee one for ubuntu?
<Kyral> should be
<Kyral> I don't knwo
<Kyral> check
<Kyral> I'm going to bed before I faceplant on the keyboard
<shadeofgrey> ...thanks
<Riddell> Kamion: kubuntu 20060217 live and 20060217.2 install good on all 3 architectures
<Mithrandir> mjg59: I'm wondering if running ddcprobe while usplash is running is a bad idea.
<fabbione> Mithrandir: it probably is
<fabbione> iirc even with FB gives out bad results
<Mithrandir> it seems it's just the EDID info which goes bad, not the rest of the info.
<fabbione> Mithrandir: are you thinking about the livecd?
<Mithrandir> fabbione: yeah
<fabbione> for livecd will do
<Mithrandir> https://launchpad.net/distros/ubuntu/+source/xorg/+bug/31830/
<Ubugtu> malone bug 31830 in xorg xserver-xorg "Incorrect screen resolution in Dapper LiveCD" [Normal,Unconfirmed]  
<Chipzz> grmbl
<Chipzz> grub is fucked up since last update
<Chipzz> aaaaaaargh
<sivang> Chipzz: there's a background image now , try to comment the splash line in your menu.lst and see if this works
<mdke> elmo, can you resend the docteam svn password for Brian Burger (https://launchpad.net/people/yh728), he had lost his gnupg passphrase and had to make another key. 
<siretart> morning
<Kinnison> Morning
<siretart> hi Kinnison 
<Kinnison> hey siretart
<sivang> hi Kinnison , 'sup?
* sivang is using irssi inside an amazingly wobbely Compiz window :)
<sivang> hey siretart 
<siretart> hi sivang 
* Kinnison grins siretart 
<Kinnison> erm, sivang
* Kinnison hugs sivang 
* Kinnison is tired and poor :-(
<sivang> Kinnison: my poor kinnie, why so?
<Kinnison> tired because of poor nights sleep
<Kinnison> poor because of having to pay for more house-move related stuff
<sivang> Kinnison: ahhh I see. Didn't you find a bargain for the move over?
<Kinnison> well yes, but it's not 100% cheap to move
<Kinnison> I still have to pay for things like a homebuyer's survey
<sivang> Kinnison: what is that??
<pitti> hi
* sivang hugs pitti 
<giftnudel> how can I debug the nm-applet from network-manager, it fails silently but I can't figure out why (DBUS_VERBOSE=1 doesnt't help)
<Kinnison> sivang: it's where someone investigates the house to check for damp, damage which isn't superficially obvious, etc
<Kinnison> guys, we're one powerpc builder down until the sysadmins can get to and fix adare
<mdke> is it worth filing a few bugs against gnome-power-manager for abnormal activity, or is it still early days and lots of problems are known?
<slomo_> infinity, lamont: please give-back beagle on ppc
<jdub> mdke: bugs
<mdke> jdub, okey dokey
<mdke> jdub, are you in london already?
<jdub> mdke: nah, arriving on monday
<Treenaks> jdub: do you ever stay in .au for longer than a week? :)
<jdub> Treenaks: ha ha, yeah :)
<ploum> Treenaks, I wonder if jdub ever stay in a given country for longer than a week
<ploum> jdub, will you be at FOSDEM next saturday ? (or only sunday)
<Kinnison> mmm fosdem
* Kinnison can't wait for friday night
<jdub> ploum: yes, i will, and will come to your meeting :)
<jdub> Kinnison: you going to fosdem?
<Kinnison> jdub: natch
<jdub> awesome
<Kinnison> jdub: Will you be in the Roy on Friday night?
* ploum is a bit sad. He tought that jdub tooks his force from his hair 
<jdub> roy?
<ploum> (like samson)
<ploum> jdub, really great !
<ploum> Thank you a lot
<jdub> ploum: so, a few people were concerned about that
<jdub> ploum: worrying if i would lose my unix mojo or something
<Kinnison> jdub: There's a pub where we often book out the top floor and drink lots of cherrybeer on the friday night
<ploum> it seems not..
<jdub> ploum: but i think i'm the opposite
<Kamion> please let me know soon if you have anything you think should be in the Flight CD 4 release notes: high-impact changes or things that require widespread testing
<Kinnison> jdub: It's called the Roy d'Espagne
<jdub> Kinnison: will have to find it :)
<ploum> Kinnison, it's a great pub indeed
* jdub wonders why his g-t/screen/mutt combo is having utf-8 probs again
<Kamion> I have nearly 2000 dapper-changes messages for that time period to sift through, and it's unlikely I'll get non-installer/liveCD things by myself
<jdub> Kamion: do you know if there's another flight review in the wiki?
<Kamion> jdub: yes
<jdub> Kamion: mihrt be worth referencing that for desktop stuff
<jdub> cool
<Kamion> already talked to mgalvin about that
<Kamion> (https://wiki.ubuntu.com/DapperFlight4)
<jdub> maybe we should use those pages as the real release notes, and make the emails really short? :)
<Kamion> I think those pages are a bit *too* verbose for the "here's the installer/liveCD stuff we fixed that you would never have noticed through ordinary upgrades" stuff
<Kamion> but they work well as release notes for the rest of the system, certainly
* Kamion wonders if his OEM fixes worked
<Lathiat> hrm
* Lathiat thinks that "Shutdown" shouldn't be under options..
<Lathiat> as its not overly obvious
<jsgotangco> those can be used as release notes?
* jsgotangco thought release notes were rather a bit techie always
* Kinnison heads out
<Kinnison> ciau
* jsgotangco actually started https://wiki.ubuntu.com/DapperReleaseNotes a few months ago
<sladen> kent: 
<sladen> keybuk: your ADSL is broken and the SOA timeout on your domain too short!
<vovkav> hello everybody! Is there anybody who is absolutely happy with his (opensourced) source and bug -tracking system and it's glue?
<Treenaks> what do you mean?
<Lathiat> i guess hes asking for reocmmendations of an open source source/bug tracking software
<Lathiat> trac si the only one i know of
<Lathiat> it seems to work
<vovkav> Lathiat Treenaks: absolutely yes!
<Lathiat> tis a litle offtopic but :)
<Lathiat> hrm
<Lathiat> when we had that downtime
<Lathiat> did the data center move?
<Lathiat> i only get 50K/s from archive. and cdimage. now :(
<Lathiat> used to be able to get my full 150K/s
<HiddenWolf> archive is slow indeed
<HiddenWolf> oh, wait, pulling 323kB/s now
<HiddenWolf> Still, that used to be ~650 for me.
<HiddenWolf> mjg59: ping
<mjg59> HiddenWolf: Hi
<HiddenWolf> mjg59: Hi
<HiddenWolf> Do you mind if I bug you with a question? something seems to mess up suspend/hibernate here.
<mjg59> Sure, go ahead
<HiddenWolf> I'm using a desktop system. nforce4-based, nvidia graphics card, nv drivers. I was trying to see if pressing the sleep/hibernate buttons would do something.
<mjg59> Ok
<HiddenWolf> It seems the system jumps immediatly. The screen goes black and the power led starts blinkining. It does not save session, just wham.
<mjg59> Suspend? That's correct.
<HiddenWolf> Same for hibernate.
<mjg59> How are you triggering hibernate?
<mjg59> Hibernation should not leave the power light flashing
<HiddenWolf> panel > log out dialogue > hibernate
<mjg59> I've absolutely no clue what the panel stuff does
<mjg59> Can you try using gnome-power-manager instead?
<HiddenWolf> how do I trigger that one?
<mjg59> Ah. With some trouble.
<mjg59> Nngh.
<mjg59> Ok. From a shell, do /etc/acpi/hibernate.sh ?
<mjg59> (with sudo)
<HiddenWolf> here goes
<HiddenWolf> mjg59: back, not succesful
<HiddenWolf> mjg59: I should've piped the output to a file, but there where some errors in there.
<mjg59> HiddenWolf: "Not succesful" in what way?
<HiddenWolf> power buttons stayed on, some activity, screen suspended, had to reset to wake up.
<HiddenWolf> button -> led
<mjg59> Edit /etc/default/acpi-support and change the DPMS statement to false
<HiddenWolf> and then try again. :)
<mjg59> HiddenWolf: Yup
<HiddenWolf> what was that script again? it didn't save my bash history
<Treenaks> 14:23 <       mjg59> Ok. From a shell, do /etc/acpi/hibernate.sh ?
<Treenaks> ?#
<HiddenWolf> huh, now it comes back on automatically
<HiddenWolf> quite a few errors in there.
<HiddenWolf> mjg59: http://paste.ubuntu-nl.org/8814
<mjg59> HiddenWolf: mkswap /dev/whatever; swapon -a
<mjg59> Then try again
<HiddenWolf> that is with "computer sleep type suspend" btw
<mjg59> That doesn't affect this
<HiddenWolf> /dev/mapper/Ubuntu-swap none            swap    sw              0       0
<HiddenWolf> that's the default lvm swap setup
<HiddenWolf> on sata / lvm 
<mjg59> Oh. I wonder how well tested this is for LVM swap.
<mjg59> In any case - have you mkswapped?
<HiddenWolf> not yet.
<HiddenWolf> hidde@megaera:~$ sudo mkswap /dev/mapper/Ubuntu-swap; swapon -a
<HiddenWolf> Setting up swapspace version 1, size = 2147479 kB
<HiddenWolf> no label, UUID=8c5e7412-eac1-43f5-a835-5cb76441b539
<HiddenWolf> swapon: /dev/mapper/Ubuntu-swap: Operation not permitted
<mjg59> sudo swapon -a
<HiddenWolf> no error now.
<mjg59> Right. Now try hibernating.
<HiddenWolf> apparantly succesful shutdown, apparantly normal boot sequence
<mjg59> HiddenWolf: Ok. What does RESUME equal in /etc/mkinitramfs/initramfs.conf ?
<mjg59> (You'll need to mkinitramfs and swapon again)
<HiddenWolf> #RESUME=
<HiddenWolf> nothing there
<mjg59> Change it to RESUME=/dev/whatever
<mjg59> And get rid of the comment character
<mjg59> Then rebuild your initramfs
<HiddenWolf> where should it go to?
<mjg59> ?
<HiddenWolf> I've never done mkinitramfs, and it's asking for an ouput location. :)
<mjg59> Oh
<mjg59> Just do update-initramfs -u
<HiddenWolf> swap is on again.
<HiddenWolf> hibernating again
<HWolf> came back up, got to an X session. No keyboard/mouse
<jsgotangco> mmm??
<HiddenWolf> jsgotangco: I'm trying for a working suspend/hibernate
<jsgotangco> ahhh
<jsgotangco> i should disable my nvidia to try that too
<HiddenWolf> and using up mjg59's saturday doing it. :)
<HiddenWolf> Which is actually pretty stupid on my part, since grub is fucked up. :P
* jsgotangco have been playing with xgl for too long
<HiddenWolf> I can't get to rescue mode if things crap out.
<mjg59> HiddenWolf: So it resumed, but stuff was broken?
<HiddenWolf> mjg59: yeah, my x/session/windows where back
<HiddenWolf> mjg59: mouse was on the position I left it.
<HiddenWolf> keyboard and mouse did not respond however.
<mjg59> HiddenWolf: USB keyboard?
<HiddenWolf> yes, mouse too.
<mjg59> Ok
<mjg59> Edit /etc/acpi/prepare.sh and comment out the block that starts "Now do something similar for USB"
<HiddenWolf> check
<mjg59> Should work now
<HiddenWolf> Hm.
<HiddenWolf> without the mkswap swapon stuff? :)
<mjg59> Without, yeah
<HiddenWolf> I'll give it a shot
<HiddenWolf> mjg59: that did it. Ain't pretty, but it works
<HiddenWolf> grub messed up, no usplash, screen corruption before turning to normal, but it works.
<jbailey> mjg59: Hmm.  Reminds me that I should file bugs about my laptop (Toshiba) suspending and not resuming.
<mjg59> "grub messed up"?
<HiddenWolf> mjg59: something went wrong with the grub splash image update.
<Chipzz> sivang: I'm aware of that; grub just doesn't work at all atm :/
<HiddenWolf> mjg59: text unreadable, and blotches of color on the screen. no working option selection.
<mjg59> HiddenWolf: Ok, not my fault
<Chipzz> no menu, no booting ubuntu, no booting windows, no nothing :(
<HiddenWolf> mjg59: I know. :)
<zakame> hi devs
<mjg59> Lathiat: If you pull latest git, your battery ought to be fixed
<HiddenWolf> mjg59: thank you for your help.
<mjg59> No problem
<HiddenWolf> Good to see that it works, altho with a bit of hackery.
<mjg59> I've just uploaded the USB fix. The lack of RESUME= is because you're tracking dapper and it got broken.
<HiddenWolf> So I can remove the comment chars from the file.
<mjg59> Just upgrade to the latest acpi-support once it gets built
<HiddenWolf> I'll do that.
<HiddenWolf> who should I talk to for the grub thing? keybuk?
<sladen> mjg59: on the TP, it's doing suspend,  then on resume it immediately suspends (second resume is fine)
<mjg59> sladen: What is?
<mjg59> (How are you triggering suspend?)
<HiddenWolf> mjg59, you should really talk to lmanul and seb and make sure that the logout dialogue does the same thing as g-p-m and the system menu. :)
<lmanul> HiddenWolf: can I help ? :)
<HiddenWolf> lmanul: ;)
<lmanul> What the logout dialog does for suspend (for example) is basically call  gdm_set_logout_action (GDM_LOGOUT_ACTION_SUSPEND);
<mjg59> lmanul: The logout dialog needs to avoid showing the sleep option unless sleep is enabled
<HiddenWolf> And sleep should really be called suspend, imho
<HiddenWolf> it is everywhere else.
<lmanul> That's what it does :)
<mjg59> lmanul: How does it determine whether sleep is enabled?
<lmanul> suspend_supported = gdm_supports_logout_action (GDM_LOGOUT_ACTION_SUSPEND);
<mjg59> Oh
<mjg59> No, that's not going to work
<lmanul> What should be used instead ?
<mjg59> hal
<lmanul> (that was in the previous code, by the way)
<mjg59> It also needs to talk to gpm
<mjg59> Yeah, we're in a brave new world now :)
<lmanul> Hmm, I'm not very familiar with thos :)
<lmanul> those
<lmanul> I might break something :-p
<lmanul> Is there a standard, easy to use procedure ?
<mjg59> Not to hand
<mjg59> This needs to be integrated with g-p-m to determine whether the user has enabled sleep or not
<lmanul> Huh, "easy to use" = I mean "easy to copy-paste" :-p
<lmanul> Hmm, I see
<HiddenWolf> If the user has set 'hibernate' in gpm, it should only offer hibernate.
<HiddenWolf> I guess
<lmanul> Well, I guess I'm not going to do this myself (I don't know much about hal or gpm)
<lmanul> But I'll speak to seb128 about this
<siretart> BenC: I notice you closed bug 30962, but I see this problem still in 2.6.15-15.21
<Ubugtu> malone bug 30962 in wine "Running wine applications instantly outputs "Killed." in the terminal" [Normal,Confirmed]  http://launchpad.net/bugs/30962
<siretart> BenC: do I miss something?
<BenC> siretart: No, I set it to "Fix committed"
<siretart> aah, ok. I see
<BenC> uploading today I hope
<siretart> no problem
<ogra> Kamion, ubuntu daily 20060217.2 install all arches are good
<BenC> is there "one true" place to set http proxy so all or most things use it?
<BenC> like macosx does :)
<jdub> BenC: no
<maswan> elmo, Znarl: is it intentional that *.releases.u.c (including se) is pointing to releases.u.c which has no ACC IPs?
<fabbione> hey BenC 
<BenC> that sucks...we should enable some kind of quick and dirty ip rules to do that
<BenC> fabbione: hey
<fabbione> BenC: please please please pull from me before uploading
<BenC> I did a pull yesterday
<BenC> is there anything new?
* jdub wonders if anoyone has a patch to get firefox to use gnome's proxy settings
<fabbione> you didn't push to kernel.org?
<fabbione> BenC: there was a RH cluster update
<BenC> I pushed
<BenC> maybe I missed some revs
<jdub> fabbione: do you do much with the linu ha project?
<BenC> oh wait, I git-fetched, but I forget to git-pull from the branch :)
<fabbione> BenC: hehe
<fabbione> jdub: i work a lot with the RH guys..
<jdub> hmm
<fabbione> BenC: i also pushed a niagara branch on people. It should be ready for merge by monday
<fabbione> BenC: i have a couple of fixes to push to David
<BenC> sweet
<fabbione> BenC: and we got to userland this night
<BenC> I have to get my e3k booted so I can do a test build with it
<fabbione> but it's kind of *cough*UNSTABLE*cough*
<maswan> hmm.. I wonder if a niagara would make a decent archive server frontend
<BenC> we'll try for niagra merge for next upload
<fabbione> BenC: yeah i am planning to work with David across the weekend
<fabbione> i didn't find any regression on the kernel
<BenC> fabbione: pulled/merged/pushing
<fabbione> so whatever breaks is SUN4V specific
<fabbione> BenC: thanks mate
<fabbione> maswan: http://vger.kernel.org/~davem/cgi-bin/blog.cgi/index.html
<fabbione> [    9.389691]  Brought up 32 CPUs
<fabbione> that's better than porn
<fabbione> and porn > *
<lmanul> fabbione: now that's questionnable :)
<siretart> emacs python mode rocks
<fabbione> lmanul: well of course... porn > 32 CPUs > * ;)
<sladen> mjg59: fn-f4
<jsgotangco> damn sunfire with 32cpus
<fabbione> jsgotangco: it's one CPU
<fabbione> 8 cores
<fabbione> 4 threads x core
<fabbione> it's like 32CPUS
* jsgotangco dies
<fabbione> except that it consumes less than a light bulb
<maswan> fabbione: neat. that'd make a good frontend to a backend nas thingie, I tihnk. too bad it is not relevant for work, due to lack of fpu.
<fabbione> cpu             : UltraSparc T1 (Niagara)
<fabbione> fpu             : UltraSparc T1 integrated FPU
<maswan> fabbione: well, yeah, one.
<fabbione> it's still ONE cpu :)
<maswan> my point is, that it is way underpowered fpu-wise
<fabbione> yes i agree
<maswan> for technical computational workloads
<fabbione> it's still a nice toy for frontends
<maswan> but for running apache, it's probably pretty neat. :)
<fabbione> yeah exactly
<BenC> I think it's mainly meant for server virtualization
<BenC> the Solaris port for it allows you to use a UI to drag and drap components from one virtual server to another
<fabbione> i still wnat one... or two :)
<maswan> now, if each of those cores had done at least one FMA per cycle, or even better, each of those threads...
<mjg59> sladen: With g-p-m?
<BenC> Like "Drag the database from Node1 to Node2", "Upgrade Node1 for security patches, reboot", "Drag database back to Node1"
<maswan> BenC: neat
<sladen> mjg59: from X, just do Fn-F4 which I guess is handled by your acpi-support packages so g-p-m shouldn't be involved?
<mjg59> sladen: No, it should all go through g-p-m now
* HiddenWolf hits evolution with a blunt object in painfull places
<HiddenWolf> it takes like a full minute to download 27 mails, put them in the relevant folders, and update the bold folder names.
<sladen> mjg59: yup, it is
<BenC> HiddenWolf: mine's not that slow
<HiddenWolf> BenC: I can clock it. :/
<BenC> pop3 to local folders, and I have like 30k emails in 20 folders
<BenC> one folder has > 10k
<HiddenWolf> BenC: I'm using an imap server off-continent, but any other client is still substancially faster.
<HiddenWolf> The email comes in fast enough.
<BenC> HiddenWolf: still didn't seem that slow when I was doing imap over my sat connection
<BenC> and that is _high_ latency
<HiddenWolf> It just takes ages to get it from inbox to the folders.
<fabbione> BenC: you won't believe it.. i figured why my machine has been slow to death since .15 something...
<BenC> well, when I was doing imap I had fetchmail on the remote putting things in folders
<BenC> fabbione: the amd64?
<fabbione> BenC: DMA is not enabled on any of the disks.. it was with .12 tho...
<fabbione> BenC: yes
<fabbione> BenC: it does the same on i386 kernels
<BenC> fabbione: odd
<BenC> can you enable dma by default?
<BenC> err, enable it manually
<fabbione> BenC: i did try using hdparm but it refuses..
<fabbione> on .15 ..
<fabbione> with i386 kernel
<BenC> what IDE controller?
<fabbione> i didn't test amd64 yet..
<fabbione> a bunch of them...
<BenC> and can you blacklist ide-generic and see if that helps?
<fabbione> hole on...
<fabbione> hold on
<fabbione> BenC: yes i can.. i figured 3 minutes ago
<fabbione> and i can't exactly reboot at the moment
<BenC> ok, I'd be really interested in knowing if that helps..I've heard rumors similar to your performance problems
<fabbione> 0000:00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
<fabbione> i think the controller is this one
<BenC> and I've also had atleast one issue where ide-generic is getting loaded when it shouldn't
<fabbione> i have something like 10 disks in this machines on different controllers..
<BenC> does dmesg show ide-via taking control of those disks?
* BenC is doing one last build with fabbione's cluster pull before uploading -15.22
<fabbione> i am not sure...
<BenC> seems not even the ACPI update required ABI bump, so that's good
<fabbione> even kern.log doesn't have all of it
<fabbione> Feb 17 13:08:02 gordian kernel: [4294678.334000]  VP_IDE: port 0x01f0 already claimed by ide0
<fabbione> Feb 17 13:08:02 gordian kernel: [4294678.334000]  VP_IDE: port 0x0170 already claimed by ide1
<fabbione> probably this one
<fabbione> the kernel buffer is too short for this box
<BenC> yeah, looks like ide-generic took it :/
<BenC> fabbione: dmesg -s70000
<fabbione> no problem.. i can test after i finish the last test build for niagara .15
<BenC> default dmesg buffer is too short
<fabbione> i did look at kern.log
<BenC> ah, ok
<fabbione> same story
<fabbione> Feb 17 13:08:02 gordian kernel: No module symbols loaded - kernel modules not enabled. 
<fabbione> Feb 17 13:08:02 gordian kernel: ors (120034 MB)
<fabbione> Feb 17 13:08:02 gordian kernel: [4294672.993000]  SCSI device sda: drive cache: write back
<fabbione> this is the first useful thing i get in kern.log
<BenC> I still think that's a udev issue, but according to one report I have "ide-generic only gets loaded if the rootfs isn't found after loading other ide modules"
<fabbione> i think i overexagerated with hw on this box
<BenC> but that conflicts with what I see on your system
<fabbione> yes.. i will try and let you know by tomorrow
<fabbione> or later
<BenC> ok
<fabbione> but if it is ide-module....
* fabbione searches for Keybuk home address...
<BenC> lol
<fabbione> somebody will wake up with a dead horse head in the bed...
<HiddenWolf> mjg59: ping
<mjg59> HiddenWolf: Hi
<HiddenWolf> mjg59: since that resume magic, my mouse seems to sometimes give two events when clicking, instead of one
<HiddenWolf> or rather, sometimes I get a doubleclick result for the price of a single click
<mjg59> HiddenWolf: No idea, I'm afraid
* Treenaks thinks HiddenWolf's mainboard is b0rked
<HiddenWolf> Treenaks: nforce4-based crap. :)
<ploum_> what is this "I want a pony" on the fridge ?
<ploum_> (It's quite funny but I don't really understand :-) )
<jpatrick> ploum_: http://fridge.ubuntu.com/files/no-pony-for-you.jpg ;)
<ploum_> jpatrick, but why ?
<jpatrick> no idea
<ploum_> I waaaaant a ponyyyyyyyyy !
<ploum_> (or at least a swallow)
<HiddenWolf> mjg59: again, Hi. I had some trouble modprobing modules after my hibernate-adventure.
<HiddenWolf> mjg59: udev loads the wrong driver for my tv-card, usually a modprobe -r modprobe set of commands fixes that. This time I had to reboot to make the kernel listen.
<siretart> mjg59: your're my hero. acpi-support 0.59 seems to fix my usb resuming problems (bug 29634). I wonder how unloading and reload usb modules can be harmful
<Ubugtu> malone bug 29634 in linux-source-2.6.15 "usb dead after hibernate/resume on Thinkpad R40-2772-B3G" [Normal,Fix released]  http://launchpad.net/bugs/29634
<siretart> is the version number coincidence with your nick? ;)
<HiddenWolf> siretart: probably a kernel fighting with acpi problem. :P
<mjg59> HiddenWolf: Almost certainly not my bug
<HiddenWolf> no, I should spank keybuk. ;)
<HiddenWolf> mjg59: but it behaves differently after reboot than on resume
<HiddenWolf> that is odd
<Treenaks> HiddenWolf: did you upgrade your kernel between tries? :)
<HiddenWolf> Treenaks: no
<somervil> im getting "Software lockup detected on CPU#0" while Enterprise Volume Management is attempting to start. Im running latest dapper. This happens with 2.6.15 i386;i686, and 2.6.14 on a Dell inspiron 8600 (pentium M)... anyone seen similar ?
<somervil> ...erm not sure if this question belongs here or in #ubuntu...
<Kyral> Kamion: Mind if I help with the Espresso docs?
<simira> I try here, since #ubuntu seems to be of no help
<simira> can someone help me make java work with Opera in Ubuntu?
* trappist glances at the topic
<sebest> is it just me or the top right menu is broken on http://fridge.ubuntu.com/ with firefox?
<HiddenWolf> it is, and has been for a while
<Treenaks> works fine for me
<HiddenWolf> jdub: ^^^
<Treenaks> (Upcoming Events, right?)
<HiddenWolf> Treenaks: main menu button bar is at the bottom of the screen for me.
<Treenaks> oh the TABS
<Treenaks> :P
<sebest> the tabs yes
<HiddenWolf> Around Breezy at 2Gbit/s
<sebest> for me it always stay at the bottom of the page
<sebest> when i resize the page, but not when i scroll
<HiddenWolf> for me it is around the height of the card picture, and stays there.
<Hieronymus> My wireless network card doesn't work anymore in dapper. (It worked with 5.10) on what package should I file a bug?
<Kyral> what kind of card
<Kyral> wait..I thought I was in #ubuntu
<LaserJock> doko: ping?
<mae> is gnome 2.14 going to make it into dapper?
<Kinnison> by definition, yes
<mae> neat :)
<Kamion> ogra: thanks!
<Kamion> Kyral: sure, there aren't any at the moment ;-)
<Kamion> Kyral: happy to take patches as bzr branches from http://people.ubuntu.com/~cjwatson/bzr/espresso/ubuntu/, or if you want to do it independently, whatever
<Lathiat> mjg59: oh, cool
<Kamion> Kyral: (and unfortunately I have pretty much no time to work on any, but I think I mentioned that before, so help is good)
<LaserJock> who do I need to contact to get a package moved from multiverse to universe?
<LaserJock> Kamion: can you change the repo for a package? or elmo?
<tepsipakki> argh, firefox is killin me... when you scroll the mousewheel rapidly, it goes to a previous/next page depending on the direction
<tepsipakki> +g
<tepsipakki> since when has it done this?
<Kamion> LaserJock: I can - what's the package, and why?
<Kamion> (BTW the term is "component")
<LaserJock> Kamion: sorry for the lack of proper terminology. ggobi was moved from non-free to main in Debian a while ago because it was relicenses under GPL. It should be moved from multiverse to universe I belive.
<LaserJock> Kamion: see http://packages.qa.debian.org/g/ggobi/news/5.html for instance
<Seveas> Kamion, has the CC already picked a date and time for the next meeting?
#ubuntu-devel 2006-02-24
<Kamion> LaserJock: ok, but I'd like elmo to look at that because I'm not sure what we think about clause 4 in that licence which talks about commercial contributors indemnifying all other contributors against legal damages
<Kamion> Seveas: not that I know of - now's not a great time to ask me though, I'm just here to do some cdimage work before going to bed
<LaserJock> Kamion: fine, just wasn't sure how to get the ball rolling ;-)
<Lathiat> hrm, any reason the installer no longer just goes ahead and starts booting after a timeout?
<Seveas> Kamion, ok, I'll poke the 4 of you via e-mail 
<Lathiat> hrm, does windows store the system clock in UTC?
<Lathiat> bad to reocmend setting the system clock to UTC in the installer as im fairly sure windows doesnt do that, whichl make for some rather confused people as the times flip around?
<wasabi_> it's determined if windows exists i believe
<Kamion> Lathiat: various people requested me not to, see ubuntu-devel@ archives
<Kamion> it's good for the live CD but turns out to be not so good for the install CD
<Kamion> yes, clock-setup checks whether MS-DOS/Windows/FreeDOS is installed and defaults to non-UTC if they are
<Kamion> if there are other operating systems installed that it's not sure about, it asks you
<Lathiat> Kamion: ok, well i have windows and it didnt work then
<Lathiat> on ntfs
<Lathiat> and i set it to mount
<Lathiat> and it suggested UTC
<Kamion> if there are no other operating systems installed, it defaults to UTC
<Kamion> Lathiat: please file a bug on clock-setup and attach /var/log/installer/syslog
<Lathiat> also, whats the logic behind that?
<Lathiat> if they install another linux or windows later..
<Lathiat> hrm
<Kamion> UTC is a LOT easier to deal with for all sorts of reasons
<Kamion> there are an amazing number of bugs caused by this braindead history of having the system clock in local time (and thus having to deal with DST)
<Lathiat> Kamion: whats the subject on u-d ?
<Kamion> sorry, don't remember
<Kamion> search for gfxboot I guess
<Kamion> or Flight CD <mumble>
<Lathiat> Kamion: ah so like your never quite sure if the time is DST or not?
<Lathiat> we had a good one here in australia
<Lathiat> they extended DST by a week
<Lathiat> for the <something> games
<StevenK> Commonwealth
<Lathiat> i had an email to bur.st support the other day asking us to update our tzdata file so his date was right :P heh
<Kamion> yeah, and you don't want that sort of logic having to be in the BIOS
<Kamion> Lathiat: http://kitenet.net/~joey/blog/entry/is_your_hardware_clock_set_to_gmt-2005-07-25-02-52.html explains some of the pain involved here
<Lathiat> cheers
<Mithrandir> hi Lathiat 
<Kamion> Lathiat: anyway, probably os-prober failed to detect Windows properly on your system or something, hence the request for a bug report so I can see what's going on
<Kamion> might be the old bug that os-prober doesn't deal very well with detecting operating systems on filesystems that are mounted
* Lathiat nods
<Lathiat> what information do you want?
<Lathiat> i guess i'tl be interesting to see if it rocks up in grub
<Kamion> 23:16 < Kamion> Lathiat: please file a bug on clock-setup and attach /var/log/installer/syslog
<Lathiat> ah, sorry
<Lathiat> i assume that will be there after reboot?
<Kamion> yeah
<Kamion> it's /var/log/syslog before reboot
* Lathiat nods
<Kamion> not world-readable after reboot though, you'll need to use root privileges to extract it
* Kinnison tries not to play with bibble while the batchconvert is in progress
<Lathiat> bibble?
<Kinnison> raw photo manip' software
<Kinnison> currently evaluating it
<Kinnison> possibly to buy a licence
<wasabi_> breezy->dapper upgrade on my mythtv box hosed my initrd
<wasabi_> heh
<wasabi_> and I can't get the grub console to appear. =/
<Kinnison> 19862 dsilvers  16   0  647m 537m 8776 S 73.5 53.6   3:48.02 bibblepro
<Kinnison> ouch
<Kinnison> gotta give it kudos for using all the ram it can
<Lathiat> Kamion: is it interesting that winxp is in the grub menu?
<Kamion> Lathiat: somewhat, but that information should be in the syslog too
<Lathiat> also, gah at that synaptics bug
<sebest> hi lathiat ;)
<Kamion> Lathiat: fixed, I think
<Kamion> clock-setup.postinst said cat instead of echo - d'oh!
<Lathiat> ah
<Lathiat> sebest: hey :)
<sebest> lathiat: i just tried xgl/compiz on my old p3 and was really surprised!
<Lathiat> sebest: yeh Xgl is pretty nuts
<Lathiat> thats what you ge tfor using hw accel
<sebest> i was surprised that compiz works so well on a 750Mhz and a gforce 4 mx
<Kamion> Lathiat: was blindingly obvious once I saw the syslog - thanks for that!
* Kamion -> bed
<Lathiat> Kamion: cya :)
<mpt> fabbione, ping
<incinerator> ah, df 4 is out :-)
<Kamion> incinerator: please don't rush to download it yet, it's currently just up for the mirrors to grab
<incinerator> torrent ok?
<Kamion> I'll announce it in the morning
<Kamion> I guess
<incinerator> ksznom
<Kamion> always wise to wait for the release notes to be posted though
* Kamion is constantly amazed at how many people must sit hitting reload on http://cdimage.ubuntu.com/releases/dapper/ ;-)
* Lathiat laughs
<Lathiat> lots :)
<incinerator> bah
<incinerator> i was just looking for the daily dvd but it would not download
<incinerator> then i decided to go for df 3 and saw that df 4 was out
<incinerator> but thanks
<Kamion> heh
<Kamion> szvesen
<incinerator> i only speak a tiny but magyarul, though
<incinerator> ;-)
<Kamion> likewise
<incinerator> but i recognised the nick *ggg*
* LaserJock ponders how many people would consider cron job to check for flight 4 ;-)
<Kamion> my nick is not Hungarian *shrug*
<Kamion> just a coincidence
<Kamion> anyway, really bedtime now
<incinerator> hehe
<incinerator> Kamion means lorry in Hungarian btw
<incinerator> *ggg*
<Kamion> yeah, I'm familiar with the meaning in a number of European languages
<Lathiat> yugh im having some nasty regressions on my laptop
<Lathiat> i cant even stop gdm
<Lathiat> the screen freezes up
<Lathiat> nor does suspend work
<mjg59> Lathiat: What have you done?
<Lathiat> mjg59: stock install
<Lathiat> on my precision m20
<mjg59> Ah, ok
<Lathiat> does anyone here have a synaptics touchpad?
<Lathiat> like a real one
<Lathiat> not an alps
<mjg59> Yup
<mjg59> Not to hand, though
<mjg59> Can check it tomorrow
<Lathiat> was gonna say
<Lathiat> can you try set the minspeed/maxspeed
<Lathiat> to 0.49, 0.63 and tell me how it affects synaptics
<Lathiat> does it make it super fast
<Lathiat> i'll email it to you?
<Lathiat> cus that seems about the right value on alps
<mjg59> Ok
<mjg59> Yeah, alps was really slow
<Lathiat> yeh
<Lathiat> its driving me up the wall
<Lathiat> i just patched the driver to that and it works nice
<Lathiat> want to see what affect it has on synaptics
<Lathiat> and if we have to differentiate between the two
* Kinnison heads off to bed now
<Lathiat> mjg59@ubuntu ?
<mjg59> @srcf.ucam.org
<Lathiat> cheers
<Lathiat> im off too, cyas
<sebest> mjg59, i submitted a bug (and its fix) about compiz (bug 31929)
<Ubugtu> malone bug 31929 in compiz "compiz needs glitz >= 0.5.3 for some nvidia gforce 4 mx " [Normal,Unconfirmed]  http://launchpad.net/bugs/31929
<Seveas> speaking of compiz, mjg59, I'm about to upload a debdiff to malone that splits out gnome/kde specific files
<LaserJock> Seveas: I believe hub is working on that as well
<esac> on breezy and dapper , during the install process, i select my wireless card (ath0). the weird part is that it is never able to get a DHCP address, i always have to set it up manually.  once ubuntu is installed, it gets a dhcp addy just fine. is this broken, or something i have to configure on my end ?
<LaserJock> esac: you should probably try #ubuntu as this is not a support channel.
<sebest> speaking about gnome-window-decorator, it seems that xeyes can make it crash in some conditions
<sebest> what is the wnck applet?
<Chipzz> Seveas: I just made a couple of my own changes to compiz too... if you want to take a look?
<Seveas> Chipzz, no 
<Seveas> if you think they are needed in the compiz package: file bug & attach patch
<Chipzz> Seveas: inclusion of opacity plugin, and removal of *.la and *.a from the packages
<sebest> Chipzz , do you use compiz right now?
<Chipzz> yes
<sebest> could you try this: for i in `seq 1 20` ; do ( xeyes & ) ; done
<sebest> then killall xeyes
<sebest> it always produce a crash in gnome-window-decorator for me
<sebest> glibc detected *** corrupted double-linked list
<sebest> with assertion abou WNCK_IS_CLASS_GROUP
<sebest> and also the xeyes don't expose (F12)
<Chipzz> yups, lots of stuff crashes when killing xeyes
<sebest> yes wnck applet and other things
<sebest> it only happens when there is "enought" xeyes for me
<sebest> for example 10 is not enought
<sebest> 20 is ok
<sebest> a problem with a link list
<mae> will glitz/xcomposite and all that nice stuff make its way into dapper?
<mjg59> It's in dapper
<mae> mjg59: but i mean enabled by default with accelerated cards?
<mjg59> No
<mjg59> It's nowhere near ready
<mae> omg
<mae> i just got compiz going
<mae> this is so wicked
<tseng> i think you meant #ubuntu-xgl
<zakame> morning all :D
<LaserJock> hi zakame 
<Kyral> There is seriously an #ubuntu-xgl channel?
<sladen> Kyral: it's where all the bling-bling crackheads are
<Kyral> sladen: I just tried it because someone sent the email to -devel-announce ;P
<Aegir> Mmmmm... crack...
<Kyral> Its....interesting
<Kyral> until I realized that I couldn't play my anime lol
<bmonty> elmo: please sync gausssum from debian unstable
<bmonty> elmo: please sync freewheeling from debian unstable, ok to drop ubuntu changes
<bmonty> elmo: please sync biococoa.app from debian unstable, ok to drop ubuntu changes
<bmonty> elmo: please sync slime from debian unstable
<monzie> hi all
<monzie> Is there any way to install the Ubuntu 5.10 live cd?
<monzie> or should i use GNOPPIX instead?
<zakame> hmm, any reason why not install using the Install CD?
<monzie> yup, zakame
<monzie> I did it at my college demo , installed knoppix onto HD while browsing net and listening to musci
<monzie> music
<monzie> makes for a great  demo of linux
<monzie> any solutions?
<zakame> hmm I dunno, anyone care to enlighten?  I hear ubuntu-express should do this one
<LaserJock> well, that is certainly the target for dapper, but at this point I don't know how stable/bug free it is
<LaserJock> espresso is what it is called, I believe
<LaserJock> I think Flight4 will be released soon. It might be usable for that purpose
<LaserJock> But I would hate to have you show how cool Ubuntu is and have it eat your hard drive or something so I would take to people who know what there doing, which is not me ;-)
<sajid> hi
<sajid> any one is here
<neoxan> yeeah
<sajid> hi dear 
<neoxan> hi baby
<sajid> hi
<neoxan> hi baby
<sajid> yem 
<sajid> me fine 
<sajid> and u
<neoxan> :D
<neoxan> also
<sajid> nice to see u
<neoxan> (:
<sajid> where from u
<neoxan> germany, u?
<sajid> ok
<sajid> me also
<sajid> but know a days not
<sajid> know me in pakistan
<sajid> but my othere family live in there at Germanyu
<neoxan> :)
<neoxan> nice =)
<sajid> stuttguard
<neoxan> stuttgart
<neoxan> ^^
<neoxan> :D
<sajid> me elder brothere lives there
<neoxan> hehe
<sajid> what hee heee
<neoxan> this is the ubuntu developer channel ;)
<sajid> channel
<neoxan> but i dont care, youre nice ;)
<sajid> why
<sajid> he are u there
<neoxan> what?
<sajid>       i mean are u busy
<sajid> where  u live in Germanyu
<neoxan> in gelsenkirchen
<neoxan> nrw
<neoxan> near colongne
<sajid> ok
<sajid> how is stuttguard from there
<neoxan> oh, i dont know ;)
<neoxan> some kilometers
<sajid> ok
<neoxan> many^^
<sajid> are u Duetch
<sajid> or 
<neoxan> yeah 
<sajid> nice to see u
<neoxan> :)
<sajid> german people are very nice
<sajid> i like them
<neoxan> nah, not all
<neoxan> like every people
<sajid> they are dont tell lie
<neoxan> lol
<sajid> they are handsome
<neoxan> wtf ;)
<sajid> and love each othere
<sajid>  as i know
<neoxan> nah, i dont
<neoxan> im not proud of germany
<sajid> what do u think about my veiws
<sajid> ok
<sajid>  thats good that you are not proud
<neoxan> veiws?
<sajid> remarks
<neoxan> dunno what that means, sorry :)
<sajid> ok
<sajid>  leave it
<sajid> what is Fenchel tea
<neoxan> fennel tea
<sajid> i think it is for babies
<neoxan> i dunno, could be
<sajid> ok
<sajid> what is the meanig of bekommlich
<neoxan> digestible
<sajid> ok
<neoxan> gonna watch a movie now :)
<neoxan> was a nice talk with you
<sajid> because some food has sent to me from my brother for baby
<neoxan> cya
<sajid> so i have discusing u
<sajid>  ok  what is Wirkstoff
<neoxan> agent
<sajid> i think i have boring you
<neoxan> no :)
<neoxan> its ok
<neoxan> nothing to do anyway ;)
<sajid> nive to see u 
<sajid> what do u do
<neoxan> compiling stuff
<sajid> clear it
<sajid> i dont no
<sajid>  hi
<sajid> are u busy
<neoxan> no :)
<sajid> ok
<sajid>  i wana add u in messenger list
<neoxan> what messanger?
<sajid> if u like
<sajid> chat list
<neoxan> yeah, what kind of?
<sajid> for future chating
<neoxan> jabber, icq, msn?
<sajid> teel me your chat id
<sajid> yahoo
<sajid> if so
<neoxan> i dont have yahoo messanger :(
<sajid> ok
<sajid> tell me icq and msn
<neoxan> 275648273
<neoxan> icq
<sajid> ok
<sajid> send me your telephone no
<neoxan> telephone? lol
<neoxan> why?
<sajid> i wil tell me brother who 
<sajid> will contact with u
<sajid> just a friend
<neoxan> lol, no, sorry
<sajid> who live there
<neoxan> i dont give my telefone number to anyone on the net ;)
<sajid> ok
<sajid> but like to
<neoxan> hehe
<neoxan> how old are you? :-)
<sajid> ok
<sajid> 
<Mithrandir> please take this discussion elsewhere, it's not related to Ubuntu development
<neoxan> i thought so Mithrandir
<neoxan> ;)
<sajid> ok tel me ab+ut Ubuntu
<Mithrandir> sajid: that's also offtopic for #ubuntu-devel; please ask user support questions in #ubuntu.
<TheMuso> /c/
<sajid> ok
<sajid> hi
<neoxan> :(
<neoxan> this guy was so coo
<neoxan> l
<neoxan> lol
<infinity> Kamion / mdz / elmo: Can someone NEW the nm-applet binary (from the network-manager source) s'il vous plait?
<Kamion> nm-applet should surely replace network-manager
<Kamion> (from before it was split out)
<Kamion> damn, missed the publisher
<infinity> Does it not?
<mae>  i have a bug to report but i am unsure how to use malone, can someone walk me through it?
<Kamion> infinity: nope, filed a bug
<infinity> I'll just fix it and upload right now.
<infinity> Bug #?
<Kamion> mae: https://launchpad.net/distros/ubuntu/+filebug, enter affected package name, one-line summary of bug, longer description of bug
<Kamion> infinity: 31961
<Kamion> Ubugtu: bug 31961
<Ubugtu> malone bug 31961 in network-manager "nm-applet should Replace network-manager from before package split" [Normal,Unconfirmed]  http://launchpad.net/bugs/31961
* infinity goes back to weekending.
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development (not support, even with dapper) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | Flight CD 4 released | If your initramfs is broken in any way, please save a copy for infinity
<Kamion> (topicdiff: flight-4 done)
<Kamion> release announcement should be in the ubuntu-announce@ moderation queue RSN
<Kamion> jdub: if you could wave it through quickly, I'd be grateful
<jdub> Kamion: ok
<Kamion> ta
<Kamion> ha, I knew doing this in the early morning UTC was a good plan
<jdub> Kamion: i'm in spain ;-)
<Kamion> oh well ;)
<Lathiat> mjg59: why do we have both g-p-m and the battery applet?
<Lathiat> mjg59: also "when laptop lid is cosed: suspend" doesnt seem to work, and it does detect lid events on this, and blanks the screen
<Lathiat> mjg59: known?
<Kamion> ok folks, that's two out of two NEW packages I've looked at this morning that don't use Replaces properly
<Kamion> simple rule of thumb: when you move a file from package a to package b, b should Replaces: a (<< version-where-the-file-was-removed-from-a)
<Kamion> remember this every time you move a file and a class of annoying bugs goes away
<infinity> Kamion: Given that n-m was done by keybuk, I can only assume he "just forgot"... I'd hate to think the (former) dpkg maintainer doesn't how how to use "Reaplces" properly. :)
<j^> would be nice if the olpc-sdk would be packaged for ubuntu (http://people.redhat.com/berrange/olpc/sdk/ | http://people.redhat.com/berrange/olpc/sdk/SRPMS/)
<Kamion> infinity: yeah. doesn't apply to compiz though ...
<fabbione> hey guys
<Mithrandir> Kamion: unless you depend on a new enough version of package a, though.
<fabbione> hey jdub
<jdub> yo!
<infinity> Mithrandir: That would work with nm-applet/network-manager, except the dependency wasn't made versioned.
<Mithrandir> infinity: then you lose, yes.
<infinity> s/you lose/Keybuk loses/ ;)
<Mithrandir> well, true.
<TheMuso> c
<Mithrandir> infinity: can we please get rid of the silly "thunderbird profile manager" from the menu? it's annoying and I hit that instead of tbird half the time.
<Treenaks> Mithrandir: switch to mutt :P
<mdke> it's about the most inconsistent menu entry with MenusRevisited
<infinity> Mithrandir: Yeah, I need to make it visible in my menu again as a reminder to remove it.
<Mithrandir> Treenaks: mutt sucks.
<pitti> Kamion: congrats for flight 4!
<aquarius> Does Ubuntu have something like dehs.alioth.debian.org where I can get watch files for packages without downloading every package?
<Treenaks> aquarius: uh...
<Treenaks> aquarius: I don't know :)
<Treenaks> aquarius: there's packages.ubuntu.com...
<aquarius> packages.ubuntu.com doesn't list watch files as far as I can tell; it does list copyright files, which I also need and which I intend to use it for :)
<mdke> so are mounted drives going to stay off the desktop from now on?
<jsgotangco> how are we going to unmount them?
<lmanul> There's a bug about this
<lmanul> I'm sure this was really a decision
<mdke> jsgotangco's question is the key one
<mdke> you can't expect users to go to Computer every time they want to take out a pen drive
<jsgotangco> unless it automagically unmounts when something is removed (ie, a USB)
<mdke> i don't think that is possible, is it? you have to unmount if before removing it
<dholbach> not necessarily, syncing is more important than unmounting before removal :)
<jsgotangco> yes since removing is a physical action that the computer will only be aware of after it is done
* mdke doesn't know much about it
<lmanul> malon bug 28991
<Ubugtu> malone bug 28991 in nautilus "drives icons on the desktop for dapper?" [Normal,Confirmed]  http://launchpad.net/bugs/28991
<mdke> but I was always told I was risking data loss by removing drives without unmounting them
<mdke> thanks lmanul 
<jsgotangco> dholbach, so its safe to remove? even windows *warns* you not to do that without unmounting
<dholbach> if you run sync(1) before, it relatively is
<dholbach> I was a bit shocked, when I saw mvo doing this the first time :)
<jsgotangco> so how will a user do it?
<dholbach> it's better for them to unmount, clearly
<mdke> dholbach, so do you know if the change was intentional or not?
<jdub> jsgotangco: with sync (and preferably flush in future), it's safe to pull
<dholbach> mdke: I'm afraid, I don't know.
<mdke> ok
<jsgotangco> ahh
<jsgotangco> ok so what's the deal with Ebuntu? =)
<mdke> jsgotangco, it is a derivative based on e17, i think.
<dholbach> If they don't get their stuff in the archive, they won't be a 'official sister project' - it won't happen for Dapper, I pretty much guess.
<jsgotangco> dholbach, ok so i saw his blog today
<mdke> i don't think e17 is stable yet, is it?
<dholbach> I think, it's a CVS version
<dholbach> jsgotangco: what does it say?
<jsgotangco> 2) SphinxLinux has now been renamed Ebuntu, and will now be a derivative of Ubuntu Linux. It is expected to get official recognition, infrastructure and monetary support from Ubuntu. Have a look at it's wiki page for all the details.
<mdke> pretty unlikely to get in the archive then
<jsgotangco> 3) I am now an official developer for Canonical , the company behind Ubuntu. I dont get paid (it's open source honey) but i do get my own page at Launchpad  (Launchpad is where all Ubuntu development happens)
<mdke> odd chap
<jsgotangco> 1) I became a member of the GNOME Ubuntu team . There are only 14 such people in the world.
<jsgotangco> I basically get to decide (along with the others) what makes and does not make it to GNOME for their next release
<tseng> hey cool, i have a launchpad page too
<dholbach> It's nice he gets excited about Ubuntu development like that.
<jsgotangco> i dunno he probably was one of those in the audience when sabdfl was in bangalore
<Mithrandir> I don't know of any promises of monetary support, though.
<dholbach> he's monzie on irc, he was hanging around in #ubuntu-motu too
<jsgotangco> Mithrandir, i dunno, when you get to see his dad though, you might consider it
<Mithrandir> jsgotangco: how so?
<jsgotangco> http://www.flickr.com/photos/manish_chaks/100091144/
<mjg59> Kamion: Ok to break UVF for glitz? (Needed to make Xgl work on a pile of nvidia and ATI stuff, nothing in the archive rdepends on it)
<ivoks> same question for ganglia
<ivoks> it seems that ganglia in universe is very outdated :/
<tseng> ivoks: universe uvf requests go to ubuntu-motu list
<ivoks> tseng: i know :)
<ivoks> tseng: thanks for reminding me
<tseng> ivoks: nice try
<zakame> ooh beowulf stuff
<sivang> mjg59: can we make a package with some default stuff like http://www.ubuntuforums.org/showthread.php?t=131253 instructs, that is modify gdm, add teh correct plugin loading order to gconf etc.., making a no hacking at all deb
<mjg59> sivang: Nope
<mjg59> Packages shouldn't screw with configuration belonging to other packages
<mjg59> The gconf thing /should/ be simple, since it's just a gconf schema
<mjg59> Except the gconf code in compiz is mad
<sivang> mjg59: I see
<sivang> mjg59: indeed those configuration changes are very simple, even for the inexperienced, so guess they could stay until more stable support is put into xgl first.
<xhaker> hi all
<xhaker> /usr/sbin is not in an user's PATH in dapper?
<Spastjeh> why should a sysadmin path be in a normal user path?
<Spastjeh> ok nm... i'm new to ubuntu :p
<Kyral> xhaker: What are you talking about, I just echo'd my $PATH and /usr/sbin is there
<xhaker> xhaker@dev:~$ echo $PATH
<xhaker> ... /bin:/usr/bin
<xhaker> not sbin
<Kyral> at all?
<xhaker> clean install dapper.. maybe 1 day before flight 4
<xhaker> before this clean install i had sbin in the path and i was using dapper too
<Kyral> I have /usr/local/sbin/:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games/games
<xhaker> wow :S
<xhaker> Kyral: new install?
<Kyral> I dunno I'm running on my Dist-Upgraded install from Breezy back in November ;P
<Kyral> Are you the "priveliged" user?
<Kyral> (ie, a user that can Sudo)
<xhaker> yes i can
<xhaker> sudo has sbin in the path
<Kyral> Dunno
<Kyral> maybe its a new security feature?
<xhaker> Kyral: so i thought
<xhaker> but i wanted somekind of explanation
<Kyral> I dunno, I haven't heard anything about it
<Kyral> then again I have been very busy with school
<xhaker> mt path is very very different than yours :P
<BenC> is there a way to make the desktop cd recording software ignore the data I am trying to burn?
<BenC> It doesn't like the hd image I am trying to burn
<siretart> elmo: please sync 6.4-2.1 from unstable. thanks
<Mithrandir> siretart: it might help if you include a package name
<Mithrandir> rather than just a version.
<siretart> elmo: please sync kdrill_6.4-2.1 from unstable. thanks
<siretart> Mithrandir: argl. right. bad copy'n paste
<slomo> siretart: better write him a mail
<siretart> slomo: I have a quite long list with open merges. I added it to my list, so that I don't miss it at my next batch request
<lucas> siretart: have you got some of your syncs done recently (< 2 weeks) ?
<slomo> lucas: nope... almost no syncs were done in the last 3 weeks
<lucas> ok
<Kamion> xhaker: that was a bug, since fixed in the installer
<Kamion> xhaker: to fix it on your system, run: sudo /var/lib/dpkg/info/libpam-modules.postinst configure ''
<Kamion> mjg59: yes, sounds fine
<Kamion> 09:52 < Mithrandir> Kamion: unless you depend on a new enough version of package a, though.
<Kamion> Mithrandir: you'd need to pre-depend, since file overwrites are checked at unpack time, not configure time
<Mithrandir> true
<mdke> Kamion, I played around a little with https://wiki.ubuntu.com/WikiLicensing/Email, and I'm keen to move along with it if possible. But obviously some of the CC need to look at the wording before we look at sending it.
<mdke> I don't know when the next meeting is, it could be done then, I suppose
<Treenaks> Kamion: Flight 4 doesn't boot, it tells me it can't find /install/initrd.g (without the z)
<HiddenWolf> \o/
<Treenaks> HiddenWolf: ?
<jon_k> i've found a kernel update that has a description of "MOMMY MOMMY! Soyuz eated my previous upload!! MOMMYYYYY!!!!!"
<jon_k> any idea if this is a compromise?
<HiddenWolf> jon_k: no, it isn't.
<jon_k> what is it?
<HiddenWolf> jon_k: it was misplaced humor on the developer's part
<jon_k> hm, i see
<HiddenWolf> jon_k: a previous upload failed, so he commented on it in his new upload.
<mdke> misplaced?
<jon_k> well, there's nothing wrong with joking, but perhaps people should be serious when it concerns kernel updates
<mdke> is that in breezy?
<HiddenWolf> mdke: it's caused a LOAD of worry, discussion and filed bugs.
<mdke> is that in breezy?
<Treenaks> mdke: yes
<mdke> gosh
<jon_k> never seen such joking for kernel changelogs before
<jon_k> sounds like someone put some nasty stuff in a new kernel and uploaded it, heh
<Treenaks> jon_k: you've never run a development release ;)
<HiddenWolf> jon_k: ubuntu recently switched to a new buildd system
<HiddenWolf> jon_k: I guess the update got lost due to some bug and he had to re-upload
<HiddenWolf> that's all that happened.
<jon_k> ah, so we can expect more funny stuff too?
<HiddenWolf> I'd hope not.
<HiddenWolf> Those bugs will get fixed, and that humor has no place in a -security upload. at least in my humble opinion.
<jon_k> heh
<jon_k> well Treenaks seems to have suggested it's commonplace with his comment
<jon_k> heh
<HiddenWolf> jon_k: in development versions, yeah
<Treenaks> jon_k: in the development release, people tend to put in all kinds of weird statements in the changelogs
<Treenaks> jon_k: but you have to be careful with security uploads :)
<HiddenWolf> this is the upload, right? https://lists.ubuntu.com/archives/ubuntu-security-announce/2006-January/000279.html
<HiddenWolf> Why aren't they on -changes?
<dholbach> HiddenWolf: to me this seems to be the announce, not the upload
<HiddenWolf> I can't find the actual upload
<HiddenWolf> upload / changelog
<HiddenWolf> and the announce I posted is the latest linux vunerability posted to the list
<^rob> hey all, I saw the screenshots posted up for UbuntuExpress and noticed that hostname is present when it is not on the mockups, was this intentional?
<maswan> ooh, some demand for flight-4
<maswan> Kamion: root@tutankhamon[pts/0] :~# currenthttpxfers | grep -c flight-4
<maswan> Kamion: 34
<maswan> Kamion: then multiply by four for our four frontends and you have approximately the number of current downloads
<siretart> gnarf. anyone knows a lazy mirror for jigdo'ing flight4?
<siretart> I'm only missing a few files related to ltsp and xserver :(
<sivang> rehi all
<Treenaks> Nobody else is having problems booting Flight 4?
<siretart> Treenaks: I just booted flight4 on x86. the machine showed me bootsplash and all (gnome didn't start because it was just a 64mb machine)
<Treenaks> siretart: hm.. when I try to start, I get an error about '/install/initrd.g' not being available
<Treenaks> siretart: (note: not .gz)
<^rob> ok hostname in ubuntu express is filed at https://launchpad.net/distros/ubuntu/+source/ubuntu-express/+bug/32010
<Ubugtu> malone bug 32010 in ubuntu-express "should not contain hostname field" [Normal,Unconfirmed]  
<Mithrandir> Treenaks: what arch?
<Treenaks> Mithrandir: i386
<Treenaks> I'm re-burning now (3rd time)
<kbrooks> does anyone here know what dapper+1 will have
<Treenaks> lots of crack :)
<kbrooks> 6.04, 7.10
<kbrooks> no. wait.
<Mithrandir> 6.10, rather
<kbrooks> 6.10, 7.04
<kbrooks> yes thank you very much
<ploum> kbrooks: yes : GNOME 2.16
<Treenaks> ploum: you win :)
<kbrooks> ploum, i wonder when 3.0 will come out
<ploum> kbrooks: after 2.98
<ploum> of course
<ploum> then it will be april 2047
<ploum> But it will rocks..
<lemsto> is there a way in gnome to asign an application to a desktop? for example, all new firefox windows will be launched in desktop 3...
<lemsto> if its not possible, thats an idea of new feature :p
<ploum> lemsto: I've already such a feature request
<lemsto> ploum, so isn't possible yet?
<ploum> Someone on pgo talked about a program that does this work
<winkle> metacity doesn't support it, other wms does...
<ploum> I'm not sure
<winkle> i doubt metacity will target such a feature..
<lemsto> have you a link about any project for gnome?
<ploum> lemsto: I'm searching  (don't you see the little magnifier animation ? ;-) )
<lemsto> hehehe
<Treenaks> Mithrandir: (burn #3, md5sum match, no boot: 'Could not find ramdisk image /install/initrd.g')
<ploum> lemsto: try this http://ubuntuforums.org/showthread.php?t=75749  I'm not sure it's what you want but it's the only thing like this I know
<lemsto> ploum, ok! thank u
<jdub> lemsto: look into devilspie
<aquarius> lemsto: devilspie will do that sort of thing.
<aquarius> oh, that'll teach me to pay more attention
<lemsto> thanks all
<ploum> it was indeed devil's pie I was talking about
<ploum> jdub: is it possible to already have an ubuntu-be mailing list ?
<Treenaks> ploum: when's your talk again? and are -nl people allowed in? :P
<ploum> Treenaks: of course !
<ploum> I will be very pleased to meet other ubuntu people !
<ploum> I will even try to speak in dutch
<ploum> (so it can be funny)
<ploum> https://wiki.ubuntu.com/BelgianTeam : Sat 25 feb at 14h, Room H3227 or H3228 
<Treenaks> http://webdemo.ns.nl/e2000.html :)
<ploum> Treenaks: will you make some more moviegotchi at FOSDEM ?
* ploum like them a lot !
<Treenaks> ploum: good idea!
<Treenaks> ploum: I still need to find a place to sleep though :(
<ploum> Treenaks: ok, I will look
<ploum> Maybe you can sleep in my "kot"
<Chipzz> ploum: you're belgian too? :)
<ploum> Chipzz: yes
<ploum> so are you ?
* Chipzz from Leuven
<ploum> Chipzz: please read  https://wiki.ubuntu.com/BelgianTeam :-)
<ploum> I'm from Louvain-la-Neuve
<Chipzz> ploum: I'll see if I can make the meeting, but I'll be running around with a "staff" tshirt ;)
<ploum> I see
<Chipzz> network and stuff :P
<jdub> ploum: don't worry, i'll blindfold and steal him :)
<Chipzz> hi jdub :)
<ploum> Chipzz: I will have a tshirt with "I was your annoying interviewer !"
<ploum> :-D
<Chipzz> ploum: *grin* :)
<ploum> jdub: Thank you for coming. I didn't tell it to the others. Can you make an apparition with smoke, light and all that sort of things ?
<ploum> with a voice coming from the grave telling : "and now ladies and gentlemen, the fearless, the hairless, the sleepless MARK SHUTTLEWORTH" 
<ploum> uh..
<ploum> no
<ploum> Jeff Waugh
<ploum> that's it !
<jdub> i will try to eat something that makes me gassy that day
<Kamion> Treenaks: sorry, absolutely no idea why that might be happening
<Treenaks> Kamion: hmm..
<Treenaks> Kamion: could it be a different manifestation of the bug where the 'boot from hard-disk' disk wasn't detected correctly?
<sebest> ploum: hello, any update on bug 6260 ?
<Ubugtu> malone bug 6260 in network-manager "network-manager breaks avahi" [Normal,Unconfirmed]  http://launchpad.net/bugs/6260
<Kamion> Treenaks: can't imagine how
<Kamion> Treenaks: have you tried editing the command line to see what it looks like?
<Treenaks> Kamion: yes (F6, right?)
<Treenaks> Kamion: that looks OK
<ploum> sebest: indeed, it's avahi 0.6.7
<sebest> ploum: and is it with wifi?
<ploum> yes
<sebest> only?
<ploum> yes, wifi only
<sebest> just to introduce myself, i'm an avahi dev, so i'd like to fix this issue
<ploum> Oh, I understand :-)
<sebest> so i'm trying to track the issue, because i'm als using nm (with ipw2100) and i can't reproduce this issue :)
<sebest> so i'm trying to find if it's related to a driver or a bug in avahi / nm
<Kamion> Treenaks: er, whatever key is listed for "Other Options", I think it's F5
<Kamion> Treenaks: and what if you edit that to add an extra random character to the end of the initrd= argument?
<sebest> ploum: does avahi crash or just stop "announcing/browsing" ?
<Treenaks> Kamion: trying, brb 
<sebest> ploum: it would be great, if you could run avahi-daemon in debug mode in a console, just issue "sudo avahi-daemon --debug". And some infos about your setup (driver/cards) and how you can reproduce it
<ploum> sebest: how can I test this optimally ?
<ploum> sebest: I will try
<ploum> but I must reinstall NM
<sebest> ploum: with the cli tool avahi-browse -a you can test that avahi-daemon is browsing
<sebest> avahi-publish allows you to publish some test services
<ploum> I don't have avahi-browse nor publish
<ploum> (in fact I'm a total newbie in avahi)
<ploum> hm.. NM is not working correctly
<ploum> apt-get install avahi-utils
<Treenaks> Kamion: no luck, when changing that
<Treenaks> Kamion: Server mode boots correctly though (haven't tried OEM)
<sebest> ploum: yes
<sebest> ploum: i'll explain you , it's quite easy
<sebest> in one terminal you run "avahi-browse -a", it will discover all announced services on your lan
<ploum> sebest: done
<ploum> With NM working !
<sebest> do you see any service?
<ploum> I see :
<ploum>  avahi-browse -a
<ploum> + ath0 IPv4 mars [00:11:95:91:97:0d]                       Workstation          local
<sebest>  avahi-publish-service "test service" _test._tcp 1
<ploum> sebest: it appears !
<sebest> this command will publish a fake service
<sebest> if you ctrl+c avahi-publish-service, it should dissapear
<sebest> in avahi-browse
<ploum> yes, I see a "-"
<Treenaks> Kamion: on what should I file the bug (so you can look at it when it's not Sunday evening ;)
<sebest> from this point it seems that everything is working properly
<ploum> so I cannnot confirm the bug anymore, I'm sorry
<sebest> maybe you could try switching to wired
<ploum> Ihave confirmed because the avahi-discover window was empty
<ploum> sebest: I don't have wired connection
<ploum> (too far)
<sebest> you could just cut the wifi connection
<sebest> and put it back
<ploum> with NM ?
<sebest> yes for example
<Treenaks> ploum: just press the 'wifi kill switch' on your machine
<sebest> avahi-browse will display that services dissappear
<sebest> and they should reappear on reconnection automatically
<ploum> I don't have one ;-) I'm on a desktop, not a laptop
<sebest> avahi-daemon, uses netlink to notice when an iface goes up or down
<sebest> ploum: nm dosn't allow to stop the wifi connection?
<ploum> sebest: I understand the thing
<ploum> sadly, it works
<ploum> (absurd humor ;-) )
<sebest> sadly? :)
<Chipzz> sebest: what package is actually responsible for seeing the list of available services in nautilus?
<ploum> sebest: I killed NM then restarted it
<ploum> all is working as expected
<sebest> Chipzz gnome-vfs i think
<ploum> I think my previous problem was due to NM and iface working at the same time on the same interface
<ploum> but NM was upgraded
<Chipzz> sebest: I didn't see a service published on another box before, but after installing avahi-utils I can see it
<ploum> and only work with interfaces not used by iface
<Chipzz> sebest: well, no, because without avahi-daemon avahi-utils libavahi-core3 libdaemon0 I don't see it
<Chipzz> sebest: I'm guessing at least one of these packages is needed on the client side?
<sebest> Chipzz: you need avhai-daemon, libavahi-cores3 and libdaemon0
<sebest> avahi-utils are optionnal cli tools
<sebest> Chipzz yes, you need the client libs and the avahi-daemon
<Chipzz> sebest: aha :)
<sebest> gnome-vfs use the  libavahi
<sebest> when available :)
<sebest> Chipzz, you can use gnome-user-share it uses avahi to publish it's webdav share
<sebest> its
<ploum> the bug that makes me mad about NM : http://bugzilla.gnome.org/show_bug.cgi?id=331529
<Ubugtu> gnome2 bug 331529 in Default "Unlocking gnome-keyring must no be needed at each connection" [Enhancement,Unconfirmed]  
<Chipzz> sebest: nah nevermind, I'm not a newbie :P
<sebest> ploum: i'll close the bug 6260
<Ubugtu> malone bug 6260 in network-manager "network-manager breaks avahi" [Normal,Unconfirmed]  http://launchpad.net/bugs/6260
<Chipzz> sebest: I publish sftp from my storage box
<ploum> sebest: I commented on it
<sebest> ploum : great
<ploum> maybe the initial reporter has still the bug ?
<ploum> I never understanded the "Preferences > Personnal File Sharing" what will be shared ?
<sebest> ploum: i don't think so, because we closed a bug in 0.6.6 really similar to the issue you and he reported
<sebest> ploum: in create a folder "Public" in the home
<sebest> and this folder is shared using webdav and announced on the lan using avahi
<Treenaks> sebest: wow, which packages do I need for that?
<sebest> Treenaks, gnome-user-share
<sebest> it's from alexander larsson
<ploum> sebest: and how can someone access it ?
<sebest> ploum, using nautilus
<sebest> nautilus, will discover and display it in network places
<ploum> sebest: that's cool ! I will try to make it working :-)
<ploum> thanks
<sebest> i think that mac os x will also see it
<Treenaks> sebest: _wow_ :)
<ploum> go to lunch !
<ploum> goodbye
<sebest> ploum: bye ;)
<ploum> see you saturday :-)
<sebest> Treenaks, i just tested, MacOSX see the share
<Kamion> Treenaks: gfxboot will do for starters
<Treenaks> Kamion: OK, thanks
<de_wizze> hello devs, I had an idea and wanted to verify the feasability
<de_wizze> with the current operation of the sound device in *nix OSes it operates on a first come first serve basis
<Treenaks> have you looked at the 'default sound device' dialog in dapper? :)
<de_wizze> no not recently I haven't had it installed yet .. why is it different?
<Treenaks> you can select the 'default' sound device in there now
<Treenaks> and I don;t know for sure, but I think it does stuff with ~/.asoundrc or something (pitti?)
<de_wizze> but what I was saying is a bit different .. is it or could it possible to have the functionality that esd and arts, etc. moved into the kernel space
<de_wizze> mainly the ability to spawn threads for each open() done on /dev/dsp
<ploum> de_wizze: in an ideal world, this functionnality would be in the kernel
<ploum> that's the goal of dmis AFAIK
<de_wizze> efectively removing th concept of dead locks ... right?
<ploum> but if you can convince kernel developpers, I will buy you a lot of beers ;-)
<Treenaks> dmix
<ploum> indeed, dmix
<de_wizze> whats their apprehension ?
<Treenaks> de_wizze: dmix is user-space
<Treenaks> de_wizze: as long as you don't use OSS, it Just Works already
<ploum> Treenaks: but the naughty bit is that some apps use OSS
<ploum> Flash for example
<ploum> and that sucks
<ploum> and ALSA drivers or often very buggy
<Treenaks> ploum: Then those apps need fixing, not the kernel or ALSA or whatever
<Treenaks> ploum: they are? file bugs! :)
<ploum> They are filled ;-)
<de_wizze> yeah ... so alsa does provide that capability ... it just a matter of uptake then ?
<Treenaks> de_wizze: yeah
<Treenaks> basically
<ploum> de_wizze: yes
<de_wizze> and I guess  upkeep as you pointed out
<ploum> but things are really better now than 2 years agor
<ploum> ago
<ploum> really
<de_wizze> yeah I know ...
<de_wizze> I was just wondering why those last few(or not so few) sets of apps still had the same problem 
<de_wizze> tying up the sound device
<ploum> de_wizze: flash because it's proprietary software
<de_wizze> so true ...
<de_wizze> but at lease in the other aspects where there aren't those barriers it good to know that progress is being made 
<de_wizze> keep up the good work :)
<shaya> at-spi seems really messed up
<shaya> causes my dapper gnome desktop to misbehave badly
<dholbach> shaya: What happens?
<shaya> 1) w/ cvs gaim it causes a libc double free error whenever I change away messages
<shaya> 2) w/ gnome terminal in dapper, it basically causes any "new" tabs opened in gnome-termlnal to hang
<shaya> those are 2 things that I've isolated to at-spi package being installed
<dholbach> shaya: did you file bugs?
<shaya> just filed bug against #1
<dholbach> shaya: file one for the second please too
<shaya> bug 32029
<Ubugtu> malone bug 32029 in at-spi "double free error when at-spi is installed" [Normal,Unconfirmed]  http://launchpad.net/bugs/32029
<shaya> hmm
<shaya> :)
<shaya> didn't know about that bot
<shaya> and now there's a new bug
<shaya> bug 32036
<Ubugtu> malone bug 32036 in at-spi "causes new tabs in gnome-terminal to hang" [Normal,Unconfirmed]  http://launchpad.net/bugs/32036
<shaya> hmm, bugs are filed rapidly
<shaya> 6 bugs filed b/w mine
<dholbach> shaya: is that a complete back trace? what did you trace? could you install back traces?
<shaya> dholbach: no
<shaya> I couldn't redo it
<dholbach> shaya: it isn't reproducible?
<shaya> gdb kept on failing when I tried to redo the baktrace
<shaya> no
<shaya> the bug is
<shaya> gdb'ing fails
<dholbach> hum
<shaya> the bug is very reproducable
<dholbach> how does it fail?
<shaya> "can't attach" or something
<shaya> dont want to install at-spi back onto my laptop right now to test
<shaya> as need to do some real work
<shaya> basically, when I gdb /opt/gaim/bin/gaim
<shaya> it runs
<shaya> then stops with some "thread info" error
<dholbach> shaya: I'll ask some questions on the bug report - it'd be nice if you could follow up.
<shaya> I then "c" it
<shaya> and now it errors it
<shaya> but when I got the backtrace it continued normally
<dholbach> gdb <program>
<dholbach> (gdb) handle SIG33 pass nostop noprint
<dholbach> (gdb) run <arguments, if any>
<shaya> changed away message, and it died w/ the error
<dholbach> that might help
<shaya> I can try later today
<dholbach> Cool. I'll post the information on the bug report.
<dholbach> We'll need to get more information into the bug report, so we can forward it upstream.
<shaya> problem came about because I was testing the at interfaces to try and use it to be a log of everything ones sees while working, "i.e. you read an email, deleted it, but now realize you need it"
<tk401> hello everyone
<tk401> anyone alive?
<tk401> hey hunger
<shaya> dholbach: the error is thread_db_get_info: cannot get thread info: generic error
<shaya> I then cont it and it get
<shaya> Cannot remove breakpoints because program is no longer writable.
<shaya> It might be running in another process.
<dholbach> shaya: even with the instructions I pointed to in the bug report?
<shaya> yep
<shaya> I can try w/o tls
<dholbach> you shouldn't have to continue at all
<shaya> it goes starting program
<shaya> thread debugging...
<shaya> new thread
<shaya> ....
<shaya> a few times
<shaya> then the error
<dholbach> hmmmm
<dholbach> shaya: thanks - could you follow up with that information on the bug report too?
<shaya> ok
<shaya> done
<dholbach> cool
<setuid> Anyone know why cups/lpr has been broken in Ubuntu? Its lobotomized, and doesn't work at all. 
<setuid> But upstream, unpatched, unmodified cups works flawlessly, of course. 
<shaya> I'm confused by recent changes to network-manager, it seems the patches included w/ it prevent it from seeing my madwifi wireless card?
#ubuntu-devel 2006-02-25
<dholbach> Good night!
<lemsto> i got segmentation faul when i run "deal" 
<lemsto> im using amd64 dapper
<lemsto> (deal: bridge hand generator)
<azeem> lemsto: did you file a bug?
<Burglaptop> lemsto: please report a bug on that. If you have a fix for it, #ubuntu-motu can help you fix the official package
<lemsto> ok, i'll try toreport it
<lemsto> to report*
<SEJeff> If there was a very trivial bug to fix to change the default smb.conf that made samba much easier to use by default, would it be considered for dapper?
<infinity> SEJeff: Are you referring to bug 32067?
<Ubugtu> malone bug 32067 in samba "the security parameter must be set to share, not user, in smb.conf" [Normal,Unconfirmed]  http://launchpad.net/bugs/32067
<SEJeff> infinity, correct. I posted a comment to it
<SEJeff> infinity, I showed jeff fortin how to fix it
<infinity> Yes, I commented on it, too.
<infinity> And "security=share" is not the right fix for this, trust me. :/
<infinity> While people who know what it means are welcome to set it, it should definitely not be the default for every Samba installation.
<SEJeff> I just read the comment. Well is there an "easy" way to make samba work for normal users?
<SEJeff> This took me all of a few minutes to figure out, but I've had 3 people ask me in the past few days
<infinity> # smbapsswd -a $username
<sladen> qemu booted casper from the cloop.  funky goodness
<SEJeff> infinity, So this bug should be filed against the package that creates the "Share Folder" dialog I'm guessing? And would you happen to know that package name?
<infinity> SEJeff: Not sure, actually, but I can reassign the bug and look into it later.
<SEJeff> thanks
<infinity> SEJeff: I see two bugs here, really.  We need to give people UNIX/Samba account mappings by default (which I can look into, if I have time), and that little share box should probably allow you to specify WHO can see the share (right now, it's just open to anyone who has a valid samba account on the box)
<SEJeff> infinity: So it gets pretty fine-grained into the ACL stuff. I don't guess thats dapper material this late in the development cycle
<zakame> noon devs :D
<infinity> It's not rocket science to make the share editor thingee also add "valid users = foo, bar, baz" to the config snippet it creates.
<LaserJock> hi zace 
<infinity> But you're right, given lack of time and feature freeze in a week, it may not be a reality.
<LaserJock> hi zakame I mean :-)
<zakame> hey LaserJock 
<SEJeff> that is sad. Dapper is going to be amazing, I am using flight4 ATM, but it seems like I see the same samba questions over and over
<SEJeff> infinity: thanks again though
<infinity> I'll see what I can do that's minimally disruptive but may help in this case.
<infinity> Just having the share editor do an smbpasswd -a $user on behalf of the user that invoked it would probably be enough of a win here.
<SEJeff> awesome
<infinity> Don't say that until someone gets around to implementing it. :P
<infinity> The problem, in a nutshell, is that SMB users need to set a password independently of system users, because SMB clients send passwords as an MD4 hash.
<infinity> Since you can't compare a hash to anything but a hash (yay), Samba needs to store SMB passwords as MD4 hashes as well, so they can't be in sync with the system passwords.
<SEJeff> and 'nix is des,md5, or blowfish generally, that is no go. Right
<infinity> (Well, they could be if we installed samba by default, and some PAM rules ot update the samba password with every update of the system password, but we don't really want samba installed on all machines)
<SEJeff> no
<infinity> SEJeff: Well, it has nothing to do with what UNIX hashes we use, but that you can't unhash the hash the client sent. :)
<infinity> Typically, other clients (POP, IMAP, SSH, whatever), send the password in clear-text, which we can then hash to compare to your hashed password.
<SEJeff> infinity: right. I understand cryptology
<infinity> Check.  The long and short of it is that the whole thing sucks cause we have n ochoice but to maintain two password databases.
<infinity> Which means that doing the "smbpasswd -a" thing in the share creation dialog would be fine, but it would require asking you to set a password for UserX at the same time.
<infinity> Hopefully, that can be done with minimal effort, and minimal confusion to the user.
<bmonty> kerberos solves the password hash issue
<infinity> Yes, putting your clients in an Active Directory domain fixes a lot of this, but that's not really a practical solution for the little home network where you want to share something with your brother for 2 minutes, either. :)
<SEJeff> isn't kerberos a bit overkill for simple filesharing between a few hosts on a lan?
<SEJeff> infinity, exactly
<bmonty> it is probaly overkill for a 2 minute temporary share, but if you are running a home network, I think it makes sense
<bmonty> it has benefits with other services besides only samba
<SEJeff> bmonty, sso is great for daemons that support it, but are don't they have to be compiled with kerberos support?
<bmonty> SEJeff: yes, the daemon has to be kerberized
<bmonty> some packages need a recompile, but some have kerberos versions in the archive
<SEJeff> bmonty: which makes it nontrivial for an average consumer.
<bmonty> SEJeff: agreed
<akk> Hi -- I'm having a problem with the orinoco driver, trying to figure out how to get the source package on breezy
<akk> but I can't seem to figure out which package it's in.
<akk> Would anyone be willing to help me find the source (or, even better, help me analyze a wifi driver problem)?
<sladen> akk: you probably want #ubuntu-users .   The orinoco source will be in the linux- package
<akk> sladen: Thanks, I'll go there. Someone over in #ubuntu-women suggested coming here first.
<sladen> akk: source apt-get install linux-source
<zakame> afternoon all
* Burglaptop watchs Naaman open a can of worms on launchpad-users
<mpt> yum
<jsgotangco> Burglaptop, ?
<jsgotangco> ohh
<Burglaptop> jsgotangco: Naaman basically asked for the source to Malone, in a package in Ubuntu/Debian
<jsgotangco> yeah i read it
<ajmitch> Burglaptop: well there's still a few days until feature freeze if one of the launchpad guys want to package it for universe 
<Burglaptop> ajmitch: has malone even be released under a free license?
<ajmitch> nope
<ajmitch> so th
<ajmitch> so the likelihood of seeing a package is slim
<Burglaptop> unhooked malone from teh rest of LP to make it useful standalone would be a big job
<ajmitch> it's probably quite dependant on a lot of other lp functionality, too 
<ajmitch> I doubt it's meant to be separated
<Burglaptop> the effort I would honestly have rather spent on UI at this point
<mpt> Burglaptop, to a very great extent the people who could improve the UI would be very little use in separating it, and vice versa
<mpt> separating out Malone, I mean
<Burglaptop> mpt: true
<dholbach> good morning
<Burglaptop> morning dholbach
<dholbach> hey Burglaptop
<jouston> good afternoon. :D
<tepsipakki> Hi! Still no news about when the next CC meeting is held?
<JaneW> fabbione: ping
<JaneW> fabbione: is this your bug? https://launchpad.net/distros/ubuntu/+source/vnc/+bug/31296
<Ubugtu> malone bug 31296 in vnc vncserver "vncserver isn't installable" [Normal,Unconfirmed]  
<fabbione> JaneW: unlikely.. but i am checking
<fabbione> JaneW: no, it's not mine but i can fix it
<JaneW> fabbione: who's should it be?
<mvo> JaneW: are you doing bug triage now :) ?
<fabbione> no idea...
<fabbione> doesn't matter...
<fabbione> i will fix it
<JaneW> fabbione/mvo: I have an e-mail asking about it
<JaneW> mvo: heh sure in the spirit of bug day!
* dholbach high-fives JaneW
* JaneW grins
<jsgotangco> nurse JaneW !
<JaneW> oh god
<JaneW> damn you guys were NOT mean to have access to that
* JaneW kicks self
<mvo> go JaneW go 
* jsgotangco needs healing
<dholbach> JaneW: access to what?
<seb128> Kamion: https://launchpad.net/distros/ubuntu/+source/espresso/+subscribe ... you probably want to subscribe to that one :)
<JaneW> dholbach: nm!
<Kamion> seb128: heh, point
<dholbach> JaneW: I do mind :)
<seb128> Kamion: there is a bunch of espresso bugs and I've noticed you are not listed as bug contact
<JaneW> jsgotangco: you are indeed sick! :P
<Kamion> ok, I'll grab them
<jsgotangco> lol
<JaneW> dholbach: get me drunk - I may show you ;P
<Kamion> I did wonder why it was so quiet
<dholbach> JaneW: will do! :-)))
<mvo> haha
<JaneW> jsgotangco: this is why I don't want to be on planet...
<jsgotangco> JaneW, understandable lol....that's a good idea really...not being on planet
<dholbach> JaneW: that'd bring the Ubuntu spirit to planet :-)
<jsgotangco> JaneW, i dunno you'll probably get stalked
* dholbach hugs JaneW
<JaneW> dholbach: stalker!
<dholbach> Come on! I'm not that bad, am I?
<pitti> Keybuk: I wonder whether nm shouldn't ignore /etc/n/interfaces ethX cards which just declare 'inet dhcp' without any additional options?
<fabbione> JaneW: bug fixed..
<pitti> Keybuk: then users will benefit from the cable plugin detection
<mjg59> pitti: In theory that should be fine, but it leads to some confusion over dhclients right now
<Keybuk> mjg59: that should work ok ... I made sure dhcdbd uses the same pid and leases files as ifupdown
<JaneW> fabbione: you are a STAR!
<Keybuk> so dhcdbd will happily kill one
<mjg59> Keybuk: Oh, right. You didn't tell me :p
<Keybuk> mjg59: I didn't tell you what I had for breakfast either :p
<mjg59> In that case, it sounds sensible
<HiddenWolf> mvo: you are the libnotify guy right?
<mjg59> Yes, but I didn't tell you to have eggs for breakfast and then have you say "No, that's difficult" and then have eggs anyway
<HiddenWolf> mjg59: compiz (gnome-kde) is stuck in new
<Keybuk> pitti: yeah, I've been vaguely considering .... it's just a matter of parsing the iftab and making sure it's just "auto, inet dhcp and no other options"
<mjg59> HiddenWolf: Out of my hands
<Keybuk> (obeying auto is important here)
<pitti> right
<Keybuk> mjg59: I didn't say "No, that's difficult" I just said "that's difficult" :)
<mjg59> Ha
<Keybuk> doesn't mean I'm not going to try to do it anyway <g>
<mvo> HiddenWolf: yes
<mjg59> sladen: I think I might know what your sleep button problem is
<mjg59> sladen: In the gnome keyboard shortcuts, what happens if you delete the sleep entry?
<HiddenWolf> mvo: I'm having some positioning errors with the popups like raised by xchat-gnome and gconf. They appear on top of the panel, obscuring the workplace switcher.
<Keybuk> my concern is that if you had two ethernet cards, both auto + dhcp, and then wondered why only one of them was working at any one time
<Keybuk> but given dhcp usually implies "default route and dns" that it's such a rare setup
<HiddenWolf> mvo: if a second popup gets triggered, both jump to the correct positions.
<mjr>  ,25
<mvo> HiddenWolf: can you make a screenshot for me please?
<Keybuk> and "remove network manager" would be a fine answer to that
<Kamion> HiddenWolf: it was my weekend and I wasn't doing lots of work. quit nagging about NEW please?
<Keybuk> (which is another reason to consider *not* seeding network-manager in -desktop, of course)
<Kamion> and, I mean, oh dear, a whole 31 hours
<HiddenWolf> Kamion: I'm not nagging, nor pushing. I just noticed the wiki suggesting -gnome, found out it wasn't in the archive, and asked to see if I should update it.
<HiddenWolf> Kamion: I have nothing but respect for all devels present here, please don't take it out on me.
<Kamion> using words like "stuck" for a package that's been in the new queue less than two days really doesn't help
<Kamion> I'll process it and some other stuff after this publisher run has finished
<HiddenWolf> Kamion: if I had said stuck ... still, you would have a point. I did not mean to cause offense.
<Keybuk> infinity: thanks
<infinity> NP.
<HiddenWolf> mvo: http://www.geocities.com/hiddenwolfsof/Screenshot.png to the bottom right. I can file a bug if you want.
<Kamion> 10:13 < HiddenWolf> mjg59: compiz (gnome-kde) is stuck in new
<Kamion> anyway, fair enough, over
<HiddenWolf> Kamion: good morning. ;)
<Kamion> heh
* HiddenWolf hands Kamion some coffee
<pitti> Kamion: hmm, espresso keeps wanting to format my home partition /dev/hdc3, although I didn't mention it in the device -> mountpoint assignment; shall I file a bug, or is that known?
<Kamion> pitti: file a bug please; if you can include /var/log/installer/espresso plus the stderr output from espresso (probably in ~/.xsession-errors?) that'd help
<pitti> yep, will do that
<Kinnison> HiddenWolf: coffee... sounds good
<Kamion> I'm just working on a change now to make all stderr go to /var/log/installer/espresso
* Kinnison ponders beating rob until he goes to make a pot of coffee
<Kamion> compiz-gnome and compiz-kde will hit the archive at the next publishing run (so about an hour's time)
<Riddell> Kamion: are you incharge of all packages in NEW now?
<Riddell> or just new binary packages?
<mvo> HiddenWolf: yes please, assign it to me
<mvo> HiddenWolf: and attach the screenshot
<HiddenWolf> mvo: roger
<Kamion> Riddell: I'm one of those who processes the NEW queue, both source and binary
<mvo> HiddenWolf: thanks
<Riddell> Kamion: e.g. Keep has been in NEW for a while, is someone processing packages like that?
<fabbione> Keybuk: running sh -x /scripts/init-premount/udev that loads ide-generic
<Keybuk> fabbione: ok, which line?
* fabbione sighs
<fabbione> couldn't you ask for that before? :)
<Keybuk> try stepping through that script line-by-line too
<fabbione> for the line i mean :)
<fabbione> ok
* fabbione disappears again
* Keybuk thought that was implied by "run it -x" :)
<HiddenWolf> mvo: done.
<fabbione> ok.. text client too
<jono_> hey all
<jono_> are there plans to still have two CDs or is just the live cd?
<Kamion> we'll still have two CDs
<Kamion> that way espresso doesn't have to be all things to all men
<jono_> cool
<Kamion> (which it won't be ...)
<HiddenWolf> three including server
<jono_> but will expresso be considered the main cd?
<Kamion> HiddenWolf: a zillion including kubuntu and edubuntu
<Kamion> server is a different axis
<Kamion> jono_: we *may* decide to only ship the live CD in shipit, depending on how well espresso turns out
<jono_> right
<Kamion> and at that point, yeah, it would be considered the main CD
<jono_> is there a flight 4 for expresso ?
<Kamion> yes
* jono_ is just trying to predict the landscape for the ubuntu book
<mjg59> It's on the live CD
<Kamion> (espresso, btw, note spelling)
<jono_> oops
<Kamion> https://lists.ubuntu.com/archives/ubuntu-announce/2006-February/000050.html <- mentioned there :)
<jono_> hmmm I just downloaded and run flight 4, and it did not boot into the GUI installer
<Kamion> did you use the live CD?
<Kamion> Flight 4 consists of two CDs per flavour
<Kamion> the live CD should start up with an "Install System Permanently" icon on the desktop
<jono_> d'oh!
<Kinnison> pitti_espresso: ping?
<jono_> I am an idiot
<jono_> ignore me
<Kamion> the "*-install-*.iso" naming may be a little confusing now
<Kamion> I'm trying to put off having to deal with that
<Kamion> Riddell: keep accepted; we are a little behind on NEW, anything particularly urgent?
<Kamion> it's not that stuff isn't being processed, I've just been prioritising work on existing packages over new packages in general
<pitti_espresso> Kinnison: pong
<Riddell> Kamion: great, thanks, that's the only important one for now
<pitti_espresso> yay, espresso finished
<pitti> Kinnison: re-pong, please speak to pitti, not pitti_espresso
<Kinnison> pitti: sorry
<Kinnison> pitti: Did you get my mail about hal and pmi?
<pitti> Kinnison: yes, I will take a look at it soon
<Kinnison> pitti: cool, thanks. I was having mail problems over the w/e and just wondered if that one had gotten lost
<Kinnison> Anyone here have a sony laptop?
<Kinnison> ideally running dapper
<jono_> Kinnison, I do
<jono_> Kinnison, I have two vaio's the little one and the big one
<Kinnison> jono_: can you do me a favour please and look in /proc/acpi/sony
<jono_> neither run dapper atm
<jono_> Kinnison, 
<jono_> sure
<Kinnison> jono_: and tell me what youcan find out about the lcd brightness levels
<jono_> brightenness contains 4
<Kamion> BenC: did you notice the linux-source-2.6.15_2.6.15-16.22 powerpc build failure
<jono_> and so does brightness_default
<Kamion> ?
<infinity> Kamion: He knows, the fix is in .23
<pitti> Keybuk: NM works fine here, tested with my l-wlan-ng device and proper ethernet
<infinity> (In git, upload pending, apparently)
<Kinnison> jono_: anything about how many levels there are ?
<mjg59> Kinnison: It's a maximum of 8 on Sonys
<jono_> Kinnison, nope, both files just contain the number 4
<pitti> Keybuk: however, I manually have to click into the (automatically detected) wireless network, it doesn't automatically connect to it; is that intended?
<Kinnison> mjg59: is that a known-fact?
<infinity> mjg59: 0 through 7, like on IBM, 1 through 8, or 0 through 8?
<fabbione> Kamion: yes he knows
<Kinnison> infinity: afaict, it must be 0 through 8
<Keybuk> pitti: I don't know, n-m does weird crap like that sometimes
<mjg59> Kinnison: Yes
<mjg59> 1-8
<Keybuk> it doesn't switch to my wired network either if I plug the cable in
<Kinnison> mjg59: 1-8? sure?
<mjg59> Kinnison: Yes
<pitti> Keybuk: ISTR that it automatically connected to the hotel network in London
<Keybuk> but does detect the cable
<mjg59> Kinnison: See drivers/acpi/sony_acpi.c
<pitti> Keybuk: hm, it automatically connects to the wired for me
<Keybuk> pitti: it *probably* means you've not introduced n-m to your wireless network at home yet
<Riddell> Kamion: could you move a few packages to main?
<Kinnison> mjg59: urgh, fecking sony
<Keybuk> now you have, it probably will automatically connect
<Kamion> Riddell: go ahead
<mjg59> Kinnison: ?
<Keybuk> pitti: could you main-review it for me today?
<Kinnison> mjg59: Everyone else seems to have zero-thru-N
<Riddell> Kamion: librsync1 from librsync
<Kamion> Riddell: but nothing complicated please, I don't have anastacia
<pitti> Keybuk: I didn't introduce it to the eth either, but I'll try
<pitti> Keybuk: yes, will review it
<Kinnison> mjg59: gnome-power-manager can't set 100% brightness on sonys because hal reports 8 levels
<Riddell> Kamion: source package needs moved too
<Keybuk> pitti: I think it just cares about networks; it doesn't automatically join an unknown network
<mjg59> Kinnison: Ah, and it doesn't fudge it. Ok.
<Riddell> rdiff-backup (binary and source)
<Kinnison> mjg59: I'm trying to decide if it's a g-p-m bug, a hal bug or a drier bug
<Kinnison> driver even
<Riddell> Kamion: keep (binary and source)
<pitti> Keybuk: 'cares about networks' => wireless networks?
<Keybuk> pitti: right
<Riddell> Kamion: and ksplash-engine-moodin (binary and source)
<mjg59> Kinnison: The sensible plan is for me to push in my generic backlight class hack, so it appears under /sys/class/backlight and has a standard interface
<pitti> Keybuk: ok, that could make sense, to not automatically leech from your neighbor's :)
<mjg59> That might not happen in time for dapper, though
<Kamion> Riddell: what needs librsync1?
<Riddell> Kamion: keep
<infinity> pitti: s/networks/named networks/ ... Wired networks are assume to be what you wanted, cause you plugged in.
<fabbione> Keybuk: this is the line: /sbin/udevplug -s -Bpci -Iclass=0x01* that loads both ide-generic and the via82cxxx. The latter too late :)
<Kamion> Riddell: librsync will need an inclusion report; coordinate with pitti
<Riddell> Kamion: rather rdiff-backup for keep
<fabbione> Keybuk: so what is next?
<Kinnison> mjg59: eta on that?
<Riddell> Kamion: that's been done
<Kamion> oh, right, I see
<Riddell> Kamion: https://wiki.kubuntu.org/MainInclusionReportLibrsync
<Kamion> can't move keep until after this publisher run
<Keybuk> fabbione: kernel bug
<fabbione> Keybuk: can you prove it?`
<Keybuk> fabbione: yup
<pitti> Keybuk: yep, works fine
<Riddell> Kamion: right
<Keybuk> because via must have been loaded first for ide-generic to have been loaded <g>
<fabbione> Keybuk: than fix it. kthxbye
<Keybuk> not my bug to fix
<pitti> Keybuk: and it didn't yet crash my kernel, so I'll keep it around for a while
<Keybuk> it's a kernel bug
<Keybuk> it sounds like the via ide driver isn't claiming its devices
<fabbione> ok brb from something more useful than this 20x10 session
<Keybuk> unless you have multiple IDE controllers in that thing?
<Keybuk> (but you didn't mention that)
<fabbione> Keybuk: yes i do have several IDE controllers
<Keybuk> gee, thanks for mentioning it
<Keybuk> it's not like that's an important detail
<fabbione> you didn't ask
<Kamion> Riddell: please seed keep
<fabbione> but none of the controllers use ide-generic
<fabbione> i am sure about it :)
<fabbione> use or need
<Keybuk> dude, will you please stop assuming something that doesn't work for you is a problem that affects everyone
<Keybuk> if you have a problem, it's likely something to do with your setup or configuration
<fabbione> i didn't say that affects everyone.. ever
<Keybuk> so all the details about that are useful *up front*
<Kamion> Riddell: librsync1, rdiff-backup, ksplash-engine-moodin all promoted
<fabbione> Keybuk: i did ask you before what do you need to debug this problem, didn't I? 
<pitti> Riddell: that sounds like it's time to review keep soon? :)
<fabbione> Keybuk: that means i might not be aware of all the details you need
<Keybuk> fabbione: yes, I need the machine sitting in front of me
<Keybuk> but given that's impossible, the next best thing is to have someone helpfully testing for you
<pitti> seb128: NM works pretty well for me, could you test it so far?
<Keybuk> and if that person doesn't give large pieces of information, like the basic spec of the machine, it's damned hard
<seb128> pitti: I've tested it friday, works fine for me (ie: doesn't mess with my static eth config
<seb128> s//)
<Kamion> pitti: yes please
<Riddell> pitti: erk, I'd forgotten that hadn't happened yet
<Kamion> Riddell: does keep build-depend on librsync-dev?
<pitti> Keybuk: if you think that NM is still too crackful to be included into desktop, do you think it makes sense to ship it in main?
<pitti> Riddell: I tried, but no packages in the archive to review :)
<Keybuk> pitti: I think it makes sense to provide support and security for it
<fabbione> Keybuk: ok don't worry. i will cope with it myself. clearly i am not helpful enough when i explicity ask for what information you need because i don't know what is useful.
<seb128> pitti: what is "too crackful"?
<Riddell> Kamion: no, it install deps on rdiff-backup which will build-dep on librsync-dev
<seb128> I think we should have it to "ship"
<Kamion> Riddell: ok, so librsync-dev will need to be promoted too
<pitti> Keybuk: I feared that you would say that :) But you are right, it's just too good to be dropped at all
<seb128> network-admin seems to be a pain for most of wireless users around
<Riddell> Kamion: confirming..
<Kamion> right, fuck this, I'm going to port anastacia to look at Packages/Sources files
<pitti> seb128: Keybuk still has issues with it AFAIUI
<Kamion> this is too hideously difficult
<seb128> pitti: what kind of issue?
* jono_ is running espresso in vmware
<jono_> all good so far
<Riddell> Kamion: yes, it needs librsync-dev
<Kamion> jono_: should be, that's where I test it most of the time ;-)
* pitti turns seb128's head to Keybuk 
<Kamion> Riddell: ok, will promote after the publisher finishes
<seb128> pitti: you are the one saying it's too crackful
<jono_> Kamion, ahhh cool
<pitti> seb128: no, I said that Scott said that it is :)
<Keybuk> seb128: no, he said I'd said that
<seb128> pitti: so assume your opinion, don't bounce it back to somebody else :)
<jono_> Kamion, so is the initrd boot problem fixed now ?
<Kamion> jono_: which problem?
<jono_> Kamion, previous flight cds have not been able to mount the root file system
<seb128> pitti: ah, right, misread, sorry :)
<Keybuk> jono_: what was the bug# you filed?
<jono_> I submitted a bug quite some time ago about it
<seb128> Keybuk: too crackful for "ship"?
<jono_> let me see if I can dig it out
<pitti> seb128, Keybuk: so everyone in the distro team should at least install and test it
<Kamion> jono_: if I'm divining your meaning correctly, that was an initramfs-tools bug only affecting the install CD
<Keybuk> seb128: did you bother to read my e-mail?
<seb128> Keybuk: it would make wireless experience much better for 90% of wireless users imho
<Kamion> jono_: and chiefly affecting vmware's SCSI driver
<Keybuk> seb128: the one where I said what problems there are with it, and then actually recommended it for at least ship
<Kamion> jono_: that's been fixed
<Keybuk> seb128: not true
<Keybuk> it makes it better for about 30%
<Keybuk> (from my own testing and feedback)
<seb128> Keybuk: yeah (quickly I admit, it was on friday, going to read it again)
<Keybuk> the other 70% get left with difficult-to-fix problems
<seb128> hum
<jono_> ahhh https://launchpad.net/distros/ubuntu/+source/initramfs-tools/+bug/27187
<Ubugtu> malone bug 27187 in initramfs-tools "failure with 2.6.15 on vmware 5.5 (scsi disk)" [Normal,Fix released]  
<Keybuk> where that 30% can be summed up as "people with ipw2100/2200"
<jono_> looks like its been fixed :)
<seb128> Keybuk: -desktop feedback seems that network-admin simply doesn't work for almost all wireless users around
<pitti> Keybuk: or, now, linux-wlan-ng :-P
<jono_> cool
<seb128> we got people complainly loudly
<Keybuk> if n-m failed gracefully, I'd be happy
<seb128> if we don't ship n-m we will have to fix network-admin or rewrite parts of it :/
<Keybuk> but it doesn't, it fails in evil ways
<j^> wireless support in network-admin always was to crackful to ship
<seb128> basically we are stucked to sucking wireless for dapper
<seb128> network-admin doesn't fit
<seb128> and network-manager is not ready
<Keybuk> *shrug*
<Kamion> jono_: yeah, both install CD and live CD work well for me in vmware at present; you do have to make sure you have a big enough virtual disk though (Mark tried with 1.5GB for install and 2.0GB for live and it blew up)
<Keybuk> it sucked in breezy, hoary and warty too
<Keybuk> so it's not a regressive suck
<seb128> yeah, but dapper is supposed to rock :)
<Keybuk> no, dapper isn't
<Keybuk> dapper is supposed to be stable
<seb128> I would like to have it shipped on the CD
<Mithrandir> wouldn't a regressive suck be a blow?
<Keybuk> dapper is not supposed to be shiny
<seb128> having your network working is not something shiny
<seb128> it's functionnal
<jono_> Kamion, ahhh cool
<pitti> seb128: given that we can afford the space, ship is probably fine, just not desktop
<jono_> Kamion, this is 4gb I think, so I just be fine
<Keybuk> seb128: you're starting to sound like Jeff
<jono_> it just hung so I am trying again
<Keybuk> "WE SHOULD HAVE THIS SHINY THING IN DAPPER!  I DON'T CARE THAT IT DOESN'T WORK!" :D
<j^> Mithrandir i think thats an iverse suck
<seb128> I don't care about shiny
<Kamion> pitti: "given that we can afford the space" means "we can afford the space, so ..."
<seb128> if you fix network-admin I'm fine with it too
<Keybuk> why me?
<Kamion> pitti: I suspect you mean "if we can afford the space, ..."?
<seb128> you beeing anybody who wants to :)
<pitti> Kamion: erm, right, thanks :)
<Keybuk> we've not had any gadget to select wireless networks for the last three releases
<Keybuk> going another release without one installed by default isn't going to kill anybody
<seb128> and lot of people complaining ...
<Keybuk> people complain.
<seb128> sure, it's not
<pitti> we coudl add it to the release notes 
<seb128> right, they do
<seb128> but they may have a reason on that one :)
<pitti> 'If you feel lucky, install n-m and check out if it works' or so
<seb128> pitti: I'm fine with shipping on the CD, it will make easy for medium-users to run it
<pitti> seb128: and we should add an autostart .desktop file to it at least
<seb128> it has one since friday
<pitti> oh?
<pitti> seb128: I just installed the latest version, and I had to run nm-applet by hand
<Keybuk> you did?
<Keybuk> it should autostart
<seb128> somebody broke it since friday so
<Keybuk> if not, is seb128 bug
<seb128> it's not running for me neither
<seb128> it was yesterday
<Keybuk> seb128 bug!
<dholbach> Keybug! :-p
<pitti> dpkg -L nm-applet |grep desktop
<pitti> /usr/share/autostart/nm-applet.desktop
<pitti> hmmm
<Keybuk> fabbione: ok, that udev upload should fix your problem ... (though if it causes a 1,000 new bugs, I'm going to revert it <g>)
<pitti> seb128: ah, wait, .autostart only becomes active at login, right? I didn't restart my session
<seb128> ccorrect
<seb128> correct
<pitti> that explains it
* pitti became so used to the inotify goodness that he never ever restarts his session after package installation
<jono_> can I make a small suggestion - may be wise when espresso is running, to dim the background and make the desktop inactive
<Keybuk> hmm, there's a good wishlist :)  if new .desktop are added to autostart, gnome should start them! :p
<jono_> just like when you log out, the desktop dims
<pitti> jono_: but you might want to play tetris or use IRC whiile installing
<Mithrandir> jono_: that'll make using a web browser to resolve issues, etc hard.
<jono_> pitti, ahhh not a bad point
<jono_> in fact, a glorius point :)
<jono_> I can be online and on the web while installing, cool
<pitti> yes, for online support
<jono_> :)
<pitti> although I consider playing tetris a much more important feature :P
<jono_> heh
<Keybuk> I didn't realise we shipped tetris?
<pitti> Keybuk: GNOMEtris
* HiddenWolf installs
<Keybuk> ah yes
<Mithrandir> Keybuk: if not, you can just install it.
<fabbione> Keybuk: i just checked. of the 4 controllers SATA/IDE/RAID i have on board, all of them are catched by specific drivers. (according to modules.pcimap and kernel code)
<Keybuk> seb128: want a poppler/document-viewer bug?
<seb128> sure
<Keybuk> fabbione: yeah, but loading those caused ide-generic to get loaded, and claim the remaining devices <g>
<Mithrandir> I mean, if we had dualhead being autoconfigured, I could be playing full-screen wesnoth on one page while installing on the other.  Killer feature!
<Keybuk> fabbione: I've removed that rule, try the new udev when it builds
<fabbione> Keybuk: ok
<seb128> pitti, slomo_: bug #31998 ... who maintains dbus now?
<Ubugtu> malone bug 31998 in dbus "session dbus started twice" [Normal,Unconfirmed]  http://launchpad.net/bugs/31998
<fabbione> i could have tested it without you uploading :)
<Keybuk> seb128: I just got a .PDF which looks like a fill-in-the-blanks form thing, and all the blanks are blank
<Keybuk> the Google .html converter shows that there are actually values there 
<seb128> Keybuk: we already have a bug about that
<Keybuk> ok
<Lathiat> mjg59: any chaance to try that synaptics package?
<pitti> seb128: the last person who asked :)
<seb128> pitti: :p
<Keybuk> dbus sounds like a pitti package to me :)
<pitti> seb128: I can take a look at it, but not anytime soon; I need to do a ton of security stuff still
<pitti> Keybuk: I love you, too
<seb128> Keybuk: https://bugs.freedesktop.org/show_bug.cgi?id=4788
<Ubugtu> freedesktop bug 4788 in general "incorrect rendering of layered(?) PDF" [Normal,New]  
<pitti> NO, I WON'T FIX POPPLER
<seb128> pitti: come on, you like it :)
<Lathiat> how many bug systems does ubugtu speak
<pitti> seb128: If I liked it, I would do crackful things like porting xpdf to it, or so
<mjg59> Lathiat: Not as yet - shortly
<jono_> Kamion, good work, all worked well here :)
<Kamion> great, good to hear
<seb128> pitti: right, somebody would really need to be found of it to do such stuff ;)
<Kamion> obviously lots of missing features as yet
<Lathiat> mjg59: cheers
<Kamion> and the advanced partitioner's horrible
<jono_> Kamion, sure, only problem I have is that the max res in x is 1024x768
<jono_> and my normal res is 1280x800
<jono_> other than that, it all works seamlessly
<Kamion> xresprobe doesn't work properly in vmware
<Mithrandir> jono_: what arch?
<Kamion> since vmware doesn't return EDID data
<pitti> does espresso generally not install grub, or didn't it just work for me?
<Mithrandir> ah, vmware.
<Mithrandir> you lose, then.
<Kamion> we may have to special-case that somehow; I looked at it briefly end of last week, but it's hard
<mjg59> I'm surprised vmware doesn't return EDID
<Kamion> pitti: it's meant to, but at the moment it's problematic and requires working network access in the chroot
<Kamion> so basically it sometimes works
<Lathiat> Package: gstreamer0.10-plugins-ugly-multiverse
<Lathiat> Section: universe/libs
<Lathiat> :)
<Kamion> when you combine this with error reporting not working properly at that stage ... I'll fix that part at least I hope
<Lathiat> i figure that needs some munging?
<infinity> Keybuk: Aladdin?  You're stretching now, aren't you?
<jono_> Mithrandir, x86
<jono_> ph right
<Keybuk> infinity: had the Lion King before
<infinity> I'm glad I missed that one.
<Lathiat> hrm
<Lathiat> theres some crap that gets spewed if yoru filesystem is remounted ro before a fsck
<Lathiat> but it went past i cant see it now
<Keybuk> and I started with Buffy
<Lathiat> was udner loading manual drivers some python spat error
<Keybuk> seb128: oh, and Monospace Bold is still dancing
<Lathiat> how can i make it mount ro before fsck to test that ?
<Lathiat> can i mark the fs dirty or something?
<seb128> Keybuk: "dancing"?
<Keybuk> seb128: changing all the time, hang on, will try and screenshot it
<pitti> Keybuk: oh, do you really need the 'deny' policy for the 'default' context in the dbus policy? I thought it's restrictive by default anyway?
<Keybuk> pitti: no idea
<Keybuk> pitti: I don't know dbus
<pitti> +       <policy group="plugdev">
<pitti> +               <allow own="org.freedesktop.NetworkManager"/>
<pitti> that looks a bit scary
<Robot101> hm, thats weird
<pitti> it shoudl only be owned by root, just for safety
<Keybuk> feel free to change dbus policy to be sane
<pitti> ok
<pitti> oh, and thanks for restoring the patch system
<pitti> removing an existing patch system was a really weird thing
<Lathiat> can we get rid of that ugly nautilus on the gnome splash screen? :)
<mjg59> Kinnison: Any chance you could try sdhci against your sd reader at some stage?
<tepsipakki> Lathiat: where did you see the gstreamer...-ugly?
<Kinnison> mjg59: I'd need an SD card :-(
<Kinnison> mjg59: but I can try loading it
<Lathiat> tepsipakki: its a package in dapper, just pointing out that the multiverse package is in fact in universe
<tepsipakki> Lathiat: ah, -ugly, not -bad
<mjg59> Kinnison: Load sdhci, and then do echo -n "vendor device" >/sys/bus/pci/drivers/sdhci/new_id
<mjg59> (This may confuse things, so you probably want to make sure everything is saved)
<Kinnison> in lspci -n, vendor/device is the two four digit hex numbers colon separated yes?
<mjg59> Yes
<mjg59> Oh, hang on
<mjg59> In scanf, does %x mean "interpret as hex" or "must have leading 0x"?
<Kinnison> iirc interpret as hex
<mjg59> Ok, fine
<stockholm> doesnt jane silbers hang out here, too?
<tseng> not often
* Kinnison tries
<Kinnison> mjg59: hardlocks the laptop
<mjg59> Kinnison: Fun!
<mjg59> So it's not an sdhci
* Kinnison reboots in single user in case there's useful debug to be had
<Kinnison> nope, so it's deffo not sdhci
<pitti> Keybuk: hm, maybe we should consider to actually show the nm debconf note if we don't ship it in desktop
* Kinnison notes grub has become next to frakking useless
<Keybuk> pitti: I'm gonna get rid of that note anyway
<pitti> Keybuk: ok, as you wish
<pitti> I reviewed the package now, looks good to me
* pitti approves and moves queue
<pitti> Keybuk: what do you think about changing access policy from plugdev group to pam-foreground?
<Keybuk> Kamion: at your leisure, could you move network-manager, nm-applet and deps into main
<Keybuk> pitti: sounds reasonable, that's what g-p-m uses right?
<pitti> Keybuk: yes, so that multiple sessions don't set conflicting network settings
<pitti> Keybuk: and remote users couldn't reconfigure network
<Keybuk> got an example of what I should do for that?
<pitti> I can do the change if you want
<pitti> if I shall clean up the dbus policy anyway
<pitti>         <policy at_console="true">
<Kinnison> pitti: don't forget to make it depend on libpam-foreground too
<Kinnison> pitti: for those who don't have ubuntu-desktop installed
<pitti> yes, thanks
<mjg59> dbus arguably ought to depend on that
<mjg59> Otherwise at_console won't work
<pitti> either that, or all packages whose policy actually use it
<Kamion> Keybuk: I'm attempting to port anastacia first
<pitti> but given the small size, a dbus dep would be easier
<Keybuk> pitti: sure, go for it
<Kinnison> seb128: bug 31941 suggests we should disable the battstat applet in dapper. your opinions?
<Ubugtu> malone bug 31941 in gnome-power-manager "[upgrade]  Both gnome-power-manager and gnome-battery-monitor display dialogues" [Normal,Unconfirmed]  http://launchpad.net/bugs/31941
<seb128> Kinnison: how disable? Stop making it a part of the default panel profile?
<Kinnison> seb128: the way richard says it, I'd guess they made it exit zero or something
<Kinnison> or even removed it from the packages
<seb128> it doesn't say anything useful
<seb128> disabled ...
<seb128> is that disabled from the config, from the package, etc
<Kinnison> right, I'll prod him about it
<seb128> some people may still want to use it, I would rather ship it but drop it from the default panel config
<mjg59> Is g-p-m part of desktop now?
<Kinnison> mjg59: certainly seems to be
<seb128> another issue is upgrades, if we drop the applet people will get the "that applet can't start, do you want to retry or drop it" since it's listed by their panel config
<seb128> but the message is not clear it has been removed, it acts like it was crashing
<Kinnison> hmm
<seb128> or we would need some hack to get it dropped silently (upstream has some such mechanism for applets they deprecated)
<Kinnison> But it's definitely bad having both
<seb128> sure
<seb128> but I would like some details on what fedora did exactly
<seb128> maybe we can take a patch from them
<Kinnison> okay I'll see if Richard can furnish me with the details
* Mithrandir bounces a bit more.
<infinity> seb128: Is there a way to permanently unlock my gnome-keyring so networkmanager doesn't ask for my password every time I login?  That's phenomenally annoying.
<Mithrandir> pitti_laptop: any chance you could test an amd64 ddcprobe for me?  (On the machine where it previously blew up with illegal instruction, etc)
<pitti_laptop> Mithrandir: I'd be glad to :)
<pitti_laptop> pitti_laptop: sorry, I didn't yet get to debug that one
<Mithrandir> pitti_laptop: http://err.no/tmp/ddcprobe5
<pitti> Mithrandir: yay, no illegal instruction any more (but still no edid)
<pitti> Mithrandir: do you want the full output /msg'ed?
<pitti> Mithrandir: (you rock :) )
<Mithrandir> pitti: yes, please.
<Mithrandir> pitti: if you could also gdb it and break before each real_call and print _X86EMU_env to me in each case, that'd be great.
<Keybuk> Mithrandir: that one gives me EDID love
<Mithrandir> Keybuk: \o/
<Mithrandir> pitti: hmm, do you get edid info from the i386 live cd?
<viviersf> Mithrandir, does the casper enable dma on cdrom drives ?
<Mithrandir> viviersf: it doesn't touch DMA.
<pitti> Mithrandir: I'd have to download the i386 one and check; I definitively got it with my old i386 box (same monitor)
<pitti> Mithrandir: I have the breezy i386 here, if that would be enough
<viviersf> Mithrandir, kewl , if i may ask whys that ? for stabality and compatibiltiy ?
<Mithrandir> pitti: that should work fine, yes.
<Mithrandir> viviersf: nobody has asked for it, and I think the kernel should enable DMA where it makes sense.
* Keybuk heads off to meet Mr O'Bacon for lunch
<pitti> Mithrandir: http://paste.ubuntu-nl.org/8952
<pitti> Mithrandir: I'll boot the i386 CD now, brb
<Kamion> http://people.ubuntu.com/~cjwatson/anastacia.txt
<Kamion> enjoy
<Kamion> I think that output is sane-ish anyway
<viviersf> Mithrandir, whats the default casper users password ?
<Mithrandir> viviersf: it's blank
<viviersf> hmm
<viviersf> weird
<Mithrandir> how so?
<viviersf> i do a sudo -s
<viviersf> just hit enter
<viviersf> it doesnt give error 
<Mithrandir> you shouldn't be asked for a password when doing sudo -s
<viviersf> but im not root
<Kinnison> is g_signal_emit synchronous?
<Mithrandir> viviersf: you're a member of the admin group?
<Robot101> Kinnison: no, it marshals signal emissions as GClosures through the mainloop, especially if you have threads :)
<Kinnison> Robot101: big smelly arse
<Robot101> arbitrary stack re-entrancy --
<viviersf> Mithrandir, well its the default user that your casper adds
<infinity> Kamion: Your anastacia seems a bit... Whack.
<Kamion> infinity: what's up with it?
<Mithrandir> viviersf: I don't know what changes you have or haven't done to the system.  It would be a lot more useful if you just answered the question.
<infinity> Kamion: The "redland wants to promote libmysqlclient12-dev to main" bit seems wrong, since redland build-deps on libmysqlclient15-dev | libmysqlclient12-dev | libmysqlclient10-dev
<infinity> Kamion: For instance...
<Kamion> well it's what germinate says ...
<Kamion> http://people.ubuntu.com/~cjwatson/germinate-output/dapper/all lists the same thing
<infinity> Isn't germinate only meant to take the first (installable) build-dep in the list?
<pitti> Mithrandir: *enlightened*
<pitti> Mithrandir: the culprit is neither amd64, nor the dapper version, but that EDID doesn't work through DVI
<Kamion> Should do (in general, although |-ed deps have a zillion corner cases). May be a germinate bug.
<pitti> Mithrandir: if I use the VGA cable, then ddcprobe5 works perfectly
<infinity> Kamion: Same story for postfix and libmysqlclient14.  (It build-deps on 15 first, and is definitely built against 15)
<Mithrandir> pitti: excellent. :-)
<Mithrandir> pitti: the same goes for i386?
<viviersf> Mithrandir, i just use your normal casper , the ubuntu user isnt in the admin group
<infinity> Score on mozilla falling out of main, though!
* infinity dances.
<Mithrandir> viviersf: then user-setup is broken.
<infinity> And python2.3
<Kamion> * Chose libmysqlclient12-dev to satisfy librdf0
<viviersf> Mithrandir, seems so
<Kamion> definitely doing something interesting there
<viviersf> Mithrandir, i was just running between the 2 pc's
<Mithrandir> viviersf: so either you have broken user-setup in your setup or there's something else weird going on.
<infinity> Kamion: Do you intend to cron that anastacia run and keep the list public?  That's actually really handy output to see what should be seeded and isn't, etc.
<Kamion> viviersf: what version of user-setup?
<Kamion> infinity: already cronned
<infinity> (For instance, db4.2-util should definitely be in main if the library stays)
<Kamion> (it's the same as http://people.ubuntu.com/~mdz/anastacia.txt used to be, just hackily ported to drescher)
<infinity> Kamion: Ahh, I somehow managed to never know about the one at ~mdz
<pitti> Mithrandir: yes
<Kamion> it may move again though, since it's a hideous hideous awful bodge and not ported properly to Launchpad
<Kamion> I've just made it look at the Packages and Sources files
* pitti ^5s infinity for mozilla
<Mithrandir> pitti: ok, then I blame it on the hardware and then I'll commit and upload
<Kamion> I'll keep DeveloperResources up to date though with whatever the link ends up being
<pitti> Mithrandir: yes, let's
<viviersf> Kamion, user-setup                    0.05ubuntu3
<Kamion> make sure you don't have a root password set in the live filesystem
<Kamion> if you do, then user-setup won't add the ubuntu user to the admin group
<viviersf> oh hell 
<viviersf> thats why
<viviersf> thx
<viviersf> weird i dont have a shadow file 0_o
<segfault> kamion: there's still some spanish strings in espresso
<segfault> kamion: i defined my hostname to only "a", and it complained about it, in spanish
<Kamion> segfault: I know
<Kamion> it's one of the many things on the to-do list
<segfault> ah, ok
<Kamion> but thans
<Kamion> k
<pitti> Kamion: mind if I rebuild openssh against gnutls12 (11 now)?
<pitti> Kamion: I'd like to apply that scp security patch (unless you want to), so the package needs to be touched anyway
<Kamion> pitti: oh, I'll do the scp security patch in Debian now
<pitti> Kamion: hm, nevermind, libgnomevfs2-dev still needs 11, so I won't touch it
<Kamion> actually, no I won't, there's a new upstream - I'll backport the change to Ubuntu
<pitti> yes, 4.3p1 or so
<Kamion> 4.3p2 now
<pitti> ah, right, p1 was the openbsd version
<pitti> thank you
<torkel> pitti: fixing my two gssapi bugs in ssh too (#28487 and #28488)? :-)
<pitti> Kamion: I'll wait with the stables updates then
<Kamion> no, 4.3 is the OpenBSD version
<Kamion> 4.3p1 was the first portable version based on that, 4.3p2 is the second
<Kamion> torkel: not unless you have patches
<torkel> Kamion: I'll see what I can do. I may take some time though
<AlinuxOS> hello, I can't find gnome-art package's .pot file for transation
<mvo> infinity: initramfs.conf is giving me a conffile prompt for a dapper->dapper upgrade. is that known?
<Kinnison> mjg59: bug 30465 -- what do you think the correct resolution is?
<Ubugtu> malone bug 30465 in acpi-support "sleep fails to remove the button module causing spurious events" [Normal,Confirmed]  http://launchpad.net/bugs/30465
<Kamion> grr, anonymously-accessible portable openssh cvs went away
* pitti points Kamion to http://people.ubuntu.com/~pitti/patches/openssh-scp-metachar-portable.patch
<mjg59> Kinnison: Yeah, that one's interesting
<mjg59> Kinnison: What we actually want is for one of the kernel, acpid or hal to ignore that button event
<Kamion> pitti: ok, go ahead and apply that to Ubuntu openssh; I'll sort out Debian later with a new upstream
<pitti> Kamion: ok, will do
<Kinnison> mjg59: I see. I can confirm that putting button on the list of module to be unloaded/reloaded certainly corrects the symptom
<Kinnison> mjg59: It certainly is annoying
<Kamion> thanks
* Kinnison can't see a case where removing/reinstating button would cause a problem, do you know of one?
<mjg59> Kinnison: Seems to kill wakeup on some hardware
<Kinnison> mjg
<Kinnison> mjg59: feck
<giftnudel> mjg59: I'd like to point you to the small bug 31156 since it's a matter of 30 seconds and sitting there for 9 days without being noticed ;)
<Ubugtu> malone bug 31156 in acpi-support "only 915resolution installable but 49-855resolution-set.sh in /etc/acpi/resume.d" [Normal,Unconfirmed]  http://launchpad.net/bugs/31156
<mjg59> giftnudel: I don't see how this is an acpi-support bug
<mjg59> That file is provided by i855resolution
<mjg59> i915resolution should provide a similar one
<giftnudel> hmm?
<giftnudel> dpkgs -S showed me acpi-support
<mjg59> Nf.
<mjg59> What the christ is it doing in there?
<mjg59> Argh. I have no idea what I was thinking.
<Kamion> infinity: it hit Scott's "I'll get you next time, Gadget!" case
<Kamion> infinity: basically the problem is that libmysqlclient15-dev is already in the supported seed, and germinate doesn't want to promote it while it's processing the build-dependency tree stemming from desktop
<Kamion> this is obviously a germinate bug somewhere - it should treat it as a satisfied build-dependency anyway
<pitti> Kamion: btw, openssh test suite fails in sftp (without any changes from me)
<Kamion> pitti: file a bug
<Kamion> I'm deeply embroiled in other stuff right now and don't have brain-space for openssh :(
<pitti> ok, sorry
<mjg59> giftnudel: Fixed
<giftnudel> mjg59: ok, should I file a bug in 915resolution or did you add a file?
<giftnudel> mjg59: thanks anyway ;)
<mjg59> giftnudel: Fixed in the 915resolution that I just uploaded
<zakame> hi all!
<giftnudel> mjg59: thanks again
<Kamion> infinity: OK, fixed now; and you owe me a new brain. That was *hard*.
<Kamion> pitti: mozilla demoted, you'll be glad to hear
<Kamion> doko_: python2.3 demoted to universe, per anastacia
<pitti> \o/ thanks
<dholbach> woohoo!
<Kinnison> Kamion: what populates /etc/shadow?
<dholbach> GO Kamion GO!
<doko_> Kamion: cool
<Kinnison> Kamion: (the initial values)
<doko_> Kamion: what about g++-3.4 / libstdc++6-dev ?
<Kamion> doko_: on the list ...
<Kamion> Kinnison: shadowconfig called from user-setup
<doko_> Mithrandir: which package is responsible for /sbin:/usr/sbin not on the PATH?
<Kinnison> Kamion:  thanks
<Mithrandir> doko_: when's your install from?
<Kamion> doko_: that's fixed; to fix your system, run: /var/lib/dpkg/info/libpam-modules configure ''
<doko_> before out sprint
<fabbione> pitti: ping?
<pitti> hi fabbione 
<fabbione> hey dude
<fabbione> pitti: did you finish the 2 Main Inclusion reports for ipvsadm and keepalived?
<pitti> yes, I did, at Friday
<fabbione> pitti: cool thanks
<Mithrandir> doko_: a bit more precisely?
<fabbione> pitti: what was the next to move them main? bend over in front of Kamion?
<Kamion> they don't appear to be seeded
<pitti> fabbione: either seed it, or make them a dependency of something -> let anastacia bend over for you :)
<Kamion> unless they're in the server seed
<doko_> Mithrandir: the friday before our sprint
<fabbione> Kamion: they are not seeded and they will be in server seed
<Kamion> seed them, then
<fabbione> Kamion: either way i would have lost :)
<Kamion> I'll make anastacia look at ubuntu-server seeds (somehow)
<fabbione> ok
<Mithrandir> doko_: you probably fell victim to a bug in d-i, which nuked /etc/environment, then.
<Kamion> and xubuntu while I'm at it
<fabbione> Kamion: done thanks
* Kinnison goes out to the shops, back in a bit
<hyperactivecrond> i tested the daily ubuntu install iso for friday... want my experience?
<Kamion> bug reports are always welcome
<hyperactivecrond> alright.
<hyperactivecrond> Upon bootup, when one selects "boot from cd" the dialog that says 'loading' shows up and goes to 99% but 'Loading linux" and "Loading initrd" shows up on top above the Ubuntu logo
<hyperactivecrond> Maybe we should highlight by default in the "time configuation" part of the install NO when asked if the hardware clock uses UTC
<hyperactivecrond> For the "downloading packages" screen, the timer is messed up... sits on 0sec 
<hyperactivecrond> when it runs grub-installl (hd0) it runs kind of slow
<hyperactivecrond> ...and maybe we should make a splash screen for GRUB
<hyperactivecrond> EOF
<hyperactivecrond> no bugs that hinder the install though :)
<Kamion> by bug reports, I meant in the bug tracking system rather than here
<zul> hehe
<Kamion> we don't want everybody sending bug reports here because we could never get anything done
<hyperactivecrond> whoops. but no bad bugs that hinder install, so
<Kamion> please also check for duplicates; at least some of the above have already been reported (e.g. the UTC thing, the downloading packages thing)
<hyperactivecrond> ah. apologies
<hyperactivecrond> i'm out
<Kinnison> pitti: had a chance to look at that hal/pmi diff?
<pitti> Kinnison: not yet, but if it's really urgent, then I can do it now
* pitti looks
<Kinnison> pitti: If I can get a "interesting" vs "yuck" I'd be appreciative
<mvo> ogra: gnome-screensaver is not showing a unlock dialog, what can I do to debug/kill it?
* Kinnison has bugs depending on whether or not you like that patch
<seb128> mvo: gnome-screensaver --no-daemon --debug 
<seb128> mvo: probably redirect that to a log and read it after trying to unlock
<mvo> seb128: *grumpf* no I can't reproruce it anymore
<pitti> Kinnison: the really clean way would be to implement this as a probe in hald/linux2/probing
<pitti> Kinnison: changing properties in the init script is pretty ugly IMHO
<pitti> Kinnison: so, it's fine for me as an intermediate solution to fix some bugs, if we can find a cleaner solution with upstream eventually
<Kinnison> pitti: my original patch did it in osspec.c but that runs after privsep
<pitti> Kinnison: the hal probes run as root and thus can call pmi, too
<hyperactivecrond> when i apt-get install 'ed nvidia-glx, i logged out of GNOME and when I logged back in, it said that gnome-panel was already running.  Also, ctl-alt-backspace doesn't re-start gdm
<pitti> Kinnison: right
<hyperactivecrond> just fyi
<Kinnison> pitti: I see, I didn't understand those bits
<Kinnison> pitti: :-)
<Kinnison> pitti: If you're happy with that as an intermediate, will you upload a hal with it, and then we can look at a cleaner way later?
<pitti> Kinnison: just upload it yourself for now
<Kinnison> pitti: if you're happy for me to do that then sure
<pitti> Kinnison: yes, we can clean it up later together, no problem
<Kinnison> pitti: thanks dude
<pitti> no problem, I didn't do anything but complain for now :)
<Kinnison> heh
<pitti> Kinnison: btw, probe-hiddev.c is an easy probe that sets properties, that should be a nice example
<Kinnison> pitti: thanks
<Kinnison> pitti: the hal package means cdbs-edit-patch doesn't work :-(
<pitti> Kinnison: after I finished my security stuff backlog, I need to work on hal again anyway, then I can do this
<pitti> Kinnison: http://people.ubuntu.com/~pitti/scripts/cdbstpatch
<pitti> Kinnison: it's a gross and quick hack I did for cdbs+tarball
<pitti> Kinnison: it needs dbs installed (it uses dbs-edit-patch as backend)
<pitti> but it works reasonably
<pitti> one day I'll integrate it into cdbs-edit-patch
<Kinnison> heh
<ogra> mvo, sounds like bug 29178
<Ubugtu> malone bug 29178 in gnome-screensaver "password dialog doesn't have focus" [Major,Confirmed]  http://launchpad.net/bugs/29178
<mvo> ogra: I didn't got a dialog at all
<ogra> mvo, if an app grabs the focus before the dialog comes up you wont get it to show up
<stockholm> what does this mean?
<stockholm> Diagnostic-Code: X-Postfix; host fiordland.ubuntu.com[82.211.81.145]  said: 550 <silber@canonical.com>: Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command)
<ogra> i have no idea where to look for that yet, but i suspect metacity to be buggy, or certain apps ... i could reproduce it with synaptics vte stuff, got a configfile prompt that grabbed the focus
<ogra> stockholm, that usually means that the target address is unknown ...
<ogra> :)
<stockholm> ogra: yes. and that means? 
<stockholm> is jane no longer around?
<stockholm> did she fire herself?
<stockholm> (c:
<ogra> if you want to reach a female employee at canonical, its usually helpful to put a "jane." in front of the address ;)
* sladen grins
<ogra> helps in many cases ;)
<Treenaks> ogra: jane.ogra will get the Female version of you? :P
<mvo> ogra: have you tried to set "gtk_window_keep_above()" to make sure that it's at least always visible in the unlock dialog?
<ogra> (while i heard that new name considerations become trendy ... ;) )
<ogra> mvo, i havent changed anny gss code from upstream yet ...
<mvo> ogra: ah, ok
<ogra> will try that, thanks
<stockholm> ogra: but this mail worked before.
<stockholm> i received mail from it
<Kinnison> seb128: apparently upgrading FC4 to FC5 isn't supported
<stockholm> is her real address jane.si... nowerdays?
<Kinnison> seb128: so they solved it one would assume by removing the applet from the default config
<Kinnison> stockholm: it always has been
<ogra> Kinnison, so we should support FC4->dapper .... would be a great marketing deal *g*
<stockholm> duh, it was a cut and past error on my side. appologies.
<Kamion> apologies for firefox currently being uninstallable; the next publisher run should fix that
<Kamion> I was bitten by the combination of bug 31515 and bug 32135
<Ubugtu> malone bug 31515 in launchpad-upload-and-queue "change-override is too quiet by default" [Normal,Confirmed]  http://launchpad.net/bugs/31515
<Ubugtu> malone bug 32135 in launchpad-upload-and-queue "change-override.py -S incorrectly moves binaries no longer built by this source" [Normal,Unconfirmed]  http://launchpad.net/bugs/32135
<JaneW> Treenaks: ROTFL
<hyperactivecrond> what packages provides gdmsetup?
<pitti> dpkg -S gdmsetup should tell you
<hyperactivecrond> thx pitti
<Keybuk> ...why is bluefish suddenly the default editor for source code?
<seb128> Keybuk: what mimetype is your source code?
<Keybuk> C
<seb128> that's not a mimetype
<Keybuk> text/x-csrc
<sladen> mjg59: I don't think KEY_SUSPEND is getting through as it's not in the /sys/class/input/input0/capabilities/key bitmask
<seb128> Keybuk: hum, does the bluefish.desktop mention "text/x-csrc"?
<Keybuk> where would I find that?
<seb128> dpkg -L bluefish | grep desktop
<seb128> grep crsc ....
<Keybuk> yes, it mentions it
<Keybuk> in the MimeType=... bit
<Keybuk> along with test/x-chdr, application/x-perl, application/x-python, etc.
<seb128> does putting a text/x-csrc=gedit.desktop to /etc/gnome/defaults.list fixes it?
<Keybuk> I have one of those in my ~/.local/share/applications/defaults.list as a result of changing it in Nautilus
<Keybuk> and that fixes it
<seb128> k
<seb128> please open a bug, I'll fix that soon
<seb128> but better to have the bug as reminder :)
<Keybuk> seb128: bug 32140
<Ubugtu> malone bug 32140 in bluefish "Claims ownership of C, Perl, Python, etc. MIME types" [Normal,Unconfirmed]  http://launchpad.net/bugs/32140
<seb128> Keybuk: ah, that's a way to see the issue
<seb128> I was thinking to list those mimetype to /etc/gnome/defaults.list with a proper default rather (ie: gedit)
<Keybuk> "see the issue" ?
<hyperactivecrond> is it save to say in #ubuntu that flight 4s out?
<hyperactivecrond> never mind. once again
<seb128> Keybuk: "point of view"
<Keybuk> ah, it's more that I have no idea how the MIME type stuff works *this week*
<seb128> Keybuk: you can blame bluefish to listing them or you can blame the default file to not list them
<seb128> s/to/for
<sladen> mjg59: urm. *not* getting through
<Keybuk> I don't think the default file was there last week ;)
<Keybuk> I'm sure nautilus used to just make replacement .desktop files
<seb128> Keybuk: /etc/gnome/defaults.list is here since warty or hoary
<seb128> nautilus creates users .desktop when adding an handler for a mimetype
<seb128> and makes a default.list when changing a default with nautilus "open with" tab
<Keybuk> right ... I think
<Keybuk> anyway, it wasn't so much an opinion as a "I don't understand this stuff" stab in the dark <g>
<seb128> k
<seb128> the default system apps are listed to /etc/gnome/defaults.list
<seb128> with MimeType=app.desktop
<seb128> I'll put a =gedit.desktop for those
<jdub> seb128: morning!
<seb128> hey hey jdub ;)
<seb128> jdub: how are you?
<jdub> Keybuk: i do not push shiny without caring if it works or not.
<jdub> seb128: pretty hammered
<jdub> seb128: but good - it's very cold outside, but the office is very hot!
<seb128> "very cold outside", sissi ... :)
<zul> heh..it was -18 celsius in ottawa this weekend...thats cold
<mvo> wb dholbach
<sivang> hi all
* Keybuk wonders how anything using inotify works
<Keybuk> or is this documentation *way* out of date?
<Keybuk> pitti: you know about inotify, right? :)
<pitti> Keybuk: only what it is for
<Amaranth> zul: pfft, it got colder than that here
<sladen> mjg59: bingo  hotkey-setup needs to do  setkeycodes cc 204  before acpi-support can be used to send 204
<sladen> mjg59: ^ acpi-support's acpi_fakekey
<Amaranth> zul: our high on friday was -17 C, iirc the low was -19.4 C
<pitti> Keybuk: in any case /dev/inotify is obsolete, if you mean that
<Amaranth> yeah, look at how gamin uses it
<seb128> or gnome-vfs2
<Keybuk> pitti: ah, that's what I mean
<Keybuk> I just noticed we don't have one
* Keybuk looks for later documentation
<Amaranth> seb128: I haven't looked at the gnome-vfs2 code but I can't see if being easier to understand than gamin. :)
<Kamion> mjg59: I don't see why ttf-bpg-georgian-fonts is a native package?
<Kamion> is it just because there's no upstream tarball?
* mvo goes out a bit
<Kamion> is Gauvain Pocentek here?
<Kamion> actually, I'll just send mail, never mind
<jpatrick> Kamion: he is in #ubuntu-motu
<raphink> hi guys
<raphink> when are the testing pages to be updated with flight 4 ?
<raphink> they're for flight 3 currenly
<dholbach> raphink: It'd be great if you could do it :)
<raphink> dholbach: sure if you tell me how to do it properly
<raphink> dholbach: I'm currently testing kubuntu dapper flight 4 live i386
<raphink> and I've seen quite a lot of things to fix
<raphink> but dunno to report
<raphink> s/to report/where to report/
<dholbach> raphink: report to Malone and list the bugs you found as known issues
<dholbach> raphink: if you like... :)
<raphink> dholbach: what is the package for the splash screen we get at startup?
<raphink> :s
<dholbach> for kubuntu?
<jpatrick> usplash
<raphink> I need to report against this one
<dholbach> no idea, sorry
<dholbach> ah that one
<raphink> no jpatrick, before that
<jpatrick> :/ no idea
<dholbach> grub?
<raphink> dholbach: where you choose the languages and so on
<raphink> dholbach: it seems more complete than grub
<dholbach> languages? erm
<jpatrick> wait, I knew this one
* raphink tries to remember how this is called :s
<raphink> iso something
<raphink> lol
<raphink> well I think it's called isolinux actually
<raphink> but not sure ubuntu uses that
<jpatrick> I got it!
<jpatrick> gfxboot
<raphink> let's see
<Gloubiboulga> hi
<Gloubiboulga> Kamion, pong :)
<raphink> jpatrick: seems like that's what it is, thanks
<Kamion> Gloubiboulga: never mind, you have mail
<Gloubiboulga> yep, thanks
<Kamion> raphink: gfxboot-theme-ubuntu
<jpatrick> raphink: no problem :)
<raphink> Kamion: it's the languages that have a bug
<Kamion> gfxboot is the infrastructure, gfxboot-theme-ubuntu is the thing that actually draws the screen
<raphink> Kamion: selecting french as the language for the CD crashes the keyboard layout for some keys
<Gloubiboulga> Kamion, we've discussed this issue with Tonio and the devs, new packages will come tomorrow
<raphink> :(
<Kamion> raphink: already reported multiple times
<ogra_> Kamion, 
<raphink> Kamion: ok then ;)
<Kamion> your keyboard layout sucks rocks through a very narrow straw :(
<ogra_> openssh (1:4.1p1-7ubuntu4) breezy; urgency=low
<ogra_>   * Add /usr/games to the default $PATH for non-privileged users.
<raphink> good then
<ogra_> Kamion, did that ever enter debian ? ^^^
<Kamion> ogra_: it's in my local tree but not uploaded
<Kamion> the French keymap in console-data made my head explode and I couldn't figure out if I was getting the translation to gfxboot-ese right or not
<Kamion> evidently not
<ogra_> Kamion, would be nice if it could, debian uses our ltsp implementation in sid ...
<Kamion> ok, I'll do it now
<ogra_> so they have path problems 
<Kamion> may as well get it out of the way before moving to 4.3
<Keybuk> hmm, clearly I'm missing something about inotify ... anyone an expert and could help me for a moment?
<Kamion> Gloubiboulga: thanks. a launchpad bug means I can't reject it for the moment anyway ...
<Kamion> (bug 32145)
<Ubugtu> malone bug 32145 in launchpad-upload-and-queue "can't reject libswitch" [Normal,Unconfirmed]  http://launchpad.net/bugs/32145
<mjg59> sladen: Yeah, I figured that out
<mjg59> Kamion: Because there's no original tarball?
<mjg59> (Or wasn't when I downloaded it, anyway)
<mjg59> sladen: There's a trivial kernel patch to make that sane
<sladen> it's probably technically correct how it is
<Kamion> mjg59: yeah, I worked that out, is accepted now
<mjg59> sladen: I don't really see why - the table in the kernel is arbitrary, based on what's been seen in the wild
<Kamion> ogra_: uploaded
<ogra_> Kamion, thanks :)
<Keybuk> pitti: ping?
<sladen> mjg59: so if you fix the kernel it deals with all the other non working keys that broke recently
<Riddell> pitti: Keep is built for your reviewing pleasure
<Seveas> Kinnison, dude, scary pictures@planet 
<Kinnison> heh
<HiddenWolf> mvo: the dapper flight4 release announcement shows the inotify bug to. http://www.simplifiedcomplexity.com/images/screenshots/dapper/flight4/xchat-gnome-notification.png
<HiddenWolf> eh, inotify -> libnotify. :P
<HiddenWolf> and added to the bug, sorry for buggin
<mvo> HiddenWolf: thanks, indeed
<jdub> elmo: please sync listadmin 2.29-1 from unstable
<pitti> Keybuk: pong
<Keybuk> pitti: you added all the dhc_dbus stuff to dhclient-script?
<pitti> Keybuk: no, thom
<Keybuk> assumedly it does something to do with finding out whether dhcdbd has spawned that dhclient?
<Keybuk> bah, you're in the changelog
<xhaker> hill
<xhaker> the contraction of hi +all
<Treenaks> not "hi y'all" ?
<xhaker> or simply result of silly typing :)
<xhaker> i mistyped
<pitti> Riddell: ping
<xhaker> Has any change to a user's $PATH happened recently?
<pitti> xhaker: https://wiki.ubuntu.com/OneTruePath
<Treenaks> One path to rule them all!
<xhaker> thanks and all but.. my $PATH is /bin:/usr/bin
<xhaker> is this wanted?
<Riddell> pitti: hi
<pitti> Riddell: I just replied to bug 30956, it would be nice to discuss how to solve this
<Ubugtu> malone bug 30956 in amarok "No Dutch translation in Amarok" [Normal,Confirmed]  http://launchpad.net/bugs/30956
<xhaker> pitti: can you answer my question please?
<pitti> xhaker: oh, that looks wrong, please prod Mithrandir 
* xhaker prods Mithrandir
<Riddell> pitti: hmm, so the extract messages scipts just sets the po directory to be $PWD/po
<Riddell> which in the case of this package isn't the same as where the po files are
<pitti> Riddell: yes, because it finds a pot in po/, but none in build-tree/../po
<pitti> Riddell: so where are the original po files?
<Riddell> pitti: in the amarok-1.3.8.tar.bz2 file which gets extracted to ./source/build-tree/amarok-1.3.8
<pitti> ah, tarball
<Riddell> yeah
<pitti> so why isn't the pot file generated in build-tree, too, then?
<Riddell> because extract messages sets $podir to $PWD/po
<Riddell> I can patch that
<pitti> I'm not sure how I could change the current heuristics without breaking the import of other packages
<pitti> Riddell: hm, would patching be easy?
<Riddell> although not sure how to patch it so that the patch doesn't need to be changed for each new amarok version
<Riddell> pitti: should be, just change the extract messages scipt to have different $podir
<Riddell> set it to ./source/build-tree/amarok-1.3.8/po presumably
<pitti> build-tree/amarok-*/po ?
<Riddell> that could work
<Kamion> xhaker: run this to unfuck your path: /var/lib/dpkg/info/libpam-modules configure ''
<Riddell> I'll give it a try
<Kamion> xhaker: you probably installed from a daily install CD between Flight 3 and Flight 4?
<xhaker> Kamion: true.. onde day before flight 4
<xhaker> hehe, i was going to try to run the postinst of the libpam-modules
<Kamion> er, yeah
<Kamion> libpam-modules.postinst, not libpam-modules
<Kamion> localechooser (0.27ubuntu6) dapper; urgency=low
<Kamion>   * post-base-installer: Don't clobber existing contents of
<Kamion>     /etc/environment.
<Kamion>  -- Colin Watson <cjwatson@ubuntu.com>  Thu, 16 Feb 2006 15:21:28 +0000
<xhaker> that's better tho :P
<Kamion> that's when I fixed it
<xhaker> let's see :)
<Kamion> it only affects installs from dailies between Flight 3 and Flight 4, so we'll probably just live with not figuring out how on earth to fix that breakage on upgrades automatically
<sladen> pitti: oh gawd, ~/.pam_environment could really do with a better name
<pitti> I agree
<xhaker> Kamion: do i need to restart pam to get my PATH back?
<sladen> xhaker: you probably  need to log in again
<xhaker> that's what i meant :)
<xhaker> thanks
<xhaker> brb then
<xhaker> shweet
<xhaker> Kamion: thanks again
<lamont> seb128/pitti: please look at https://launchpad.net/distros/ubuntu/+source/util-linux/+bug/32136 and figure out who it really belongs to.  kthxbye
<Ubugtu> malone bug 32136 in util-linux "Unable to unmount remov. mediums without terminal" [Normal,Unconfirmed]  
<shaya> beagle changelog says that evolution backend was disabled because it doesn't work
<shaya> I've been using my own beagel 0.2.1 package (dpkg-buildpackage debian source) w/o a problem
<shaya> so wondering why it was disabled
<gouchi> Hi
<gouchi> #12741 is fixed in Dapper ?
<gouchi> I have upgraded my kernel in Breezy and grub change my entry !
<slomo> shaya: so searching your contacts in the evolution address book work for you in beagle?
<shaya> slomo: searching messages for sure does
<shaya> let me check contacts
<tseng> searching messages has nothing to do with it
<shaya> ok
<shaya> I have one contact in my evolution address book
<shaya> beagle finds it
<tseng> ok, it uses a custom widget now
<tseng> it might not blow up, but evo-sharp still doesnt properly support evolution-data-server 1.5
<tseng> i will reenable it when it does
<tseng> but searching mail is unaffected either way
<Marticus> is the web site maintainer available in this channel?
* ogra hands Kamion a bag with 5MB xscreensaver bits scrubbed off the CD
<Kamion> ogra: bonus
<Kamion> all flavours?
<ogra> Kamion, can you please un NEW xscreensaver-gl-extra and xscreensaver-data-extra after they built 
<ogra> Kamion, yupp
<shaya> ok
<Kamion> probably not this evening, I'm going out to karate RSN
<ogra> no hurry :)
<Kamion> but I can do a pass over NEW tomorrow morning, sure
<tepsipakki> Kamion: you seem to be on the CC, any news when the next meeting is held?-)
<Kamion> tepsipakki: er no sorry, see above about going out soon
<tepsipakki> ah, righto
<Kamion> tepsipakki: unilaterally declared as 2000 UTC
<Kamion> (tomorrow, obviously)
<tepsipakki> Kamion: ok, thanks!
<gouchi> is there a doc that present Ubuntu flavor ?
<gouchi> so that new user can choose his flavor ?
<Burgwork> gouchi, Ubuntu has GNOME, Kubuntu has KDE, Edubuntu is for kids and schools, Xubuntu has XFCE. Not much more to say
<gouchi> Yep I know :)
<gouchi> there is a little to tell
<Burgwork> generally if they don't know what those are, give them Ubuntu
<gouchi> for user that never heard about Linux
<Burgwork> IHMO, don't confuse new users with that kinds of questions, because they don;'t have the context to be able to make a meaningful choice
<gouchi> yep :)
<gouchi> just graphically :)
<Burgwork> gouchi, that still doesn't help them, becuase a pretty screenshot is not enough context to make that kind of decision
<gouchi> yep that's true
<Burgwork> so give them Ubuntu and if they want to explore later, let them
<gouchi> ok
<Kyral> i just tell'em to try them all
<Kyral> since KDE/GNOME/XFCE/etc can be installed alongside each other :P
<ogra> dholbach, ping ...
<gouchi> :)
<Seveas> Kamion, thanks for setting the meeting time. Are you going to send notices to the e-mail lists too or should I do that?
<sivang> Seveas: CC meeting?
<Seveas> sivang, yes
* mvo goes for dinner
<HiddenWolf> dholbach: since you touched gnome-games a while ago, do you know where it stores the scores for mahjongg?
<dholbach> /var/games
<HiddenWolf> Danke
<jmg> hi guys
<jmg> is there a hax to install the skype deb on dapper?
<jmg> or is it impossible
<Burgwork> jmg, please ask in #ubuntu, as this is not a support channel
<wasabi_> Huh. I think updating dapper just changed my bios UTC setting
<wasabi_> Cuz it's suddenly 10 PM
* mvo has connection problem to archive.u.c. anyone else experiencing this?
<Burgwork> mvo, me as well
<ogra> the webserver is down it seems
<ogra> pachine is pingable ...
<ogra> *machine
<ajmitch_> morning
<Burgwork> morning ajmitch_ 
<mlistus> hi all
<mlistus> i need help about cd customization. nobody answered on the other ubuntu channels. i figured this is the best place to ask for help
<Kamion> Seveas: go ahead, thanks - I've run out of time for tonight
<mlistus> hello?
<slomo> infinity, lamont: gst-plugins-ugly-multiverse0.10 isn't build on ppc for some reason... the buildds are idle but it is still at "Needs building"
#ubuntu-devel 2006-02-26
<dholbach> good night guys.
* sophie^ is away: mv sophie^ >> /dev/null
<trappist> man I hate public away messages.
* sophie^ is back (gone 00:00:42)
<Burgwork> sophie^, please turn that off
<sophie^> oops
<sophie^> script thingy
<Burgwork> sophie^, thanks
<sophie^> my apology...
<stockholm> i try to reach jeff bailey. what is the best email? rasperyginger and nisa seem to be out
<tseng> how about jeff.bailey AT canonical.com
<stockholm> ok, thanks
<shaya> mjg59: so yoi going to be packaging up aiglx? :)
<mjg59> shaya: Nope
<shaya> wondering whose going to win the battle of the bling
<mjg59> In the short term, probably aiglx
<mjg59> It's massively easier to integrate, and it has other practical side effects
<mjg59> In the long run? Fuck knows
<jsgotangco> heh
<Kyral> what is aiglx?
<azeem> http://fedoraproject.org/wiki/RenderingProject/aiglx
<setuid> Can someone tell me how "ubuntu-server" differs from the other variants? 
<sistpoty> setuid: afaik different packages on the cd, no sudo-er for first user, doesn't install ubuntu-desktop by default
<setuid> So it would be the preferred approach for a headless box, yes? 
<setuid> I'm looking for a debian-based distro that will allow me to throw mysql 5.x on there without much trouble
<setuid> I'm going to be building apache/php from source, but MySQL is kind of a pain to get right with the paths and such
* setuid finds #ubuntu-server and idles
<sistpoty> setuid: yes, if you want new stuff like mysql5, you'll (hopefully) like ubuntu-server... I didn't do a headless install though ;)
<sistpoty> (or headless setup)
<setuid> We'll see in about 39 minutes, when this download is done
<infinity> setuid: Out of curiosity, why build apache2 and PHP from source?  Is there anything I can change/fix to make the packages more appealing?
<setuid> infinity: Are you the Debian/Ubuntu Apache2 packager? 
<infinity> setuid: Yes.
<infinity> setuid: With PHP, I know our "try to include every feature we can" policy won't make everyone happy.  With apache2, though, I've been pretty happy with the packaging, even in large datacentre contexts.
<setuid> One major pet peeve (which is shared by hundreds of my peers), is to stop splattering the configs all over the place. /etc/httpd, /etc/apache2, /etc/apache-ssl, and all that. Apache1 is nice and clean (if you use includes for conf files of course) 
<infinity> setuid: Erm, the configs are in one place.  /etc/apache2
<setuid> Not if you install the ssl version (and why the hell is it two separate packages anyway?!) 
<infinity> setuid: You would only have /etc/httpd if you built from source.
<setuid> If you do port 80 and port 443, you need two separate packages, which are in two separate dirs. That's just odd, and even the Apache developers concur on that point. 
<infinity> setuid: If you're referring to apache 1.3 ("apache" and "apache-ssl" packages), I'd strongly recommend you move to apache2.
<setuid> If you build from source, you get /usr/local/apache, actually
<setuid> Well, Apache2 has its limitations, when compared to Apache1
<infinity> setuid: Also, "apache-ssl" is "apache with BenSSL complied statically"... You could just as easily install "apache" and "libapache-mod-ssl" to use mod_ssl in apache instead.
<setuid> But I'll digress for now
<infinity> (But that's all apache1.3 stuff)
<infinity> setuid: Hit me with the apache2 limitations.  Most of those should be long resolved by now.
<setuid> I've been doing apache+ssl+php+mod_perl+dav/etc. for years now with one script, one command.... and it does it all in one shot. 
<setuid> http://code.gnu-designs.com/apachebuild/
<setuid> That's my script, one for apache1, one for apache2
<setuid> Probably not updated for this month's releases, but I'll update it 
* infinity shrugs.  I don't much MIND if you build from source, I just want to address needs of people who prefer to build from source to see if our packaging can be more "correct" for more people.
<setuid> The way Debian does its configs is wildly out of spec, and far too confusing to make any logical sense. It takes me a couple of hours to unfuck the thing back into compliance. 
<setuid> pardon my french ;) 
<infinity> "compliance"?
<infinity> Compliance with upstream is to have one giant httpd.conf
<setuid> Right, back into some semblance of normalcy
<setuid> No it isn't, that's also braindead
<infinity> Which doesn't scale terribly well.
<setuid> But the whole symlink modules into separate dirs mess is a hack
<setuid> You enable modules by commenting them in or out, in the configs
<infinity> I'll politely agree to disagree on that one.
<setuid> And I make use of includes heavily in my main .conf file
<setuid> Which keeps things clean
<infinity> conf.d directories are a pretty longstanding tradition that Just Works.
<setuid> Right, so I'll undo that back into something I can manage better with scripts
<setuid> Having to do file IO just to update a vhost or enable/disable a module, is messy
<sistpoty> hm... I find the split apache2 config very good, managable and intuitive... but I didn't have to setup many webservers yet (only a few times)
<setuid> I split my apache1 configs, just not a 1-module-per-file thing like the Debian package does
<setuid> Modules are in modules.conf which in include in my main conf
<infinity> Yes, that's how our apache 1.3 packages do it.  We found it was quite a bit more painful to manage automatically.
<setuid> But I'll install it and see what I can do to minimize that damage. Maybe the process has changed in the last 6 months when I last looked. 
<infinity> The setup in apache2 is much simpler to handle.
<setuid> Have the ssl ProxyPass bugs been fixed? 
* setuid looks
<infinity> setuid: Do you have a bug number?
<setuid> http://issues.apache.org/bugzilla/show_bug.cgi?id=12355
<infinity> That's fixed in dapper, not in breezy.
<setuid> That's keeping one of my clients back on 1.3 for now, they manage the financial front-end firewalls/authentication for about 200 different banks/credit unions
<setuid> And for them, that's a showstopper
<infinity> Yeah.  I wanted to backport that fix to breezy, but got vetoed, with fairly good reason.
<infinity> So, will have to wait for dapper to release to get that one in a stable release.
<infinity> Oh, wait.  I lied.
<infinity> I wanted to backport it to HOARY, but couldn't.
<infinity> setuid: I got that fix into breezy before it shipped.  breezy is fine.
* infinity has a horrible memory for these things, had to check the changelog.
<setuid> Ok, give me a few minutes to get this thing installed and ssh routing on it so I can poke at your apache2 packages
<setuid> I'll give you some constructive feedback (btw, I've been doing this a long, long time... as both user, OSS developer and web dev)
* setuid owns, operates and manages gnu-designs.com (hosting/web), SourceFubar.Net (OSS project hosting), and contributes heavily to lots of projects, including my own... pilot-link and several embedded projects. 
<infinity> setuid: For the most part, criticisms of the split config will probably fall on deaf ears.  No one's stopping you from completely blowing away the config directory and doing it "your way", but this way works well for a lot of users and for package management scripts.
<infinity> setuid: Issues with the server itself, how it's built, features we (don't) include, etc.  Those are more important to me.
<setuid> I'll try to grok it... it just seems very unintuitive, and it isn't the way the stock install works if you do it from source
<setuid> I'll be running this behind squid, with deflate, in an EXTREMELY high-volume situation (10GiB of transfers/week, of http and files) 
<infinity> The stock install from source uses a config that's next to impossible to mangle in a Debian policy-compliant way.  We made a conscious decision to scrap it.
<setuid> And I'll be relying heavily on DAV in this particular case, as well as mod_perl 
<infinity> As for concernes about file I/O, that's clearly a non-issue, since apache only reads the config files on startup.
<setuid> By file IO, I meant management tools that read/write/modify that config, now have to open multiple (dozens of) file handles to do the same job
<infinity> Well, some constructive criticism there could be in the form of "I'd like a better view of what's in those files without having to look at all of them", etc.
<setuid> So from our perspective, its a ground-up rewrite of our tools, or a ground-up rewrite of the config as shipped in your packages, or we go back to doing source builds
<infinity> Lord knows we need to improve a2enmod/a2dismod to do some things like let you list what's currently enabled (and what'd available but disabled), etc.
<setuid> I don't use those tools, didn't even know they existed (something Debian-specific?) 
<infinity> But I'm assuming you already have a "default config" you use in your case, so you could just rm -rf /etc/apache2 and drop your own configs in if your tools DTRT for you.
<infinity> We obviously can't really cater to that case well. :)
<setuid> One small thing I'd love to see, is patching HARD_SERVER_LIMIT to a reasonable level, 256 is a bit low
<infinity> (Yes, a2{en,dis}mod is the interface used by module packages to turn themselves on and off, and for admins to do the same... Saves from manually mangling symlinks)
<setuid> I set that to 1024 here on Linux, and it works great
<setuid> $PERL -pi -e 's,HARD_SERVER_LIMIT 256,HARD_SERVER_LIMIT 1024,g' $WORKDIR/$APACHE/src/include/httpd.h
<infinity> I'm sure I have a Debian bug about it somewhere, but could you file a bug in Malone (pretty please) about HARD_SERVER_LIMIT?
<infinity> I do hit the Dbeina bug list every few months or so, but (as it's my job), I hit Ubuntu bugs more often.
<setuid> Let me get everything working and see if its even an issue with apache2, if it is, I'll file it, if not, I'll drop it as an apache1.x requirement
<setuid> Is the Preserve ProxyHost patch rolled into this? 
<infinity> It doesn't sound familiar to me, so I'll go with no.
<setuid> sec. 
<infinity> Again, a bug with a pointer to the patch and an explanation of what it does would go a long way.
<setuid> http://code.gnu-designs.com/apachebuild/PreserveProxyHost.diff
<setuid> You eat the host header, this returns that back to normal behavior
<infinity> Oh, wait.  apache 2.0 doesn't even have a HARD_SERVER_LIMIT... That was an apache 1.3 thing.
<HrdwrBoB> I have to second that
<infinity> I need to screw my head on and get into the right codebase. :)
<HrdwrBoB> the hard server limit is a ridiculous thing
<setuid> I've got a few of Rasmus' patches here too, but probably nothing you'll want in general circulation, they're for high-volume sites 
<infinity> setuid: Again, that may be an apache 1.3 only issue (the ProxyHost thing)... I'd have to dig through apache2 to see how it behaves.
<setuid> I'll test it out, as I said, I do a lot with squid in front 
<setuid> I'll find these things pretty quickly
<setuid> Ok, burn is done... I'll be back in 15 minutes when this headless install completes
<infinity> ProxyPreserveHost is a backport to 1.3 from 2.0.31
<infinity> (So, yes, it's supported in apache 2.0 out of the box)
<sistpoty> infinity: just a quick question about mysql-server: are the permissions for /var/run/mysqld intended to lock out world from the socket?
<sistpoty> (seems to break default package setups for e.g. phpmyadmin, since mysql -hlocalhost tries to connect through socket instead of network)
<infinity> sistpoty: No, that's a bug.  I'll fix it.
<sistpoty> thx infinity
<infinity> The directory should be 755, if you want to change it locally while I get around to doing an upload to fix that (and a few others)
<sistpoty> infinity: actually marcin` on -motu just reported this one, I'm a mere proxy ;)
<infinity> Heh.
<sistpoty> elmo: any ETA when syncs will be progressed again?
<setuid> What is "kickseed", and why does it hard-lock my machine during install time? 
<sistpoty> setuid: just guessing it has s.th. to do with preseeding debconf-options during install, but I don't really have a clue ;)
<setuid> hrm... weird that it would get all the way to that point, then hard-lock the machine
<sistpoty> setuid: indeed... but actually knowing what it does (instead of guessing) might give more hints ;)
<setuid> of course
<setuid> Locked up again, this time at 65% of evms... wtf. 
<setuid> I need to figure out how to make this install slimmer
<sistpoty> setuid: hw is ok, I guess?
<setuid> Yes, this server has run 24x7 for about 3 years without any problems
<setuid> I'm trying again 
* sistpoty is just looking for one special bug...
<sistpoty> setuid: have you tried turning acpi off via kernel-cmd-option?
<sistpoty> (maybe related to malone: #12483, but again just a guess)
<setuid> Looks like this disc fucked up the hardware somehow
<setuid> Does ubuntu-server poke any data into registers at boot/install time? 
<setuid> Its locking up like crazy now
<setuid> I just did a 5-cd install of SuSE 9.2 Professional on this about 2 hours ago, worked flawlessly. 
<Lathiat> setuid: No, of course not
<setuid> No lockups or anything, now I can't even get into the BIOS without it locking up on me, and it all started after I tried to install ubuntu-server on it 
<Lathiat> sounds like a bad co-indicdence
<Lathiat> i mean, stuff fiddles with all sorts of hardware
<setuid> Must be something fishy 
<Lathiat> but suse would do the same
<Lathiat> turn it off for a half hour
<setuid> I've pulled every card except NIC/video and cd drive and hdd
<sistpoty> maybe corrupted memory?
<setuid> I pulled the RAM and put in different RAM
<setuid> 512M of Crucial, bench-tested
<sistpoty> hm...
<setuid> man, this is so fucked up now
<setuid> Its just rebooting at the video card splash at POST
<setuid> rebooting, rebooting, rebooting
<infinity> "Can't get into the BIOS without locking up" sounds more like either dead cache, or overheating CPU (ie: dead fan), the former being much cheaper to fix.
<infinity> Or overheating video card, I suppose, but I can't imagine a server-class system with a fan-cooled video chipset.
<infinity> Also, s/former/latter/... Yay brain.
<setuid> You hit that one on the head, the cpu fans were wiggled out of their power connector, weren't spinning
<setuid> trying again
<setuid> hrm, screen went blank right after I hit Enter on the "Install base system" option
<setuid> Been blank for 5 minutes
<setuid> This 15-minute install is now taking me 2+ hours
<setuid> Hrm, I guess the kernel on here doesn't like my hardware
<setuid> ugh
<setuid> I got all the way to kickseed the first try, now I can't even get past the fbsplash
<setuid> Oh here we go.... "Uncompressing Linux... crc error -- System halted" 
<infinity> Hopefully you're not suffring fallout from the non-spinning CPU fan..
<infinity> (It's taken me all of 5 seconds running a CPU with no cooling to eat the L1 cache)
<setuid> Well I'll be... there's something I've never seen before
<setuid> Too many things on one +5 lead from the PSU
<setuid> HDD + CD + case fans
<setuid> Moved some to the other +5 leads, and now we're back in business
<setuid> Let's see if we can get past kickseed 
<LaserJock_away> gnight all
<setuid> arg!!!
<setuid> "debootstrap: : Unknown error 990"
<setuid> crap crap crap
<setuid> XFS file corruption with LVM
* setuid tries again 
<dholbach> Is somebody else's network-manager acting odd? like wrong dhclient usage, obtaining an IP from Zeroconf and then joining a mDNS multicase group with a strange IP?
<dholbach> ... which doesn't help me to get into the internet? :-)
<infinity> dholbach: As in "it's not invoking dhclient at all, and I had to go back to using ifupdown?"
<infinity> dholbach: If so, yes.
<dholbach> gar!
* dholbach looks at dhclient-dhcdbd-support.patch
<infinity> dholbach: Not sure if we should blame keybuk's latest n-m changes, or pitti's dhclient changes (that removed some dhcbdb support)
<robitaille> yes, wireless just broke for me as well...
<dholbach> infinity: reverting pitti's dhcp3 changes makes the world happy again. :)
<dholbach> But I can't really tell where the actual problem is.
<robitaille> bug 32223?  maybe?
<Ubugtu> malone bug 32223 in network-manager "NetworkManager doesn't work if latest dhcp3-client package is installed" [Normal,Unconfirmed]  http://launchpad.net/bugs/32223
<dholbach> hey pitti!
<ajmitch> morning pitti 
<dholbach> robitaille: yeah, but that's not the "reason" why it breaks ;)
<robitaille> the extra "-x"?
<dholbach> pitti: we were just discussing bug 32223 and dhcp3 :-)
<Ubugtu> malone bug 32223 in network-manager "NetworkManager doesn't work if latest dhcp3-client package is installed" [Normal,Unconfirmed]  http://launchpad.net/bugs/32223
<dholbach> pitti: but take your time :-)
<pitti> Good morning everyone
* pitti hugs dholbach and ajmitch 
<pitti> dholbach: hmm, Keybuk asked me to remove the dhcdbd patches...
<pitti> (bug 32134)
<Ubugtu> malone bug 32134 in dhcp3 dhcp3-client "does not update /etc/resolv.conf (when changed from NetworkManager)" [Normal,Fix released]  http://launchpad.net/bugs/32134
<dholbach> it seems like the dhclient usage from networkmanager doesnt work
<ajmitch> ok, time for me to go home, see you all tomorrow :)
<pitti> Ubugtu: bug 32134 !!!
<Ubugtu> malone bug 32134 in dhcp3 dhcp3-client "does not update /etc/resolv.conf (when changed from NetworkManager)" [Normal,Fix released]  http://launchpad.net/bugs/32134
<dholbach> pitti: be kind with Ubugtu :-)
<pitti> dholbach: ok, I'll discuss that with Keybuk and take a look at it
<dholbach> pitti: you rock! :-)
* dholbach hugs pitti
<sladen> On that subject, Firefox doesn't update its ideas about resolv.conf unless it's restarted
<infinity> dholbach / pitt : robitaille is right, bug 32223 does seem to hold the answer, not just the question. :)
<Ubugtu> malone bug 32223 in network-manager "NetworkManager doesn't work if latest dhcp3-client package is installed" [Normal,Unconfirmed]  http://launchpad.net/bugs/32223
<infinity> sladen: Great... So that means it has its own local cache of the contents of resolv.conf and doesn't just trust glibc's resolver?
<infinity> sladen: I don't suppose you have an urge to tear through libnss (or whatever's responsible) and find the offending code?
<dholbach> infinity, robitaille: awwww, yes.
* infinity does the "it builds, ship it" dance and uploads the new fglrx.
<robitaille> I finally  got my network working on the laptop.  Got my wired cable out from the closet, and then had to run dhclient3 manually after n-m found the wired connection. 
<infinity> robitaille: Hurrah for progress, eh? :)
<robitaille> a working network connection is always a good thing in life :)
* jsgotangco haven't done the n-m challenge
* robitaille loves n-m   always worked fine until tonight
<jsgotangco> i'll finish my flight4 pages first before i start doing stuff again
<dholbach> hey seb128!
<seb128> hi dholbach
<pitti> Hey Mith^W tfheen
<Micksa> grah
<Micksa> anyone know/care about this prob in dapper?:
<Micksa> http://knobbits.org/ws.png
<Micksa> ugly ugly bold font.  I had it working nicely before with an appropriate .Xresources but now it goes ugly. *sometimes*.
<seb128> what font do you use?
<seb128> what $PS1 do you have?
<Micksa> 6x10. um, big-arse $PS1 :) but the same issue occurs with e.g. joe using bold fonts
<Micksa> (don't say a word :P )
<Micksa> http://knobbits.org/tmp/dot-xrsources.txt
<seb128> Micksa: what is "6x10"? do you use g-t?
<Micksa> no, that's xterm.
<Micksa> shoulda said that, sorry :)
<Micksa> XTerm*font:             6x10
<Micksa> well well
<Micksa> 6x10         -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1
<Micksa> eeenteresting
<seb128> you should use g-t
<seb128> and pick a real font :)
<lifeless> seb128: is there some useful way of giving you feedback when evo hangs ?
<seb128> lifeless: gdb backtrace
<lifeless> seb128: k
<lifeless> seb128: I shall start doing that
<Micksa> I would use g-t if it didn't slow down gcc 8)
<seb128> lifeless: hang when doing fast switching on imap sometime?
<lifeless> seb128: into Malone ok ?
* Micksa ducks the flying gegls
<tepsipakki> micksa: shouldn't do that anymore
<seb128> lifeless: sure
<seb128> Micksa: dapper vte has been way optimized
<lifeless> seb128: imap yes, dunno about 'fast switching'
<seb128> lifeless: may be known (it hangs sometime for me too), get a backtrace that's the best way to know if that's the same hang
<Treenaks> lifeless: 'clicking on multiple folders in a row quickly'
<lifeless> Treenaks: oh, no not that
<tepsipakki> micksa: but I'm using 6x13 with g-t, and things look nice ;)
<lifeless> usually I come back to evo via alt tab
<tepsipakki> and fast
<seb128> Treenaks: can you reproduce a hang that way?
<Treenaks> seb128: I'm not using evo at the moment, but I used to get hangs in hoary that way
<seb128> Treenaks: ok, we can always use people able to reproduce a bug :)
<seb128> much easier to try patches that way
<Treenaks> seb128: sure :)
<tepsipakki> micksa: http://www.gnome.org/~davyd/gnome-2-14/
<seb128> it hangs for me, but like once every few days, so to say if that's a patch working ...
<Micksa> tee hee, "crack team of speed kings"
<Treenaks> seb128: Hmm.. would always running evo under valgrind/gdb work? :)
<seb128> Treenaks: no need for a hang
<Micksa> that phrase as so much potential for bad jokes
<seb128> Treenaks: which is nice with a hang is that you can attach gdb to the process whenever you want :)
<Treenaks> seb128: good point.. you'd have to be running a debug build though, right?
<viviersf> whos maintainer for nividia-glx /
<Micksa> hmmm!
<viviersf> ?
<Micksa> I WANNA BE IN A CRACK TEAM
<sladen> infinity: IIRC, yes.  It has its own async DNS resolver and it'll need patching (or just patching-out to use resolv again)
<Treenaks> Micksa: first, find a crack dealer. then come back ;)
<seb128> Treenaks: better yep, but half of the time a non-debug is enough to figure if that's a dup of a known issue
<Treenaks> seb128: wow, 'crack team of backtrace readers' ;)
<tepsipakki> Micksa: maybe someone can "push" you in the right direction ;)
<Micksa> Treenaks: already on it
* Micksa chortles heartily
<Micksa> man, gnome is goin off
<Micksa> *policies* now. well, "lockdowns"
<Treenaks> Micksa: yes, but implemented sanely, not as one neverending list of options
<Micksa> heh
<viviersf> who maintains nvidia-glx 
<infinity> viviersf: #ubuntu-kernel (and me)
<infinity> viviersf: But I'm heading out in a few minutes.  If you have a bug to file, please file it.
<viviersf> soz nm
<Micksa> and wobbly minimise!!!
<sladen> don't Apple have a patent on that crack
<Treenaks> sladen: they have the genie effect..
<Micksa> man, check out fluendo's site
<Micksa> open source is starting to *look* really sexy
<Micksa> okay, s/starting/continuing/ :)
<viviersf> infinity, soz found the bug filed already
<infinity> viviersf: Which bug?
<viviersf> infinity, the nvidia-settings + glx bug
<infinity> viviersf: That's already been fixed.
<infinity> (base)adconrad@cthulhu:~$ apt-cache show nvidia-glx | grep ^Conflicts
<infinity> Conflicts: nvidia-glx-src, nvidia-settings
<hunger> Could someone please move S18displayconfig-hwprobe.py to a point where python is actually available? (aka. after /usr is mounted).
<sladen> Micksa: sexy?  You /do/ remember the original Ubuntu backdrops don't you...
<Treenaks> sladen: they didn't wobble!
* sladen blinks and stares, just *don't*.
<Micksa> dammit, where is this app?
<Micksa> http://www.gnome.org/~davyd/gnome-2-14/images/compositing-manager.png
<Treenaks> gconf-editor you mean?
<sladen> compiz?
<Micksa> ah
<Treenaks> or the latest version of metacity?
<Micksa> yeah
<Treenaks> sladen: this is all metacity
<Micksa> gconf-editor
<Micksa> I guess gconf-editor is what you use to tweak all the stuff that's been hidden in the name of It Just Works?
<Treenaks> Micksa: yeah :)
<Treenaks> Micksa: or gconftool-2 if you're hardcore
* Micksa tries to get gconftool-2 to do something
<Micksa> ... nope, apparently I suck
<seb128> "thread_db_get_info: cannot get thread info: generic error"
* seb128 kicks gdb
<giftnudel> generic errors are nice, at least you know what's going on
<Micksa> man, I'm gonna end up being one of those half-assed techie suit guys that doesn't really know about anything
<Micksa> I'm scared
<Micksa> when DOS was king I knew more than anyone
<jsgotangco> lol
<raphink> Micksa: if you prefer using a console, you can do so ;)
<raphink> Micksa: quite everything can be done with the console
<TheMuso> raphink: I can vouch for that.
<Micksa> well yeah but that's not my point.
<Micksa> I used to be able to recite fucking *interrupt numbers*.
<raphink> what's your point then Micksa ?
<Micksa> now I have to ask how to configure my apps.
<Micksa> it's depressing
<giftnudel> your too old, just realize it ;)
<raphink> ah ok
<Micksa> GNAGRGH
<raphink> if you want to do computer stuff, better stay up-to-date
<Micksa> it's a horrible decision to make
<Micksa> I used to be like a magician
<Micksa> but like, well
<Micksa> I was the kind of guy who could recite interrupt numbers
<raphink> hhmmm so ?
<raphink> there are books that list interrupt numbers
<Micksa> it's a good thing in *some* circles ;)
<raphink> I used to have a program on Mac OS that would give me the description of each
<infinity> Very short books, I'd assume, as there were only 15 standard PC interrupts.
<Micksa> nono, I'm talking about the, um
<infinity> Anyhow, the lamenting of your aging computer skills is seriously offtopic.
<raphink> infinity: hehe
<Micksa> the values you'd set AX to to perform whatever operation
<infinity> Like int 10h, and such?
<infinity> Yeah, a few more of those.  Still offtopic. :)
<Micksa> OKAY, FINE. </rant>
<raphink> Micksa: apart from complaining on the obsolescence of DOS, do you plan on helping with Linux?
<Micksa> wel not *right* now. I just felt the urge to rant. sorry.
<Micksa> I have blue-sky dreams of helping with Linux in a way not unlike how Mark Shuttleworth is :)
<hunger> Micksa: So do I... unfortunately I do not have the wits to get that kind of money together in the foreseeable future:-(
<Micksa> I sure am ambitious and confident huh
<madduck> Kamion: thanks for the reply and sorry for getting it mixed up. *this* way around it makes perfect sense!
<sladen> Riddell: is Kubuntu following the Ubuntu way of letting hotkey-setup handle the mapping of special keys?
<sladen> Riddell: if so, I can tell these people to stop playing with xmodmaps
<stub> Launchpad will be going down in 15 mins. Estimated downtime is 10 minutes. Wikis will be in read only mode during this period.
<sladen> Riddell: eg. 27542
<Kamion> madduck: no problem, sorry for the delay in digging into it
<pitti> dholbach: yay, I fixed dhcdbd and dhcp3 to finally work properly with networkmanager
<sivang> morning follks
* dholbach hugs pitti
<sladen> has any here got an old-style Compaq (pre-HP) with special keys along the top?  I could do with some keycodes confirming
<Treenaks> thpethial keys?
<infinity> pitti: Did you disable dhcdbd's usage of the '-x' flag, or patch dhclient with RedHat's patches to support it?
<infinity> pitti: (Yes, I was just looking at the same bug while waiting for Zofia to get ready to go out)
<pitti> infinity: the former, and I fixed dhcp3 to actually notify dhcdbd again
<pitti> infinity: AFAIU Keybuk, we don't need the -x stuff
<infinity> pitti: The feature is interesting anyway, outside the scope of NetworkManager.  But I somehow doubt users are climbing over each other to get it.
<infinity> pitti: I expect with a bit of polish, it'll end up in ISC upstream eventually.
<pitti> infinity: yes, that's what I'd like to see, too; the patch is pretty intrusive
<pitti> well, let's see what else breaks
<pitti> we can always reactivate it if we really need it
<infinity> Ahh, I haven't looked at the code, just read up on what "-x" does.
<infinity> If the patch is ugly, I'm all for dropping it, since we don't actually need it.
<pitti> yep, that's what I did in ubuntu5, but I was a bit overzealous
<infinity> :)
<pitti> I dropped the dbus-send, too :)
<pitti> now I put it to the right place
<sivang> pitti: I'm too busy with working on HUB, not sure I will have time to create the patch for the volume capabilities. Have you requested / got UVF exception for the new upstream?
<siretart> morning
<siretart> are there versioned dependencies in rpm packages at all?
<sivang> siretart: why are you touching rpm ? :)
<j^> how can i switch off all notifications? i dont need them, i.e. i know if i unplug my power cable also the brightnes of my display changes, that is enough feedback for me
<siretart> sivang: I don't touch it. it is a discussion about packaging a library: comparison between rpm and dpkg
<sivang> siretart: ah, I see.. u-d ML ?
<Kamion> yes, rpm has versioned dependencies
<Kamion> see http://www.kitenet.net/~joey/pkg-comp/
<siretart> ah, thanks for the link, Colin
<pitti> aaargh, WTF is linux-source-2.6.15 a native package nowadays???
<fabbione> pitti: yes
<fabbione> it needs to be
<Kamion> why does it need to be?
<pitti> fabbione: that sucks, why does it need to?
<Kamion> surely "fetch upstream tarball, stick it in ../linux-source-2.6.15_2.6.15.orig.tar.gz" would work fine
<pitti> the official 2.6.15 could be the orig.tar.gz
<fabbione> Kamion: we are upstream of ourself..
<jdub> released from git branch?
<Kamion> fabbione: sorry dude but last I checked everyone else thinks Linus is upstream for the kernel
<fabbione> pitti: we pull too many patches.. really.. the diff.gz is HUGE
<Kamion> I know we have our own version control, but that's not the same thing
<fabbione> jdub: yup
<jdub> makes sense to me
<Kamion> the tar.gz is huge too
<jdub> that's the UBUNTU SIX MONTH TIME BASED KERNEL RELEASE branch :-)
<Kamion> I don't see a problem with the diff.gz being huge :)
<fabbione> Kamion: we are in git from where we push/pull from Linus.
<fabbione> there is no concept of upstream anymore
<Riddell> sladen: hotkey-setup?  stuff like that should be handled by kmilo
<fabbione> Kamion: it only makes a tad easier to work.
<Kamion> there is a version of the kernel called "2.6.15"
<Kamion> we describe our kernel as "2.6.15"
<fabbione> there is also a version called 2.6.15.4
<Kamion> therefore the .diff.gz should describe our differences from 2.6.15
<Kamion> perfectly normal practice
<fabbione> not according to your POV
<Kamion> the only difference for the kernel is the fact that it's huge
<fabbione> it doesn't come from "upstream"
<fabbione> but it's upstream for us...
<fabbione> we have too many upstreams...
<pitti> I just wanted to check which parts we patch (my friend's vesafb breaks)
<fabbione> pitti: that's why you have git :)
<fabbione> git-whatchanged $file
<pitti> fabbione: grepping a diff.gz is way easier for me than to learn git just for that
<Kamion> we have .diff.gz files so that we don't have to learn every revision control system on the planet
<sladen> Riddell: for Ubuntu, hotkey-setup and acpi-support make sure that standard keypresses are generated for all magic keys (these are defined in the kernel, see /usr/share/acpi-support/key-constants)  The gnome-power-manager and crack acts on those
<Kamion> or check out repositories that take hours to check out
<fabbione> Kamion: well the sabdfl wanted our kernel in git...
<Kamion> (when you already have a local mirror)
<Kamion> fabbione: that's TOTALLY ORTHOGONAL to whether you have a .diff.gz
<Kamion> it is UNRELATED
* Kamion enters ZIPPY the PINHEAD mode
<chmj> Kamion: you can still have a look at .diff.gz 
<fabbione> Kamion: dude.. you forgot your capslon on
<chmj> it is there ! 
<fabbione> caplock
<sladen> Riddell: so I'm assuming kmilo would eat those standard kernel/Ubuntu key codes in a similar fashion?
<siretart> sladen: is hotkey-setup supposed to make ibm volume keys generating x-events?
<Kamion> <cjwatson@riva ~>$ ls /mirror/ubuntu/pool/main/l/linux-source-2.6.15/*.diff.gz
<Kamion> ls: /mirror/ubuntu/pool/main/l/linux-source-2.6.15/*.diff.gz: No such file or directory
<Kamion> chmj: no it's not
<pitti> chmj: it's native now
<sladen> siretart: they will, when elmo has synched 0.14 from Debian
<siretart> sladen: I see
<chmj> Kamion: oh brother, I use git... *hides* 
* siretart goes and builds hotkey-setup_0.14
<Kamion> yeah, you expended the several hours initial bandwidth to get a checkout
<janimo> Kamion, can you please move xfdesktop4 binary out of new? thanks
<Kamion> I have a local mirror so that I don't have to check out everything known to man in order to see what our differences are
<Riddell> sladen: well kmilo makes the mistake of trying to do everything, reading the keys and handling them, where it should read the keys and make sure a standard keypress is generated then let kmix/klaptopdaemon etc handle them
<sladen> siretart: let me know how you get on
<Kamion> janimo: last I checked it wasn't in NEW ...
<Kamion> janimo: I can't check right now because launchpad is down (I think)
<sladen> Riddell: right, everything up to the 'generate a standard keypress' is already handled now
<Pygi> Kamion: launchpad is not down...
<janimo> hmm, I thought that was what you and mdz told me on Friday (was in warty - no longer since hoary discussion)
<Kamion> Pygi: well soyuz is hosed, whatever
<sladen> Riddell: so if klaptopdaemon listens for KEY_SLEEP/KEY_SUSPEND and kmix listens for KEY_VOLUMEUP/KEY_VOLUMEDOWN then that would work
<janimo> I don;t know why else it does not show up in http://archive.ubuntu.com/ubuntu/pool/universe/x/xfdesktop4/
<Kamion> janimo: I don't recall that being about xfdesktop4
<janimo> since it build on Wed or Thu I think
<Kamion> xfdesktop4 | 4.3.6.4-1ubuntu3 | dapper/universe | amd64, hppa, i386, ia64, powerpc, sparc
<sladen> Riddell: s/would/should/
<Kamion> xfdesktop4 | 4.3.0svn+r19908-0ubuntu1 | dapper/universe | source
<Kamion> hmm, that looks odd
<janimo> yes the latter is the new source providing the same binary
<janimo> for warty we had debian upstream
<Riddell> sladen: yeah, but they don't, and nobody has had time (or hardware) to fix it
<janimo> for hoary changed to another external package
<Kamion> janimo: 4.3.0svn+r19908-0ubuntu1 < 4.3.6.4-1ubuntu3
<janimo> than back now to debian source
<Kamion> you can't do that
<Kamion> version numbers must increase
<janimo> oh, that. Rigth so both source and bin versions must incereas
<janimo> thanks I completely forgot that, I wish LPL would have mailed me
<Kamion> well, especially binary versions
<Riddell> infinity: could you give back ept?
<Kamion> since those are what users install (and apt won't downgrade automatically)
<janimo> Kamion, thanks
<Kamion> so either use a higher version number, or (less good) an epoch
<sladen> Riddell: hotkey-setup is in the kubuntu-seed?
<janimo> higher version, since it will become 4.4 soon anyway
<siretart> uuh, hotkey-setup collides with tpb.. hmm
<siretart> Cannot open /dev/input/uinput: No such file or directory
<siretart> Could not open uinput device: Bad file descriptor
<siretart> sladen: ?
<sladen> siretart: sudo modprobe uinput ?
<sladen> siretart: which it should do
<siretart> sladen: yes, the keys are not creating xevs
<siretart> they don't have Keysyms mapped, though
<siretart>     state 0x0, keycode 159 (keysym 0x0, NoSymbol), same_screen YES,
<siretart> for my Access IBM key
<Riddell> sladen: yes
<siretart> sladen: can I still control my hardware mixer somehow? I assume that the keys only control the software mixer, right?
<sladen> siretart: actually they move both if you have a normal thinkpad, and just the software mixer if you have an Acer knockoff
* siretart has an R40
<sladen> siretart: AccessIBM should generate KEY_PROG1 and can you remap that from  System->Preferences->Keyboard Shortcuts
<siretart> hm. interesting
<sladen> siretart: the R40e doesn't have a hardware mixer;  I think the R40 does
<siretart> yes, the R40 has
<sladen> siretart: try playing some music and check the volume up/down/left/right/mute  do as expected  (Don't think too hard, so try it as a normal user would expect when they don't know there are two mixers)
<siretart> sladen: great work. Works as expected!
<sladen> siretart: then I'll tell you the one case where it doesn't
<siretart> sladen: what is the special case?
<sladen> siretart: (hardware mute, followed but right-click software unmute)
<siretart> puh. you're right. 
<siretart> that could be somewhat confusing
<sladen> I have written a separate little daemon to sync the software mute status back to the hardware, but I haven't worked out where to load it from...
<siretart> it unmutes as soon as the user presses the volume keys on the keyboard again..
<siretart> I see
<seb128> Kamion: if I want to give a try to espresso, better to use flight-4 or daily CD?
* Chipzz kicks tomcat :P
<Chipzz> pos :P
<Kamion> seb128: no difference yet
<seb128> ok
* seb128 goes to download
<Kamion> will be from tomorrow though, I'm adding a language dialog
<Kamion> er, page
* mvo goes to grab some food
<Kamion> janimo: the use of Conflicts in xfce4-mixer-{alsa,oss} is weird
<janimo> Kamion, what should it look like?
<Kamion> janimo: you have Conflicts: xfce4-mixer (<= 4.3.0-1) in both of those
<Kamion> janimo: shouldn't that bit be in Replaces instead? since you ship files in those packages that used to be in xfce4-mixer
<janimo> between alsa and oss or between versions?
<Kamion> that's what Replaces is for
<Kamion> the bidirectional Conflicts between alsa and oss is fine
<janimo> I'll have a look, thanks
<Kamion> but you definitely need Replaces: xfce4-mixer (<= 4.3.0-1)
<Kamion> if installing xfce4-mixer-{alsa,oss} 4.3.x will break xfce4-mixer <= 4.3.0-1, then the Conflicts is fine too
<Kamion> am I being at all clear? :)
<Kamion> basically, whenever you move a file from one package to another, you must have a Replaces in the new package
<janimo> yes
<janimo> clear :)
<Kamion> Conflicts+Replaces has a special meaning documented in Debian policy
<janimo> I have keybuk's rant on the subject bookmarked but need to read it more often than once per week :)
<Kamion> his rant's kind of not very much related to this
<janimo> hmm, maybe that's why I am getting it wrong then
<janimo> I know I need replaces if a package overwrites some files in another
<janimo> I'll have to see why I did not do this in mixer
<ogra_ibook> his rant only says that Conflicts+Replaces only apply to files inside the package, not to the package itself 
<Kamion> right, doesn't apply here because they really do share files
<ogra_ibook> ah
<janimo> yes but it contains useful bits of info
<janimo> the rant that is
* janimo goes to see what changed on the server so that the xubuntu seeds are no longer seen by the mirror script
<Kinnison> Kamion: May I please pester you for a UVF exception for gnome-power-manager again? Richard Hughes has been taking on board vast amounts from our users and released 2.13.91 (to replace 2.13.90) last night. Packages at http://people.ubuntu.com/~dsilvers/gpm-nuv/
<Kamion> Kinnison: looks fine, thans
<Kamion> +k
<Kinnison> Kamion: thank you, I think he's trying to follow gnomeish release patterns on this, I'm not sure
<Kinnison> #op[
<Kinnison> ] 
<Kinnison> p] [[[
* Kinnison grins sheepishly as he drops a plate on his keyboard
<seb128> they proposed g-p-m for GNOME desktop that cycle
<seb128> it was rejected for somes details though (lack of integration, etc)
<seb128> but I think they follow the cycle anyway
<Kinnison> right
<sivang> morning Kinnison 
<sivang> Kamion: HUB related question: when attempting to burn the same filename on a multisession CD, do they conflict? (trying to think how to deal with incremental backups and successive ones by the same file name)
<Treenaks> sivang: afaik, they overwrite
<Treenaks> sivang: (or replace, depending on how you look at it )
<sivang> Treenaks: even if it's a CDR and not CDRW ?
<Treenaks> sivang: Well, they will be re-written, but the same filename points to another piece of disk
<sivang> Treenaks: okay, cool, thanks. What I had assumed :)
<Treenaks> sivang: so for the user it looks like it's overwritten, but it does cost you disk space
<Treenaks> (and in Cd-players that don't understand multisession, you'll only see the first session, afaik)
<pitti> Kinnison: I uploaded more security stuff today, but the last lp_queue mail I got was from 09:45 today; did it stop for some reason?
<Kamion> there was a launchpad rollout, but it's not entirely obvious to me that soyuz has been restarted
<Kinnison> There was a raft of permissions errors in the launchpad tree rolled out to drescher
<Kinnison> it has not yet been restarted
<pitti> ok, so it's known; good
<pitti> Riddell: hmm, I can't test the new amarok, soyuz doesn't appear to export translation tarballs 
<Riddell> pitti: that could be quite a problem for our non-english speakers :)
<freeflying> who is in charge of the archive server of ubuntu
* Kinnison apologises. A minor hiccough in the archive mailing scripts means that the dhcp3, dhcdbd xfce-mcs-plugins xfdesktop4 localechooser kde-guidance and gnome-power-manager announces got sent to the maintainer instead of the list
* Kinnison will be working on sending them to the list
<pitti> Kinnison: does the cronjob run again for the invocation in 8 minutes?
<ogra> jdub, 12_shaped_splash.patch results for me in 12_completely_invisible_splash.patch on poerpc
<ogra> *powerpc
<Treenaks> ogra: \o/ ?
<Kinnison> pitti: should all be back up now
<pitti> thanks
<dholbach> ogra: that's functionality which will be exposed by a change in ubuntu-artwork
<ogra> dholbach, ah, the changelog didnt mention that ... i was waiting for a shiny new screen :)
<dholbach> we all were
<dholbach> :-)
<ogra> is that documented somewhere, so i can keep up with edubuntu-artwork ?
<ogra> jdub, ?? ^^^
<dholbach> ogra: sent you a link
<ogra> thanks
<Kinnison> I've bounced the announce mails to the list
<Kinnison> their 'to' line is a bit buggered but at least they're archived now
* xerox_ praises the men who fixed with the last updates and let him install libnotify-bin
<doko> is archive.ubuntu.com down?
<hunger> doko: Worked for me.
<hunger> doko: Was awfully slow for the last couple of min though.
<rjune> pitti: Is there a reason that there hasn't been anything like /etc/profiles.d/ setup for sudoers? aka, /etc/sudoers.d/ ?
<pitti> rjune: what should that be good for?
<pitti> rjune: ah, you mean a split sudoers file?
<rjune> well, in my case, I want to add a line so that anybody can run a specific command as a specific user.
<rjune> yeah
<pitti> rjune: I guess that would just encourage packages to drop stuff into it, which would be wrong
<pitti> rjune: just write it into /etc/sudoers?
<rjune> is there a reason it would be wrong? or is that just accepted practice?
<rjune> I would prefer to do it with a package, not manually
<pitti> rjune: that's exactly the way it is intended to
<pitti> no, you don't want packages to mess with your sudo privilege policy
<pitti> s/you/we/ :)
<rjune> well actually, I do want *MY* packages to. maybe not yours.
<rjune> I admin a bunch of LTSP boxes, and it would be nice if I could just push out the package and be done with it.
<Kamion> /etc/sudoers is a configuration file, not a conffile; so your package could just append to it
<rjune> I do that now, it's just cleaner the other way
<Kamion> .d directories are more useful for conffiles (i.e. configuration files that are actually shipped in .debs rather than edited in maintainer scripts) because editing those in packages has harmful effects
<Kamion> I'd be inclined to avoid the extra complexity of dealing with lots of configuration files in a program that elevates privilege
<Kamion> the simpler the better
<ogra> Keybuk, i noticed that if i run nfs connections over nm managed interfaces it gets very flaky ... 
<rjune> but writing scripts to deal with sudoers is way easier?
<ogra> Keybuk, could that be a dchpdbdb bug ?
<Kamion> those scripts are not setuid and installed on hundreds of thousands of machines worldwide :P
<Kamion> the consequences of them going wrong aren't as bad
<Kamion> dealing with sudoers is pretty trivial, anyway
<rjune> it's not too bad, thats true. 
<Kamion> I think if it were a less critical program then a .d directory might well make sense, but we should keep sudo as simple as we can (well, relative to its current extremely complex state ...)
<Keybuk> ogra: shouldn't think so ... dhcdbd is just "run and kill dhclient"
<ogra> hmm, k
<ogra> its just that i see it on different machines ... 
<ogra> ls takes about 10mins to respond for example ... if i remove nm and bring up the interface manually it works as expected
<Keybuk> odd, wireless interface?
<ogra> yup
<ogra> both bcm43xx ....
<ogra> one in my ibook, one linksys pcmcia card ...
<ogra> i'll test with another card soon (currently busy with the last feature goal work)
<ploum> http://ploum.fritalk.com/cosmogotchi.png : my answer to jdub post !
<ploum> Also http://ploum.fritalk.com/cosmogotchi2.png seems a bit improved
<Treenaks> ploum: whoa :)
<ploum> hello Treenaks :-)
<Treenaks> You've been taking lessons from Yoe? :)
<ploum> Yoe ? 
<HiddenWolf> ploum: sweet. 
<ploum> No, I'm just using gimp. This wonderful software does it nearly alone !
<ploum> :-)
<Treenaks> ploum: You. Wouter Verhelst
<Treenaks> ploum: uh.. Yoe that is
<ploum> I'm not sure I can do as good looking hackergotchi as he does
<Treenaks> ploum: he wrote the HOWTO :)
<ploum> Treenaks: yes, I think I've read it once !
<ploum> So he deserves the credit :-)
<ploum> Wouter also created planet.grep.be which is very cool :-)
<jsgotangco> sladen: thanks, i understand bug 32267 now
<Ubugtu> malone bug 32267 in linux-source-2.6.15 "Hibernate function key KEY_SUSPEND is dropped by kernel." [Normal,Confirmed]  http://launchpad.net/bugs/32267
<sladen> jsgotangco: lets make that the canonical bug then unless I find a better one
<jsgotangco> sure
<Mithrandir> sladen: you're insane. :-)
<sladen> Mithrandir: which particularly piece of crack?
<Mithrandir> sladen: the casper raw device crack.
<Mithrandir> sladen: get_fstype won't ever return "cloop", there's no way to detect a cloop image.
<Mithrandir> (or, there might be, but fstype won't give you it)
<sladen> Mithrandir: sure there is, it starts with   #define CLOOP_PREAMBLE "#!/bin/sh\n" "#V2.0 Format\n" "insmod cloop.o...
<jbailey> Keybuk: Haround?
<Keybuk> yup
<sladen> Mithrandir: want me to file a bug?  ;-)
<jbailey> Keybuk: This morning's reboot got the interfaces in the right order, but didn't seem to actually run the dhclient on it.  ifup claimed the interface was already up.  Where's the best place to look to see what happened?
<Mithrandir> sladen: it's not an fstype anyway so no, no need to.
<Treenaks> jbailey: are you using resolvconf?
<Keybuk> jbailey: *blink* ... that makes it sound like /var/run/network/ifstate had stuff in it
<jbailey> Treenaks: If that's a package, I don't have it installed.
<Keybuk> which makes it sounds like /var/run isn't a tmpfs
<jbailey> varrun                 2018640       100   2018540   1% /var/run
<Keybuk> check /etc/network/interfaces too
<jbailey> auto lo; iface lo inet loopback; auto eth0 ; iface eth0 inet dhcp; iface eth1 inet dhcp
<jbailey> Which is correct - eth1 isn't plugged into anything.
<jbailey> I only have it defined in there so that when the interfaces got mapped wrong I could ifup eth1 and get going. =)
<Keybuk> right
<Keybuk> what's in /var/run/network/ifstate ?
<jbailey> That 2 gigs is a maximum, right? =)
<jbailey> lo=lo; eth0=eth0
<Keybuk> that two gigs is your memory usage :)
<Keybuk> ok ... uh, check /proc/mounts for /var/run ;)
<jbailey> tmpfs /var/run tmpfs rw 0 0
<Keybuk> just checking
<Keybuk> right
<Keybuk> so it's up then
<stockholm> ah, jbailey 
<Keybuk> do you have network-manager installed?
<Keybuk> or dhcdbd?
<jbailey> stockholm: g'm.  Scott might ask me to reboot, so chatting should wait for a sec.
<jbailey> Neither.
<stockholm> sure
<sladen> Mithrandir: if you're going to take that patch and you think it'd be worth it I could add something  [ $(dd if=/dev/$dev bs=1 count=10) = '!#/bin/... cloop shebang' ] 
<Keybuk> jbailey: no dhclient3 running?
<stockholm> my wife stole my phone
<jbailey> Keybuk: FWIW, this is my dual g5 box - not a laptop or anything.
<jbailey> dhcp      5017     1  0 08:17 ?        00:00:00 dhclient3 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0
<jbailey> dhcp      5273     1  0 08:26 ?        00:00:00 dhclient eth0
<sladen> Mithrandir: the other optimisation that can be done is that if it's a squashfs it doesn't need mounting via a loopback and can be used directly
<jbailey> Hmm
<Mithrandir> sladen: cloops are deprecated, so no need.
<Keybuk> jbailey: that "dhclient eth0" is suspicious :)
<jbailey> Keybuk: That's the one I ran by hand, I suspect.
<Keybuk> indeed
<Keybuk> well, I don't see a problem here
<Keybuk> everything is consistent, the interface is up and dhclient3 is running on it
<Keybuk> it may be just that dhclient isn't getting an IP
<jbailey> Is there any way to ask dhclient3 why it hasn't seen fit to give me an IP address?
<Keybuk> it usually says in the syslog every time it tries
<sladen> Mithrandir: I was assuming other people might still use casper and choose a cloop
<sladen> Mithrandir: everything else is still agnositc
<jbailey> Keybuk: 'kay.  When I next reboot if I get the same thing, I'll dig i nthere to see what I find.
<jbailey> Thanks, Scott.
<hunger> Any idea how to debug a suspend issue?
<zakame> evening all
<Mithrandir> sladen: *shrug*, it'll simplify casper a fair bit.
<Mithrandir> sladen: it's not a dapper thing anyway
<hunger> I got a log of pmi action suspend... which claims that "device or resource busy" when doing echo -n mem > /sys/power/state.
<sladen> Mithrandir: what isn't, deprecating cloop?
<Mithrandir> sladen: yes
<jdub> ogra: you can't see the splash at all, and icons float in the air?
<dholbach> jdub: any idea on malone bug 32168 and gnome bug 328475 ?
<ogra> yup
<Ubugtu> malone bug 32168 in ekiga "ekiga: Image icontray, not is transparent" [Normal,Confirmed]  http://launchpad.net/bugs/32168
<Ubugtu> gnome bug 328475 in general "System tray icon doesn't have a transparent background" [Enhancement,Resolved: notabug]  http://bugs.gnome.org/show_bug.cgi?id=328475
<jdub> dholbach: ask damien on #gnome-hackers
<dholbach> jdub: according to upstream it's a theme bug, not an app bug
<jdub> dholbach: possibly
<ogra> dholbach, are you sure the icon tray isnt at fault ? there is the same bug for g-p-m
<dholbach> ogra: and for xchat-gnome and ....
<ogra> yup
<dholbach> ogra: I dont' know what you mean by "icon tray at fault"
<jdub> well, it's a systemic problem really
<ogra> if the notification area is buggy with displaying transparency you wont fix it in the icon ...
<jdub> the app draws that little square
<seb128> that's a gnome-panel bug
<HiddenWolf> yeah, all apps have it.
<seb128> hey vuntz :)
<ogra> hehe
<jdub> so it isn't really anyone's bug, it's just a problem with the standard, how themes are implemented, etc.
<dholbach> seb128: cool, I'll DUP the bugs we have then and assign them to vuntz! woohoo! :)
<seb128> GNOME bug #100600
<Ubugtu> gnome bug 100600 in Notification Area Applet "Notification area doesn't support all the panel background types" [Minor,New]  http://bugs.gnome.org/show_bug.cgi?id=100600
<tepsipakki> lamont: you dropped NFSv4-support that was in util-linux_2.12r-4.1?
<dholbach> seb128: thanks, I'll take care of those, then.
<jdub> norm walsh is using dapper ;)
<jdub> http://norman.walsh.name/2006/02/19/bleedingEdge
<Kamion> https://launchpad.net/distros/ubuntu/+source/gfxboot-theme-ubuntu/+bug/32183 is weird - it affects precisely one language
<Ubugtu> malone bug 32183 in gfxboot-theme-ubuntu "Graphical bug with Zhngwn language" [Normal,Confirmed]  
* Kamion just went through selecting all the others to see
<Mithrandir> what language is Zhngwn?
<Kamion> zh_CN
<Mithrandir> oh, unshiny.
<Kamion> I'll just have to read and understand all the menu drawing code, I guess :(
<infinity> Riddell: Done.
<Riddell> infinity: thanks, could you do the same for kdesdk
<xerox_> seb128: hi.
<seb128> Hi xerox_
<infinity> Riddell: And done.
<xerox_> seb128: may I ask you some advice wrt libsvg and libsvg-cairo packaging?  I got some undecipherable issues on revu.
<seb128> libsvg? what is that?
<seb128> but sure
<xerox_> seb128: <http://revu.tauware.de/revu1-incoming/libsvg-0602200825/REVU_report> is the problematic one.
<xerox_> seb128: <http://revu.tauware.de/revu1-incoming/libsvg-cairo-0602200825/REVU_report> is quite good.
<slomo_> Kamion: hi... can you remove banshee from NEW for x86? it's currently there because i splitted off a plugin to a separate package...
<xerox_> seb128: libsvg is a dependency for libsvg-cairo.  It is written my cworth, based on librsvg by someone other.
<seb128> slomo_: and you changed your mind? :)
<Kamion> slomo_: please don't confuse me by saying "remove"
<Kamion> do you mean "accept" or "reject"?
<seb128> xerox_: why having librsvg and libsvg?
<slomo_> Kamion: i mean accept... sorry for the confusion...
<Kamion> slomo_: I'll do it after this publisher run finishes
<xerox_> seb128: there isn't either of them in ubuntu nor in debian.
<slomo_> Kamion: thanks :)
<seb128> xerox_: what do you mean?
<Kamion> I thought I'd processed banshee the other day, actually, but evidently not
<seb128> xerox_: I mean what is the advantage of that new one over librsvg?
<xerox_> seb128: I don't know the reason behind the rewrite.
<Kamion> I think I looked at it, was about to accept it, and then the publisher kicked in
<infinity> Kamion: linux-source-2.6.15 has been rescued on powerpc, and it's now in NEW.  I think that's my cue to go to bed.  Enjoy.
<Kamion> infinity: thanks
<xerox_> seb128: I'm investigating
<seb128> k
<ogra> Mithrandir, do you have a bug for the liveCD i can duplicate bug 32305 and bug 32306 to ?
<Ubugtu> malone bug 32305 in edubuntu-meta edubuntu-live "Edubuntu dapper flight4 live: Ejects wrong cd upon shutdown" [Normal,Unconfirmed]  http://launchpad.net/bugs/32305
<Ubugtu> malone bug 32306 in edubuntu-meta edubuntu-live "Suspend quits unexpectantly" [Normal,Unconfirmed]  http://launchpad.net/bugs/32306
<infinity> Kamion: After you NEW those kernels, can you poke Kinnison with a stick to reset the build for LRM on PPC, so I can go to bed and not worry about it? :)
<Kamion> slomo_: done
<slomo_> Kamion: thanks :)
<xerox_> seb128: that was the right question.  cworth advices using librsvg.
<seb128> :)
<janimo> Kamion, do you know if the mirroring script of the xubuntu seeds stopped for some reason?
<janimo> I made the branch anew a couple of days ago, but keeping the ubuntu ancestor
<xerox_> seb128: do you think it's doable to package librsvg and get it into dapper if I start looking into it now?
<seb128> xerox_: librsvg is packaging for years now, that's what GNOME uses for svg for ages in fact ...
<Mithrandir> ogra: no.  The latter isn't a bug in casper anyway, it's probably a bug in the suspend tool.
<Kamion> janimo: it got stuck on a lock; I've kicked it
<janimo> thanks
<Kamion> janimo: but if you did that I'll probably have to re-pull from scratch
<seb128> xerox_: ii  librsvg2-2               2.13.93-0ubuntu1         SAX-based renderer library for SVG files. (for GNOME2)
<Kamion> please try not to do that in future
<ogra> Mithrandir, ok
<janimo> but it should be ok with bzr no?
<janimo> pulling from a related branch
<xerox_> seb128: thank you very much.  I probably should ask some motu to nuke my libsvg and libsvg-cairo attempts.
<seb128> xerox_: you're welcome
<janimo> I had to do it because bzr 0.8pre corrupted the repo
<Kamion> janimo: as long as it's a descendant of whatever I had before, that's fine
<Kamion> I thought you meant that you re-branched from the Ubuntu seeds
<Kamion> anyway, updated now
<janimo> yes I rebranched, is that not ok?
<janimo> the
<janimo> maybe that caused the lock, then but I thought bzr should handle this
<Kamion> the last commit I have was:
<Kamion> revno: 512
<Kamion> committer: jani <jani@ds9.narancs.net>
<Kamion> timestamp: Tue 2006-02-21 16:16:32 +0200
<Kamion> message:
<Kamion>   add xfce4-mixer-alsa
<janimo> yes, good
<Kamion> does that match your branch?
<Kamion> and I don't see in that that you re-branched from the Ubuntu seeds
<Kamion> there are lots of old merges in there
<xerox_> seb128: where could I read librsvg documentation?
<Kamion> (good)
<janimo> oh, I actually rebranched from the xubuntu seeds on your page. I forgot.so it's all fine now, thanks
<seb128> xerox_: http://librsvg.sourceforge.net/ maybe
<Kamion> janimo: ok, *that's* fine
<Kamion> janimo: re-branching from the Ubuntu seeds would mean that when I run 'bzr pull' it would refuse to pull your seeds and demand that I merge instead, because the branches would have diverged
<Kamion> (obviously I'd just throw away the branch and re-pull instead if that happened, but it would be an inconvenience)
<janimo> Kamion, ok I tought you bzr merge in the script
<Kamion> hell no
<Kamion> why would I want to do that? :)
<janimo> to prevent such accidents :)
<Kamion> it's a mirror, not an auto-merged thing
<Kamion> such accidents Never Happen (tm)
<Kamion> if they do, I want to know about them!
<Kamion> also, merging all the time would make the log look very strange
<janimo> fair enough
<JaneW> who knows about SCIM and who the upstream author is?
<Yagisan> JaneW: minghua is the scim guy IIRC
<JaneW> Yagisan: cool thanks
<JaneW> Yagisan: I found this "JamesSu: Core developer, project maintainer"
<Yagisan> JaneW: your welcome. I need to get around to downloading flight 4 and testing scim, so I don't have any surprises on upgrade.
* pvanhoof looks angry at the ubuntu dapper packagers that messed up the evolution support for beagle
<slomo_> pvanhoof: "messed up" in what way? evolution-sharp simply doesn't work with e-d-s 1.5/1.6... but mail searching should still work, this only affects searching the address book
<pvanhoof> there's no .dll in the package
<pvanhoof> it only contains the doc/ files
<pvanhoof> how can it support anything that way? :-)
<Kamion> beagle-backend-evolution is obsolete ...
<pvanhoof> so which one do I need for the evolution support?
<slomo_> pvanhoof: that dll would only be for searching the address book... when searching mails doesn't work it is a bug and should be filed ;)
<Kamion> well, not currently built, I mean
<pvanhoof> pvanhoof@lort:~/.beagle$  beagled --list-backends | grep Evo
<pvanhoof> pvanhoof@lort:~/.beagle$
<pvanhoof> slomo_, okay but the current beagle package in dapper doesn't have support for evolution at all
<pvanhoof> so the bug is .. that the support-plugin isn't available? 
<Kamion> ogra: do xscreensaver-data-extra and xscreensaver-gl-extra need to be seeded somewhere?
<slomo_> pvanhoof: let me check... well, the problem is that the evolution backend needs evolution-sharp which produces crashes with e-d-s 1.5/1.6... but it would be only used for searching in the address book afaik... searching mails works by looking in the directory in your home and needs nothing...
<ogra> nope, they are for universe
<ogra> Kamion, ^^^
<pvanhoof> ok
<ogra> Kamion, you can keep them in supported if you think that makes sense ... i have to care for the whole package anyway
<Kamion> ogra: it's up to you
<Keybuk> pitti: you know that hal spits evil error on stop/shutdown, yes?
<ogra> heh, i dont really care ... 
<pitti> Keybuk: no, details?
<ogra> lets put themm into supported for now ...
<slomo_> pvanhoof: but next time better file a bug instead of saying something here... it was pure luck that i noticed it
<JaneW> Yagisan: him? -> https://launchpad.net/people/minghua
<pvanhoof> slomo_, okay :)
<Keybuk> pitti: kill needs arguments, or something
<pvanhoof> Kamion, if that package is obsolute .. shouldn't it be removed from the distro? atm it only contains the copyright files
<pitti> Keybuk: /etc/dbus-1/event.d/20hal start/stop/restart works well for me
<slomo_> pvanhoof: it's remaining from an older version currently... and will come back later when it works again
<Kagou> hi
<Yagisan> JaneW: yes
<pvanhoof> ok
<Keybuk> pitti: it does for me here too, will see if the message is still there
<JaneW> Yagisan: ok ta. are you sure? He is not mentioned on http://www.freedesktop.org/wiki/Software_2fscim
<Keybuk> have only seen it on shutdown so far
<janimo> ogra, xss stays in main right?
<pitti> Keybuk: I'm currently hacking on hal anyway, so it would be a good time to fix stuff :)
<Keybuk> pitti: I need to reboot in a bit, so will look for it then
<Yagisan> JaneW: upstream == debian or debian upstream ?
<Kamion> pvanhoof: after the change of the archive infrastructure a while back, I only just worked out how to get an automatic list of such packages ("not built from source") about ten minutes ago
<pitti> Keybuk: I see what *could* go wrong
<pitti> Keybuk: that could happen if the pid file still exists, but is empty
<pitti> Keybuk: I will refine the check to avoid this message
<ogra> janimo, not sure ... but if you need it, we can keep it :)
<pvanhoof> ok
<janimo> ogra, well yes for xubuntu
<Kagou> am I alone having the problem when i select language on the boot of flight4 (install or live), that's make the boot menu inaccessible, so i must reboot? is this reported ?
<ogra> ok
<janimo> thanks
<Yagisan> JaneW: he is the debian maintainer. Did I misunderstand you ?
<Kamion> Kagou: are you selecting French?
<Kagou> yes Kamion 
<Kamion> Kagou: your keymap has driven me almost entirely insane. It's a known bug.
<janimo> the fancy gl bits or whatever else can go to universe, just the basic screensavers are ok
<Kamion> and it only affects French
<pitti> Keybuk: oh, do you use dash? $(< $PIDFILE) could be a bashism
<Kagou> ok Kamion. if i can help you ... thanls
<ogra> janimo, thats why i split the package into multiple pieces ...
<ogra> janimo, xscreensaver-data and xscreensaver-gl contain only a small subset of selected hacks
<janimo> right, the only patch which is dropped for dapper but in breezy we may need is the circles in password field
<Kamion> Kagou: I'll probably just override it to death - I think it's just bizarre arrow key handling
<Keybuk> pitti: nope, no dash
<JaneW> Yagisan: no, I think I didn't specify well... I need the upstream author
<ogra> janimo, i wont do work on more than one screensaver app ..
<janimo> ogra, I know I'll pick the patch if necessary
<ogra> janimo, feel free to patch it yourself :)
<Kagou> Kamion, is there a bug in malone ? i can't find it
<ogra> janimo, the breezy patch s a dpatch that should mainly apply without issues even in dapper
<ogra> just grab the source from breezy and try to add the patch to dapper
<pitti> Keybuk: ok, should be fixed
<Keybuk> pitti: :)
<Keybuk> thanks
<Kamion> Kagou: https://launchpad.net/distros/ubuntu/+source/gfxboot-theme-ubuntu/+bug/31767
<Ubugtu> malone bug 31767 in gfxboot-theme-ubuntu "Keyboard stop responding in installer splash screen" [Major,Confirmed]  
<slomo_> pvanhoof: ok, you're right... it really doesn't work *sigh*
<Kagou> thnx Kamion
<pvanhoof> :)
<pvanhoof> slomo_, np. Just fix it :)
<janimo> ogra, yes I looked at that patch a while ago. that circle stuff seemed to be a large xpm inside C source IIRC
<janimo> big patch
<ogra> nope, its separate xpms in a patch... not in the source ...
<Yagisan> JaneW: sorry then. I don't know who the authors are
<JaneW> Yagisan: thanks for trying. I'll possibly ask Minghua anyway...
<janimo> ogra, I must misremember then
<janimo> I know there was a large diff to a C file containing something that looked like a xpm struct
<ogra> note that if it doesnt apply it will be a lot of work to integrate it right ...
<mjg59> Argh, lists.ubuntu has just dumped a huge pile of stuff on me
<Kamion> mjg59: I think jdub did a big moderation pass
<jdub> 8)
<jdub> didn't approve of much though
<Keybuk> heh
<Kinnison> jdub: you're in the UK now aren't you?
<Treenaks> jdub: btw, I'll be at FOSDEM on Saturday
<mjg59> Is Mark back in the country, or still in Asia?
<pitti> Kinnison: ok, I'm going to write a proper probe for your PMI thingy
<Keybuk> mjg59: dunno, but he's certainly active on e-mail today
<mjg59> Cool
<Kinnison> pitti: cool
<jsgotangco> it's supposed to be his last day in thailand today
<Kinnison> pitti: I was gonna do a patch for lcds today
<Kinnison> pitti: to get the levels right for sony laptops
<pitti> Kinnison: oh, you are working on the hal package ATM?
<Kinnison> pitti: I was about to start
<pitti> Kinnison: I do, so we shouldn't stomp on each other's feet
<Kinnison> pitti: I can punt you the patch file when I'm done
* Kinnison would really like you to do the pmi stuff properly :-)
<pitti> Kinnison: ok, that should be fine
<pitti> I cleaned up the privilege dropping stuff
<jdub> Kinnison: i am in the office
<jdub> Treenaks: rad!
<jdub> mjg59: thailand
<pitti> Kinnison: so, hal by default assumes that you can suspend and hibernate without checking? that's weird
<Kinnison> pitti: well it checks /sys/power/state
<Kinnison> pitti: osspec.c
<pitti> ah, I see
<mjg59> I don't see why we'd want hal to claim otherwise
<pitti> mjg59: Kinnison's patch asks pmi, which respects /etc/default/acpi settings
<mjg59> No!
<mjg59> We shouldn't do that
<mjg59> The point of having this is that people can enable sleep without having to hack files as root
<mjg59> We should just have g-p-m provide a warning dialogue when somebody enables sleep
<pitti> but it's for disabling, not enabling
<pitti> i. e. I know that STD is broken for me, so I could disable it in acpi-support to not see it in the GUI
<pitti> mjg59: ah, I see, STR is disabled by default
<mjg59> pitti: Correct
<pitti> hmm, well, Kinnison?
<mjg59> Why is STD broken for you?
<Kinnison> I was making hal display what pmi would be prepared to do
<mjg59> Kinnison: Right, that's not the best plan
<pitti> mjg59: on the laptop it has always been (STR works fine, after STD the graphics card is not reinit'ed properly, so I get a black screen)
<pitti> mjg59: on the desktop, STD + nvidia doesn't work (nv does, though)
<mjg59> pitti: Apple?
<Kinnison> mjg59: but hal uses pmi to do the suspend, so surely hal shouldn't claim something pmi will refuse to do?
<mjg59> Kinnison: No, because hal forces pmi
<pitti> mjg59: yes, the laptop (where acpi isn't relevant anyway)
<mjg59> pmi will do it quite happily
<jdub> o/~ push the bzr o/~
<mjg59> pitti: We should try to fix that. I believe it's supposed to work.
<mjg59> pitti: Have you spoken to benh?
<pitti> mjg59: I'd be happy to :)
<pitti> mjg59: yes, this bug is ages old, it sits somewhere in bugzilla, even fd.o's AFAIK
<Keybuk> jdub: I want an ogg of that
<pitti> but I didn't follow it closely, STR works just fine
<mjg59> pitti: The console ought to be restored if you suspend from there
<jdub> Keybuk: i want an ogg THEORA of that
<pitti> mjg59: I'll do some experiments then (from minimal boot, console, X, etc.)
<mjg59> pitti: Ta
<pitti> ok, so we drop that 'hal queries pmi capabilities' thing altogether?
<Keybuk> jdub: do it then
<pitti> Kinnison, mjg59 ^
<mjg59> pitti: I think so
<Kinnison> If you say so. I'll have to see if I can add UI to g-p-m then
<pitti> Kinnison: what was the original problem?
<mjg59> Kinnison: Why?
<Mez> is the NEW queue actually being processed?
<pitti> Mez: yes, it is
<mjg59> Kinnison: Oh, just the dialogue box? Yeah.
<mjg59> Hibernate doesn't need it, STR does
<Mez> pitti: weird... I uploaded something to ubuntu unstead of REVU - didnt realise till I got the NEW reply ..
<Mez> lol
<Mez> but I still havent had an ACCEPT/REJECt
<pitti> Kinnison: ok, so please tell me whatever you two end up discussing :)
<jpatrick> Mez: NEW queue has been slow recently
<Mez> a week slow ?
<jpatrick> yep
<jpatrick> nothing mine has turned up
<jpatrick> and it took kblogger two weeks to appear
<Kinnison> mjg59: bug 2764 I think
<Ubugtu> malone bug 2764 in hal "Gnome-power-manager ignores /etc/default/acpi-support" [Normal,Fix released]  http://launchpad.net/bugs/2764
<mjg59> Kinnison: Right. I think it ought to ignore acpi-support.
<mjg59> That only existed because we had no sane user-level mechanism for doing this
<Kinnison> mjg59: right, so the policy belongs in g-p-p
<Kinnison> pitti: drop the patch
<Kinnison> pitti: In fact, I can drop the patch when I do the lcd change
<pitti> Kinnison: alright, I'll drop it
<mjg59> Kinnison: Sorry, we should possibly meet up some time to discuss this stuff...
<Amaranth> can we ban john moser from the lists? he is getting annoying
<Kinnison> pitti: are you doing other stuff on hal right now?
<pitti> Kinnison: otherwise I'm done with my changes, so I can either upload and you work from that, or send you the source pacakge
<Kinnison> pitti: You upload, I'll work from your stuff in a while
<pitti> alright
<pitti> Kinnison: uploaded; FYI, I also fixed debian/run-hald.sh to actually work; this makes change/compile/try turnarounds much faster
<Kinnison> hehe
* pitti usually does make -C build-tree/hal-* && sudo sh debian/run-hald.sh
<pitti> mjg59: hm, is /sys/power/state expected to work for STD on ppc? (since it's broken for STR)
<pitti> mjg59: pbbcmd hibernate doesn't work, and I don't know another way to trigger STD
<pitti> well, at least suspend works fine
<pitti> mjg59: heh, interesting; the screen comes back (suspended without X), now it hangs after a kernel oops in usdev?ioctl()
<pitti> s/?/_/
<Kamion> Mez: yes, I haven't been doing it terribly quickly, sorry
<Kamion> the fact that the archive is apparently Hotel California isn't helping either
<Mez> Hotel Califoria?
<Kamion> can't remove packages
<Kamion> it pretends to but never does
<Keybuk> hmm, why doesn't the bash manpage seem complete?
<Kinnison> Kamion: just out of interest, what's your LPCONFIG?
<Kamion> Kinnison: ftpmaster
<Seveas> Kamion, I guess you might know this: who's "in charge" of the winfoss packages on the live cd? (aka: who to pester with bug reports)
<Kamion> Seveas: Henrik (heno)
<Kinnison> Kamion: right, that's okay (I have more than once almost done something to staging y'see :-)
<Kamion> mdke_: fancy eyeballing my rewritten WikiLicensing/Email?
<jsgotangco> ohh wiki licensing
<Seveas> Kamion, gracias
<pitti> mjg59: ok, summary: STD@powerpc works in text mode with almost all modules removed; oopses on resume with normal modules present; garbles screen when suspending under X or switching back to X after resuming
<mjg59> pitti: Ok, that's a good start
<pitti> yes, last time I tried it didn't even work in minimal boot
<mjg59> pitti: Can you figure out which module breaks it?
<Kinnison> mjg59: When would be good for you and I to discuss all this PM crud?
<mjg59> Kinnison: Pretty much any time
<pitti> mjg59: I think so, yes; after removing USB modules, I got a different oops, but I can bisect them until I hit the right one
<mjg59> Thanks!
<pitti> mjg59: I could also try to disable DRI in X; that helped back in hoary with STR
<mjg59> pitti: Sure
<Kinnison> mjg59: are you busy tonight?
<mjg59> Kinnison: Might be post 10, but probably not before then
<Kinnison> mjg59: I think face-2-face with a laptop to play with is a good way to get all this decided upon
<Kinnison> mjg59: Would it be okay if I popped over this evening?
<mjg59> Kinnison: Sure
<Kinnison> cool. What sort of time would be good for you?
<mjg59> 7ish?
<Kinnison> sure
<Kinnison> See you then
<sladen> mjg59: what happened to "# Disable keys that may generate a hibernate event", and e02a (which is PrintScreen)
<Keybuk> PrintScreen is hiding on my Pause key this week
<mjg59> sladen: Should be fixed
<mdke_> Kamion, looks fine to me: i'm happy to remove it from the CC agenda, if you are
<Kamion> mdke_: the only remaining thing is that mako said he was going to talk to a lawyer about whether PD-self was ok
<mdz> mvo: ping?
<mvo> mdz: hello
<pitti> moin mdz
<mdz> mvo: I'm curious about getting the upgrade tool into breezy-updates
<mvo> mdz: do you mean, getting it in now?
<mdz> mvo: I mean, when?
<mdz> mvo: is it at a point where you would be comfortable backporting it?
<mvo> mdz: I think at prerelease time probably
<Kamion> pitti: did you approve skim's main inclusion? it's in the approved bit of the queue, but you've never edited the page
<mdke_> Kamion, ok
<mvo> mdz: it's not that usefull before people can use it to upgrade to dapper. so maybe even closer to release time is enough
<mdz> mvo: I think we should do it much earlier than that, and use it as the basis for testing the tool
<mdz> it should work for upgrades to dapper even before dapper is released
<pitti> Kamion: oops, I must have forgotten to save the page
<mdz> mvo: if the tool is there and readily accessible in breezy-updates, we'll get more testing for it
<mvo> mdz: right. we need to warn the users that it's not the final dapper yet
<Kamion> dholbach: so is icon-naming-utils going back to universe?
<mvo> mdz: but that isn't a problem :)
<mdz> mvo: it shouldn't display the notification of a new release, but the user should be able to explicitly ask for an upgrade to the development release
<mvo> mdz: we need to integrate it into the existing lp infrastructure I think
<mdz> mvo: which lp infrastructure?
<mvo> mdz: currently update-manager downloads the dist-upgrade tool from my people.ubuntu.com account
<mdz> yes, that should move into the archive and onto the mirrors
<mvo> mdz: we agreed at ubz that for the final version we want to use a archive.u.c dir
<mdz> mvo: please write up a description of how it should work and send it to me & kiko
<mvo> mdz: ok
<mvo> mdz: a quick question about the i18n sprint, will it be a whole week?
<mdz> mvo: that is an ongoing discussion, nothing is final
<mvo> mdz: so it's too early to book a flight yet :) ?
<mdz> yes
<mvo> ok
<Kamion> mdz: FYI I've added xubuntu and ubuntu-server to http://people.ubuntu.com/~cjwatson/anastacia.txt
<Kamion> mdz: if you object to either, please let me know now before it all gets too confusing
<Kamion> I'm using a separate cron.sync though, so xubuntu doesn't have Task headers in the archive yet (and thus no working netboot)
<mdz> Kamion: I appreciate having them included, but I think it needs to say "xubuntu Desktop seed" rather than "Desktop seed' e.g. for sanity
<Kamion> ug
* Kamion attempts to work out which layer of the teetering software stack is responsible for that
<Kamion> probably germinate
<Kamion> will "xubuntu-dapper Desktop seed" be OK? easier to produce
<mdz> Kamion: yes
<janimo> Kamion, thanks I was just about to ask about promotions and CD builds
<janimo> will the latter happend automatically?
<janimo> s/d//
<setuid> infinity: Do I want prefork or perchild? 
<dholbach> Kamion: for this release, yes - sorry for not yelling earlier.
<ogra> Keybuk, ping
<dholbach> Kamion: thanks for the NEW love (supposing you looked at them.
<Kamion> dholbach: no problem - back to universe it goes
<Kamion> dholbach: yeah
<Kamion> been working my way through it in spare moments
* dholbach high-fives Kamion
<lamont> tepsipakki: the nfsv4 support was only ever uploaded to debian/experimental
<ogra> mdz, i think i have the nbd swap solution, if you have time for a chat about my implementation idea i'd appreciate that 
<setuid> infinity: Looks like apache2 has a dep for apache-ssl
<setuid> Suggested packages:
<setuid>   apache apache-ssl apache-perl apache2-doc php-pear modxslt-tools modxslt-doc db4.3-util libio-socket-ssl-perl
<mdz> ogra: email would be best, but I have a few minutes now
<pvanhoof> latest fglrx updates mismatch between the kernel fglrx module https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.15/+bug/32332
<Ubugtu> malone bug 32332 in linux-restricted-modules-2.6.15 xorg-driver-fglrx "On the current 686 kernel, the fglrx-xserver driver does not match the kernel one" [Normal,Unconfirmed]  
<elmo> right, quick, someone give me a single important sync  that hasn't been done yet
<Keybuk> ogra: 'sup?
<siretart> elmo: aspectc++_0.99+1.0pre2-4
<fabbione> elmo: apr and apr-utils from debian
<LaserJock> that was a pretty loaded questions, can we do "rock-paper-scissors" over who gets the "important sync" ;-)
<pitti> elmo: libpng sync and libpng3 removal (transition)
<fabbione> elmo: they replace apr1.0 and apr-utils1.0 (all in universe
<Kamion> pitti: removals don't seem to be working for me at the moment
<elmo> Kamion: oh?
<pitti> ouch, ok
* fabbione heads offline for the evening
<fabbione> night everybody
<siretart> elmo: this list: http://thread.gmane.org/gmane.linux.ubuntu.motu/457
<pitti> well, syncing libpng should work anyway since it at least has a newer version then
<siretart> sleep well fabbione 
<pitti> bye fabbione 
<Kamion> elmo: https://launchpad.net/products/soyuz/+bug/32314
<Ubugtu> malone bug 32314 in soyuz "remove-package.py pretends to work and then does nothing" [Normal,Unconfirmed]  
<dholbach> hahahaha: "Hotel California mode"
<LaserJock> Kamion: did you have a chance to talk to elmo about moving ggobi from multiverse to universe?
<Kamion> LaserJock: no
<Kamion> LaserJock: I wanted you to do it rather than directing it through me
<Kamion> sorry if that wasn't clear
<LaserJock> Kamion: ohh, I see. I misunderstood.
<LaserJock> Kamion: sorry.
<Kamion> elmo: (context re ggobi was that I didn't know how we felt about licence clauses requiring commercial contributors to indemnify other contributors against lawsuits)
<elmo> Kamion: you should use the rene port for what you were doing there anyways
<Kamion> elmo: archive-cruft-check.py?
<elmo> yah
<Kamion> I was
<elmo> ah, ok
<Kamion> (once I figured out how to run it)
<elmo> the bug title is confusing then
<Kamion> only way I could get it to work was 'PYTHONPATH=/home/james/launchpad/scripts /srv/launchpad.net/codelines/current/scripts/ftpmaster-tools/archive-cruft-check.py'
<Kamion> elmo: er, oh, archive-cruft-check can remove packages itself?
<elmo> it does by default
<Kamion> oh, I used -n because I was paranoid and wanted to check
<Kamion> then cut-and-pasted to remove-package.py to see what happened
<Kamion> (the answer being nothing, as you can see)
<Kamion> elmo: archive-cruft-check.py doesn't seem to log to removals.txt?
<Kamion> does it log anywhere else?
<elmo> no, that'd be useful
<Kamion> uh-huh
<elmo> well
<elmo> in theory you can see the publishing history of indivudal binary packages
<Kamion> at least it prints output unlike change-override.py ;)
<elmo> through the web ui
<elmo> but yeah
<elmo> the tools ports were done in a fairly busy two week period :P
<Kamion> yeah, I know
<mjg59> mdz: Around?
<Kamion> elmo: do you want cced on bugs I file about them?
<elmo> wtf
<elmo> Kamion: they should probably be assigned to me
<Kamion> ok
<elmo> this is quite special, espresso-frontend-cloner has no datesuperseded entries
<Kamion> did it manage to get half-removed or something?
<mdz> mjg59: yes
<j^> will AiGLX also make it into dapper?
<elmo> kamion: https://launchpad.net/distros/ubuntu/dapper/amd64/espresso-frontend-cloner/0.99.10
<elmo> it's in "PendingRemoval" ?
<elmo> tho, I wish they hadn't removed the history stuff
<Kamion> I utterly don't understand Soyuz's binary statuses
<Kamion> they seem to be randomly "Removed" or "Superseded"
<elmo> and it's not in the Packages files?
<Kamion> though maybe that's source statuses, don't remember and basically don't understand :)
<elmo> so I'm slightly confused
<Kamion> it's in universe
<elmo> oh, so I'm just stupid
<Kamion> and madison-lite says it's there, so it must be in Packages
<elmo> so it is
<Kinnison>  dapper amd64 Release: Published 0.99.10 in component universe and section admin on 2006-02-15 00:02:21 GMT
<Kinnison> the issue is there's some NULLs in the table
<Kinnison> and they sort first
<Kinnison> always
<Kinnison> go SQL
<elmo> NULLs in which column?
<Kinnison> not sure
<Kinnison> whatever the history is sorting by on the page
<elmo> there's a history?
<Kinnison> knock the version off the end of the url
<elmo> rocking UI ;-)
<Kamion> "Removed" then "PendingRemoval"
<Kamion> cool
<Kamion> "it's gone" / "oh shit, no it's not, er, maybe, I'm so confused"
<Kinnison> we ought to sort that table by the datecreated always
<Kinnison> but we try to do some magic
<Kinnison> possibly we ought to s
<Kinnison> ort by status and then datecreated
<Kinnison> rather than any oh
<Kinnison> other column
* Kinnison needs a keyboard which isn't hidden behind his laptop to IRC from
<elmo> Nominated Independent Architecture:
<elmo> i386
<elmo> that info so doesn't need to be displayed
<robertj> Kennison: is this Postgres?
<robertj> MySQL has ORDER BY FIELD(COLUMN, Z, B, C)
<Kamion> mm, let's switch all of Launchpad to MySQL, that's a good idea
<robertj> Kamion: i'm not saying that, I'm just saying maybe Postgres does as well
<robertj> but I've never used it
<Kamion> heh
<elmo> /usr/sbin/laptop-detect: line 6: test: : integer expression expected
* elmo gets deja vu
<pitti> mjg59: bah, this is annoying; as soon as I start X, resuming kills my keyboard, and it's impossible to pinpoint the faulty module since the behavior isn't deterministic
<mjg59> pitti: Haha.
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/anastacia.txt has flavour names alongside the seeds now
<mdz> Kamion: beautiful
<Kinnison> mjg59: huzzah, I have one possible solution to the suspend/hibernate policy thing ready for our meeting
<Kinnison> mjg59: I shall bring the laptop with
<janimo> Kamion, I notice the old binary names for the xfce libs are there too. (libxfce4mcs-client-2, libxfce4mcs-manager-2, libxfce4util-1)
<janimo> when removals are possible maybe they should go from the archive
<mjg59> Kinnison: Cool
<janimo> libxfcegui4-3 too
<Kamion> janimo: yes, they appear in the archive cruft checker's output so no need to mention them individually, thanks
<ogra> hmm, i wonder why our ubuntu server depends on gnome1 :)
<Kamion> janimo: however they're listed for promotion to main because you've forgotten to rebuild something against the new libraries
<janimo> Kamion, hmm I wonder what
<janimo> I'll try to find out
<Kamion> janimo: http://people.ubuntu.com/~cjwatson/germinate-output/xubuntu-dapper/ should help
<janimo> thanks
<Kamion> hmm, or not
* Kamion pokes at update-germinate
<Kinnison> mjg59: heading out
<janimo> hmm, is that based an older version of the xubuntu seeds? xfce4-battery-plugin and xfce4-goodies have been taken out for a while
<janimo> same for systray, iconbox
<janimo> and I have deleted them from the maininclusion wiki page last week
<Kamion> seems very unlikely that it would have been based on an older version - but I think something else might have been confused, and I'm rerunning update-germinate at the moment to see
<Kamion> the cron job runs every hour on the same machine as I mirror your seeds to
<ogra> jinty, what about schooltool .... feature freeze is in two days ...
<jinty> ogra: I have the release tarballs, but have to fix a bug in zope before I can build those with confidence
<ogra> phew ...
<mdz> Kamion,JaneW,jdub,mjg59,Keybuk: if any of you actually have the admin password for ubuntu-devel-announce, please send to me
<dholbach> does anybody have an opinion on  bug 32341 ?
<Ubugtu> malone bug 32341 in gaim "Gaim legal issues" [Normal,Unconfirmed]  http://launchpad.net/bugs/32341
<mjg59> mdz: Afraid not
<mjg59> Oh, hang on
<KurtKraut> I need to report an error in Flight4. When I ask to the LIVECD to check its integrity, there is a error when it prompts the word 'mismatch'. It is scrambled with other words. Please check these pictures: www.kurtkraut.net/ubuntu/flight4/
<KurtKraut> Anyone could give me the name of that package so I can report this problem ?
<Pygi> wb seb and Jane
<giftnudel> dholbach, creating a jabber.ubuntu.com server and promoting jabber is the best option, then the issue will solve itself in time ...
<dholbach> giftnudel: I personally have no problem with that, but a lot of other people will, so I'd love to know if it's really the way the bug report says
<dholbach> MS/Yahoo/AOL didn't decide that yesterday, did they? :)
<giftnudel> dholbach, oh well, it really is this way
<giftnudel> dholbach, a couple of jabber servers shut down there msn transports because of this
<dholbach> yeah read it already
<giftnudel> i don't know, something must have happened
<Burgwork> giftnudel, why is this a big issue right now? those TOSes have been in place for a long time
<mdz> mjg59: Keybuk had it
<LaserJock> gaim does IRC as well doesn't it. So we would be left with jabber and IRC?
<Burgwork> IMO, there is no reason to move gaim to multiverse
<Burgwork> we are not actually breaking any TOS by actually having it installed
<Pygi> what happened to gaim if I am ask?
<Burgwork> Pygi, nothing yet
<Pygi> and what is about to happen?
<Burgwork> Pygi, there is some concern about hte legality of gaim connecting to yahoo/aim/msn
<LaserJock> malone bug 32341
<Ubugtu> malone bug 32341 in gaim "Gaim legal issues" [Normal,Unconfirmed]  http://launchpad.net/bugs/32341
<Burgwork> plus loosing the ability to connect to those services is a major major regression
<giftnudel> Burgwork, that is a nice point of view: "we are not actually breaking any TOS by actually having it installed"
<LaserJock> Burgwork: but if *nobody* can legally use those protocols in gaim isn't that an issue?
<Burgwork> what users do on their machines cannot be our concern
<Burgwork> if we were responsible for them breakign the law, then the world would be a very different place
<LaserJock> but if there is no possible way for it to be legal then it seems a bit odd to me
<giftnudel> here is a nice blog if you don't know it; http://blogs.openaether.org/?p=146
<Pygi> huh, isn't actually AIM partly interoperable with oscar/libicq?
<Burgwork> can you imagine, suing MS because Windows allows you to install Kazaa on it
<pitti> mdz: I would like to upgrade postgresql-common to the current version (from 39 to 43); it's only bug fixes and some small improvements, and test suite passes; do you consider this as a new upstream version?
<LaserJock> but you can use Kazaa for legal purposes right?
<ptlo> Pygi: *any* client not developed by / explicitly authorized by msn/yahoo/aol is banned by these statements
<LaserJock> so maybe we need to get gaim authorized?
<Burgwork> I would welcome them attempting to shutdown us for using gaim
<Burgwork> antitrust laws are great things
<Pygi> ptlo: well, that was my point...that would mean that we would have to remove part of oscar/libicq which is also part of aim
<Burgwork> I think we should simply ignore the issue until such time as it actually hurts us, because there is no evidence that there is any danger
<Burgwork> and regardless, we are still not legally at fault for anything
<ptlo> well, if nobody mentiones the fact of installing the application on the system, ubuntu can't be to blame if the user actually *uses* these, so i'd say go with the inclusion in main (gajim + gaim/universe is also a nice solution), but IANAL
<giftnudel> Burgwork, I think you are right
<Pygi> ptlo: yes, but we have to understand that ubuntu is taking causious steps in cases like this...
<Burgwork> I am going to reject that bug, due to the fact that it is not an Ubuntu issue
<Pygi> if we would follow your theory, we could install mp3 codecs by default and let the users be responsible for using it?
<ptlo> Pygi: *nod*, well that's why the bug was filed in in the first place. people are cautious, and then other people think about the problem and decide the best course of action
<Burgwork> Pygi, that is different
<ptlo> Pygi: no. the mp3 codecs are illegal for distribution also (in the fluendo mp3 case, patented codec is also illegal to use in a system which uses gpl, also).
<Burgwork> there we are actually breaking US law
<ptlo> Pygi: this is just about the terms of some service 
<ptlo> (and it's what user does, not the distributions)
<Pygi> yes, but in this case we are breaking the TOS
<giftnudel> no, the user is
<giftnudel> and that's the difference
<ptlo> Pygi: no, the user is, by using it.
<Pygi> ah
<LaserJock> I just think it kinda dumb to ship something that *nobody* can use legally. but that's just my $0.02 and IANAL ;-)
<ptlo> and to be frank, the wors possible thing you get for breaking a TOS is ban from the service. it's not strictly *illegal*
<giftnudel> LaserJock, you can use it for jabber and irc
<LaserJock> giftnudel: then we should ship that
<Pygi> if you want to be legal, and still provide something capable of connecting... I say go with jabber client which has interprocess ability
<LaserJock> giftnudel: I have no problem with shipping gaim with only jabber and IRC.
<ptlo> LaserJock: well, we know the users *will* use it no matter what. stripping eg. icq from gaim leaves users with no icq option, so they must install additional client by themselves and after that they'll break the law again
<Pygi> that doesn't use none of the protocols of aol/msn/whateva
<ptlo> s/users/some users/
<giftnudel> LaserJock, yes, but there is no legal point to do so, but users will be annoyed
<LaserJock> but this is similar to the mp3 problem. Are we really solving the problem by just ignoring it?
<LaserJock> I like that Ubuntu doesn't have mp3 support out of the box
<giftnudel> for the mp3 problem, there is a legal point - it's illegal
<giftnudel> in the other one, you can get banned from the service -so what?
<Pygi> laser: yes, you like but Joe Average doesn't
<Burgwork> LaserJock, we can't do anything about it and we (the distro) are not breaking the law
<LaserJock> but we won't change Joe Avereage if we keep ignoring problems
<ptlo> LaserJock: there are ways of dealing with mp3. you could use fluendo's mp3 codec, or just recode your whole damn collection if you wish. for services like icq, you're either in or out. and disabling the way in shuts out a lot of users in places where icq is almost exclusively used (as it is in croatia, for example, which is why i'm arguing)
<LaserJock> I can see if TOS != legality then you have a point
<Burgwork> LaserJock, yes, but neither are we going to make Joe Average happy by not having these things available
<Burgwork> jdub has a great story about demonstrating gaim to a few 13 year old girls
<ptlo> that's the same effect as removing samba or disabling .doc file support for ooffice
<LaserJock> I use .ogg and jabber and IRC because of these issues but I wouldn't have been aware of a problem if at some point I hadn't said "WTF, why can't I play my music?"
<giftnudel> well, I try to convert my friends to jabber, but it doesn't really work
<Pygi> ptlo: well, what's the issue with jabber interprocessing abilites? that way you can talk with icq people, you are not breaking law, using their protocol, etc
<Burgwork> LaserJock, better to offer something like .Ubuntu and get them to sign up to Jabber because it has better service, not because they are forced to
<giftnudel> Pygi, funny enough - the one in charge of the server is responsible
<LaserJock> Burgwork: I agree
<Pygi> gift: well, once using that we don't actually have to login to their network, so...
<ptlo> Pygi: when jabber/gtalk<->icq/aim/msn bridge gets up and officially blessed, i'll be the first one to ditch the proprietary protocol plugins out of my box. they're reverse engineering and incomplete anyways
<giftnudel> yes, of course
<mdz> pitti: whether it's considered upstream or not is irrelevant if you are upstream ;-)
<mdz> pitti: so long as the changes are consistent with the Dapper release cycle, it's OK
<LaserJock> I guess I just find it irritating that I could be breaking a TOS just by using a defualt Ubuntu package. I guess that could be a common problem though.
<Pygi> ptlo: yes, it's kinda partly implemented now
<Pygi> ptlo: but *maybe* we could push it along...
* dholbach takes a break until CC meeting
<ptlo> LaserJock: probably, but at least the user doesn't break it "by default". ie, (s)he has to configure gaim to access these servers in the first place. adding a note "by using these you're breaking your terms of service, beware" might be informative, but i'm not sure how easy it is to hack gaim to do it
<Pygi> ptlo: that shoudl
<giftnudel> ptlo, actually, once you create an account you have agreed to the terms
<giftnudel> so they "should" know what they can and can not do
<ptlo> giftnudel: of course. this would just be a reminder to the gaim users
<giftnudel> and if they deliberately try to violate the tos
<giftnudel> hmm
<Pygi> and let's be honest...most of users will...
<pitti> mdz: yes, I think so; thanks
<ptlo> anyways, i'm off, i trust the wise ubuntu overlords will at least put some icq client in the universe/multiverse so i won't have to compile it for myself ;-) cya
<Pygi> anyone know what's the current status of jabber/gtalk<->icq/aim/msn bridge implementation?
<LaserJock> Pygi: what do you mean by status?
<LaserJock> I think people use it.
<Pygi> well, what's the stability/level of implementation of that bridge?
<Pygi> can it be usable in real time enviroment?
<LaserJock> that I don't know. I've never used icq/aim/msn and don't have an account for any of those. I know somebody that does use jabber for that but I don't know how well it works for them.
<Pygi> because if that's working decently, that would solve the entire *issue*
<Pygi> we are bypassing all of their server, protocols, etc
<LaserJock> Pygi: but are you violating the TOS by using jabber?
<Pygi> and we are not violating TOS if we are talking with people from other protocols
<Pygi> laser: why would I violate TOS by using jabber? 
<giftnudel> LaserJock, no, the server admin is
<LaserJock> giftnudel: that's what I thought.
<slomo_> giftnudel: and what happens when the server admin never agreed to the TOS?
<Pygi> possibly we could hack up on jabber so it uses p2p for intercommunication?
<LaserJock> well, whatever. I try to not violate laws or TOS but I realize that most people probably woudn't care.
<Pygi> slomo: well, he didn't actually agreed...he doesn't have to...
<LaserJock> slomo_: I would imagine that they agree by using it
<giftnudel> slomo_, well then he can not enable the transport?
<slomo_> giftnudel: the server admin can run the transport without ever seeing the TOS... only the user is the one agreeing to the TOS
<Pygi> any way that we could hack up on jabber so we use p2p for transporting purpose?
<giftnudel> slomo_, I can imagine that by using the service (as connecting) you have to agree to the terms
<LaserJock> slomo_: hmm, I would think that use of the protocol would be a part of the TOS but maybe it is just the client.
<Pygi> no, it's the protocol as well, read up
<Pygi> they only do *authorized protocols*
<Kamion> Community Council meeting in #ubuntu-meeting in five minutes
<xxenon> are nvidia drivers currently broken in flight 4 ?
<Kyral> I remember the Bot Attacks (in reference to #ubuntu-meeting). It was quite cool to see lilo kicking ass :D
<dieman> lamont: yay!
<dieman> lamont: you closed 8409, my 'too smart' users will stop saying nfs is broken.
<lamont> dieman: just for you dude.  just for you. 
<lamont> now they'll have to find something else to say is broken
<Kamion> mdz: what's your feeling on moving specs off to a separate wiki again? http://wiki.ubuntu.com/BetterWikiDocs, discussion in #ubuntu-meeting now
<dieman> lamont: im just hoping 2.6.15 is a bit more clean with acting as a nfs client, haven't run it at work yet...
<dieman> lamont: the hoary 2.6.10 kernel pukes into stale handle mode from time to time
<dieman> but not reproducable enough to figure out why
<lamont> dieman: ouch
<dieman> lamont: plus autofs with symlinks pointing into autofs mounts sometimes gets weird.
<dieman> if they are still there with 2.6.15, i'll try and come up with an actual reproducable case for it
<lamont> that'll help
<dieman> sometimes the mount will be there and mounted (nfs) but it can't stat anything
<dieman> but it can list the directory
<lamont> although a patch would be even better. :-)
<dieman> but any attempt at statting gives an i/o error
<dieman> go back to the mount through the actual autofs mount, and sometimes it decides to start working again for both ways, through the symlink and through the autofs mount
<pitti_> re
<lifeless> seb128: where do I get evolution debug symbols ?
<dholbach> seb128: for Dapper?
<seb128> DEB_BUILD_OPTIONS="noopt nostrip"? :)
<dholbach> seb128: oops :)
<lifeless> seb128: aww, baby jesus is crying
<dholbach> lifeless: for Breezy, seb128 put them up on p.u.c
<lifeless> seb128: so I've got a evo hang in dapper
<lifeless> seb128: and I'd like to give you as useful a report as possible.
<seb128> lifeless: put the non-debug backtrace on pastebin.com
<seb128> might be enough to spot a dup
<lifeless> seb128: ok
<seb128> anyway we spoke about debug during distro sprint
<seb128> and we are going to make -dbg packages for stuff like evolution
<lifeless> thank you!
<seb128> that's on my list for that week or next week
<lifeless> I do that for all my packages that can support them, its -so- useful.
<lifeless> http://pastebin.com/565662
<sivang> lifeless: building evo with debug symbols takes _Ages_ 
<sivang> :)
<seb128> it doesn't take longer
<lifeless> sivang: it should not
<seb128> it's faster in fact
<seb128> we always build with debug
<lifeless> sivang: its a 'build and strip to files rather than strip to /dev/null'
<seb128> and we strip usually
<seb128> so it should be a strip faster
<lifeless> seb128: nah, strip to file isn't faster, its ~ the same.
<seb128> right, we do move the debug so might be the same
<lifeless> seb128: anyway, does that look duplike to you ?
<seb128> yep
<seb128> I got that one sometime too
<lifeless> ok.
<seb128> and not when I've a debug package installed grrr
<lifeless> and its reported somewhere already so I should just kick evo in the nuts ?
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=331317 upstream
<Ubugtu> gnome2 bug 331317 in Mailer "Hang when reading a message" [Normal,Unconfirmed]  
<lifeless> thanks
<seb128> hum
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=317790
<Ubugtu> gnome2 bug 317790 in Mailer "Evolution is not responding" [Major,Resolved: fixed]  
<seb128> they closed that one, but they are not quite true, it's not fixed
* seb128 reopens it
<lifeless> heh
<seb128> I'll comment on ross bug saying so rather
<sivang> lifeless: don't think I've understood how you make nostrip faster :) 
<lifeless> sivang: package builds normally build debug symbols and then strip them.
<lifeless> sivang: so nostrip is faster than a normal package build, but building -dbg packages is not slower than a normal package build.
<Kamion> rah, demoting packages to universe due to germinate fixes ++
<Kamion> ogra: xscreensaver-data-extra xscreensaver-gl-extra demoted to universe for now, let me know if you want them back
<ogra> Kamion, as i said before, i dont really care ...
<ogra> might be a question for sabdfl if he wants them in supported or not ... since i care for the source in main, i'll care for the rest anyway 
<sivang> lifeless: ah, so what I was seeing was probably just slow build due to a huge amount of dependencies and nostrip building of them as well :)
<sistpoty> is there s.th. wrong with a.u.c? I can't install python2.4-dev due to size mismatch
<pitti> *grumble* Malone email interface doesn't work *grumble*
<dholbach> ogra: another new dia release
<trappist> pitti: bug 
<pitti> trappist: ENOVERB
<trappist> oops. 31893 was suggested to me by crimsun.  I'd appreciate it if you could have another look at it.
<pitti> (or is that meant as a verb?) :)
<trappist> spoda be a noun :)
<pitti> bug 31893
<Ubugtu> malone bug 31893 in alsa-utils "Multiple sound cards difficult to manage with asoundconf" [Normal,Unconfirmed]  http://launchpad.net/bugs/31893
<pitti> trappist: oh, I see; I still don't think that asoundconf is an appropriate end user tool
<pitti> trappist: however, I can apply the patch nevertheless if it helps you
<trappist> I think I agree with you, but alsaconf is pretty universally hated and I think we need *something*.
<trappist> it doesn't help me personally now that I know the names of my sound cards.  but I doubt I'm the only non-gnome-user with multiple sound cards.
<pitti> trappist: I'll add another task to the bug that asks for a KDE equivalent; can't hurt
<trappist> nope, can't hurt.  except someone will say there is a kde equivalent without having paid attention to the behavior of kde's sound configurator, which either turns off or configures arts and nothing else.
<pitti> trappist: ok, thanks for the feedback, and sorry for the premature closing
<trappist> no harm no foul, thanks for lettin me cry on your shoulder
<pitti> :)
<BenC> is there a mirror of cdimage.u.c?
<seb128> BenC: cf Kamion's announcement of flight CDs by example
<seb128>   Europe:
<seb128>     http://ftp.acc.umu.se/mirror/cdimage.ubuntu.com/releases/dapper/flight-4/ (Ubuntu)
<BenC> ah, thanks
<seb128> np
<BenC> much faster
<trappist> pitti: it occurs to me that some people don't use gnome *or* kde and that we really should have a cli solution for this.
<Panzerboy> hey all
<seb128> GetRideOfTheDesktop (tm)
<Panzerboy> i've just updated to dapper and all i can say is: WOW !
<Panzerboy> congrats guys
<seb128> thank you :)
<Panzerboy> and thanks for all the hard work
<marcin`> trappist: you are not the only non-gnome-user with multiple sound cards it's plenty of them
<marcin`> trappist: I use ratpoison and got two sound cards - one integrated on mobo and another is sb live
<marcin`> trappist: so I agree with you
<marcin`> anyway hello #ubuntu-devel
<marcin`> got a question
<trappist> marcin`: I'm glad to hear from you then
<HrdwrBoB> trappist: you don't have to use 'gnome'
<HrdwrBoB> to be able to run gnome-fix-something-ladeda
<marcin`> could someone tell me if are there any plans to implement conditional dependencies in dpkg?
<marcin`> anyone?
<dholbach> good night guys
<trappist> HrdwrBoB: at first glance gnome-sound-properties does look handy
#ubuntu-devel 2007-02-19
<Riddell> "dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address" hmm
<kylem> Riddell, yeah, annoying++ :/
<Riddell> oh well, cheereo Debian maintainer
<Hobbsee> heya Riddell 
<kylem> Riddell, you can rename it to "XSBC-Original-Maintainer:" to stop it whining.
<mconnor> hmm, I bet iwj is asleep already
<crimsun> likely. perhaps alexander (asac) is awake?
<mconnor> oh, right
<mconnor> asac: ping
<mconnor> right, it was asac who made the change :-/
<mconnor> asac: the FeedWriter.js patch fixed the feed preview bug that happens with flat chrome, see LP 61182
<asac> mconnor: why didn't someone ask for branch approval?
<mconnor> asac: because we didn't know anyone ships with flat chrome?
<mconnor> asac: the perf overhead sucks, etc
<mconnor> asac: whoever landed it didn't point at the LP bug?
<asac> nope
<asac> at least I didn't see it in changelog
<mconnor> bah
<asac> mconnor: thanks ... will reapply when 2.0.0.2 is out. would you volunteer to take over the approval for 1.8.1.3 step?
<mconnor> which approval?
<asac> for landing on branches
<mconnor> asac: we have a group doing that already, but I'll nominate the upstream patch for approval
<asac> mconnor: thx
<mconnor> which is probably enough to get it rubber-stamped ;)
<asac> what group?
<mconnor> there's no mailing list, because I'm a failure, but its Jay Patel, dveditz, and a rotating group of three others (one from the Firefox team, one from the Platform team, and one from QA)
<mconnor> I'll hopefully get that handled before I leave for FOSDEM
<asac> mconnor: good to hear. please keep me updated on new procedures for getting distributor patches approved.
<mconnor> asac: nominate for the branch once they're appropriately reviewed
<mconnor> asac: that should be it
<mconnor> if you run into roadblocks, email me
<asac> mconnor: ty ... will definitly come back to you soon :)
<mconnor> asac: I'm not always evil, I really do want this to all be less painful ;)
<asac> mconnor: i didn't perceived you as evil ... just as a messenger of sad news :) ... n8
<mconnor> asac: well, that's good, for a while I had visions of showing up at FOSDEM or something and getting swarmed ;)
* poningru takes reeds cross and pushes it on mconnor's chest watching him melt
<mconnor> bah
<mconnor> I'm not THAT evil
<mconnor> I'm just the bad cop sometimes
<poningru> naah its reed's cross its got that gnu magick powder
<poningru> it harms anyone who has written any code in non-GPL/LGPL
<poningru> ;)
<poningru> but dont tell reed I stole his cross
<mconnor> poningru: don't try to sucker me into a discussion about licenses :P
<poningru> mconnor: lol
<poningru> wtf wrong channel
<jdong> seeking prod on bug 85424
<Ubugtu> Malone bug 85424 in gnome-mount "Unmount fails every time " [Undecided,Confirmed]  https://launchpad.net/bugs/85424
<jdong> stale /media/.hal-mtab causes spurious errors from gnome-mount
<jdong> wondering if that file should be cleaned out per bootup
<Hobbsee> jdong: it's a sunday in most countries, and the europeans are asleep
<jdong> Hobbsee: thanks for ruining my optimism
<jdong> Hobbsee: I'm gonna go three blocks east and jump off the Charles River bridge
<jdong> Hobbsee: and it's all your fault
<jdong> :P
<Hobbsee> jdong: oh dear...
* jdong prints off a google map to the bridge
<jdong> look, longfellow bridge is only .2 miles away
<jdong> ironically mass general hospital is right across the bridge :)
<popey> hehehe@jdong
<Mirv> Mithrandir: you might want to consider applying the patch for bug 22985 (19 duplicates) in xserver-xorg-video-ati, now that there is such
<Ubugtu> Malone bug 22985 in xserver-xorg-video-ati "[x700]  fails to infer lvds for primary connector on acer ferrari 4005 | card detected, but driver fails to use right output port" [High,Confirmed]  https://launchpad.net/bugs/22985
<Mithrandir> Mirv: thanks; I'll have a look.
<dholbach> good morning
<bhale> hello dholbach 
<dholbach> hey bhale
<seb128> asac: hi. About that totem,firefox crasher, any reason firefox stopped linking to libxpcom?
<pitti> good morning
<ajmitch> morning pitti 
<pitti> hey ajmitch 
<seb128> hey pitti
<seb128> hi ajmitch
<ajmitch> hi seb128
* pitti hugs seb128
<ajmitch> so who's approving UVF exceptions at the moment? ubuntu-release?
* seb128 hugs pitti back
* ajmitch should have a new (bugfix-only) release of f-spot soon
<Mithrandir> ajmitch: yes, ubuntu-release, but we don't have a process in place for it yet, so it's "nag Tollef on IRC" for now.
<ajmitch> ah right
<ajmitch> so nag you once I have a package tested?
<Fujitsu> pitti: I've attached a new debdiff to that zope3 SRU, as you may have noticed. I've got no idea if the changelog is user-oriented enough now.
<ajmitch> Fujitsu: tested the twisted-web2 'fix'?
<Mithrandir> ajmitch: yes, for main packages.  Universe has the motu-uvf team.
<ajmitch> I haven't had any problems with it yet (and have a package ready to upload)
<ajmitch> Mithrandir: yep, I was part of motu-uvf for edgy
<Fujitsu> ajmitch, yep, it seems to sort of work. I haven't tested too much of it.
<ajmitch> I was playing around a bit with zope3 today, I'll check with doko before I upload
<ajmitch> doko: ah, your package seems to work fine, thanks :)
<dholbach> gpocentek: there's a new goffice and gnumeric - if you care about it
<seb128> dholbach, gpocentek: already packaged by Debian if that makes the job easier
<dholbach> seb128: that's good to hear... I reckon we just need to apply our "*-gtk packages" patch
<gpocentek> dholbach, seb128, ok, I'll work on it
* dholbach hugs gpocentek
<iwj> fabbione: AYT?  What's the current situation with bug 38409 ?
<Ubugtu> Malone bug 38409 in lvm2 "creation of snapshots fails unpredictably" [High,Confirmed]  https://launchpad.net/bugs/38409
<pitti> doko: gcc-4.1 is alright now in feisty?
<pitti> seb128: so I'll ignore Maintainer: stuff for Xish and Gnomeish packages for now?
<seb128> pitti: correct
<doko> pitti: yes
<pitti> splendid
<pitti> so, we need to upload about 10 packages per day until the beta freeze
<doko> pitti: but not yet built on sparc
<pitti> doko: still building or ftbfs problems? shall I wait?
<doko> pitti: still building
<pitti> doko: ok, I'll just wait another day then?
<seb128> pitti: do you have a list of packages to rebuild somewhere?
<pitti> seb128: grep-dctrl -sPackage,Maintainer,Original-Maintainer -FVersion ubuntu archive.ubuntu.com_ubuntu_dists_feisty_main_binary-amd64_Packages | grep-dctrl -sPackage -FMaintainer -v -n ubuntu
<doko> pitti: do you have a list of packages somewhere? maybe we can sort out some stuff, where we know about new uploads
<pitti> doko: see above
<pitti> seb128: this gives 305 hits so far, but of course this will boil down a bit since we rebuild entire source packages
<pitti> doko: oh, oo.o-help/l10n covers some 40 packages alone :)
<pitti> and the X.org video drivers another good chunk
<seb128> pitti: that's 129 source packages apparently
<doko> pitti: right ... and I know I will make another upload ... could you put the list in the wiki, so we can sort out some packages to other sections?
<pitti> doko: 'sections'?
<seb128> pitti: without xorg and gnome package there is probably like 40 packages to rebuild, we can probably wait and see which ones sort themself
<pitti> seb128: that's not too bad
<doko> paragraphs, whatever
<pitti> doko: ah, sure
<pitti> wiki will become obsolete quite fast, though
<doko> so you only process these, and others take the responsibility for other packages
<pitti> doko: right, maintaining an explicit blacklist is fine
<asac> seb128: have to take a look if it was a regression from last upload. otherwise, I don't know.
<seb128> asac: that's a regression, totem didn't change recently and those crashes happened since your firefox upload
<seb128> asac: I think firefox used to link with libxpcom and stopped doing that or something like that, that's not the first time that happens IRC
<asac> seb128: you sure it popped up with last upload? we a good bunch of totem crashers in bts.
<seb128> asac: and totem doesn't link explicitly with the firefox libs to not make the browser plugin depends explicitly on a browser
<seb128> asac: well, the missing symbol was making firefox crash on any video for everybody and I'm pretty sure that's due to a recent change, we started to get totem bugs about that some days ago
<asac> seb128: ok ... hasn't there been a fix uploaded for totem? ... what does it do, load libxpcom manually?
<seb128> asac: right, I made the plugin build with "-L/usr/lib/firefox -lxpcom"
<seb128> asac: totem doesn't do it usually to no Depends specifically on a browser (the browser plugin can work with firefox, xulrunner, etc then)
<pitti> seb128, doko: https://wiki.ubuntu.com/MaintainerFieldRebuilds; please add the things you want to take care of (doko: oo.o-help* are separate sources, will they be updated again before freeze?)
<pitti> seb128, doko: I'll write an u-d-a mail now with some details
<seb128> pitti: do we need to do that?
<seb128> pitti: can't we just wait 2 weeks and see what solves itself by normal uploads and then do the remaining changes?
<asac> seb128: ok, then how was it linked before?
<pitti> seb128: that's the thing, we have pkgbinarymangler in place for a long time already
<pitti> seb128: and stuff like libogg, mailx, or mount won't change anytime soon again
<seb128> pitti: those are the ones we can rebuild in 2 weeks
<seb128> there is probably not a zillion of them, there is only 129 source packages to rebuild
<seb128> and a good part of them are xorg drivers
<cjwatson> pitti: -sSource:Package FYI
<pitti> seb128: I don't want to rebuild them on one day, though
<seb128> pitti: well in one week will be good enough
<pitti> seb128: ok, WFM
* cjwatson prods the example command line
<pitti> cjwatson: thanks
<seb128> asac: I'm looking at it, one min
<pitti> cjwatson: ah, that's 'show Source:, and if that doesn't exist, show Package:'? clever
<cjwatson> pitti: yeah
<seb128> asac: 
<seb128> with 2.0.0.1+0dfsg-0ubuntu1:
<seb128> $ objdump -x firefox-bin | grep xpcom
<seb128>   NEEDED      libxpcom.so
<seb128>   NEEDED      libxpcom_core.so
<doko> pitti: and now make it a list of source packages ;-)
<seb128> with 2.0.0.1+1-0ubuntu1
<seb128> $ objdump -x firefox-bin | grep xpcom
<seb128>   NEEDED      libxpcom_core.so
<seb128> 
<pitti> doko: see grep on updated wiki page
<seb128> asac: the "NEEDED      libxpcom.so" drop is what created the problem
<asac> seb128: so lib has not been loaded, so bang ... ok
<seb128> right
<seb128> might be considered as a totem bug though
<seb128> the "don't link to required libs to not depends on a specific browser" is sort of a workaround
* asac wonders how firefox works at all without libxpcom.so loaded ... interesting. anyway, I guess I know what caused this.
<Riddell> cjwatson: new partitioner in kde frontend should be ready to merge in, are you happy for me to go ahead or do you want to take a look first?
<cjwatson> Riddell: feel free to blat it into mainline and I'll have a look before upload
<cjwatson> Riddell: btw see http://wiki.ubuntu.com/InstallerDevelopment for CIA setup so that your commit gets logged on #ubuntu-installer
<lifeless> cjwatson: btw, you can configure branches centrally for bzr-email
<lifeless> cjwatson: and looking at cia-email, that too in all probability
<cjwatson> lifeless: sorry, I don't understand?
<lifeless> 'Unlike with a centralised revision control system, this can't (easily) be set up centrally; each committer needs to set this up for each branch.'
<lifeless> this is not the case
<cjwatson> lifeless: I don't see how I could set it up such that anyone's commits get sent to CIA; can you elaborate?
<cjwatson> lifeless: the only way I could see to do that would be if I got to install push hooks on the supermirror
<lifeless> if you put the settings in branch.conf, which lives in .bzr/branch, then the code will find the configuration on each machine during post commit
<lifeless> it should be that all you need to do is to have the plugin installed on each machine
<cjwatson> branch.conf doesn't propagate to other branches surely?
<cjwatson> and in any case, my point that each committer will need to do some setup (getting the plugin at least) still stans
<cjwatson> stands
<lifeless> thats true
<ogra> seb128, are you aware of any probs with the screenshooter ? i just had a prob with it (it wasnt saving anything) so i ran an strace which then hardlocked the machine ...
<cjwatson> which is my main point
<lifeless> it sounds worse than it is to me
<seb128> ogra: nop
<lifeless> which was my point
<cjwatson> lifeless: feel free to edit the wiki page to more accurately describe the state of affairs, as long as the setup information remains accurate
<ogra> last thing i saw was it was trying to access a socket in /tmp/.ICE-unix/
<cjwatson> lifeless: I think you're reading it as criticism of bzr, which it isn't intended to be
<cjwatson> the primary purpose of that section is to document the setup
<lifeless> cjwatson: 22:41, so not right now, but we'll see later
<cjwatson> I'll s/centrally/on a single central machine/
<cjwatson> lifeless: better now?
<lifeless> its fine, I'll make some time to test exactly what can be done to make the setup easier for you
<lifeless> I think what I'm really saying is you aren't using bzr's facilities to their fullest for what you seem to want
<lifeless> and thats really something I'm better placed to fix, but after 0.15 is out
<cjwatson> I'd certainly welcome suggestions of improvements
<cjwatson> supermirror hooks to do service notification (whether CIA or something Launchpad-specific) on push would actually be ideal, but that seemed like something I shouldn't hold my breath for
<lifeless> LP is getting email-on-commits soon
<lifeless> done lp specific
<cjwatson> perhaps that can be made to be extensible and machine-parseable and stuff
<cjwatson> I do like the CIA model, although I appreciate that it overlaps with Launchpad in some ways
<cjwatson> IRC notification is the bit I actually care about
<Mithrandir> seb128: is the gdm socket going to move to /var/run/gdm_socket soonish?
<seb128> Mithrandir: I'm working on it at the moment
<Mithrandir> seb128: cheers.
<seb128> Mithrandir: will be uploaded before lunch
<seb128> ;)
<Mithrandir> seb128: but the new address will be /var/run/gdm_socket, right?
<Mithrandir> seb128: I'm updating powermanagement-interface now.
* Hobbsee waves to Mithrandir 
* Mithrandir waves to Hobbsee
<seb128> Mithrandir: correct
<Mithrandir> seb128: cheers
<seb128> Mithrandir: I can update that package as well if you want
<seb128> would be nice to have something like 
<seb128> if (old_socket_name_exist)
<seb128> ...
<seb128> else
<seb128> ...
<Mithrandir> indeed.
<Mithrandir> if you want to fix it, feel free. :-)
<seb128> will do
<seb128> I'm already doing for gnome-session
<Mithrandir> it should be easy enough to make it iterate over the possible names.
<seb128> right
<shawarma> Stuff in the NEW queue should (if they don't get rejected) make it in time for universe's FF, right?
<shawarma> &win 2
<shawarma> ... sorry
<Mithrandir> shawarma: if we have the time, yes.
<ogra> kwwii, http://people.ubuntu.com/~ogra/ldm_cairo_screenshot.png
<ogra> i didnt work on the font handling yet
<ogra> feel free to drop me a different wallpaper svg
<ogra> seb128, is there a way that we split out pythons rsvg module from gnome-python2-desktop ? i think the xubuntu guys wont be happy if ldm depends on half of the desktop libs
<seb128> ogra: there is still a way to split things, yep ;)
<ogra> (and i wonder why its in there instead of being separate since i started with cairo stuff)
<ogra> well, would it be possible for feisty ? 
<shawarma> Mithrandir: Ok.. So "likely, yes" ?
<shawarma> :-)
<kwwii> ogra: cool, I'll send you a bg sometime later today
<Mithrandir> shawarma: "maybe".  We're usually processing the queue in FIFO order, so get your uploads in early rather than late.
<shawarma> Mithrandir: Ok. The particular upload I'm interested in went in saturday night. Does that qualify as early, you think?
<shawarma> Mithrandir: It's network-manager-{openvpn,vpnc} if it matters.
<infinity> I'm happy to do some universe NEW processing when I need a brain break here and there if the distro-owned archive guys are tied up with doing main processing.
<Mithrandir> shawarma: shiny, yes, I do definitively think we should get that in.
<shawarma> Mithrandir: Whee! Thank you. :-)
<Mithrandir> infinity: I'm doing binary new now, but if you'd like to start with source new at the top or the bottom, that works for me.
<infinity> (And I agree with Tollef, those are toys I want)
<infinity> Mithrandir: I'm assuming you'll be focussing on main first, so I'll poke at universe stuff when I need a context switch for sanity reasons.
<infinity> Mithrandir: Tomorrow, mind you, I'm about to cut out for the day today (11pm)
<Mithrandir> infinity: sounds good to me.
<Mithrandir> infinity: binary new is generally so small I just do it all in one batch
<Hobbsee> Mithrandir: i think the question more is "will we have to file exceptions, etc, if our stuff doesnt get thru NEW in time for the freeze"
<infinity> Mithrandir: Yeah, binary NEW was always just a "I have a few minutes and look, there's some crap in the queue!" thing for me.
<infinity> Hobbsee: If it was uploaded pre-freeze, but not processed, I'd recommend a poke to the -archive list for the ones you're concerned about.
<Hobbsee> infinity: right.  shawarma ^
<Mithrandir> Hobbsee: I'd have to make up some policy about that.
<seb128> Mithrandir: I should have left the huge pile of new python -dbg for you :p
<Mithrandir> but otherwise as infinity says.
<infinity> Hobbsee: In some cases, it may be stuff we've purposefully not processed, cause we just don't think it can be made useful between now and release, in other cases, it'll be stuff that slipped through and we should process it.
<Hobbsee> Mithrandir: well, yeah
<Mithrandir> seb128: lucky me you didn't. :-)
<seb128> yeah ;)
<shawarma> Hobbsee: Mkay.
<doko> infinity: could you get me the preprocessed file in the openoffice.org build on amd64?
<Mithrandir> doko: hmm, why is ooo-l10n now trying to drag in stlport?  I thought we got rid of that?
<doko> Mithrandir: not yet rebuilt from new sources
<infinity> doko: You know the answer to that.
<doko> infinity: no?
<infinity> doko: Correct.
<infinity> doko: But if it's required, I can do a manual rebuild and save the chroot.
<infinity> doko: By default, it's all blown away post-build.
<doko> infinity: that is the question I have ...
<infinity> doko: Yup, can be done.  Mail me, pretty please, I'll do it in the background tomorrow while coding and such.
<doko> infinity: done
<infinity> doko: Danke.
<jdub> what controls gnome power manager showing suspend and hibernate? for some reason, in fisty, mine shows neither (and i can't make the machine suspend)
<jdub> ACPI_SLEEP and ACPI_HIBERNAME == true in /etc/default/acpi-support
<cjwatson> /usr/sbin/pmi
<cjwatson> (last I checked)
<jdub> $ pmi capabilities
<jdub> hibernate suspend
<cjwatson> guess I'm wrong then
<lifeless> jdub: try clicking on logout again
<jdub> aha
<jdub> after i ran the power manager applet
<jdub> gnome-power-manager ran
<jdub> and now i can see them in power manager again
<Riddell> seb128: re bug 86257, do you know if the gdk-pixbuf feature is used by anything?
<Ubugtu> Malone bug 86257 in amarok "amaroK indirectly depends on libgtk2.0 (dup-of: 59663)" [Wishlist,Rejected]  https://launchpad.net/bugs/86257
<Ubugtu> Malone bug 59663 in libgpod "Please build without gdk-pixbuf/gtk" [Wishlist,Confirmed]  https://launchpad.net/bugs/59663
<seb128> Riddell: gtkpod
<jdub> so g-p-m is never run, it seems
<seb128> jdub: do you have an autostart to /etc/xdg/autostart for it?
<Riddell> seb128: ok
<jdub> seb128: hmm! no
<jdub> not in startup programs either
<seb128> jdub: what version of the package do you have installed?
<jdub> 2.17.90-0ubuntu3
<jdub> also
<jdub> it has a /usr/share/gnome/autostart directory, but it's empty
<geser> infinity: Hi. Have you some time to look at the build failure of xmms2? http://librarian.launchpad.net/6335715/buildlog_ubuntu-feisty-i386.xmms2_0.2DrHouse-3.1ubuntu3_FAILEDTOBUILD.txt.gz
<geser> infinity: it's HASH(0x82db558)="" in the environment that /bin/sh can't parse and errors out
<infinity> geser: Yeah, I recall, though it wasn't on my immediate TODO.  Can you mail me about it, though?
<infinity> geser: The failure looks... Interesting... But should be trackable.
<seb128> jdub: 
<seb128> $ dpkg -L gnome-power-manager | grep desktop
<seb128> /usr/share/applications/gnome-power-preferences.desktop
<seb128> /etc/xdg/autostart/gnome-power-manager.desktop
<seb128> jdub: maybe you removed the autostart at some point and since that's a conffile ...
<geser> infinity: I send you an email on 7 Feb 2007 about it. Should I send it again?
<jdub> seb128: hrm, can't imagine i dicked with that
<cjwatson> if I've got a runtime-determined set of buttons which may well end up not fitting onto a single line in a GTK UI, what container widget should I use for them? It doesn't look like HButtonBox will wrap
<heno> dholbach, Mithrandir: can we still get a new upstream version of onboard? the current one is broken since the python changes. Should I file a UVF request?
<Mithrandir> heno: debdiff, please?
<infinity> geser: Oh, so you did.
<infinity> geser: Again might be nice anyway, unlike most people, I appreciate the occasional nag. :)
<heno> Mithrandir: I'll ask Chris to prepare one
<Mithrandir> heno: thanks.
<geser> do Debian updates of native packages need an UVF exception?
<jdub> seb128: i just upgraded g-p-m and now i have that file :)
<shawarma> Does our sparc version install in a qemu sparc thing?
<infinity> No idea, you could try. :)
<infinity> I've only installed it on real hardware.
<shawarma> I tried it a while ago, but it didn't work, but I don't know if it's me or qemu that's being stupid.  I'm going to try again when the feisty image is done downloading.
<seb128> jdub: ah, you had .90, yeah that was a known bug fixed
<shawarma> infinity: It seems not. It just says "Unsupported image format
<mvo> iwj: I assume you have intimite knowledge of update-alternatives? if you could have a look at https://launchpad.net/ubuntu/+source/vim/+bug/84466, it looks like there is some problem with it there
<Ubugtu> Malone bug 84466 in vim "[apport]  package vim-tiny failed to install/upgrade:  (dup-of: 84906)" [Undecided,Unconfirmed]  
<Ubugtu> Malone bug 84906 in vim "vim-tiny postinst fails" [Undecided,Confirmed]  
<iwj> mvo: Hmm.
<mvo> update-alternatives: unable to make /usr/share/man/ru.KOI8-R/man1/vi.1.gz.dpkg-tmp a symlink to /etc/alternatives/vi.ru.KOI8-R.1.gz: No such file or directory
<mvo> that is the error
<mvo> vi.ru.KOI8-R.1.gz vanished from the packaage in the later version but was part of it in the earlier version
<infinity> Then the slave needs to be removed with a version check, no?
<iwj> Well, the _alternative_ needs to be removed.
<iwj> Exactly how that should work depends on what the old package said.
<iwj> Oh, err, no, infinity was right.
<cjwatson> mvo: there's a Debian bug for that too
<mvo> hm, prerm runs "update-alternatives --remove vi" and it seems to be only trigger for some people
<mvo> I'm unable to reproduce it here
<cjwatson> I reproduced it
<Mithrandir> it fixes itself over a couple of runs, iirc.
<iwj> That's weird.
<jdub> seb128: thanks :)
<cjwatson> yes, update-alternatives removes the slaves one by one on repeated runs, or something like that
<seb128> jdub: np
<tbf> finally found some script for creating linux-to-osx cross-compilers
<iwj> cjwatson: Freaky.
* cjwatson tries to find the bug
<tbf> wondering if this script should not be turned into some ubuntu package - like the mingw32 packages
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=399024
<Ubugtu> Debian bug 399024 in vim "Upgrade fails because of missing man page directory" [Important,Closed]  
<cjwatson> iwj,mvo: ^--
<shawarma> Where would I ask questions about Ubuntu on Sparc hardware? (May god have mercy on the soul of the first person who says #ubuntu..)
<cjwatson> I attached a /var/lib/dpkg/alternatives/view to that bug
<gnomefreak> shawarma: but you leave it wide open for someone to say #ubuntu ;)
<mvo> cjwatson: thanks! 
<cjwatson> supposedly we can merge to fix it, but there may be an update-alternatives bug there too
* shawarma grumbles
<gnomefreak> asac: not many people in #ubuntu use sparc anyway
<iwj> cjwatson, mvo: I think this needs looking at the code really.  Do you want me to take a look ?
<iwj> I mean the code in update-alternatives.
<mvo> iwj: I would appreciate that, especially since it does seem to be triggered on nano as well (not only vim)
<iwj> The `rerun it to fix it' definitely sounds like an u-a bug.
<iwj> mvo: OK, willdo.
<shawarma> gnomefreak: precisely.
<gnomefreak> shawarma: is ther a #sparc channel?
<mvo> iwj: thanks, I subscribed you to bug https://launchpad.net/ubuntu/+source/dpkg/+bug/84906 (the master) and will add the information we have so far
<Ubugtu> Malone bug 84906 in vim "vim-tiny postinst fails" [Undecided,Confirmed]  
<iwj> mvo: Thanks.
<mvo> iwj: I also added how the workaround works. let me know if I can do more 
<Mithrandir> shawarma: you need to ship a copy of the licences in the orig.tar.gz.
<seb128> Mithrandir: are you doing syncs atm?
<Mithrandir> seb128: nope
<seb128> ok, I'm doing the libdrm sync now then
<seb128> does anybody have an opinion on using gnome-power-manager for restart and shutdown from GNOME rather than gdm?
<seb128> it would make the actions work for people not running gdm
<seb128> and make them configurable by gconf with the possibility for an admin to force settings for example
<giskard_> g-p-m is installed by default?
<mvo> seb128: if you do this, please let me know because I would have to switch the reboot method in u-n (it currently uses gdm)
<seb128> it would also means means gnome-session has to keep depending on gnome-power-manager
<seb128> pitti as requestion a move to Recommends for it
<seb128> mvo: well, you don't "have to", gdm keeps working
<Mithrandir> ubiquity would also need updating that way.
<seb128> giskard: yep, it's part of GNOME desktop and gnome-session uses it for power management
<seb128> giskard: speaking about g-p-m, do you maintain it for Ubuntu? Help on the huge bugs list would be welcome ;)
<seb128> "pitti was asking if we could Recommends g-p-m only" rather ;)
<seb128> mvo, Mithrandir: any preference between using gdm or gpm?
<ogra> Mithrandir, not as long as we use gdm on the livecd ...
<ogra> seb128, i'd go for gpm ...
<ogra> to have all options centralized in one place
<seb128> right
<ogra> and there is finally a centralized source for the bugs ...
<seb128> need to check if it works fine with usplash now
<mvo> I don't mind either way, I just want to keep u-n in sync so that is uses the same method
<seb128> we reverted that change for dapper because we had no usplash screen on shutdown with it IIRC
<ogra> nobody told me ... whats required to make it work if it doesnt ? 
<seb128> not sure
<ogra> well, it shouldnt be to hard given that it works from console as well as from gdm
<seb128> probably not
<keescook> Mithrandir: aagh.  sorry (see email).  I was doing the UVFe upload, so I didn't study the packaging -- I assumed it was unchanged from the prior package.
<seb128> hi keescook
<keescook> hiya seb128
<seb128> keescook: do you want to work on the "filename doesn't match mimetype" thingy?
<keescook> seb128: not today at least; it's a holiday here.  :)  I am interested in poking at it in general, though, since it relates to .desktop management.
<seb128> keescook: ah right, enjoy your holiday ;) You have some interest for .desktop management? ;)
<keescook> seb128: well, from the perspective of changing the entire design to make sure .desktop files have to be executable, etc, yeah.  :)
<keescook> but I can't do that without a better understanding of things around them.
<seb128> keescook: BTW Debian patched nautilus for the "don't run .desktop not named .desktop" problem
<seb128> keescook: I'll grab the patch once it got some testing in Debian
<keescook> seb128: excellent.  :)
<seb128> wb pitti
* pitti grumpfs - still no real network back
<pitti> hey seb128
<seb128> pitti: any opinion on making GNOME uses gnome-power-manager for restart and shutdown?
<seb128> pitti: that would mean to Depends on g-p-m and you opened a bug for moving it to Recommends
<seb128> the advantage over using gdm is that it would work for people not using gdm
<pitti> seb128: if it's better/easier for you, sure
<seb128> and would allow gconf config flexibility
<keescook> okay, so I want to fix up my mistake with the mythtv upload... I imagine I should move the /home stuff to /var/lib/mythtv somewhere, correct?  Anyone see anything else wrong with it?
<leleobhz> someone can help-me to update the jackd?
<leleobhz> im trying to insert libfreebob support
<seb128> pitti: well, it's not really easier since it's already working with gdm atm. I'm just wondering if using g-p-m for that would be better
<leleobhz> but im unsuccessfull
<pitti> seb128: hm, I don't have a strong opinion about it; I don't know the pros and cons, but as desktop team master you should decide
<seb128> one advantage is the gconf use which could make easier for admin to force values by user category
<seb128> pitti: what was the reason you were trying to remove gnome-power-manager? Cleaning the installed packages or it's created problems for you?
<seb128> I'm try to determine if moving to Recommends (which we can do if we keep using gdm) would make some users happy
<pitti> seb128: no, just getting rid of unnecessary cruft on a desktop system
<seb128> ok
<pitti> seb128: there's no other point in running all the dynamic freq/battery/power stuff here
<seb128> right
<pitti> seb128: but I wouldn't particularly mind if g-p-m keeps being installed
<wasabi> I like GPM on my desktop... because I have a UPS. :0
<wasabi> And it all sort of works together really cooly.
<wasabi> Even lets me shut down when the UPS power gets too low.
<Mithrandir> keescook: the previous package was busted too.
<keescook> Mithrandir: yeah.  :(  I've started making a list of all the problems I see with it.  What's the right way for me to fix this?
<pitti> doko: ah, gcc-4.1/sparc built
<Mithrandir> keescook: apply the necessary cluebats to the sponsee and get him to make you new packages until you're really, really happy with them.
<Mithrandir> keescook: then upload them.
<keescook> Mithrandir: okay.  what would you suggest for the /home dot-file shipping issue?  just move the mythtv user in /var/lib/mythtv or something?
<Mithrandir> keescook: for instance, yes.
<keescook> Mithrandir: did anything else jump out at you?
<Mithrandir> keescook: I don't see the point of the metapackages, particularly not four of them
<keescook> Mithrandir: as far as I can see; they're for setting up specific configurations of mythtv, in the right combinations for what a person wants their system doing.
<Mithrandir> keescook: a couple of them didn't have any postinsts.
<keescook> Mithrandir: I don't think a postinst is required for them; they're just the list of the various myth packages to get installed to get a sane myth setup.
<Mithrandir> keescook: why can't that just go into the description of the packages they depend on?
<keescook> Mithrandir: I assumed it was to make it easy to install a given configuration.  I'm happy to make whatever changes; this package is giant.  :)
<Mithrandir> keescook: I don't think the metapackages make sense there; they're like "frontend-backend", something which doesn't make any kind of sense unless you know a bit about how mythtv is put together (and then the metapackage still doesn't make any sense, because you can just as easily install the two packages it depends on)
<keescook> Mithrandir: I could go either way; the metapackages do enforce some non-myth deps that are required for sane functioning.  looking at it, for example, the ubuntu-mythtv-master-backend requires mysql-server, where as u-m-secondary-b does not, etc.
<keescook> I'm going to have to have some preinst scripts build some /etc/defaults files too, for sane migration out of /home and /media (!!)
<shawarma> Mithrandir: As in basically a copy of debian/copyright?
<Mithrandir> shawarma: as in a full copy of the licence.  
<shawarma> Mithrandir: Alright. The LGPL stuff is contained in then auth-daemon directory, so I could toss the LGPL COPYING file in there and the GPL one in the main dir. Something like that?
<Mithrandir> shawarma: yes, that's fine
<shawarma> Coolenss.
<shawarma> Coolness, even.
<shawarma> Mithrandir: I have to say, it really feels wrong to alter the orig.tar.gz..
<cjwatson> I don't see why this needs to go in the .orig.tar.gz
<cjwatson> the only reason to modify the .orig.tar.gz is really if for some reason we have to remove stuff from it
<shawarma> Ok, now I'm really confused. :-)
<Chipzz> shawarma: licensing issues
<Mithrandir> it's an svn snapshot anyway.
<Chipzz> shawarma: if the orig.tar.gz contains material which is not suitable for distribution
<shawarma> Chipzz: Yes, yes, I get that.
<Chipzz> shawarma: all the rest can be taken care of with a patch
<shawarma> Chipzz: I'm just confused since cjwatson and Mithrandir seems to be giving me contradictory orders. :-)
<keescook> Mithrandir: trimmed metapackages to 2.  :)
<Mithrandir> shawarma: we are, because we are of a differing opinion.  I am of the belief that the orig.tar.gz by itself has to allow for redistribution and not just reference the licence.
<Chipzz> is it normal that apt-get dist-upgrade keeps insisting on removing hwdb-client and a couple of python packages?
<Chipzz> this seems like some unsorted stuff from python 2.4 -> 2.5 migration
<shawarma> Mithrandir: That is also a valid point.. fine, I'll add it, but I'll be feeling funny while doing it. :-)
<doko> pitti, seb128, cjwatson: please promote the binary only python packages, found in anastacias output
<seb128> doko: today's is Mithrandir's archive day ;)
<doko> Mithrandir: ^^^ ;)
<Mithrandir> doko: yeah, I'll poke it
<shawarma> Mithrandir: Should I subsequently make sure that those COPYING files are copied to /usr/share/doc/..../ ?
<Mithrandir> shawarma: no.
<shawarma> Mithrandir: Ok.
<pochu> I have just tried to update the system, but the update-manager tells me that it's dangerous because the packages aren't authenticated. did you know this?
<cjwatson> this sometimes happens transiently if the mirror you're using got a bit desynchronised
<cjwatson> reload in synaptic (or apt-get update, or whatever) in a while and try again
<pochu> cjwatson: ok, thanks. but I think I'm using the main server :)
<cjwatson> pochu: unfortunately once in a while it happens on archive.ubuntu.com as well; it should go away in an hour
<pochu> cjwatson: there is no problem in update, right?
<shawarma> Mithrandir: Reuploaded the network-manager-{openvpn,vpnc} packages.
<Mithrandir> shawarma: cheers.
<shawarma> Mithrandir: Thanks for your help!
<Ocha> hello everyone
<Ocha> no one here :-/
<Riddell> pitti: 84717 updated with patches with improved descriptions and some missing dependencies and shlibs
<Riddell> bug 84717
<Ubugtu> Malone bug 84717 in update-manager "SRU: updates necessary for Kubuntu Upgrade Tool in Edgy" [Undecided,Needs info]  https://launchpad.net/bugs/84717
<pitti> Riddell: ah, great
<Riddell> pitti: nothing much can be done about the complexity of the diffs in kdelibs or python-kde3 I'm afraid
<pitti> Riddell: hm, they seemed to have shifted code around
<Riddell> pitti: the methods added in the kdelibs patch do reuse some lines of code from the existing open() method which makes diff not just give you a diff of the methods
<Ocha> oooow, someone is talking.  hello all, i would like some information out of you guys.  I'm looking into getting ubuntu, but i want to be selled first.  tell me whats great about ubuntu.
<Nafallo> Ocha: you probably want #ubuntu :-)
<Ocha> your telling me you can't describe any good of ubuntu?  but thanks for the channel.
<mjg59> Ocha: We could, but this is the wrong place to ask
<Ocha> sorry then, what is this channel for?
<mjg59> Development of Ubuntu
<Ocha> thought so, thanks everyone. ^_,^  have a good day.
<yveslu> hello, I have an observation regarding startup speed of OOo, something that looks strange
<yveslu> for fun I put fedora core 6 on the laptop, alongside with edgy and feisty
<yveslu> warmstart of oowriter on edgy takes almost 3 seconds
<yveslu> on feisty a little less, about 2.5 I guess
<yveslu> and on fedora 6 it takes 1, yes one, second
<yveslu> also, their whole gnome starts in 3 seconds, on my edgy it takes twice the time
<yveslu> so finally the question: is feisty built with dt_gnu_hash already?
<Reefa> Howdy eeryone, Was hoping someone could shed some light on this error for me, with amd64 ubuntu 6.10 and with ubuntu i368 6.10, it loads live fine but when I actually install and reboot I get, tty can't start job control. Any ideas?
<Treenaks> Reefa: Please ask support questions on #ubuntu; this is not a support channel, but a development channel
<Reefa> Yeah no one there could help me
<Reefa> Or answer lol
<Reefa> Sure no dev might be able to lend me a minute?
<sladen> Reefa: could you file a bug report on https://launchpad.net/ubuntu/+filebug
<Reefa> Yeah
<sladen> reefa: people would love to lend you a hand, but on #ubuntu :)
<Reefa> I've been in there for 20 mins asking that question, no one there is happy to lend a hand :)
<superm1> cjwatson, are you around?
<cjwatson> superm1: kind of
<superm1> well i just had a quick suggestion/question for ubuiqity
<superm1> i wanted to see if you could add "mythtv" to the list of reserved usernames 
<superm1> that it prevents from being used
<sladen> cjwatson: which part of ubiquity selects the partitions to be passed to grub post-install?
<cjwatson> superm1: that's in user-setup; feel free to file a bug
<cjwatson> superm1: (sounds reasonable)
<sladen> (causes 'root=' to be filled out in menu.lst
<superm1> oh didn't realize which package it was part of, will do
<superm1> thanks
<cjwatson> sladen: that's done by update-grub in the grub package
<cjwatson> sladen: ... which fishes it out of /etc/fstab for itself
<sladen> cjwatson: okay thanks, I'll follow it back
<sladen> ubuntu_: /nick Reefa
<Reefa> Thanks
<RageMax> anyone know what package reconfigures fstab and menu.lst to use UUID? I didn't do the proper upgrade to edgy and those files never got switched to the new system
<stgraber> RageMax: Maybe "volumeid"
<RageMax> ok, I'll take a look at that one
<geser> RageMax: /etc/fstab was handled by volumeid
<RageMax> I at least know it's not ubuntu-base
<RageMax> I'm wondering why dist-upgrade didn't take care of that though
<geser> RageMax: and menu.lst is updated by /usr/bin/update-grub
<RageMax> geser: right, but I don't think it automatically changes to the UUID format
<geser> RageMax: I've only feisty to check but update-grub uses vol_id to do the translation from /dev/* to uuid
<RageMax> ok, I try it
<geser> RageMax: search for vol_id in the script
#ubuntu-devel 2007-02-20
<Riddell> Mithrandir: how do we go about asking for permission to upload a new upstream version these days?
<Riddell> (into main)
* Hobbsee waves
* angasule waves back
<Hobbsee> :)
<superm1> could someone point out at what point during the livecd bootup, the ubuiqity .desktop file is copied to the live cd user's desktop?  I was making a custom disk and wanted to copy something else too
<dholbach> good morning
<_ion> Hi dholbach
<dholbach> hi _ion
<ajmitch> hey dholbach 
<dholbach> hey ajmitch
<dholbach> should the NEW queue be accessible from  http://launchpad.net/ubuntu/+builds ?
<pitti> Good morning
* dholbach hugs pitti
* pitti knuddelt dholbach
<dholbach> :-)))
<cjwatson> dholbach: try /ubuntu/feisty/+queue
<dholbach> cjwatson: found it in the meantime - thanks again
<Mithrandir> Riddell: uvf exceptions> ask me, either by email or IRC (until we have the new process working)
<Nafallo> where we supposed to upload a new wtf (bsdgames) if we stumble upon an unknown acronym? :-)
<cjwatson> Nafallo: the Debian maintainer always mails the upstream author first
<cjwatson> see the address in the package; it's easy to find
<Nafallo> okidoki :-)
<ailean> is anything happening to get rid of the ugly fade outs when asked for admin password, or the ugly terminal transparency?
<Nafallo> sent :-)
<Treenaks> argh.. my screensaver is misbehaving again
<Lathiat> ailean: having real compositing on the desktop would go along way to sorting that sortof stuff out
<Lathiat> and im not talking about cubes or burning windows, or burning cubes ;)
<ailean> Lathiat, lol, i know what you mean :)
<Treenaks> did the gdm socket move _again_?
<Mithrandir> Treenaks: yes.
<Treenaks> *sigh*
<seb128> Treenaks: I've used a Breaks on packages using the socket and updated them
<Treenaks> seb128: I think I don't log out often enough :)
<seb128> Treenaks: that doesn't make real sense, the gdm socket will not change until you restart it and if you restart gdm you restart gnome-screensaver
<seb128> Treenaks: if you don't restart the app no reason for the socket to change
<Treenaks> seb128: sometimes Gnome apps just die while I'm upgrading..
<Treenaks> seb128: mostly the panel.. but maybe gnome-screensaver too
<seb128> basically you restart gnome-screensaver during your session then?
<seb128> that's a feisty upgrade problem though
<Treenaks> yeah.. I know.. I shouldn't complain :)
<seb128> I made the apps looks to /tmp/.gdm_socket first and then /var/run/gdm_socket
<seb128> so it would work fine with app restarting if you upgraded from edgy
<seb128> I just didn't add a case for the /var/run/.gdm_socket which has been used for a week only
<Treenaks> I have /var/run/.gdm_socket
<Treenaks> ah!
<seb128> what I just wrote :p
<Treenaks> seb128: ok.. I need to logout/login (and probably reboot too; new l-r-m)
<Riddell> mvo: I completed my first successful upgrade from edgy to feisty with kubuntu upgrade manager, everything works great
<doko> pitti, seb128, Mithrandir: although it's no archive day, please process the new sip4-qt3 binaries
<pitti> doko: will do in a minute
<seb128> doko: looking at it
<Riddell> doko: what's changed in that?
<seb128> ok, pitti was faster ;)
<doko> Riddell: -dbg packages, you may want to check them ...
<Riddell> pitti: I added a cleaner patch to kdelibs for the dist-upgrade SRU
<pitti> yay
<pitti> doko: while I'm at it, I can as well do the python-gnome* stuff, too
<mvo_> Riddell: rock!
<doko> pitti: please do
<Riddell> mvo_: you can ignore the e-mail I sent you about an error, fixed by changing the working directory
<Riddell> pitti: what's the current hwdb plan?
<pitti> Riddell: wrt what?
<Riddell> pitti: removing menu entry and replacing with something?
<pitti> Riddell: ah, it doesn't have a menu entry any more; instead, we now have a postinstall notification
<pitti> Riddell: see the spec
<pitti> Riddell: does adept-notifier support these notifications as well?
<Riddell> pitti: no
<pitti> Riddell: so we should either teach it to, or add a KDE .desktop file to hwdb-client-kde?
<Riddell> pitti: did you remove the KDE .desktop file?
<pitti> Riddell: I didn't remove any file, I just changed back and forth the 'NoDisplay' value
<pitti> Riddell: i. e. the net effect is zero compared to edgy
<pitti> 'k, binary NEW is empty again
<Riddell> pitti: I think adding popups to adept-notifier is sufficiently difficult it needs to be spec'ed, I'd rather keep a menu item for feisty and have popups in feisty+1
<pitti> right
<Riddell> pitti: oh, what's the use case for the Report a problem menu entry?
<ogra> Riddell, thats LPI
<ogra> malone iirc
<Riddell> Linux Professional Institute?
<cjwatson> launchpad-integration
<pitti> Riddell: it collects some info about the package and running process and files a launchpad bug
<pitti> Riddell: i. e. like source/+filebug with additional apport data love
<Riddell> pitti: it's in the k-menu, how does it know what process you care about?
<pitti> Riddell: you mean in a particular applications' menu, or the general KDE panel?
<Riddell> pitti: in the general KDE applications menu
<Riddell> on the panel
<pitti> Riddell: ah, right; this will file a general distro bug
<pitti> we weren't so sure about that one
<Riddell> where does it appear in Gnome?
<pitti> whether it would ask for a package or not (spec doesn't say so ATM), or whether to display it at all
<pitti> Riddell: similar place, 'System -> Report a bug'
<Riddell> pitti: ah, system menu makes more sense than top level apps menu, mind if I change s/Core/System/ in the KDE .desktop file?
<pitti> Riddell: of course not; can you commit it to the official bzr branch?
<pitti> Riddell: sftp://bazaar.launchpad.net/~ubuntu-core-dev/apport/ubuntu
<Riddell> yes
<doko> Mithrandir: please requeue psycopg for all archs
<Mithrandir> doko: please file a bug about it.
<doko> Mithrandir: bug reports for requeues?
<doko> Mithrandir: and assign/subscribe who?
<Mithrandir> doko: sorry, I read "remove", not requeue.
<doko> :)
<Mithrandir> doko: given-back
<Keybuk> http://rafb.net/p/PEW7W882.html
* Keybuk can't decide whether gcc is right or not, there
<Hobbsee> tepsipakki: which source package did my upload change?  do you remember off hand?
* StevenK wonders if evms in Feisty needs to be neutered.
<StevenK> I need to confirm if having the evms.conf file in the initramfs ignore hd? fixed the problem.
<tepsipakki> Hobbsee: the xserver dying thingy?
<Hobbsee> tepsipakki: yep
<tepsipakki> Hobbsee: I think it was this https://lists.ubuntu.com/archives/feisty-changes/2007-February/005133.html
<Hobbsee> bug #60288
<Ubugtu> Malone bug 60288 in xorg-server "xorg segfaults in FontFileCompleteXLFD" [Medium,In progress]  https://launchpad.net/bugs/60288
<tepsipakki> it applies to 1.2 as well, and I have included it
<Hobbsee> tepsipakki: 1.2?  that's the version you published?
<tepsipakki> yes
<Hobbsee> tepsipakki: when did that get published?
* Hobbsee had her system crash again, same symptoms
<tepsipakki> oh, it's not yet in feisty
<Hobbsee> right
<tepsipakki> do you have ati?
<Hobbsee> nope - intel 965 card.
* Hobbsee cant see anything obvious that caused that.
* Hobbsee has disabled the svnautoreleasedeb that she was trying now, though.
<tepsipakki> ok.. maybe it'll be better with 1.2
<tepsipakki> +mesa
<Keybuk> doko: ping
<Hobbsee> will see if it's reproducable - this is the first hardlock i've had since that patch was put in.
<tepsipakki> err, mesa 6.5.2
<Hobbsee> tepsipakki: yes, hopefully.
<doko> Keybuk: pong
<Hobbsee> tepsipakki: current ETA is...?
<Keybuk> doko: trying to track down whether that is a gcc bug or not
<Keybuk> don't suppose you know of any upstream pointers (heh) on it?
<doko> which one?
<Keybuk> http://rafb.net/p/PEW7W882.html
<Keybuk> I think I should be able to pass a char ** to a function that expects a const char * const *
<Keybuk> since that is only adding const to the type
<doko> hmm, no, make it a const char **a = 0 ?
<Keybuk> that would defeat the object
<Keybuk> the intent is to declare that function in such a way that it says it does not modify the array, nor the strings the array points to
<Keybuk> (just as you'd declare one with const char * and pass in char * to indicate it doesn't modify the string)
<Keybuk> I think gcc is misinterpreting the C standard which says that const <array>s and <array>s aren't equivalent
<Keybuk> but I'm only dealing with pointers there
<Keybuk> a pointer and a const pointer should be equivalent
<tepsipakki> Hobbsee: I'm now merging xorg, and if I can get it ready today all of the remaining bits can go in, provided that they are reviewed first
<Hobbsee> tepsipakki: yay :)
<tepsipakki> xorg-server can't go in before xorg since it might not work without editing xorg.conf
<tepsipakki> manually
<tepsipakki> mesa and xft could go now, I guess
<tepsipakki> but back to #ubuntu-x :)
<doko> Keybuk: hmm, I'm sure the current behaviour is intended; I'll try to track down a pointer, IIRC there was at least on discussion on gcc-help
<Keybuk> doko: the only reference I can find is for passing char ** into a function that accepts const char *[] , which is very definitely invalid :p
<doko> Keybuk: what does gcc-snapshot say?
<Keybuk> but it should be, afaik, possible to pass a char ** into a function that accepts const char * const *, since that's just adding a couple of levels of const
<cjwatson> Keybuk: I'm pretty sure I recall the C standard forbidding that
<cjwatson> I'll try to dig up the reference
<carlos> dholbach: hi, around?
<cjwatson> Keybuk: C99 6.3.2.3 says "For any qualifier q, a pointer to a non-q-qualified type may be converted to a pointer to
<cjwatson> the q-qualified version of the type; the values stored in the original and converted pointers
<cjwatson> shall compare equal.
<cjwatson> "
<cjwatson> Keybuk: which allows char ** to be converted to const char **
<Keybuk> right
<Keybuk> it also allows char ** to be converted to char * const *
<cjwatson> but I'm pretty sure you aren't allowed both levels
<cjwatson> ah
<cjwatson> ok, it allows char ** to be converted to char * const *
<cjwatson> but not to const char **
<cjwatson> it only talks about one level of indirection
<cjwatson> in fact this is a C FAQ
<Keybuk> I couldn't find it in the FAQ
<cjwatson> one sec
<cjwatson> Keybuk: http://c-faq.com/ansi/constmismatch.html
<cjwatson> gcc is correct
<Keybuk>  6.2.5.25 says Any type so far mentioned is an unqualified type.  Each unqualified type has several qualified versions of its type, corresponding to the combinations of one, two, or all three of the const, volatile and restrict qualifiers.  The qualified or qualified version of a type are distinct types that belong to the same type category and have the same representation and alignment requirements.  A derived type is not qualified by the qual
<Keybuk> ifiers (if any) of the type from which it is derived.
<Keybuk> so char ** is an unqualified pointer to pointer to char
<cjwatson> the FAQ explains why it is disallowed
<Keybuk> and char * const * would be qualified
<cjwatson> yes, and you can convert an unqualified pointer to pointer to char into a const-qualified pointer to pointer to char, but not into a pointer to const-qualified pointer to char
<Keybuk> right
<Keybuk> const char ** is a pointer to const-qualified pointer to char
<cjwatson> it's easier to understand given an example such as that in the FAQ, IMO
<Keybuk> right, but the standard only forbids that
<Keybuk> I don't see how the standard forbids const-qualified pointer to const-qualified pointer to char
<cjwatson> "(C++ has more complicated rules for assigning const-qualified pointers which let you make more kinds of assignments without incurring warnings, but still protect against inadvertent attempts to modify const values. C++ would still not allow assigning a char ** to a const char **, but it would let you get away with assigning a char ** to a const char * const *.)"
<cjwatson> I think your complaint is with the C standard, not with gcc
<Keybuk> yeah
<Keybuk> I think it's one of those situations where you have to read the standard in a "what does it say? AND WHAT DOESN'T IT SAY?" kind of way
<Keybuk>  6.3.2.3 does say they're equivalent, but doesn't say the equivalents recurses 
<Keybuk> so that implies that they don't recurse, I guess
<Keybuk> so you can only add const at the top-most level
<cjwatson> it's talking about convertibility, not equivalence
<Keybuk> err, yes
<cjwatson> and 6.3.2.3 is a complete specification of what you're allowed to convert
<cjwatson> so indeed, if it doesn't say it recurses, it doesn't :)
* Keybuk flicks forward to the rationale to see whether it mentions it
<Keybuk> (why the rationale is at the front of the book, I have no idea <g>)
<Treenaks> Keybuk: otherwise, people would stop reading it too soon ;)
<Keybuk> nope, typically not mentioned there
<Keybuk> cjwatson: thanks for the reference :p
<Keybuk> (not for the first time, I wonder why the standard permits "const void *" :p
<Keybuk> it should fail with "nonsense type")
<Keybuk> gnome-screensaver has failed locked again
* Keybuk kills it (and ogra)
<pitti> Keybuk: nooo, then he can't fix it
<seb128> Keybuk: the gdm socket changed, you might need to restart gdm if you restart gnome-screensaver
<Treenaks> seb128: I just symlinked it to the right place :)
<Treenaks> seb128: works too
<Treenaks> (as an emergency solution)
<ogra> seb128, since its /var/run which gets wiped on reboot, why not adding a symlink to the postinst ?
<seb128> ogra: symlink to what?
<ogra> its not beautiful, but would solve it
<seb128> solve what?
<ogra> .gdm_socket to gdm_socket
<seb128> <seb128> I made the apps looks to /tmp/.gdm_socket first and then /var/run/gdm_socket
<Treenaks> seb128: a symlink from the real socket location to the expected socket location
<seb128>  so it would work fine with app restarting if you upgraded from edgy
<seb128>  I just didn't add a case for the /var/run/.gdm_socket which has been used for a week only
<ogra> Keybuks problem, which might show up for more pwople
<seb128> it only happens for people who run feisty daily
<ogra> right
<seb128> and who restarted apps without restarting gdm
<ogra> but for these you could solve it with a symlink
<seb128> people running feisty can restart gdm once
<seb128> feel free to do it
<ogra> well, indeed
<seb128> I think that's a waste of effort now
<seb128> most of people probably already updated
<ogra> hopefully
<seb128> bah
<seb128> tepsipakki: pitti removed libpthread-stubs
<seb128> from the archive
<seb128> libxcb can wait for a long time on it :p
<ogra> bad pitti
<ogra> :)
<seb128> yeah, blocking xorg 7.2 :p
<Mithrandir> uh, why on earth did he do that?
<seb128> looking at why libxcb Build-Depends on it
<Mithrandir> I approved it like a week ago.
<seb128> "'(pitti) only produces empty binaries, synced from Debian/experimental, useless'"
<seb128> indeed the .deb are empty
<seb128> the ones from Debian experimental
<Mithrandir> yes, which is why it's -stubs.
<seb128> ah, the -dev has a .pc
<seb128> ok, let's sync it again
<Mithrandir> hm, can we just do that?
<seb128> can we sync a version which has already been available and removed?
<Keybuk> seb128: wouldn't it also affect people who installed Herd 4 and upgrade ?
<seb128> Keybuk: it does
<Keybuk> (this was an upgrade from Herd 4 gnome-screensaver to today's)
<Keybuk> right
<pitti> hm, I didn't find anything in those debs, and I wasn't sure where they came from
<Keybuk> so it's more serious than "just affects people running daily"
<Keybuk> so needs to be fixed
<seb128> Keybuk: if you restart gnome-screensaver without restarting gdm
<Keybuk> does gnome-screensaver's postinst restart gnome-screensaver?
<seb128> Keybuk: well, the socket doesn't change if you don't restart the app
<Keybuk> so why didn't it unlock?
<seb128> I don't think so
<Mithrandir> seb128: can you please just upload a 2build1?  I'd rather be cautious than risk breaking something fun in soyuz.
<Keybuk> I had Herd 4 installed
<Keybuk> I upgraded today
<seb128> it would unlock people dist-upgrading while they are away
<Keybuk> gnome-screensaver locked during the upgrade
<Keybuk> and then wouldn't unlock, and just stuck at "Checking..." eating 100% CPU
<seb128> Keybuk: maybe gnome-screensaver crashed or something?
<seb128> there is no reason for the socket to change if the program doesn't restart
<seb128> Mithrandir: will do
<Mithrandir> seb128: cheers.
<seb128> pitti: no problem, I'll upload a build1 one, you can review it and libxcb for main if you want to make up for it :p (new libx11 requires them)
<pitti> seb128: I still don't understand the point of empty debs?
<pitti> seb128: yes, will review :)
<ogra> Keybuk, did dbus restart during the upgrade ? 
<seb128> pitti: the package is bugged
<seb128> I'll fix it
* Keybuk checks the upgrade log
<Keybuk> gdm was restarted (if that makes any difference)
<Mithrandir> pitti: they're used on non-pthread arches of which we don't have any, but where syncing from debian > avoiding an empty package.
<pitti> Mithrandir: ah, I see
<seb128> ah, ok
<seb128> non bugged then ;)
<pitti> sorry for having screwed this up
<seb128> Keybuk: weird, then everything should look for /var/run/gdm_socket and that should work
<Keybuk> ogra: no, no dbus update
<Keybuk> seb128: it didn't
<Keybuk> I'd suggest testing this in vmware?
<seb128> Keybuk: what socket do you have in use?
<Keybuk> seb128: how do I tell?
<seb128> ls /var/run -a | grep gdm
<Keybuk> there's a /var/run/.gdm_socket
<seb128> if you restarted gdm that should be /var/run/gdm_socket
<seb128> what version of gdm is installed?
<Keybuk> gdm was upgraded from 2.17.7-0ubuntu1 to 2.17.7-0ubuntu2
<Keybuk> it was restarted by postinst with the usual "log out all sessions to take effect" message
<Keybuk> (which I haven't done yet)
<seb128> ah ok
<seb128> so it was not restarted
<Keybuk> gnome-screensaver was upgraded from 2.17.7-0ubuntu2 to 2.17.7-0ubuntu3
<seb128> and for how long is gnome-screensaver running?
<Keybuk> seb128: I can't tell
<Keybuk> oh wait, yes I can, I have the VT where I killed it from
<Keybuk> and ran ps first
<Keybuk> Feb 19
<seb128> ok, it's most likely than gnome-screensaver got restart for whatever reason
<Keybuk> so I was running 2.17.7-0ubuntu2
<Keybuk> doesn't look like it was started
<seb128> which is using /var/run/.gdm_socket
<seb128> I'll try later to install and herd4 and upgrade
<Keybuk> are you sure it's not just that the gnome-screensaver-dialog process (which gets started when you try to unlock) wasn't looking in a different place?
<pitti> Mithrandir: how do you feel about http://www.php.net/releases/5_2_1.php for feisty?
<seb128> Keybuk: hum, might be yes
<ogra> right, gnome-screensaver-dialog isnt running all the time ...
<Mithrandir> pitti: apart from it being PHP so I have to hate it? :-)  I'll review the changelog at least.
<ogra> it gets started on demand .... and the socket is hardcoded there
<pitti> Mithrandir: I feel with you, but it's chained to our testicles^W^W^W^W^Wwe support it
<pitti> Mithrandir: I have to cherrypick security patches anyway, so not updating to 5.2.1 wouldn't be much more work either; but people even ask me to put new microreleases into dapper (d'oh)
<Mithrandir> pitti: the changelog looks sane to me at least.  Mostly small changes; I'd be a bit worried about the PDO_MySQL prepared statement API bit.
<pitti> Mithrandir: right; OTOH there are probably much worse changes in 5.1.6(edgy) -> 5.2
<Mithrandir> pitti: well, we have 5.2.0 already.
<Mithrandir> (in feisty)
<Mithrandir> pitti: I say just go for it.
<pitti> ok
<pitti> Mithrandir: you mean demoting php to universe, right? :-P
<Mithrandir> pitti: that too, yes. :-)
<Mithrandir> I'm sad we can't, but we can't.
<StevenK> Mithrandir: Why not?
<pitti> StevenK: sad, but true, server folks need it
<StevenK> Pity.
* StevenK kicks uswsusp.
<StevenK> I give you -lusplash and the right headers, so why can't you find usplash_open!
<jdong> StevenK: be nicer to it.
<jdong> have you ever done anything in return for usplash?
<jdong> tell it a entertaining story.
<jdong> dance for it?
<StevenK> I don't dance for anybody. :-P
<jdong> that explains a lot...
<jdong> ;-)
<StevenK> Actually, it gets better. I drop -L/usr/local/lib, and now it tells me it can't find -lusplash
<seb128> Mithrandir: did you accept libpthread-stubs previously? i.e: can I accept it without review? ;)
<Mithrandir> seb128: yes.
<seb128> good
<seb128> doing that now
<seb128> pitti: do you want wiki MIR pages for libpthread-stubs and libxcb?
<pitti> seb128: don't bother about MIR for an empty package :)
<pitti> seb128: I'll do the source/binary review of libxcb, ok? that'll do for MIR for my part
<seb128> pitti: ok, thank you
<seb128> pitti: libxcb has been already source accepted (it was coming from Debian and looked fine)
<pitti> 'k
<seb128> binaries will be available when libpthread-stubs is available so it can build
<Riddell> dholbach: is the ubuntu logout dialogue a custom one?  and who made it?
<Lathiat> pitti: ping?
<Lathiat> pitti: i think https://launchpad.net/ubuntu/+source/avahi/+bug/83468 needs a serious look at
<Ubugtu> Malone bug 83468 in avahi "Avahi behaves badly where there is a unicast .local-domain." [Undecided,Unconfirmed]  
<Lathiat> pitti: i had problems where that was popping up once a second at an airport
<Lathiat> pitti: *10 seconds
<pitti> Lathiat: once per second? that is, you got a new dhcp lease so often?
<Lathiat> im not sure if its dhcp lease related
<Lathiat> i didnt think to check at the time
<pitti> Lathiat: it's called as a dhclient plugin
<Lathiat> ah so that would make sense
<Lathiat> can you differentiate between renewing and a new lease?
<pitti> Lathiat: not sure
<Lathiat> if its an exit hook i think you can
* Lathiat looks
<Lathiat> wheres the files?
<Lathiat> doesnt appear to be in the exit-hooks.d/ ?
<pitti> Lathiat: /etc/network/if-up.d/avahi-daemon
<Lathiat> ah
<Lathiat> wouldnt have thought those files wouldbe recalled for a lease update
<Lathiat> wee
<Lathiat> i think i found an avahi bug
<pitti> neither had I...
* Lathiat laughs
<Lathiat> Feb 20 23:22:29 lathiat-desktop avahi-daemon[5117] : Host name conflict, retrying with <lathiat-desktop-12157>
<Lathiat> i guess it's been doing that since i turned the machine on ;)
<Lathiat> so i've set my dhcp timer to 10 seconds on my gateway
* Lathiat tries
<Treenaks> "oops"
<Lathiat> heh i know why the above was happening 
<Lathiat> theres a bug atm if the reverse dns pointer already exists
<Lathiat> it just continues to conflict
<Lathiat> because the reverse dns PTR never changes on host name change
<Lathiat> it can never find a non conflicting set
<Treenaks> *cycle* *cycle*
<Lathiat> i had a conflicting host entry on my fileserver to test that bug from a few weeks back and forgot about it ;)
<Lathiat> Feb 20 23:27:50 lathiat-desktop dhclient: bound to 203.15.141.2 -- renewal in 6 seconds.
<Lathiat> woo ;)
<Lathiat> pitti: hrm, that doesnt seem to be the cause
<Lathiat> unless your ip changes everytime you got a new lease i guess
<Lathiat> i guess that coudl cause it
* Lathiat ponders how he could make that happen
<pitti> Lathiat: I wonder whether the notification actually does something good...
<Lathiat> pitti: either way perhaps some sort of rate limiting is in order and an easy way to disable the message
<Lathiat> the notification is possibly superfluos
<Lathiat> i guess its usefull to know
<Lathiat> not sure if its worth a popup
<Lathiat> could cause some confusion tho
* pitti takes a little break, bbl
<Treenaks> Lathiat: wow, that DHCP server will get _hammered_
<Lathiat> Treenaks: i just did that now as a test to see if that was the issue
* cjwatson truly realises how much better the ubiquity new-partitioner design is when adding validation takes five minuttes
<cjwatson> minutes
<Lathiat> cjwatson: heh
<dholbach> carlos: pong
<dholbach> Riddell: lmanul hacked on it
<zorglu_> q. is there a 'network person/team' for ubuntu ? i mean who decide stuff about network like "no firewall by default" or "netif lo without multicast", this kind of stuff ?
<Lathiat> pitti: i've added some comments to the bug please review when your back, cheers
<zorglu_> where should i look to get an answer to this ? (if here is not the most suitable one)
<carlos> dholbach: just wanted to know the status of gnome-power-management and totem in full screen mode
<seb128> carlos: what do you mean?
<carlos> seb128: let me look the bug #
<dholbach> carlos: from that description I dunno either
<infinity> The age-old "don't blank my screen while media players are fullscreen" thing that has no standard solution?
<carlos> https://bugs.beta.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/30969
<Ubugtu> Malone bug 30969 in gnome-power-manager "monitor goes to standby when playing a movie in totem fullscreen" [Medium,Confirmed]  
<carlos> infinity: yeah, that one
<dholbach> carlos: ogra takes care of g-p-m
<seb128> nothing to do with g-p-m probably
<carlos> oh, I saw comments from you and thought you were caring of that bug
<infinity> You need to get totem, g-p-m, g-s-s, mplayer, blah blah blah to all talk to each other in a sane way.
<carlos> seb128: any suggestion about how to help debugging it?
<infinity> daniels and I once specced this using root window hints, but while it got coded on someone's laptop hard drive, it never really went anywhere.
<seb128> carlos: nop
<carlos> infinity: well, I guess GNOME modules should work by default
<infinity> Neat theory. :)
<carlos> I mean, totem is integrated with GNOME
<seb128> totem does send a dbus signel to inhibit the screensaver
<seb128> signal
<carlos> and I know it's using DBUS to disable setting the screen off (or it's supposed to)
<carlos> seb128: yeah
<seb128> not sure of what trigger the screen power saving though
<carlos> seb128: maybe a bad x.org configuration?
<seb128> no idea
<seb128> I've no clue about xdpm
<carlos> I just killed gnome-power-manager and it still happens
<seb128> dpms I mean
<carlos> so I guess it's not directly related with it
<seb128> not a surprise
<infinity> Could still be.
<infinity> DPMS timeouts are handled by the Xserver, no?  g-p-m just adjusts the delay according to user prefs.
<infinity> So, if you kill it, the setting just never changes.
<bddebian> Heya
<carlos> infinity: I see
<iwj> I think I might make a wrapper script called `vcs' which looks to see what metadata your cwd has and runs the right one ...
<Mithrandir> it'd still break when you have stuff which is stored in multiple RCS-es.
<Mithrandir> or am I the only person insane enough to do that? :-)
<kylem> ... why?
<cjwatson> I've done it in the past
<Riddell> pitti: doing the adept apport stuff, it seems to need a delay of a second or so after the crash before running apport else apport doesn't process the files, did you have anything similar on the update-notifier side?
<Mithrandir> kylem: useful way of doing CVS + SVN before I wrote my CVS-to-SVN committer.
<cjwatson> kylem: nCipher had a CVS repository of handy stuff for your ~/.vim. I had my own SVN repository for ~, including .vim. I solved this by having ~/.vim/CVS and ~/.vim/.svn and cross-committing where necessary.
<Mithrandir> kylem: and the reason I wanted both SVN and CVS is CVS exists on so many more systems.
<cjwatson> iwj: it's only for commit, but debcommit is very useful for that
<cjwatson> (in devscripts)
<kylem> cjwatson, yow.
* kylem just had everything in cvs.
<cjwatson> It's lucky I didn't. I couldn't have had two overlapping CVS checkouts like that nearly so easily.
<iwj> cjwatson: Right, but then `vcs' would say "err, this is too confusing for me" and bail out.  So you'd have to say what you actually wanted in that case.  No great loss I think :-).
* iwj RTFMs debcommit(1)
<iwj> Wow, that sounds quite useful.
<iwj> Thanks.
<iwj> It's almost certainly cleverer than the shoddy thing I have for doing the same job.
<Keybuk> cjwatson: isn't that the standard way of doing it? :p
<iwj> Aargh, I hate python.  I've just spent 10 mins debugging something where I wrote    '\n'.split(output)
* iceman is away: AwaY
<pitti> Riddell: well, apport needs some time to write out the report
<pitti> Riddell: but we don't have any explicit delays
<Riddell> pitti: ok, putting a sleep 1 before running apport fixes it fine
<pitti> Riddell: however, it'll take a while between 'inotify reports action in /var/crash' and 'call apport-checkreports
<pitti> Riddell: I think u-n checks every 10 seconds or so
<iwj> Yay!  It's using the right version finally.
<iwj> dsc1t-mawktest       FAIL status: 1, stderr: /root/adt-downtmp/mawktest: 24: mawk: no...
<iwj> Not only can report test passes, but it failures too.
<tkamppeter> pitti, ping
<pitti> hi tkamppeter 
<jdong> pitti: thanks for quick resolution of the hal mtab bug :)
<pitti> jdong: you're welcome :)
<jdong> now, pitti how do you feel about the unmount notify popups? :)
<pitti> jdong: I'm not sure TBH
<jdong> would you agree that it should always display that it's safe to remove the media?
<pitti> I think the computer shuold only warn about unsafe things, not things that are safe
<jdong> well, important things that are safe should be confirmed.
<tkamppeter> pitti, it seems that the upload server is somehow hanging. The HPLIP which you have uploaded today in the morning did not arrive yet.
<jdong> especially since in a slightly different context it could be unsafe...
<kwwii> dholbach: so, did I mess something up somehow without knowing?
<jdong> i.e. icon changes/disappears before data is flushed anyway
<jdong> if that wasn't the case, I'd agree with you.
<mvo_> iwj: from reading bug #84906 it looks like we need a SRU for the dapper vim package? 
<Ubugtu> Malone bug 84906 in vim "vim-tiny postinst fails" [Medium,Confirmed]  https://launchpad.net/bugs/84906
<dholbach> kwwii: seems the .desktop file is missing
<dholbach> kwwii: HumanCircle has one, Human does not
<dholbach> kwwii: or it's not installed
<jdong> and pitti , while unmounting an iPod with near no dirty data, it still takes a bit of time for the disk to spin up....
<Goliath23> hi
<dholbach> kwwii: i can take a look too
<pitti> jdong: hmmkay
<dholbach> kwwii: ok, might have been my fault I'll check later
<Goliath23> how do I get a hand on the ubuntu source repository? https://code.launchpad.net/ doesnt help much.. I need the file usplash-testcard-theme.c
<Goliath23> its supposed to be an example for a minimal bootsplash theme
<Goliath23> do I have to have an account to be able to read the repository?
<jdong> no, you need bzr
<kwwii> dholbach: I found it...it was removed from the makefile
<kwwii> dholbach: I'll add that to the makefile, and update some picks soon
* dholbach hugs kwwii
<Goliath23> jdong: is there a webfrontend like websvn.kde.org?
<jdong> Goliath23: not yet...
<jdong> sorry :)
<Goliath23> kk, i'll install bazaar. could you point me to an url, where I can find usplash-testcard-theme.c
<Goliath23> ?
<Riddell> Goliath23: you can also just do apt-get source usplash
<Goliath23> oh okay. thanks
<Keybuk> ooh... the spanish grand prix is the weekend immediately after UDS ...
<Keybuk> just up the coast ...
<Keybuk> (pretty boring track though)
<Goliath23> Riddell: usplash seems to be version .4 while usplash-theme-ubuntu seems to be 0.6, also the makefiles differ much. which one should I use to create a simple custon usplash?
<pochu> Keybuk: spanish grand prix?
<pochu> Keybuk: formula 1? :)
<iwj> mvo_: No, I don't think so.  That is, we can fix it up later rather than doing an SRU and that seems preferable.
<Keybuk> pochu: yes
<doko> seb128, pitti: please could you look again for -dbg packages in NEW
<Riddell> Goliath23: usplash-theme-ubuntu
<iwj> fix it up later> As in, just retain the workaround I uploaded today.
<iwj> (Speaking of which I discover I failed to save debian/control before uploading :-/)
<Goliath23> Riddell: do I have to recreate all the different images in all sizes or can I just modify the c-file so some are missing?
<mvo_> iwj: ok, so its enough to have the feisty version fixed?
<pitti> tkamppeter: which version was that?
<iwj> mvo_: Yes, if we retain the fix until the next LTS.
<iwj> The `fix' is just to create those directories and eventually to merge from Debian.
<mvo_> iwj: ok, cool. and you will do the upload for vim? or should I do that?
<iwj> As in that ought to make the symptoms go away and the real bug is fixed there.
<iwj> I already have, see ^
<mvo_> cool, thanks!
<seb128> doko: looking now if nobody else did
<Riddell> pitti: http://kubuntu.org/~jriddell/tmp/apport.png
<pitti> Riddell: sexy! :)
<pitti> Riddell: do you check for both user and system crashes?
<Riddell> pitti: yes, it runs it with kdesu if there has been a system crash
<pitti> cool
<Keybuk> yay for not using the phrase "terminated unexpectedly"
<seb128> doko: binary NEW mostly cleaned
<seb128> pitti: libpthread-stubs binaries available for review
<pitti> seb128: ah, will have a look
<seb128> thank you
<pitti> seb128: look fine, I put them into main
<seb128> pitti: thank you
<pitti> seb128: I'll NEW the python goo as well while I'm at it
<seb128> pitti: ok, I did most of binary NEW a few min ago so there should not be much left
<pitti> seb128: did you already new ps3pf-utils? there's a single ppc build in the queue
<seb128> no
<pitti> ok, I'll wait then
<seb128> just the python dbg uploads from doko
<pitti> these are done again
<pitti> ah, php finished building, so back to that ;)
<tkamppeter> pitti, there was a short network failure, so again, package is hplip_1.7.1-1ubuntu2
<pitti> tkamppeter: ah, you built the changes with -sa, i. e. with an orig.tar.gz
* pitti fixes and reuploads
<doko> seb128, pitti: there always new dbg uploads ;)
<seb128> doko: looking
<doko> seb128: no, just joking
<seb128> doko: ah :p
<doko> seb128: the last one was vte/python-vte
<Keybuk> http://tango.freedesktop.org/Window_Experiments
<Keybuk> ^ that's rather nice
<_ion> Quite nice indeed, as long as the document title, the program name and the menu bar take no more than two lines.
<_ion> "Large, click-able/drag-able document icon that can be dragged to the trash to delete, dragged to the desktop and other locations to save, etc." Doesn't MacOSX do that (although with a small icon)?
<Keybuk> Risc OS used to do that
<Ng> why do you need to waste a whole line that tells you it's a text editor? I can see that, there's text in it :(
<Keybuk> there wasn't an open or save dialog, you dragged the icon somewhere
<Keybuk> Ng: I guess "Text Editor" vs. "IDE" vs. anything else
<Keybuk> we had that argument a while back when we wanted to call "Firefox" just "Web Browser" ;)
<Ng> I'm turning off more and more window borders as time passes, I'd just rather have the useful space
<_ion> ng: I only have a title bar, the other borders are zero pixels thick.
<Ng> that's the way to do it, but I appreciate that I'm an atypical use case ;)
<Treenaks> macos does have that option that in the title bar
<_ion> With soft shadows, windows are perfectly distinguishable from each other without borders.
<Riddell> pitti: do python programmes need anything special for apport to pick up crashes?
<pitti> Riddell: no, it just works
<tkamppeter> pitti, thanks.
<pitti> Riddell: just try adding a 'raise Exception' in /usr/bin/bzr or so
<Riddell> pitti: that works, but it doesn't work if I do raise exception on just a local file
<tkamppeter> pitti, it seems that in a short time CUPS 1.2.9 will come out, fixing bug 85339 and bug 57050, so we should perhpas put this up with UVF exception request, instead of 1.2.8.
<Ubugtu> Malone bug 85339 in cupsys "CUPS test page does not look very good at A0" [Low,Needs info]  https://launchpad.net/bugs/85339
<Ubugtu> Malone bug 57050 in cupsys "Brother HL-1430 USB printer will only print once" [Low,Confirmed]  https://launchpad.net/bugs/57050
<slomo> Mithrandir: could you please take a look at #85454? :) the compiler bugfixes are something i would prefer to have asap ;)
<pitti> Riddell: right, it's not supposed to; we only catch exceptions for packaged software
<Riddell> pitti: clever
<mdz> BenC: I received a request from a community member on bug 78634 for more information; is that what's needed or are they confused?
<Ubugtu> Malone bug 78634 in linux-source-2.6.20 "usbdev4.1_ep00: PM: suspend 0->1, parent usb4 already 2" [Undecided,Unconfirmed]  https://launchpad.net/bugs/78634
<BenC> mdz: Checking...
<BenC> mdz: Nope, it just needs to be fixed...I'll set the status
<BenC> mdz: Most likely it's a driver, and the new code is just doing sanity checks that weren't there before
<seb128> cjwatson, Mithrandir: do you know what happened to the libpthread-stubs binaries? pitti accepted them one hour ago and they are no to the archive
<pitti> seb128: they are in drescher's archive
<seb128> pitti: where?
<pitti> seb128: drescher:~/ubuntu/pool/main/libp/libpthread-stubs
<pitti> libpthread-stubs0 | 0.1-1build1 |        feisty | amd64, i386, ia64, powerpc, sparc
<seb128> ah ok
<pitti> seb128: so it's just the mirroring that lags
<seb128> ok, good
* iceman is back (gone 02:34:14)
<_ion> Thanks a lot for the information!
<victory747> I'm having a really strange problem with disappearing text in gnome terminal in feisty.  Has anyone seen anything like this?
<Treenaks> victory747: no disappearing text here
<Treenaks> but they do blink white every now and then
<Treenaks> or flash once actually
<Treenaks> but only during upgrades
<victory747> well, i have whole lines that disappear, and then re-appear when highlighted or sometimes when the mouse is over them
<jdong> victory747: I've seen xchat do that :)
<victory747> almost like it's a refresh problem
<jdong> victory747: using a 3D compositing WM or anything?
<victory747> no, nothing strange
<victory747> it's pretty much a stock feisty install from about a week ago (with upgrades)
<jdong> hmm
<jdong> I can't confirm that :(
<victory747> I AM using my home directory from my edgy install, so there may be some strange stuff left over.
<victory747> let me try a new user profile and see if i see anything
<victory747> hmm, switch user doesn'twork
<victory747> i remember now that when i woke up from suspend it would not log back in, so i killed the screensaver process
<victory747> maybe that's why.  anyway, the gnome terminal thing has been doing that since i installed.
<pochu> heno: ping?
<heno> pochu: hi
<pochu> heno: hi :)
<pochu> heno: I'm building listen, but it has a warning:
<pochu> Gtk-Message: Failed to load module "gail": libgail.so: cannot open shared object file: No such file or directory
<pochu> Gtk-Message: Failed to load module "atk-bridge": libatk-bridge.so: cannot open shared object file: No such file or directory
<pochu> heno: those are accesibility libraries, I think
<pochu> heno: should I build against them?
<pochu> since they are just warning, I can ignore them :)
<heno> pochu: have you installed the relevant -dev packages and sources?
<pochu> heno: no, I haven't. Should I add them to the build-deps?
<heno> pochu: I'm not the best person to ask though; I don't build these things :)
<pochu> :)
<pochu> ok, ty anyway ;)
<heno> pochu: some people in #ubuntu-accessibility will know, such as TheMuso and chrisj
<pochu> heno: there :)
<jdong> urgh since a dist-upgrade today X suddenly became very sluggish?
<Mithrandir> slomo: approved
<slomo> Mithrandir: thanks, uploaded :)
<givr1> Mithrandir, or any archive manager around : can you reject ntfs-config from NEW, i have a new version in REVU waiting for an ack. Thanks
<macd> would a dapper to edgy upgrade remove scsi emulation from a pata dvdr?
#ubuntu-devel 2007-02-21
<Strom_C> hey guys, sorry if this is the wrong channel, but I've been asking this question in #ubuntu all day and gotten no help:  What is the exact procedure that ubuntu uses to auto-determine video settings when starting the livecd, and is it possible to invoke that procedure post-install?  I'm trying to create a partition image which is fairly portable across machines.
<Strom_C> I guess it's happy hour at the bar :)
<jdong> or everyone is asleep :)
<Strom_C> for some reason, I ddidn't expect all 172 people in here to be in russia
<bddebian> Or doesn't know the answer ;-)
<Strom_C> i'm surprised that no one knows the answer to this one
<ScottK> Strom_C: Your best bet is to look at the source.  I don't know either.
<Strom_C> ScottK: I've been grepping and googling and trying things for eighteen hours now
<ScottK> Sorry I can't help.
<Strom_C> thanks anyway :)
* Strom_C continues to rip hair out
<ScottK> Strom_C: The good news is that can only go on so long.
<Strom_C> well, at least until you add minoxidil into the equation :D
<jdong> Strom_C: sudo dpkg-reconfigure -pcritical xserver-xorg
<jdong> Strom_C: you can adjust critical to low, medium, or high, each setting asking fewer questions than before
<Strom_C> jdong: I have tried two dozen variants of dpkg-reconfigure and NONE of them produce the same results as the livecd's automatic process
<jdong> low probably is the version used by the dept. homeland security when they confiscate your laptop....
<jdong> Strom_C: that is exactly what the livecd runs. It sometimes helps to move your old xorg.conf out of the way
<Strom_C> having dpkg-reconfigure ask any questions is unacceptable for this application
<jdong> -pcritical is what the livecd uses.
<Strom_C> alright, let me give this one another go
<jdong> Strom_C: if you're reasonably fluent in reading bash scripts, grab the source of 'casper'
<jdong> and look at /scripts/casper-bottom
<Strom_C> nope, xorg won't start
<jdong> 20xconfig mainly
<Strom_C> jdong: I looked at that one already, actually
<Strom_C> but my bash script fluency isn't all that good
<Strom_C> if dpkg-reconfigure -pcritical xserver-xorg is what the livecd runs, then why are the results different when run from an installed system with X not running?
<jdong> "casper-reconfigure /root xserver-xorg"
<jdong> yeah it simply calls reconfigure xserver-xorg
<jdong> with a noninteractive debconf
<Strom_C> yeah, i've tried -fnoninteractive too
<jdong> have you tried comparing the xorg.conf the livecd generates
<jdong> vs this command's?
<Strom_C> yep
<jdong> it should be identical
<Strom_C> they're completely different
<jdong> runcommandinroot "$root" dpkg-reconfigure -fnoninteractive --no-reload "$package"
<jdong> that's what casper-reconfigure reduces to
<jdong> so -fnoninteractive --no-reload
<Strom_C> nope, still different from what the livecd generates
<Strom_C> fwiw, the livecd actually detects my video hardware and monitor, whereas all flavors of dpkg-reconfigure give me VESA and a generic monitor
<jdong> hmm weird
<Strom_C> yeah
<jdong> is this a stock installed system? or have you changed/added/removed packages
<jdong> or activated some different configuraiton?
<Strom_C> the only things I've done have been to throw a few tarballs in /usr/src, install a few dependencies, and add the "universe" repository to apt-get.
<jdong> hmm that shouldn't affect things
<Strom_C> yeah, this is close enough to default that it shouldn't matter
<jdong> all the times I've tried -pcritical generates an identical X config to xorg.conf
<Strom_C> well, i'm trying the same image in two environments: a boring low-end Dell machine and a VM in "Parallels Desktop" on os x
<Strom_C> the reconfigure works fine in the VM, but not on the Dell, though I suspect that the VM's virtual hardware is fairly genericized for compatibility
<jdong> then there's someting weird going on with that dell....
<jdong> all my systems reconfigure correctly
<Strom_C> yeah, but the thing is that the livecd configures it perfectly
<jdong> that's definitely weird
<Strom_C> and if I'm going to take this image to various training centers to use as the lab environment for a technical training course, I kind of want it to work reasonably well in as-yet-unknown environments :)
<Strom_C> i wonder if the livecd loads some other environment settings
<Strom_C> this is supremely irritating
<jdong> Strom_C: you'd want to find a time when cjwatson is around....
<jdong> probably like 12h from now
<Strom_C> alright....cool
<Strom_C> thanks for your help :)
<jdong> np
<pitti> Good morning
<LaserJock> pitti: good morning
<LaserJock> pitti: I don't suppose you'd have time to look at qcad and qalculate MIRs?
<LaserJock> :-)
<pitti> LaserJock: ah, can do today after finishing php
<pitti> LaserJock: please just keep poking me  :)
<pitti> LaserJock: hmm, I actually remember looking at qalculate
<LaserJock> pitti: oh?
<pitti> LaserJock: Dependencies: most not yet in main
<pitti> LaserJock: ^ these need to be listed and get MIRs filed/approved
<pitti> LaserJock: from a three-second inspection, qcad report looks fine, will process it soon
<LaserJock> pitti: oh sorry about qalculate, I thought I had fixed that, oops
<LaserJock> qalculate need cln, libgd, and gnuplot
<pitti> LaserJock: libgd? literally? we made great efforts to throw this out and only keep libgd2
<LaserJock> pitti: I'll have to dig a bit deeper but I think it's actually libgd2
<LaserJock> which is already in Main
<LaserJock> I'll have to double check that
<pitti> gd2 is fine
<viviersf> soz to bother, but whos in charge of building the -desktop cds ?
<dholbach> good morning
<pitti> hey dholbach 
<pitti> asac: here?
<dholbach> hey pitti
* dholbach hugs pitti
* dholbach hugs asac too
<Mithrandir> viviersf: I tend to do it, why?
<viviersf> im trying to see how brand spanking new isos get generated
<mneptok> magical pixies that live under Mithrandir's floorboards.
<Mithrandir> actually, they live underneath the floor in the DC, not in my house.
<infinity> They're not that magical either.
<LaserJock> just ordinary pixies?
<Mithrandir> viviersf: roughly: debootstrap ; apt-get install $packages ; mksquashfs ; mkisofs 
<mdke> is bug 76632 actually fixed? I still can't unlock my screensaver... anyone seeing that?
<Ubugtu> Malone bug 76632 in gnome-screensaver "screen does not unlock after locking" [High,Fix released]  https://launchpad.net/bugs/76632
<Strom_M> Mithrandir, if one does those steps, will packages you apt-get install be automagically installed while the installer runs?
<Strom_M> or is there more scripting jiggerypokery one needs to do
<Mithrandir> Strom_M: ubiquity just copies the file system off the CD.
<Strom_M> awesome
<Mithrandir> you want to make sure all the bits ubiquity expects to be there are there though.
<Strom_M> right; i was just planning on supplementing the basic install
<viviersf> Mithrandir, you got a script that does all that by any change, i can do it that way, just what does all the default configs of pam etc ?
<Mithrandir> viviersf: yes, we have such a script, no, we are not giving it out, sorry.  There's a customisation howto on the wiki.
<seb128> Mithrandir: is there a way to look from drescher what happened to some binary packages? libgoocanvas1 (binary NEW) is available for 4 archs, according to launchpad it built on sparc yesterday evening but the binary is not to the queue
<viviersf> Mithrandir, thx btw
<Mithrandir> seb128: it probably got lost in failed-to-move; try rerunning ~lp_buildd/reprocess-failed-to-move (as lp_buildd)
<seb128> ok, thank you
<Strom_C> stupid question: does the install cd customization process apply only to the server cd, or can I customize the desktop livecd using the same procedure?
<Strom_C>  the instructions are a touch ambiguous on that one
<seb128> Mithrandir: that solved it, thanks
<LaserJock> pitti: do you have any script to check if a packages deps are not in Main
<seb128> pitti: could you review libxcb today (binaries are to NEW atm) for main promotion? it's part of the xorg 7.2 stack and blocks libx11 update
<viviersf> hmmmk Mithrandir 
<Mithrandir> Strom_C: there are two sets of instructions.  You want the one which concerns itself with live cds.
<Strom_C> Mithrandir: ah ok, I didn't see that one - looks much easier than the other set of instructions :)
<Strom_C> thanks
<slomo> pitti: hi :) can you take a look at the ndesk-dbus and ndesk-dbus-glib main inclusion reports? should be fairly fast to review and we have the code itself in main already anyway (in other packages) ;)
<pitti> LaserJock: no, I don't
<pitti> seb128: can do right now
<pitti> slomo: right, I remember; will do
<seb128> pitti: danke
<LaserJock> pitti: ok, np. I've got a script but it doesn't handle |'s very well
<pitti> seb128: fun; libxcb already was in warty and hoary - welcome back :)
<seb128> ;)
<mneptok> has there been any talk about making apps like Azureus and Frost/Limewire depend on sun-java*-jre in the future?
* mneptok stares at doko 
<doko> mneptok: why? to move it to multiverse?
<mneptok> doko: because Java apps depending on GCJ are breaking all over the place.
<mneptok> AFAIK, the GCJ dependency was only because GCJ is free.
<pitti> seb128: wow, designed to replace Xlib? I guess 25 years of API stability are enough :-P
<doko> mneptok: please file bug reports
<seb128> pitti: ;)
<cjwatson> pitti: it doesn't break API or ABI
<seb128> pitti: there is a new libx11-xcb with it
<pitti> cjwatson: ah, it's the same API, just a reimplementation for thread safety and other goodies?
<seb128> pitti: well, new libx11 has the standard libx11-6 and a new libx11-xcb
<Mithrandir> pitti: it's also so toolkits can use raw X11 instead of Xlib and thereby get better performance.
<cjwatson> http://en.wikipedia.org/wiki/XCB links to some papers
<pitti> right, the package description is pretty interesting
<doko> mneptok: and you may want to check out deb http://people.ubuntu.com/~doko/ubuntu/ feisty/$(ARCH)/
<doko> deb http://people.ubuntu.com/~doko/ubuntu/ feisty/all/
<cjwatson> http://www.usenix.org/events/usenix04/tech/freenix/full_papers/sharp/sharp_html/index.html was the one I read a while back
<Mithrandir> doko: zope 3.3.1 looks good; approved.
<doko> Mithrandir, cjwatson: who should get the approval emails in the future?
<Mithrandir> doko: I, until I get ubuntu-release@lists set up, then it should go there.
<Mithrandir> I'm considering if we should move towards the same model used for SRUs and such though.
<doko> Mithrandir: ok, mdz did forward you another one for sqlite3
<Mithrandir> doko: yes, I'm looking at it right now
<slomo> pitti: thanks :)
<pitti> seb128: libxcb promoted to main and NEWed
* seb128 hugs pitti, thank you
<slomo> pitti: yay, xcb :)
<pitti> slomo: right, I saw some new build deps on ndesk on -changes
<pitti> slomo: so libdbus-1-cil is obsolete?
<pitti> slomo: and/or dbus-sharp in general?
<Mithrandir> doko: sqlite approved.
<slomo> pitti: it is since ~1 year already... there just was no better alternative until today ;) dbus-sharp can go to universe and the last rdep is already ported to ndesk-dbus upstream, i'm only waiting for a release
<pitti> slomo: ah, great; would be nice to demote it for feisty
<givre> seb128: could you please reject ntfs-config from NEW, i have a new version waiting in REVU
* pitti does a checkrdepends
<seb128> givre: no need to reject it, just upload the new version and it'll be superseded
<pitti> slomo: in fact, nothing in main depends on it
<slomo> pitti: it's already on the anastacia demotion list
<slomo> pitti: yes, the only rdep is in universe (gshare)
<pitti> slomo: right, will kick it right now
<givre> seb128: ok, bddebian wasn't sure. thanks
<Mithrandir> Riddell: where can I find the KDE release schedule?
<seb128> slomo: BTW the gnome-user-share change you did for Debian is not good for Ubuntu?
<pitti> slomo: there it goes :)
<seb128> slomo: the apache config one
<slomo> seb128: it is, we need it... i'll file all remaining sync requests today, that's the next point on my todo list :)
<seb128> slomo: ok
<seb128> I was surprised that you didn't ask for a sync nor uploaded to Ubuntu
<pitti> slomo: btw, would you mind improving the package description a bit? "ndesk-dbus is a C# implementation of D-Bus." sounds like reimplementing dbus-daemon, when it is in fact reimplementing the client library
<pitti> slomo: when I read that the first time I thought "d'oh, just what the world needs..."
<Mithrandir> Riddell: never mind; I found it.
<slomo> pitti: well, until now its only a client implementation... but a daemon is planned too ;) although i doubt someone will really use it as default
<slomo> pitti: i'll change the description with the next upload
<pitti> slomo: thanks
<pitti> slomo: I want a dbus daemon written entirely in posix shell
<Mithrandir> pitti: no, you don't.
<pitti> Mithrandir: sorry, working on php for too long causes irreversible brain damage
<slomo> pitti: oh... go for it, should be interesting :)
<Mithrandir> pitti: so you clearly want a dbusd written in php?
* Mithrandir hides from pitti's wrath.
<pitti> uuarrrgh
<Treenaks> Mithrandir: ooh! great idea! I'll start writing immediately
<slomo> pitti: btw, apport still complains about crashing mono in feisty :/
<pitti> slomo: can you give me a test case? kill -SEGV'ing f-spot or tomboy didn't work
<slomo> pitti: not really, but i saw bugreports from crashing beagle...
* ajmitch saw one from f-spot earlier today
<slomo> seb128: hm, seems to be the only important thing i didn't sync/upload yet
<seb128> ok, good ;)
<seb128> slomo: I can sync it now if you want
<slomo> seb128: btw, will you update gstreamer core and plugins-base to a new cvs snapshot soon? or wait until the releases?
<seb128> slomo: I was going to ping Mithrandir about that today
<seb128> let's do that now
<slomo> seb128: would be nice, sync request is bug #86663
<Ubugtu> Malone bug 86663 in gnome-user-share "Please sync gnome-user-share 0.10-4 from debian/unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/86663
<seb128> re
<seb128> Mithrandir: did you read what I was writting before the split?
<Mithrandir> seb128: the gnome-user-share one doesn't require UVF exception.
<Mithrandir> seb128: what's new and shiny in the new gstreamer bits?
<seb128> what did you read before the split?
<seb128> let's copy again
<seb128> <seb128> Mithrandir: gstreamer upstream did some changes for easy codec installation (basically they moved libgimme-codec to gst-plugins-base0.10), the new totem tarball has its code updated for that change
<seb128>  mitsuhiko Mithrandir
<seb128>  Mithrandir: new gst tarballs are coming next week, would it be ok to update the CVS snapshots we have today and update to new versions next week?
<seb128> well
<seb128> lot of bug fixes, probably some new feature
<seb128> what I'm interested in is the EasyCodecInstall bits
<Mithrandir> hm, that's interesting, yes.
<Mithrandir> ok, go for it.
<seb128> thank you
<seb128> and we have a CVS snapshot atm already so it's probably a good idea to upgrade to next tarball anyway
<slomo> Mithrandir: can you also take a look at the dbus-glib (#84932) and liferea (#86596) uvf exceptions? both are mostly bugfix releases
<seb128> doko: could you get an UVF exception for bug #84820
<Ubugtu> Malone bug 84820 in Ubuntu "sync request" [Undecided,Unconfirmed]  https://launchpad.net/bugs/84820
<seb128> fastjar sync request
<Mithrandir> slomo: both approved.
<slomo> Mithrandir: thanks :)
<seb128> dholbach, slomo: if MOTU UVF is still assigned to a bug does it mean it's not ready to be processed yet?
<seb128> https://bugs.beta.launchpad.net/ubuntu/+source/kphotoalbum/+bug/85103
<Ubugtu> Malone bug 85103 in kphotoalbum "please sync kphotoalbum [universe]  from Debian experimental [main] " [Undecided,Confirmed]  
<doko> seb128: hmm, I'll close the report, it's not necessary
<seb128> doko: ok, thank you
<slomo> seb128: no that's fine... if the bug is set to confirmed it's approved
<seb128> ok
<sabdfl> seb128: had the same screensaver login issue again yesterday, is that fixed now?
<seb128> sabdfl: yes, we changed the location to /var/run/gdm_socket and it'll stay there now and I've updated the package using it to check the edgy and the feisty sockets so it should not break edgy upgrades
<sabdfl> cool - thanks seb128
<seb128> np
<doko> do we have any meta package for beryl, or just close beryl bug reports?
<Mithrandir> we don't have beryl in the archive.
<pitti> beryl-manager - Tray application launcher tool for Beryl
<pitti> but nothing else
<pitti> (and because of that it's uninstallable)
<Mithrandir> given that the rest of it wasn't distributable, I rejected it and nobody's uploaded a new version.
<StevenK> Beryl isn't distrubutable? Neat.
<pitti> StevenK: no, it killed the eyes of too many people, thus falls under the WMD category (Windows of Mass Distraction)
<StevenK> Hah
<Mithrandir> it includes compiled files without sources.
<StevenK> Neat.
<sabdfl> pitti: it may yet emerge as the stronger system, ui wise
<Mithrandir> oh, and some of the files there doesn't have a free compiler either, so they'd have to go to multiverse.
<pitti> sabdfl: I agree; at least I noticed that compiz sucks hard ATM
<Lathiat> what the hell does beryl needs thats compiled and/or non-free?
<seb128> doko: I reject beryl bugs saying to people to send the bug to the people making the package they are using
<Mithrandir> Lathiat: opengl shaders.
<Lathiat> ah hrm
<sabdfl> we should get this stuff cleaned up and into ubuntu
<sabdfl> so the conversation happens here, not somewhere else
<Mithrandir> as well as having C files with 4k x 4k pixmaps in them where I doubt that is the preferred form of modification.
<Lathiat> beryl-1.dfsg1 anyone :)
<seb128> there is a mail about compiz,beryl on http://lists.freedesktop.org/archives/compiz/2007-February
<pitti> Mithrandir: it's not an .xpm?
<Mithrandir> pitti: no.  OpenGL doesn't use XPMs.
<seb128> pitti: beryl sucks as much as compiz
<seb128> pitti: they basically have the same core, beryl has extra workarounds, configuration dialogs, plugins and things like that
<pitti> seb128: metacity FTW! :-p
<seb128> pitti: yeah, for me as well ;)
<mneptok> in related news, both of my cats are now working on competing compositors for X.
<mneptok> you know, just to be au courant.
<pitti> argh, mneptok is in his best mood again today :)
* mneptok smooches pitti 
* pitti crawls mneptok's neck
<mneptok> let me know if you find an X compositing layer back there.
<pitti> mneptok: no, just little fur balls, but that's close enough
<mneptok> do they wobble?
<mneptok> and why is my GPU not melting?
* elkbuntu blinks. i thought i was in -offtopic for a second there...
<Mithrandir> mneptok: because compositing is not very much work for GPUs.
<pitti> except, of course, if you have a two years old laptop :-(
<Mithrandir> my x40 is more than two years old and runs compiz at least just fine.
<pitti> well, my radeon 9200 runs tuxracer just fine, but cube rotation and window moving/resizing really sucks with compiz
<pitti> (with the free driver anyway; not that I have much choice on powerpc)
<jdub> localhost kernel: [963670.820000]  EIP: [<f092ab96>]  ext3_clear_inode+0x26/0xa0 [ext3]  SS:ESP 0068:effafeb4
<doko> pitti: what is calling /usr/share/apport/apport-gtk ?
<doko> pitti: what is calling /usr/share/apport/apport-gtk ?
<doko> pitti do you see bug 73104 for feisty as well?
<Ubugtu> Malone bug 73104 in apport "apport causes Python interpreter to segfault" [Medium,Confirmed]  https://launchpad.net/bugs/73104
<pitti> doko: python segfault> no, I never saw it
<pitti> doko: calling a-gtk> update-notifier
<Mithrandir> dholbach: can I use bughelper with a product and not just packages?
<dholbach> Mithrandir: yes.... -U to use "upstream bugs" too
<Mithrandir> how do I get it to just look at a product?
<dholbach> not implemented yet - if you file a bug, I'll look into it
<seb128> Mithrandir: UVF exception for rhythmbox? We have 0.9.7.90 which is 0.9.8 pre version and they rolled 0.9.8 now
<Mithrandir> seb128: anything which should scare me there?
<seb128> no, that's mostly bug fixing since 0.9.7.90 which is ~2 weeks old
<Mithrandir> go ahead, then
<seb128> thank you
<gpocentek> pitti: is there a way to avoid changing the maintainer with the new dpkg-source?
<pitti> gpocentek: the dpkg-source change is to enforce you not to avoid it :)
<pitti> gpocentek: however, someone posted a script on u-devel-discuss to do it automatically
<gpocentek> ok
<shawarma> seb128: Will you get around to accepting network-manager-{openvpn,vpnc} today? Universe FF is getting dangerously close. :-)
<seb128> shawarma: I though that Mithrandir was on them, will do if he doesn't
<Mithrandir> seb128: they should be easy enough, so please just grab them.
<shawarma> seb128: Ah, I thought he took off his archive admin hat monday evening.
<seb128> Mithrandir: ok
<seb128> shawarma: well, that doesn't prevent to have a look on package you are interested in ;)
<tepsipakki> shawarma: the release-manager hat is firmly in place ;)
<shawarma> tepsipakki: True. :-)
<pitti> Mithrandir: speaking of RM hat, cups 1.2.8 looks pretty sane: http://www.cups.org/articles.php?L443
<ajmitch> Mithrandir: oh, and I've got a new f-spot (0.3.4) package that seems to work, shall I file a bug for it?
<Mithrandir> ajmitch: yes, please.  Or give me a link here and I can look at it.
<ajmitch> source package or debdiff?
<Mithrandir> debdiff, please.
<Mithrandir> pitti: yeah, looks sane enough.  Go ahead.
<pitti> Mithrandir: will do, thanks
<ajmitch> http://ajmitch.net.nz/debuild/mono/bzr/f-spot/f-spot_0.3.3-0.3.4.debdiff
<ajmitch> I still have to fill in the changelog before uploading
<slomo> pitti: hm, the binary packages libndesk-dbus1.0-cil and libndesk-dbus-glib1.0-cil are still in universe, only the sources are in main
<pitti> slomo: hm, let me look
<slomo> pitti: or LP confuses me... but tomboy is again on depwait because it can't find the packages
<pitti> slomo: weird, I NEWed them to main
<pitti> slomo: libndesk-dbus-glib1.0-cil is in main already
<pitti> slomo: promoted libndesk-dbus1.0-cil now; for some reason that didn't work the first time I tried it
<slomo> pitti: but not the other? hmm, thanks :) and apart from that archive.ubuntu.com seems to be broken, i didn't get anything new since yesterday evening ;)
<pitti> slomo: me too, doesn't even pong here
<pitti> slomo: I get a 'Destination Port Unreachable' from the DC, too, I just asked the sysadmins
<slomo> pitti: hm, well as long as everything still builds with the new packages it's not too bad ;)
<pitti> slomo: I'm not sure whether the buildds use archive.u.c or drescher directly, but I suspect the former
<gnomefreak> pitti: if your around is there a way to repack the apport crash reports so i can retrace for debugging symbols?
<seb128> gnomefreak: apport-retrace can take a launchpad bug number
<seb128> gnomefreak: it'll download the dump and retrace from it
<gnomefreak> just apport-retrace bug 11111?
<Ubugtu> Malone bug 11111 in kernel-package "Grubs menu.lst gets overwritten every time a kernel update is done" [Medium,Rejected]  https://launchpad.net/bugs/11111
<seb128> gnomefreak: apport-retrace -g nnnnnn
<gnomefreak> ah ok ty
<seb128> np
<gnomefreak> ill try it
<seb128> or -s if you want to print the retrace on the command line rather than attaching gdb
<gnomefreak> i dont need to tell it what bug tracker like malone #####
<seb128> gnomefreak: no, just the launchpad bug number
<Keybuk> why can't I get either beryl or compiz to work?
<seb128> probably because of the xorg updates
<gnomefreak> seb128: ok its running we will see what happens :)
<seb128> try again when new mesa has built
<tepsipakki> Keybuk: used to work?
<Keybuk> tepsipakki: never tried it
<Keybuk> was trying to demo it last night
<tepsipakki> a-ha! :)
<Keybuk> and both failed completely
<Keybuk> I did think that it's a pretty good idea that we're *not* shipping them as default <g>
<seb128> gandalfn who work on compiz told me it was broken for him yesterday after the libxrandr update
<Keybuk> compiz vaguely worked, but gnome-panel kept crashing
<seb128> he had some white screen problem
<Keybuk> beryl also vaguely worked, but the controls inside the windows were incredibly slow to update -- if they updated at all
<seb128> Keybuk: weird, it should not impact on the panel ... did you install an external libwnck?
<Keybuk> seb128: nope, just desktop-effects
<Trewas> umm, isn't including full coredumps in the bugreports reported by apport and keeping them forever available for everyone to see in launchpad a pretty bad privacy hazard, at least for firefox and other web browsers? 
<seb128> do you have a backtrace or crash file for the problem with compiz?
<Keybuk> seb128: I can get you one
<seb128> Trewas: don't send a dump if you don't want to
<seb128> Keybuk: would be nice, thank you
<Trewas> seb128: I know, but if the people knew what it actually sends (I checked a few coredumps) I doubt anyone would let it... but I guess it's ok if it has some very, very prominent warnings
<seb128> Trewas: the apport dialog say it might contain private datas, no?
<Trewas> seb128: s/might/will surely/ would be more honest, at least in case of firefox
<seb128> what datas does it send?
<seb128> I don't know for firefox but for many programs there is nothing private to the crash file
<seb128> do you consider things like the URL you were browsing as private data?
<Trewas> at least a large number of urls from the browsing history, I assume also saved form-data could also be found if one was filled recently (meaning for example credit card numbers)
<heno> seb128: does it also warn you that the data will be posted on the web and indexed by google? :)
<Treenaks> seb128: firefox tends to have passwords in memory
<gnomefreak> seb128: retracing it gives paths to files using the -v -d options
<gnomefreak> doesnt send passwords or anything from what i have seen
<seb128> Treenaks: non-crypted password? 
<seb128> heno: google will not index the content of the coredump.gz
<seb128> anyway that's something know
<gnomefreak> seb128: it grabbed the symbols using -g nnnn and dropped me to gdb what do i do from gdb?
<seb128> I think the plan at some point is to have a crash collector system
<seb128> and move crashes to bugs then
<seb128> gnomefreak: thread apply all bt
<seb128> gnomefreak: if you don't know about gdb you probably want to use the -s option rather than the -g one
<geser> how much time does it currently take for a build package to appear on the archive?
<pitti> geser: between .05 and 1.5 hours usually
<pitti> erm, s/0.05/0.5/
<geser> what could block a2mp3 (finished building at 2007-02-21 01:51:36 CET) to not reached the archive yet?
<pitti> geser: archive.ubuntu.com currently seems to have troubles
<geser> ok, thanks
<Riddell> pitti: dpkg-source complains if the maintainer is set to a kubuntu e-mail address, is that your doing?
<pitti> Riddell: hmm, let me look
<pitti> +            if ($fi{'C Maintainer'} !~ /ubuntu/) {
<pitti> +                    &error(_g('Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address'));
<pitti> Riddell: ^ since @kubuntu.org matches /ubuntu/, I'm confused
<Riddell> pitti: never mind, my fault
<Riddell> I kept the old maintainer line as well without changing it
<pitti> but thanks for poking, I just saw a bug in the check
<pitti> or, rather, it was correct before applying the bug fix
<pitti> ah, no, it's alright
<kwwii> dholbach: where can I find the source for gdm artwork in hoary?
<ne78> Will xorg 7.2 (with xserver 1.3 is possible) be part of fesity or feisty+1 ?
<kwwii> dholbach: forget it, I foudn it
<seb128> ne78: we are working to get it for feisty, several lib and mesa have already been updated
<seb128> ne78: I'm not sure about xserver 1.3 though, is it available yet?
<ne78> seb128: http://lists.freedesktop.org/archives/xorg/2007-February/022005.html
<seb128> ne78: I think we will try to get xorg 7.2 and xserver 1.2 first and then we will see
<mjg59> xserver 1.3 is basically just 1.2 + randr 1.2
<ne78> seb128: randr 1.2 is the feature i would ove to have in feisty
<seb128> ne78: randr 1.2 has been uploaded yesterday we will see what we can do for the server when we update it
<ne78> seb128: cool
<seb128> no reply for now
<seb128> but we will look at it
<seb128> Mithrandir: could you give a retry to rhythmbox on all archs?
<Mithrandir> seb128: given-back
<seb128> thank you
<bddebian> Heya
<seb128> hate quilt
<seb128> how do I create a patch with that
<tepsipakki> seb128: I love it :)
<seb128> weird :p
<seb128> I want cdbs-edit-patch
<seb128> something I can run, do my changes and get a patch
<tepsipakki> quilt new 100_some_patch.diff; quilt add some/file.c; <edit>; quilt refresh
<bddebian> dpatch-edit-patch? :-)
<tepsipakki> oh and 'quilt push -a' before that
<tepsipakki> did I miss something..
<seb128> gnagnagna
<seb128> hate hate it
<seb128> quilt new patch
<seb128> autoreconf
<seb128> quilt refresh
<seb128> -> Nothing in patch 099_autoreconf
<kylem> you have to actually tell it you're changing something.
<seb128> I don't know what I'm changing
<kylem> so it can preserve it and actually generate a diff.
<seb128> I'm running autoreconf
<seb128> and I want it to diff before and after like cdbs-edit-patch do
<kylem> cdbs-edit-patch has the advantage of using a temporary copy... quilt is trying to do things in place. you're pretty much S.O.L. for this...
<seb128> I don't want to "quilt add file" on a zillion of Makefile.in
<tepsipakki> seb128: you could ask jcristau on #ubuntu-x
<seb128> I'll just switch that package back to some sane patch system I think
<tepsipakki> seb128: you need it for libx11?
<seb128> no for compiz I was trying to merge from debian
<tepsipakki> ah
<seb128> but doing that stupid autoreconf patch is taking as long as merging the rest of the package
<Mithrandir> seb128: just quilt add $(find -type f) and leave it to it to work out which files actually changed? :-)
<seb128> Mithrandir:  yeah I'll do that
<seb128> I don't get why people actually use that, they don't like things that just work ;)
<pochu> BenC: do you have a kernel meeting now?
<BenC> pochu: In 9 minutes, yes
<pochu> BenC: oks. it's because in ubuntu-meeting it says current meeting, and there is nobody :)
<pochu> hehe
<BenC> I think it's preemptive or something :)
<pochu> :)
<BenC> unless it's UTC clock is just broken
<pochu> BenC: maybe :)
<iwj> At last!  autopkgtest is now building dovecot.
<gpocentek> ls
<gpocentek> sorry, wrong window
* dholbach hugs gpocentek
* gpocentek hugs dholbach back
* bddebian hugs gpocentek and dholbach :-)
<iwj> ROTFL
<iwj> adt-run: erroneous package: Test Depends field contains dependency `python' with invalid characters
<jdong> Dear emacs doctor... everywhere I look there are subliminal messages that I should use emacs
<jdong> there's emacs and solaris vi on the workstation that I'm currently on.
<Treenaks> jdong: Ctrl+X Ctrl+C will show them
<jdong> There's emacs posters around me....
<jdong> and now ESR has joined Ubuntu?
<Treenaks> jdong: Mwuahahaha! :)#
<jdong> please make it stop... my pinky hurts to think about it.
<Treenaks> jdong: be sure to use xemacs -- to annoy him
<jdong> :)
<Keybuk> I spend all of my time trying *not* to use emacs
<Keybuk> but there's just nothing better
<Keybuk> which is ad
<Keybuk> sad too
<bddebian> jdong: WHAT, no nano??
<bddebian> :)
<jdong> bddebian, the one I'm on is Solaris 10 based... and the  Linux WS'es here are RHEL4-based
<jdong> both of which have no shipped nano
<jdong> but my bashrc imports a few vim packages :)
<bddebian> heh
<jdong> and aliases emacs to vim :)
<jdong> the first time I launched solaris vi I actually got a notice that it isn't officially supported by IS&T :D
<tsmithe> i'm trying to package something (wired), but came across http://paste.ubuntu-nl.org/6899/ when trying to document copyrights. i'm not really sure what to do.
<tsmithe> sistpoty pointed me here
* tsmithe waves
<Keybuk> tsmithe: looks like the "Wired Team" have modified code taken from someone else
<Keybuk> the original code is LGPL, the modified code is GPL
<tsmithe> ok. so it's now GPL?
<tsmithe> shall i give both credits?
<Keybuk> tsmithe: I would normally give both credits, yes
<tsmithe> thanks
<Keybuk> it's permissible to relicence LGPL code under the GPL
<tsmithe> oh. didn't know that. cool - /me dives back into his console
<Keybuk>   3. You may opt to apply the terms of the ordinary GNU General Public
<Keybuk> License instead of this License to a given copy of the Library.  To do
<Keybuk> this, you must alter all the notices that refer to this License, so
<Keybuk> that they refer to the ordinary GNU General Public License, version 2,
<Keybuk> instead of to this License.  (If a newer version than version 2 of the
<Keybuk> ordinary GNU General Public License has appeared, then you can specify
<Keybuk> that version instead if you wish.)  Do not make any other change in
<Keybuk> these notices.
<Keybuk> (from LGPL 2.1)
<tsmithe> great!
<LaserJock> pitti: get a chance to look at qcad MIR by chance?
<pitti> LaserJock: not yet, sorry
* pitti does now
<LaserJock> pitti: np, just wondered if I missed something
<esr> finalbeta on #ubuntiu directed me here when I asked what mailing list to join first to get involved in Ubuntu development.
<finalbeta> that's great, blame me ;)
<Mirv> esr: hi, ubuntu-devel and ubuntu-devel-discuss for example
<Mirv> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
<esr> I read the wiki and know about those two.  I was trying to get a handle on which one to start with.
<sharms> esr: that list is moderated, might not be 100% what you are looking for
<Mirv> a more full list at https://lists.ubuntu.com/mailman/listinfo/ , where you can pick yours. but be aware that a lot of development is basically happening inside Launchpad, which takes some time to get used to
<Mirv> https://launchpad.net/
<Keybuk> esr: ubuntu-devel-discuss is an open list for discussing development ideas, etc.
<Keybuk> esr: ubuntu-devel is moderated to active developers only, to keep the traffic lower
<sharms> Or come to Ubuntu-Motu since that is a great starting point for anyone
<Keybuk> esr: the majority of Ubuntu (the "universe" repository) is maintained by the "Masters Of The Universe", their mailing list is the ubuntu-motu mailing list
<Mirv> (motu="masters of the universe", universe=community maintained software packages)
<Keybuk> if you want to join the development team, first you'd join the MOTU list and team and work your way towards the core development team
<esr> I guess it will be the MOTU list first, then.
<Keybuk> https://wiki.ubuntu.com/MOTU
<pitti> hi esr
<Keybuk> that's a pretty comprehensive starting point for that team
<Keybuk> http://www.ubuntu.com/community/processes/newdev
<sharms> if MOTU can deal with me, then you know its a good place to start
<Keybuk> ^ is a wordy overview of the "becoming a developer" process
<sharms> I am pretty sure Jono's herding cats was about filtering me out :)
<Keybuk> http://www.ubuntu.com/community/processes/newmember -- anyone can become an Ubuntu member by contributing to the community (where contribution can include advocacy, etc.)
<esr> Right, I read http://www.ubuntu.com/community/processes/newdev.
<esr> I've just sent a subscription request to the MOTU list.
<bddebian> esr: For Universe/MOTU, you should probably join us in #ubuntu-motu :-)
<pitti> LaserJock: still here?
<LaserJock> pitti: yep
<pitti> LaserJock: I just reviewed qcad; how badly is this needed for edubuntu?
<mdke> are we shipping the control center shell by default in feisty?
<LaserJock> pitti: well, that's sort of a tough question
<pitti> LaserJock: the only critics I have is that it does not support gettext, and thus does not integrate into our translation infrastructure at all
<pitti> LaserJock: otherwise it's fine
<LaserJock> pitti: CAD is a pretty high demand
<LaserJock> pitti: and it's about the only/best CAD program we've got as far as I can tell
<pitti> LaserJock: I'm willing to approve it, it'd just become a nuisance once we demote qt3 and want to translate it
<pitti> LaserJock: right, but it doesn't get any worse in universe (IOW, in main it cannot profit from langpack support etc. anyway)
<Mithrandir> LaserJock: how useful is kicad?
<pitti> LaserJock: if you want to put it onto the edubuntu CD, then there's no question
<pitti> LaserJock: but if you want it in main 'just because', then I'm not sure about the benefits
<LaserJock> pitti: it's supposed to go onto the Edubuntu Add-on CD
<pitti> LaserJock: ok then
<LaserJock> pitti: well, if you approve it I can ask ogra about the issue and let him decide
<pitti> alright
<LaserJock> my feeling is he'll want it because we get a lot of requests for CAD
<LaserJock> but that sure stinks about no gettext support :/
<bddebian> pitti: Are you just pitti@u.c ?
<pitti> bddebian: that should work, too
<bddebian> Is there a preferred one?
<pitti> bddebian: martin.pitt@
<ZiNC> Hey.
<bddebian> pitti: Too late but thanks.  I'll remember for next time :)
<pitti> bddebian: as I said, pitti@ is an alias and should work
<bddebian> NP
<ZiNC> Anyone familiar with SMART, particularly how sector remapping works?
<Mez> is there an easy way to get a list of all installed packages?
<mr_pouit> dpkg --get-selections ?
<Chipzz> dpkg --get-selections | grep install | cut -f1 in that case :P
<mr_pouit> ^^"
<Chipzz> hrrrrm wait no :P
<Chipzz> the grep install is wrong actually :P
<Mithrandir> dpkg -l | grep ^ii
<BenC> What's the suggested way to fix this:
<BenC> dpkg-source: error: Version number suggests Ubuntu changes, but Maintainer: does not have Ubuntu address
<Mithrandir> BenC: what's the maintainer address?
<BenC> It's a Debian.org address (kernel team), but I'm wondering if all I need to do is change it to mine
<pochu> BenC: an @ubuntu.com address :)
<BenC> I don't need to add some magical meta field for the original maintainer?
<Mithrandir> move the current one to XSBC-Original-Maintainer and set the Maintainer one to yours or kernel-team@lists.u.c or something.
<BenC> ah, that's what I was looking for
<BenC> Mithrandir: thanks
<Mithrandir> BenC: you know, this is all documented in pitti's posting to u-d-a a week or so ago. :-)
<pochu> BenC: not subscribed to devel-?
<BenC> Mithrandir: Yeah, I remember now :)
<bluefoxicy> does anyone know what the flicker is in X anyway?
<bluefoxicy> Once in a while (I've noticed this since the beginning of time), the screen will just jerk and for like 1 frame everything will be dragged off to the side or scrunched
<bluefoxicy> brief display corruption
<bluefoxicy> no real impact on usability or stability, it's just weird.
<LaserJock> sounds like a bluefoxicy-specific issue ;-)
<bluefoxicy> vo.ov
<pitti> Mithrandir: is there anything in the live system creation that could clean /var/lib/update-notifier/user.d/, i. e. the package post-install notifications?
<Mithrandir> pitti: yes, we could do that.  Could you mail infinity to get that fixed, please?
<pitti> Mithrandir: ah, good; I wondered since yesterday why the hell that postinst doesn't work
<Mithrandir> grr, what's the way to get bzr to output a proper ChangeLog style log?
<sabdfl> Mithrandir: #bzr?
<Treenaks> Mithrandir: submit a spec, then organise a sprint ;)
<elmo> Mithrandir: there's a plugin for it I think, but bzr itself doesn't do it
<Mithrandir> elmo: k, thanks.
<elmo> http://telecom.inescporto.pt/~gjc/gnulog.py
<Mithrandir> elmo: oh, excellent.  Thanks.
<Mithrandir> apart from it blowing up due to non-ascii chars, but I'll work around that. :-)
<seb128> shawarma: ping?
<h4writer> Do anyone know if the code of run_command (<alt>F2) is in python and where I can find it. For the moment I find only the panel-run-dialog.glade file
<h4writer> (I want to change it a bit)
<seb128> it's not in python
<seb128> it's gnome-panel code
<h4writer> can I edit it and run it direct. Or do I need to recomile it always I change a bit?
<tsmithe> gnome-panel is C
<tsmithe> you'll need to recompile
<h4writer> no, so quick changing something in it, is not easy:-(
<h4writer> ok it wil not be for me
<h4writer> thanks anyway
<tsmithe> sorry :)
<shawarma> seb128: pong
<seb128> shawarma: network-manager-vpnc is not good
<seb128> gnome-two-password-dialog.c looks like LGPL
<seb128> "   The Gnome Library is free software; you can redistribute it and/or
<seb128>    modify it under the terms of the GNU Library General Public License as
<seb128>    published by the ree Software Foundation; either version 2 of the
<seb128>    License, or (at your option) any later version.
<seb128> "
<seb128> and there is no copy to the LPGL to the package
<shawarma> Yes.
<shawarma> Sure. It's in that same directory.
<shawarma> Isn't it?
<sistpoty> seb128: btw.: is there a way to send new-rejects to the signer as well? I guess that would help us quite to improve reviewing skills
<shawarma> seb128: It's there in my copy.. 
<shawarma> seb128: auth-dialog/COPYING should be LGPL-2 unless I messed up somewhere.
<h4writer> tsmithe, I wanted to fill a bug request (for my small tweak), but there was already reported: http://bugzilla.gnome.org/show_bug.cgi?id=339963
<Ubugtu> Gnome bug 339963 in Panel "Run dialog should not modify the list when selecting an item" [Normal,Unconfirmed]  
<h4writer> It dates from 2006!?!
<h4writer> that's pity
<seb128_> re
<seb128_> shawarma: 
<seb128_> properties/nm-vpnc.c is  Copyright (C) 2005 David Zeuthen, <davidz@redhat.com>
<seb128_>  and it's not listed to debian/copyright
<shawarma> seb128_: True.
<tsmithe> seb128_, you on archive duty?
<shawarma> seb128_: I'll fix it right away.
<shawarma> seb128_: Anything in -openvpn I should fix while I'm at it?
<seb128__> re
<seb128__> what did you get before my internet disconnected? :p
<shawarma> That you believed the LGPL was missing
<shawarma> ...to which I responded:
<shawarma> seb128: auth-dialog/COPYING should be LGPL-2 unless I messed up somewhere.
<seb128__> <seb128> properties/nm-vpnc.c is  Copyright (C) 2005 David Zeuthen, <davidz@redhat.com>
<seb128__>  and it's not listed to debian/copyright
<seb128__>  sistpoty: I didn't reject it yet, I was pinged shawarma because he asked about the package today
<shawarma> seb128: Oh, that too. I'm fixing it right now.
<sistpoty> seb128_: it was more a general question, not nm-vpnc specific ;)
<seb128__> shawarma: ups, I'm used to have the COPYING to the src dir, not to subdirs, that's fine then
<seb128__> sistpoty: ok
<shawarma> seb128__: I put it there because the rest is GPL and i put the corresponding COPYING for that in the root.
<seb128__> usually people use a COPYING and a COPYING.LIB to the src dir
<seb128__> but that's fine
<bddebian> seb128__: Do you happen to know if you are going to hit libtifiles2 also?
<bddebian> Oh, nm
<tsmithe> seb128__, did you get my ping? (/me feels really rude)
<seb128__> bddebian: "hit libtifiles2", what?
<seb128__> tsmithe: no
<tsmithe> ah
<shawarma> seb128__: Ah, that makes sense, too. I'll leave it where it is for now, though.
<tsmithe> seb128__, are you on archive duty tonight?
<bddebian> seb128__: In NEW
<seb128__> tsmithe: I am
<tsmithe> seb128__, could you take a look at wired? _MMA_ would really like it to be in feisty and thus ubuntustudio
<seb128__> bddebian: I'm working on NEW, I'll probably not process everything to source NEW though, there is too much of it
<bddebian> seb128__: OK
<seb128__> "_MMA_"?
<tsmithe> seb128__, he's the lead for ubuntustudio
<seb128__> tsmithe: ok, will do
<tsmithe> thanks much
<tsmithe> also, if enblend gets up there, i'd appreciate that as well
<bddebian> Sheesh, what am I chopped liver? :-)
<tsmithe> bddebian, er yeah...
<bddebian> Shut up tsmithe, no more reviews for you ;-P
<tsmithe> :D
<tsmithe> you know that's not true :P
<shawarma> seb128__: Reuploaded nm-vpnc.
<seb128__> shawarma: ok, thank you, otherwise it looks fine, I'll probably accept the update
<shawarma> seb128__: Sounds excellent. -openvpn was fine?
<mdke> seb128__: are we sticking to control center for feisty or reverting with GNOME?
<seb128__> mdke: control-center is GNOME
<seb128__> shawarma: it's next :p
<shawarma> seb128: ah. i'll stick around for a bit. :-)
<mdke> seb128__: I mean, I read that GNOME are going back to the administrative tools in menus by default, rather than the cc shell; are we following that decision?
<seb128> mdke: yes we are
<mdke> ok
<seb128> mdke: we would probably have reverted to menus even if they would not have done that
<mdke> oh right.
<mdke> shame
<seb128> mdke: not shame, most of the distro team was breathing in my neck for a revert :p
<seb128> mdke: we will likely switch next cycle, there is still some speed, keyboard navigation, graphical space used, etc problems that could use some work before that
<mdke> seb128: ah, well I liked the concept; dunno if it was too buggy or usability issues
<seb128> lack of polish we will say
<seb128> next cycle should be fine
<mdke> seb128: cool
<seb128> shawarma: openvpn (and maybe the other one as well) auth-dialog/gnome-two-password-dialog.h has a "Copyright (C) 2005, Red Hat, Inc." and debian/copyright status that "a) auth-dialog/* are Copyright 1999, 2000 Eazel, Inc."
<seb128> and auth-dialog/main.c has 
<seb128> " * (C) Copyright 2004 Red Hat, Inc.
<seb128>  *               2005 Tim Niemueller [www.niemueller.de] 
<seb128> "
<seb128> not listed by debian/copyright neither
<seb128> properties/nm-openvpn.c is "Copyright (C) 2005 Tim Niemueller <tim@niemueller.de>
<seb128> s//"
* ajmitch is going to have great fun with copyright & mozldap
<seb128> and debian/copyright states "d) Everything else is Copyright 2004-2007 Red Hat, Inc."
<seb128> shawarma: same for src, .c are copyight "Tim Niemueller <tim@niemueller.de>"
<seb128> shawarma: network-manager-openvpn is not good to go, please fix those
<seb128> shawarma: network-manager-vpnc has the auth-dialog/gnome-two-password-dialog.h copyright to Red Hat problem, could you fix it as well?
<jdong> have the archives been really slow recently?
<jdong> pratt.canonical.com often time out
<jdong> and the other 195.x.x.x one pulls like 0-15kb/s
<jdong> and I'm sure it's not my link :)
<shawarma> seb128: I'm on it.
<tsmithe> when does ff take effect?
<sistpoty> tsmithe: my ff starts in 10 minutes, though other ppl. from other time zones still have a few more hours ;)
<seb128> shawarma: 10 days ago?
<tsmithe> ok
<shawarma> seb128: what?
<tsmithe> can i be in utc-12?
<sistpoty> tsmithe: I guess +-12 hours won't make a big difference
<seb128> shawarma: feature freeze you mean?
<tsmithe> sistpoty, ok thanks
<ajmitch> seb128: universe feature freeze is today, so people are wanting packages in :)
<seb128> shawarma: ups, that was for tsmithe
<seb128> ajmitch: ah ok
<tsmithe> seb128, yes
<shawarma> seb128: Ah.
* tsmithe waits for enblend to build for the last time, so he can hopefully speed it through revu
<elmo> jdong: this is why there are mirrors
<jdong> elmo: what's a good US mirror that's not two weeks behind archive.ubuntu.com?
<jdong> kernel.org was kinda out of date the last time I tried it
<jdong> and us. seems to still be the same servers
<elmo> jdong: https://launchpad.net/ubuntu/+archivemirrors
<jdong> ooh very cool
<shawarma> seb128: One of the file in the openvpn package lacks a copyright notice.. What to do?
<shawarma> seb128__: ^^
#ubuntu-devel 2007-02-22
<shawarma> seb128__: There. Both reuploaded.
<shawarma> seb128: Both reuploaded.
<seb128> ok, will have a look to them
<shawarma> seb128: Cool. Sorry for all the fuss. I never imagined the copyright issues with these packages would be so complex.
<seb128> np
<shawarma> seb128: I'm off for tonight. Should there be any other issues, just /msg me or mail me at sh@linux2go.dk ok? Thank you very much for your help. 
<seb128> k, will do that or ping you tomorrow, np, thank you for the work on those packages
<shawarma> np
<shawarma> G'night.
<seb128> 'night
<BenC> anyone know a decent flow chart program?
<kylem> visio
<kylem> :P
* BenC punts kylem to redmond
<sistpoty> BenC: /me likes dia pretty much, but I don't know if you'd call that decent ;)
<BenC> kivio...sounds nearly the same and starts with a 'K', it must be good
<lifeless> err
<lifeless> why does ubuntu-standard depend on *dselect* ? wtf?
<jdong> why don't you.... de-select it! \end{terriblepun}
* jdong hides under a rock
<tsmithe> @lart jdong 
<tsmithe> that was horrible!
<elmo> anyone got up-to-date feisty?
<jdong> elmo: sup?
<elmo> jdong: can you see if xmodmap works for you?
<elmo> xmodmap -e "keycode 11 = 2 quotedbl"
<elmo> e.g. ^-- try that
<elmo> and see if shift-2 produces '"' afterwards.  assuming you're on a US keymap
<jdong> "
<jdong> yeah
<jdong> works fine here...
<elmo> jdong: when did you last update?
<jdong> 5 minutes ago
<elmo> hmm, meh
<jdong> remember I was whining to you about the archive? :D
<elmo> I have no idea why this is broken for me, but it's broken, even with a completely new user
<jdong> feisty X since two days ago has been acting up for me somewhat though
<jdong> like terminal scroll is absurdly slow
<jdong> and even locks up X sometimes
<jdong> beryl broke too but that's old news ;-)
<z_malloc> hello
<z_malloc> any ubuntu developers know why this bug would take so long to resolve, and be priority : low urgency ?? https://translations.launchpad.net/ubuntu/edgy/+source/mysql-dfsg-5.0/+bug/66702
<Ubugtu> Malone bug 66702 in mysql-dfsg-5.0 "GCC emits 3DNow!-specific instruction for __builtin_prefetch" [Undecided,Fix committed]  
<z_malloc> 4 months to resolve a bug rendering mysql inoperable in the 64bit server version seems insane to me
<z_malloc> im concerned about using ubuntu long term in a production environment if a bug like this takes 4 months to correct, and the guy who fixes it doesn't even have an EMT64 machine.
<pochu> z_malloc: I'm not an ubuntu developer, but I'm looking at that bug report, and it's marked as fixed, so what's the problem?
<HrdwrBoB> anyone using production ubuntu and not using LTS on servers is insane
<Lathiat> from what i can see , that bug was filed in the edgy development phase
<Lathiat> and fixed in the edgy development phase
<HrdwrBoB> and anyone not using at the very least, stable, should be committed
<Lathiat> if your running the unstable version in your production environments, you'll have plenty of other issues to worry about ;)
<z_malloc> the problem is I'm trying to understand why it took 4 months to fix, and is marked low urgency.  the installer says "install LAMP server".  seems like having apache, mysql and php working would be pretty important.
<pochu> z_malloc: it isn't marked as low urgency
<z_malloc> the bug was submitted in october 06, and the fix was submitted a few days ago.
<pochu> z_malloc: it is undecided
<z_malloc> mysql-dfsg-5.0 details Current version:  5.0.24a-9ubuntu1
<z_malloc> Upload date: 2007-02-16
<z_malloc> Urgency: Low Urgency
<Lathiat> oh i see i misread, my appologies
<Lathiat> z_malloc: thats the source, not the bug
<z_malloc> ahh i see
<z_malloc> that makes more sense :)
<pochu> z_malloc: 13 Dec 06 14:44  	 Matthias Klose  	gcc-4.1: status  	Confirmed  	Fix Released
<z_malloc> hmmm. i installed after that date, and updated since. 
<pochu> z_malloc: it was fixed in gcc in december. however, it was noticed also in mysql, so it was fixed later ;)
<z_malloc> i don't understand.  mysql won't start.  
<pochu> 15 Feb 07 19:08 <---- Date when it was reported on mysql-dfsg-5.0
<pochu> z_malloc: ^^
<pochu> z_malloc: so 6 days to be fixed :)
<z_malloc> i guess thats what i mean
<Lathiat> pochu: that bug was opened 18/10/06 
<pochu> Lathiat: for gcc yes
<pochu> Lathiat: but not for mysql
<pochu> https://translations.launchpad.net/ubuntu/edgy/+source/mysql-dfsg-5.0/+bug/66702/+activity
<Ubugtu> Malone bug 66702 in mysql-dfsg-5.0 "GCC emits 3DNow!-specific instruction for __builtin_prefetch" [Undecided,Fix committed]  
<pochu> look there
<Lathiat> thats what im looking at
<Lathiat> Bug Details:
<Lathiat> Reported on:
<Lathiat> 2006-10-18 17:04:14 WST
<pochu> Lathiat: but that's the gcc bug
<Lathiat> the bug was originally filed against mysql
<Lathiat> and then mvoed to gcc as it was actually a gcc bug
<Lathiat> z_malloc: certainly if you have a critical production environment, perhaps you should look at purchasing support from canonical
<pochu> Lathiat: you are right, sorry
<pochu> hehe
<z_malloc> whether it took 2 months to fix, or 4 .. either way.. isn't it important enough?
<z_malloc> aren't tons of people using 64bit server
<z_malloc> and more importantly.. didn't anyway try Mysql?? i mean, its pushed as a LAMP server right from the start of the install
<z_malloc> i'm just trying to understand the scenerio, thats all.
<z_malloc> i am hopeful that i am missing something
<pochu> z_malloc: the really stable system is the LTS (dapper)
<pochu> maybe that's what you are missing (maybe not)
<bddebian> Yes, there are thousands of packages and not enough developers
<Lathiat> z_malloc: The current Ubuntu "focus" is on the desktop environment
<Lathiat> z_malloc: while the server efforts are not without aid, it is not the focus of the dev teams at this time
<ajmitch> Lathiat: yet there are still server editions, with mysql prominently available
<z_malloc> yes, but its the server version, and .. maybe i'm wrong.. but it just seems like mysql is like one of the top 2 applications in that distribution.  way to important to have simply not working for months.
* ajmitch would have come across this bug, except that mysql runs on an amd64 chip here
<z_malloc> that was my other question.  did this bug only afflict some amd64 installs? or all
<ajmitch> only em64t
<HrdwrBoB> yeah
<ajmitch> all the 64-bit amd chips support the instruction used
<HrdwrBoB> it's an amd specific extension
<z_malloc> which is what?  all intel based chips
<HrdwrBoB> basically yes
<HrdwrBoB> but only if you run 64bit
<Lathiat> "all intel based 64bits, running the 64bit distribution"
<ajmitch> which is hardly uncommon for a server
<z_malloc> ajmitch : my thoughts as well
* ajmitch may hopefully get a 64-bit core 2 duo box for a server soon, where mysql will be critical
<z_malloc> basically, two chips.  amd/intel, and with dell only providing intel.. i just don't understand
<ajmitch> however I'll most likely run dapper or etch
<ajmitch> 'edgy' has its name for a reason
<HrdwrBoB> I agree it should be fixed
<HrdwrBoB> but I also think that anyone running a server not running dapper needs their head read
<pochu> anyway it's already fixed :)
<ajmitch> z_malloc: have you confirmed that it is fixed & replied on the bug report?
<z_malloc> i am glad its fixed, and i don't want to come off as a jerk.  im just fearful about this being a sign for things to come. ala debian package maint.  which has gotten really bad.
<ajmitch> pochu: in -proposed, iirc
<pochu> ajmitch: oh, right :)
<z_malloc> ajmitch : no i havent.  i forced the previous version from dapper, which was suggested in the ubuntu forums.  not an ideal solution, but the only one i could find short of compiling.
<ajmitch> ok, testing of the version in edgy-proposed would be appreciated if you have the time
<z_malloc> sadly, im barely capable of installing packages.  my linux skills are weak at best.
<z_malloc> well..thats a bit overstated. but needless to say, i'm probably not well suited.
<pochu> z_malloc: then, please comment the bug report confirming that it's fixed, in order to get it to the -updates repo
<z_malloc> others have commented that it is working now.  i guess i just wanted to find out what was up with the thinking and importance of the bug. 
<z_malloc> sounds like, the answer is "not enough maintainers"?
<z_malloc> ty and gn
<xerroz> is there some way i can install ubuntu on top of an already existing ubuntu? (looking to setup a system to debug)
<Hobbsee> xerroz: #ubuntu for support
<Hobbsee> please see the /topic
<xerroz> Hobbsee: wouldn't this question be more specific to the development of Ubuntu..
<Burgundavia> xerroz: not really
<pitti> Good morning
<dholbach> good morning
<LaserJock> pitti: do new binaries as a result of a split of a source package end up in the NEW queue?
<pitti> LaserJock: yes, they do
<LaserJock> do they need a MIR?
<pitti> LaserJock: no, just a standard review
<LaserJock> k
<pitti> LaserJock: is tomorrow ok, or shall I do it right now?
<LaserJock> pitti: it's not uploaded yet
<LaserJock> I gotta ask dholbach about that ;-)
<mdke> do they need a feature freeze exception?
<pitti> LaserJock: ah, that makes it hard to review :)
<dholbach> LaserJock: about what?
<LaserJock> dholbach: I committed some changes the doc repo that splits up the ubuntu-docs package
<LaserJock> we needed to split the server guide and packaging guide as standalone .debs
<dholbach> LaserJock: yeah, that's fine with me
<dholbach> dunno, what you need to know from me?
<LaserJock> I just wanted you to check over my changes (not so familiar with CDBS)
<LaserJock> when you get a chance
<dholbach> ok - can you send me a mail with that?
<LaserJock> dholbach: ok
<dholbach> gracias
* Treenaks slaps fglrx in the face... for some reason it keeps eating 100% CPU when scrolling gnome-terminals
<Treenaks> (yes, really..)
<pitti> Treenaks: that also happens with the nv driver
<pitti> Treenaks: for a week or so, terminals became unbearably sluggish with nv
<pitti> Treenaks: I guess something in the backend has changed (such as using another graphics backend for text rendering)
<Treenaks> pitti: I have the same problem with Xv windows, they generate slowness as well
<Treenaks> pitti: opengl does not
<pitti> right
<pitti> Treenaks: I guess the nvidia driver is just fast enough to paper over the new slowness
<Treenaks> maybe.. 
<Treenaks> could it be Composite? I disabled that..
<Treenaks> (but also, gnome-terminal has changed its rendering a few weeks back, to fix an overlapping-characters bug)
<dholbach> pitti, Mithrandir: can you please reject the last new-stuff-manager upload from source NEW? I'll upload a new version right now... upstream/the maintainer decided to change a few things
<pitti> dholbach: doing
* dholbach hugs pitti
<pitti> dholbach: new-stuff-manager? I'd be inclined to reject it because of that silly name already
<dholbach> gracias
<Treenaks> new-stuff-manager... is that the new name for bling-manager/desktop-effects?
<dholbach> pitti: I'd suggest you let the maintainer know :)
<pitti> dholbach: who is it?
<dholbach> XSBC-Maintainer: Sebastian Plsterl <marduk@k-d-w.org>
<pitti> I'm serious, I regard this as totally impolite namespace clutter and sloppiness
<Kagou> hi
<pitti> hi Kagou 
<pitti> dholbach: ok, I let him know
<dholbach> ok, thanks again
<pitti> [done] 
<dholbach> mdke, Laser_away: the changed docs packaging is in the usual place?
* dholbach hugs pitti
* pitti hugs dholback
<dholbach> *snigger*
<dholbach> pitti is witty ... even early in the moning :)
<Treenaks> we call him 'witty pitti'
<Treenaks> ("petit pitti"?)
<mdke> dholbach: yes in trunk
<dholbach> seems everybody gets an appropriate title these days :-)
<pitti> :-P
<dholbach> mdke: we should get rid of "/usr/share/ubuntu-artwork/" in feisty+1 somehow
<dholbach> (in ubuntu-docs)
<mdke> yeah, the firefox homepage issue is so annoying
<dholbach> yeah
<dholbach> mdke: looks good to me - shall I upload it?
<seb128> moning
<seb128> morning
<dholbach> heya seb128!
<seb128> hey dholbach
<ajmitch> hi jono 
<jono> hey ajmitch
<dholbach> hey thekorn
<dholbach> hey jono
<jono> hi dholbach
<thekorn> hey dholbach
<Treenaks> pitti: it's a time thing
<Treenaks> pitti: I just rebooted, and now everything is fast
<carlos> pitti: I think your latest ifupdown update broke my network support in Feisty
<Treenaks> pitti: but I know that if I keep running, it will happen again
<pitti> Treenaks: hm, not for me
<pitti> carlos: uh, how so? I just added a new network method... any details?
<carlos>  I just downgraded the package to check whether that's the cause
<carlos> pitti: I'm using static ip address in that server
<pitti> carlos: so do I for my secondary eth
<carlos> and lo device is not up and eth1 is up but without ip address
<carlos> doing it by hand works
<pitti> by hand -> ifup -a?
<carlos> ifup eth1 and ifup lo
<carlos> hmm
<carlos> but seems like that package is not the problem
<carlos> with previous version I'm without network too
<pitti> carlos: does /etc/init.d/networking stop/start works?
<carlos> pitti: with that, I get a working eth1 card with the fixed ip address
<carlos> but lo interface does not appear with ifconfig
<carlos> pitti: it appears with loopback stop / start
<pitti> carlos: can you put your /etc/network/interfaces somewhere?
<pitti> carlos: ah, indeed, /e/i/networking doesn't touch lo
<carlos> is there any public paste bin service you use?
<carlos> I only know about the internal one that we use for launchpad development
<pitti> http://paste.ubuntu-nl.org/ works fine
<carlos> pitti: http://paste.ubuntu-nl.org/7010/
<pitti> carlos: I'm just asking because network-admin had a bug until recently that screwed up the file
<carlos> I don't see anything wrong there, but maybe I'm missing something
<pitti> no, looks fine
<pitti> carlos: and they reproducably do not come up at boot?
<carlos> yeah, every boot has this same problem
<pitti> carlos: ok, a second please
<carlos> the only change I have done, that I'm not sure whether would be causing this is that I moved /var to a new partition
<pitti> carlos: ah, that indeed sounds likely
<carlos> but it has been at least a week since I restarted the computer so I cannot be sure whether it's a software problem or a migration problem
<carlos> pitti: it's not the first time I do that
<carlos> and I use rsync -avzH to preserve everything
<carlos> but this time is the first time it would cause problems
<pitti> carlos: you could try adding 'set -x; exec 2>/tmp/network.log' to /etc/init.d/networking
<carlos> ok
<pitti> carlos: /var is likely not mounted at the time when loopback is executed?
<carlos> hmmm
<carlos> maybe
<carlos> good point
<carlos> so the problem would be just that the partition is not ready...
<pitti> S08loopback vs. S35mountall
<carlos> pitti: how does it work for new servers that you install with var in its own partition?
<pitti> hm, I don't know
<pitti> carlos: e. g. /var/run/network/ifstate looks kind of important
<carlos> pitti: ok, thanks for the clue, I will try to figure whats going wrong...
<carlos> well, how to fix it as I know what's going wrong now :-P
* Mithrandir looks around for a vict^WMOTU.
<mjg59> Mithrandir: I hear esr will be one soon
<Mithrandir> dholbach: are you going to send out a mail about universe ff or should I?
<dholbach> am I the victim now? ;-)
<Treenaks> *blame-shift*
<dholbach> Mithrandir: if you have a boilerplate freeze announce mail in front of you, you could do it -- if not, I can do it too --- in fact you just reminded me to announce the MOTU council meeting tomorrow :)
<Mithrandir> Treenaks: you!  Want to package the new blender upstream version?
<dholbach> Mithrandir: I think lfittl is working on that.
<Mithrandir> ok.
<dholbach> Mithrandir: I can mail him if you like
<dholbach> at least he told me last week in vienna
<Mithrandir> lfittl@u.c?
<dholbach> Mithrandir: yes
<Mithrandir> I'll mail him
<dholbach> cool
<carlos> pitti: It's fixed now. Ubuntu handles quite well that use case (having /var in its own partition), but you still need to have /var/run and /var/lock created in rootfs to get all magic working
<cjwatson> carlos: yeah, the installer takes care of that, but obviously if you move it yourself then you have to do it
<carlos> right
<carlos> it took me a while to figure it
<seb128> Mithrandir: I'm looking to network-manager-openvpn and network-manager-vpnc from NEW, I did look at them yesterday and there was some debian/copyright small problems that should be fixed now
<giskard> someone did a release of vpn plugins?
<seb128> the packages are from svn code apparently
<Mithrandir> seb128: yeah, it was just the full text of the licences missing from the tarballs.
<seb128> Mithrandir: I didn't notice that
<Mithrandir> seb128: if it's been fixed, then it's good. :-)
<seb128> Mithrandir: there is the GPL to COPYING and the LGPL to subdir/COPYING
<Mithrandir> seb128: then it's good
<Lathiat> what package woudl i file incorrect driver detection on?
<Lathiat> (Xorg driver, nvidia card detected as vesa not nv)
<Mithrandir> discover-data
<Treenaks> pitti: the terminal-slow-bug has to do with scrollback + lots of windows.. if I turn my scrollback back to 500 lines, it's fast(er) again
<shawarma> seb128: Rock'n'roll! :-) Thanks!
<seb128> shawarma: np ;)
<pitti> Treenaks: hm, (1) but scrolling forward is slow, too and (2) I didn't change this setting, and it happens to many people
<Lathiat> Mithrandir: hrm thanks
<Treenaks> pitti: I changed it from 5000 to 500
<shawarma> seb128: Is it common for packages to that many different copyrights?
<pitti> Treenaks: 500 is my default, too
<Treenaks> pitti: how many terminals (they're all one process..)
<seb128> shawarma: not sure on how common but that's not the only one for sure ;)
<Treenaks> pitti: I have 6 atm
<pitti> Treenaks: 5
<shawarma> seb128: Ok.
<doko> pitti: is it reasonable to extract the first parameter of the python command line and figure out a package for that for an apport report?
<pitti> doko: that sounds similar to what mono does
<pitti> doko: and in fact I thought that apport should already do this; it doesn't?
<doko> pitti: when did you introduce this? look at the duplicates in the listen package
<pitti> doko: ages ago, but of course there might be corner cases
<dholbach_> kwwii: good looking - uploaded
<seb128> Mithrandir: I've accepted the newest upload of network-manager-vpnc, there is still 2 old versions in the NEW queue, should I just q reject them?
<kwwii> dholbach_: great, thanks!
<pitti> doko: ah, bug 86744?
<Ubugtu> Malone bug 86744 in listen "[apport]  python2.5 crashed with SIGSEGV while running Listen 0.5-0ubuntu2" [Medium,Fix committed]  https://launchpad.net/bugs/86744
<Lathiat> and what package handles the logout screen? (the livecd when you hit restart just logs out and goes back to the gdm login screen)
<pitti> doko: ah, it's because it calls python -OO /usr/lib/listen/listen.py
<Lathiat> is that a gnome-session or gdm thing?
<pitti> doko: apport currently only looks at the second argument, not the third
<doko> pitti: hmm, ok, discard the options =)
<pitti> doko: sounds reasonable; can you please file a bug?
<pitti> doko: actually, don't bother
<Chipzz> pitti: please take a look at bug 66908, should be an easy fix
<Ubugtu> Malone bug 66908 in linux-restricted-modules-2.6.17 "nvidia-glx-config does not work any more" [Medium,Unconfirmed]  https://launchpad.net/bugs/66908
<pitti> doko: I just added this case to the test suite, so it fails now
<tepsipakki> does anyone know why we put wacom-devices in every xorg.conf?
<pitti> doko: this is enough for a reminder
<Chipzz> it's a regression from from something you fixed earlier ;)
<Adri2000> seb128: packages in NEW that are rejected now (ie. after the universe FF), will it be possible to reupload them?
<Chipzz> tepsipakki: more importantly, does anyone know why we put *3* wacom devices in xorg.conf? :)
<pitti> Chipzz: urgh, ok
<tepsipakki> Chipzz: right
<pitti> Chipzz: erm, -17? edgy?
<pitti> Chipzz: how come that I broke that?
<Chipzz> pitti: edgy-security
<doko> pitti: bug 87005
<Ubugtu> Malone bug 87005 in apport "discard options when looking for the first paramter" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87005
<Chipzz> -17.7 iirc
<seb128> Adri2000: it's always possible to upload, dunno if they will be accepted, ask Mithrandir
<Adri2000> Mithrandir: packages in NEW that are rejected now (ie. after the universe FF), will it be possible to reupload them (and get them accepted)?
<Chipzz> pitti: probably something that only got commited on one branch or something?
<pitti> Chipzz: I didn't commit it to a VCS, just uploaded it normally
<pitti> Chipzz: thanks for the pointer
<Chipzz> pitti: btw, I'm not saying you broke it, may be something someone else inadvertently broke ;)
<pitti> Chipzz: right
<iwj> Does apt modify /var/lib/dpkg/available ?
<cjwatson> no
<cjwatson> the only way to get that updated if you're using apt (to my knowledge) is 'dselect update'
<iwj> I thought so.  Someone has a weird corruption in it which looks like a localised corruption.
<iwj> Err, localised memory corruption in dpkg or dselect, I mean.
<tepsipakki> which one is ok: 1) change everyones font-paths in xorg.conf to /usr/share/fonts/X11 or 2) add /usr/share/fonts/X11/*
<dholbach> somebody please moderated my post to ubuntu-devel-announce
<Chipzz> seb128: is it normal for changes in /etc/mailcap not to show up immediately in <some file> -> properties -> Open With ?
<seb128> Chipzz: yep, GNOME doesn't use /etc/mailcap
<pitti> tepsipakki: definitively symlinking
<seb128> it's used the freedesktop database
<pitti> tepsipakki: sed'ing xorg.conf in some postinst just cries for trouble
<pitti> tepsipakki: shipping a symlink and making sure that new installs use the new paths are the right solution IMHO
<Chipzz> seb128: I'm not sure but I think it does; I installed acroread recently (clean edgy install), and acroread doesn't install a desktop file. Acroread didn't appear in that list until a reboot though...
<tepsipakki> pitti: ok :)
<seb128> Chipzz: if it's listed then it does install a .desktop
<tepsipakki> pitti: but I guess it's ok that new confs have new paths
<pitti> tepsipakki: yes, of course
<cjwatson> dholbach: done
<dholbach> cjwatson: thanks
<Chipzz> seb128: hrrrm you're right actually, it does install a .desktop file. makes me wonder why I had to log out for it to show up though, it should show up immediately
<seb128> Chipzz: you have to refresh the view of the folder
<seb128> Riddell: koffice-i18n-fa_1.6.2-0ubuntu1_all.deb koffice-i18n-ga_1.6.2-0ubuntu1_all.deb koffice-i18n-km_1.6.2-0ubuntu1_all.deb NEW binaries are empty, is that normal?
<Riddell> seb128: yes, they're just translations so they all get sucked out into rosetta
<seb128> Riddell: ok, thank you, and binaries are for universe then, right?
<Riddell> seb128: no, main
<seb128> hum
<Riddell> seb128: actually
<seb128> why are all the other packages to universe then?
<Riddell> others are in universe
<Riddell> seb128: yeah, universe it is
<seb128> ok, I'll accept them to universe
<Riddell> thanks
<seb128> accepted
<seb128> np
<hunger> Is it known that gnome-applets-data conflicts over some filenames with wesnoth-data?
<hunger> In fact gnome-applets-data conflicts with lots of packages over stuff in /usr/share/locale/*.
<pitti> doko: I'll do Till's cups upload and check it into the svn
<doko> pitti: thanks
<seb128> hunger: locale? like translations?
<hunger> seb128: It conflicts over /usr/share/locale/sl with wesnoth-data and lots of other dirs with other packages.
<Chipzz> mvo_: ping?
<seb128> hunger: that's a directory, there is no conflict over directory
<hunger> seb128: wesnoth-ei, iso-codes, coreutils, a2ps, console-common, gphoto2, apt, wesnoth-*, digikamimageplugins, kdiff3 trow, 
<seb128> hunger: packages can installed files to the same directory
<seb128> there is no file conflict there
<hunger> seb128: I get this message: " trying to overwrite `/usr/share/locale/sl', which is also in package wesnoth-httt"
<seb128> hunger: something is screwed to your bug then
<seb128> hunger: /usr/share/locale/sl should be a directory
<hunger> seb128: It is.
<seb128> what package do you try to install?
<hunger> seb128: I did dpkg -i --force-overwrite /v/c/a/a/gnome-applets-data[tab] .
<hunger> seb128: aptitude only reported the first such attempt to overwrite the directory. The rest only showed up with force-override.
<seb128> force-override is usually not a good idea
<hunger> seb128: I know... but it is only locales which I will never use, so I dared do it here.
<seb128> that's not locales
<seb128> that's a directory
<seb128> that error is really weird
<hunger> seb128: Yeap, but I hope it holds locales;-)
<seb128> maybe some package try shipping a /usr/share/locale/sl file
<seb128> well, you should not have a conflict over a directory
<seb128> packages are allowed to use the same directory
<seb128> that error doesn't make much sense, it's really weird
<hunger> seb128: dpkg -S /usr/share/locale/sl lists only this: gnome-applets-data: /usr/share/locale/sl
<seb128> $ dpkg -S /usr/share/locale/sl
<seb128> libwnck-common, devhelp-common, libgnomeprintui2.2-common, tracker, bug-buddy, gnome-session, libgnomeprint2.2-data, libgnomescan-common, gnome-applets-data, libgnomeui-common, iso-codes, vino, gnome-desktop-data, gnome-panel-data, libgnomevfs2-common, nautilus-data, totem-gstreamer, gedit-plugins, libgtksourceview-common, epiphany-browser, gaim-data, fast-user-switch-applet, alacarte, libgnome2-common, libpq4, coreutils, evolution-data-server
<seb128> -common, gconf-editor, capplets-data, libglib2.0-data, apt, gnome-media-common, amule-common, gnome-nettool: /usr/share/locale/sl
<hunger> seb128: I did a force-overwrite.
<seb128> hunger: you said that already, we loop
<hunger> seb128: So I am not surprised that nothing else is there anymore.
<seb128> what is the question exactly? ;)
<seb128> that's not a gnome-applets bug for sure
<seb128> something is screwed on your box
<_ion> hunger: For each package that was listed as conflicting (and why not also gnome-applets-data as well), try dpkg-deb --contents /path/to/its/deb | grep /usr/share/locale/sl
<_ion> hunger: Does any of the lines have '-' instead of 'd' as the first char?
<tkamppeter> pitti, biff
<pitti> tkamppeter: new cups? thanks for preparing it, will handle it today
<pitti> tkamppeter: a big sorry for forgetting to revert that recommends patch
<hunger> seb128: Seems you are right. I just reinstalled kdiff3 and that went well (it conflited over /u/s/l/ta before).
<tkamppeter> pitti, I have done the important point of undoing Mike's change of filtering the " (recommneded)" out.
<tkamppeter> pitti, I have also packaged a new foomatic-filters, see the other e-mail. It fixes the ugly bug 85569 which requires users to do a hard reset in certain cases.
<Ubugtu> Malone bug 85569 in foomatic-filters "foomatic-rip using 100% CPU" [Medium,Needs info]  https://launchpad.net/bugs/85569
<pitti> great!
<tkamppeter> pitti, can you approve UVF ER, where you are in the archive team now?
<pitti> tkamppeter: no, that's the release manager's job (Tollef)
<pitti> tkamppeter: archive team just means doing the grunt work, it doesn't have any decision power
<tkamppeter> pitti, is it enough to send the mail which I have sent to you to Tollef, or is a special proceeding required now for the UVF ER?
<pitti> tkamppeter: sending to Tollef is enough
<pitti> tkamppeter: this looks perfectly reasonable, so I don't expect any problems
<cjwatson> Mithrandir: we were to poke at moving powerpc out of cdimage
<cjwatson> Mithrandir: do you have a few minutes so that we can get this one before the meeting?
<cjwatson> s/one/done/
<tkamppeter> Mithrandir, biff
<tkamppeter> pitti, have sent it now.
<pitti> Riddell: could you please take a quick look at bug 86879 on i386? it's a gdb crash triggered by a kdeinit crash, and I wondered whether just attaching gdb to the running kdeinit and reading symbols already triggers the crash again
<Ubugtu> Malone bug 86879 in gdb "[apport]  gdb crashed with SIGSEGV in symbol_demangled_name()" [Medium,Needs info]  https://launchpad.net/bugs/86879
<StevenK> Neat, the debugger SEGVs.
<Mithrandir> cjwatson: sure, now's a good time.
<Riddell> pitti: attaching to my kdeinit doesn't cause any problems
<pitti> Riddell: alright, thank you
<pitti> Riddell: bt works, too?
<Riddell> pitti: yes
<cjwatson> Mithrandir: got a cdimage checkout handy?
<Mithrandir> cjwatson: we're not just going to do it on lithium?
<cjwatson> Mithrandir: unfortunately it's kind of awkward since there's that private deployment branch
<cjwatson> Mithrandir: we should make the relevant changes to the public branch first, IMO ...
<Riddell> although it does freeze starting anything new in KDE :)
<cjwatson> but sure, see the checkout on lithium
<cjwatson> Mithrandir: so, there are the following things to change: etc/config (default architecture selection; should be changed only for feisty and onwards); etc/anonftpsync* (mirroring, to move powerpc to cdimage/ftp-ports); bin/find-mirror (to take powerpc packages from the ports mirror); and bin/cron.* as appropriate
<Riddell> mvo, glatzor: have you looked at having software-properties let people set the apt proxy?
<cjwatson> Mithrandir: in bin/find-mirror, it needs to be changed only for feisty and onwards
<cjwatson> Mithrandir: (I'm making the changes already, FWIW, just talking you through them - is that ok? I still need to set things up so that you can push to all the branches in question)
<Mithrandir> cjwatson: yes, that's fine.
<cjwatson> Mithrandir: I generally prefer to write things like "only for feisty and onwards" as "case $DIST in warty|hoary|breezy|dapper|edgy) ... ;; *) ... ;; esac"
<Mithrandir> yup, that's fine.
<cjwatson> Mithrandir: just to ensure that we can still build older dists if we have to
<cjwatson> not that I imagine we'll care about warty again
<cjwatson> but it's a useful historical record if nothing else
<cjwatson> should probably be in a configuration file, but there
<Mithrandir> it's hard to express trees in a single shellscript config file.
<glatzor> Riddell: mvo: synaptic already does this. but the proxy configuration is currently quite a mess. you can set the proxy per user in the GNOME prefs, in synapitc, environment variable ...
<Riddell> glatzor: so synaptic will use the proxy set in gnome?
<Riddell> how does it tell apt to do that?
<cjwatson> hmm, build-image-set anonftpsync config selection will be fiddly
<cjwatson> Mithrandir: I'm basically grepping for other architecture names here, chiefly i386 and ia64 as good examples
<glatzor> Riddell: mvo: yes. sudo preservers the HTTP environment variable of the user
<glatzor> Riddell: but mvo can tell you more about this. issue. I am out running. see you
<cjwatson> Mithrandir: initial commit pushed to public branch (http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/); have a look?
<pitti> mvo: I just pushed some update-notifier changes FYI
<hunger> seb128: Looks like something was hosed on my system. I reinstalled everything that conflicted with gnome-applet-data and everything installed just fine.
<mvo> pitti: thanks, looking
<hunger> seb128: Sorry for the fuss.
<seb128> np
<cjwatson> Mithrandir: oh, hmm. It's not been moved on ports.ubuntu.com yet has it?
<pitti> mvo: no, just to remind you to bzr pull before committing
<mvo> Riddell: it will use (via gksu) the gnome proxy configuration
<cjwatson> Mithrandir: so that commit is wrong
<cjwatson> Mithrandir: in the private branch, only the buildlive script needs to be changed; I assume you don't want to trigger powerpc from here on in?
<mvo> pitti: icon+grammer?
<pitti> mvo: right
<cjwatson> though maybe the ports_daily-live build should
<Riddell> mvo: so gnome exports an environment variable and that gets picked up by apt?
<mvo> Riddell: yes (gksu)
<Riddell> mvo: which variable?  what does gksu have to do with it?
<Mithrandir> cjwatson: nope, it hasn't.  That's non-trivial with LP, AIUI.  Or it might just require the rsync comconfig to be changed.
<cjwatson> it's not LP, it's the rsync configuration, and it's hard because rsync can't be release-specific
<Mithrandir> ah, point.
<cjwatson> it needs to become debmirror or similar, which is harder on resources
<mvo> Riddell: http_proxy
<cjwatson> plus the installer would need to be told
<Mithrandir> it'd just need to be debmirror on the first level?
<cjwatson> true
<Mithrandir> cjwatson: I'm wondering if we should make buildlive trigger all ports arches; I took it out because ia64 was too slow, iirc.
<cjwatson> Mithrandir: what I'm doing now is adding separate buildlive invocations in the ports lines in crontab
<cjwatson> with ARCHES='ia64 powerpc'
<cjwatson> elmo: btw, I don't know if you have any plans regarding moving powerpc to ports somehow, but I just thought I'd make sure that you know it needs to happen far enough before a release that the installer can be updated
<elmo> cjwatson: meh
<Mithrandir> cjwatson: makes sense.
<cjwatson> Mithrandir: I think that's all safely done and deployed on lithium now, if you want to check that
<Mithrandir> cjwatson: looks sane to me.
<cjwatson> pitti: your activity report says you're blocked on archive.u.c not being reachable from machines in the DC; have you tried 'export http_proxy=http://squid.internal:3128/'?
<pitti> cjwatson: no, I didn't try; it wasn't necessary so far
<cjwatson> but you're blocked on it?
<pitti> more or less, yes
* cjwatson scratches his head
<pitti> doesn't seem to help either
<cjwatson> not sure how it can be not necessary *and* a blocker :-)
<pitti> cjwatson: I RTed it yesterday
<cjwatson> ok
<pitti> cjwatson: oh
<pitti> cjwatson: necessary> playing env tricks with the proxy, not network access
<pitti> cjwatson: well, it's not a hard block, I could write some python-apt script to emulate apt-get source and use security.u.c
<pitti> cjwatson: nice, the http_proxy trick works
<pitti> cjwatson: thanks
<pitti> Mithrandir: btw, if you are at hacking cd-image anyway, could you please do a grep -r for 'user.d'? Does it contain any commands to clean /var/lib/update-notifier/user.d for the live system? (I mailed Adam, but no reply yet)
<Mithrandir> pitti: that's not cdimage, that's livecd.sh.
<pitti> ah, I see
<Mithrandir> I'm not sure where that's stored atm.
<pitti> Mithrandir: ok, nevermind; thanks
* Mithrandir considers going home and catching a bit of rest before his head explodes.
<ubuntu_> Hello, I have a problem regarding the console fonts. I would like this problem to be fixed in the next Ubuntu release. Is this the right place?
<Mithrandir> ubuntu_: no, use the bug tracker for reporting bugs.
<ubuntu_> Mithrandir: I have reported the problem as a bug but I wanted to see whether I can get someone to help get it fixed.
<ubuntu_> Anyone?
<cjwatson> ubuntu_: what's the bug number?
<cjwatson> pitti: yes, it does 'rm -f ${ROOT}var/lib/update-notifier/user.d/*'
<ubuntu_> The bug number is 87031. Thank you for your attention.
<pitti> cjwatson: uh, can we stop that and instead fix the packages that leave unwanted notifications on virgin installs?
<cjwatson> I'm not promising to fix it, as this isn't a bug escalation channel; I'm just curious
<cjwatson> pitti: now that's an appropriate thing to mail Adam about ... :)
<ubuntu_> cjwatson: It's nevertheless better than not getting any help at all.
<pitti> cjwatson: alright, thanks for looking; at least I can stop breaking my head about that postinst :)
<cjwatson> pitti: pkgsel marks any pending notifications as seen rather than removing them
<cjwatson> pitti: (pkgsel/debian/postinst)
<cjwatson> unfortunately I didn't note why I did that - it was a change in breezy
<cjwatson> ubuntu_: running edgy or feisty?
<ubuntu_> cjwatson: running edgy eft (6.10
<ubuntu_> )
<cjwatson> ubuntu_: ok, that's fixed in feisty by doing it in the initramfs before usplash starts
<ubuntu_> cjwatson: Thank you very much. Are you really really sure that it is fixed for good?
<cjwatson> pretty certain, yes - I made the change in question
<ubuntu_> cjwatson: Thanks again. I am looking forward to the release of 7.04.
<cjwatson> testing is of course welcome, but it works for me whereas previously it didn't :-)
<ogra> cjwatson, btw, poke, poke .... any news on cipher=none ? 
<cjwatson> ogra: no, sorry
<pitti> hi ogra
<cjwatson> ubuntu_: we were a bit over-optimistic in edgy about what the kernel would let us do while usplash (or even X) was running
<ogra> cjwatson, is there a chance we will see it in feisty ? it's one of the blocking factors for ltsp upstream to drop support for the old release
<cjwatson> the new approach is much simpler and much more liable to work
<ogra> hey pitti 
<cjwatson> ogra: urgh, I really can't promise itt
<cjwatson> it
<ogra> ok
<ubuntu_> cjwatson: I guess I should download and check whether it works or not before 7.04 gets released.
<ogra> hey mpytasz 
<ogra> :)
<mpytasz> ping mjg59
<mjg59> Hi
<mpytasz> Hi, I was adviced to contact You, I have problems with wacom on Siemens tables (Lifebook T series)
<ogra> mjg59, i pointed mpytasz to you, he as one of these nifty touchscreen lappies ...
<mjg59> Install wacom-tools
<mjg59> Reboot
<mjg59> File bug if it doesn't work
<mpytasz> ok, wait, it's not that simple :)
<ogra> heh
<ogra> mjg59, he's running gentoo, and ubuntu apparently doesnt boot on the builtin SATA CDrom ... :)
<mpytasz> I am not using ubuntu, I'm using gentoo, I have everything I shouyld need (linuxwacom) and xorg configured properly, (ogra verified it)
<ogra> mpytasz, so grab the souce of wacom-tools :)
<mjg59> Sorry, I don't support gentoo
<mjg59> I have no idea what's in their kernel
<mpytasz> I tried wacdump and I get it working there however I am gettin bit errors
<ogra> mjg59, well, you just pointed in the right direction ... 
<mpytasz> ok, thanks anyway, I'll go to gentoo irc, however I already tried it there
<ogra> mpytasz, just check the wacom-tools source and make sure the set of modules we use in ubuntu is matching your gentoo kernel and it should work ...
<mpytasz> ok, thanks
<ogra> and next time we meet we'll get your damned CDrom running so you dont have excuses to not run ubuntu ...
<ogra> :)
<mpytasz> ogra, ok, Iif I won't make gentoo work with it 'll remind you ;)
<pitti> kwwii: uh, wobbly splash-down :)
<kwwii> pitti: hehe...is that good or bad?
<kwwii> ;-)
<pitti> kwwii: looks pretty cool
<kwwii> good to hear :-)
<kwwii> the logo on gdm and the splash will still change though :-)
<kwwii> but we are getting closer and closer
<h4writer> kwwii, do you have a screeny of it?
<kwwii> h4writer: the splash is the only thing I do not know how to make a screen off ;-(
<h4writer> (vmware:p), but is it already in the repos (than I can down it)
<kwwii> for some reason ubuntu won't install on my x60s...after it boots it no longer finds the cdrom in the docking station
<kwwii> in vmware, that is
<kwwii> so I gave up pretty quick :-)
<tepsipakki> kwwii: what a coincidence, I just installed X60s with feisty
<tepsipakki> but not using vmware
<tepsipakki> and after undocking the cdrom is lost
<kwwii> good thing I didn't try that then :p
<oxygen> hi
<oxygen> i cant join #ubuntu
<elkbuntu> oxygen, please see #ubuntu-ops
<bddebian> Heya
<tepsipakki> to finish the xorg-7.2 merge there are xorg-server and xorg left to do..
<tepsipakki> and they need reviewing
<seb128> people who want to help to review them are welcome ;)
<tepsipakki> you can find the current versions here, along with debdiff's against the latest version in Debian: http://users.tkk.fi/~tjaalton/xorg72/new
<tepsipakki> hopefully the changelogs are verbose enough :)
<tepsipakki> you can give comments either here, or on #ubuntu-x
<tepsipakki> I'm off now for a couple of hours, but will read the backlog later
<bddebian> Are we actually going to bring them into Feisty?
<tepsipakki> most of it is already in
<tepsipakki> ->
<seb128> bddebian: why doing the work if that's not the use it? ;)
<bddebian> I ask myself that often for Universe? ;-P
<ubuntu_> cjwatson: Are you there?
<pitti> BenC: uh, I just discovered and filed bug 87065; I already went crazy searching the bug in apport...
<Ubugtu> Malone bug 87065 in linux-source-2.6.20 "does not set CORE_REAL_RLIM correctly" [Undecided,Unconfirmed]  https://launchpad.net/bugs/87065
<FlyOnTheWall> crimsun, you about?
<BenC> pitti: ok
<cjwatson> ubuntu_: yes
<tkamppeter> pitti, the foomatic-filters package is accepted by Tollef, so foomatic-filters and cupsys can get uploaded now (tried to tell it earlier but my internet connection failed that time)
<pitti> tkamppeter: yup, saw it
<crimsun> FlyOnTheWall: I'm in lecture for ~8 additional hours.
<FlyOnTheWall> ok
<FlyOnTheWall> I'll return later on then, perhaps 
<FlyOnTheWall> enjoy your lectures
<ubuntu_> cjwatson: I have just installed Feisty Herd 4 and can confirm that the same problem exists... :(
<cjwatson> ubuntu_: bah. could you reopen that bug and attach /etc/default/console-setup and your initrd (either /initrd.img or /boot/initrd.img should be a symlink pointing to it), please?
<ubuntu_> cjwatson: Okay, I will do that as soon as I go home.
<cjwatson> thanks - it's probably an entirely *different* bug now, of course
<givre> cjwatson: while in the same context, could you also look at bug 86606 thanks 
<Ubugtu> Malone bug 86606 in usplash "[feisty] Screen corruption when usplash is enable" [Undecided,Confirmed]  https://launchpad.net/bugs/86606
<cjwatson> givre: totally different context, and I'm in a meeting right now
<cjwatson> givre: I see the same thing, but I don't even know where to start with debugging it
<cjwatson> hmm, interesting that adding setupcon fixes it - that's just plain weird
<cjwatson> ok, I'll have a look based on that later
<givre> cjwatson: thanks :)
<heno> Riddell: updated kubuntu winfoss: http://people.ubuntu.com/~henrik/winfoss/feisty/kubuntu/current/
<bluefoxicy> wow
<bluefoxicy> I filed a duplicate bug o.o
<bluefoxicy> the automatic bug search showed me like 10 bugs in the package, but none of them were what my bug was; once I filed it, it showed me a list of open bugs on the package, and the only other open one was the one I filed @_@
<Mithrandir> mdz: so, I'm thinking ubuntu-release as a contact point; anybody can subscribe, some bits which are important to the release are mailed there automatically, but it's not for general discussion.
<heno> Mithrandir: what kind of things will be posted, announcements of rebuilds?
<heno> or more about status of targeted bugs?
<Mithrandir> heno: no, it's not an announce list.  List of targetted bugs, for instance, yes.
<heno> ok
<Mithrandir> probably the daily mail from Colin about CD image problems.
<heno> Is there a canonical place for finding out that Beta images are ready and testable?
<heno> other than IRC?
<heno> does it go to devel-announce?
<mdz> Mithrandir: I think that once it's open for subscription, it's hard to prevent it becoming a discusison list
<Mithrandir> lp/ubuntu-iso-tests ?
<Mithrandir> mdz: nah, that's just moderating everybody except some people on a whitelist.
<mdz> heno: it ought to go to -devel-announce
<Mithrandir> mdz: do you really think so?  There will likely be at least one rebuild a day of most of the variants..
<mdz> Mithrandir: reply-to is probably as effective and lower overhead
<heno> Mithrandir: but who wants to check that unless they are subscribed to a test
<mdz> Mithrandir: I think perhaps we need a review of all the types of communication we do and where they go
<mdz> to me, -devel-announce is sort of "development-related announcements, often interesting even to non-developers"
<Mithrandir> mdz: quite possibly; that'd be nice to do with a big, clean wall and some crayons or pens.
<mdz> Mithrandir: or a wiki :-)
<heno> I still think a testing-announce list would cover the middle ground here
<heno> so that d-a can stay really low traffic
<heno> but people can get enough pings about test status
<Mithrandir> now, if LP grew RSS feeds for bug lists, it'd be trivial to get those notifications out, and people could get them on IRC, by email or whatever.
<seb128> asac: for bug #86265, you used the "Target To Release" option? I usually use the milestone rather for bugs that need to be fixed for feisty
<Ubugtu> Malone bug 86265 in firefox "[apport]  firefox crash [@totemScriptablePlugin::~totemScriptablePlugin] " [High,In progress]  https://launchpad.net/bugs/86265
<seb128> what other people are doing?
<seb128> having both that "Target To Release" and milestone is confusing
<asac> seb128: ok ... sorry for confusion
<seb128> no need to be sorry, I'm not sure to be right
<seb128> I used it as a pretext to ask on the chan ;)
<seb128> and to point that you can use the milestone
<asac> one more reason for a quick fix :) ... this will then disappear from your rader ->  no more confusion :)
* asac is gone
<kwwii> dholbach: got a bug about the new gdm stuff - just pushed a fix
<dholbach> kwwii: gracias - will upload it later on
<mdz> asac,seb128: yes, it's confusing, and we need to use the tools consistently.  the trouble is they've been changing...
<seb128> mdz: is milestone the right one to use?
<pitti> I think milestone is right for development release and 'target to release' for stables
<mdz> seb128: I don't think it ever makes sense to use 'target for release' for the development release
<pitti> it should not be possible to create a feisty task ATM
<mdz> I asked for that to be impossible in LP
<pitti> heh, snap :)
<seb128> ok, what I though
<mdz> seb128,pitti: please have heno communicate about this to LP
<seb128> I use the "target to release" for SRU basically
<seb128> mdz: ok
<igor> hi all ;-0
<tepsipakki> whoa, I'm swamped with feedback on the remaining xorg-packages :)
<tepsipakki> ..not
<pitti> tepsipakki: ?
<tepsipakki> pitti: nevermind.. I asked if someone had time to review xorg-server and xorg, which are the last bits of the R7.2 update remaining
<tepsipakki> and the most difficult ones
<tepsipakki> maybe we'll sort them out tomorrow
<pitti> good night everyone!
#ubuntu-devel 2007-02-23
<bddebian> Heya
<timetrap> can anyone chat with me about a gdebi issue I am having, I already asked on #ubuntu and got no response . . .
<timetrap> my /usr/local/lib/python2.4/sitepackages is empty . . . is that normal?
<ajmitch> yes
<timetrap> my add/remove programs in the Applications menu does not work niether does gdebi
<ajmitch> file a bug, if there isn't one there already
<timetrap> no its not a bug
<timetrap> I think I f'd up my system
<pitti> Good morning
<ajmitch> hi pitti 
<pitti> hey ajmitch
<pitti> moin slomo
<slomo> hi pitti, ajmitch :)
<pitti> Mithrandir: wow, only 12 ubuntu-archive subscribed bugs? how did you do that? :)
<Mithrandir> pitti: uh; I haven't touched those for a bit; I did NEW on Monday, iirc.
<pitti> Mithrandir: hm, then LP might be broken
<dholbach> good morning
<mdke> morning dholbach 
<pitti> hey dholbach 
<dholbach> hey mdke, hey pitti
<dholbach> mdke: shall i upload that ubuntu-docs check out?
<dholbach> mdke: seems my mail did not reach you
<dholbach> mdke: some problem with dreamhost
<mdke> dholbach: argh. Yes, please
<dholbach> ok
<dholbach> done
<mdke> :)
<mdke> thanks dholbach 
<dholbach> de rien
<mdke> dholbach: does anything need to be done in terms of poking through the new binary packages? do I have to file a bug/
<pitti> mdke: no, that'll happen regularly
<pitti> mdke: in fact, it's my archive day today, I'll clean up soon
<Mithrandir> mdke: no, they're in a queue we tend to regularly.
<mdke> yay
<pitti> argh, silly network-manager, stop clobbering my resolv.conf every 10 seconds
<infinity> s/network-manager/dhclient/
<StevenK> pitti: chattr -i ? :-P
<pitti> heh
<pitti> StevenK: no, /etc/dbus/event.d/25NetworkManager stop
<StevenK> That works too. :-)
<AnAnt> pitti: hello, what other info is needed in this sync request: https://launchpad.net/bugs/84857 
<Ubugtu> Malone bug 84857 in Ubuntu "Please sync gplcver 2.11a-3 (unstable) from Debian" [Wishlist,Needs info]  
<pitti> Hi AnAnt 
<AnAnt> pitti: hello
<pitti> AnAnt: https://wiki.ubuntu.com/SyncRequestProcess
<tepsipakki> pitti: could you sync libxrandr from experimental? It has a patch which makes for instance kdebase to compile again :)
<AnAnt> pitti: I did follow the steps there
<pitti> AnAnt: it's missing the changelog, components, description of Ubuntu delta, and an ack from an Ubuntu-dev member
<pitti> AnAnt: hint: just use requestsync, that'll do the right thing
<AnAnt> pitti: the perl script ?
<AnAnt> ok
<pitti> AnAnt: it's python, but yes
<StevenK> pitti: I didn't think your Python looked like Perl. :-)
<ajmitch> gplcver doesn't look to be in ubuntu
<AnAnt> pitti: btw, gplcver doesn't exist in Ubuntu
<AnAnt> yes, it doesn't
<pitti> ah, I see
<pitti> AnAnt: ok, then the 'ubuntu changes' bit doesn't apply, changelog is not necessary either
<pitti> tepsipakki: ubuntu changes can go?
<AnAnt> pitti: what is components ?
<ajmitch> still needs an ACK from an ubuntu dev
<pitti> AnAnt: main/universe/multiverse for Ubuntu, and main/non-free/restricted in Debian
<tepsipakki> pitti: oh, let me check
<StevenK> Poor restricted. pitti doesn't remember it.
<pitti> StevenK: well, I do, but I don't think that we ever synced something to it :)
<AnAnt> pitti: who would decide if it should go in main/universe/multiverse if it is new pakage ?
<pitti> AnAnt: depending on where it comes from in Debian; the archive admins will do, don't worry
<AnAnt> pitti: well, I did mention that it is in main
<pitti> AnAnt: I basically only need the ack from an ubuntu-dev
<pitti> AnAnt: right, sorry
<ajmitch> ah, I see it's fairly new (25 days) in debian
<tepsipakki> pitti: hah, didn't notice that it was uploaded last night :)
<AnAnt> pitti: ok, so only the ack now, how do I get that ?
<tepsipakki> I mean the current version has that fix
<pitti> tepsipakki: ok, so are all our changes in the experimental version, too?
<tepsipakki> yes, so a sync is safe
<tepsipakki> but not necessary
<tepsipakki> oh.. sync it
<pitti> tepsipakki: indeed; let's sync it then (I just compared changelogs)
<tepsipakki> the patch we have is not complete
<AnAnt> pitti: ok, so only the ack now is needed right ? how do I get that ?
<pitti> ajmitch: ^ do you know whether there is a documented process for that?
<pitti> or dholbach ^
<AnAnt> I know that LaserJock is responsible for scientific apps
<AnAnt> shall I ask him ?
<dholbach> pitti: for what? syncing a NEW package?
<ajmitch> pitti: the documented process is subscribing ubuntu-universe-sponsors, who will then ACK if appropriate & subscribe ubuntu-archive
<AnAnt> didn't I do so ?
<pitti> AnAnt: if you did, then your part is done
<ajmitch> you subscribed ubuntu-archive as well, before it had been checked
<AnAnt> ajmitch: I didn't do that
<AnAnt> ajmitch: I only added ubuntu-universe-sponsors
<AnAnt> didn't add Brian Murray either
<AnAnt> pitti: ok, thanks
<ajmitch> then bdmurray needs to be talked to :)
<AnAnt> k
<pitti> tepsipakki: hm, it's neither on incoming.debian.org nor on the Debian mirror we sync from; must be in limbo somewhere
<tepsipakki> pitti: oh, pity
<tepsipakki> well, let's sync it when it shows up
<pitti> tepsipakki: can you please ping me on Monday?
<tepsipakki> sure
<AnAnt> thanks
<pitti> tepsipakki: or file a sync request?
<tepsipakki> pitti: either way
<seb128> morning
<mvo> hey seb128
<seb128> hi mvo
<cjwatson> givre: poking at that X corruption thing, I'm beginning to think it's just a race condition
<cjwatson> givre: if I stick 'sleep 5' in rather than 'setupcon -f --force', I don't see visual corruption
<seb128> pitti: I'm taking a sync lock to grab the new libxrandr from Debian
<pitti> seb128: sure
<pitti> seb128: I tried syncing it before, but I couldn't get -4 in the sources lists
<seb128> pitti: hum, right
<seb128> there is no hurry, will try again later
<pitti> seb128: right, tepsipakki will ping me on Monday
<Tonio_> seb128: just fyi, there is a fix upstream svn for the old and annoying gtk-qt-engines, I'm just  packaging it
<seb128> Tonio_: packaging SVN might be a good idea, fedora seems to do that
<Tonio_> seb128: that's what the bug report says, indeed
<Tonio_> seb128: I'll probably have to fix startkde witch put the initial settings too
<ogra> Tonio_, so it wont crash gnome apps anymore ? 
<cjwatson> argh, we really need to get fsck<->usplash interaction working in feisty+1
<Tonio_> ogra: requires testing, but shouldn't :)
<cjwatson> it's a pain when you're trying to test usplash<->gdm interaction :)
<ogra> Tonio_, that'd be cool, all former versions either blacked out menus, broke colorsettings or made the apps crash
<Mithrandir> cjwatson: should be relativetly easy.. Just link fsck with libusplash.
* Mithrandir hides.
<ogra> and upstream wasnt ver active either
<cjwatson> *thwack*
<Amaranth> heh
<Tonio_> ogra: yeah I know.... pitty...
<Amaranth> isn't there a command you can call to update usplash?
<ogra> does anybody else experience a forced fsck on fresh installs ? 
<cjwatson> I think I've nailed the X display corruption (not a race condition after all); just trying to make sure stuff doesn't appear on the console now after usplash shuts down
<cjwatson> Amaranth: yes, but needs to be hooked into fsck progress
<ogra> i always get a fsck on first boot ... telling me the disk wasnt checked since 44xxx days
<Mithrandir> ogra: your clock is broken, then.
<ogra> Mithrandir, well, after the fsck is done and i have booted the clock and TZ settings are correct ...
<ogra> i'll check the clock values on my next test install next week ... but i'm pretty sure they are even right in the installer
<cjwatson> seb128: would you mind if I uploaded gdm shortly? I'm working on some fine details of its interaction with usplash
<cjwatson> (just the init script)
<ogra> cjwatson, anything i need to take into account for ldm ? 
<cjwatson> ogra: I'll check; I need to check kdm as well
<ogra> oki
<seb128> cjwatson: not at all, go for it ;)
<cjwatson> basically just to make gdm.init wait until the console actually changes (up to some reasonable limit) before exiting
<cjwatson> this avoids visible console noise from later init scripts
<ogra> right, then i'll likely need that as well
<cjwatson> does ldm.init shut down usplash?
<ogra> ltsp-client.init, yes
<cjwatson> ok
<ogra> ldm is just a screenscript executed b ythe ltsp-client init
<ogra> is it avoidable to do that via sleep ? 
<ogra> (ldm is very slow already)
<cjwatson> you only need to sleep if the console doesn't immediately change, and it's asynchronous
<cjwatson> i.e. ldm will already be starting up separately from the thing that's waiting for the active console to change
<Tonio_> ogra: the bad thing is that this will only fix new profiles, for exisint ones, you may have to just change fonts and theme in gnome once, loading on kde will not crap them again...
<ogra> well, i didnt notice any breakage with the cosole in ltsp yet ...
<cjwatson> at least that's what I'm doing for gdm; it won't slow the perceptible boot down at all
<ogra> probably ldm is slow enough ;)
<cjwatson> ogra: you won't have, due to a usplash bug I'm fixing right now ;-)
<cjwatson> this only came up because after fixing that usplash bug I started noticing console noise
<ogra> ah, k
<cjwatson> ogra: does ldm wait until the X server has started before returning control to ltsp-client.init?
<ogra> iirc it never returns control to the initscript ...
<cjwatson> uh
<cjwatson> maybe I had better read the source
<ogra>         for screen in $(env | awk -F= '$1 ~ /^SCREEN_/ { print $1 }'); do
<ogra>             num=${screen##SCREEN_}
<ogra>             start-stop-daemon --start -b --exec /usr/lib/ltsp/screen_session -- "$num"
<ogra>         done
<seb128> cjwatson: BTW how is the usplash interaction when you restart without using gdm?
<ogra> the ldm script itself only runs: exec ldm vt$ttynum :$displaynum
<cjwatson> seb128: usplash gets stopped in the last init script
<seb128> cjwatson: I was thinking changing gnome-session to use gnome-power-manager rather than gdm for restart and shutdown
<seb128> but that will probably be for next cycle
<cjwatson> seb128: oh, I'm not looking at shutdown, only startup
<seb128> ah ok
<ogra> cjwatson, the ltsp-client initscript explicitly calls /etc/init.d/usplash start
<ogra> so it should be fine
<cjwatson> ogra: it'll need to be updated, then. Is it in bzr?
<ogra> i'm not sure i pushed the recent changes, but yes, it is
<ogra> (i dont have the bandwith here to push now)
<cjwatson> ogra: I'll give you a branch later then
<ogra> well, i can look at the gdm debdiff :) 
<cjwatson> ogra: /
<cjwatson> er
<ogra> no prob for me to add it then ...
<cjwatson> ogra: is ~ogra/ltsp/feisty-ltsp the one I should branch from?
<ogra> right
<Tonio_> seb128, ogra: gtk-qt-engine, kdebase and kubuntu-default-settings including new default config are uploaded
<ogra> i'll check how it behaves in edubuntu then ... if its fine, t can go on the add-on CD 
<ogra> Tonio_, thanks :)
<Tonio_> ogra: you're welcome :)
<Tonio_> ogra: best is to makes tests on a new and clean profile of course
<ogra> right
<ogra> i'll test intensively with the next milestone isos
<toystory2> hi. my box ubuntu 6.06 does not have /etc/ld.so.conf. i asked in #ubuntu, but nobody knows why. anybody please help me?
<toystory2> why ld.so.conf disapper from my 6.06 box?
<cjwatson> kdm doesn't shut down usplash, so I guess I don't need to touch it
<AnRkey> hi all
<doko> hmm, feisty did get the order of the disk controllers right (as set in the bios), but that did break my upgrade from edgy ...
<dholbach> Mithrandir: I changed "FeatureFreeze Universe" to "NewPackagesFreezeUniverse" to be less ambiguous - and I'll wiki it
<dholbach> (on FeistyReleaseSchedule)
<cjwatson> argh, crackful horribleness. gdm/debian/patches/15_usplash.patch patches gdm/debian/initt
<cjwatson> -tt
<cjwatson> -t
<cjwatson> (sorry)
<AnRkey> where can i put a feature request in for feisty?
<Hobbsee> AnRkey: [23:55]  <ubotu> A spec is the details (specifications) of the components that make up software or a device. See: https://launchpad.net/ubuntu/+specs for specifications in Ubuntu.
<Hobbsee> it's probably too late for feisty, though
<cjwatson> almost certainly. feature freeze was last week.
<seb128> AnRkey: don't create a spec for a minor wishlist though
<seb128> AnRkey: what is the feature request you want?
<AnRkey> well something that i have been begging for for a long time
<AnRkey> and i think others would love too
<AnRkey> its a mouse setup wizzard
<AnRkey> something that would allow the user to set each button on the mouse
<mjr> m36
<mjr> oops
<AnRkey> this would be perfect for logitech mx5xx series and so on
<AnRkey> also handicapped users could use it to set mice up as well as left handed people
<AnRkey> is taht something small?
<AnRkey> seb128: how would i request this
<AnRkey> ?
<seb128> AnRkey: we are not likely to work any time soon, that doesn't look like a high priority feature and we have lot to do
<cjwatson> ogra: ok, ~kamion/ltsp/usplash-interaction pushed to bazaar.launchpad.net and should be ready for you to merge once it's mirrored to http
<seb128> AnRkey: feel free to open a specification for it, it'll not likely to be picked any time soon though
<jdub> whoa, fisty's moving to xcb-xlib?
<seb128> jdub: moving? just updating to xorg 7.2
<seb128> jdub: that's a new package, it doesn't replace libx11
<jdub> mmm, changelog is mildly unclear
<jdub> that would be ambitious :-)
<ubuntu> cjwatson: Are you there?
<Hobbsee> ubuntu: contentless pings tend to get ignored.
<Hobbsee> ubuntu: seeing as people are busy
<ubuntu> Hobbsee: I had a discussion with cjwatson yesterday, so I thought that he would remember me.
<Hobbsee> ubuntu: right.
<ubuntu> Hobbsee: I have question. How can one reopen a bug in Malone?
<ubuntu> a question, that is.
<jdong> change the status from rejected to confirmed or unconfirmed
<Hobbsee> go to the bug, click on the title of it, set it back to unconfirmed, adn comment on it
<cjwatson> ubuntu: yes?
<ogra> cjwatson, great, thanks ... not sure when i'll have net access again, but i'll do it asap ... 
<ubuntu> cjwatson: I couldn't reopen the bug... That's the problem.
* ogra has to leave the room
<cjwatson> ubuntu: BTW, "ubuntu" is such an anonymous nick that I wouldn't necessarily assume it was the same person. I would suggest using a more descriptive nick on Ubuntu channels
<cjwatson> ubuntu: remind me of the bug number?
<ubuntu> cjwatson: 87031
<zzz_> Okay, I changed my nick to something less anonymous. I will converse with you with this nick from now on.
<cjwatson> zzz_: reopened
<zzz_> cjwatson: Thanks. I will attach my /etc/default/console-setup and initramfs to the bug right now.
<zzz_> cjwatson: (As you might remember, you asked for those yesterday.)
<cjwatson> yep, thanks
<cjwatson> zzz_: could you tell me what you see when you press the  key?
<cjwatson> zzz_: (before fixing it up with setupcon)
<zzz_> cjwatson: I see an ASCII symbol character. I can reboot and say for sure if you want.
<cjwatson> zzz_: just dotted "i" then?
<cjwatson> or something else?
<cjwatson> I'm going to try in a minute, just seeing if I can save myself the reboott
<zzz_> cjwatson: Something else. Let me reboot and say it for sure. I will be right back.
<cjwatson> ok, thanks
<seb128> mvo: around?
<Hobbsee> wow, someone found u-u-s list
<mvo> seb128: yes
<seb128> mvo: is there some apt feature than make type-handling installed?
<seb128> mvo: it wants to install it when trying to install the new xorg
<cjwatson> it's probably a bogus dependency on something that type-handling provides
<seb128> mvo: the package has a Depends on "sparc-utils | not+sparc" and I'm wondering if that the "not+sparc" which makes it wants to install it
<seb128> cjwatson: ah, right, it Provides that
<seb128> hum
<cjwatson> oh, this is an architecture: all package, right?
<seb128> cjwatson: yes
<cjwatson> honestly, the least evil fix would be to convert it to architecture: any and use substvars, imo
<seb128> or just drop the Depends? ;)
<cjwatson> it probably is a real dependency on sparc, which we support
<seb128> hum, right
<zzz_> cjwatson:  creates an "A" character and a box next to it. If I try echo "" > test.txt and then see that test.txt file in X, I see a little superscript 1 character.
<zzz_> cjwatson:  prints out AC.  prints out A and a circle with a horizontal line below it.  prints out A and a small 1/4 fraction.
<cjwatson> does the A character for  have two dots over it, by any chance?
<zzz_> cjwatson: No.
<cjwatson> either way, it sounds like it hasn't set the character encoding to Unicode
<cjwatson> zzz_: what does 'locale charmap' say?
<zzz_> cjwatson: kbd_mode reports unicode. 'locale charmap' reports UTF-8
<cjwatson> zzz_: experiment: does this fix it? /bin/echo -n -e '\033%G' >/dev/tty1
<cjwatson> kbd_mode is slightly different - that's keyboard input mode rather than terminal output mode
<zzz_> cjwatson: Now  prints out only a box and other international (Turkish) characters print out single characters. (Instead of two.)
<mvo> seb128: where is the package? can I have a look?
<zzz_> cjwatson: It looks like the font is not setup.
<cjwatson> yeah, just trying to figure out why really
<cjwatson> /etc/console-setup/boottime.kmap.gz in your initrd is all wrong
<seb128> mvo: http://people.ubuntu.com/~seb128/xorg, that's Depends on "sparc-utils | not+sparc"
<cjwatson> zzz_: what did you use to do the installation? the desktop CD or the alternate install CD?
<zzz_> cjwatson: I just installed this system. I used the alternate CD.
<cjwatson> ok, that's useful to know, thanks
<zzz_> cjwatson: I also installed and uninstalled console-data package, but the program existed before I did that too.
<zzz_> cjwatson: Sorry, I meant to say 'problem' instead of program.
<mvo> seb128: *ick* I see. it is indeed the type-handling provides that makes it installed. how evil
<cjwatson> zzz_: console-data is obsolete
<zzz_> cjwatson: I used console-data to be able to switch the keyboard map to something else - such as US English.
<mvo> seb128: need to run, bbl in ~15
<seb128> mvo: see you
<zzz_> cjwatson: Maybe you could install a new system on a spare computer and see what happens.
<cjwatson> no worries, I'm going to, just trying to find out as much as possible first
<zzz_> cjwatson: Shoot. I am at your service. :)
<cjwatson> the keymaps in console-data are still unmaintained and bogus. I probably need to write a wrapper script to make it easier to use the console-setup infrastructure to change the keyboard map on the fly
<cjwatson> "ckbcomp -model pc105 us '' '' | sudo loadkeys" is probably about the simplest way to do it at the moment
<zzz_> cjwatson: For the record, the trqu keymap that comes with console-data is better than Ubuntu's default trq.
<cjwatson> zzz_: can you give me specific examples? the console keymaps are now generated from the X keymaps on the fly, so if there's a problem, either we're using the wrong X keymap or the X keymap probably needs to be fixed
<zzz_> cjwatson: Caps-lock does not work properly so trqu uses Shift lock instead.
<zzz_> cjwatson: In Ubuntu's default trq, when one presses Shift- with Caps-Lock on, one gets 1 insead of I.
<cjwatson> ah, that problem
<cjwatson> that's really more an irritating kernel bug, but maybe some kind of keymap-specific workaround is possible
<cjwatson> in edgy, caps lock was mapped to shift lock across the board, but this was horribly confusing for many keymaps whose users weren't used to thatt
<zzz_> cjwatson: I don't know which way would be the best: making caps-lock just work versus the other way around.
<cjwatson> probably has to be keymap-specific, informed by what console-data did
<zzz_> cjwatson: Yes, as far as I know only Turkish users need Shift-Lock.
<cjwatson> grepping through console-data supports you on that, yes
<zzz_> cjwatson: Or are there others who need it?
<cjwatson> there was a weird thing for French where Shift+Caps-Lock was mapped to Shift-Lock
<cjwatson> not sure how to deal with that, but that's separate really
<seb128> cjwatson: something like http://paste.ubuntu-nl.org/7207/ looks correct for that xorg problem?
<cjwatson> seb128: looks plausible except that you'll also need to move bits in debian/rules from binary-indep to binary-arch
<seb128> cjwatson: which one?
<seb128> there is nothing specific to binary-indep apparently, out of the "dh_gencontrol -- -VF:XServer-Xorg-Detect-Depends=$(XSERVER_XORG_DETECT_DEPENDS)" which is not for xorg
<cjwatson> seb128: oh, right, ok, now that I look at the context I see you're right
<cjwatson> zzz_: ok, fixed the Shift Lock thing for my next console-setup upload
<seb128> good
<zzz_> cjwatson: Thanks.
<cjwatson> zzz_: any other deficiencies in the current Turkish keymap?
<zzz_> cjwatson: I haven't used it long enough. That's the only problem I have encountered.
<zzz_> cjwatson: (Repeating in case you didn't see this message:) In Ubuntu's default trq, when one presses Shift- with Caps-Lock on, one gets 1 insead of I.
<cjwatson> oh, I didn't realise that was a separate item
<cjwatson> zzz_: fixing the Shift Lock thing fixes that.
<cjwatson> (tested)
<zzz_> cjwatson: That's good to hear. Thank you.
<zzz_> cjwatson: One more thing. I told you that I used the Alternate CD to install this system. Before doing this, I had tested the Desktop CD too and this console font problem exists for both CDs.
<cjwatson> zzz_: ok, that's an interesting data point too, thanks
<ogra> cjwatson, is there any documentation how the selection of the console keymap from the X settings happens ? it would be intresting if i can get that into ltsp ... but i dont have an xorg.conf during boot 
<cjwatson> ogra: should already be handled for you by the installer
<cjwatson> console-setup is meant to save all the bits it needs so that it doesn't need X during boot
<ogra> for ltsp chroots ? 
<cjwatson> providing that you have console-setup and dependencies installed
<ogra> i plainly bootstrap 
<ogra> no installer involved ...
<bddebian> Heya
<cjwatson> oh, you'd need to configure console-setup then, sure
<ogra> but console-setup is there indeed
<ogra> ok, i'll look into that
<ogra> thanks
<cjwatson> copy /etc/default/console-setup and /etc/console-setup/*.gz from the host system, or words to that effect
<cjwatson> the configuration is actually separate - xorg.conf isn't used post-installation
<ogra> ok
<cjwatson> you could also run setupcon --save-only in the chroot rather than copying /etc/console-setup/*.gz, which might be better
<ogra> yeah, that sounds way cleaner
<cjwatson> or dpkg-reconfigure console-setup (or thereabouts) if you have xorg.conf in the chroot already
<ogra> i have to do a bunch of locale fixes next week as well, looks like it fits in there :)
<seb128> somebody wants to test the xorg update before upload? http://people.ubuntu.com/~seb128/xorg
<seb128> dholbach: ^ ? ;)
<dholbach> sure
<bddebian> "There's no better test than production.." ;-)
<seb128> dholbach: you can use "deb http://people.ubuntu.com/~seb128/xorg /"
<dholbach> neat
<cjwatson> doesn't it need to be ./ ?
<cjwatson> didn't know / worked
<dholbach> seb128: shall I build and test and upload it for amd64?
<seb128> cjwatson: both work apparently
<cjwatson> neat
<seb128> dholbach: if you want, kylem was also going to try on amd64
<dholbach> ah ok
<seb128> dholbach: that's like 40 seconds to build the package though
<dholbach> :)
<seb128> but having binaries only make easier to upgrade only the ones you have installed ;)
<dholbach> you need to fix the Maintainer - no?
<dholbach> oh, no, sorry
<seb128> dholbach: ?
<dholbach> nevermind
<dholbach> restarting X
<seb128> k
<dholbach> looks good
<dholbach> on i386
<seb128> dholbach: cool
<dholbach> deb http://people.ubuntu.com/~dholbach/feisty/xorg ./          for amd64
<dholbach> amd64 looks good too
<ardchoille> Isn't this a potential security problem in Ubuntu?  http://ubuntuforums.org/showthread.php?t=368438
<goliath23> hi
<seb128> dholbach: excellent
<goliath23> to what palette do the .text-foreground etc. entries in the usplash-ubuntu-theme.c file relate?
<dholbach> seb128: are the drivers next?
<seb128> dholbach: no, server is next
<goliath23> it seeems that its not the palette of the used splash images... 
<seb128> ardchoille: doesn't look like a security problem, other people should not be authorized to copy binaries to your user directory, if they are that's the problem
<goliath23> is there something like a "default (k)ubuntu palette" that is used by usplash, too?
<ardchoille> seb128: I was more worried about compromised systems and such. But i see your point.
<seb128> ardchoille: if the system is compromised you have an another problem than you user bin path
<ardchoille> True
<ardchoille> seb128: Ok, thank you for that info :)
<seb128> often the user config is used before the system one
<seb128> that allow users to make local changes if they want
<ardchoille> So, I should search all the dirs in $PATH before naming a bash script? I can do that.
<seb128> ardchoille: don't search, just type the name and look what happens
<ardchoille> Ah, yeah, good point.
<ardchoille> Ok, I won't worry about it.
<jcole> is this ffmpeg x11 patch in feisty? -> http://ubuntu.wordpress.com/2006/06/08/how-to-create-a-screencast-in-ubuntu/
<jcole> this appears to be the best way to record beryl/aiglx screencasts
<AnRkey> seb128: thanks, ill add a spec for it there and another for the joystick idea.
<bddebian> Damnit, wxwidgets2.8 has a /debian dir in the tarball
<seb128> bddebian: that's fine, just mv it away and copy the one from the package
<bddebian> What do you mean by mv it away?
<pochu> bddebian: remove it? :)
<bddebian> seb128: Do you mean remove and re-pack?
<bddebian> Gah meeting, bbiab
<seb128> bddebian: repack what? just untar, move the debian dir away and use the one from the previous package, that will go to the diff.gz
<pochu> bddebian: are we going to have wwx2.8 in feisty?
* poningru hugs \sh_away 
<poningru> we're here for you dude... if you need anything at all
<cjwatson> zzz__: ok, I think I see the problem now - the font wasn't being copied into the initramfs due to a set of bugs in the installer integration
<cjwatson> still beating on it
<zzz__> cjwatson: Good to hear that you're making progress. Thanks once again. If there's anything I can do for you, please let me know.
<seb128> There is an xorg-server candidate update available on http://people.ubuntu.com/~seb128/xorg-server if anybody wants to try
<seb128> I'm away for around an hour, will read my IRC when I'm back if anybody has comments on it
<cjwatson> zzz_: thanks to you - this is a nasty problem on fresh installations that I was unaware of. Upgrades were fine.
<zzz_> cjwatson: I found it strange that upgrades were not affected. Maybe because of the way initramfs was generated?
<cjwatson> zzz_: it's because the bug was specific to the installer glue
<cjwatson> /etc/default/console-setup wasn't being copied into the target system at the right time
<cjwatson> (plus other similar kinds of problems)
<zzz_> cjwatson: I see. Hopefully not a hard problem to solve.
<dholbach> brb
<zzz_> cjwatson: I will be back within one or two hours. See you later.
<rtg> mjg59: ping
<bddebian> seb128: The current package is 2.6, this will be 2.8 :-)
<bddebian> But yes I will look at the current debian dir from 2.6
<[H] 3b0R> is rhythmbox beeing replaced with audacious
<LaserJock> [H] 3b0R: not that I know of
<[H] 3b0R> hmm weird, according to audacious homepage, audacious is included in fiesty
<finalbeta> java seems to cause some troubles for users on the forum. i'm guessing it's that native Java spec. Looks like a real bad idea.
<LaserJock> [H] 3b0R: sure, it's included, just not the default I don't think
<LaserJock> [H] 3b0R: audacious is in the Universe repo
<[H] 3b0R> what are you working with on ubuntu?
<LaserJock> [H] 3b0R: how do you mean?
<[H] 3b0R> your responsebility of distro?
<[H] 3b0R> what you maintain etc...
<LaserJock> oh, I'm just an ordinary volunteer developer
<Amaranth> ubuntu-science!
<LaserJock> I mostly work on science packages
<[H] 3b0R> ok
<LaserJock> do some doc writing
<Amaranth> or is it called motu-science?
<LaserJock> and work on Edubuntu a little bit
<LaserJock> Amaranth: motuscience on LP
<LaserJock> Amaranth: ML is ubuntu-sceince
<Amaranth> heh
<Amaranth> confusing
* gnomefreak sticks with firefox :)
<LaserJock> well, ubuntu-science should be more generic
<LaserJock> [H] 3b0R: most of us are just volunteers that help out where we can
<[H] 3b0R> the only way im involving in ubuntu is to report every single bug i see:)
<LaserJock> good
<LaserJock> that helps quite a bit
<[H] 3b0R> yes
<[H] 3b0R> the buggest problem with bugs is that people don't report them
<[H] 3b0R> they think its like on windows: no one cares
* givre just tested the new usplash, and hugs cjwatson :)
<dholbach> seb128: the new xorg-server is not happy :)
<Amaranth> givre: is usplash to gdm smoother now?
<givre> Amaranth: no, it just that i got some weird console noise previously with usplash enable : bug 86606
<Ubugtu> Malone bug 86606 in usplash "[feisty] Screen corruption when usplash is enable" [High,Fix released]  https://launchpad.net/bugs/86606
<seb128> dholbach: what does it do?
<dholbach> seb128: no xorg, does not load /usr/lib/xorg/modules/libint10.so
<dholbach> "no screens"
<dholbach> it also complained about wacom and dri, so I disabled those, but still no love
<bddebian> seb128 or dholbach: Do either of you happen to know why wxwidgets2.6 is a native package?
<seb128> dholbach: could you join #ubuntu-x
<seb128> bddebian: mistake probably
<bddebian> OK
<dholbach> bddebian: no idea - doko might know - but he's on the way to fosdem - try checking out older packages
<Amaranth> givre: oh, that might be something i was getting too
* Amaranth waits for launchpad to load
<Amaranth> nope, nevermind
<Amaranth> mine is almost certainly nvidia problems
<LaserJock> dholbach: thanks for the ubuntu-docs upload, hope I didn't mess up your beautiful CDBS up ;-)
<Amaranth> and it's completely random :)
<dholbach> LaserJock: it looked good
<cubicool> Can anyone link me to SOMETHING (I've been googling for hours trying things that simply do not work) on setting up a simple remote apt repository?
<Treenaks> cubicool: falcon
<cubicool> I just cannot get it to work at all--which is frustrating, since setting up a YUM repo was effortless.
<cubicool> The word falcon, with no context, is supposed to mean--?
<cubicool> Is that a package itself perhaps?
<LaserJock> yes
<Treenaks> cubicool: falcon is a "repository builder"
<LaserJock> cubicool: how many packages do you plan on?
<cubicool> one.
<cubicool> Maybe up to two or three later. But really, just one.
<LaserJock> I'd just use apt-ftparchive then
<cubicool> Well, the server won't be hosting FTP is that's a requirement for that...
<LaserJock> with apt-ftparchive you just do it on the machine that's serving the repo
<LaserJock> or you can do it locally and scp the files over
<cubicool> Well, my real question is: does the server need to be running ftpd or similar for apt-ftparchive to work. I'm not authorized to do any installation here...
<LaserJock> no
<LaserJock> it doesn't require anything
<cubicool> Well, apt-ftparchive is generating the exact same Packages file dpkg-scan does...
<LaserJock> yeah, basically
<cubicool> So, it may be the client's sources file is wrong...
<cubicool> deb http://downloads apt/
<cubicool> I was told the last "/" is necessary to tell apt that this is a "simple" repo, not a full-heiarchy kind of thing...
<LaserJock> try something more like deb http://dowloads/apt/ ./
<cubicool> Well, taht certainly causes different results during "apt-get update"; failures, to be more specific, but that's at least a change. :)
<LaserJock> cubicool: this is kinda off-topic for here, can we maybe move this to #ubuntu-motu real quick?
<jcole> hey guys, these guys just went GPL, it's a good alternative to M$ Sharepoint, might want to add it to the repos ->  http://www.alfresco.com/
<jcole> i saw their demos at linuxworld
<sabdfl> jcole: good demos?
<cjwatson> givre: glad it fixed it for you
<jcole> sabdfl: ya, it's very professional and works in most linux browsers
<jcole> sabdfl: http://www.alfresco.com/products/ecm/screenshots/
<jcole> sabdfl: http://www.alfresco.com/products/ecm/tour/tour.html
<jcole> cp -f /boot/grub/splashimages/fiesta.xpm.gz /boot/grub/splash.xpm.gz
<jcole> #Hack out for kubuntu
<jcole> grep -v splashimage /boot/grub/menu.lst > /boot/grub/menu.lst.tmp; mv /boot/grub/menu.lst.tmp /boot/grub/menu.lst
<jcole> update-grub
<jcole> oops
<jcole> crap
<bddebian> Holy crap wxwidgets builds a ton of binaries... Sheesh
<LaserJock> hehe
<LaserJock> merging wxwidgets was about the first merge I ever tried
<LaserJock> it was a wonderfully confusing time ;-)
<bddebian> Great thanks
<mdz> asac: I had firefox crash directly after my most recent upgrade, which included totem-mozilla.  have you seen that happen before?
<sharms> mdz: That has happened to me also, I believe I saw a bug filed on it
<seb128> mdz: isn't that fixed? I workarounded it from totem some days ago
<seb128> there was a problem with undefined symbols because firefox stopped to link with libxpcom
<mdz> seb128: it happened upgrading to 2.17.92-0ubuntu1 for me
<seb128> dunno if you are speaking about that
<seb128> ah
<seb128> different problem then
<mdz> seb128: yes, I saw that earlier problem
<mdz> but I think this is different
<seb128> ok, dunno about it then
<jcole> mdz: i have never got totem-mozilla to work, i've always removed it and installed mozilla-mplayer instead... it removes the ubuntu-desktop meta package but at least i can watch videos... also mplayer can send cookies which is required for our intranet authentications
<mdz> jcole: works fine for me
<seb128> jcole: you are welcome to report bugs if you want to get problems fixed one day
<seb128> we don't fix problems we don't know about
<mdz> jcole: and mplayer is not an option for the default
<sharms> looks like clairvoyance loses again
<mdz> seb128: I'm also seeing my panel crash in gtk_widget_reset_rc_styles; have you seen that?
<seb128> mdz: during upgrade?
<mdz> seb128: no, at odd times (once late last night running totem, once just now)
<mdz> this time I had just upgraded, but not before
<seb128> during upgrade that's likely bug #85776
<Ubugtu> Malone bug 85776 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV on package installation, valgrind log required" [High,Confirmed]  https://launchpad.net/bugs/85776
<seb128> 39 dups already :/
<seb128> I'll have a look at fixing the GTK invalid read spotted by valgrind for the herd next week
<seb128> not sure if there is an another problem
<seb128> most of those crash happens to random place or to malloc, that's likely a memory corruption somewhere
<mdz> pitbug 85776 has another example of that weird file:// bug with apport
<mdz> er, pitti
<mdz> seb128: yes, top is malloc for me
<seb128> I'll ask for people to run their panel with valgrind for some time if there is still crashes once the GTK bug is fixed
<seb128> mdz: that file:// problem has been spotted I think, it happens to people who used the firefox "set firefox as default function"
<seb128> s/function/browser
<seb128> it sets the gconf key to '/usr/lib/firefox/firefox-bin "%s"' or something like that
<seb128> which is not a correct key
<seb128> especially the "" around the %s
<seb128> and that breaks gnome-open
<mdz> seb128: oh, so it's a firefox bug?
<seb128> yep
<seb128> asac knows about it and is going to fix it I think
<seb128> bug #83974
<Ubugtu> Malone bug 83974 in python2.5 "webbrowser incorrectly handles quoted arguments" [Undecided,Confirmed]  https://launchpad.net/bugs/83974
<seb128> ah, pitti moved it to python, must have changed since we discussed it
<seb128> well, firefox is going to be changed to use "firefox %s" also I think
<asac> seb128: yes ... gconf is broken for global install. I have a hack for that in debian thunderbird, but dunno if we should using that in ubuntu.
<asac> I always though that "automatic update of gnome default application" was disabled.
<seb128> asac: it's not automatic, I think I sometime got the "do you want to make firefox the default browser" question when starting it
<asac> yes ... that's what I mean ... that should not happen
<seb128> note that I don't use firefox often, I'm using epiphany
<seb128> maybe there is a bug making that sometime the question is asked then
<asac> maybe it was a temporary bug and some user ended up with a screwed default app setting?
<seb128> might be
<seb128> still, it should be easy to make firefox write "firefox %s" rather than "/usr/lib/firefox/firefox-bin "%s"" 
<seb128> no?
<asac> yes and no ... would be a hardcoded fix
<seb128> I've not looked at the code
<asac> i have :) ... would be a hack. Clean solution would need some work on build system too
<seb128> but it's probably easy to make it not espace the URI when writting the gconf key no?
<_ion> seb128: Btw, thanks for uploading compiz-extra! :-)
<seb128> _ion: np
<seb128> asac: the path is not a problem, what is a problem is the extra ""
<seb128> whatever code put them there can probably be modified to not do that no?
<seb128> or the code do something else than modifying the gconf key?
<asac> anyway ... got to go, will look on monday ... or maybe at the weeken.
<asac> seb128: yes ... if the quotes are the problem the fix might be  easy
<seb128> ok
<seb128> see you later, enjoy your WE
<asac> u2
<seb128> I call it a week, see you on monday
<elmo> any forums folks alive?
#ubuntu-devel 2007-02-24
<aSt3raL> when will X be fully merged?
<Hobbsee> aSt3raL: when it's done.
<aSt3raL> haha ok
* bhale hugs Hobbsee 
* Hobbsee hugs bhale :)
<Hobbsee> how's that for an answer?
<aSt3raL> it was more of a 'quit bugging me' than an answer :p
<Hobbsee> well...
* Hobbsee isnt merging X
* aSt3raL isnt either
<aSt3raL> Hobbsee: so what do you do?
<Hobbsee> aSt3raL: i work on the kubuntu side of things, do a fair bit of bug triage, and am a MOTU, so work on universe stuff too
<aSt3raL> ok cool
<Hobbsee> + the community-ish side of kubuntu too
<geser> aSt3raL: the xorg meta package was uploaded with version 7.2 10 hours ago
* Hobbsee is still updating...
<Hobbsee> heya jono!!!
<jono> heya Hobbsee:)
<jono> hows are we tonight?
<jono> or morning
<jono> or whatever it is in that crazy timezone
<StevenK> jono: 10:30am
<Hobbsee> jono: it's morning!
<jono> heh
<Hobbsee> strange thing - i almost never see it...
<jono> hehe
* Hobbsee keeps working too many night shifts...
<Hobbsee> even the customers comment...
<sabdf1> Hobbsee: you must be a morning person :-)
<Hobbsee> sabdf1: heh.  nope :P
* Hobbsee went to bed at 2am this morning
* Hobbsee wishes they did night uni - i'd actually be awake!
<ajmitch> hey jono, sabdf1 
<sabdf1> howdy ajmitch
<jono> hey ajmitch
<Fujitsu> Hi sabdf1, jono.
* Hobbsee wonders why sabdf1 is sabdf1, not sabdfl, and cloaked.
<jono> hey Fujitsu
<Hobbsee> (or identified)
<jono> Hobbsee: he has multiple personalities
* jono chuckles
<Hobbsee> jono: oh dear.  that's plus the random lunatics that pretend to be him, but talk like 13 year olds, right?
<ajmitch> how worrying
<Hobbsee> ajmitch: yes.  thank goodness for op powers.  (for stopping people disrupting channels)
* Fujitsu attacks Hobbsee for age-based discrimination.... and stuff.
<Hobbsee> Fujitsu: heh, sorry :)
<jono> Hobbsee: not really, Mark contacted me the other in fact and said "Hi Jono, Is it true you have m/\d l33t sk1llz? Power to the brother. Ubuntu FTW. See my website myspace.com/sabdfl"
<kylem> Hobbsee, if it makes you feel any better, he's connected to internal irc from the same host. :)
<Hobbsee> kylem: right :)
<jono> Hobbsee: that may in fact be lies what I just said
<sabdfl> FTW?
<Fujitsu> kylem: You /must/ have been hacked.
<Hobbsee> jono: yeah yeah :P
<Hobbsee> sabdfl: for the world, i believe
<jono> sabdfl: For The Win
<sabdfl> niiiiice
<jono> sabdfl: the kids of today seem to use it
<ajmitch> jono: I wonder how much we'd need to get him to drink to say that :)
<jono> I don't get it either
<jono> ajmitch: sounds like a challenge
<Fujitsu> jono: I'm a kid of today, and I had no idea what it means.
<Hobbsee> oh wah.
<Fujitsu> So there.
<jono> Fujitsu: obviously not "l33t" enough
<Fujitsu> Obviously.
<jono> Hobbsee: how much does the Kubuntu community post to the fridge?
<Hobbsee> jono: close to nothing.
<jono> Hobbsee: I am looking to get it fixed up
<jono> Hobbsee: any particular reasons?
<Hobbsee> jono: mainly because we post the stuff direct to kubuntu.org
<jono> Hobbsee: right
<Hobbsee> which only Riddell has access to, currnetly, incidently
<Hobbsee> or Riddell blogs directly, so appears on planet
<jono> Hobbsee: do you feel the fridge feels ubuntu/kubuntu/edubuntu or just ubuntu?
<Hobbsee> argh.  this supertux bug...and email...
<Hobbsee> jono: at the moment, i dont even read the fridge - it seems that planet has depreciated the fridge
<Hobbsee> it likely hasnt, but it's not active enough to be a snapshot of what's going on
<jono> Hobbsee: yeah, I get the same views from some people, looking to fix this up a bit, and see how the marketing team can feed it better
<Hobbsee> it's not even mentioning that UDS has been announced - at the minimum, the stuff from ubuntu-devel-announce should probably be on there, tc
<Hobbsee> right
* Hobbsee ponders the original question
<jono> exactly
<jono> this is what I am looking to fix
<jono> the fridge team is a little informal right now, it needs a leader and a roadmap
<jono> and its a sexy job, I am sure a loving leader is out there
<Hobbsee> i'm trying to figure out what of kubuntu should go on there
<Hobbsee> maybe our testing team, or something, once that's ramped up a bit.
<Hobbsee> at the moment, it talks conferences, teams, and asking people questions, from what i'm gathering, browsing it now - how would kubuntu fit into that?  (apart from the obvious of one of us answering questions)
<Hobbsee> jono: sexy job hey?  interesting description :P
<jono> Hobbsee: I reckon so, sexier than glibc maintenance
<Hobbsee> hehe
<ajmitch> that's not too hard
<StevenK> jono: Oh come on, toolchain hackers get all the chicks.
<canine_kouji> I'm wanting to create a couple programs for ubuntu. I'm not sure if anyone has done this already, so I'm checking. Has anyone here been working on a program or configuration application for GNOME for Windows services integration?
<ajmitch> StevenK: oh is that what I have to work on?
<canine_kouji> I do know how to integrate by hand, but for others.. I want them to be able to drink the ubuntu kool-aid ;)
<ajmitch> canine_kouji: what do you mean by windows services integration?
<lotusleaf> canine_kouji: you mean like what kcontrol has for wine?
<canine_kouji> ajmitch: set up certain settings like active directory.
<ajmitch> oh right
<canine_kouji> adding the machine to the network
<StevenK> ajmitch: :-P
* ajmitch has been working on that
<canine_kouji> is there anything I can work on?
* ajmitch still has to do some tidying so that the code is hackable by more than just me :)
<canine_kouji> specifically with this. I would consider it a very valuable feature. MacOSX already has an application.
<ajmitch> the code is in feisty, just not very good right now
<canine_kouji> ajmitch: if I can read Indian code, I can read your code ;)
<ajmitch> in universe
<canine_kouji> ajmitch: would you have a application name I can use to find this application?
<_ion> What is Indian code? :-)
<canine_kouji> _ion: code which comes from Rent a Coders from India.
<kylem> c code tikka masala
<_ion> I'd think there are competent as well as incompetent coders in India just like in any other country. :-)
<ajmitch> the package is authtool, it's written in python, and I'm rewriting some reasonable sized chunks right now
<canine_kouji> _ion: more code I read comes from India, I'm sure the college kiddies here in the US are just as illiterate and incompetant.
<canine_kouji> ajmitch: awsome :) My favorite language
<_ion> from __future__ import ruby
<canine_kouji> using gtk, right?
<canine_kouji> _ion: I'm waiting on YARV
<StevenK> _ion: Have you seen 'from __future__ import braces' ?
<canine_kouji> _ion: koichi has been very calm in implementing the byte code compiler for rb -> rbc for me. Ruby is almost there.
<_ion> stevenk: Is there an actual implementation? :-)
<_ion> canine_kouji: Yeah, YARV should be good.
<StevenK> _ion: It's a more a joke.
<canine_kouji> ajmitch: will authtool be included in ubuntu by default in future releases?
<StevenK> >>> from __future__ import braces
<StevenK> SyntaxError: not a chance
<_ion> Ah, hehe. :-)
<ajmitch> canine_kouji: hopefully :)
<canine_kouji> ajmitch: I hope so too. to clarify, does GNOME have a smb browser?
<canine_kouji> ajmitch: the smb browser is another one of the points of joining the network, to be able to access computers.
<kylem> nautilus with gnomevfs.
<canine_kouji> :) authtool is a dream come true
<ajmitch> heh
<ajmitch> most of what I'm doing is configuring pam, winbind, nsswitch.conf, etc
<canine_kouji> ajmitch: you know of anyone working on a "add printer" for "look in directory"?
<ajmitch> I still have to do the little things like the joining of the domain with 'net ads join'
<ajmitch> nope, I haven't dealt with printer stuff
<Hobbsee> yay, X didnt die.
<canine_kouji> its just one of those "another cool features" OSX doesn't have look in directory, but it can scan for the extraneous data the printers send across the network for detection.
<ajmitch> good
<ajmitch> yes, cups can do that on ubuntu
<Fujitsu> ajmitch: CUPS doesn't do Avahi-stuff, does it?
<ajmitch> eg in the printer config tool, there's a 'detect LAN printers'
<ajmitch> Fujitsu: I can't recall if it does yet or not
<canine_kouji> ajmitch: I see it ;)
<Fujitsu> I believe it doesn't.
<ajmitch> oh well
<Lathiat> no
<Fujitsu> 'tis unfortunate.
<ajmitch> something for Lathiat to fix :)
<canine_kouji> looking in active directory for printers would be one of those features needed for the corp env :/
* ajmitch wonders why his connection to nz.archive.ubuntu.com is crap
<canine_kouji> ajmitch: gremlins :)
<ajmitch> nah, it's going to the main archive
<ajmitch> I think because the nz mirror isn't usable for many people
<ajmitch> due to isp's peering squabbles
<Lathiat> is there an IX over there?
<ajmitch> yep
<Lathiat> whats it called?
<ajmitch> and telecom & telstraclear are the main two who refuse to peer nciely
<Lathiat> oh, yes
<Lathiat> naturally
<ajmitch> WIX, and APE are the 2 main ones
<Lathiat> its the same here
<Lathiat> the big ones don't peer
<Lathiat> because they dont need 
<Lathiat> to
<ajmitch> exactly
<Lathiat> telstra/optus dont peer at any of the WAIX or PIPEs
<Fujitsu> Same in AU, neither Telstra nor Optus do.
<Fujitsu> Ah.
<Lathiat> because they have prestigous tier-1 status :)
<Fujitsu> Yep.
<Fujitsu> Sooo annoying.
<Lathiat> yeh
<ajmitch> we also have smaller ones, with rather humourous names
<Lathiat> its dumb
<Lathiat> its the big players throwing there wait around
<Lathiat> at the detrement of the internet as a whole
<Lathiat> it sucks
* Hobbsee wonders if this modesetting branch is causing her X to crash.
<Hobbsee> damned thing
<bddebian> Heya
<saddev> hi, I've a development policy question
<saddev> Mono is able to run most applications that were written using the  IDE editor Visual Studio .NET 2005. If I'm developing an application that helps administering Ubuntu, and I write it with VS.NET. Granted that it has to work under Mono, would that application be considered for inclusion in Ubuntu, or there is some policy that prevents this because of VS.NET?
<Treenaks> saddev: It probably should be compileable in Ubuntu as well
<Treenaks> using mono
<Treenaks> as long as it does that, IDEs/editors don't really matter I think :)
<saddev> ok, so as long as msc is able to compile it under ubuntu, it won't matter that the design part of the app will be full of autogenerated Microsoft code?
<saddev> and can I ask you another question about the inclusion process?
<Treenaks> hm
<Treenaks> autogenerated code
<Treenaks> you should read the license of VS.NET what the license of generated code is..
<Treenaks> +and figure out
<saddev> so forget about Mono, say that I develop an app for Ubuntu (be it Mono, Python, etc...). If I want it to be part of the standard Ubuntu repository, how hard is it?
<Treenaks> saddev: not hard (but we prefer to get new# apps through Debian)
<saddev> Microsoft license... poor me. It's going to be hell! I better just use glade or GTK#
<Treenaks> saddev: monodevelop ;)
<saddev> Trennaks: yes, that's what I'm looking into
<saddev> Trennaks: so a built open source application can be submitted for inclusion in Debian
<saddev> and then picked up by Ubuntu?
<Treenaks> it will automatically be picked up by ubuntu on the next release, or if it's before the freeze, you can ask for it to be included.
<Treenaks> (Ubuntu syncs from debian unstable when starting to prepare a new release)
<saddev> Treenaks: sounds very reasonable
<saddev> Treenaks: I know it sounds silly. But being a developer I'd like to contribute with some cool little app or utility. Do you have any idea about what I could develop? Something that is currently missing from Ubuntu. perhaps?
<Treenaks> saddev: uh.. no idea :)
<saddev> leaving the hard part to ESR who just joined Ubuntu :-)
<saddev> Trennaks: thanks. In what do you program if i may ask?
<Treenaks> whatever I need :)
<Treenaks> not much atm
<niktaris> cjwatson, hi, can ubiquity create a root account in feisty ?
<bddebian> Heya
<towolf> ugh, fc-cache keeps strangling my system after an X-related update yesterday. an infinite loop or something?
<towolf> it must be related to Type1 fonts because when I move gsfonts and some others away it runs through.
<sladen> is Jono going to show up at FOSDEM, people are asking for him
<cjwatson> niktaris: not yet, no
<mjg59> sladen: No
<cjwatson> niktaris: might be a reasonable thing to add to the Advanced tab, or maybe somewhere else, dunno
<sladen> mjg59: funky, ta.
<mjg59> cjwatson: I've just been chatting to the parted maintainer - the current upstream code is supposed to handle synchronising the gpt and mbr tables
<cjwatson> interesting
<cjwatson> though we need to get refit building on amd64 *anyway*, so it may not be worth ripping out the code we already have in place
<cjwatson> unless there are other relevant things we need from upstream parted
<mjg59> Why do we need refit?
<cjwatson> well, gnu-efi
<cjwatson> refit's easy after that, aiui
<mjg59> We've got no way of modifying EFI flags or usefully blessing it in the installer, have we?
<cjwatson> I just have an aversion to upgrading parted to new upstreams after UVF
<cjwatson> it has a habit of breaking
<mjg59> Yeah I'll see if I can find the patch
<cjwatson> I guess I'd be happy with that then, yeah
<cjwatson> would have to rip code back out of partman-efi, but there
<mjg59> I think worrying about gnu-efi is probably unnecessary
<cjwatson> (and yes we still need partman-efi to handle the EFI system partition logic)
<mjg59> Yeah
<mjg59> Also need to send him the HFS+ resize patch
<cjwatson> if Kyle's discussion with linux-ide goes well, we'll need to patch parted for HPA handling too
<mjg59> Hm. Not getting anywhere in finding this code.
<mjg59> Need to try to find Dave Cantrell
<kylem> dave cantrel..
<kylem> why is his name familiar.
<mjg59> RH developer
<kylem> ah.
<kylem> cjwatson, assuming i get any discussion at all :/ (posting on a friday was probably a bad idea :)
<cjwatson> maybe I should have deferred my followup ;-)
<cjwatson> Alan's point was a good one, certainly, and needs to be dealt with
<cjwatson> kylem: maybe post a followup early next week with a patch adding an ioctl to let you find out the non-HPA size, and see what they say?
<kylem> yeah.
<kylem> problem with adding an interface is it has to stand th etest of time
<cjwatson> it does feel like a bit of an excessively specific hack; I don't know if there's a more generic concept that it could be glued into
<cjwatson> maybe the right thing would be "suggested size of area covered by a new partition table on this block device"
<cjwatson> I need to learn more about partitioning on arches other than the big three
<mjg59> ioctl?
<mjg59> I'd have thought a sysfs attribute was more fashionable
<cjwatson> well, BLKGETSIZE is an iocttl
<cjwatson> ioctl
<kylem> mjg59, block device crap is all ioctls
<kylem> leeeegacy
<cjwatson> should really live in the same place as it's the same kind of thing
<mjg59> cjwatson: Not utterly sold on that argument :)
<mjg59> But yeah. Adding a sysfs interface to block device magic is probably a job for later.
<cjwatson> is BLKGETSIZE available via sysfs?
<cjwatson> if not, I don't think something like it should appear in sysfs until BLKGETSIZE does too
<cjwatson> otherwise you end up with random scattered bits of interface, none alike
<niktaris> cjwatson, how about using a checkbox in the user creation dialogbox? "Create root account?"
<cjwatson> which OK is kind of what the kernel already is but I don't think it should be encouraged
<kylem> perhaps "BLKGETMAXSIZE"
<cjwatson> kylem: maybe but that would break old partitioning tools wouldn't it?
<cjwatson> assuming that you mean "get the full size of the block device including HPAs"
<cjwatson> old parted wouldn't be able to work with partition tables overlapping the HPA
<kylem> could return a tuple? :)
<kylem> dunno.
<cjwatson> niktaris: could work, feel free to try it out and send a patch
<cjwatson> niktaris: not sure I'm entirely happy with it being presented by default but that's not a firm no
<kylem> i don't really have a preference, in fact, my preference would really be to just do what the legacy code did.
<niktaris> cjwatson, hehe will try
<cjwatson> kylem: what does that mean though? return the size of the block device including HPA (since AIUI that's what the old code did)?
<mjg59> This network is shonky
<mjg59> Legacy behaviour is for the HPA to be utterly disabled and all ioctls to behave as if it had never been enabled, AFAIK
<kylem> right.
<cjwatson> mjg59: meaning that parted will see a block device whose extents include the HPA?
<cjwatson> or the other way round? for some reason I am finding the terminology confusing
<mjg59> Disabling the HPA means that the host no longer protectes the area
<mjg59> Resulting in it becoming available
<mjg59> That is, yes, parted will see a block device whose extents include the HPA (ie, the entire disk)
<cjwatson> right, so if it's enabled, how would parted work with a partition table created while the HPA was disabled and overlapping the HPA?
<cjwatson> would there be a separate bit of interface to disable the HPA again, or would the kernel detect that such a partition table was there and disable the HPA automatically?
<cjwatson> maybe I misunderstood Alan then - if the HPA is enabled, as far as creation of new partitions go, all I want to know is how big the block device is now - I don't want to deliberately create partition tables extending into the HPA
<mjg59> drivers/ide will *always* disable the HPA before userspace starts
<mjg59> There is currently no interface for userspace to know it was ever there, other than parsing dmesg
<cjwatson> which means that legacy partition tables will be broken
<mjg59> When moving to libata, yes
<mjg59> That's the issue
<cjwatson> I think the kernel should detect such legacy partition tables and re-disable the HPA
<cjwatson> since nothing else can
<kylem> can't.
<cjwatson> why not?
<mjg59> To maintain consistency, the libata behaviour should be to always disable the HPA
<kylem> the hpa detection happens on device discovery
<mjg59> parted could then be enhanced to suggest that you not create or delete partitions in the HPA
<kylem> partition tables occur way afterwards
<cjwatson> ok, then I agree that libata should always disable the HPA, since otherwise you're fucked
<kylem> right.
<kylem> the problem is SATA.
<kylem> which is almost universally libata based.
<kylem> which means partition tables are based on the reduced size of disk.
<cjwatson> there's no compatibility issue with moving from an enabled HPA to a disabled HPA, is there?
<mjg59> No
<kylem> it won't break, but people might fuck their shit up when they see "free space" in their partition tables.
<cjwatson> the partition table will just only specify a reduced range of the disk
<cjwatson> they won't, the free space is bounded in the partition table, isn't it?
<mjg59> parted will notice that the partition table doesn't cover the entire disk and mark the remainder as free space, no?
<kylem> hmm. i don't know. could experiment and find out.
<kylem> mjg59, that was my thought.
<cjwatson> er, I need to remember the partition table format
<mjg59> I thought the mbr table just contained partition sizes, rather than attempting to define disk geometry?
<cjwatson> mm, you're right, it doesn't contain the disk size, annoyingly
<cjwatson> you could funt BLKGETSIZE to lie
<cjwatson> but again that would break partition tables that deliberately use the HPA
<cjwatson> so you need to teach parted, fdisk, and everything else to know about the HPA double-quick ;-)
<cjwatson> have fun
<kylem> mjg59, does the HPA region typically exist in the partition table?
<kylem> i can't recall what my ibm had.
<cjwatson> or add a userspace interface to enable/disable the HPA and then at least a workaround is available
<mjg59> cjwatson: Surely always disabling the HPA without providing any intelligence is no worse than the current situation?
<cjwatson> http://lkml.org/lkml/2005/9/2/213
<cjwatson> mjg59: depends how vital the contents of the HPA are
<cjwatson> if the BIOS relies on it ...
<kylem> iirc it's used for BIOS suspend on some old thinkpads.
<kylem> er, hibernate.
<mjg59> cjwatson: As I said, how is it worse than the current situation?
<mjg59> If people were breaking stuff, we'd already have heard about it
<cjwatson> with the current situation you can't break your HPA on fresh installation
<mjg59> Yes you can
<cjwatson> (if it's using libata)
<mjg59> Right
<cjwatson> I'm not convinced we'd have heard about it
<mjg59> But you've been able to for anything using drivers/ide up until now
<cjwatson> I have nowhere near enough bandwidth to keep up with all the installer bugs
<kylem> the problem currently is that anyone upgrading to feisty and using libata-pata will suddenly not be able to use their disk.
<kylem> and will scream in panic as they think their /home is fried...
<mjg59> kylem: It's presumably not hard to limit this to pata, even if that's not what upstream want?
<kylem> mjg59, it is indeed not terribly difficult.
<mjg59> That then leaves us where we were pre-feisty
<cjwatson> anyway, must go tidy the house some more
<kylem> i can read cable type and limit to 40p/80p PATA.
<mjg59> Ok
<kylem> i can also add an ioctl to increase the size and revalidate the disk
<kylem> that way if we wanted to let ubiquity or something detect it and provide a clickbox to disable it, we could.
<kylem> ugh, then we have to put it into the initramfs and.. oh bother.
<kylem> partitioning is hard. let's go shopping.
<kylem> mjg59, i'm tempted to say we could just leave HPA enabled wholesale for new installs...
<kylem> hmm. did ubuntu disable middle click in firefox? bummer.
<Mithrandir> it's been disabled since warty or so.
<kylem> gruntle.
<Mithrandir> just set middleMouse.contentLoadUrl to true
<kylem> heh, was looking through the changelog for that.
<phoenix24> but simple tweaks can enable it.
<mjg59> kylem: How do you define a new install?
<kylem> thinking more about it, i don't think there's a single good way to do this.
<mjg59> I think the least worst is to do what drivers/ide did in the kernel, and make userspace smarter
<kylem> yeah.
<kylem> i'm trying to determine call chain when the disk gets revalidated from ioctl.
<kylem> to make sure i'm handling it correctly.
<kylem> mjg59, one of the thoughts i had was to just stow way the full disk size, and if there's a BIO which gets rejected as within limited_size <= x <= hpa_size, disable hpa and retry the bio.
<mjg59> Hm.
<mjg59> kylem: Sounds distressingly hacky
<kylem> no fucking clue how feasible it is.
<kylem> alternatively, hack the msdos partition (ugh, i guess efi too) code to see if the results make sense and unclip the disk...
<kylem> there's sata disks using drivers/ide too, which is also a problem with just basing it on cable type.
<mjg59> Nf.
<mjg59> We lose heavily.
<kylem> everyone loses.
<mjg59> Whoever wins, etc.
<kylem> i don't know how much of this should be solved for feisty, maybe we should defer libata-pata until it's more mature...
<mjg59> Well, given that we can trivially ensure that it has much the same level of functionality as it had in edgy...
<kylem> i don't know that the error recovery is as good in drivers/ata yet.
<tsmithe> hi - if i have a package waiting on NEW, but it has a bug, is it possible to have a fixed version uploaded on top?
<jdong> mjg59: any emotional attachment to xinerama on xgl?
<jdong> mjg59: we need new xgl from git to compile against xorg 7.2....
<jdong> and that xinerama patch no workie
#ubuntu-devel 2007-02-25
<achak> will feisty support ntfs-3g by default?
<Mithrandir> no
<achak> Mithrandir: any idea why?
<Mithrandir> nobody has written a spec and done the work and we are post feature freeze.
<achak> Mithrandir: aha, i see
<Mithrandir> it's in universe though, so it's there and might work.
<achak> Mithrandir: it would be cool to have it by default, since ntfs-3g recently reached its stable version (1.0) and hence is quite safe :(
<Mithrandir> maybe for feisty+1
<achak> Mithrandir: aha, that's still good enough
<achak> Mithrandir: beryl too?
<Mithrandir> hiya Scott.
<achak> Mithrandir: or nothing's certain?
<Keybuk> hey
<Mithrandir> achak: beryl's not even in the archive yet.
<Keybuk> (and doesn't even work if it was :p)
<achak> Mithrandir: oops, didn't know that
<achak> Mithrandir: is it that bad? :)
<Mithrandir> achak: I rejected it back in December due to licencing problems and nobody has uploaded a new package yet.
<Mithrandir> the state back then was quite bad.
<achak> Mithrandir: licencing problems?! is it not gpl?
<Mithrandir> it is, but it ships files without sources.
<achak> Mithrandir: i wonder why some people prefer to do this
<Keybuk> botched-together build
<Mithrandir> achak: the compiler needed for making the .c files is non-free..
<Mithrandir> so beryl would conceivably go to multiverse.
<Keybuk> heh
<Keybuk> Mithrandir: that bit I didn't know; what are the .c files?
<Mithrandir> Keybuk: GLSL (GL Shader Language) fragment shaders.
<Mithrandir> in this case they're trivial enough you could have written them from scratch, but they haven't.
<Mithrandir> Keybuk: there are also 4k by 4k pixmaps embedded in .c files which I somehow doubt is the "preferred format for modifications".  (No, it's not xpm.)
<Keybuk> lol
<Keybuk> I can't even get beryl to compile
<Keybuk> it segfaults ld
<Keybuk> you can only compile the i386 package on an x86-64
<Mithrandir> !
<achak> Mithrandir: why don't they use compiz's?
<achak> Mithrandir: or does compiz have similar issues?
<Mithrandir> achak: why don't they use compiz's what?
<achak> compiler
<Mithrandir> uh, compiz does not include a fragment shader compiler.
<Mithrandir> that'd be like your shell providing a web browser and sshd.  Not even zsh does that.
<achak> Mithrandir: oh, actually i have no idea what a fragment shader is
<Mithrandir> achak: no, for a start compiz is MIT, so it would be fine in compiz.
<achak> Mithrandir: but probably a fragment shader is what makes beryl nicer than compiz, i guess
<Mithrandir> it's just used in one of the plugins.
<achak> Mithrandir: ah, then is should simply be eliminated until issues are addressed by *them*
<Keybuk> "nicer" ?
<Mithrandir> somebody needs to do that work and actually upload the new packages.  Most of this can be solved fairly easily by chopping off bits, but it's still works somebody needs to do.
<Keybuk> it makes beryl a lot more entertaining and fun
<achak> Keybuk: yes, nicer, at least to some
<Keybuk> I'm not sure that it makes beryl a better window manager
<Mithrandir> Keybuk: but it BURNS your windows.  How could it not be good?
<Keybuk> Mithrandir: it's great for showing off
<achak> Mithrandir: what do you mean by "burn"?
<achak> Mithrandir: is it some effect?
<Keybuk> achak: you've never seen the BURN animation plugin?! :P
<Keybuk> windows catch fire and burn off your desktop
<Mithrandir> very bling.  Not very useful.
<Keybuk> indeed
<Keybuk> right now, I think metacity is the only useful window manager
<Keybuk> and you can switch to beryl to show off to non-Linux users, but switch back when they're not looking
<Keybuk> and that as we find things that improve usability, they'll end up in compiz
<Keybuk> which will get to be as useful a window manager as metacity over time
<Keybuk> but with a little transparency, shadowing, etc. to improve things
<Mithrandir> which, to be fair, is just eyecandy, but people want pretty.
<troy_s> eyecandy != pretty
<Keybuk> making unused windows increasingly transparent is quite handy, makes it more obvious which window is focussed
<Keybuk> and slight shadows mean you can do away with the window borders, freeing up screen estate
<Keybuk> beryl has a handy plugin, windows shiver slightly as they get focus -- handy for ffm
<Keybuk> yet again it strikes me that Google have a really fucked concept of Internationalisation
<Fujitsu> Keybuk: What have they done this time?
<Keybuk> my usual gripe is that the list-o-languages in the preferences is translated into whatever language you're viewing Google in at the time
<Keybuk> that should be a fixed list, with each language given its local name -- since you're only using it because you can't read anything else
<Keybuk> today's "new thing" is Google Maps
<Keybuk> they show each country with place names in the local language
<Keybuk> e.g.
<sabdfl> Keybuk: what language are you navigating in today?
<Keybuk> http://maps.google.co.uk/maps?f=q&hl=en&q=tokyo&ie=UTF8&z=14&ll=35.678599,139.773474&spn=0.031165,0.086517&om=1
<Keybuk> when they should show place names according to your browsing locale
<Keybuk> sabdfl: Google infamously override your browser/preference language with the language of your origin country (from geoip)
<Keybuk> sabdfl: so whenever you visit any foreign country, the first thing you have to do is tell Google that you want it back in English, thankyou
<sabdfl> hard to get xhosa names for tokyo suburbs
<Fujitsu> Keybuk: maps was normal a few hours ago, I'm sure.
<sabdfl> but yes, agreed, this is suboptimal
<Fujitsu> Oh, for small-scale like that...
<Keybuk> Fujitsu: yeah, I think this is a new thing
<Keybuk> Fujitsu: it's true at the world-scale too, Japan appears as waffle-samurai
<Fujitsu> I had Google Earth showing me Melbourne in katakana for some reason some months back.
<Keybuk> sabdfl: it reminds me that I must blog about my favourite example of people paying lip service to accessibility without actually thinking about it
<Keybuk> at the Trafford Centre in Manchester, they have carefully added brail to every single sign
<Keybuk> so blind people can still read them
<Keybuk> one sign in particular, with brail on it, amused me
<Mithrandir> (braille)
<Keybuk> "DO NOT STAND IN FRONT OF THIS DOOR"
<Keybuk> Mithrandir: err, yes
<Fujitsu> Keybuk: How very useful!
* Fujitsu likes the inconsistencies in the localisation... Some places are in their own languages, others aren't.
<Fujitsu> Small-scale Japan has been in Japanese for months, but I don't think it has been from the default zoom level for long.
<giskard> the latest xorg in ubuntu can use AIGLX right?
<Mithrandir> giskard: xorg in Ubuntu has supported aiglx for a long time.
<giskard> Mithrandir, i only wanted be sure :) thank you (morning)
<Mithrandir> yes, good morning.
<Keybuk> do you still need the Option "Composite" "Enable" thing?
<JanC_FOSDEM> no
<Keybuk> it's enabled by default now?
<giskard> we prefer to use aiglx or xgl? because i don't like build the beryl-xgl  bin
<JanC_FOSDEM> if aiglx works for you, use it -- it's the easiest to set up   :)
<JanC_FOSDEM> Keybuk: I didn't have to use it until some days ago, except that partial Xorg 7.1/7.2 on feisty seems to have broken beryl/compiz currently
<Keybuk> yes
<giskard> JanC, Keybuk shaw_work (a debian pkg-xorg guy) has some patches
<giskard> <shawn_home> xorg-x11-server-1.1.0-dont-backfill-bg-none.patch
<giskard> <shawn_home> xorg-x11-server-1.1.0-no-move-damage.patch
<giskard> <shawn_home> xorg-x11-server-1.1.1-glcore-visual-matching.patch
<giskard> <shawn_home> xorg-x11-server-1.1.1-offscreen-pixmaps.patch
<Keybuk> updating to xorg 1.2 fixes it too
<cjwatson> sabdfl: Xhosa> wouldn't it just be i-Tokyo etc.? :-)
<cjwatson> tsmithe: yes, just bump the version number for each upload and it'll do the right thing
<tsmithe> ok thanks
<okaratas> hmm
<okaratas> hello
<okaratas> ozgur@ozgur:/var/crash$ ls -la /var/crash/
<okaratas> total 27028
<okaratas> drwxr-xr-x  2 root  root      4096 2007-02-25 14:16 .
<okaratas> drwxr-xr-x 15 root  root      4096 2006-10-25 16:39 ..
<okaratas> -rw-------  1 root  root     65383 2007-02-25 14:16 _sbin_udevd.0.crash
<okaratas> -rw-------  1 ozgur ozgur  1801255 2007-02-25 14:19 _usr_bin_gnome-terminal.1000.crash
<okaratas> -rw-------  1 ozgur ozgur  1565976 2007-02-24 16:23 _usr_bin_xchat.1000.crash
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* okaratas was kicked off #ubuntu-devel by Hobbsee (You should know better.  Bye!)
<okaratas> ozgur@ozgur:/var/crash$ uname -ar
<okaratas> Linux ozgur.laptop 2.6.17-11-generic #2 SMP Thu Feb 1 19:52:28 UTC 2007 i686 GNU/Linux
<Hobbsee> okaratas: please dont spam the channel with needless info
<Hobbsee> okaratas: please, file a bug.
<okaratas> Hobbsee, okey
<Hobbsee> okaratas: if you're going to spam the channel, make sure you actually provide some context first
<Hobbsee> heya jono 
<jono> hey
<okaratas> jono, hello
<jono> hey okaratas
<okaratas> how are you jono ?
<jono> okaratas: good thanks, just woke up :)
<okaratas> hm okey eh :)
<okaratas> i using ubuntu 6.10 my laptop
<bhale> jono: weee mathcore
<_ion> Where?
<bhale> jono blogged it the other day, tickled me
<jono> bhale: hehe :)
<_ion> Oh, no audio? :-(
<okaratas> I use ubuntu 6.10 in the computers of the company and keep it updated. I also use ubuntu for the servers. However, there were several crashes in the ubuntu that I installed in the laptop. What might be the reason of that? In addition, firefox is crashed in all computers most of the time. What would you suggest?
<Hobbsee> okaratas: please see the /topic
<KaiL> okaratas, at first I suggest reading the topic - more specifiy the first part of it
<okaratas> Hobbsee, ok
<AnRkey> what is the best ide to use for python?
<AnRkey> does any1 have any favourates?
<Mithrandir> I like emacs.
<bhale> and I am using vim with python just now :)
<AnRkey> yeah but for the less hardcore
<AnRkey> :D
<bhale> ive always found the value of linux ides to be dubious
<bhale> find a text editor you like and your favorite language reference and go
<AnRkey> well here is the thing, i am used to using zends ide for php
<AnRkey> and i was looking for something like that for python
<Keybuk> I'd like a decent IDE
<giftnudel> yes, but the possibility to shift-klick on a function and go to the definition is nice
<AnRkey> still learning here
<AnRkey> i found zend's ide for php very helpfull when learning php
<bhale> thats because in php they change the order of arguments in array functions every 3 :)
<bhale> you have no choice but to look them up
<AnRkey> common bhale, answer the freaken question! :-D If you had to choose or suggest one...
<AnRkey> we all know you use one :D
<Keybuk> AnRkey: most people don't use them, actually
<Keybuk> we really just use emacs or vi
<AnRkey> ok ok
<AnRkey> thanks anyway
<finalbeta> perhaps code blocks can do python, don't know
<finalbeta> nope
<AnRkey> i think eclipse is what i am looking for
<AnRkey> just installed it
<AnRkey> wow
<AnRkey> gonna try pydev
<Spads> AnRkey: check out eric when you find time.  it seem sto have a sizable following
<bddebian> Heya
<h4writer> Got a question. I used bzr to get the 'source' of yelp/help centre. Now I want to compile it, to see if it works properly. It tried with autogen.sh but got some errors I can't solve.
<h4writer> http://paste.ubuntu-nl.org/7490/
<h4writer> does anyone knows how I can compile the bzr branch of yelp?
<h4writer> or how you supposed to do that
<bddebian> h4writer: Do you have gconf installed?
<h4writer> nop
<h4writer> is now installing
<h4writer> yes is now installed
<h4writer> bddebian, what do I need to do next?
<bddebian> re-run autgen?
<h4writer> still giving the same error
<bddebian> Hmm
<h4writer> !flood
<bddebian> Did you install gconf or libgconf2-dev ?
<h4writer> this time gconf
<h4writer> but I have installed libgconf2-dev already
<h4writer> okey, I've missed
<h4writer> I did only install gconf
<h4writer> the whole time
<h4writer> is now installing
<h4writer> bddebian, isn't installed totally. I got some other errors then before. But I will try to fix them first myself.
<okaratas> rver
<h4writer> Got a question. For building the yelp package I need to install a mozilla/firefox/xulrunner -devel package. Now I think that is libxul that I need to install. But that depends on libnss3-dev and that conflicts with libnss a default package for ubuntu-desktop. So I can't install it??????
<bddebian> h4writer: I would suggets firefox-dev
<h4writer> okey
<h4writer> yes, that worked thanks
<bddebian> NP
<h4writer> after running ./autogen.sh you only need to run 'make' and 'sudo make install' and it is installed?
<bddebian> That's the theory :-)
<bddebian> Oh, no, you should still need to run configure, unless autogen does that for you
<h4writer> if I'm not wrong I saw autogen.sh do it
<bddebian> OK
<h4writer> indeed: Running ./configure --enable-maintainer-mode ...
<lesshaste> hi all
<balor> Is VDSO disabled in Feisty kernels?
<Le-Chuck_ITA> hi there
<Le-Chuck_ITA> there is a bug in ubuntu, bug #40473
<Ubugtu> Malone bug 40473 in xorg "/etc/X11/xorg.conf should point to /dev/input/wacom instead of /dev/wacom and xserver-xorg-input-wacom should depend on wacom-tools (AKA Wacom support almost there... add some udev magic?)" [Medium,Confirmed]  https://launchpad.net/bugs/40473
<Le-Chuck_ITA> I think that for feisty it could be solved easily
<Le-Chuck_ITA> and I have a tablet and are often available online
<Le-Chuck_ITA> so if nobody is here right now I will try in the next days or else just tell me now that you're interested in interactive experimenting
<pochu> Le-Chuck_ITA: feisty will probably ship x.org 7.2
<pochu> Le-Chuck_ITA: does that also happen with it?
<pochu> Le-Chuck_ITA: I've read something that 7.2 doesn't use /etc/X11/xorg.conf
<pochu> but I'm not sure :)
<Le-Chuck_ITA> omg if this is true there will be nothing that I know about my system
<Le-Chuck_ITA> :)
<Le-Chuck_ITA> everything changed from my first installation of slackware 10 years ago, kernel, init, now X!!!!
<Le-Chuck_ITA> ok, I think that it is a dependency bug
<Le-Chuck_ITA> and one needs wacom-tools which are not installed
<Le-Chuck_ITA> when xorg wacom input drivers are installed
<Le-Chuck_ITA> so not using xorg.conf would not change things
<Le-Chuck_ITA> ok will try in the next days, thanks and bye
<arnor> hello World!
<jdong> System.Console.out.println("hello to you too");
<sacater> who here is a developer?
<jdong> a good 90% of the channel :)
<jdong> but it's a weekend
<jdong> and we'd like to pretend we have lives
<mr_pouit> ^^
<jdong> mr_pouit: btw how is ffmpeg for edgy? :)
<sacater> jdong: if i wanted to be a devel, there are different choices, like community, software, that sort of thing
<jdong> I don't quite follow what you are implying
<sacater> jdong: are you a developer?
<jdong> kind of in between
<jdong> I do work on Ubuntu (backports, forums, miscellaneous bugfixing contributions) but am not an official MOTU or core developer
<Hobbsee> sacater: people here are either developers, lurking developers, or just lurkers.
<mr_pouit> jdong, oops, I didn't try to backport it from feisty (too lazy :P). But I use feisty ffmpeg with --enable-risky, and no problem. ;)
<jdong> mr_pouit: yeah, feisty works great :)
<sacater> jdong: Im interested in the whole 'Developer' thing
<sacater> I know a gentoo devel, and he says be a devel is great :P
<jdong> mr_pouit: Edgy will work but that x264 patch needs to be commented out
<jdong> (stock edgy packages won't enable all risky stuff with --enable-risky..., so you need to backport Feisty)
<Hobbsee> wow, no updates today
<jdong> sacater: cool. you'd probably want to be in #ubuntu-motu then :)
<simira> Hobbsee: they're all at fosdem and to drunk :p
<sacater> jdong: ty
<jdong> np
<Hobbsee> simira: haha.  some of them, anyway :P
<Hobbsee> simira: you going to be in spain?
<simira> Hobbsee: and some is on their way home... :)
<simira> Hobbsee: don't know. Probably not.
<Hobbsee> true
<Hobbsee> awwww....
<simira> Hobbsee: maybe adding a weekend to one or two days.
<Hobbsee> simira: right, yep
<simira> you're going?
<Hobbsee> simira: planning to, yes
<simira> Hobbsee: going that far, you could as well drop by Norway ;)
<Hobbsee> simira: i wish :)
<h4writer> !flood
#ubuntu-devel 2008-02-18
<TheMuso> c/
<Kano> hi, did you see the new security update for ntfs-3g?
<Kano> http://ntfs-3g.org/releases.html
<Kano> http://article.gmane.org/gmane.comp.file-systems.ntfs-3g.devel/418
<Kano> i updated it for kanotix already...
<superm1> Kano, please file a bug and mark it as a security vulnerability
<Kano> how about you
 * TheMuso shakse his head.
<TheMuso> shakes
<Hobbsee> greetings!
<zul> welcome back Hobbsee
<Hobbsee> ty, but i'm still on VAC
<superm1> Hobbsee, where to?
<Hobbsee> superm1: adelaide
 * Hobbsee has finally renewed ubuntu membership
<lamont> slangase`: heh
<lamont> your k got eaten.
<lamont> wondering about your thoughts on making the 64-bit implicit-ptr conversions fatal for hardy..
<lifeless> lamont-break-your-buildly-yours
<lamont> lifeless: that's what I does. yep.
<lifeless> lamont: better to make it fatal in debian ;)
<lamont> lifeless: it is
<lifeless> lamont: ah, then you have my vote
<lifeless> lamont for prez!
<ScottK> Dear lamont: You're postfix package doesn't automatically bathe the baby and feed me candy.  Plz fix.  kthnksbye.
<ScottK> Sorry.  Tiring of reading postfix-users and "I installed postfix on Ubuntu and used some random 3rd party web site cargo cult script to configure it how come it doesn't work?" posts
 * StevenK still has to figure out how to do SMTP AUTH with postfix.
<koolkat> How do I become a Documentation Member?
<nixternal> koolkat: you were int he right channel, but left before I could say anything :)
<koolkat> Ok
<koolkat> what chanel was that?
<nixternal> #ubuntu-doc
<koolkat> nixternal: so how do I become a member?
<nixternal> go to #ubuntu-doc and we can talk about it there
<ScottK> StevenK: Give me a root login to your server and I'll be glad to set it up for you. ;-)
<nixternal> careful now, ScottK stole my credit card and social security number with that trick :p
<StevenK> Haha
<StevenK> ScottK: Like I even trust myself with root access. :-P
<ScottK> StevenK: I trust me more than I trust you.  Why shouldn't you too?
 * StevenK blinks, trying to dereference
<StevenK> ScottK: My main problem is "Postfix SMTP AUTH (and TLS) HOWTO" is all Postfix 1.x
<superm1> nixternal, those are replaceable, at least he didn't take your gpg key like he took mine with that trick
<ScottK> StevenK: IIRC Ubuntu postfix docs are sensible.  I'll find you a link if you're interested.
<StevenK> ScottK: Sounds great
<ScottK> StevenK: Which release?
<StevenK> ScottK: Dapper
<ScottK> StevenK: https://help.ubuntu.com/7.10/server/C/postfix.html#postfix-smtp-authentication isn't exactly how I do it (I use sasldb and auxprop), but I believe this will work for Dapper - Gutsy.  For Hardy I'd recommend Dovecot.
<TheMuso> What package in hardy provides the gpg agent facilities?
<ScottK> TheMuso: There are several.
<TheMuso> Whats used by default then.
<TheMuso> ah seahorse
<StevenK> ScottK: Yes, since I use dovecot for IMAP/POP3, I was pondering waiting for Hardy
<lifeless> I used gnome-gpg
<lifeless> I likes it.
<ScottK> TheMuso: gnupg-agent will be used by Default actually.  I think it's the only one in Main.
<TheMuso> Well I need to investigate why 1) seahorse gpg sign passphrase windows don't get proper focus, and 2) why they are completely inaccessible.
<ScottK> TheMuso: For gnupg-agent the U/I is provided by pinentry.  I don't know if that relates at all to Seahorse.
<StevenK> Hrm. I have SMTP AUTH half setup
<StevenK> I think
<ScottK> StevenK: If you've got a recent enough Dovecot for SMTP Auth (I'm not at all familiar with that), I do know the Postfix in dapper-backports will support it.
<StevenK> ScottK: I don't think so, I think it requires a newer dovecot. Besides, I don't like running backports.
<ScottK> StevenK: Sure.  If it helps any on this one, lamont runs a backported Postfix on his Dapper boxen and he did the backport.
<StevenK> Hrm. I think I have all of the bits, it just doesn't work ...
 * StevenK is unsure
<ScottK> StevenK: If you want to get it sorted I'll be glad to help.  Here or on #ubuntu-server (where help is in fact on topic).
<StevenK> ScottK: I think I need to sort out two things -- 1) Does my SASL setup work, and 2) Does Postfix then work, since it looks to be configured correctly
<ScottK> What do the logs say?
 * StevenK tries to remember how to speak SMTP AUTH
<ScottK> If you're doing it by hand you'll have to speak TLS too if you're set up correctly.
<StevenK> I just turned off TLS so I don't have to speak that bit.
<StevenK> Ack. Can't remember enough about how to speak it.
 * ScottK neither.  I usually just use an MUA and read logs to figure out what I forgot (for me it's usually forgot to copy the update sasldb into the chroot - won't be your problem if you're using the documented approach)
<ScottK> If someone's got a minute, I'd appreciate a look at http://launchpadlibrarian.net/12048829/buildlog_ubuntu-hardy-i386.kdebase_4%3A3.5.9-0ubuntu1_FAILEDTOBUILD.txt.gz - it's claiming dependencies that I'm pretty sure should be available weren't.
<nixternal> ScottK: I think there is a repo issue
<ScottK> nixternal: Do you know if someone is working on it?
<nixternal> don't know...myself and superm1 are having the same exact problem
<nixternal> because graphviz is fine, I just installed it here
 * ScottK too.
<superm1> it was reported in #launchpad yesterday by Fujitsu
<superm1> and cprov said that its probably further in the mirroring mechanics
<ScottK> OK
<nixternal> ya, if I do 'sudo apt-get update' it flies through, and I know there are a couple of updates available
<ScottK> nixternal: lifeless figured it out.  libgraphiz4 is in Universe.
<ScottK> Or however you spell it.
<StevenK> And there's the smoking gun.
<nixternal> you were close, forgot the v :)
<nixternal> ScottK: but why would it be a problem now, and never was a problem before?
<nixternal> is the universe repos bunked up or something?
<StevenK> nixternal: Because kdebase is in main ...
 * StevenK goes to take something for his headache
<ScottK> nixternal: My guess is a soname jump when graphviz 2.16 was uploaded on 2/7 and the new lib version got left in Universe by mistake.
<nixternal> ahhhh
<ScottK> Maybe slangase` is still present and up for a little archive admin work so we can build it.
<nixternal> hehe
<Hobbsee> boo
<blistov> hey, why is the ubuntu livecd automatically killing all my mbrs from every disk it finds, on boot?
<blistov> I put in the cd, booted off it, the framebuffer never loaded correctly, waited 5 minutes till i was sure nothing was going on, tried again in safe mode (i assumed that wouldn't use a splash, no change, took the cd out, rebooted, and of my the mbr's from both raids, and my one single drive, were all wiped out.
<blistov> i booted off a backup usb drive, put grub back in the mbr to all disks, reboot, everything works again. boot the ubuntu cd, and once again, the mbr's all die.
<blistov> any ideas on this? is ubuntu cleverly installing something to the mbr of every disk it see's?
<TheMuso> blistov: Which live CD?
<TheMuso> blistov: Is it a hardy daily image?
<blistov> ubuntu-7.10-desktop-amd64.iso
<blistov> I hate to bitch, especially to the devs, and more especially, when i'm not even part of the ubuntu community, but it seems like every time I try a ubuntu livecd, it results in something being deleted, formatted, repartitioned, or broken in general, without input from me, and i can't very well stop it because the live disks always use fbsplash, which i've never seen work on any recent hardware.
<blistov> I can't imagine my experience is the majority, as there is a huge userbase.
<blistov> I keep thinking of moving away from Gentoo because of the idiot politics with communtication between userland and dev, but I run into major limitations in every other direction (ie, the live disk wipes out my mbr's without my knowledge.)
<blistov> Am I running an unstable/untested version of the livecd?
<StevenK> blistov: That filename indicates that it's the released version. I've never seen a Live CD touch the MBR of another disk like that, either.
<blistov> Ok. Well... It did, and does.  I'm not sure why.  I don't know if anyone is interested in the Ubuntu community.
<blistov> Is there any known weirdness with geforce 8800 cards and fb/gensplash?
<mjg59> We don't use fbsplash or gensplash
<blistov> What's used?
<mjg59> But there is an issue with x86emu and recent nvidia BIOSes
<mjg59> I need to find some time to work on that
<mjg59> usplash
<blistov> But no one's ever heard of the livecd arbitrarily wiping out mbrs?
<mjg59> Nope
<mjg59> If it's reproducable, it's certainly concerning
<mjg59> But there's no code that touches the hard drives until you hit the installer, and that's not autostarted
<mjg59> So there's no obvious reason for it to be happening
<mjg59> Which makes it weird and awkward to diagnose
<blistov> k. well its possible (not plausible though) that i accidentally and quite blindly started the install...
<blistov> any idea why the video never comes up?
<mjg59> Yeah, that's also weird
<mjg59> The lack of splash is easy enough to explain, but X ought to start eventually
<blistov> I left it for 5 minutes exactly.
<mjg59> I'm relatively sure that you can encourage the livecd to start without a splash
<mjg59> One of the F keys should give you a dialog that lets you edit the boot options - delete quiet and splash from there
<blistov> Is there any chance on a  6.8Ghz machine with 2GB of 1Ghz ram, would take longer than 5 mintues to start x?
<blistov> mjg59: i did that.
<mjg59> And no text output at all?
<mjg59> You should at least get the kernel startup output
<blistov> no, i got a console, but it almost immediately failed to mount vfs
<mjg59> Uh.
<mjg59> Right.
<mjg59> Something is very horribly wrong.
<blistov> took about 5 seconds till it paniced
<mjg59> Yeah
<mjg59> Are you able to scroll the output with shift+pgup?
<blistov> buuuut, when i leave the splash on, it runs and does stuff for about a full minute before the hd's stop and cpu stops doing anything (external cpu monitor)
<blistov> not able to scroll.
<blistov> said something about hd8,0 vfs
<mjg59> Sigh. Sometimes the kernel is mean.
<blistov> Hrm.  Any suggestions?  I'm getting fed up with the Gentoo devs, so I do need to start looking at an alternative.  In the past, I've been turned off by Ubuntu simply because it wasn't as easily scalable in the long term, but I've heard that's changed.
<mjg59> Nope, no suggestions
<mjg59> (Sorry, it's past midnight here - I'm not necessarily as sharp as I could be
<mjg59> )
<TheMuso> blistov: Have you tried an alternate CD?
<mjg59> In fact, I really need to hit bed now
<blistov> heh, i'll give the alt a try.
<blistov> thanks
<blistov> any chance some of the weirdness could be caused by my bios initially forcing the tertiary sata controller to present itself as primary for the purpose of bringing up grub ?
<dholbach> good morning
<ion_> good evening
<blistov> wait, any chance the x86 build doesn't run at all on a 64bit cpu?
<TheMuso> blistov: No idea at this stage sorry, have you tried updating your BIOS?
<blistov> (i can't imagine why..)
<blistov> Bios is up to date.
<TheMuso> blistov: The i386 build shoudl work fine.
<blistov> Meh, I'll try alternate.
<blistov> Thanks guys.
<TheMuso> blistov: np, good luck.
<pitti> Good morning
<pitti> thegodfather: mythplugins> looking
<thegodfather> pitti: just read a few lines more in the scrollback
<thegodfather> pitti: it seems to be a known problem with the mirroring
<pitti> thegodfather: on drescher it looks good, can't check LP until my dist-upgrading is done and ff works again
<pitti> thegodfather: on, I see
<thegodfather> but it's still broken.. that's for sure
<pitti> thegodfather: didn't see anything truly enlightening in scrollback; that's something for IS, I think
<pitti> thegodfather: drescher-wise it's fine, and that's where my powers end
<thegodfather> pitti: yes i know. thanks for checking. I thought in the beginning it was a publisher issue...
<thegodfather> we will need to check with elmo and cprov when they are around
<pitti> Riddell: did you see the last comment in bug 184149? that worried me a bit
<ubotu> Launchpad bug 184149 in kdelibs "[hardy]xembed and flash support patches doesn't work for konqueror" [Undecided,Fix committed] https://launchpad.net/bugs/184149
<slangasek> lamont: 64-bit implicit-ptr conversions: fatal on which archs?
<warp10> Good morning
<pitti> hi warp10
<warp10> Hey pitti
<thegodfather> superm1: ping? :)
<thegodfather> slangasek: i assume ia64 and others :)
<slangasek> thegodfather: the "and others" that would be relevant here is amd64...
<thegodfather> slangasek: probably... :)
<mdke> hiya dholbach
<poolie> i'm working on bzr packaging
<poolie> and am getting an error from pdebuild if i have a build-depend that in turn depends on a virtual package
<poolie> in this paces
<poolie> case
<poolie> The following packages have unmet dependencies:
<poolie>   graphviz: Depends: libgraphviz4 (>= 2.16) which is a virtual package.
<poolie> Resolving dependencies...
<poolie> removing that lets it pass
<slangasek> poolie: libgraphviz4 was stuffed in universe by mistake; fixed in next publisher run
<poolie> oh i see
<poolie> so, i should just go ahead and upload with that dependency to our ppa, and it'll come out in the wash?
<slangasek> well, I don't know how often ppa failed builds are retried; for guaranteed results you may want to wait a couple of hours
<poolie> ok
<poolie> but, basically, not my fault
<slangasek> yah
<mdke> dholbach: thanks a lot for those uploads
<dholbach> mdke: no problem
<mdke> dholbach: were there any major problems with ubuntu-docs?
<dholbach> I just added myriads of (LP: #xxxxxxx) entries
<dholbach> mdke: I'll attach the diff
<mdke> :) thanks for that. I was thinking about it but didn't know how to include more than one of those entries. Now I see they are comma separated, I'll do it in the future
<dholbach> no problem
<dholbach> mdke: attached
<mdke> mmm, lots of closed bugs :)
<dholbach> :)
<slytherin> Is anyone already working on evolution build failures?
<lool> slytherin: bug id?
<slytherin> lool: I am looking for bug. I was checking build logs and see FTBFS for everything except powerpc. And surprisingly it doesn't let me upgrade on powerpc due to some version conflicts.
<seb128> slytherin: looking
<seb128> it just needs a retry
<seb128> pitti: can you give a retry to evolution?
<pitti> seb128: done
<seb128> danke
 * seb128 hugs pitti
<seb128> pitti: hey btw, had a good week end? ;-)
<slytherin> seb128: That is waht I thought. But I am trying to build locally just to make sure
<seb128> slytherin: upstream should learn to update the evolution-data-server configure requirements
<pitti> seb128: yes, it was wonderful; we celebrated our 7th anniversary and our 0.5th wedding anniversary :)
<pitti> (same day)
<pitti> seb128: brunch at the Sarrasani circus/variete
<seb128> ah, nice ;-)
<poolie> hello europe
<poolie> i'm trying to build a bzr backport using pbuild
<pitti> hi poolie
<poolie> pbuild
<poolie> pbuild returns 0 and doesn't give an obvious error, but doesn't give me a deb either :-/
<poolie> any clues?
<pitti> poolie: you did look in /var/cache/pbuilder/result?
<pitti> it's not there?
<pitti> (that's where pbuilder puts them by default at least)
<pitti> I don't know the pbuild script, sounds like a wrapper
<poolie> huh
<poolie> yes, it's there
 * pitti just knows "pbuilder build" and "pdebuild"
<poolie> sorry, i meant pbuilder --build
<poolie> so there's a deb in /var/cache/pbuilder/result
<poolie> but i thought previously it was copying them back to the directory above my source directory
<poolie> was i confused before?
 * slytherin declares pbuild as new acronym for 'pbuilder --build' :-)
<Fujitsu> poolie: I don't believe pbuilder ever does that, though sane builders like sbuild do.
<poolie> ok
<poolie> should i be using sbuild insteadL
<poolie> ?
<pitti> poolie: maybe pdebuild does that, but I haven't used it much (usually I want to build a .dsc, not an unpacked source)
<slytherin> poolie: pbuilder doesn't do that. But if you build packages using dpkg-buildpackage -b the you will get the deb where you are looking right now
<poolie> i probably saw a file produced by another command, maybe pdebuild
<poolie> there are certainly a lot of different tools
<poolie> i'm basically just trying to run it here as a dry run for a PPA upload
<poolie> to get a result with less delay
<Fujitsu> You should always do that anyway, rather than uploading builds that you don't know to work...
<poolie> ok
<poolie> so what's the best way to test that something will build on say dapper?
<poolie> i agree that it's a good practice
<poolie> both wrt launchpad cpu resources, and also latency of waiting for the rebuild
<Fujitsu> One can use the pbuilder-dist script to use pbuilder for multiple releases, but I use sbuild with a chroot for each release.
<poolie> so sbuild is an alternative to pbuilder, rather than built on top of it?
<TheMuso> poolie: Yes, but its a little more involved to set up.
<soren> If you use kees' mk-sbuild-lv.sh from ubuntu-dev-tools, it's quite trivial.
<soren> ..assuming you already have lvm set up.
<geser> good morning
<slytherin> seb128: evolution built locally. It was really just a matter of retry. :-)
<seb128> slytherin: I didn't doubt it, I built it myself before uploading
<slytherin> No will have to check whether it updates properly on my ibook
<geser> pitti: Hi, can you move libxstream-java from universe to multiverse please. It build-depends on sun-java6-jdk.
<cjwatson> thegodfather: mirroring brokenness is (ultimately) my fault, so don't bug cprov about it please; I'll work on it
<pitti> mvo: any idea why bash autocompletion for apt-get stopped working?
<mvo> pitti: no
<mvo> pitti: did it maybe moved to the bash-completion package or something?
<pitti> no idea, I just noticed it
<pitti> (while cleaning up the old kernels)
<pitti> geser: will do as soon as my ssh gets unbroken ((#*$# ISP)
<geser> I see libgraphviz4 got moved from universe to main today. Could an archive admin please also move libgraphviz-dev too? graphviz-dev (main) depends on it and imagemagick is in depwait on it. Thanks
<pitti> how come that this is something new?
<Chipzz> while on the topic of bash-completion; could that file please be split up in smaller files?
<Chipzz> it is a very real performance hit on starting a terminal and such
<pitti> geser: oh, it was graphviz-dev before, I see
<mvo> pitti: slangasek mentioned libgraphviz got accidentely moved to universe I think
<thegodfather> cjwatson: ok, i didn't even ping him tbh as i was told he already knew
<Chipzz> heh
<Chipzz> doko is not on IRC anymore?
<Chipzz> !seen doko
<ubotu> Sorry, I don't know anything about seen doko - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
<Chipzz> meh
 * Chipzz kicks ubotu :P
<Chipzz> anyway
<Chipzz> since bash-completion got split out of bash
<Chipzz> I think it would be a better idea to split the script in small pieces and ship those pieces with the relevant packages
<Chipzz> how does that sound?
<Chipzz> mvo: would that be possible for apt for example?
<jpatrick> Chipzz: /msg SeenServ seen doko
<mvo> Chipzz: sure
<cjwatson> some packages do that already. Looking at e.g. the ssh completion, the main obvious problem for me in shipping that separately is that it's not a trivial chunk of code to copy and paste, and it would require me to take on maintenance of it; as soon as I copy it then we lose out on the benefits of the work done by bash-completion upstream.
<Chipzz> cjwatson: bash-completion is unmaintained upstream
<cjwatson> that's an accident and might well not always be the case
<Chipzz> cjwatson: says both on https://launchpad.net/ubuntu/+source/bash-completion, and the last update on the homepage is a long time ago
<tjaalton> let's switch to zsh \o/ :)
<Chipzz> cjwatson: the problem is the delay from having bash_completion enabled in .bashrc is very noticable; ie over 1 second delay when starting a terminal
<cjwatson> zsh is an interesting thing to mention. It also ships a lot of completion. How many shells should packages ship completion for?
<cjwatson> one? two? 300?
<cjwatson> it's not entirely obvious whether it belongs in a shell-specific package or in a feature-specific package, is my point
<Chipzz> point taken
<Chipzz> but
<Chipzz> I don't think there's that many shells to start with, and even less that support completion?
<cjwatson> sure, but I certainly couldn't maintain zsh completion rules because I don't speak zsh
<Chipzz> dash/ksh variants/etc all don't even support completion at all
<cjwatson> so even right now it is impossible for me to cater in the same way for all shells supporting completion
<cjwatson> the shell maintainers will do a better job
<tjaalton> zsh upstream maintains all the completions
<Chipzz> cjwatson: but I guess my reply to that is: zsh completion is optional; if it's already written, integrate in your package; if it isn't, accept patches that do implement it
<cjwatson> on the performance hit, I would suggest simply disabling it, and sourcing it when you need it
<Chipzz> that way you wouldn't have a feature regression
<cjwatson> that's what I do
<cjwatson> and doesn't seem significantly more complex than sourcing a bunch of different files whose names are likely to change over time, etc., etc., tedium
<Chipzz> well the thing is that there is some functionality of bash_completion that I use on a daily basis
<Chipzz> and
<cjwatson> please don't do that thing with putting conjunctions on a single line of IRC
<Chipzz> . /etc/bash_completion doesn't complete very nicely
<cjwatson> well, it's in /etc, you *could* just strip out the stuff you don't want :-)
<Chipzz> maybe we could consider splitting out the most often used parts of it
<Chipzz> altough it wouldn't be immediately obvious what those parts are or how that's going to benefit
<Chipzz> for me the most often used functionality is ssh completion and apt/dpkg completion
<Chipzz> cjwatson: as a reference point, last upstream update was 20060301, which is almost 2 years old
<lool> cjwatson: I filed bugs against quilt, dpatch and cdbs to use touch --date or similar to set the timestamp as dpkg-source does
<Chipzz> http://www.caliban.org/bash/#completion_download
<lool> I was surprized to not find any bug on this subject on all three packages
<cjwatson> lool: cool, thanks
<lool> cjwatson: Thanks for the idea; I didn't know dpkg-source was clever
<cjwatson> lool: it hadn't occurred to me that they would have the same problem, though it's obvious in retrospect
<lool> First I suspected it had a broken trick such as sorting files or so
<ogra> cjwatson, is there *any* documentation of gfxboot somewhere (beyond teh code) ? i tried to wrap my head around it on the weekend but failed (actually i wanted to have a patch for an LTSP entry in the modes menu ready for you)
<ogra> (and the basic knowledge to get the addon welcome screen going)
<cjwatson> ogra: there's language-evel documentation in gfxboot/doc/ (you have to build it), but otherwise no
<cjwatson> language-level
<ogra> i'll look at that
<ogra> it looks like it is using its own interpreter language
<cjwatson> it will at least give you the minimum knowledge to decipher the language - unfortunately practical use requires building a bunch of stuff on top of the basic facilities
<cjwatson> yes
<cjwatson> it's a forth-like bytecode-compiled language
<cjwatson> or postscript-like, if you prefer
<ogra> ps is something i used before ... forth now really :)
<ogra> s/now/not/
<pitti> geser: both done (multiverse/main)
<geser> pitti: thanks
<Riddell> anyone know why graphviz was moved to universe?
<pitti> Riddell: I just kicked the binaries back
<pitti> wrong override apparenlty
<Riddell> pitti: ok, could you give back kdelibs
<pitti> done
<geser> pitti: please also give-back: bzr doxygen. It FTBFS because graphviz wasn't installable. Thanks.
<pitti> geser: done
<lool> pitti: Do you know why Debian's sysvinit didn't merge "multiuser"?
<pitti> lool: they changed sysvinit to respect the LSB headers
<lool> (I'm seeing this in the dbus package and I guess it speeds up shutdown as we don't need to stop dbus
<pitti> lool: but it's not enabled by default AFAIK
<pitti> I think this is a better approach than our multiuser hack
<lool> So we should stop using multiuser in ubuntu and simply list nothing in stop levels?
<pitti> but nobody had time to work on that yet
<pitti> lool: ideally yes, but the code doesn't respect it by default ATM
<pitti> and we haven't merged sysvinit for ages
<lool> The sysvinit one?
<pitti> yes, because of upstart & co
<lool> Do you know whether it's honored in Debian at least?
<pitti> not 100% sure, but I think it's not enabled by defautl
<lool> Anyway, doesn't hurt to list nothing in stop-levels
<pitti> right
<lool> pitti: (thanks!)
<geser> pitti: did the give-back of bzr succeed? because https://edge.launchpad.net/ubuntu/hardy/+source/bzr/+builds shows no sign of a new build attempt
<pitti> I wasn't asked to give it back
<pitti> done now
<geser> pitti: [11:44:56]        geser | pitti: please also give-back: bzr doxygen.
<pitti> geser: oh, that slipped my mind, sorry
<geser> np
<pitti> seb128: is it safe to restart the i386 retracer?
<seb128> pitti: if it doesn't crash yes
<seb128> pitti: it has not been stopped on purpose, it's just crashing
<seb128> pitti: did you figure what was wrong?
<pitti> ValueError: Unsupported attachment-type '<type 'set'>'
<seb128> yes, that one
<pitti> seb128: no, I haven't looked into it at all
<pitti> first time I see it
<seb128> I told you about it some days ago
<pitti> thekorn, any idea?
<pitti> seb128: yes, that it's stopped and that you asked thekorn about it
<seb128> pitti: https://bugs.edge.launchpad.net/python-launchpad-bugs/+bug/191963
<ubotu> Launchpad bug 191963 in python-launchpad-bugs "ValueError: Unsupported attachment-type '<type 'set'>' " [Undecided,In progress]
<pitti> seb128: Friday was too crazy to look into it, sorry
<seb128> pitti: that's alright, thekorn said he doesn't got the issue and that he would try on a dapper vm later
<seb128> pitti: maybe untag the bug which makes it crashing for now and restart?
<pitti> ah, thanks for the bug #; subscribed
<pitti> yep
<seb128> pitti: you are welcome ;-)
<thekorn> seb128, pitti , sorry forgot to mention, I can not reproduce this error in a dapper vm
<seb128> thekorn: hum, ok, thanks
<geser> thekorn: is there an other way to specify the cookie python-lp-bugs should use instead of "exporting" the lp cookie with a small script from cookies.sqlite (Firefox 3) and writing it into a file?
<geser> or is the old cookies.txt format the only one supported by python-lp-bugs?
<thekorn> geser: I'm working on a solution for the .sqlite format, but in the hardy version of py-lp-bugs you can also use:
<thekorn> Bug.authentication = {"password":<password>,"email":<email>}
<thekorn> geser, where password and email are you login data in LP
<geser> good to know
<davmor2> How's Alpha 5 shaping up, is it ready to test?
<cjwatson> davmor2: seems a bit early yet
<cjwatson> davmor2: a few bits of the archive and CD processes are busted at the moment so probably not very
<davmor2> cjwatson: np's just queried as there had been no daily updates so thought it might be safe to test.
<cjwatson> davmor2: that's due to the archive bustedness :-)
<cjwatson> there have been updates, they just aren't getting mirrored out ...
<davmor2> ahhh
<ogra> pitti, about the classamate-settings package, i can drop the user parts (can go to the installer script) as well as the firefox cache disabling (can go into an initramfs bottom script) ... but i cant drop the static xorg.conf since i have to a) force a driver we dont detect for that card and b) need to have a virtual screenwhich we dont support at all in the default configurator in any case
<ogra> *screenwidth
<pitti> ogra: why does it have to be a package at all? this seems to unfitting
<ogra> pitti, would the package be ok with you with tehse changes ?
<davmor2> is it possible to get f-spot to change backends for burning or not does anyone know?
<pitti> breaking X.org's configuration file is still bad IMHO
<ogra> pitti, we will always need to ship a static one for classmate
<pitti> seb128_: retracer is running again for now
<pitti> ogra: we can't fix the X.org detection to properly treat the classmate?
<ogra> pitti, we have an agreement that we will support screen panning thast something we (and upsteam) just weeded out completely from the config ools
<pitti> that will improve it for similar hardware, too
<ogra> detection is only one part of it
<pitti> ogra: ok, I see
<ogra> and we cant do any detection mechanisms during bot anyway
<pitti> well, why not make it part of the install script then?
<ogra> (i.e. like the livecd does)
<pitti> meh, retracer already failed again
<ogra> pitti, it will even get more tricky as we probably have to support two diaply variants ... both dont return any EDID data
<ogra> *display
<ogra> (its not clear yet if we need to support both for hardy final though, but if thats the case i need t even supply two static files that are used alternating depending on the HW it runs on
<ogra> )
<MacSlow> asac, is a corrupt language-support-writing-en package perhaps moe more issue due to firefox3? I just ran into that.
<pitti> MacSlow: that got fixed this morning
<MacSlow> pitti, but why does it show up for me then still? New/fixed packages not yet fully exposed via the repos?
<pitti> MacSlow: might not yet be published
<ogra> MacSlow, btw cairo-dock rules the world on the classmate :) i tried a setup with cairo-dock, pcmanfm an metacity with composite enabled yesterday ... its the fastest and most responsive desktop setup i've tried so far :) (things like awn just eat your ressourcesm, cairo-dock seems to not do that by some reason)
<seb128_> pitti: cool, did you workaround the bug or just untagged the bug?
<pitti> seb128_: just untagged; but as I said above it already failed again on a different bug
<pitti> and if my ssh ever comes back, I could actually report it and untag/restart
<ogra> MacSlow, is there a roadmap anywhere for it ?
<seb128_> pitti: you likely commented when my dsl disconnected
<seb128_> ok
<MacSlow> ogra, well I don't know how much of the original approach the french folks, who picked it up changed... but back when I started it, I made sure to stick to best practises regarding cairo-usage
<pitti> thekorn: FYI, bug 192892
<ubotu> Launchpad bug 192892 in python-launchpad-bugs "TypeError: argument 2 to map() must support iteration" [Undecided,New] https://launchpad.net/bugs/192892
<pitti> seb128_: ^
<pitti> MacSlow: right, not published yet; fixed in version 8.04+20080218
<ogra> yeah. its incredibly "non stuttering" on that HW ... all the others do their autohide "in several steps" :)
<MacSlow> ogra, maybe... I never wanted to do more than experimenting with cairo, when I started cairo-dock... I'm actually surprised that it stayed "alive"
<MacSlow> pitti, ok
<ogra> well, compared to AWN or that wxwindows based one its just a ton better
<MacSlow> ogra, I cannot really remember if I did add image/xlib/glitz-surface support in cairo-dock, like I did for some other cairo-things I wrote... that would allow the user to choose the best available option for rendering (acceleration)
<ogra> it depends on glitz so i think you used glitz functions there
<ogra> not sure it does that b default
<MacSlow> ogra atm it is expected to get best results form using cairo's xlib-surfaces (which would benefit from EXA... if the xorg-driver is properly written/complete)
<ogra> well, anyway, we should look into that for a lowend desktop variant in hardy+1 :)
<pochu> pitti: did you get libcrypto++ out of NEW? It's already available in archive.u.c for amd64 and ppc, but missing for the rest. (bug #189243)
<ubotu> Launchpad bug 189243 in libcrypto++ "please sync libcrypto++ 5.5.2-1 from Debian testing" [Wishlist,Fix released] https://launchpad.net/bugs/189243
<ogra> i'd like to get away from gnome for the classmate if we have to do more images for that ... its just to heavyweight
<ogra> and i guess such a desktop would help with the other subnotebooks as well ...
<geser> pochu: a.u.c is out-of-date since Friday
<pochu> geser: oh, that would explain it.
<pochu> pitti: ^-- nevermind. thanks anyway
<pitti> ok
<mdz> what's the difference between ~/.Trash and ~/.local/share/Trash?
<mdz> I have files in both
<pochu> geser: I assume there's someone working on it? :)
<pochu> mdz: the latter is the new one in gio. I thought there was a migration path
<pochu> the latter is fdo compliant
<mdz> if so, it doesn't seem to have worked for me.  on my desktop, I have files in both places.  on my laptop, all my trash is in ~/.Trash, but the trashapplet only looks at the other one
<geser> pochu: afaik cjwatson_ is working on it
<pochu> mdz: there's http://bugzilla.gnome.org/show_bug.cgi?id=509759. Perhaps I was wrong with the migration path
<ubotu> Gnome bug 509759 in trash applet "Migrate from GnomeVFS to GIO" [Major,Resolved: fixed]
<cjwatson> geser,pochu: yes, I am, amid other things
<davmor2> cjwatson: can you change the burning backend of f-spot to use gvfs if so how?
<cjwatson> davmor2: I have no idea, and am not quite sure why you're asking me :)
<ogra> heh
<ogra> davmor2, thats rather a question for one of our gnome guys
<seb128_> mdz: .Trash is the old gnome-vfs location, .local/share/Trash is the new gvfs freedesktop one
<davmor2> sorry just thought I'd ask
<seb128_> mdz: upstream will add some code to migrate .Trash to the new location, likely to gnome-session, that has not been done yet though
<cjwatson> I don't mind being asked, but you'd have a better hit rate from picking somebody who works on the package in question
<davmor2> np's I've written a bug report for it anyway just wondered if anyone knew.  It's still using gnome-vfs by default.
<seb128_> davmor2: gnome-vfs doesn't do burning, I don't know the f-spot code though
<pitti> yay, I think I fixed the p-lp-bug
 * thekorn hugs pitti!!
<pitti> thekorn: I dumped it all into the bug report, including a patch
<thekorn> pitti, reading it
<davmor2> seb128_: bug 192510
<ubotu> Launchpad bug 192510 in f-spot "F-spot still depends on gnome-vfs to burn cds and fails" [High,Triaged] https://launchpad.net/bugs/192510
<davmor2> seb128_: there is a screenshot attached of the bug I get
<Riddell> pitti: mega giveback if you could.  kdebase kdeaccessibility kdeadmin kdebindings kdeedu kdegames kdegraphics kdemultimedia kdenetwork kdepim kdesdk kdetoys kdeutils kdewebdev kdevelop
<MacSlow> bryce, didn't the patch for fixing the drop-shadow-decoration rendering under EXA (intel, i965) work?
<pitti> re
<pitti> Riddell: done
<Riddell> thanks
<pitti> hmm, just started current live CD
<pitti> what's the difference between "Try Ubuntu without any changes" and "Install Ubuntu"? Shouldn't both be a live system with ubiquity?
<mjg59> pitti: The latter just starts the installer, not a GNOME session?
<pitti> Possibly; haven't tried it yet
<cjwatson> mjg59 is correct
<cjwatson> cf. hardy-bootloader-review
<ogra> seb128_, where do we hide the ssh connection options for nautilus nowadays ? i just searched my ass off but seem to be to blind to find it
<seb128_> ogra: what ssh options?
<ogra> it was called "connect to server" once and created a folder with the connection transparently on the desktop
<seb128_> ah, no
<ogra> seems that whole thing has vaished
<ogra> *vanished
<seb128_> the thing is that gnome-vfs didn't have persistent mount, it was just using the URIs
<seb128_> those were a workaround to sort of "bookmark" the connection for easy use
<seb128_> the new gvfs stack mounts thing on first access and they stay mounted for the session
<seb128_> so that's not required
<ogra> well, i cant create the connection first place
<seb128_> the first time you access it in nautilus it'll be mounted and be listed in all applications
<ogra> since we dont have the UI bits anymore
<seb128_> just type the ssh url in nautilus
<ogra> ah, k
<seb128_> you can add standard bookmarks and use it too
<seb128_> you are not the only one confused though
<ogra> will we get a UI for final ?
<seb128_> they will add a connect to serrver which creates bookmark before GNOME 2.22
<seb128_> yes
<ogra> (feels very KDEish to have to type urls in the filemanager :) )
<ogra> ah, cool then
<ogra> hmm, doesnt seem to want to connect
<seb128_> what is the prompt you get using ssh on a command line?
<seb128_> did you specify an user?
<ogra> i tried both: ssh://ogra@rookery.ubuntu.com/ as well as the same with sftp protocol
<seb128_> and without specifying an user?
<ogra> hmm, wait a sec, seems not to work on cmdline
<ogra> seb128_, hmm, it helps to have ~/.ssh/config in place :P ...
<ogra> but beyond that it always only offers me to have a connetcion to / on my desk, seems the mount doesnt handle subdirs
<seb128_> ogra: ;-)
<ogra> so drag n drop like i had it before would end up in / on rookery if i dont open a browser win and navigate to the dir forst
<seb128_> ogra: that's a mount, the same way than mounting a partition or a CDROM or an usbkey only mount the device and not subdirs
<frafu> Hello doko, I wanted to let you know that Henrik and Luke have replied to your question in the mir process of mousetweaks: https://bugs.edge.launchpad.net/ubuntu/+source/mousetweaks/+bug/190208
<ubotu> Launchpad bug 190208 in mousetweaks "Main Inclusion Report for mousetweaks" [Undecided,Incomplete]
<ogra> yeah, but te former variant offered me to have a shortcut on the desktop with the right dir directly selected
<seb128_> ogra: use bookmarks
<seb128_> what with wrong with adding the directory to your bookmarks?
<ogra> apparently i cant drag a bookmark from the treeview to the desktop  ...
<ogra> waht i used to use before (i.e. for screenshots) was a folder on the desktop that scp's to my public_html on drop ... tahst apparently not possible with te new way
<ogra> ARGH
<seb128_> ogra: not yet, those are lot of changes
<ogra> and dragging from te places menu starts to copy / from rookery !!
<ogra> (copying 3.9G)
<seb128_> they are working fast a fixing regressions and issues don't worry it'll be in shape for hardy
<ogra> good
<ogra> would be odd if our users suddenly find the / of their servers everywhere *g*
<MacSlow> seb128_, there's a debian/control and debian/control.in file in libwnck. Which sould I touch if I want to add a new build-/dependency? Just the debian/control.in I assume?!
<ogra> thabnks for the hints, i'll live with what i have atm :)
<ogra> ohh, the trayicon is sweet :)
<pitti> thekorn: ah, thanks for the patch; that might explain other spurious bugs, too
<ogra> so back to what i needed the scp for ...
<ogra> asac, http://people.ubuntu.com/~ogra/firefox_weirdness.png
<asac> ogra: known issue
<asac> ogra: if you have a chance to use EXA ... that will fix it
<ogra> k
<asac> its a bug in XAA create picture implementation for REPEAT_NORMAL
<ogra> i dont think my thin client has EXA capabilities
<asac> nobody knows how to fix :)
<seb128_> MacSlow: control.in
<ogra> i can try to tweak xorg.conf though
<asac> (well we have a patch for that for cairo ... but thats a workaround)
<MacSlow> seb128_, ok, thanks
<seb128_> MacSlow: it's copied over the control during the clean target
<seb128_> you are welcome
<seb128_> do you can "debuild clean" to update control
<ogra> asac, ok, just wanted to show it in case its not known yet ... its funny that the url bar updates if i type in th real one :)
<asac> seb128_: any news on fixing the issue that configure is run during clean for all gnome packages btw?
<asac> (i bumped into that for seahorse today again)
<seb128_> asac: is that bug discussed upstream? We got a libcairo debdiff from fta I think but I prefer to not apply workarounds if the issue is not being worked at the right place
<seb128_> asac: no, it doesn't annoy me and I've other things on my todolist to do before looking at that ;-)
<MacSlow> seb128_, would the "+git20080214" of "0.6.99+git20080214" belong to the version-number one has to state in "package (>= some.version.number)" in debian/control?
<asac> seb128_: you have a bug id for fta patch?
<asac> seb128_: upstream knows about it
<seb128_> asac: bug #186186
<ubotu> Launchpad bug 186186 in xulrunner-1.9 "web page background render errors" [High,Confirmed] https://launchpad.net/bugs/186186
<seb128_> MacSlow: yes
<asac> seb128_: commented
<seb128_> asac: thanks
<cjwatson_> ogra_cmpc: please excuse the zillion Edubuntu CD builds today - I'm using you as a test case
<ogra> cjwatson, dont excuse :)
<ogra> s/excuse/apologize/ :)
<frafu> doko : ping
<HighNo> are there gdebi developers available?
<lamont> slangasek: if we deployed it, it would be on all archs (which would mostly mean that it failed on amd64/ia64)..
<mvo> HighNo: yes
<HighNo> My problem is a hand edited .deb file gets installed perfectly by dpkg but get rejected as being unreadable or corrupt by gdebi
<mvo> HighNo: I see, could you please file a bugreport with the deb attached ?
<HighNo> mvo - ok, will do
<HighNo> mvo: created as https://bugs.launchpad.net/gdebi/+bug/192939
<ubotu> Launchpad bug 192939 in gdebi "gdebi rejects a package that dpkg does accept" [Undecided,New]
<HighNo> mvo: ah - forgot to say I am running feisty
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek about to start in 25 minutes in #ubuntu-classroom
<mruiz> hi all . I tried to install five-a-day but it complained:   five-a-day: Depends: python-central (>= 0.5.50) but 0.5.15ubuntu3 is to be installed
<lool> dholbach: ^^^
<dholbach> lool: python-central has built on the buildd, but it's not published yet it seems
<lool> Aha
<lool> nm then, sorry for the useless ping
<dholbach> but it's since a few hours already
<dholbach> I wonder if soyuz has a hiccup
<dholbach> https://launchpad.net/ubuntu/+source/python-central/0.5.50ubuntu1
<mruiz> thanks dholbach
<soren> Has anyone tried the daily alternate installer lately?
<ogra_cmpc> soren, friday the last time
<soren> ogra_cmpc: And it worked, I suspect?
<ogra_cmpc> yeah
<soren> What are the memory requirements for the alternate installer?
<ogra_cmpc> i just checked, it was the image from the 14th though
<ogra_cmpc> i think something around 64M should work
<soren> ogra_cmpc: Ok, that's not it, then.
<ogra_cmpc> migth have increased though, i ddint test d-i in such small setups lately
<soren> I'm reliably informed that it gets stuck during "saving language settings" if you run it inside kvm.
<soren> Meh... I'll look into it.
<mvo> soren: I did a netinstall at sunday
<soren> mvo: That doesn't help much, I'm afraid. The server install works just fine, too.
<soren> Don't worry about it just yet. I'll test it myself and do some digging.
<slangasek> lamont: ok; I'm concerned there that, TTBOMK, the amd64 loader will rarely map libraries above the 32-bit mark, so it seems kinda late in the cycle to add a bunch of new RC bugs for an issue with no practical impact on the release archs
<ogra_cmpc> soren, savaing language settings is the very end before grub-install starts i think
<ogra_cmpc> might be the grub part locking up here
<soren> ogra_cmpc: It could be, but isnt :)
<soren> ogra_cmpc: Thanks for the hint, though.
<ogra_cmpc> ah, no, it canht, the screen would have been cleared already if you are i n the next st4ep
<ogra_cmpc> meh i need to train more on that keyboard again
<soren> ogra_cmpc: Also, the syslog shows when each finish-install script is invoked, and it doesn't say anything after localechooser (afair)
<mtaylor> um... why does ubuntu-minimal depend on alsa-base alsa-utils? Do I really need sound on a minimal system?
<crimsun_> that point has been raised several times.
<mtaylor> ok
<mtaylor> any chance there's a ranting web page explaining the choice somewhere?
<crimsun_> I don't know offhand.
<Nafallo> crimsun_: what's your opinion on that one? :-)
<Nafallo> just curious
<crimsun_> it should be at most Recommends.
 * mtaylor thinks that if we think sound is an integral part of the system, there should be an alternate ubuntu-server package one can install ...
<Nafallo> yea. of standard :-)
<mtaylor> Nafallo++
<Nafallo> mtaylor: all servers are diverse and different. so I don't believe in a server seed
<mtaylor> Nafallo: I don't really either...
<emgent> heya thegodfather
<mtaylor> Nafallo: I'm just saying that if minimal is going to stick desktop need in... I would like a server thing that doesn't have them
<Nafallo> hehe
<cjwatson> mtaylor: the reason we put that stuff in ubuntu-minimal is because alsa-* is needed for stability of hardware detection
<mtaylor> cjwatson: wow. really?
<cjwatson> mtaylor: all possible server profiles are by design supersets of minimal
<cjwatson> we certainly won't be offering anything that's less than that
<mtaylor> cjwatson: I would certainly expect them to be supersets of minimal
<cjwatson> I would like to see stuff organised such that we didn't need alsa-* in minimal for stability though
<mtaylor> I would agree.
<mtaylor> I can understand their existence there for that reason - but I would suggest that it's a bug in hardware detection that that is the case
<cjwatson> it's not as important as it used to be, actually
<jwendell> asac, have you noticed that java plugin doesn't work with firefox 3?
<cjwatson> it used to be that the installer was two-stage; after installing a minimal system, it rebooted to install everything else, and then dropped you into the final system without rebooting again
<cjwatson> so, if stuff like alsa-base that provides /etc/modprobe.d files and alsa-utils that provides udev rules weren't installed in the first pass, your first boot would be different from all the rest
<cjwatson> however, in dapper, we finally got the installer reorganised so that it could all operate in a single stage
<cjwatson> so I think there is now a case for moving alsa-* to desktop
<cjwatson> crimsun_: what do you think?
<crimsun_> cjwatson: agreed.
<asac> jwendell: which java plugin?
<jwendell> asac, sun-java6, which doesn't even appear in about:plugins
<jeromeg> asac: jwendell : there seems to be bugs about it
<jeromeg> bug 192962 for example
<ubotu> Launchpad bug 192962 in sun-java6 "sun-java6-plugin does not work in firefox3" [Undecided,New] https://launchpad.net/bugs/192962
<jwendell> reported 11 minutes ago hehe
<asac> jwendell: yes, the package post* scripts haven't been updated yet
<ogra_cmpc> cjwatson, why not have an alsa-common that only ships modprobe.d files and udev rules ?
<cjwatson> ogra_cmpc: no need, per the above
<jwendell> asac, but the slinks seem to be ok... is there any other thing that needs to be done in order to make it work?
<mtaylor> cjwatson: should I file a bug somewhere?
<asac> jwendell: which slink?
<mgunes> hi all. when submitting a debdiff for sponsorship by u-m-s should I keep the maintainer field intact and add myself to "Uploaders"?
<cjwatson> mtaylor: no need, I'll just do it and send mail to ubuntu-devel for the record
<mtaylor> cjwatson: great
<jwendell> asac, /usr/lib/firefox/plugins/libjavaplugin.so -> /etc/alternatives/firefox-javaplugin.so
<asac> jwendell: thats the old place. new place is /usr/lib/xulrunner-addons/plugins/
<jwendell> hmmm
<cjwatson> ogra_cmpc: do you have a specific concern about those files moving to desktop?
<ogra_cmpc> cjwatson, nope
<cjwatson> ok, good
<crimsun_> mgunes: See https://wiki.ubuntu.com/DebianMaintainerField.
<ogra_cmpc> i just saw your comment that the only reason were modprobe.d and udev
<ogra_cmpc> and was wondering why we never solved it like that
<cjwatson> ogra_cmpc: because this was put in place before the single-stage installer work, and we never revisited it afterwards
<ogra_cmpc> quite a while :)
<cjwatson> indeed :)
<ogra_cmpc> but now that you point it out, i need to add it to the ltsp-client deps then :)
 * ogra_cmpc notes down on whiteboard
<mtaylor> also... while I'm being annoying, is there any reason why the ubuntu version of lintian in hardy needs to complain about invalid distro name for hardy and gutsy and stuff?
<cjwatson> ogra_cmpc: *nod*
<cjwatson> mtaylor: it only does that if the package's version number doesn't contain 'ubuntu'
<cjwatson> it's a heuristic to try to avoid skew between Debian's lintian and Ubuntu's
<jwendell> asac, thanks, plugin working now :)
<mtaylor> cjwatson: any way we could get it to also search for gutsy or hardy, etc in the version number field?
<mtaylor> sometimes having -1ubuntu1gutsy1 starts to get ridiculous
<cjwatson> mtaylor: that sounds like unusual versioning
<cjwatson> mtaylor: are these packages in the Ubuntu archive?
<mtaylor> cjwatson: no
<ogra_cmpc> that would be broken
<cjwatson> mtaylor: ok, the reason we do this is because 'ubuntu' is actually magic in Ubuntu version numbers
<cjwatson> mtaylor: it inhibits the autosyncer from syncing those packages from Debian
<mtaylor> ah
<MacSlow> pitti, any idea if de.archive.ubuntu.com is down? It's being unresponsive for me here.
<cjwatson> mtaylor: but sure, I could make that change in Lintian upstream
<cjwatson> though not sure if it'll make it into hardy
<pitti> MacSlow: same for me
<mtaylor> cjwatson: it's not _pressing_ of course
<MacSlow> pitti, pk
<MacSlow> pitti, ok
<cjwatson> mtaylor: right, you can clearly just ignore those warnings
<mtaylor> cjwatson: my thing is, I'm trying to make ubuntu package of mysql to be distributed by MySQL... so we'll have a feisty, gutsy and hardy package for a release we do, right?
<mtaylor> cjwatson: and there's no real need in that case to have ubuntu in the version string
<cjwatson> mtaylor: the only thing I'd say there is that it's worth following Ubuntu versioning practices as closely as possible in order that upgrades work properly in both directions
<cjwatson> mtaylor: but I don't think it'll make a huge difference, and in your position I would probably just ignore the warning
<mtaylor> cjwatson: yes... I'm actually quite interested in upgrades working in both directions :)
<mtaylor> ok
<cjwatson> -               if ($data->{'version'} =~ /ubuntu/) {
<cjwatson> +               if ($data->{'version'} =~ /ubuntu|hardy|gutsy|feisty|edgy|dapper/) {
<cjwatson> mtaylor: ^-- committed upstream
<mtaylor> cjwatson: you rock!
<ogra_cmpc> mtaylor, he does :)
<superm1_> cjwatson, did you by chance glance over the changes i made to cdimage, to see if they can be merged into mainline?
<cjwatson> superm1_: I think I missed them
<superm1_> cjwatson, let me grab the branch url again then, sec
<cjwatson> superm1_: my main concern is that I'm pretty sure we're out of space to host more derivatives
<cjwatson> superm1_: so if it's just to have the code merged, fine, but a hosting request is more difficult
<superm1_> cjwatson, would it be possible to only keep one of the daily images generated, and toss any older ones?
<superm1_> that way it would be minimal space requirements?
<cjwatson> yes, but even then we're really getting painfully close to the wire
 * ogra_cmpc sees edubuntu on cdimage seems to buikld now :)
<cjwatson> it becomes a serious problem every now and again
<cjwatson> ogra_cmpc: yeah, I think I got it working, though it needs testing
<superm1_> cjwatson, well getting the code merged would be a good start for now at least
<cjwatson> superm1_: could you run it by slangasek and ask him to look at the merge?
<ogra_cmpc> cjwatson, btw, did you see amits mail about the usb suspend ? i'm not reallly fond of having a separate kernel package just for that one change
<cjwatson> ogra_cmpc: no, where?
<ogra_cmpc> i CCed you in my answer
<cjwatson> ogra_cmpc: oh, that's been a contentious problem for some time
<superm1_> cjwatson, sure.  I had figured I should run it by you since I branched I pushed them to http://bazaar.launchpad.net/~mythbuntu/ubuntu-cdimage/mythbuntu-cdimage/, is that not the main branch then?
<ogra_cmpc> apparently the patch for poersistent USB disks is in the kernel since some time already
<superm1_> er from
<cjwatson> ogra_cmpc: it's one of those things where if you turn it on, you break one set of hardware, and if you turn it off, you break a different set
<ogra_cmpc> but we never enabled it in out builds
<superm1_> http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/
<cjwatson> ogra_cmpc: Ben has looked into it before
<ogra_cmpc> ah, k
<ogra_cmpc> so i actually need a separate build :(
<cjwatson> superm1_: yeah, the public mirror is mine but actually all of ~ubuntu-cdimage have magic write access behind the scenes
<superm1_> cjwatson, ah okay.  i'll check with slangasek then.  thanks.
<cjwatson> the real master copy is on the cdimage build machine
<cjwatson> ogra_cmpc: I agree that it would be useful to have it as a boot option
<cjwatson> ogra_cmpc: but I can't answer as to whether that's feasible
<ogra_cmpc> right
<soren> Ok, I've reproduced the alternate install CD's stuckage.
<ogra_cmpc> what is it ?
<soren> localedef seems to be stuck in an infinite loop somewhere.
<soren> strace and ltrace are both silen.
<soren> +t
<soren> It's eaten 33 minutes and 16 seconds of CPU time already.
<soren> Does anyone have a physical machine they can try to reproduce this on? (i'm doing this in kvm)
<ogra_cmpc> cjwatson, i assume report.html doesnt gain me any info anymore for the addon now ?
<ogra_cmpc> seems it lists all packages ...
<cjwatson> ogra_cmpc: oh, err, yeah, it's probably completely useless
<ogra_cmpc> right
<cjwatson> ogra_cmpc: please turn it off in cdimage/bin/build-image-set
<cjwatson> check for [ ! "$CDIMAGE_ADDON" ] or some such
<ogra_cmpc> ok
<cjwatson> soren: localedef is notoriously memory-hungry and can easily suck 50M
<cjwatson> soren: how much have you got?
<cjwatson> soren: swap's supposed to be switched on by that point so it isn't normally a problem
<soren> cjwatson: 128MB. 10 of which are free, and there's 150MB swap free.
<soren> I suppose it could be semi-interesting to try it with significantly more memory, but as it's completely CPU bound..
<soren> 40 minutes, 44 seconds (on a 1.2GHz box).
<cjwatson> it generates UTF-8 locales by building up a gigantic table in memory
<cjwatson> soren: capture the command line it's using and try it somewhere else?
<cjwatson> could be a genuine locale-specific bug
<soren> I'm guessing someone would have caught it.. It's en_US.UTF-8 :)
<soren> But sure.
<soren> Er... I can't even kill -9 it.
 * soren sighs
<cjwatson> soren: that would suggest a kernel problem ...
<ogra_cmpc> hmm, why cant i9 access lithium anymore
<elmo> because it's not lithium
<elmo> and hasn't been for months
<ogra_cmpc> i didt have to touch it for ages
<elmo> you asked the same question last time dude
<elmo> try antimony
<ogra_cmpc> gah
<ogra_cmpc> i use it to rarely ...
<ogra_cmpc> elmo, thanks
<cjwatson> ogra_cmpc: I suggest that you keep a record of this by way of e.g. comments in ~/.ssh/config so that you don't forget again
<slangasek> infinity: can you give compiz back on all archs !i386?
<danimo> hi
<danimo> did anyone test wine on hardy lately? I get a core dump on like every binary I am trying to execute, immediately on start.
<danimo> in libwine
<danimo> uni2cp_low is the last useful function I get in the bt, I need to try with dbg packages if that's not a known problem
<\sh> danimo: it's known and I#m working on it
<danimo> \sh: ah, good to know
<\sh> danimo: I'm compiling this damn thing since this morning
<andresj> hello! I'm not sure if this is the right channel, but is there a tool for making svn snapshot source packages? I want to regularly upload them to Launchpad PPA...
<andresj> I want to use blender as my first test. I have downloaded the latest stable source package already.
<Chipzz> andresj: if you don't get an answer here, try #ubuntu-motu
<Chipzz> slightly more on-topic there
<andresj> thanks Chipzz. askin there... :)
<superm1_> Is there an equivalent package to desktop-base that would provide a similar 640x480 wallpaper for Ubuntu?
<cjwatson> pitti: what's happening with getting Arne's language-support changes merges?
<cjwatson> merged
<cjwatson> pitti: that really should happen tomorrow if we want it for hardy
<cjwatson> which I think we do
<lamont> slangasek: "rarely" just means that it's a royal bitch to track down when the bug _is_ hit
<slangasek> lamont: but isn't "rarely" on amd64 really "in extreme circumstances that would only be encountered by users running a ucLinux kernel in their madness"?
<slangasek> or "load the program, allocate a 4GB array, then dlopen a plugin linked to every library on the system"...
<lamont> dunno.. I know I had some bind bugs that were related to 64-bit beyond 4GB on amd64
<slangasek> hmm, ok
<slangasek> that's a different story, then.  is there any hope of a rebuild test of main with this option before switching it on the buildds, though?
<slangasek> lamont: otherwise, without a full rebuild test we have no assurance of noticing the issue before, say, we need to do a post-release security update...
<lamont> slangasek: I believe that we can process all of the autotest logs...
<lamont> at least I think we still have these
<lamont> :-)
<lamont> I'll check with infinity in the morning about where the current autotest logs are, and we can certainly scrape them for the failures
<slangasek> ok, cool
<bryce> MacSlow: yes the patch I did for drop-shadow-decoration works great; I've got it installed on my 965 laptop and am having no problems with it
<bryce> MacSlow: I asked tjaalton about uploading it, but he suggested turning on greedy by default instead, which I gather also solves the issue but in a different way, and also addresses performance and other issues
<bryce> MacSlow: anyway, so I've done up a patch for that too, but it doesn't quite work yet.  Planning on tinkering with it more tomorrow or Wednesday
<bryce> MacSlow: I also passed my drop-shadow-decoration patch upstream, but didn't get a response
<alvarezp> Please excuse me, I'm looking for guides on how to rebuild a package with newer versions of the source code. I already did apt-get source p, apt-get build-dep p, and wget new-source, but I don't know how to tell debuild to use the new version of the source code to build a new package.
<tjaalton> bryce: there were three replies to the post ;)
<tjaalton> bottom line was that it'll get fixed properly in 2.3
<bryce> tjaalton: hmm I only saw jesse's
<bryce> oh right
<bryce> tjaalton: well eric and zhenyu didn't really give feedback on the patch, just said they needed to "fix it properly in 2.3", but didn't give any indication what they meant by that
<bryce> so, I got a response, but not quite what I was hoping for...
<tjaalton> heh
<bryce> maybe eric just doesn't like me ;-)
<tjaalton> bryce: maybe he doesn't like the state of intel code atm ;)
<bryce> tjaalton: well he definitely doesn't seem to like it when I put up patches to work around the problems ;-)
<tjaalton> "I'm working on it, leave me alone" :)
<bryce> heh exactly
<bryce> but jesse is helpful - "for a work around, that looks good enough" :-)
<bryce> (aside from that it didn't actually work... but at least I know I'm not way off base)
<tjaalton> yep, I'll test it again once you have something
<bryce> cool
<bryce> I'm going to allocate tomorrow to focus on it
<bryce> I'm guessing that either my logic is screwy, or else it requires something in addition to greedy to be turned on.  I'll just slip in some debug statements and that should prove it one way or the other.
<lamont> slangasek: and then there's the current gconf (one of many with ldap issues):
<lamont> Function `ldap_get_values' implicitly converted to pointer at evoldap-backend.c:265
<lamont> Function `ldap_init' implicitly converted to pointer at evoldap-backend.c:579
<lamont> and gnome-mount
<slangasek> lamont: that's not the current gconf, I fixed that over 12 hours ago ;)
<lamont> heh
<lamont> that's autotest
 * slangasek nods
<tjaalton> does gconf now have a usable ldap backend?
<slangasek> lamont: cyrus-sasl2 still has the same problem, but those are the only two ldap incompatibilities left in main that I know of
<slangasek> oh, I guess autofs is in main too
<nxvl_work> if a bug has been fixed on upstream, how do i mark the bug? as fix commited?
<Fujitsu> nxvl_work: You mark the upstream task of the bug Fix Released.
<bryce> nxvl_work: generally I would use "Also affects project" to link to the upstream bug report with the fix
<nxvl_work> bryce: already done
<nxvl_work> Fujitsu: but the ubuntu one, stay as confirmed?
<Fujitsu> nxvl_work: Correct.
<Fujitsu> Some people set it to Fix Committed, but that's wrong.
<bryce> nxvl_work: in case it's not clear what the fix is, it can sometimes be useful to also attach the patch to the Ubuntu bug; this way if someone searches bugs with patches, it'll show up
<nxvl_work> the patch has been sended to upstream
<nxvl_work> and they included the fix
<nxvl_work> the upstream part of LP is marked as fix released
<nxvl_work> but i don't know how to mark the ubuntu part
<nxvl_work> since that bug must to be closed one or other way
<slangasek> Fujitsu: I wonder, why is 'fix committed' wrong? I'm not aware of anything saying /where/ the fix has to be committed to use that status
<Fujitsu> Leave it as it is. It will appear in the list of bugs fixed upstream but not in Ubuntu.
<Fujitsu> slangasek: It's not committed to anything Ubuntu-related, therefore it can't be right.
<slangasek> well, I think the definition of "Ubuntu-related" is fuzzy... if an Ubuntu package is maintained on alioth, is "fix committed" warranted?
<Fujitsu> One doesn't set a bug in Ubuntu as In Progress just because upstream is working on it.
<crimsun_> the protocol needs to be clarified/documented on the wiki, at least.
<mathiaz> nxvl_work: you're probably refering to bug 24777 - marking it as confirmed or triagged is the best option I think.
<ubotu> Launchpad bug 24777 in openssh "Apply openssh sftp-chroot patch to openssh-server" [Medium,Confirmed] https://launchpad.net/bugs/24777
<nxvl_work> mathiaz: yep, this one
<nxvl_work> mathiaz: ok, so i will mark it as confirmed as i can't use triaged
<mathiaz> nxvl_work: even if it's been committed to upstream openssh, it hasn't been included in ubuntu (yet).
<nxvl_work> mathiaz: and there are no plans to include it on this release, that's what i thought :D
<nxvl_work> mathiaz: thnx
<mathiaz> nxvl_work: well - considering that we're in FeatureFreeze I don't think it will be included in hardy.
<mathiaz> nxvl_work: but you can always to try to convince cjwatson_ to include it.
#ubuntu-devel 2008-02-19
<lifeless> so is pycentral horked or what ?
<crimsun_> quite.
<lifeless> anyone fixing it, or should I break out pdb?
<crimsun_> I started looking at it but was distracted by PulseAudio.  So, the latter.
<superm1> slangasek, when would be a good time to look over the changes to cdimage that I had proposed?  cjwatson had asked me to ask you to look into merging them in
<slangasek> superm1: mmm, today is archive duty day and tomorrow I'm off, so I guess Wednesday?
<superm1> slangasek, okay sounds good to me.
<superm1> slangasek, while you are archive duty'ing, you can nuke the first upload of libnet-upnp-perl to save yourself catching the error in it (there are two in NEW).  it was uploaded as arch any rather than all (the second one is fine)
<slangasek> superm1: thanks, kicking it out so I don't get confused later
<superm1> ok thanks
<crimsun_> johanbr: still having issues with bz headset and PA?
<johanbr> crimsun_: Yes, I'm afraid so. Even getting it to work without PA has been challenging.
<johanbr> Sadly, it seems like the bluez developers are not very interested in the issue. I've had more luck with headsetd than with the bluez audio service.
<cody-somerville> Is there any reason why thunar-svn-plugin hasn't been accepted yet? It did make it before the FF, right?
<_MMA_> Still sitting in the queue. https://launchpad.net/ubuntu/hardy/+queue Might take a bit to clear.
<_MMA_> And only been 4 days. (it looks like)
<Chipzz> slangasek: is that in the standard gconf? I just did a quick google for gconf ldap and only found references to some evolution specific stuff?
<slangasek> Chipzz: I didn't look too closely at how gconf was using ldap
<azeem> lifeless: ping
<lifeless> pong
<azeem> lifeless: so, people asked me to upload opensync-0.22 for hardy, as it's pretty clear 0.40 won't be ready in time
<lifeless> think 0.22 is an unambiguous improvement ? :)
<lifeless> if so then yeah, JFDI
<azeem> of course, there's still the issue that the plugin configuration and the database changed etc.,
<azeem> but what about a 1-line patch telling it to use ~/.opensync-0.22 rather?
<lifeless> yeah, I like that
<azeem> if time permits, I/somebody else could try to port the plugin configuration converter from 0.3x that dgollub committed last week
<azeem> (for 0.22->0.3x)
<azeem> now, should I upload that to Debian unstable first and get somebody to sync?
<azeem> opensync appears to be in main
<lifeless> yeah
<lifeless> upload and sync is easiest
<lifeless> I think hardy is frozen now anyhow
<azeem> only the lib
<azeem> right, it'd need an exception
<azeem> I have to admit that while evo2<->file works, I had no luck trying to sync my mobile via bluetooth or irda
<azeem> connection refused, something which at least works slightly better with 0.3x
<azeem> lifeless: do you remember why you changed the test suite (create_case->CREATE_CASE, which is a macro)
<azeem> because that got rejected during update
<johanbr> crimsun_: With the bluez audio service I can get simple things working, like playing a wav file. But ekiga segfaults and Twinkle fails to open the device.
<lifeless> azeem: blink, debian changelog
<azeem> lifeless: AFAICT it was in from the beginning, so "Intial upload" would be the entry...
<azeem> hrm, or not
<lifeless> I'm pretty sure someone gave me a patch for that; might be in the bzr changelog, one sec
<slangasek> isn't that codehelp's patch?
<azeem> oh indeed
<azeem> lifeless: oops, sorry
<Chipzz> slangasek: apparently it only does this for certain (evolution-specific) settings: http://svn.gnome.org/viewvc/gconf/trunk/backends/README.evoldap?revision=1966&view=markup
<slangasek> Chipzz: to be honest, I don't really care about the gconf backend at all, my only concern is that it not get misbuilt and become a source of bug reports :-)
<Chipzz> ok :)
<Chipzz> I actually was kind of interested ;)
<Chipzz> http://lists.debian.org/debian-project/2008/02/msg00048.html -> *sigh* :)
<lifeless> *yawn*
<Fujitsu> Wordpress! YAY!
<StevenK> Oh, that mail.
<Fujitsu> I wish they'd hurry up and remove it from the archives so that we can too...
<slangasek> haha
<TheMuso> lifeless, azeem I know for a fact I need to use 0.22 to sync with my mobile, so 0.22 would be welcome.
<slangasek> I know I need > 0.22, so I'd like > 0.22 please ;)
<TheMuso> slangasek: I can live without, I just build locally, but nevertheless.
<slangasek> TheMuso: what mobile?  I think we really ought to be moving opensync forward, and getting fixes for any plugins that aren't ported yet
<TheMuso> slangasek: Nokia 5700 Xpress Music.
<slangasek> TheMuso: which plugin does that use in 0.22?
<azeem> slangasek: problem is, 0.22 is sort of a dead end
<azeem> the few developers who hack on opensync concentrate on 0.3x
<lifeless> problem is, opensync has never had a stable release that they actually stand by
<azeem> yeah
<azeem> and I see mentionings of "let's get 0.40 out before I switch jobs and go MIA, maybe somebody else will pick up"
<lifeless> they've routinely broken disk compatibility and api compatibility, and while thats ok if you provide migration - they aren't.
<azeem> lifeless: there's now a migration tool from 0.22 to 0.3x
<azeem> they actually say it's a requirement this time
<slangasek> azeem: hmm?  I'm aware 0.22 is a dead end, this contributes to me wanting something newer...
<azeem> slangasek: ah, ok
<slangasek> since the plugin that supports my phone is 0.3x-only
<TheMuso> slangasek: Syncml.
<azeem> unfortunately, there's no nice GUI for 0.3x yet either
<azeem> 3-4 half-finished ones
<TheMuso> Probably expalins why opensync in Debian has stayed where it is for so long. :)
<slangasek> TheMuso: I think that's explained by "upstream keeps screwing around with build systems"
<TheMuso> heh right
<azeem> they're really happy with cmake now that they reimplemented pkg-config and libtool in it
<Chipzz> azeem: isn't pkg-config written in C? :)
<TheMuso> slangasek: What plugin do you need to use with your phone?
<slangasek> TheMuso: moto-sync, which has no working 0.22 version AFAIK
<TheMuso> No, I don't remember seeing that plugin for 0.22
<Amaranth> did the x86 retracer die?
<pwnguin> if i wanted to find which applications ubuntu packages that use Xinput, would "apt-cache showpkg libxi6" be appropriate?
<mjg59> pwnguin: rdepends
<azeem> how can I tell libtool to use libopensync.0d as soname?
<azeem> (after re-reading Debian #429798)
<ubotu> Debian bug 429798 in libopensync0 "opensync: please use library versioning" [Wishlist,Open] http://bugs.debian.org/429798
<StevenK> Dear tarfile, please become 200% faster. No love, Steve
<azeem> oh wait, nm
<chrisb_> is this the right place to be for help with building source?
<StevenK> lifeless: This isn't Linda, this is moblin-image-creator.
<lifeless> StevenK: ah; creating tars ?
<lifeless> StevenK: are you using python's gzip support ?
<StevenK> lifeless: It is using python's bz2 support.
<lifeless> are you setting a compression level ?
 * StevenK paws through the code
<StevenK> tar_file = tarfile.open(tar_filename, "w:bz2")
<StevenK> I doubt it.
<lifeless> write, thats your problem
<slangasek> TheMuso: well, moto-sync is a separate upstream, and I think the current, working version only builds against opensync 0.3x
<StevenK> lifeless: Hm? Don't write? :-)
<lifeless> try:
<lifeless> ah, I was going to suggest something like TarFile.bz2open(tar_filename, mode='w', compresslevel=5), but checking my docs bzip2 doesn't scale like gzip
<lifeless> python's GZipfile uses -9 by default, not -6 which gzip does; so pythons gzip wrappers are insanely slow by default
<lifeless> StevenK: run lsprof over it
<lifeless> StevenK: if you need glue code to do that and get a kcachegrind file look at bzrlib.lsprof
<lifeless> you can trivially get a cachegrind file from there :)
<StevenK> I don't think I care that much. :-)
<CarlFK> alt-installer, is a python stack dump an error, or is this allowable?  http://dpaste.com/35856/
<CarlFK> the installer aborted, but much later and I think for an unrelated problem
<superm1> that's a different bug
<superm1> someone broke python central today
<superm1> a lot of hardy is broke because of it
<lifeless> no lube on that upload
<CarlFK> superm1: so no need to file report - just wait ?
<superm1> CarlFK, there's an open bug already if you want to subscribe to it
<superm1> let me grab it
<lifeless> many open reports :)
<slangasek> hrm, that's the sort of bug that should be milestoned for the alpha that's due in, oh, 3 days
<superm1> but 192992
<CarlFK> this is what caused the installer to abort   http://dpaste.com/35857/
<superm1> bug 192992
<ubotu> Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [Medium,Confirmed] https://launchpad.net/bugs/192992
<CarlFK> thanks
<CarlFK> "This bug has            16 duplicates"
<CarlFK> I feel so behind :)
<superm1> i'm surprised its only 16
<CarlFK> but is it confirmed? :)
<ScottK2> superm1: Did you know you set the pycentral bug back to Medium at the same time slangasek set it to High?
 * ScottK2 thinks you might put it back.
<superm1> ScottK2, I didn't change it?
<superm1> i only changed the milestone
<slangasek> rather, you targetted it to a release
<superm1> well i did that by accident looking for the milestone, and then i changed the milestone :)
<slangasek> ah - so yes, I had done that just before you :)
<ScottK2> superm1: Activity log says different (it's a refresh issue).
<superm1> yeah suppose so
<ScottK2> Just thought I'd mention it so it'd end up set where it was wanted to be.
<TheMuso> Ouch. The latest live CD appears to still be using an old version of casper.
<TheMuso> Yeah, latest live CD has casper 1.115.
<TheMuso> And 1.118 is in the archive.
<TheMuso> Same with a lot of packages I think, including artwork.
<TheMuso> So much for my a11y testing this afternoon. :)
<cjwatson> TheMuso: check http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/
<cjwatson> TheMuso: this is usually because later livefs builds failed and somebody needs to focus on getting them back into shape
<StevenK> It may be related to the python-central breakage ...
<StevenK> I win, it is.
<ScottK2> I have a theory on the python-central breakage, but no good way to test it and I'm about to go to bed.  Anyone interested in hearing a shot in the dark?
<StevenK> ScottK2: No chroot you can upgrade?
<ScottK2> StevenK: I've got a machine, just it's almost 1am and I've got an early meeting.
<TheMuso> cjwatson: Ah right, it took me a bit to work that out, but looks like they are failing. Latest is from the 18th, for i386 at least. Ppc and ia64 have builds from the 19th.
<CarlFK> ScottK I have a box I czan test on
<ScottK2> StevenK: My shot in the dark is to revert the changes in python/sourcelist.cc in the last python-apt upload.  The pyversions.py file the python-central keeps dieing on is unchanged from the last to the current versions..
<CarlFK> er... I take that back.  I have a gutsy box...
<ScottK2> You could do it in a Hardy chroot.
<ScottK2> http://pastebin.com/m63ba51ca is the change that I'm guessing needs reverted.
<ScottK2> But it's just a guess.  Doing that may eat you children.
<ScottK2> Good night all.
<ionstorm> yea that bug is a bit annoying
<pitti> Good morning
<pitti> cjwatson: language-support split> that happened last Thursday
<ion_> Good evening.
<pitti> cjwatson: it's all done
<pitti> cjwatson, asac: BTW, I wonder whether I should continue to test the n-m 0.7 packages? will we get it for hardy, or shall I go back to dogfooding the 0.6 ones?
<dholbach> good morning
<ion_> Good evening
 * pitti hugs dholbach
 * dholbach hugs pitti back
<tseliot> good morning
<pitti> argh argh, seems that the new python-central is on a 'break postinsts' rampage
<superm1> yes, yes it is
<dholbach> on the master bug there seems to be at least a workaround - no idea if it's "the real fix"
<dholbach> bug 192992 comment 32
<ubotu> Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992
<pitti> apport bugpattern for bug above bug added
<pitti> no more dups from now on
<pitti> hm, current hardy's bzrtools is 1.0, which is incompatible with 1.1~rc1
<pitti> but when I sync from Debian, I get bzrtools 1.2
<pitti> because Debian already has bzr 1.2
<StevenK> Drag in both bzr{,tools} 1.2?
<pitti> slangasek: ^ Since bzr gets so exceptionally well self-tested, WDYT about syncing 1.2 for both?
<StevenK> Ah
<pitti> (a lot of people will want 1.2 anyway)
<slangasek> pitti: we probably ought to take 1.2 for hardy, yes
<pitti> ok, then I'll flush my syncs, thanks
<warp10> Hi all!
 * pitti hugs warp10, his favourite MOTU aspirant
 * warp10 hugs back pitti, his favourite mentor and UDW speaker :D
<seb128> mvo: is you or doko looking at bug #192992?
<ubotu> Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992
<mvo> seb128: possible, I don't know
<seb128> mvo: I asked you or doko, I'll take it as you are not ;-)
<seb128> where is doko? broke hardy and ran away? ;-)
<mvo> seb128: I can check it out now if he is not around
<seb128> mvo: there is already 30 duplicates so would be nice if somebody could look at it, upgrades are broken for everybody
<dholbach> bug 192992 comment 32 has a workaround (maybe even a solution) for it
<ubotu> Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992
<seb128> mvo: there is a comment pointing a preinst change, not sure if it's correct though
<dholbach> seb128: doko is at some OOo meeting
<seb128> ok, so we better don't wait on him to fix the issue
<pitti> seb128: I added an apport pattern for it now, BTW
<seb128> thanks
<mvo> seb128: looking at it now
 * seb128 hugs pitti
 * seb128 hugs mvo
<seb128> pitti: good idea, I almost forgot about bug patterns ;-)
<seb128> we don't use those often
<pitti> for cases like these they are really handy
<pitti> I recently sent an announcement about putting them in bzr
<pitti> so more people can use them
<seb128> right, I read this one
<seb128> Amaranth: stop reassigning all the compiz bugs to libwnck ;-)
<Amaranth> heh
<seb128> I'm pondering making a compiz sucks bug there and duplicating everything
<Amaranth> seb128: the one that i think i moved over a couple times is libwnck not paying attention to window extents
<Amaranth> then there are the usual "libwnck doesn't handle viewports correctly" bugs
<seb128> well, if they have the same cause and you know which one that would be nice to comment to say that and duplicate those
<Amaranth> right, i planned to go through them afterward, had like 50 compiz bugs open in tabs at the time
<seb128> ok, thanks
<Amaranth> that'll probably be a few hours though, gotta sleep soon :)
<Amaranth> but i'll take care of it, libwnck probably has a bunch of compiz-related dupes hanging around
<seb128> btw, the broken move to workspace n, are you sure it's due to libwnck?
<Amaranth> upsteam says yes
<seb128> bah
<Amaranth> I know one of the problems was not taking window decorations into account when figuring out how far to move
<Amaranth> the window extents i mentioned
<Amaranth> seb128: ooh, bug 184998 looks easy to fix
<ubotu> Launchpad bug 184998 in libwnck ""Move To Another Workspace:" moves to Desk 3 in Desk 2 when selectin Desk 1 in Compiz" [Unknown,Confirmed] https://launchpad.net/bugs/184998
<Amaranth> it seems to just move the wrong way, the reporting just happened to get lucky enough to have so little viewports it wrapped around
<Amaranth> probably a + needs to be a - somewhere, i'll look later
<seb128> Amaranth: thanks
<asac> pitti: looks like we will stay at 0.6 in hardy
<seb128> asac: :-(
<tjaalton> asac: so upstream doesn't have a release schedule yet?
<slytherin> Hi all. I am not sure if this the place to discuss this but is anyone working on getting latest bluez-gnome in Ubuntu? I think the recent releases also have file transfer support using obex-data-server and libopenobex-glib (none of them present in Ubuntu).
<asac> tjaalton: more or less yes.
<asac> otoh, NM 0.6.6 is planned for end of this month ;)
<tjaalton> bah, 0.7 has all the goodies ;)
<seb128> slytherin: obex-data-server is in NEW
<slytherin> seb128: Damn. I always forget to make sure before I ask
<seb128> slytherin: I think there is a sponsor request about the new bluez-gnome but the other one needs to be accepted first
<seb128> slytherin: dunno about libopenobex-glib
<slytherin> seb128: Thanks for info. I will try to explore what all is possible with obex-data-server.
<seb128> you are welcome
<pitti> asac: oh, then I better downgrade
<Mithrandir> seb128: I'll NEW obex-data-server, since I was the one who rejected it last time.
<mvo> seb128: I uploaded a fix that is hopefully correct
<pitti> asac: too many regressions?
<asac> pitti: too much uncertainty
<beb> y s tat
<beb> ur 4rm
<ssam> on https://launchpad.net/ubuntu/hardy/+source/linux/2.6.24-9.15 under builds it says 'failed to upload' what does that mean? will there be afix before the next alpha?
<geser> good morning
<asac> pitti: we don't know _when_ upstream will release ... and if we release a random snapshot we might end up with a code base in a LTS release that upstream has no clue about (e.g. sec patches might not apply et al)
<pitti> asac: ah, I see
<asac> pitti: we discussed that in -platform meeting and came to this conclusion
<beb> gud morning
<seb128> Mithrandir: thanks!
<pitti> I wasn't aware of the release status of 0.7
 * seb128 hugs mvo
<Mithrandir> seb128: accepted now.
<seb128> mvo: thanks for the quick fix
<Mithrandir> I should probably do a MIR for it
<seb128> Mithrandir: rock on ;-)
 * pitti hugs mvo
<seb128> that would be nice
<beb> wat would be nice
<slytherin> mvo: I have another question about python-apt if you are not too busy.
<beb> ya sure
<saispo> anyone from xorg team ?
<geser> ssam: something went wrong with the upload of the debs build by the buildd. the uploader should got a mail with the errror message, others can currently only guess about the reason.
<beb> i dont know
<mvo> slytherin: sure, fire
<mvo> slytherin: I may be a bit slow answering, but will do my best :)
<ssam> geser, thanks
<beb> y thanx
<seb128> saispo: #ubuntu-x
<slytherin> mvo: I see in the examples installed in package python-apt, apt_pkg.Architecture is used to retrieve architecture. But when I try to use it I get some error, something that sound like api is not present (probably removed). Is this a bug or problem in examples?
<saispo> seb128: thanks
<mvo> slytherin: that sounds like a bug, I wouldn't mind a bugreport. use "apt_pkg.Config.Find("APT::Architecture")
<slytherin> mvo: I had tried Config.Get instead of Config.Find. :-D
<slytherin> mvo: Ok, .Find works. I will log a bug for the examples
<mvo> slytherin: thanks
<cjwatson> pitti: ah, ok, thanks, I checked but must have missed it somehow
<pitti> cjwatson: well, the split of language-support-* into fonts/writing aids etc. is done; not the per-country split of language-pack-zh
<cjwatson> right, that I knew
<cjwatson> I think I just misread apt-cache show (since it also showed my installed package)
<ogra> mvo, what would you think about a note that is displayed if users run apt-get dist-upgrade, pointing them to update-manager(-core) ? i guess we'd avoid a lot of breakage with a tiny change
<ogra> like: "if you want to use this command to upgrade to a new distribution release, please rather use update-manager"
<Keybuk> pitti: I have *THE BEST* apport bug
<pitti> Keybuk: apport crash on apport crash on apport crash?
<Keybuk> no, even better
<ion_> ogra: It probably should also mention do-release-upgrade (itâs the same thing with a text UI, isnât it?)
<ogra> ion_, i thought that was -core
<ion_> ogra: Ah, right :-)
<Keybuk> pitti: http://people.ubuntu.com/~scott/apport-doh.png
<ogra> in any case we shouold give users being used to dist-upgrade a hint imho
<mvo> lol
<mvo> ogra: yeah, I think that makes sense
<ion_> keybuk: :-D
<mvo> ogra: something more clever would be even better that can see if a actual release upgrade is performed or "just" some random upgrading
<ogra> Keybuk, are you sure we're not violating a M$ patent here ?
<pitti> Keybuk: "upgrade to a known-broken version! now!" :)
<Keybuk> pitti: that's exactly what failed ;)
<ogra> mvo, that would be the second iteration :)
<Keybuk> the report is the failure to upgrade python-central
<Keybuk> which it can't file, because I need to upgrade python-central
<Keybuk> but I can't upgrade python-central, because it fails
<Keybuk> generating a problem report which I can't file, because I nee*BOOM*
<pitti> Keybuk: interesting self-referential case :) I think we shuold disable that check if ProblemType == Package and Package == obsolete Package
<Keybuk> and I got a problem report because I ^\'d an app
<Keybuk> but I think I'll ignore that ;)
<Keybuk> awn crashed with SIGQUIT
<pitti> what was it again, SIGSTOP or SIGQUIT?
<pitti> ah
<pitti> worth a bug report, though
<Keybuk> a but that apport reports it?
<pitti> yes
<Keybuk> it's a valid report for most things I would have said
<Keybuk> *shrug*
<Keybuk> did you know, btw, that apport is actually an English word? :)
<pitti> it's actually supposed to ignore SIGQUIT
<pitti> Keybuk: yes, it's a German word, too
<pitti> "apportieren" -> a dog fetches somethign you throw
<cjwatson> it's a property of pets in nethack ;-)
<Keybuk> heh
<cjwatson> (meaning pretty much exactly that)
<pitti> that's why I chose it as a name, it fitted well
<Keybuk> in English, it means "to transfer something by mysterious means"
 * Fujitsu finds apport mysterious enough.
<pitti> sounds about right :)
<Keybuk> heh
<pitti> Keybuk: so, anyway, I expliticly have "if signum == str(signal.SIGQUIT): sys.exit(0)" and even test cases for it
<Keybuk> good name :-)
<Keybuk> pitti: hmm, maybe I did something very strange that confused it
<Keybuk> I'm good at that
<pitti> Keybuk: that's why I wonder why you still got a report; can you mail me your /var/log/apport.log?
<tjaalton> asac: is there a bug against FF that if I have both GNOME & KDE installed, FF uses external applications randomly choosing either a KDE or GNOME equivalent depending on the phase of the moon :)
<tjaalton> strike the moon stuff, it wouldn't be random then ;)
<Keybuk> pitti: sure, it's my home machine
<asac> tjaalton: not that i know of
<pitti> Keybuk: toghether with an explanation which application you ^\ed
<tjaalton> asac: it can offer file-roller five times in a row, then the same for ark ..
<Keybuk> it was avant
<Keybuk> it was annoying me
<tjaalton> asac: when trying the same archive, for instance
<pitti> Keybuk: just tried it here, I don't get a report for ^\
<Keybuk> pitti: I'm wondering whether it didn't respond fast enough, and I did something else :p
<asac> tjaalton: if you have a minute, please file a bug about this
<tjaalton> asac: sure
<asac> thanks
<Keybuk> pitti: in fact, arguably any upgrade failure should be filed whether or not there are obsolete packages?
<pitti> Keybuk: true that
<Keybuk> . o O { if only Launchpad tracked versions }
<pitti> oh
<pitti> Keybuk: in fact the obsolescence check already applies *only* to ProblemType: Crash
<pitti> Keybuk: apparently your report wasn't a package install/upgrade one, but a crash report
<Keybuk> so python-central crashed while it was upgrading itself?
<pitti> right
<Keybuk> does python-central's postinst run python-central?
<pitti> spethial
<pitti> and I don't generally want to disable the obsolescence check, since we very deliberatly introduced it
<pitti> Keybuk: yes, so it seems
<pitti> if /var/lib/pycentral/delayed-pkgs exists
<mvo> Keybuk: I uploaded a fix for the python-central issue some minutes ago
<pitti> ArneGoetje: hm; I was just told that openoffice.org-hyphenation is the *old* way of doing things, and that it was split into several sources for easier maintenance; so we shuold migrate the language-support packs away from it
<soren> The locale generation bug yesterday doesn't happen if I give the virtual machine a GB of RAM.
<siti> yeah that bug is weird
<siti> it has killed my machine before :(
<ogra> mvo, that didnt fix it completely it seems
<ogra> mvo, http://paste.ubuntu-nl.org/56598/
<ogra> (i just grabbed your upload from LP)
<stgraber> confirmed ^^
<mvo> ogra: thanks! doko took care of it and uploaded a new (better) fix
<geser> pitti: please give-back: libept. I got hit by graphviz being uninstallable. Thanks
<mvo> ogra: could you please grab that latest version https://edge.launchpad.net/ubuntu/+source/python-central/0.5.50ubuntu3 and check if that helps?
<pitti> geser: done
<doko> ogra: you need to rebuild with this version
<geser> pitti: please also give-back: xen-3.2. Got also hit by graphviz. Thanks.
<ogra> doko, you mean i need to rebuild python-apt ??
<doko> ogra: yes
<ogra> oh
<ogra> ok
<dholbach> doko, mvo, ogra: just installing the new python-central (ubuntu3) made installation work for me
<ogra> dholbach, well, stgraber sees it as well
<dholbach> ogra: ubuntu3?
<ogra> the first error was gone for me after ubuntu3
<dholbach> hm, weird
<ogra> but introduced the byte_compile error
<doko> dholbach: yes, for python-apt it does work
<ogra> err
<ogra> ubuntu2
<mvo> ogra: could you please check ubuntu3? if that is ok we are good, otherwise we need to look at it again
<ogra> well, that takes some more effort ... let me see to get python-central ubuntu3 into my pbuilder somehow
<mvo> ogra: pbuilder login --save-after-login and install it there
<ogra> yeah
<ogra> thats what i'm doing :)
<doko> ogra: rebuilt package: http://people.ubuntu.com/~doko/tmp/python-apt_0.7.4ubuntu5_i386.deb
<ogra> oh, wow, thats even better :D
<pitti> geser: done
<ogra> doko, mvo, http://paste.ubuntu-nl.org/56603/
<ogra> :/
<doko> ogra: http://people.ubuntu.com/~doko/tmp/python-central_0.5.50ubuntu3_all.deb
<ogra> ogra@ceron:~/Desktop$ dpkg -l python-central|grep ii
<ogra> ii  python-central                             0.5.50ubuntu3                       register and build utility for Python packages
<ogra> ogra@ceron:~/Desktop$
<ogra> but i'll try your package
<ogra> same thing
<ogra>   File "/usr/bin/pycentral", line 624, in byte_compile
<ogra>     rt.byte_compile(files, bc_option, exclude_regex)
<ogra> AttributeError: 'NoneType' object has no attribute 'byte_compile'
<doko> ogra: please could you try to remove the package first?
 * ogra tries
<ion_> I also get that error.
<ogra> urgh
<ogra> thats a lot of deps
<mvo> python-apt? yeah :-D
<ion_> python-central
<ogra> both
 * pitti claims the trophy for the first LZMA-enabled upload
<ogra> hrm
<pitti> ia32-libs shrinks to less than 50% (!)
 * mvo hands pitti a gold star
<ion_> The crowd cheers.
<ogra> meh -central removes nearly everything
<doko> ogra: sorry, can't reproduce here, neither with an update from the broken, nor from the old version
<ogra> especially xchat ...
<ion_> doko: Still the same error after purging and reinstalling python-central.
<doko> ion_: python-apt, not python-central
 * ogra ctrl-C's quickly
<ogra> doko, same error
 * ogra reinstalls ubuntu-desktop
<ogra> hrm ...
<stgraber> I dpkg --purged python-central and reinstalled, doesn't seem to help
<stgraber> (assuming that dpkg --purge + dpkg -i does the same as using the aptitude way)
<ogra> it should
<mvo> ogra: is that some special environment (pbuilder) or do you see it on your regular system?
<ogra> thats my regular system
<ogra> i fear to log out now ... half of my desktop is gone and not installable anymore
<mvo> ogra: could you please check the last lines in /var/log/pycentral.log ?
<mvo> ogra: there should be something like "bc for v%s (%d files)" in it
<ogra> empty
<mvo> ohh
<stgraber> doesn't seem to work when reinstalling python-apt (except that now I don't have python-apt installed and all the packages depending on it are now broken ...)
<ion_> ogra: I just forced the purge without removing the dependees since hey, the very next thing iâd do was to install the package back.
<ogra> ion_, the deps are still broken
<mvo> ogra: could you please try setting PYCENTRAL=debug and running the command again?
<mvo> ogra: you need to be on "sudo -s" first, otherwise sudo eats the environemt
<mvo> (^--- or stgraber or ion_)
<ogra> still empty
<mvo> PYCENTRAL=debug apt-get install python-apt
<mvo> and nothing printed on the terminal?
<ogra> ah, now its better :)
 * soren likes the old python-central much better :)
<ogra> http://paste.ubuntu-nl.org/56608/+
<ogra> err
<soren> ogra: Oh, oh, what did you do?
<ogra> s/\+//
<ogra> soren, wasnt me
<mvo> ogra: out of curiosity, does it go away if you install python2.4?
 * ogra whistles innocently
<soren> ogra: No, but you said it was better. I thought you fixed it :(
<soren> I have python2.4 installed and I'm seeing the same thing.
<mvo> soren: better == more output (more output is always better :)
<ogra> mvo, snap, thats it
<stgraber> http://pastebin.ubuntu.com/4752/
<stgraber> hmm, ogra was faster :)
<mvo> stgraber: do you have python2.4 installed? does it help if you install it?
<mvo> soren: oh? you get this with python-central 0.5.50ubuntu3 and python2.4 installed? the same error?
<ogra> for me 2.4 fixed everything it seems
<mvo> doko: is this fallout of the incorrect settings in the preinst or is this a different problem (i.e. will this go away after the packages got rebuild against the latest python-central)?
<stgraber> I don't, let me install it
<soren> mvo: I can't really install 0.5.5ubuntu3, apparantly.
<mvo> ogra: still a bug, but we now know what the problem is
<ogra> yeah
<soren> mvo: Er.. hang on.
 * mvo really needs to go for lunch now
<soren> mvo: Sorry, I'm an idiot.
 * soren tries again.
 * mvo hugs soren
<stgraber> here I seem to get the crash when installing python2.4 now ...
 * pitti wonders how he can damage an ext3 file system in a way that fsck -a fails
 * dholbach hugs soren
<stgraber> (though python-apt and update-manager installed correctly :))
<mvo> dd if=/dev/random of=/dev/pittis_hdd
<soren> Er.. Yes, I *do* get the same error.
<soren> ii  python-central                   0.5.50ubuntu3                    register and build utility for Python packages
<soren> ii  python2.4                        2.4.4-7ubuntu1                   An interactive high-level object-oriented language (version 2.4)
<pitti> mvo: well, that won't even remotely look like an ext3 partition any more :)
<mvo> soren: same debug output as well?
<soren> mvo: You mean lines the start with "pycentral:"?
<mvo> pitti: use skip and count to just make it broken on random bits :)
<mvo> soren: yes
<pitti> mvo: ah, will try taht
<soren> mvo: No, all it says is: pycentral: pycentral pkgremove duplicity
<soren> mvo: ...which is probably the first package in pycentral's queue.
<ogra> hmm
<ogra> my system beahves weird now
<ogra> now pitti's jockey upload breaks on pycentral
<ogra> same erros
<ogra> err
<ogra> error
<pitti> ogra: my bzrtools sync as well (FTBFS)
<pitti> I'm collecting the logs for a later give-back
<stgraber> I somehow managed to install python2.4 and I now get the crash when removing it :)
<soren> mvo: The stacktrace is the same, though.
<ogra> pitti, no, its pycentral thats broken
<mvo> I need to go for lunch now, sorry. but when I'm back we can debug this further, looks likethere may be more issues hiding here :/
<pitti> ogra: ah, you mean it built, but it doesn't install?
<ogra> pitti, yeah
<stgraber> http://pastebin.ubuntu.com/4753/ <--- When removing python2.4-minimal
<pitti> right, it built successfully
<emgent> heya people :)
<ogra> stgraber, looks like "buffer" is empty
<soren> I don't get it.
<soren> It reads through the preinst..
<soren> and only if it says '[python-package]' on a line by itself, it sets the buffer to something other than None.
<soren> Why would preinst have a line like that?
<soren> I'm having trouble seeing how this *wouldn't* fail ?
<ogra> created by some dh_python helper ?
<soren> Well..
<soren> How can "[python-package]" on a line by itself be valid in a general preinst?
<ogra> ogra@ceron:~/Desktop$ grep python-package /var/lib/dpkg/info/*.preinst|wc -l
<ogra> 6
<ogra> hmm
<ogra> only 6 packages
<soren> Sure, if the interpreter was set to pycentral or something.
<soren> ..but then you couldn't put general stuff into the preinst.
<soren> ..and possibly require a pre-depends on pycentral (not sure about that, though)
<ArneGoetje> pitti: hum... then where are the new sources?
<pitti> ArneGoetje: e. g. hyphen is the new one (the one we removed recently)
<pitti> I haven't checked in detail for other languages
<soren> Ah... inside a heredoc.
<ogra> cjwatson, i'll take myself out of bin/daily-checks for now (since it only sends the same as the report has)
<ArneGoetje> pitti: uah... sometimes it's oo.o-dictionaries, somtimes myspell and sometimes ispell besides hyphen... :( that's a mess
<ogra> cjwatson, also what do we do about the DVD ?
<soren> Well, I'm no python-central expert, but it seems that a "if not buffer: return None" in read_preinst_pkgconfig would be useful..
<soren> Right after iterating through the preinst.
<soren> The current implementation seems to assume that any package that has a preinst must have pycentral magic in there.
<soren> doko: Opinion?
<cjwatson> ogra: daily-checks> sure
<cjwatson> ogra: Edubuntu DVD doesn't seem to make a whole lot of sense any more?
<ogra> not sure
<cjwatson> ogra: I'm not sure, I know we need to at least sort out DVD seeds
<ogra> i suspect it will take some effort to get it in shape size wise
<cjwatson> I didn't try to do it at the same time as everything else since it was complex enough already
<ogra> i'll talk to RichEd about the expectations from his side about DVD
<soren> Yay, working python-central.
<ogra> soren, what did you break to make it work ?
<ogra> :)
<soren> ogra: I added the fix I suggested 6 minutes ago
<soren> 12:16:47 < soren> Well, I'm no python-central expert, but it seems that a "if not buffer: return None" in read_preinst_pkgconfig would be useful..
<soren> I could upload it, but I'm scared :(
<soren> I'd like to head doko say "good idea" or something before I become TIL for pycentral and it breaks the world.
<soren> *hear* doko say..
<pitti> Keybuk: I uploaded a new sysvinit for usplash fsck magic for checkroot.sh FYI
 * soren hugs pitti 
<Keybuk> pitti: ok
<Keybuk> pitti: the root is fixed?
<soren> mvo: ping
<pitti> Keybuk: I confine it to ext2 and ext3 (other fs'es don't benefit from it anyway)
<pitti> Keybuk: I tried for two hours to track down why reiserfsck kills your partition when being called in the background, without success
<pitti> Keybuk: but since I only tested it with 4 file systems, and only ext3 actually matters wrt. clean fsck, I think this is acceptable
<mvo> soren: I'm checking your fix out currently
<StevenK> pitti: Being backgrounded is something that happens to other processes?
<YokoZar> Where can I find a good PPA howto?  I've spent a bit too long on google and wiki search looking for something that should probably be in an obvious place on launchpad...
<mvo> soren: I think it is a good idea
<soren> mvo: I'll prepare an upload an wait for your "Ok, go!".
<pitti> StevenK: I don't understand what you mean?
<StevenK> pitti: Heh, sorry, I'm trying to be funny. Being backgrounded is something that only happens to other processes, not reiserfsck?
<mvo> soren: I have a upload ready here based on your suggestion
<pitti> StevenK: apparently :)
<pitti> StevenK: well, if I & it on a shell, it even works fine
<soren> mvo: Oh, even better! It keeps my name off of it! :)
<mvo> soren: with "if buffer is None: return []"
<mvo> soren: but otherwise idential :)
<StevenK> pitti: It needs a tty, then?
<pitti> but if usplash is active (and thus I can't see what it's doing), it totally wrecks the partition
<soren> mvo: Oh, ok. I just wanted to act exactly as though there was no preinst at all.
<soren> mvo: ..but I haven't a clue :)
<mvo> soren: right, that sounds sensible
<mvo> soren: this dosn't fix the "apt-get install python-apt" with no python2.4-minimal crash, I look into that one now
<pitti> and this is just an reiserfs -a /dev/bla &
<pitti> on a readonly fs
<pitti> reiserfsck, I mean
<pitti> so I better leave its evilness alone, I figure
<soren> mvo: I've taken a quick peek at the rest of the code and it seems to be the only bug of its kind. (there's nothing similar for {pre,post}{inst,rm})
<mvo> great, thanks soren
<doko> soren, mvo: ok, the fix for the preinst without having the config looks fine
<soren> soren.debug_fu++
<mvo> doko: if you don't beat me to it, I upload this change in a few minutes
<doko> I can't see the failure "apt-get install python-apt" with no python2.4-minimal crash
<doko> mvo: please go ahead
<pitti> StevenK: </dev/null works fine, >/dev/null, too
<pitti> StevenK: as I said, I haven't been able to reproduce it with usplash being disabled
<mvo> doko: it looks like this: http://paste.ubuntu.com/4754/ - I can reproduce it here. I think I will just add checks that ensure that rt.byte_compile is not called if the runtime is not available
<StevenK> pitti: That's wierd as hell.
<tjaalton> umm, why isn't mdadm included on amd64 ubuntu-standard?
<tjaalton> the changelog says it was removed from all, but at least feisty standard-i386 has it
<pitti> StevenK: exactly my thoughts
<tjaalton> whoops, sorry
<tjaalton> I was looking at a dapper box
<mvo> ogra, stgraber, doko: new version uploaded that works for me (tm) - please test ubuntu4 and let me kow if that fixes the issues for you too
 * soren hugs mvo
<soren> "  * do not crash if the"  ?
<soren> https://edge.launchpad.net/ubuntu/hardy/+source/python-central/0.5.50ubuntu4
<pitti> soren: ...editor saves a file? :)
 * soren chuckles
 * mvo coughs
<ion_> iRon: I want my R back.
<iRon> :)
<iRon> ion_: no problem
<etretyak> ion_: take your R ;)
<\sh> Riddell: grmpf..
<\sh> question to our release team in general: is it feasable to re-upload a NEW package which was rejected, because of a silly mistake by me inside the license file, without prior approval? :)
<pitti> \sh: sure; NEW uploads don't generally require prior approval
<Riddell> \sh: yes that's fine
<\sh> pitti: and it's likely that the package will be processed for include into hardy still? I thought new packages only until FF sday
<frafu> doko: Could you please tell me whether it is the fact that mousetweaks installs a daemon that makes you hesitate? https://bugs.edge.launchpad.net/ubuntu/+source/mousetweaks/+bug/190208
<ubotu> Launchpad bug 190208 in mousetweaks "Main Inclusion Report for mousetweaks" [Undecided,Incomplete]
<Riddell> pitti: motu says they do
<Riddell> \sh: today is my archive day, of course it'll be processed!
<pitti> :)
<\sh> Riddell: ok, you are fine that I bugfix this mistake and reupload? :) I mean it was already approved actually :)
<Q-FUNK> howdy!  could anybody tell me where are the latest how-to for building a customized ubuntu CD, as applying to gutsy?
<Riddell> \sh: of course
<\sh> Riddell: cool..thx :)
<pitti> Riddell: great goals; I spent hours and hours on NEW on Friday already
<Riddell> Target: New queue zero!
<Riddell> only 49 to go
<\sh> Riddell: hmm...if I say that it is licensed as GPL (version 1 or greater) or artistic (same lic as perl) then it's ok for you to include GPL-2 instead of GPL-3 right? :)
<pitti> Riddell: hm, following that spirit I should continue the MIR crunch :)
<Riddell> \sh: so long as upstream really is that
<\sh> Riddell: upstream is same licences as perl...which means GPL 1 or greater or artistic
<\sh> Riddell: upstream itself doesn't provide a license file in general and I'm using the infos on cpan for it
<danimo> \sh: any updates on the wine crash?
<\sh> danimo: nope...I have a report, that it works magically after the last dist-upgrade...I'll check just now
<\sh> danimo: but I'm not sure if this has something to do with the crash in general..0.9.54 works still, but 0.9.55 doesn't and my debugging didn't give me any clue what is going wrong
<Riddell> \sh: you should point to that in debian/copyright then
<\sh> Riddell: ok
<Riddell> \sh: and include a GPL, perferably version 1
 * Riddell tsks at slangasek for leaving backports in New
<\sh> Riddell: I'm just searching for it :)
<Riddell> \sh: apt-get source perl
<Riddell> Copying
<\sh> Riddell: reuploading the same version or should I inc the rev no?
<Riddell> \sh: doesn't matter
<soren> cjwatson: Ok, so I can totally reproduce the alternate installer failing if I only have 128MB... What to report that against? There's a kernel bug involved somewhere, so maybe that's a good starting point?
<\sh> Riddell: re-uploaded libfile-flock-perl and libdaemon-generic-perl
<\sh> pitti: thx for adding the other libs to ia32 :)
<pitti> \sh: feedback appreciated if it actually works now
<\sh> pitti: well, the crash comes from something else..I think
<\sh> pitti: I really wonder if it's the preloader thing with its strange memory mapping or something like that
<danimo> \sh: unfortunate,  I kinda need wine for online banking
<\sh> danimo: well, I need it too for my tax application ;)
<danimo> hehe
<erudified> Hey, congrats on all your hard work - Hardy is looking awesome!
<frafu> doko: ping
<stgraber> mvo: http://paste.ubuntu.com/4756/ <-- I get this one with pycentral -ubuntu4
<stgraber> that's when installing jockey-gtk
<pitti> frafu: I'll have another look at MIR later in the afternoon
<frafu> pitti: thanks
<mvo> stgraber: woah, this is still another one
<stgraber> yes
<mvo> stgraber: thanks, I can reproduce it too
 * ogra_ got the same here
<CarlFK> bug #192992
<ubotu> Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992
<mvo> stgraber, ogra_: thanks, have it and have a fix
 * mvo uploads another python-central and hopes for the best
<ogra_> heh
<cjwatson> soren: I'm not sure. Kernel might be worth a start
<soren> cjwatson: Mkay. I was hoping to not depend on that. The bug list for the kernel is not very encouraging :/
<soren> pitti: Have you managed to access the magic sysrq thing on your d430?
<cjwatson> soren: I know, I'm just conscious that chances are there's not going to be a whole lot we can do from the installer end
<cjwatson> short of not running localedef, which doesn't sound like a great option either
<soren> :)
<soren> cjwatson: Well, sure, and there's no doubt there's a kernel bug involved somewhere. I just hoped you had some magic trick up your sleeve that could narrow it down a bit. :)
<cjwatson> soren: hang on - exactly when did you say it was failing?
<cjwatson> what installer step?
<soren> cjwatson: When it's running localedef (during finish-install)
<cjwatson> soren: yeah, the weird bit is that localedef is run from post-base-installer, way earlier than finish-install
<cjwatson> soren: a process tree might help ...
<soren> cjwatson: Er.. ok?
<cjwatson> post-base-installer:    log-output -t localechooser chroot /target /usr/sbin/locale-gen "$LOCALE" || true
<soren> cjwatson: Ah, localedef is put into the background, I guess?
<cjwatson> post-base-installer:    log-output -t localechooser chroot /target /usr/sbin/locale-gen $EXTRAS || true
<cjwatson> no
<soren> but..
<soren> um..
<soren> Okay.
<soren> O_o
<soren> Well, the way it looks from the UI is that it gets stuck when it says "Storing language".
<soren> When I switch to vt2 I can see localedef running at full steam.
<soren> strace and ltrace are both silent, it's in R state and can't be kill -9'ed.
<cjwatson> like I say, a process tree might help establish what's going on
<soren> Attaching gdb to it gave me no love at all.
<soren> cjwatson: True.
<soren> Nevertheless, process in R state, that can't be killed => kernel bug, but let's see if we can narrow it down a bit.
<cjwatson> localechooser's finish-install ought not to be doing much at all
<cjwatson> I think it is probably actually the post-base-installer script that's running, in which case there is no confusion
<soren> cjwatson: It's the finish-install script that says "storing language", though, isn't it? Or why do I think it is?
<cjwatson> well, the template is finish-install/blah
<cjwatson> but actually base-installer uses that template as a fallback too
<cjwatson> to save duplicating it
<soren> Ahah..
<soren> busybox has not pstree, afair. Oh, well, I'll whip something up based on /proc.
<cjwatson> I don't think it's needed
<cjwatson> this is pretty clearly p-b-i AFAICS
<cjwatson> <meeting>
<mok0> lamont: ping
<lamont> yes?
<mok0> lamont: can you tell me what cpp predefines exist on hppa?
<lamont> __hppa__ iirc
<mok0> lamont: I am guessing __hppa
<mok0> lamont: ah, ok
<lamont> __${arch}__ is pretty much always there
<mok0> lamont: great, thanks, thats all :-)
<MacSlow> hm... I'm just updating and get tons of error-messages about python- and apt-packages not correctly installing... trying to generate bug-reports fails too
<CarlFK> bug #192992
<MacSlow> anybody got a clue what I just ran into there?
<ubotu> Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992
<mvo> MacSlow: its a known issue
<mvo> python-central had a bad day today
<MacSlow> mvo, do I have to feel guilty not knowing this?
<mvo> no :)
<MacSlow> *phew*
<ogra_cmpc> s/python-central/mvo/ ?
<mvo> ogra_cmpc: *pfff* I'm fixing it
 * ogra_cmpc hugs mvo
 * seb128 hugs mvo
 * MacSlow has "fun" fixing wncklet's tooltips
<mok0> lamont: the hppa platform in the buildd is running Linux, yes?
<Keybuk> asac_: so, err
<Keybuk> firefox 3.0
<Keybuk> where's the Home button?
<lamont> mok0: yes.
<azeem> Keybuk: it's the MyFacebook button now
<mok0> lamont: ... and big endian?
<pitti> soren: hm, if you ask me like that, no
<lamont> of course
<lamont> hppa/linux is always BE
<stgraber> Keybuk: have a look at the bookmark toolbar :)
<Keybuk> I don't have a bookmark toolbar?
<ogra_cmpc> Keybuk, ++
<stgraber> you have to enable it, then move it back to the main one :)
<Keybuk> that's a bit silly
<ogra_cmpc> the most useless waste of screen space ever
<Keybuk> why did they take away the Home button by default?
<stgraber> I wondered the same
<azeem> I didn't notice I don't have a Home button with Epiphany for years now
<Keybuk> epiphany has a Home button
<Pici> Probably because they wanted to put it near the Smart Bookmarks and Places folder buttons
<Keybuk> when it's not busy crashing
<azeem> Keybuk: maybe I removed it then :)
<asac> Keybuk: its on the bookmarks toolbar ... but upstream is working on improving this: bug 192505 + mozilla bug 417152
<ubotu> Launchpad bug 192505 in firefox-3.0 "Where's my home button?" [Undecided,Confirmed] https://launchpad.net/bugs/192505
<ubotu> Mozilla bug 417152 in Toolbars "move the Home button only if the bookmarks bar is visible" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=417152
<Keybuk> the bookmarks bar is invisible by default?
<Mithrandir> no
<asac> Keybuk: no its visible, but some users disable it
<ogra_cmpc> no, its visible
<stgraber> I don't think so but I didn't reset my FF profile for a long time
<Keybuk> it's invisible for me
<Keybuk> and I only installed firefox-3.0 a few hours ago
<ogra_cmpc> i disable it as first thing usually
<stgraber> it probably took your settings from your FF2
<asac> Keybuk: maybe an old profile setting?
<Keybuk> asac: laptop was fresh installed with hardy
<Keybuk> and I use epiphany normally
<Keybuk> so if I have a firefox profile, it's an empty one from when firefox has been started by mistake by some application that has it hard-coded
<stgraber> well, that probably created a FF2 profile then which was taken by FF3 at first start ...
<cjwatson> Mithrandir: could you visit https://launchpad.net/casper/trunk/+source and set the Bazaar branch for the series to ~ubuntu-core-dev/casper/trunk, please?
<ogra_cmpc> but the default ff2 profile has the bookmarks toolbar enabled as well
<asac> Keybuk: hmm ... just tried with a fresh profile: bookmarks toolbar is visible here. do you do backups of your home? we could look at the profile then?
<Keybuk> no
<Mithrandir> cjwatson: done
<cjwatson> ta
<superm1> Riddell, the author of libnet-upnp-perl lists the terms of his license in the README
<superm1> he just doesn't explicitly have a "COPYING" file that he put them in
<Riddell> superm1: doh, so he does
<Riddell> superm1: ok accepted, sorry about that
<superm1> Riddell, okay thanks.  Well it's good I was still around when you rejected it :)
<ogra_> oh
<ogra_> now i know why my addon seems so full ... its full of windows software
<rhpot1991_laptop> can an archive admin look at something that failed to build for me: https://edge.launchpad.net/ubuntu/+source/atomicparsley/0.9.0-0ubuntu1
<rhpot1991_laptop> has some errors about section unknown, but the section should be misc on the latest version
<stgraber> ogra_: how ?
<ogra_> stgraber, well, the winfoss stuff is on it
<ogra_> openoffice, inkscape, celestia, firefox and tuxpaint
<stgraber> right, openoffice taking a lot of space I guess :)
<ogra_> yeah
<ogra_> hmm, i wonder what icon to take for edubuntu-desktop in the addon metadata ...
<stgraber> ogra_: Can't you simply take the standard edubuntu logo ?
<ogra_> hmm
<Keybuk> thought of the day
<Keybuk> we should inhibit reboot/shutdown/logout/gdm etc. when dpkg is running
<slytherin> Hi all. I have packaged latest bluez-gnome and will upload a .diff.gz soon. Just let me know if we should disable the 'Browse Device ...' menu in the applet as gnome-vfs-obexftp doesn't work as of now.
<jdong> Keybuk: interesting... though what would be the use case?
<Keybuk> the person who signs our pay cheques rebooted her laptop while the kernel was being upgraded, and then it wouldn't boot because the initramfs was truncated
<Robot101> true indeed
<pitti> Keybuk: oops
<pitti> Keybuk: I hope she had at least one older kernel still?
<\sh> pitti: lib23ncurses5 should install a /usr/lib32/libncurses.so.* lib, right? but according to packages.u.c it doesn't ship with it, but lib32ncurses5-dev comes with /usr/lib32/libncurses.{a,so}
<pitti> \sh: hm, it should at first sight, yes
<Keybuk> pitti: happily so, I booted it with /bin/bash and dpkg --configure -a
<mjg59> \sh: The .a and .so should be in -dev. The .so.foo should be in the main package.
<Keybuk> but it shouldn't be *that* easy to shoot yourself in the foot
<Keybuk> you should have to be trying to
<\sh> mjg59: yes, the .a and .so are in the -dev package, but the .so.major.minor are not in the main package
<pitti> asac: is the 'firefox' (2.0) build dependency of firefox-themes-ubuntu on your radar?
<pitti> asac: it's the only thing that keeps firefox in main still
<rhpot1991_laptop> any archive admins around to look at something?
<pitti> rhpot1991_laptop: you need to be a little more specific :)
<rhpot1991_laptop> pitti: https://edge.launchpad.net/ubuntu/hardy/+source/atomicparsley/0.9.0-0ubuntu1
<rhpot1991_laptop> failted to build
<slytherin> Hi all. I have packaged latest bluez-gnome and will upload a .diff.gz soon. Just let me know if I should add patch to disable the 'Browse Device ...' menu in the applet as gnome-vfs-obexftp doesn't work as of now.
<rhpot1991_laptop> actually this is a link with the build info: https://edge.launchpad.net/ubuntu/+source/atomicparsley/0.9.0-0ubuntu1
<\sh> pitti, mjg59 : http://launchpadlibrarian.net/10730655/buildlog_ubuntu-hardy-amd64.ncurses_5.6%2B20071124-1ubuntu1_FULLYBUILT.txt.gz the 32bit package for amd64 doesn't ship with a libncurses.so.* lib...
<pitti> rhpot1991_laptop: you should ahve gotten an upload rejection mail
<pitti> rhpot1991_laptop: it's built, but failed to upload for some reason
<rhpot1991_laptop> I did
<pitti> rhpot1991_laptop: and the reason should be explained in the mail
<asac> pitti: firefox 2 currently has no binaries in main ... all have been replaced by firefox (>=3). anyway, it just became a prominent object on my radar ;)
<rhpot1991_laptop> 13:10:31 WARNING Unable to grok section 'unknown', overriding it with misc
<rhpot1991_laptop> 13:10:31 WARNING Upload was rejected:
<rhpot1991_laptop> 13:10:31 WARNING Â  Â  Â  Â atomicparsley_0.9.0-0ubuntu1_i386.deb control file lists section as main/unknown but changes file has main/misc.
<rhpot1991_laptop> but its set as misc in my debian/control
<asac> pitti: interesting that this package has firefox as build-dep anyway
<ogra_> rhpot1991_laptop, does it have a control.in by chance ?
<pitti> asac: oh, indeed
<pitti> asac: want me to remove the firefox source then?
<asac> pitti: i guess that should be removed from seeds?
<rhpot1991_laptop> nope
<rhpot1991_laptop> I am using cdbs, not sure that matters
<pitti> rhpot1991_laptop: it shouldn't; cdbs doesn't care about/touch Section:
<asac> pitti: please keep it, but demote it to universe ... firefox-2 binaries will go to universe ... several people requested that they need this or that extension and i want to serve that need somehow
<pitti> asac: but if the binaries are all shadowed by the firefox-3.0 source, what's the purpose?
<rhpot1991_laptop> I had it as unknown originally, but changed it cause unknown isn't alloud
<asac> pitti: new binaries will grow :)
<frafu> pitti: thanks for the review and the promotion of mousetweaks. Point 1 of what has to come next is already done because it has been added as a dependency to the gnome control center and accepted. However I think that your second point of your reply about making LP kick in might not be correct because mousetweaks is not hosted in GNOME since its integration into it.
<pitti> frafu: I mean stripping the translations (*.mo) out of the .debs and importing htem into LP
<pitti> frafu: so that language-pack-* will have the translations, and you can use LP to translate
<slytherin> Can anyone please look at .diff.gz attached to bug 190405
<ubotu> Launchpad bug 190405 in bluez-gnome "please upgrade bluez-gnome to 0.18 " [Wishlist,Confirmed] https://launchpad.net/bugs/190405
<geser> rhpot1991_laptop: looking at the .diff.gz I still see Section: unknown in debian/control
<frafu> pitti: but mousetweaks is not hosted anymore on launchpad (has been abandoned) ; it is hosted on gnome svn. Does this not matter?
<pitti> frafu: no, it doesn't
<pitti> frafu: the Ubuntu packages are hosted on LP
<pitti> and the language-pack-* refers to the Ubuntu packages, not the upstream project
<frafu> pitti: ok.  Do I have to ask for a feature freeze exception?
<pitti> frafu: what for?
<frafu> to get mousetweaks included?
<asac> pitti: i subscribed ubuntu-archive to bug 193321
<ubotu> Launchpad bug 193321 in firefox "please demote firefox source to universe" [Undecided,New] https://launchpad.net/bugs/193321
<pitti> frafu: no, that's fine; it was requested and discussed before FF
<pitti> frafu: take my approval if you feel better :)
<pitti> frafu: (I'm still in the release team, although not the primary RM any more)
<pitti> asac: ah, I just did that :)
<asac> pitti: oh ok ... then don't bother
<asac> i will close it
<pitti> asac: alrady done, thanks
<frafu> pitti:  cool B)
<rhpot1991_laptop> pitti: hmmm, I just got the latest diff.gz from my box and it looks different than the one from LP
<pitti> rhpot1991_laptop: uh, that's disturbing
<pitti> forgot to rebuild the source package before upload or so?
<rhpot1991_laptop> well I didn't rebuild now
<rhpot1991_laptop> so that shouldn't be the case, unless I somehow did upload this one, but I swear that a MOTU made me change that
<asac> carlos: ping ... firefox locales ;)
<warp10> Hi all!
<asac> hi warp10
<carlos> asac: I'm on the phone, will ping you once I'm done.
<warp10> hey asac!
<asac> carlos: oh ok ...  i have a conf call in 10 minutes too ;)
<carlos> asac: or even better, talk with jtv, he's my manager and should be able to provide all information... ;-)
<rhpot1991_laptop> pitti: http://revu.tauware.de/details.py?package=atomicparsley
<rhpot1991_laptop> pitti: has misc in there
<sistpoty|work> asac: bug #193319 is just a demotion from main to universe? or are there other changes as well?
<ubotu> Launchpad bug 193319 in firefox "FF exception: firefox source will be revived to produce firefox-2 binaries in universe" [Undecided,New] https://launchpad.net/bugs/193319
<asac> sistpoty|work: binary package renamed
<sistpoty|work> asac: oh, heh, well I guess that isn't really exception worthy imo
<asac> sistpoty|work: its basically the same package ... only difference is package name and the binary name is now /usr/bin/firefox-2
<asac> sistpoty|work: yeah ... i just don't want to ignore motu-release :)
<sistpoty|work> heh
<awen_> calc: hi. i've tried looking further into bug 192310 regarding openoffice.org-hyphenation and openoffice.org-hyphenation-en-us containing the same file...
<ubotu> Launchpad bug 192310 in hyphen "package openoffice.org-hyphenation-en-us None [modified: /var/lib/dpkg/info/openoffice.org-hyphenation-en-us.list] failed to install/upgrade: trying to overwrite `/usr/share/myspell/dicts/hyph_en_US.dic', which is also in package openoffice.org-hyphenation" [High,Confirmed] https://launchpad.net/bugs/192310
<awen_> calc: I can't really figure out what the best solution could be; from what Martin-Ãric Racine has said in the bug, compared to the current state of the openoffice.org-hyphenation-* packages, it seems quite of a mess
<frafu> pitti: concerning the next upload : I prepare the package, submit a bug  (supplying the diff.gz) and subscribe ubuntu main sponsor to it correct? What title should I give to the bug? Next monday, a new upstream release is due: should I wait for the new release or package the current release? (I will prepare a package after the new release even if you tell me to meanwhile post the current package)
<pochu> frafu: is that mousetweaks? If so, you can add it to the DesktopTeam TODO
<dholbach> Ubuntu Development Week is up and running in #ubuntu-classroom!
<awen_> calc: I was told in #ubuntu-motu that you might have an opinion on that
<frafu> pocho: yes mousetweaks; do I get you right: instead of subscribing it to ubuntu-main-sponsor, I add it here: https://wiki.ubuntu.com/DesktopTeam/TODO?
<pochu> frafu: to the weeklyTODO, yes
<frafu> pochu: sorry for the typo
<pochu> frafu: with a link to the dsc, or to a bug where it is
<pochu> no probs :)
<frafu> pochu: ok
<frafu> thanks
<pochu> frafu: feel free to drop by #ubuntu-desktop and ask any questions you may have
<frafu> pochu: ok; thanks for the tip
<mario_limonciell> pochu, good news: gmyth is in debian now (at least in NEW), we'll be able to sync the gstreamer bad plugins soon again
<pochu> mario_limonciell: yeah, nice work!
<mario_limonciell> pochu, slomo helped rush it in. so thank him :)
<pochu> I already did :)
<calc> awen_: i'm going to talk to the debian maintainer and see what he thinks about i
<calc> awen_: er it
<awen_> calc: thanks, sounds good... just give a sound in the bug or poke me in #ubuntu-motu and i'll be happy to help out with some repackaging if needed
<slytherin> Should I also add the bluez-gnome bug to Weekly TODO page?
<slytherin> Can please someone tell me what the course of action should be? I have added .diff.gz to a bug for bluez-gnome. I have subscribed main sponsors. Will someone look at it?
<seb128> slytherin: that's the sponsoring team idea yes
<seb128> slytherin: you are speaking about the desktop team WeeklyTODO? No need to update that no
<slytherin> seb128: Ok. So nothing left form my side right?
<seb128> correct, just wait for a review now
<slytherin> Ok cool
<rhpot1991_laptop> anyone have any idea why my diff.gz is different on LP than on revu?
<geser> rhpot1991_laptop: have you asked the motu who did the upload for you?
<\sh> hmm...
<\sh> Setting up ttf-opensymbol (1:2.3.0-1ubuntu5.3) ...
<\sh> Updating fontconfig cache...
<\sh> /usr/share/fonts: failed to write cache
<\sh> etc. just update gutsy with -security and -updates (latest)...
<seb128> do you have some clock issue on this box?
<\sh> seb128: nope...17:53 UTC+1
<\sh> seb128: clock is correct
<seb128> k
<rhpot1991_laptop> geser: left them a message, thanks
<seb128> there is some bugs about fonts cache update failing if the directory timestamp is newer than the system clock
<seb128> dunno who the issue is in your case though
<\sh> seb128: oh yes
<\sh> seb128: I see that the /usr/share/fonts dir is set at least one hour later...18:22 in this case
<\sh> seb128: what can cause this? machine clock is set to UTC...installer settings: also choose UTC (german time is the result)
<seb128> \sh: the CD might assume your computer clock is on UTC where the installed system doesn't, evand or cjwatson likely know better
<cjwatson> rhpot1991_laptop: it's normal for a .diff.gz to change if it's rebuilt; .gz files contain a timestamp
<cjwatson> there are various bugs around UTC handling, certainly, which we need to look into for hardy
<rhpot1991_laptop> cjwatson: the one on LP seems to have some old code in it
<rhpot1991_laptop> causing a failure in uploading
<rhpot1991_laptop> cjwatson: https://edge.launchpad.net/ubuntu/+source/atomicparsley/0.9.0-0ubuntu1 if you want to have a look
<rhpot1991_laptop> and: http://revu.tauware.de/details.py?package=atomicparsley
<cjwatson> I don't, just mentioning a generality :-)
<rhpot1991_laptop> heh, ok
<carlos> asac: did jtv talk with you already?
<rhpot1991_laptop> I'm still new to ubuntu dev, so kinda lost when I run into problems
 * ogra wonders where mvo's python-central 0.5.50ubuntu5 upload went 
<ogra> (uploaded 13:50 UTC ... still no trace on a.u.c)
<seb128> pitti: could you do a jockey no change upload? the fixed python-central is available now
<stgraber> ogra: it's on LP, I downloaded it one hour ago
<geser> ogra: looking at the timestamps it looks like a.u.c doesn't get updated anymore again
<ogra> stgraber, there is no binary on archive.ubuntu-com
<seb128> ogra: like mirroring issue
<seb128> likely
<ogra> yeah
<stgraber> ogra: not the first time this week that archive.u.c is laggy
<mvo> ogra: Accepted: python-central 0.5.50ubuntu5
<\sh> cjwatson: fyi, clock set during installation to UTC, localtime is UTC+1 (CET) and files were written with UTC+2
<ogra> mvo, i know i got the source package here from LP
<mvo> aha
<ogra> but the users dont get it
<stgraber> http://launchpadlibrarian.net/12084647/python-central_0.5.50ubuntu5_all.deb
<stgraber> ouch, according to apt-cache the current version of python-central on archive is still ubuntu3 :)
<ogra> yep
<ogra> 4 has the source available but no binary
<cjwatson> stgraber: the previous cause of archive.u.c failed updates is fixed, and has not recurred
<cjwatson> but there seems to be a stale lock
<cjwatson> I don't have time to fix it now but will raise it with others
<\sh> how nice...ncurses FTBFS..
<ScottK> slangasek: I notice from reading planet that once again LP has scheduled and outage/upgrade on the same day as an Ubuntu milestone release.  This has proven to be a painful thing in the past.  I thought I'd mention it to see if maybe the two events could be separate a bit in time ...
<cjwatson> ScottK: there are some discussions in progress about that
<cjwatson> it may be that this is still most convenient for other reasons
<asac> carlos: no he didn't
<ScottK> OK.  Just wanted to make sure the right people were aware and if we have to suck up any pain it wasn't just by accident.
<asac> carlos: any issues?
<\sh> pitti: language-selector-common prerm script crashes with a BT :)
<\sh> pitti: during upgrade from gutsy to hardy
<\sh> pitti: to be more precise: pycentral failes...and I can't start a ff now for filing the bug..will do later
<carlos> asac: well, the news are not too good for Hardy, but he just told me that he just sent you an email
<asac> carlos: whats his email?
<carlos> asac: jtv@canonical.com
<Riddell> New Queue Zero achieved!
<_MMA_> Nice. :)
 * ScottK looks around for some backports that'll need Newing.
<jdong> ScottK: btw, on a related note, how would you like to handle queuing source change backports?
<jdong> ScottK: shall we redefine the triaged state for this purpose?
<ScottK> Let me think about that.
<jdong> yep
<jeromeg> jdong: by the way you are the only one suscribed to gutsy backports, shouldn't the whole backport team be suscribed ?
<jdong> jeromeg: indeed, I guess that's a oversight
<jdong> am I the only one who can correct that </laziness>
<jeromeg> :)
<jeromeg> jdong: as you are the owner of the project, I guess so
<jdong> jeromeg: what do you think, -backporters or -backports-testers
<jdong> do you think testers would mind the spam err bug mail?
<jeromeg> jdong: I odn't think that there are many of them, and I see only a bunch of active testers, that could remind the others that this project exists :)
<jdong> ok let's do it!
<jdong> done kthxbye *vanish*
 * jeromeg is going to suscribe to backport testers :)
<\sh> mvo: you uploaded the last python-central, right? I just had to install the new one from LP and now during upgrade I see this message
<\sh> mvo: pycentral: byte_compile: python version '2.4' requested but not available
<\sh> brb rebooting
<jdong> \sh: bug 192992? :)
<ubotu> Launchpad bug 192992 in python-central "[hardy] pycentral crashed with ValueError in parse_versions()" [High,Confirmed] https://launchpad.net/bugs/192992
<jdong> or is that the "fix" erroring out :D
<jdong> it's a feature (oh wait that's not allowed either)
<jeromeg> jdong: could you please ack bug 190471 and bug 193374 ?
<jeromeg> jdong: earlier versions of those packages are already in backports
<ubotu> Launchpad bug 190471 in gutsy-backports "Please backport scribes 0.3.3.3-3 from Hardy" [Undecided,New] https://launchpad.net/bugs/190471
<ubotu> Launchpad bug 193374 in gutsy-backports "Please backport sonata 1.4.2-1 from Hardy" [Undecided,New] https://launchpad.net/bugs/193374
<jdong> jeromeg: not atm, I don't have the information at hand to confidently ack things :)
<jeromeg> jdong: ok
<jeromeg> i think we can close bug 183678 and bug 190358
<ubotu> Launchpad bug 183678 in gutsy-backports "mono runtime 1.2.5 needs to be upgraded to 1.2.6" [Undecided,New] https://launchpad.net/bugs/183678
<ubotu> Launchpad bug 190358 in gutsy-backports "Please backport Alsa 1.0.16 from gutsy." [Undecided,New] https://launchpad.net/bugs/190358
<jeromeg> what's your opinion on this ?
<jdong> jeromeg: agreed, both are unreasonable backports
<jeromeg> jdong: ok, I'll close them as won't fix
<jdong> thank you
<jeromeg> np
<\sh> jdong: after that error ;)
<jdong> \sh: + except: pass
<\sh> jdong: I installed the new pycentral and then restarted my upgrade...and the 2.4 warning came
<jdong> there problem fixed.
<mvo> \sh: yes, that message is where it crashed before. do you have python2.4 python2.4-minimal installed?
<\sh> mvo: nope...it was an dist-upgrade from gutsy to hardy...totally clean
<\sh> oh and compiz with an intel card works...but the shadows are, well, crap :)
<mvo> \sh: yes and yes
<mvo> \sh: :) where is gives the message it used to crash, doko will likely modify my fix again, but at least its working again
<\sh> mvo: cool...now I need to fix ncurses package somehow, that it will build again
<\sh> but first...leaving the office :)
<\sh> asac: btw..upgrading from gutsy to hardy...and ff3 upgrade leaves an empty launcher on the gnome-panel...(formerly ff2)
 * \sh heads home...bbl
<jeromeg> got to go
<jeromeg> bye all
<asac> \sh_away: i have that in my mind, yes.
<asac> \sh_away: if you could file a bug and set it blocking some milestone i would much appreciate it
<keescook> pitti: hi!  Can you look at a hal patch?  David Zeuthen hasn't commented on it yet, and I'd like to get it into Hardy if it's sane: https://bugs.freedesktop.org/show_bug.cgi?id=14537
<ubotu> Freedesktop bug 14537 in hald "hald ignores virtual network devices (e.g. vlan and bridge ifaces)" [Normal,New]
<mjg59> Fun
<mjg59> Epiphany doesn't want to open https sites for me
<mjg59> Oh, right, it's the self-signed cert thing
<asac> mjg59: workaround for now: accept cert permanently in ffox and copy the ffox cert*.db to your ephy profile
<mjg59> asac: Heh
<mjg59> asac: I'm getting some weird layout issues in ffox3 - the BBC news website has continuous bars split up, for instance
<asac> mjg59: like http://people.ubuntu.com/~asac/corrupted1.png ?
<asac> or "really" layout?
<asac> mjg59: have to go now. if its not like the pic above, i would appreciated to get a bug with a screenshot ;)
<mjg59> asac: Not that, I'll grab a screenshot
<selckin> lp down?
<awen_> is it okay when making a .desktop-file to link it to an icon, that the package depends on?
<awen_> is it okay when making a .desktop-file to link it to an icon, that is contained in another package, that this package depends on? (this Q should be more clear)
<awen_> (sry... wrong channel; intended to ask in motu; disregard)
<hellboy195> hi! Any archive admins around? Can somebody rebuild 'ebug-http' . It FTBFS for several times because of broken libcatalyst-perl package (which should be fixed now).
<emgent> heya all
<Amaranth> did something bad happen in bug 193382?
<ubotu> Bug 193382 on http://launchpad.net/bugs/193382 is private
<Amaranth> Or is that just to stop "me too" posts?
<lamont> slangasek: add autofs_4.1.4+debian-2 to the impl-conversion list. :-)
<wasabi> I have a problem with a bad DSDT. Is this a reasonable bug to file against the kernel? Basically, how would you all fix it anyways, specific override of some sort?
<keescook> pitti: hi! seems jockey-common isn't installable (193408)
<mario_limonciell> keescook, that looks like the python-central bug that's out
<keescook> mario_limonciell: oh! eek
<keescook> jockey must have been unlucky -- it's the only thing that failed for me.
<rhpot1991_laptop> mario_limonciell: did you get my pm earlier?
<mario_limonciell> rhpot1991_laptop, no i didn't
<rhpot1991_laptop> the diff.gz on LP and REVU are different
<rhpot1991_laptop> the LP one seems to have some old stuff in it, hence the error showing up
<mario_limonciell> that's interesting.
<mario_limonciell> nothing should be different, i pulled it right from revu
<mario_limonciell> i'll repull when i get home and try it again then
<mario_limonciell> you sure that's the cause?
<rhpot1991_laptop> ya, the one on LP has "+Section: unknown" in it
<rhpot1991_laptop> that got changed to misc at some point
<mario_limonciell> ah okay.
<mario_limonciell> well i'll take care of it when i get home
<rhpot1991_laptop> whenever you get a chance
<rhpot1991_laptop> I think the ffmpeg on your ppa might not be doing aac right too
<mario_limonciell> for which release?
<rhpot1991_laptop> gutsy
<rhpot1991_laptop> complaining about unknown codec 'aac'
<mario_limonciell> i shouldn't have ffmpeg on gutsy on my ppa, if so that was a mistake
<rhpot1991_laptop> I'm rolling back to medibuntu stuff by hand to verify I'm not doing something stupid
<rhpot1991_laptop> my machine slurped it up when I was trying your mythtv build
<mario_limonciell> a
<mario_limonciell> ah
<rhpot1991_laptop> superm1: verified that the gutsy ffmpeg on your ppa doesn't do aac, might want to check your hardy one just incase
<mario_limonciell> rhpot1991_laptop, yeah i shouldn't have an ffmpeg there.  it was intended for dapper, but for debugging only when the dapper build failed
<mario_limonciell> i'll remove it later
<rhpot1991_laptop> think the weekly build mythtv and your ppa mythtv will communicate fine?
<rhpot1991_laptop> at work so I can't check and see if they are working
<geser> rhpot1991_laptop: as your (source) package got accepted (even if it didn't build/upload) an new upload with a new version is necessary
<rhpot1991_laptop> geser: a new upload to where, LP from REVU?
<rhpot1991_laptop> or do I need to make a new one into revu and get it ack'd again
<geser> rhpot1991_laptop: into the archive, as -0ubuntu2
<geser> rhpot1991_laptop: an new round through REVU isn't needed, a debdiff with the changes attached to a bug in LP and subscribe ubuntu-universe-sponsors is enough
<rhpot1991_laptop> alright, I'll do that when I get a chance later, thanks
<YokoZar> pitti: thank you for the new ia32-libs :)
 * jdong kicks Amaranth 
 * Amaranth looks around
<Amaranth> What'd I do?
<jdong> Amaranth: ok, in compiz scale mode, when I miss a window and click empty space, all my open windows go scattering minimized
<jdong> it's like I'm some nazi window hunter and the persecuted windows go into hiding
<Amaranth> Yes, you chose to view the desktop
<jdong> Amaranth: pfft no, I have bad hand-eye coordination!
<xivulon> slangasek, was anything decided on metalink urls?
<jdong> any way to turn off that behavior?
<xivulon> also can I assume that md5sums and md5sums.gpg will be provided?
<jdong> Amaranth: http://jdong.mit.edu/~jdong/day_in_matlab_hell.png <-- for something like that, it's quite costly to miss ;-)
<Amaranth> jdong: scale options "Click Desktop to Show Desktop"
<Amaranth> eep
 * jdong hunts for said option
<Amaranth> of course you could just hit ctrl-alt-d to undo the Show Desktop action if you miss
<jdong> Amaranth: you could've told me that sooner and saved me 40 mouseclicks
<Amaranth> heh
<jdong> but anyway, love ya!
<Amaranth> that's only been a standard thing since...how long has metacity existed?
<Amaranth> at least that long :)
 * jdong goes back to remembering what the hell "figure 11" is
<Amaranth> hehe
<Amaranth> have fun
<jdong> :D
<YokoZar> Is there any reason why backports shouldn't add new packages?
<_MMA_> YokoZar: #ubuntu-motu might be the better channel but they do add new packages.
<ScottK> YokoZar: We do it all the time
<ScottK> They just have to get into the developmental release and then we can backport them if they are new
<YokoZar> ScottK: I'm a little bit confused as to why there's a time between feature freeze and release where we don't let new packages in then, since they can come in later through backports
<ScottK> Because backports aren't enabled by default, so users have to go out and get them.
<YokoZar> Could we add to backports before release?
<ScottK> No, because it does actually have to be backported from an Ubuntu release.
<ScottK> That's a hard and fast QA rule.
<YokoZar> heh, ok
<lamont> how do I tell stupid gnome-panel to always group like apps?  these 10-pixel wide window names on the bottom bar are pretty useless
<Fujitsu> lamont: Right click on the window list widget, hit preferences.
<lamont> Fujitsu: "window list widget"??
<lamont> ah, found it
#ubuntu-devel 2008-02-20
<elmo> # FIXME: Remove this LVM block after Etch releases
<elmo> ^-- mkinitramfs in gutsy ;-)
<jdub> bryce: unlikely ping (totally awesome X bug)
 * lamont wants a fix for debian bug#457799
<lamont> (zenmap desktop file)
<jdub> hey lamont
<lamont> howdy jdub
<lamont> long time no see
<calc> asac: i finally got it all patched and tried to build ooo with lzma and xulrunner-1.9 and it failed, so i'm trying to debug it now
<calc> asac: i'm not sure if it is actually related to xulrunner yet or not
<calc> asac: i may end up sending you the patch and have you look over it to see if it looks right to you
<calc> asac: i may have done something wrong since i haven't messed with autoconf stuff in a while
<calc> asac: esp autoconf + pkgconfig code
<bryce> jdub: thanks :-)
<bryce> jdub: yeah it's surprising how many serious issues this one patch solves
<bryce> jdub: and I have a suspicion that if we use it for ALL intel graphics it may solve a slew of other similar bugs
<Hobbsee> argh.
<Hobbsee> going away is bad.
<TheMuso> Hobbsee: With all the email you have to catch up on, yes of course it is.
<Hobbsee> TheMuso: yeah...and updates.
<TheMuso> Meh thats nothing compared to email.
<Hobbsee> yeah, true
<jdub> bryce: still there?
<bryce> jdub, yup
<jdub> http://www.gnome.org/~jdub/2008/x-marks-the-black.png
<jdub> bryce: so here's why it's weird
<jdub> that black area is completely inactive (blacked out), 'cept for the mouse cursor
<jdub> then if i disable the metacity compositor
<jdub> the previously active area goes inactive (no more updates)
<jdub> and the previously inactive area becomes active (i can see the background and move windows into it)
<jdub> and i can switch between those areas by turning the compositor on and off
<jdub> reproduceable after logout and reboot
<jdub> it's wild :-)
<bryce> jdub, have you tried doing `xrandr --output LVDS  -off`?
<jdub> bryce: yeah -- no change
<jdub> note that the whole screen area (1920x1200) is, uh, interactive... but isn't updated
<jdub> you can see the panel disappears into the black on the right there
<bryce> hmm, so by chance is the active area 1280x800?
<jdub> yes, the size of the LVDS :-)
<bryce> interesting, so best bet is that the LVDS is confusing either X or metacity
<bryce> have you tested running a different wm?
<jdub> the composite inversion thing is hilarious
<jdub> no, just states of metacity
<jdub> i'll try something else now
 * jdub finds something that is not objectionable
<bryce> if I had to guess, I'd bet it's xrandr confusifying metacity
<bryce> we've seen a variety of metacity and gnome bugs when resizing, disabling, etc. stuff through xrandr
<jdub> aha, interesting
<jdub> under twm, it's all okay
<bryce> ahh, as I suspected
<jdub> okay
<jdub> i am shocked and appalled that it's metacity :-)
<bryce> hehe
<jdub> thanks, i should've thought about running another wm
<bryce> I suspect its looking at what outputs are *connected* rather than which are *enabled*
<jdub> i'll bug marnanel about it
<nixternal> uh oh, jdub is in da hizzy, hide your liquor!
<bryce> jdub, glad to help :-)
<jdub> this compositor switching thing will melt his face
<jdub> if not his brain
<jdub> meanwhile, the vintage appeal of twm
<bryce> hehe
<jdub> alt-tab? HAHA. children.
<bryce> hmm, wouldn't it be ironic if you switched compiz on and it worked fine there too?
<jdub> thankfully, compiz just didn't start at all
<bryce> ah, whew
<bryce> metacity is saved that embarrassment ;-)
<bryce> slangasek: tjaalton and I have a couple questions about getting in some X package uploads for alpha5 if/when you're around
<Hobbsee> bryce: ouch.  where are they?
<tjaalton> uploaded ~8h ago
<bryce> heya cjwatson
<slangasek> bryce: ok, what packages?
<bryce> slangasek: xserver-xorg-video-intel and xorg-server
<bryce> also, we are considering syncing xserver-xorg-video-ati, which just had a new release yesterday
<tjaalton> a new _stable_ release, the first in 18 months or so :)
<bryce> right; we currently have a fairly recent git snapshot, but would like to get onto the official released version
* slangasek changed the topic of #ubuntu-devel to: Archive: Feature freeze, Alpha 5 freeze | 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
<pitti> Good morning
<bryce> heya pitti
<Hobbsee> morning pitti!
<Hobbsee> darn.
<Hobbsee> just after i deleted all the package changes
<warp10> Good morning
<slangasek> bryce: please hold off the sync of the new -ati release until after the alpha.  The others would be uploads of targetted bugfixes?
 * pitti hugs Hobbsee and bryce, good morning
 * Hobbsee hugs pitti back :)
<pitti> YokoZar: you're welcome
<bryce> slangasek: ok.  Yes they're fixes for specific critical bugs
<YokoZar> pitti: :)
<Hobbsee> bryce: i can't seem to find -intel.  where is it?  :)
<pitti> keescook: fallout from the python-central goo; I think seb128 did a rebuild, I'll check it out today
<pitti> keescook: hald virtual network> ah, that patch looks good; virtual interfaces are direct childs of computer? ok
<pitti> keescook: I'll apply it after hardy-5, ok?
<bryce> Hobbsee: tjaalton uploaded it; it's also present at http://people.ubuntu.com/~bryce/Uploads/
<pitti> \sh_away: language-selector-common> if it was uploaded recently, it'll need a rebuild
<pitti> \sh_away: hm, it was not; seems it'll just sort out itself
<Hobbsee> bryce: oh good.  that's a workable solution for hardy, then.
<keescook> pitti: hal> yeah, I tried a few ideas (matching MAC addresses) etc, and in the end nothing really works well, and trying to represent a tree for network devices starts becoming non-trivial since you can have very non-tree relationships (vlan interfaces on different physical interfaces belonging to different bridges, etc etc)
<keescook> so, due to madness, I just went the route of having them show up where other virtual devices do -- direct children of computer.
<pitti> keescook: yeah, makes sense; the hal tree is organized by physical bus layout
<pitti> so I'm fine with this solution
<pitti> keescook: I didn't see upstream's comment on this, though?
<keescook> okay, cool.  I'd _like_ vlan interfaces to show up as children of the physical dev, but i'd like that hinting to come from the kernel since I can't count on interface names showing the relationship.  Yeah, David hasn't commented still.  I pinged him on IRC, but no response there either.
 * ogra mumbles about the buildds not having http access to pull data from popcon at buildtime ...
 * Hobbsee grumbles about this keyboard bug.
 * keescook goes to bed
<slangasek> bryce: so is 177492 is the only change not yet uploaded?  How soon could you have it uploaded if I said "yes" for alpha5?
<bryce> immediately; we have the packages ready to go
<bryce> slangasek: the change (which involves one patch to xserver and two to -intel) essentially just flips a configuration option, and in the new config it solves 4 different issues
<slangasek> ok, please go for it
<bryce> cool thanks, tjaalton would you mind putting the upload in?
<tjaalton> ok, let's try again
<tjaalton> uploaded
<tjaalton> still not getting them through
<bryce> tjaalton: where are you looking to see if they come through?
<tjaalton> my inbox and the changes list :)
<tjaalton> same thing 8h ago
<bryce> ah
<thegodfather> superm1: ping?
<ogra> bryce, do you know if there is somebody anywhere in the world packaging the intel embedded graphics drivers (iedg) into .deb ?
<superm1> thegodfather, hey
<superm1> i'm off to bed in a few min, is it quick?
<thegodfather> superm1: hey dude... yes quick.. did you read my suggestion to make the Depends on libmyth (= version) instead of (>= version) ?
<pitti> keescook: btw, David and other upstreams are much more likely to comment on the hal ML; no idea why they ignore the bug tracker so much
<thegodfather> superm1: all plugins refuses to work if the lib is newer anyway
<superm1> thegodfather, yeah while we are in trunk, that does make more sense
<thegodfather> superm1: might as well avoid the update until it's all in sync on the same system
<thegodfather> superm1: ok cool. that's it.. good night :)
<slangasek> asac: any objections to a no-change rebuild of NM against the current libnl?
<bryce> ogra, no idea; in fact this is the first I've heard of iedg
<asac> slangasek: has libnl been upgraded?
<ogra> bryce, yeah i heard about it last week first time and was told it improves the classmate ... i'll try it myself then .. saldy i dont seem to be able to find the actual source, they have a binary rpm and an exe :/
<slangasek> asac: yes, we have libnl 1.1-1 in hardy now
<bryce> ogra, hrm, not a good sign
<ogra> right
<asac> slangasek: oh ... thast most likely more recent than 1.1-pre8, right?
<ogra> but they asvertise its linux compatibility (at least for xorg 7.0 to 7.2)
<asac> slangasek: i think it won't build then ... at least 0.6 branch needed apatch for pre8
<ogra> *advertise
<slangasek> asac: it's no longer pre-, so yes it's more recent
<asac> slangasek: i added this to my todo list. feel free to prod me in case don't happen quick enough
<slangasek> asac: ack, thanks
<slangasek> pitti: libpam-mount was recently promoted to main but not libhx, which is mentioned as a build-dependency in https://wiki.ubuntu.com/MainInclusionReportLibPamMount - oversight?
<pitti> slangasek: ah, oversight, sorry
<pitti> slangasek: I'll review and either promote, or demote libpam-mount again and ask for an MIR
<slangasek> asac: confirmed that n-m FTBFS currently; Debian does seem to have the package, so perhaps this would be a straightforward merge
<slangasek> pitti: ok, cheers
<asac> slangasek: well ... there is a patch patch available. but i think upstream had concerned with the debian one, but afaik they care for latest libnl in the 0.6.6 update they wanna release
<asac> and most likely its alrady in the 0.6.6 preview release they did last week ... i'll look
<slangasek> ok, I'll shut up and leave it in your hands :)
<dholbach> good morning
<asac> slangasek: hehe ;)
<geser> good morning
<cjwatson> slangasek: hostname => hostname -f basically ends up being localhost() => gethostbyname(localhost())->h_name
<cjwatson> slangasek: /etc/hosts might not be configured in the livefs chroot, which could be it?
<slangasek> mmm, right
<slangasek> ok, I'll upload a quick 'hostname -a || hostname' fix
<TheMuso> c
<TheMuso> ugh wrong tab
<slangasek> er, hostname -f || ...
<cjwatson> slangasek: how about also having livecd-rootfs copy /etc/hosts from the build system?
<cjwatson> of course live fs building is chroot-within-chroot and I don't know if the middle chroot has an /etc/hosts either
<slangasek> cjwatson: well, I can't actually reproduce the error by nuking my /etc/hosts in a chroot... so conversely, it doesn't seem that copying /etc/hosts would fix it
<slangasek> not that having a good /etc/hosts would be a bad thing
<cjwatson> hm
<cjwatson> where did I put my unpacked glibc tree
<cjwatson> oh, mind you, if we copied /etc/hosts during build we'd have to take care to clean it out at the end too
<cjwatson> terranova's /etc/hosts is probably not massively useful elsewhere
<slangasek> heh
<cjwatson> thank you, glibc, for calling the file containing gethostbyname() "gethstbynm.c"
 * cjwatson hands Ulrich some more vowels
 * slangasek trembles to think how they'll be applied
<ion_> :-D
<bryce> hi seb128
<seb128> hey bryce
<pitti> hey seb128, bonjour
<pitti> seb128: thanks for taking care of the jockey rebuild
<seb128> guten tag pitti ;-)
<seb128> pitti: you are welcome, I didn't manage to use the bzr correctly though I think, sorry about that
<pitti> seb128: no, it was fine
<thekorn> pitti: hi, I think I broke the ubuntu-bugpattern branch yesterday, I useed bzr 1.x and did not know that the brnach format changed,
<pitti> seb128: unlike apport and r-m, jockey has an orig.tar.gz, though, which makes it a little harder
<seb128> pitti: I diffed the current package and bzr, and there is 3 examples which are in one and not the other and the ChangeLog you generate, but the gnu format doesn't work on my installation
<thekorn> so, this branch can't be used with bzr <1.x anymore
<pitti> thekorn: that's just the format of your local checkout, I assume
<thekorn> $ bzr branch http://bazaar.launchpad.net/~ubuntu-bugcontrol/apport/ubuntu-bugpatterns
<thekorn> bzr: ERROR: Unknown branch format: 'Bazaar pack repository format 1 (needs bzr 0.92)\n'
<cjwatson> does look like hostname -f || hostname is the right answer, anyway
<cjwatson> thekorn: that would normally only happen if you explicitly did 'bzr upgrade'
<cjwatson> bzr doesn't auto-upgrade branches just 'cos you use a newer version of bzr
<thekorn> I might be wrong but I think a simple   bzr branch ... ; bzr commit; bzr push   changes the branch format
<cjwatson> thekorn: it gives you a local branch with a different format, but it doesn't change the format of the remote branch IME
<cjwatson> hmm, python-central doesn't seem entirely fixed; bzrtools still refuses to upgrade or even install from scratch, even after rebuilding with absolute current python-central
<slangasek> and that's not a bzrtools bug?
<cjwatson> though it seems to be a different problem from the original python-central one
<cjwatson> it's something to do with the pycentral upgrade handling
<cjwatson> hmm, or maybe not, I'm investigating
<soren> Hm.. The kernel udebs are missing on the alternate installer. Is this known?
<cjwatson> doko: http://paste.ubuntu.com/4793/
<cjwatson> doko: is this a python-central bug or a bzrtools bug?
<doko> looking ...
<cjwatson> soren: damn, I forgot to change the seeds again
<cjwatson> will fix
<soren> cjwatson: The oddest part (IMO) is that the cd build logs talk about -7.. We've been using -8 happily for at least a few days have we not?
<cjwatson> soren: depends which bit of the CD build logs. Like I say, I only updated d-i and forgot to update the seeds too.
<soren> cjwatson: Sure, got that, but AFAIR we updated both to -8 a few days ago, and now I see "! Allowing d-i kernel versions: ['2.6.24-7-386']" in the build logs. Maybe I just remembered wrong. :/
<cjwatson> soren: we did not. we updated *only* d-i because *I forgot*.
<cjwatson> soren: you seem to be saying "but you remembered" and it's clear I didn't because I only made the change just now.
<cjwatson> should be fixed now, anyway
<soren> Erm.. Ok. I thought you were updating it to -9 now.
<soren> I'm clearly confused.
<pitti> doko: so the python-pysqlite2 package is 100% integrated into python2.5?
<pitti> doko: it says "Python-Version: 2.4, 2.5" (unlike -celementtree, which only has 2.4)
 * soren wonders which kernel version the dailies from yesterday and the day before used
<TheMuso> soren: afaik -9 has no meta yet.
<pitti> doko: oh, seems it's called 'sqlite3' in python2.5, not pysqlite2
<soren> TheMuso: You're probably right.
<cjwatson> mjg59: your VT switch font restoration patch works beautifully. Thanks!
<doko> pitti: afaik there are three versions of the sqlite module, 2.5 only comes with sqlite3
<pitti> doko: python-pysqlite2 is still in main, built for 2.5, and has a different python module name, so I guess leaving it as a recommends doesn't hurt for now?
<doko> hmm, if we don't need it, why keep it?
<\sh> doko: ncurses FTBFS...it can't find the 32bit libs which were moved from /emul/ to /usr/lib32/ (ubuntu change)...I don't have the time to fix it myself...
<pitti> doko: we could patch the upstream source to import s/pysqlite2/sqlite3/, but that would break with python2.4?
<doko> pitti: I'll have a closer look later today
<pitti> doko: ok, thanks
<Fujitsu> Somebody might want to throw the netbeans binary back to universe.
<pitti> Fujitsu: erk, done; thanks
<doko> cjwatson: this time not pycentral, but bzrtools; there's a "workaround", which just removes all the preparation work done by pcentral. preparing a fix
<cjwatson> doko: ok, cool, thanks
<pitti> mvo: so you tried ndisgtk and think we can support it?
<soren> I've tried it.
<pitti> it's shiny?
<soren> Quite.
<soren> I like it.
<pitti> . o O { bah, can we please have a su-to-root wrapper like Debian? those tiny debian deltas suck }
<soren> It made setting up the nic in my d430 a breeze (I got the Dell 1505 wifi nic).
<pitti> cool
<pitti> soren: why didn't you take a 3945?
<soren> pitti: DElivery time.
<pitti> soren: well, in the interest of widening the scope of hw of the distro team that was a good choice :)
<soren> pitti: I needed this laptop before Boston (didn't want to be stuck on a plane for 20 hours with a non-kvm-capable machine).
<soren> pitti: That too :)
<mvo> pitti: I played with it a bit, I think its something that a lot of users find very useful, the code itself is relatively small, mostly running some ndiswrapper commands
<pitti> mvo: right; if it's actually working and DTRT, I'm all for it
<pitti> mvo: recently I was quite surprised to see ndiswrapper in main, so we should provide a GUI, too :)
<ogra_cmpc> pitti, it was a SoC project and was in pretty good shape from the beginning :)
<mvo> pitti: :)
<pitti> mvo: btw, did you get an answer about the compiz session mgmt plugin?
<mvo> pitti: not yet :/
<mvo> pitti: I will keep naging about it
<pitti> doko: ok, we are on top of the MIR stack
<pitti> doko: I need to talk about elisa with Keybuk, all the others are incomplete or fully done
 * pitti ^5s doko
<doko> pitti: cool, thanks!
<cjwatson> seb128: where does bug 192441 belong? it clearly isn't casper; I can reproduce the .spx problem on an installed system though not the .ogg problem
<ubotu> Launchpad bug 192441 in casper "Examples folder has files Hardy Ubuntu can't play" [Undecided,New] https://launchpad.net/bugs/192441
<pitti> dholbach: hm, I just tested add-5-a-day, which works fine
<pitti> dholbach: but update-signature breaks my signature
<dholbach> pitti: how?
<pitti> dholbach: first, it adds a "-- " line to it, which shouldn't be part of .signature IMHO (the MUA should add it)
<pitti> second, it should append 5-a-day data, not prepend it (loks really nasty that way)
<dholbach> pitti: let me check if evolution and thunderbird will do it
<pitti> and third, it should leave a blank line
<pitti> dholbach: ok, let me cross-check with mutt
<seb128> cjwatson: that's a duplicate, I closed it
<dholbach> pitti: I'm happy to change the second part
<ion_> Yeah, the MUA should definitely be the one that adds that IMHO.
<dholbach> thunderbird is OK
<pitti> dholbach: hm, mutt adds "-- " unconditionally itself, thus I end up with two
<ion_> What is this update-signature you speak of?
<dholbach> ion_: http://wiki.ubuntu.com/5-A-Day#Log
<ion_> Thanks
<pitti> dholbach: and it doesn't wrap the very long line
<pitti> dholbach: anyway, add-5-a-day works great! *hug*
<pitti> dholbach: so you think it's not worth the effort of adding some verbs to the bugs? just the package name?
<pitti> dholbach: WDYT about s/Bug /#/ for brevity?
<dholbach> pitti: if you can think of a clever way update-signature can be used with adding comments
<dholbach> # is fine with me
<pitti> dholbach: no, that would be entirely manual work
<tjaalton> hmm 5-a-day.. we've closed nearly 500 X bugs in the past 80 days, so it seems we're on track here :)
<pitti> like "#12345 (fixed in hardy), #23456 (tested SRU), etc.
<dholbach> pitti: how will the normal user use add-5-a-day and update-signature?
<dholbach> where will this information come from?
 * pitti is speaking about "vi ~/.signature"
<dholbach> can't figure out evolution right now, I'll assume it adds "-- " itself
<pitti> but if the general consensus is to just mention the package names, I'm fine with it
<pitti> dholbach: testing evo
<pitti> dholbach: meh - seems that evo doesn't even look at ~/.signature
<pitti> dholbach: I have to manually update it in evo
<pitti> dholbach: but I don't have "-- " in the signature field there, evo adds that automatically
<dholbach> I think that jcastro did some symlinking somewhere and it worked
<dholbach> ok, so we're safe
<pitti> right
<pitti> dholbach: so, drop "-- ", and s/Bug /#/, and auto line-wrap?
<seb128> pitti: evo has its list of signature or can use a script
<pitti> and maybe append the 5-a-day data, not prepend it?
<dholbach> the signature will be a bit big ten
<dholbach> already done
 * pitti hugs dholbach
<dholbach> if you do the auto-line wrap, it might get a bit big
<dholbach> but I can do it
 * pitti tries to squeeze his former 3-line sig into fewer lines
<pitti> dholbach: hm; well, let's keep it like it is for now
<pitti> it just looks a bit awkward, but I think that's more a mutt bug
<pitti> dholbach: BTW, I guess it is ok if "my 5 today" are really "my 5 yesterday", since I update the sig in the morning :)
<dholbach> pitti: I think everybody can live with that ;-)
<dholbach> grrrrrr
<dholbach> pycentral crash
 * dholbach fetches ubuntu7
<pitti> keescook: I tagged your patch (Description: and Upstream:) and committed it to ubuntu's hal bzr; I'll upload it after alpha-5
<MacSlow> What could I do to check if a mail I sent to ubuntu-art was actually received or rejected?
<seb128> pitti: did you upload the fix for duplicates battery?
<pitti> MacSlow: you can check the web archive
<stgraber> MacSlow: you can check the archives of the list
<pitti> seb128: I'm just about to commit it
<stgraber> bah, pitti was faster :)
<seb128> pitti: ah ok, I was under the impression you had a pending upload when I pinged about that one week ago
<seb128> pitti: good ;-)
<pitti> well, a TODO list item
<dholbach> pitti: http://daniel.holba.ch/temp/five-a-day_0.7_all.deb - let me know if it's better and I'll upload to PPA
<seb128> pitti: maybe you can upload that now? quite some users notice it
<pitti> seb128: well, I think I can upload it now, too
<pitti> it's just a bug fix, after all
 * seb128 hugs pitti
<seb128> right
<geser> pitti: what is needed to get icatalan, idutch, ispanish and ilithuanian back into the archive? It looks like it was promoted twice from universe to main which mislead LP to remove it completely.
<pitti> erm, you mean it's gone?
<pitti> duh
<geser> pitti: e.g. https://edge.launchpad.net/ubuntu/hardy/i386/icatalan/+index#
<pitti> geser: I'll ask the soyuz guys
<Fujitsu> pitti: I filed a bug on that a couple of days ago.
<pitti> Fujitsu: oh, which? thanks
 * Fujitsu looks.
<geser> pitti: I asked cprov about it and he said it needs archive admin approval to get them back
<Fujitsu> Bug #192547
<ubotu> Launchpad bug 192547 in soyuz "Doubly-overridden binaries get eaten" [Undecided,Triaged] https://launchpad.net/bugs/192547
<MacSlow> hm... sending an email with my ubuntu.com-address apparently gets silently rejected by the ubuntu-art list... I know that I'm subscribed to it with my bangang.de-address
<pitti> Fujitsu: thanks
<geser> there is also bug #193202 complaining about the missing idutch package in hardy
<ubotu> Launchpad bug 193202 in dutch "Missing dependency idutch" [Undecided,Confirmed] https://launchpad.net/bugs/193202
<cjwatson> seb128: thanks
<seb128> cjwatson: you are welcome
<dholbach> pitti: http://daniel.holba.ch/temp/five-a-day_0.7_all.deb - fixed another small bug
<pitti> dholbach: \o/
<dholbach> pitti: let me know if it works for you and I'll push to PPA
<pitti> NameError: global name 'fn2' is not defined
<pitti> argh, pycentral
<seb128> curses doko
<pitti> I have 0.5.50ubuntu6, that's not recent enough, I guess
<dholbach> pitti, seb128: try 0ubuntu7 - it's in LP already
 * dholbach had the same problem
<pitti> not yet in dist-upgrade
<pitti> I'll fetch it
<dholbach> it's weird - how often does the publisher run?
<dholbach> to me it seems like it's running only once a day
<seb128> dholbach: I've no problem, I don't update that often, just speaking about all the python breakages since yesterday ;-)
<dholbach> I had the same experience in the last days already
<cjwatson> dholbach: it had some problems yesterday and some separate problems a few days ago, but AFAICS is working fine now
<dholbach> cjwatson: great - thanks a lot
<cjwatson> gb.archive seems behind for some reason; I thought it updated hourly
<cjwatson> archive is up to date though
<doko> seb128: the fix is in -7
<pitti> yep, that worked
<seb128> doko: ok
<pitti> seb128: ok, hal patch works; my laptop lost a battery *sniff*
<pitti> debian/patches/revoke-free-batteries.patch
<pitti> dholbach: much better, but I still prefer having my original sig at the top, and the 5-a-day list at the bottom
<ion_> Just remember that the evilness of an email signature is exponentially relative to the number of lines in it. :-)
<pitti> seb128: uploaded
<seb128> pitti: danke
<dholbach> pitti: oh, I thought I fixed that - hang on
<dholbach> pitti: sorry my bad, fixing
<dholbach> pitti: fixed and uploaded
<dholbach> thanks again
<pitti> dholbach: hm, I wget'ed and dpkg -i'ed again, no change
<pitti> dholbach: or did you upload to the PPA?
<dholbach> pitti: to PPA, but just re-uploaded to holba.ch/temp again
<dholbach> pitti: if you want to try, that'd be great
<pitti>     f.write(text)
<pitti> ValueError: I/O operation on closed file
<pitti> on line 76
<dholbach> ok... that's what I get for trying to do too many things at once
<pitti> yeah, that looks quite obvious :)
<dholbach> yes it does :)
<pitti> dholbach: I swapped the f.close() and f.write(), looks great now!
<dholbach> thanks a lot pitti
<dholbach> I'll upload the changes to hardy ppa and gutsy ppa in a bit :)
<mjg59> cjwatson_: Excellent
<Sevenhill> hi there
<Sevenhill> could anyone say where are kdm's Xsession files ?
<jdstrand> asac: hi!
<jdstrand> asac: do you know of any workarounds for bug #193405
<ubotu> Launchpad bug 193405 in firefox-3.0 "firefox-3.0: doesn't work as a preferred application" [Undecided,New] https://launchpad.net/bugs/193405
<Ng> jdstrand: custom application -> firefox-3.0 %s  ;)
<Ng> fwiw, I think the xml file that lists the available applications is in gnome-control-center
<jdstrand> Ng: tried that already :P
<Ng> jdstrand: works here
<jdstrand> Ng: it goes to use firefox, but firefox gives an error
<seb128> pitti: bouhouh, the retracer is still crashing
<seb128> pitti: didn't you fix the "ValueError: Unsupported attachment-type '<type 'set'>'" issue?
<emgent> jdstrand, ping
<jdstrand> emgent: pong
<emgent> jdstrand, cacti patch it'snt pubblic now
<emgent> i will try to write this
<emgent> and mail upstram, but i know that there are a rivate discussion about this vuln in cacti group
<jdstrand> emgent: if the patch isn't public, I can publish what you have if you want
<jdstrand> meaning publish the patch for the 2 vulns, and when this gets sorted out upstream, we can do the rest
<emgent> it's cool write this and mail upstram? or commit old patch and wait cactipeople ?
<jdstrand> if you would rather wait, that is fine too
<emgent> uhm
<jdstrand> emgent: it's up to you, but I'd like to use the patch that upstream ultimately uses
<emgent> jdstrand, oh ok..
<emgent> well, now is good commit old patch and i will reopen new bug for new vuln
<jdstrand> so please, get involved, write the patch and submit it upstream
<emgent> sure i will do!
<emgent> :P
<jdstrand> emgent: ok cool-- thanks! :)
<emgent> someone have docs about python-launchpad-bugs ?
<emgent> i'd like complete https://wiki.ubuntu.com/UbuntuPentest/ptreport
<emgent> jdstrand, add in todolist ehehe :P
<jdstrand> exactly
<geser> emgent: I've added support to requestsync to use p-lp-bugs based on https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Bug
<emgent> geser, big thanks
<pitti> seb128: yes, I did
<pitti> seb128: but only the 'outside' one, not in the chroots
<seb128> pitti: ah ok, will do that then
<seb128> pitti: hum
<seb128> pitti: the dup finder should be patched then?
<pitti> seb128: I can fix it, yes
<pitti> seb128: no, the outside instance *should* be fixed
<pitti> it crashed there?
<seb128> it chashed on "checking for duplicates"
<seb128> which is the system instance I think
<pitti> right
<pitti> ah, seems you are already attached to the i386 screen
<seb128> pitti: detached
<StevenK> pitti: You can share with screen -x
<pitti> seb128: I just fixed one instance of the problem, thekorn fixed all of them upstream
<pitti> oh
<pitti> no, that was the bug I wasn't able to fix
<seb128> ah ok
<pitti> yesterday I fixed another crash
<seb128> DOH
<seb128> that thing is crash land :-(
<pitti> hm
<pitti> o_O
<pitti> sure, any(empty set) must fail
 * pitti fixes
<seb128> StevenK: thanks
<pitti> seb128: apparently this bug does not have any attachment
<pitti> seb128: restarted *crossing fingers*
<pitti> seb128: https://bugs.edge.launchpad.net/python-launchpad-bugs/+bug/191963/comments/3
<ubotu> Launchpad bug 191963 in python-launchpad-bugs "ValueError: Unsupported attachment-type '<type 'set'>' " [Undecided,In progress]
<seb128> pitti: thanks
<jwendell> seb128, GNOME 2.22 will ship GDM 2.20 :)
<jwendell> hehe
<seb128> jwendell: yeah, I know, we didn't update ;-)
<jwendell> seb128, you knew it hehe
<jwendell> deja vu
<seb128> jwendell: do you still read the tsclient bugs on launchpad?
<seb128> jwendell: there is an user who reopened the warning on disconnect one you closed upstream
<jwendell> seb128, yep, but some guy has asked for its maintence
<\sh> seb128: known to you that somehow "network" places doesn't work?
<seb128> \sh: yes
<pitti> wow, most new python crash reports are duplicates
<jwendell> seb128, tsclient needs more love, I can't supply it because I'm giving my love to vinagre
<jwendell> seb128, I hope to support rdp in vinagre soon
<Colossus73> hi
<Colossus73>  according to what I read here:http://www.gimp.org/release-notes/gimp-2.4.html the print option should be in the file menu and leading to a window allowing print preview and print WITHOUT gutenprint
<tickler> hallo
<ogra_cmpc> jwendell, the ltsp crowd would love you for that
<Colossus73> but the print option is not in file menu of the gimp ubuntu package
<Colossus73> how come?
<jwendell> ogra_cmpc, :)
<tickler> how you get acer orbi cam working on ubuntu
<tickler> it uses bison drivers
<Colossus73> does nobody know why?
<tickler> my wireless works fine after i patched madwifi
<StevenK> Colossus73: It is in the File menu if you right click an open image
<Colossus73> there is no print option in the file menu of the image
<Colossus73> I tried it
<Colossus73> StevenK: which package do you have of gimp?
<StevenK> I just tried it and it worked
<Colossus73> StevenK: can you tell me the version and the package please?
<StevenK> Colossus73: 2.4.2-0ubuntu0.7.10.1
 * Colossus73 checking
<StevenK> Colossus73: Do you have gimp-print installed?
<Colossus73> ok i understand what you mean
<Colossus73> StevenK: I DON'T mean Gutenprint
<Colossus73> StevenK: please go here:http://www.gimp.org/release-notes/gimp-2.4.html
<Colossus73> and look for improved printing
<StevenK> Right, okay, you're talking the native plug-in
<Colossus73> you will see that the print window is not the one of gutenprint
<Colossus73> so where is the native plug-in?
<Colossus73> there is even a print preview!
<StevenK> Not enabled in Gutsy, it wasn't suitable to enable when Gimp was updated.
<Colossus73> ah ok
<StevenK> Since it was about two weeks before Gutsy's release.
<Colossus73> thanks for the explanation
<Colossus73> :)
<StevenK> Colossus73: No problem, happy to help.
<Colossus73> StevenK: will be ok for Hardy then?
<jwendell> seb128, ogra_cmpc when it happens, we can replace tsclient :)
<StevenK> Colossus73: It was enabled for Hardy. By me, actually. :-)
<Colossus73> good !
<Colossus73> Thank you!
<StevenK> Colossus73: No problem
<Colossus73> do you think I can download the gimp hardy package on gutsy?
<ogra_cmpc> jwendell, well, i was pondering that for edubuntu for this release already ...
<seb128> jwendell: cool
<Colossus73> StevenK: I mean installing the gimp hard package on gutsy?
<ogra_cmpc> Colossus73, you can grab the source package and try to build it in gutsy
<jwendell> ogra_cmpc, the problem is rdp support
<StevenK> It wouldn't work.
<ogra_cmpc> jwendell, pfft, windows
<Colossus73> ok, waiting for Hardy then.
<StevenK> It requires changes to gutenprint to not provide the plugin
<Colossus73> StevenK: thank you so much, bye.
<StevenK> Colossus73: No problem
 * ogra_cmpc wonders why evolution exchange has to run all the time after he once started an app using e-d-s
 * ogra_cmpc uninstalld
<warrend> hi
<warrend> is it normal that since that gutsy is out gdebi-kde doesn't work?
<Riddell> warrend: no
<warrend> it would be nice to fix the bug :)
<ogra_cmpc> seb128, whats the reason for the above ? seems e-d-s properly stops if i close the app ("dates" in this case) evo-xchange doesnt and hogs 8M
<warrend> a friend said kubuntu wasn't able to install debs
<warrend> i found this bug on launchpad but it doesn't move :)
<seb128> ogra_cmpc: bug?
<seb128> ogra_cmpc: or lack of feature
<Riddell> warrend: what's the bug
<ogra_cmpc> seb128, so its supposed to stop ?
<warrend> https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/156031
<ubotu> Launchpad bug 156031 in gdebi "Kubuntu - GDebi fails to install .deb package" [Undecided,New]
<mvo_> warrend: it seems to be working for me
<warrend> really?
<warrend> with kubuntu?
<mvo_> warrend: hardy, gdebi 0.3.5 (latest bzr version, but the kde bits didn't change compared to the released version)
<warrend> ow but i use gutsy
<mvo_> warrend: oh, sorry
<warrend> but i've read the bug still exists on hardy too
<ogra_cmpc> seb128, i mean, its rather thyeoretical anyway ... i dont assume if people have to used dates as their calendar app they even would have evo-xchange installed ... but on the classmate 8M RAM are quite a lot :)
<ogra_cmpc> s/used/use/
<Riddell> warrend: works for me
<warrend> on gutsy?
<Riddell> warrend: what version of kde do you have?
<warrend> 3.5.8
<Riddell> no on hardy
<warrend> i don't use hardy, yet
<Riddell> warrend: kde is installed from where?
<seb128> ogra_cmpc: there is a bug about "evolution-exchange should not be started if the plugins is not activated
<warrend> from ubuntu's official repos
<ogra_cmpc> seb128, well, i would like it to stop if nothing uses it anymore ... thats a bit different
<warrend> it looks like a problem with encoding
<seb128> ogra_cmpc: it should, that's a bug
<Riddell> warrend: what error does it give when you run gdebi-kde on the command line?
<ogra_cmpc> seb128, i'll file it if i'm back on my workstation ... i guess upstream is better here, right ?
<warrend> euh i am not at home but i can't remember the error
<warrend> but it is the same as on launchpad
<warrend> but gdebi-kde launchs and when you want to install a package it crashes
<warrend> silently
<asac> pitti: are the retracers running? (bug 193247)
<ubotu> Launchpad bug 193247 in firefox-3.0 "firefox crashed with SIGSEGV in __kernel_vsyscall()" [Undecided,New] https://launchpad.net/bugs/193247
<seb128> ogra_cmpc: yes
<ogra_cmpc> oki
<warrend> when i will be on my pc i will come back with the error
<seb128> dholbach, pitti: is the python-launchpad-bugs api documented somewhere?
<dholbach> seb128: best to ask bdmurray and thekorn - in a call right now
<seb128> ok
<geser> seb128: there is an example how to work on bugs with p-lp-bugs in the wiki: https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/Bug
<dholbach> pydoc launchpadbugs  has some holes in it but is much better than it was
<dholbach> I usually copy and paste stuff I've used before ;)
<pitti> asac: yes, again; they crashed earlier
<pitti> seb128: I don't know either; maybe still in the GSoC wiki docs
<seb128> dholbach, geser, pitti: I was wondering if there is some function returning the packages maintained by a team but that doesn't seem to be the case
<asac> pitti: ok thanks.
<dholbach> seb128: no, unfortunately not afaik
<seb128> ok
<pitti> seb128: it's primarily focused on bugs still
<dholbach> maybe there's a hidden   team/+rdf-bugs    something *shrug*
<dholbach> might be a good idea to ask in #launchpad
<emgent> heya
<slytherin> any core developer from bluetooth team here?
<dholbach> slytherin: #ubuntu-mobile might be a good idea
<pitti> lool: any idea why elisa doesn't work at all on hardy? the process is running, but it doesn't produce any window
<lool> pitti: I have no idea, but as a lot of opengl hackery is involved, I would suggest checking with metacity if you're running compiz
<pitti> lool: I am running metacity
<pitti> lool: Scott just tried on compiz, and there it just kills all windows
<lool> haha
<pitti> on my box it just sits there
<USN1520> I fully understand this is not the place for newbs to discuss development, however
<lool> I didn't try it under hardy at all yet; it worked fine on sid though
<USN1520> I love ubuntu and want to help
<pitti> lool: so that's not just the standard pygtk app, I figure :)
<lool> pitti: Oh you might have to wipe your config
<USN1520> how do I get started
<pitti> lool: which config?
<lool> pitti: ~/.elisa
<azeem> USN1520: see the /topic
<pitti> lool: I didn't have an ~/.elisa before
<lool> pitti: Ah
<pitti> lool: today was the first time ever I tried it
<lool> pitti: I'm out of the idea, but a new upstream is pending
<pitti> lool: ok, thanks; just thought I'd check with you :)
<USN1520> thanks
<lool> pitti: Thanks for telling me it's broken, I'll test the new upstream (which upstream wants into hardy) under hardy asap
<pitti> USN1528: https://wiki.ubuntu.com/ContributeToUbuntu has some useful entry points
<pitti> oh, gone already
<pitti> lool: thanks
<pitti> lool: I prepared some dependency fixes in Ubuntu which also apply to Debian; I think I'll just report them to the BTS then, maybe we can even avoid a fork
<lool> pitti: With pleasure
<dholbach> UBUNTU DEVELOPER WEEK Session starting in #ubuntu-classroom in 15 minutes!
<crevette> hello dholbach
<dholbach> hey crevette
<crevette> I would like to propose obex-data-server to be included in main; from https://wiki.ubuntu.com/MainInclusionProcess I need to ask here beofre do the MIR
<crevette> doing
<slytherin> dholbach: ^^
<dholbach> slytherin: better ask the guys in #ubuntu-mobile - I'm not taking care of any bluetooth related packages any more - they took over
<slytherin> dholbach: I am not doing MIR, I just directed him to the wiki page. But yes I have interest in that MIR. I suppose there should be a generic discussion in devel lists or channel right?
<dholbach> slytherin: I haven't filed a MIR in a while, maybe somebody else knows better?
<dholbach> MainInclusionRequiremens on the wiki should know
<dholbach> or UbuntuMainInclusionQueue
<slytherin> Ok. crevette: be patient then. SOmeone here will answer sooner or later. :-)
<dholbach> sorry :)
<slytherin> crevette: Or you can also send mail to ubuntu-devel-discuss list
<pitti> lool: bug+patch sent
<lool> pitti: Thanks!
<slytherin> pitti: Can you help crevette? He plans to file MIR for obex-data-server. He wants to discuss it here first (as per the process).
<crevette> slytherin:
<crevette> slytherin: okay
<pitti> crevette: o-d-s sounds pretty reasonable, so please go ahead
<crevette> hello pitti
<pitti> crevette: I just want to point out that it's subject to Feature Freeze and thus needs an exception
<crevette> I'll do that tonight
<crevette> pitti: yeah, I understand; o-d-s 0.1 release came few days before FF
<slytherin> pitti: Just for the record ... It is required for the file transfer functionality of latest bluez-gnome.
<lool> pitti: From upstream:
<lool> 17:04 < philn> yes it's a known bug wrt a deadlock in xcb
<lool> 17:04 < philn> in svn of pigment we have a workaround to avoid it
<pitti> lool: good to know!
<davmor2> pitti: Should Jockey install ndis or is it a todo?
<pitti> davmor2: neither nor ATM
<pitti> davmor2: if you have some recipes how to do some useful things with it, I'm all ears :)
<keescook> pitti: hello!  yeah, hal irc seems to be an idling contest.
<seb128> carlos, pitti: do you know if not having locales like "en_US" is a bug or what is expected? we have en_US.UTF-8 but not en_US and similar with other locales
<pitti> seb128: it's expected, we only support UTF-8 locales
<carlos> pitti: isn't en_US supposed to be an alias of en_US.UTF-8 ?
<davmor2> pitti: No development skills sorry :( I just test Riddell wasn't entirely sure if ndis should be detect and installed or not and recommended asking you :)
<seb128> carlos: that's sort of my question
<seb128> the setlocale() manpage says it should work with en_US
<pitti> davmor2: not necessary; writing down the steps for making a particular piece of hw work is enough (like, install this package, configure that file like this, etc.)
<seb128> but it returns NULL on ubuntu
<slytherin> davmor2: which cards still need ndis?
<pitti> grep 'en_US\>' /usr/share/i18n/SUPPORTED
<pitti> en_US ISO-8859-1
<pitti> seb128: ^
<seb128> hum, k
<pitti> so I think it's correct for our purposes
<seb128> pitti: the issue is that gdm calls setlocale() on the values it gets from LANGUAGE
<seb128> using LANGUAGE is likely wrong there
<pitti> of course you can always manually create it, but we don't support it
<seb128> but I'm discussing with upstream
<pitti> right, it is
<pitti> it probably wants setlocale(LC_ALL, "")?
<pitti> keescook: your patch is in hardy, btw
<davmor2> slytherin: broadcom bcm4328 series
<pitti> davmor2: uh, that doesn't work with b43 or at least bcm43xx?
<Longfield> hello there ... I have a question about the opensync packages: why are they still with the 0.19 version, even for Hardy, although the development is already at 0.36 and the 0.22 version is considered stable ?
<davmor2> pitti: not detected I just followed the info off the wiki
<seb128> pitti: could be, they had setlocale (LC_CTYPE, NULL) and changed for whatever reason, anyway I'll sort that, thanks for the reply, I was not sure if en_US was supposed to be an alias to the utf8 locale or not
<slytherin> davmor2: Are they not supported by new b43 drivers? I myself haven't looked the 'supported cards list', so please provide some more info.
<davmor2> slytherin: pitti: I will gladly provide you with what ever info you need if you let me know how/where to get it
<davmor2> need to reboot be right back
 * slytherin wonders why people keep buying broadcom wireless hardware. :-(
<davmor2> slytherin: What info do you need?
<slytherin> davmor2: Can you paste output of dmesg somewhere?
<davmor2> slytherin: yes hang on
<davmor2> slytherin: for lspci -vvnn go here http://launchpadlibrarian.net/11798811/lspci.txt  and for dmesg goto http://www.davmor2.pwp.blueyonder.co.uk/dmesg.txt
<davmor2> hang on I get an error with the dmesg one
<davmor2> slytherin: that's fixed it it had wrong permissions
<davmor2> same link
<davmor2> slytherin: currently testing Kubuntu on the machine
<slytherin> davmor2: I don't see even a mention of broadcom in dmesg output
<davmor2> slytherin: that's what I'm saying it isn't detected at all until I use ndisgtk/wrapper in order to enable it
<davmor2> slytherin: then it works flawlessly
<warrend> hi
<warrend> can someone say if flashplugin works again with kde 3.5.9 ?
<slytherin> davmor2: Ok. I have to leave now. You better bug pitti about this since he is developer. Make sure you document the steps to make the card work and contact him.
<Riddell> warrend: yes.  #kubuntu for user support
<davmor2> slytherin: ta
<warrend> ok
<warrend> btw thanks :)
<davmor2> pitti: any ideas?  the card is listed under the lspci.txt file.  Normally I just use ndisgtk and the drivers I got off the forums to make my wifi card work.
<pitti> davmor2: do you see it in lspci?
<pitti> davmor2: if yes, then it's possible to make it work with jockey
<pitti> davmor2: please open a bug, paste your lspci output, and describe the steps to configure the card for you
<pitti> ArneGoetje: I fixed langpack-o-matic to generate correct changelogs for updating already existing language-support-* packages, and now it doesn't update them any more if nothing changed
<pitti> ArneGoetje: so following the procedure in operator-guide.txt works now
<keescook> pitti: thanks for adding it.  :)  virt-manager will work for me now.  :)
 * \sh wonders who sits at canonical hq and toture his brain and comes up with names like "Intrepid Ibex" 
<davmor2> pitti: np's
<pitti> davmor2: cool, thanks
<ArneGoetje> pitti: ok, thanks a lot
<pitti> carlos: how come that the gutsy 20080208 update tarball is so incredibly big? we had a full export on 20080205
<pitti> ArneGoetje: that is, if my bzr push ever finishes (will happen eventually)
<ArneGoetje> pitti: I will check it out tomorrow
<carlos> pitti: that's a mix of the number of new package updates uploaded into Ubuntu's archive and the new feature we introduced to invalidate cache with each template update
<pitti> carlos: but in three days, gutsy can hardly accumulate 200 MB worth of new translations?
<pitti> carlos: with update packages that big we don't actually need them any more...
<carlos> pitti: yeah, but template updates mean that all translations are exported again
<pitti> carlos: ok, but even if that is justified, the templates in gutsy don't change
<pitti> (why does it need to happen, though? that sounds inefficient)
<carlos> pitti: with the optimisation I told you about last month, it shouldn't grow so much
<carlos> pitti: agreed, the problem is that we need to add an extra optimisation
<carlos> to invalidate the cache only when new messages are added/removed
<pitti> carlos: what's the rationale for invalidating the .pos in the first place?
<pitti> adding new strings to the template doesn't need to change them
<pitti> and for removing a string the overhead of duplicating the .po/.mo is much bigger than just keeping the now unused string
<carlos> pitti: old templates that are only updated in later versions
<asac> Riddell: gnash folks told me that qt has fixed some licensing issue for gnash recently (for both qt3 and qt4) ... can you confirm that there was a licensing change?
<carlos> that produces that old .po version miss some translations
<carlos> once the template is fixed and the new version appear
<carlos> the new added strings will be exported too
<carlos> removed strings would be ignored too, given that they only cause waste space
<pitti> (and waste much less than having two copies)
<carlos> so that's something else to consider to optimise it even more
<carlos> pitti: indeed
<pitti> carlos: can this be disabled until it is fixed properly?
<pitti> i. e. only include a new .po if the .po itself changed, not the template?
<carlos> pitti: is more easy to fix it properly, I will discuss with jtv and kiko whether we could get it fixed with a cherry pick
<pitti> so that we can continue to build daily updates to stables, and put them into the archive as well?
<carlos> pitti: this shouldn't affect stable releases
<pitti> carlos: ah, ok; it sounded pretyt complex :)
<carlos> only development ones
<pitti> carlos: well, I'm talking about gutsy
<carlos> is gutsy big again?
<carlos> I was talking about Hardy...
<pitti> carlos: http://launchpadlibrarian.net/11847269/ubuntu-gutsy-translations-update.tar.gz (20080208) -> 293 MB
<pitti> carlos: with 20080205 (three days earlier) being a full export
<carlos> pitti: oh, that!
<carlos> that's just that 20080205 is not yet on -updates
<carlos> so I didn't set it as the base one to get updates from...
<carlos> you told me that next Monday it should move into -updates, right?
<pitti> carlos: hm, 20080205 is shown as 'full export being tested'
<pitti> right
<carlos> right, but is not yet the base package in Gutsy
<pitti> well, it is in -proposed
<pitti> so it'll be small again once it moves to -updates?
<carlos> is not hte way the system works, if you have a use case to do it in that other way, I'm happy to discuss such change
<pitti> if it's meant to work that way, I'll shut up
<carlos> pitti: yes
<pitti> I was just a bit concerned and thought that there was something wrong
<carlos> pitti: it's designed in that way, but I'm open to improvements, you are the main user of that feature, so it should work as you need it to work...
<pitti> carlos: I don't particularly mind, I disable the daily updates while we test -proposed
<carlos> ok
<pitti> but for clarity and for internal testing it might be more useful to produce small ones right after doing a full export
<pitti> either the full export is good, then we'll use it
<pitti> or it is bad, and then we'll need a new one anywa
<pitti> y
<pitti> carlos: at least I'm relieved; thanks for the heads-up!
<carlos> np
 * pitti hugs soren for the kvm upload
<carlos> pitti: however, in Hardy, is actually a problem, should I push for a fix as soon as possible or could you wait for next month's release?
<soren> pitti: Oh, I was just about to tell you :)
<pitti> carlos: I think we can wait
<carlos> pitti: ok, thanks
<pitti> carlos: given the size of current update packages we should put new -base packages into hardy soon anyway
<cjwatson> \sh: release names? let's just say his name begins with M
<carlos> ok
<LaserJock> and ends with an ark
<LaserJock> I'm pretty sure this must be some passive-aggressive way to get us to use release numbers more instead of code names ;-)
<LaserJock> I like the name but I just know I'm gonna slaughter it in some important changelog or doc
<Keybuk> \sh: it takes a lot of effort to come up with something that's not "Itchy Iguana" ;)
<\sh> Keybuk: hehehe...I think a good whisky helps too
 * \sh 's rushing home
<Keybuk> pitti: an fsck idea occurs
<Keybuk> there's no particular reason that we have to force it on mount count in the disk options
<Keybuk> we could just expose the "last checked" attribute through HAL, and if it's been a particularly long time, notify the user graphically (or by e-mail on server) that a check could be a good idea
<Keybuk> and offer them a chance to decide when to schedule it
<ogra_cmpc> sounds great
<Keybuk> "Your filesystem has not been checked in six months, we recommend periodic checks to detect disk errors early and avoid data loss.
<Keybuk>  Would you like to schedule a check?
<Keybuk>  (o) no
<Keybuk>  ( ) yes, when I next restart
<Keybuk>  ( ) yes, in [ ] hours
<Keybuk> type thing
<ogra_cmpc> how would you technically do the last ?
<ogra_cmpc> force a reboot ?
<Keybuk> ogra_cmpc: shutdown to single user mode, or force a reboot
<ogra_cmpc> remount the disk
<ogra_cmpc> ah
<mathiaz> seb128: how did you setup the desktop-bugs mailing list ?
<seb128> mathiaz: we asked IS if we could get a list, why?
<mathiaz> seb128: right - I've done that step.
<Keybuk> arguably we should have a little notification icon pop up if some other admin does "shutdown -r +60" anyway
<carlos> cjwatson: Hi, I did a debian-installer update for Hardy today based on what you have in people.ubuntu.com
<davmor2> pitti: bug 193731  having issues with the driver files though
<ubotu> Launchpad bug 193731 in jockey "Broadcom bcm 4328 install details for hp pavillion dv9657em laptop" [Undecided,New] https://launchpad.net/bugs/193731
<hunger> that aptitude keeps crashing is really annoying:-(
<davmor2> pitti: is there anything else other than the drivers that you need?
<Keybuk> cjwatson: d-i doesn't love me
<carlos> pitti: should I accept translations for https://edge.launchpad.net/ubuntu/hardy/+source/x264/1:0.svn20071224-0.0ubuntu1 ?
<carlos> pitti: it's in multiverse
<slangasek> somerville32, mr_pouit: you're aware that xubuntu dailies are oversized?
<pitti> Keybuk: you can also trigger it after a regular time interval AFAIR
<pitti> Keybuk: 'tune2fs -i 1m' or so
<pitti> Keybuk: but it doesn't change the overall situation?
<carlos> seb128: hi, is gnome-settings-daemon a new package split from gnome-control-center ?
<seb128> carlos: hey, yes
<seb128> why?
<carlos> I'm approving new .pot files that are still waiting for hardy
<ogra_cmpc> pitti, dropping the bootcount would improve it a lot
<seb128> ah ok
<seb128> thanks
<seb128> anyway I was just going for dinner, see you later
<carlos> and saw things like gnome-vfs2 being rename to gnome-vfs
<carlos> too late ;-)
<Keybuk> pitti: why wouldn't it change it?
<Riddell> asac: yes, qt is now GPL (2 and) 3
<pitti> ogra_cmpc: you can interrupt it now
<pitti> good night
<ogra_cmpc> night
<ogra_cmpc> oh, i didnt know that
<MacSlow> Keybuk, btw... I will have to skip exposing shortcuts for compiz-plugins zoom or ezoom as they are usually only bound to a mouse-button plus modifier... and I don't want to start parsing the values I get form gconf or libcompizconfig
<MacSlow> Keybuk, and instead of having a binding like "<Super>Button3" be exposed as "Super+" I'd rather not show it at all
<mvo> does "Fetching and installing the upgrade can take several hours and cannot be canceled after the download is finished." sound ok or can it be improved (context is the release upgrader)
<mjg59> I'd make it two sentences
<mjg59> "Fetching and installing the upgrade can take several hours. Once the download has finished, the process cannot be cancelled"
<mvo> thanks, that sounds better
 * mvo updates
<crimsun_> davmor2: regarding your query, there does not seem to be a suitable level that's consistent for "most" codecs
<crimsun_> davmor2: at least three different AC'97- and HDA-based ones will react differently: some Analog Devices ones driving the former will distort horribly above %80, others be barely audible, etc.  The situation only becomes more muddy when one considers the inconsistency also appears across Realteks, Vias, ...
<slangasek> stgraber: the edubuntu 'product' on iso.qa.ubuntu.com needs to be adjusted for alpha-5, the server CDs have been reduced to a single 'addon' CD named 'hardy-addon-$arch'
<stgraber> slangasek: I don't think I'll have a code/SQL update ready soon enough for Alpha-5 but that'll be fixed for Alpha-6 (I also need to move the LTSP testcase from Edubuntu server to Ubuntu alternate)
<slangasek> stgraber: ok; is there a good way to collect feedback on edubuntu addon out-of-band, then?
<slangasek> if not, we can forego it since the add-on CD isn't installable at all
<stgraber> slangasek: I'll test it myself (Install Ubuntu Alternate with LTSP (extra boot parameter) and try the Add-on)
<slangasek> ok
<slangasek> thanks :)
<slangasek> stgraber: otherwise, alternate CDs are up for testing now
<stgraber> slangasek: thanks, I'll ping people in #ubuntu-testing
<TheMuso> slangasek: How long till live CDs are likely to land?
<slangasek> TheMuso: the first of them should land within the hour, I think
<TheMuso> slangasek: Great, thank.
<TheMuso> thanks
<davmor2> crimsun_: Right okay.  Thanks for letting me know.
<cjwatson> carlos: cool, thanks
<cjwatson> Keybuk: d-i> -v
<Keybuk> cjwatson: was having a really hard time persuading it to resize an NTFS filesystem
<Keybuk> it didn't help that it appears to be almost impossible to run chkdsk in vista
<cjwatson> Keybuk: odd, hardy? should be fairly ok now
<cjwatson> I haven't tried it in a bit though
<Keybuk> it worked after about the third attempt
<Keybuk> I had to boot windows in safe mode
<Keybuk> run chkdsk /f
<Keybuk> agree it to it doing it on reboot
<Keybuk> reboot
<Keybuk> and then boot windows again
<Keybuk> and then shutdown
<cjwatson> ntfsresize is a bit picky
<cjwatson> file a bug, we can have a look and see if that can be smoothed out
 * cjwatson &
<Nafallo> Keybuk: you may :-)
<Nafallo> Keybuk: 5 min late, but anyway ;-)
<jablko> am having some trouble maintaining a mixed gutsy / hardy system
<jablko> i added all the gutsy / hardy repositories to my sources.list
<jablko> but only want to get updates from gutsy
<jablko> however apt wants to upgrade all the packages to hardy
<jablko> is maintaining a gutsy / hardy mixed system documented anywhere?
<ScottK> No.
<ScottK> If it works it's only by luck.
<ScottK> Support is in #ubuntu for Gutsy and #ubuntu+1 for Hardy.
<jablko> ScottK: ok, thanks
<seb128> slangasek: do you remember the webpage you pointed me about LANGUAGE the other day?
<slangasek> seb128: I think I only pointed you as far as locale(7); someone else had the webpage, I think?
<seb128> might be
<seb128> I replied that the manpage has no information about LANGUAGE
<seb128> and somebody came with a webpage
<torkel> seb128: http://www.gnu.org/software/libc/manual/html_node/Locale-Categories.html#Locale-Categories
<seb128> torkel: thanks
<seb128> ok
<seb128> so we set LANGUAGE incorrectly
<seb128> it's supposed to be a list of valid locales
<slangasek> hmm, I think that's a retcon then
<seb128> torkel: not sure if that was the one I read the other day though, anyway it's clear
<seb128> "the LANGUAGE variable's value can consist of a colon separated list of locale names"
<seb128> on http://www.gnu.org/software/libc/manual/html_node/Using-gettextized-software.html#Using-gettextized-software
<seb128> <halfline> seb128, i don't think that's right
<seb128>  seb128, i checked with uli
<seb128>  seb128, he said  LANGUAGE and LC_* take the same format
<seb128>  
<seb128> that's confirmed by the libc upstreams apparently
<slangasek> seb128: that page accurately documents why the values passed to LANGUAGE is *not* supposed to be a list of locales
<slangasek> it's supposed to be a list of subdirs to use for message catalogs, which are almost always not valid locales!
<slangasek> "If now the user set in her/his environment the variable LANGUAGE to de the gettext function will try to use the translations from the file     /usr/local/share/locale/de/LC_MESSAGES/test-package.mo
<slangasek> "
<torkel> seb128: that was the one I pasted to you on the 11th
<seb128> torkel: ok, that was likely this one then, thanks ;-)
<torkel> :-)
<seb128> slangasek: "de" is a valid locale
<slangasek> $ LANG=es ls moo
<slangasek> ls: cannot access moo: No such file or directory
<slangasek> $ LANGUAGE=es ls moo
<slangasek> ls: no se puede acceder a moo: No existe el fichero Ã³ directorio
<slangasek> seb128: ^^
<seb128> slangasek: that's because we don't install non-UTF8 locales
<seb128> hum
<slangasek> er, the point is that LANGUAGE=es is not being resolved as a locale, and isn't meant to
<soren> Ã³?
<soren> Not "u"?
 * soren 's Spanish must be rusty.
<slangasek> soren: it should be "o"; something's goofy with the Spanish translation that we're shipping, and I keep forgetting to file a bug about it
<soren> It turns into "u" after a word that ends with "o" doesn't it?
<seb128> slangasek: do you have a translation for ls in /usr/share/locale/es?
<slangasek> soren: before a word that begins with "o"
<soren> Ah.
<slangasek> seb128: /usr/share/locale-langpack/es/LC_MESSAGES/libc.mo
<seb128> k, don't have this one
<seb128> do you have a local build? ;-)
<slangasek> no, I just have language-pack-es installed
<seb128> ah, right
<seb128> anyway I pointed it to halfline who asks uli
<seb128> I think uli is Ulrich Drepper
<seb128> who said that LANGUAGE and LC_* are supposed to use the same format ;-)
<slangasek> seb128: I haven't tested, but I expect that installing the es_ES.ISO8859-1 locale will still give you the same results with LANG=es, because "es" is /not/ a well-formed locale name; all locales are ll_CC[.enc][@dongle]
<slangasek> seb128: the syntax of LANGUAGE was defined for GNU well before Uli was involved, he's not welcome to change it now :-P
<seb128> ;-)
<cjwatson> seb128: 'info gettext' has a much more sensible definition of LANGUAGE
<cjwatson> among other things, it says:
<cjwatson>    In the `LANGUAGE' environment variable, but not in the other
<cjwatson> environment variables, `LL_CC' combinations can be abbreviated as `LL'
<cjwatson> to denote the language's main dialect.  For example, `de' is equivalent
<cjwatson> to `de_DE' (German as spoken in Germany), and `pt' to `pt_PT'
<cjwatson> (Portuguese as spoken in Portugal) in this context.
<cjwatson> I trust gettext upstream over libc upstream when it comes to this kind of thing
<cjwatson> perhaps Ulrich is just speaking loosely and being overly strictly interpreted
<seb128> cjwatson: thanks
<seb128> right
<seb128> I think I got the other redhat guys agreeing with me, they will ping Ulrich against asking for precisions
* herb changed the topic of #ubuntu-devel to: Launchpad is going down from 00:00 UTC until 03:00 for a code update. | Archive: Feature freeze, Alpha 5 freeze | 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/HelpingWi
<pipegeek> Hmm.  Something just changed... when I try to import certain python modules now, I get "RuntimeWarning: Python C API version mismatch for module <module name>"
<pipegeek> including modules that end up getting imported when python tries to print an error.
<pipegeek> Did the python2.5 package just change?
<ScottK> pipegeek: #ubuntu+1 for support if you are running Hardy.
<pipegeek> Hmm.  I wonder what broke.
<pipegeek> Because I'm not.
<pipegeek> All relevant packages are from gutsy.
<ScottK> Then #ubuntu for support
<pipegeek> and if I (very vaguely) suspect a broken package?
<pipegeek> well, off I go.
#ubuntu-devel 2008-02-21
<Hobbsee> intrepid ibex, hey?
<infinity> Yeah, my suggestion of Incontinent Imbecile was rejected.
<StevenK> Hah
<Hobbsee> HAHA
<Hobbsee> oops, caps
 * lamont kicks /etc/event.d.
<lamont> how do I get the system to reconize changes there?
<lamont> short of reboot, that is
<Chipzz> ScottK: errr, yes it (maintaining a mixed system) IS documented; it's called pinning and is documented in man apt_preferences
<ion_> FSVO documented
<Chipzz> although I should poorly documented :P
<Chipzz> ion_: ;)
<ScottK> Not supported though
<Chipzz> ion_: I found that manpage to be really confusing ;)
<Chipzz> ScottK: yeah but the guy was asking about documentation ;)
<Chipzz> s/confusing/complex and lacking examples/
<ScottK> K.  I took it more as I did this really odd thing to my system, I want to do something odder, and want it to work.  Please help.
<Chipzz> question of interpretation I guess ;)
* herb changed the topic of #ubuntu-devel to: Archive: Feature freeze, Alpha 5 freeze | 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
<Chipzz> the one thing I did try to achieve with apt/preferences, I failed at :P
<Chipzz> which was trying to convince apt that packages recompiled locally and installed with dpkg -i should take precedence
<Chipzz> but then, I don't even know if that's possible (or if apt/preferences is the right way to do that)
<superm1> slangasek, still going to have time to look over the changes to cdimage with me?
<choudesh_> Anyone around?
<Hobbsee> no
<choudesh> heh. ;-)
<choudesh> Is the 8.04 kernel compiled with the HIGHMEM flag?
<emgent> heya Hobbsee :)
<Hobbsee> hey emgent!
<_MMA_> choudesh: I believe it is for 32-bit.
<slangasek> superm1: is there a branch I can look at?  I think I can squeeze in looking at the changes, but only asynchronously
<superm1> slangasek, yeah there is.
<superm1> slangasek, let me get you a url
<superm1> http://bazaar.launchpad.net/~mythbuntu/ubuntu-cdimage/mythbuntu-cdimage/
<slangasek> superm1: thanks, pulling for later
<superm1> slangasek, thanks.  let me know if you have any questions or concerns.  i'll be up for 1-2 more hours, otherwise i'll answer in the morning
<slangasek> yah, I don't think I'll get to it until tomorrow anyway, I'm a bit sleep-deprived ATM
<pitti> Good morning
<warp10> Hi all!
<tjaalton> pitti, slangasek: the latest xorg-server upload is not built yet?
<tjaalton> -intel needs that
<pitti> tjaalton: built everywhere
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<tjaalton> pitti: but not published? -1ubuntu4 is the one
<slangasek> tjaalton: published too.  there've been some mirror pulse issues, I know; perhaps your local mirror is lagged as a result of that
<tjaalton> slangasek: ah ok, I'm using archive.u.c ;)
<pitti> tjaalton: ah, just wanted to say the same
<tjaalton> slangasek: I uploaded a new -intel which build-deps on the latest xserver-xorg-dev, and drops the patch which forces XAA on !965
<slangasek> tjaalton: perhaps archive.u.c is lagged as a result of that ;-P
<tjaalton> hope it's ok..
<tjaalton> we discussed these with bryce
<slangasek> tjaalton: is that a new new -intel, or the new -intel that I know about already from talking to bryce ~24h ago?
<bryce> same -intel
<slangasek> ok
<slangasek> that one's built & published, but perhaps not published as far as we'd like
<tjaalton> slangasek: it's the same, but with the latest patch disabled since it turns out that compiz has issues with XAA&Xv at least on some i9xx in addition to 965
<tjaalton> it's published, but doesn't do what we'd like it to do :)
<tjaalton> ie. force greedy EXA
<bryce> yeah users are reporting that our fix for 965 also works great on other intel chips
<slangasek> so what you're saying is that you want a -2ubuntu7?
<tjaalton> exactly
<slangasek> the current behavior isn't a regression, right?
<bryce> it's not a regression from gutsy (we had been running XAA there)
<slangasek> so no urgent reason to try to squeeze it into alpha5..?
<bryce> but for alpha3 and 4 we'd turned EXA on for everyone, which we assumed worked no differently than XAA
<tjaalton> exa has been there since 2.2.0 was uploaded..
<slangasek> ah
<bryce> however users are saying they had been finding EXA fixed things for them, they just hadn't really told us until this patch to put them back to XAA went in
<slangasek> heh. :)  ok, go ahead and upload 7 and I'll try to see that it gets squeezed onto the ISOs
<Fujitsu> Is XAA actually meant to work with Xv? It never has for me.
<bryce> ok cool
<bryce> Fujitsu: I only knew that it didn't work with 965.
<bryce> (but then, on my 945 where I play video regularly, compiz had been crashing left and right anyway)
<tjaalton> slangasek: already did, I assumed that you'd put it on hold if not acceptable for a5 :)
<Pete_B> can anyone please tell me the dependencies of the lamp-server virtual package? (I'm not running Ubuntu so can't check myself)
<sladen> peter_b:  http://packages.ubuntu.com/hardy/lamp-server  except that doesn't return any results, did it get renamed?
<sladen> pete_b: grep -A8 lamp-server /usr/share/tasksel/ubuntu-tasks.desc
<pitti> infinity: gcc-3.3 upload> ... but it already was in universe before?
<\sh> asac: ff3 + flash + usb headset (in this case a sennheiser) doesn't work...I wonder if it's a regression of gnome/ff3+flash or something else
<soren> pitti: Now that the gcc issue is taken care of in kvm, everything is fine, right?
<pitti> soren: yes, it is; I'll get to review/promoting it soon
<soren> pitti: Cool. Thanks.
<soren> Just wanted to make sure it wasn't blocking on me somehow.
<davmor2> Do we have stable images across the board now, for testing purposes?
<mvo> hey sladen! will you be at fosdem?
<sladen> mvo: a bit late if I do turn up.  Ferry to Rostock left 22:00 last night and I was too busy watching the fresh snow to watch it
<sladen> s/watch/catch the ferry/
<mvo> sladen: heh :) ok
<slytherin> Does a MIR bug need to be marked confirmed?
<sladen> silly Deutsch Bahn site is suggesting I go via St. Petersburg.  meh germany technology.
<seb128> do we have anybody looking to fuse in ubuntu?
<davmor2> sladen: it's a long bike ride any way you look at it ;)
<seb128> looks like the rmdir behaviour on ntfs fuse mounts is not correct
<seb128> I would like to know if that's a known issue
<pitti> seb128: you mean ntfs-3g or fuse proper?
<seb128> pitti: no idea, whatever we use to mount ntfs partitions
<seb128> ntfs-3g likely
<seb128> rmdir gives a  = -1 EEXIST (File exists)
<seb128> instead of a = -1 ENOTEMPTY (Directory not empty)
<seb128> when used on a non empty directory
<seb128> that breaks gvfs
<slytherin> And I thought only I was having this problem
<seb128> slytherin: ?
<slytherin> ntfs-3g here (default install)
<slytherin> seb128: I get error when trying to delete folders with files inside
<seb128> slytherin: you are the one who opened the bug?
<slytherin> seb128: No. I didn't
<pitti> seb128: yep, ntfs-3g likely
<pitti> seb128: there is a new upstream version allegedly, which we should update anyway
<pitti> (not for alpha5, though)
<pitti> seb128: aside from that it seems easy enough to fix; can you subscribe me to the bug #?
<pitti> I'm happy to take a look
<carlos> pitti: hi, should I accept translations for x264 package? it's in multiverse
<pitti> carlos: good question; why not?
<carlos> pitti: it's not a package in main, so I just wanted to check it ;-)
<seb128> pitti: bug #186569, I've subscribed you
<ubotu> Launchpad bug 186569 in ntfs-3g "cannot delete files off of an Fuse mounted NTFS partition in nautilus" [High,Confirmed] https://launchpad.net/bugs/186569
<pitti> carlos: you are afraid of violating LP's usage policy or so?
<carlos> pitti: no, there is no problem in Launchpad side
<pitti> seb128: taking
<carlos> pitti: I was more worried in the fact that the translations will be installed in language packs
<pitti> oh
<carlos> which are in main
<pitti> carlos: no, that shouldn't happen
<pitti> I thought LP would import universe translations, but not export them to langpacks?
<carlos> we ignore those imports to prevent translation effort lose
<carlos> until we implement a way to deploy it
<asac> \sh: hard to tell.
<\sh> asac: i test it a bit later with loudspeakers attached to the default soundcard, so i can trace this problem
<pitti> carlos: ok, then we better ignore it
<carlos> ok
<geser> good morning
<pitti> hi geser
<geser> Hi pitti
<Hobbsee> guten tag pitti
 * pitti hugs Hobbsee
 * Hobbsee hugs pitti back!
<lool> pitti: elisa dep changes applied with | python >= 2.5 (as also mentionned by pochu); thanks
<pitti> lool: great, thanks; I'm not fussed about python2.5 or python (>= 2.5)
<pitti> the latter is better for forwards compatibility, right
<lool> Well elisa runs with the default python ATM, so these are only optional if it's >= 2.5
<pitti> StevenK: oh, the joys of de-yada-ifying (just did it for ossp-uuid)
<StevenK> Yay!
<pitti> soren: I wonder whether kvm-source should better stay in universe? I take it on hardy release kvm-source and l-u-m should ideally be synchronized?
<soren> pitti: Well, not l-u-m, but yes.
<soren> And that is currently the case.
<pitti> right, it's in linux proper
<pitti> ok, done
<soren> Feel free to leave kvm-source in universe.
 * soren hugs pitti
<pitti> soren: can you please get it seeded?
<soren> Sure.
<davmor2> Can anyone tell me please if the Ubuntu cd's are safe for testing?
<dredg> depends what you mean by safe. there's always the chance a cd could shatter and cut you
<Hobbsee> davmor2: slangasek should be able to answer you
<soren> dredg: I hate that :(
<cjwatson> mvo: 'apt-get install ubuntu-desktop' installs recommends from the metapackage. 'apt-get install ubuntu-desktop^' does not.
<cjwatson> mvo: this feels like an apt bug to me?
<cjwatson> mvo: this happens even if I set APT::Install-Recommends=true. I think perhaps MarkInstall never gets called with AutoInst==true?
<cjwatson> mvo: http://paste.ubuntu.com/4824/ seems to fix it, but I'm not entirely certain what other effects it would have?
<cjwatson> mvo: (this is alpha-5-critical, by the way; we're only running into it as a consequence of other problems, but those seem a lot harder to address)
<ogra_cmpc> cjwatson, oh, you pushed kdeedu completely into desktop-kde ... if i add it to desktop-addon now that will pull in the deps i guess ?
<sabdfl> Riddell: help re displayconfig
<sabdfl> Riddell: is there a known issue with the display configuration in Hardy?
<sabdfl> complaining about being unable to find libpython2.5.so, iirc
<cjwatson> ogra_cmpc: I don't think I made any changes as far as the position of kdeedu is concerned
<cjwatson> ogra_cmpc: yes, seed dependency resolution works as normal
<ogra_cmpc> cjwatson, no, that change was made before aolready (it was in live and the old addon seed)
<ogra_cmpc> we did that for gutsy
<ogra_cmpc> hmm, unpredictable growth then, i'll keep it for after alpha then
<ogra_cmpc> the desktop install works fine from g-a-i now :)
<cjwatson> excellent
<davmor2> The new ubiquity doesn't set the country and keyboard defaults after the world map anymore.  Is this known?
<ogra_cmpc> having .desktop files for -desktop metapackages seems worth to have for all of them imho
<ogra_cmpc> we should discuss that at UDS
<cjwatson> davmor2: #ubuntu-installer
<davmor2> cjwatson: ta
<Riddell> sabdfl: yes, that's a known issue, it's on my todo for fixing
<Riddell> sabdfl: but it has larger problems too due to changes in xorg.conf files so it may disappear altogether
<Riddell> sabdfl: you can install python2.5-dev to work around that issue
<__keybuk> asac: default firefox launcher is broken, known?
<mvo> cjwatson: thanks, sorry I was at lunch, checking it now
<asac> __keybuk: yes we will go back to firefox.desktop in next upload
<asac> (if that is what you mean)
<mvo> Riddell: what are your plans re> displayconfig? is there someone working on fixing it?
<DktrKranz> pitti, it seems SRU candidate in bug 41491 is not sufficient, what's the procedure in these cases?
<ubotu> Launchpad bug 41491 in wzdftpd "Dapper: Broken dependencies for some wzdftpd modules" [Medium,Fix released] https://launchpad.net/bugs/41491
<Riddell> mvo: there is not
<Riddell> mvo: bryce wants to replace it with improved xrandr tools
<pitti> DktrKranz: upload a fixed one
<mvo> Riddell: yes, I have seen that (and think that its the right way) - is there a kde version for this in the works too?
<pitti> DktrKranz: we can kill the version in -proposed if it is worse than the one in -release
<Riddell> mvo: not that I know of
<pitti> cjwatson: yay, I just wrote "msgequal" to weed out msgid == msgstr
<cjwatson> mvo: the two commands I gave are enough to reproduce in a clean debootstrap
<DktrKranz> pitti, it's not worse, because now there's only one packae which has unmetdeps (against three than -release)
<cjwatson> pitti: ooh, neat
<pitti> cjwatson: /usr/include/gettext-po.h FTW :)
<mvo> cjwatson: thanks, doing that now
<pochu> doko: are you aware of bzrtools 1.2.0-1ubuntu1 failing to upgrade with latest pycentral? I get this: http://paste.ubuntu.com/4826/plain/
<ogra_cmpc> wow, virtualbox through ssh -X works really well :)
<doko> pochu: yes, we (mvo and me) don't yet understand why the preinst is not run. this only happens for upgrades from 1.2.0-1build1. you can work around by using apt-get --reinstall install bzrtools
<edsiper> is *jemalloc* going to be integrated in ubuntu 8.04 ?
<pochu> doko: ok, nice that you are aware of it. do you want me to submit it to lp (via apport) ?
<mvo> cjwatson: I can reproduce the different behavior here, I looked closer and it seems that the Task: in the Packages file is incorrect (or not in sync with the metapackages). if you look at e.g. landscape-client, that one is part of ubuntu-desktop as a recommends but in my chroot apt-cache show landscape-client does not list ubuntu-desktop as a task
<mvo> cjwatson: apt-get install ubuntu-desktop^ is really just using the task information from the packages file
<cjwatson> mvo: yes, that is a bug (harder to fix), and is triggering the bug in apt; but I think it is nevertheless a bug in apt
<cjwatson> mvo: the ubuntu-desktop metapackage is part of the ubuntu-desktop task, and as such apt should honour Install-Recommends-Sections and install Recommends from the ubuntu-desktop metapackage
<cjwatson> even if they aren't in the task
<davmor2> Ubiquity is frozen at 94% on ubuntu 32 bit and 64 bit
<cjwatson> mvo: I wrote an analysis of the bug you describe to #ubuntu-release; it's going to take some seed changes and a Launchpad change to fix
<mvo> cjwatson: thanks, I see. let me look a bit closer at the code so that I can get a better idea why it is run this way
<cjwatson> 12:28 <cjwatson> the underlying problem here is that the seed_map stuff in *-meta/update.cfg is only there, and not in the seeds, so Launchpad is unable to make use of it for generating Task fields
<cjwatson> 12:29 <cjwatson> it's actually not a new problem - note the lack of Task field in base-files which strictly speaking should have Task: ubuntu-minimal
<cjwatson> 12:29 <cjwatson> err, Task: minimal I mean
<cjwatson> 12:30 <cjwatson> but in order to fix it we'll need a Launchpad change, and if we can work around it by fixing the apt bug it appears to be triggering, I'd prefer that to having to ask for a cherry-pick
<cjwatson> this is in turn triggered by the seed reorganisation which split part of the desktop seed out into desktop-common (and desktop-kubuntu-common for kubuntu/kubuntu-kde4)
<mvo> cjwatson: thanks for the background. I think I wrote the code under the assumption that the task header would be present on the packages, your change is fine if that assumption is incorrect. I can do a upload with that fix
<cjwatson> mvo: I think the best way to describe it is "incorrect for the time being" :-)
<cjwatson> mvo: I'll definitely try to get the systemic and Launchpad bugs fixed. Thanks!
<mvo> cjwatson: ok .) let me do a final test and then I do the upload
<mvo> cjwatson: hrm, your fix helps, but its not perfect, there is still a delta between the task install and the meta-package (also smaller) - I look a bit deeper
<cjwatson> mvo: hmm, ok
<cjwatson> I admit I didn't do a proper comparison, I was just looking for ones I knew were left out by mistake
<ogra_cmpc> mvo, do we have *any* GL checks left in compiz (read: is there still a blacklist where we could add xephyr) ?
<ogra_cmpc> seems the desktop crashes in xephyr sessions with a message about texture_from_pixmap (which i belive comes from compiz)
<mvo> cjwatson: wdiff with fix compared to metapkg http://paste.ubuntu.com/4827/
<mvo> ogra_cmpc: yes and yes
<ogra_cmpc> ok
<mvo> ogra_cmpc: it crashes?
<ogra_cmpc> wait a sec
<mvo> ogra_cmpc: no fallback to metacity?
<ogra_cmpc> apparently no fallback
<johnny> beep
<ogra_cmpc> johnny is the guy who works on sabayon atm
<johnny> one of the guys..
<ogra_cmpc> which is supposed to switch to xephyr at some point
<mvo> ogra_cmpc: strange, it should fall back
<johnny> we hope..
<ogra_cmpc> johnny, *the* guy in ubuntu :)
<johnny> im a guy in ubuntu?
<ogra_cmpc> :P
<johnny> not officially at least
<johnny> my main OS is gentoo, i just happen to use ubuntu all over the place elsewhere :)
<ogra_cmpc> mvo, can we blacklist it (likely post alpja stuff though)
<ogra_cmpc> *alpha
<johnny> is this a place where you guys talking about issues you have with specific apps in hardy?
<johnny> i'm still having troubles with 2.22 and sabayon that i have replicated with hardy
<cjwatson> johnny: no, this is the Ubuntu developer coordination channel
<johnny> but i don't know anybody familiar with gvfs to know what should happen
<ogra_cmpc> cjwatson, he cares for our sabayon package a lot
<johnny> got some patches merged in
<johnny> hmm.. need to find the guy who maintains the current sabayon dev, gotta tell him that i removed gnomesu from the desktop file
<cjwatson> mvo: odd, fontconfig depends on fontconfig-config; why would the latter ever not be installed?
<johnny> now you can add gksu or not.. depending on the setup
<mvo> ogra_cmpc: sure
<ogra_cmpc> thanks
<mvo> cjwatson: I have no idea at the moment, I'm looking at it, sorry
<cjwatson> mvo: fontconfig-config is installed in both cases for me
<mvo> cjwatson: with -o APT::Install-Recommends=true or without?
<cjwatson> mvo: without
<cjwatson> just with the default install-recommends-sections stuff
<cjwatson> mvo: the only difference for me with my patch is mousetweaks, which was a recent addition and I think the metapackage just hasn't been updated yet
<cjwatson> mvo: http://paste.ubuntu.com/4829/
<mvo> cjwatson: thanks, maybe something odd in my chroot
 * mvo investigates
<mvo> cjwatson: right, my bad. the fix is fine
<ogra_cmpc> johnny, btw, could you try setting /desktop/gnome/applications/window_manager/current and /desktop/gnome/applications/window_manager/default to metacity and see if it doesnt crash with that ?
<ogra_cmpc> (in gconf-editor)
<johnny> it crashes before i get a chance
<johnny> i'm just going to put at-properties in /etc/xdg/autostart
<ogra_cmpc> it uses your default desktiop
<johnny> with autostart disabled
<johnny> oh.. that's a seperate thing
<johnny> i was thinking of something else
<johnny> oops
<johnny> what uses my default desktop?
<cjwatson> mvo: ok, cool
<ogra_cmpc> johnny, sabayon should use your default desktop
<ogra_cmpc> as starting point
<mvo> cjwatson: preparing the upload now
<johnny> it says that key has been deprecated?
<ogra_cmpc> if you switch the default to metacity it shouldnt choke on compiz
<ogra_cmpc> johnny, thats an upstream comment ... its still used regardless
<johnny> ok
<pitti> ArneGoetje, cjwatson: I rolled out the langpack-o-matic fix to eliminate msgid==msgstr translations, FYI
<ogra_cmpc> (we should probably fix teh text for final release)
<johnny> same diff
<johnny> it says it aborts and uses metacity, but that is too late
<cjwatson> pitti: nice
<pitti> cjwatson: ah, thanks for devscripts
<mvo> ogra_cmpc: just tested it with Xepyhr and compiz, the fallback works ok for me
<ogra> hmm, then it must be the way sabayon calls it i guess
<mvo> ogra: if you can give me instructions how to reproduce I'm happy to have a look
<emgent`work> packages.ubuntu.com is down ?
<cjwatson> not run by us, the same guy who runs packages.debian.org runs it
<dholbach> Ubuntu Developer Week is going on, join #ubuntu-classroom
<selckin> really sucks ubuntu.org isn't what i think it is every time i type it in
<infinity> pitti: gcc-3.3 was moved to universe without anyone realising that libgcc1 builds from gcc-3.3 on hppa.  We ended up with override mismatches, DAK exploded, I cried.
<pitti> infinity: oh, erk; thanks
<slangasek> tjaalton: eh... soft freeze, so I wouldn't have had any way to put it on hold if we needed to roll new CDs
<mario_limonciell> slangasek, is there currently any intention of DVDs with this release?
<mario_limonciell> <this alpha>
<slangasek> mario_limonciell: no, that would get me yelled at about disk space
<Chipzz> (sorry for the off-topic question; but does anyone know if there's a channel where the opers hang out?)
<Chipzz> (#opers appears to be a no-go)
<Pici> Chipzz: If you need to speak to freenode staff, #freenode is the place, for Ubuntu operators, you can try #ubuntu-irc or #ubuntu-ops. (depending on the type of issue, see the channel topics)
<Chipzz> Pici: thx!
<Chipzz> (I needed #freenode ;))
<pranith> hello, which channel do i join for the developer week irc's?
<pranith> the bughelper session in particular?
<Mithrandir> 17:30 < dholbach> Ubuntu Developer Week is going on, join #ubuntu-classroom
<pranith> thank you
<Mithrandir> do we yet have any way to modify pam configs when packages get installed?
<Mithrandir> I'd like libpam-ck-connector.so to be added, either programatically or to the default config
<slangasek> there's auth-client-config
<slangasek> for intrepid I'm hoping for a reworked pam config framework
<slangasek> but that didn't come along quickly enough for hardy
<Mithrandir> this is for mobile, so I'd rather not install too much stuff like auth-client-config
<Mithrandir> (and is that supposed to be driven from maintainer scripts?)
<slangasek> dunno.  that's all that exists today, though; the proper in-pam solution is still a cycle away
<Riddell> evand, cjwatson: I've got a patch to add proxy support to ubiquity's qt side, is now a suitable time to commit it?
<evand> Riddell: should be.  I've already uploaded the fixed ubiquity for bug 193986
<ubotu> Launchpad bug 193986 in ubiquity "Ubiquity is locking up at 94% Configuring Hardware" [Critical,Fix released] https://launchpad.net/bugs/193986
<Riddell> evand: committed, hugs to nixternal
<davmor2> yeah
<davmor2> evand does that mean we'll have a new cd in a bit :)
<evand> thanks Riddell and nixternal
<evand> davmor2: eventually.  ubiquity needs to build and the cd build system needs time to get the update and then make new images.
<davmor2> cool :)
<bryce> cjwatson: you about?  perhaps this would be a good time to talk with tjaalton about input-hotplug?
<evand> bryce: I believe he left around :15
<tjaalton> slangasek: uh ok, will remember it the next time ((=won't happen again)
<evand> not sure when he'll be back though
<bryce> oh, ok, too bad
<tjaalton> bryce: my gprs-connection is busy downloading a java-plugin for FF, so it's quite laggy atm :)
<bryce> boo java ;-)
<bryce> tjaalton: anyway, with input-hotplug the question is how to get to a stable point - would it be easier to revert back to having input stuff specified in xorg.conf, or to complete the work for making input-hotplug function properly?
<tjaalton> bryce: it would be easier to revert back
<bryce> tjaalton: given that we may not know what bugs may appear even after turning input-hotplug on, maybe that would be the safest thing to do?
<tjaalton> bryce: indeed
<bryce> tjaalton: what is your opinion?
<tjaalton> bryce: I'm leaning towards status quo, and bringing back the synaptics entries to dexconf
<tjaalton> since hal upstream is not helping
 * bryce nods
<bryce> tjaalton: I think I agree; last I talked with cjwatson he was of similar mind
<tjaalton> maybe we could ship a script which generates an fdi-file from xkb configuration so people can start using it if they like
<bryce> that's a good idea
<bryce> tjaalton: also expectations are going to be that with input-hotplug that things work at least as well as in gutsy, but since things are still not fully matured upstream with this, it's hard to guarantee
<bryce> also, I'm a bit worried about that we don't have config utilities yet, so even with input-hotplug working, people will find it difficult to customize beyond the defaults
<tjaalton> yeah, and because upstream input maintainers hate every single component that is related... even the evdev driver deserves a rewrite :P
<bryce> yup
<bryce> ok sounds like a decent plan - do you want to do the dexconf reverts, or would you like my help with that?
<tjaalton> either works, although I'm away most of this week so it would have to wait until Monday
<bryce> I think Monday would be soon enough
<tjaalton> yeah
<bryce> I'll go ahead and outline this plan to cjwatson and on the bug report
<tjaalton> ok cool
<jdong> hey while I have you two here.... I'm having an intriguing xorg-video-intel bug
<jdong> seems like if I use xvideo,  suspend and resume then use xvideo again, X hangs and only lets me move the mouse
<jdong> I can't click anything, keyboard totally locked, power button doesn't respond either
<jdong> (Compiz, EXA, greedy migration). Any clues?
<tjaalton> jdong: doesn't sound familiar.. filed a bug yet?
<jdong> tjaalton: not yet, I'll reconfirm a few times and then file a bug if it's reproducible
<tjaalton> ok
<jdong> tjaalton: actually, the problem is more trivial than that to reproduce
<jdong> tjaalton: xv+compiz seems to randomly
<jdong> destroy the display
<jdong> ~.
<jdong> ~.
<bryce> jdong, check through the bugs against -input; xvideo issues after suspend/resume sounds vaguely familiar
<bryce> jdong: I've not looked into that issue myself yet, but it is likely an acpi and/or kernel issue (and so probably highly chipset-specific)
<jdong> bryce / tjaalton after today's updates it seems like compiz+xvideo = hardlock on my macbook
<jdong> it wasn't like this a few days ago
<bryce> jdong: well the only change we've put in recently is the greedy patch stuff
<bryce> which only affects 965
<jdong> bryce: hmm just rolled back to -video-intel 2ubuntu6 and that worked fine
<jdong> lemme apply the upgrade again and see what happens
<bryce> jdong, hmm also try out 2ubuntu5.  iirc 2ubuntu7 merely reverted the patch in 2ubuntu6
<jdong> nope 6 and 7 both happen
<jdong> but it's all pretty random
<bryce> hrm
<bryce> ok, so it still happens with both 2ubuntu6 and 2ubuntu7?
<bryce> 2ubuntu2 would probably be the next to try - 3 and 4 were mainly quirk releases iirc
<bryce> jdong, ok anyway, please file a bug with as much info as you can gather (I'll probably forget our discussion here, so please summarize), and I'll take a look into it when I get a chance
<jdong> bryce: indeed, I'll have to find some time to look into this more thoroughly
<jdong> bryce: the combination core 1ubuntu3 and intel ubuntu6 seems to work
<jdong> but core 1ubuntu4 with all intel versions seems to fail
<jdong> I'll test this for the rest of the afternoon and let you know if this is wrong
<bryce> cool thanks
<bryce> so it is starting to sound like the issue may be that greedy fails on your hardware..... something I worried about
<bryce> you might also try setting your migration heuristic to "always" (see man exa)
<bryce> jdong: what does your `lspci | grep VGA` say?
<alex-weej> debugging network-manager via my mum on the phone is not even funny
<mrsno> alex-weej :) i was doing tech support via sms the other day, /sys/bus/pci/drivers/ipw3945/0000:02:01.0 is not easy to type :<
<alex-weej> hehe
<Elly> which package do the man pages for the pthreads functions (e.g.: pthread_create) live in?
<Chipzz> Elly: off-hand, without checking, I would say manpages-dev
<Chipzz> Elly: but this is not the right channel blablabla :), use http://packages.ubuntu.com/ ;)
<Elly> Chipzz: I have manpages-dev installed already :P I just noticed there are no man pages for pthreads only - I have manpages for all the system calls and stuff, just pthreads docs appear to be missing
<Chipzz> I betcha I can find it with one google search and one lookup on p.u.c :P
<Chipzz> so, so should you :P
<Elly> aha
<Elly> thanks :)
<davmor2> slangasek: You'll be glad to hear that Ubuntu Alt's aren't too bad.  Firefox applet is missing and bluetooth applet has vanished.
<TheMuso> Do we have CDs tat need testing?
<slangasek> TheMuso: more testing wouldn't hurt; I'm about to reroll all the images and the liveCDs are currently uninstallable, but more feedback on the current alternates could still be useful
<slangasek> otherwise, give it a couple of hours and we'll have a whole new set
<TheMuso> slangasek: I can wait, thanks for the heads up.
<NthDegree> Got a technical question:  Is there any plans to add more proactive security to future compiles of Ubuntu? (Sorry if this is OT, but neither the wiki or the support channels really seem to know)
<slangasek> davmor2: hopefully the changes that cjwatson_ made fix that problem for Ubuntu as well as Kubuntu
<NthDegree> by proactive security I mean fortify_source and other such compiler features
<davmor2> slangasek: we shall see in a bit I'm sure :)
<ScottK2> NthDegree: Try in #ubuntu-hardened
<doko> Mithrandir: thanks for the brightness fix!
<Mithrandir> doko: it helps you too?
<doko> Mithrandir: package is not yet available, but currently the screen is dimmed after about 5sec of inactivity and doesn't come back to full brightness after pressing a key
<Mithrandir> ugh, ok.  I'm not sure it'll fix that.
<slangasek> new kubuntu alternate CDs are up for testing, now with a properly-sized amd64 ISO
<slangasek> davmor2: ^^ if you're keen to test whether the task issue is resolved for kubuntu alternate
 * Treenaks pokes >5 of his own bugs (does that count? :))
<RussellGee> Hi huys
<slangasek> TheMuso: for 5-a-day? yes... :)
<slangasek> er
<Treenaks> slangasek: whoo :)
<Treenaks> slangasek: the other t<tab> :)
<slangasek> TheMuso: sorry, that was for Treenaks
<davmor2> cool I'll check it out in a second
<Gee> Hi guys
<Gee> When will alpha 5 be released now ?
<Gee> Anyone ?
<Treenaks> Gee: well.. I guess when people get around to it
<NthDegree> ScottK2: what's the development status of hardy like for a user interested in KDE 3.5.x?
<ScottK2> NthDegree: --> #kubuntu-devel
<ScottK2> NthDegree: If you join in #kubuntu-devel we can discuss there.
<slangasek> Gee: tomorrow, as noted at https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-February/000381.html
<persia> slangasek: It's already "tomorrow" for some of us :p
 * persia isn't advocating early release, just global timezones
<Treenaks> persia: those people just need some adjustment to proper time zones ;)
<slangasek> persia: yes, but not in Ubuntu Temps CoordonnÃ©
<Gee> Weird, Im on the mailing list but i never got the announcement
<Gee> Ok, thanks
<Treenaks> the mailinglist is slow somehow
<Treenaks> I got sabdfl's "intrepid" announcement this morning
<persia> slangasek: Fair, but I thought releases happened in -9 or something these days anyway :)
<slangasek> persia: -8, yes... :)
<slangasek> Treenaks: sabdfl's mail to u-d-a was delayed because it hadn't been moderated; I moderate my own mails to u-d-a so that's not related
<Treenaks> slangasek: US/West?
<slangasek> Treenaks: US/Pacific, yes
<Treenaks> slangasek: sabdfl's mail to u-d-a was in the archives >12hrs before I received it
<Treenaks> slangasek: but I admit I might have to spank my postfix, because it does weird things (like giving spurious 4xx statuses) sometimes
<davmor2> slangasek: do you know if the images are on the rsync server?
<slangasek> davmor2: well, you should be able to find out quickly enough if you use the date serial (20080221.1) in your rsync command
<slangasek> it's either there or it's not :)
<Treenaks> slangasek: ooh.. suspense! :)
<slangasek> mr_pouit, somerville32: any plans to fix the size problems on xubuntu alternate for alpha-5?
<emgent> heya
<Nafallo> emgent: hiya
<jdong> bryce: just an update, it's neither -core nor intel causing the problem, I experienced a freeze on a subsequent reboot using the setup I detailed above. Looks like on some reboots though the system works like a dream while on others just starting up mplayer hardlocks the system
<jdong> bryce: so yeah, I'll try setting migration heuristics to Always when I get a chance to and report back
<bryce> weird, ok
<jdong> yeah this is really strange, because before everything worked fine
<jdong> I did apply the keyboard firmware and "video update" from OS X this morning
<jdong> the former sounds irrelevant, the latter sounds fishy
<jdong> though I understood it as an OS X driver update that should not do anything to the hardware
 * jdong cries a bit
<TheMuso> Does anybody knw why -es langpacks are broken?
 * TheMuso is looking at UbuntuStudio's disk report.
<slangasek> TheMuso: which package, specifically?
<TheMuso> language-support, language-support-translations language-support-writing, mozilla locales, and thunderbird locales, all the -es stuff.
<geser> TheMuso: LP ate ispanish
<geser> (and some other ispell dicts)
<TheMuso> geser: THanks, I'll just yank that langpack for now.
<geser> TheMuso: I see now that it should be back
<geser> it has a published record again
<slangasek> geser: hrm, still missing from the Packages file though
<TheMuso> Meh, I'll just yank it for now, we can do without it for an alpha.
<geser> hmm, when I look at the dates at https://edge.launchpad.net/ubuntu/hardy/i386/ispanish/+index for the first entry, I'm not sure it should be there or not
<Keybuk> ?!
<Keybuk> we don't put users in the users group?
<geser> "Published  on 2008-02-14" and "Removed from disk  on 2008-02-16"
<Nafallo> Keybuk: defaults to their own group AFAIK.
<Nafallo> Keybuk: I usually change that first thing on servers though ;-)
<geser> cprov: do you know how the current status of ispanish is? should it appear on a.u.c. again?
<cprov> geser: what does LP say ?
<geser> the status column says published but when I expand the entry and look at the dates I'm not sure anymore
<geser> cprov: because of "Published  on 2008-02-14" and "Removed from disk  on 2008-02-16"
<cprov> geser: it was badly rescued by me, let me fix it.
<cprov> geser: I will fix it later LPDB is down and I have to go. What matters  is the date published ... it should be in the a.u.c, it looks like a mirroring issues
<geser> cprov: thanks, I see that idutch has a date for "removal request" after the date of "published". Could it make a problem it the future? it is currently on a.u.c
<cprov> geser: yes, it's very confusing I will make it pending again (with empty dates) so we can be sure it will end up in the archive pool
<geser> cprov: icatalan and ilithuanian are in the same situation as idutch (with ispell that are the four package I could find which were affected)
<cprov> geser: sure, the ones that I've changes before.
<geser> s/ispell/ispanish/
<geser> cprov: thanks for fixing it
<cprov> geser: the files will be published correctly in the next publishing cycle, they should reach the mirror in 1 hour or so.
<slangasek> oh argh, now why do I have an oversized amd64 liveCD where it wasn't before?
 * Nafallo is not sure he will even try to answer that one ;-)
<Keybuk> pitti: not around I guess?
#ubuntu-devel 2008-02-22
<toresbe> I have a quick question about a bug I just submitted which I'm not sure got submitted right.
<toresbe> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/194196 - under "Affects"
<ubotu> Launchpad bug 194196 in linux "Fails to insert nVidia SATA disk modules on boot causing boot fail" [Undecided,New]
<toresbe> does that mean the bug is being forwarded to the Kernel.org dudes? 'cause I think this is a kernel packaging issue
<LaserJock> toresbe: I think the Ubuntu Kernel team will be looking at it
<toresbe> LaserJock: great, that's my "target audience". :) thanks
 * toresbe sticks around in case someone says LaserJock is wrong
<LaserJock> you might also ask #ubuntu-kernel
<toresbe> ah, right, thanks.
<toresbe> LaserJock: solved, thank you
<toresbe> (my confusion, not the bug :))
<toresbe> bye!
<toresbe> I'm seeing some very strange behavior in the tracker system, but I'm not sure where to report it.
<toresbe> Well, launchpad, yes, but I don't know why this bug is occurring or anything. it's a rather strange bug.
<blueyed> toresbe: post a bug in launchpad itself: https://help.launchpad.net/Feedback
<toresbe> sorry, not *that* tracker system, but "tracker" the deb package :)
<toresbe> I'd like to ask a tracker upstream developer about it... y'know where they might be found?
<blueyed> toresbe: no. I would look at the homepage/google or just try #tracker
<toresbe> #tracker's empty
<toresbe> and "tracker" is quite difficult to google!
<blueyed> http://www.gnome.org/projects/tracker/development.html
<blueyed> via https://launchpad.net/tracker => Homepage
<blueyed> IRC: GimpNet, channel #tracker
<toresbe> aha! Thanks. :)
<blueyed> often the mailing list might be better though :)
<blueyed> good luck and good night.
<toresbe> Hehe. I really like this bug.
<toresbe> So - here's what's happening. tracker is searching along, and encounters a graphics file. It wants to thumbnail it, so it passes it along to convert. Convert creates a temporary file. Tracker notices that a file has been created. It notices it's an image file, so it wants to thumbnail it. It calls convert.
 * Hobbsee wonders why stuff from firefox is only playing out of one speaker.
<lifeless> because fox is singular ;)
<lifeless> tchau!
<bddebian> heh
<pitti> Good morning
<pitti> Keybuk: I am now
<z5000man> I've got an issue with gutsy installation, can someone lend a hand, as i have been in like 10 different channels where noone talks
<warp10> Good morning!
<pitti> hey warp10
<bryce> z5000man: sorry to hear of the troubles; this probably isn't the right channel either, but maybe try asking via answers.launchpad.net/ubuntu
<evand> Agostino Russo and I are trying to determine whether a ntfs-3g panic occurs outside of virtual iron.  If someone would be so kind as to try installing Ubuntu 64-bit in Windows using Wubi from the latest daily live CDs, I would very much appreciate it.
<evand> The panic occurs post-install, on the first boot.
<dholbach> good morning
<mdke> morning dholbach
<dholbach> heya mdke
<Mithrandir> is it just for me that sudo -u $USER -i (i386, hardy) segfaults?
<cjwatson> WFM
<Mithrandir> hm, ok.
<toresbe> toresbe@mjollnir:~$ sudo -u postgres -i
<toresbe> [sudo] password for toresbe:
<toresbe> postgres@mjollnir:~$
<toresbe> WFM2.
<Mithrandir> toresbe: that's something else than what I asked about
<Mithrandir> I wonder if it's related to me adding myself to a group just before.
<toresbe> oh, $USER as in, the actual shell variable $USER, and not "whatever user". :)
<Mithrandir> yes
<cjwatson> oh, I misunderstood that too
<toresbe> that works, too.
<cjwatson> ditto
<Mithrandir> it's related to pam_mount, it seems
<evand> Riddell: Kubuntu Wubi works...sort of.  I need to fix the calling of kwin/dcop as they currently crash and leave you with just an X cursor, but the install goes through just fine.
<evand> You just have to sit and stare at a mostly black screen and wait for it to reboot
<Riddell> evand: exciting.  so I should be able to test it on my girlfriend's dual boot laptop without it wiping her windows partition?
<evand> Riddell: indeed
<evand> Riddell: Just pop in one of today's daily live CDs, then select "Install inside Windows"
<evand> it'll create a C:\Ubuntu folder and add Kubuntu to the NT bootloader, both of which can be undone by running the Wubi uninstaller in Add / Remove programs
<Riddell> evand: does today's daily CD include 20080221.1?
<Riddell> I suppose it does in your timezone
<Riddell> made at 21:41
<evand> heh, indeed it does
<evand> really any Kubuntu CD after the new livefs landed (I think that was day before yesterday, no?) will work
<davmor2> out of curiosity will the language selector at the beginning of the cd look better than it does at the moment?
<evand> davmor2: can you elaborate?
<Riddell> he means the gfxboot menu that now pops up by default
<Riddell> it's useful to non-english speakers but looks very out of place to those of us who don't need it
<davmor2> evand: currently at the boot up of any *buntu cd you get the language selector over the top of the menu.  It's grey and blocky and looks cheap and tacky
<evand> cjwatson: ^
<Riddell> I suspect it would take a lot of gfxboot hacking to improve it notably
<evand> SuSE seems to have done it with theirs, which I quite like, but I agree.  gfxboot is scary, and it would probably take quite a bit of work.
<evand> or maybe that's a false memory, I'd have to check again
<evand> Riddell: is there going to be a separate Kubuntu Alpha 5 announcement?
<davmor2> Riddell: not even if you don't need it everything else on the cd looks nicely integrated and smooth but this looks like an after thought at the moment.  I can see that it is useful just ugly.
<Riddell> evand: not if it's released at the same time
<evand> Riddell: ah, well in case you end up needing them, I took some screenshots of the Kubuntu umenu and Wubi: http://evalicious.com/kubuntu/
 * evand -> bed
<Riddell> evand: excellent, thanks
<cjwatson> davmor2: yes, it is kind of an afterthought. We'll try to improve the UI. In the meantime please accept that this is known (I think that this is the second time you've mentioned it)
<davmor2> cjwatson: no first the other language thing is latter on in ubiquity
<pitti> \o/ NEW queue == 0
<soren> pitti: really?!? Wow.
 * soren hugs pitti
 * dholbach hugs pitti too
<pitti> asac: can you please modify the firefox seeds in -desktop for firefox-3.0?
<asac> pitti: why? all is fine imo
<asac> firefox
<Q-FUNK> did the PPA builders go belly up?
<Q-FUNK> they fail a build becuase they try to include a non-existant sources.list item
<cjwatson> Q-FUNK: URL to build log?
<Q-FUNK> http://launchpadlibrarian.net/12152121/buildlog_ubuntu-hardy-i386.flashrom_0.0%2Br3112-1ubuntu2_CHROOTWAIT.txt.gz
<Fujitsu> Q-FUNK: That's a #launchpad problem. Did you just activate your PPA now?
<cjwatson> Q-FUNK: odd; presumably that *would* exist if it managed to build and publish anything
<cjwatson> but yes, as Fujitsu says, better in #launchpad
<Fujitsu> I can see why that would happen as of 1.2.2, though.
<Q-FUNK> Fujitsu: no, I've been using it for a while already
<Fujitsu> Q-FUNK: It was empty, though?
<Q-FUNK> alright then
<Q-FUNK> no
<Q-FUNK> it wasn't empty
<cjwatson> err, ok, that's very weird, that URL *does* exist
<Q-FUNK> my gutsy PPA was laready in use
<Q-FUNK> hardy was just activated with a 1st package today
<Fujitsu> Ah, that's it, then.
<saispo> any hibernate expert in the room ?
<Q-FUNK> https://launchpad.net/~q-funk/+archive/+builds?build_text=&build_state=all
<Fujitsu> Before 1.2.2, builds didn't start for up to 45 minutes after the source was uploaded.
<Q-FUNK> but the gutsy package failed the same way
<Fujitsu> As sources are published every 20 minutes, they were already published before the builder tried to update its sources.
<Fujitsu> Now builds start immediately.
<Q-FUNK> hm
<Q-FUNK> weird
<Q-FUNK> the builder produces different output than pbuilder does
<Fujitsu> Q-FUNK: Those builds failed normally.
<Fujitsu> Only hardy has that problem.
<Fujitsu> Gutsy fails for legitimate reasons.
<Q-FUNK> I'm not so sure.
<Q-FUNK> her,e build works fine using pbuilder
<Fujitsu> It's entirely unrelated, at any rate.
<Fujitsu> It's a problem in the package, but it might not be picked up in pbuilder.
<Q-FUNK> could be
<Q-FUNK> is the PPA using sbuild?
<Fujitsu> A horribly mangled sbuild, but yes.
<Q-FUNK> horribly mangled might be the key.
<Fujitsu> I don't find it likely that it could produce that kind of error.
<Q-FUNK> http://ftp.debian.org/debian/pool/main/f/flashrom/
<Q-FUNK> it builds fine on debian
<Fujitsu> Debian's archive isn't identical.
<Fujitsu> A lot of things fail to build here.
<Q-FUNK> builders should be
<Fujitsu> Er, why?
<Fujitsu> We have completely independent archive and builder infrastructure.
<Q-FUNK> they both are debian packages.  there's no reason for a complete fial on one distro and not on the other.
<Fujitsu> Tell that to all of our FTBFS bugs.
<cjwatson> there are plenty of reasons why that sort of thing might happen
<Q-FUNK> hmm. ok
<Q-FUNK> anyhow. thanks for the explanation
<Q-FUNK> :)
<cjwatson> in this case your CFLAGS seems not to be taking
<pitti> asac: hm, but package 'firefox' is transitional, isn't it?
<asac> pitti: nope ... meta
<pitti> oh, argh, that
<pitti>    firefox | 3.0~b3+nobinonly-0ubuntu2 | hardy/universe | all
<pitti> then we need to promote it
<asac> why is it in universe?
<pitti> because I demoted source+binaries of firefox, and apparently soyuz got confused
<asac> ah ok
<pitti> promoted
<asac> pitti: promote all firefox binaries: firefox + firefox-gnome-support + firefox-libthai (that will appear again in next upload) and firefox-dom-inspector
<asac> pitti: well firefox-libthai is the only transitional package
<asac> because the feature is now in core-xulrunner
<davmor2> mjg59: ping
<mjg59> davmor2: Hi
<nrpil> .top
<davmor2> mjg59: Riddell just asked me to have a word about an unusual effect in Kubuntu.  This display fades to black once you've logged in.
<mjg59> Hm. Sounds like it may not be my problem :)
<davmor2> Riddell: is thinking it might be a hal issue don't ask me why.
<mjg59> Can't see how it would be a hal issue
<mjg59> But it'd be nice to have some more background
<Riddell> well I've no idea, but it doesn't seem to be kmilo or guidance which are the parts that touch brightness in kde
<mjg59> hal will never alter anything without being told to
<ion_> And sometimes when told to, he answers âIâm afraid I canât do that, Daveâ.
<davmor2> Riddell: don't forget that guidance doesn't seem to be running.
<davmor2> slangasek: cjwatson:  Ubiquity issue is sorted now run straight through to 100% :)
<cjwatson> good stuff
<Keybuk> jdstrand: around?
<jdstrand> Keybuk: I'm a while for a while
<jdstrand> wow, I just woke up
<jdstrand> I'm around for a while
<Keybuk> jdstrand: pitti and I were discussing PAM
<Keybuk> and he mentioned you'd been working on a way to automatically change /etc/pam,d/common-auth for libpam-ldap
<jdstrand> Keybuk: it's called auth-client-config.  it is profile based, and can switch pam and nsswitch.conf
<jdstrand> it's in main
<pitti> right, that was it
<dredg> it works pretty well, especially in conjunction with things like puppet
<jdstrand> basically if an admin knows what pam/nss settings he/she wants, then the admin can put the profile into the auth-client-config datase, run a command and *poof* the machine is updated
<jdstrand> it doesn't do pam/nss configuration (and stacking) however-- the admin has to know what he/she wants
<Keybuk> so it can't be used in postinst?
<jdstrand> Keybuk: yes
<Keybuk> yes it can't or yes it can? :p
<jdstrand> Keybuk: it was designed to have the necessary flags in place to work safely in this regard
<jdstrand> oh heh-- still sleppy
<jdstrand> Keybuk: AKAIK, no package is using it for that
<jdstrand> Keybuk: but /usr/share/doc/auth-client-config/README hasa blurb on it
<jdstrand> Keybuk: it is largely untested in this regard, and ideally we would need to develop a policy to ensure safety
<jdstrand> Keybuk: but I believe everything is there to do it properly
<jdstrand> sleepy even
<Keybuk> right, what would that policy look like?
<jdstrand> Keybuk: postrm is easy: auth-client-config -p profile_name -a -r-- this will revert pam and nss for profile_name only if the current system settings match profile_name
<Keybuk> what about install?
<jdstrand> it reverts pam/nss to pre-auth-client-config settings
<asac> dholbach: can i participate in five-a-day by just reporting to the log?
<dholbach> asac: sure
<jdstrand> Keybuk: thinking...
<asac> dholbach: what bugs do qualify for that list? every bug touched? or only fix release/invalid/wontfix?
<dholbach> asac: I think that if you contribution helps to get it fixed, that qualifies it :)
<jdstrand> Keybuk: I think just a debconf question asking whether or not to activate the profile would be good enough, then use 'auth-client-config -a -p profile_name'
<jdstrand> Keybuk: well, that may not be good enough
<dredg> i think you're looking for something like redhat's authconfig :)
<jdstrand> Keybuk: no, if it was a shared debconf key, I think that might do it
<cjwatson> dredg: IME Red Hat tools are just about as difficult to port to Ubuntu/Debian as our tools would be in the opposite direction
<dredg> cjwatson: very much so
<cjwatson> distributions tend to build up a lot of infrastructure on which this sort of thing is built, and we're pretty divergent in those terms
<jdstrand> dredg: redhat doesn't have a packaging policy like we do, so they can take shortcuts
<dredg> while you can preseed some things, like libnss-ldap, you can't easily preconfigure pam. if you could preseed auth-client-config with a profile (or profile location it could slurp) and tell it to apply a profile
<Keybuk> jdstrand: a-c-c has no knowledge of the default config, right?
<jdstrand> Keybuk: no. but it can reset the system to pre-a-c-c values
<jdstrand> Keybuk: when you apply a profile, it will comment out the old settiings.
<Keybuk> right
<Keybuk> does anything use a-c-c at the moment?
<jdstrand> Keybuk: I had initially thought that pam and base-files might want to use auth-client config, along with ldap, kerberos, etc
<jdstrand> but currently no packages use it that I am aware of
<jdstrand> Keybuk: slangasek wasn't too keen on base-files and pam using it
<jdstrand> Keybuk: he has a valid argument that pam stacking configuration should be handled by the packages
<jdstrand> Keybuk: the problem is that is incredibly difficult once you get past a couple of pam mosules
<jdstrand> modules
<jdstrand> Keybuk: and in so doing, packaging makes assumptions about what the admin wants
<dredg> plus pam config is very site specific
<jdstrand> Keybuk: this conveniently bypasses all that, as long as the admin knows what she wants
<jdstrand> not to mention-- this pam stacking configuration code for the packages doesn't exist yet :)
<jdstrand> dredg: exactly
<Mithrandir> I disagree about the site specific bit.  If you are using pam_ldap, you most likely want one type of config.  Ditto if you're using pam_mount.
<jdstrand> Mithrandir: but no kerberos, for example
<jdstrand> Mithrandir: and if you throw disconnected users in, there are various ways to do caching
<jdstrand> not kerberos
<Mithrandir> jdstrand: kerberos generally consists of putting pam_krb5.so into the local login files, not much work and very much stock
<Mithrandir> as for caching, why can't we choose a sane default and stick with it?
<jdstrand> Keybuk: a-c-c doesn't scale either for large numbers of profiles, but then, I on't think that is a big concern
<Mithrandir> nobody is suggesting the files shouldn't be configuration files, just that we have a sane way to update the config programatically.
<dredg> putting pam_krb5.so in, depends if you want pam-heimdal or mit pam-krb5. then you need to configure the module - do you want the config in krb5.conf or in the pam file?
<jdstrand> Mithrandir: a-c-c will allow for programatically updating these
<dredg> it's site specific.
<cjwatson> what would base-files have to do with PAM configuration?
<jdstrand> cjwatson: base-files provides nsswitch.conf
<cjwatson> ah, ok
<jdstrand> a-c-c supports profiles for just changing nsswitch.conf, or just changing pam as well
<jdstrand> (ie, a profile doesn't have to do both-- there is a profile for using cracklib for example)
<pitti> yay, I killed 50 hal bugs by triaging; does that count as 5-a-day? :)
<dholbach> pitti: absolutely :)
 * seb128 hugs pitti
<jdstrand> Keybuk: I think there is some potential here for simplifying large deployments, as well as providing users with a good sane profile on install of a pam package-- but the packaging scripts policy need more thought
 * seb128 hugs dholbach
<jdstrand> I am happy to update a-c-c as needed for this of course
 * dholbach hugs seb128 back
 * Hobbsee hugs seb128 and dholbach
 * dholbach hugs Hobbsee too
<dholbach> is it a Hug Day and I missed it? :-)
<Hobbsee> dholbach: what does this mean?
<Hobbsee>  - Discussion of the process for requesting someone participation
<Hobbsee> (temporarily or permanently). Agreement to review past activity and
<Hobbsee> document process to smooth such occurrences if they were to happen in
<Hobbsee> the future.
 * seb128 hugs Hobbsee
<dholbach> Hobbsee: there has been long mailing list threads and we thought it'd help to massage this into a concise wiki document
<Hobbsee> dholbach: i don't understand.  the first is not valid english, and words may be missed, and i don't see the relevance of the second statement to the first.
<dholbach> ugh, you're right
<dholbach> "cease" is the missing word
<dholbach> sorry
<Hobbsee> ahhhh....
<Hobbsee> right, that makes more sense then
<dholbach> I'll ... err ... follow up :)
<Hobbsee> i didn't think i was that dense.
 * lamont finally notices the bind9 upload to hardy from last week, decides he maybe better fetch it and deal with adding that
<lamont> jdstrand: did that get coordinated with a change in debian AppArmor?  or did we just fork bind9 while I wasn't looking?
<jdstrand> lamont: ubuntu specific-- but changes are minimal
<lamont> moving ownership of a file is not _MINIMAL_
<jdstrand> lamont: you mean usr.sbin.named?
<lamont>   * debian/control: Replaces apparmor-profiles << 2.1+1075-0ubuntu4 as we
<lamont>     should now take control
 * jdstrand nods
<lamont> which requires coordination with the owner of apparmor
<jdstrand> lamont: I meant simply in terms of the size of the diff
<lamont> so that it _STOPS_ delivering it
<jdstrand> lamont: I coordinated that with ubuntu's apparmor
<lamont> right.  meaning that the package is now _FORKED_ until someone works with the debian apparmor maintianer
<lamont> where it used to be one that we could just sync.
 * jdstrand again nods
<jdstrand> lamont: this was a server team FF directive
<lamont> so now I get to decide if it's worth generating debian/control as part of the build (which makes me vomit), or just let y'all keep merging
<lamont> has anyone even _started_ the discussion with debian's apparmor?
<jdstrand> lamont: not that I am aware off
<mathiaz> lamont: there isn't any apparmor package in debian.
<jdstrand> of
<lamont> mathiaz: that does help some...
<lamont> is hardy going to let one choose between selinux and apparmor? or are we still stuck apparmor crap?
<mathiaz> lamont: there is work done on the selinux front too.
<jdstrand> lamont: selinux is in universe, but it will be much better supported by the system
<jdstrand> lamont: with a kernel boot option, selinux can be turned on and apparmor disabled
<lamont> jdstrand: selinux has always struck me as the better of the two...
<jdstrand> lamont: it is in terms of security-- no doubt
<jdstrand> lamont: the problem is usability for end-users
<ScottK> lamont: Enabled apparmor is better than disabled SE Linux.
<lamont> ScottK: I'm not 100% convinced of that.
<mathiaz> lamont: see https://wiki.ubuntu.com/HardySELinux for the state of selinux in Hardy
<jdstrand> lamont: apparmor provides much better security than not having either, but is easier for people to get into
<lamont> really good locks on a cheap door are not better than no locks on a solid door: they lead the owner to _THINK_ that he's secure, when he's not.
<jdstrand> lamont: while I understand your point, I disagree.  apparmor is actually quite good with network daemons-- less so for local confinement (eg firefox)
 * lamont didn't say apparmor was worthless... just that it's not the panacea it's sold as.
<jdstrand> but still better than nothing for local confinement (every hurdle is better than nothing)
<lamont> jdstrand: so long as the user understands that it's just a hurdle
<jdstrand> jdstrand: everything is just a hurdle-- until you disconnect the network :)
<jdstrand> and for local confinement, the power cord
<jdstrand> (nice that I responded to myself, eh)
<lamont> jdstrand: is it safe to assume that the patchset isn't in git anywhere?
<jdstrand> lamont: not git for bind9
<jdstrand> (apparmor is in bzr though, but I doubt you care about that part at this point)
<lamont> XS-Vcs-Git: git://git.debian.org/~lamont/bind9.git
<lamont> I was noticing that I hadn't actually uploaded postfix to debian last night, did that, and was tossing a couple more changes into bind9 before uploading that... which is how I noticed that someone had uploaded a new bind9 to ubuntu
<lamont> so now this evening after work, I get to do more stuff, or I could save that for you.. :)
<jdstrand> lamont: as debian doesn't have apparmor, I assumed the apparmor portion would just be a diff ubuntu would carry
<jdstrand> I can do the git bit, but not until next week (I am technically on vacation right now)
<lamont> jdstrand: why?  the package hasn't diverged in the past, other than security uploads for versions that debian wasn't shipping
<lamont> iz OK.  I'll smack it around this evening
<jdstrand> lamont: why what? why apparmor at all?
<lamont> "why" == "why have an ubuntu diff and all the pain that brings"
<lamont> admittedly, BIND is not postfix...
<jdstrand> lamont: apparently my assumption was wrong wrt to git and the debian packaging
<lamont> (postfix discovers which distro it's building for at build time and does the right thing)
<Riddell> siretart: libxine1 is brining libmad onto the CDs
<asac> how can i force mutt to reply to all instead of Mail-Follow-Up: ?
<lamont> jdstrand: generally, if the debian maintainer is an active ubuntu devel (esp core team), one can expect that they're trying to do it all in one branch, unless that stops making sense...
<lamont> and "stops making sense" goes a little beyond  some other definitions....
<lamont> asac: if 'g' doesn't do it, then use cut-n-paste, your editor, and your firm confidence that you know better than the sender.
<seb128> lamont: you can't expect everybody to know about that and try to get changes to debian first though
<jdstrand> lamont: ok. well, like I said, if you'd like me to do the git stuff, I can next week.
<lamont> seb128: I can too.  It's just not reasonable.
<seb128> lamont: agreed that's better, when that doesn't happen the debian maintainer can also grab changes
<lamont> seb128: yeah.  I'm just being grumbly this morning
<lamont> while I'm grumbling....
<lamont> is network-manager supposed to auto-discover a wireless net and connect to it?  I nuked it and reinstalled it on my gutsy laptop, and now I just have manual mode...
<lamont> OTOH, gutsy is the first time that it was getting sane enough for me to consider leaving it on..
<lamont> jdstrand: and pardon my being cranky
<ScottK> lamont: You have to manually edit /etc/network/interfaces back to auto mode
 * lamont had assumed that apparmor was in debian as well, which was wrong of me.
<jdstrand> lamont: np :)
<lamont> ScottK: and how does one know it's in "auto mode"?
<lamont> and back to work for me
<ScottK2> lamont: When /etc/network/interfaces says auto
<jdong> intriguing. My macbook uses nearly 2W less power after a suspend than before.
<jdong> (I meant after waking up from a suspend vs a cold boot)
<jdong> bryce: oh btw, the xv debacle gets even weirder....
<lamont> ScottK2: lew;/
<lamont> kewl. even
<jdong> bryce: it seems like only shortly after a VT switch into X, xv causes a hang. If I wait 10 secs or more after Compiz initializes or coming out of a suspend, it works just fine.
<jdong> bryce: could that be some kind of AIGLX initialization race condition?
<siretart> Riddell: how that?
<\sh> siretart: libxine1: Recommends: libxine1-ffmpeg and suddenly we have Recommends installed by default? ,-)
<Riddell> siretart: because it depends on libxine1-plugins which depends on libxine1-ffmpeg
<siretart> Riddell: it installs recommended universe packages?
<Riddell> it's a depends.
<siretart> AFAIUI, recommends to universe packages should be installed by default
<\sh> asac: looks like that ff3 and flash-nonfree doesn't honour my sound settings from gnome...the sound is still coming from the main speakers instead of the headset (other apps are working as expecting and giving me sound on the headset)
<cjwatson> recommends-by-default isn't on yet
<cjwatson> with the exception of metapackages
<\sh> siretart: forget what I said...what riddell said is more correct
<asac_> \sh: you use sound server?
<\sh> asac_: well, what are we using by default= sound setting tells me: USB Audio  (Sennheiser)  so I think no sound server
<siretart> Riddell: -plugins is a convenience package which drags in all xine packages. I didn't expect it to be an installation candidate on the live cd.
<slytherin> jamesh: Can you please tell me (or publish somewhere) what is the format of entry to be added in rhythmdb.xml for the FM radio plugin (using tuner card)?
<cjwatson> siretart: did you intend libxine1-misc-plugins to be used instead?
<asac_> \sh: can you see if gnash works better?
<asac_> \sh: (sound wise)
<\sh> asac_: if gnash plays youtube, I can test it
<cjwatson> siretart: if so, you should reverse the order of the |-ed dependency in libxine1
<asac_> \sh: it should play a few
<\sh> asac_: can I tell ff3 to use gnash exclusively without uninstalling adobe?
<asac_> \sh: you could try to link the gnash.so to the .mozilla/plugins/ directory
<asac_> maybe that will prefer it then
<asac_> otherwise update the alternative
<siretart> cjwatson: well, we used to ship all xine modules in earlier releases. now the modules are split across smaller packages. I had an argument with the debian release team, and vorlon explained to me that not depending on all plugin packages would break partial upgrades
<siretart> I understand that this affects dapper->hardy upgrades
<\sh> asac_: I updated the alternative...but no gnash
<\sh> argl...
<siretart> TBH, I'd prefer to just drop the dependency on -plugins
<\sh> asac_: no ways ... it prefers adobe...purguing it
<pecisk> which package provides live cd grub menu at the begining? I need to translate it but I can't find which package it is
<asac> \sh: the alternative is named xulrunner-addons-flashplugin
<asac> anyway purging should help too
<asac> be sure that you have no flashplugin in your .mozilla/plugins dir
<\sh> asac: yep
<asac> who is eclipse/swf package liason for ubuntu
<cjwatson> pecisk: that isn't grub
<cjwatson> pecisk: gfxboot-theme-ubuntu is the one you're looking for
<pecisk> ok, then what it is?
<pecisk> thanks ;)
<\sh> asac: tells me all the time, that I have to install a flash plugin...gnashplugin is installed, but it gives me all the time this...(youtube, video.google. etc.)
<asac> \sh: oh i think the link is still missing :)
<asac> \sh: do ln -s /usr/lib/gnash/libgnashplugin.so $HOME/.mozilla/plugins/
<\sh> asac: ok...now...youtube works somehow, but no sound
<\sh> asac: video.google no ways to get it to work
<xivulon> If anyone has a 64bit machine + windows + 5GB free, please test Wubi on latest daily ISO
<asac> \sh: interesting ... maybe the the fluendo mp3 plugin for gstreamer works better
<xivulon> we have mixed reporst on that, and some clarification would be nice in light of the coming release
<\sh> asac:  15:52:03: ERROR: Unimplemented: MovieClip.attachAudio()
<asac> \sh: try a different youtube video ... there are a few players in use that use different swf functions afaik
<\sh> asac: well, I have tried a  lot of...even our own app (which is using flash normally) is not working ;)
<ScottK> asac: re eclipse I don't think we have one.  It's generally whoever touched it last (which thankfully isn't me any more).
<xivulon> Whether wubi works (or not) please report it to myself or evand in #ubuntu-installer
<asac> ScottK: someone claimed that latest milestone supports xulrunner 1.9
<\sh> asac: totem <foo>.flv (downloaded with youtube-dl) works like a charm :)
<brettalton> Can I get help on compiling a package into .deb format?
<brettalton> am I in the right place?
<ScottK> asac: It's going to stay not me who touched it last.  Sorry.  No time to look into it.
<asac> \sh: ok then gnash would work as well i guess
<\sh> asac: gnash doesn't play .flv just swfs
<\sh> asac: but gnash failes when opening a youtube url, (where the player comes from)..
<brettalton> can someone help me compile ProjectPier and/or KohanaPHP in .deb format?
<brettalton> KohanaPHP should be similar to phpMyAdmin where it installs to /usr/share/phpmyadmin
<\sh> asac: any possibility to set the adobe plugin to a more "noisy" mode? or how would you debug ff3 + flash plugin to find out what it does
<jakob__> Hi! The infamous "High frequency of load/unload cycles on some hard disks may shorten lifetime"-Bug:
<jakob__> What does it take to get the Debian Patch into Hardy?
<jakob__> And then as a SRU into Gutsy.
<jakob__> Patch is here already: http://launchpadlibrarian.net/12024340/debian-hdparm-fix.debdiff
<jdong> jakob__: we do not do that by default, and I assume anyone who turns on that acpi-support option wants aggressive power savings
<jdong> which doesn't come free
<Ng> that patch is not a fix, it's a workaround at best and harmful at worst
<jdong> 128 still lowers disk life just to a lesser degree
<jdong> it also saves power to a much lesser degree
<jdong> we should do a FFT on the disk activity history to predict when it's optimal to park the disk!!!
<jakob__> Well, i didn't turn on acpi-support.
<jakob__> It's the HD default.
<jdong> jakob__: what package is that against? hdparm?
<jakob__> The patch is a workaround, yes.
<jakob__> No, against acpi-support.
<jakob__> It's installed by default.
<jdong> acpi-support is installed by default, but we do not set any hdparm disk modes by default
<jakob__> Laptop HDs have crazy power managemant defaults.
<jdong> I don't see why we should be forcing a particular mode (128)
<cjwatson> jakob__: http://mjg59.livejournal.com/77672.html if you haven't read it already
<jakob__> Seen it already.
<jdong> jakob__: well I don't see why Ubuntu should blindly apply such workarounds to all systems when those affected can do it themselves
<jdong> jakob__: I don't make Ubuntu send my laptop into suspend and resume in rc2.d
<jakob__> Yeah, but the workaround is quite difficult.
<jdong> even though my particular laptop requires that :)
<jdong> my hard drive defaults to -B 1 (disabled). Setting -B 128 will lower my disk life by that argument.
<Keybuk> jakob__: I've yet to see conclusive proof of anybody with a laptop hard drive killed by their BIOS's default power management settings
<jakob__> Probably the workaround should become a independent package?
<jdong> jakob__: not to mention I have one laptop harddrive with 15 million park cycles
<jakob__> You mean, the excessive parking is not harmful?
<jdong> and it is still working
<jdong> jakob__: there's no conclusive proof of it, no
<jakob__> Ok, i see.
<Keybuk> jakob__: on all of the laptops I've looked at, the amount of parking was consistent with the manufacturers recommendations and expected life of the drive
<jdong> jakob__: the load cycle limit spec on the disk is not exactly a ticking timebomb
<Keybuk> it hasn't helped that most people pasting SMART values have misunderstood them and actually not pasted the important values!
<jakob__> Ok, so what to do about the angry users (lots of them out there)?
<Keybuk> the load cycle limit specifies when the drive will be considered "old" by the manufacturer
<jdong> jakob__: what do you propose we do? Set the wallpaper to a large bold message explaining their blogposts were false?
<Keybuk> Ubuntu increases this at a rate that would roughly coincide with the time factor of when it would be considered "old" as well
<cjwatson> jakob__: Matthew already posted a clear response and it's been largely ignored or misread; what do you propose we do?
<jakob__> Package the workaround?
<Keybuk> jakob__: users feelings have been stirred up by the media, without any technical basis for the problem
<jakob__> To make it easy to apply.
<Keybuk> the workaround isn't working around anything though
<jdong> jakob__: no other OS does something this silly
<jdong> jakob__: and your workaround penalizes (parks more often) properly working hard drives
<cjwatson> we package workarounds to real problems, not injured feelings
<Keybuk> it's a workaround for bad publicity
<Keybuk> not a workaround for technical problems
<jakob__> Well, Debian does it...
<cjwatson> if it is demonstrated to be a real problem, then it becomes a different matter
<jakob__> Ok. Then the Bug shouldn't be critical?
<\sh> jakob__: tell those users to buy a sun x4500 with 48 500g sata drives...and that they have to renew them every year at least once...even if the manufacture of the drives are not saying they are old...what you have in your desktop is more crappy then that what you have in your laptop...regard the fact, you are travelling with your laptop in suspend/switched off mode a lot more then you do with your desktop/server
<jdong> jakob__: the only thing that I would do in Ubuntu is in the comments of /etc/default/acpi-support, warn that ENABLE_LAPTOP_MODE sets the hard disk to aggressive mgmt by default
<Keybuk> jakob__: the bug is marked critical by a user
<jakob__> I see.
<jdong> if your disk firmware or BIOS is setting insane settings.... that's not really the business of the OS to resolve
<\sh> cjwatson: the old toshiba r200 used on windows a tool which parked the drive head every time you touched the laptop a bit harder...just because to protect the user for drive damage...it harmed the user more to park the head, then to disable this tool in general
<Keybuk> jdong: arguably the OS should help
<Keybuk> (we used to fix insane DSDTs)
<Keybuk> but we've yet to see evidence of alleged insane settings
<jdong> Keybuk: but help in a more sane manner than blindly forcing -B 128
<jdong> Keybuk: monitoring how SMART values change over time could be useful for a Hardy+1 spec
<Keybuk> isn't that exactly what smartd does? :p
<jdong> Keybuk: isn't that what we don't offer by default or have a nice dbus notify bubble frontend for? :)
<\sh> cjwatson: especially this little drive is working after the laptop felt on the floor...display dead, drive alive
<Keybuk> that's a different matter :)
<jakob__> Probably make the pm setting GUI-configurable?
<Keybuk> jakob__: e.g.
<Keybuk> 193 Load_Cycle_Count        0x0032   059   059   000    Old_age   Always       -       412916
<jdong> Keybuk: oh btw, do I cry to you if sysfs power supply sucks at detecting that my ac cord is unplugged?
<Keybuk> from my own laptop
<Keybuk> it self-claims that the drive has 59% of its load cycle count left
<pecisk> in which package I can find graphical installer translations?
<Keybuk> until it is considered old
<jakob__> Hm those values are seldum linear
<Keybuk> it's about 18 months old, and the drive is manufacturer rated for three years
<jakob__> seldom
<Keybuk> jakob__: the entire point of the three digit ones is that they are normalised
<Keybuk> it's the last number that's never linear
<cjwatson> pecisk: debian-installer
<cjwatson> pecisk: (I know it's a little weird to look there, but all the installer translations are collected there)
<Keybuk> (and in most of the hysteria, it's only the last number people have looked at - and compared it to a number somebody once plucked out of the air)
<pecisk> :))
<pecisk> thanks guys
<jakob__> Retracting while on AC power is quite useless, the drive can't know about that.
<jakob__> Ok, the dev position is that it doesn't harm either... Probably, yes.
<Keybuk> quite useless ?
<jakob__> Yes
<Keybuk>  * Scott uses his laptop in bed while plugged into AC power, he'd like it to not overly burn him or have head crashes
<jakob__> Dropping it with a power cord plugged in is unusual
<jakob__> Hmm...
<ScottK> Actually my most common laptop drop scenario is tripped over the power cord.
<Keybuk> I think that the only time I've ever "dropped" a laptop has been *because* of the AC cord!
<jakob__> ^^
<jakob__> Have you applied the workaround?
<jakob__> The "workaround"
<Keybuk> I have no reason to
 * ScottK just leaves it all in it's default configuration.
<Keybuk> 193 Load_Cycle_Count        0xc720   088   214   032    Old_age   Offline      -       222788708911008
<Keybuk> (pretty much proof that the load cycle count doesn't kill hard drives)
<jakob__> lol
<Keybuk> that one still works just fine
<jakob__> Looks like corrupt data
<Keybuk> nah
<Keybuk> it came out of a Sky+ box
<Keybuk> they have *really* aggressive power management by default
<jakob__> Age?
<Keybuk> a few years
<Keybuk> less than 5
<jakob__> That's 807380 load cycles.
<jakob__> PER SECOND.
<Keybuk> err, more than 5
<jakob__> 222788708911008/5/365/24/3600
<jakob__> +/- few years doesn't make a difference here. That's corrupt data.
<Keybuk> they pretty much do "load mpeg frame", "park", "unpack", "load mpeg frame", etc.
<jakob__> Yeah, but nut 100000 times a second.
<Keybuk> 50,000
<Keybuk> since it counts load and unload
<Keybuk> 0.2ms response, that's about right
<Keybuk> but pretty much proves that
<Keybuk>  a) you can't trust that number for anything
<Keybuk>  b) its value is meaningless
<Keybuk>  c) hard-drive manufacturers hate you
<jakob__> ;)
<Keybuk> I went digging last time this came up
<cjwatson> even if it is corrupt: if it can be corrupt in one drive, it can be corrupt in another, even if the resulting number is smaller
<Keybuk> and proved that according to the manufacturer, you can't operate a hard drive within the usual temperatures for a desktop computer
<cjwatson> for evidence you need an actual scientific controlled experiment
<jakob__> Keybuk: You can't what?
<Keybuk> jakob__: the drive in my desktop is usually about 31Â°C iirc
<Keybuk> (I put a thermometer on it)
<pecisk> in which package I can find network-manager GUI strings? I can't find it :(
<Keybuk> it's only rated by the manufacturer up to 28Â°C
<jakob__> Really? Strange drive...
<seb128> pecisk: network-manager-gnome
<jakob__> Another point is that the load-unload click is
<jakob__> 1) annoying
<jakob__> 2) raises latency
<jakob__> That's why i applied the workaround.
<pecisk> seb128: https://translations.launchpad.net/ubuntu/hardy/+source/network-manager-gnome/+pots/network-manager-gnome/lv/+translate
<pecisk> it says it can't find it
<jakob__> I don't know if "annoys people" is enough to do something about it. Is it?
<seb128> pecisk: the source network-manager-applet
<pecisk> ok, thanks
<seb128> you are welcome
<cjwatson> "annoys people" is not enough if the workaround causes damage to other people's systems
<cjwatson> which has been alleged here
<jakob__> Would a patch that makes the pm setting configurable through some /etc file make it through? I'd probably write that then.
<cjwatson> surely it is already configurable in /etc/hdparm.conf
<jakob__> Not after resume?
<jakob__> Because of that users download strange stuff from forums and drop it anywhere in their systems.
<jdong> hook restart hdparm into resume?
<jdong> *shrug* sounds possibly reasonable
<jakob__> Yes, something like that.
<cjwatson> I'm sorry, but we cannot prevent users downloading strange stuff from forums and dropping it into their systems
<cjwatson> I know that the ubuntuforums guys try to keep the level of that sort of thing under control
<Keybuk> cjwatson: perhaps its time to resurrect that idea of not giving users root on their own machines? <g>
<jakob__> You can. By making it configurable by default.
<jdong> yeah, we do, but again users tend to come up with interesting workarounds faster than we can read them :)
<cjwatson> jakob__: that won't actually help
<cjwatson> people will continue to fail to find the configurability for one thing or another, and instead do something else
<jakob__> Yeah, of course.
<cjwatson> making it configurable on the desktop might help
<cjwatson> something in /etc probably won't make a whole lot of difference
<jakob__> But in this case, the configurability doesn't exist.
<cjwatson> though for things that are configurable on the desktop, we need to be very sure that we completely understand the issues and can explain them clearly in the UI
<cjwatson> otherwise it's:
<cjwatson> Make my computer work one way <-----------> Make my computer work a different way
<cjwatson> possibly s/work/break/g
<jakob__> Yeah, of course.
<jakob__> But hdparm should be hooked into resume.
<jakob__> Because the hdparm.conf is quite pointless otherwise,
<cjwatson> I think that would be reasonable
<jakob__> (when on a laptop)
<jakob__> But it doesn't know about AC or batt then
<jakob__> Just leave that to laptop-mode..?
<pitti> seb128: sorry, have class now; I think I fixed the retracer, but we lost some bugs due to untagging and crashing
<pitti> seb128: do you think you can take a look at the log, re-tag some bugs, and check whether it works now?
<seb128> pitti: will do, thanks
<Keybuk> I've always mused how hardware events get dealt with during suspend
<Keybuk> if you unplug a device while suspended
<Keybuk> how does it know?
<LaserJock> my computer knows eeeeeverything
<jakob__> Hooking hdparm into resume... There is a kernel argument "nohdparm" that has to be obeyed.
<jakob__> So it's not _that_ trivial.
<Keybuk> surely you just /etc/init.d/hdparm restart ?
<jakob__> Ah. Right. That handles the kernelarg.
<jakob__> "Feature freeze" means that can't get into hardy, right?
<jakob__> Hm, won't that overwrite laptop-mode settings at resume?
<Keybuk> sodomy non sapiens
<jakob__> Anyway. Does somebody think about writing a patch for this?
<jakob__> If not i'd probably try.
<jakob__> If somebody would probably commit it then.
<Keybuk> jakob__: PPA :-)
<jakob__> Keybuk: Uhmm, which of these? http://en.wikipedia.org/wiki/PPA
<Keybuk> Pro-pedophile activism
<Keybuk> oh man
<Keybuk> jakob__: this one https://help.launchpad.net/PPAQuickStart
<jakob__> Thx :)
<mrcheeks> Can I ask about a hardy related bug here?
<jakob__> I got to go now, thanks for the discussion, i'll do something about the hdparm-resume-stuff next week.
<Keybuk> mrcheeks: if you have a patch for it, sure
<Keybuk> mrcheeks: if you have more information, it's better to just add it directly to the bug
<mrcheeks> Keybuk:I don't know how to fix it, so I don't have the patch... I am not able to login from gdm or a terminal, I guess it is a bash issue
<Keybuk> mrcheeks: #ubuntu would be more able to help you
<mrcheeks> thanks
<\sh> soren: is it possible to have sound output in one or more xen instance?
<pitti> seb128: ok, class is over
<pitti> seb128: taking a look now
<geser> pitti: Please give-back delo. It should build now with the fixed pkg-create-dbgsym. Thanks.
<pitti> urllib2.HTTPError: HTTP Error 403: Forbidden
<pitti> meh
<pitti> geser: done
<DktrKranz2> pitti: stani confirmed Feisty is not affected by bug 124896. Can you delete 0.8.2a+repack-1ubuntu0.7.04 from feisty-proposed?
<ubotu> Launchpad bug 124896 in spe "spe 0.8.2a+repack-1 fails with python-wxgtk2.8" [Medium,In progress] https://launchpad.net/bugs/124896
<pitti> seb128: meh, hardy apport chroot is all crash-o-rama due to p-lp-bugs
<seb128> :-(
<pitti> seb128: I guess I will install the upstream trunk patch on Monday
<pitti> I just need to leave soon
<seb128> ok
<pitti> so if you want to give it a shot, please go ahead
<seb128> ok, I might have a look
<pitti> seb128: use bug 194406 as test case
<ubotu> Launchpad bug 194406 in gnome-utils "gnome-dictionary crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/194406
<pitti> I opened it
<seb128> would you suggest rather picking changes or trying to use trunk?
<seb128> ok
<pitti> it needs apport-chroot login (see history), edit python files, save, re-tagbug, run crash-digger
<pitti> wash rinse repeat
<pitti> seb128: I honestly don't know
<seb128> ok, I'll manage
<seb128> thanks for the efforts you already put into it
<pitti> seb128: hm, now that I opened it you should actually be able to use "apport-retrace -s 199406" in the chroot
<seb128> I should be able to do those changes
<pitti> that's much quicker than re-compressing the chroot everytime and calling the digger
<seb128> ok, cool
 * seb128 hugs pitti
<pitti> so, edit the python, call apport-retrace -s 199406 until it works
 * pitti hugs seb128, thanks
<dholbach> MOTU Q&A Session in #ubuntu-classroom in a bit
<pochu> How's alpha 5 coming?
<davmor2> pochu: getting there :)
<pochu> davmor2: cool. It's targetted for today, right?
<davmor2> as far as I know.  Most of the cd's are tested a few bugs but nothing really major anymore
<slangasek> yes, it's still targetted for today
<slangasek> sooner if someone wants to help test ubuntu studio, xubuntu images
<davmor2> slangasek: burning Xub now is it just the desktop?
<Keybuk> slangasek: so, one piece remains
<slangasek> just desktop this time, yes; alternates were oversized and I got no response from xubuntu devs to my pings about it
<slangasek> Keybuk: ?
<Keybuk> change the default common-auth in libpam-runtime, this would still seem to require postinst fu to change the existing common-auth since it won't do it othewise
<Keybuk> OR
<Keybuk> apply sed-fu in libpam-thinkfinger postinst to modify common-auth when it's installed
<Keybuk> OR
<slangasek> Keybuk: well, there's existing pam postinst fu for upgrading to a new default common-auth
<Keybuk> use auth-client-config to change it
<Keybuk> slangasek: execpt the existing fu doesn't get used except on install
<slangasek> er, not true unless someone broke it?
<slangasek> if [ -z "$2" ] || dpkg --compare-versions "$2" lt 0.76-17
<slangasek> ||
<Keybuk> ah, so I could just increase that version?
<Keybuk> wouldn't that break the "respect the user deleting the conffile" check though?
<Keybuk> since it'd put them all back
<slangasek> and stow the md5sum of the current config file in the list
<slangasek> ummm... I suppose, but I'm generally uninterested in use cases that involve users willfully breaking their setup :)
<Keybuk> I just mention it, since the comment in that file implies the maintainer wanted to preserve that
<Keybuk> and since the maintainer is either you
<Keybuk> or a prior incarnation of you
<Keybuk> ... :)
<davmor2> does anyone know the current state of gvfs' obex-ftp module?
<slangasek> Keybuk: well, since I failed to implement my comment correctly, feel free to ignore it too :-)
<Keybuk> slangasek: :-)
<slangasek> we can fix it up later, low priority
<Keybuk> slangasek: so do you think that libpam-runtime is the right place to do this?
<jdong> pitti: may I try to plea the case to you that the two-batteries-in-gpm issue was fixed wrongly?
<Keybuk> if so, should that recommend the other package?
<jdong> pitti: i.e. sure "a battery" is not shown anymore but IMO the wrong one is being shown
<slangasek> Keybuk: yes to the first, for the second I have no opinion
<jdong> pitti: or do you feel this should be a bug filed against the kernel or hal for sysfs battery readouts sucking?
<Keybuk> pam is ok if a module mentioned in common-auth doesn't actually exist?
<slangasek> the config does need to be tested to make sure it works when the module doesn't need to exist, but AFAIK it's /supposed/ to work
<Keybuk> (I assume so, since pam_foreground mentioned in common-session doesn't exist)
<slangasek> yeah, should still be tested to make sure there are no differences wrt "optional" vs. "sufficient" modules
<Keybuk> slangasek: so why isn't the current common-auth md5sum in the common-auth.md5sums file?
<slangasek> Keybuk: because we don't bother adding it there until the file itself has been superseded
<Keybuk> ah right
<Keybuk> slangasek: http://people.ubuntu.com/~scott/pam_0.99.7.1-5ubuntu5.debdiff
<Keybuk> slangasek: does that looks reasonable to you?
<slangasek> Keybuk: is 'try_first_pass' really appropriate here? is pam_thinkfinger ever going to prompt for a password?
<slangasek> doesn't hurt much if it doesn't, and would be consistent with a config generated by the new pam framework stuff, so no big deal
<slangasek> otherwise, looks good
<Keybuk> slangasek: it does prompt, yes
<Keybuk> since you obviously want to be able to swipe your finger *or* type a password
<slangasek> that's true, but what does pam_thinkfinger think it's going to do with the password when it has it? :P
<slangasek> I'd call that a bug in pam_thinkfinger for prompting for things that are none of its business
<Keybuk> nothing, it just passes on to the next authentication
<Keybuk> does PAM give you any way to prompt for something that's not a text entry field? :)
<slangasek> there's a Linux-PAM extension for binary prompts, yes...
<Keybuk> can you have multiple PAM modules active at once
<Keybuk> e.g.
<slangasek> it's basically a poor reimagining of SASL :-P
<Keybuk> simultaneously have pam_thinkfinger and pam_unix waiting for input
<Keybuk> with one cancelling the other?
<slangasek> nope
<Keybuk> so it wouldn't work your way ;)
<Keybuk> you'd have to swipe your finger, or press some key to move on to trying a password, no?
<slangasek> yeah, with that constraint, that's valid
<slangasek> unfortunately, it means that if your next module in the stack is something like, say, pam_opie, you don't get a useful prompt
<Keybuk> opie?
<slangasek> one-time-pass module
<Keybuk> I think upstream basically just want to bypass PAM for the biometric stuff
<Keybuk> since it doesn't quite fit the model
<slangasek> (hmm, worse would be trying to stack with SecureID... :)
<Keybuk> it's not so much a stack, as an alternative
<slangasek> for PAM values of "stack"... :)
<Keybuk> e.g. at a login prompt, you shouldn't even need to ask for a username
<slangasek> davmor2: hrm, I definitely haven't noticed bug #194007 in my testing of Ubuntu, I think I would've noticed if my keyboard had suddenly switched out of Dvorak... was this Kubuntu-specific, or maybe keymap-specific?
<ubotu> Launchpad bug 194007 in ubiquity "Ubiquity keyboard is not being setup after world map." [Undecided,Confirmed] https://launchpad.net/bugs/194007
<evand> slangasek: it's just not picking a proper default.  So you'll end up on USA - USA every time.
<slangasek> Keybuk: so what's the prompt that pam_thinkfinger gives the user as the alternative?  Does it ask for the username first, or the password?
<slangasek> evand: oh, so it should be hinting a keyboard preference and it isn't?  Fair enough
<evand> slangasek: indeed, I've updated the bug title to reflect that
<slangasek> I don't think I'll bother release-noting that one
<davmor2> slangasek: No across the board.  It does actually change your keyboard.  But I for example set my language as english and time zone as London.  With the old ubiquity this set my keyboard to Uk English.  Now however it stays on Us English until you change it.  This used to be automatic.
<slangasek> davmor2: right, understood
<davmor2> s/does/doesn't sorry
<Keybuk> slangasek: it doesn't ask for a username yet
<Keybuk> right now you get "Password or swipe finger"
<slangasek> Keybuk: hrm.  unfortunately there'll be cases where PAM already knows the username anyway, so you don't want to prompt for it unconditionally... otherwise, a username prompt would let you handily bypass prompting for passwords that don't belong to it
<davmor2> wine is a bit bust seg faulting
<cjwatson> evand,davmor2: weird, I'm sure it selected UK for me
<evand> cjwatson: I'd be very surprised if it did.
<evand> I can't for the life of me figure out why this is happening though.  There haven't been any console-setup changes between the version that worked and this one.
<davmor2> cjwatson: It's happened on every live install so far 64 bit and 32 bit on Ubuntu and Kubuntu
<cjwatson> oh, I might have forced it in the bootloader
<cjwatson> my suspicion would be timezone widget changes
<Keybuk> slangasek: this is all, it has to be said, "future versions"
<evand> cjwatson: I thought so too at first, but it's basically the same code for that.
<slangasek> Keybuk: yes :)
<davmor2> cjwatson: Kubuntu's has though has it?
<evand> davmor2: no, kubuntu uses its own timezone widget
<Keybuk> slangasek: they want to get to the point where you can walk up to a computer and just swipe your finger
<davmor2> same error on kubuntu it's where I first noticed it
<Keybuk> it'll do a user switch and login there and then
<slangasek> Keybuk: aieee
<davmor2> evand: Now you see that makes a lot more sense :)
<davmor2> sorry back to my question earlier.  Gnome-vfs-obexftp got upgraded to main the day after the whole backend got switched to gvfs/gio which means that the bluetooth applet does next to nothing again is this likely to get fixed before hardy is released or is it more likely to be a Intrepid.
<davmor2> slangasek: Xubuntu isn't booting I'll try a reburn but it could be dead :(
<slangasek> davmor2: mm, at what point does it fail to boot?
<davmor2> pass but I did the check disk for errors and it's shown one up hence the reburn.
<dholbach> Library Packagin Session in #ubuntu-classroom
<slangasek> oh bother, how did I manage to get my UI in Spanish on my last login
<dholbach> slangasek: it must have been the end of a very long night :)
<slangasek> dholbach: it doesn't bother me too much, except when I'm trying to navigate mutt and all the keybindings are changed
<dholbach> hehehe, I can imagine :)
<dholbach> or should I say jÃ©jÃ©jÃ© (in a good impersonification of pedro_)
 * pedro_ hugs dholbach
<slangasek> :-)
<pedro_> it should be the default language ;-)
 * dholbach hugs pedro_ back
<dholbach> sure... like seb128 would vote for french :)
<pedro_> why? he's german
<slangasek> haha
<dholbach> Alsatian :)
<dholbach> anyway... I call it a day - see you on monday and have a great weekend :)
<ogra_cmpc> ciao dholbach
<dholbach> bye ogra
<dholbach> and give sistpoty some love in  #ubuntu-classroom !
<slangasek> davmor2: any luck with the xubuntu reburn?
<davmor2> slangasek: trying it now
<ogra_cmpc> cjwatson, will you kill me if i add a edubuntu-desktop.postinst to -meta ? i think it needs a notification to re-login now that its always installed as addon
<Kuni> sorry to bring this here, but over at +1 we were wondering what the status is on alpha 5. Could someone clarify please?
<ogra_cmpc> (the artwork changes wont take effect without logging out, apps appear in the menu indeed)
<slangasek> Kuni: http://iso.qa.ubuntu.com/qatracker/build/all shows the testing status of the images that are being prepared for the release; when we have adequate test coverage to ensure we're not releasing broken images, we release
<Kuni> sweet, thanks
<davmor2> slangasek: still issues I'm just check all the md5sums so far they check out I'm just checking the iso against the cd now
<slangasek> ok
<slangasek> which image is this, precisely?
<davmor2> slangasek: cced43ba9e39f1853c06f890ebf4212e *hardy-desktop-amd64.iso
<davmor2> slangasek: I think it's the re-writeable disc at fault
<davmor2> so I'm going to write it to a standard disc
<slangasek> ok
<davmor2> slangasek: that's craked it :)
<davmor2> slangasek: printing from FF3B3 doesn't work :(
<slangasek> davmor2: crash in texttops, or are you seeing a different problem than the one I just tested?
 * Keybuk wonders what tracker is indexing
<davmor2> slangasek: stgraber: http://ubuntu.pastebin.com/f6308f46f that's stgrabers cups issue
<slangasek> ok, so it seems to be a cups problem of some sort?
<slangasek> oh, 'empyt print file', hmm
<davmor2> it only happens with FF3
<slangasek> ok, is this being filed as a bug report?
<davmor2> doing it now
<slangasek> ok, please give me the bug # when you have it for release-noting
<Keybuk> errr...
<Keybuk> what the fuck is ~/xmp ?
<Keybuk> actually ~/xmp:-
<ogra_cmpc> lsof ?
<davmor2> slangasek: how permanent is the pastebin can I link to it or should I copy the info across to the bug report?
<Keybuk> "convert" apparently
<slangasek> davmor2: copy it across
<davmor2> np
<ogra_cmpc> Keybuk, a freaked out nautilus thumbnailer ?
<davmor2> slangasek: bug 194486
<ubotu> Launchpad bug 194486 in firefox-3.0 "printing in Firefox 3 Beta 3 is broken" [Undecided,New] https://launchpad.net/bugs/194486
<Keybuk> I have a feeling it might be a freaked out tracker indexer
<Keybuk> something like
<slangasek> davmor2: thanks
<ogra_cmpc> uding convert ?
<Keybuk> tracker sees file, runs convert, convert freaks and dumps to ~/xmp:-, tracker sees file change, runs convert, convert freaks...
<ogra_cmpc> *using
<Keybuk> it is tracker too
<Keybuk> trackerd
<ogra_cmpc> ah
<davmor2> slangasek: Xubuntu is downloading the language packs in ubiquity and taking forever over it.
<Keybuk>  \_ tracker-extract /home/scott/xmp:- image/gif
<ogra_cmpc> i thought that was from imagemagic
<Keybuk>      \_ convert /home/scott/xmp:- xmp:-
<ogra_cmpc> why does tracker convert images ???
<Keybuk> JAAAAAAAAAMIE!
<ogra_cmpc> indexing must be fun on kwwii's disk with that
<LaserJock> ogra: my guess would be to provide the thumbnails in the search results
<ogra_cmpc> oh, fun
<Keybuk> basically, from what I can see
<Keybuk> tracker is chasing its own tail
<ogra_cmpc> should we rename it to beagle ?
<slangasek> TheMuso, persia: any chance of getting some testing of the ubuntustudio images?
<TheMuso> slangasek: Are they ready to test? If so, I can do a bit of testing.
<_MMA_> I can also.
 * TheMuso syncs.
<davmor2> slangasek: I feel sorry for anyone on dial up it going to be another 25 minutes ish for these lang packs
<slangasek> TheMuso: yes, though I see I've got the wrong ones linked yet from the tracker, sorry about that
<slangasek> TheMuso: please be sure you grab 20080221 rather than 20080220
<TheMuso> slangasek: IF ITS THE CURRENT ONE< I'm getting it.
<slangasek> hrm, ubuntustudio images are supposed to be DVD-sized then, not CD-sized?
<slangasek> they're > 700MB, but not marked as oversize :)
<TheMuso> Yes they are DVD size.
<slangasek> ok
<_MMA_> slangasek: The page itself says DVD. Though, some people still have a hard time burning it in windows. Even trying to use a DVD.
<slangasek> heh
<davmor2> slangasek: Xubuntu is okay but should it download the language packs?
<TheMuso> Hrm. I pulled the -es langpack from our seeds yesterday, yet they are still showing up in our CD report as uninstallable.
<TheMuso> slangasek: Are the -es issues supposed to be fixed in the archive now?
<slangasek> TheMuso: they are now fixed in the archive; I didn't bother rerolling the images for that issue, do you think it's important enough to do so?
<slangasek> davmor2: if you chose a language that requires downloading them from elsewhere, I imagine so?
<TheMuso> luisbg: Do you want -es on the latest alpha?
<TheMuso> slangasek: I don' but others on our team, for example luisbg might.
<davmor2> slangasek: I choose english?
<slangasek> davmor2: well, right :)
<davmor2> slangasek: I think though that it pulled down all of the language packs considering it took 25 minutes on a 20 meg connection
<luisbg> I'm spanish as a lot of this planet
<luisbg> it's the 3rd biggest language AFAIR
<slangasek> davmor2: er, odd, ok
<luisbg> I don't mind not having it in alpha
<luisbg> but having it soon is a MUST
<davmor2> slangasek: other than that It's okay
<_MMA_> TheMuso: slangasek: Well I'd like to think more -es users were testing but I think its ok to go ahead as is.
<TheMuso> _MMA_: same
<luisbg> There is a huge test base in Spain and spanish speaking countries
<luisbg> GNU/Linex, Guadalinex, Bardinux, are a few of Ubuntu Derivatives made by spanish governments
<luisbg> they hire companies to make local themed or local purpose derivatives
<slangasek> if you think not having all of the -es langpack packages being installable from the disk will break the ability to get good feedback, I'm happy to reroll
<_MMA_> luisbg: I'd like to hear from them about Ubuntu Studio then. :P FOr now, I think its fine.
<slangasek> otherwise, none of the images have been respun for this particular issue, and I think the fallback is just that it has to go to the network to grab the ispanish package...
<luisbg> slangasek, in a test build with possible installation from network
<luisbg> it's ok
<TheMuso> Gah still syncing  here.
<luisbg> brb
<zdzichuBG> tjaalton: xf86-video-intel-2.2.1
<zdzichuBG> tjaalton: was released, with fix for https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/178505 ;  could you please package it?
<ubotu> Launchpad bug 178505 in xserver-xorg-video-intel "TV-out missing from xrandr output on Thinkpad z61t with Intel" [Medium,Confirmed]
<cjwatson> ogra_cmpc: I don't mind, but it sounds like maybe it would be more appropriate in the artwork package
<tjaalton> zdzichuBG: next week, unless someone beats me to it
<zdzichuBG> ok, thanks.
<ogra_cmpc> cjwatson, hmm, probably, tes
<ogra_cmpc> *yes
<slangasek> TheMuso: what news on ubuntustudio?
<mathiaz> slangasek: have you send an email to test ubuntu-server iso from iso.qa.u.c ?
<slangasek> luisbg: la instalaciÃ³n de alpha-5 desktop-amd64 en espaÃ±ol rula bien
<slangasek> mathiaz: no, I don't typically coordinate ISO testing directly except when we're missing test coverage and I need to chase people down
<mathiaz> slangasek: hum.. So how can I be notified that a new ubuntu-server iso is availabe and should be tested ?
<davmor2> slangasek: 64 server is tested there's only 32bit left server wise
<davmor2> oh and sparc anyone with a spare sparc box ?
<slangasek> mathiaz: a) monitor http://iso.qa.ubuntu.com/qatracker/build/all, b) ask stgraber who normally coordinates this, c) lurk on #ubuntu-testing around milestone time?
<mathiaz> slangasek: ok. I'll keep that in mind.
<davmor2> http://iso.qa.ubuntu.com/qatracker/build/all/untested
<slangasek> mathiaz: I'd be happy to have a better process for notifying testers of new ISOs, that means fewer tests I need to do myself :)
<davmor2> slangasek: iirc at wednesday's meet there was talk of automating this process.  Also anyone who has signed up to do tests can get emailed as a reminder that the images are up and need testing (unfortunately this time round stgraber broke it :) )
<slangasek> davmor2: heh, that would be a welcome improvement
<mathiaz> well - that's what I was waiting for.
<davmor2> slangasek: The email thingy has been in the tracker for a while but it needs to be switched on from the profile page.
<mathiaz> Usually I start testing the ubuntu-server isos when I receive the email from the iso tracker
<davmor2> mathiaz 32bit and sparc need testing.
<slangasek> I'm actually already testing 32bit
<slangasek> (next wishlist bug: some way to indicate what tests are in progress...)
<davmor2> slangasek: on the tracker test in progress
<slangasek> huh?
<davmor2> slangasek: if you go to the tracker page there is a link for tests in progress
<slangasek> davmor2: that doesn't tell me what I want to know
<davmor2> Oh right :)
<slangasek> "in progress" here only means "some parts have been reported as tested"
<davmor2> ah true
<slangasek> where I want to know "someone over there has started downloading image $foo, so others shouldn't duplicate that"
<TheMuso> slangasek: COnnection kinda choppy here, only just got it synced, but am heading off for the weekend in a bit. _MMA_ is doing a test install/test now.
<davmor2> slangasek: mind you it's not too bad to have more than one pair of eyes viewing the image to be fair.
<_MMA_> (94% complete)
<mathiaz> davmor2: right - but if we could assign the test to different people, we'd get more coverage.
<mathiaz> davmor2: but that depends on the test cases.
<mathiaz> davmor2: the one for ubuntu-server are well defined and targeted for a different configuration each time.
<mathiaz> davmor2: I'm not interested in knowing that three people have sucessfully tested that openssh is working correctly.
<mathiaz> davmor2: I'd rather now that openssh, mysql and postfix are all working correctly.
<davmor2> true.
<mathiaz> but for more generic test, such as boot the livecd and poke around - then having more people doing the same test case is usefull.
<slangasek> _MMA_: 94% of the download, or the install?
<slangasek> davmor2: it is bad if you only have enough testers to get 1 test each, and they lose time duplicating efforts; and if you have more testers, knowing who's downloading what already helps you still distribute the tests more evenly
<_MMA_> slangasek: Rebooting into install now.
<slangasek> _MMA_: ok
<davmor2> slangasek: mathiaz: both true.  On the tracker though there is a big list of who's meant to test what.  Heno swapped most of my tests around because some area's where covered really well while others sucked.  So as people sign up who is testing what can be monitored.
<davmor2> http://iso.qa.ubuntu.com/qatracker/subscriptions
<slangasek> that would be sufficient if all the people signed up for testing were available 24h a day and were notified of new ISOs in a timely manner :)
<slangasek> it doesn't help if you have opportunistic testers and need ad hoc coordination of testing of the untested images
<luisbg> slangasek, nice spanish, where did you got that from?
<_MMA_> slangasek: I grabbed and installed the 32-bit disk from 20080220. Looks good here.
<davmor2> slangasek: I have a small rsync script which used to download 22 images.  However with the edubuntu cd's being all over the place now I need to modify it.  So quite often I test images that aren't tested :)
 * _MMA_ wishes he could do a 63-bit one but just cant nuke his main desktop yet.
<_MMA_> *64
<davmor2> _MMA_:  64bit one what?
<_MMA_> Ubuntu Studio
<stgraber> A good way to know what needs testing is : http://iso.qa.ubuntu.com/qatracker/testcases
<stgraber> So you can make sure every install options of debian-installer or ubiquity have been tested at least once
<Amaranth> bryce: did you see https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/175774/comments/25 ?
<ubotu> Launchpad bug 175774 in dell "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [High,Fix committed]
<bryce> Amaranth: hah!  :-)
<stgraber> slangasek: Can I remove the two Edubuntu Desktop builds ? (IIRC we don't have Edubuntu Desktop but only the Add-on CD)
<slangasek> stgraber: the ones that are disabled?  yes, they can be removed
<slangasek> edubuntu desktop exists, but isn't in a state to include in this alpha
<stgraber> slangasek: done. I'm now downloading Ubuntu Alternate and will do a LTSP + LVM + encrypted FS and then install the Edubuntu Add-on
<slangasek> stgraber: ok, thanks
<slangasek> _MMA_: umm... you know 20080220 wasn't current, right?
<slangasek> luisbg: many years of practice. :)
<luisbg> slangasek, how so?
<slangasek> _MMA_: did you really test 20080220, or 20080221 which is current?
<_MMA_> Sorry. 21. :P
<slangasek> luisbg: I have a degree in Spanish
<luisbg> slangasek, nice
<slangasek> _MMA_: awesome, I'll go pull the lever then :)
<slangasek> stgraber: the edubuntu add-on test is the only one outstanding, then; do you have an idea how long it'll take?
<slangasek> mathiaz: what bit of the postgresql install failed for you?
<mathiaz> slangasek: postgres doesn't start
<slangasek> doh
<mathiaz> slangasek: sudo -u postgres psql -l fails with unable to connect to socket
<mathiaz> slangasek: alpha4 already had the problem.
<mathiaz> slangasek: but I hadn't had time to investigate the problem.
<mathiaz> slangasek: I need to file a bug and milestone for beta at least
<stgraber> slangasek: ltsp can take a while to install, I would expect a result in 30-40mins
<slangasek> mathiaz: right, yes please :)
<slangasek> stgraber: ok, thanks
<davmor2> slangasek: Does this mean that Alpha 5 is ready for release?
<davmor2> Right I'm off Bye
#ubuntu-devel 2008-02-23
<slangasek> that's interesting, now why would gnome-screensaver be segfaulting on unlock when the disk is full...
<cathya> hi
<cathya> is it possible to get ubuntu working on my mac?
<cathya> does ubuntu still have ppc support?
<jdong> cathya: #ubuntu is for support, please
<cathya> im there
<cathya> and its a bloody spam
<cathya> im in  ubuntu power pc as well
<cathya> it's pretty dead in there
<jdong> I'm sorry to hear that, but this channel is for development of Ubuntu and developers need it to coordinate the alpha 5 release. It is not for support
<cathya> tyo get your question noticed, i have to literally flood the channel else it's a bunhc of garb i keep getting responses from
<cathya> i just need to know if it'll work on my mac
<cathya> since i did hear some months ago that ubuntu stopped work on ppc
<jdong> there is still a ppc port of Ubuntu, but I wouldn't be able to tell you whether or not it works on your mac's hardware completely
<pkh> cathya, you asked the qn in ubuntu, someone immediately answered you with a two line answer and a link to the community port site.  what more were you looking for?
<cathya> ok jdong
<cathya> thanks, that'll do
<cathya> pkh: the two line was some community development as reference and some random user telling me bluntly NO
<jdong> what you heard is that Ubuntu no longer offers ppc as an officially supported platform, though the community has continued to maintain it :)
<cathya> while clearly it does have some form of support as jdong stated
<cathya> ah ok
<cathya> thanks
<stgraber> slangasek: it's taking a bit longer than expected. it's currently generating the LTSP chroot, then will compress it and finish the install
<slangasek> stgraber: ok; I'll still be here when you're done :)
<stgraber> slangasek: ok, installation completed. LTSP seems to work (I haven't tested with a client but nbd and tftp work) and I successfully installed edubuntu-desktop, inkscape, kalzium and kvoctrain from the Add-on CD
 * slangasek pushes the plunger
<stgraber> I basically only saw one bug with this install and it's far from an critical one :) (bug 193902)
<ubotu> Launchpad bug 193902 in firefox-3.0 "[Hardy alpha5] Firefox launcher is broken (on the top menu)" [High,Confirmed] https://launchpad.net/bugs/193902
<stgraber> probably the best alpha so far (at least for this computer)
<slangasek> cool
<okaratas> hello
* slangasek changed the topic of #ubuntu-devel to: Archive: Feature freeze | Alpha 5 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
<slangasek> okaratas: hi
<okaratas> slangasek, hi, how are you ?
<slangasek> well enough, and you?
<okaratas> i am fine, thanks.
<okaratas> i am a sleep, sorry :)
<okaratas> [reed], hello
<[reed]> "Alpha 5 includes several new features that are ready for large-scale testing.  Please refer to http://www.ubuntu.com/testing/hardy/alpha5 for information on changes in Ubuntu" <-- except I get Access denied for that URL :)
<[reed]> hi, okaratas.
<okaratas> hmm
<okaratas> You are not authorized to access this page.
<okaratas> what is the ubuntu web site problem ?
<slangasek> [reed]: yes, the URL won't be live for another half hour or so; sorry, I ought to have held the mail until it was published
<slangasek> the ISOs themselves are available
<ffm> are packages still accepted for universe for hardy?
<pochu> ffm: if you can convince the motu-release team to grant an exception, yes (for new packages, that is)
<ffm> pochu: we're on the front page of http://launchpad.net .
<ffm> pochu: GASP.
<ffm> never mind, we'll try with intrepid.
<ScottK2> lamont: You said to remind you about requesting Postfix 2.5.1 sync.  I'll take care of it.
<ScottK2> lamont: Postfix 2.5.1-1 sync requested.
<ffm> May I ask if we can introduce new packages in universe in hardy 8.04.1?
<persia> ffm: You've asked before.  The same answer applies.  Hardy is in feature-freeze, and it would need an approved exception.
<persia> (This is as true for 8.04 as for 8.04.1, although 8.04.1 needs much more justification for the exception)
<ffm> persia: ah. Well, what I am working on is undergoing a major rewrite, so I'll submit it to ibex.
<persia> ffm: Thanks.  The worry is that it will destabilise something.  Once it gets into the Ibex, it can be backported to 8.04, so it could be available, but not in universe.
<ffm> persia: can  beta software be placed into universe?
<ffm> persia: it is a _minor_ python package that won't really harm anything.
<persia> Yes, if considered of sufficient quality to be release-worthy.  Something getting a major rewrite wouldn't be a good candidate.  Also, the decisions aren't made on IRC (and I'm not one of the decision makers).  You'd need a freeze exception.
<ffm> persia: Ok. Thanks,
<lamont> ScottK2: rock on.  thanks
 * lamont messes with bind9 vs apparmor
<lamont> autoheader: warning: missing template: CALL_PTHREAD_SETCONCURRENCY
 * lamont hates auto*
<lamont> autoheader: Use AC_DEFINE([HAS_PW_CLASS], [], [Description])
<lamont> anybody know what that actually means?
<Griswold> Hello guys.  :)
<Griswold> I am working on implementing stuff for Wine
<Griswold> I came across a page about things that Wine could do upstream to help you guys out
<Griswold> Let me see if I can find it again
<Griswold> https://wiki.ubuntu.com/BetterIntegratedWineSpec
<Griswold> ^^ In that page, it says you guys need some type of console configuration.
<Griswold> Would a re-implementation of the windows' 'reg' program be enough?
<Griswold> Something like:  reg add 'hkcu\Wine\Direct3D' /v UseGLSL /d 'disabled'      be enough?
<Griswold> (To disable GLSL and enable ARB shaders, for example)
<lamont> jdstrand: was there a reason you re-autotool'ed bind9?
<Griswold> YokoZar, ping
<YokoZar> Griswold: pong
<Griswold> YokoZar, Can you read the above and give me an answer?  :)
<YokoZar> Griswold: I think we discussed this before, yes?
<Griswold> YokoZar, Perhaps.  I have been busy - can you give a quick summary just to job my memory?
<Griswold> *jog
<YokoZar> Griswold: my only worry is that the interface to reg might change - or the registry itself.
<Griswold> The interface to 'reg' will never change once implemented
<Griswold> The interface to the registry itself might, but not reg
<YokoZar> Griswold: Though, configuring GLSL is something we probably don't want to do (we're trying to cut down the interface, so accepting Wine's magic default should be best).  Stuff that we'll keep needing to configure no matter how good Wine's defaults are would be stuff like mentioned in the spec - Windows version, whether apps contained in a window or separate (which is similar to managed/unmanaged/desktop)
<Griswold> YokoZar, Ok.  :)
<Griswold> It was just an example though - quickest key I could think of that I know by heart
<YokoZar> Yeah.  Would your reg be able to do the uninstallation stuff?
<Griswold> I don't know.  Is uninstallation stuff stored in the registry?
<YokoZar> It should be yeah
<Griswold> Then yes, once implemented
<YokoZar> Windows looks somewhere when you go to add/remove
<YokoZar> So that's the other half of the puzzle, to spruce up gnome-app-install.
<Griswold> You will be able to query, add, delete, etc. registry keys
<Griswold> YokoZar, Ok.  Are you able to write the code for Ubuntu once I get reg written?
<Griswold> reg will have a built-in help and you could ask me any questions you want about its interface
<YokoZar> Griswold: Some of it.  Gnome-app-install would be someone else's work.  Adding a new applet for wine configuration I may be able to do.  The trick is it's a bit too late to get that stuff in Gnome/Hardy.
<Griswold> Ahh, I see
<YokoZar> Griswold: Anyway, thank you for taking up this feature request, it's very awesome of you and I'll help however I can.
<Griswold> Ok, awesome.  :)
<Griswold> I did some talking in the past few days to see what is the best route for Wine
<YokoZar> Griswold: It's quite plausible that it can still be done though, especially stuff that would be part of Wine (rather than part of Gnome)
<Griswold> Yeah
<YokoZar> For instance Wine's configuration applet could be a part of Wine package.
<YokoZar> So the uninstallation stuff would come later.
<Griswold> Hmm.. you could make a wine-ubuntu-config or something package
<Griswold> (I don't know the exact naming scheme, obviously)
<YokoZar> Wouldn't really matter if it were a dependency.
<Griswold> Yeah.  :)
<ScottK> lamont: You've got mail....
 * jdong locally backports mono 1.2.6 just to see what blows up :D
 * ScottK still thinks of mono as the disease that wiped him out of an entire semester in college.
<Griswold> YokoZar, Hmm... Just thought up something else for you to think about
<Griswold> Some users expect a sort of GUI for Wine where you can browse for a .exe and run it, etc.
<Griswold> Maybe a little dialog box pop-up explaining how to use Wine might be useful.  (When you install it for the first time)
<lamont> ScottK: yeah... /usr/lib/sasl2 is (uh) wrong - it'll be nice of them to change it.
<lamont> as for whether we should move from /etc/postfix/sasl to /etc/sasl, dunno..
<ScottK2> Well that part they don't seem to want to change
<lamont> I'll worry about it when someone files a bug against postfix. :-)
<ScottK2> lamont: It's a hard question.
<ScottK2> If we did manage the move, it'd be one less Debian unique piece of config documentation to keep track of.
<lamont> postfix grew the hooks and config directory specifically because the sasl package is wrong.
<lamont> config files do not live in /usr
<lamont> ever.
<ScottK2> So if we can live in /etc/sasl2 are we happy?  Is that somehow better?
<ScottK2> Agreed.
<lamont> I don't mind living in /etc/sasl2
<lamont> we just set the path to be $PATH:/etc/sasl2:/etc/postfix/sasl :)
<lamont> then document the order of finding things
<ScottK2> So something along the lines of sure, go for it, we might even move over there at some point.
<lamont> yeah
<lamont> that's my thinking, anyway
<ScottK2> I just finished scripting maintainer scripts for a conffile move in one of my Debian packages, so I have some idea how much fun that is.
<ScottK2> And if it breaks something we'll just get pitti to fix it anyway ...
<ScottK2> ;-)
<emgent> hehehe
<lamont> yeah
<emgent> pitti++
<lamont> ScottK: heh... actually, postfix doesn't actually deliver anything in /etc/postfix/sasl. :)
<lamont> win!
<ScottK2> Hmmm.  Do I put smtpd.conf in there by hand each time?
<ScottK2> I guess I must.
 * Hobbsee waves
<ScottK2> Heya Hobbsee
<Hobbsee> world blown up yet?
<emgent> heya Hobbsee :)
<ScottK2> Not so as I've noticed.
<lamont> evening Hobbsee
<Hobbsee> heya lamont
<ScottK2> I stormed off in a huff about 14 hours ago about ppaput claiming it's part of the Ubuntu sponsorship process (it's not).  Came back and filed 10 bugs against ubuntu-dev-tools.
<Hobbsee> hey emgent
 * Fujitsu waners in.
<Hobbsee> hah
 * Fujitsu kicks his D key.
<Hobbsee> oh nice, someone's finally stepped up again about the LP real name policy
 * ScottK2 thought it was Australian for something
<ScottK2> Hobbsee: What's that?
<pwnguin> i think our hardy heron looks a little sickly :)
<lamont> ScottK: claiming _what_ was part of the sponsorship process? blowing up the world? or tickling Hobbsee ?
<ScottK2> Some script that uses an LP PPA.
<lamont> LOL
<ScottK2> It's something it's author and I had discussed before and I thought had reached a clear understanding.
<ScottK2> My favorite bug was noticing the the AUTHORS file for the package is executable.
<lamont> it made less sense when I thought ppaput was an IRC ncik
<ScottK2> Ah.
<ScottK2> I'd be less annoyed about that
<lamont> AUTHORS to be executed at daybreak.  film at 11.
<ScottK2> That's about right for some of the stuff in the package.  Some of it's geniunely useful.
<ScottK2> Unfortunately they're also improving some of the things to the point beyond utility
<Hobbsee> hah
<lamont> heh
<ScottK2> Stuff like improving requestsync to spawn into an editor, but then asking you if you want to edit the bug before they show you what's in it.
<ScottK2> It's almost like they're trying to get hired as LP developers
<lamont> ROTFL
<lamont> just spawn the &^) editor, already
<lamont> and _before_ the mail is signed, eh?
<lamont> :-)
<ScottK2> Yeah
<ScottK2> There was another script in there that was a shebang and a copyright statement
<lamont> heh
<ScottK2> It appears the script was meant to do the same thing as dget -x withouth having to type the -x
<Hobbsee> ScottK2: the policy which *requires* all lp-beta users to have their real name set.
<ScottK2> Ah.
<Hobbsee> apparently it makes them feel better, or something.
<ScottK2> I get annoyed enough with the production quality LP.  I can't imagine wanting to use it when it's less mature.
<lamont> ScottK2: maybe it's just that they don't get to work on any other pacakges?
<Fujitsu> ScottK2: But using ege means you can see the braineadd features an complain about them before they're release.
<ScottK2> Well they're all (I think) motu, so they've got several thousand choices handy.
<Fujitsu> An I hate my keyboar.
<Hobbsee> ScottK2: heh :)
<Hobbsee> ScottK2: at least you can scream faster, and htey tend to listen.
 * lamont hands Fujitsu a 'd' key
<Fujitsu> lamont: Thanks.
<lamont> ScottK2: lp-beta is love
<ScottK2> Fujitsu: Sure.  Then I file bugs and they tell me putting two little triangles in the UI fixes all the confusion.
<Fujitsu> I'll hopefully be able to get a new keyboar from Dell soon...
<Fujitsu> ScottK2: Correct.
<lamont> there's also the trick of screaming about something and actually having the fix for a while _before_ it shows up in production
 * Hobbsee hands Fujitsu another 'd' key, as the last one appears not to work
<Hobbsee> lamont: yeah, exactly
 * jdong suggests Fujitsu map unused F12 key to d with xmodmap ;-)
 * ScottK2 has been learning the email interface lately
<Fujitsu> I note the more braineadd features are those which we can't test on ege.
<Fujitsu> Like emailing, Soyuz...
<Hobbsee> heh
<ScottK2> Any project that doesn't have a solid testbed is doomed
<Hobbsee> i'm not sure that soyuz is an accurate representation of the rest of the project's quality, though
<ScottK2> The only exception is if you do a huge amount of up front engineering
<Fujitsu> ScottK2: It does have a good testbed, just not with users.
 * Fujitsu has removed the mechanism from the d key.
<ScottK2> Fujitsu: Ah, so it's a good internal test bed for developers?
<lamont> there are certain issues that show up when a product is designed and built by people who never use it, other than in what _they_ believe is the normal use model
<Fujitsu> That's why edge is important.
<Fujitsu> An why specs shoul be public
<Hobbsee> lamont: this is where ScottK2's quote about the LP devs being very happy to show you how you should be using LP comes in, right?
<ScottK2> lamont: But they all know exactly how it's going to be used and will be glad to tell us how we're doing it wrong.
 * Hobbsee grins
<ScottK2> ;-)
<lamont> Hobbsee: yep
 * lamont is reminded of a discussion on exactly how metacity keyboard focus should work
 * ScottK2 suddenly remembers it's late and he has to wash his hair.
<lamont> the most memorable comment from _that_ discussion was "Why do you even use gnome?"
<Fujitsu> Hahha.
 * ScottK2 tends to wonder about that.
<lamont> in the end, debian/patches/001_strict_focus.patch was born.
<lamont> and then warty released a couple months later
 * ScottK2 is also wondering about how long python-kde3 really takes to build.
<lamont> ScottK2: 'kde' is in the name... figure a couple hours
<lamont> minimum
<ScottK2> Yeah, well.  Probably
<Fujitsu> ScottK2: Why does it have it's own source package?
<ScottK2> Fujitsu: I've no idea.  I don't make this stuff up, I just try to fix it.
<Fujitsu> Isn't against KDE policy to have a source package that doesn't build 50 binaries?
<lamont> Fujitsu: that's the python implementation of kde, dontcha know
<lamont> or was it the kde implementation of python... I forget
<ScottK2> Fujitsu: Probably, but that's less interesting the sylpheed-claws/claws-mail that seems to have a strict policy against have two releases with the same number of source packages.
<Fujitsu> Haha.
<ScottK2> KDE python bindings.
<ScottK2> Not kidding
<ScottK2> We lost claws-mail-clamav in the last release.
<ScottK2> Ironically due to their concerns about freeness of clamav unrar code that Debian removes
 * lamont -> bed
<Fujitsu> Night lamont.
<ScottK2> Fujitsu: Any idea what the [NEW] bit in bug mail is supposed to signify?
<Fujitsu> ScottK2: That it's the initial email for a bug.
<Fujitsu> Appeared with 1.2.1, IIRC.
<ScottK2> Right.
<ScottK2> I guess I don't get it.
<ScottK2> I thought it was "Hey. This is a new bug."
<Fujitsu> It is.
<Fujitsu> Or it might be `Hey. This is a new bug task."
<ScottK2> No.  It's "Hey.  This is the first time I've spammed you about this bug."
<Fujitsu> I'm not sure.
<ScottK2> Bug may or may not be new.
<ScottK2> I just assigned myself a 5 month old bug and it came in as [NEW]
<Fujitsu> You in't create a new task?
<Fujitsu> Gaah.
<persia> I've only seen it when the bug is new or the bug is newly non-private, or the bug has a new task, or the bug is against a new package/project/milestone, or the bug newness was unintentionally reset.
<persia> ScottK: For that, you got the NEW warning because the bugmail you received was the top part.  Just add a comment when assigning to avoid it (and make the bug less new)
<ScottK2> No.
<ScottK2> Just assigned the bug
<Fujitsu> That woul be YALPB.
<persia> There were other comments in the bug?  that's a NLPB for me.
<Fujitsu> I woul presume that [NEW] woul indicate newness.
<Fujitsu> Not newly-notifiedness.
<ScottK> Acutally I did include a comment
<ScottK> And there were other comments
<ScottK> It's Bug 144490
<ubotu> Launchpad bug 144490 in python-kde3 "autopkgtest gutsy python-kde3: erroneous package!" [High,New] https://launchpad.net/bugs/144490
<persia> Fujitsu: In my experience, it comes from the bug being "New", which doesn't mean recent.
<ScottK> Status is New.
<ScottK> I'm not sure why that needs bold blinky subject lines
<persia> Status oughtn't define newness for bug notification.  That's a bug.
<Fujitsu> persia: I have no replies that are marked [NEW], other than those that are done through the email interface, so it's not marke by Status.
 * ScottK2 has already filed his LP bug for the day.  
 * ScottK2 looks around for an LP developer...
<persia> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<pwnguin> its also like midnight or later in the us / euroland
<pwnguin> though maybe germany's close to wake up time ;)
<pwnguin> does keybuk hit irc much anymore?
<ScottK2> Nevermind.  I'll file the bug.  It's even more annoying than I thought.
<ScottK2> I get a copy of the entire bug marked new and then another mail with my comment.
<Fujitsu> That's what I'd expect, except without the [NEW] bit.
<ScottK> I don't need a copy of the ficking bug in my inbox.  I already read it before I assigned it to myself.
<warp10> Good morning
<persia> ScottK: That behaviour is a workaround for the previous issue that subscribing people after leaving a comment didn't send them an email notification (as I understand it)
<ScottK> persia: Not my problem.  It's a bogus design
<persia> Sure, just sharing my impression of history hoping it might cause your use case to be better written to avoid being rejected out of hand.
<ScottK> Thanks.
<ScottK2> I filed the bug.  I managed to mostly contain my sarcasm.
<ScottK2> Have a good night/day as your circumstances and timezone permit.
<persia> Good night ScottK
<ScottK2> Good night persia
<Fujitsu> Night ScottK2.
<toresbe> http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02140.html what!
<Griswold> Heh
<ion_> Yeah, he switched to Vim.
<toresbe> finally took to his senses, huh!
<toresbe> I guess this is one of those "where were you when ..." things
<Chipzz> who is (coming to|at) FOSDEM? :)
<rohan> https://bugs.edge.launchpad.net/ubuntu/+bug/190677 --> in this bug report, what does LUM stand for?
<ubotu> Launchpad bug 190677 in linux-ubuntu-modules-2.6.24 "Backport acer-wmi to hardy 2.6.24 kernel" [Low,Fix committed]
<persia> rohan: linux-ubuntu-modules
<persia> rohan: Also, #ubuntu-bugs is generally the best place to ask about bugs.
<rohan> persia: i'm sorry!
<afflux> pitti: could you have a look at bug 193533? It looks like the var/run/PolicyKit stuff in policykit's postinst script should be handled in policykit.init as var/run/PolicyKit is created first in the init script
<ubotu> Launchpad bug 193533 in policykit "mkdir /var/run/PolicyKit" [Low,Confirmed] https://launchpad.net/bugs/193533
<jeromeg> ScottK: hello, are you available ?
<ScottK2> jeromeg: I'm here
<jeromeg> ScottK2: what did you decied for the brasero backport ?
<ScottK2> I didn't yet (I agreed about backporters for the maintainer)
 * ScottK2 looks for the bug.
<jeromeg> ScottK2: ok, I think this is really an important backport
<jeromeg> unofficial repos are being created in a lot of places
<ScottK2> OK.  What's the impact of the dropped dependencies?
<jeromeg> ScottK2: none
<jeromeg> it just removes a feature that is not in gutsy
<jeromeg> (it was added for hardy)
<ScottK2> K
<jeromeg> ScottK2: i'm also working on a backport for pidgin
<jeromeg> which has even more unofficial buggy packages
<ScottK2> jeromeg: I'm unlikely to touch that one without a lot of backing from jdong.
<jeromeg> ScottK2: yep, yep I know it's a tough thing, that's why I set up a ppa to have some feedback
<jeromeg> i'm testing all plugins at the moment, quite boring :)
<ScottK2> Fair enough
<ScottK2> jeromeg: Where do I find usr/share/gnome-pkg-tools/1/rules/uploaders.mk?
<jeromeg> ScottK2: why do you need this ?
<ScottK2> Because the source package won't build for me for the lack of it.
<jeromeg> weird
<jeromeg> in Gutsy ?
<ScottK2> Yes
<jeromeg> I'll have a look
<jeromeg> you have gnome-pkg-tools installed right ?
<ScottK2> No.
 * ScottK2 neither uses nor develops for Gnome.
<jeromeg> ScottK2: this is during build or during debuild ?
<ScottK2> Building the source backage.  That's probably what I need.
<ScottK2> Yep.  That was it.
<jeromeg> yep you need to install gnome-pkg-tools
<jeromeg> great
<jeromeg> ScottK2: works ?
<ScottK2> jeromeg: Your patch applied, the source package built and I'm doing a test build now.
<jeromeg> ScottK2: thank you very much
<ScottK2> jeromeg: For the future, use gutsy-backports as the target in debian/changelog, not gutsy.
<jeromeg> ScottK2: oh yep, sorry for that
<ScottK2> jeromeg: Uploaded.
<jeromeg> ScottK2: great !
<jeromeg> thank you so much !
<ScottK2> Now we need to wait for an archive admin to publish it.
<jeromeg> ok
<jeromeg> ScottK2: the pidgin backport seems to work pretty well
<jeromeg> only one plugin remaining to test
<jeromeg> took me 1h and a half...
<ScottK2> jeromeg: Convince jdong first.
<jeromeg> ScottK2: yep :)
<ScottK2> jeromeg: You should have gotten a waiting for approval mail on brasero (I think)
<jeromeg> ScottK2: not yet
<ScottK> jeromeg: Maybe just the uploader gets that one.  I'm not sure.  I got it, so it's confirmed the upload made it.
<jeromeg> thank you very much
<cheddarcheeseisy> is JFS supported?
<mjg59> Supported in what way?
<mjg59> I don't believe you can install to JFS with the standard installer, but the alternate will do it. The kernel certainly has support.
<cheddarcheeseisy> get bugfixes and all that in ubuntu
<mjg59> It's in the kernel, so yes
<cheddarcheeseisy> ok
<andrea-bs> Could somebody tell me which is the difference between MOTU and Ubuntu Developer, please?
<Keybuk> Ubuntu Developer includes core developers
<Keybuk> Ubuntu Developer := ( MOTU + Ubuntu Core Developer )
<andrea-bs> Keybuk: thanks, but on Launchpad I see that MOTU is a member of ubuntu-dev
<Keybuk> exactly
<Keybuk> that isn't inconsistent with what I said :-)
<andrea-bs> oh, yeah
<andrea-bs> I read too quickly, sorry :D
<andrea-bs> thanks
<slangasek> har, no one commented on the fact that my feature freeze announcement linked to the gutsy list of blueprints
<Keybuk> slangasek: everyone's already running intrepid ;)
<slangasek> ah, good. :)
<Kopfgeldjaeger> btw, are we running intrepid or ibex?
<Keybuk> Kopfgeldjaeger: we use the adjective
<Kopfgeldjaeger> yeah, i know... but intrepid.. OK
<Keybuk> it's a secret plot to get everyone to just call it "8.10"
<siretart> does 'intrepid' sound strange to native speakers as well?
<j1mc> Keybuk: "it's a secret plot . . ."  hehe
<Fujitsu> siretart: I think it's slightly less strange than the rest of the adjectives that have been use.
<slangasek> siretart: no, why should it sound strange?
<Amaranth> siretart: it's better than hoary
<Kopfgeldjaeger> n8
#ubuntu-devel 2008-02-24
<Hobbsee> morning
<j1mc> hi Hobbsee.
<sistpoty> hi Hobbsee
<geser> Hi Hobbsee
<Hobbsee> sky fallen in yet?
<pochu> hey Hobbsee
<geser> can't see, it's dark outside
<Hobbsee> oh
<pochu> pitti: hi, would you have a minute, could you see if you anything wrong in this apport hook for tracker-extract? TIA. http://emilio.pozuelo.org/~deb/tracker.py
 * Hobbsee sets geser's house on fire then
<pochu> s/you/you see/
<pochu> pitti: it's not stopping me from reporting a crash in tracker-extract (I sended sigsegv to it to test the hook)
<j1mc> hi pochu
<pochu> hi j1mc, how is it going?
<j1mc> pochu: fine, thx.  i've been contributing to xubuntu docs lately.  it's easier for me to do on my own schedule, rather than the testing stuff, which has to be done at certain times.
<mgunes> which package is the pop-up volume indicator that appears when adjusting volume with keyboard belong to? top suspects: gnome-media, gnome-applets
<Fujitsu> mgunes: I think that's actually gnome-settings-daemon.
<mgunes> Fujitsu, I suspected that too, since g-s-d gets active when playing with volume, but couldn't see any relevant bug reports in the g-s-d component in GNOME bugzilla.
<Fujitsu> What's the issue?
<mgunes> bug #194656
<ubotu> Launchpad bug 194656 in gnome-media "make the volume bar show a real GTK+ bar" [Wishlist,New] https://launchpad.net/bugs/194656
<zooko> Can we get Python 2.5.2 into Hardy?
<zooko> Or, to put it another way, there a handful of known bugs in Python 2.5.1, along with patches to fix them.
<zooko> Can we get some or all of those patches into Hardy?
<zooko> :-)
<Fujitsu> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<jimlay> I gather this isn't exactly the correct place to ask a lot of the questions I have, but I'm not sure where to go. I want to ask questiions like "Compiz.real has been using 90% cpu for a few hours but nothing on my computer is doing anything. I want to inspect it but I don't understand what's going on." or "Where can I get an overview of what is going on? I've avoided gnome  for most of a decade  now because it makes me feel like I don'
<jimlay> I have lots of such questions.
<jimlay> Fujitsu, is anyone around?
<zooko> I'm not sure, but maybe #ubuntu-help ?
<Pici> jimlay: You can try #compiz-fusion for your compiz specific questions, and #ubuntu for everything else.
<zooko> I'm a paid developer, but I'm paid to work on something else (http://allmydata.org ), so I'm more likely to work on Ubuntu during weekends.  ;-)
<jimlay> who pays you to work on allmydata?
<zooko> jimlay: http://allmydata.com
<zooko> The .com sells consumer backup services.
 * lamont scratches his head and wonders how exactly the system can be right in reporting 30KB/s through a 128kbps line...
<slangasek> metric vs. English seconds
<sistpoty> heh
<jimlay> #ubuntu is sort of an explosion of noise.  I'm still trying to figure out who is responsible for the package containing the text installer. I managed to  clobber about 300gb last week using the installer and I Didn't get a notice that the operation I was about to perform was non-reversable.
<jimlay> lol
<jimlay> If there is a bug in the alt-cd install program - what do I do?
<lamont> slangasek: well, it got over it's fantasy and is now reporting 10K/s, which fits
<jimlay> if I knew what package it was I'd know what to do - but I can't figure it out.
<zooko> jimlay: reportbug
<zooko> Ah.
<lamont> jimlay: file a bug against the debian-installer package,  I expect
<lamont> of course, if it's a bug in one of the 50 bazillian udebs that debian-installer brings in to do it's work, then it's not a debian-installer bug necessarily.  OTOH, that does seem to be a popular dumping ground
<sistpoty> lamont: btw.: do you have an idea what might caused ghc6 on sparc to fail (looks like it was externally killed from s.th.): http://launchpadlibrarian.net/11902091/buildlog_ubuntu-hardy-sparc.ghc6_6.8.2-1ubuntu1_FAILEDTOBUILD.txt.gz
<lamont> OOM maybe?
<sistpoty> OOM?
<lamont> out of memory
<jimlay> Who pays the paid ubuntu developers?
<lamont> although looking at it, here's the reason:
<lamont> make: *** [build-stamp] Terminated
<lamont>  ...killed.
<lamont> Build killed with signal 15 after 149 minutes of inactivity
<lamont> jimlay: I expect that there are multiple companies who pay people to work on ubuntu stuff.
<lamont> canonical ltd (www.canonical.com) pays a bunch of them
<sistpoty> yes, I've seen that... but what caused that (or what means inactivity there)... btw.: I'm still building at on an ultrasparc 2 (for more than 24 hours now and it still makes progress *g*)
<lamont> sistpoty: for 149 minutes, it failed to generate any output to stdout
<lamont> Setting up bind9 (1:9.5.0~b2-0~gutsy1) ...
<lamont> Reloading AppArmor profiles  Skipping profile /etc/apparmor.d/usr.sbin.cupsd.dpkg-old
<lamont> : Warning.
<lamont>  * Starting domain name service... bind                                                       [ OK ]
 * lamont vomits
<lamont> and bind9 installs again.  go me.
<sistpoty> lamont: oh... any chance, to increase that timeout? (it does some heavy ghc6 -> c-file -> gcc things, which really take a long time for gcc to be done with one file (at least on the test box I'm using right now)
<lamont> sistpoty: yes..  poke infinity on mondya
<sistpoty> lamont: thanks, will do (I hope my testbuild will have succeeded by then *g*)
<zooko> Good night, folks.
<jimlay> How many MOTU's are there?
<lamont> jimlay: not enough (and I don't know an  actual number)
<lamont> note that many core-devs are also unpaid volunteers
<lamont> jimlay: for example, I do not get paid to work on ubuntu.
<jimlay> are you a core-dev?
<lamont> since before it was ubuntu
<simon360> hey
<lamont> (I do currently receive money from canonical for system administration activities, those activities do not include distro work)
<lamont> jimlay: I was paid ubuntu development staff from march 2004 through may 2005
<jimlay> Ok, so issue #1. The problem I had with the alt-installer was pretty serious - I managed to run lucsFormat on a partition with data on it and lost a bunch of stuff. I assumed that because I was mounting an encrypted volume with the same crypt key the data would be there - I did a lot of figuring out after the fact and now I need to figure out who's responsible for that particular bit of the installer. I don't feel like poosting a bug -
<jimlay> Forum, irc, mailing list from the package-maintainer field in the debian-installer package?
<Fujitsu> jimlay: You should have told it to not overwrite it...
<jimlay> ?
<jimlay> Fujitsu: are you familliar with what I'm talking about?
<Fujitsu> Is there not an option set by default to overwrite the entire volume with random data?
<jimlay> no I didn't do that.
<jimlay> I had an encrypted install of 32bit and while installing 64 bit I told it I wanted to mount the encrypted volume - but not format it. When it mapped the device it asked for my crypt key it used it to generate a new keyfile. Luks uses the users crypt key to encrypt the actual key on the disk - that way you can change your password without hhaving to re-encript everything. Well, when I gave it my key to map the device, rather than mappin
<jimlay> The data was unrecoverable (I had almost all of it backed up).
<jimlay> Where the sticking point is, is that when I went to map the device (the last window before it alll went kuput) I got a warning that said "after this you wont be able to make any more changes to the partition table on your unencrypted volumes" but it didn't give any warning that it was about to run luksFormat which is a potentially dammaging command. Partitioners should function such that when you always get a big nasty message about "a
<lamont> that sounds like the parted piece that does the formatting...
<lamont> if it was me, and I couldn't figure out which package it should be in a reasonable time, I'd dump it on debian-installer and let them migrate it to the right package, since they actually know what udebs do what and such.
<jimlay> indeed parted looks like it is the package.
<lamont> that or the individual filesystem beastie under it
<jimlay> the maintainer for parted is ubuntu-devel-discuss so I'm just going to send it to that.
<sistpoty> jimlay: please rather file a bug on launchpad... makes it much easier for developers to pick that up and sort in instead of a mail to ubuntu-devel-discuss
<jimlay> ok - that's why I asked. thanks.
<Laney> What package should bugs with the Live CD environment be filed against?
<sistpoty> Laney: what bug are you stumbling into? (I guess casper would be the right package, if it was live-cd only, but not showing in an installed system)
<Laney> sistpoty: I was looking to triage bug 194927
<ubotu> Launchpad bug 194927 in ubuntu "Error: Could not launch application: Not a launchable item" [Undecided,New] https://launchpad.net/bugs/194927
<sistpoty> Laney: hm... might be a gnome-s.th. problem as well as a problem of unionfs... however I guess the most common denominator would be casper
<Laney> sistpoty: OK, I guess the most important thing is getting the right people to look at it...
<sistpoty> Laney: yep, I assume that casper devs will know where it can come from ;) (as I usually know where trigger bugs come from *g*)
<simon360> I have a panel setup in Gnome that I want to apply to a derivative. I know it needs to go into /usr/share/gconf/defaults/ into a file I can't remember the name of right now, but that file is long and would take a while to write in the way I need it...
<simon360> is there something that will export my gconf configuration to an XML file instead of a series of directories with xml files within them?
<simon360> nevermind, figured it out
<simon360> use gconftool-2 --dump /apps/panel
<simon360> I spent all day trying to find that, and as soon as I ask here I find it myself :P
<slangasek> jimlay: partman-crypto, FWIW.  BTW, many of your comments above were being cut off because you hit the IRC message limit; you may want to take care to write in shorter chunks, or to use something like irssi's splitlong.pl
 * slangasek wonders why in the world the abiword maintainer decided to handle a build failure with current libgoffice by disabling the goffice bits and shipping an empty abiword-plugins-gnome package :P
<jdong> slangasek: must've had medical training. when in doubt snip it out :)
<slangasek> I find my mistrust of doctors strangely reinforced
<genbuntu> hi
 * simon360 is bedding hoimself
<evand> Anyone know how I can get the "Ubuntu Developer" tag on the forums?
<StevenK> evand: I think you beg the forum admins
<evand> I was afraid of that.
<evand> thanks StevenK
<ScottK2> evand: Talk to jdong.  He's easy.
<evand> ok, thanks
<evand> jdong: ping ^
<evand> jdong: nevermind
<slangasek> geser: do we need to get the new upstream version of evolution-sharp packaged, to match the version of evolution we have? (bug #194456)
<ubotu> Launchpad bug 194456 in evolution-sharp "FTBFS in latest archive rebuild test" [High,New] https://launchpad.net/bugs/194456
<yao_ziyuan> i want to borrow some ubuntu developers who are familiar with scim configuration to #kubuntu-devel
<Hobbsee> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<yao_ziyuan> east asian input method setup is currently the deadliest problem in Kubuntu
<Chipzz> Hobbsee: you at fosdem?
<Chipzz> (guessing not)
<Hobbsee> Chipzz: nope.  i'm in the wrong country for that
<geser> slangasek: if you have some time for sponsoring: bug 194566, bug 194446, bug 194529
<ubotu> Launchpad bug 194566 in usbutils "FTBFS in latest rebuild test" [High,New] https://launchpad.net/bugs/194566
<ubotu> Launchpad bug 194446 in bogofilter "FTBFS in latest archive rebuild test" [High,New] https://launchpad.net/bugs/194446
<ubotu> Launchpad bug 194529 in lockfile-progs "FTBFS in latest archive rebuild test" [High,New] https://launchpad.net/bugs/194529
<lucas> what's the status of ubuntu wrt upstart? installed by default? since when?
<StevenK> lucas: Since Edgy, 6.10
<lucas> ok
<lucas> thank you
<SuperKBilly_> hi
<bigon> apt-cache policy mplayer
<bigon> E: Encountered a section with no Package: header
<bigon> E: Problem with MergeList /var/lib/apt/lists/archive.ubuntu.com_ubuntu_dists_hardy_universe_i18n_Translation-fr
<bigon> any clue? changing the locales fix the problem
<asac> Riddell: there?
<jpatrick> asac: FOSDEM I think
<asac> k
<soren> bigon: Try removing that file and do an apt-get update.
<jdong> evand: did you get the tag you wanted?
<Adri2000> bigon: open that file and remove the ^Ms at the top of it
<ogra_cmpc> soren, in your virtual images, do you use grub anywhere ?
<soren> ogra_cmpc: all the time.
<soren> ogra_cmpc: Why?
<ogra_cmpc> soren, how do you install griub in such an image then ?
<soren> ogra_cmpc: I'm not entirely sure I understand the question...
<soren> ogra_cmpc: You boot an iso...
<soren> ogra_cmpc: ...perform installation (which installs grub)...
<soren> ogra_cmpc: done.
<ogra_cmpc> soren, oh
<soren> ogra_cmpc: I also do it from ubunut-vm-builder though.
<ogra_cmpc> i thought you create image files
<soren> ogra_cmpc: In that particular case, I reimplemented grub's bootloader isntallation stuff in posix shell (!).
<ogra_cmpc> not iso filesystems
<soren> Well, that's what ubuntu-vm-builder does.
<soren> However, most people just boot one of the usual ubuntu iso's in a vm and does that installation as they're used to.
<ogra_cmpc> well, what i want is to create an image from scratch with dd, partiton it, loop mount it and then install grub in there
<soren> ogra_cmpc: Look at ubuntu-vm-builder then.
<ogra_cmpc> but thats not the grub cd or floppy image or something ?
<soren> ogra_cmpc: I didn't manage to pursuage grub to install itself onto a loopback device or directly to a file, so I replicated its install code in shell.
<ogra_cmpc> (i dont want to have to use syslinux for the usb image installer for the classmate)
 * soren types very pooly today, apparantly.
<soren> poorly, even.
<james_w> Adri2000: bug 195103 is about this, is it a known issue, could you perhaps explain there?
<ubotu> Launchpad bug 195103 in update-manager "Bug d'update-manager" [Undecided,New] https://launchpad.net/bugs/195103
<ogra_cmpc> get a classmate, that teaches you :)
<soren> ogra_cmpc: heh :)
<ogra_cmpc> soren, so i assume you just dd stage1 ?
<soren> ogra_cmpc: What I do in the ubuntu-vm-builder in shell is *exactly* the same as grub-install does in the regular installer.
<soren> ogra_cmpc: No.
<ogra_cmpc> ok, i'll look at the code before making more assumptions
<ogra_cmpc> thanks a lot
<soren> ogra_cmpc: I dd stage1, yank out some of the existing mbr, change a few bytes here and there, shove in the stage 1.5, blahlblah... It's *horrible*.
<ogra_cmpc> well, if it works
<soren> ogra_cmpc: I wouldn't recommend looking at it to anyone I like.
<ogra_cmpc> heh
<soren> ...which happens to include you, so if there's a way around it.. don't look.
<ogra_cmpc> well, i have looked at a lot weird stuff this weekend for that particular prob :)
<soren> What's the problem exactly?
<Adri2000> james_w: yep, will do
<james_w> Adri2000: thanks.
<ogra_cmpc> i have a classmate image that boots fine etc ... to get that on the classmate i have a small installer script ... i want to wrap all that into an image that you just can dd to a usb key so that it boots out of the box ...
<ogra_cmpc> wiothout using syslinux or being forced to use any othetr kind of crack that forces me to vfat
<ogra_cmpc> its like an onion ... one image wrapped into another
<soren> mmkay.
<ogra_cmpc> and the outer one needs to be built from scratch while the inner one has actually a real bios device (internal classmate flashdik) to attach to
<soren> Aha.
<ogra_cmpc> i want to use the same initramfs for both and avoid as much duplication as i can here
<soren> Right.
<ogra_cmpc> so while syslinux could save me its not what i want (i can fallback to it if i dont get the other way to work)
<soren> Right.
<ogra_cmpc> grumble ....
<ogra_cmpc> never run apt-proxy on a livecd if you actually want some response speed ...
<ogra_cmpc> soren, hmm
<ogra_cmpc> whats ubuntu-vm-builder-foo ?
<ogra_cmpc> oh, i didnt know grub accepts UUID
<ogra_cmpc> (in device.map i mean)
<ogra_cmpc> soren, wow, you must really love dd :)
<Chipzz> ATTENTION DEBIAN DEVELOPERS
<Chipzz> someone forgot his camera in the debian developer room at fosdem
<Chipzz> Kodak EasyShare ZD710
<Chipzz> it's at the infodesk right now
<emgent> Chipzz, lol
<jpatrick> Chipzz: best try irc.debian.org/debian-devel
<evand> jdong: Indeed I did, thanks
<jdong> cool
<alex-weej> is there some place to discuss the performance of the archives?
<alex-weej> i'm getting a maximum of about 70 KB/s from the main mirror and the UK mirror weeks
<alex-weej> *for weeks
<alex-weej> yet i have just tried the SE mirror and it's uber fast
<ccm> tried the "find best mirror" method?
<alex-weej> how do i do that?
<alex-weej> oh i see it!
<ccm> go to Sources where you can choose the mirror
<ccm> there you can tick it
<ccm> yes
<alex-weej> i see there are also options for virginmedia
<alex-weej> which is my ISP
<ccm> just run the test
<ccm> quite nice feature i think
<alex-weej> it hung on some mirror that i think is probably underwater in the south pacific somewhere
<alex-weej> nm i will just use Virgin Media
<alex-weej> it's fast!
<alex-weej> thanks
<ccm> you are welcome
<CoCaiNe> HI i have 3 year old LAPTOP - and i was wondering if i could install ubuntu on it over windows
<CoCaiNe> ???
<CoCaiNe> is it possible
<james_w> CoCaiNe: please use #ubuntu for support questions.
<slangasek> geser: fixes sponsored
<geser> thanks
<emgent> hello people
<Itaku> i get this error when compiling in gcc http://paste.ubuntu-nl.org/57250/ how do i fix
<jdong> Itaku: that's offtopic for this channel, so you're unlikely to get a meaningful response around here
<Kibbles> Seveas: thanks for the ban on #ubuntu... could you please reverse decision?
<Seveas> Kibbles, thats very offtopic in here, ask in -ops
<Kibbles> Seveas: sorry, i know - how do i get to ops?
<Seveas> same as how you get to other channels
<Kibbles> i.e. /join ops?
<Seveas> #ubuntu-ops
<Kibbles> done sorry
#ubuntu-devel 2009-02-16
<Knives> I'm looking for a Jpdota
<Jpdota> Knives: found
<kees> andersk: sure, I'll apply it.
<fakhriz> hi folks
<fakhriz> I have trouble installing my webcam ubuntu 8.1
<fakhriz> anybody there
<nhandler> fakhriz: This channel is not for support. Try #ubuntu
<fakhriz> thx
<dholbach> good morning
<amason_> hey guys is UXA & DRI2 working in jaunty with -intel ? i know there are known issues with alpha4 and EXA. I was hoping to test out some newer packages and can deal with most things not working
<amason_> but obviously the display portion is important
<pwnguin> amason_: if you don't get an answer here, ubuntu-x might have your answer
<amason_> pwnguin: thanks i'll head over and ask there.
<pitti> Good morning
<pitti> ScottK: I copied 4.1.4 to i-updates yesterday
<pitti> apw: cool, thanks! will review
<pitti> maxb: hm, you shouldn't really get a prompt, the file should just go; please file a bug against locales and subscribe me
<primes2h> Could someone have a look on this and tell if the package affected is correct? BTW, this bug has an high impact on many many users especially newbies. bug #255651
<ubottu> Launchpad bug 255651 in linux "floppy disk drive not detected (module not loaded) in Intrepid and Jaunty" [Undecided,New] https://launchpad.net/bugs/255651
<primes2h> I forgot.. please? :-)
<jeromeg> pitti: you seem to have taken care  of a few abiword uploads in the past. I'm working on packaging 2.6.6. Are you interested in reviewing it once I'm done ?
<pitti> jeromeg: I can look at it, but please just subscribe ubuntu-main-sponsors, so that it's not blocking on just me
<jeromeg> pitti: ok, I'll do that
<primes2h> bryce: Could you have a look on this, please? bug #291436
<ubottu> Launchpad bug 291436 in compiz "Video on Ati Radeon HD 2400 is flickering, I cant watch any video with compiz" [Undecided,Confirmed] https://launchpad.net/bugs/291436
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<pitti> tkamppeter: please try to test-build cups before committing a patch :)
<tkamppeter> pitti, about your upload of CUPS, the pdftopdf filter has to get built in Ghostscript mode. Poppler's pdftopdf has a general bug of not supporting different paper sizes in the output. Can you repackage CUPS with the pdftops filter being Ghostscript-based? Thanks.
<tkamppeter> pitti, diod the CUPS not build for you in the form how I uploaded it? For me it built.
<tjaalton> primes2h: nothing we can do
<primes2h> tjaalton: about the ATI one?
<tjaalton> primes2h: yes
<pitti> tkamppeter: the test suite failed
<pitti> tkamppeter: because it didn't find gs
<pitti> tkamppeter: so if we should stop using pdftops from poppler-utils, and start using ghostscript, we need to change the patch again and swap the build-depends and depends instead
<pitti> tkamppeter: I just wonder whether switching to gs will give us a different set of bugs?
<tkamppeter> pitti, I see. Can you do so? Return to my original patch and add "ghostscript" to BuildDepends and Depends.
<pitti> tkamppeter: I can, just wanted to confirm that that's the right thing
<pitti> tkamppeter: it's not possible to fix poppler?
<tkamppeter> pitti, OK, thanks.
<tkamppeter> pitti, I had reported a bug to them, but they do not fix it.
<pitti> tkamppeter: okay; can you please open a bug and assign it to me?
<tkamppeter> pitti, this is the link to the Poppler bug report: https://bugs.freedesktop.org/show_bug.cgi?id=19777
<ubottu> Freedesktop bug 19777 in general "pdftops command line utility does not convert multiple-page-size documents correctly" [Normal,New]
<primes2h> tjaalton: Thanks.
<tkamppeter> pitti, bug 329991
<ubottu> Launchpad bug 329991 in cups "Poppler's pdftops does not support multiple-page-size output, use Ghostscript for the CUPS filter instead" [Medium,Triaged] https://launchpad.net/bugs/329991
<pitti> tkamppeter: thanks
<tkamppeter> pitti, have you already seen http://bugs.freedesktop.org/show_bug.cgi?id=19968
<ubottu> Freedesktop bug 19968 in Driver/intel "clone mode: If projector does not report its default resolution, wrong resolution gets selected" [Major,Resolved: notourbug]
<pitti> maxb: ah, found the problem; will fix
<pitti> tkamppeter: I saw the reply, yes; but I can't test it here either
<tkamppeter> They have closed it because they cannot reproduce it with their projector, probably theirs reports the default.
<tkamppeter> They also they use Intrepid and not Jaunty.
<pitti> seb128: btw, the retracer failures are my fault (conffile question in locales); fixing locales...
<lool> pitti, tkamppeter: I had this exact same bug, I discussed it at length with seb128 and bryce
<seb128> pitti: ok
<lool> xrandr (the command-line binary) has a special --preferred flag which makes it *compute* the preferred mode when one isn't advertized; there's no comparable logic in the XRandr API or in GNOME (either libgnome-desktop or g-s-d)
<lool> Which is what seemed to be missing
<directhex> compute it based on what?
<tkamppeter> pitti, lool, bryce, I think, this is a bug in xrandr, as if one starts the X server with the projector plugged, it works correctly. So the X server contains the correct logic. One only needs to use the same logic in xrandr.
<lool> directhex: It selects the largest mode you support
<lool> directhex: see preferred_mode() in xrandr/xrandr.c
<lool> (in the x11-xserver-utils package)
<lool> tkamppeter: If you "xrandr --auto" in a Xorg session it works fine, right?
<tkamppeter> Perhaps projectors which behave as the one on the Sprint are rare and so it is difficult to convince someone to fix this.
<tkamppeter> lool, no, if I do so, I get exactly the problem described in the bug. If I start X with the projector plugged I get the correct result.
<lool> My understanding is that in GNOME sessions, all xrandr updates / hotkeys etc. are handled in GSD; I don't quite know whether it's a Xorg bug too
<maxb> pitti: thanks! I'll wait for a new glibc to hit the archive before upgrading my remaining jaunty machines, to test
 * directhex installs a jaunty VM
<jeromeg> pitti: ok, I think I'm for abiword, I attached everything and suscribed ubuntu-main-sponsors
<jeromeg> bug #318444
<ubottu> Launchpad bug 318444 in abiword "[need-update] abiword to latest stable version 2.6.6 in Ubuntu 9.04" [Wishlist,New] https://launchpad.net/bugs/318444
<mvo> lool: when I looked into the xrandr util last it had a lot of logic in it that really should be in some sort of library
<jeromeg> I hope there aren't many issues because each test build takes 40 minutes here :(
<lool> mvo: Yes
<lool> mvo: That's exactly what we saw in my case
<directhex> jeromeg, try your hand at OOo packaging, then moan about 40 minute build times ;)
<jeromeg> directhex: I tried to build ooo one time, and killed the pbuilder after 2 hours :)
<directhex> jeromeg, barely 25% in? tsk
<tkamppeter> mvo, and the logic which does it correctly with the projector of the sprint is in the X server and not in xrandr ...
<pitti> maxb: I uploaded the fix half an hour ago; it's not in glibc, but in "locales" (langpack-locales source), which is fairly small
<pitti> maxb: thanks
<maxb> "Add alternative dependency to libc6.1, to unbreak ia64." ?
<pitti> maxb: no, the next one, in -3
<cjwatson> doko: python2.6 binaries accepted now
<maxb> Oh. mail being slow, then
<geser> so we have now four python versions in the archive?
<mok0> geser: 2.3 is still supported?
<cjwatson> geser: https://blueprints.launchpad.net/ubuntu/+spec/python-for-jaunty includes dropping 2.4 modules
<doko> cjwatson: thanks
<geser> mok0: 2.4, 2.5, 2.6 and 3.0
<geser> doko: Hi, what are the chances to see python-central 0.6.8 in jaunty? Some packages from universe are in DEPWAIT as they want python-central >= 0.6.8 and jaunty has only 0.6.7ubuntu1.
<mok0> cjwatson: any idea how many modules are not supported under 2.5?
<mok0> geser: oh cool
<cjwatson> mok0: I thought everything was supported
<mok0> cjwatson: I'm not sure
<mok0> cjwatson: perhaps
<mok0> cjwatson: that's why I asked :-)
<cjwatson> mok0: I would be surprised if not; about the only thing that has trouble is zope2.x/plone
<cjwatson> mok0: everything else is fine AFAIK
<mok0> cjwatson: sounds great then
<cjwatson> doko: what's up with the i386 build failure on -0ubuntu3 though? is it due to a parallel build?
<mok0> cjwatson: Usually Python version upgrades have meant that extension modules had to be corrected
<mok0> cjwatson: especially those relying on swig
<doko> geser: no, will upload a new version
<doko> cjwatson: no, profile based build. will disable this for now. it's a GCC bug
<geser> doko: you mean something like python-central 0.6.8ubuntu1 (or even greater)?
<cjwatson> mok0: maybe, but we did 2.5 ages ago
<mok0> cjwatson: k, thx
<lool> doko: Looks like /etc/ld.so.conf.d/<triplet> should be rm_conffiled in glibc
<lool> doko: I have /etc/ld.so.conf.d/i486-linux-gnu.conf and /etc/ld.so.conf.d/i486-linux-gnu here
<lool> I filed this sa #330029
<doko> lool: yes, but it currently doesn't hurt, because only *.conf files are read
<lool> doko: Ok
<lool> doko: Hmm I don't see how the nosegneg dir is included in hardy; if I ldconfig -p with libc6-xen installed on a hardy xen domU, it doesn't show any nosegneg dirs, only the cmov one
<lool> doko: I suspect we miss the xen.conf file
<lool> doko: If I create a /etc/ld.so.conf.d/xen.conf with "hwcap 1 nosegneg" and run ldconfig, I see the nosegneg files in the cache now
<lool> (in ldconfig -p)
<lool> That said, it still prefers the i686 version, which is probably another bug
<lool> Hmm TLS is disabled in all cases, so not a big deal
<lool> ubuntu-minimal depends on libc6-i686 though, blah
<lool> I don't quite see the point of the libc6-xen in Ubuntu since -i686 is built with the same flags
<apw> pitti, thanks for looking at my apport  (when you get to it)
<apw> pitti, just to say i finally figured out how to test it propoerly with all three interfaces, and did actually test them all
<lool> wow three reasons why libc6-xen is uselesss :-/
<lool> doko: I filed 330039 on libc6-xen being useless, it might be the result of Ubuntu specific changes
<lool> doko: Right, it's Ubuntu-specific; Debian doesn't set nosegneg by default
<lool> doko: Perhaps we should drop the xen pass as a result
<elmo> why do we nosegneg?
<doko> I would have to look, I think I inherited this code
<lool> elmo: This seems to be a very old change in Ubuntu
<lool>     * i386.mk:
<lool>       * readd no-tls-direct-seg-refs to generic libc cflags.
<lool> glibc (2.5-0ubuntu1) feisty;  -- Fabio M. Di Nitto <fabbione@ubuntu.com>  Wed, 01 Nov 2006 12:49:55 +0100
<elmo> I mean, I'm not complaining, it's a win for Xen ;-)  I just didn't think it was a win in the normal case
<lool> I can tel it results in slower i386 assembly, but I don't know by how much
 * lool returns to arm
<ogra> hmm, new d-i inst built yet ...
<cjwatson> it'll need another rebuild today for cdebconf-terminal anyway
<cjwatson> ... once I get that built
<lool> ogra: It the new NSLU2 kernel in?
<ogra> lool, just checking
<lool> I didn't see the change from jaunty-changes, but I might have missed it
<ogra> yep. looks like we have an 8.22
<lool> ogra: In the latest git tip, I see CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y
<ogra> yes, somehow the changelog parser missed it
<lool> ogra: So it's supposed to be the correct flag?
<ogra> i knew it was in there already, was just waiting that it builds
<ogra> amit picked it from the debian config he said
<ogra> so i assume it is
<ogra> we'll know if d-i is there ...
<ogra> ... i would have poked around with my script, but since d-i was uploaded anyway i'll just wait for the real thing to appear
<ogra> theoretically it should bot now
<ogra> *boot
<Keybuk> cjwatson: you'll sympathise with this
<Keybuk> I've been trying to listen to the Ubuntu UK Podcast
<Keybuk> and having the "someone is being wrong on the Internet" issue
<ogra> that cant be ... if its n the internet it has to be true ...
<directhex> the internet wouldn't... lie to me!
 * soren imagines a world that adapts itself in order to make whatever was on the Internet true
<ogra> no, its like your TV ... one of the few things that tell the absolute truth in the world :)
 * soren fails
<pitti> Keybuk: http://xkcd.com/386/ ?
<Keybuk> pitti: exactly
<ogra> lool, hrm, seems d-i failed badly on all arches anyway
 * ogra didnt look before ..
 * Keybuk is having the most random issue with jaunty today
<Keybuk> it sometimes resolves IPv6 addresses for things
<Keybuk> and then declares "Network unreachable"
<Keybuk> especially gb.archive.ubuntu.com
<Daviey> WAT
<Daviey> Keybuk: i wouldn't bother listening to that podcast, full of jerks :)
<pitti> tkamppeter: however, it seems that some filters in debian/local/pdf-filters/ still use poppler; that would mean that we'd get a mix of poppler and ghostscript?
<asac> doko: have a clue about http://paste.ubuntu.com/118812/ (from http://launchpadlibrarian.net/22674731/buildlog_ubuntu-jaunty-sparc.ppp_2.4.5~git20081126t100229-0ubuntu1_FAILEDTOBUILD.txt.gz)
<asac> doko: ?
<asac> seems that BIG_ENDIAN and LITTLE_ENDIAN is defined there ;)
<asac> doko: the error say: # error Fix asm/byteorder.h to define arch endianness ... so maybe there is something missing on sparc ?
<asac> or are you the wrong to ask ;)?
<doko> asac: I didn't touch ppp ... maybe fix the configure test?
<asac> doko: well. i dont ask because of pp, just wonder if the sparc header might be wrong
<asac> doko: what is the configure test supposed to do?
<asac> doko: on i386 asm/byteorder.h includes "little_endian.h"
<doko> asac: well, have a look at the linux-libc-dev package
<asac> doko: do you have a sparc jaunty thing somewher?
<ogra> .oO( all the poor sparc dialup users .... )
<asac> hehe
<asac> ogra: more so about the sparc ppp server providers ;)
<ogra> heh, yeah
<asac> i hoped i would get feedback on server capabilities from them. but now ...
<doko> asac: my sparc machine is currently down, so maybe have a look at faure?
<asac> doko: let me check that
<asac> doko: hmm ... seems i have no access to that system
<asac> oh. so kernel is in manualdepwait for sparc
<cody-somerville> Sounds no longer works in Xubuntu. :(
<Tm_T> cody-somerville: is it lighter that way?
<cody-somerville> no
<cody-somerville> Bulkier
<cody-somerville> ala PulseAudio
<Tm_T> cody-somerville: interesting, I had always the sense of lightness when I played good old "indy500" without sound
<cody-somerville> I predict a day of the utmost suffering without my beautiful music : (
<Tm_T> cody-somerville: for that reason I always have backup, lp player
<Tm_T> cody-somerville: as I spend too much time fiddling with upstream
<davmor2> cody-somerville: here borrow mine :)
 * davmor2 passes cody-somerville his music to listen to
<cody-somerville> I think I hear something... oh wait, no... just the snowplow outside :(
 * hyperair wonders what's the state of the intel drivers on jaunty
<Keybuk> I wish grub had copy & paste between reboots
<ogra> implement it :)
<Keybuk> I have too much real work to do
<asac> doko: seems asm/byteorder.h includes linux/byteorder.h while it should inlcude linux/byteorder/big_endian.h
<asac> doko: so i guess -kernel?
<asac> (and drop the #define __BIG_ENDIAN i guess from asm)
<tkamppeter> pitti, the mix of Ghostscript and Poppler in the CUPS filters should not be a problem. Conversions from PDF to PS and vice versa are done with GS now, Poppler is only used for pdftopdf, as Poppler has a better API for page management. Poppler does not render the PDF files here, it only takes them apart and puts them together in another order.
<pitti> tkamppeter: okay
<tkamppeter> pitti, also formerly CUPS uses both Poppler and GS, Poppler for pdftops and Ghostscript for the printer drivers.
<jeromeg> anyone available to review abiword 2.6.6 ?
<primes2h> Keybuk: Could you have a look on bug #255651 please?
<ubottu> Launchpad bug 255651 in linux "floppy disk drive not detected (module not loaded) in Intrepid and Jaunty" [Undecided,New] https://launchpad.net/bugs/255651
<Keybuk> someone filed that one again?
<primes2h> In Hardy all worked out of the box, no floppy modules in /etc/modules
<primes2h> It has 18 duplicates-
<ogra> cjwatson, can we make sure the ixp4xx microcode udeb ends up in the ixp4xx netboot d-i image ?
<cjwatson> ogra: sure, what's it called?
<ogra> hmm, no idea, i dont see an explicit package on http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-firmware/
<ogra> http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux-firmware/nic-firmware_1.6_all.udeb ?
<ogra> i guess rtg just includes it in the std. binary
<ogra> i'll ask
<primes2h> Keybuk: I don't know what changed between Hardy and Intrepid so I don't know where to adress it.
<Keybuk> primes2h: it's a kernel bug
<primes2h> Keybuk: even if module it's not present in /etc/modules in Hardy but floppy works out of the box?
<Keybuk> primes2h: a temporary workaround
<Keybuk> echo alias acpi*:PNP0700:* floppy > /etc/modprobe.d/makemyfloppywork
<_MMA_> Hi all. Anyone from the release team around? The Ubuntu Studio dailies haven't been built since the 2nd. I need to get that remedied.
<primes2h> Keybuk: A wordaround is adding floppy in /etc/modules
<soren> Keybuk: That doesn't work for me. I had a file called acpi-oh-dear-this-is-not-going-to-work:PNP0700:what-do-I-do in my $PWD, when I did it. Does that matter?
<Keybuk> soren: in your PWD ?
 * soren should sleep more at night, /me thinks
<Keybuk> what did that file contain?
<cjwatson> ogra: done
<soren> "im in ur $pwd eeting ur modulz"
<cjwatson> Keybuk: I think soren is trolling your lack of shell quoting
<primes2h> Keybuk: It works but I would like to know what is in charge to let floppy works in Hardy, because no module is present in /etc/modules... Is it built directly in the kernel itself?
<Keybuk> primes2h: hardy has a variant of that line in a file in /etc/modprobe.d
<Keybuk> in fact, intrepid and jaunty have the same file
<lool> soren: haha
<Keybuk> it's just that the file doesn't work anymore, because it's wrong ;)
<primes2h> Keybuk: How can it be fixed so?
<Keybuk> primes2h: it's a one line patch to the kernel
<ogra> cjwatson, thanks
<cjwatson> _MMA_: one moment
<cjwatson> _MMA_: the cron job was apparently commented out; I'm not sure why but can't find a justification for it. I've reenabled it.
<Keybuk> primes2h: it's somewhere in my TODO list
<Keybuk> assuming the kernel team don't get to it first
<primes2h> Keybuk: Unfortunately it's a blocking bug for many many users, newbies firstly...
<Keybuk> but there's 10 of them, and 1 of me, so I outnumber them 1-to-10
<Keybuk> primes2h: the things above it in my TODO list concern more useful hardware than floppy drives :)
<primes2h> Keybuk: ok, but it's just one line... ;-)
<Keybuk> yes, but then I have to test it
<Keybuk> and I have to use git
<Keybuk> which means I have to stab someone afterwards
<Keybuk> and then I have to have the "why not work around it in userspace?" argument
<Keybuk> at which point, I should probably just commit it upstream
<Keybuk> which means it'll turn up in jaunty+1
<Keybuk> in summary: one line patches take more effort than entire new features :p
<jeromeg> anyone here has a few spare time to review bug #318444 ?
<ubottu> Launchpad bug 318444 in abiword "[need-update] abiword to latest stable version 2.6.6 in Ubuntu 9.04" [Wishlist,New] https://launchpad.net/bugs/318444
<primes2h> Keybuk: I don't want to put pressure on you but unfortunately this kind of bug put away a lot of new users in Ubuntu.. :-)
<jeromeg> I won't have much time in the following days, and feature freeze is soon
<primes2h> Keybuk: users that are not even able to report a bug...
<Keybuk> primes2h: those users will be even more upset if Ubuntu fails to mount their root filesystem
<Keybuk> which is amongst the bugs higher up on my list ;)
<_MMA_> cjwatson: Oh odd. Thanx for the fix.
<primes2h> Keybuk: if I find someone providing a patch for this could you review it? (when you have time, of course) :-)
<Keybuk> primes2h: of course
<primes2h> Keybuk: Thank you.
<azeem> w31
<azeem> oops, sorry
<PecisDarbs> pitti: hi there, I have that patch for sl-modem-daemon init script, can I send it to you, will you take look at it?
<ogra> cjwatson, hmm, i suspect there is more to change for the nslug ... in debian it starts an ssh server after booting
<ogra> oh, it does so for me too now, but first asks the kbd questions ...
 * ogra guesses that needs special preseeding
<cjwatson> ogra: as documented ...
<primes2h> Keybuk: just one last thing. Do you mean the patch has to be addressed at the kernel package? Or what else package alternatively?
<directhex> slugbuntu?
 * ogra wonders what kbd to set ... i guess just gb or us is fine ... nobody will use that anyway
<ogra> directhex, yeah :)
<ogra> a hommage to the sydney linux user group ;)
<cody-somerville> hmm... abiword appears to be in main. I thought it was in universe.
<primes2h> Keybuk: I mean, is the bug in the kernel package itself?
<Keybuk> primes2h: it's a bug in the kernel source itself
<cody-somerville> Can someone do me a big fat favour and review/upload an update prepared by one of the Xubuntu contributors jeromeg for Abiword? https://launchpad.net/bugs/318444
<ubottu> Ubuntu bug 318444 in abiword "[need-update] abiword to latest stable version 2.6.6 in Ubuntu 9.04" [Wishlist,Triaged]
 * ogra grins about the nslug loading the PS/2 driver
<pitti> PecisDarbs: great! Please attach it to the bug report
<ogra> hrm, i dont get where d-i pulls the preseed file from during build
<PecisDarbs> pitti: patch attached to bug report with explanation what it does
<pitti> PecisDarbs: thanks
<cjwatson> ogra: build/config/arm/iop32x/netboot.cfg:29: cp boot/arm/glantank.preseed $(SOME_DEST)/$(EXTRANAME)/glantank/preseed.cfg
<cjwatson> that kind of thing presumably
<ogra> cjwatson, yeah, seems the default file is assembled in the oldsys-preseed usdb
<cjwatson> that's a bit different
<ogra> i got a preseed.cfg in the booted d-i but dont see it in the d-i buildlog
<ogra> there is no such thing like the iop32x code for ixp4xx
<cjwatson> oldsys-preseed is for *dynamic* preseeding based on stuff extracted from the device
<ogra> so i assume it comes with a package
<cjwatson> ogra: it's not generic, you would have to write it
<cjwatson> there is normally no default preseed file
<ogra> ah
<cjwatson> unless you've modified your local tree with a preseed.cfg
<ogra> i was assuming there was one since ixp4xx has so much special setup
<ogra> no, i didnt touch my tree
<cjwatson> there's no preseed.cfg in the ixp4xx images in the archive
<ogra> right
<cjwatson> so I don't know why your tree would be picking one up
<ogra> but i have /preseed.cfg in the booted d-i on the device
<ogra> which makes me assume oldsys-preseed created it somehow
<ogra> the values match wahts in oldsys-preseed
<cjwatson> ah, right, yes oldsys-preseed would do that at run-time
<ogra> right
<ogra> cjwatson, btw, dont wait for me with the d-i upload for this ...
<cjwatson> I'm waiting for other things at the moment
<ogra> ok, just want to make sure ... the team has serial consoles anyway so for internal tests the debconf questions wont get in your way
<cjwatson> need debian-installer-utils to publish
<ogra> s/your/our/
 * ogra goes for some late lunch
<ogra> cjwatson, geez, most of the config is hardcoded in the oldsys-preseed script actually
<ogra>                         sanity_check_static_config
<ogra>                         if [ "$NET_CONFIG" != "static" ]; then
<ogra>                                 IPADDRESS=192.168.1.77
<ogra> .....
<ogra> tsk
<ogra> and the static file has exactly the same values ...
<cjwatson> hah. Please take that up in a Debian bug report, I don't want to have to figure it out myself
<ogra> will do
<Keybuk> bryce: why is there an /etc/init.d/xserver-xorg-input-wacom ?
<ogra> Keybuk, i wuld guess it calls hal-set-property to adjust the config
<Keybuk> it does not
<ogra> Keybuk, tablets are tricky since they have multiple input devices
<ogra> hmm
<Keybuk> it makes symlinks
<Keybuk> in fact, it makes one symlink - /dev/input/wacom
<ogra> shudder
<ogra> now that should be halified ...
<ogra> but its probably for backwards compatibility with old xorg.conf setups
<sladen> and IIRC it's wrong anyway, as it's not an *input* (HID) device
<Keybuk> ah
<Keybuk> you misunderstand me
<Keybuk> it makes a symlink, in /dev, to a device node, in /dev
<Keybuk> based on properties found in /sys
<Keybuk> I may be wrong, but we have a daemon entirely dedicated to that purpose
<Keybuk> and would you know, xserver-xorg-input-wacom installs a config file for that daemon
<Keybuk> and WOULD YOU KNOW it makes a symlink with it ;)
<ogra> right, but we had that hardcoded /dev/input/wacom entry in xorg.conf from mr. garret for years
<Keybuk> you still miss the point ;)
<Keybuk> the symlink is already there by the time this init script runs
<sladen> HAL/udev, yes yes yes
<ogra> oh
<ogra> gets it
<ogra>  /me even :)
<sladen> but the symlink that bryce (?) added is wrong anyway, so don't duplicate it
<soren> sladen: Wacom tablets aren't input devices?
<Keybuk> well, yes, having such a symlink is inherently bogus
<sladen> soren: no, they're serial ports
<soren> sladen: What would you call the thing at the end of it?
<soren> I mean.. At the other end of the port?
<sladen> soren: an RS-232 transceivever
 * soren feels like he's missing half a story here
<sladen> the protcol that runs over these serial ports is not HID, or kernel dev/input.  It's a 5-9 byte protocol that must be converted ito HID.  And *that* translated device added to /dev/innput
<ogra> though it doesnt need to create the same symlink twice :)
<sladen> the purpose of the shell script was to search for such "hidden" serial ports, and then tell X to talk magic protocol to those ports
<Keybuk> sladen: no, the shell script doesn't do any of that
<sladen> Keybuk: indeed.  However, that's what used to happen when it did work out of the box, which IIRC, it no longer the case...
<Keybuk> such a shell script would still be wrong
<Keybuk> HAL should do that kind of thing
<sladen> Keybuk: agreed.  If there's now a in-kernel wacom driver (that translates to HID) it should be possible to make it all work "correctly"
<Keybuk> there certainly seems to be
<jeromeg> dholbach: could you please have a look at bug #318444 ?
<ubottu> Launchpad bug 318444 in abiword "[need-update] abiword to latest stable version 2.6.6 in Ubuntu 9.04" [Wishlist,Triaged] https://launchpad.net/bugs/318444
<jeromeg> I would like to get this in before feature freeze
<dholbach> jeromeg: I'd prefer if somebody else could take a look at it - I'm quite busy atm - did you ask in #ubuntu-desktop?
<jeromeg> dholbach: nope, I'll try that
<rgreening> mvo: ping
<mvo> rgreening: pong
<rgreening> heya. I got a q for you... in the apt backend for kpk, do you know if it supports searching the app-install data (desktop) files for applications?
<rgreening> mvo: I am looking at adding a simplified search to kpackagekit, as the default one returns all packages (i.e. libraries, etc) but the end user may only wish to know about applications from the app-install-data package.
<rgreening> mvo: but I need some direction on how to set the correct Client Filter (if it exists)
<mvo> rgreening: I thnk it does exist, glatzor was doing some work on the packagekit backend, he probably knows the answer better than me
<rgreening> ok.
<rgreening> glatzor: I have basically everything complete for a Add/Remove simple view in kpackagekit. I need some assistance on setting a filter for app-install desktop entires only.
<rgreening> ty mvo
<mvo> cheers, sorry that I was not more helpful
<glatzor> rgreening, what should the filter return? the application names?
<rgreening> glatzor: hey. Well, right now, if you filter on Group, it will return all packages in that group. I'd like to filter out libraries, etc and just return valid Applications from the app-install-data package. I was wondering if that exists?
<rgreening> glatzor: like a filter AppOnly option or something
<glatzor> rgreening, getting an application view requires a lot more things than just to hide libraries.
<rgreening> glatzor: well, that's what I am asking...
<rgreening> glatzor: is that backend written?
<rgreening> glatzor: I have a ready to go front-end, if there is a backend filter available to use
<glatzor> rgreening, there is already some code to map packages to menu entries (desktop files) which is used in the gnome utils
<glatzor> but that is not very mature.
<rgreening> glatzor: who is working that piece? if anyone?
<glatzor> rgreening, e.g. it doesn't not handle multiple applications per package
<glatzor> rgreening, richard
<rgreening> glatzor: nick for richard?
<glatzor> rgreening, I already gave you the recommendation to look at this code at UDS. :)
<glatzor> rgreening, hughsie at #packagekit
<rgreening> glatzor: ty. UDS was a long while ago. My brain forgot :)
<rgreening> glatzor: I'll try richard,
<glatzor> rgreening, there is already an infrastructure and terminology in the packagekit api: the basename or gui filter
<glatzor> rgreening, but basenames aren't "yet" implemented in the apt backend
<rgreening> glatzor: which part is that contained it?
<rgreening> glatzor: oh...
<glatzor> rgreening, we can take the discussion to #packagekit
<rgreening> glatzor: is richard the one working on the basename stuff for the apt backend?
<glatzor> rgreening, no. I am the apt backend maintainer and richard is the chief of the whole project :)
<rgreening> ok, can you help me then?
<glatzor> rgreening, he doesn't work on any other backend than the yum one
<glatzor> rgreening, I hope so.
<rgreening> glatzor: ok. so, what do we need to do?
<rgreening> I can help, if you point me to things to test/try.
<rgreening> glatzor: right not my front-end looks liek this... http://imagebin.ca/view/8dy8cR1.html
<rgreening> glatzor: basically, whats missing is the ability to show only end-user apps, which comes down to a filter into the app-install-data somehow.
<apw> pitti, did you get a chance to look at that apport thingy
<kirkland> RainCT: howdy, just got your messages
<kirkland> RainCT: regarding your screen-profiles mousewheel issue, can you read https://bugs.edge.launchpad.net/ubuntu/+source/screen-profiles/+bug/328536 and tell me if that's your issue?
<ubottu> Ubuntu bug 328536 in screen-profiles "confusing scrollbar behavior in gnome-terminal when using screen-profiles" [Low,Confirmed]
<RainCT> hi kirkland :)
<kirkland> RainCT: please see my explanation in Comment 3
<kirkland> RainCT: i think this is what you're experiencing.  if so, i will create a launchpad question/answer for this issue
<RainCT> kirkland: I know the workaround, but I think that didn't happen before
<RainCT> (workaround = that pgup/pgdown works)
<kirkland> RainCT: hmm, okay, then i misunderstand your question
<kirkland> RainCT: this is a regression against an earlier screen-profiles?
<RainCT> I may be wrong though.. Perhaps I did just never try to scroll with the mouse before :P
<kirkland> RainCT: or a regression against the way normal 'screen' works?
<kirkland> RainCT: go back to using normal 'screen' for a moment, in a new gnome-terminal window
<kirkland> RainCT: select-screen-profile, choose "plain"
<RainCT> kirkland: Against normal. I've just tried uninstalling screen-profiles and it doesn't happen
<kees> is this about mouse-scrolling?
<kirkland> kees: yes
<kees> kirkland: what's the expectation, that it _should_ scroll or not?
<kirkland> kees: i'm fixing my cryptsetup mess right now too, sorry.
<kirkland> kees: my explanation is: https://bugs.edge.launchpad.net/ubuntu/+source/screen-profiles/+bug/328536/comments/3
<kees> kirkland: I already uploaded and committed to bzr for cryptsetup
<RainCT> (normal screen just does nothing on scroll)
<ubottu> Ubuntu bug 328536 in screen-profiles "confusing scrollbar behavior in gnome-terminal when using screen-profiles" [Low,Confirmed]
<kees> RainCT: under "Profile preferences" in gnome-terminal, under Scrolling, there is a check-box for "Use keystrokes to scroll on alternate screen".
<kees> is that the setting you're looking for?
<RainCT> my problem isn't exactly the same as in the report though, if I understood it correctly. I have no problems unless I move the mouse whell, in which case I get old stuff.. I have scroll bars disabled and am using terminator
<kees> oh, hm
<RainCT> kees: that's enabled
<s0u][ight> hello where can i find ubuntu staff?
<kirkland> RainCT: you have multiple windows open within screen?
<kees> RainCT: try turning it off, it may change what you're experiencing
<kirkland> s0u][ight: depends on what you're looking for;  post your question, someone will answer if they have the information
<s0u][ight> power is being abused in the turkish help forum
<RainCT> kirkland: irssi, welcome and shell
<RainCT> kees: still the same
<s0u][ight> someone posted a question and the forum admins made fun out of him etc., another one supported that guy and he got banned from the forum
<kirkland> RainCT: okay, and if you use irssi window for a bit, then switch to shell, and mouse-scroll back, you see irssi data?
<RainCT> kirkland: yes
<kees> RainCT: hrmpf
<kirkland> RainCT: right, so gnome-terminal doesn't really understand that screen has multiple windows running beneath it
<persia> s0u][ight, You'd do better to look for a forums admin on #ubuntuforums
<RainCT> kirkland: but without the profile it works
<kees> kirkland: it can depend on one's TERM -- I think there is a way to have screen's scrolling go off the top of the scroll-back buffer.  normally it's contained, though.
<kirkland> RainCT: so with the plain profile, you can open multiple windows?
<kirkland> RainCT: switch among windows
<RainCT> kirkland: err, ignore my last sentence :)
<kirkland> RainCT: roll your mouse wheel and scroll each window's buffer independently?
<RainCT> nope :)
<kirkland> kees: interesting, i'd love to solve that one
<kees> kirkland: yeah, I've never known how to change it.
<kirkland> as i understand it, it's a matter of which program traps and uses the mouse's scrollwheel keypresses
<kirkland> since gnome-terminal is at the top of the stack, i think it captures it first
<kirkland> unless you disable it, and ask it to pass that through to the shell program
<kirkland> if we could do that, then we could probably tell screen to prepend an F7 on the beginning of that
<kirkland> and voila, we'd have per-window scrolling
<pitti> apw: doing right now; good work!
<apw> its a lot better than the last one
<cjwatson> coo, I think I have LVM handling working in kickseed
<cjwatson> but that's enough for the day ...
<_010100> can whomever is the mod on ubuntu-devel ML let my explanation of the effect the pulseaudio auto-spawn will have go through?
<maco> er...right, joke nick --> real nick
<Brujah> Is creative commons licence free enough to be in ubuntu? (for games resources)
<maco> 2.5 or 3.0?
<maco> i think 3.0 is DFSG-free, but 2.5 isn't
<Brujah> f.e. the freesounds project?
<maco> which CC license is it?
<Brujah> Creative Commons Sampling Plus 1.0 License.
<maco> wow that one hasnt been around on creativecommons.org in a while...lemme find the text
<maco> actually...there's a list of DFSG-free licenses
<maco> and yeah, it's on there
<maco> oh wait
<maco> in the "incompatible" category
<maco> Brujah: http://wiki.debian.org/DFSGLicenses
<persia> There's some variance between Ubuntu-free and DFSG-free, for example GFDL and CC-SA 2.5 are Ubuntu-free (if I remember correctly).  One would need to check the ubuntu-devel and sounders mailing list archives to find an actual opinion.
<Brujah> so it could be that this licence is ubuntu-free? :-) the debian guys told me they cannot accept it. I use kubuntu so it would work for me :-)
<james_w> Brujah: it does seem too restrictive, it would be a candidate for multiverse at the very least though
<Brujah> I would rather like to replace everything that causes problems with really free stuff
<Brujah> but for the sounds I cannot find nothing
<Brujah> Its a dungeon crawling game
<Brujah> www.lostlabyrinth.com
<Brujah> we use 48 sounds
<Brujah> are there any free sounds for dungeon games?
<Brujah> there are tiles on sf which we use :-)
<maco> Brujah: got a creaky door and a faucet you can make drip?
<maco> you can always record some free sounds
<Brujah> i lack the equipment I fear. I am a programmer :-)
<persia> You don't have a sound card?  You can get a cheap mic (low-quality recordings are best for compression anyway) and attach it.
<persia> Post the raw sounds, and ask someone to reformat, etc.
<sistpoty> asac: would you volunteer as motu-release delegate for the mozilla team again?
<Riddell> Brujah: CC is fine in Ubuntu (except for no-derivs of course)
<persia> Riddell, All CC?  I thought we preferred 2.0+, and didn't like 1.0.
<persia> (but the sampling license has a different numbering scheme)
<Riddell> I don't think I've come across 1.0 licenced stuff, but 2+ is ok for us.  3.0 or up preferred of course since that's better for Debian
<maco> the sampling license was retired after 1.0, i think
<maco> they got rid of it in june '07
<persia> I thought 1.0 was widely panned as being non-free.
<persia> Anyway, if there's precedent for the license, it's free to upload.  If not, best to ask the TB.  TB response usually seems to be that anything redistributable can go in multiverse, which makes it easy to get included.
<asac> sistpoty: i guess so ;)
<sistpoty> asac: excellent, thanks :)
<sistpoty> superm1: would you be willing to act as mythbuntu delegate for motu-release for this cycle again?
<superm1> sistpoty, yeah should be able to.  i've already been hounding my guys to hit FF, so hopefully there won't need to be too much delegating necessary :)
<sistpoty> superm1: cool, thanks!
<sistpoty> ogra: and would you like to act as motu-release delegate for netbook remix (or whatever mobile is called nowadays) again?
<Brujah> would you accept laby into multiverse? when I remove all the pictures from unknown sources and replace all sounds with cc licenced ones?
<ogra> sistpoty, i hve not much to do with image building this release, i'm mostly doing arm ... StevenK does the ubuntu-netbook-remix and ubuntu-mid images, but it might be a bad time for him
<sistpoty> ogra: ah, thanks...
<ogra> your meeting times are not really aussie friendly
<sistpoty> heh
<sistpoty> I'll ask at a better time then :)
<ogra> siretart, if he cant do it, i can be the fallback though
<sistpoty> ogra: cool, thanks :)
<geser> slangasek: Hi, could you please give bug #323863 another try and move now also the other binary deb and the source to universe too? thanks.
<ubottu> Launchpad bug 323863 in libjdic-java "Please move package to universe" [Wishlist,Confirmed] https://launchpad.net/bugs/323863
<lamont> Keybuk: around still?
<lamont> Keybuk: git clone git://git.debian.org/~lamont/util-linux.git; cd util-linux; git checkout -b foo origin/ubuntu/stable/v2.14
<lamont> gets you the current tree
<lamont> Keybuk: util-linux doesn't use debian/patches, if that's what you mean
<lamont> since that way lies madness
<Keybuk> lamont: what's the difference between master and the other branch?
<lamont> master is "current devel" - basically all of my branches track karel's branches of the same name
<lamont> and then ubuntu/* is a branch from *
<Keybuk> but master has a debian directory?
<lamont> which reminds me, I need to test 2.14.2-1ubuntu1 and upload it
<lamont> sure
<Keybuk> pretent that I'm confused by this whole git multiple branches in a branch thing
<lamont> master is a debian-ish branch based off of karel's master
<Keybuk> so I've done a checkout of your git tree
<Keybuk> is that the util-linux package you upload?
<lamont> I upload from stable/v2.14 or so - since I don't upload until it releases (or will release before our release, such as 2.14.2~rc2 ish)
<superm1> Keybuk, am I to understand this correctly; we're not using upstart to spawn gdm?  I was talking to someone about the priority it starts in Fedora, and they *are* starting it from upstart.  Why not in Ubuntu?
<lamont> and within stable/v2.14, I say "debuild -I.git -S" or so
<Keybuk> so how do you keep all these changelogs straight?!
<lamont> I don't bother with changelog until I'm uploading, and then I grab the 1-liner from each commit, along with it's author, to generate a debian changelog
<lamont> that, mixed with never committing debain/ and !debian in the same commit -> love
<Keybuk> so how does a changelog end up in master?
<Keybuk> is that when 2.14 itself was released?
<lamont> see also the commits with a log of 'changelog: release'
<Keybuk> so your stable/v2.14 branch is what you actually upload as util-linux right now
<lamont> master got a merge of the stable stuff at some point, it's probably seriously diverged
<Keybuk> and that is based off Karel's stable/v2.14 branch
<Keybuk> where does the ubuntu one come from?
<Keybuk> do you just track other people's uploads with it?
<lamont> the tag v2.13
<lamont> meh
<lamont> the head of stable/v2.14 is what I will have uploaded as 2.14.2-1 to debian, and head of ubuntu/stable/v2.14 will be 2.14.2-1ubuntu1 once I reboot my laptoo
<lamont> p
<lamont> at that point, I'll tag both trees, and push again
<Keybuk> and when karel releases 2.15 off master, you'll merge the debian stable/v2.14 back into your master branch?
<lamont> possibly even before that, but yes.  2.15 release from karel means: merge my stable/v2.14 and his v2.15 branch to a new stable/v2.15 branch
<lamont> and yeah, smack it onto master as well at the same time
<Keybuk> and people wonder why I laugh when they say revision control makes packaging easier
<lamont> heh
<lamont> OTOH, having a debian repo and a !debian repo makes me cry
<lamont> so I quit trying
<lamont> and directory-per-branch is one of the reasons I went with git instead of bzr when I did my mass exodus from CVS/TLA/arch in 05ish
<lamont> that is, bzr's then-insistence on one-directory-one-branch was a major factor in not going there
<Keybuk> debian repo and !debian repo?
<lamont> I understand that's been fixed since then...:-)
<lamont> some people like to have foo-1.1/.bzr and foo-1.1/debian/bzr and then magically do wonders to smash them together into a package to upload
<lamont> maybe my failure to understand what they were doing is a factor in the screaming fit I had running from them
<lamont> anyway - rebooting, brb (or screaming, pretty sure it'll be the "brb" option)
<Keybuk> well, in theory, the Ubuntu diff should go away anyway
<Keybuk> the vol_id/blkid thing is fixed upstream
<Keybuk> you should just merge the udev hooks into Debian
<Keybuk> and the fallback clause stuff should be sent upstream, and merged into Debian too
<Keybuk> the udev rules directory change should go into Debian as well
<calc> jcastro: how long did it take your lenovo to clear customs?
<calc> my laptop has been sitting in US customs for 3 days it appears
<directhex> Setting up monodevelop (1.9.2+dfsg-1~pre1~jaunty3) ...
<jcastro> calc: 3/4 days
<directhex> jcastro, ^^
<dtchen> cody-somerville: RE: your e-mail to -devel, please note that *only* ubuntu-desktop seeds PulseAudio. None of {[kx],myth}ubuntu{,studio}-desktop do.
<dtchen> cody-somerville: your inaudible audio issue cannot possibly have anything to do with those PulseAudio changes unless you installed pulseaudio explicitly.
<ogra> dtchen, wow, do you have a shotcut key for that regex ? :)
<ogra> *short
<jcastro> directhex: ! awesome
<calc> jcastro: ok
<directhex> jcastro, needs a bugfixed mono-addins, which is in debian incoming
<superm1> dtchen, i think that he was referring to breakage that happens when you install xubuntu-desktop on top of ubuntu-desktop and switch between the two
<dtchen> superm1: which is by no means default, but yes, that's one specific test case i'm running locally
<superm1> dtchen, yeah.
<lamont> Keybuk: though the debian/control diff will not go away until udev has a similar version between the two distros...
<dtchen> i've already identified a regression, but its probability of striking that particular use case and the one of only default *-desktop needs more feedback.
<lamont> BTW, uploaded, and pushed
<dtchen> (referring specifically to autospawn in this instance)
<Keybuk> lamont: that's never going to happen :-(
<Keybuk> lamont: did you deliberately miss out two ubuntu revisions?
<calc> jcastro: i ended up buying a seagate 7200.4 500gb drive for mine, hopefully it won't be hard to swap out
<cody-somerville> dtchen, I have ubuntu-desktop installed
<cody-somerville> in addition to xubuntu-desktop
<lamont> Keybuk: probably not deliberately, no.
<lamont> but then, if it's a random upload to ubuntu, i don't always get it back into my tree, esp if it gets superseded before I get to it
<persia> lamont, Can you not get it by revision from patches.ubuntu.com or LP?
<Keybuk> lamont: gnargh!
<Keybuk> lamont: it's ok to miss them when you're doing Debian uploads, but uploading to Ubuntu without checking is just not cool
<Keybuk> lamont: need some git help here
<Keybuk> I cannot seem to push my branch anywhere with my changes
<TheMuso> dtchen: Have you noticed that if an alsa-info URL is broken into two lines in an email, it doesn't work?
<RAOF> What would be an appropriate way to debug "Evolution spends the first 30 minutes thrashing the disk after startup"?  strace?
 * calc has to remember how to determine how to properly handle the ooo human icons set
<lamont> Keybuk: as in I dropped changes?
<lamont> which would not be the intention
<Keybuk> lamont: so, I've made a git branch with the missing changes
<Keybuk> and I've added a changelog
<lamont> thanks
<Keybuk> now, how the hell do I push this somewhere?
<Keybuk> because every time I do, git explodes in a violent array of puke or nothingless
<lamont> git push ssh://git.debian.org/public_git/util-linux.git I expect
<lamont> er..
<lamont> git push ssh://git.debian.org/public_git/util-linux.git ubuntu/stable/v2.14
<lamont> or so.
 * lamont needs to run for an hour or so, unfortunately
<Keybuk> why ubuntu/stable/v2.14?
<RAOF> That would be the branch you want to push to, I think.
<Keybuk> then I just get:
<Keybuk> error: src refspec ubuntu/stable/v2.14 does not match any.
<RAOF> Keybuk: What does 'git branch -a' say?
<Keybuk> RAOF: lots, what are you looking for specifically?
<Keybuk> http://rafb.net/p/YnJptB92.html
<RAOF> Keybuk: I was hoping that the one with at * next to it was ubuntu/stable/v2.14
<Keybuk> no
<Keybuk> I couldn't do that
<Keybuk> as soon as I tried to do anything on that branch, git threw me into a nameless branch
<Keybuk> so I had to give it a name
<Keybuk> thus "ubuntu"
 * RAOF hates on git.
<Keybuk> all I want to do is push _this_ branch somewhere that lamont can get it
<RAOF> Maybe just 'git push origin' will work, then.
<Keybuk> I can't push to an http url, can I? :)
<RAOF> Mess with .git/config until it's no longer http? :).  I don't really know; I was just trying to help with my fairly minimal git knowledge.
<directhex> silly git
<Keybuk> how will that help?
<Keybuk> I can make it ssh, but I don't have access to that machine
<RAOF> Oh.
<RAOF> I'm out of my depth then, sorry.
<dtchen> cody-somerville: file a bug, then.
<dtchen> TheMuso: no. do you mean MUA parsing?
<TheMuso> dtchen: No, never mind, I am working around it by going to the web page for the bug.
#ubuntu-devel 2009-02-17
<Keybuk> lamont: ok
<Keybuk> lamont: http://kernel.ubuntu.com/git?p=scott/util-linux.git;a=summary
<Keybuk> lamont: that either includes the missing uploads which I've uploaded again
<Keybuk> lamont: or it contains hard core porn
<Keybuk> lamont: I'm not entirely sure which, but it says "master" so it could be either
<Keybuk> lamont: if you pull from that into your ubuntu branch, things may work out
<Keybuk> lamont: and if they do, I'll use that to push any further uploads
<Keybuk> lamont: (until sabdfl notices, and makes you use bzr like a sane person <g>)
<ion_> :-P
<Keybuk> seriously, two hours to get a branch pushed
<Keybuk> the next time someone tells me that git is easy to use, I'm going to bypass subtlety and go straight for the chainsaw to the face
<ion_> Git is easy to use.
<RAOF> FSVO easy.
<Keybuk> ion_: you're only able to get away with that because you know we'll never meet :o)
<ion_> Who knows. :-)
<ogra> ion_, only for masochists though
<cjwatson> Keybuk: every time I complain about git being hard to use, people tell me it got much easier in 1.5
<cjwatson> Keybuk: then I point out I'm already using >=1.5, and they sort of shrug
<TheMuso> Git is hard to use if you are not used to its workflow.
<Keybuk> no
<Keybuk> Git is hard to use
<TheMuso> I am warming to it a lot more recently, since I've had to get used to its workflow.
<cjwatson> ah, now that's code for "git fails to adapt to my workflow"
<TheMuso> Whatever... I am at the point where I feel reasonably comfortable with it.
<Keybuk> TheMuso: ok, you have a branch in your working directory
<Keybuk> you've committed some patches to it
<Keybuk> how do you make that public?
<Keybuk> in 1,000 words or less, please
<TheMuso> Keybuk: Depends on how many patches. If a lot, it may be worth creating a git branch on a host, and pushing to that via ssh.
<TheMuso> Otherwise, use git format-patch to create mailable patches.
<ion_> Do a couple of clicks at github and paste the command it gives to your terminal. :-P
<TheMuso> ...this is assuming I am actually understanding what you are asking.
<Keybuk> since git can't even process MIME, let's ignore the e-mail option
<Keybuk> I want to publish a branch
<cjwatson> TheMuso: he's asking for the direct equivalent of 'bzr push sftp://host/path/to/published/directory'
<Keybuk> I know what it is now
<Keybuk>   ssh host
<Keybuk>   cd /path/to/published
<Keybuk>   GIT_DIR=directory git init
<Keybuk>   chmod +x directory/hooks/post-update
<Keybuk>   ^D
<Keybuk>   git remote add ssh://host/path/to/published/directory
<TheMuso> Keybuk: I've never created a git branch on a host from scratch, so haven't had to go through those steps yet.
<Keybuk> err
<Keybuk>   git remote add wibble ssh://host/path/to/published/directory
<Keybuk>   git push wibble mybranch
<Keybuk>   ssh host
<Keybuk>   cd /path/to/published/directory
 * RAOF 's brain collapses.
<TheMuso> Ok so you are saying bzr just does it, interesting. Again, I have never had to do that with git.
<TheMuso> So can't comment.
<Keybuk>   rm -f refs/HEAD
<Keybuk> err
<Keybuk>   rm -f HEAD
<Keybuk>   ln -s refs/heads/mybranch HEAD
<Keybuk>   git update-server-info
<Keybuk>   ^D
<doko> ubuntu-archive: some distraction: please accept python3-stdlib-extensions and python3-profiler in source NEW
<ogra> doko, you are breaking the rant for an actual work request ... damn you :)
 * ogra was actually pointed to the git gui tools today since you would understand the cmdline tools way easier through that :)
<cjwatson> TheMuso: do you have any idea why the ia64 kernel seems to have suddenly bloated up from 5.something MB to 16 MB?
<cjwatson> TheMuso: it made d-i fail to build; I can probably work around it but it seems perhaps accidental?
<TheMuso> cjwatson: Probably a configure option that got enabled when it shouldn't have been, I'll have a dig tonight and see what I can find, and fix it along with other changes I need to make in another upload in the next day or so.
<cjwatson> TheMuso: thanks
<Keybuk> http://www.netsplit.com/2009/02/17/git-sucks/
<Keybuk> I feel better
<calc> Keybuk: yuck
<calc> Keybuk: i'm glad i don't use git :)
<TheMuso> Keybuk: Ok, I feel your pain now.
<Rocket2DMn> cjwatson, hi.  I see that you are in charge of the Installer Team, do you have good contact with the Wubi guys?
<Keybuk> Rocket2DMn: we keep at least one of them tied up in the basement at all times
<Rocket2DMn> cjwatson, I wanted to let you know that the link to the Ubuntu Forums from the wubi homepage is no longer good, that forum area was removed this evening - is that something you can pass along to them?
<Rocket2DMn> Keybuk, probaby a good place :)
<cjwatson> Rocket2DMn: I talk to them every now and again, but it would be better to mail Agostino directly: https://launchpad.net/~ago has his address
<Rocket2DMn> ok, i'll do that, thanks cjwatson
<Mavericks> hello everyone anyone applied for a job @ canonical - If this is the wrong place to ask, I apologize beforehand - I am little desperate, and any help will be appreicated
<cjwatson> Mavericks: this really isn't the right place, although I'm not sure what would be. What is the problem?
<Mavericks> I wanted to find out if anyone around here (any developer) had a chance to apply for jobs @ cannoical, and would like some feedback
<Mavericks> as i did apply, and am given 21 day grace time for their decision
<Mavericks> I am actually a student, and that makes it all the more complicated
<cjwatson> I'm not sure what you're looking for feedback about, is the thing ...?
<cjwatson> if you applied, you ought to get feedback in the usual way for job applications
<Mavericks> ok
<Mavericks> well, so far no correspondence, and i have four days left until end of 21 day grace time - i think it is too late, and i am also guessing that the recession might have had an impact
<cjwatson> beyond that I'm not really sure what you're asking other applicants for :-)
<Mavericks> feedback regarding general procedures, what kind of applicants are their first preference, and sort of suggestions/tips on passing that first round interview phase
<cjwatson> if you're concerned about progress, you should probably send a nag mail to the HR people
<Mavericks> people who had applied before,  or had some experience with canonical would know a bit and i thought would be able to help prospective applicants
<cjwatson> www.ubuntu.com/employment is pretty clear about what kinds of applicants generally get first preference: "Please note that in general preference will be given to existing community contributors"
<cjwatson> though obviously that's not always going to be overriding if somebody else really good comes along
<Mavericks> yeah i have seen that, but some sort of correspondence would be nice. i guess with the huge volume of job apps. , it is really tough
<Mavericks> sigh
<cjwatson> I don't have an insight into the current volume of applications; I imagine it will depend somewhat on the hiring manager for the particular post being advertised
<Mavericks> yeah , makes sense
<lamont> Keybuk: heh.  thanks
<ember> cjwatson when you have time can you look at http://bugzilla.gnome.org/show_bug.cgi?id=556114
<ubottu> Gnome bug 556114 in gparted "no longer sees /dev/mapper/* devices" [Normal,Reopened]
<cjwatson> ember: yes, it's on my enormous to-do list
<cjwatson> (already)
<ember> heh just a reminder, i was checking the merge for 0.4.1 and i saw that
<cjwatson> I will deal with gparted >= 0.4.2 by feature freeze, at least
<cjwatson> or intend to at any rate
<cjwatson> however, there are other things ahead of it in my list
<Mavericks> cjwatson: have you come across students who work for canonical by chance?
<Mavericks> i mean in the IRC ,, or if you happened to meet before any of such student developers
<cjwatson> Mavericks: it happens from time to time, sure
<Mavericks> ok. "it happens from time to time,sure" helps a LOT
<ScottK> Mavericks: You are really off topic for this channel.
<Mavericks> cjwatson: my emphasis was on the assurance i got from that statement, and wanted to express that using caps on LOT
<Mavericks> thank you ScottK and persia for the responses
<Mavericks> i didn't intend to flood the IRC with these questions, and as I was talking to cjwatson, I tried to locate the HR for ubuntu
<ScottK> Mavericks: Ubuntu doesn't have HR. It is a free software project.
<Mavericks> Oops, my bad. I mean't to say HR for Canonical.
<ScottK> Right, which gets back to this being totally the wrong place.
<cr3> where's the wiki page providing a sample bug format for requesting sponsorship?
<ScottK> There isn't a set form.  Just subscribe ubuntu-main-sponsors or ubuntu-universe-sponsors to the bug.
<ovnicraft> hi, when i clone displayconfig-gtk from launchpad give the pkg for ubuntu, how i can get the src?
<jdong> Keybuk: You've made my day. Someone else who feels Git is ridiculously unintuitive to the uninitiated...
<spenser> Hi can anyone enlighten me on how to setup a branch of the linux kernel on a personal git server that keeps up to date with the latest mainline?
<dholbach> good morning
<ion_> morniÅ
<dholbach> hiya ion_
<ion_> Hi
<pitti> Good morning
<directhex> morning pitti
<ion_> morniÅ
<gimpuzmani_> hi
<PecisDarbs> pitti: good morning, just for info sake, I did a updated patch for #298424, few things ironing out
<pitti> PecisDarbs: I saw
<PecisDarbs> I could do a patch for jockey, but I didn't know if you allow to use subprocess there :)
<pitti> PecisDarbs: sure, I use subprocess all the time
<PecisDarbs> ok, then I will do it for jockey too
<pitti> cool
<primes2h> pitti: Hi, what about jockey icons that come up in emblems? Are you planning to remove them in time for Jaunty?
<pitti> primes2h: hm, that should already be fixed...
<pitti> jockey (0.5~beta3-0ubuntu11) jaunty; urgency=low
<pitti>     - Move status icons from emblems/ to actions/, emblems/ are wrong.
<primes2h> pitti: I have jockey (0.5~beta3-0ubuntu13) but jockey icons are still in nautilus->Edit->Backgrounds and emblems->emblems
<pitti> primes2h: hm, indeed; can you please file a bug and assign it to me? looks like a packaging bug
<primes2h> pitti: ok.
<dholbach> good morning, seb128! didrocks told me what you guys found out about the sponsoring script - I fixed it - thanks a bunch
<seb128> dholbach: hello, thank you!
<seb128> dholbach: I'm guessing that was bugs with no comments triggering the issue but was not sure
<dholbach> seb128: that was exactly it
<dholbach> seb128: in those cases I now display the bug reporter
<seb128> dholbach: ok good
<primes2h> pitti: done, bug #330421. There is also another place where jockey icons are present. see bug report.
<ubottu> Launchpad bug 330421 in jockey "Jockey icons shouldn't be present as emblems" [Undecided,New] https://launchpad.net/bugs/330421
<primes2h> pitti: thanks
<IntuitiveNipple> Q: Should a package install using update-alternatives fail when the install scripts use the update-alternatives --quiet option? I've got a user with failed installs of gij-4.2 and apt is 'stuck'
<IntuitiveNipple> update-alternatives man-page claims --quiet isn't yet implemented
<mok0> I would appreciate a "soonish" ACK of jeuclid in the NEW queue, since we have a dependent waiting for it (scilab)
<lool> pitti: Hey, the glibc in the archive has a "rm -f $(CURDIR)/po/*.mo" which the one in bzr doesn't seem to have
<pitti> lool: hm, very weird; I built it from the bzr tree..
<lool> is ~ubuntu-toolchain/ubuntu-toolchain/glibc-2.5-package the good branch?
<lool> pitti: Oddly, this rm is present twice in the archive
<lool> >-------rm -f $(CURDIR)/po/*.mo
<lool> >-------rm -f po/*.mo
<lool> in clean::
<pitti> lool: I branched from that and pushed mine separately; I asked doko to pull mine into that
<pitti> lool: however, I didn't touch any po/mo stuff, so it shouldn't differ
<lool> pitti: It might be that I'm not looking at the right branch, I don't see your commits
<pitti> lool: https://code.edge.launchpad.net/~pitti/ubuntu-toolchain/glibc-locales-debmerge is mine
<pitti> lool: oh, hang on, I also merged with Debian, which might have pulled in that fix
<pitti> lool: I just can't push to ~ubuntu-toolchain, which is why I had to do it like that
<pitti> someone in ~ubuntu-toolchain please pull my branch
<lool> pitti: I see your changelog entries, but not commits; I guess doko did the merge himself
<doko> didn't merge yet ... will do
<lool> doko: pitti's changelog entries are in the tree though
<lool> Hmm perhaps I added them
<lool> Grmpf, I'll have to revert my commits to drop them now
<pitti> lool: bzr-rebase FTW :)
<lool> pitti: I'll try, but last time I used it, I was really disappointed
<lool> I ended up bzr uncommitting and bzr stashing a bunch of times
<lool> Now because I needed the tarball I worked from both an apt-get source tree and the bzr tree to offer my changes for merging; as a result I mixed pitti's changes in the archive with mine when I committede to bzr
<lool> pitti: How did you build glibc directly from the bzr tree?  ln -s . debian and bzr bd?
<pitti> lool: tar xzf ../glibc_*orig.tar.gz --strip-components=1 and then just debuild -S /debuild -us -uc -b
<pitti> I should learn bzr-builddeb some day..
<lool> pitti: But the glib branch doesn't have a debian dir
<pitti> lool: no, that *is* the debian dir
<pitti> bzr get lp:.... debian
<lool> Ok; I usually keep the branch name as dir
<pitti> yeah, I don't do it like that either, it also breaks debcommit, etc.
<lool> Yes, ln -s . debian helps for dch/debcommit
<lool> I guess it's historical due to the vcs-import
<doko> now merged
<lool> wow bzr rebase worked like a charm here, excellent
<asac> anyone knows what the group "dip" stands for?
<asac> like Bug 292203
<ubottu> Launchpad bug 292203 in ppp "/usr/bin/pppd has group owner dip, not dialout" [Undecided,Invalid] https://launchpad.net/bugs/292203
<asac> Keybuk: when replugging USB modems duplicates the hal entry is that a udev issue?
<petski> asac, seems to be "Dial-Up IP"
<asac> hmm wiki.ubuntu.com down, anyone?
<seb128> asac: no
<asac> hmm ... seems my dns has problems
 * asac reconnects
<sistpoty|work> seb128: would you be willing to act as motu-release delegate for ubuntu-desktop for jaunty?
<lool> Hmm is it on purpose that the bootchart update recreates all my initramfses, not just the current one?
<seb128> sistpoty|work: which means grant desktopish freeze exception right?
<sistpoty|work> seb128: yep
<pitti> lool: I think so, yes
<seb128> sistpoty|work: yes
<sistpoty|work> seb128: excellent, thanks!
<seb128> you're welcome
<directhex> hm, i need to read up on appropriate bribes for seb128
<seb128> ;-)
<directhex> how do you feel about cake?
<seb128> what I like is people helping on desktop updates ;-)
<lool> pitti: Ok; any reason for bootchart to be specific in this respect?
<pitti> lool: I don't think it's special at all; other packages like cryptsetup or lrm regenerate all as well, AFAIR
<seb128> lool: why should it be limited to the current one?
<pitti> lool: also, you might want to compare speed with different kernels, etc.
<seb128> lool: you want to be able to bootchart using any installed linux version no?
<lool> Hmm I don't know
<lool> I think we don't automatically change all initrds because we want to allow keeping safe working ones around
<lool> At least I think that's the rationale behind e.g. udev only updating the current initrd
<lool> even if I might want the latest udev and its fixes in all initrds, we don't update all because we want to keep the old ones working
<seb128> ok, that makes sense too, better to let somebody who has a clue about a policy reply now ;-)
<lool> The thing is I can understand either of bootchart or udev's behaviors, but not mixing the two in the archive
<seb128> do we have a policy about that?
<lool> seb128: I think you have a point that this should be in policy, I agree
<PecisDarbs> pitti: attached patch for jockey for sl_modem.py to #295158, check it out if that's ok
<pitti> PecisDarbs: thanks a lot! won't have time for that today, but that can wait well until after FF anyway
<PecisDarbs> pitti: will it make it into Jaunty? :)
<pitti> PecisDarbs: sure
<directhex> FF is for upstream versions, not package versions, right?
<PecisDarbs> that's all I need to know, thanks :)
<pitti> directhex: no, for features
<lool> seb128: I filed #330455
<lool> But I guess I should rather be bringing this up on ubuntu-devel
<seb128> bug #330455
<pitti> directhex: bug fix only upstream versions are okay
<ubottu> Launchpad bug 330455 in ubuntu-policy "Please document or specify proper update-initramfs usage" [Undecided,New] https://launchpad.net/bugs/330455
<seb128> right, I was going to suggest that
<seb128> lists are better for such discussions
<directhex> pitti, okay, gotcha. that gives me, hrm, 2 days to get monodevelop 2 beta in. and gnome-subtitles 0.8 (which dep-waits on something in NEW)
<apw> pitti, guess what ... i have some more changes for apport, same branch.  the first two changes on there seem pretty obvious, the last needs some review as it needs to run some of the hooks earlier and there is possibly a better way to do that
<pitti> apw: ah, great; can you please mail me? I'm terribly busy today
<Laney> are REJECT/ACCEPT mails sent to any publicly accessible place?
<sistpoty|work> any archive admin around, who'd know why sabnzdplus was rejected? (the reject mail contained no hint)
<pitti> sistpoty|work: ScottK rejected it, and wanted to send out one
<Laney> sistpoty|work: It has been reuploaded to NEW anyway
<sistpoty|work> pitti: ah, I see, thanks
<sistpoty|work> Laney: ah, then I guess it was on request from the packager
<pitti> ScottK: please CC: ubuntu-archive@ for reject mails
<sistpoty|work> Laney: as I told the packager to check with ubuntu-archive in regards for the .js thingies in there
<Laney> sistpoty|work: Actually I think I remember some talk in -motu yesterday
<Laney> maybe check the irclogs
<sistpoty|work> Laney: good idea, thanks
<asac> StevenK: yt?
<StevenK> asac: Hum?
<asac> StevenK: i wanted to push connman and wonder if you would be available for a quick archive round ;)
<asac> since its mobile you seem to be a perfect match ;)
<ScottK> pitti: I did cc ubuntu-archive, but it was moderated.
<ScottK> sistpoty|work: I sent mail to the address in your GPG key.
<ScottK> sistpoty|work: Also (archive hat off/motu hat on) I reviewed an update and re-uploaded it last night.
 * StevenK grins at ScottK's last line
<directhex> which hat is easier to bribe?
<Keybuk> asac: no, almost certainly not
<Keybuk> it could be a kernel issue
<Keybuk> but I expect it's a HAL isue
<asac> Keybuk: could i check by restarting hal?
<asac> i assume so ;)
<Keybuk> yes
<Keybuk> the reason it's unlikely to be a udev issue is that udev actually doesn't keep any kind of in-memory database or list of devices
 * ogra points lool to bug 231960 ... there is that scott guy who seems to be able to point you to a policy
<ubottu> Launchpad bug 231960 in bootchart "only regenerates initramfs for first kernel found" [Undecided,Won't fix] https://launchpad.net/bugs/231960
<cjwatson> ScottK: I've adjusted the moderation settings so that your mails should be auto-accepted in future
<Keybuk> ogra: and I fixed that bug afterwards ;)  what's your point?
<ogra> Keybuk, that lool just filed bug 330455
<ubottu> Launchpad bug 330455 in ubuntu-policy "Please document or specify proper update-initramfs usage" [Undecided,New] https://launchpad.net/bugs/330455
<cjwatson> Keybuk: it's unusual for packages to regenerate *all* initramfses, and has the practical problem that you can be left without any working backup initramfs
<cjwatson> everything else just regenerates the current one for this reason
<Keybuk> I agree
<Keybuk> but I got bored of people nagging at me every other week because bootchart only regenerated the current one
<Keybuk> (or only regenerated the -generic one, not the -server one, etc.)
<cjwatson> the -generic/-server bit was unfortunate, I agree
<ogra> Keybuk, you say "its ubuntu policy" in my bug so i thought i should point lool to the person which knows where its written down ;)
<Keybuk> since people install bootchart for doing tests, I figured they are likely to be trying to compare different kernels
<cjwatson> perhaps we should have an update-initramfs to regenerate all kernels of the current ABI?
<Keybuk> ogra: like most ubuntu policy, it's written down in someone's head ;)
<cjwatson> s/to /option to /
<ogra> haha
<Keybuk> cjwatson: then you couldn't compare two kernel ABIs with bootchart, etc.
<cjwatson> yeah, it's not an entirely obvious case
<cjwatson> I do agree that it should be documented for all other cases
<ogra> cjwatson, so by the looks of it, yesterdays d-i build doesnt have the slug firmware :(
<sistpoty|work> ScottK: ah, thanks... (/me admits to not having checked that adress for two weeks or so *g*)
<ogra> (20081029ubuntu18 is what i tested)
<cjwatson> cjwatson@cocoplum:~/ubuntu/dists/jaunty/main/installer-armel/current/images/ixp4xx/netboot$ zcat initrd.gz | cpio -it | grep firmware/NPE
<cjwatson> lib/firmware/NPE-C.02020201
<cjwatson> is that not correct?
<cjwatson> lib/firmware/NPE-B.01020201
<ogra> weird
<ogra> ~ # ls /lib/firmware/
<ogra> ~ #
<cjwatson> slug is ixp4xx, yes?
<ogra> yep
<cjwatson> you're absolutely sure you're booting the current image?
<ogra> yes, the former ones didnt boot
<cjwatson> I'd be double-checking if I were you, since there should be a number of other files in /lib/firmware/ too
 * ogra agrhs
<ogra> sorry, i downloaded the right one but used the upslug command from my bash history (which indeed dumped di-nslu2-test.bin and not di-nslu2.bin into the flash)
 * ogra slaps head and starts over
<ogra> pitti, evolution-indicator supposed to replace my mail notification plugin automatically ?
 * ogra starts getting annoyed having his desktop cluttered with 100s of little notification windows
<pitti> ogra: no, I don't think so
<pitti> ogra: I don't know how the transition will be done yet, I'll ask the DX team
<ogra> ah, k but its the same function then at least
<amitk> ogra: what ppa is this notification work available in?
<ogra> cjwatson, looks better :)
<ogra> amitk, see other chan
<cjwatson> ogra: oh good
 * ogra wishes he had ifconfig in d-i ...
<cjwatson> you have ip
<liw> mvo, ping
<mvo> liw: pong
<ogra> oh, right, i always forget out it :)
<ogra> *about
<seb128> dholbach, mdz: you had the ssh agent issue right? can you tell me if yesterday's upgrade fix the bug for you?
<liw> mvo, I've just pushed the new-plugins branch again, it has plugins for nfs-common, kdeblibs5-dev, and language packs; I did not write one for fglrx, since that needs a UI and we need to discuss how to deal with that
<mvo> liw: ok, thanks. I will check it out.
<mvo> liw: I will probably have to modify the scd0 one a bit, but otherwise the previous push looks good
<Riddell> liw: new plugins?  kdelibs?  what's all this?
<liw> mvo, I can imagine there being a lot of bugs, but I didn't want to write tests, since these things seem best tested with your existing distupgrade tests
<liw> Riddell, we're integrating update-manager and computer-janitor code bases
<mvo> liw: I'm finishing some work that the DX team requested now, then I'm all yours
<liw> Riddell, i.e., just refactoring how upgrades and related tweaks work, no functionality changes anywhere
<liw> mvo, ack
<bigon> hi
<bigon> does anybody know which program network manager uses to get the dhcp lease?
<mdz> seb128: I'm in the office today but will upgrade my home system tomorrow
<mdz> bigon: dhclient
<lool> cjwatson, Keybuk: what about allowing a list of kernels to update-initramfs for?  much like we have menu.lst per-kernel kopts: we could include all 2.6 or all 2.6.28 or specific flavours etc.
<seb128> mdz: ok, let me know next time you try then!
<Keybuk> lool: that sounds over-complicated
<lool> Keybuk: Would it be good enough to only update-initramfs on all kernels on the initial install and not on upgrades of bootchart?
<bigon> mdz: I was asking because it seems that some post-exec scripts of dhclient are not executed
<lool> Keybuk: What's complicated in a list of kernels for which you care to always update the initramfs?
<lool> The default would be current behavior and people can change it to all if they dare
<dholbach> seb128: fixed here
<seb128> dholbach: danke!
<Keybuk> lool: it sounds like a very random "configuration option to solve the problem" solution
<lool> Keybuk: it would solve user complaints while allowing us to default on what's sane?
<lool> Keybuk: You changed upstart to silence the complaints but increasing the risk of breakage
<Keybuk> lool: what are the complaints?
<lool> s/upstart/bootchart  :-)
<lool> Keybuk: 12:54 < Keybuk> but I got bored of people nagging at me every other week
<Keybuk> no, I mean, what are the current user complaints?
<lool> Keybuk: My complaint is that this puts my systems at risk
<Keybuk> of what?
<lool> Of a bootchart upgrade updating all my initrds and breaking all of them
<Keybuk> can you forsee a breakage?
<lool> I keep older kernels because I want to try them out with current ubuntu or because I want to recover with them
<Keybuk> what kind of breakage are you expecting?
<lool> For instance the recent udev breakage with the md devices
<pitti> there's still an initrd.bak, isn't there?
<Keybuk> you'll be broken by that anyway
<Keybuk> if the currently installed udev doesn't work with the older kernel
<Keybuk> it won't work with the older kernel
<lool> Would I have received a bootchart update along the new udev, I wouldn't have been able to boot my system easily anymore
<Keybuk> getting out of the initramfs just means it won't fail so quickly
<mdz> bigon: I believe it supplies its own dhclient-script
<lool> Keybuk: The fact is I could boot with the older initrd
<lool> pitti: Don't think so
<bigon> mdz: it's quite annoying
<cjwatson> mvo: do you think I could drop aptitude's recommendation of libparse-debianchangelog-perl to a Suggests?
<Keybuk> lool: why did you install bootchart, out of interest?
<Keybuk> installing bootchart would have instantly broken your current running kernel
<lool> Uh?
<Keybuk> so you would have had to have had a fallback kernel there anyway
<lool> I had bootchart installed already when that happened
<cjwatson> mvo: I want to make tasksel have the option to run aptitude in the installer; recommending libparse-debianchangelog-perl pulls quite a lot of stuff into the debootstrapped set
<Keybuk> any particular reason?
<lool> I just bootchart every boot and I take a look from time to time
<mdz> bigon: it may be that NM's script needs to be fixed to invoke the same hooks as the default one
<mvo> cjwatson: I need to check what it is used for to be certain but for now I would say it is fine
<cjwatson> mvo: changelog parsing is not particularly useful in the installer, but it does mean that people would need to install libparse-debianchangelog-perl in order to get changelog parsing after boot; this seems like a fairly reasonable tradeoff
<mvo> cjwatson: agreed
<cjwatson> it's used for the "view changelog" option - it parses the changelog and displays it in some more digested way
<cjwatson> all right, I'll do that then
<lool> Keybuk: So what do you propose to stop updating all initramfs-es each time bootchart is updated?
<cjwatson> my installer change is still a little ropey - for some reason only packages that are actually to be installed are showing up in aptitude
<Keybuk> lool: I don't see a problem with updating them all
<soren> Keybuk: I do.
<soren> Keybuk: I might have some rather old kernels that don't work very well with a newly generated initramfs.
<lool> I see that as an issue, I think cjwatson understands the issue as well (I don't know whether he cares), pitti also mentionned initrd backups (I don't know whether he cares)
<Keybuk> soren: then they won't work very well with the userland either
<cjwatson> mvo: hmm, alternatively I could say that it doesn't really matter much if we pull those packages into debootstrap since they're already in standard
<cjwatson> they won't be in Priority: required so there'll still be a smaller set available
<cjwatson> maybe I'll try pulling them in and see who complains
<soren> Keybuk: That sounds reasonable.. :)
<Keybuk> "updating initramfs is bad because the new udev might not work with the older kernel"
<Keybuk> if the new udev doesn't work with the older kernel, you're not going to have a /dev after you boot
<Keybuk> so you're pretty doomed anyway
<Keybuk> we run mdadm and lvm from udev these days
<Keybuk> so you're still doomed
<lool> I just gave an example of an udev upgrade where the old initrd allowed me to boot and not the new one
<mvo> cjwatson: how much additional space it will cost? if its not too bad that should be fine I guess
<lool> I goot at least start up my system with networking and downgrade udev
<lool> *could
<cjwatson> it's additional space we're using in the default system anyway - it only makes a difference for minimal debootstrapped systems
<asac> StevenK: can you look at connman(-gnome) NEW please?
<cjwatson> mvo: it's a couple of hundred KB until you add the HTML and XML output backends
<cjwatson> mvo: maybe the right answer is actually to downgrade the HTML and XML bits of libparse-debianchangelog-perl to Suggests
<cjwatson> aptitude only uses rfc822 output
<ogra> grmbl, so d-i expects a link to the slug firmware to be in place in /lib/firmware ...
<mvo> cjwatson: that sounds good to me
 * ogra sighs ... why cant it be easy
<ScottK> cjwatson: Thanks (for whitelisting me on ubuntu-archive).
<bigon> mdz: I will open a bug for that
<dratone> Hello everyone
<dratone> Hi
<cros13> evening all
<cros13> I got a really weird issue
<cros13> with jaunty
<cros13> my boot time doubled after running an update this morning
<cros13> bootchart shows a pile of dmraid-activate instances
<dratone> I was wondering, I want to become active in ubuntu development, but the information page left me with a few questions. Is there someone here who could give me some more information regarding becoming active in the development?
<cody-somerville> dratone, certainly!
<cody-somerville> What page did you read exactly?
<cody-somerville> There are a few.
<dratone> cody-somerville: I read https://wiki.ubuntu.com/UbuntuDevelopers
<cody-somerville> dratone, Okay, great. Thats one of the more comprehensive pages.
<dratone> But it didn't quite make clear to me how to actually 'get started'
<cody-somerville> Ah
<cody-somerville> We have the page for that! :)
<dratone> I was hoping you might ;)
<cody-somerville> https://wiki.ubuntu.com/MOTU/GettingStarted
<cjwatson> dratone: in addition to what Cody said, UbuntuDevelopment is probably a better starting point than UbuntuDevelopers
<cjwatson> UbuntuDevelopment is a page full of resources; UbuntuDevelopers is about the process for joining the development team (which you'd be doing once you're a little more familiar with the resources)
<cody-somerville> Ah
<cody-somerville> good catch
<dratone> Ok, that does make things a bit clearer, thanks. I'll read up and get back in a little bit
<dratone> thanks
<cjwatson> I've edited UbuntuDevelopers to provide links to other pages up top
<radix> Is it possible to pre-seed debuild with a set of packages so it doesn't need to download them (without using some kind of caching proxy)? I'm thinking of somehow preseeding /var/cache/apt with a bunch of packages
<ogra> apt-get install -d <packagelist>
<ogra> not sure debuild has an extra option for that
<radix> ogra: I'm not sure what you mean
<radix> okay
<ogra> -d tells apt to download the packages but not install them
<radix> yes I know about it
<ogra> they end up in /var/cache/apt
<radix> oh sorry, I was ambiguous
<radix> hmm, maybe I'm confused
<radix> I was assuming that debuild uses the /var/cache/apt that's in the chroot
<radix> so I'd need to somehow get the packages into that one
<radix> oops oops
<cjwatson> radix: this doesn't match any debuild I'm used to. Are you perhaps talking about pdebuild?
<radix> I've been saying "debuild" but I mean "debootstrap"
<cjwatson> oh
 * radix finishes his coffee
<cjwatson> how about --make-tarball/--unpack-tarball?
<radix> cjwatson: oh, great
<radix> sorry, I don't know how I missed it
<radix> thanks very much for dealing with my confusion, ogra and cjwatson: )
<cjwatson> I don't think the tarball has to be complete; it unpacks it and then carries on with whatever else it was told to do
<maxb> I use a simple wrapper around debootstrap that bindmounts my /var/cache/apt/archives into the new root, so that it shares my normal apt cache
<radix> maxb: oh, interesting
 * ogra knows a bunch of people doing that 
 * maxb pastebinds
<maxb> -d
<ogra> i wonder why debootstrap never grew an option for it :)
<maxb> http://paste.ubuntu.com/119222/
<radix> maxb: thanks
<maxb> Clearly I should tidy it up and turn it into a patch for debootstrap
<maxb> one day :-)
<radix> maxb: huh, I was thinking that wouldn't help me because my guest is a different distro, but... I could bind mount it to something like /var/cache/apt-hardy or something
<radix> and that way my various guest chroots could use the same one
<maxb> that's an option. Personally, my /var/cache/apt/archives is a pool of mixed intrepid and jaunty packages
<radix> maxb: oh, interesting
<maxb> I have another wrapper script so that when I run apt-get autoclean, I do it with an alternate sources.list that contains both distros
<radix> I think I'll just use a separate cache directory :)
<radix> anyway, as usual #ubuntu-devel is fantastically helpful :-)
<ogra> gar
<ogra> my self built d-i doesnt boot the slug ...
 * ogra doesnt get what that is 
<ogra> hmr
<ogra> *hrm even
 * ogra wonders wahatd different between the d-i in the archive and his ... nothing changed ...
<ogra> *whats
<ogra> ha ... silly ,me not building in a pbuilder ...
 * ogra makes note to not forget to update the build-deps if doing so
<dratone> Hi Again. I've read the pages but.. I'm still not sure on what to actually do :) I know most of the stuff (worked with some form of linux for about 9 years, Debian/Ubuntu and other debian based distro's for the past 7 so the stuff I'm pretty well aware of but I'm not sure on what i can actually do as a developer :) *I know, it sounds dumb*
<fasix> hi
<fasix> http://forum.ubuntu-it.org/index.php?topic=262207.0
<fasix> hel me
<fasix> help me
<dratone> Ehmm, I think you need #ubuntu instead of #ubuntu-devel, though i could be mistaken.
<Keybuk> http://news.bbc.co.uk/1/hi/technology/7894763.stm
<Keybuk> "The world's biggest mobile phone makers and network operators have backed plans to create a universal phone recharger." ... "The micro-USB connector will be used as the common charging interface."
 * Keybuk passes out
<Keybuk> the world has gone sane
<soren> Keybuk: It'll pass.
<ogra> sigh .. and that now where you can get mini-USB power upplies everywhere, so i need an adapter now ?
<ogra> *supplies
<Keybuk> ?
<ogra> well, i have about ten devices that come with mini usb power supply, charging through it ...
<ogra> i wonder why they dont go with mini
<Keybuk> because micro-usb is the current standard?
<soren> ogra: It's a plot to annoy you.
<ogra> soren, yeah, conspiracy against me all over the world ... i always knew it
<Keybuk> ogra: are you sure you're not confusing the two?
<ogra> yes
<ogra> micro is about half as thick ... similar width and form
<ogra> my n810 has a micro, the n800 has mini
<Keybuk> right, that sounds about right
<Keybuk> mini was obsoleted by micro
<Keybuk> all newer devices use micro
<ogra> and my (this week arriving) n85 will have micro
<ogra> still, its annoying, they could simply keep a standard if it already quasi-established itself ...
<Keybuk> the best bit about standards is there are so many to choose from ;)
<ogra> yeah
<Keybuk> you may as well claim they should have kept the old A/B type plus from the USB 1.0 days
<ogra> well, thats at least still around
<ogra> you can still buy new pronters using them
<ogra> *printers
<Keybuk> are you sure?
<ogra> i think i saw one last week
<Keybuk> I've only seen printers using the newer Type-B plug
<Keybuk> which looks a bit like the old Type-B plug, but isn't _quite_ compatible ;)
<ogra> ah well, i wont stop the world from moving forward i guess ...
<ogra> its just such a waste of resources to invent a new standard every year just to sell new power supplies
<Keybuk> micro came first
<Keybuk> and that was simply because they needed a smaller connector for the increasingly smaller devices
<ogra> are you sure ?
<ogra> i actually saw my forst micro in the n810 ... my first mini is more than a year ago
<Keybuk> according to Wikipedia ;
<emgent> Keybuk: i love your post about GIT! :)
<Keybuk> ogra: every device that uses Micro USB came with a cable that had a Type A on one end and a Micro-B on the other
<Keybuk> every device that uses Mini USB came with a cable that had a Type A on one end and a Mini-B on the other
<ogra> and most of the ones i have also came with a power supply
<Keybuk> so if all new devices are going to have a Mini-B socket, they will assumedly come with a cable
<ogra> to charge over mini
<Keybuk> did the power supply have a hard-wired cable in it?
<ogra> yes
<Keybuk> how weird
<Keybuk> I've not seen that
<Keybuk> I've got a couple of USB power supplies now
<ogra> i have about ten of them here
<Keybuk> they're plug sockets with a USB Type A socket in the top
<Keybuk> so you just plug the cable into them
<ogra> from camera to GPS
<ogra> some BT devices i have too
<Keybuk> kooky
<Keybuk> you can buy universal USB charger plugs in most good stores
<Keybuk> they look a bit like a "Swiss travel adapter", but instead of having lots of holes in the top, they just have a USB socket
<Keybuk> or just go to an Apple store in each country and get theirs, which are soooo dinky and cute
<Keybuk> then you just need to take one plug, and one or two cables
<Keybuk> instead of the suitcase full of chargers, adapters and bricks
<ogra> well, i dont need to since i got tons for the hardwired ones :)
<ogra> hrm
<ogra> hw-detect in d-i force udev to disconnect network devices ?
<ogra> cjwatson, so the 'console-setup-udeb -' fix works fine, i get d-i noninteractively running up to the ssh server and can connect just fine
<ogra> cjwatson, though now it kills the connection on "Detecting disks and all other hardware" (i think thats hw-detect or some such)
<ogra> i can re-login with ssh installer@192.168.1.77 and pw "install" (like it should be) ... but it respawns at exactly that point to drop me out again
<ogra> argh !!!!
<ogra> 0 pages swap cached
<ogra> Out of memory: kill process 2488 (sshd) score 84 or a child
<ogra> Killed process 6977 (sshd)
<ogra> sigh
<ogra> Keybuk, shrink udev !
<Keybuk> err
<ogra> i only have 30M
<Keybuk> if your udev is running out of memory, and it's 137, you have some interesting problems
<Keybuk> udev doesn't *use* much memory
<Keybuk> [6291] udev_rules_new: temporary index used 17900 bytes (895 * 20 bytes)
<ogra> ~ # cat /proc/meminfo
<ogra> MemTotal:          28324 kB
 * ogra cries
<ogra> why does lenny work :/
<Keybuk> [6291] udev_rules_new: rules use 46332 bytes tokens (3861 * 12 bytes), 12857 bytes buffer
<Keybuk> I think that ~64 KB is small enough
<ogra> hmm
 * ogra shakes his fist towards oom-killer
<directhex> ogra, ah, oom. let me tell you a story of oom. it involves Â£300,000 of useless computers
<ogra> were they 133MHz/30M ARM systems ?
<ogra> else i'm not so intrested
<directhex> ogra, dual quadcore xeons. doesn't ubuntu sshd have oom_adj set to -17?
<ogra> no idea about the settings in the installer udeb
<jcastro> evand: I need to fill out the bug contact info for debian-installer, whom would you say handles the bugs for d-i more, you or cjwatson?
<ogra> jcastro, isnt teher an installer team ?
<ogra> *there
<evand> jcastro:  cjwatson
<jcastro> ogra: yeah but I try to nail it down to one person when I can
<ogra> ah
<calc> yipee my x200 just arrived
<calc> its so much smaller than my old laptop
<cjwatson> jcastro: what evand said - which contact info is this? I thought I'd filled it out in the obvious places
<ogra> cjwatson, would i gain any ram if i excluded console-setup-fonts-udeb as well ?
<jcastro> cjwatson: it's the bug supervisor info in lp: https://bugs.launchpad.net/debian-installer
<cjwatson> ogra: I'd expect you'd get a bit; also the keymaps
<jcastro> cjwatson: it's not obvious and most of them aren't filled out so I am hitting the top100 basically.
<ogra> good
<cjwatson> jcastro: why is it appropriate to set that to an Ubuntu contact?
<cjwatson> I mean, as it happens, I'm an upstream developer too
<cjwatson> but it seems to me that it's the job of the upstream project to fill that in if they're interested, and in the case of upstream d-i, bugs shouldn't be reported in LP at all ...?
<jcastro> it's supposed to be who to contact in the ubuntu project who is looking at those bugs
<cjwatson> that makes no sense
<cjwatson> the bug supervisor on a project should be somebody upstreamish, surely
<jcastro> it can be, if that project is interested
<cjwatson> and if they aren't, we should mark the project as not using LP for bugs
<jcastro> from what I've seen so far it's the person who is weeding through the bugs and reporting those upstream
<cjwatson> the only bug on upstream d-i right now does not belong there
<cjwatson> it should be filed on the appropriate Debian package instead
<ScottK> jcastro: I agree with cjwatson.  That's the upstream project, not Ubuntu.
<jcastro> it lists the debian bug tracker as the upstream tracker
<jcastro> so you're saying when the project has an upstream bug tracker that that field shouldn't exist?
<ScottK> It definitely shouldn't have Ubuntu specific information in it.
<cjwatson> what ScottK said
<cjwatson> we already have a space for the Ubuntu contact; it's the bug contacts for the package
<cjwatson> (possibly filtered, given that there can be multiple contacts)
<cjwatson> there's no need to abuse the upstream bug supervisor field for that
<jcastro> ok I am having a hard time finding the ubuntu bug contact
<ScottK> Honestly I think the entire concept of upstream projects for projects that don't use Launchpad is pretty broken.
<cjwatson> it's useful for d-i because the upstream code import lives there
<cjwatson> and in general upstream projects in LP are a hook for such things
<ScottK> It's not at all clear to a casual observer that these are not the actual project home.
<ScottK> ... but that's kind of OT, so nevermind
<cjwatson> jcastro: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+subscribe lists the bug contacts (in a slightly obscure way); you could intersect that with people who actually do useful work
<cjwatson> expand out teams and intersect with ubuntu-dev, or something
<jcastro> ok I think there is a disconnect with what you guys think that first field is for, and what the lp people think that field is for.
<cjwatson> jcastro: in this specific case I'm happy to be the upstream contact, BTW - I just think it's fairly meaningless
<cjwatson> I'm astonished that the LP people think that the upstream bug supervisor should be filled with an Ubuntu contact address; that violates everything I know about the LP data model
<cjwatson> Ubuntu != upstream is built right into lots of assumptions in Launchpad, even when it's actually slightly inconvenient (native packages)
 * pitti sighs at python-kde4-dev pulling in half of KDE; I clearly need phonon-backend-xine to build a python KDE package :/
<Riddell> pitti: seems reasonable to me, python-kde4 includes phonon bindings
<seb128> pitti: did you try not installing recommends?
<pitti> seb128: yes
<seb128> ok, seems that's not it then ;-)
<pitti> Riddell: yeah, I guess so :) (nevermind)
<greg-g> seb128: can I ask you to clarify this sentence: "COPYING states it's GPL where the copyright lists
<greg-g> LGPL as license
<greg-g> " from https://lists.ubuntu.com/archives/ubuntu-archive/2009-February/024963.html (sorry about the line break)
<seb128> greg-g: what is not clear
<seb128> ?
<greg-g> where does it say LGPL?
<seb128> greg-g: the copyright file in the debian directory?
<greg-g> ohhhh, sorry, I'm upstream, I haven't messed with the packaging, they just sent me that email
<seb128> greg-g: whoever did the packaging wrote in the debian directory that the source is under LGPL which is wrong
<seb128> greg-g: let the package know that the issue is a packaging one
<greg-g> seb128: doing so now, thanks for the clarification.
<seb128> you're welcome
<LaserJock> Main packages don't have to have Suggests in Main do they?
<ScottK> LaserJock: No.  Recommends, yes, but not Suggests.
<LaserJock> right, just making sure ;-)
 * Laney cuddles whoever is AAing today
<soren> Can someone explain why Aspectj is in multiverse?
<pitti> soren: if it's free software, then just because nobody filed an ubuntu-archive bug to move it to universe, I suppose
<soren> pitti: http://changelogs.ubuntu.com/changelogs/pool/multiverse/a/aspectj/aspectj_1.5.3-1/aspectj-doc.copyright looks free to me.
<pitti> soren:   aspectj |    1.5.4-1 | unstable/contrib | source, all
<soren> ...but I'm not a cool archive admin like yourself, so what do I know? :)
<pitti> soren: please file a bug about moving it then; thanks for spotting
<soren> contrib means it's free, but depends on non-free stuff?
<pitti> yes
<soren> Cool. thanks.
<pitti> most likely because of earlier non-free java deps
<soren> pitti: Exactly.
<soren> pitti: Filed. Thanks!
<mvo> james_w: the bzr-builddeb snapshot looks good, the only change I noticed is that it puts the debs/changes files into ../build-area again (the latest packaged one put the final stuff into ../ )
<james_w> mvo: were you building a source package?
<mvo> james_w: yes (bzr-buildpackage -S)
<mvo> (not a big deal, just wanted to mention it)
<james_w> mvo: hmm, works for me, do you have "Placing result in" as the last line of the output?
<mvo> james_w: oh, I guess its because its a sponsored build and debsign failed
<james_w> mvo: ah, yeah, that'll do it
<mvo> nevermind then :)
<james_w> I want to make it work better by not using "../build-area"
<james_w> I think it will work, you just get a complaint about "directory name is not <source>-<version>" or something
<james_w> which can probably be removed, as I believe it makes no difference
<mvo> yep
<ogra> cjwatson, "Loading additional components" is that anna ?
<ogra> it loads a lot of unused stuff
<cjwatson> yes
<cjwatson> use lowmem
<ogra> like ltsp-client-builder
<ogra> it switches to lowmem immediately after boot
<cjwatson> which level?
<ogra> there are levels ?
<cjwatson> yes
<ogra> oh, i didnt know
<cjwatson> cat /var/lib/lowmem
<ogra> 2
<cjwatson> hmm
<cjwatson> it doesn't go higher than that
<cjwatson> can you get me a syslog please?
<ogra> http://paste.ubuntu.com/119296/
<ogra> the try before it actually didnt download all that stuff and jumped to hw-detect
<cjwatson> well, ltsp-client-builder alone isn't going to help very much
<ogra> or i missed that, but i doubt it
<cjwatson> nearly everything else there is mandatory
<ogra> weird
<ogra> i wonder why i got further before
<cjwatson> phase of the moon?
<ogra> hmm, and why is it pulling in localechooser now
<cjwatson> low-memory problems can sometimes not be entirely deterministic, depending on exact ordering
<ogra> localechooser - is in the default cfg
<cjwatson> that's only the initrd
<cjwatson> localechooser is meant to be run once the network console is up
<ogra> ah
<ogra> well, for sure our kernel is 500k bigger (compressed) ... and i would suspect debian has less things in d-i as well ..
<cjwatson> not by very much
<cjwatson> anyway, you can't solve low memory problems by randomly shooting at the thing you notice that you like least :)
<cjwatson> you have to profile
<ogra> well, i have a working setup in debian so i'll start comparing
<ogra> but the kernel might be our biggest issue here
<ogra> i'm not sure to what the 500k translate uncompressed
<ogra> but surely a lot for that arch
<ogra> if i could swap before doing anything else ...
<cjwatson> ltsp-client-builder is installed because it's Priority: standard; it's the same reason that it gets pulled in unnecessarily on netboot installations
<cjwatson> can we arrange to pull that in only on ltsp installs instead?
<ogra> sure, it should only be in when preseeded
<cjwatson> ok, I'll take care of that
<ogra> thanks
<ogra> but i doubt that buys me enoug
<ogra> h
<cjwatson> just needs extra preseeding in debian-cd and an override change
<ogra> ltsp-client-builder is quite tiny scripting
<cjwatson> no, it almost certainly won't, it's just that it had been irritating me for some time and you mentioned it :)
<ogra> cjwatson, hmm, going to menu in the serial console i see "free memory for lowmem install" below "Download installer components" shouldnt that be the other way round ?
<cjwatson> ogra: it's after it in Debian too
<ogra> ok
<cjwatson> ogra: I think the point of that step is to ditch the syslog from the early phases of the installer while you get the partitioner going
<ogra> ah, makes sense
<ogra> i wonder if it will get to OOM if i dont use ssh
<ogra> and just stay within serial
<kirkland> Keybuk: enjoyed your git post, ditto :-)
<LaserJock> kirkland: OMG, you must be a dilusional Canonical-brain-washed bzr fanboi too!!! ;-)
<kirkland> LaserJock: yeah, that's me
<Keybuk> a Novell person was doing that bitch at me earlier
<mathiaz> slangasek: are you working on an openldap 2.4.14 upload to unstable?
<Keybuk> I retored "I suppose you think we should all use GroupWise?"
<slangasek> mathiaz: "working" :)
<kirkland> hehe
<slangasek> mathiaz: I'm laying the groundwork, at least
<mathiaz> slangasek: ok - anything would be ready before FF?
<slangasek> mathiaz: that's vaguely my hope
<slangasek> mathiaz: among other things, we get to ditch db4.2 then :)
<mathiaz> slangasek: I'm planning to work on a 2.4.14 before FF
<mathiaz> slangasek: yeah - that's one of the main thing :D
<mathiaz> slangasek: oh - and thanks for taking care of samba 3.3.0!
<slangasek> sure :)
<kirkland> Keybuk: i move ecryptfs-utils from git over to bzr about 2 weeks ago and my upstream-maintainer life is so much happier
<kirkland> Keybuk: surprisingly, the other two main contributors, individuals who work for IBM and Red Hat, have openly stated how easy bzr is
<kirkland> Keybuk: and have specifically mentioned the 'bzr push' command as ridiculously easy :-)
<ogra> what ?
<ogra> it doesnt do what git does !
 * ScottK discovered it was totally even easier after learning of bzr push :parent.
<ogra> that has to be wrong :P
<Keybuk> kirkland: the best bit was that in the process I discovered another neat bzr command
<Keybuk> bzr branch . ssh://.../
<Keybuk> ie. you can make a branch of your working copy and put that branch on another machine
<LaserJock> that is rather nifty
<kirkland> that is a neat little gem
<LaserJock> Keybuk: clearly the problem was you weren't using github
<cjwatson> ssh:// doesn't work, does it? sftp://
<Keybuk> cjwatson: err, sftp or bzr+ssh
<cjwatson> (I filed a bug earlier today asking for ssh:// to be an alias for sftp://)
<james_w> jelmer has just posted a patch making it say "you probably wanted bzr+ssh://" if you use ssh://
<Keybuk> james_w: that's idiotic
<Keybuk> if it knows what you mean, it should just fdi
<Keybuk> I just wish bzr could support a directory containing a repository of multiple branches *and* a working tree of one of those branches
<james_w> yeah, that's what I think
<cjwatson> :parent> neat
<cjwatson> and :submit :public :push :this :bound, although I can't find 'bzr help' documentation on those
<james_w> just pointing out that bzr is fixing the complaint, not criticising you for not getting it right in the first place :-)
<james_w> cjwatson: are you filing a bug? if not I will
<cjwatson> for the docs? I will
<cjwatson> bug 330535 for jelmer's thing
<ubottu> Launchpad bug 330535 in bzr "using ssh:// should hint at bzr+ssh://" [Undecided,New] https://launchpad.net/bugs/330535
<cjwatson> james_w: ah, bug 262969 maybe?
<ubottu> Launchpad bug 262969 in bzr "help topic listing available directory services" [Undecided,New] https://launchpad.net/bugs/262969
<james_w> cjwatson: they are not actually directory services, but it's close enough I think
<cjwatson> james_w: they're in the directory service registry ...
<cjwatson> the AliasDirectory stuff
<james_w> oh, my apologies
<slangasek> sigh, I really hate the openldap ITS
<slangasek> doko: did the issues causing python2.4/python2.5 to need libdb4.2 ever get resolved?
<doko> slangasek: ?
<slangasek> doko: after openldap gets updated, python will be the only thing holding db4.2 in main
<slangasek> actually, it'll be the only thing holding db4.2 in the archive
<doko> slangasek: not on supported architectures
<slangasek> that doesn't help us get rid of db4.2
<slangasek> if we have to have it for unsupported archs, we have to have it
<slangasek> unless we kill off those archs entirely, that is
<doko> I don't care much about this, maybe just upload a python2.4/python2.5 with a db4.x version you do want. python2.6 seems to be fine with db4.7
<doko> the build should succeed despite failing db tests
<slangasek> doko: so instead we'll have broken python modules on those archs? :(
<slangasek> doko: I was really hoping someone was working on the issue upstream
<doko> slangasek: no, upstream isn't interested in minority archs. last thing rejected was the fix to fix float handling on old arm abi. at least this doesn't affect us
<slangasek> doko: which are the affected archs?  Perhaps I could send out a call for porters
<doko> slangasek: libdb4.2-dev [!amd64 !i386 !lpia], libdb4.6-dev [amd64 i386 lpia] you might want to have an python2.5 upload to get current test results
<mun> hi
<mun> does anyone know why i'm getting a syntax error near unexpected token `(' on line 14? http://pastebin.com/m3dc05706
<RainCT> mun: out of curiosity, what language is that?
<mun> RainCT: it's from a configure file. i believe it's a shell script.
<RainCT> weird one :)
<maxb> mun: is that csh?
<mun> maxb: i really don't know. there's no header.
<mun> maxb: should it be csh?
<maxb> well, it's certainly not Bourne shell
<mun> right. i'll set the header to csh and see
<mun> oh it all works! thanks
<red-lichtie> I have a question about kernel packaging. As I see it, modules with experimental status are not build (delivered) as part of the standard kernel distribution. Would it not be better to distribute these modules and add them to modprobe.d/blacklist instead ? This way, if someone wants to use an experimental module, they don't have to compile everything ?
<red-lichtie> Or am I missing a simple way of compiling a commented out module in the config and adding it quickly to my system ?
<jelmer> Keybuk, bzr supports bzr+ssh://, git+ssh://, svn+ssh:// and sftp://. Aliasing ssh:// to one of them is going to cause confusion.
<ScottK-desktop> red-lichtie: #ubuntu-kernel is probably better for that question.
<red-lichtie> Thanks
<slangasek> jelmer: well, I guess I would rule out two of those as obviously incorrect choices, but YMMV :)
<maxb> I don't think there's anything wrong with bzr+ssh:// - the level of redundancy is the same as http:// in a web browser
<slangasek> maxb: if you omit "http://" from a url passed to a web browser, the web browser will DTRT
<slangasek> mathiaz: har, for openldap 2.4.14 supposedly including a bunch of GnuTLS fixes, it would be nice if the code actually compiled
<slangasek> mathiaz: btw, no fix in 2.4.14 for the V1 CA cert issue
<maxb> Indeed, the point I was hinting at is that despite being autofilled (in that context) the http:// is still considered a sensible part of the url
<mathiaz> slangasek: I saw an email on openldap-software about that
<slangasek> mathiaz: which part, the build failure or V1_CA_CERT?
<mathiaz> slangasek: I don't know if the bug has been fixed though (I'm refering to the build failure)
<slangasek> ok
<slangasek> http://www.openldap.org/lists/openldap-software/200902/msg00103.html, I guess
 * mathiaz nods
 * slangasek snorts at the follow-up, "I suggest you file an ITS"
<mun> hi
<mun> if a Makefile has the definition CFLAGS = @CFLAGS@ where would @CFLAGS@ be defined?
<slangasek> mun: the @VARIABLE@ convention is related to autoconf; you should never see such a line in Makefile, it should appear in Makefile.in but be substituted with a value when generating Makefile.
<mun> slangasek: ok thanks
<pmo> are you the owners of ubuntuforums.org ?
<pmo> just found traces of JS:Pdfka-AL [Expl] in it
<RainCT> pmo: I think there is #ubuntuforums
<pmo> ah ok ty
<lool> directhex: Heya, can I ask you for help on a C# update?
<lool> directhex: Basically: http://paste.ubuntu.com/119400/ is what I asked to slomo, but seb128 I could ping you as well
<lool> Erf, Tasque uses the name "API Application" to register to RTM's services
<lool> Woohoo, it works
<btQuark> btw: would it be possible to couple tomboy to evolution?
<kees> Keybuk: around?  I'm looking at getting kerneloops to not run as root, but I suspect that will affect the dbus changes you made.
<TheMuso> superm1: Takashi has another sound git tree, located here: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
<TheMuso> superm1: Thats where a lot of the alsa driver development work happens, and then its merged back into alsa-kernel, less often than it should be IMO.
<allquixotic> bryce: Hey
<allquixotic> bryce: I got the feature freeze message from Steve Langasek. The UXA testing is still messy. 24 mixed/better/same vs. 9 worse/broken/locks up. :( Are we going to have to ship with EXA, and if so, have you heard anything back from Intel about speeding its 2D up at all?
<superm1> TheMuso, gah. this is the first patch i've seen that IDT churned out that didnt go right into alsa-kernel.  I really didn't want to get *this* involved... just wanted to make sure that a laptop worked right :)
<TheMuso> superm1: Yeah I can understand that.
<kirkland> bdmurray: just making sure, you know that there's a browser search plugin for http://people.ubuntu.com/~kirkland/search.html, right?
<bdmurray> kirkland: no I didn't
<kirkland> bdmurray: "Install the Browser Plugin"  ;-)
<slangasek> mathiaz: it looks like the slapd test suite hangs for me during build, while running one of the concurrency tests - if you have some time to try to reproduce/debug this, that would be helpful
<mathiaz> slangasek: sure
<mathiaz> slangasek: is the code in debian svn up-to-date?
<slangasek> mathiaz: yes
<directhex> lool, someone might already be looking at evolution# - check in oftc #debian-mono
<lool> directhex: But then the update I prepared is ubuntu specific
<RAOF> lool: That's the new upstream release?  0.19.2.1?
<lool> RAOF: Yes
<lool> RAOF: Check my PPA if you like, I pushed the sources with detailed changelog entries of my changes
<bryce> allquixotic: yes we will have to ship with EXA.  I did talk to Intel about it and they said it sounded like a rational plan given the state of UXA
<bryce> allquixotic: so far they've not given up any tips for improving EXA performance
<slangasek> Keybuk: I'm intrigued by the use of $ENV{UTC} in the util-linux udev rule.  Is this really guaranteed to always be set in udev's environment?
<allquixotic>  bryce: Argh
<allquixotic> bryce: That's a shame that we can't get things a little better from either side. As long as we ship UXA though I'll be using it
<allquixotic> got to run.... thanks
<directhex> can someone with write access to Importance please bump https://bugs.launchpad.net/ubuntu/+source/mono-addins/+bug/330440 ? as well as fixing monodevelop, it appears to fix a critical issue with f-spot plugins not working
<ubottu> Ubuntu bug 330440 in mono-addins "Please sync mono-addins 0.4-3 (main) from Debian experimental (main)." [Undecided,New]
<StevenK> directhex: So, where's my tomboy upload?
<RainCT> directhex: which importance do you want?
<directhex> RainCT, i don't even know the options, since i can't see them
<RainCT> heh
<RainCT> directhex: http://wiki.ubuntu.com/Bugs/Importance
<directhex> StevenK, i believe DktrKranz has been at the head of gnome# issues. i haven't touched it
<directhex> argh compiz has decided that my favourite decoration mode for firefox should be "none at all" and doesn't give me window borders unless i fullscreen & unfullscreen my ff window :(
<DktrKranz> directhex, StevenK: tomboy has been recently uploaded
<directhex> RainCT, it is a Medium. "# A bug that has a moderate impact on a core application. " AND "# A bug that has a severe impact on a non-core application. "
<directhex> DktrKranz, neato!
<RainCT> directhex: already set it :)
<directhex> i should start work on my praise-filled mail to ubuntu-devel & ubuntu-motu thanking people for their help on mono-related transitions
<DktrKranz> directhex, only evolution-sharp is out, we're almost done :)
<StevenK> DktrKranz: The tomboy upload drops libgnome2.0-cil and friends?
<StevenK> DktrKranz: And tomboy is DEPWAIT on  libgnomepanel2.24-cil
<slangasek> StevenK: fixing that requires resolving the gnome-sharp2/gnome-desktop-sharp2 packaging still, doesn't it?
<StevenK> slangasek: No idea, I'm chasing this from a purely NBS angle :-)
<StevenK> But yes, libgnomepanel2.24-cil is in universe
<slangasek> StevenK: yeah, you probably need to put that one on hold; note that the NBSes are my fault, yet they're still there :)
<RainCT> argh.. glest-data is hanging at 68154k/68155k
<DktrKranz> StevenK, it drops NBSes, and libgnomepanel2.24-cil needs to be promoted
<directhex> oh, that explains it
<directhex> i was thinking "huh, i see that package" but forgot that it was NEW
<directhex> so universe
<slangasek> oh, but if libgnomepanel2.24-cil is here now, that's fixable :)
<directhex> slangasek, https://launchpad.net/ubuntu/jaunty/i386/libgnomepanel2.24-cil/2.24.0-1ubuntu1
<slangasek> StevenK: I'll promote gnome-desktop-sharp2
<StevenK> slangasek: Excellent
<directhex> neato! ^_^
<directhex> DktrKranz, can you mail me a list of people i need to thank for helping the gnome# transition?
<cjwatson> BTW, people have been complaining about daily CD builds not working due to libart*-cil
<StevenK> Now, how to fix texlive ...
<cjwatson> http://cdimage.ubuntu.com/daily/current/report.html is empty though
<slangasek> hmm
<DktrKranz> directhex, thank or blame? So you can start for blaming me :)
<cjwatson> and http://people.ubuntu.com/~ubuntu-archive/testing/jaunty_probs.html doesn't show anything obvious
<StevenK> libart2.0-cil or libart2.24-cil ?
<cjwatson> so I don't quite know what's going on; I suppose they might be looking at old images
<cjwatson> StevenK: a conflict between the two
<slangasek> cjwatson, StevenK: it's a conflict between the two of those, yummy
<StevenK> Oh, fun.
<slangasek> so that'll shake out once we have everything building against the new version
<directhex> it's just gnome# issues
<slangasek> I guess people want tomboy and f-sharp to both be installable at the same time
<RAOF> Silly people.
<cjwatson> given that they're both in desktop ... :)
<StevenK> slangasek: You tell funny jokes
<cjwatson> wonder why ubuntu-desktop doesn't come out as uninstallable
<directhex> and DktrKranz has been sprinkling magic dust on gnome# issues
<directhex> cjwatson, recommends: not depends:
<StevenK> That should get sorted out with this tomboy issue
<slangasek> cjwatson: because tomboy is a Recommends only
<cjwatson> directhex: hmm. it'd be nice if britney regarded that as mandatory
<slangasek> as is f-spot
<cjwatson> at least recommends from metapackages
<cjwatson> maybe I should fix that
<directhex> slangasek, because mono isn't on all arches, afaik
<directhex> slangasek, that or a concession to the "omg no monoez" crowd
<slangasek> directhex: no, the metapackages are arch-dependent binary packages
<slangasek> directhex: there are lots of severable bits of the desktop listed in the Recommends, not just the mono stuff
<directhex> slangasek, in either case, it's a transitory problem - albeit the highest profile package is the last one fixed
<directhex> oh, and which lovely archive admin let my very first package through NEW?
<directhex> well, second if you count mono-basic, but that was based on never-uploaded packaging work by someone else
<cody-somerville> directhex, It was I! The most wonderful person in the room which I stand.
<directhex> cody-somerville, yay! have some cake!
<DktrKranz> directhex, what about baking cookies (as Debian guys did)=
<directhex> DktrKranz, depends. my cookies might offend any vegetarians present
<DktrKranz> directhex, anyway, I'll mail you about *real* changes about gnome#, so they can be of aid to Debian guys
#ubuntu-devel 2009-02-18
<directhex> DktrKranz, thanks. bugs.debian.org is probably best - the ones i have the ability to change i get a ping from (as the bug gets mailed to the pkg-cli-apps mailing list)
<directhex> hm. i think i'm going to try for DD. i spend too much time prodding DDs in an irritating manner when i should be doing things myself. sound sensible?
<DktrKranz> ok, I'll have a test build with a exp chroot to see if it's the case to submit to them
<slangasek> StevenK: hmm, you might want to have a look at DktrKranz's latest post on ubuntu-devel, if you're in the NBSing right now
<slangasek> i.e., apparently the NBS report is rather wrong ATM
<StevenK> slangasek: Making plans, not executing
<directhex> DktrKranz, building for exp is pain :(
<directhex> DktrKranz, question is when slomo is going to upload gnome# 2.24 to unstable
<DktrKranz> directhex, yep, but gnome# has not migrated to unstable, ATM
<directhex> DktrKranz, hopefully not until after hanska gives it some policy love
<directhex> hm, i'll need an advocate and a signed gpg key
<RAOF> ...a bible, and a stopwatch?
<directhex> and a bucket of weasels
<DktrKranz> RAOF, FYI, evolution-sharp dot release is out
<RAOF> DktrKranz: I know.  They closed the bug I filed :)
<DktrKranz> directhex, and some $deity help :)
<DktrKranz> good :P
<DktrKranz> so, we're done with gnome# finally! \o/
<Laney> someone sponsored tomboy?
<RAOF> Yup.  It's waiting for gnome-panel-sharp to be promoted to main before it builds, though.
<Laney> yayness
<StevenK> It's been promoted, waiting for a publisher run
<Laney> double yayness
<directhex> if some lovely archive admin on binary new duty let  libsublib-cil_0.9-0ubuntu1_all.deb  slip in, then i could test a merge for gnome-subtitles 0.8 and sign off on the mono 2.0 app transition too
<Laney> I think we should promote gnome-do and replace the default bottom panel with docky
<directhex> assuming i don't keel over from exhaustion first. zzzzzzzzz
 * StevenK looks at the NEW queue and then wishes he hadn't
<directhex> Laney, ask shuttleworth! i heard he likes do :p
<Laney> heh
<directhex> Laney, perhaps with savings from the lib transition, there'll be room :p
<Laney> consider it done
<StevenK> directhex: libsublib released from binary NEW
<Laney> sweet!
<directhex> StevenK, sweet!
 * directhex fires up his jaunty vm
<cjwatson> right, I'll be able to test a britney modification to treat Recommends in metapackages as Depends, just as soon as I can build the C code involved since cocoplum doesn't have libapt-pkg-dev :-(
<cjwatson> tomorrow, I feel
<cjwatson> (I snarfed a copy of the test data)
<Keybuk> slangasek: look at the line right above where you're reading
<_tulio_123> hello all
<_tulio_123> can somebody help me with a python class please
<slangasek> Keybuk: ah
<slangasek> Keybuk: clever!
<Keybuk> _tulio_123: try #python ?
<_tulio_123> ok
<_tulio_123> thanks
<_tulio_123> =D
<Keybuk> slangasek: yeah ;)  I snuck that one into udev a while back
<Keybuk> but hadn't got around to using it until now
<_tulio_123> #python need to be registered
<ion_> Perhaps this channel should switch to that, too. :-P
<directhex> ion_, or only let awesome people like cody-somerville and StevenK speak
<StevenK> You only like me because of my archive admin hat :-)
<Keybuk> I dunno, cody-somerville would like kinda hot in a ball gag
<Keybuk> . o O { /me watches mneptok explode }
<directhex> StevenK, do you have any other hats i can abuse? :)
<StevenK> directhex: You stay from my hats, you bad person
<_tulio_123> i'm not making it to join python
<_tulio_123> dont know why i cant join it
<_tulio_123> just a little help with python?
<_tulio_123> anyone?
<StevenK> _tulio_123: Your nick isn't registered with NickServ, do that and you can join.
<StevenK> Python, and help joining channels is off-topic here
<cjwatson> wow, wonder what nhandler did
<directhex> killed the EV1 electric car
<calc> leave it to vista to make a new computer completely unresponsive :-\
 * calc will have jaunty on here by the time he goes to bed... he hopes
<kees> what's the right way to convert an ext3 to an ext4?
<calc> kees: reformat
<directhex> calc, for some reason audio on vista on this laptop just *doesn't work*. it freezes momentarily all the bloody time
<calc> kees: you can sorta get the benefits (of part of ext4 at least) by just upgrading in place, but reformat is recommended
<directhex> kees, the "right" way is with a format. a converted FS only gains ext4 power on new files
<kees> calc: no wai.  I can mount ext3 as ext4 without problem, and http://ext4.wiki.kernel.org/index.php/Ext4_Howto has some hints at the bottom
<calc> long term conversion is supposed to work, but i don't think it does yet, and not until online defrag fully works anyway
<kees> directhex: true, but that's all I want for the moment.  :)
<calc> kees: well i meant to get all the benefits of ext4 you need to reformat
<kees> but comparing filesystem features between mkfs.ext3 and mkfs.ext4 shows more than the wiki suggests
<kees> right
<Laney> write a script to recreate all files!
<kees> erf.
<Laney> cat foo >> foo~; mv foo~ foo
<Laney> >*
<kees> that won't retain permissions, but I get the picture.  :)
<Laney> it is too late for such considerations
<StevenK> If you're doing that hack, you may as well mkfs ...
<calc> just tar it to some other fs then back ;-)
<calc> i can't recall for certain but iirc even moving the files around doesn't get you full ext4 feature set iirc
<calc> its been a while since i looked though so i might be wrong
<TheMuso> calc: tar depends on having space elsewhere.
<calc> TheMuso: yea
<kees> thank goodness I use LVM.  :)
<persia> Well, that only helps if you have space elsewhere :)
<kees> yup
<StevenK> kees: I keep saying that too and then people like Keybuk call me insane
<kees> :)
<Keybuk> my calling you insane has nothing to do with your filesystem choices
<StevenK> LVM isn't a filesystem, kthxbye
<StevenK> But, fair point :-P
<Keybuk> besideswhich, I was heard not so long ago saying we should just do LVM by default
<Keybuk> but now I'm all about the btrfs
<StevenK> I like my data enough to not try and lose it
<Keybuk> StevenK: really?  I could swear you once claimed to like XFS
<calc> ext4 should be stable by 10.04 and btrfs maybe 12.04? :)
<calc> XFS is evil
<StevenK> Keybuk: So not me.
<ion_> I hear the XFS problem was corrected about 1Â½ years ago.
<Keybuk> ion_: not that I'm aware of
<calc> if XFS was a gauge of how long it takes to become stable it would be ~ 8 years
<Keybuk> last time I looked, XFS was still not safe to do fclose (); rename() without fsync() in there
<Keybuk> interestingly, ext4 seems to suffer from the exact same problem
<StevenK> I've used XFS once, and that was under duress because ext3 can't do online resizing by default
<ion_> 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
<ion_> keybuk: Oh, ok.
<calc> ion_: yea people refer to that like someone should trust XFS when it had a serious bug that ate fses for 6-8 years before that unfixed
<calc> my system got hit by that bug about 5-6 years ago which nearly caused me to lose all my data, luckily i managed to get it back
<ion_> In Finland, we have these things called âbackupsâ.
<Keybuk> I often make backups
<Keybuk> generally just after losing something
<Keybuk> some of the btrfs features are just made of awesome
<Keybuk> like you can upgrade ext3 to btrfs
<Keybuk> and if you don't like it, you just hit a button, and all the btrfs stuff vanishes leaving you with your original ext3 filesystem
<calc> ion_: i recovered my data and never used another untested fs again (eg just ext2/ext3) after that
<Keybuk> since btrfs is copy-on-write, there's no reason it _has_ to clean up the old data
<Keybuk> which means, if you have lots of cheap disk, you needn't bother
<Keybuk> and at any point, can simply roll back a file, a directory or your entire filesystem to any previous version
<ion_> keybuk: Neat
 * calc hopes it defrags well
<persia> Almost like VMS, really.
<jdong> Keybuk: ugh YES ext4 picked up that nasty trait from XFS, just got hit by it a month ago.
<Keybuk> jdong: I was chatting to tytso about it at FOSDEM
<jdong> cool
<StevenK> Keybuk: What did he say?
<jdong> it's also picked up a greater chance of losing transient/in-cache data too compared to ext3
<jdong> I mean for all I see as an end-user ext4 is XFS with faster metadata operations and slower large-file performance....
<Keybuk> StevenK: "argh, my laptop got stolen, I hate brussels, everything wikitravel says is true"
<StevenK> Haha
<jdong> and a poorer suite of backup tools ;-)
<StevenK> Keybuk: I meant about the fsync() needed thing
<Keybuk> jdong: since the principle change from ext3 to ext4 (other than extents) is delayed block allocation - which is the prime feature of XFS - that's about right
<jdong> at least with XFS I can take an xfsdump every night and call it peace-of-mind
<Keybuk> StevenK: he mentioned he may be considering an implicit data sync on fclose()
<jdong> Keybuk: is that going to give those lovely infamous reiser4 delays where :wq triggers a flush of everything in-cache to disk?
<jdong> I guess more recently, firefox/sqlite
<Keybuk> no, he was saying it'd be more intelligent and only flush that file's blocks
 * StevenK shivers.
<jdong> mmm, I see
<Keybuk> ie.perform block allocation on close
<ion_> keybuk: Thatâs nice.
<jdong> I thought due to that ordered metadata commit stuff that could imply flushing out other data too? or was that changed?
<jdong> or are my views completely misguided ;-)
<persia> So if you've several large files open with data growth (say all the Ubuntu torrents on release day) on a small disk (say 20G), you could conceivably not allocate until you've overused your disk?
<calc> persia: the torrent program should preallocate
<calc> persia: and the new transmission has support for regular create a really big file already (iirc)
<jdong> lol that doesn't sound like the correct solution/answer to the question though.
<calc> not sure if it does the ext4 preallocate stuff though
<jdong> "My foot hurts, doc ==> well stop using it.."
<persia> calc, So the answer is "Yes, but don't do that"?
<persia> calc, For a less contrived example, consider server logs.
<calc> persia: unless i am missing something the try to download too much via torrents is already an issue with other fs as well?
<persia> calc, Not quite the same: when you run out of disk, the writing program stops writing, even if you have lots of potential disk cache could could fill in RAM, because they tend to be allocate-on-write.  If it's truly allocate-on-close, that creates a somewhat different model.
<persia> So, in short, yes, running out of disk is bad, and breaks your files, but this would do it in a different way, I think.
<persia> On the other hand, you could probably delete space pre-close and save the contents of the precious file with allocate-on-close in a way that might not be possible with allocate-on-write.
<calc> persia: ah i see now
<persia> I could be completely wrong of course.
<jdong> persia: I thought delayed-allocation still accounted for the currently-accurate free blocks state in RAM, just didn't put it on disk until a (convenient) later time?
<persia> jdong, That's excellent news.  So it keeps track of the available blocks, and expected allocations, and does the right thing?
<jdong> persia: that's the way XFS works and how I assume ext4 works
 * persia ceases to worry
<jdong> the only thing being "delayed" is writing the updated accounting info onto the disk until it is reasonably certain it's not going to fluxuate
<jdong> so I guess the ill effect is a higher probability of losing in-transit data on bad shutdown
<persia> Well, sure, but that's a performance tradeoff anyway.  Same as buying disks with larger memory caches, or setting high swappiness with lots of RAM to use the kernel disk cache.
<directhex> oh, wow, is it me or did NEW shrink by 33% in the last hour? nice going
<maxb> i386      678 builds waiting in queue
<maxb> Yikes!
<ScottK> Language packs do that.
 * directhex translates ScottK into klingon
<StevenK> directhex: Klingon is too low to get a language pack :-(
<StevenK> I should translate gdm into Klingon
<directhex> StevenK, does unicode include klingon glyphs? :/
<directhex> oh, poop, problem
<directhex> StevenK, ubuntu is linux for human beings
<directhex> so no klingon
<LaserJock> directhex: I don't think that's an issue
<LaserJock> directhex: since humans, for whatever reason, sometimes speak it
<directhex> time for bed. tomorrow i need to construct a big thank you message
<LaserJock> so "Ubuntu is Linux for Human Beings (who may speak klingon)"
<ajmitch> LaserJock: next you'll be arguiing for quenya language packs
<persia> ajmitch, Get quenya to > 90% coverage, and you could probably find support.
<ajmitch> persia: I suspect there's probably a team for it on launchpad
<LaserJock> ajmitch: I wasn't arguing anything other than "for human beings" doesn't limit klingon as it can be spoken for human beings
<LaserJock> I personally can't understand why people would be so silly
<LaserJock> but to each his own I guess
<ajmitch> People can be that silly quite easily, I'm not sure why either
<LaserJock> I should make a periodic table language
<ajmitch> chemists...
<ion_> Unfortunately, Klingon hasnât been included in Unicode AFAIK.
<LaserJock> I wonder how that happened
<LaserJock> I would have thought some genius would have said "who needs ASCII? Klingon is the way to go"
<ion_> I still donât understand why Unicode has a white smiling face and a white frowning face, but only a black smiling face. Offtopic, sorry. :-P
<persia> There are fonts using the user space in unicode, and well-known codepoints to use for both Klingon and Quenya.
<mneptok> Keybuk: explode with rage. you promised me first.
<NCommander> pitti, mvo, ping? can you review a packagekit branch for me?
<TheMuso> When working with usplash and requiring user input, should I use usplash's input mechanism, or just read from console? Only want one letter entered as a response.
<ScottK> Is the publisher running?  I've just watched binaries from more than one package sit at accepted for their second publishing opportunity.
<StevenK> ScottK: From my untrained eye, yes
<ScottK> OK.
<ScottK> StevenK: I've seen it happen before where LP doesn't know stuff is published, but it is.  Do you have (and would you be willing) a way to see if phone and akonadi in intrepid-backports actually published?
<StevenK> Which version?
<ScottK> akonadi 1.1.1-0ubuntu2~intrepid2
<ScottK> phonon 4:4.3.0-0ubuntu1~intrepid1
<StevenK> Source is
<StevenK> Binaries I can't find
<ScottK> StevenK: OK.  I guess I'll wait until tomorrow and see what happens.
<ScottK> StevenK: Thanks for checking.
<StevenK> ScottK: No problem
<LaserJock> is there an X IRC chan?
<ScottK> LaserJock: #ubuntu-x
<ScottK> At least for Ubuntu
<ScottK> Dunno about upstream
<LaserJock> ScottK: no, that's what I wanted
 * NCommander sighs
<Hobbsee> heh.  good to be back, apparently
<NCommander> Who's bright idea was it to backport KDE 4.2 and clog up the buildds one day before feature freeze
<NCommander> Hey Hobbsee
<StevenK> NCommander: Er, I was complaining about that yesterday and you didn't say anything, Mr. Backporter
<NCommander> StevenK, I didn't approve it, and I want to smack whoever did
<StevenK> Why didn't want to do so yesterday when I was complaining, then?
 * NCommander wasn't paying attention.
<NCommander> ^to that.
<NCommander> I was on holiday :-)
<StevenK> That explains oh so much
<NCommander> :-P
<NCommander> Well, we could always rescore everything else, or downscore the kde* packages so they won't build until after feature freeze ... although I'm not sure anyone ever used rescore in such a way before ...
<Hobbsee> you got buildd admin?
<NCommander> Hobbsee, yeah.
<Hobbsee> nice.
<NCommander> Comes with the nice bonus I can retry main builds once the buildds stop going boom.
<Hobbsee> i hope you're trustworthy to do so ;)
<Hobbsee> man, this feels weird...
<NCommander> Hobbsee, what does?
 * Hobbsee hasn't touched a keyboard since last tuesday.
<Hobbsee> it's now wednesday aftenoon.
<TheMuso> Hobbsee: I've had that before, haven't used a computer for over a week, and it feels weird to type when coming back.
<Hobbsee> TheMuso: and use a touchpad.  very bizarre.
<TheMuso> wow
 * NCommander looks for a list of intrepid-backports packages to downscore
<ScottK> NCommander: As long as you keep kde4libs back, the rests will depwait.
<NCommander> ooh, thats handy
<ScottK> No need to work at it too hard.
<NCommander> (we'll still loose some buildd time for the dep-waits, but that isn't bad)
<NCommander> That's pathetic, I scored it to zero, and it only went up by an hour on estimated build start time -__;
<NCommander> Oh
<NCommander> You can rescore to negetive numbers
<NCommander> Which does extactly what I wanted it to do
<StevenK> Careful
<StevenK> Then they won't build by themselves
<NCommander> StevenK, they won't?
<StevenK> I don't think they will
<NCommander> StevenK, I'll watch the two packages I did score to negetive. All the other KDE packages are now dep-waiting or will hit dep-wait, so now jaunty packages will take president.
<NCommander> So any last minute uploads will not get stuck behind the backports packages
<StevenK> "precedence"
<NCommander> sorry :-/
<dholbach> good morning
<Hobbsee> hi dholbach
<dholbach> hi Hobbsee
<RAOF> Howdie dholbach, Hobbsee.
<dholbach> hiya RAOF
<Hobbsee> heya RAOF!
 * StevenK waves to RAOF 
<RAOF> Sam found a best of /Supergrass/ CD while we're preparing to move.  This is good :)
<Hobbsee> woot!
<StevenK> Ugh, moving
<RAOF> Eh.  It hasn't been so bad the (2) times I've done it.
<StevenK> Moving away from the uni?
<RAOF> Yeah, but it's quite close to busses straight into the city, which makes it not bad.
<RAOF> And it roughly halves Sam's travel time.
<StevenK> And what, quadruples yours?
<RAOF> But quadrupling 5 minutes isn't so bad :)
 * StevenK grins
<StevenK> I liked the commute change with the last job change -- an hour each way to about 30 seconds
<Hobbsee> i'm jealous
<slangasek> the telecommutative property
<pitti> Good morning
<StevenK> Morning pitti
<pitti> NCommander: PK branch> please sub me to the bug, or mail me?
<pitti> hey StevenK
<Hobbsee> heya pitti!
 * pitti hugs Hobbsee
 * Hobbsee hugs pitti back
<Hobbsee> LTNS!
<pitti> ArneGoetje: langpack export for jaunty is finished
<pitti> Hobbsee: LTNS?
<StevenK> Long Time No See
<Hobbsee> yes
<pitti> ArneGoetje: I think langpack-o-matic is ready to go now, too
<pitti> ah, indeed
<slangasek> oh.  Not "Lose The Source, Nuke"
<slangasek> Or "Lose the Norse, Sook" I guess that is
<StevenK> That would be LTSN ...
<ArneGoetje> pitti: ?
<StevenK> ... Because Odin is excess baggage?
<ArneGoetje> pitti: langpacks for jaunty (export from 13th) are currently building.
<pitti> ArneGoetje: I did some fixes for bug 316174, bug 204705, and so on
<ubottu> Launchpad bug 316174 in language-pack-es "update langpacks need strict -base dependency" [Critical,In progress] https://launchpad.net/bugs/316174
<ubottu> Launchpad bug 204705 in language-pack-gnome-pt "Missing translation for "Mouse" in gnome-control-center pt_BR" [Undecided,Fix committed] https://launchpad.net/bugs/204705
<pitti> ArneGoetje: there's one from the 16th
<pitti> ArneGoetje: but well, won't matter so much I guess
<ArneGoetje> pitti: I know. that one came after I uploaded the ones from 13th
<ArneGoetje> pitti: yeah, doesn't matter. we will have new ones before release anyways.
<StevenK> slangasek: I think I prefered NBS before you fixed checkrdepends
<ArneGoetje> pitti: langpack-o-matc choked on the latest intrepid and hardy exports... need to fix some code there,
<pitti> ArneGoetje: oh, what did it do?
<ArneGoetje> pitti: when importing, it ignores ll_CC and the like, including ll_CC@var. But it choked on ll@var an aborted.
<ArneGoetje> pitti: although it is not quite clear to me why we ignore ll_CC and @var locales... they are valid locales and translations for those may differ from the standard ll locale.
<slangasek> StevenK: tough :)
<StevenK> Haha
<pitti> ArneGoetje: we ignore non-UTF8 locales
<StevenK> Hmmm. I wonder about syncing koffice from experimental
<StevenK> Maybe that one will actually *gasp* build
<ArneGoetje> pitti: from the import log: "Skipping obsolete locale fr_CA" <- why?
<ArneGoetje> pitti: and the error, where it choked: Copying nds@NFE/yelp into package ../intrepid-proposed/sources-update/language-p
<ArneGoetje> ack-gnome-nds
<ArneGoetje> Traceback (most recent call last):
<ArneGoetje>   File "./import", line 375, in ?
<ArneGoetje>     (lang, country) = noat.split('_')
<ArneGoetje> AttributeError: 'module' object has no attribute 'subst_string'
<StevenK> Riddell: So, pointless or not trying to shove koffice from experimental under the FF door?
<LaserJock> hmmpf, I'm stuck in the middle of a git merge but I can't change branches to investigate the merge
<LaserJock> I guess that's why branch-is-a-dir is nice
<ArneGoetje> pitti: in this case nds@NFE is not a valid locale. First it doesn't exist, but nds_DE and nds_NL do, and second, it should be nds_{DE|NL}@nfe if at all... so, something went wrong in rosetta I guess. It shouldn't have accepted an invalid locale.
<persia> LaserJock, You could always clone into another directory, and fiddle there ...
<ArneGoetje> pitti: and the log from the hardy import: Processing locale pt_PT...
<ArneGoetje> Skipping obsolete locale pt_PT
<ArneGoetje> Traceback (most recent call last):
<ArneGoetje>   File "./import", line 394, in ?
<ArneGoetje>     r = macros.subst_string('%RELEASEVERSION%')
<ArneGoetje> AttributeError: 'module' object has no attribute 'subst_string'
<LaserJock> persia: hmm, good idea, let me try that
<slomo> directhex: when gnome 2.24 is in unstable and mono 2.0 ;)
<slomo> lool: i can take a look later probably, but directhex can do it too ;)
<rimbi> hi
<pitti> ArneGoetje: macros.subst_string breakage fixed and pulled on rookery
<pitti> ArneGoetje: untested, though
<ArneGoetje> pitti: both of them?
<pitti> ArneGoetje: the first AttributeError looks identical to the second one
<ArneGoetje> ok
<pitti> ArneGoetje: but the traceback on the first one doesn't make sense
<pitti> ArneGoetje: is that in the log somewhere?
<ArneGoetje> pitti: well, it looks for ll_CC, but gets ll@var
<ArneGoetje> pitti: yes, in ../logs/intrepid-updates.log and ../logs/hardy-updates.log ant the end of the file.
<pitti> ArneGoetje: hardy-updates.log only has the second exception
<ArneGoetje> pitti: yep
<pitti> ArneGoetje: hm, that still doesn't make sense to me
<pitti> ArneGoetje: can you please try again with the current version?
<ArneGoetje> pitti: ok
<ArneGoetje> pitti: the intrepid tarbal version is the same as the last imported one... how can I override?
<DktrKranz> doko: re bug 324636, ludovic uploaded version 4.3.3-1, could gnat-4.3 be synced then?
<ubottu> Launchpad bug 324636 in gnat-4.3 "gnat-4.3 needs update" [High,Confirmed] https://launchpad.net/bugs/324636
<directhex> slomo, the kde team is already on at us for mono 2.0 - i think gnome is YOUR department though
<DktrKranz> pitti: no rush at all, but when you have time could you please comment on bug 315101? Thanks.
<ubottu> Launchpad bug 315101 in pkgbinarymangler "pbuilder fails if pkgbinarymangler is installed" [Low,Triaged] https://launchpad.net/bugs/315101
<pitti> ArneGoetje: just delete sources-updates/*, shoudl work
<ArneGoetje> pitti: ok
<pitti> DktrKranz: can you please subscribe me to the bug? I'll respond later then (after FF)
<DktrKranz> sure
<doko> DktrKranz: please merge from gcc-4.3 4.3.3-4 instead of syncing
<DktrKranz> doko: sure, I'll have a look. Thanks!
<mdke> morning all. Is there an irc channel for ubuntu netbook remix? I can't see the details on the wiki page
<jpds> mdke: Maybe #ubuntu-mobile ?
<mrvanes> virt-manager is uninstallable on amd-64 in jaunty at the moment, is python-virtinst (0.400.1) scheduled?
<slomo> directhex: what do you mean?
<directhex> slomo, "<slomo> directhex: when gnome 2.24 is in unstable and mono 2.0 ;)" - gnome 2.24 is the gnome team's department
<mdke> jpds: thanks, will try
<slomo> directhex: yes, sure... and i'll try to move as much gnome 2.24 stuff to unstable as time permits... but i guess gtk 2.14 will take another 10 days or something because of some issues (directfb)
<directhex> new gtk too? woo
<directhex> and i was just learning to love 2.12
<slomo> directhex: well, 2.14 is part of gnome 2.24 ;) and i guess some stuff is currently blocked by it
<Mirv> is there a reason for gnome-spell to be in main anymore, and a dependency of ubuntu-desktop? AFAIK the last user of it evolution migrated to using enchant already.
<Mirv> just wondering before filing a bug
<Tm_T> Mirv: I'd say yes, it should be removed
<Tm_T> Mirv: as no reason to be there
<Mirv> bug #330931 - now if I just find if there is an actual process for demoting from main etc...
<ubottu> Launchpad bug 330931 in gnome-spell "Obsolete, remove from main and ubuntu-desktop" [Undecided,New] https://launchpad.net/bugs/330931
<directhex> is anyone wearing an archive admin hat?
<apw> Keybuk, was it you who was doing bootcharting of various kernels?
<MacSlow> any idea what could be causing the system-monitor applet to fail being loaded under jaunty?
<seb128> MacSlow: look to .xsession-errors for errors?
<MacSlow> seb128, nothing added to .xsession-errors
<seb128> MacSlow: is gnome-applets installed?
<seb128> MacSlow: dpkg -l gnome-applets
<MacSlow> listed as rc
<MacSlow> ?
<MacSlow> reinstall?
<seb128> that's your issue then
<seb128> removed and configured
<MacSlow> outch
<seb128> yes reinstall it
<seb128> dunno what you did but you uninstalled it
<MacSlow> seb128, I now have a vague clue, what might have caused this
<MacSlow> seb128, certainly a "pebkac" :)
<seb128> yeah ;-)
<Riddell> StevenK: KOffice?
<Riddell> we have koffice-kde4
<StevenK> Oh, so koffice should die horribly?
<Silicium> hi there
<Silicium> where in the Squashfs on the LiveCD is the Home environment of the Live User (Ubuntu) defined?
<Silicium> i want to change some user specific settings on my custom CD
<mrvanes> Anybody any idea about python-virtinst (0.400.1) in amd64? It breaks virt-manager.
<soren> mrvanes: I uploaded it half an hour ago.
<mrvanes> thx ;)
<cjwatson> Silicium: mostly not in the squashfs at all, but in the initrd (/scripts/casper-bottom/10adduser)
<Silicium> cjwatson: thanks
<tkamppeter> pitti, hi
<ogra> hmm, so with evolution indicator installed i have no mail notification at all anymore
<ogra> njpatel, what is supposed to happen with evolution-indicator installed ?
<pitti> hi tkamppeter
<ogra> (aside from not doing anything it seems to break the notification plugin)
<pitti> ogra: now it's time to file lots of bug reports :)
<ogra> yeah, i just want to know what actually is supposed to happen before i start ;)
<pitti> ogra: and thanks for testing that; I tested the Pidgin indicator and alsdorf, but not the evo-indicator
<njpatel> ogra: its meant to replace the default notification plugin
<tkamppeter> pitti, I want to do a MIR of python-smbc. It is needed by s-c-p.
<ogra> that the notification plugin doesnt even show the little mail icon in the systray anymore is definately a heavy bug
<pitti> ogra: if you ask me: you should never *ever* be notified about getting email; that defeats the entire purpose of using email and is a productivity killer :)
<ogra> i'm no so much concerned about notifications, but want to know if mail arrived while i was afk
<pitti> njpatel: is it also supposed to eventually take over the evolution-alarm-notify functionality?
<tkamppeter> Once, I cannot find the instructions in the Wiki (too much noise in search results), and second, I do not know whether the whole formalism is needed.
<njpatel> ogra: it should show a popup for new messages, add the count to the message inidicator applet on the panel. optionally play a sound. Prefs are in edit->preferences->mail prefs->general
<ogra> pitti, well, i *explicitly choose* to be notified
<njpatel> pitti: No, not that I am aware
<ogra> thats why i deliberately enabled the plugin
<pitti> ogra: (I'm just bashing, nevermind)
<ogra> njpatel, oh, i need an applet now ?
<pitti> tkamppeter: it's on https://wiki.ubuntu.com/MainInclusionProcess
<ogra> hrm
<pitti> ogra: yes, you need to add the indicator applet
<tkamppeter> pitti, it is a simple Python Bindings package for libsmbclient, written by Tim Waugh as he needed it for s-c-p
<pitti> ogra: that will happen automatically, but it isn't yet
<njpatel> pitti: you can change the prefs to switch off the popups, and only have the count added to the message indicator applet
<ogra> bah, so i need to permanently waste panel space ...
<pitti> tkamppeter: sounds easy, indeed; but please still submit a MIR (don't waste too much time on it, though, if it's simple)
<njpatel> ogra: not for the popups, but yes, for the extra functionality. you need to `apt-get install indicator-applet message-indicator` (unless the names have changed)
<ogra> njpatel, both are installed but i didnt add the applet to the panel yet
<njpatel> ogra: stop complaining! ;-)
<njpatel> ogra: popups should work without the panel applet
<ogra> njpatel, not if you change my evolution !
<ogra> :)
<tkamppeter> pitti, there is no "Depends:" in the s-c-p package for it yet. Do I have to add this before the MIR?
<njpatel> ogra: it's better, I promise! :)
<pitti> tkamppeter: not before the MIR, but before the package can get promoted
<ogra> njpatel, i'll come to your house if it isnt :)
<pitti> ogra: the applet disappears if it is "empty"
<njpatel> ogra: some tea + cakes will be waiting for you:)
<ogra> no, there is a handle
<pitti> njpatel, ogra: FYI, I just uploaded an updated ubuntu-meta with these added dependencies
<ogra> and apparently a dotted frame
<njpatel> ogra: intrepid or jaunty?
<pitti> ogra: yes, the handle is a bug; I already told Ted
<ogra> njpatel, jaunty
<ogra> Pici, ok
<ogra> err
<ogra> pitti,
<ogra> hmm, so adding the applet makes the old notification work again, thats strange
 * ogra has the little windows popping up in his face again
<ogra> hmm, no package named message-indicator
<njpatel> ogra: it's indicator-messages now (just installed it myself)
<ogra> heh, k
<ogra> ah, got already the latest
<ogra> njpatel, will you automatically disable the evolution notification in a user setup if you switch the defaults ?
<njpatel> ogra: the message applet should allow you to switch to evolution, and also show the unread mail count when you have some new messages (which again, takes you to evolution). I wanted to do some more fine-grain stuff, like showing some message metadata, but Evolutions plugin arch. is really sandboxed. Can't get any info without loading and parsing all the libcamel stuff :-/
<njpatel> ogra: default mail client?
<ogra> no default notification
<ogra> the old notification plugin shows a little blinking mail icon and a notification if messages arrive
<njpatel> ooh, you mean the old plugin
<ogra> i assume that clashes with the indicator plugin if both is enabled
<njpatel> well, I think evolution will be built without it, or with it disabled
<ogra> iirc its off by default ...
<njpatel> (as evolution indicator does the same, sans flashing mail icon (using the message panel thing instead)
<njpatel> )
<ogra> but we should leave it optional for people using other desktops imho
<njpatel> cool. I think if the user knows how to switch it on, they can switch of evolution indicator too. We don't need to automate that imo
<njpatel> sure, makes sense
<ogra> right, just dont disable it during build :)
<ogra> so people still have it available if they want to
<njpatel> sure, good point. /me emails to make sure that doesn't happen
 * ogra wonders if he has to re-login or something ... 
<ogra> i get mais but there is noting in the applet yet
<ogra> nor do i get a notification
<tkamppeter> pitti, dependency to s-c-p added, MIR in progress ...
<Silicium> cjwatson: hmm, the scrips are only for live definitions but not for desktop icons and so.
<njpatel> ogra: hmm, that doesn't sound good. I'll check and see what's up
<ogra> ok, a re-login got me the mail icon
<ogra> is it not supposed to vanish if all mail is read ?
 * ogra would prefer to not have a permanent button in the panel
<njpatel> ogra: I just tested new install, and got a popup
<ogra> i didnt get a popup, but i have a little icon that expands a menu item to open a minimized evo now
<njpatel> ogra: can you just check mail-prefs->general tab, and make sure it's set-up to send popups (and that you've set whether you want notifications for all mail boxes or just inbox)
<ogra> though the original one is more usable imho, it disappears automatically if there are no unread mails
<ogra> so i can see if new messages arrived when i was afk by noticing the additional icon quickly
<njpatel> ogra: yep, there is some missing functionality on the message panel right now, which will make that easy to see
<ogra> ok
<njpatel> ogra: i can see its not reporting the unread message count, which implies something changed on the server-side. I'll have a proper look tomorrow, on my "dx day" ;-)
<ogra> well, i'm not fond of having to read numbers :)
<njpatel> ogra: you won't need to. The icon should change to reflect status. It will be very easy to spot
<ogra> i just want the icon to appear/disappear, else i would use some real mail notification applet that shows the counts
<ogra> thats a huge advantage of the edisting plugin
<ogra> it doesnt get in your way
<ogra> *existing
<ogra> ah, k
<ogra> i'll wait for what you implement then :)
<njpatel> ogra: you'll be the first to know when it's done, promise :D
<ogra> i'll be the firt to complain too :)
<ogra> *first
<ogra> ask seb ;) i'm the pain in his butt with weird evo bugs
<cjwatson> Silicium: the only icon we put on our desktop is for ubiquity (the installer); that's done in the script I pointed you to by copying in a desktop file from the squashfs, which includes a reference to an icon
<Silicium> and the examples
<njpatel> lol
<Silicium> but i will check that again
<Silicium> thanks
<tkamppeter> pitti, MIR is posted, bug 330973
<ubottu> Launchpad bug 330973 in python-smbc "MIR: python-smbc needed by system-config-printer" [High,New] https://launchpad.net/bugs/330973
<tkamppeter> pitti, the SRU bug 310575 got verified by its reporter, you can pass the package to -updated now.
<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: just marked so
<pitti> tkamppeter: can you please have a look at bug 320873 ?
<ubottu> Launchpad bug 320873 in cups "CUPS update breaks Evince printing to SMB printer(s)" [Undecided,Incomplete] https://launchpad.net/bugs/320873
<asac> Keybuk: do you know out of head which date you took the udev-extras snapshot on? (only found git id)
<asac> dont need exact date ... just approx. i assume it was around the time when you did first packaging?
<pitti> asac: oh, so that's the thing which ships probe-modem
<asac> pitti: yes.
<Keybuk> asac: yeah it would have been up to date at the point I uploaded the packagte
<asac> Keybuk: seems you have a snapshot from 5th jan
<Keybuk> is there something new you want from it?
<asac> Keybuk: any reason not to bump it to latest?
<asac> Keybuk: yes. there is more modem-prober code
<Keybuk> no reason
<asac> http://git.kernel.org/?p=linux/hotplug/udev-extras.git;a=summary
<Keybuk> quest udev-extras% ./update.sh
<Keybuk> bumping ;)
<asac> Keybuk: great. also write a MIR ;)
<asac> hehe
<pitti> asac: it was from http://cgit.freedesktop.org/~dcbw/udev-extras/commit/?id=95b96e3 FYI
<asac> i can do that though
<pitti> asac: juding by Keybuk's version number :)
<Keybuk> MIR?
<Keybuk> do you have something that depends on it now?
<asac> Keybuk: well it would help to get rid of the modem mess we are doing in 10-mode.fdi
<ogra> NM ?
<asac> for 3g
<asac> NM supports that now
<Keybuk> asac: have you tested probe-modem at all?
<cjwatson> such a hack, it should be done in the kernel instead :P
<Keybuk> I packaged udev-extras simply because it was there
<asac> heh
<Keybuk> I haven't ever even installed it or played
<Keybuk> I don't think Kay's done much testing yet
<asac> Keybuk: well. we had a more hacky probe-modem code in 0.7 :)
<cjwatson> indeed the kernel *does* do this for some modems
<cjwatson> sporadically
<asac> Keybuk: so NM falls back to hal if probe-modem fails. what kind of testing would you want?
<cjwatson> (assuming that this is the "switch modem out of silly CD mode" thing)
<asac> cjwatson: no its not
<cjwatson> oh, ok
<asac> cjwatson: its about probing for modem capabilites ... so we dont have to add a hal rule every modem out there
<asac> cjwatson: the CD mode thing is kernel issue for sure
<Keybuk> asac: well, some basic "does it work" testing would be good :)
<cjwatson> capabilities> gotcha
<pitti> cjwatson: it's supposed to replace /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi with a dynamic probing solution, to get rid of those static lists, which are always behind, and in some cases wrong
<cjwatson> asac: right, ISTR the CD mode thing being in udev-extras as well which is why I mentioned it
<asac> cjwatson: hmm. could be that they added something there. but dan always prays that it should be done in kernel
<Keybuk> there's quite a bit in udev extras
<asac> cjwatson: btw, did your hso fix flow upstream? is there anything we need to do for your modem in jaunty?
<Keybuk> the prototype ACL code is in there too
<Keybuk> (to replace the equivalent bit in HAL)
<Keybuk> in fact, udev-extras could be described as "stuff to replace bits in HAL when it goes away"
<Keybuk> right now, the right thing to do is probably still to use HAL
<asac> Keybuk: hmm. so maybe we should make a probe-modem package out o it and promote just that (if our testing shows that it works a bit)
<Keybuk> asac: maybe
<asac> Keybuk: anyway. you said you already bumped it. i will test once the new versoin is in universe
<Keybuk> *nods* it's uploaded, so test and play to your heart's content :p
<asac> dan said its not ready for prime time, but its not hurting especially since we still have hal
<cjwatson> asac: it's a bit stalled at the moment
<asac> cjwatson: ok. where did it get stuck?
<cjwatson> asac: I care a lot more about the kernel fix than about the hal fix, because the kernel is harder for me to tweak locally; Dan said, upon prodding, that he thought it looked OK and that he wanted to test it with some other hardware first, but I never heard anything else
<cjwatson> asac: the hal fix is stalled because it was frankly a hack :-)
<cjwatson> and they wanted to define a proper spec for this type of hardware instead
<asac> cjwatson: ok. do you have any pointers? i can bug dan a bit ;)
<cjwatson> asac: kernel: https://lists.one-eyed-alien.net/pipermail/usb-storage/2009-January/004499.html
<cjwatson> asac: hal: http://lists.freedesktop.org/archives/hal/2009-January/012783.html
<asac> hehe ... that first list uses HTTPS with a self-grown cert ;)
<cjwatson> I think maybe the hal one will be superseded by this udev-extras work
<cjwatson> so I'm not really interested in nagging about that part
<asac> yeah
<asac> just kernel part. understood
<ogra> njpatel, so i now noticed why i dont see the notifications :) they are simply shown in black over the content of my black terminal background, the new positioning scheme is a massive mess ...
<pitti> I recently sent a question about a pretty insolvable problem with 10-modem.fdi, and I also got that reply ("will get fixed with the udev modem prober")
<asac> pitti: where did you send it?
<cjwatson> https://lists.one-eyed-alien.net/pipermail/usb-storage/2009-January/004556.html -> "give me a day or two"
<cjwatson> s/two/so/ - on Jan 24
<pitti> asac: http://lists.freedesktop.org/archives/hal/2009-February/012995.html
<cjwatson> asac: note that Option (the manufacturer) are a bit upset about all this, because they want the CD enabled by default for marketing purposes
<cjwatson> asac: and there was a thread about that by e-mail
<asac> cjwatson: eehh ... what use does that have on linux?
<cjwatson> asac: Dan and I were both pretty firm that the OS should do the right thing damnit :-)
<asac> thought they use it to install drivers on windows
<asac> pitti: ah ok. hal list. thanks
<cjwatson> asac: apparently it might occasionally contain documentation or other shiny things - TBH the engineering case is really weak
<njpatel> ogra: ah right, that's not good
<asac> cjwatson: i dont even see the marketing case ;)
<asac> cjwatson: if the modem doesnt work that seems to be kind of perfect marketing ;)
<cjwatson> that's what we said
<asac> doesnt work as advertised ;)
<cjwatson> work out of the box, damnit
<pitti> tkamppeter: eww, debian bug 515918 looks like a serious regression
<ubottu> Debian bug 515918 in cups "cups: prints raw source of PDF files" [Normal,Open] http://bugs.debian.org/515918
<cjwatson> I think they maybe have some pressure from carriers, but I'm only reading between the lines here
<cjwatson> however, we have no contract with the carriers
<pitti> tkamppeter: that's probably due to switching to ghostscript mode from -13 to -14
<cjwatson> I'm a little conscious that this is a company that is at least *trying* to work with Linux, mind ... but I don't think there's much we can sensibly do, we have a general goal of out-of-the-box
<cjwatson> Dan suggested some technical adjustments they could make to future revisions to make things easier for us, which they seem to have tentatively acknowledged
<cjwatson> in the meantime I think we should proceed as before
<tkamppeter> pitti, Debian bug 515918 was not cauised by the transition from 13 to 14. 13 alreeady had tyhe problem according to the reporter of the bug.
<ubottu> Debian bug 515918 in cups "cups: prints raw source of PDF files" [Normal,Open] http://bugs.debian.org/515918
<pitti> tkamppeter: hm, but he says it hasn't happened with the non-PDF workflow
<tkamppeter> pitti, ask him to post the PDF files which failed, the evince version, the PPD file(s) of his print queue(s).
<pitti> tkamppeter: okay
<Geek`N`Proud> Hey guys:  How safe are "proposed updates" with regards to core system functionality?  I'm more than happy to encounter a few bugs to prevent the average user, what's the worst I could expect realistically?
<directhex> worst? unbootability
<pitti> Geek`N`Proud: depends; if you install a new kernel from -proposed, then this might not even boot, and you need to go back to the previous one in teh grub boot menu (but of course those are the very things we are interested in getting feedback about)
<Geek`N`Proud> ah that's fine
<pitti> Geek`N`Proud: it really depends on the package; in the theoretical worst case, a package could fail to work completely
<pitti> Geek`N`Proud: that doesn't actually happen that often, but we did have at least two miscompilations in Ubuntu's history, for example
<pitti> Geek`N`Proud: with some effort and asking for help here, it should always be possible to recover from this, though
<Geek`N`Proud> Was one of those glibc on Hardy BETA? :P
<Geek`N`Proud> i'm willing to give it a go... with exception to the time glibc broke i've always recovered :D
<Geek`N`Proud> thanks guys ^^
<pitti> Geek`N`Proud: entirely possible, I don't remember any more; but "proposed" -> stable releases, != development release (beta)
<pitti> Geek`N`Proud: thanks a lot; if you encounter a regression, please come here immediately and ping me, cjwatson, or slangasek; we all are 24/7 in IRC and read scrollback
<Silicium> anyone know where in or around the casper on a live CD the gtkrc file for the live user is placed?
<Silicium> and also the themes and gnome style
<cjwatson> Silicium: ... what gtkrc file for the live user? it uses system defaults
<asac> Keybuk: seems you use bzr-git for the udev-extras branch? how are your experiences. is that reliable?
<asac> btw, there is no new commit yet
<Keybuk> I'm not using bzr-git
<Keybuk> I'm using git fast-export | bzr fast-import
<Silicium> cjwatson: ok
<AnAnt> Hello, is Ian Jackson here ?
<soren> AnAnt: Nope.
<directhex> doesn't he work for sun these days?
<evand> Citrix
<soren> Citrix
<evand> :)
<directhex> bah, i confused him with ian murdoch. i need more sleep!
<directhex> murdock
<directhex> even more sleep
<AnAnt> so, iwj@ubuntu.com is invalid ?
<cjwatson> it may still exist but that doesn't mean it gets read ...
<cjwatson> actually it probably doesn't exist any more
<cjwatson> perhaps you should say what you want rather than asking for a particular person, and somebody else may be able to help
<AnAnt> well, regarding LP 144468
<ubottu> Launchpad bug 144468 in sl-modem "sl-modem-daemon does not work on some hardware" [High,Fix released] https://launchpad.net/bugs/144468
<AnAnt> he solved it by doing: ulimit -Hl unlimited before running slmodemd
<soren> Yes.
<AnAnt> someone on Debian, commented on this fix as follows: If I'm not wrong, assigning unlimited locked memory can give the process
<AnAnt> the ability to lock the whole machine: dropping the privileges loses
<cjwatson> the justification for that in the changelog seems reasonable, yes
<AnAnt> then part of its sense.
<cjwatson> I don't think Ian would mind if somebody figured out a better fix that actually solved the original problem as well
<AnAnt> the full comment is on debian bug 511996
<ubottu> Debian bug 511996 in sl-modem-daemon "sl-modem-daemon: slmodemd doesn't work, process unkillable" [Important,Open] http://bugs.debian.org/511996
<cjwatson> such as making it use less memory
<cjwatson> in the meantime it behooves anyone dealing with it in Ubuntu to avoid introducing regressions
<AnAnt> cjwatson: well, I wanted to know his opinion about the comment
<cjwatson> if a sane upper bound has been determined that's actually reliable, then I see no reason not to have a stricter bound
<AnAnt> cjwatson: ok, thanks
<cjwatson> you can google for Ian and find his contact details if you want
<cjwatson> http://www.chiark.greenend.org.uk/~ijackson/contact.html
<Koon> Archive Admins: what is our position regarding CDDL ?
<directhex> Koon, CDDL is a free software license, it's just not GPL-compatible. why would it cause concern?
<Koon> directhex: I thought it was controversial in Debian. If it's not, then I'm happy with it.
<Koon> directhex: thx
<directhex> Koon, i think some projects mix GPL with CDDL when they can't
<directhex> e.g. cdrecord
<Silicium> where is defined the liveCD default theme?
<Silicium> so, i have changed the human themes color an icons
<Silicium> and now i want to use this in the live cd
<Silicium> i just have a .theme file
<Silicium> ./usr/share/themes/Human/index.theme ?
<Silicium> hmm i will try :p
<Keybuk> slangasek: well, if you have UTC, one of the biggest changes in the new hwclock setting code is that hwclock isn't called at all <g>
<Keybuk> so it's good to know it still works
<pitti> Keybuk: I have this version installed as well, FYI, no problems so far; hwclock is still correct
<pitti> Keybuk: but I also use UTC, and I didn't test large offsets or anything; is there something we should try?
<Keybuk> the old bug was an American using a local time clock, who needed a filesystem check
<Keybuk> reboot after the filesystem check, and all your modification times are in the future, and you need another one
<Silicium> is there a channel for get help which are not dev type but also not beginner ones?
<cody-somerville> mdke, I sent you an e-mail re: your e-mail this morning.
<Silicium> sorry guys i need to ask this here, but nobody can answer me...
<cody-somerville> Silicium, #ubuntu
<Silicium> i cant get the point where is the actual user gnome theme defined
<cody-somerville> Where the current one in use is defined?
<Silicium> yes
<cody-somerville> Probably in gconf
<Silicium> that also i think\
<Silicium> but i cant find
<Silicium> nowhere i get help about that, no support chans, no mailinglists and no googling...
<Silicium> is so damn crap
<cody-somerville> Try /desktop/gnome/interface
<Silicium> ok thanks
<cody-somerville> (btw, google told me that)
<Silicium> :/
<cody-somerville> It was in the Gnome FAQ
<MacSlow> mvo, I was a bastard and assigned you to https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/331037 sorry :)
<ubottu> Ubuntu bug 331037 in compiz "alter default set of values for plugins to work correctly with notify-osd" [Undecided,Confirmed]
<mvo> MacSlow: I'm sure it includes a patch?
<MacSlow> mvo, not yet
<mvo> I like the "yet" in this :)
<MacSlow> I knew :)
<ogra> MacSlow, did you assign it to mvo because the subject starts with "alter" ? :)
<mvo> lol
<mvo> that would be more a dholbach bug ;)
<MacSlow> ogra, Alter Schwede ... you're almost right :)
<mvo> he started it all!
<ogra> well, for dholbach it needs an additional exclamation mark or two :)
<MacSlow> dholbach uses "Alter!"
<dholbach> Â¡Â¡Â¡Â¡ !!!!
 * MacSlow uses "Alter Schwede!"
<MacSlow> subtle difference :)(
<MacSlow> :)
<MacSlow> mvo, we use cdbs for compiz right?
<MacSlow> outch ... not
<MacSlow> it uses quilt
 * MacSlow pukes
<MacSlow> sorry for that :)
<mvo> MacSlow: no need for a debdiff really
<mvo> MacSlow: just the config snippet is enough, I can do the integration
<MacSlow> mvo, phew ... ok
<mvo> MacSlow: you probably want the "fade" from the animation plugin though
<MacSlow> mvo, well I'm looking at the default install and there we have the normal Fade-plugin enabled in Jaunty
<MacSlow> so that'll just get a new window-match rule "!Notification" instead of the old value "any"
<mvo> MacSlow: right, but animation overrides the fadeing (if its enabled)
<MacSlow> mvo, hm... didn't happen here
<mvo> MacSlow: is the name of the window "Notification" ? I can add it then
<MacSlow> I'll just make sure I'll add the needed bits to the animation -plugins changes too
<MacSlow> mvo, it's acaually the class
<MacSlow> not the window-title/name
<mvo> MacSlow: thanks. strange still, animation should overrule fade, might be a but somewhere
<MacSlow> mvo, just added the two patches to https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/331037
<ubottu> Ubuntu bug 331037 in compiz "alter default set of values for plugins to work correctly with notify-osd" [Undecided,Confirmed]
<mvo> thanks MacSlow
<mvo_>  MacSlow: with the patch that remove "Notification" from the default, will that mean that the old notifications will no longer be faded?
<mvo_>  (if someone wants to use notification-daemon instead of alsdorf^Wnotify-osd?
<mvo_> (sorry, got disconnected *again* *sigh*)
<allquixotic> Are there any PPAs or otherwise out there which apply Ubuntu's .config (and maybe patches, but not important) to the latest prepatch of the upstream kernel, e.g. 2.6.29-rcX?
<allquixotic> (and ship binary builds)?
<cjwatson> apw: ^-
<mvo_> MacSlow: could we make it so that the old ones sitll work? i.e. is there osmething to test for
<apw> cjwatson, will answer in a sec
<apw> allquixotic, https://wiki.ubuntu.com/KernelMainlineBuilds
<MacSlow> mvo_ well we can at somepoint just name the notification windows differently
<allquixotic> apw: thank you, I appreciate it :)
<allquixotic> and thanks cjwatson for pinging
<mvo_> MacSlow: that would be nice
<MacSlow> mvo_ hm... wait with the patches
<MacSlow> I'll just change that
<mvo_> MacSlow: thanks, maybe type Notification is fine, just some name to be able to identify it?
<mvo_> MacSlow: we have the !(name=compiz) rule
<mvo_> we could extend that
<mvo_> MacSlow: anyway, I'm standing ready and can upload at once :)
<stgraber> ogra: any idea why ltsp-build-client wouldn't be called with current daily ?
<stgraber> ogra: http://www.davmor2.co.uk/syslog
<davmor2> ogra: if you need any other logs give me a shout
<ogra> stgraber, hmm, weird, no ... i know cjwatson wanted to make some changes to the defaults for the actual inclusion of ltsp-client-builder, but i see the udeb is clearly executed, it just doesnt call ltsp-build-client
<stgraber> ogra: I did a small change to disabled --mount-cdrom but I really doubt that's it
<ogra> no, you would see errors
<ogra> it doesnt even attempt to run ltsp-build-client
<Keybuk> I think I need another monitor
<cjwatson> the udeb isn't being loaded
<cjwatson> oh
<ogra> cjwatson, hmm ? what installs ltsp-server and frinds then ?
<cjwatson> stgraber,ogra: I forgot to roll out my debian-cd change to antimony
<ogra> *friends
<ogra> ah
<cjwatson> ogra: other bits of the preseed file
<cjwatson> fixed for the next build, thanks
<cjwatson> davmor2: ^-
<davmor2> cjwatson: And there was me thinking it was the installer :)
<BUGabundo> pgraner: ping
<BUGabundo> can you take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/329254
<ubottu> Ubuntu bug 329254 in pm-utils "WARNING: at /build/buildd/linux-2.6.28/kernel/power/main.c:177 suspend_test_finish+0x7c/0x80()" [Undecided,New]
<BUGabundo> I'm starting to think it's the hibernate test of apport
<BUGabundo> ogasawara: ping ^^^^^^^^
<pgraner> BUGabundo: apw is handling all the suspend/resume testing...
<pgraner> apw: ^^^^^^^^^^
<BUGabundo> okay
<BUGabundo> I've subs you to the bug... please remove your self then... sorry
 * apw looks
<BUGabundo> thanks apw
<manjo> superm1, ping
<manjo> superm1, I have 2 laptops for you
<jdstrand> seb128: hi! I wanted to quickly ask you if I'm missing something obvious or should file a bug. 'Alt+F2' (Run application) hasn't worked for me in jaunty in a while (my keyboard shortcuts are correct). Does it for you? What package should I be looking at?
<BUGabundo> apw: anything else you need from me, to add to the bug?
<apw> sorry been on the phone
<BUGabundo> np
<apw> BUGabundo, ahh, those call traces are simply warnings that resume took a little longer than expected
<BUGabundo> humm
<BUGabundo> but hibernate now failes
<apw> and yes, the web cam does seem to be the straw that takes up over the 5 second mark
<BUGabundo> it was working on Saturday
<BUGabundo> I removed the module, and installed -8 today
<BUGabundo> and it still fails
<BUGabundo> just awakes before shuting down
<apw> Feb 17 01:17:00 blubug kernel: [15010.424230] PM: resume devices took 8.112 seconds
<apw> ok if its not shutting down at all then its not that trace thats the issue
<BUGabundo> then it has just coincidence?
<Keybuk> cjwatson: you know that Fedora said they're supporting btrfs in F11 and ext4 is going to be the *default*?
<BUGabundo> how lucky for me
<cjwatson> Keybuk: mm-hm?
<BUGabundo> Keybuk: really?  there goes competition
<apw> that is just saying that the wake up took a long time, it doesn't change the behavior on eesume
<Keybuk> cjwatson: and Fedora 11 is going to be the basis for RHEL 6
<apw> if you clean boot and remove the webcam driver and it doesn't hibernate then there is a separate
<cjwatson> how long will RHEL 6 take to stabilise, though?
<apw> bug going on.
<Keybuk> these two statements to me appear to be at odds with each other
<cjwatson> could take quite a while ...
<apw> i would file a new bug for that, and the first thing you should do is
<BUGabundo> apw: but it simply fails... I don't know how to put it...
<cjwatson> anyway, I imagine it wouldn't be hard to change the default filesystem in RHEL
<Keybuk> true, that is the question I don't know the answer to
<apw> try the hibernate from VT1 and run pm-hibernate there
<BUGabundo> start regular hibernate, and then awakes, before disk stop
<apw> BUGabundo, well that is a reasonable statement of the error
<apw> if you could file it like that
<BUGabundo> I tried yesterday from recovery console
<apw> then do the test i just suggested, and also attach the dmesg output following the attempt to hibernate to the new bug
<BUGabundo> already without driver loaded
<BUGabundo> but with kernel -7
<apw> and i would like to see the dmesg output from that, or a repeat on -8
<BUGabundo> I haven't installed the driver to this new kernel
<Keybuk> james_w: I vaguely remember you saying you'd eliminated a hwclock call
<apw> even better
<BUGabundo> will do in a few minutes
<apw> as that confirms that its not that driver
<Keybuk> james_w: was that in pm-utils or acpi-support
<apw> if its not working without that driver, best to test without the driver
<MacSlow> mvo__, outch I attached the wrong files to the compiz bug ...
<apw> BUGabundo, i will write up what this erorr means in this old bug and close it off, so others who find it know what i means
<apw> and let me know the new bug number
<Riddell> james_w: what was the bzr-buildpackage command to create a temporary shell with your sources and packages together so you can edit then exit ?
<BUGabundo> ok
<BUGabundo> I'll sub you to it once I open it
<BUGabundo> do you need the regular kernel tests too?
<BUGabundo> or just dmesg apw?
<apw> i am particularly interested in dmesg after the failed hibernate, as that should have hints as to how far down it got
<BUGabundo> ok
<mvo__> MacSlow: no worries, just give me the name/type to match against and I add it
<BUGabundo> brb , reboot
<tjaalton> hrm, apport tried to open the bug-filing page, but the url was "file:///ubuntu/.../+filebug/<hash>", which obviously failed
<apw> tjaalton, that is the glib2.0 bug
<apw> if you downgrade that to the previous ubuntu15 version it works again
<tjaalton> apw: ok.. the kernel crashed on resume from hibernate, again.. but it's possibly just nvidia doing it's business
<tjaalton> hmm, I've got 2.19.6-0ubuntu3
<Keybuk> pitti: you have unreleased changes to acpi-support/
<apw> nivce
<apw> tjaalton, will check the versions i have either side of the bug
<apw> i had to build the old one to confirm it was broken
<tjaalton> apw: maybe I'll just upgrade and hope the problem goes away :)
<apw> didn't for me yet
<tjaalton> apw: the one that caused the crash
<tjaalton> :)
<apw> oh heh
<apw> lets hope
<tjaalton> resume from suspend just crashes X, so it's not quite as bad :)
<apw> tjaalton, what a lovely life your laptop leads
<tjaalton> apw: actually this is my desktop, but they both share the symptoms
<apw> worse even
<ScottK> bigon: In Debian when you updated pymsn to Change python-elementtree to python (>= 2.5) | python-elementtree that you changed just depends and not build-dep too?
<ScottK> ... was there a reason ... is missing out of there
 * Keybuk gets confused
<Keybuk> so we have /etc/pm/sleep.d, /etc/acpi/suspend.d and /etc/apm/suspend.d
<Keybuk> and all of them have different scripts in them
<Keybuk> which is used? :)
<cjwatson> Keybuk: yes
<jdong> I thought pm/* was the only one that mattered these days?
<ogra>  /etc/pm should be the default
<Keybuk> so what are the others doing there?
<jdong> "legacy API"
<jdong> ;-)
<ogra>  /usr/lib/pm-utils/ for systemwide settings
<Keybuk> so what's all that /etc/acpi-support/suspend.d stuff doing there?
<Keybuk> did somebody just not get around to removing it yet?
<jdong> I think we still use some config optiosn in /etc/default/acpi-support
<ogra> apmd ships the /etc/apm/ tree
<ogra> (dont ask me why though)
<jdong> and that just happens to ship the /etc/acpi-support tree
<Keybuk> ogra: right, apm makes sense - some machines still only support apm
<ogra> Keybuk, slangasek fiddled with acpi-support changes this cycle iirc
<ogra> might still be something with hdparm stuff
<slangasek> jdong: we aren't using them by choice; the whole thing should be phased out, but it should be faced out gracefully
<Keybuk> slangasek: so what do the old suspend.d scripts do?
<pitti> Keybuk: yes, slangasek asked me to not upload them yet
<slangasek> Keybuk: handling suspending when you're using acpi-support for suspending instead of pm-utils
<jdong> are the ac.d/battery.d events handled by acpi-support still?
<Keybuk> slangasek: and how might you be using acpi-support instead of pm-utils?
<pitti> Keybuk: yes, /etc/acpi-support/suspend.d/ should be killed, and the good bits perhaps carried over to /etc/pm/ scripts
<slangasek> Keybuk: which I think happens, currently, if the suspend is triggered via an ACPI event and acpi-support sees that you don't have an active X session
<ogra> and /etc/pm scripts need to be reviewed to not be darn slow :)
<Keybuk> ok
<slangasek> (I haven't dug into that to confirm; it should certainly be considered a bug, regardless)
<Keybuk> ok
<Keybuk> I'll update acpi-support "just in case"
<Keybuk> james_w, slangasek: from the docs of pm-utils
<Keybuk> +* If your clock drifts across a sleep/wake cycle, you can use
<Keybuk> +  NEED_CLOCK_SYNC="true" to force pm-utils to synchronize clocks.
<Keybuk> +  This is a change in the default behaviour of pm-utils -- 1.2.2.1 and earlier
<Keybuk> +  always synchronized clocks, but doing so is slow and most hardware stays in
<Keybuk> +  sync without assistance.
<Keybuk> that's incorrect
<Keybuk> it's not that the hardware stays in sync without assistance
<Keybuk> it's that the kernel already contains code to synchronise them
 * Keybuk isn't sure whether that was added upstream, the MoM diff is hard to read ;)
<Keybuk> slangasek: ok, hwclock changes committed to bzr
<Keybuk> upload at your leisure
<slangasek> @whee
<BUGabundo> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/331101
<ubottu> Ubuntu bug 331101 in linux "s2disk[3330]: segfault at 0 ip 0000000000000000 sp 00007fff942ccdf8 error 14 in s2disk[400000+8000]" [Undecided,New]
<taavikko> someone able to say anything about this? https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/329161
<ubottu> Ubuntu bug 329161 in transmission "Transmission 1.50 should be considered for inclusion in 9.04" [Undecided,Confirmed]
<Keybuk> slangasek: moving over here
<slangasek> yah
<Keybuk> powernowd uses the scaling driver and adjusts the frequency based on polling
<Keybuk> I cannot see why ondemand wouldn't work?
<slangasek> I don't know
<slangasek> but that's what the init script claims to do
<Keybuk> the init script simply seems to guard against the ondemand governor not existing
<slangasek> hmm, ok
<Keybuk> (ie. it pokes ondemand into scaling_governor, and is happy if that succeeds)
<BUGabundo> apw: ping
<Keybuk> certainly there's nothing in the ondemand governor code itself that would fail
<apw> BUGabundo, hi
<slangasek> Keybuk: right - let's axe the thing then :)
<BUGabundo> did you see the bug linki?
<BUGabundo> apw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/331101
<ubottu> Ubuntu bug 331101 in linux "s2disk[3330]: segfault at 0 ip 0000000000000000 sp 00007fff942ccdf8 error 14 in s2disk[400000+8000]" [Undecided,In progress]
<apw> yep seen it
<apw> BUGabundo, an update added to the bug
<BUGabundo> ok
<Keybuk> slangasek: this hwclock change fixes a lovely bug
<slangasek> oh?
<Keybuk> DST getting applied/removed across a suspend/resume cycle
<Keybuk> what happened before
<Keybuk> system clock saved to hardware clock on suspend (delta without DST)
<Keybuk> on resume, system clock restored from hardware clock
<Keybuk> but localtime() called, so it's assumed the delta was with DST
<Keybuk> but since the kernel already adjusted it, it wasn't
<slangasek> hee
<Keybuk> and the whole thing got into a bit of a mess, and depending whether you're east or west
<Keybuk> you'd either not have DST applied
<Keybuk> or have double-DST
<Keybuk> by not doing any of this, the hardware clock stays in non-DST localtime across a suspend/resume
<Keybuk> which means the system clock stays in correct UTC across a suspend/resume
<ogra> it should pop up a message "please move one TZ east/west" :)
<Keybuk> which means all the software in userspace just works (because DST is calculated there anyway)
<Keybuk> when we shut down, we're free of mid-air collisions, so the hardware clock is written out with the DST-adjusted time
<slangasek> so when the user reboots to Windows they'll still get it double-applied, but that's why you shouldn't have your clock in localtime. :)
<BUGabundo> apw: set to kernel again"
<Keybuk> slangasek: exactly
<BUGabundo> do I need to reboot, or does it work
<apw> BUGabundo, ?
<BUGabundo> right now?
<BUGabundo> /etc/pm/config.d/00sleep_module
<Keybuk> but Windows is pretty idiotic and if left on overnight, some versions still apply DST every time it reaches 2am
<Keybuk> 2am, ah, DST, 1am now
<Keybuk> 2am, ah, DST, 1am now
<Keybuk> 2am, ah, DST, 1am now
<Keybuk> 2am, ah, DST, 1am now
<Keybuk> ...
<apw> i would like to see if that workes yes
<BUGabundo> but do I need to reboot?
<apw> i don't believe so no
<BUGabundo> or can I try it right now?
<BUGabundo> ok
<BUGabundo> brb
<Keybuk> slangasek: I'll just de-seed powernowd, shall I?
<slangasek> Keybuk: sure
<slangasek> do you know an ETA for the corresponding kernel upload?
<slangasek> also, should we be kicking this package clean out of the archive rather than demoting to universe?
<Keybuk> well, it's claimed to be unmaintained by the author now
<Keybuk> slangasek: "a few minutes" :)
<slangasek> heh
<BUGabundo1> apw: it works /TM)
<BUGabundo1> slow as hell, but it works
<BUGabundo1> took way too much to hibernate (compare to pm-utils with compressed image)
<soren> Could a friendly archive admin please demote eucalyptus to multiverse?
<BUGabundo1> and resume, just froze my desktop for a while (it used to be almost immediate)
<soren> It has build-deps in there right now, so to get it built and all that before FF, we need it demoted.
<Keybuk> slangasek: seed changes committed, shall I just go ahead and do ubuntu-meta on the basis the kernel is coming soon
<soren> We'll be fixing this all up and moving it to universe (or main or whatver) later on.
<slangasek> Keybuk: if it's really that soon, sure
<Keybuk> since powernowd's init script is actually broken right now and not installing the scaling driver in the majority of cases, it's not likely to really break anything if people have it deinstalled before getting the kernel
<BUGabundo1> apw: set to invalide the linux task?
<slangasek> Keybuk: "in the majority of cases"?
<Keybuk> slangasek: anything that should use acpi-cpufreq afaict
<apw> BUGabundo1, cool.  i will handle the bug close, and shove it off to s2disk people
<slangasek> Keybuk: acpi-cpufreq is loaded correctly for me here
<apw> as they should be made aware s2disk isn't working in jaunty
<Keybuk> slangasek: you have a /sys/devices/system/cpu/cpu0/cpufreq ?
<slangasek> Keybuk: yes
<BUGabundo1> apw: it was up until Saturday
<apw> it was working until Sat?
<BUGabundo1> will ubuntu ever use a faster hibernate kernel mode?
<Keybuk> what does /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver say?
<BUGabundo1> apw: yes it was
<apw> BUGabundo1, define faster?
<BUGabundo1> I even tested it and added to the wiki page for resume testing
<slangasek> Keybuk: 'acpi-cpufreq' - this was all implicit in my statement that it was "loaded correctly" :)
<Keybuk> slangasek: lucky git <g>
<Keybuk> it's not loaded at all for me
<apw> BUGabundo1, a good plan
<BUGabundo1> humm I guess the best way for you to know, is for you to test
<Keybuk> acpi-support seems to irrationally prefer speedstep-* to acpi-cpufreq
<Keybuk> which of course promptly fail to load
<BUGabundo1> for me, hibenate took much less and the timed count down helped A LOT
<slangasek> hmm
<ogra> Keybuk, still having the scripts in use ?
<ogra> or is that plain kernel now
<Keybuk> err
<Keybuk> powernowd
<BUGabundo1> apw: and then, desktop would be much faster to react
<Keybuk> powernowd seems to irrationally prefer speedstep-* to acpi-cpufreq
<Keybuk> wrong evil package
<apw> BUGabundo1, with uswsusp ?  i see, well lets get someone from there to look at it
<BUGabundo1> not its just slow.... and a black screen for 10 secs
<BUGabundo1> apw: I been using it since hardy
<Keybuk> BUGabundo1: what happens if you buy a faster disk?
<BUGabundo1> and then you guys kicked it of the kernel
<apw> if you could paste in any informaiton you have on the uswsusp into the bug
<BUGabundo1> Keybuk: both uswsusp and kernel mode be faster?
<apw> like what its version is now, and check if it got updated since saturday
<BUGabundo1> humm apw I added my installed version
<apw> see /var/log/apt/term.log or similar for that info
<BUGabundo1> already deleted my weekend apt-changes
<BUGabundo1> let me see if apt has it
<BUGabundo1> yep that's it!
<apw> mostly things get thrown own of the kernel when upstream gets it in their head that its not going to ever get finsihed
<apw> and we don't get much control over that kind of thing
<apw> BUGabundo1, heh its upgraded from 0.6 to 0.8 ... yeeks
<BUGabundo1> revert then ?
<BUGabundo1> or fix
<apw> Keybuk, you look to be the last person who touched uswsusp you know who merged it from debian about 4 days ago?  The changelog doesn't seem to have a name in it?
<Keybuk> apw: no idea
<apw> the LP page myust be broken, will look at the diff ... sorry to bother
<ogra> there should be a merge bug as well
<ogra> if there is no name in the changelog it likely was synced from debian via a bug request
<apw> there is one in the real changelog, just the LP page on the versions stops short of the -- WHO line for some reason
<ogra> apw, Changed-By: Devid Antonio Filoni <d.filoni@ubuntu.com>
<apw> ogra, thanks
<ogra> it has done a jump from 0.7 to 0.8 with several debian versions inbetween
<apw> yeah is all a bit scarey
<apw> now to find Devid
<ogra> well, its in niverse for a reason :)
<ScottK> apw: He goes by devfil on IRC.
<ogra> LP id ... should list his IRC nick
<BUGabundo1> ogra: sure
<BUGabundo1> but its way better then the kernel mode
<apw> yeah and he is not about
<apw> poop
<BUGabundo1> much faster, and interative
<ogra> BUGabundo1, if it would be better we would use it by default
<ogra> it works faster on some machines
<apw> and segfaults on others it seems
<ogra> and breaks many others heavily
<BUGabundo1> LOL
<BUGabundo1> it just stared segfaulting...
<BUGabundo1> not on any laptop I ever touched
<BUGabundo1> but I followed one of it bugs....
<BUGabundo1> heads rolled in there
<BUGabundo1> ppl got to extremes
<ogra> such is life ...
<apw> its a contensious issue.  the kernel maintainers for the suspend stuff are more than one, and all very opionionated
<ogra> i think the case BUGabundo1 means were ubuntu users
 * ogra thinks he remembers that bug from the time where he cared for gnome-power-manager
<apw> BUGabundo1, ok done what i can get this this to his attention,
<apw> hopefully you will get contacted via your bug to test things
<BUGabundo1> thanks
<BUGabundo1> ogra: let me see if my ff awesome bar remember is
<apw> you should have email updates for it
<slangasek> Keybuk: wrt your request for a standing freeze exception, from a freeze policy standpoint I'm uncomfortable with this because it's not clear to me what is or isn't in scope (so I don't know what I'm agreeing to)
<slangasek> Keybuk: could we narrow this somewhat?
<Keybuk> how would you like it narrowed?
<slangasek> well, start by telling me what you think is in scope? :)
<Keybuk> anything that is started at boot-time
<slangasek> heh
<slangasek> see, that's why I'm concerned about it being a standing exception
<slangasek> if it were "killing startup scripts we don't need" or "converting some init scripts to upstart jobs", that I could see giving a blanket exception for; but not "anything at boot"
<Keybuk> it's not mostly that kind of thing
<mathiaz> slangasek: I've tried to build openldap 2.4.14 based on your work and it works well
<mathiaz> slangasek: which tests were failing?
<mathiaz> slangasek: (that was on jaunty)
<slangasek> mathiaz: one of the concurrency tests locked up with the hdb backend; I ran it twice more and it succeeded, so I guess it's racy :(
<mathiaz> slangasek: ok - so do you plan to upload to unstable?
<mathiaz> slangasek: I've got a package ready for jaunty
<slangasek> mathiaz: there was a commit Quanah said we should pull, I was going to do that before upload to unstable
<mathiaz> slangasek: are you still on track for an upload for today?
<slangasek> mathiaz: to unstable, or to jaunty? :)
<mathiaz> slangasek: unstable
<mathiaz> slangasek: I can take care of jaunty
<slangasek> mathiaz: if getting it in unstable helps you get it sorted in jaunty for FF, I will; otherwise the upload won't be a priority today
<mathiaz> slangasek: I've already got a pkg ready (it's in a loomified bzr branch)
<mathiaz> slangasek: I don't need an upload to debian. I'll base my work on the current content of the svn repository then.
<mathiaz> slangasek: I'll add the two patches Quanah refered to
<slangasek> mathiaz: ack
<LaserJock> does anybody know if the archive reorg plan has any allowance for Universe-like lobes? some sort of split between supported and community-supported
<persia> LaserJock, How do you mean?  I can't speak authoritatively, but I'm mostly familiar (and "lobes" is deprecated: "layers" is the appropriate term for (usually depends/recommends/build-depends closed) package sets)
<LaserJock> persia: well, I'm wanting to create 2 layers (although I'm not sure if it's exactly equal to the seed "layer") for Edubuntu
<LaserJock> one that roughly corresponds to Main and one corresponding to Universe
<LaserJock> I don't want to create something that's going to disappear in a couple of months
<Keybuk> asac: what happens if nm-applet starts but NetworkManager isn't running
<cjwatson> it certainly won't disappear in a couple of months anyway
<Keybuk> does it die, or does it wait patiently for it to start
<cjwatson> I haven't updated the spec yet, but we're decoupling the permissioning changes from the actual component reorganisation
<LaserJock> cjwatson: well, for Jaunty+1?
<asac> Keybuk: it waits ... i even patched out that it doesnt show up ... so now you get an erroful icon and if you click on it it says "netowrkmanager not running"
<Keybuk> so we don't need to start NetworkManager before gdm?
<persia> cjwatson, so the components will probably remain, but the permissions will shift?  Will the components be considered to have semantic value?
<asac> Keybuk: err. well. we have system-connections now
<asac> so you can have a working network even without logging into X
<Keybuk> asac: what I mean is, currently Network Manager is started before gdm
<Keybuk> whereas if we started it after, we'd save a tenth of a second or so
<Keybuk> and NM can do its thing while X starts
<cjwatson> so the extension of permissions will happen first, and then we'll look at component work later once there are better facilities in LP
<persia> LaserJock, Very loosely, a layer will correspond to a seed branch, and layers ought be permitted to depend upon other layers (as seed branches can depend upon other seed branches).  So, if you have two sets of seeds, you'll be well aligned.
<allquixotic> Does anyone else get an error when running xdriinfo on Jaunty?
<Keybuk> if the race went slow and NM wasn't quite ready when the session was logged in (which should be practically impossible, given X is 6s to start and compiz 10s) then is the worst that would happen that they'd get a brief error logo
<asac> Keybuk: sure. as long as gdm can properly deal with a "suddenly appearing" network
<cjwatson> also, I think we're just going back to "package sets" as the naming. [sorry.]
<asac> Keybuk: at some point we hopefully get an applet like thing into gdm
<Keybuk> asac: it has to anyway, starting NM just means the daemon is started - not that there's a network interface
<asac> Keybuk: true. but starting it early enough ... ;)
<Keybuk> the NM init script doesn't wait for NM to get a network connection up
<cjwatson> LaserJock: as long as you think of them in terms of who's supposed to have upload access rather than in terms of main and universe, then with what persia says you should be fine
<asac> right
<asac> Keybuk: so which numbers should i use ;)?
<LaserJock> cjwatson: I'm more concerned about the level of support than who can upload
<Keybuk> asac: > 30 - 50 sounds sensible
<asac> Keybuk: what is > 30 - 50? > 50 ?
<asac> or between 30 and 50 ;)
<persia> cjwatson, Actually, if there are no negative permissions based on Depends/Recommends/Build-Depends complete sets, "package sets" makes more sense than "layers".
<Keybuk> asac: I mean "greater than 30", "50 sounds like a sensible number"
<LaserJock> right now we can call Main the core set of apps and Universe the community supported "extras"
<LaserJock> but I'm wondering if the archive reorg will make it very difficult to define any of that
<persia> LaserJock, Well, that semantic meaning lost value a few releases ago, in terms of actual coordination of packages.
<asac> Keybuk: ok so i use update-rc.d NetworkManager start 50 2 3 4 5 . then
<Keybuk> asac: yup
<persia> I believe Intrepid included changes to allow declaration of "Supported" separately from component.
<cjwatson> LaserJock: if you regard this as an important distinction, there's no reason not to have separate sets
<cjwatson> LaserJock: either in the old model or the new model
<asac> Keybuk: ok done
<LaserJock> persia: really? do you happen to know if gnome-app-install knows about that
<asac> next upload will get that
<LaserJock> the only bit I've seen is Main = "Canonical-maintained" in Intrepid
<cjwatson> persia: I hadn't heard of that
<persia> LaserJock, I think that's where it's implemented.
 * persia hunts changelogs
<cjwatson> (of course it's entirely possible it exists nevertheless, I'm not omniscient ;-) )
<LaserJock> *gasp*
<LaserJock> ok, so do people not find different levels of support as useful then?
<persia> I don't know exactly where, but I recally being told by a couple people it was done.
<LaserJock> I've always found the "Main is the core subset of apps we heavily support as a project" useful
<asac> Keybuk: so why do you want this change actually? you think it reduces startup time?
<Keybuk> asac: it does reduce startup time
<asac> how much of a win?
<Keybuk> moving a whole bunch of things in rc2.d to after gdm seems to buy us 3 seconds
<asac> ok. lets try it then
<persia> Hrm.  https://blueprints.launchpad.net/ubuntu/+spec/package-supportedness-ui is similar, but not quite it.
<persia> LaserJock, cjwatson My apologies: I don't see it, which may well mean I'm mistaken.  mvo would know for sure.
<cjwatson> LaserJock: I think it's useful, but main/universe has too many other things associated with it. That's, er, rather a lot of the point of archive reorg :)
<LaserJock> cjwatson: right, I guess Edubuntu's a bit of a corner case
<LaserJock> I think we're likely to have more problems than gains by permission changes
<LaserJock> and the supportability bit was useful
 * Keybuk has a moment
<Keybuk> I've just completely forgotten what I just changed
<Keybuk> oh, I remember
<cjwatson> LaserJock: I don't see how anyone would have problems, TBH. It makes things more flexible; you can always constrain it back if you like
<LaserJock> cjwatson: well, I wanted to leverage MOTU and they're kinda going away from what I understand
<shtylman> cjwatson: so...I have hit a roadblock...the debian installer user-setup currently being used is hard coded to the /etc/kde3 directory
<shtylman> what would I need to do to change that?
<shtylman> I have found the user-setup script I need to change...but beyond that..
<Keybuk> http://people.ubuntu.com/~scott/jaunty-20090218-5_cropped.png
<shtylman> oops...wrong window...my bad others
<LaserJock> for instance, will it be easy to say anybody in todays ~ubuntu-dev can upload a package that's in one of Edubuntu package sets?
<geser> LaserJock: if I understood it correctly then yes, ~ubuntu-dev will be generalists that can upload nearly everything
<LaserJock> geser: and ~ubuntu-dev will be roughly what it is today?
<geser> yes, ~motu + ~core-dev
<LaserJock> geser: and then can I restrict to something that's more ~core-dev?
<LaserJock> I thought ~ubuntu-dev was going to get to upload to anything that wasn't in the package sets
 * geser checks the wiki page again
<geser> LaserJock: ~ubuntu-dev will get uploads to the entire archive (minus the restricted layer)
<LaserJock> geser: so that sounds like ~core-dev
<LaserJock> so MOTU are getting a promotion? :-)
<geser> LaserJock: yes
<LaserJock> well, I can't say I'm very excited about that
<geser> LaserJock: it's not clear yet now the transition of ~motu to the new ~ubuntu-new will look like
<LaserJock> that seems like something we should vote on or something
<LaserJock> since it's a big bump in trust
<geser> yes :/ but with the archive reorg you either have to promote motu or demote it to unseeded packages
<ScottK> geser: With the exception of Universe flavors it's unseeded packages today, so it's not much of a demotion.
<persia> And if you want to enable arbitrary overlapping package sets (e.g. The Ubuntu Haskell Team), the demotion can be very deep indeed.
<ScottK> True.  Depends on how package sets are defined.
<LaserJock> but that gives the package set owners the flexibilty to determine the appropriate level of trust
<persia> LaserJock, *overlapping*
<geser> ScottK: exactly, if you move the several gnome packages in universe to the desktop layer, the KDE packages to the KDE layer, the science programms perhaps to Edubuntu there won't be much left that many people might get interested in
<persia> ScottK, Last I heard they were just lists of packages.  Most of the discussion has involved alignment with seeds, but I think that's not enforced currently.
<LaserJock> geser: but I don't see why we can opt-in to that
<LaserJock> *can't
<LaserJock> since I seriously doubt we're gonna have exclusionary permissions
<geser> but you might want to have a "core" set of packages in the layer which are important for the layer where only regular contributors/developers should be able to upload and auxiliary programs you might want MOTUs to allow to upload, so you need two package sets again
 * Keybuk figures out where all the CPU is going while X is starting
<LaserJock> geser: right
<LaserJock> geser: so with the archive reorg can I set one package set permissions as current ~core-dev + edubuntu-dev and then another package set permissions as current ~ubuntu-dev?
<geser> LaserJock: I don't understand the outcome of the ArchiveReorg completely myself yet, only some fragments
<Keybuk> I was wondering why nautilus was eating lots of CPU
<Keybuk> turns out it's "fading in" the desktop background
<Keybuk> likewise gnome-panel chews CPU "sliding in" the panels
<ogra> Keybuk, well, thats the reason we have dual core cpus nowadays, one core is for X the other for processing :P
<persia> I didn't think arbitrary "core sets" were going to be considered.  I thought "restricted" package sets were only for things that were very special, like the kernel, or gcc.
<jdong> hahahaha
<jdong> I note that I never see panels "fading in" anyway because compiz bloody hangs the UI for 5 seconds on login anyway
<davmor2> ogra: I thought that was why we had gpus :P
<LaserJock> persia: that seems like a serious limitation
<geser> persia: with "core" I meant the core of e.g. KDE or Gnome, which is important for the layer to work
<ogra> davmor2, naaah, the gpu's are the replacement of the math co-processors :)
<davmor2> :)
<davmor2> Ah the geeks brain :)
<jdong> I thought they were the replacement spaceheater unit now that we don't have Netbursts.
<persia> geser, Right.  I think there won't be that.
<geser> LaserJock: as there won't probably be a group which consists of currently ~core-dev, it might get difficult to grant upload right to current core-devs and I don't know either if it will be possible to exclude the new ~ubuntu-dev from upload rights
<LaserJock> geser: right, which seems very uncool to me
<persia> LaserJock, Why?
<LaserJock> I didn't think the purpose of the archive reorganization was to promote current trust levels without asking
<LaserJock> I thought it was to make it easier to add relevent people
<persia> Well, it is, but the trick is to figure out what to do with all the existing people.
<LaserJock> I don't particularly see why the current trust levels need to change
<LaserJock> let the maintainers of the package sets figure out what permissions work for their project
<persia> Well, surely you need some people who can upload to nearly anything, if only to handle NBS type stuff.
<LaserJock> right
<LaserJock> I think the TB/CC could help moderate if big issues come up
<LaserJock> but for the most part, it's in the best interest of the project to allow as many uploaders as you're comfortable with
<LaserJock> we've already set up that kind of system with ~motu and ~core-dev
<persia> Right.  So, why wouldn't you be comfortable with anyone currently in ~ubuntu-dev?
<LaserJock> on stuff that's currently in Main I'm most *certainly* not comfortable with that
<persia> Well, for some classes of installations, but not others.
<persia> I see.  What about the stuff in main that hasn't been touched by a core-dev since Dapper?
<LaserJock> I barely trust half of MOTU with Universe, I sure as heck don't want them screwing around with core packages
<lupine_85> allo allo. Anyone seen the .list for libcaptury0 recently?
<LaserJock> persia: that should get fixed, but not by lowering the bar to uploading, IMO at least
<persia> Well, what's a "core package"?  Is nautilus a "core package"?  How about for Kubuntu users?
<lupine_85> 0.3.0+svn20070725-0ubuntu3
<LaserJock> persia: something roughly Main
<lupine_85> lupine@nick:/var/lib/dpkg/info$ file libcaptury0.list
<lupine_85> libcaptury0.list: ASCII HTML document text, with very long lines
<persia> LaserJock, And what about the many flavours of Ubuntu that aren't restricted to Main?
<LaserJock> Main is by definition the core set of packages Ubuntu has chosen to fully support
<lupine_85> kde-window-manager Depends: on this package and the broken .list prevents me from doing any upgrades
<LaserJock> if a flavour or project wants to have a set of package they fully support then they should go for it
<persia> Well, that was the original definition.  It's stretching it to say it's been true for the past few releases, which is the why behind Archive Reorganisation.
<LaserJock> but I reject that the origina definition is a bad one
<Riddell> lupine_85: no such problem here
<LaserJock> *original
<Riddell> lupine_85: try an apt-get install --reinstall libcaptury0
<lupine_85> Riddell: same version?
<persia> LaserJock, I don't claim it's bad, just that it hasn't matched practice in a while.
<LaserJock> persia: right, so perhaps we should look at practice
<lupine_85> I guess it could be filesystem corruption on my side
<LaserJock> I see the archive reorganization as an oppritunity to match practice better with *existing* philosophy
<Riddell> lupine_85: 0.3.0+svn20070725-0ubuntu3 is the latest, hasn't changed in a while
<LaserJock> not match philosophy with existing practice
<lupine_85> ok, thanks for looking
<lupine_85> I think I should fsck it :D
<persia> LaserJock, I think it's somewhere in-between: to define a philosophy that is meaningful for the current scale of activity, and a practice that matches that philosophy, where neither precisely matches the current environment.
<LaserJock> I suppose, yeah
<LaserJock> it just doesn't seem to be heading in a useful direction for me
<persia> Otherwise, I'd argue that every official flavour ought be in Main, which makes Main much bigger, and unverse much smaller.
<LaserJock> I think they should be
<persia> OK, and so all the developers for those flavours should be core-dev?
<LaserJock> core-dev + flavour specific devs
<persia> OK.  That works.
<LaserJock> if the flavour is fully supporting their project then it should be "Main"
<persia> Now, on top of that, let's add the idea that there are certain specialist developers in a given area (e.g. Java, Games, Mozilla), and let them upload those things.  Are you still good with that model?
<LaserJock> not so much
<persia> OK.  Why shouldn't the mozillateam be able to upload the mozilla packages?
<LaserJock> but I guess I could kinda roll with it
<persia> OK.
<LaserJock> I would prefer they be ubuntu-dev+
<LaserJock> i.e. your an ubuntu-dev who specializes in Mozilla
<persia> OK.  Let's say that someone who does Mozilla packaging can be allowed to upload the Mozilla packages, if they meet the requirements for being an Ubuntu Developer.
<persia> Are you comfortable with that?
<LaserJock> yeah, but they should me the requirements of a Core Dev for the core mozilla packages
<LaserJock> *meet
<persia> And we'll restrict those people to just their area (whatever it might be) until they either get inolved with other areas, or meet the requirements to upload to all of main.
<persia> Well, I'd trust the team to manage that.  Presumably there's enough social pressure within the team that it's not an issue.  It's not like most of these teams are that big.
<LaserJock> the requirements to uploading FF for instance should be quite a bit higher than generic extensions, say
<persia> Well, I'd leave that to the team.  If there are separable sets of stuff with different requirements, they can have two subteams.  Would that work for you?
<LaserJock> sure
<persia> And then we add per-package uploaders, who can upload a specific package or packages where they have a deep specialisation, assuming they meet the requirements of an Ubuntu Developer.  Still good?
<LaserJock> ish, yeah
<LaserJock> I generally think per-package uploaders should be a necessarily evil at best
<persia> Sure.
<persia> So, with all of that, every person who qualifies as an Ubuntu Developer has the ability to upload to any of the packages in which they have sufficient knowledge or involvement with a team.
<persia> So all the rest of the packages will probably only be uploaded by someone doing large-scale transisions, or similar work.
<LaserJock> sorta yeah
<persia> Given that most of those affect both Main and Universe, and given that we've already given special upload rights to everyone in ~ubuntu-dev, let's restrict that to core-dev.
<LaserJock> well, I would say "Ubuntu Developer" is a necessary but not sufficent condition
<persia> necessary but not sufficient for which?
<LaserJock> for package sets
<persia> Of course not.  As we've outlined above, they have to be core-dev, or involved with and accepted by a team, or have specialist knowledge in a package.
<LaserJock> right
<LaserJock> I'm onboard with that
<persia> So, the easiest way to restrict the large transition uploads, etc. to core-dev is to toss all the rest of the packages into Main.
<LaserJock> I don't exactly know why we'd want to limit that stuff to core-dev
<LaserJock> if it's not in a package set I would think MOTU should be fine
<persia> Well, nobody really cares for the packages, so they're just likely to bitrot unless well maintained in a sync source.
<persia> If someone cares, the TB can authorise a team, or someone can be a specialist.
<LaserJock> well, somebody *should* care about everything
<LaserJock> what matters is the level of care
<LaserJock> brb
<persia> Well, sure.  So, firstly, encourage the development of teams to care for things, and make sure the rest is maintained by those developers we trust the most.
<lupine_85> yep, that was it. multiply-claimed inodes right through /var/lib/dpkg
<soren> StevenK: Around yet?
<soren> I need an archive admin to move eucalyptus to multiverse.
<james_w> Keybuk: pm-utils
<james_w> Riddell: "bzr bd-do" if you still need it
<james_w> Riddell: /usr/share/doc/bzr-builddeb/ has a user manual that mentions this
<cjwatson> soren: done
 * soren hugs cjwatson 
<soren> cjwatson: Thanks!
<LaserJock> persia: ok, back
<persia> OK.  So we left off having granted Ubuntu Developers permission to upload to various package sets, and core-dev to upload to all of Main, and having dumped all the rest of the packages also into main.
<LaserJock> right
<persia> At this point, universe consists only of those packages that are in package sets with teams given special permissions to upload.
<persia> Since the special permissions are special, we may as well toss those in main also: it won't affect anything.
<persia> Now we have main, restricted, and multiverse, with complex upload permissions in main.
<slangasek> directhex: is anyone working on gmime2.2?  That seems to be the last bit pulling libmono-corlib1.0-cil onto the CDs (via tomboy)
<geser> and this won't make any package sets "better" than others
<persia> geser, Right.
<directhex> slangasek, it's not team maintained is it
<slangasek> directhex: nope
<LaserJock> persia: ok, I'm seeing some end to the tunnel now
<directhex> slangasek, i don't know of any contact with the maintainer
<persia> Now we rename "restricted" to "restricted-drivers" and we rename "multiverse" to "restricted-software" just to make the distinction more clear.
<slangasek> directhex: transitioning it is just switching to gmcs, right?
<persia> So, thats the emerging philosophy, as I understand it.
<directhex> slangasek, best-case, switching the build-dep from mono-* to mono-devel and forcing "csc" as a compiler
<LaserJock> persia: one thing I'm not certain on is that it would seem we're dramatically lowering the number of generalists
<LaserJock> if core-dev is now the "catch-all" team
<jetsaredim> is it possible to implement link handling in desktop notifications (meaning the text of a notification has a link in it - convert to a clickable object which opens a window in browser)
 * slangasek nods to directhex, and queues up giving that a whack later
<persia> Indeed.  So to address that, we look to the other team of generalists we have, MOTU.  Since universe is gone, MOTU doesn't have anything to do.
<persia> So those of them that are interested would become core-dev to help out.
<LaserJock> ok, but that then moves them into the "can upload anything" group
<LaserJock> which affects the package sets
<persia> But since there really isn't a core anymore, we rename the core-dev team to "Generalists" or something.
<cjwatson> we'll need to go through MOTU case by case in the process
<cjwatson> I believe that this is even explicitly recognised in the spec
 * ScottK thinks it is.
<LaserJock> cjwatson: so like a massive core-dev app process :-)
<persia> Also, because we've added so many additional generalists, we reserve some special packages (like the kernel or gcc) to be restricted, so that only specialists can upload them.
<cjwatson> sort of, but recognising in the process that many of MOTU in fact already meet the requirements despite not having applied, and many of the rest only care about some particular area
<directhex> slangasek, poot, it's not in svn - but the package was RFA'd & meebey can upload
<LaserJock> cjwatson: who recognises that?
<cjwatson> which leaves us only with the problem of dealing with the people who (a) don't yet meet core-dev requirements and (b) can't be adequately trained in a few months or so
<persia> cjwatson, More a) don't meet requirements, b) can't be trained in time, and c) don't fit better into one of the more specialised teams.
<cjwatson> LaserJock: I was speaking only for myself, but the decision would be made by the TB. Note that I did not say "all"
<cjwatson> persia: I thought I'd covered that in my previous utterance, but if you want to be explicit, certainly
<LaserJock> but we're still talking about a pretty significant bump in trust level
<LaserJock> I'm think in terms for protecting package sets from the generalists
<LaserJock> s/for/of/
<persia> Why, if the TB believes that those generalists would be suitable for core-dev did they get around to applying?
<meebey> slangasek: plan was to get package maintained in pkg-gnome, but they didn't reply yet (since about 3 weeks)
<LaserJock> persia: is that for me?
<persia> LaserJock, Yes.  Sorry.
<LaserJock> persia: because they're obviously not suitable
<cjwatson> LaserJock: are we really? I'm actually not convinced. MOTU is already root on most Ubuntu users' systems; nearly everyone installs something from universe.
<persia> LaserJock, Hrm?  If the TB indicates they are suitable, wouldn't they be suitable?
<slangasek> meebey: ah
<LaserJock> persia: well, not in my opinion
<LaserJock> but whatever
<cjwatson> and we already have lots of ways to keep track of what people are doing; if people mess with something that other people actually care about, then they will be noticed
<LaserJock> I don't think the TB is currently capable of making a sound decision on that
<LaserJock> they've already delegated away most of these decisions
<LaserJock> I don't see how they're going to be able to go through ~ 100 applications in a timely manner without cutting corners
<LaserJock> there will also be a tremendous social pressure to just let people in
 * cjwatson feels under no such pressure
<persia> Well, sure, but that's a transition pain.
<LaserJock> so no, I personally don't think the TB can just find people suitable
<meebey> slangasek: as I am no C hacker, I don't want to take full maintainer ship of it
<persia> I don't think the TB will just "find people suitable", but rather that they would select those people who they would find suitable if they applied for core-dev.
<slangasek> meebey: ah, don't look at me, I'm only interested in getting the transition done :)
<ajmitch> persia: is all this written down somewhere so I can catch up?
<LaserJock> ok, but why aren't they already core devs?
<LaserJock> people generally apply for things they are suitable for
<persia> ajmitch, The spec has an outline, but you'll have to check the backlog for the socratic presentation.
<meebey> slangasek: hehe too bad, ok :)
<directhex> meebey, isn't slomo our pkg-gnome guy?
<meebey> directhex: he is? shoot him! :-P
<LaserJock> the assumption seems to be that most MOTU are ready for core-dev, they just haven't applied for whatever reason
<ajmitch> persia: just trying to grasp what happens to exsiting MOTUs & core devs
<LaserJock> which seems to be counter to Ubuntu's history
<meebey> directhex: he didn't reply either so...
<meebey> directhex: I dont think he has interest
<persia> LaserJock, Remember, we pulled in all the flavours, so suddenly all the flavour developers need to be core-dev.  Speaking for myself, none of the flavours on which I work are in main.
<geser> ajmitch: it's not really decided yet besides that the groups should get merged somehow
<cjwatson> I think the number is 66, not 100, BTW
<LaserJock> persia: no, they *shouldn't* be core-devs
<cjwatson> LaserJock: I've certainly seen plenty of instances where people needed to be encouraged to apply
<LaserJock> cjwatson: right, but you're assuming that thats the case with the majority of current MOTUs, right?
<LaserJock> or do you plan on tossing out most?
<cjwatson> I'm looking through the names and trying to work out who would scare me if they could upload to everything rather than just to things that lots of Ubuntu users use even though they aren't in main
<cjwatson> there seems to be an implicit assumption going on here that universe is somehow safe
<cjwatson> it is not
<RAOF> Some of this will be dealt with by marking some groups of packages specialist-only, right?  It's not quite the same as a strict MOTU->core-dev transition.
<LaserJock> safe?
<cjwatson> the ability to upload to directly universe is already a very high trust level
<cjwatson> directly to
<LaserJock> ah, I see what you mean
 * directhex uploads directly to RAOF 
<cjwatson> and therefore the relevant question is whether I am scared that people will suddenly decide to break glibc or whatever
<LaserJock> well, I think it is and frankly I think it's mostly given out all to quicly
<persia> RAOF, I believe that will only be a very small set of packages, where even most current core-dev oughtn't be playing randomly.
<ajmitch> persia: like the kernel?
<cjwatson> in the full knowledge that people will notice (assuming that the package actually matters)
<persia> ajmitch, That's my expectation.
<cjwatson> persia: I don't think the question of exactly how small has really been explored very much
<LaserJock> cjwatson: I'd be seriously afraid of any packages I care about
<cjwatson> LaserJock: why wouldn't you notice if somebody broke them?
<calc> or randomly firing off OOo builds on cd release week ;-)
<LaserJock> cjwatson: I don't want the broke in the first place!
<ajmitch> calc: well, if they're brave enough to get that source package uploaded... :)
<cjwatson> I care about stuff in universe as well as in main
<calc> anyone who wants to fix OOo bugs be my guest, just need to coordinate uploads
<cjwatson> I am not scared about MOTU breaking it
<LaserJock> you aren't?
<cjwatson> nope
<LaserJock> I am for sure
<cjwatson> I think you're too paranoid, then :)
<pitti> with our current TIL practice I'm not really scared either, TBH
<cjwatson> occasionally I might have to go and reeducate somebody
<cjwatson> but it's pretty rare
<LaserJock> ok, so say I'm paranoid
<pitti> I don't ever recommend anyone for MOTU whom I don't trust to ask if he encounters something unknown
<LaserJock> is there a mechanism in the archive reorg where paranoia will be OK?
<cjwatson> we have always said that Ubuntu will be about team-maintainership
<pitti> LaserJock: I'm not saying that you are wrong, just my personal feeling
<LaserJock> that is, can I lock out "core-dev" from a project?
<LaserJock> pitti: sure, I know
<cjwatson> if anything, we have gone too far in the direction of individualism
<LaserJock> I don't trust probably 50% of MOTU as it is
<geser> LaserJock: why didn't you comment on MOTU applications if you think they aren't ready yet?
<LaserJock> making them core dev scares me a lot
<cjwatson> LaserJock: the technical capability will be there, but we strongly discourage people taking a maintainer lock
<LaserJock> geser: because it's largely pointless
<cjwatson> LaserJock: if you said that in your own core-dev application, the TB would be thinking quite hard about whether to say yes, frankly
<pitti> frankly, I don't believe that the current set of MOTUs just counts down the time when they can jump and upload a new glibc
<persia> LaserJock, Why?  We do reject some applications, if there is controversy, or delay them for long enough that we feel comfortable.
<LaserJock> pitti: I don't either, for sure
<cjwatson> because one of the things we typically test is whether people are willing and able to work as part of a team
<LaserJock> cjwatson: teams are great!
<pitti> if they were, they had applied already, presumably
<cjwatson> ... to work as part of the Ubuntu development team
<LaserJock> I just want to be able to trust my team to work as a team and not break things too much
<cjwatson> not just the team of people they like
<Amaranth> pitti: I dunno, I'm getting excited about uploading a new kernel, glibc, firefox, and OOo
<Amaranth> :P
<geser> Amaranth: don't forget dash
<pitti> Amaranth: deal! you fix it all, become TIL, and receive all the blame/bugs :)
<RAOF> Amaranth: I think you missed out gcc there.
<cjwatson> LaserJock: I'm very worried by the fact that you say you regard some incoming MOTU as inadequate, but intentionally fail to comment on their applications
<Adri2000> slangasek: I think you're the best person to review/ack the samba sru, and review/upload the debdiff. could you do that?
<cjwatson> I think it is the responsibility of team members to speak up when they see problems
<Amaranth> RAOF: I'll put a virus in gcc that puts it into new gccs compiled with that gcc
<LaserJock> cjwatson: well, most of the time these days I've never even heard of the people
<LaserJock> cjwatson: but on occasions when people have brought up issues they're generally told to stop being mean
<LaserJock> gives much less motivation to say something if you're just gonna get flamed for it
<cjwatson> and from what I see the new MOTU approval process seems to be largely consensus-driven; I can't remember the last time I saw a successful application that included negative comments, and I know there are some failed applications, which suggests that there are applications that fail due to negative comments
<cjwatson> LaserJock: I'd very much like to see a reference for that remark
<cjwatson> examples
<cjwatson> because that is a critical failure
<LaserJock> cjwatson: it's consensus of those who speak up, yes
<cjwatson> those who choose not to speak up have abrogated some of their moral right to criticise the process, IMO
<persia> cjwatson, There was actually a recent application that contained a couple semi-negative comments and was approved, but the comments were all addressed to the commentor's satisfaction before approval.
<cjwatson> persia: right, I mean unresolved negative comments
<LaserJock> cjwatson: I realize that. It's certainly not my desire to just hold my tongue all the time
<LaserJock> I'd rather not drag names around
<cjwatson> in any case, I did already bring up the "there are some members of MOTU whom I'd rather not see in core-dev" issue with Mark et al
<cjwatson> it was acknowledged and we will explicitly address it as part of any implementation of the reorg
<LaserJock> I mean, I thought we had the MOTU/Core Dev split for a reason
<slangasek> Adri2000: you might ask around whether anyone in the server team could do the upload?  If I do the upload, then another member of the SRU team should approve the SRU itself
<cjwatson> we had it for reasons that made sense four years ago
<LaserJock> if we're going to abandon that and go more Debian-style then we can talk about that I guess
<cjwatson> I honestly do not think that those reasons make direct sense any more
<LaserJock> but I haven't seen a lot of discussion on -devel about that
<cjwatson> god, I've been discussing this until I'm blue in the face everywhere I can find
<cjwatson> I'm not going to take criticism about it being under-discussed :P
<cjwatson> I feel like I never stop talking about it
<LaserJock> well, no offence, but maybe you've been talking in the wrong direction
<Amaranth> Whatever the solution is I just want it to allow me to do compiz uploads
<cjwatson> I am stepping back from this conversation because if I do not I will violate the code of conduct
<directhex> let's swap recipes instead. how'd you like some bacon cookies, cjwatson?
<LaserJock> I haven't seen this specific issue of bumping developer permissions on -devel ever
<Amaranth> directhex: I'll trade you for my cheese cookies
<LaserJock> perhaps it would mean less repeating if we could hash it on more on -devel
<LaserJock> cjwatson: that's fine dude, I've learned a lot about the plan through the conversation, and I *do* trust you
<LaserJock> so I'll let you get back to more important work
<RAOF> Amaranth, directhex: You should breed those cookies.  Cheese and bacon?  MMmmm.
<Adri2000> slangasek: oh ok, needs two different people... then, mathiaz? could you sponsor my debdiff for the samba sru?
<directhex> RAOF, i don't know how well the cheese would go with the choc chip
<cjwatson> LaserJock: it has at least been mentioned in TB meeting minutes
<cjwatson> which received zero (0) comments
<Laney> heh
<Laney> oops
<slangasek> cjwatson: I guess there's no MIR yet for grub2 (for grub-common); shall I go ahead and do that, or do you have some hidden state on that question that I should pull in?
<cjwatson> slangasek: no hidden state, no; please do
<cjwatson> LaserJock: I'm not fishing for compliments, and I do want to hear about problems. I really think this is something I've already made an effort to take account of, though, and I'm not sure I'm comfortable with the tone of a conversation that seems to essentially be "half my colleagues suck"
<LaserJock> cjwatson: right, I see what you're saying for sure
<cjwatson> it just seems pretty defeatist, and to fail to recognise that if that is the case then we should be doing something about it entirely independently of the reorg
<cjwatson> because if half of MOTU sucks, then those sucky people *already* have a very high privilege level
<LaserJock> yep
<cjwatson> one thing I have thought of is that maybe a reorg gives us the opportunity/excuse/whatever to reevaluate those people who have been in MOTU for years but aren't core-dev
<cjwatson> because originally MOTU was conceived at least in part as an on-ramp
<LaserJock> yeah, I thought about that too
<jcastro> Come on LaserJock! Half-full bro! half full.
<cjwatson> I don't especially want to have a rah-rah don't we all rock conversation either :)
<LaserJock> jcastro: well, if there's a big hole in the bottom it's kinda hard ;-)
<directhex> jcastro, the glass is not half full. or half-empty. the glass is in need of a top-up
<LaserJock> I've been told for the last couple years that we need to lower the barrier to entry and not be "mean" to people by asking tough questions of applicants
<cjwatson> if nothing else I suspect that there is at least some expiry that can be done
<LaserJock> I guess I let that get the better of me in the conversation, which isn't good
<directhex> LaserJock, adopt the debian NM process!
<LaserJock> I'd rather not
<cjwatson> there is a problem with lots of Ubuntu being in some ways a reaction to problems in Debian
<cjwatson> we fail to pick up the good stuff sometimes
<cjwatson> Debian NM is an unnecessarily protracted process, and in particular it is slow even for good people
<LaserJock> I guess my general feeling is that it's good to have the applicant prove themselves rather than everybody else have to prove why not
<directhex> on a related note, where is cjwatson based? i need a key signed to start debian NM process
<LaserJock> but I guess I can see where the philosophy isn't exactly the best way to grow a developer community
<cjwatson> the questions asked in Debian NM are occasionally way over the top and things that I don't know offhand after eight years of being a Debian developer, so in some ways they just test your ability to look things up
<LaserJock> the problem for me is rarely the technical skills
<cjwatson> but on the other hand, the fact that the process is seen as difficult means that there is more kudos attached to completing it, and it means that people really try hard
<LaserJock> but I've seen people become MOTU who are quite immature and don't seem to understand when to ask and when to "just do it"
<LaserJock> we've created quite a bit of "policing" such as motu-release and motu-sru because we don't trust each other
<cjwatson> the people who do well in their Debian application processes are those who spend the NM delay time sitting there building up expertise and bombarding people with good patches until other developers are begging for them to be let in
<cjwatson> directhex: Cambridge
<directhex> oh, that Other place
<cjwatson> you should've asked, I drove by Oxford last weekend ;)
<directhex> cjwatson, reckon i need more than one signature?
<cjwatson> being in the web of trust at all was fine last I checked
<Mithrandir> cjwatson: if you manage to get to Cam, getting ten sigs should be a SMOBB
<Mithrandir> uhm
<ajmitch> directhex: your bias is showing :)
<Mithrandir> s/cjwatson/directhex/
<directhex> hm, yes, i think i can rustle up a second DD in oxford
<cjwatson> LaserJock: I agree regarding policing; excess requiring of signoff for things is something that generally bothers me. OTOH I also have a bias towards actually getting releases out so meh :)
<LaserJock> cjwatson: +1 ;-)
<directhex> ajmitch, bias?
<cjwatson> LaserJock: although speaking of merging things, the members of motu-release and motu-sru are pretty experienced guys. Why do we have separate ubuntu- vs. motu- teams there?
<cjwatson> or, maybe more relevantly, why do we need separate teams?
<LaserJock> cjwatson: Main, vs Universe
<LaserJock> I tried to get them into one at one point
<cjwatson> that's an answer for how they arose, but not an answer as to why they're needed
<kirkland> so does FF go into effect at midnight UTC ?
<persia> kirkland, Yes.  148 minutes.
<mvo> ha! plenty of time
<cjwatson> the separation there means that motu-release don't get the opportunity to learn from the "main" release team, etc.
<LaserJock> cjwatson: because having non-Core Devs approving Core Dev actions seems weird?
<pitti> didn't it say "slangasek's morning"?
<kirkland> begin haphazard commits now.
<kirkland> :-)
<kirkland> persia: thanks.
<LaserJock> cjwatson: I totally agree
 * pitti pedals faster
<Amaranth> mvo: Quick, upload gnome-do and enable docky :)
<LaserJock> cjwatson: they also have to have different task lists, etc.
<cjwatson> LaserJock: motu-release and motu-sru aren't enforced to be core devs, but those are teams of people whom I would expect to be uncontroversial for core-dev if they aren't already
<RAOF> Amaranth: Too slow!  It's already in!
<cjwatson> LaserJock: and we could deal with different task lists by launchpad's component filtering for bug queries, almost entirely
<Amaranth> RAOF: I meant by default :P
<RAOF> Amaranth: Now that _would_ be desktop-eXperience :P
<LaserJock> cjwatson: well .... I personally don't know that I'd recommend them all for Core Dev, but maybe they'd get through OK
<cjwatson> at least I would expect them to be able to learn pretty quickly given incentive
<ajmitch> cjwatson: you mentioned expiry - wouldn't the usual LP team expiry work in most cases?
<persia> Actually, many if both teams are often also core-dev.
<cjwatson> ajmitch: to some extent. It tests that people are reading e-mail, but not that they're actually still doing anything
<cjwatson> IOW it's an "are you still on the Internet?" policy
 * Amaranth wasn't reading email :(
<savvas> mvo: could you take a look at the first draft for the end-of-life page your requested? https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/319146 http://launchpadlibrarian.net/22419716/end-of-life_document.txt
<ubottu> Ubuntu bug 319146 in update-manager "When a release reaches End-of-Life, update manager should show EoL status and provide a link with working procedures and more information." [Undecided,Confirmed]
<LaserJock> cjwatson: when I was working on the QA team I pushed for essentially making -sru one team
<savvas> *you
<cjwatson> which is better than nothing, but doesn't deal with people who just haven't uploaded anything for three years
<cjwatson> LaserJock: I think I'd like to reopen that discussion
 * Amaranth also hasn't uploaded anything in a long time
<LaserJock> cjwatson: awesome, I think it makes things so much easier
<ajmitch> true, it's only a 1-week window
<cjwatson> Amaranth: because compiz is in main, right? :)
<Amaranth> cjwatson: Right
<Amaranth> Everything I've ever touched moved to main
<cjwatson> Amaranth: did you ever apply for core-dev?
<cjwatson> I'm curious
<Amaranth> No, never had enough package uploads in universe to think I'd get it
 * LaserJock feels a "told you so" coming on ;-)
<slytherin> Hi, next time someone refreshes ubuntu-meta package, can you please remove libpt-1.10.10-plugins-* packages? They are not used by ekiga anymore.
<Amaranth> and now I'm not even MOTU
<mvo> Amaranth: you don't have to, you just commit to the compiz bzr and I sposnor it ;)
<cjwatson> I don't say I told you so when it's obvious ;-)
<cjwatson> slytherin: somebody needs to change the seeds
<cjwatson> we don't edit the lists in ubuntu-meta by hand
<slytherin> cjwatson: Should I log bug then so that it will be on the record?
<cjwatson> slytherin: yeah, stick a bug on ubuntu-meta please
<Amaranth> mvo: That doesn't really work when we're going git snapshots though, half the work is making the snapshot
<Amaranth> Sometimes almost all the work is making the git snapshots, compiz fails distcheck a lot :P
<mvo> Amaranth: oh yes
<slytherin> cjwatson: done. bug 331256
<ubottu> Launchpad bug 331256 in ubuntu-meta "Please remove libpt-1.10.10-plugins-* from ubuntu-desktop dependencies" [Undecided,New] https://launchpad.net/bugs/331256
<cjwatson> ta
<slangasek> LaserJock: hrm, motu-sru and motu-release as "policing" - would you argue that ubuntu-sru and ubuntu-release are also bad?
<slangasek> cjwatson: ... LP has component filtering for bug queries?  Wherewhere?
<cjwatson> slangasek: under advanced
<slangasek> huh
<LaserJock> slangasek: mostly
<cjwatson> comes out as &field.component= etc. I think
<LaserJock> I certainly think a release team is important
<cjwatson> it's in the "Series-specific" section of the advanced search bit
<LaserJock> I'd rather we didn't need SRU policing
<cjwatson> SRUs are an example of where we've been screwed by inadequate care taken
<cjwatson> specifically and in very very high-profile ways
<LaserJock> yep
<LaserJock> I would expect a developer to be responsible for it though
<cjwatson> and in at least one case, it wasn't even because the uploader did anything obviously wrong
<slangasek> slytherin: why does ekiga not need the plugins anymore?  What replaced this functionality?
<LaserJock> a developer should be able to  figure out what is and what is not SRU worthy though
<cjwatson> we've analysed many of the cases where this went wrong, and I don't think it typically comes out to be that simple
<LaserJock> exactly
<cjwatson> the particularly difficult bit is that "make this obviously correct one-line change" is actually not safe
<cjwatson> because simply rebuilding the package *at all* can create bugs
<LaserJock> yep
<cjwatson> and I don't think this is something that's intuitive to most developers
<LaserJock> but the SRU teams are mostly policing, i.e. "is the developer following the SRU Policy?"
<slangasek> LaserJock: I think that too much expects all developers to be interchangeable, which they aren't; having an extra set of eyeballs on SRU changes is valuable per se, and it's also valuable to have someone with an SRU "big picture" perspective nvolved
<LaserJock> not necessarily taking responsibility for and checking for complete correctness of SRUs
<slangasek> LaserJock: er?
<cjwatson> ubuntu-sru generally does code review, IME ...
<slangasek> yes, this is why I hate kernel SRUs. :)
<LaserJock> at least with MOTU SRU it's generally just been "is this a properly formated SRU request?"
<Amaranth> mvo: Hopefully we never do another git snapshot though, just poke the compiz guys to do a release :)
<persia> That's not what the team is supposed to do.
<cjwatson> I think that's another case for merging the teams, then, provided that we take the opportunity to merge the practices too :)
<cjwatson> separate teams do tend to create divergence like that
<pochu> LaserJock: really? I'm sure I've done some SRUs without needed to do all the paperwork
<pochu> just a debdiff
<slangasek> cjwatson: knowing now that I'm able to filter LP bug queries will certainly help; but I don't think we have an equivalent way to filter bug mails
<cjwatson> slangasek: we certainly no
<cjwatson> do
<slangasek> how?
<cjwatson> X-Launchpad-Bug:.*component=
<slangasek> hmm
<slangasek> ok
<slangasek> (what does that do if there's more than one Ubuntu bug task, on packages in different components?)
<LaserJock> you might also consider just having the non-Core Dev MOTU SRU people just agree to not take on Main SRUs
<LaserJock> or are you concerned more about getting Universe SRUs in your mailbox
<slangasek> yes
<LaserJock> ah
<LaserJock> then maybe cjwatson's filtering might work a lot better
<pwnguin> is it common for a source package to be a tarball?
<pwnguin> let me rephrase
<pwnguin> what's going on with coreutils?
 * slangasek hopes another rephrasing is pending
<pwnguin> used apt to get the source code, and there's a tarball instead of an unpacked source dir
<slangasek> ah
<pochu> tarball-in-tarball?
<pwnguin> i guess
<slangasek> that's not common; I consider it actively discouraged
<pochu> not common, but not forbidden
<pochu> discouraged++ :)
<persia> actually, I kinda like it when upstream distributes a .zip file.
<LaserJock> I've used it for that before
<slangasek> I can't fathom why the coreutils 6.10 tarball is the way it is.  The 6.12 one is not
<Skiessi> is libsamplerate staying at 0.1.4 for jaunty?
<maxb> I can see it being a matter of preference, but why zip-in-tarball rather than uscan --repack ?
<slangasek> so the question goes away with a merge
<pwnguin> ok. i just wanted to browse the source code to uniq and ran across that oddity
<cjwatson> maxb: some people prefer to ship the original source bit-for-bit
<Skiessi> http://tinyurl.com/aglwp4 this graph says there's a lot of awesomeness in the newer versions
<cjwatson> it's really a dpkg anomaly that it can't cope with more original source formats
<cjwatson> one that's being fixed at least for tar.bz2 and the like although I don't know about zip
<fta> anyone working on fixing the bad regression introduced recently in libsdl1.2debian breaking sdl apps using opengl?
<cjwatson> tarball-in-tarball was popular at one point due to a particular patch system
<maxb> dbs
<cjwatson> indeed
<cjwatson> and I think cdbs has a tarball.mk
<cjwatson> slangasek: you get multiple X-Launchpad-Bug: headers, one per task
<slangasek> cjwatson: ah, optimal :)
<cjwatson> (conveniently, the last message in =ubuntu/mybugs is an example of this)
<slangasek> directhex, meebey: hmm, what's this?: Failure adding assembly gmime-sharp.dll to the cache: Strong name cannot be verified for delay-signed assembly
<meebey> slangasek: ohoh, an outstanding issue
<meebey> slangasek: IIRC upstream lost the signing key
<slangasek> hmm
<meebey> slangasek: and mono enforces the signature now :(
<meebey> slangasek: good news is that gmime 2.4 ships a signing key now
<slangasek> so we need to upgrade to gmime 2.4 first?
<meebey> slangasek: bad news is, that changing the key of gmime 2.2 would mean an ABI breakage
<ajmitch> they lost the key?
<meebey> yes... *cough*
<directhex> ajmitch, awesomez!
<ajmitch> directhex: quite
<meebey> it was never in the tarball and nobody noticed because mono didn't care
<soren> Any archive admins around to review xmlbeans, please?
<slangasek> meebey: tomboy and beagle are the only reverse-deps, so I don't think ABI breakage should be a big deal... except that I don't have a clue how to manage the actual ABI changing of a mono lib
<meebey> slangasek: rename package to 2.2a-cil? :)
<slangasek> meebey: that's all?
<meebey> slangasek: gmime itself had an ABI breakage too (for a different reason) :-P
<directhex> meebey, is it in the policy doc?
<slangasek> meebey: or should I just track gmime 2.4?
<meebey> slangasek: sure that nobody else uses gmime?
<meebey> slangasek: the C API changed alot I heard, that reason the maintainer went away :(
<slangasek> meebey: those are the only cil reverse-deps.  I'll check the C stuff too
<meebey> slangasek: so for 2.4 I think that will take a while till the apps are ported
<directhex> short version: computers suck
<meebey> slangasek: 2.4 should be packaged as a new source package IMHO
<meebey> slangasek: I can't tell how much porting tomboy and beagle need
<meebey> slangasek: you could try that route, only port the C# apps for now
<meebey> slangasek: that would mean we found the missing C maintainer, yay! :-P
<slangasek> erm
<meebey> slangasek: deal, I help you porting the C# apps, and you care for the C part (no transition needed for now, just care for the C lib package)
<meebey> slangasek: I am partly familar with the C# API, our company uses it
<slangasek> meebey: "care for"?
<slangasek> meebey: if you mean "check it over for this one upload"...
<meebey> slangasek: nah, I am teh C noob, I don't (actually should not) touch that C lib part
<meebey> slangasek: "care for" as in being maintainer for the C package part (libgmimeX + libgmime-dev) :)
<slangasek> meebey: pass, sorry
<meebey> slangasek: or find someone in debian who would like to do that :)
<meebey> slangasek: I tried in pkg-gnome, but nobody seems to be interested
<meebey> slangasek: for the reference: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513428
<ubottu> Debian bug 513428 in wnpp "RFA: gmime2.2 -- MIME library - development files" [Normal,Open]
<meebey> nice botty
<slangasek> meebey: ok, there are a number of other C reverse-deps; I would rather not deal with the scope creep of transitioning those packages at the same time.  Is the key something I can grab from gmime2.4 upstream?
<meebey> slangasek: yes its in the released 2.4 tarball
 * calc will finally be converting his wife over to ubuntu today :)
<calc> along with vmware unity for adobe cs4
<NCommander> calc, yay!
<calc> if all goes well on the laptop conversion i will be converting her desktop as well
<directhex> yay for whomever has the archive admin hat
<cjwatson> tain't me, I'm desperately uploading stuff
<directhex> cjwatson, before FF?
<cjwatson> aye
 * directhex hunts for his stopwatch
<mathiaz> slangasek: openldap 2.4.14-0ubuntu1 uploaded to jaunty
<slangasek> @yay
<cjwatson> slangasek: can I have a FF exception for gparted 0.4.2+ (ext4 support)? I'm not going to get to the sponsorship before midnight
<directhex> i'm tired; i'd rather get an FFe for a package produced when not comatose than write a bad debdiff. motu-release are already up to speed on my plans & progress
<slangasek> cjwatson: yes
<cjwatson> rock, thanks
<mathiaz> slangasek: I've used a loomified bzr branch to handle the ubuntu pkg. It's based on debian svn repository and looks like this: http://paste.ubuntu.com/119862/
<mathiaz> slangasek: how should I send relevant patches to debian?
<directhex> i've achieved most of my headline goals for jaunty - now it's just tidying up before release
<mathiaz> slangasek: should I try to push the loomified bzr branch somewhere and you can look at it?
<slangasek> mathiaz: I'm the only one on that team who has a preference for bzr, so that makes me a bottleneck; but it's better than nothing if you don't have time to push individual patches to the mailing listn
<mathiaz> slangasek: well - it's rather easy to push patches to the mailing list since I've used looms
#ubuntu-devel 2009-02-19
<cjwatson> RIGHT
<slangasek> mathiaz: hmmm where can I read about looms?
<cjwatson> oh, heh, I think I was 18 seconds late with the kickseed sync
 * cjwatson blames his local clock
<TheMuso> lol'
<cjwatson> ... which has yet to hit midnight
<slangasek> let's blame Keybuk
<soren> hahah!
<mathiaz> slangasek: http://www.flamingspork.com/blog/2008/02/22/bzr-loom-a-bzr-plugin-with-quilt-like-functionality/
<mathiaz> slangasek: https://edge.launchpad.net/bzr-loom/
<mathiaz> slangasek: looms is quilt for bzr
<slangasek> yes, I gathered that, I was interested in getting ahold of the details :-)
<PhillipA> hello, does anyone have blender and NetworkManager running on their ubuntu so I can confirm a bug? thanks
<PhillipA> non-ati video card preferred
<soren> Who can change build priorities?
<directhex> soren, an archive admin!
<Laney> buildd admin, rather
<soren> Thinking about it some more, I'm not sure it'll make any difference.
<Laney> https://launchpad.net/~launchpad-buildd-admins/+members
<savvas> hm... mount command's manpage should be updated for -t ext4 type
<slangasek> mathiaz: ah, hrm, if you're going to fire off all the patches in a batch, bug reports would probably be better
<calc> update manager autolaunch, ugh, now i just need to go uninstall it entirely since apparently the notification icon wasn't annoying enough already
 * calc had thought he had somehow hit the button by accident until he read the bug report that this is a new "feature"
<directhex> calc, how about xpsp2-style "your pc will reboot in 15 mins for an update"? :)
<calc> directhex: heh that will be when everyone switches to fedora
<calc> directhex: that is one of the reasons I refuse to use XP for anything more than bug testing
<calc> though there is a way to disable it, that is well hidden, it is the most evil pos
<calc> the idea about getting a stock gnome setup though may have more users than originally intended depending on how far these feature changes go
<calc> iirc it was thought it would only be wanted by gnome devs
 * calc just used gconf-editor and disabled the autolaunch
<StevenK> calc: At least the update icon is unobtrusive
<calc> StevenK: yea the new feature is that update notifier runs on your desktop every 2 days
<StevenK> Eek
<calc> so really intrusive
<StevenK> Bad
<calc> yea
<calc> bug 331054, its considered a new 'feature'
<ubottu> Launchpad bug 331054 in update-notifier "Do not launch in background" [Undecided,Invalid] https://launchpad.net/bugs/331054
 * calc hopes the DX team doesn't manage to run off all the Ubuntu users
<calc> it won't take too much to reach windows annoyance level which will drive users elsewhere
<TheMuso> That is a shocking feature.
<calc> at least the users who don't know how to fix it on their machines, anyway
<TheMuso> That will get users in more trouble than it will help them IMO
<TheMuso> I won't want to have to keep turning that off when I create a fres install/user.
<TheMuso> fresh
<calc> TheMuso: feel free to bring it up on one of the mailing lists for discussion, apparently it was closed as invalid, since they want it to work that way
<TheMuso> Hrm.
<calc> though it looks like this might be a feature request from sabdfl after looking at the bug report :-\
 * TheMuso sighs.
<StevenK> The bug did say auto-updating isn't going to be the default ...
<calc> StevenK: auto updating isn't default, but popping up to show you need to update will be
<StevenK> Ah
 * StevenK grumbles
<calc> so every 2 days you get this dumb thing launched
<calc> which i don't even use, i only don't remove it since it is depended on by ubuntu-desktop
<slangasek> does it launch every two days, or only when there are pending updates?
<calc> every 2 days with pending updates, so for people tracking development releases, every 2 days :)
<calc> regardless popping up a large app window is pretty annoying
<calc> i guess they considered the app icon showing up wasn't sufficient annoying so they wanted to make it worse
<calc> iirc it shows up red or something like that when you need to update
 * TheMuso will have to test it, and if it behaves badly with accessibility, will have to turn it off for accessibility use cases.
<calc> things popping up the user didn't explicitly ask for isn't particularly good ui design (imho), it causes confusion
<TheMuso> on the live CD/installs etc.
<StevenK> slangasek: FF is, or is not in effect yet?
<slangasek> is
<StevenK> Damn
<StevenK> So I need FFe's for all of the stuff I just cleared out of NEW?
<FrankT-Qc> Hi ! There's been an important security update in vsftpd and I was wondering to whom should I raise a flag so that it makes it to the repos as fast as possible ??? Any Idea ?
<StevenK> slangasek: Just worried that I should be processing NEW and syncs differently
<ScottK> StevenK: From a motu-release perspective we have considered stuff that got uploaded prior to FF as OK even if it got processed out of new later.
<StevenK> Right, so NEW is okay, but syncs need closer checking
<ScottK> Even there I'd say if they were ack'ed and approved, pre-FF it's OK.
<ScottK> Unless someone is starting a new ghc6 transition or something
<ScottK> Someone actually asked about updating ghc6 today.
<ScottK> We all said NO.
<StevenK> I've only done binary NEW, so ...
<savvas> FrankT-Qc: you could try #ubuntu-hardened - other than that, I don't know :) you could also file a bug report and check the box below the report to make it a "security risk" (or something like that) at http://bugs.launchpad.net/ubuntu/+filebug
<FrankT-Qc> savvas : thanks
<ScottK> slangasek: If we're past FF, then I think a "Hey, stop now" mail would be in order.  I havene't seen one yet.
<StevenK> Indeed
<slangasek> ScottK: will send it out in a couple of hours, unless you want to beat me to it
 * ScottK has to deal with kids for a few more hours, so probably not.
<ScottK> The good news is that means I don't have to stay up late tonight to finish something.  I can give myself an FFe on the weekend as easily as today.
<slangasek> :-)
<ScottK> slangasek: I changed /topic in #ubuntu-motu.  It's a start.
<StevenK> $topic =~ s/open/FF (ish)/;  # ?
<ScottK> jcastro: Just read your blog on the tool for opening upstream tasks.
<ScottK> I guess I don't understand what good a blank upstream task does?
<calc> ScottK: well it would make it clear the bug is an upstream issue versus something that needs fixing just in ubuntu
<maxb> I'm rather getting the impression that the new notifier stuff was landed to get in before FF, not because it was ready :-(
<ScottK> maxb: You sound suprised.
<maxb> not surprised :-)
<ScottK> calc: I guess, it just seems like a lot of effort for little gain unless you are actually going to report the bug upstream and then link it.
 * maxb goes on bug-filing spree
<jcastro> ScottK: unfortunately the talk I gave at UDS wasn't recorded but basically, people who triage do a good job at linking once they find that it's an upstream bug
<jcastro> ScottK: so the idea is to get developers opening more open tasks so that triagers can link them
<ScottK> jcastro: I see.  I guess that makes sense.
<ScottK> Kind of.
<jcastro> basically, if developers can grow the pile of possible bugs, it's relatively easy to grind through them and open the bugs upstream
<ScottK> I see.
<ScottK> I thought the theory of Triaged was the was when it was ready for developer attention.
<ScottK> Now I'm confused again.
<jcastro> it only looks at triaged bugs
<ScottK> OK.
<ScottK> I'm caught in a mental catch 22 in that I don't know how you can mark it triaged and not know it needs upstreaming, but I never understand this stuff.
<calc> cool new 5-a-day group :)
<jcastro> ScottK: ok, so when you are looking at a bug and you know it's upstream, you can mark it as such, and then someone like me will go through the annoying (but relatively easier) task of filing it upstream.
<calc> jcastro: how are the stats tracked with the new group?
<ScottK> I see.
<jcastro> that way you do what you do best, and the triagers can do what they do best
<ScottK> I guess that makes sense.
<ScottK> jcastro: OK.  Thanks.
<jcastro> that's the /idea/ anyway
 * ScottK just wishes he see more triagers doing more than "-> Incomplete, can you still reproduce this in Jauntu".
<cjwatson> amen
<ScottK> I'd even much prefer "I tried to reproduce this and couldn't, how did you do it and can you still"
<lifeless> absolutely
<lifeless> I just put my bugs back to what they should be when folk do that to me
<lifeless> usually with a snarky comment
<lifeless> :(
<NCommander> does anyone know why gcj-4.3 on HPPA seems to be MIA?
<NCommander> LP says it built
<NCommander> the binaries seem to have vanished into thin air ...
<ScottK> Yes.  Me too, although I'd describe my reponse is these cases more as 'pointed'
<Amaranth> The bug team doesn't test the bugs, they just look at the ones that are Incomplete for more than a month
<ScottK> We could script that.
<Amaranth> ScottK: It is scripted, the Launchpad Janitor
<ScottK> Amaranth: That's for after they're incomplete.
<Amaranth> I guess I missed half the conversation
<Amaranth> Do you mean the "Does this still happen in jaunty?" ones?
<ScottK> Yeah.
<ScottK> It
<ScottK> It's a new bug and the first comment is can you reproduce it and set it to incomplete.
<ScottK> We could trivially replicate this by setting all bugs to incomplete at the last alpha and then marking them invalid if no one complains by release.
<ScottK> I don't think this would be a good policy, but it would give us most of the same effect.
<calc> as long as all doesn't include triaged bugs ;-)
<cjwatson> it would give us most of the same effect and it would suck even more completely. :-)
<calc> heh
<NCommander> +1 cjwatson
<NCommander> cjwatson: quick question, how often are the ports alternate CDs being built? Each milestone, or more often?
<ScottK> cjwatson: I'm definitely not arguing in favor of it, just trying to point out how mechanical the current 'triage' effort it.
<cjwatson> ScottK: oh, I know
<cjwatson> NCommander: daily
<NCommander> Oh
 * NCommander is lagging
<NCommander> I thought today was the 20th ...
<NCommander> And the last build was yesterday
<NCommander> :-)
 * NCommander is actually trying to make our ports be shiny this release
<ScottK> \o/ boost1.35 fixed on sparc.
<ScottK> Speaking of ports.
<NCommander> ?
<ScottK> Akonadi built.
<NCommander> Score!
<cjwatson> speaking of sparc, can somebody fix its asm/byteorder.h?
<cjwatson> http://launchpadlibrarian.net/22607976/buildlog_ubuntu-jaunty-sparc.glibc_2.9-0ubuntu10_FAILEDTOBUILD.txt.gz
<NCommander> cjwatson, testbuilding the fix now
<cjwatson> ah good
<NCommander> (I have to build a kernel, then the fixed glibc)
<cjwatson> I have a potential glibc change pending for the not too distant future anyway
<cjwatson> so maybe we can do those in one upload rather than separately
<NCommander> cjwatson, powerpc and sparc are looking quite good for this release, and if I can get an itantic, it will look good with ARM :_)
<cjwatson> I need to get it tested from my PPA though, so tomorrow
<NCommander> cjwatson, test what to where?
<cjwatson> potential fix for bug 313218
<ubottu> Launchpad bug 313218 in glibc "IPV6 causes slow internet access" [Critical,Confirmed] https://launchpad.net/bugs/313218
<cjwatson> it's in 'deb http://ppa.launchpad.net/cjwatson/ppa/ubuntu jaunty main' if anyone wants to try it before I do and potentially hose their system ;-)
<NCommander> Actually, I can test this
 * NCommander has an IPv6 network ... or did 
<cjwatson> that's one of the components of the test
<cjwatson> I have an IPv6 network too
<NCommander> I haven't reset up the router since I replaced it
<cjwatson> also needs testing from the folks actually afflicted by the bug, though, which is rather more those people who have broken IPv6 connectivity
<NCommander> oh
<NCommander> What did you change?
<cjwatson> pulled in a Fedora patch to disable gethostbyname4 for the time being
<NCommander> O_o?
<NCommander> That sounds like a necessary bit of code ...
<cjwatson> it's from Jakub Jelinek who knows what he is doing wrt glibc.
<NCommander> Well, if my point just didn't burn and crash
<cjwatson> if gethostbyname4 isn't there it'll use gethostbyname3 - glibc tends to support older interfaces of things
<NCommander> glibc's source code scares me
<NCommander> I feel like its going to come and get me in the middle of the night and rip off my head
<cjwatson> speaking of middle of the night ...
<NCommander> cjwatson, I was about ot say it was kinda late your time.
<calc> i noticed we were switching to boost 1.35 but 1.37 is also in the archive, should packages migrate to that instead?
<ScottK> calc: We all need to use the same one.
<ScottK> Please let's not start another switch right now.
<ScottK> That and I just got 1.35 patched to work on sparc.
<NCommander> cjwatson, do you know about anything on java on HPPA?
<ScottK> NCommander: I don't think such a thing exists.
<NCommander> :-/
<ScottK> IIRC that's what lamont told me.
 * ScottK goes back to trying to understand what the heck he was thinking when we wrote this beautiful code 9 months ago.
 * NCommander watches ScottK's brain liquidify
<ScottK> It really was a lovely way to solve the problem I was having at the time.
<ScottK> It may, however, turn out to be just one increment short of extensible enough.
<NCommander> ScottK, looks like kdebindings on HPPA is fixed
<ScottK> \o/
<NCommander> Its nice to have that fixed.
<ScottK> Yep.  I don't think that's ever built.
 * NCommander is officially the KDE port gurur ;-)
<NCommander> *guru
<NCommander> It did in the 3.x series
<ScottK> No mono bindings in KDE3.
<NCommander> yay
<ScottK> We could have solved KDE4 easily enough be not shipping them.
<NCommander> I'm kinda suprised mono is disabled on HPPA
<NCommander> It seems to be supported
<ajmitch> it probably wasn't supported back in the distant past
<NCommander> maybe its worth seeing if we can kick the mono lines from PAS
 * ScottK knows just that he wants the fricking package to build.
<NCommander> Well, either way ...
<ScottK> NCommander: Let's get pimlibs built on sparc before another upload first, so it'll have a chance there too.
<ScottK> That just needs a publisher run followed by a rescore.
<NCommander> stupid question: is porting a feature to a new architecture (i.e., fixing mono on HPPA) affected by feature freeze?
<ScottK> NCommander: Was the lack of Mono a design decision or a bug?
<NCommander> I think the HPPA porting group just never realized mono was ported
<Amaranth> who has HPPA hardware?
<NCommander> Physical, or access to one?
<NCommander> Amaranth, lamont :-)
<Amaranth> NCommander: He runs a KDE desktop on there? :)
<NCommander> dunno
<NCommander> Its a sticking point with me tha tKDE been broken on HPPA
<NCommander> (actually, just having a hosed port is :-P)
<TheMuso> cjwatson: I have managed to get the ia64 kernel down to 10MB, which will appear to just fit inside boot.img. I can't go any smaller without sacrificing functionality. A lot of stuff was disabled and/or built in for the last kernel as it was.
<TheMuso> NCommander: so you made the fix to glibc? I thought the fix had to be done in the kernel.
<NCommander> TheMuso, no, I made it to the kernel
<TheMuso> NCommander: ah ok
<NCommander> TheMuso, ah, the sparc kernel just finished
<NCommander> (like five seconds ago :-)
<TheMuso> timing
<NCommander> But ...
<NCommander> I built the wrong kernel
<NCommander> wait
<NCommander> Hold on
 * NCommander is an idiot ...
<lamont> NCommander: java/hppa vs doko is a long standing frustration of his.
<NCommander> lamont, I take it is a chicken and the egg problem because to bootstrap OpenJDK, you need a JDK already in place, right?
<lamont> NCommander: doko was at least smashing his head against openjdk/hppa, iirc.  until he got tired of the threads/kernel/libc/whatever-the-hell-it-really-is bug
<NCommander> lamont, which seems to have gone away-ish
<lamont> the one that has me rapidly approaching the point where I craft the email to ubuntu-devel-announce announcing the retirement of the hppa port from ubuntu
<lamont> ish being the operative word
<lamont> mostly, we just don't giveback things that we know kill it
<NCommander> lamont, well, I haven't experienced the fun it caused with Ruby
<lamont> because, well, it hurts when we do that
<lamont> NCommander: coolness
 * NCommander was one of the people who helped debug ruby on HPPA
<NCommander> I'd like to drop jaunty's kernel on the porting box and see if it works.
<NCommander> ^- better.
<NCommander> (and then run glibc's test suite to see what our breakage level is at)
<lamont> NCommander: here's a test for you:  pick anything amusingly interesting from _DAPPER_ and build it in a dapper+security chroot on that jaunty kernel - needs to work
<lamont> at least until jun 2011
<NCommander> I don't have a HPPA box I can install kernels on
 * NCommander has root at an HPPA box at HP, but thats on the other side of the US for me ...
<NCommander> *sighs*
 * NCommander grabs a handbook on SPARC ASM
<NCommander> lamont, is there a HPPA virtualization solution? (I've been trying to find an actual HPPA box for some time, but they're damn pricy, even used :-/)
<lamont> no solution that I know of
<NCommander> know where I can get a cheap box?
 * lamont was part of an investigation into virtualizing hppa in about 1992ish, that determined that it would certainly require guest knowledge in lots of places, and then we dropped that
<NCommander> ok, sparc should be fixed soonish
 * NCommander grumbles and backports more fixes
<NCommander> lamont, side issue, do you have access to the HPPA build chroots? They're misconfigured to disallow installing unsigned packages. I had a fun build failure in a devirtualized PPA due to that :-/
<lamont> I'm gonna go with "no" to that, even though rules-lawyers might disagree
<NCommander> lamont, rules-lawyers?
<lamont> NCommander: I have root on just about every machine in the data center.  and the others I have console on.
<NCommander> oh, I see
<lamont> mostly, I'm just tired enough to not want to even understand the issue, let alone fix it.
<lamont> which reminds me... I need to deal with the debian release on the debian/hppa buildd machines
<NCommander> lamont, this leads me to my next question on why HPPA is so bleck :-/. I do remember when it was a fairly loved architecture in Debian (before NPTL ...)
<lamont> and there you go answering your own wquestion
<NCommander> Oh
<NCommander> I'm just suprised HP hasn't sponsored work on it
 * lamont goes back to the pain that he knows, with:  apt-get remove --purge libvirt-bin
<NCommander> ouch
 * NCommander just wish PA-RISC boxs didn't command such a high price on ebay
<calc> hppa didn't even get bootstrapped until late 2000 iirc
<Cxoliac> join #fedora
<NCommander> Well, HP seems to be fairly bipolar on it; I see them moving to IA-64, and yet HPPA is quite common from what I see on their server offerings
<calc> NCommander: iirc ia64 was supposed to be the replacement... except that ia64 wasn't that great (aiui) once it actually came out
<NCommander> Well, ia64's are fairly cheap if your not too picky
<NCommander> Someone told me at UDS that the ia64's in the data center were ebay specials ...
<calc> NCommander: probably cheap because they aren't very useful, heh
<NCommander> well, I can find plenty of SPARCStation 20's for less than 200 bucks. Might just snag one for installation testing
<lamont> sparcstation 20 won't run ubuntu, iircf
<NCommander> bah
<NCommander> So HP-UX supports Java, so pa-risc support is there
 * NCommander takes a look to see if the code to support it is there ...
<rootard> hi all, quick q on building packages. What mechanism generates the .changes file once all of the .debs and sources are placed into the parent directory of the source?
<rootard> oh, nm. I need caffeine
<ScottK> It looks like at least libgpod-nogtk-dev and possible other binaries from libgpod have fallen into Universe for some archs (e.g. for i386, but no am64).  I was wondering it an archive admin is around who would clean that up?
<dholbach> good morning
<dholbach> bryce: wow... my gdm is in explosion loop of death and I can only click "OK"
<dholbach> does anybody of you have something like this in your gdm log?
<dholbach> error setting MTRR (base = 0xe0000000, size = 0x08000000, type = 1) Invalid argument (22)
<dholbach>  ddxSigGiveUp: Closing log
<dholbach> I believe gdm when it tells me that the xkbcomp problems are not fatal
<dholbach> > Warning:          Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols
<dholbach> >                   Ignoring extra symbols
<slangasek> "error setting MTRR" - that's a hardware matter
<slangasek> definitely no such error in my logs
<dholbach> I dist-upgaded and restarted - that's what it looks like now (on my nv amd64)
<dholbach> my i386 laptop works fine
<dholbach> and on the amd64 I can't switch to the consoles now
<dholbach> which sucks
<superm1> slangasek, can you retry the livefs build for ubuntu dvd?  yesterdays didn't come out, and we were counting on some fix(es) in it.
<dholbach> https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/331292
<ubottu> Ubuntu bug 331292 in gdm "gdmgreeter crashed with SIGSEGV in __libc_start_main()" [Undecided,New]
<slangasek> superm1: yep, running
<dholbach> I guess that's my issue
<dholbach> what happened to bulletproof X?
<dholbach> :-(((
<dholbach> hum, maybe it's not
<dholbach> I wasn't using nvidia
<jdong> heh with my video chipsets whenever X really fails it tends to lock everything with it...
<jdong> I once had a mismatch between the kernel blob and userland that triggered hardlocks...
* slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | alpha-4 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
<dholbach> what about http://people.ubuntu.com/~dholbach/new-nm-dialogue.png - do we really mean to have that dialogue?
<dholbach> and why does gnome-terminal crash on me?
<dholbach> today is not going to be my day, I just know it
<jdong> oh it is definitely one of those weeks where just about everything goes wrong :)
<jdong> to pile up on my fun stuff this week I lost both of my Firefox profiles... on the same day... independent systems same bug :)
<dholbach> ok... xdm instead of gdm works
<Amaranth> dholbach: Apps that try to use notification-daemon with buttons get an error that they think means notification-daemon isn't running and fall back to showing a dialog
<Amaranth> I like how the "You are now running on battery power" dialog has a Cancel button
<Amaranth> Maybe if I click it the computer will automatically attach the power cord again
<dholbach> I'm not sure those dialogues help with anything
<Amaranth> They don't, it's something no one ever actually saw before because notifications always worked
<calc> dholbach: does 5-a-day-stats get automatically updated by just joining the group now?
<johanbr> Amaranth: That's apparently supposed to act as a reminder to patch those applications.
<dholbach> calc: that's the plan - I still have to do some work to do for that
<calc> dholbach: ok
<dholbach> calc: now that I can log in to GNOME again, I'm one step closer to doing it :)
<calc> dholbach: heh :)
<dholbach> ok, it's bug 331324
<ubottu> Bug 331324 on http://launchpad.net/bugs/331324 is private
<slytherin> Can any of the archive admins please rescore libdvdread on ia64, hppa and armel? It is stuck at score 3255 for more than 30 hours.
<Mithrandir> slytherin: no.  Done.
<Mithrandir> (you need a buildd admin, not an archive admin)
<slytherin> Mithrandir: thanks
<ScottK> slytherin: There is a bit of a line tonight.
<Mithrandir> ScottK: though, if people are actively waiting for something to build, I'm happy to rescore it so they don't get blocked.
<ScottK> Mithrandir: Sure, I just mentioned it in there interests of 'nothing's wronge except everyone uploading tons the day before FF.'
<Mithrandir> oh, sure.
<slangasek> superm1: still fails to build; langpack conflicts
<slangasek> looks like it's because of the long build queues
<stefanlsd> Does anyone know if mom data is available in xml or csv or somthing?
<pitti> Good morning
<ion_> Hi
<Koon> Good morning pitti
<scizzo-> morning
<primes2h> pitti: Good morning.
<dholbach> pitti: do you know why bug 330621 was not retraced yet?
<ubottu> Bug 330621 on http://launchpad.net/bugs/330621 is private
<PecisDarbs> pitti: good morning, can I talk with you for a minute? :)
<pitti> Meh, X froze again while I was showering
<pitti> PecisDarbs: pong
<pitti> dholbach: when was it filed?
<dholbach> pitti: nm, saw your conversation with seb128 about the retracer
<pitti> dholbach: "my conversation"?
<pitti> it might be stuck again, but I didn't get a warning mail
 * pitti checks
<pitti> dholbach: oh, was it amd64? the retracer got stuck apparently
 * pitti restarts it
<pitti> seb128: ^ FYI
<seb128> pitti: cf #distro
<seb128> pitti: stop ignoring me there dude ;-)
<pitti> seb128: didn't see anything
<beuno> pitti, mine is freezing as well (we seem to share a lot of hardware!). I also have to log in twice to gdm. Is that a known issue?
<pitti> beuno: happens to me, sometimes, a few minutes after suspend from hibernate; otherwise it's behaving
<beuno> pitti, it has happened to me twice in the past few days, but not related to hibernating or suspending, unfortunetly
<pitti> beuno: can you still ssh in?
<pitti> beuno: I can, and I tried stracing X, and got a busy loop with
<pitti> --- SIGALRM (Alarm clock) @ 0 (0) ---
<pitti> sigreturn()                             = ? (mask now [])
<pitti> ioctl(11, 0x40046445, 0xbfb8e4a4)       = -1 EINTR (Interrupted system call)
<beuno> pitti, ah, I haven't tried. Will do next time.
<\sh> soren: you have main powers, right? would you like to review bug #331410 (jaunty debdiff) for net-snmp
<ubottu> Launchpad bug 331410 in net-snmp "CVE-2008-6123: not fixed in latest security releases" [Undecided,In progress] https://launchpad.net/bugs/331410
<pitti> beuno: me too, I'll check if it's the same next time
<pitti> beuno: oh, and I just tried stracing X in X; don't do that...
<pitti> gives a nice lockup :)
<beuno> hahah
<ion_> :-D
<pitti> ssh'ing in and kill -9'ing strace recovers, though
<beuno> pitti, other than those two things, Jaunty seems much more solid than Intrepid
<pitti> tseliot: btw, did GNOME stop respecting .config/monitors.xml a week ago (or so) as well?
<pitti> tseliot: that's pretty nasty, I always have to start the session with reconfiguring screens, compiz --replace, killall gnome-panel..
<pitti> beuno: what hardware do you have?
 * pitti -> back in 5
<tseliot> pitti: no, did you file a bug report about it?
<beuno> pitti, dell xps1330 with GM965 and 3945ABG
<tseliot> pitti: if you do, I'll be happy to fix that
<pitti> tseliot: yes, I did, let me find it
<pitti> tseliot: bug 329410
<ubottu> Launchpad bug 329410 in gnome-control-center "does not set configured resolutions at GNOME startup any more" [Undecided,New] https://launchpad.net/bugs/329410
<pitti> tseliot: .config/monitors.xml didn't change AFAICS (did it?), so it seems that gnome-settings-daemon or whatever else is responsible for reading and acting on it doesn't work any more?
<tseliot> pitti: no but there can be different (temporay) configuration files. I'll try to reproduce the problem here and I'll fix it
<pitti> tseliot: it just seemed to coincide with the new-style capplet (separate on/off, and so on)
<pitti> might be pure coincidence, though
<pitti> tseliot: is g-settings-daemon the piece that should read it?
<tseliot> pitti: yes, through libgnome-desktop.
<pitti> ah
<pitti> tseliot: so maybe something was ported to drop libgnome?
<tseliot> pitti: I've done some serious work on it therefore I should be able to figure out where the problem lies
<pitti>   * debian/control.in:
<pitti>      - the new version doesn't require libesd, libpulse, libgnomeui
<pitti> gnome-settings-daemon (2.25.2-0ubuntu1) jaunty; urgency=low
<tseliot> I doubt they can be the cause of the problem
<pitti> ah, no, that's too  old
<pitti> it just stopped working a week ago or so
<tseliot> I have some suspects ;)
<pitti> ArneGoetje: hardy/intrepid-proposed langpacks accepted
<cjwatson> NCommander: java/hppa> absolutely no idea
<cjwatson> TheMuso: ia64 kernel> thanks, sounds good
<PecisDarbs> pitti: did a changes in sl-modem-daemon.init patch you suggested, a little bit optimized all alsaload along the way. Patch attached to bug report.
<pitti> PecisDarbs: great, thanks
<majeru> hello, i'd like to propose some enhancements to the display manager applet, is there anyone that is in charge with it?
<pitti> anyone on current KDE? can you tell me where Konqueror stores its cookie file/database?
<pitti> majeru: display manager applet? you mean the fast user switcher in the panel, with your name and status?
<majeru> no, i mean that one that may change the screen resolution
<pitti> majeru: tseliot primarily
<majeru> ok, thanks
<tseliot> majeru: what's the problem?
<majeru> there's no problem, i have some usability proposals
<majeru> mostly for those people with multiple display setups
<majeru> like having profiles accessible from the notification menu
<majeru> and sub-menus for each display's resoluton
<tseliot> majeru: can you file a bug about it and send me a link to it, please? I'll have a look at it later
<majeru> okay, thanks
<ogra> tseliot, oh, while you're at discussing the screen applet, do you know about https://blueprints.launchpad.net/ubuntu/+spec/mid-screen-rotation ?
<pitti> Riddell: can you tell me where Konqueror stores its cookie file/database?
<ogra> tseliot, would be nice to have a version for MID with all capabilities cut out of the applet apart from teh rotation settings, that way we could use it in MID
<tseliot> ogra: it can be done by reusing libgnome-desktop or doing it from scratch
<ogra> tseliot, well, thats what i wanted to avoid :)
<ogra> youse seems perfect for the task, it just has to many options
<ogra> *yours
<tseliot> ogra: which one?
<ogra> the little display i can add to the systray
<ogra> MID uses a systray and the menu apart from the "open display settings" button is prefectly what we are looking for
<ogra> either bryce to tjaalton told me that you wrote that
<tseliot> I worked on it but that depends on libgnome-desktop though. It's part of gnome-control-center
<ogra> oh, even the applet ?
<tseliot> yes
<ogra> ah, k, i guess then i'll just steal your code and adapt it in 9.10
<tseliot> ok ;)
<ogra> i doubt we want libgnome-desktop or gnome-control-centerin MID
 * ogra needs to reboot after upgrade ... bbs
<tseliot> it shouldn't be difficult to write something from scratch
<ogra> yeah, i grokked that, but its usually even easier to write a patch that just compiles code again with a different configure option to disable features :)
<ogra> pitti, is it normal that i dont get a reboot notification icon anymore ?
<ogra> i had the popup message telling me i need to restart after the upgrade ...
<pitti> ogra: I'm not sure, ask mvo?
<ogra> mvo, ^^^
<ogra> but no icon in systray
<mvo> ogra: yes, its all part of the new design
<mvo> https://wiki.ubuntu.com/NotificationDesignGuidelines
<ogra> hrm, so i dont have a way to postpone the reboot and still have a reminder
<ogra> thats a bit odd
<soren> Is there a way to see the the build queue? I mean the specific order in which stuff in "Needs building" is going to get built?
<persia> soren, I believe it is https://launchpad.net/ubuntu/jaunty/+builds
<soren> persia: I was expecting a link that didn't have "jaunty" in it.
<Riddell> pitti: .kde/share/apps/kcookiejar/cookies
<soren> -proposed and -backports and all that jazz is in the same queue, is it not?
<Riddell> sorry for the delay there
<pitti> Riddell: that's a file?
<Riddell> pitti: yes
<pitti> Riddell: thanks a lot
<persia> soren, As I understand it, they are different queues, and the queues are processed on the same buildds in a specific order.
<persia> Hrm.  https://launchpad.net/ubuntu/+builds seems to also work, but I believe it misses -security stuff (which also uses the same buildds).
<soren> persia: Oh. I thought I tried ubuntu/+builds already. That's odd.
<soren> Oh.
<soren> You have to sepll "builds" correctly, apparantly.
<soren> And "spell" as well.
 * ogra thought that was deliberate :)
<persia> I seem to remember there was some reason why I always use /ubuntu/${dist}/+builds, but I can't recall the actual reason.
<soren> persia: Do you happen to know how to limit it to a single arch?
<persia> soren, Only on a per-release basis (e.g. https://launchpad.net/ubuntu/jaunty/hppa/+builds)
<persia> That the generalised form doesn't work might be a bug, but you've the use case for it, so would be the better candidate to file than I.
<soren> persia: That works. Thanks!
<soren> Is anyone filling in as the substitute archive admin of the day today?
<pitti> soren: why substitute?
<soren> pitti: I'm told today is a bank holiday in Australia.
<pitti> oh, I see
<soren> ...and AFAIR, it's StevenK's aa day.
<soren> pitti: Did you just volunteer? :D
<pitti> nope
<pitti> I stepped down from archive days :)
<soren> Didn't think so, but thought I'd try my luck anyway. :)
 * pitti has 150% hands full, sorry
<soren> pitti: Don't worry about it. I'll find another helpless victim.
<directhex> me! me! pick me!
<PecisDarbs> directhex: helpless victims usually don't show iniciative, so keep your voice down :)
<soren> directhex: You're clearly not helpless.
<PecisDarbs> :D
<soren> doing it wrong.
<cjwatson> archive> I'll do some in a bit, but I need to reboot first
<directhex> (into his vista partition)
<cjwatson> :-P
<MacSlow> why can't I change the "Importance" of a bug in e.g. https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/331235 ?
<ubottu> Ubuntu bug 331235 in notify-osd "Alsdorf doesn't work with composite enabled metacity" [Undecided,Confirmed]
<dholbach> MacSlow: not in ~ubuntu-bugcontrol?
<directhex> MacSlow, nobody can unless they have launchpad awesomeification powers
<directhex> or what dholbach said
<MacSlow> dholbach, directhex: but I could change the importance of some other bugs
<dholbach> MacSlow: that were not in the lp.net/ubuntu namespace and your own project?
<MacSlow> dholbach, directhex: problem there currently is ... there are 3 or 4 pages where pepole can file bugs on alsdorf/notify-osd
<Geek`N`Proud> Hey guys.  Is Ubuntu 9.04 getting Firefox 3.1 at any point?
<jeromeg> could someone please review xfce4-notifyd which is waiting in NEW ?
<cjwatson> Geek`N`Proud: there's a firefox-3.1 package for people to play with; I don't know about the default
<Geek`N`Proud> cjwatson: okay cool =]
<MacSlow> what's gnome-stracciatella ?
<cjwatson> MacSlow: https://blueprints.launchpad.net/ubuntu/+spec/stracciatella-session
<cjwatson> I gather that stracciatella is some kind of fancy word for vanilla
<directhex> MacSlow, hard to install on the command line, that's what
<cjwatson> actually a bit more than that. http://en.wikipedia.org/wiki/Stracciatella
<MacSlow> cjwatson, I only know it as ice-cream
<MacSlow> ah interesting
<pitti> cjwatson, MacSlow: it's not plain vanilla GNOME, it still has some brownish bits in it (Ubuntu patches, and smaller Ubuntu changes)
<pitti> MacSlow: yes, it indeed is a pun referring to ice cream
<giskard> stracciatella == cream + chocolate drops (icecream)
<pitti> providing a pure vanilla GNOME session would be very hard to do with current technologies
<pitti> that's rather for grumpy groundhog
<giskard> anyway, i've sent a test mail to my ubuntu.com mail address and suddenly i'm receiving a lot of spam to this address. it's a coincidence?
<ogra> "some brown crumbs" haha
<maxb> What determines whether a package is chosen to be in ubuntu-desktop's Depends, vs. its Recommends ? Is it just a matter of a design decision on the relative importance of the package? Or is there some greater significance?
<IntuitiveNipple> Depends means it is required for the package to function, Recommends means it won't crash if that package isn't there
<IntuitiveNipple> See the Debian Policy for the precise definitions of course
<maxb> IntuitiveNipple: those definitions don't really apply to a metapackage
<maxb> ubuntu-desktop doesn't "function" it just exists to cause the package manager to behave in certain ways
<IntuitiveNipple> Policy seems pretty clear to me: "The Recommends field should list packages that would be found together with this one in all but unusual installations"
<IntuitiveNipple> "This declares an absolute dependency. A package will not be configured unless all of the packages listed in its Depends field have been correctly configured"
<cjwatson> maxb: loosely, the intent is that Depends are core parts of the desktop without which it really isn't the Ubuntu desktop, and Recommends are things like applications that you can reasonably swap out for alternatives
<cjwatson> this is not necessarily implemented entirely consistently, but that's the idea
<cjwatson> IntuitiveNipple: I think he understands that, he's asking for reasoning
 * maxb wonders whether the argument "notify-osd can reasonably be swapped out for notification-daemon, please demote to recommends" would gain any sympathy
<IntuitiveNipple> cjwatson: Hah! While you're there. Those partman issues with Ubiquity... I've supported two other users via remote SSH with the similar situations. One was caused by the 'Automatic resize' option and left the partition table on-disk different to the one in-memory.
<cjwatson> I'm not here for long enough to diagnose that :-) I'm about to go out for lunch
<cjwatson> I assume you are busy gathering all the necessary log files, preferably including a hex dump of the boot sector
<IntuitiveNipple> cjwatson: No, I'm not expecting you to.... just a heads-up ... I spent 6 hours on it.
<cjwatson> (od -Ax -tx1 -N512 /dev/sda)
<IntuitiveNipple> cjwatson: I have enough that I *hope* (when I can find time) to be able to reproduce it in a VM
<cjwatson> IntuitiveNipple: sounds like the sort of thing that could be caused by a missing ped_commit_to_disk or whatever it is, and that could well be due to a partman logic bug; /var/log/partman will be necessary
<TuTUXG> after update the restricted-modules, nvidia driver(180.29) keeps crash my X, I can see the nvidia logo but cannot get into gdm screen, any ideas?
<cjwatson> maxb: do bear in mind, though, that it is not a design goal of Ubuntu that all conceivable changes can be made without removing the ubuntu-desktop package; indeed for certain changes it makes sense to remove ubuntu-desktop, since you're now taking broad responsibility for your own package selection
<IntuitiveNipple> cjwatson: It caused 'logical partition to overlap extended' - due to multiple sub-extended partition sectors
<TuTUXG> jaunty
<cjwatson> what is a "sub-extended partition sector"?
<cjwatson> the sector vs. cluster thing that you were talking about earlier?
<IntuitiveNipple> cjwatson: primary -> extended > extended > extended
<cjwatson> oh, you mean chained extended partitions
<IntuitiveNipple> cjwatson: Yes :)
<IntuitiveNipple> The user's situation was two existing file-systems, one at start of disk, one towards the end, and resized to create gaps between where new extended/logical were created... poor thing just got itself confused :)
<ogra> cjwatson, did you make the changes for nslu2 in d-i to disable the keyboard selection ?
<ogra> (the stuff i verified recently)
<cjwatson> ogra: you mean removing console-setup-udeb? no, not yet
<cjwatson> ogra: I'll do it after lunch
<ogra> cjwatson, there was more ... http://paste.ubuntu.com/120104/
<ogra> though it still hits oom ... i'll need to see what i can do about bug 331510
<ubottu> Launchpad bug 331510 in linux "ixp4xx kernel to big to use with debian-installer on NSLU2" [Undecided,New] https://launchpad.net/bugs/331510
<pitti> apw: just reviewed https://code.edge.launchpad.net/~apw/apport/suspend-resume-pt3/+merge/3684, needs some changes
<apw> pitti, no problem
<apw> pitti, where will you feedback?
<pitti> apw: I did it in the merge request itself
<apw> cool
<pitti> apw: but great idea to autoamtically include it in the bug title -- that will also help to avoid filing dupes
<pitti> since LP proposes existing bugs with the same title
<apw> yeah i see how i missed the dmidecode one as the resume stuff is always root, bah
<pitti> apw: I really think the existing info from hal should suffice
<apw> yeah it does, i wish i'd noticed it was in there, i've been asking people for info
<apw> which was hiding there all alone!
<pitti> I guess it's not immediately visible, since it's an attachment
<apw> yeah, silly error on my part
<ogra> also please dont forget that we support arches that dont have PCI busses exposed to the system or dont have dmidecode :)
<apw> yeah i knew that, and expect it to just add a not found to the report
<ogra> i.e. make them fail gracefully please if you implement something based on it
<pitti> apw: also, do you actually need to run attach_hardware? the linux package hook already does that
<apw> it gets run after the report generator runs
<pitti> apw: if it isn't there on existing reports, then there's something wrong with the hook, or how it is called
<apw> so i don't have the pr[Hal] th
<apw> thing defined yet
<pitti> right, indeed
<apw> it gets defined on submit, ie after i needed it to set the title
<apw> that was one of my queries, if there was a correct way to run the hooks earlier
<apw> i could add it unconditionally to all kernel reports i believe
<apw> ie, not doing it in the suspend specific parts, but it does feel like it would be nice to have it possible there
<apw> pitti, it is a little supprising that the hooks don't run at apport.report.Report('foo') time
<pitti> apw: they can't, they need the SourcePackage: and Package: fields first
<apw> perhaps we could offer an optional
<apw> apport.hookutils.trigger_hooks()
<pitti> apw: so, for now it's fine to call attach_hardware in your script
<apw> which runs them ealrly
<pitti> apw: that's report.add_hookinfo()
<pitti> add_hooks_info(), sorry
<apw> does it handle being run twice cleanly
<apw> ie. do nothing the second time.
<apw> if so then that might be a clean way to do it
<pitti> should, it's just not very efficient
<apw> i add that, and make it do nothing the second time
<apw> ie. self detecting
<pitti> apw: for now I propose that you just call attach_hardware()
<pitti> i. e. as you do now
<apw> will do
<pitti> take it as it is, parse out system.hardware.product and system.hardware.vendor and mangle the bug title accordingly
<apw> yep, on it
<NCommander> infinity, or lamont, can someone determine why https://edge.launchpad.net/ubuntu/jaunty/+source/kdebindings/4:4.2.0-0ubuntu2 didn't get dispatched to HPPA? (its not in P-a-s- as far as I know and 0ubuntu1 did get attempted ...)
<doko> Koon: were you able to work with the updated ecj and eucalyptus?
<Koon> doko: not exactly.
<apw> pitti, ok, i've reworked that branch and pushed it up.  merge request updated
<pitti> apw: great, thanks
<pitti> apw: looks great now
<apw> pitti, cool thanks
<pitti> apw: I assume that you tested this already? or should I give it another go?
<apw> i have tested it on my crashy laptop, let me test all three interfaces one more time
<apw> seems to generate the right thing in all three on my crashy laptop
 * cjwatson attempts to resurrect his IPv6 networking
<cjwatson> I have to cast Turn Undead on the bloody thing every time I care
<mvo_> hm, under what circumstance can X_LOADTEMPLATEFILE hang? I get this from grub/ucf on failed upgrades apparently
<mvo_> when dpkg --configure -a runs for recovery
<cjwatson> mvo_: suggests to me that it isn't connected up to debconf properly
<cjwatson> if it runs properly, it's just walking through a file, there's no reason it should hang
<mvo_> thanks cjwatson
<cjwatson> mvo_: of course IME the usual solution to this is to sit down and think very hard about what fds are connected to what other fds :-/
<cjwatson> sometimes involving paper
<seb128> jdstrand_: hey, sorry I was busy when you pinged yesterday and forgot to reply to your question yesterday
<jdstrand_> seb128: np! I know how these things go :)
<seb128> jdstrand_: alt-f2 is a gnome-settings-daemon shortcut I think
<jdstrand> seb128: does it work for you?
<seb128> jdstrand: is it listed in gnome-keybinding-properties as a "show the run application dialog box" action?
<seb128> jdstrand: yes
<jdstrand> odd...
<seb128> jdstrand: do you use compiz?
<jdstrand> seb128: I do, yes
<seb128> could be a compiz issue, though I don't get the bug on my laptop which runs compiz
<seb128> jdstrand: did you try with a new user?
<jdstrand> seb128: yes, on my laptop, which doesn't run compiz, it works
<seb128> that would tell us if that's due to some configuration for your user
<seb128> I would first bet on some compiz setting creating the issue
<jdstrand> (the yes was not an answer to your new user question, which is 'no')
<seb128> could you try with a new user or guest session? ;-)
<cjwatson> grr, for some reason connect() to an IPv6 link-local address isn't working
<cjwatson> it seems to work to a global-scope address
<cjwatson> connect(3, {sa_family=AF_INET6, sin6_port=htons(46372), inet_pton(AF_INET6, "feac:0:0:1499::11", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EINVAL (Invalid argument)
<cjwatson> connect(3, {sa_family=AF_INET6, sin6_port=htons(46374), inet_pton(AF_INET6, "2001:41a8:604::1:1", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
<cjwatson> mdz: ^- this is what we were seeing on the plane I think
<cjwatson> mdz: aha; the problem is that one needs to explicitly specify an interface when connecting to link-local addresses
<mdz> cjwatsonweird
<cjwatson> ping6(8) documents this (-I)
<mdz> cjwatson: which applications actually let you do that?
<cjwatson> tracepath6 doesn't
<cjwatson> traceroute6 does
<cjwatson> as for, you know, actual applications I have no idea
<cjwatson> but at least now I know how to debug my network
<jdstrand> seb128: I will check as a new user and look into compiz. if it is a real bug I'll file it. thanks for your help :)
<seb128> jdstrand: you're welcome
<siretart> cjwatson: FYI, `ssh feac:0:0:1499::11%ethX` seems to do the trick for ssh
<cjwatson> thanks; interesting, that's undocumented
<cjwatson> ah, it's implemented in getaddrinfo()
<cjwatson> so that's probably in fact quite widely-supported
<cjwatson> and indeed works with tracepath6
<calc> anyone happen to know if apt package list does not get updated if you are not on a regular net connection?
<calc> eg does it still update across mobile broadband, i'm looking at the script and it looks like it downloads anytime you are on mains power(?)
<calc> yipee my new laptop hd will be here today :)
<pitti> calc: ssd? fast as hell? :-)
<pitti> calc: apt-get> I think that's correct, whenever you have a default route it'll download them
<pitti> arguable if you are on a mobile connection, indeed
<calc> pitti: not a ssd but a 7200 500gb drive
<pitti> calc: wow, that'll fit a couple of OO.o trees :)
<calc> pitti: yea for the mobile case that could be very expensive and even in flat rate cases usually have low limits
<calc> pitti: heh yea
<calc> pitti: the update-notifier change reminded me about the fact apt pulls the data daily
<ion_> pitti: About three?
<calc> for devel releases that is around 1.3GB/month of package lists
<pitti> ion_: heh
<slytherin> Does anyone know any particular reason why *ubuntu-restricted-extras has direct recommends on libdvdread3 and libmp3lame0?
<pitti> ion_: well, I never had such a large internal hard disk (my /home is usually 50 GB), and I built OO.o before
<pitti> slytherin: isn't that its primary purpose?
<ion_> calc: Someone should finish apt-sync. :-)
<pitti> to pull in the questionable codec/CSS stuff?
<slytherin> pitti: but it already recommends gstreamer0.10-plugins-bad and other similar packages which will pull these libraries anyway.
<pitti> slytherin: ah, I see; I guess those can be droppped then
<slytherin> pitti: are *-restricted-extras packages managed by any seed?
<pitti> slytherin: I don't think so; apparently it's not even in bzr
<slytherin> ok, then I will update those packages.
<seb128_> tseliot: hey
<seb128_> Original exception was:
<seb128_> Traceback (most recent call last):
<seb128_>   File "/usr/bin/nvidia-detector", line 2, in <module>
<seb128_>     import NvidiaDetector
<seb128_> ImportError: No module named NvidiaDetector
<seb128_> is that a known issue?
<seb128_> current jaunty
<pitti> seb128_: you have nvidia-common installed?
<pitti> $ nvidia-detector
<pitti> none
<seb128_> pitti: I guess since that's the postinst for this one breaking
<pitti> ah, python-central fun
<seb128_> hum
 * seb128_ looks at doko
<tseliot> seb128: mvo reported the problem to me and I committed what he suggested and volunteered to sponsor the upload
<doko> which package is this?
<seb128_> doko: nvidia-common
<tseliot> seb128_:  we tried adding export DH_PYCENTRAL=nomove to the debian/rules
<saispo> hi
<saispo> it's possible to rsync somewhere old feisty* repository ?
<pitti> saispo: old-releases.ubuntu.com
<saispo> pitti: thanks, will see
<pitti> saispo: archaeology? :-)
<saispo> pitti: yep :/ i ha ve a lot of feisty server :/ and when i rsync i lost all things ;)
<pitti> saispo: eww -- not in production on the internet, I hope
<savvas> saispo: you can upgrade using the alternate cd, choose "No" when asked to upgrade from the internet
<saispo> pitti: it's hard to explain ;)
<savvas> http://www.ubuntu.com/getubuntu/upgrading#Upgrading%20Using%20the%20Alternate%20CD/DVD
<saispo> savvas: with near 12000 server ? ;)
<saispo> pitti: old-release.ubuntu.com have an rsync server ?
<ogra> get some inline skates :)
<pitti> saispo: I don't know
<savvas> hehe
<savvas> ogra: original :P
<saispo> ogra: in ethernet wired ? ;)
<savvas> saispo: then support this: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/319146 :P
<ubottu> Ubuntu bug 319146 in update-manager "When a release reaches End-of-Life, update manager should show EoL status and provide a link with working procedures and more information." [Undecided,Confirmed]
<saispo> savvas: thanks to help me ;)
<savvas> saispo: but the alternate cd and choosing "No" is the only working way I found, I don't know about the servers unfortunately, there's probably a similar "non-gui-through-console" way to mass-upgrade them
<slytherin> pitti: should I also remove libdvdread3 and libmp3lame0 for kubuntu-restricted-extras?
<kagou> bryce, please hace a look at my last comment on #325394
<bryce> kagou: sure
<kagou> thnaks
<kagou> thanks
<pitti> slytherin: if it's pulled in by something else, then sure; but these libraries might get dlopen()ed, so please triple-check, and check the changelog why they were added
<Riddell> slytherin: why remove them?
<cjwatson> I'd like anyone who can to test the glibc packages in "deb http://ppa.launchpad.net/cjwatson/ppa/ubuntu jaunty main", relating to bug 313218
<ubottu> Launchpad bug 313218 in glibc "IPV6 causes slow internet access" [Critical,Confirmed] https://launchpad.net/bugs/313218
<slytherin> pitti: they were added back in gutsy. No explanation as to why they should be there for kubuntu. kubuntu apps use xine backend by default IIRC.
<cjwatson> I'm interested in tests from people with real IPv6 connectivity as well as from people who suffer from that bug, since I've been unable to resurrect my IPv6 setup so far
<pitti> slytherin: for example, some programs used to dlopen() libdvdcss
<slytherin> Riddell: I am just asking. In case of ubuntu and xubuntu they will be pulled by gstreamer plugins so no point in having those direct dependencies.
<BUGabundo> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/124338/
<ubottu> Ubuntu bug 124338 in apport "[feature request] apport/launchpad possibility to attach apport report to already reported bugs" [Wishlist,Fix released]
<slytherin> pitti: right. I will leave them for kubuntu for now.
<BUGabundo> its failing to build
<BUGabundo> https://edge.launchpad.net/ubuntu/+source/apport/0.132/+build/875501
<seb128> BUGabundo: uploaders get build failure emails no need to ping on IRC too
<pitti> dh_pycentral: /usr/share/debhelper/autoscripts/prerm-pycentral does not exist
<pitti> make: *** [binary-install/apport] Error 1
<pitti> WTF?
<BUGabundo> ok seb128
<BUGabundo> it seems pitti did not read the email in time
<BUGabundo> ehehe
<pitti> BUGabundo: will look later
<BUGabundo> thanks
<BUGabundo> btw can I just branch LP?
<BUGabundo> its a python script right?
<seb128> BUGabundo: if people don't read there email every 5 minutes that's often because they try to get work done ;-)
<seb128> there -> their
<BUGabundo> I know the feeling seb128
<BUGabundo> I just read the announment and tried to get it
<BUGabundo> and then found the failure
<seb128> BUGabundo: well, IRC ping doesn't go in the right direction then, they just add extra noise to the stack
<pitti> I know, people are probably eager to test apport-collect :)
<BUGabundo> sorry
 * BUGabundo shuts up
<BUGabundo> pitti: it will come in handy
<pitti> BUGabundo: but in general seb128 is right, at FF everyone is busy and needs to batch their work for efficiency
<BUGabundo> right now I just upload the logs to new bugs and get them marked as dupes
<seb128> BUGabundo: don't get me wrong I appreciate you being enthousiastic but there is no need to ping people in the second something goes wrong, better to let them handle their schedule and ping after a while if nothing is happening
<pitti> BUGabundo: feel like finding out what went wrong? it builds fine on my machine
<BUGabundo> hey you won't here from me more about *this* issue
<BUGabundo> pitti: I would if a I new a bit more about it
<BUGabundo> and right now you guys don't have the time to hand carry me..
<BUGabundo> maybe next time
<pitti> ah, there's a new python-central coming through apt-get dist-upgrade
<pitti> maybe doko broke it :)
<BUGabundo> ehhe
<BUGabundo> see.. know I learned something (from all this noise)
<seb128> kirkland, james_w, jdstrand: does anybody of you want to process syncs today?
<seb128> the list has quite some waiting and it would be nice to clean it
<kirkland> seb128: i can push some through
<seb128> kirkland: would be appreciated
<jdstrand> kirkland: leave a couple for me. I haven't processed a sync request yet :)
<kirkland> jdstrand: :-D
<slytherin> I have a question. I filed a sync bug today (about 12 hours ago) not knowing FF was in effect. Do I need to convert it to FFE?
<kirkland> jdstrand: you can tackle them if you want :-)
<jdstrand> kirkland, james_w: sure-- I'll get started and ping you guys if/when there are any left
<kirkland> jdstrand: no prob, have fun
<seb128> slytherin: is that a new upstream version?
<slytherin> seb128: yes
<seb128> it's border line then, usually request filed before the freeze are just synced
<slytherin> Ok. I will add all the info needed by FFE to the bug anyway.
<slytherin> When did the freeze come into effect exactly?
<pitti> apw: whoops, I forgot to upload apport with your changes; done now
<apw> heh happens to the best of us
<LaserJock> is a FFe needed for a new binary that results from a bugfix?
<kirkland> jdstrand: i found it useful to do a few syncs by hand, and after i got the hang of it, i used syncbugbot
<LaserJock> it lands in NEW so I'm guessing so, but it's not new source or new upstream release
<jdstrand> kirkland: that is exactly what I am doing
<kirkland> jdstrand: ;-)
<kirkland> Keybuk: ping, regarding pitti's comments on ubuntu-devel@ about powernowd and the server
<kirkland> Keybuk: we just recently added powernowd to the server to get cpu freq scaling (and ondemand by default)
<Keybuk> did you add it because of the daemon or the init script?
<kirkland> Keybuk: init script, i think;  the daemon isn't running
<Keybuk> ok, great
<Keybuk> that's solved by the kernel patches in 2.6.28
<Keybuk> in fact, the init script was broken anyway
<kirkland> Keybuk: sweet, let me remove powernowd and reboot
<Keybuk> kirkland: make sure you have 2.6.28-8.24
<jdstrand> kirkland: in the bugs I see 'Sync request ACKed'. am I to assume that this review is required to sync?
<kirkland> jdstrand: yeah, check that it's ack'd by someone with MOTU or core-dev privs
<kirkland> jdstrand: you might also check the changelog too
<kirkland> jdstrand: to sort of make sure that the sync is mostly bug fixes at this point (past FF)
<kirkland> Keybuk: linux-image-2.6.28-8-server
<Keybuk> kirkland: which version?
<kirkland> Keybuk: rebooting atm
<Keybuk> the version is important ;)
<kirkland> Keybuk: ii  linux-image-2.6.28-8-server       2.6.28-8.24                       Linux kernel image for version 2.6.28 on x86
<kirkland> Keybuk: rc  powernowd                         1.00-1ubuntu3                     control cpu speed and voltage using 2.6 kern
<kirkland> Keybuk: ^ removed
<Keybuk> kirkland: that's ok - that includes the right patches
<kirkland> Keybuk: ls /sys/devices/system/cpu/cpu0/cpufreq/ checks out
<kirkland> Keybuk: rock-tastic
<Keybuk> kirkland: what does scaling_driver and scaling_governor say?
<calc> the drive actually arrived, i am somewhat surprised since i bought it from a questionable website
<kirkland> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<kirkland> ondemand
<Keybuk> and driver?
<kirkland> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
<kirkland> powernow-k8
<Keybuk> sweet
<calc> no other companies in the US had the drive in stock though so i just went for it ;)
<kirkland> Keybuk: cool, do you agree it's safe to remove powernowd from the server seed?
<LaserJock> calc: have you looked in the box? :-)
<calc> LaserJock: yea and even checked to make sure the drive is listed as in warranty :)
<LaserJock> calc: I once bought a CD burner from Walmart that was an empty CD drive case with a photocopy of the burner's frontplate on the front :-)
<calc> LaserJock: its a new seagate moments 7200.4 500gb g-shock drive
<calc> about to rip the tiny 160gb drive out of my x200 to replace it with this
<Keybuk> kirkland: I think I already removed it ;)
<Keybuk> I just didn't regenerate the meta package
<Keybuk> slangasek: if you want to remove powernowd from the archive ... <g>
<tkamppeter> pitti, I have seen that you have passed the -proposed package of CUPS to the updates. Cab you take the next one from the queue to -proposed? It is supposed to fix 3 or 4 bugs.
<kirkland> Keybuk: so you have :-)
<pitti> tkamppeter: I'll attack the SRU soon again, yes; these days are just pretty crazy due to FF
<jdstrand> kirkland: for LPUID it should be the requester, not the acker, correct?
<Keybuk> pitti: btw, have you rebooted your laptop in the last couple of days?
<Keybuk> if not, want to check something
<tkamppeter> pitti, yes, everyone is rushing in the last stuff, I have done arouind 20 dputs this week.
<pitti> Keybuk: I reboot every day
<pitti> Keybuk: I have some recent trouble with suspend/hibernate
<Keybuk> pitti: damn
<Keybuk> pitti: I guess you have a /sys/devices/system/cpu/cpu0/cpufreq ?
<kirkland> jdstrand: i put the acker, if the requestor doesn't have commit priv's
<pitti> Keybuk: yes; that didn't change in ages, AFAIK
<pitti> (the structure, anyway)
<kirkland> jdstrand: ie, the person we can track down and ask about it, if the sync goes boom :-)
<jdstrand> kirkland: is that policy documented somewhere?
<Keybuk> pitti: are you sure?
<Keybuk> pitti: my laptop stopped loading a cpu scaling driver a while back
<Keybuk> so it wasn't actually working
<pitti> Keybuk: well, admittedly it's the first time I looked into it in jaunty
<kirkland> jdstrand: I think that's what Riddell advised me in #ubuntu-release
<kirkland> Riddell: can you please confirm that I understood you correctly?
<pitti> Keybuk: last time was probably in intrepid or even hardy
<kirkland> jdstrand: if Riddle confirms, we should probably add that to the wiki page
<jdstrand> kirkland: yes, I shall
<pitti> Keybuk: I'm just 100% sure that the actual CPU scaling has always worked
<Keybuk> pitti: what does scaling_driver say?
<pitti> thus I had no real reason to poke it
<pitti> Keybuk: acpi-cpufreq
<pitti> Keybuk: I still have powernowd installed; shouldn't I?
<Keybuk> pitti: that at least has likely changed
<Keybuk> pitti: you can safely purge powernowd
<pitti> Keybuk: $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<pitti> ondemand
<Keybuk> pitti: powernowd's init script _probably_ preferred speedstep-centrino for your machine
<pitti> I think that was "userspace" in ancient days; is that possible?
<Keybuk> pitti: powernowd does require that to be userspace
<Keybuk> but the powernowd init script always set it to "ondemand" in recent years and didn't start powernowd
<Keybuk> now we just changed the kernel config to be right to begin with ;)
 * pitti purges
<pitti> I'm glad for every bit that doesn't slow down my boot ime :)
<Riddell> kirkland: "first person who knows what they're doing" generally, so if the requester doesn't have upload right but is an active contributor who's likely to sort things out if there's a problem that's ok
<Keybuk> do you still have freaky I/O ?
<Riddell> jdstrand: ^^
<jdstrand> Riddell: ok thanks
<kirkland> Riddell: thanks.
<pitti> Keybuk: should that have changed recently?
<Keybuk> pitti: I'm slowly narrowing that down, scarily it seems to only affect certain laptops
<pitti> oh
<pitti> Keybuk: after purging powernowd
<pitti> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
<Keybuk> bootcharts I have from thinkpad users don't show it
<pitti> performance
<Keybuk> pitti: did you reboot after purging?
<pitti> no
<Keybuk> ah, the init script probably changed it on its way out
<Keybuk> as a parting gesture
<pitti> right and it doesn't scale right now
<Keybuk> reboot :p
<pitti> heh, no problem
<pitti> Keybuk: if I'm at it, I'll measure boot time with the kernel du jour
<cjwatson> syncs> TBH I just feed the sync to syncbugbot and let it sort it out
<cjwatson> which generally produces the original requestor, but ... time
<calc> does anyone know if there is a trick to ejecting an ultrabay device? i have a x200 ultrabase with a ultrabay dvdrw i want to eject but i can't determine how to make it eject
<pitti> Keybuk: so the 12 second hang from grub to usplash reduced to 5, but total grub->gdm time increased slightly to 54 seconds
<Keybuk> got a bootchart?
<pitti> Keybuk: no, I'm usually running without; if you are interested, I can do one
<pitti> Keybuk: eek, this now pulls in the entire openjdk
<LaserJock> pitti: apport-collect sounds awesome, thanks for that
<pitti> Keybuk: with -headless I just had to add a symlink to load the awt library at a different place
<pitti> LaserJock: \o/
<LaserJock> pitti: will it just be available for >= Jaunty or can it get backported somehow?
<pitti> LaserJock: it just needs python-apport (pretty much any version >= gutsy should work) and python-launchpadlib
<slytherin> calc: is that like slot loading drive?
<calc> wow hdparm returns 97MB/s for this hd
<calc> slytherin: its a removable drive for thinkpads, but i can't seem to make it remove
<Keybuk> pitti: oh, if there's a better way to fix bootchart, please upload
<pitti> Keybuk: not sure how it figures out the library locations; it crashed with "cannot find /something/awt.so"
<tkamppeter> pitti, I have a little SRU problem. See bug 303691. stek79 reports that the last fix on foomatic-rip (0ubuntu3) solved his problem. Unfortunately I have put a wrong bug number into the debian/changelog and so the bug does not get connected to the package. Can you move foomatic-rip 0ubuntu3 into -updates? Thanks.
<ubottu> Launchpad bug 303691 in cups "Intrepid, print broken with Minolta PagePro 8L printer" [Medium,In progress] https://launchpad.net/bugs/303691
<calc> my desktop drive only does 110MB/s so this laptop drive is pretty fast :)
<Keybuk> pitti: yeah, I know very little about Java :-(
<calc> is there a high speed non zero device i can use to write data to disk? urandom doesn't seem that fast at least on this machine for some reason
<calc> its only doing ~ 5MB/s
<pitti> calc: you could cat >/dev/null an .iso file, to get it into the cache, and then cp it to a new file?
<pitti> calc: or try hdparm -tT /dev/sda ?
<calc> pitti: i'm trying to write to all sectors on disk to prime it for smart
<pitti> calc: but what's actually wrong with /dev/null? I don't think it creates sparse files by default
<calc> i suppose writing zeros may be good enough for that
<calc> eg dd if=something of=/dev/sda bs=16M
<pitti> if I want to properly delete all unused disk blocks on a HD I'm about to give away, I cat /dev/zero > bigfile and rm it afterwards
<pitti> and it actually writes down zero blocks
<calc> pitti: basically i want to force writes to all sectors on the drive because smart needs that (aiui) to detect if there are any bad sectors that need to be remapped
<pitti> calc: well, at least with the drives I tried it on, dd was okay; that won't catch the reserve sectors, of course, since that's HD firmware controlled
<calc> so i think using /dev/zero probably is good enough assuming linux isn't too smart and detects the sector is already zeroed out
<calc> yes, thats fine :)
<calc> wow intrepid cd is too old to recognize my wifi :-\
<cjwatson> slangasek,directhex: I've made britney treat Recommends from packages in Section: metapackages as if they were Depends; so that mono uninstallability we had will be caught in future
<directhex> cjwatson, that's great!
<directhex> now to work on monodevelop
<slangasek> Keybuk: removing powernowd from the archive> can we have a bug report, please? :)
<pitti> Keybuk: http://people.ubuntu.com/~pitti/tmp/jaunty-20090219-1.png
<pitti> Keybuk: note that this is with GNOMEified readahead
<pitti> Keybuk: oh, and I removed l-r-m
<slangasek> cjwatson: ok, cool :)
<pitti> slangasek: do you just need grub-common in main, or grub-pc and friends as well?
<pitti> slangasek: with just -common I'd have a much less aching stomach :)
<slangasek> pitti: grub-common now, but grub-pc eventually
<Keybuk> pitti: care to try http://people.ubuntu.com/~scott/sreadahead_1.0-1~_i386.deb ?
<pitti> Keybuk: with the default readahead list or my fat one?
<Keybuk> it doesn't matter
<pitti>  Conflicts: readahead
<pitti> I see :)
<Keybuk> you'll have to --force-depends --purge readahead anyway ;)
<Keybuk> the first boot will generate you an sreadahead pack
<Keybuk> (wait for /var/lib/sreadahead/pack to appear)
<Keybuk> the second boot will use it
<pitti> yay dynamism
<pitti> Keybuk: when does it stop profiling?
<Keybuk> it profiles for one minute after boot
<pitti> is that tweakable?
<Keybuk> yes
<pitti> one minute hardly gets me to gdm
<Keybuk> edit /etc/event.d/sreadahead and add -t 120
<Keybuk> for example
<pitti> Keybuk: trying...
<pitti> Keybuk: done
<pitti> Keybuk: first run with sreadahead: grub->gdm 77s, gdm->desk 46s
<Keybuk> pitti: better with or without
<pitti> kees: second run (with pack): grub->gdm 80s, gdm->desk 16s
<pitti> erm, Keybuk ^
<Keybuk> what was it with old readahead?
<pitti> Keybuk: so, with the grub->gdm is slightly slower, but gdm->desktop is very fast
<pitti> Keybuk: including GNOME, grub->gdm 50s, gdm->desktop 20s
<pitti> ^ old readahead
<Keybuk> ok
<Keybuk> that fits my own testing
<pitti> Keybuk: is it expected that bootchart stops working with sreadahead?
<Keybuk> sreadahead is much slower than readahead if you have rotary disk
<pitti> I didn't get any
<Keybuk> pitti: probably a bootchart bug, I've noticed it fails to run sometimes
<kenvandine> pitti: bootchart works fine for me with sreadahead
<pitti> not even a log file
<Keybuk> the question, of course, is whether sreadahead can be patched to behave like old readahead when you have a rotary disk
<Keybuk> since it's collector is *far* better
<pitti> bootchart> hang on, I suck; forgot to stop it
<pitti> Keybuk: do you need bootcharts from both cases?
<Keybuk> no, just your own observation is fine
<Keybuk> proves I'm not going nuts
<Keybuk> afaict. the problem is that sreadahead reads things in by order of when they were requested
<Keybuk> whereas readahead reads things in by on-disk position order
<slytherin> may I please know who processed the sync for libdvdnav? I just finished adding all the info assuming that it was going to be FFE.
<pitti> Keybuk: sreadahead seems to have very little effect on booting; I see a lot of I/O in actual programs/daemons
<Keybuk> (sreadahead also runs in parallel, readahead runs in series)
<Keybuk> right
<Keybuk> because sreadahead is fighting with the other processes for the I/O they need
<pitti> readahead in parallel had a similar effect
<Keybuk> and sends the disk seeking all over the place
<Keybuk> pitti: now you have an sreadahead list fil
<Keybuk> change the event.d start on to "start on starting rcS"
<Keybuk> and delete/comment out the "service" line
<pitti> Keybuk: oh, the test goes on; sorry, already reinstalled readahead
<pitti> Keybuk: trying again
<Keybuk> no problem :p
<pitti> Keybuk: hm, sreadahead doesn't trigger an initramfs rebuild, should it?
<Keybuk> no
<pitti> ok
<Keybuk> (it's not done in the initramfs :p)
<Keybuk> oh, hmm, that doesn't work
<Keybuk> pitti: that might work with the updated package
<pitti> Keybuk: you mean "start on starting rcS" won't work?
<pitti> Keybuk: anyway, I'm producing more accurate numbers and bootcharts for all cases
 * pitti -> reboot again
<Keybuk> it'll work with the new sreadahead package I think
<Keybuk> heh, I just worked out why the powernowd init script doesn't work for me
<Keybuk> no, I just unworked it out again
<Keybuk> damn, it wasn't the bug I thought
<Keybuk> not that it matters, I killed it :p
<pitti> Keybuk:
<pitti>                 1st     2nd     start on rcS
<pitti> grub->gdm       82      84.5    70
<pitti> gdm->desktop    43.5    16      16
<pitti> Keybuk: so "start on rcS" is not far behind with gnome-tweaked readahead, and just about on par with default readahead
<pitti> well, I tweaked sreadahead with -t120
<Keybuk>  Keybuk: including GNOME, grub->gdm 50s, gdm->desktop 20s
<Keybuk> "on par" being 20s slower ? :p
<pitti> right, still 16 secs
<pitti> Keybuk: except that I apparently forgot to rm /etc/rc2.d/stop-bootchart
<pitti> so it created the bootchart during boot sequence, and doesn't include the desktop
<pitti> grrr
<Keybuk> heh
<pitti> so a couple of seconds were wasted on that
<Keybuk> still slower though :(
<pitti> yes, definitively
<Keybuk> much faster on SSD tho
<Keybuk> maybe I should just include the readahead code in sreadahead, so it can do both <g>
<pitti> but right now SSD is still pretty much a corner case
<Keybuk> indeed
<Keybuk> right, bbl
<pitti> Keybuk: can you re-sort the sreadahead pack by disk order?
<Keybuk> pitti: that's the idea
<Keybuk> ie. write the code to do that
<pitti> depending on whether it's rotary, of course
<pitti> Keybuk: need any further tests?
<pitti> otherwise I'll set up my desktop again and continue to do useful stuff :)
<pitti> dear compiz, please react properly to resolution changes. love, pitti
<pitti> s/compiz/gnome-panel/ as well
<Svendo> Can proftpd be compiled with mod_tls as default so there is security for the users accounts ?
<jdstrand> kirkland, james_w: fyi, sync requests are done for now
<james_w> thanks jdstrand
<Svendo> I've been wondering about this for quite a while and appears odd. Why is ubuntu the only distribution that doesnt supply proftpd with encryption ?
<infinity> Svendo: We do...
<Svendo> infinity, how ?
<infinity> Svendo: It's linked with libssl, you just need to enable encryption in your configs.
<Svendo> "proftpd -l" tells me there no mod_tls
<Svendo> Theres no such thing you know
<Svendo> Not in jaunty either as seems
<infinity> /usr/lib/proftpd/mod_tls.la
<infinity> /usr/lib/proftpd/mod_tls.so
<infinity> It's compiled as an external module, not statically.
<Svendo> So you have to add include statements you mean ?
<infinity> /etc/proftpd/modules.conf
<infinity> Just add LoadModule mod_tls.c
<infinity> Which is actually there on my config.
<infinity> I'm betting that "proftpd -l" only lists statically compiled modules, not runtime-loaded ones.
<infinity> So, yeah.  I'd say it's working as intended, just configure SSL/TLS in your configs with whatever directives you need.
<infinity> http://www.proftpd.org/docs/howto/TLS.html might prove helpful.
<Svendo> infinity: That is true, all modules are compiled as such. Hence theres trouble supporting this feature on the debian/ubuntu side.
<Svendo> Checked Jaunty dist
<Svendo> Next, why cant bind/named be run within a chroot ?
<Svendo> This is an outstanding issue with Jaunty as seems .. ?
<Svendo> and the ubuntu dists before it
<Svendo> It would be good if that can be done
<infinity> adconrad@lucifer:~$ grep chroot /etc/init.d/bind9
<infinity> # for a chrooted server: "-u bind -t /var/lib/named"
<Svendo> can you start it then ?
<infinity> (Change OPTIONS in /etc/default/bind9)
<Svendo> Check it maybe..
<Svendo> In my Jaunty it cant even read etc/localtime
<Svendo> permission denied
<Svendo> Even though its started as root
<Svendo> Read by named:named from the named process and localtime is chmod named:named
<infinity> Svendo: README.Debian has a pointer to http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html
<infinity> Svendo: Which should, I assume, hilight the files that need to be copied to the target chroot directory for it to work.
<infinity> Svendo: It's not going to magically be able to read anything it can't get at, that's sort of the point of a chroot.
<Svendo> Its not getting permission to read its own files in the chroot that is owned by the process owner. Kinda odd
<Svendo> Could it be an selinux issue with named running from another directory in /var/named/... ?
<Svendo> or /var/bind/...
<infinity> If you're running selinux, it very much could be an issue, yes.
<Mithrandir> selinux + chroots is teh fail, according to a friend of mine who played with it the other day.  Well, or at least needs a bit of tuning.
<infinity> Anyhow, this has gone far beyond a -devel discussion, and is probably more appropriate for #ubuntu
<Svendo> Mithrandir: It cant be told to relax permissions so that named can read its own files ? .. wouldnt this make selinux less secure then ?
<Mithrandir> Svendo: no idea.  I don't use selinux.
<Svendo> since bind cannot be run in a chroot
<Svendo> i try to avoid it as much as possible too
<Svendo> My trust is with the source ;)
<Svendo> Seriously, selinux can probably be good but im seeing the opposing factor
<soren> If I have a new package that I'd like to upload, what's the procedure? Should I file an FFe and have it approved before I upload?
<soren> ...and then perhaps reference the FFe in the changelog?
<ScottK> soren: Generally it's FFe before upload.
<Svendo> Mithrandir: If the modules where compiled in like in all other dists, then the ubuntu users would have encrypted sessions. Instead they have plain text.. very good :=)
<Mithrandir> Svendo: huh?
<Mithrandir> what does selinux have to do with encryption?
<Svendo> Nothing... you missed the other question i had 15-20 lines above ?
<Svendo> <infinity> /usr/lib/proftpd/mod_tls.la
<Svendo> <infinity> /usr/lib/proftpd/mod_tls.so
<Svendo> it was a few lines before actually
<soren> ScottK: Thanks.
<Mithrandir> Svendo: no idea, I couldn't care less about FTP.
<Mithrandir> I care less about FTP than I care about gopher.
<Svendo> You are a gopher :=) ... dunno the meaning of that
<Svendo> go pho her ? :=)
<Mithrandir> Svendo: http://en.wikipedia.org/wiki/Gopher_(protocol)
<Svendo> Like in Zak McKracken ?
<Svendo> http://www.youtube.com/watch?v=bcQgWV4tPOQ :)
 * directhex attacks Svendo with a bobby pin & some VISA codes
<Svendo> www.celetania.com
<Svendo> directhex: sorry kidalot, didnt see you over that minute wall
<Svendo> Mithrandir: like a sock on a trumpet! ;)
<Svendo> YeeHaw! /tehb0rk
<LaserJock> cjwatson: I just tried a d-i install from the current Jaunty DVD and it still has all the preseeding
<cjwatson> Svendo: you're going increasingly off-topic for this channel
<cjwatson> LaserJock: hmm, so it does
<Svendo> cjwatson: Interresting since i havnt said anything for 30 minutes :)
<cjwatson> Svendo: I was away; but nevertheless
<Svendo> youre sorry ?
<cjwatson> no, I am not
<Svendo> Go fuck yourself
<cjwatson> (and don't come back)
<Pici> cjwatson: it should be +b *!?=svendo@ip-187-200-241-92.dialup.nmt.net
<cjwatson> what's the difference?
<Pici> Well,  *!Svendo@ip-187-200-241-92.dialup.nmt.net wont match Svendo!n=Svendo@ip-187-200-241-92.dialup.nmt.net
<cjwatson> oh, right
<cjwatson> will that do?
<scizzo-> you learn something new everyday
<cjwatson> LaserJock: my own stupid mistake, I think I've fixed it now
<cjwatson> (perl -ne ... vs. perl -ni -e ...)
<LaserJock> cjwatson: ok, great
<Pici> cjwatson: That'll work
<ScottK> doko: boost1.35 (at least, haven't checked the others yet) now FTBFS due to the python 2.4/2.5 -> 2.5/2.6 change.  Can I go ahead and fix that or is there more stuff that you need to upload first?
#ubuntu-devel 2009-02-20
<slangasek> mathiaz: ping
<mathiaz> slangasek: hello
<slangasek> mathiaz: hi, is it ok for me to go ahead and assign bug #305264 to you, regarding openldap working around the gnutls behavior change?
<ubottu> Launchpad bug 305264 in openldap "gnutls regression: failure in certificate chain validation" [Undecided,Invalid] https://launchpad.net/bugs/305264
<mathiaz> slangasek: ok - I'm already assigned to the jaunty task though.
<slangasek> mathiaz: rather, I just assigned it to you after asking the question here ;)
<slangasek> Keybuk: do you have an ETA for uploading udev 137-3, or could I go ahead and do the upload?
<Keybuk> slangasek: please don't
<Keybuk> what from 137-3 are you after?
<slangasek> Keybuk: er, the RC bugfix that's the only change in bzr?
<Keybuk> that's not in bzr yet
<Keybuk> it's in udev 138
<Keybuk> which I haven't fully merged
<slangasek> Keybuk: ok; the bzr log / changelog say otherwise
<Keybuk> it came out today, I'll most likely fix it up tomorrow
<Keybuk> I put the bug# in the changelog to remind me which it was ;)
<Keybuk> I do that
<Keybuk> message:
<Keybuk>   Apply NAME rules when string_escape=none.  LP: #325690.
<Keybuk> modified:
<Keybuk>   debian/changelog
<Keybuk> --
<Keybuk> the changelog was all that was modified
<slangasek> oh; the previous commit wasn't related?
<Keybuk> partially related
<slangasek> ok
<Keybuk> it's not complete and introduces new bugs by being a partial merge
<slangasek> right, good reason for me not to upload it. ;)
<slangasek> tomorrow's fine, just wanting to make sure it's on track for alpha-5
<Keybuk> I was just waiting for the upstream release
<TheMuso> dtchen: Seen this bug? bug 326596, I vaguely remember why in Hardy we played the logon sound through a newly connected audio device, but I can't remember why.
<ubottu> Launchpad bug 326596 in alsa-driver "If system sounds is disabled don't play system music" [Undecided,New] https://launchpad.net/bugs/326596
<TheMuso> s/vaguely remember why/vaguely remember/
<dholbach> good morning
<dholbach> does anybody else get gnome-terminal crashes as well?
 * iulian is not getting any crashes.
<dholbach> bug 330621 and bug 331462 is what I get
<ubottu> Bug 330621 on http://launchpad.net/bugs/330621 is private
<ubottu> Bug 331462 on http://launchpad.net/bugs/331462 is private
<dholbach> it's mildly annoying
<greg-g> I think pedro was getting some today, actually
<dholbach> it's not easily reproducable but every now and then when I have the gnome-terminal with a few tabs open and ctrl-d-ing out of one of the tabs it takes down the whole thing
<dholbach> one of the crashes was within gnome-terminal itself, the other one in vte
<greg-g> bug 331740 is pedro's from today
<ubottu> Bug 331740 on http://launchpad.net/bugs/331740 is private
<dholbach> interesting, yet another one
<greg-g> yeah, very weird
<greg-g> but time for bed for me. g'night dholbach
<dholbach> sleep tight greg-g
<pitti> Good morning
<mok0> Packages which are new in Debian Unstable, are they automatically sync'ed when Jaunty+1 opens or does it require a sync-request?
<pitti> mok0: they'll get all synced; it's manually triggered, but we'll sync them wholesale
<mok0> pitti: ok, thanks, exactly what I wanted to know
<\sh_> moins
<\sh> jdstrand: bug #331410 complete...
<ubottu> Launchpad bug 331410 in net-snmp "CVE-2008-6123: not fixed in latest security releases" [Undecided,In progress] https://launchpad.net/bugs/331410
<Lure> pitti: are you pushing all the hal-info changes upstream, or should we push it individually? I would like to get quirk from bug 328522 into hal-info...
<ubottu> Launchpad bug 328522 in hal-info "HP nw8440 resumes with blank screen due to vbetool hang" [Medium,Triaged] https://launchpad.net/bugs/328522
<pitti> Lure: I usually commit them directly upstream, yes
<Lure> pitti: ok, will then wait for you to review and commit
<Lure> pitti: thanks
<pitti> Lure: if you want you can send them to the hal mailing list, but if you attach it to a bug and sub me, that's fine too
<Lure> pitti: subscribe or assign?
<pitti> either
<Lure> pitti: done
<pitti> Lure: I'm always a bit hesitant to change existing quirks, because they obviously worked for someone else
<pitti> but that might have been with older kernels, x.org, etc.
 * pitti arghs at git
<pitti> what's the git equivalent of bzr blame -r 407 file.c ?
 * pitti looked at git rev-list --help, but that didn't really help
<amitk> pitti: git-blame?
<pitti> amitk: right, sure, but specifying "everything before this commit"
<pitti> but I found a workaround now
<pitti> git blame, find the last commit, git log, look up the previous commit, and
<pitti> git blame 123deadbeef file.c
<pitti> that seems to work
<ion_> Would git blame lastcommitid^ foo.c work?
<pitti> what does ^ do?
<ion_> It should refer to the previous commit.
<pitti> I want "blame earlier versions up to, but not including, 1234"
<pitti> ah, nice
<pitti> ion_: that works, thanks
<pitti> Lure: ok, archaeology done and committed, bug updated
<lool> doko: I'd like to push a glibc to the archive with support for vfp hwcaps
<doko> lool: sure, please go ahead. are test results the same as for the normal build? could you add a file for the expected test results?
<lool> doko: I'm not adding the vfp pass yet, that one hangs
<lool> doko: But adding the vfp hwcaps allow to proceed to enablement of other libs
<doko> ok
<cjwatson> hmm, still no testers for bug 313218 ...
<ubottu> Launchpad bug 313218 in glibc "IPV6 causes slow internet access" [Critical,Confirmed] https://launchpad.net/bugs/313218
<lool> cjwatson: I have IPv6, internet is not particular fast, but I don't get the errors the people report
<lool> cjwatson: Is there a clear way to see whether I'm affected?  I guess the system call in the strace will be the same
<lool> Actually the fact that I have IPv6 connectivity is likely to prevent me from reproducing if I understand the fedora bug correctly
<cjwatson> lool: the problem is for people who don't actually have real IPv6 connectivity, especially for those whose routers do funny things with it
<cjwatson> lool: however, if you have real IPv6 connectivity, I'd appreciate you testing the package in my PPA to ensure that it doesn't break it
<lool> Uh your ppa doesn't have the same pathname
<cjwatson> lool: hmm?
<lool> cjwatson: I copied my sources.list entry for my ppa for yours, and it failed; it surprized me; it seems we now have a /ppa in the URL; the old URL works for me still
<lool> Anyway, irrelevant, ignore me
<cjwatson> oh, yes, that was a relatively recent change
<cjwatson> I don't use my PPA all that often so it was probably generated from scratch
<soren> lool: Yes, it's the first step on the way to allowing users to have more than one PPA.
<lool> cool
<fta> did something change /wrt cdbs and python? some of my packages now ftbfs because of missing python2.6
<fta> http://launchpadlibrarian.net/22893842/buildlog_ubuntu-jaunty-amd64.gwibber_0.8-0ubuntu1~jaunty_FAILEDTOBUILD.txt.gz
<soren> fta: Perhaps you're missing a build-dependency on python-all-dev?
<fta> sommer, it used to build fine, it started to fail 2 days ago
<fta> oops
<fta> soren, ^^
<fta> sommer, nm
<cjwatson> well, yeah, that's when python2.6 was added to the set of supported python versions ...
<gnumdk> Hello
<soren> cjwatson: How is that defined? I mean... How does a package know that it now has to try that as well?
<soren> cjwatson: I was thinking python-central, but its changelog doesn't seem to mention anything about it.
<gnumdk> I'm using jaunty for testing but i can't get Xorg to be as fast as Intrepid... I've looked a lauchpad, EXA is slow, UXA is slow and XAA just give me a kernel panic
<fta> cjwatson, I build-dep on python python-central python-distutils-extra, it's a bit rude to suddenly fail on python2.6 setup.py
<cjwatson> soren: python-defaults
<cjwatson> $ pyversions -s
<cjwatson> python2.5 python2.6
<soren> cjwatson: I see. Thanks.
<cjwatson> fta: hardly a matter of rudeness, I don't think the definitions of the build-dependencies have changed ... it's just the sort of thing you only actually notice during relatively small periods
<cjwatson> i.e. whether your package is building extensions for things that aren't pulled in by build-deps
<cjwatson> as soren says, sometimes python-all-dev is the right answer, or sometimes you only want extensions for a single version; if in doubt, ask doko
<fta> well, it's just too bad that I have package in NEW for a few days that will fail because of this. bad timing
<cjwatson> you can upload a new version while it's in NEW
<fta> seb128, don't bother reviewing gwibber, it will fail because of the new python ^^ :(
<pitti> jdstrand: ^
<pitti> fta: jdstrand's archive day today
<seb128> fta: well that can be newed anyway and you can fix the build in a new revision
<directhex> aha, i wondered who had done my mono-addins sync
<pitti> directhex: the bug should say
<directhex> should fix bugs in f-spot et al
<directhex> pitti, it was jdstrand - but i didn't recognise the name
<fta> seb128, new push or new version?
<cjwatson> change the version number, it's better practice anyway
<Mez> is there a bugjam channel ?
<dholbach> Mez: it'll just be #ubuntu-bugs
<Mez> ah, kk
<Mez> well, we're already here
<doko> fta: yes, sorry, didn't send the email yet. please could you file a bug report for this package and assign it to me?
<fta> doko, hi! it's not in the archive yet. it's still in NEW. I've fixed it and i'll re-submit once i'm sure it's fine (it = gwibber, the micro blogging client for gnome
<asac> fta: i would think that NEWing gwibber still makes sense
<asac> otherwise it will all start from scratch
<slytherin> not sure if anyone has already noticed, but openjdk-6 build on armel is blocking all other builds that might be already queued up on that buildd. Anyway to requeue them on other servers?
<fta> asac, what do you mean? let it fail and update afterwards? the fix is ready, i just need to test it on older dists
<asac> fta: yes. either just upload new gwibber or wait till it fails and reup ;)
<asac> fta: didnt know you have fix ready for upload
<highvolt1ge> ogra: nice post
<ogra> highvolt1ge, which one, i wrote multiple :)
<highvolt1ge> ogra: the one about update-manager
<ogra> ah, thanks :)
<Keybuk> I discovered with glee this morning that purging notify-osd puts notifications back the way they were
<ogra> ah, nice
 * ogra did get the ugly little windows all over the desktop last time he tried that
<Riddell> calc: any change in the OO icons recently?  my spelling icon has stopped being crystal http://www.kubuntu.org/~jriddell/tmp/oo.png
<Keybuk> ogra: I get the windows all over the desktop *with* notify-osd
<ogra> its fun to get up in the morning and see that you got a small window for every mail you revied overnight
<ogra> and i usually get between 150 and 300 /night
<seb128> Keybuk: changing the notification will not stop update-manager to be auto-opened if that's what you are speaking about
<seb128> ogra: disable the upstream mail-notification option, that's being worked and will not be activated by default
<Keybuk> seb128: it will not; it stops me getting a screenful of dialog boxes and those insidious new notifications
<Keybuk> I changed the gconf key to stop update-manager being auto-launched
<seb128> Keybuk is reluctant to changes apparently ;-)
<ogra> seb128, yeah, i found that after a week of a click orgy every morning :)
<Keybuk> seb128: not so much
<Keybuk> I have all my notifications very personally configured anyway
<Keybuk> and that's in the *opposite* direction to what the DX team have taken
<Keybuk> so all this new stuff killed all my preferences, and starting throwing pop-ups, dialogs and bubbles all over my screen again
<seb128> bubbles go in a specific corner here
 * kees is really motivated to test the dx stuff now. :)
<ogra> haha
<seb128> which is what is supposed to happen if I understand the thing correctly
<Keybuk> seb128: I don't want them at all!
<seb128> uninstall notify-osd and notification-daemon?
<Keybuk> a bubble every time someone messages me on IRC is about the most distracting thing I can think of
<Keybuk> <Keybuk> I discovered with glee this morning that purging notify-osd puts notifications back the way they were
<seb128> don't enable the libnotify option for your IRC client?
<kees> Keybuk: what were you and pitti comparing with boot speed tests the other day?
<Keybuk> kees: readahead vs. sreadahead
<seb128> I like the volume bubbles in the new system I've to admit, I'm not so much convinced about other messages etc
<kees> Keybuk: sreadahead was the stuff arjan worked on for the ssd?
<Keybuk> right
<ogra> seb128, volume bubbles ?
 * ogra doesnt have any display for vol up/down at all anymore
<ogra> same for brightness
<seb128> Keybuk: is there any known issue with bootchart atm btw? I can do standard bootcharting to gdm but if I use nostop and try to stop it after login it fails and don't create a chart
<seb128> ogra: works for me
<kees> Keybuk: and plain readahead won out? i.e. no change on our end?
<ogra> strange
 * ogra checks for updates ... 
<Keybuk> kees: on rotary disk, which was not a surprise
<Keybuk> seb128: yeah, it sometimes seems to crash - haven't debugged it yet
 * kees nods
<Keybuk> seb128: it'd probably work if you did it again
<Keybuk> kees: more interesting will be to see whether I can patch sreadahead in such a way that it's good for both
<ogra> gah, u-m doesnt show the number of avaliable updates anymore ?!?
<Keybuk> (with a toggle option)
 * ogra scrolls and counts ... how annoying
<kees> Keybuk: ooh, that'd be fun :)
<Keybuk> ogra: you care? :p
<ogra> usually, yes
<ogra> but i agree my mother wouldnt ...
<ogra> but i like to see how much i get for my money ... thats the german in me :P
<seb128> ogra: how does that matter? you get the number while it's downloading
<ogra> seb128, *after* i clicked, yes :)
<ogra> i like to know it before
<ogra> so i can decide if i postpone or if its worth it
<seb128> it displays what it will download
<seb128> which is the useful thing to know
<ogra> yeah, means i have to scroll around
<seb128> what and how much rather
<seb128> you decide on numbers? weird
<seb128> I usually either upgrade or look to items in the list
<ogra> having eh number on first look was an intresting info
<Keybuk> I don't do any of those
<seb128> having 60 or 70 updates doesn't make a real difference
<ogra> but i might be special that i want to know it, as i said above
<Keybuk> I upgrade just before going to do something when it's really important that my laptop work properly
<ogra> having 50 or 250 makes one
<seb128> not so much if they are 700 octets each
<seb128> how much you will download is rather what you want to know no?
<ogra> no, i want to know if its 200 packages that hog my system with postinst and unpacking for 20min
<seb128> again that's not the number that makes a difference there but what they do
<ogra> the download doesnt hog my CPU and ram
<seb128> if you have to rebuild caches, etc that will take a while
<ogra> right
<seb128> if those don't do anything that will be quick
 * ogra needs to reboot after upgrade, else he will forget about it :P ...
<ogra> bbl
<Keybuk> cjwatson: how do I do an "OR" in the seeds?
<cjwatson> Keybuk: you don't
 * directhex submits his NM application
<Keybuk> cjwatson: oh, I thought it supported that
<Keybuk> hmm
<seb128> directhex: hey, good work on mono in jaunty ;-)
<cjwatson> no, sorry
<Keybuk> cjwatson: can you depend on a virtual package?
<cjwatson> you need to select one entry that supports both, or have a metapackage or something
<cjwatson> I think so
<Keybuk> how does it determine which one is pulled in by default?
<cjwatson> but exactly what happens is not all that well-defined
<cjwatson> the usual "promote from other seed" rules, followed by random
<directhex> seb128, thanks - much as i helped a bit with mono in intrepid in the last few weeks, i think jaunty is the release i'm going to feel responsible for in that area
<cjwatson> seb128: number of packages does make a difference to some extent, because it affects number of forks required
<seb128> directhex: that's very nice to have somebody responsive for that, mono was not really actively worked until jaunty
<directhex> seb128, and it wouldn't be remotely as good as it is without help frmo those named in my message to ubuntu-devel (plus the sponsors & archive admins who put up with me)
<seb128> directhex: right, still you did a very useful job coordinating those and letting know the lists about the changes, etc
<Keybuk> is expiration not working on Launchpad?
<Keybuk>  This bug report was marked for expiration 15 days ago. (find out why)
<directhex> and slangasek's been very helpful too
<slytherin> ogra: which post of yours was highvolt1ge was referring to?
<seb128> Keybuk: there is no autoclosing no, they did it once and got flamed for it because there was buggy closing cases and stopped after that
<ogra> slytherin, the "update-manager jumps in your face every two days" one
<directhex> on a related note, gmime development seems to have come back from the dead, so the last thing pulling in mono 1.0 classlib onto the jaunty cds should soon be cleaned
 * ogra really really wants that mail icon to vanish from his panel if there is no unread mail ... hrm
<Lure> pitti: thanks for hal-info commit
<kwwii> if anyone wants to see the new usplash and gdm, sponsor it in main :)
<ikonia> kwwii: what do you mean a new uplash and gdm ?
<ikonia> a new version, a totally new product, or a theme ?
<ogra> themes
<kwwii> ikonia: just new themes :(
<directhex> an usplash which doesn't approach widescreen in a very very silly way?
<directhex> oh, no, no such luck :/
<kwwii> well, I did include two bigger pics, so it should be somewhat improved
<kwwii> and plymouth isn't ready just yet
 * directhex squashes kwwii to 4:3 then stretches him back to 16:9
<directhex> hello jelmer!
<ikonia> I'd be more interested in seeing development of the actual products, rather than just themes
<ikonia> themes aren't really a great use of developer resource, rather artists
<ogra> oh, cute ... now i know why i dont see my notificatils ... they actually pop under the panel aligned to the top of the screen
<ogra> *notofocations
<ogra> bah
<directhex> ikonia, you still doing lots of HP-related work? https://launchpad.net/ubuntu/+source/moon/1.0-0ubuntu2/+build/874173 ;)
<ikonia> directhex: lets see, and "yes2
<ikonia> directhex: I'll give that a go if you want some feedback
<directhex> ikonia, is hppa ubuntu big or little endian? the cpu seems to cope with both
<ikonia> big would be better
<ikonia> (in my opinion)
<ikonia> as in built for big
<ikonia> where is your ia64 port ?
<ikonia> come on
<ikonia> your slacking
<directhex> hm. there's a known issue w/ multimedia codecs on bigel arches. i'd love to get it fixed, but have no bigel, and upstream don't exactly have it as a priority
<directhex> ikonia, the ia64 buildd is heavily oversubscribed
<ikonia> ha ha ha
<ikonia> I can provide you access to some bigel boxes if you want ?
<ikonia> no shying away now
<kagou> bryce, for informations,  I'm trying to build a package https://edge.launchpad.net/~vetsel-patrice/+archive/ppa for Bug #325394
<ubottu> Launchpad bug 325394 in xserver-xorg-driver-ati "[RV770 HD 4850] ATI Radeon HD 4850 not supported - white screen and system freeze" [Unknown,Fix released] https://launchpad.net/bugs/325394
<directhex> but since you asked...
<directhex> jms@orac:~> file moon-1.0/src/.libs/libmoon.so.0.0.0
<directhex> moon-1.0/src/.libs/libmoon.so.0.0.0: ELF 64-bit LSB shared object, IA-64 (Intel 64 bit architecture), version 1 (SYSV), not stripped
<ikonia> directhex: touche' nice
<directhex> ikonia, i'm no c++ developer, i'm not well equipped to try & solve the issue myself
<ikonia> wimp,
<directhex> ikonia, if i hear bug reports from users, then i have something to beat upstream with
<ikonia> (me neither though)
<ogra> Keybuk, "- Loop devices now get persistent disk links too." does that mean we finaly have partition support there ?
<ogra> *fnially
<ogra> hrm ... i should stop correcting myself today, it only gets worse
<directhex> hm, looks like there's a 3/50 chance of being assigned an AM who knows me, assuming (falsely) that AMs are assigned randomly
<Keybuk> ogra: no
<ogra> ah, sounded like
<Keybuk> it means if you mount a file with -o loop, a /dev/disk/by-{uuid,label} symlink will appaer for it
 * ogra is tired of having to compute offsets manually
<ikonia> directhex: if he knows you - your screwed
<directhex> ikonia, hm?
<soren> ogra: kpartx.
<ikonia> directhex: just kidding
<kagou> bryce, I hope that it will solve the problem and that we can have it inluded in alpha5
<directhex> ikonia, i don't spot anyone on the AM list who i know hates me, so that's a good start
<ogra> soren, oh, thanks !
<cjwatson> ikonia: kwwii is an artist, so it's a bit silly to tell him off for working on themes :)
<soren> ogra: It's what all the cool kids use.
<ogra> soren, well, i'm behind times as always :)
<ikonia> cjwatson: I meant for development, themes are always welcome
<directhex> cjwatson, neat. free software needs more talented artists
<ikonia> concur
<directhex> still think there are plenty of talented emos on deviantart as an untapped resource :p
<Keybuk> it must be half term
<ikonia> it kills me
<ikonia> there are some great ones on there
<directhex> to be fair, whomever designed the hardy heron wallpaper deserves cake. that looked awesome
<ikonia> one of the best
<ikonia> agreed
<ikonia> I liked the cracked wall one too
<ogra> so send flowers to kwwii for both then instead of attacking him ;)
<ikonia> I didn't attack him
<ogra> he deserves all the kudos
<ikonia> he's getting public kudos here if he designed them
<lool> doko: Pushing glibc; I've put the branch up for review as well
<lool> There's a larger debdiff between the .dscs than just my changes, I think glibc doesn't clean properly, so my upload drops some files in control.in etc.
<lool> it's a bit scary
<lool> But fakeroot debian/rules debian/control doesn't change control, so I think it's fine
<cjwatson> I generally go to some effort to sync up those control files even if clean doesn't do it properly
<lool> cjwatson: By removing the things which should be removed, right?
<lool> Cause that's what I'm uploading
<lool> I guess I could add the clean:: snippet to actually remove them
<cjwatson> lool: no, what I usually do is make sure that the diff between .dscs is the diff between the bzr branches, i.e. copy in those files from a previous source package if necessary
<cjwatson> lool: I leave it to somebody else to work out whether they should actually be removed or not
<lool> Wow, shutdown actually works from startx sessions now!  \o/
<lool> cjwatson: Hmm I'm afraid I didn't do that; should I go cancel my merge request, add the files in a new branch, merge my previous branch in it, and resubmit the new branch for a merge request?
<doko> lool: which files are different?
<fta> seb128, fyi, a new gwibber is ready in NEW, whenever you have time to re-review it. thanks.
<lool> glibc-2.9/debian/control.in/libc0.3
<lool> glibc-2.9/debian/control.in/libc6.1
<lool> glibc-2.9/debian/control.in/libc6
<lool> glibc-2.9/debian/control.in/libc0.1
<seb128> ok
<lool> New compiz is great
<doko> they can be kept, but we don't need to check those in
<lool> Stops moving the background around
<lool> doko: I think cjwatson wants to have a commit in the history representing the uploaded source exactly
<Silicium> hi there
<Silicium> where is the bootsplash .so saved on the live CD?
<Silicium> in the initrd or directly in the kernel?
<calc> Riddell: i changed the human set, but not the other sets
<calc> Riddell: do you know when it changed, was it just when 3.0.1 was released?
<Riddell> calc: changed when I did an install from monday's daily CD build
<Riddell> I hadn't updated for a while before that
<calc> Riddell: oh ok, well the crystal icon set may have had that icon removed, i know a lot of tango icons went away at least since 2.3.1, when i updated the set in bzr i noticed that part
<PecisDarbs> pitti: got time to check out last patch for that sl-modem-daemon init script?
<pitti> PecisDarbs: on my list, release team meeting right now
<RenatoSilva> sorry but developers may know the answer
<RenatoSilva> is there a way to make update manager run an apt-get autoremove & autoclean after applying updates?
<RenatoSilva> does it have any trigger mechanism for running commands?
<kirkland> apw: howdy, did you have a chance to check out my patch to test-suspend?
<apw> kirkland, not yet
<kirkland> apw: cool.  fwiw, i have a draft of a blog post, with instructions on how to run test-suspend --server, i'll wait to publish until you can review and update the script as posted on people.ubuntu.com
 * calc got a bug about more gnome craziness, apparently gnome shell wants to use the name of the desktop file itself to name apps, not the name or genericname in the desktop file, but the freaking name of the file itself
<calc> and so they decided to file a bug against OOo in Ubuntu because they didn't like what the ooo desktop files were named
<azeem> bug number?
<calc> please Gnome people stop this insanity there are standards for a reason
<azeem> calc: gnome shell isn't gnome, you know
<calc> azeem: its intended to be in gnome 3.0
<calc> aiui
<calc> bug 331768
<ubottu> Launchpad bug 331768 in openoffice.org "Use standard name for .desktop files" [Undecided,Invalid] https://launchpad.net/bugs/331768
<azeem> well maybe
<azeem> but you can't blame gnome people for it at this point
<calc> so in Ubuntu 10.04
<cjwatson> doko: are you going to merge lool's glibc branch or shall I? seeing as it's been uploaded and all :)
<calc> azeem: so gnome shell isn't being written by gnome people just out of tree currently?
<calc> azeem: aiui it is being written by gnome people
<calc> azeem: and its hosted on gnome.org
<azeem> sure, but that doesn't mean it automatically gets included I guess; they still need to get it approved
<pochu> and anyway it wasn't the developers who reported that bug :)
<pochu> (it's still a gnome-shell bug and not a OOo, of course ;)
<calc> azeem: which doesn't seem to take much, so blaming gnome people who write gnome things that will go into a future gnome release for not following the standards they helped write is reasonable ;-)
<azeem> calc: maybe it's an optimization; one stat() vs. parsing .desktop files
<calc> azeem: you need to parse anyway for l10n
<ogra> calc, mark it invalid for openoffice ... it follows todays xdg standard while the app developers of that app seem not to ... so they should enhace the standard first if they want it differently
<calc> and if they are throwing away l10n then god help them
<calc> ogra: yea
<ogra> azeem, right, but still that needs to go into the widely accepted standard first
<ogra> otherwise that bug is just noise
<calc> and you aren't going to get names with spaces in them so the conversion to space will need to be documented, etc
<calc> i have a feeling when they try to get the spec updated whoever is in charge of it will remind them to lay off the crack
<cjwatson> wouldn't it be more productive to forward this bug to the gnome-shell developers, rather than flaming them here?
<cjwatson> it could easily be a simple bug, which we all suffer from
<calc> cjwatson: they filed the bug (aiui) against OOo, just mentioning the craziness of it
<calc> at least the person filing the bug seemed to indicate he was involved with gnome shell
<ogra> so mark it invalid for oo.o, open a task for gnome-shell
<ogra> and then forwrd it
<lool> cjwatson: I think you could merge it after adding the files from the previous glibc; that would require less steps then me doing the ones I described
<cjwatson> the problem about adding them is that I think they get created/removed in some circumstances, and such files are awkward to add to bzr
<calc> yea the bug reporter is Milan Bouchet-Valat who is a gnome shell dev
<Keybuk> cjwatson: so I think I'm going to put the console and keyboard stuff on the shelf
<Keybuk> at least for jaunty
<cjwatson> Keybuk: oh?
<Keybuk> cjwatson: some other changes have made them sufficiently fast that they're not appearing on most of my bootcharts
<Keybuk> so it's merely inelegant that we do it so many times
<Keybuk> and since we'll likely use KMS in kinky, it'll all change all over again anyway
<Keybuk> so we may as well just get it right for KMS
<cjwatson> Keybuk: hmm, ok, as long as it isn't just an anomaly that they aren't showing up
<cjwatson> Keybuk: what's the current time for comparison?
<Keybuk> cjwatson: on a mini 9 with metacity: 25s
<cjwatson> bingo
<cjwatson> with compiz?
<Keybuk> with compiz 29s
<Keybuk> so I'd rather spend some time getting compiz to go faster instead of futzing around with something that we'll have to break again next release
<cjwatson> are we considering this to meet the agreed target or not?
<cjwatson> I'm assuming not since it isn't stock
<robbiew> Keybuk: so we just need mvo to squeek out 4 sec of compiz performance :P
<Keybuk> cjwatson: I would like to see 25s with compiz
 * cjwatson nods
<Keybuk> X is up in 12s
<Keybuk> I have a personal goal to get X up in 10s
<Keybuk> because I like round numbers ;)
<cjwatson> xkbcomp?
<Keybuk> right, that's one of the patches I have to get this 25s
<directhex> ... kinky?
<doko> cjwatson: yes, I can do that (tomorrow)
<robbiew> directhex: Keybuk's nickname for the yet to be announced 9.10
<cjwatson> doko: oh, the reason I ask is that I've confirmed 313228 and wanted to upload that today
<directhex> robbiew, i dread to think what a kinky koala looks like
<cjwatson> doko: so if you're ok with me pulling lool's branch I could unblock myself
<doko> cjwatson: please merge, leaving in 15min today
<cjwatson> ok, will do
<Mithrandir> Keybuk: 8 is rounder than 10. :-)
<mvo> robbiew:  asac promised me some computer time on his mini9 :) that should make it possible to test stuff for me
<Keybuk> Mithrandir: true, but I think I can only get 8 by ripping out apparmor
<Keybuk> and kees would rip out my intestines for that
<Mithrandir> mmm, brains.
<robbiew> mvo: great thnx!
<apw> kirkland, just reviewed that patch
<apw> i think it makes more sense to treat --full as a collective enable
<apw> and make --server the same
<kirkland> apw: k
<apw> so rather than having --server --full
<kirkland> apw: that's fine
<apw> and have server just turn off some of full
<kirkland> apw: crossed my mind in retrospect
<apw> it makes more sense to make --full == --desktop
<apw> and --server == --server
<kirkland> apw: right
<apw> and enable what makes sense there, which is just exhaustive right now
<kirkland> apw: i agree with that
 * apw does that
<pitti> Keybuk: hm @ bug 332017
<ubottu> Launchpad bug 332017 in linux "Significant performance regression in 2.6.28-8.24 due to ondemand governor" [Undecided,New] https://launchpad.net/bugs/332017
<Keybuk> pitti: since we were using ondemand before -> Invalid
<ogra> well, wernt there machines where performance was used by accident ?
<Keybuk> no, there were machines which had no scaling driver by accident
 * ogra thought he read that in the thread
<ogra> which results in full performance, no ?
<ogra> since they dont know how to scale down
<calc> where do bugs about problems resuming belong?
<lool> doko: glibc ppc build failed; not sure what to do about it except retry -- it built in ppa
<pitti> lool: it failed for me the first time as well, in a test case (small number difference)
<pitti> lool: I just retried it, and it worked
<cjwatson> I'm going to upload glibc again anyway, so you can just let me have the failure if you prefer ;-)
<apw> Keybuk, i'd ask him for numbers
<Keybuk> apw: exactly
<lool> cjwatson: Ok
<slangasek> apw, Keybuk: numbers> are you talking about 332017?
<apw> indeed
<Keybuk> yes
<slangasek> apw, Keybuk: in that case, the submitter is maxb in this channel
<slangasek> if you want to ask directly :)
<maxb> bug 332017
<ubottu> Launchpad bug 332017 in linux "Significant performance regression in 2.6.28-8.24 due to ondemand governor" [Undecided,Invalid] https://launchpad.net/bugs/332017
<maxb> ah, yes
<apw> so what was the test case, and how much slower was it?
<maxb> My "test" case was switching between channel tabs in xchat - performance: effectively instantaneous redraw; ondemand: the lines of text noticeably appear one-by-one from top to bottom, taking approximately a complete second to finish
<Keybuk> maxb: how had you overridden the default to performance before?
<maxb> other apps (gnome-terminal, firefox) were also impacted, but the xchat use-case was the most clear cut
<maxb> I had not overridden it before, the problem started when the kernel config changed in -8.24
<Keybuk> could you reboot into the previous kernel
<Keybuk> making sure you still have powernowd installed
<maxb> Previous as in -8.23, right, not -7.x?
<Keybuk> maxb: right, 8.23 is fine
<Keybuk> if you don't have that, but have a -7, that's fine too
<maxb> -7.x would be easier but I accept that it would be a less useful datapoint
<Keybuk> -7 would be ok for the first test I'd like to run with you
<maxb> rebooting (powernowd is 1.00-1ubuntu3)
<Keybuk> sweet, let me know when you're up
<pitti> doko: please commit your cdbs changes to bzr
<allquixotic> Hi, I am having problems with NetworkManager and wifi. if I connect to a network with NetworkManager (on gnome, nm-applet), it seems to continually "roam" between different APs. I am in a university with 10+ APs in the vicinity with >= 10% signal strength, all on the same network in master mode. dmesg indicates it tries to associate with a different one very often, between every 30 seconds to every 10 minutes.
<allquixotic> If I kill NetworkManager and tell iwconfig 'ap auto' and set my essid and run dhclient, it sticks to the best AP without constant roaming.
<allquixotic> so it's definitely NetworkManager that continually (mistakenly?) thinks the grass is greener on the other side, and hops. Over and over and over.
 * pitti hugs doko for the python2.6 changes to drop the symlink madness
<maxb> Keybuk: in -7, noticed error messages during bootup re failed to insert speedstep_centrino and acpi_cpufreq (No such device)
<Keybuk> maxb: aha!
<Keybuk> maxb: I had a feeling you might have actually hit _that_ bug instead
<maxb> Panel applet complained about cpu frequency scaling unsupported on entering desktop
<Keybuk> the default was always "ondemand"
<Keybuk> but we seem to have been failing to load the right scaling driver for a little while
<Keybuk> maybe even in intrepid
<Keybuk> so you actually had no scaling at all
<Keybuk> (and assumedly dreadful battery life)
<Keybuk> can you confirm:
<maxb> This is a desktop
<Keybuk> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_{driver,governor}
<Keybuk> ok, dreadful electricity bills then :p
<maxb> I can confirm not having a cpufreq directory there at all
<Keybuk> great
<Keybuk> can you reboot back into 8.24 for me
<maxb> here I go...
<maxb> but I have a second machine here
<Keybuk> maxb: what is that second machine running? 8.24 or earlier?
<maxb> same. But it's a laptop
<Keybuk> can you reboot that one into -7 as well, checking powernowd is installed
<Trewas> Keybuk: powernowd has been selecting the wrong driver for a long time, bug 97042 for example (that one is because it selects speedstep-centrino instead of acpi-cpufreq)
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/97042/+text)
<Keybuk> Trewas: right, that's fixed now :)
<Trewas> good :)
<slangasek> Keybuk: so it may not be a regression in that sense, but if ondemand is causing that serious of performance problems, surely that should be considered a bug as well
<Keybuk> I agree
<Keybuk> but let's debug first
<Keybuk> maxb: back in 8.24 on your desktop yet?
<Keybuk> and in -7 on your laptop yet?
<maxb> ok, up
<Keybuk> maxb: ok
<Keybuk> on the desktop, can you run:
<Keybuk> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_{driver,governor}
<Keybuk> and likewise on the laptop
<maxb> laptop, -7, centrino ondemand
<maxb> desktop, -8.24, p4-clockmod ondemand
<Keybuk> maxb: ok, reboot back into 8.24 on your laptop and try again
<Keybuk> so your laptop was running with ondemand before
<Keybuk> your desktop wasn't
<Keybuk> and your desktop is now using p4-clockmod
<maxb> netbook, -8.24, acpi-cpufreq :-)
<Keybuk> can you pastebin /proc/cpuinfo from your desktop
<maxb> http://paste.ubuntu.com/120671/
<Keybuk> interesting that it ends up with p4-clockmod rather than acpi-cpufreq
<Keybuk> maxb: [desktop] cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
<Keybuk> maxb: in fact, to save IRC wear
<maxb> 375000 750000 1125000 1500000 1875000 2250000 2625000 3000000
<slangasek> p4-clockmod is the one that's terrible
<Keybuk> maxb: [desktop] grep . /sys/devices/system/cpu/cpu0/cpufreq/* | pastebin
<Keybuk> :p
<slangasek> so that much is expected
<Keybuk> slangasek: indeed; so far this is what I had hoped to not see
<Keybuk> frankly, if it's that bad, we should just disable it
 * slangasek nods
<slangasek> or make it a module only, for the masochists
<ion_> keybuk: Btw, thereâs âpastebinitâ which actually works exactly like that. :-)
<maxb> http://paste.ubuntu.com/120675/
<maxb> (pasted with pastebinit :-) )
<Keybuk> maxb: ok, it's basically just your cpu governor that's whacked
<Keybuk> err
<Keybuk> no
<Keybuk> DRIVER
<Keybuk> maxb: do you like compiling your own kernels?
<LaserJock> Karmic Koala, hmmm at least it's short this time
<maxb> I haven't, but could do
<Keybuk> maxb: give me a few minutes
<Keybuk> in the mean time
<pitti> LaserJock: oh, where did that leak?
<slangasek> pitti: u-d-a :)
<Keybuk> maxb: git clone git://kernel.ubuntu.com/ubuntu/ubuntu-jaunty
<pitti> aah :)
<Keybuk> pitti: it's all announced now
<LaserJock> I know I'm gonna misspell koala a lot
<ogra> better than katatocic katamaran :)
<Keybuk> so the thirteen times it appears in various IRC logs can be safely ignored ;)
<slangasek> Mez: why did you target bug #1 to jaunty?
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<ogra> *katatonic
<LaserJock> ogra: heh
<LaserJock> oh, more importantly UDS is in Spain again \o/
<Keybuk> maxb: then when you've done that, git merge git://kernel.ubuntu.com/scott/ubuntu-jaunty and build
<ogra> pitti, the original mail said gdm 2.24, i was aware of that ;)
<Keybuk> maxb: that will give you a kernel without p4-clockmod - and hopefully your performance back (though it'll probably mean you have no scaling)
<pitti> ogra: hm?
<apw> kirkland, about?  could you try out the new script ... test-suspend-v6 (will copy it in officialy when you ok)
<Keybuk> maxb: just to confirm though: you're not seeing any reduction in performance on your laptop or netbook?
<ogra> pitti, your recent -desktop mail
<Mez> slangasek: it was more of a trying to work out what the button did
<pitti> ogra: right, I was saying that 2.20 doesn't use that keyboard env var at all; ceratinly the new gdm does
<kirkland> apw: hmm, at the moment, i'm debugging broken wireless, jaunty update b0rked me
<ogra> pitti, right, old gdm is out of question :)
<pitti> ogra: just pointing out that starting to use that variable certainly introduces new issues, since gnome-settings-daemon evaluates it
<ogra> yeah
<apw> job
<apw> joy even
<maxb> Keybuk: this clone could take a while..... .  Confirmed, I've not noticed any performance issue with laptop or netbook.
<slangasek> Mez: it makes the release manager angry :)
<slangasek> Mez: please don't push the "aggravate the release manager" button
<infinity> slangasek: Should we re-label it?
<infinity> slangasek: If I knew it had that effect, I'd press it ALL THE TIME.
<maxb> Keybuk: If the kernel build is purely to remove a module, does the fact that setting the governor to "performance" makes things good again prove the point just as well?
<Keybuk> maxb: performance still uses the scaling driver
<Keybuk> I'm obviously curious to see what happens if we remove that driver
<Keybuk> whether you get another one take its place, or whether you end up with no scaling at all
<slangasek> infinity: do not taunt the happy fun RM
<maxb> ok. Well, it'll be ~15m for this clone to finish, I reckon
<infinity> slangasek: That's your first mistake.  Release managers shouldn't be "fun".  That's how the world ended up with Windows ME, and the Ford Pinto.
<Keybuk> ember: keen, aren't you?
<Mez> slangasek: it's not clear what it is. Apologies
<pitti> slangasek: I guess a friendly Launchpad admin can SQL it out again?
<Keybuk> p4-clockmod and ondemand is a recipe for fail.
<Keybuk>  -- Dave Jones
<kirkland> apw: okay, where's your script?
<apw> kirkland, http://people.ubuntu.com/~apw/suspend-resume/test-suspend-v6
<kirkland> apw: cheers, looks good, thanks
<apw> if it works ok then i'll make it the real one
<pitti> kirkland: do you happen to have time for kernel NEWing, or should I just do it now and tell you later?
<kirkland> pitti: the latter would be better, i'm afraid :-(
<pitti> kirkland: that's fine
<kirkland> pitti: i'm late for a meeting with kvm/qemu upstream
<kirkland> pitti: i do want to learn the AA kernel magic at some point soon, though
<ogra> MacSlow, is the fact that notifications pop up under the panel with the latest updates known ?
<pitti> kirkland: we'll get a new one soon enough, don't worry :)
 * pitti -> off for the weekend
<MacSlow> ogra, that should not happen
<MacSlow> ogra, that sounds like a start-order problem
<ogra> well, it does since my upgrade and reboot around noon today
<slangasek> pitti: I'm using it as a launchpadlib learning opportunity :)
<MacSlow> ogra, I know the fix ... but a bit hard to implement bullet-proof atm
<ogra> MacSlow, i also note that the notification blinks shortly before it disappears
<MacSlow> ogra, just please file the bug on notify-osd at lp
<ogra> will do
<MacSlow> thanks
<ogra> MacSlow, oh, it looks like bug 332094 just with the panel being on top instead of below
<ubottu> Launchpad bug 332094 in notify-osd "Jaunty: notifications overlap top panel " [Undecided,New] https://launchpad.net/bugs/332094
<ogra> i'll just comment on that one then
<MacSlow> ogra, you can add that that's probably a start-order problem of the panel and notify-osd
<MacSlow> at least that's my best guess atm
<ogra> well, the position is wrong
<ogra> it shouldnt popup at the edge of the screen but respect the panel size
 * ogra commented
<directhex> karmic koala?
<slytherin> is there some problem with buildd of ia64, hppa and armel. Builds seem to be getting stuck in 'needs building' state for long time.
<Tm_T> perhaps just overcrowded?
<directhex> both
<majeru> hello, is how could I make suspend occur when some programs that usually inhibit it are running? (synaptic or vlc are blocking suspend)
<directhex> openjdk on arm has been building for yonks though
<majeru> when i close my laptop lid i expect it to suspend, not wait until i close transmission
<majeru> i had a few times then i carried it powered on in my bag due to this issue
<slytherin> Tm_T: looks like some particular servers are overcrowded and hence new packages are in needs building state for long time.
<slytherin> directhex: yes, it is building for 2 days :-)
<directhex> slytherin, that's the computing definition of "yonks"!
<maxb> Keybuk: $ git merge git://kernel.ubuntu.com/scott/ubuntu-jaunty
<maxb> fatal: 'git://kernel.ubuntu.com/scott/ubuntu-jaunty' does not point to a commit
<Keybuk> maxb: + " master" ?
<ion_> If that doesnât work, perhaps git remote add keybuk git://kernel.ubuntu.com/scott/ubuntu-jaunty, git merge keybuk
<Keybuk> ah, git; you've got to love that "don't do what I want, let alone what I mean" design philosophy
<maxb> I think I've settled on 'git reset --hard keybuk/master'
<Mithrandir> why not just git checkout keybuk/master?
<maxb> it warned about it being nonlocal branch
<Mithrandir> yes, it's just a warning.
<ion_> Then git checkout -b foo to fork a local branch from it.
<ion_> If youâre going to make any changes
<LaserJock> mvo_: edubuntu ping
<maxb> Is there a quick knob to twiddle to ask it to build generic flavour only?
 * maxb hacks around in debian/rules.d/ and debian/control.d/, and starts the build
<calc> slangasek: is it safe to upload yet?
<calc> oh hmm i must be off by a week for a5, heh
<superm1> maxb, if you look at the kernel/compile wiki page there is a quick command to trigger a build of just one arch.  you can't do it in a pbuilder/sbuild/ppa though, have to run it in your source tree
<LaserJock> kees: around?
<Lure_too> is it just me, or did root on lvm break with recent udev/dmsetup upload?
 * sebner winks sistpoty 
<sistpoty> huhu sebner
<sistpoty> hm... /me wonders what yellow is doing atm. 17 minutes spent building faucc seems way over the top
<laszlok> seb128: a new gstreamer-plugins-good was released today, do you know if it will make it into Jaunty or not because of feature freeze?
<seb128> laszlok: we will get stable updates still no issue
<ScottK> doko: I did convert all three boost* packages to Python 2.5/2.6 last night, so they're done.
<laszlok> seb128: still allowed even if its a feature release? thats good, it has some pulseaudio fixes we would like for Jokosher
<slytherin> I have question about gstreamer plugins packages. gst-plugins-ugly-multiverse0.10 source is nothing but a copy of gst-plugins-ugly0.10 source, right?
<laszlok> slytherin: -ugly-multiverse contains only gstreamer lame plugin, gstreamer-plugins-ugly in universe has the rest of the ugly ones
<slytherin> laszlok: right, but the source is duplicated right?
<laszlok> slytherin: you mean are there any source modifications?
<slytherin> laszlok: No. I mean 'upstream does not release any separate source for ugly-multiverse, so we copy ugly and rename it ugly-multiverse'
<seb128> laszlok: GNOME has a standing freeze exception and gstreamer is sort of GNOMish, I don't expect gstreamer stable update to be any issue
<laszlok> okay thanks
<slytherin> seb128: can you please my answer about the source of ugly-multiverse?
<silas428> what is a good way to start developing for Ubuntu?
<silas428> for someone who doesn't know how to program but is comfortable learning
<seb128> slytherin: the multiverse version is the same source but build-depending on multiverse sources
<slangase`> calc: hmm?
<seb128> slytherin: the universe version can't depends on things which are in multiverse so there is an extra source to build those
<sistpoty> silas428: we're always in need of persons trying to fix bugs... feel free to ask further questions in #ubuntu-motu
<slytherin> seb128: Ok. The reason I am asking is that the ugly-multiverse source is quite old as compared to ugly.
<silas428> sistpoty: I'll do that, thanks
<seb128> slytherin: try to find a motu interested to update it?
<slangasek> calc: ah - yes, a5 is next week :)
<seb128> slytherin: the other one is in sync with debian, nobody seems interested to work on the multiverse variants
<slytherin> seb128: There is one. Me. :-)
<slytherin> I was just checking if my understanding is correct.
<seb128> slytherin: ok, cool
<slytherin> And that reminds me. A simple -bad source rebuild fails currently because of updated libcelt0. I need to contact the uploader who updated libcelt0 and file a bug then.
<tobi> should translations to Chinese simple and traditional share the same folder in /usr/share/locale?
<jdstrand> mathiaz: fyi-- I just uploaded new gnutls packages to the ubuntu-security-proposed ppa to fix bug #305264
<ubottu> Launchpad bug 305264 in gnutls26 "gnutls regression: failure in certificate chain validation" [High,Fix committed] https://launchpad.net/bugs/305264
<slangasek> tobi: no
<calc> tobi: isn't that zh_CN vs zh_TW ?
<slangasek> tobi: they differ as calc describes
<tobi> which is simple and which traditional?
<calc> iirc simple is CN and traditional is TW
<jdstrand> mathiaz: jaunty has gnutls26 2.4.2-6 now too
<calc> slangasek may know more details than me
<tobi> aren't the latter 2 characters for the different countries?
<calc> tobi: yes
<calc> taiwan and china
<calc> ugh, dselect crashing :\
<rmcbride> calc: you are correct in regard to simple vs traditional
<jdstrand> dselect... man, that takes me back :)
<tobi> ok, and all Taiwanese use traditional and all Chinese simple?
<rmcbride> tobi: with regard to localization character set choices, yes.
<tobi> kk, thank you guys
<tobi> one more question: is this ubuntu specific or something general?
<calc> tobi: read wikipedia :)
<calc> tobi: its due to Mao iirc
<slangasek> tobi: it's common across Linux distributions, at least
<calc> wrt it being called traditional vs simplified its universal
<calc> the directory layout on linux is common to linux :)
<calc> tobi: http://en.wikipedia.org/wiki/Debate_on_traditional_and_simplified_Chinese_characters
<tobi> packaging can be quite educating :D
<calc> tobi: also if you don't know yet (People's Republic of China) China doesn't acknowledge (Republic of China) Taiwan
<jdstrand> zul: ^ (gnutls)
<SyL> if I have a question about ubuntu-server, but it's jaunty, should I be asking it in here?
<slangasek> tobi: ISTR that Hong Kong also uses Traditional instead of Simplified, since they were administratively separate from the PRC during the orthographic reform; but I could be mistaken about that, and in any case we don't normally have separate zh_HK translations
<mathiaz> jdstrand: great - thanks
<RainCT> slangasek: the update-manager windows needs 100MB memory? o_O
<RainCT> sounds pretty much like a bug to me :P
<sebner> RainCT: it's python :P
<RainCT> sebner: and?
<ScottK> SyL: #ubuntu-server
<RainCT> Python can be efficient, and 100MB is... I don't know what that is :P
<sebner> RainCT: should be rewritten in C# :P
<RainCT> I have written a complete game in Python with fancy graphics and it needs less memory than that :P
<sebner> RainCT: LINK!!!
<SyL> ScottK: it looks like a kernel issue
<RainCT> sebner: http://launchpad.net/freevial, or sudo apt-get install in Jaunty (the version in Hardy is outdated) :)
<slangasek> RainCT: python + 64-bit pointers
<slangasek> and this is 100MB of real memory, AFAICT, excluding shared libs
<RainCT> slangasek: what is it used for? keeping the whole apt database in memory or what?
<slangasek> RainCT: I haven't looked; you could ask mvo
<slangasek> but there are a fair number of python modules involved, each of which contributes a bit for its data structures 'n'such
<sebner> RainCT: /me looks
<RainCT> Using Ubuntu with less than 700MB of RAM is a real pain.. With stuff like this I don't wonder why anymore :P
<RainCT> sebner: if you want to write questions, contributors are welcome :)
<slangasek> well, after getting nowhere trying to figure out why my system was so sluggish with 1GB of RAM, I upgraded it to 3GB this week. :)
<sebner> RainCT: really crazy game. just funny to see mono logo floating around :P
<slangasek> so while I'm still concerned about memory usage generally and think the problem needs more attention, it's no longer blocking my work :P
<RainCT> sebner: That's *not* funny. Mono is evil! *g*        /me hides
 * sebner slaps RainCT :P
<calc> is launchpad dying?
<calc> it keeps giving me errors
<RainCT> calc: performance seems horrible lately.. here it takes ages too, and a while ago keyserver.ubuntu.com took over 2 minutes to respond -.-
<calc> oh well this is giving me the error webpage pretty fast but often
<maxb> Keybuk: kernel build done: performance is good, no frequency scaling method
<calc> i hate launchpad, gah it ate my comment
<calc> due to this stupid constant failing to show pages
<calc> its getting really annoying and happens at a great time... bug jam weekend
<directhex> calc, file a bug!
<ScottK> calc: I think you're being too picky Launchpad does an awful lot of things, it's not like being a bug tracker is really one of its primary functions.
* slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | alpha-4 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 | LP sporadically unresponsive; LP team is investigating
<calc> directhex: heh yea if it will load
<slangasek> "file a bug" - perhaps you didn't get the same error message I did, but the one I saw asked people to report issues to #launchpad; which is done now, the problem is being investigated
<directhex> slangasek, i didn't get an error. but i live my life on the line between sarcasm and usefulness :)
<calc> slangasek: ah ok
<calc> it was happening so often i'm surprised it wasn't reported already
<calc> almost every second page load it seemed
<slangasek> I didn't see it for a half hour after your first comment here; then I reported it, they've been working on it since at least that time
<calc> ok
<ScottK> In all seriousness the line between "It does that" and "It's broken" isn't always easy to tell.
<directhex> ScottK, especially on windows!
 * calc bbl
#ubuntu-devel 2009-02-21
<directhex> hm. is it appropriate to mention DDs i've worked with in an ubuntu context in my reply to the NM front desk? e.g calc & slangasek?
<slangasek> calc: where do we stand at this point as far as getting all the OOo bits onto the CD that we think should be there?  We have a fair amount of wiggle room now thanks to some aggressive pruning campaigns; I've been shoving said wiggle room full of langpacks because if nothing else it makes a good early warning system, but if there are OOo bits that are missing then those should take precedence over trying to get a maximal langpack set
<slangasek> directhex: off-topic?  but I don't think the front desk cares about that so much as about making sure you have a DD advocate prior to assigning you an AM
<directhex> damnit, i lost track of what i was planning to do tonight. i think i'll just go to bed
* slangasek changed the topic of #ubuntu-devel to: Archive: feature-frozen | alpha-4 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 | LP believed fixed - please report any further timeouts to #launchpad
<YokoZar> Where is the packages-arch-specific file we use?
<YokoZar> And, more importantly, could someone remove the restriciton on zsnes building on amd64 from there?
<TheMuso> YokoZar: afaik zsnes has i386 asm.
<YokoZar> TheMuso: the amd64 package uses ia32 libs to build and is essentially 32 bit: https://bugs.edge.launchpad.net/ubuntu/+source/zsnes/+bug/184255
<ubottu> Ubuntu bug 184255 in zsnes "[patch] build amd64 package of zsnes" [Wishlist,In progress]
<TheMuso> ah ok
<maxb> YokoZar: P-a-s updates would be blocked on migrating away from the obsolete CVS repository, I'd guess
 * maxb hunts bugnumber
<YokoZar> hrmph
<maxb> bug 316579
<ubottu> Launchpad bug 316579 in soyuz "Soyuz needs to switch to obtaining Packages-arch-specific from non-obsolete source" [High,Triaged] https://launchpad.net/bugs/316579
<YokoZar> why don't we just get rid of PAS and use proper control files in packages
<maxb> IIUC the problem is the relevant info doesn't get copied from debian/control --> .changes --> Sources
<maxb> but yeah, would be nice
<maxb> YokoZar: anyway, as I understand it, Ubuntu just uses Debian sid's P-a-s unmodified, so approaching debian would be the way to get an alteration done
<YokoZar> maxb: problem is here I don't know if Debian carries the patch yet (we're working ahead of them here)
<ScottK> If there's a buildd admin in the house, would you please push the amd64 build of kdepimlibs in intrepid-backports to the front of the line?
<calc> slangasek: enough room for java? :)
<calc> slangasek: that would fix a lot issues if we could do that :)
<slangasek> calc: wasn't that 70MB last time we tried?
<calc> slangasek: i think so, so not 70mb of wiggle room? :)
<slangasek> not that much, no
<slangasek> more like 20 total
<calc> slangasek: ah ok
<calc> slangasek: i'll take a look and see if anything should be added, but i think most of what OOo still needs is java related so wouldn't work anyway
<slangasek> ok
<slangasek> I couldn't remember if that was the case, or if there was other stuff we could still be adding back in
<calc> slangasek: there might be but i can't remember what it was (if anything) atm
<calc> the search bits we removed were java related
<calc> i think we disabled redland due to not fitting on the cd
<calc> iirc its not java, so i could turn that bit back on (i think)
<calc> but its not really something that is immediately needed, we may want to turn it back on for karmic, but it isn't a user visible change
<calc> second but probably should be an and :)
 * calc loves his new smaller thinkpad x200, but it made it more obvious he needs new glasses (his current set are 6 years old)
<arooni> thank you for ibex;  i like it much better than hardy
<arooni> it is great+++!
<LaserJock> what's the URL for the CVE tracker?
<LaserJock> nvm, found it again
<highvolt1ge> hi. anyone know of alternative accomodation that will be near uds or are self-sponsored that wants to share a room at hrjs?
<J-_> I'm not sure if it's been fixed, but in Hardy. I've downloaded some packages from synaptic. Now the package manager is removing software that I've told it to. BUT, it states it's Installing and Removing, though, it's removing first. Has Jaunty changed issue? It's quite cosmetic, but, the action queue/ title doesn't make sense. It should be 'Removing and Installing Software'.
<Hobbsee> is there a bug filed for this?
 * Hobbsee notes that means a whole lot of extra string changes, too
<J-_> I'm not entirely sure. That's why I'm asking if it's the same in Jaunty.
<J-_> :)
<StevenK> Download a live CD and check?
<J-_> I'm still using Hardy.
<StevenK> How is that related?
<cjwatson> J-_: (I don't work on synaptic myself, but) my inclination would be to say that while your comment is pedantically correct, "Removing and Installing Software" would tend to give prominence to the "Removing" bit, which I think might be surprising to others
<directhex> it can't change in hardy can it? the string changes would mean doom for all concerned
<cjwatson> if it were me, I'd probably say "Applying Changes" or some such, but maybe that was felt to be too vague ...
<StevenK> "Frobbnicating package changes"
<cjwatson> it certainly can't change in hardy, no, but J-_ didn't ask for that
<Hobbsee> Frobbnicating++
<cjwatson> it appears to still be "Installing and removing software"
<cjwatson> at least judging from the translation files
<cjwatson> J-_: BTW, synaptic does not uniformly remove everything first
<cjwatson> J-_: it may happen to in your case, but it's entirely possible for removals to be interspersed
<J-_> Ah I see. It appeared to me it looked like it was removing everything first. Well, downloading, removing, installing/ configuring.
<cjwatson> J-_: particularly if they interact with the packages to be installed in any non-trivial way (e.g. some installed package used to depend on a package that's to be removed, and needs to be upgraded first to a version that doesn't have the dependency)
<StevenK> cjwatson: It's non-deterministic, right? Since the entire list is just fed to dpkg?
<cjwatson> StevenK: firstly, that wouldn't make it non-deterministic; secondly, apt does its own ordering typically invokes dpkg several times
<cjwatson> s/ordering/ordering and/
 * StevenK grumbles at his tired brain
<cjwatson> although some of the ordering is done by dpkg: it'll feed a big pile of packages to unpack to dpkg when apt decides it doesn't need to care about the order, and dpkg will use whatever order suits it
<cjwatson> likewise for configuration
<cjwatson> but you can't really do "unpack lots of packages, then configure lots of [potentially different] packages" in a single pass with dpkg
<cjwatson> and Pre-Depends tend to partition the set
<cjwatson> J-_: ... so basically, it's complicated and it's better to regard "Installing and Removing" as a simple conjunction rather than implying ordering :-)
<J-_> But, I'll leave it at that, and since it's out there, it'll either be changed, or won't be. :) (Sorry if I created some sort of retarded argument) Just wanted to see what had to be said, and see if anyone else took notice.
<J-_> It works though, quite well and, thanks.
<Unggnu> hi all
<Unggnu> Afaik acpi-support is deprecated in Jaunty
<Unggnu> so the sonybright.sh script is removed from /etc/acpi
<Unggnu> But the brightness keys still works in Ubuntu but not in Kubuntu Jaunty. Does anyone know what could make the difference? Is there a special new program for that in Gnome Jaunty which Kubuntu doesn't have?
<mun> hi
<mun> can a bash script be blocked until a python program outputs something?
<maxb> mun: kinda off-topic for this channel. Try #ubuntu for generic user help, or maybe there's a #bash ?
<maxb> Unggnu: Could be gnome-power-manager? You could try killing that in Ubuntu and seeing if the keys then stop working.
<Unggnu> maxb: thx, I am going to test it soon
<ScottK> If there's an archive admin in the house that can accept kdebase-workspace for intrepid-backports I'd appreciate it.
<ScottK> The LP U/I is, of course, broken.
<Unggnu> maxb: yeah ,it it is the gnome-power-manager thanks
<ScottK> Not sure if it got accepted due to my repeated stabbing at the LP U/I or if someone else accepted it.
<ScottK> If it was someone else, thanks.
<calc> pitti: ping
<calc> for apport-collect what authorization level does it need?
 * calc is guessing "change non-private data"
<calc> pitti: bug 332578
<ubottu> Launchpad bug 332578 in apport "apport-collect should submit initial data as well as hook data" [Undecided,New] https://launchpad.net/bugs/332578
<hikenboot> hello all dont know if this is the right place to say this but I tried setting up raid 1 with lvm and encrypted volumes on my system using separate volumes for system snapshots home and swap using all three in the installer is poorly supported and things seem to get lost during needed reboots
<cjwatson> hikenboot: file a bug on the 'debian-installer' source package in Ubuntu with full details and log files (/var/log/installer/syslog and /var/log/installer/partman), please
<cjwatson> hikenboot: make sure to describe as precisely as you can what actions you took in the installer. Some punctuation would help too. :-)
 * ogra grumbles about partman loading partman modules for filesystems the kernel doesnt support
<cjwatson> partman doesn't, anna does
<ogra> ah, well
<ogra> took me nearly
<ogra> 1h to find out ext3 was missing
<cjwatson> (at which point it is rather difficult to tell whether the kernel supports them or not!)
<ogra> well, it didnt spill any error and all i could find in syslog was that the device /dev/sda2 couldnt be found
<ogra> without ext2 and ext3 in kernel d-i gets to the point where it uses swap btw
<ogra> (on nslu2)
 * ogra hopes that still works with tht kernel after adding the two filesystems
<ogra> whopeeee ... i'm in base install for the first time ever on the slug
 * ogra dances
<ogra> finally a kernel config that works with the crappy 30MB
 * mok0 needs an u-a favour...
<mok0> please reject jeuclid so we can upload a revised version; current copy in new queue has incomplete copyright & other problems
<cody-somerville> mok0, You just need to upload a higher version
<cody-somerville> mok0, No need to reject it.
<BUGabundo> does any one knows where to had apps that need patching, to the new notifications?
<BUGabundo> is it the wiki (https://wiki.ubuntu.com/NotifyOSD/Comments) or LP?
<ScottK> mok0: Rejected.
<ScottK> cody-somerville: Since it's a different orig.tar.gz it does need to be rejected.
<cody-somerville> Ah.
<cody-somerville> Stupid upstream
<hikenboot> cjwatson do i ftp or ssh the logs to somewhere where they can be reviewed. I mean during the install is when this happens
<ogra> hikenboot, go back to the menu and install the openssh-client udeb, then you can scp the log ...
<ogra> another option is to manually mount a usb key and copy it over
<ogra> (from a shell which you can exec from the main installer menu as well)
<mok0> ScottK: thanks
<mok0> ScottK: I will upload the corrected version then
<ScottK> mok0: You're welcome.
<salty-horse> is anyone noticing that apps which don't set an icon have a "black glossy page" as the window decoration icon, but a "blank app" icon in the window list?
<highvoltage> LaserJock: awake? :)
<LaserJock> highvoltage: of course
<salty-horse> can anyone confirm this on jaunty? https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/332624
<ubottu> Ubuntu bug 332624 in metacity "Inconsistencies when windows change their icon" [Undecided,New]
<ScottK> salty-horse: Generally #ubuntu-bugs is a better place for such questions.
<salty-horse> ok. though it's usually filled with bot jabber :)
<BUGabundo> doko: ping
<asomething> Do packages in main with sync requests filed before FF need to go through the FFe process?
<ScottK> If they were ack'ed by a developer before FF, no.
<asomething> but they do need FFe's  if they were in the sponsorship queue with no ACK, right?
<ScottK> Yes
<ScottK> That's my understanding anyway/
<ScottK> /.
<sebner> ScottK: +1
<asomething> cool, just want to make sure I don't do a bunch of paper work that isn't actually needed. =)
<capitan_whiky> hola
<slangasek> TheMuso: powerpc seems to be the one arch failing to build out of linux-ports 2.6.28-2?
<slangasek> TheMuso: failing because rtc modules aren't found
<ScottK> The sparc fix though should resolve most of our sparc specific FTBFS.
<slangasek> spiff
 * slangasek would like to have powerpc building, though, so he can clear out NBS :)
<fta> doko, wrt python2.6, can i add --install-layout=deb unconditionally in my package? i.e. will it work in hardy & intrepid too?
<fta> it's for a package using cdbs (and pycentral), I used to have DEB_PYTHON_INSTALL_ARGS_ALL += --prefix=/usr but now, i have all the files both in /usr and in /usr/local
<ScottK> slangasek: I've got a little problem I could use some assistance on ....  Our KDE4.2 backport is currently blocked on python-qt4, it needs binary New, but needs to go part into Universe and part into Main.
<slangasek> ScottK: ok - that's intrepid-backports NEW?
<ScottK> slangasek: Would you please accept python-qt4 for the archs it's done on?  KDE with backports is broken until I get get it done building.
<ScottK> slangasek: Yes.
<ScottK> Sorry, got kind of laggy there.
<slangasek> ScottK: so the universe bits are python-qt4-{gl,gl-dbg,phonon,phonon-dbg}?
<ScottK> slangasek: The phonon-* ones are in Main in Jaunty.
<ScottK> They're just New, so they default to Universe.
<ScottK> The gl* ones stay in Universe.
<slangasek> ok - and the phonon ones are wanted in main for the KDE4.2 backport?
<ScottK> It doesn't actually matter, but I'd rather stay consistent.
<slangasek> alrighty
<slangasek> accepted
<ScottK> slangasek: Thanks
<ogra> doko, are you still around ?
<ogra> Feb 21 21:01:57 in-target: mkinitramfs: missing disk/by-uuid/36bd4470-358f-4193-856d-8ba993ddb02 root /dev/disk/by-uuid/36bd4470-358f-4193-856d-8ba993ddb026 /sys entry
<ogra> Feb 21 21:01:57 in-target: mkinitramfs: workaround is MODULES=most
<ogra> Feb 21 21:01:57 in-target: mkinitramfs: Error please report the bug
 * ogra cries
<ogra> after 3h installation :(
 * ogra doesnt get where d-i got that uuid from
<ogra> weird ... all uuids in d-i are different from the ones in /target/etc/fstab
<ogra> hrm, a chrooted vol_id call shows the ids that are in /target/etc/fstab
<ogra> and vol_id in the d-i env too ?!?
<slangasek> why are half the bugs with no package being reassigned to acpi-support today?
<ScottK> Dunno.  The one that was assigned to postfix complained about GUI problems.  That assignement didn't last long.
<ogra> aha ! an "udevadm trigger" corrects the uuids
<slangasek> ScottK: is there something going on today that explains all these mis-assignments?
<directhex> can never have too many "udevadm trigger"s
<ogra> directhex, no, thats the point, the udevadm trigger call in d-i was deliberately removed by cjwatson on request from Keybuk
<ogra> but apparently it causes weird issues to not have it
<directhex> ogra, i know. my default position is "sarcasm" though
<ogra> heh
 * ogra wonders what to do with http://paste.ubuntu.com/121199/ now
<IntuitiveNipple> ogra: Had you noticed that the "missing" warning shows the first UUID with one character short ?
<IntuitiveNipple> Is that coming from fstab or crypttab?
<ScottK> slangasek: Yes.  Global bug jam
<slangasek> hmm
<slangasek> is there IRC coordination for that?
<ogra> IntuitiveNipple, fstab
<ScottK> slangasek: No idea, but maybe #ubuntu-bugs
<ogra> IntuitiveNipple, thats an NSLU2 ... 30MB ram ... no way to have crypto in d-i without hitting OOM :)
<TheMuso> slangasek: hrm ok, I thought I had fixed that up, let me check the log and fix it properly.
<ogra> IntuitiveNipple, also note that the first uuid doesnt exist at all
<ogra> IntuitiveNipple, the funs stuff though is that the uuids in /target/etc/fstab dont match the actual ones, but the ones showing up after udevadm trigger
<ogra> *fun even
<IntuitiveNipple> yeah I got that ... maybe the original symlinks were somehow created before the device settled and then blkid was used later which got the real ones? *random theory time* :)
<ogra> well, i guess i'll have to wait until monday when cjwatson and Keybuk are around at the same time the issue sits somewhere between d-i and udev
<IntuitiveNipple> ogra: which udev package version is that?
<IntuitiveNipple> What you're seeing might be caused by a bug in the latest package update I dealt with earlier
<ogra> some days old, from the last d-i build
<IntuitiveNipple> oh... drat not likely to be that then
<ogra> d-i from monday actually
<ogra> on the nslu2 you can only use a rolled netboot firmware image thats built by d-i so i cant have anything newer
 * ogra saves the logs and notes down his findings, pops open a bottle of wine and calls it a day :)
<cjwatson> ogra: I haven't actually removed the udevadm trigger yet, because it causes other problems
<cjwatson> ogra: beware of inferring too much from overheard discussions :-)
<cjwatson> (that doesn't mean I know what your problem is though)
<bluefoxicy> strange
<bluefoxicy> sometimes my system doesn't talk to the captive portal right, so I disconnect, reconnect, nothing
<bluefoxicy> reboot, and it fixes it.
<bluefoxicy> rebooting shouldn't fix anything.
<bluefoxicy> someone add me a button to reload networking (down interfaces, remove drivers) and all networking services, given sudo password.
<bluefoxicy> nipple o.o
<cjwatson> whoever coined that quote never watched a baby try to learn to feed
<Spads> cjwatson: heh, I actually had that convesation with IntuitiveNipple on OFTC once
<cjwatson> what did he say?
<Spads> cjwatson: he seemed to think it was a uniquely human failing, and a sure sign of our inferiority.  I provided the counterexample from a nature show I'd seen about an orangutan adoption attempted by a wildlife preserve
<cjwatson> *blink* what a curious bit of blinkeredness
<directhex> i find the nipple intuitive. better than the touchpad.
<cjwatson> ogra: I'll get you a new d-i upload tomorrow or so, and you can see whether that deals withit
<cjwatson> with it
<cjwatson> oh, hmm, maybe better not if current udev is buggy?
<maco> is someone knowledgeable in ecryptfs-utils around?
<hunger> Any known problems wrt. jauty boot-up?
#ubuntu-devel 2009-02-22
<maco> kirkland: hey can you take a look at bug 317895?
<ubottu> Launchpad bug 317895 in ecryptfs-utils "netboot newuser and ecryptfs fails to login" [High,Triaged] https://launchpad.net/bugs/317895
<sabdfl> cjwatson: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ makes good installer fodder?
<ScottK> If there's an archive admin available, the kde4.2 backport is once again hung up on binary New.  I'd appreciate it if you would accept kde4bindings from Intrepid New.  It's got mixed Main/Universe binaries so I can't do it from the LP U/I.
<directhex> kde 4.2 backport? sounds like a big job
<ScottK> It is.  sigh.
<directhex> i didn't think major infrastructure was even eligible for backporting
<ScottK> It's several dozen packages that mostly have to get built in a certain order and several of which get stuck in New because they grew new binaries in Jaunty.
<ScottK> Kubuntu has historically had a more generous policy about post release updating.
<directhex> fair enough
<ScottK> Also because KDE4 is such a rapibly moving target ....
<directhex> anyway, good luck with the backport. i think it's time for sleepybyes
<ScottK> directhex: JFTR if I'd dropped all the CIL bindings for the backport I'd have avoided a trip through New, but I didn't.
<Hobbsee> ScottK: waved thru
<ScottK> THanks.
<directhex> ScottK, see, that wasn't as bad as all that, was it?
 * directhex hands Hobbsee a fiver
<Hobbsee> directhex: \o/
<directhex> hmm... sounds like rhythmbox development is winding up
<directhex> i wonder what that'll mean for ubuntu desktops
<Hobbsee> would help if the power didn't trip out, too...
<Hobbsee> OK, that's actually accepted this time
<ScottK> Thanks.
<dtchen> hunger_t: yes, currently at least bug 332270
<ubottu> Launchpad bug 332270 in udev "[jaunty] doesn't boot anymore after udev upgrade" [Critical,Incomplete] https://launchpad.net/bugs/332270
<pwnguin> oh neat
<pwnguin> for some reason update-manager is blocking on a etc file in the embedded VT
<MrMacPlus> any chance of getting the PC-BSD package manager ported to Ubuntu?
<MrMacPlus> (it doesn't require internet)
<MrMacPlus> the only machines I have don't have an internet connection
<MrMacPlus> nevermind
<maco> kirkland: i *think* that patch is doing the right thing.  when the user's not logged in, their ~ is 755 with visible filenames (as in release notes) but all files appear empty (even to root).  when the user is logged in, ~ becomes 700 and root can see into the files (which makes sense to me, since the fs is mounted). i just want to check with you that this is the correct behavior for fixing that bug.
<cjwatson> sabdfl: yeah, there was somebody on ubuntu-devel-discuss (I think?) a little while back who was interested in working on that
<sabdfl> cjwatson: would that logic best be encoded in the d-i partitioner
<sabdfl> ?
<cjwatson> sabdfl: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-January/006760.html
<cjwatson> sabdfl: and followup, where I provide some suggestions
<sabdfl> thanks colin
<cjwatson> libparted is a good common place to put this kind of thing - d-i would just need to flip the switch, ideally. However from the look of tytso's blog it does seem that we'd have to pass some extra arguments to mkfs.ext4 and such
<cjwatson> but we could stash that information in /var/lib/partman if libparted were doing the work of fishing it out from the kernel
<sabdfl> yes, it looks like there needs to be a level of intelligence in a variety of the tools
<sabdfl> did daniel respond to your question about whether he's willing to do the work? we could connect him to ted tso
<cjwatson> sabdfl: haha, and in my work mailbox this morning there's a followup from Daniel J Blueman on parted-devel about this exact subject ;-)
<sabdfl> including a ref to ted's blog?
<cjwatson> no, but it would fail to surprise me if he were prompted by the same thing
<cjwatson> the coincidence is a bit much
<cjwatson> I'll keep the link and nudge things alon
<cjwatson> g
<cjwatson> sabdfl: I've mentioned Ted's blog on parted-devel
<cjwatson> sabdfl: the bit about alignment of the first partition is interesting, given that we haven't historically created a /boot
<cjwatson> (well, not by default anyway)
<sabdfl> he's encoded a *lot* of "wisdom and best practice" into that blog
<cjwatson> I wonder whether the right answer is to create a /boot on SSDs, or whether it's to say screw MS-DOS compatibility and hope that not too many partitioning programs will whine at us if we 128KB-align the first partition
<sabdfl> can we detect SSD's? and worse, can we determine things like which type of SSD it is?
<cjwatson> we can detect SSDs with ATA IDENTIFY. I don't know about which type
<cjwatson> Daniel says: """
<cjwatson> I've checked into this, and since libparted sees the SATA block device
<cjwatson> as SCSI, it doesn't perform the expected ATA 'identify' command to
<cjwatson> fill out the 512 bytes of device info, of which (short) word 217 is
<cjwatson> device RPM, defined to be 1 on newer compliant SSDs. The kernel uses
<cjwatson> this word to detect if a device is an SSD or not, so I suggest we use
<cjwatson> the same.
<cjwatson> """
<cjwatson> that much is pretty trivial
<sabdfl> assuming we fix the libparted-sees-scsi bit
<ogra> cjwatson, do we have a way to enforce that users create swap in partman ? (would be handy to not make nslu2 users shoot themselves in the foot, though i can just document that you need it indeed)
<LordMetroid> I just installed 8.10 and now 9.04 is soon to be released, I can't keep up with this high pace...
<LordMetroid> How can I get insight in what is being developed for each release?
<hunger> LordMetroid: CHeck launchpad:-)
<LordMetroid> I am hanging around on Launchpad, I even contributed some bug reports
<LordMetroid> But how do I know what people are working on?
<hunger> LordMetroid: https://launchpad.net/ubuntu/intrepid/ is the "homepage" for intrepid. The most interesting section there wrt. planning is "Blueprints".
<hunger> You might want to replace intrepid with jaunty... Not that much planning is happening in intrepid nowadays:-)
<LordMetroid> karmic has no section of its own?
<StevenK> LordMetroid: Not yet, no.
<geser> a quick question: why is python3-minimal an essential package?
<directhex> because ubuntu wuvs python?
<highvoltage> geser: are you wondering more about the '3' part or more about the 'python' part?
<geser> yes
<geser> the 3
<geser> python3 is still in universe and iirc doko waits on python 3.1
<highvoltage> yeah that is a bit weird
<directhex> any rdeps?
<geser> I just wondered why my jaunty pbuilder install python3-minimal just to find out it's because it's essential
<doko> geser: it's a bug and should be fixed
<Keybuk> mdeslaur: so you're getting this udev bug too?
<mdeslaur> Keybuk: yes...not fun
<Keybuk> have you worked around it yet, or can I pick on you for some debugging?
<Keybuk> it seems to be uniquely affecting people who use some magic combination of lvm, devmapper or mdadm
<mdeslaur> Keybuk: well, I commented out the watch line, but I booted on an old kernel, so I can simply add it back in
<Keybuk> mdeslaur: do you have some time to do that now?
<Keybuk> or Monday (since today is Sunday and you might be busy :p)
<mdeslaur> problem is, I had a hell of a time getting my laptop to boot so I could make the change
<mdeslaur> yes, let me just save my work
<mdeslaur> Keybuk: what would you like me to do?
<Keybuk> I'd like to find out what's causing these inotify events
<Keybuk> so firstly need to get booted up, so we can find out which block devices they're happening for
<Keybuk> ie. run udevadm monitor
<mdeslaur> Keybuk: I can't successfully boot _with_ the problem
<mdeslaur> Keybuk: the best I can do is add the watch line back in, but boot with the 2.6.28-7 kernel
<mdeslaur> is that ok?
<Keybuk> does the kernel make a difference?
<geser> Keybuk: I'm affected by the bug too (I downgraded udev in the end). I didn't get near a shell with the bugged udev (perhaps I didn't wait long enough) to be able to test something.
<mdeslaur> Keybuk: I think it's juste because the old kernel has an old initrd
<Keybuk> oh, hmm
<Keybuk> ok, let's just debug this from the other angle then
<Keybuk> can you remember which filesystems you saw inotify events for?
<Keybuk> geser: likewise?
<mdeslaur> Keybuk: I think it was my home directory.../dev/mapper/defaultvg-home on /home
<mdeslaur> Keybuk: but I'm not 100% sure
<Keybuk> is there anything special about that drive, other than using LVM?
<Keybuk> is it encrypted?
<Keybuk> do you use encrypted drives or swap?
<mdeslaur> Keybuk: I use encrypted swap, and have an ecryptfs ~/Private directory
<Keybuk> geser: what about you?
<geser> I use just simple raid + lvm for / and /home
<Keybuk> geser: lvm-on-md-on-sda?
<mdeslaur> Keybuk: I use LUKS for my encrypted swap
<geser> yes, raid1 on sda+sdb and lvm on that raid
<Keybuk> interesting
<Keybuk> mdeslaur: so you use md at all?
<mdeslaur> Keybuk: nope
<Keybuk> mdeslaur: but you do use lvm?
<mdeslaur> Keybuk: yes
<Keybuk> mdeslaur: cryptswap is done all inside the kernel, right?
<Keybuk> there's no userspace helper that writes to the block device?
<mdeslaur> Keybuk: yeah, I'm pretty sure it's kernel
<Keybuk> geser: do you see inotify events for both underlying disks/
<mdeslaur> Keybuk: of course, I get prompted for a password during boot up for my encrypted swap
<mdeslaur> Keybuk: It's during usplash, from initr
<mdeslaur> initrd
<Keybuk> the confusing thing is that none of this is supposed to generate inotify events
<Keybuk> certainly not the IN_CLOSE_WRITE event that udev actually looks for
<geser> Keybuk: I could upgrade udev again and check.
<Keybuk> geser: you should be able to upgrade in-situ without rebooting
<Keybuk> and then trigger it
<geser> even better
<geser> Keybuk: I've started udevadm monitor and restarted udev and no output from udevadm
<Keybuk> ok
<Keybuk> run udevadm trigger --subsystem-match=block
<mdeslaur> Keybuk: I've done the same
<Keybuk> (have a very niced root terminal somewhere :p)
<mdeslaur> Keybuk: whoa, I'm getting a TON of events
<Keybuk> mdeslaur: are they repeating?
<mdeslaur> Keybuk: yes
<Keybuk> if so, kill udevd from the other terminal and pastebin me the output ;)
<geser> Keybuk: http://paste.ubuntu.com/121466/ (it didn't stop)
<mdeslaur> Keybuk: https://pastebin.canonical.com/14086/
<Keybuk> geser: kill udevd harder
<mdeslaur> Keybuk: I didn't get the beginning
<geser> Keybuk: that was before I killed udevd
<Keybuk> both of you: can you run "find /sys/block" for me and pastebin that
<mdeslaur> Keybuk: http://paste.ubuntu.com/121467/
<geser> http://paste.ubuntu.com/121468/
<IntuitiveNipple> Keybuk: Some info: If running with udev_log=debug (and a serial console) the problem isn't nearly as bad, although there are a huge number of "vol_id..." invocations early in the initrd - before netconsole  gets going. Without either "debug" or "info" log-levels, the disk will just thrash constantly and not reach a prompt for a very long time (hour?). This is with just a single LVM volume, not even mounted via fstab.
<IntuitiveNipple> Keybuk: If you want to ssh in to observe/interact, I can do that
<Keybuk> my guess is that mdadm and lvm (and probably just devmapper) are generating open/close events in the kernel
<IntuitiveNipple> It is very weird how with logging on, the timing difference allows the system to boot. Also very frustrating, because it is making it almost impossible to catch the activity!
<Keybuk> the timing difference is just because udevd is much slower
<Keybuk> you could replicate the same by adding a rule like
<Keybuk> SUBSYSTEM=="block", RUN+="/bin/sleep 5"
<IntuitiveNipple> yeah, but my point is, the timing delay is preventing the problem... the disk doesn't thrash like it does when the system's being hit
<Keybuk> is it preventing it? or just slowing it?
<geser> Keybuk: you need more testing? else I'd downgrade udev again so I can boot tomorrow
<Keybuk> a continuous loop of events is bad whatever
<Keybuk> geser: I think I have enough information to try and put together a test install
<Keybuk> if I still can't replicate it, I'll come back to you
<IntuitiveNipple> With logging enabled, I can get to the root prompt in about 80 seconds. Without it the disk thrashes with no screen reports for a _long_ time... longest I left it was 30 minutes
<IntuitiveNipple> Keybuk: I found as soon as I added lvm2 to the intrd it fired it off - remove lvm2 from initrd and it's fine
<Keybuk> sure, that's just the symptom though
<Keybuk> the real problem is udev picking up events that seem to cause other events
<Keybuk> it'd be interesting to find out whether it's caused by a udev event
<Keybuk> or whether the kernel simply generates events over and over again anyway
<IntuitiveNipple> I have a log here now (captured via screen from the serial console). I *think* it might be useful but I'm trawling through it to check
<IntuitiveNipple> Keybuk: It's got a lot of this kind of thing: http://paste.ubuntu.com/121476/
<Keybuk> what I need to find out is whether the *next* event is caused by the previous one
<Keybuk> that's possibly quite easy
<Keybuk> SUBSYSTEM=="block", ACTION=="change", OPTIONS+="last_rule" as a 00-xxx.rules file
<Keybuk> add that to the system, and see if the eventS stop
<IntuitiveNipple> OK I'll try that now. I've just attached this most recent log-file to the bug report for you.
<geser> Keybuk: http://paste.ubuntu.com/121483/ with 00-xxx.rules (complete output, no looping)
<geser> after a udevadm trigger --subsystem-match=block
<cjwatson> ogra: partman already complains if you don't create swap, AFAIK
<Keybuk> geser: aha! fantastic
<Keybuk> I bet it's something silly
<lamont> should 'Running "grub-install (hd0)"...' take forever in a qemu box?
<IntuitiveNipple> Keybuk: With the 00-xxx.rules the boot with udev_log="err" succeeded. About 60 seconds to the root prompt
<Keybuk> IntuitiveNipple: does udevadm monitor show continuous activity?
<IntuitiveNipple> Keybuk: After the system reaches the root prompt, the 'storm' has gone away. So no, it shows 'normal' behaviour at that point.
<Keybuk> IntuitiveNipple: what about throughout the boot?
<IntuitiveNipple> During the boot there's no way to run that manually since the storm kicks off the very moment udevadm starts.
<Keybuk> so you're saying that you still get the looped events during boot?
<Keybuk> or are you saying you simply don't know
<Keybuk> please be accurate
<IntuitiveNipple> With udev_log="err" it is difficult to know what is going on. The console reaches about 6 seconds and then all console logging ceases, the hard disk begins thrashing continuously, and it never appears to get out of the initrd stage (I was hoping by leaving it that /var/log/udev might catch something)
<Keybuk> "it" ?
<Keybuk> please be specific about what you are doing
<Keybuk> I cannot read your mind]
<IntuitiveNipple> With udev_log="info/debug" the console continues to deliver kernel messages as well as the udev output, and it takes about 80 seconds to reach the recovery root prompt
<Keybuk> I don't care about how long anything takes
<Keybuk> that is irrelevant
<Keybuk> are you seeing the same change event for the same block device repeated over and over?
<geser> IntuitiveNipple: did you also add that additional rule to the initrd?
<IntuitiveNipple> Keybuk: The log messages blur the console. The log-files I attached to the bug from serial are hard to parse since there's so much in them. I've not spent a massive amount of time analysing every line of one so far
<IntuitiveNipple> geser: Yes, and it allowed the system to boot but problems with /dev/disk/by-uuid/ entries missing - obviously :)
<Keybuk> ok, so you see continous log messages
<Keybuk> putting in that rule I asked, do you _STILL see continuous log messages
<Keybuk> or do they stop?
<IntuitiveNipple> With the 00-xxx rule *and* udev_log="debug" there seemed to be the same amount of log messages.
<Keybuk> continuously?
<Keybuk> ie. the log messages never ever stop?
<IntuitiveNipple> No. Whenever I use udev_log="debug|info" the udev messages stop just before the root login is reached
<Keybuk> well, that doesn't make sense in of itself
<Keybuk> changing udev_log shouldn't change anything
<Keybuk> are you, honestly, telling me that changing udev_log makes this bug appear and go away?
<IntuitiveNipple> Yes.
<Keybuk> ie. if you set udev_log to a particular value, your machine boots as normal, and udevadm monitor shows nothing if you run it while booted
<Keybuk> even with the OPTIONS+="watch" rules all in place?
<IntuitiveNipple> I've seen it before, with the kernel, debugging suspend/resume. Just adding additional logging added enough time delay to cure the problem
<IntuitiveNipple> correct
<IntuitiveNipple> This test-bed has the default install on, I've not messed with it
<Keybuk> iiiinteresting
<Keybuk> you know what this suggests?
<Keybuk> this suggests that the inotify event is coming from one of the programs that udev runs
<Keybuk> and the logging is enough to slow down the call of inotify_add_watch such that the run rule finishes before it
<Keybuk> geser's debugging suggests that udev is indeed chasing its own tail
<IntuitiveNipple> The thing I keep noticing is vol_id
<IntuitiveNipple> It feels as if it is triggering itself
<Keybuk> vol_id certainly shouldn't
<Keybuk> extras/volume_id/vol_id.c:	fd = open(node, O_RDONLY);
<Keybuk> it opens the block device RDONLY
<IntuitiveNipple> Looking through that log, I see a lot of this kind of thing, too: udevd-event[1569]: '/sbin/modprobe' (stderr) 'FATAL: Module acpi:LNXTHERM: not found.'
<Keybuk> that's all normal
<IntuitiveNipple> okay
<Keybuk> all we're looking for is something that udev runs that opens the block device for _writing_
<IntuitiveNipple> I'm reading every line in the log now, but its slow going
<IntuitiveNipple> There are a *lot* of these: udevd[835]: seq 729 forked, pid [914], 'add' 'acpi', 0 seconds old
<geser> Keybuk: it's 65-mdadm.vol_id.rules what's causing this
<IntuitiveNipple> geser: they're not installed on this test-bed
<Keybuk> http://people.ubuntu.com/~scott/udev.inotify.patch
<Keybuk> could you try applying that to udev's source and rebuilding
<IntuitiveNipple> I think I've noticed something. The rules are firing like mad when ACPI and PCI are creating devices
<Keybuk> IntuitiveNipple: *shrug* you'd expect to see a lot of udev events then anyway
<geser> Keybuk: when I comment out IMPORT{program}="vol_id --export $tempnode" from 65-mdadm.vol_id.rules the looping stops
<Keybuk> geser: right
<Keybuk> that's what will cause mdadm to be run though
<Keybuk> so commenting out the mdadm --incremental line has the same effect, no?
<ramvi> I'm customizing Ubuntu. What are possible reasons for vntwsusb not showing up in lsmod? 1. sudo depmod -a vntwusb  2. lsmod . It's also added to /etc/modules
<Keybuk> how does one set up encrypted swap?
<Keybuk> do I select "physical volume for encryption" then put the swap in that?
<lamont> is the xml that libvirt wants to see documented anywhere?
<lamont> meh. so it is
<cjwatson> Keybuk: yes
<cjwatson> Keybuk: (or put a physical volume for LVM in that, and put swap on LVM)
<cjwatson> the reason you might do the latter is that it is much less faff to have just a single encrypted block device
<Keybuk> I've gone for a full spectrum attack
<Keybuk> /dev/sda1 + /dev/sdb1 -> /dev/md0 -> ext3 /boot
<siretart> the other approach that many people seem to use is to avoid LVM, and just create a crypted block device and use /dev/random as key.
<Keybuk> /dev/sda2 + /dev/sdb2 -> /dev/md_crypt1 -> swap
<Keybuk> /dev/sda3 + /dev/sdb2 -> /dev/md1 -> lvm ubuntu -> root -> ext3 /
<Keybuk> so at least one of these should show up the bug :p
<Keybuk> cjwatson: about half a dozen people have reported that udev seems to chase its own tail with inotify watches
<Keybuk> ie. it makes the node, sets the inotify watch, and then runs some things that write to the block device, so loops doing it over and over
 * lamont kills trackerd with 2+hours CPU time, wonders if it will ever be interesting enough to let it complete a run
<IntuitiveNipple> lamont: That's a bug - it writes its IntegrityCheck=1 value into the database back to front :)
<lamont> huh?
<alex-weej> jaunty broke some kind of very important library i think
<alex-weej> a few weeks ago
<IntuitiveNipple> lamont: https://bugs.edge.launchpad.net/ubuntu/+source/tracker/+bug/324300
<ubottu> Ubuntu bug 324300 in tracker "Incorrect parameter order for SetOption" [Unknown,Fix released]
<alex-weej> i am trying to use apt to upgrade my system from the live cd
<alex-weej> but chrooting doesn't work because i can't run a shell or any other command due to said breakage
<alex-weej> so i need a way of telling dpkg to work on files in /some/mountpoint
<lamont> trackerd uses sqlite?
<lamont> ZOMFG
<lamont>  /dev/md4             968864600 386122036 572982160  41% /home
<cjwatson> Keybuk: yeah, I saw - being called away now though, I'm afraid
<geser> Keybuk: tested your patch, no improvement (it got only harder to stop it, had to use the init-script)
<Mamarok> mdz: you around?
<lamont> IntuitiveNipple: I've always assumed it just meant I needed to clean up /home :)
<IntuitiveNipple> lamont: Well I thought it was just all my Evolution imap4 accounts and the number of mailing lists I'm subscribed to
<lamont> then again, apt-get remove --purge tracker; killall -9 trackerd seems to fix it for me quite nicely
<IntuitiveNipple> lamont: upstream have completely reworked the code now, and so I think we'll be left to patch what we have ourselves
<lamont> though sometimes I wonder what I'm missing by doing that
<IntuitiveNipple> I found google-desktop was better than trackerd
<lamont> I choose not to share my desktop with google
<Mithrandir> I choose not to share my desktop with tracker.
<lamont> then again, on the rare times that I need to find something, uh... find works well enough for me
<lamont> Mithrandir: what exactly does tracker purport to do?
<directhex> ehm... track things?
<lamont> duh
<IntuitiveNipple> index files via metadata etc
<Mithrandir> lamont: apart from filling up your home partition and burn in your CPU?
<Mithrandir> lamont: dunno, I've taken to just tossing it out.
<lamont> Mithrandir: well, yeah... /me is searching for any redeeming value in said burnage
<lamont> Mithrandir: I mean, not all of the crack in the desktop is bad...
<lamont> (and most of it isn't crack at all - fun distinctions to make)
<Mithrandir> lamont: I think it's supposed to be a search engine.  I tend to just use folders for organising stuff.
<Mithrandir> (and most of the interesting bits where I want to search aren't on my desktop.)
<lamont> yeah
<lamont> as in it just looks in ~/Desktop?
<lamont> that'd be a waste
<Mithrandir> nah, as in ~
<lamont> ok
<Mithrandir> still, I regularly use a bunch of different machines, and things like my email is not on this machine.
<lamont> and yeah, the habits of actually organizing stuff that have grown over the past uh decade plus mean I don't really need something to find stuff for me
<Mithrandir> I tend to have duplicate copies of stuff, but I generally find what I'm looking for
<Mithrandir> else I have find and grep
<lamont> hrm... I wonder how to bludgeon libvirt into putting the devices on the same bridge as the physical eth0
<alex-weej> if i can only run executables like this: /lib/ld-linux-x86-64.so.2 /bin/bash
<alex-weej> then what do i need to do fix it?
<Keybuk> geser: sure?  my patch doesn't compile <g>
<geser> Keybuk: it applied here, I build successfully a new source package and my pbuilder had no problems to build the deb
<Keybuk> I think you're all going mad ;)
<Keybuk> I just put together the most complicated setup I could think of, and still can't replicate the bug
<alex-weej> help me please, my system is broken and i'm sure someone knows the quick answer
<alex-weej> i can ONLY execute binaries when run under /lib/ld.so
<ScottK> alex-weej: You really need to ask for help in #ubuntu or #ubuntu+1 if you are running Jaunty.
<alex-weej> everyone there is just like "how do i get compiz to spin?"
<ScottK> That doesn't make this a help channel.
<alex-weej> ok let me rephrase my problem
<alex-weej> apt HOSED my system. there is a bug somewhere. i am trying to find out what it has broken so it doesn't happen again
<Keybuk> alex-weej: #ubuntu
<Keybuk> this channel is for "I'm patching APT to ..."
<alex-weej> i'm patching apt to not break my linker
<alex-weej> but i need to know what the difference is between me manually running /lib/ld exec args and just asking the kernel to execute exec args
<Keybuk> depends how the program you're execing is compiled
<Keybuk> what linker is the program compiled to use?
<alex-weej> well i would have thought /lib/ld-linux-x86-64.so.2
<alex-weej> but apparently not, as nothing works
<Keybuk> don't think, look
<Keybuk> if you don't know how, you're in the wrong channel ;)
<alex-weej> "the program" is anything ubuntu has installed on my system, even /bin/true
<alex-weej> Keybuk: you obviously know the answer and are just torturing me
<alex-weej> :(
<alex-weej> ubuntu@ubuntu:~$ sudo chroot /mnt /lib/ld-linux-x86-64.so.2 /bin/bash /usr/bin/ldd /bin/true
<alex-weej> 	not a dynamic executable
<Mithrandir> alex-weej: is /mnt mounted noexec?
<alex-weej> Mithrandir: no. if it was, i wouldn't be able to run the linker ;)
<Mithrandir> if you just cd to /mnt and run bin/bash, does that work correctly?
<alex-weej> yes, but with the wrong libs obviously
<alex-weej> wait -- ...
<alex-weej> oh no, yes, ignore that. yes it works
<Mithrandir> naturally.  Try copying /mnt/lib into /mnt/lib.old or something and copy /lib/ld-linux-x86-64.so.2 into /mnt/lib and ditto for glibc, then chroot /mnt true and see if that works?
<geser> Keybuk: I'm used to bugs which only a handful person can reproduce, in intrepid I had a kernel problem where only kees was affected too
<alex-weej> Mithrandir: glibc is just libc.so.6 ?
<Mithrandir> alex-weej: the file that points to, yes.
<alex-weej> libc-2.8.90.so
<alex-weej> yep got it, no luck
<Mithrandir> can you strace it?
<Keybuk> geser: are you around tomorrow?
<geser> yes, starting from 10 UTC or so
<alex-weej> Mithrandir: yeah. do you want me to reinstate the real lib folder?
<Mithrandir> alex-weej: either one which fails should tell us something
<alex-weej> i did tr this first but couldn't figure it out
<alex-weej> Mithrandir: actually, do you want me to strace the chroot process or trying to exec a process within the chroot?
<Mithrandir> alex-weej: you need to strace the chroot call.
<Mithrandir> so sudo strace chroot /mnt /bin/true
<Mithrandir> then pastebin that.
<alex-weej> ok the other one is interesting though, i'll show you both
<alex-weej> Mithrandir: http://rafb.net/p/N1GgmP21.html is what you asked for, and http://rafb.net/p/wVWnv565.html is the one within the chroot (running strace via ld and trying to execute "bash")
<Mithrandir> alex-weej: can you try using true rather than bash?
<Mithrandir> alex-weej: and can you do strings /mnt/bin/true | grep ^/lib ?
<alex-weej> Mithrandir: sure
<alex-weej> Mithrandir: http://rafb.net/p/UkEibD20.html and http://rafb.net/p/xTwDG588.html
<alex-weej> also true has /lib64/ld-linux-x86-64.so.2 in it, that's it
<Mithrandir> and that file exists and is executable and all, else nothing would have worked.
<alex-weej> Mithrandir: indeed, there's no /lib64 in /mnt
<Mithrandir> ah
<Mithrandir> that'd explain it
<alex-weej> so it looks like coreutils was upgraded or something and they changed to /lib64
<Mithrandir> just make it a symlink to /lib
<Mithrandir> no, it's always been lib64
<alex-weej> this system used to work...
<Mithrandir> yes, so something ate the symlink.
<alex-weej> Mithrandir: ok now i can just chroot and indeed it seems to work fine
<alex-weej> is strings the only way to check what linker a bin is supposed to use?
<Mithrandir> it's at least an easy way to do so. :-)
<alex-weej> ubuntu@ubuntu:/$ dpkg -S /lib64
<alex-weej> libc6: /lib64
<alex-weej> maybe a bug in libc6 packaging?
<Mithrandir> it could be.
<alex-weej> ok i'll get uptodate and see what happens
<alex-weej> the fact that when i booted it just says "/sbin/init - no such file or directory" is a bug though i think
<alex-weej> the missing linker is causing that error message and it's getting misrepresented by the looks of things
<lhoersten> whenever I log out of gnome, my screen turns black (backlight still on) and my computer becomes unresponsive. ctrl + alt + backspace/delete do nothing. I don't see a cursor in the top left either. Anyone have any ideas how to debug this?
<lhoersten> seems launchpad has nothing similar
<IntuitiveNipple> Keybuk: I've managed to catch it in the act and log it.
<lamont> wtf do I get EPERM from a write to a connected UDP socket on localhost?
<lamont> *giggle*
<mdeslaur> Keybuk: you can't reproduce it?
<mdeslaur> Keybuk: here's the script I used to create my encrypted swap: http://paste.ubuntu.com/121574/
<hunger> Keybuk: I have that issue without any encryption. Just plain LVM.
<hunger> Keybuk: I do not even have / on LVM... that is on boring plain partition.
<cjwatson> Keybuk: you reassigned bug 328045 to partman-base - do you have any help to offer on it?
<ubottu> Launchpad bug 328045 in partman-base "[jaunty] Jaunty CD installation problem during harddisk partitioning" [Undecided,New] https://launchpad.net/bugs/328045
<cjwatson> stgraber: any progress on bug 328097?
<ubottu> Launchpad bug 328097 in partman-auto "preseeding partitionning isn't working anymore hardy 8.04.2" [Undecided,Incomplete] https://launchpad.net/bugs/328097
<stgraber> cjwatson: haven't had much time to look at it recently, I should be less busy next week now that we're feature-frozen so I hope to have some time to debug it
<cjwatson> stgraber: thanks
<LaserJock> cjwatson: with the latest DVD the preseeding is gone by d-i complains about the ubuntu seed file being gone
#ubuntu-devel 2010-02-22
<qwer> anyone here know a crapload about linux drivers?
<qwer> I'm fairly knowledgeable, but I've a problem that no on in any other channel has been able to help me solve for about 2 weeks
<qwer> anyway, I'll just tell the story, mysteriously ubuntu 10.04 detects the sata_mv driver properly - as well as an old slackware install cd - I've tried about a dozen recent and current distros though - and even after mod probing sata_mv -> no block devices found.......I've no idea how to continue troubleshooting - I've messed with udevadm, modprobe, etc
<hyperair> qwer: try #ubuntu-kernel. the ones knowledgable about these things reside there, usually.
<qwer> thanks
<qwer> #ubuntu-kernel
<qwer> oppppps
<wolfe> xD is there a launchpad admin around?
<wolfe> "me too. I would also like to unsubscribe and it won't let me. PLEASE, MAKE
<wolfe> IT STOP!
<wolfe> "
<persia> wolfe: You probably have the implict bug subscription issue.  But you also probably want to ask in #launchpad
<wolfe> I'm falling out of my seat laughing at this
<wolfe> persia: ah okay. I haven't tried to unsubscribe yet, but I'll try too
<emgent> persia :-)
<twb> So I am rolling lucid live images using Debian's live-helper.
<twb> I'm a bit puzzled by the kernel making a "ramzswap" -- why is it creating virtual swap on top of ram?
<persia> twb: live-helper is explicitly not supported by the Ubuntu installer team (last I heard).
<persia> You *might* get some help out of #ubuntu, but I'm unsure they would have the necessary familiarity.
<twb> Ooooooh.  Googling finds http://code.google.com/p/compcache/, which says that ramzswap is a *compressed* virtual swap
<twb> persia: I'm asking about the kernel, not about live-helper.
<twb> And there's an #ubuntu-kernel, so I guess I'll bug them instead.
<crimsun> "/usr/bin/dpkg-deb: line 53: 28311 Segmentation fault      /usr/bin/pkgstriptranslations"
<persia> extra points!
<crimsun> on armel, nonetheless :-/
<crimsun> (http://launchpadlibrarian.net/39501757/buildlog_ubuntu-lucid-armel.pulseaudio_1:0.9.22~0.9.21%2Bstable-queue-32-g8478-0ubuntu10_FAILEDTOBUILD.txt.gz)
<StevenK> Ouch
<lifeless> isn't that python?
<StevenK> # file /usr/bin/pkgstriptranslations
<StevenK> /usr/bin/pkgstriptranslations: Bourne-Again shell script text executable
<lifeless> wow
<StevenK> Ooooh, that's even more impressive
<TheMuso> wow that is impressive.
<StevenK> crimsun: Throw me a link to the upload page, and I'll try and build it on the porter?
<crimsun> StevenK: meaning https://launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10 ?
<crimsun> (or https://edge.launchpad.net/ubuntu/+source/pulseaudio/1:0.9.22~0.9.21+stable-queue-32-g8478-0ubuntu10/+build/1523932)
<StevenK> crimsun: Yeah
<StevenK> (The former)
<pitti> Good morning
<lifeless> hi pitti
<tjaalton> nice, boot hangs after one unclean shutdown
<tjaalton> rescue doesn't work
<Speedy2> www.search2.net
<tjaalton> no idea what's run after mountall?
<tjaalton> much harder to debug with upstart..
<lifeless> pitti: I filed a bug on lp-project-upload
<lifeless> pitti: I'd like to move it out of ubuntu-dev-tools; its not really ubuntu related ;)
<pitti> tjaalton: what do you see?
<pitti> lifeless: I know, but u-d-t is a kind of catch-all place for these tools
<lifeless> pitti: but I then rewrote it from scratch anyhow :P so perhaps just nuke it now (once my lptools patch lands)
<lifeless> pitti: 'lptools'
<pitti> lifeless: same is true for lp-set-dup, grab-attachments, lp-shell, and whatnot
<tjaalton> pitti: /usr being mounted
<lifeless> pitti: for some of them, I totally agree
<tjaalton> this worked last night when I upgraded the box
<pitti> tjaalton: so it's not the plymouth hang yet?
<tjaalton> but the power button didn't make acpid to shut it down (though acpi_listen showed it sending the signal), so I pulled the plug
<tjaalton> pitti: no, it's a server install
<tjaalton> I've disabled ureadahead and plymouth
<tjaalton> by moving the jobs away
<dholbach> good morning
<tjaalton> even if I don't have splash on the kernel cmdline it loads some framebuffer module (probably vga16fb), which makes debugging even harder
<tjaalton> since the screen is reset and previous messages are gone
<tjaalton> so is there a way to disable that from grub?
<tjaalton> hmm, nofb maybe
<tjaalton> nope
<tjaalton> oh well, got to reinstall it then..
<poolie> pitti, hi
<pitti> hey poolie, how are you?
<poolie> good
<poolie> lifeless pointed me to your lp-shell command
<poolie> i would like to show you bugclient in lp:hydrazine
<poolie> it gives you a specific command line interface to lp
<poolie> rather than a python shell
<poolie> eg you can say 'bug 123' 'triage +tags +easy confirmed medium'
<ubottu> Launchpad bug 123 in rosetta "There's no direct way to see the project info when translating it" [Medium,Fix released] https://launchpad.net/bugs/123
<pitti> poolie: oh, that's useful
<poolie> i find it pretty nice
<pitti> poolie: it seems to have quite a different purpose than lp-shell, but useful for mass bug operations
<poolie> yes, that's true
<poolie> it doesn't really support bulk operations atm
<poolie> but it's pretty quick for single operations
<lifeless> pitti: so to continue the prior conversation; how do you feel about us moving the non distro stuff to the lptools project; build an upstream there, rather than having them in ubuntu-dev-tools that is a bit more restricted for getting developers
<lifeless> this is related to poolies hydrazine project too
 * persia thinks this is a good idea
<pitti> lifeless: sounds fine to me
<pitti> u-d-tools could even recommends: lptools
<pitti> to have the same effect
<persia> And make the transition near-invisible for most developers.
<lifeless> I'm going to have to apply sanity-sticks to get that project to have more committers in the short term; once thats done I'll submit a merge proposal to clear things up
<lifeless> we do have different licences on the current code, but the sasme (C) holder. for hilarity.
<ogra> seb128, poke ... with the last gtk upload my system started to misbehave massively, i had to downgrade libgtk2.0-2 ... did you hear complaints from anyone else ?
<seb128> define misbehave
<seb128> "it doesn't work"?
<ogra> seb128, like X taking 100% CPU, evo locking up the machine, widgets in xchat's chat window start to flicker heavily, gnome-terminal flikers a lot
<seb128> bug #523949
<ubottu> Launchpad bug 523949 in gtk+2.0 "the csd changes make some desktop applications hog the cpu" [High,In progress] https://launchpad.net/bugs/523949
 * ogra checks
<seb128> for the cpu issue, I'm about to upload an improved version
<seb128> dunno about the flickering
<ogra> in xchat the separator between nicks and text (that little vertical line) gets random flickering dots ... looks like an old movie :)
<ogra> i know jdub had similar issues ... but that bug seems to describe it, i'll try the upgrade
<poolie> pitti, lifeless: so having one client set for launchpad is better than having many fractional-assed ones
<pitti> poolie: depends on what you need
<poolie> the problem is that many are just toys
<poolie> and, right, people have different ideas of what is useful
<pitti> poolie: the one you pointed me to is great for actually doing work in Launchpad
<pitti> poolie: I use lp-shell for testing code snippets using launchpadlib before I put them into programs
<poolie> where do you put them?
<pitti> not for actually doing stuff on LP
<pitti> poolie: apport, for example
<pitti> or the work item tracker
<poolie> yay apport :-)
<qwer> Wholy fucking shit - a bios update fixed EVERYTHING! And I've been using this hardware for 4 years...
<persia> !ohmy
<ubottu> Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<cjwatson> I find lp-shell useful for when I'm doing odd one-off things nobody has thought to write explicit programs for yet
<dholbach> ifupdown 0.6.8ubuntu21.1 in karmic-proposed tries to overwrite etc/init.d/networking from netbase
 * Mamarok was going to report the same :)
<pitti> Mamarok, dholbach: erk, can you please report this to bug 497299?
<ubottu> Launchpad bug 497299 in ifupdown "upstart not starting init-scripts (event net-device-up IFACE=lo missing)" [High,Fix committed] https://launchpad.net/bugs/497299
<pitti> weird though, the package just changed the postinst
<Mamarok> done
<dholbach> pitti: http://paste.ubuntu.com/381526/
 * pitti removes that version from -proposed
<pitti> thanks for the report
<dholbach> no worries
<pitti> bug updated accordingly
<pitti> slangasek: ^ FYI
 * ogra tries out seb128's fixed upload ...
<ogra> seb128, still the flickering dots in xchat
<seb128> ogra: talk to bratsche when he will be there
<ogra> yep
<seb128> I still get the slowness issue too
<ogra> same here
 * ogra downgrades gtk again
<seb128> so I guess his fixes is not working as expected
<ogra> sadly that makes evo unhappy
<ogra> ah, better ... gdm looks intresting though with the clinet side frames :)
<cjwatson> ArneGoetje: pinyin-database looks like it may need an MIR for promotion to main?
<tseliot> mdeslaur: do we ship 64bit flash on amd64?
<tseliot> (in lucid)
<tjaalton> tseliot: no
<tseliot> tjaalton: oh, do you know why?
<tjaalton> aiui adobe doesn't want people to ship prerelease versions
<tjaalton> there should be a bug about it
<tjaalton> s/should be/is/
<tjaalton> tseliot: bug 331275
<ubottu> Launchpad bug 331275 in adobe-flashplugin "adobe-flashplugin not available on 64-bit Ubuntu 8.04" [High,Triaged] https://launchpad.net/bugs/331275
<tseliot> tjaalton: thanks
<cjwatson> dpm: did you see my request for branch recreation in bug 518718?
<ubottu> Launchpad bug 518718 in ubuntu-translations "Change "Ubuntu Netbook Remix" messages to "Ubuntu Netbook Edition"" [Low,In progress] https://launchpad.net/bugs/518718
<dpm> cjwatson, yeah, thanks, I just haven't had the chance to do it
<cjwatson> james_w: I'm getting hourly e-mails about "spiv/jam" not being a valid Launchpad account in foundations-lucid-distributed-development work items; can that be regularised?
<dpm> pitti, could you please copy the latest karmic PPA to karmic-proposed when you've got some time? They include a fix in FF translations generated with po2xpi which would be good to get tested
<dpm> (the language packs, I mean)
<pitti> dpm: sure, running
<dpm> cool, thanks pitti!
<davmor2> pitti: https://bugs.launchpad.net/bugs/422536 seems to of crept back into Lucid.
<ubottu> Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/422536)
<dholbach> **
<pitti> davmor2: eww; mind to reopen it then with a comment?
<davmor2> pitti: no probs
<nigelb> pitti: hey, you got some time?
<nigelb> wondering how to make a report from an apport hook automatically private
<pitti> nigelb: I need to leave in 10 mins for some 2.5 hours, so only if it's quick
<nigelb> I've been working on a hook for rhythmbox, so some of the data might be private
<pitti> but if it's a private bug, nobody will be able to see it..
<pitti> nigelb: wouldn't it be better to filter out the potentially private bits?
<nigelb> I'm working on that right now
<nigelb> but, otherwise, there is no way to make the report private?
<pitti> nigelb: we could add that to apport relatively easily
<pitti> like report['Private'] = 'Yes'
<pitti> report['Subscribers'] = 'ubuntu-core-dev'
<nigelb> oh, that works now?
<pitti> but I don't think it's a very clean use case
<pitti> nigelb: no, it doesn't right now
<nigelb> from the angle of how many people can work on the bug, I agree, it looks messy
<pitti> we sort of have to deal with it for crashes, but for hooks we might just better try to obfuscate/filter sensitive stuff
<nigelb> it would mean only bug control and a small group of people can see the report
<nigelb> I'll get around to filtering it then.  Thanks :)
<pitti> nigelb: like, if you dump the DB, you could replace all file and tag names with a dummy
<pitti> so that structural damage is detected, but no actual information exposed
<pitti> credentials from the music stores should of course be filtered out entirely
<pitti> nigelb: ok, good luck! if you have further questions, I'll answer scrollback once I'm back
<nigelb> I'm just getting a dump of gconf data.  I've figured of all fields that needs to be removed, so the data in the fields is going to be replaced with ##masked##
<pitti> nigelb: for the ease of triaging, you might just check their validity, and remove them altogether?
<pitti> i. e. see what you would like to look at as a triager, and try to automate that, so that the "unusal" bits stand out
<pitti> anyway, need to go, cu later
<nigelb> okay :)
<persia> So we just get a nice report "Database OK" or "Database corrupt", or similar?
 * nigelb frowns
<nigelb> thats a lot of work
<nigelb> persia: this is what I have right now.  Its not much.  the masking is not working (yet), http://etherpad.com/nJwmxU3dGv
<persia> nigelb: I think you want to capture some data about the pulse configuration as well.  Maybe crimsun has a good suggestion for that.
<nigelb> I thought "report.add_package_info("pulseaudio")" did that
<persia> (or at least with my limited python it appears you're capturing gstreamer and alsa config, but not pulse config)
<nigelb> the pulse bit it between alsa and gstreamer
<persia> Oh, I missed that bit, perhaps because it came after the paplay call.
 * persia apologises for the unnecessary highlight
<nigelb> the more eyeballs it get, the more bugs i correct
<nigelb> (otherwise, I would have never known the earlier wav didn't work)
<ogra> seb128, ha ! my armel desktops are not affected by the csd bug :)
<ogra> we should just all switch to armel :)
<seb128> lol
<soren> cjwatson: I just stumbled upon bug 246558. I'd still love to get that fixed. Do you have an opinion on the approach taken in my patch? The patch is a couple of years old, so probably needs fixing up.
<ubottu> Launchpad bug 246558 in openssh "ssh's init script should generate host keys if they're missing" [Low,Confirmed] https://launchpad.net/bugs/246558
<nigelb> seb128: do you deal with merges for rhythmbox?
<seb128> nigelb, yes, why?
<nigelb> seb128: I'm merging an apport hook :)
<nigelb> or requesting a merge for rather
<seb128> hum, what we call merge usually is taking debian changes
<seb128> that's rather sponsoring
<nigelb> sorry, should have been more clearer
<seb128> nice, thanks, I will have a look to that
<nigelb> just doing it locally now, will ping you once finished
<seb128> ok thanks
<zul> soren: ssh uses upstart now as well fyi
<soren> zul: Really? The package still ships an init script?
<soren> Bah, I'm on crack.
 * soren can't spell "init"
<zul> heh
<cjwatson> soren: doing anything like this at boot makes me uncomfortable - I keep imagining Scott turning up at my door with an axe
<cjwatson> soren: and this patch wouldn't deal with Bjorn's use case, because of the special postinst handling of no HostKey directives
<cjwatson> all looks rather tricky :(
<soren> I never understood the no-hostkey thing.
<soren> How does openssh do without a hostkey?
<cjwatson> I thought Bjorn explained that
 * soren rereads
<cjwatson> #ifndef GSSAPI
<cjwatson>         /* The GSSAPI key exchange can run without a host key */
<cjwatson>         if ((options.protocol & SSH_PROTO_2) && !sensitive_data.have_ssh2_key) {
<cjwatson>                 logit("Disabling protocol version 2. Could not load host key");
<cjwatson>                 options.protocol &= ~SSH_PROTO_2;
<cjwatson>         }
<cjwatson> #endif
<cjwatson> (sshd.c)
<soren> I see.
 * soren goes to a phone call
<james_w> davmor2: hey, could you open a new bug for the EDAC warning thing please?
<davmor2> james_w: I can indeed
<mdeslaur> Is it possible to use an icon from a path when porting a python app to application indicators?
<james_w> that bug is too huge and horrible to be useful
<james_w> I want it to go away
<davmor2> james_w: np's 2 ticks
<james_w> thanks davmor2
<davmor2> james_w: bug 525792
<ubottu> Launchpad bug 525792 in linux "EDAC amd64: WARNING: ECC is disabled by BIOS. Module will NOT be loaded." [Undecided,New] https://launchpad.net/bugs/525792
<james_w> davmor2: you are getting this as an apport popup?
<davmor2> james_w: Yeap
<james_w> thanks
<sgnb> anyone here willing to help with OCaml transition (#522358, #522363)?
<davmor2> james_w: Is there anything else you'd like adding that might be useful?
<james_w> davmor2: a patch? :-)
<james_w> davmor2: I understand the issue and your logs that apport attached should be sufficient to work out why the pattern isn't matching to ignore this issues
<davmor2> james_w: Hmmmm a patch from me do you hate the kernel?
<james_w> davmor2: it's not really a kernel issue
<james_w> though I don't think it should be acting like this
<james_w> the issue is with kerneloops, it shouldn't be causing an apport report for this issue, I just reassigned
<BenC> Good morning software scally wags
<mdeslaur> tedg: Is it possible to use an icon from a path when porting a python app to application indicators?
<tedg> mdeslaur: Not currently.  Do you have a use-case?  Why is the icon not installed?
<mdeslaur> tedg: well, I started to port virt-manager to app indicators, and it's icons are in it's own directory...
<tedg> mdeslaur: Is it in an "icon-theme" format?  Like with all the different sizes?
<tedg> mdeslaur: If so, you just need "new_with_path" which installs an icon theme path, but I think that's not in the Python bindings for some reason.
<mdeslaur> tedg: unfortunately not, it's just a single icon in a directory
<tedg> mdeslaur: :-/  We probably should fix that... can we just install it in /usr/share/icons/hicolor ?
<tedg> mdeslaur: (that's the spec locations for one-of icons)
<qense> tedg: we did find an appindicator.icon_path property, but that was the only reference to an icon path we could find.
<qense> I've also got a problem with an icon being located in /usr/share/pixmaps/{appname}/{appname}_tray.png
<qense> at*
<jcastro> mdeslaur: did you file a bug for virt-manager app indicators?
<tedg> qense: Yeah, it needs to be built at construction time.  So in the current Python bindings you really need the special _new function.  With PyGI it would be possible to se it.
<mdeslaur> tedg: ok, I'll try putting a symlink in there
<mdeslaur> jcastro: LP #525462
<jcastro> ta
<ubottu> Launchpad bug 525462 in virt-manager "Support Application Indicators" [Wishlist,Triaged] https://launchpad.net/bugs/525462
<nxvl> kirkland: ping
<kirkland> nxvl: yo
<nxvl> kirkland: are you still maintaining encrypted home directory?
<nxvl> kirkland: a friend of mine hited a really weird bug
<nxvl> and i was able to reproduce it
<kirkland> nxvl: yes
<kirkland> nxvl: what's the bug?
<nxvl> kirkland: if you have EHD, and change the user password from A to B, then reboot, for some reason the system won't accept B, but it will A, but your HD won't get decrypted
<nxvl> kirkland: (change the password using the UI, haven't tried using passwd)
<kirkland> nxvl: you can successfully change the password as the user, using either passwd or System->Preferences->About Me->Change password
<kirkland> nxvl: but you can't use the admin user to force-overwrite the user's password, using passwd or System->Administration->Users
<nxvl> i used.... System > Administration > Users and Groups
<kirkland> nxvl: because if the admin does it, the admin is not prompted for the user's old password
<kirkland> nxvl: note that this is fixed in Lucid
<kirkland> nxvl: the key is that we need to "re-wrap" the passphrase
<kirkland> nxvl: for that, we need the old password and the new password
<nxvl> kirkland: actually i used the same user to change it's own password, and it was indeed prompted for the old password
<kirkland> nxvl: are you *sure*?
<kirkland> nxvl: i bet you were prompted by gk-sudo to run that app
<kirkland> nxvl: and then you were asked for the user's new password, and that's all
<kirkland> nxvl: is this 9.10?
<nxvl> kirkland: i went to Users and Groups, the selected the user, clicked properties, click on change password, it asked me for the current password, once i hitted autenticate it unblocked the new password and repeat pasword input field
<nxvl> kirkland: yup, 9.10
<kirkland> nxvl: yes, the first password you entered just unlocked administrator mode
<chrisccoulson> nxvl - if you're referring to users-admin, did you use it to change somebody elses password?
<kirkland> nxvl: it was not used in the passwd call
<kirkland> nxvl: hence the problem
<kirkland> nxvl: again, i note, look at the behavior in Lucid -- this is fixed
<nxvl> chrisccoulson: nope
<nxvl> kirkland: no, not the onlocking
<chrisccoulson> nxvl - that should work in karmic too if you are changing your own password
<nxvl> kirkland: on the users and groups dialog you have a button with keys on it, that's the one to unlock, that's NOT the one i pressed
<chrisccoulson> is gnome-about-me installed?
<nxvl> kirkland: i selected the user (i.e. nxvl) from the list the dialog shows
<nxvl> kirkland: then clicked properties on the right
<nxvl> kirkland: once in that new dialog there is another button "Change Password..."
<nxvl> clicked on that and a "Change password" dialog apeared
<nxvl> let me take a screenshort
<nxvl> kirkland: how do i upload to people.ubuntu.com?
<kirkland> nxvl: it's people.canonical.com now
<nxvl> oh, ok
<jpds> nxvl: That or: https://wiki.ubuntu.com/PeopleUbuntuCom
<nxvl> kirkland: http://people.canonical.com/~nxvl/change_password.png\
<nxvl> kirkland: http://people.canonical.com/~nxvl/change_password.png
<chrisccoulson> that dialog is part of gnome-control-center
<chrisccoulson> i'd be surprised if that doesn't work. it just calls passwd
<nxvl> it doesn't, it seems that it changes something in cryptfs, but not the password itself in the system
<nxvl> is really weird
<kirkland> nxvl: fwiw, i have this script in my ~bin/pcc, pcc=people.canonical.com: http://people.canonical.com/~kirkland/pcc
<kirkland> nxvl: so i can just pcc <FILE> or pcc <DIR>
<kirkland> nxvl: yep, this is broken in 9.10
<kirkland> nxvl: because the "authenticate" step is separate from the change password step
<nxvl> oh really?
<kirkland> nxvl: so the password given in the first step is NOT passed to passwd on the change password
<kirkland> nxvl: rather, after being authenticated, it just force changes the password as root
<kirkland> nxvl: so i'm telling you ...
<nxvl> ohhh
<kirkland> nxvl: a) this is fixed in Lucid
<nxvl> ok, that makes sense
<kirkland> nxvl: b) use passwd on the command line
<kirkland> nxvl: or c) use About Me to change password
<chrisccoulson> kirkland - the gnome-about-me dialog should actually work though (it passes the old password to passwd)
<kirkland> nxvl: and if you really want this fixed, then propose an SRU or something
<kirkland> chrisccoulson: absolutely, About Me will definitely work
<chrisccoulson> the one with the issue was users-admin, which we worked around in karmic by calling gnome-about-me
<chrisccoulson> but the dialog nxvl shows is the gnome-about-me dialog
<kirkland> chrisccoulson: hrm
<nxvl> kirkland: oh yeah, actually it is
<nxvl> i just tried the About me and got the same dialog
<randomaction> Can some core dev(s) please help with the OCaml transition? Currently 2 packages are waiting for a sync ACK (bug 522358), and 2 packages need to be rebuilt (bug 522363).
<ubottu> Launchpad bug 522358 in jocaml "[OCaml 3.11.2 transition][round 2/6] Please synchronize packages involved in OCaml transition from Debian sid to lucid" [Wishlist,Confirmed] https://launchpad.net/bugs/522358
<ubottu> Launchpad bug 522363 in xml-light "[OCaml 3.11.2 transition][round 2/6] Please rebuild packages involved in OCaml transition" [Undecided,Fix released] https://launchpad.net/bugs/522363
<randomaction> In total, around 100 uninstallable packages are blocked on this.
<pitti> randomaction: the two syncs are already approved
<pitti> randomaction: do you need them synced right now?
<pitti> randomaction: hevea/ocaml synced
<pitti> "jocaml"
<pitti> randomaction: and the two rebuilds uploaded
<randomaction> pitti: thanks for that
<pitti> randomaction: oh, seems I missed camlp5; syncing
<randomaction> pitti: great, thanks again!
<randomaction> james_w: thank you, too
<randomaction> sgnb: round 2 complete (except for actual building)
<Laney> bah
<Laney> you guys and your easy ocaml transition!
<Laney> ghc6 is having trouble even building...
<randomaction> sgnb: for the next rounds, it'll probably be more handy filing separate bug reports for packages in main and universe
<nigelb> seb128: bzr merge requested for rhythmbox apport hook :)
<seb128> nigelb, thanks
<nigelb> :)
<sgnb> randomaction: I've just added two packages for round 2 that I overlooked
<sgnb> randomaction: you mean 4 bugs per round?
<sgnb> (i.e. {main,universe} x {sync,rebuild})
<Laney> can't you just poke a friendly archive admin with a list of stuff to sync?
<sgnb> Laney: I don't know any
<randomaction> Laney: that's a more efficient way to handle a transition :)
<sgnb> (I mean, I don't know any archive admin... not that all archive admin are not friendly)
 * Laney is sure that some read this channel :)
<sgnb> Laney: what's the difference between archive admins and sponsors?
<sgnb> (in Debian, archive admins mostly don't care about transitions)
<nigelb> seb128: hold off, I made a mistake.  will correct and push again
<seb128> nigelb, ok
<Laney> sgnb: Archive admins push the buttons to make syncs happen
<Laney> and other things like handling removals
<sgnb> ok
<Laney> and NEWing, kind of like ftpmasters
<sgnb> Laney: but how are rebuilds handled?
<Laney> by doing a new sourceful upload
<sgnb> (most of the work is in rebuilds)
<Laney> don't need archive admin powers to do that, just upload access
<sebner> Laney: NEW is so awfully full *hrhrhrhr*
<sgnb> Laney: there are no such things as binNMUs, right?
<Laney> nope (sadly)
<nigelb> seb128: Done.  Sorry. I forgot to change changelog from karmic to lucid :)
<randomaction> sgnb: I'm confused about confluence and ocamldsort, they only depend on libc6, do they need to be updated?
<sgnb> randomaction: they depend on ocaml on armel and ia64 (aka "bytecode" architectures)
<nxvl> james_w: hi
<nxvl> james_w: i just hitted BTS #570504
<sgnb> (and btw, I've juste understood why I overlooked them at first)
<nxvl> james_w: is there a workaround or something i can do to use bzr bd?
<nxvl> i kinda need it
<seb128> nigelb, do you have a bug about this change?
<james_w> bug 570504
<ubottu> Error: Launchpad bug 570504 could not be found
<james_w> debian bug 570504
<ubottu> Debian bug 570504 in bzr-builddeb "ERROR: No module named configobj" [Grave,Open] http://bugs.debian.org/570504
<nxvl> mm ubottu sould know what BTS is
<randomaction> sgnb: ok, I missed that on i386 :)
<james_w> nxvl: hmm, I'm not sure of how to workaround this without editing files
<james_w> nxvl: I can tell you what change to make to fix it if you want to edit the files on your system
<james_w> or you could use lp:bzr-builddeb temorarily
<nxvl> james_w: would those changes be overriden by the next package installed?
<james_w> yeah
<nxvl> james_w: as in, when the package with the fix is uploaded to the ppa, would the files edited dump the changes?
<james_w> yeah
<nxvl> then i can edit some files, will take a look at the patch in the branch
<nigelb> seb128: no
<seb128> nigelb, can you maybe open one and put the url for the change there?
<cjwatson> jcastro: I was about to go and fix bug 494282, but I see you're assigned to it - do you need a branch merged or anything?
<seb128> it's easier to keep track of those
<ubottu> Launchpad bug 494282 in example-content "example-content in Lucid still shows flat file icon for ~/Examples (dup-of: 458250)" [Undecided,Confirmed] https://launchpad.net/bugs/494282
<ubottu> Launchpad bug 458250 in example-content "Examples folder has no icon" [High,Triaged] https://launchpad.net/bugs/458250
<seb128> I'm not even sure I get bug emails otherwise
<cjwatson> dup> er, yeah, that one
<nigelb> seb128: you mean open a bug and put a closes into changelog?
<seb128> nigelb, just open a bug, I'm going to do a new git snapshot
<seb128> so I will tweak changelog anyway
<nigelb> will do :)
<seb128> but I got nothing now, I think I don't get those merge request emails
<nxvl> james_w: what's the revision with the fix? i don't find the patch
<seb128> we usually use sponsoring bugs rather for desktop changes
<seb128> nigelb, thanks
<nxvl> james_w: nm, found it
<nigelb> seb128: ah, I know, but this is not exactly a bug, thats why went this route
<seb128> well a feature request
<seb128> or a sponsoring request
<seb128> all the same we use bug reports
<nigelb> will do this in the future :)
<jcastro> cjwatson: I was going to fix it when we upload the free culture showcase winner.
<seb128> nigelb, thanks
<jcastro> cjwatson: feel free to do it now if you want!
<nxvl> james_w: works \o/
<james_w> score
<james_w> thanks for testing
<nigelb> seb128: bug 525888 opened :)
<ubottu> Launchpad bug 525888 in rhythmbox "Apport hook for rhythmbox" [Undecided,New] https://launchpad.net/bugs/525888
<seb128> nigelb, thanks
<jdong> hmm, after archive reorg, seems like I lost my magic powers to upload to the -backports pocket...
<jdong> *sniff sniff*
<jdong> can an archive admin / core-dev take a look at bug 411849 please? sponsor the debdiff in the initial comment to hardy-backports?
<ubottu> Launchpad bug 411849 in hardy-backports "Please backport security fix for USN-812-1 in subversion 1.5" [Undecided,Fix committed] https://launchpad.net/bugs/411849
<cjwatson> ... I didn't know you had such powers?  didn't the TB say it should be core-dev only for direct uploads?
<jdong> cjwatson: that was what it was supposed to be, yeah, but for quite some time I seemingly posessed the power to do so
<jdong> maybe that was by error/accident :)
<jdong> I seem to recall we had a conversation about it (or maybe it was just ScottK) and concluded that the ACL was okay since an archive-admin has to prod it through anyway
<cjwatson> not aware of archivereorg affecting this
<Laney> any developer could upload to -backports
 * Laney has done so before
<jdong> Laney: I just got shot down :)
<jdong> Signer is not permitted to upload to the component 'main'.
<jdong> maybe it's -universe only for MOTU?
<jdong> "MOTU"
<Laney> you can probably find a backport to test with
<jdong> Laney: or find someone who knows the answer ;-)
<Laney> bah, that's no fun!
<shtylman_> has the libmysqlclient situation been unmangled?
<pitti> shtylman_: yes
<shtylman_> pitti: when will that hit the repos? any idea?
<pitti> shtylman_: last week :)
<shtylman_> pitti: really?
<shtylman_> pitti: http://packages.ubuntu.com/lucid/liblua5.1-sql-mysql-2
<shtylman_> I look at that ... and that one in particular is still on 15
<pitti> libmysqlclient16 | 5.1.41-3ubuntu6 |         lucid | amd64, i386
<pitti> shtylman_: if you have the 7 version installed locally, you need to purge it
<shtylman_> pitti: k... I will try that
<persia> shtylman_: You may find rmadison more usefully informative than packages.ubuntu.com
<shtylman_> persia: thanks
<cjwatson> jcastro: ok, thanks, will do
<cjwatson> happened to see YA duplicate of it going past ...
<james_w> was the entirety of mysql-cluster nuked?
<james_w> it's in binary NEW, and all the binaries it builds are showing as new
<shtylman_> pitti: is there a nice way to purge that package without also uninstalling what depends on it?
<pitti> shtylman_: does somethign depend on it?
<pitti> shtylman_: I could just purge it here; it had one other library dependency which got purged along
<pitti> shtylman_: if you actually need it, use apt-get install libmysqlclient/lucid
<shtylman_> libmysqlclient16 yea... when I purge it .. it also wants to remove akonadi ... etc
<james_w> would apt-get install libmysqlclient16=5.1.41-3ubuntu6 work
<cjwatson> dpkg --purge --force-depends
<james_w> possibly with --force-downgrade
<cjwatson> (BE VERY CAREFUL)
<pitti> james_w: libmysqlclient/lucid should do that as well, it downgrades
<cjwatson> installing a lower version explicitly is definitely better if you can
<pitti> sorry
<pitti> apt-get install libmysqlclient16/lucid
<pitti> (forgot the number)
<shtylman_> the lower version install worked
<shtylman_> thanks all :)
<nailora> there is bug 11334 that i am following for quite some time because it bugs me, too :) it is about what happens to the clipboard contents when an application quits. discussion has become more and more off-topic, and there seems to be a lack of developer participation. i'd like to know how to proceed with this...
<ubottu> Launchpad bug 11334 in ubuntu "MASTER Copy-Paste doesn't work if the source is closed before the paste" [Wishlist,Confirmed] https://launchpad.net/bugs/11334
<nailora> it is somewhat broken deep within the x-server (or the spec the x-server follows). or nearly all application just do not to the right thing as it can be fixed on application level, too. but this will not happen for all legacy applications. clipboard managers are not the solution but a workaround, but waiting for a solution in x.org/the spec x.org follows will take lots of time and a workaround might be good in the meantime... ...
<genii> I have Intel Pro/1000 XF (fibre optic card) ethtool is reporting only 1000 Base T (copper) capability (when should be 1000 Base FX). Is there some known prob/fix for the e1000 driver?
<cjwatson> nailora: workaround: use a clipboard manager application, that takes a copy of the clipboard contents and stashes it
 * pitti reenables hourly WI tracker updates, sorry
<cjwatson> it's an X design issue, I wouldn't expect it to be fixed any other way
<cjwatson> indeed I don't think it is *fixable* any other way
<nailora> cjwatson: i know that and i do it it that way personally. but arguably this should "just work" for everyone. that would require a solution that could be included in the default installation
<cjwatson> if you're starting from the position that "clipboard managers are not the solution but a workaround", then there is no other option except to wait for (or participate in?) an X design fix
<cjwatson> X clipboard clients ask the clipboard owner (an application) for clipboard contents when they need it, and if the application exits then there's no owner to respond; there's no way that can be an application bug
<chrisccoulson> which applications don't work correctly?
<chrisccoulson> i could only recreate that with firefox, and that's been fixed upstream recently
<cjwatson> maybe something is managing the clipboard centrally now?
<nailora> it seems that upon exiting an application is able to ask the x server to preserve the contents somehow (most gnome apps and notably firefox nowadays do it). so it can be fixed on application level
<jdong> isn't that something introduced way bac: http://library.gnome.org/misc/release-notes/2.12/#rngeneral
 * cjwatson is just five seconds late with the same link
<chrisccoulson> the clipboard is still based around the selection mechanism
<nailora> but most apps simply do not do that. and somehow it seems redundant that you have to request this "feature" if i cannot think of a situation where you would not want it. so it should be default to save the contents and thus be handled in x.org (even so contents from crashing applications would still be lost that way).
<cjwatson> gnome-settings-daemon, apparently
<chrisccoulson> but applications that don't work explicitly destroy these resources when they close
<nailora> therefore i think a push solution (instead of pull like now) is in fact better (and clipboard managers are basically transforming it from pull to push)
<cjwatson> nailora: do you have evidence that applications need to explicitly request this feature?
<cjwatson> the current state appears to be basically just a clipboard manager built into gnome-settings-daemon
<cjwatson> I don't see any application-level requests going on - gnome-settings-daemon responds to various X events
<nailora> however todays clipboard managers are to much bling bling. they should run in the background, have no gui, just make things work. history and stuff like current implementations offer could optionally be added for power users). and something sensible should be done with binary data in case applications offer different content depending on the receiver (notably the gimp does this). these things could be fixed easily. but no developer commen
<cjwatson> nailora: gnome-settings-daemon's clipboard manager runs in the background, with no bling
<cjwatson> no UI at all AFAICS
<nailora> no i have no strong evidence, it is just how i understood the discussion in the bug
<cjwatson> you're making some assertions that don't seem to match how the code works
<cjwatson> at this point, I imagine that developers are put off commenting on the bug simply because it's one of those enormous unmanageable bugs
<nailora> cjwatson: gnome-settings-daemon's clipboard manager does not seem to fix all problems
<cjwatson> this is why bugs need to be kept small and focused, and why jumping into an existing bug to expand its scope tends to be harmful
<nailora> so you basically are suggesting a new bug should be opened containing a short&precise list of applications that are still broken and an overview about the possible solutions?
<cjwatson> ah, let's see, there's a SAVE_TARGETS request
<cjwatson> not suggesting that at all
<cjwatson> I'm suggesting that, if it works for many applications, there ought to be a separate individual bug against each application that seems to have a problem in conjunction with the clipboard
<cjwatson> grab-bag bugs are fundamentally doomed
<cjwatson> apologies for not noticing SAVE_TARGETS before now, that supports the application-request assertion you made
<nailora> installing a clipboard manager by default would have solved all the issues so it was not unreasonable to group it at that time.
<cjwatson> it may not have been unreasonable, but it was never going to work well :)
<nailora> when favoring the fix-every-application-solution this massive collection is counterproductive
<cjwatson> http://www.freedesktop.org/wiki/ClipboardManager seems to be the closest thing that's going to happen to a spec-level change
<nailora> but it seems as if this is not a simple "bug" but something that needs more discussion
<nailora> has been featured in forums & brainstorm too
<cjwatson> it seems reasonable to file separate bugs against individual applications (presumably non-GTK applications, for the most part? don't know about Qt) that don't support it
<nailora> just tried dolphin and it fails :)
<nailora> so yeah, perhaps all qt-apps could be fixed with one change. this would be a big improvement but still leaves a lot more apps. but it shows why the "applications can request this feature" is the wrong default imho. apps should be allowed to opt-out but have it enabled by default because that way data loss is prevented.
<slangasek> pitti: sorry about that; ifupdown reuploaded
<pitti> slangasek: ah, thanks; what happened there?
<slangasek> pitti: ifupdown hadn't been rebuilt with the karmic-final version of debhelper, so this conflict went unnoticed; was already fixed in lucid, but I'd forgotten about it and didn't do a test install of ifupdown on karmic before upload, thinking it was a trivial change :/
<pitti> I suspected something like that when the problem was reported, but it wasn't obvious that something like that could happen when I reviewed the diff
<pitti> thanks for the fast fix
<pitti> I'll check/accept it right away
<slangasek> pitti: ta!
<mrenouf> Is it possible to make unattended-upgrade work like 'apt-get distupgrade' ? Specifically, permit it to install versions with new dependencies?
<mrenouf> I'm now reading the apt source for clues ;-)
<slangasek> cjwatson: hmm, we have a topic lock here?
<cjwatson> slangasek: maybe imposed during the last days of hyperion?
<cjwatson> (sounds like a Dan Simmons novel)
<slangasek> heh
<slangasek> cjwatson: could you unset, or add a mention of FF? :)
<cjwatson> unset
<slangasek> cheers
* slangasek changed the topic of #ubuntu-devel to: Lucid Alpha 2 released | Archive: Feature Freeze | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<mathiaz> bdmurray: hi! I'd like to add a query to bughugger
<mathiaz> bdmurray: I'd like to generate a list of bugs to which the ubuntu-server is subscribed, that are in New,Undecided and that haven't been created today
<mathiaz> bdmurray: being able to filter by date in LP is not possible from the advanced search AFAICT
<mathiaz> bdmurray: the next option I'm looking into is bughugger
<ccheney> anyone notice thinkpads not spinning their fans up enough to cool down?
<tkamppeter> pitti, hi
<Pici> ccheney: Yes.  But I thought it was just mine, I had to replace the fan not that long ago and thought it might be acting up again.
<ccheney> i'm building webkit and the cpu is up to 87C
<mrenouf> ouch
<ccheney> and the fan doesn't seem to be making too much noise
<kklimonda> ccheney: 87C is bad? My get up to 99C :/
<ccheney> kklimonda: its still climbing
<Pici> I hit 102C the other day.
<ccheney> iirc my system has gotten in the mid 90s before and starting having errors
<kklimonda> my started acting strange when it got over 100C once :/
<kklimonda> gcc was segfaulting
<ccheney> i'm not sure what the max speed of the fan is supposed to be but it claims to be at ~ 4300rpm
<mrenouf> if you're doing something cpu intensive for long periods of time, i'd recommend a stand where there is free airflow around all sides
<ccheney> its sitting on a flat desk with plenty of airflow
<Pici> Anyone know if there is already a bug logged for this?
<kklimonda> my laptop is going to die anyway - I'm a lucky owner of the nvidia gpu from G86 serie..
<kklimonda> Pici: is it even a bug? laptops get hot. period. :)
<mrenouf> well if you could simulate the same cpu activity under windows and that results in lower sustained temps. then yes. it's a bug.
<ccheney> 89C now
<ccheney> handrest is very warm :-\
<ccheney> i guess i'll try testing out the windows side after this build completes or dies due to heat, heh
<kklimonda> mrenouf: well - I've noticed that laptops get hotter when running linux in the idle but last time I've checked I could get my laptop to about 99C using Windows so I'm not sure if there is a bug
<ccheney> also i could try 9.10 or 9.04 to make sure it doesn't have the same issue also
<kklimonda> ccheney: have you tried cleaning it up?
<ccheney> hmm?
<ccheney> compressed air i suppose? just did that
<kklimonda> ccheney: using compressed air or a vacuum cleaner to get all the dust out of it ;)
<ccheney> it seems to have cooled it down at least temporarily
<bdmurray> mathiaz: http://qa.ubuntu.com/reports/team-subscribed/ubuntu-server-subscribed-bug-tasks.json would likely be a good a start
<ccheney> it was suprisingly dusty
<bdmurray> mathiaz: I could add in date_reported as a field then you could filter that result set with bughugger
<kklimonda> ccheney: well - you just have to believe in linux and your laptop to shut down itself when temperature gets critical
<mathiaz> bdmurray: that would be great!
<ccheney> yea
<mathiaz> bdmurray: how do I add a filter by date in bughugger?
<kklimonda> ccheney: I have an old T23 with a broken fan and it can get up to 103-104C and then system shuts down
<ccheney> actually its staying lower temp, i might have to run the build again to make sure that solved it, but its looking good so far :)
<ccheney> already down to 69C
<bdmurray> mathiaz: well the data (date reported) would need to be there first ;-)  I'll set it up and e-mail you or something
<tlyu> ccheney: it ingested a dustbunny that didn't agree with it?
<mathiaz> bdmurray: great - thanks!
<kklimonda> after I've cleaned up my T61 recently it idles at around 53C for cpu and 55C for gpu
<ccheney> tlyu: seems to have, lol :)
<mathiaz> bdmurray: does ubuntu-server-subscribed-bug-tasks.json include the list of bugs for packages to which the ubuntu-server team is a bug contact?
<ccheney> but it might not be doing as much work atm, so will need to rerun the build or run cpuburn to verify
<ccheney> it definitely had a disturbing amount of dust that blew out
<bdmurray> mathiaz: yes
<kklimonda> yeah, it's hard to believe how much dust can you blow out of your laptop :)
<ccheney> it seems to just be linking now instead of compiling so that may be part of the reason it cooled down
 * ccheney needs another can of air
<csurbhi> i have a question on acpi bios... i want to blacklist an acpi bios.. the options for blacklisting are a "system id" or "board id" .. i am in favor of using a board id as i think that a bios will be dependent on the board rather than the machine/laptop
<csurbhi> for eg: dell inspiron laptop (which shows an acpi bug) could have a different motherboard and then the bug may not show its face..
<csurbhi> oops.. wrong window :P
<ccheney> so far on the new build hasn't gone over 56C
<ccheney> its amazing what a heatsink can do if not coated in dust :)
<Caesar> slangasek: everything in main is supposed to be using upstart jobs now, right?
<james_w> no
<slangasek> Caesar: I don't think that was ever explicitly the target for lucid; certainly everything in main is a candidate for conversion, but there are some things that are probably too touchy to convert this late
<apachelogger> superm1: ping
 * sebner waves at apachelogger :)
 * apachelogger hugs sebner
<superm1> apachelogger, contentless pong
<apachelogger> superm1: hey, are you ok with moving bluez-gstreamer from a recommends of the bluetooth package to suggests? ... hence it probably needs to be added to the ubuntu-desktop seed
<apachelogger> currently it (along with all of gstreamer) gets pulled in on kubuntu
<superm1> sounds fine by me
<apachelogger> superm1: ok, are you going to add it to the seed?
<persia> May also have to be added to the serveral other gstreamer using flavour seeds.
<apachelogger> persia: good point, I better drop a mail somewhere
<persia> ubuntu-devel@ seems likely.
<persia> Alternately, check the set of tasks that currently apply, and go fiddle the seeds yourself/
<apachelogger> ah, I better let the appropriate people do that :)
<nxvl> james_w: still around?
<apachelogger> superm1: fixed package uploaded
<nxvl> james_w: how do i pass '-sa' or an equivalent to bzr bd?
<crimsun> nxvl: --
<nxvl> crimsun: thnx
<crimsun> bzr bd -S -- -sa [..]
<crimsun> pitti: help for apport-hookutils references http://docs.python.org/library/apport.hookutils, which is 404
<jcole> too much noise in #ubuntu
<jp_> hi guys. is there a way to fix lirc on intrepid without making a re install? i just saw that a reinstall fixes problms with it. any ideas???
<lifeless> jp_: #ubuntu for support please
<jp_> i've been there for 1 hours waiting for an answer, lifeless
<jp_> thank you anyway for the reminder
<lifeless> you can also try the forums
<lifeless> and answers.launchpad.net/ubuntu
<jp_> i have a forum post for 1 week with no answer
<jp_> thanks for the reminder again, you're so kind lifeless :)
<persia> james_w: I've just noticed an interesting case: bug #360590 received a branch link from the package upload import branch after the fix was released.  Is this intentional for tracking, or an artifact of how the upload was structured?
<ubottu> Launchpad bug 360590 in ubuntustudio "Please compile portaudio with Jack support" [Medium,Confirmed] https://launchpad.net/bugs/360590
<crimsun> slangasek: do you know if using "on mounted MOUNTPOINT=/var/lib" in an upstart job will DTRT, i.e., perform an action if /var/lib is mounted?
<slangasek> crimsun: I think that depends on what you think "TRT" is.  You shouldn't use that as a start condition for any job uploaded to Ubuntu
<james_w> persia: intentional
<slangasek> because /var/lib isn't going to be a separate mount point on 99.999% of systems, so you'll never see that signal
<persia> james_w: Nifty.  Do we need to do anything to make sure it happens?
<james_w> either upload a package with LP: or use --fixes when using bzr
<persia> ah, so the same things we do anyway.  Thanks for the work to make it so transparent.
<crimsun> slangasek: might "on mounted MOUNTPOINT=/var" be acceptable?
<slangasek> crimsun: what are you trying to accomplish?
<crimsun> slangasek: run a job only if /var/lib/alsa is accessible to fix the store race
<crimsun> I suppose since in most cases /var isn't separate, /var really wouldn't be correct either
<slangasek> you will only get 'mounted' signals for things that are actually mount points.  You can't assume that any mount point other than / is or isn't a separate mount point.
<slangasek> you want 'on filesystem' for that
<crimsun> slangasek: ok, thanks
<slangasek> (what store race?)
<crimsun> slangasek: on some system it appears that / is mounted read-only, so alsactl store will fail
<slangasek> crimsun: in what job?
<slangasek> I only have alsa-mixer-save.conf here, and that only runs on shutdown
<crimsun> slangasek: this was karmic's alsa-utils, but it appears to be reproducible in lucid's
<crimsun> right, lucid added that job
<slangasek> ok, so what job has the bug?
<persia> crimsun: Could you stick it in /var/run (exceedingly likely to be mounted separately and early), and copy to /var/lib if it's writable?
<crimsun> slangasek: meaning which version? lucid'sl
<slangasek> crimsun: no, what *job*?
<crimsun> slangasek: alsa-mixer-save
<slangasek> crimsun: the only job I have in alsa-utils is one that runs on *shutdown*
<crimsun> slangasek: right, that's the job
<slangasek> then 'on mounted' and 'on filesystem' have nothing to do with it
<crimsun> persia: eek? I don't think that's any better than attempting the store directly.
<persia> crimsun: It's only better in terms of error codes without || true :)
<slangasek> crimsun: is there a bug number for this?
<crimsun> slangasek: https://bugs.launchpad.net/ubuntu/+source/alsa-utils/+bug/366160
<ubottu> Launchpad bug 366160 in alsa-utils "reboot hangs due to alsa issue (probably regression of bug 274995)" [Undecided,Incomplete]
<slangasek> crimsun: start on starting rc RUNLEVEL=[06]
<hacker07_> hey
<crimsun> slangasek: great, thanks
<hacker07_> i have a question
<slangasek> crimsun: that works because what you want is to serialize alsa-mixer-save wrt /etc/rc[06].d/, which is what mounts / ro at shutdown
<crimsun> slangasek: excellent, thanks for the explanation
<cjwatson> hacker07_: just ask, rather than asking to ask
<hacker07_> okay
<hacker07_> is there an application in development to change the xsplash theme? or images?
<slangasek> ccheney: do you know why OOo wants to pull ttf-sil-gentium-basic into main, and whether we should sub a different font that's already in main for Ubuntu?
<slangasek> ccheney: _rene_'s changelog says "for graphite support"
<slangasek> but I don't know what that is
<ccheney> ah then most likely for graphite which does font support for non-latin 1 based (complicated glyph) languages
<ccheney> but afaict it only has this dep in 'openoffice.org' itself which isn't in a seed?
 * ccheney greps control to see if it is somewhere else
<slangasek> ccheney: everything in main is seeded somewhere
<slangasek> why does graphite need this font /specifically/, when we already have other fonts in main that correctly implement glyphs for languages with shaping?
<ccheney> the sil gentium font is for the sil graphite library afaict which is the thing that does font support for complicated glyphs (for lack a better explanation)
<ccheney> http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&cat_id=RenderingGraphite
<slangasek> ccheney: so is this not a Unicode font?
<slangasek> if it is, it should be redundant wrt the other fonts we already have that handle shaping
<geser> mathiaz: Hi, are you working on merging mutt?
<mathiaz> geser: no
 * ccheney still investigating to see what it does exactly
<ccheney> actually if i am reading this correctly its by the people who wrote graphite but its not for graphite itself, hmm will have to ask rene what is going on
<geser> james_w: have you an idea what those date-versioned branches listed on https://code.edge.launchpad.net/ubuntu/+source/mutt and https://code.edge.launchpad.net/debian/sid/+source/mutt are? left over from the package importer?
<james_w> yes I do
<ccheney> slangasek: apparently it is an extended latin font as opposed to normal latin font, though i am unsure what that means, still waiting to hear from rene to see if he has any additional insight
<slangasek> ccheney: that's not a term with a standard definition in fontland, but anyway I'm almost certain it's redundant with stuff we already have in main if it's Latin
<james_w> geser: they are when there are collisions between someone uploading a source package and someone pushing the branch. Currently they are more likely to be bugs though.
<slangasek> we have very good coverage of Latin glyphs :)
<ccheney> ok, i don't know much about fonts myself so not sure if its better or not
<ccheney> ArneGoetje: do you happen to know?
<ccheney> slangasek: so is the openoffice.org package seeded to the dvd or something, i didn't realize it was seeded anywhere
<ccheney> or just a general 'supported' seed i suppose?
<slangasek> ccheney: curiously, I can't actually find what's pulling in the openoffice.org metapackage
<slangasek> will dig
<slangasek> (I /assumed/ it was seeded, because it shows up as the reason on the component-mismatches report)
<ccheney> slangasek: talking to rene it apparently does special graphite things already but more is in the queue
<ccheney> http://qa.openoffice.org/issues/show_bug.cgi?id=89682
<ubottu> Error: Could not parse XML returned by OpenOffice.org: timed out (http://openoffice.org/issues/xml.cgi?id=89682)
<ccheney> "This font supports various advanced typographic capabilities using the Graphite, OpenType, or AAT font technologies." and goes on to explain some of them (in the URL referenced by the bug report)
<slangasek> ccheney: ok; I can't say whether those font features are implemented by other fonts we have in main
<ccheney> i somehow doubt they are as the font is written by the same people who wrote the extra feature library (graphite)
<ccheney> should i file a MIR bug for it to resolve the issue?
<slangasek> ccheney: well, let me see what the archive thinks if I move the openoffice.org binary to universe :)
<ccheney> heh ok
<slangasek> ccheney: if it pops back up on my radar, I'll let you know
<ccheney> ok
<slangasek> (but it's probably a bug in the component-mismatches report, not caring about the difference between source and binary packages here)
<soren> slangasek: Is there any more information I need to provide for bug 525741?
<ubottu> Launchpad bug 525741 in vm-builder "[FFe] VMBuilder 0.12.0" [Undecided,New] https://launchpad.net/bugs/525741
<slangasek> soren: followup question sent to the bug
<soren> slangasek: ta
<sgnb> does lpia still exist?
<slangasek> sgnb: no lpia architecture will be released with lucid
<bdrung_> jdstrand: hi
<bdrung_> jdstrand: yofrankie upstream devs do not have released an tarball yet. that's why the version contains ~svn. You can find a get-orig-source rule for grepping the source from their svn.
<jdstrand> bdrung_: I thought I saw a release note for it though...
<bdrung_> jdstrand: not that i am aware of.
<jdstrand> bdrung_: I found a reference to it in google's cache and thought there might have been a tarball
<bdrung_> jdstrand: link?
<jdstrand> http://74.125.93.132/search?q=cache:19uCvkl0NUMJ:www.yofrankie.org/+yofrankie+download&cd=1&hl=en&ct=clnk&gl=us&client=firefox-a
<bdrung_> jdstrand: there is yofrankie_1_1b_bge.zip, but that's not the source tarball
<jdstrand> yeah..
<bdrung_> jdstrand: i extended the makefile for making the generation of the tarball simpler. so he has to run "make dist" and upload the tarball somewhere.
<jdstrand> bdrung_: fyi, you have a git Vcs in control but an svn pull
<jdstrand> bdrung_: where is their svn?
<bdrung_> jdstrand: the svn belongs to upstream, the git is for package (but not yet created) - it will be moved to pkg-games
<bdrung_> s/for/for the/
<jdstrand> bdrung_: your debina/copyright said you downloaded it from www.yofrankie.org, but you are saying you got it from svn. that should really be somewhere-- this is very hard for me to verify
<jdstrand> bdrung_: can you give me an svn url?
<jdstrand> bdrung_: I see it in the rules file. nm
<bdrung_> jdstrand: the url is in the get-orig-source rule: https://svn.blender.org/svnroot/yofrankie
<cjwatson> chrisccoulson: do you have any idea what's going on in https://launchpad.net/~cjwatson/+archive/ppa/+build/1526187/+files/buildlog_ubuntu-lucid-i386.gnome-format_0.1.1-0ubuntu8~ppa1_FAILEDTOBUILD.txt.gz ?  I'm trying to rebuild gnome-format against parted 2.1, and, er, well, vala is not my first language
<slangasek> cjwatson: heh, I thought you were making a Tolkien joke
<cjwatson> I think I can probably manage Quenya very marginally better than GNOME's Vala, not that that's saying much
 * slangasek grins
<chrisccoulson> cjwatson - i'm just taking a look now, although i'm not that familiar with vala either ;)
#ubuntu-devel 2010-02-23
<cjwatson> the geom member of PedPartition doesn't seem to have changed type in libparted itself
<chrisccoulson> cjwatson - i can recreate with the current libparted
<chrisccoulson> it's more likley a change in vala
<chrisccoulson> but the language is so poorly documented ;)
<cjwatson> that's a relief of sorts
<james_w> bryceh: do you have a traceback for the wadllib bug you just reopened?
<bryceh> james_w, no
<bryceh> james_w, worked around the problem manually so can't easily repro it at the moment
<james_w> the problem is that the error could come from passing the wrong thing in, or launchpad changes as well
<james_w> bryceh: do you remember which values it was complaining about?
<james_w> or the LP method call you were making?
<bryceh> james_w, yep
<bryceh> it was complaining about "Confirmed"
<bryceh>   File "/home/bryce/src/Arsenal/arsenal/contrib/process-incomplete-bugs.py", line 88, in <module>
<bryceh>     bugtask.transitionToStatus(status = new_status)
<bryceh> ...
<bryceh> ValueError: Invalid value '"Confirmed"' for parameter 'status': valid values are: "New", "Incomplete", "Invalid", "Won't Fix", "Confirmed", "Triaged", "In Progress", "Fix Committed", "Fix Released", "Unknown"
<james_w> aha, thanks
<bryceh> james_w, the code is in the arsenal branch if you want to poke at it.  Or I can gather more data if you'd like, but it'll be tomorrow before I can get to it
<cjwatson> that looks like an over-quoting problem?
<james_w> bryceh: no, that's enough to go on, thanks
<james_w> cjwatson: yeah
<james_w> no Idea why it just reared its head again
<bryceh> cjwatson, bug #418802 near as I can tell
<ubottu> Launchpad bug 418802 in python-wadllib "requestsync crashed with ValueError in validate_param_values()" [Critical,Triaged] https://launchpad.net/bugs/418802
<james_w> bryceh: checking apt-cache policy python-launchpadlib python-lazr.restfulclient python-wadllib would be good
<bryceh> james_w, btw this is on a karmic machine
<james_w> aha!
<bryceh> I had been running the versions currently in https://edge.launchpad.net/~tsimpson/+archive/launchpadlib
<bryceh> that's a backport of the lucid bits
<bryceh> I also tried downgrading off that to the stock karmic versions 1.5.1, etc.
<bryceh> but got the same errors
<bryceh> james_w, what's weird is that this definitely went away for me for several months after upgrading to 1.5.1-0ubuntu1
<james_w> and this was code that stopped working today?
<kees> seb128: bug 525924 is an evince bug because the profile is in evince.  it's related to the profile though, yes.
<ubottu> Launchpad bug 525924 in apparmor "Document viewer shows error instead of launching Chrome" [Low,New] https://launchpad.net/bugs/525924
<bryceh> james_w, I've been having the problem since at least the start of the year
<james_w> ok
<seb128> kees, I though the browser list abstraction thing was in apparmor
<kees> oh, er
<bryceh> james_w, for a while I just procmailed the errors away.
<kees> seb128: you are totally right.  :)
<seb128> kees, ;-)
<bryceh> james_w, if you're pretty sure this is solved in lucid maybe don't worry about it too much, I intend to upgrade this box soon and can follow up if it's still an issue on lucid.
<james_w> bryceh: well, if you are using the backported bits then it may well be an issue
<bryceh> james_w, *nod*
<seb128> kees, in fact it seems that's fixed in lucid already
<bryceh> james_w, and since I had been the one that marked it fixed, that's why I reopened it
<kees> seb128: yeah, 488559
<kees> I've dup'd it now
<seb128> kees, thanks
<slangasek> ccheney: openoffice.org is recommended by openoffice.org-hyphenation-af et al. in main; do you know why that is?
<slangasek> ccheney: i.e., it's recommended as an alternative against openoffice.org-writer, but it seems it could just recommend the second of these
<slangasek> asac: component-mismatches nominates the whole EFL stack for demotion to universe.  Are these packages required to be in main, and if so, what's supposed to hold them in?
 * cjwatson digs into why he keeps getting "A volume with software packages has been detected" on the live CD
<freinhard> Hi!
<freinhard> does anybody know if atheros ar2427 will be supportet in the near future for lucid?
<freinhard> got a asus 1005PE which ships that wireless chip
<Kai_> I can't wait for Alpha 3. I'm going to see if it has a wiki page.
<Kai_> No :-\
<ccheney> Kai_: huh?
<ccheney> Kai_: alpha 3 is this thursday
<arand> Kai_: A3 will likely pretty much be what the dev is today, with a few bit maybe..
<Kai_> ccheney: I couldn't find a wiki page for Lucid Alpha 3, but I found the blueprints
<ccheney> Kai_: https://wiki.ubuntu.com/LucidReleaseSchedule
<Kai_> ccheney: I know it's on thursday, it's always on thursday
<Kai_> that doesn'
<Kai_> that doesn't say much about alpha 3
<ccheney> Kai_: once it is out the link to alpha 3 will be active
<ccheney> Kai_: like how alpha 2 link is currently active
<Kai_> okay
<Kai_> hi jono!
<jono> hey!
<james_w> bryceh: I can't reproduce on either karmic or lucid.
<james_w> bryceh: I think you can use task.status = "Confirmed"; task.lp_save() as well now
<bryceh> james_w, ok I'll give that a shot
<ArneGoetje> ccheney,slangasek: FYI, graphite is an alternative to the Truetype GPOS and GSUB tables, which has an extended rule set to describe in fonts how a particular glyph should be rendered in a specific situation. But since I don't know any open source editor for graphite code in fonts, I cannot see what's really inside those fonts, it's stored in a binary format. Graphite has been developed by SIL in order to improve rendering supportfor certain languages 
<twb> I'm having trouble installing daemons inside lucid chroots, due (I guess) to upstart start(8) ignoring policy-rc.d
<twb> http://pastebin.com/fbb11bff <-- example
<mneptok> twb: this is a development channel, not a support channel.
<twb> Well, they're pbuilder chroots.
<mneptok> that still does not make your issue related to the development of Ubuntu
<cjwatson> twb: yes, start(8) pays no attention to policy-rc.d.  The way to handle this with upstart is to divert /sbin/initctl
<cjwatson> for an example, see debootstrap, which does this
<twb> Thanks.  I guess my debootstrap is too old, or I'm accidentally using cdebootstrap.
<cjwatson> I didn't say debootstrap was responsible in this case
<twb> (Oh, of course once the base debootstrap is done, the debootstrap stub package will get removed.)
<cjwatson> debootstrap undoes the diversion when it's finished (nothing to do with a stub package); presumably pbuilder ought to put it back
<twb> Yup.
<cjwatson> so seems like a pbuilder bug
<twb> I bet it has been fixed in Ubuntu's pbuilder but not resynced upstream :-/
<cjwatson> you would lose that bet
<cjwatson> I checked the pbuilder source in Ubuntu before commenting
<twb> Darn, you beat me to it, then :-)
<geser> twb: why do you need a daemon like rsyslog inside your pbuilder?
<twb> geser: probably xvfb or something pulls it in
<cjwatson> daemons often wind up getting installed inside chroots by accident
<twb> cjwatson: have you also already found the existing BTS ticket? ;-)
<cjwatson> no, I get bored easily at 2am ;)
<twb> No worries :-)
<twb> BTW, is there a CLI tool like bts(1) that can talk to malone?
<cjwatson> there are various tools based on launchpadlib; at the lowest level, there's lp-shell in ubuntu-dev-tools
<twb> Ah, that rings a bell
<cjwatson> 'apt-cache rdepends python-launchpadlib' (on Ubuntu) will find others
<twb> IIRC I got ran out of time last time trying to reroll the debs for my Debian laptop.
<geser> twb: see also https://lists.launchpad.net/launchpad-dev/msg02590.html for a "textmode bug client"
<twb> geser: thanks.
<persia> slangasek: The EFL stack is supposed to be pulled for netbook-launcher-efl, which is in the netbook seed.
<chrisccoulson> cjwatson - i can make gnome-format build with the latest version of vala now, so i will upload that tomorrow
<chrisccoulson> i'm just wondering if anyone uses gnome-format though
<cjwatson> chrisccoulson: cool, thanks.  no idea on that
<chrisccoulson> it's unmaintained upstream now, and replaced by other tools
<cjwatson> I was just looking at all libparted1.8-dev's reverse build-deps
<chrisccoulson> it might be a good time to remove gnome-format from the archive
<crypt-0> cjwatson, i would like to help add https://mknowles.com.au/wordpress/2009/12/02/ubuntu-karmic-koala-9-10-%E2%80%93-full-disk-encryption-with-usb-key-authentication-v2/#more-81  to the ubuntu wiki https://help.ubuntu.com/community/FeistyLUKSTwoFormFactor is outdated
<cjwatson> crypt-0: it's a wiki, you don't need my help to add to it :)
<cjwatson> editing is encouraged
<crypt-0> well
<crypt-0> what credits would i have to put?
<crypt-0> "From https://mknowles.com.au/wordpress/2009/12/02/ubuntu-karmic-koala-9-10-%E2%80%93-full-disk-encryption-with-usb-key-authentication-v2/#more-81" ?
<cjwatson> no idea
<crypt-0> should mail the guy first
<crypt-0> unless i redo some of it
<cjwatson> that would be appropriate and polite
<crypt-0> then mail him the changes
<twb> cjwatson: FYI, #571054 and #571056 (in debbugs), re. diverting initctl
<cjwatson> cool
<twb> Ah, nice, simply referencing a debbugs URL in a malone comment causes it to auto-link.
<twb> (I filed https://bugs.launchpad.net/ubuntu/+bug/523688/+index late the other night, when tired and very grumpy.)
<ubottu> Launchpad bug 523688 in ubuntu "postinst calls start(8) instead of invoke-rc.d(8), ignores policy-rc.d(8)." [Undecided,New]
<persia> twb: You can also do tricks like "Debian bug #571054 " and the bot here will post links.
<ubottu> Debian bug 571054 in pbuilder "Divert /sbin/initctl to fix start(8) in lucid postinsts." [Normal,Open] http://bugs.debian.org/571054
<twb> Nod.
<twb> I haven't played with ubottu enough to memorize his pattern matching heuristics
<slangasek> persia: ah; does the netbook seed pod not have the equivalent of ubuntu supported's "Extra-Include: *-dbg *-debug *-dev *-doc *-docs *-gcj"?
 * persia has no idea and branches the seed to look at it for the first time not over someone else's shoulder
<StevenK> slangasek: No, netbook's supported seed is blank
<slangasek> StevenK, persia: may I suggest adding the above line, for consistent handling of such packages?
 * persia defers to someone with commit access to the branch and familiarity, like StevenK :)
 * slangasek defers to someone who knows where the branch is
<StevenK> Same place as platform, ubuntu, etc, just netbook.lucid ?
<persia> lp:~ubuntu-core-dev/ubuntu-seeds/netbook.lucid
<slangasek> ok :)
<StevenK> Do we need to do anything more than have Extra-Include in supported?
<slangasek> StevenK: and make sure it's included sensibly in STRUCTURE
<slangasek> but no uploads needed, etc
<StevenK> Yeah, we had a blank supported to help with livecd building, so it's already in STRUCTURE and everything, it was just empty.
<slangasek> Riddell: I've done the kubuntu-meta upload to drop bluetooth, but kdebluetooth still depends on it rather than on the bluez-* bits it needs; I guess you may want an upload of kdebluetooth before a3 to get bluez-gstreamer off the CD?
 * StevenK blinks. Why is it that if someone else uploads d-i, it builds on ppc, and if I upload it, it doesn't.
<mdeslaur> lucas: do you have any idea why ruby1.9 won't build for i386 with the latest lucid gcc?
<mdeslaur> lucas: bug #526144
<ubottu> Launchpad bug 526144 in ruby1.9 "ruby1.9 fails to compile with gcc4.4 4.4.3-2ubuntu2" [Undecided,New] https://launchpad.net/bugs/526144
<micahg> ArneGoetje: ping
<ArneGoetje> micahg: pong
<micahg> ArneGoetje: about the language-support-translations bug, we're probably going to have a lot of people hit this on hardy->lucid upgrades...any ideas?
<micahg> is a release notes mention enough?
<ArneGoetje> micahg: I'm not sure... ideally the update-manager would deal with that...
<micahg> ArneGoetje: that's an idea..I can ping mvo in the morning and ask
<ArneGoetje> micahg: ok, thanks
<micahg> ArneGoetje: thank you :)
<nixternal> any archive tweakers around?
<StevenK> Archive tweakers?
<nixternal> someone who has some access to look at something for me
<nixternal> someone who can tweak their way in and tell me what I need to know :)
<nixternal> I want to know, what is your username and password so I can break into the archives? :p
<StevenK> And what do you need to know?
<StevenK> Right, so no serious question.
<nixternal> no, for real, I am wondering why 'create-resources' isn't showing up in Packages.bz2...I am getting the good ol' "it's a virtual package moron" warning when building right now
 * StevenK dumps IRC for something more interesting
<StevenK> nixternal: In lucid?
<nixternal> yes
<nixternal> create-resources |  0.1.3-2.1 | lucid/universe | source
<nixternal> missing the good ol' ', all' there
<Kai_> Is the Me Menu a panel applet?
 * Kai_ searches synaptic
<StevenK> nixternal: Are you only building from main, since it's in universe?
<nixternal> no, I am building koffice which is now in universe
<StevenK> Can I see a build log?
<nixternal> there are other packages in universe that koffice deps on that is fine, just that one package
<nixternal> yeah, let me paste bin it for you
<nixternal> http://paste.ubuntu.com/382057
 * nixternal keeps forgetting about pastebinit
<slangasek> does anyone here know why empathy's lib packages (and -dev packages) went away?
<StevenK> slangasek: I seem to recall empathy being in NBS, but I didn't bin them
<slangasek> StevenK: yah, am working NBS right now
<StevenK> nixternal: I think the binary package has been eaten by a Soyuz bug, since it was demoted from main to universe 10 hours ago
<nixternal> nom nom nom :)
<nixternal> I take it you can fix that, or is there something I need to do?
<StevenK> I can't, no, I need to talk to someone.
<nixternal> you can talk to sabdfl, he is a nice guy, he doesn't bite, and his name is written all over soyuz :D
<nixternal> alrighty, I just wanted to make sure that I wasn't any more crazy than I already am
<wgrant> StevenK: It wasn't eaten by a Soyuz bug.
<wgrant> StevenK: It was demoted, then slangasek deleted it. I see no bug.
<wgrant> (there is still the bug where an arch-all package that is overridden then has the overrides reverted within one publishing cycle gets eaten, but it doesn't seem to be the case here)
<wgrant> Oh, you were talking about create-resources.
<wgrant> That one *was* eaten by the bug I mentioned.
<wgrant> Since the issue is very difficult to fix, it is tempting to fix change-override to bail if it's going to get a binary into that situation.
<StevenK> wgrant: Yeah, I was talking about create-resources.
<wgrant> StevenK: It was just off the top of my screen :(
<nixternal> wgrant: get a bigger screen :)
<nixternal> or shrink your fonts
<wgrant> Pfft.
<pitti> Good morning
<dholbach> good morning
<nixternal> good morning
<dholbach> hey nixternal
<nixternal> howdy
<stefanlsd> wgrant: heys, do u know whats happening with motu-swat team?
<wgrant> stefanlsd: It's purpose in the new world has not been decided, AIUI.
<persia> It's likely to be decided sooner if people who have active involvement join the discussion :)
 * persia can talk a lot, but isn't actually MOTU SWAT, which makes it hard to reach a known good model
<stefanlsd> wgrant, persia: just looking at the current workflow (i used to be a member, expired, applied a while ago (other applicants also pending)). I see that motu-swat is a member of ubuntu-security-sponsors. (i think you need that indirect membership to join that team)
<persia> stefanlsd: That matches what I know.  It needs someone to vet and accept new members to MOTU SWAT, a clear definition for MOTU SWAT in the face of ArchiveReorganisation (which may become more clear after the TB meeting today), and (I think) some MOTU SWAT representation at the weekly security team meeting.
<wgrant> Once it becomes clear what the responsibilities of the team are, we can work out membership and ownership.
<wgrant> But its membership in u-s-s suggests that it may confer some kind of privileges, if only socially rather than technically.
<stefanlsd> persia, wgrant: kk. lets wait till TB meeting and i'll try pick it up with the security team as to the plans and how we can get more motu involved with security. i wrote http://people.canonical.com/~ubuntu-security/d2u/ which is an awesome tool to help people with security patches already in debian. so there lots of fairly easy work :)
<persia> wgrant: At least based on the Security Meeting last night, I had the impression that u-s-s was intended to be the focal group for people who were reviewing and uploading security stuff (although they may need to request pocket-copies from a smaller team).
<wgrant> persia: Right, which hints that motu-swat's original membership of just about anybody interested in security work probably needs to change.
<persia> Quite possibly.
<stefanlsd> persia: my understanding is that we (non members of ubuntu-security) cant upload the patches, that people in motu-swat would be able to test and ack the patches that ubuntu-security would upload. also there was discussions about the security team being more flexible wrt universe / multiverse uploads (lower barrier to entry)
* slangasek changed the topic of #ubuntu-devel to: Archive: Feature Freeze, main frozen for alpha-3 | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<persia> stefanlsd: I'm not sure, but I had the impression yesterday that the security team would welcome non-embargoed stuff just being uploaded, with requests to pocket-opcy to -security.  Note that special models likely apply when there has already been a non-security SRU to the package in question.
<wgrant> The process for non-embargoed uploads could be improved with some Soyuz work.
* persia changed the topic of #ubuntu-devel to: Archive: Feature Freeze, main frozen for alpha-3 | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<wgrant> At the moment, security uploads need to build in a non-virtual PPA before the copy, because Soyuz can't do builds directly in -security.
<wgrant> This is pointless for unembargoed fixes, where they could just be uploaded to a normal PPA then source-copied.
<wgrant> That means that ubuntu-security would just have to hit the Copy button, which makes it much easier for them.
<stefanlsd> wgrant: cool. lets try and take it up at monday sec meeting
<persia> wgrant: That's surely just a workflow thing, and could be enabled with a u-s-s PPA, no?
<wgrant> persia: Sort of. Non-virtual PPAs need to be approved by IS, and they really don't like to do it.
<wgrant> Giving a hoard of community people access to one would probably not happen.
<persia> Right, but u-s-s could be a virtual PPA, and u-s could pocket-copy into the non-virtual one.
<persia> (which also makes it easier for them)
<wgrant> True, then there's just that one extra layer.
<persia> Right, which is still annoying, but less so.
<wgrant> Very true.
<slangasek> StevenK: dunno who all from your quarter tracks such things, but I've armel out-of-date/uninstallable reporting to the main report now: http://people.canonical.com/~ubuntu-archive/testing/lucid_outdate.html
<sebner> james_w: You were in charge yesterday for the archive, would you mind telling me why you rejected docky and zyn?
<slangasek> sebner: https://lists.ubuntu.com/archives/ubuntu-archive/2010-February/033740.html, https://lists.ubuntu.com/archives/ubuntu-archive/2010-February/033739.html
<tkamppeter> pitti, hi
<slangasek> jdstrand: interesting; source rejects for not using dpkg v3?
<persia> slangasek: Some of those appear to be FTBFS (which are being tracked with some effort), and the rest appear to be timing skew (in that the package appears in the archive).  I'll poke the FTBFS folk to try to hit those packages soonest.
<slangasek> persia: ok - wasn't asking anyone to work on them Right Now, just making sure I pass the word so people aren't wondering where it's gone :)
<phildini> hi. if I wanted to know the status of lucid support for intel core i* processors and graphics (and possibly contribute) where could I look?
<persia> slangasek: From a quick investigation is appears that most of it is waiting for the gtk+2,0 build to finish and could be resolved with give-backs.
<persia> Err, and there's a good chunk of DEPWAITS on all of KDE too :)
<sebner> slangasek: oh, thx!
<Riddell> persia: waiting on kdebindings I guess?
<persia> Riddell: Did that get wedged again?
<persia> Ugh.  segfault in code generation again.
 * persia goes off to find a volunteer
<Riddell> yeah, blows up building smoke
<Riddell> which I doubt anyone on armel uses so we can alter the packaging not to build it as a work around
<persia> What is "smoke"?
<slangasek> "Scripting Meta Object Kompiler Engine"
<persia> And why wouldn't it be interestng to armel folk?
 * persia 's primary laptop when traveling is armel, which perhaps gives a different perspective
<Riddell> persia: smoke is the tool and library to create bindings for ruby and c# for qt and KDE, there aren't many apps which use those bindings
<Riddell> persia: obviously it would be nicer to fix the compile, we just shouldn't spend too long on it
<Riddell> persia: let me know if you find a volunteer
<persia> Riddell: Fair.  My most likely volunteer is in the US, so I'll probably know within the next 6 hours if something useful can be done.
<Riddell> slangasek: apachelogger was pointing out that /usr/share/icons/oxygen/icon-theme.cache is on our live CD but is only used by gnome which isn't on our live CD, can we delete that before the livefs gets squashfs'ed?
<pitti> hey tkamppeter
<tkamppeter> pitti, for bug 141641 I have made a new debdiff to also address Jeff's comment, now the lsb package should be ready for upload.
<ubottu> Launchpad bug 141641 in lsb "installing lsb requires postfix" [Medium,Fix committed] https://launchpad.net/bugs/141641
<pitti> tkamppeter: with "exit 255" now?
<tkamppeter> Yes, pitti, thank you for this hint.
<pitti> tkamppeter: okay, will upload ASAP
<tkamppeter> pitti, having fixed this was important, as probably in a week or so the first manufacturer-supplied driver will be posted on OpenPrinting. So there will be soon also a key to be added to the key list of Lucid.
<tkamppeter> pitti, Now I have another problem, with system-config-printer.
<pitti> tkamppeter: I still have your mails; will answer ASAP
<tkamppeter> The web application of the OpenPrinting web site was replaced by a completely new one (moved from CGI + XML database to PHP + MySQL databse => LAMP). This changed nearly all URLs, so I have done some URL redirecting in .htaccess, which means that when an old URL is requested (which s-c-p naturally does in all released distros) the server sends back error status 301 and the new URL, and the client is then supposed to request the new URL.
<tkamppeter>  s-c-p uses some kind of primitive HTTP lib and tracebacks. I have a 10-line patch to fix s-c-p. WDYT should we better apply the patch to s-c-p upstream and SRU all distros and versions or should I try to make query.cgi on the server natively behaving as query.php, to avoid redirects?
<tkamppeter> pitti ^^^
<pitti> tkamppeter: ideally it could be fixed on the server side; updating all boxes out there is expenseive and takes a while
<pitti> I wouldn't mind an SRU for this, but getting this through will take a while, and it won't help live systems, etc.
<tkamppeter> pitti, I have fixed the server now, as OpenPrinting does not use the CGI concept any more I have told Apache that .cgi files are PHP and symlinked query.cgi to query.php.
<pitti> heh, nice
<c_korn> did someone kill this build ? http://launchpadlibrarian.net/39601964/buildlog_ubuntu-lucid-amd64.scilab_5.2.1-3_FAILEDTOBUILD.txt.gz
<jpds> Build killed with signal 15 after 150 minutes of inactivity
<c_korn> inactivity means no output to the shell ?
<Laney> yes
<cjwatson> yes (well, not the shell, just no output on stdout or stderr)
<c_korn> well, there is still activity. it just takes some time: https://launchpad.net/~getdeb-package-managers/+archive/ppa/+build/1517734
<c_korn> Build needed 06:32:51, 1024900k disc space
<c_korn> https://buildd.debian.org/fetch.cgi?&pkg=scilab&ver=5.2.0-7&arch=amd64&stamp=1266339679&file=log
<c_korn> can this inactivity check be disabled for scilab ? as you can see it compiles fine in a PPA
<c_korn> the i386 build also succeeded: https://launchpad.net/ubuntu/+source/scilab/5.2.1-3/+build/1525157
<cjwatson> c_korn: just make it output something every so often
<c_korn> well, I don' think you want something like: while true ; do echo hello ; sleep 60 ; done
<c_korn> i is the parsing of the master document which takes so long
<c_korn> s/i/it/
<c_korn> and it is done by an underlying library
<cjwatson> in fact there are some long-building packages that do something quite similar to that, as a watchdog process in the background
<cjwatson> better that than having to mess around making exceptions at the buildd level
<Laney> check out agda â I recently added a watcher to that as it was timing out on armel
<tkamppeter> pitti, OpenPrinting server is fixed and Karmic downloads both packages and single PPDs without any patches, so you can do all tests described in the mails I sent to you and the problems are not caused by the server.
<pitti> tkamppeter: thanks
<Ixan> i'm having some problems with oem-config. when oem-config-firstboot runs, it exits after a couple of seconds with "error: the oem installer failed"
<cjwatson> /var/log/oem-config.log would come in handy
<c_korn> Laney: I don't see a watchdog in the diff.gz. did you implement it in the agda tarball ?
<Laney> look harder
<Ixan> cjwatson: http://pastebin.ubuntu.com/382190/
<Ixan> this is 10.04 a2, but i got the same symptom on 9.10. warning,i've used preseed for unattended install
<cjwatson> then I need to see your preseed file too
 * c_korn was looking in the wrong diff.gz *cough*
<tkamppeter> pitti, thanks for the upload of "lsb".
<Ixan> http://pastebin.ubuntu.com/382192/ preseed-file
<cjwatson> Ixan: actually if you could file a bug against ubiquity with all of this ...
<Ixan> roger
<cjwatson> Ixan: incidentally, you know that 'd-i passwd/user-uid string 1010' will have some very odd effects, don't you?
<Ixan> no, i'll test with 1000
<cjwatson> no, just leave it out!
<cjwatson> you don't need to set it
<Ixan> yeah, found it odd it was in the examples i saw
<Ixan> i'll retest without it for 10.04 and 9.10
<Ixan> before bug report
<Ixan> took me a whiel to figure out it was oem-config which crashed. it started in terminal 8, but after boot i just got text login up in term 1. no note nor nothing that something had crashed
<asac> slangasek: odd. let me check with desktop team
<Ixan> cjwatson: got the same problem after removind uid 1010. filed a bug report. https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/526405
<ubottu> Launchpad bug 526405 in ubiquity "oem-config-firstboot crashing upon run" [Undecided,New]
<cjwatson> Ixan: yeah, didn't say it had anything to do with this specific problem :)
<cjwatson> I suspect debconf_ui is just broken
<cjwatson> (again)
<Ixan> i'll check 9.10 and see if it's the same there.
<cjwatson> Ixan: debconf_ui was definitely known-busted in 9.10, wouldn't bother if I were you
<cjwatson> I'd thought I'd got it fixed though
<cjwatson> anyway, on my queue
<Ixan> good shit
<Ixan> i'll toss in a feature request for luks-ed /home with oem-config at the same time =)
<cjwatson> not if you want me to get to your first request ;)
<Ixan> hehe, sounds sensible ;)
 * ogra arghs
<ogra> so logging out and switching consoles, then switching back to gdm suspends my machine
<jdstrand> slangasek: re dpkg v3> no? which made you say that?
<ogra> 100% reproducable
<jdstrand> slangasek: if there were rejectable items then I might also suggest improvements such as dep-5 and dep-3...
<cjwatson> jdstrand: you can only use .orig.tar.bz2 with source format v3, and even then we don't yet recommend it because there are believed to still be some Soyuz bugs related to that
<cjwatson> jdstrand: the historical practice is to recompress with gzip, even though this isn't optimal and requires coordination with Debian to avoid differing .orig.tar.gz files
<persia> There are some recipes on the wiki for constructing get-orig-source rules that repack in a repeatable-checksum manner.
<jdstrand> cjwatson: ah, I see
<cjwatson> repeatable> gzip -n, basically
<cjwatson> but of course that only works if the Debian maintainer uses the same recipe
<persia> -nf actually, to deal with potential architecture or filesystem skew.
<jdstrand> I'll follow up on that one-- I tried a gzip on my own, but it didn't work. I didn't try -nf
<persia> Right, but it's been historically easier to file a bug attaching a get-orig-source snippet than a binary blob :)
<persia> jdstrand: We usually recommend -9nf just for space savings, but the 9 doesn't actually matter.
<apachelogger> cjwatson: hey, could you please approve jonathan thomas' mail to devel-permissions (should have been sent a week ago or so)
<jdstrand> slangasek: nm
<cjwatson> apachelogger: done
<apachelogger> cjwatson: thanks :)
<jdstrand> cjwatson, persia: thanks for the info
<persia> jdstrand: That's why we have an IRC channel :)
<jdstrand> :)
<kvalo> hello. I'm having problems upgrading an old thinkpad t30 to lucid:
<kvalo> (**) Option "xkb_layout" "fi"
<kvalo> Failed to alloc memory
<kvalo> http://paste.ubuntu.com/382225/
<kvalo> and X segfaults
<mdeslaur> slangasek: yesterday I uploaded ruby1.9, and it fails to build on i386 with the most recent gcc that was uploaded a week ago. So, currently the i386 archive has an older ruby1.9. I'm not quite sure how to handle this, any ideas?
<kvalo> if I use failsafe mode from gdb, X works. problem related to 3d or what?
<kvalo> s/gdb/gdm/
<soren> Sometimes when I mkfs a loopback device and immediately afterwards run e.g. "blkid -sUUID -ovalue /dev/mapper/loop1p1" on it, it fails (exit code 2).
<soren> blkid docs says that "If the specified token was not found [...] an exit code of 2 is returned".
<soren> Will a "udevadm settle" in between the two solve it?
<soren> Yes, I could just try it, but it only happens every one in 15-20 times, so it's hard to determine if it's actually fixed or I'm just lucky for a while.
<persia> soren: It ought, assuming that there's not a timing gap between the event being "handled" and the device node being available.
 * persia believes there not to be such a gap
<soren> I /think/ udev is triggered by mkfs calling close() on the device node.
<soren> The device node is already there (since I could call mkfs on it).
<persia> In that case, `udevadm settle` won't do anything.
<soren> So, assuming the inotify event reaches udev before my "udevadm settle" call does, I should be safe. That makes sense.
<soren> persia: Well, it'll wait until udev is done handling it, surely?
<soren> Or am I misunderstanding udevadm settle?
<persia> I believe `udevadm settle` to hang until all udev events have been processed.  I don't believe that mkfs generates a udev event.
<soren> persia: mkfs as such doesn't. However, opening a device node and closing it again, does. I /think/.
<persia> Ah, I thought it didn't.  Maybe someone else actually knows :)
<soren> Yeah. Where's
<soren> Keybuk when you need him? :)
 * soren runs vmbuilder and stares at "udevadm monitor"
<soren> Err.. Something certainly happened :)
 * soren adds some sleeps here and there to make sure.
<soren> persia: Yup, there are certainly udev events to be handled after mkfs. Yay.
<persia> Oh, cool.  In that case: "Yes, using udevadm settle will do precisely what you want" :)
<Chipzz> kvalo: I'm sorry, I think you're mistaking this channel for a support channel :) pls read the topic
<kvalo> Chipzz: so lucid regressions should be discussed in #ubuntu?
<kvalo> btw, seems to be kms problem
<cjwatson> kvalo: #ubuntu+1 specialises in support-type things for stuff that hasn't been released yet
<kvalo> cjwatson: ok, thanks. I'll bring this up there
<Chipzz> kvalo: no, #ubuntu+1
<Chipzz> cjwatson: that did seem to get dropped from the topic though
<cjwatson> Chipzz: *shrug* space constraints, and it doesn't matter all that much if the odd person comes in here
<kvalo> Chipzz: thanks, I'll ask for help there. sorry for bothering you
<RainCT> seb128: Hey. Can you still give Feature Freeze exceptions this cycle? If so, I'd like to sync gnome-activity-journal 0.3.3 (once I get it uploaded into Debian).
<seb128> RainCT, I don't know but that one should be no issue even if I'm not the one granting it
<RainCT> seb128: Yeah, just wondering if I need to file a bug (and if so, whom to subscribe? motu-release?)
<seb128> dholbach, ^
<dholbach> RainCT: slangasek is going to send out a process proposal later today - for now I'd just say follow the old process
<persia> RainCT: file a bug and subscribe ubuntu-release.
<dholbach> ScottK, iulian, nhandler: ^
<RainCT> seb128, dholbach, persia: OK, thanks.
<cjwatson> argh
<cjwatson> what's the point of moving to source format 3.0 AND KEEPING DBS
<persia> tradition?
<Laney> which team grants access to upload source NEW packages to Ubuntu?
<jpds> Laney: ~ubuntu-dev?
<Laney> jpds: I don't know, as PPUs are members there AFAIK
<cjwatson> er, *cough*, this is a bit of a process hole atm
<cjwatson> technically, right now, the answer is motu
<cjwatson> I think
<Laney> yes, I was just thinking about the new set
<Laney> whether CLI/Mono developers would be able to upload NEW packages for the set
<cjwatson> Laney: so, at worst: upload to PPA (so that the sourcepackagename is valid in Launchpad), have TB add the name to the set, upload to archive
<cjwatson> Laney: I don't recall just now whether the first step is needed
<Laney> oh, that works?
<cjwatson> we may be able to add arbitrary strings as package names, but I have a suspicion that the LP DB will want them to be SPNs
<cjwatson> but uploading to a PPA is enough to make that work
<Laney> It's not really a problem for us as we have MOTU
<Laney> so LP will check for PPU upload rights even for source NEW, that's good.
<cjwatson> Laney: I *think*.
<Laney> well, we can see if this ever comes up
<cjwatson> actually I think it may have come up with linux-backports-modules-2.6.32, now that you mention it
<cjwatson> not sure
<micahg> mvo: ping
<jdstrand> ScottK: I'm working on clamav -backports to -security for hardy. All I should need it https://wiki.ubuntu.com/MOTU/Clamav correct?
<jdstrand> ScottK: hi btw :)
<mvo> micahg: pong
<micahg> mvo: we had an issue with a deprecated package language-support-translations trying to pull in apps on a hardy -> lucid upgrade...is there any way for update manager to remove it on upgrade?
<micahg> mvo: bug 525866
<ubottu> Launchpad bug 525866 in thunderbird-locales "thunderbird-locale-en-gb should not depends on thunderbird" [Undecided,New] https://launchpad.net/bugs/525866
<kees> micahg: I'm seeing this bug: http://superuser.com/questions/76625/unable-to-click-on-tabs-in-firefox-unless-i-press-command-q with all my extensions disabled.  do you have any idea what I can try next?
<mvo> micahg: yes, let me read the bug
<micahg> kees: --safe-mode or -ProfileManager
<micahg> mvo: thanks
<kees> micahg: both.
<kees> micahg: it's crazy -- I have hit ctrl-Q several times before ff behaves correctly again
<kees> micahg: it's like it's stuck prompting somewhere, but doesn't actually prompt
<micahg> kees: can you get a backtrace when it sitcks
<micahg> *sticks
<kees> micahg: I can, but it still mostly works (i.e. I can click links on the current tab, sometimes I can ctrl-tab to new tabs, but clicking tabs doesn't work, can't pop new dialogs, etc)
<kees> micahg: trivial to reproduce for me; you just want a gdb thread backtrace?
<kees> micahg: http://paste.ubuntu.com/382349/
<micahg> maybe an strace will be better...you don't have to load all the dbg libs
 * micahg guesses it's an extension
<kees> all my extensions are disabled.
<kees> even the media plugins are disabled
<slacker_nl> hello, will lucid convert grub-legacy to grub2? like debian testing does
<cjwatson> not planning to at the moment; it's possible we may revisit this but currently not planning to
<cjwatson> got enough to do :)
<slacker_nl> mkay, too bad, it made my day when I upgraded to testing from stable :)
<kees> micahg: any clue what to do next?  strace shows nothing, and gdb backtraces are identical before/after the ctrl-Qing
<cjwatson> yeah, problem is dealing with the people whose days it ruins ;-)
<slacker_nl> the FF bug sounds familiar, I cannot close tabs, it then closes my FF
<slacker_nl> cjwatson: hehe :)
<micahg> kees: mozilla 508738
<ubottu> Mozilla bug 508738 in Tabbed Browser "Cannot close tabs with Command+W and even select Close Tab with right click on tab" [Minor,Unconfirmed] http://bugzilla.mozilla.org/show_bug.cgi?id=508738
<directhex> slacker_nl, is nyu including my grub2 theme yet? i know he mentioned it
<kees> micahg: I'm not sure if that's my bug, but I'll comment
<slacker_nl> directhex: i do not follow
<directhex> slacker_nl, does your debian grub2 have a graphical menu screen?
<slacker_nl> yes
<cjwatson> I don't see that in the package yet
<cjwatson> I think it's just a graphical background
<micahg> kees: maybe file a new bug upstream
<Riddell> ev: seele is wondering why the "update the installer" button is needed?
<ev> Riddell: can you expand on that?  It gives us a way to get a newer version of the installer to users on released CDs, in case things go horribly wrong at release.
<ev> https://blueprints.edge.launchpad.net/ubuntu/+spec/ubiquity-auto-upgrade
<Riddell> ev: why is it a button rather than something it just does?
<ogra> doko, do you happen to have any idea about bug 520465 ?
<ubottu> Launchpad bug 520465 in ubuntu "armel/versatile: glibc detected double-free or corruption (!prev)" [Undecided,New] https://launchpad.net/bugs/520465
<ev> Riddell: well, for one it requires internet access, which not everyone has at install time.  But cjwatson would be able to give you an exact answer (he did UI and code for this).
<cjwatson> also don't want to block starting the installer on a network probe
<cjwatson> don't want to phone home by default noninteractively
<cjwatson> don't want to unconditionally break older working installers in the event that we release a broken installer (particularly the case during development cycles, but not exclusively)
<doko> ogra: no, didn't look yet
<cjwatson> don't want to impose the extra memory cost of installing a new installer package (it has to be entirely in RAM due to how the live CD works), which might render some systems unable to install Ubuntu
<cjwatson> that's just what I can think of right now
<cjwatson> bryceh,pitti: problem: ubuntu-desktop now transitively depends on grub-pc - ubuntu-desktop -> xserver-xorg-video-all -> xserver-xorg-video-nouveau -> linux-backports-modules-nouveau-lucid-generic -> [...] -> linux-image-* -> grub-pc (recommends)
<bryceh> cjwatson, ew
<tseliot> slangasek: is it ok if I upload the fix for bug #467490 after alpha 3?
<ubottu> Launchpad bug 467490 in nvidia-graphics-drivers-180 "nvidia drivers don't work due to -Q in obsolete /etc/modprobe.d/lrm-video" [High,Triaged] https://launchpad.net/bugs/467490
<cjwatson> bryceh,pitti: this is bad because it subverts the installer's logic for boot loader installation and causes bug 526422.  we've always tried hard to keep linux out of the desktop task for this reason.  what can we do about this?
<ubottu> Launchpad bug 526422 in grub-installer "Grub installer asks too many questions to the user" [Undecided,Confirmed] https://launchpad.net/bugs/526422
<pitti> cjwatson: (lagging, desktop meeeting going on)
<bryceh> cjwatson > #ubuntu-x 2>&1
<pitti> cjwatson, bryceh: would it be prudent to drop the video-nouveau -> lbm dependency?
<pitti> the other video drivers don't depend on the kernel either
<pitti> of course that'd require them to cleanly fail to load if the module isn't present
<bryceh> pitti, but then would l-b-m-nouveau not be included in the cd?
<pitti> bryceh: we'd need to seed it explicitly somewhere, I guess
<cjwatson> but then that would have the same problem
<pitti> or make it a recommends of linux-image in linux-meta
<bryceh> as long as that's done it'd be fine.  afaik that's the only reason we put the dep on it in there
<cjwatson> I don't see a clean way to do this, short of making the kernel image package *depend* on lbm-nouveau
<cjwatson> a recommendation would be ineffective in this case
<cjwatson> the installer ignores recommends when installing the kernel package, and has to do so because otherwise it would pick up boot loaders when doing so
<pitti> cjwatson: so the actual linux-image-* -> grub-pc (recommends) should stay and is intended?
<cjwatson> but I would expect that having the kernel image package depend on lbm-nouveau would cause a chicken-and-egg problem on ABI transitions
<cjwatson> pitti: yes
<cjwatson> it's recommends: grub-pc | <other boot loaders>
<cjwatson> and it got lifted to that due to another bug, iirc
<cjwatson> apw: ^- is there any chance that we could just have lbm-nouveau integrated into the main kernel package?
<cjwatson> I wonder if there's any seed trickery I could do
<pitti> short of that, the only way I see is to make it a dpeendency of -generic, but not of -server
<c_korn> Laney: I think I did something wrong with the watcher :/ why is there another tick after the terminating message ? https://launchpad.net/builders/platinum/+index
<pitti> which should amount to the same thing than integrating nouveau into -generic itself?
<cjwatson> but lbm-nouveau can't be built until after the main package is built
<pitti> but might be easier to maintain by the kernel team
<apw> cjwatson, that is likely possible though pretty hard, but we may well be getting rid of it in favour of a bigger backport
<apw> cjwatson, wahts the issue?  isn't lbm-nouveau a dep of the x-server?
<Laney> c_korn: you have two watchers running
<cjwatson> yes, the issue is that that dependency pulls in grub-pc indirectly at a point when the installer is not prepared to install a boot loader
<cjwatson> (see scrollback)
<apw> cjwatson, so lbm is recommending grub ?
<cjwatson> no, linux-image recommends grub-pc
<cjwatson> and should continue to do so, that's desirable for other reasons
<apw> got ya
<cjwatson> indeed I think there's a sabdfl bug on the subject
<apw> hrm, tricky
<cjwatson> I'm trying some seed madness
<c_korn> Laney: any idea how this can happen ? I copied your watcher.sh and pasted this into the debian/rules http://pastebin.com/yBpggnva
<cjwatson> the kernel's already installed, so in theory I just need to get it out of the task
<cjwatson> actually there's another problem
<Laney> c_korn: do "debcheckout agda" and use the version from there
<cjwatson> x-x-v-nouveau depends specifically on linux-backports-modules-nouveau-lucid-generic
<cjwatson> bryceh: ^- that will break if the user installed the PAE kernel
<apw> cjwatson, i believe that just got fixed ... like today
<bryceh> cjwatson, yeah fixed that yesterday
<cjwatson> ah
<apw>   * debian/control
<apw>     + Add -pae as fulfilling dependency
<apw>       (LP: #524792)
<cjwatson> ok, although I don't think the installer will be smart enough right now to pick the right now
<cjwatson> *right one
<cjwatson> we might have to arrange for the lbm package to be installed explicitly when installing the kernel, or something
<c_korn> Laney: ah, it uses a lock file I see. does "exit 1" mean that the compilation will fail if two watchers are spawned ?
<Laney> no, the second watcher will exit
<apw> cjwatson, damn ... i am not sure we'll be doing that for much longer ...
<cjwatson> doing which?
<c_korn> Laney: fine, I thank you
<apw> cjwatson, necessarily doing the backport that way
<cjwatson> right
<cjwatson> I've worked around most of this at the installer level for now
<cjwatson> but in general, direct kernel dependencies in the desktop seed are problematic, and we should try to avoid them
<apw> ok
<c_korn> Laney: but I don't quite understand why the second watcher does not terminate.
<Laney> you should examine how it is invoked
<c_korn> Laney: I would like to if I had the build log. is there a timeout for PPAs (even if output is still occuring) ? (although I do not see the watcher tick again in the build log. so it should be terminated already)
<Laney> it will be terminated soon enough
<c_korn> ok
<cjohnston> mbudde: ping
<randomaction> sgnb: there are 3 unfinished builds from round 2 (confluence, jocaml, ocamldsort), am I right in thinking that round 3 can start without waiting for them (i.e. no rdepends of these 3 packages are involved in round 3)?
<porthose> Would a kind core-dev please have a look at bug #526587 thx :)
<ubottu> Launchpad bug 526587 in dbconfig-common "Sync dbconfig-common 1.8.44 (main) from Debian testing (main)" [Wishlist,New] https://launchpad.net/bugs/526587
<slangasek> Riddell: hmm, if the cache is removed from the livefs, will it be regenerated at install time?  If a user installs packages in the live environment that want it, will it be regenerated then?
<slangasek> Riddell: (I guess this is a size issue?)
<cjwatson> slangasek: I asked the same question on #ubuntu-release
<Riddell> slangasek: still trying to work out what actually creates the cache in the first place
<cjwatson> and there was a conversation there
<slangasek> mdeslaur: have you checked with doko?  if toolchain changes uploaded at FF are causing build regressions, he may know why (and if not, he should be in the loop)
<slangasek> mdeslaur: the particular error certainly looks like a toolchain regression to me...
<slangasek> cjwatson: ok, will process that window next :)
<doko> slangasek: which one is this?
<slangasek> doko: ruby1.9/i386 FTBFS
<doko> seen, but the report didn't have infos pointing to the toolchain
<cjwatson> I'm reaching end-of-day; if anyone could help to track down bug 526391 in the meantime, I would be very grateful - d-i is very ugly right now
<ubottu> Launchpad bug 526391 in cdebconf "Debian Installer screen text is corrupted" [Medium,Confirmed] https://launchpad.net/bugs/526391
<slangasek> seb128: that's the last gtk+2.0 upload for a3, right?  Because we kinda need gtk installable on armel if we're going to have it included in the milestone...
<seb128> slangasek, yes, and I only uploaded -0ubuntu6 because -0ubuntu5 failed on armel
<slangasek> doko: the error in the log says "<dummy toplevel>:17: unexpected throw"
<slangasek> seb128: ah, ok
<seb128> slangasek, well it didn't fix the build issue which was a random segfault but since a rebuild was needed anyway
<slangasek> seb128: <nod>
<seb128> slangasek, anyway no desktop changes coming now
<seb128> or at least not lib ones
<slangasek> seb128: ok, good :-)
<doko> slangasek: hmm, I did interpret this as a ruby failure ...
<seb128> I might squeeze an app fix later
<slangasek> cjwatson: can't guarantee I'll get to 526391, but adding it to the list
<slangasek> doko: but the commandline above it is a gcc call? :)
<slangasek> oh, no, there's an intervening 'make'
<slangasek> sorry
<slangasek> mdeslaur: was this ruby1.9 FTBFS reproducible?
<sebner> slangasek: I uploaded a new package before FF and it got now rejected because of md5sum mismatch, my understanding is that I don't need a FFe now because nothing is changed for a new upload, right? ;-)
<lucas> you shouldn't care too much about ruby1.9
<lucas> the plan for debian squeeze is to ship ruby1.8 and ruby1.9.1
<lucas> we are currently dropping library packages for 1.9(.0) and providing them for 1.9.1 instead
<lucas> that transition is almost done
<lucas> I'd would be silly not to follow that in Ubuntu (you would end up with some libs with 1.9.1 binary packages, and some other with 1.9.0 binary packages)
<lucas> s/I'd/it
<lucas> mdeslaur/slangasek: ^
<cjwatson> slangasek: so, bug 524439 - the fix involves migrating console-setup to upstart jobs.  I think this would be a good idea but I'm a bit wary of trying to do it for a3 now.  Should we move it to b1?
<ubottu> Launchpad bug 524439 in console-setup "20100219 Server ISO fails to set up console keyboard correctly" [High,Triaged] https://launchpad.net/bugs/524439
<slangasek> sebner: yes, that should be ok
<sebner> slangasek: great, thanks
<slangasek> lucas: ehm, we're past feature freeze and currently have ruby 1.9 in main and ruby 1.9.1 in universe; someone would need to steer this transition on the Ubuntu side and come up with a plan of action quickly, are you in a position to work that out or do you know someone else on the Ubuntu side who would?
<lucas> I could do that
<lucas> why is ruby 1.9 in main?
<slangasek> cjwatson: yes, I think deferring 524439 makes sense here
<lucas> slangasek: (probably as a dep of something, but I'd need to know what that something is)
<slangasek> lucas: according to http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/all, it's rrdtool
<lucas> slangasek: ah, ok
<slangasek> lucas: though germinate only ever tells you first-match, so there could be other reasons
<slangasek> lucas: rrdtool, libaugeas-ruby
<slangasek> (EOF)
<lucas> libaugeas-ruby? why do you have that in main?
<slangasek> lucas: for puppet
<lucas> anyway, both were already migrated to 1.9.1. rrdtool is a newer version, so the patch would have to be backported
<lucas> ok
<cjwatson> slangasek: I think it's probably something like http://paste.ubuntu.com/382441/, but I *know* there are subtleties here, like making sure dpkg-reconfigure saves the keymap
<cjwatson> and IIRC Scott wanted setupcon to run as a udev rule, though perhaps an upstart job is an acceptable stopgap
<slangasek> cjwatson: udev rule sounds non-trivial, since it also has to wait for /usr, doesn't it? (I assume - since otherwise it wouldn't need to be 'start on filesystem')  So would probably have to be an upstart job regardless
<slangasek> mdeslaur: answer: yes, the FTBFS is reproducible
<Cascade_> New programming forum! http://www.hackersrus.info JOIN!
<apw> does anyone know if we expect plymouth fsck integration to work completly?  i think i just hit ESC on it and instead of stopping plymouth exited and the fsck continues (it looks like)
<slangasek> apw: 'esc' isn't supposed to stop the fsck
<apw> heh is anything?
<slangasek> apw: did you have a '[C]' sitting on your screen before you hit esc?
<apw> nope, i had the fsck and the red? progress bar
<apw> so i hit escape, does that just kill plymouth?  have i been a wally?
<slangasek> there are a number of completely opaque keys you're supposed to be able to press for various actions; you should get a line telling you what the keys are, but not what they do...
<slangasek> apw: try hitting 'esc' again, see if it comes back :-)
<cjwatson> slangasek: keyboard-setup doesn't necessarily, maybe console-setup does - personally I do tend to think that a udev rule may be more trouble than it's worth although it seems to be a sort of theoretical ideal
<apw> slangasek, oh yeah it did.  what does the [C] indicate?  cancel?
<slangasek> apw: I think so
<slangasek> [C]ancel, [S]kip, [M]aintenance
<apw> ahh ... thats not at all intuitive, and the semantic change for ESC is going to hurt peoples heads ...
<apw> i suspect a release note may be in order
<slangasek> well, I think we need to get that text fixed before release
<slangasek> there's an open bug on mountall about it
<apw> that would help a lot
<apw> sorry for the noise
<sebner> slangasek: what's the difference between Cancel and Skip?
<slangasek> sebner: cancelling an fsck vs. skipping waiting for a filesystem
<sebner> the same for me
<sebner> nearly
<slangasek> no, they're opposite
<slangasek> cancelling the fsck will cause it to try to mount anyway, skipping waiting for the filesystem will cause the boot to proceed without mounting
<slangasek> (I think)
<sebner> slangasek: and what happens if that's the root partition you skip?
<slangasek> you don't always get all the options :)
<sebner> what a magic and intelligent system ;D
 * ogra wishes mountall was that clever :)
<ogra> ... and would learn to handle broken hwclocks :)
<mdeslaur> lucas, slangasek: I've spent a lot of time trying to get ruby1.9 to compile with the -2ubuntu2 gcc revision, and failed
<slangasek> mdeslaur: and if you roll back to the previous gcc, it works?
<mdeslaur> lucas: if you can get 1.9.1 in main instead of 1.9, that would be great
<mdeslaur> slangasek: yes, going back to -2ubuntu1 works fine
<slangasek> mmk
<xnox> mvo: your awesome! #ubuntusoftwarecentre
<lucas> slangasek, mdeslaur: actually, it might be easier to get ruby1.9.* out of main. it only requires dropping the dependency in rrdtool and libaugeas-ruby, and the 1.9 binary packages don't have any other users in the archive.
<lucas> slangasek, mdeslaur: given that 1.9.{0,1} are development branches of ruby, it's probably a good idea not to support them
<mdeslaur> lucas: I agree
<slangasek> lucas: no objection from me
<mdeslaur> lucas: looks like libaugeas-ruby1.8 is in main, 1.9 is in universe already
<lucas> mdeslaur: yeah, but I guess that the problem is that libaugeas-ruby build-depends on ruby1.9
<mdeslaur> oh, I see
<lucas> mdeslaur: (same for rrdtool, probably)
<cjwatson> slangasek: I think I found a Debian bug matching the described screen corruption symptoms, with an analysis
<cjwatson> yay Debian
<mdeslaur> lucas: actually, libaugeas-ruby only builds libaugeas-ruby1.8 for lucid, so it's not a problem (libaugeas-ruby1.9 is not in lucid)
<lucas> mdeslaur: ah
<lucas> mdeslaur: it was forked, and not merged, so it's severely outdated in ubuntu
<lucas> mdeslaur: it's probably a good idea to merge it from debian
<lucas> (correction: it wasn't forked, it was introduced independantly in ubuntu by DktrKranz in jaunty time)
<mdeslaur> nothing seems to depend on librrd-ruby1.9
<lucas> mdeslaur: "and the 1.9  binary packages don't have any other users in the archive.
<lucas> "
<lucas> ;)
<mdeslaur> lucas: die-ruby1.9-die-die-die
<lucas> mdeslaur: do you want to patch rrdtool to drop the ruby1.9 package?
<mdeslaur> lucas: I can do that, sure
<lucas> mdeslaur: on my side, I'll prepare a list of syncs from debian for the ruby packages
<mdeslaur> lucas: sounds good, as long as you remove libaugeas-ruby1.9.1 from the debian libaugeas-ruby package
<lucas> mdeslaur: my plan was to patch that specific package in ubuntu, not in debian
<mdeslaur> lucas: yes, perfect
<mdeslaur> (that's what I meant)
<cjwatson> superm1: you seem to have sent a reply to me to ubuntu-devel containing only quoted text?
<superm1> cjwatson, reply should be below your text
<cjwatson> superm1: https://lists.ubuntu.com/archives/ubuntu-devel/2010-February/030294.html doesn't show it.  Is this a list archives bug?
<cjwatson> oh, it's failing to handle From-escaping correctly
<cjwatson> poo
<cjwatson> I think this is a known list-archives bug, I vaguely recall there being an RT ticket on it from ages back
<superm1> in the interim should I just top reply instead?
<cjwatson> no, it breaks any time you have "From" at the start of a line :)
<superm1> oh :)
<mdeslaur> slangasek: I'm about to upload rrdtool that removes the ruby1.9 main requirement, any objections? and, what's the next step to remove ruby1.9 from main? (that was the only dependency)
<cjwatson> it's doing stupid mbox parsing somewhere
<tremolux> mvo
<tremolux> (woops, scuse me)
<mvo> :)
<mvo> no worries
<cjwatson> slangasek: ok, so newt uploaded to fix the d-i screen corruption; will require a d-i upload once it's built everywhere
<slangasek> mdeslaur: libaugeas-ruby was the other rev-build-dep, that will also need uploaded?
<slangasek> cjwatson: ack, will follow
<mdeslaur> slangasek: it's not a rev-build-dep on lucid
<slangasek> mdeslaur: yes, it is
<mdeslaur> slangasek: oh, yes it is, I'll fix that too
<mdeslaur> it's not even building the binary packages for ruby1.9 anyway
 * slangasek nods
<mdeslaur> slangasek: packages uploaded
<slangasek> mdeslaur: cheers :)
<mdeslaur> slangasek: will the seeds correct themselves, or does someone need to move ruby1.9 to universe?
<lucas> mdeslaur: have you took the opportunity to merge libaugeas-ruby from debian? there's probably not much point in keeping the older version in lucid.
<mdeslaur> lucas: no, I haven't...I just wanted to get the ruby1.9 build dep out for now
<lucas> slangasek: can I submit a bug with a list of sync requests, or should I file one bug per sync req?
<slangasek> lucas: it's generally easier on the process to submit one bug per package; for one thing, you can use 'requestsync' that way
<slangasek> (instead of having to open tasks by hand for each package)
<lucas> slangasek: ok
<mdeslaur> fyi, I have opened bug 526677 to get ruby1.9 moved to universe
<ubottu> Launchpad bug 526677 in ruby1.9 "ruby1.9 should not be in main for an LTS release" [Undecided,New] https://launchpad.net/bugs/526677
<mrenouf> Is it possible to make unattended-upgrade work like 'apt-get distupgrade' ? Specifically, permit it to install versions with new dependencies?
<slangasek> mdeslaur: bug isn't needed, as soon as it no longer has revdeps it'll show up on component-mismatches and be processed semi-automatically
<mdeslaur> slangasek: ah! thanks for the info!
<sgnb> randomaction: right
<sgnb> (basically everything in round 3 depend on findlib)
<randomaction> sgnb: ok, I'll do some of the rebuilds tomorrow and will advertise this transition on #ubuntu-motu a bit
<Laney> you should email the mailing list about it
<randomaction> ok, will do
<jdstrand> sbeattie: hey. fyi I fixed test-clamav.py in qrt so it should actually work now (verified on lucid as well as pending update for hardy)
<jdstrand> sbeattie: I saw it on the qa-lucid-automated-server-testing bp and thought that its brokenness may have been why it was postponed
<jdstrand> oh, that is actually for ara
<sbeattie> jdstrand: I think there was something in the documentation about needing to wait for clamavd to start before running that had me not pursue it.
<jdstrand> sbeattie: there is a sleep call waiting for clamd.ctl. I t*think* that was only needed on feisty, but I'm not sure
<jdstrand> anyhoo, it works now...
<sbeattie> okay, I wasn't sure, and I didn't want to fight races, I'll give it a go and see about enabling it.
<jdstrand> cool
<Laibsch> Hi, I know there are some people thinking about how distributions like Ubuntu and OpenSuse or Gentoo can collaborate better in packaging software (sharing patches is just one example).  Can you give me some names of people driving this?
<superm1> slangasek, would it be OK to upload the fix for bug 526405 still so that it could make a3?
<ubottu> Launchpad bug 526405 in ubiquity "oem-config-firstboot crashing upon run" [Undecided,Fix committed] https://launchpad.net/bugs/526405
<slangasek> superm1: if we got other ubiquity fixes in at the same time, maybe; otherwise, given the landscape for a3 I think that should go to errata
<superm1> slangasek, got another one for bug 526496 in there too
<ubottu> Launchpad bug 526496 in ubiquity "Kubuntu OEM install fails" [Undecided,Fix committed] https://launchpad.net/bugs/526496
#ubuntu-devel 2010-02-24
<superm1> and cjwatson had a commit for the fix to bug 524169  on the tree ready to go too
<ubottu> Launchpad bug 524169 in ubiquity "Ubiquity installer partitioner crashed, main installer enters endless loop" [High,Fix committed] https://launchpad.net/bugs/524169
<slangasek> superm1: ok, that sounds like a set worth uploading then
<slangasek> superm1: please go ahead
<superm1> alrighty, thanks
<Sarvatt> so something is sending a quit signal to x's controlling tty when some people press enter after first boot ( http://paste.ubuntu.com/382615/ shows it coming from the tty layer) when plymouth is used. suse seems to be getting around it with http://suse-moblin.com/obs-status/Moblin:Factory/aaa_base/aaa_base-bootsplash.patch anyone familiar enough with plymouth to dig into it more? i noticed one place where it could be resetting the ISIG flag o
<Sarvatt> n plymouths tty (in src/libplybootsplash/ply-terminal.c) so the enter key (0x1c) becomes Control-\ (0x1c) if the same VT is used for X but its a bit over my head.
<slangasek> pitti, bryceh: what's the status of hal removal now?  I see it included on daily desktop ISOs, which seems to put the lie to what was written in the A2 tech overview :)
<bryceh> slangasek, afaik we no longer use it for anything
<bryceh> slangasek, so if you spot something X-ish which does, let me know as it's a bug
<slangasek> it's in main because of libvirt-bin, but that doesn't explain it being on the CD; will dig
<slangasek> ah, it's pitivi
<ccheney> lol
<bryceh> heh
<slangasek> seb128, robert_ancell: does pitivi need this Recommends: hal?
<robert_ancell> slangasek, not sure, seb128 do you know?
<robert_ancell> slangasek, thanks for your help with plymouth+upstart.  It's driving me insane :)
<seb128> slangasek, yes
<slangasek> seb128: waah - why? :)
<seb128> slangasek, it needs to be ported to python-gudev
<slangasek> robert_ancell: is it /still/ driving you insane? :/
<seb128> slangasek, because it uses it...
<robert_ancell> slangasek, yeah.  I already knew about the /proc issue (I've tried mounting it before running plymouthd and modifying plymouthd to not require it)
<slangasek> seb128: is that likely to happen in lucid?  I guess the daemon is no longer started by default so it's not a huge problem, right?
<robert_ancell> slangasek, the problem I find is it's really hard to tell why it doesn't boot up
<seb128> slangasek, https://bugzilla.gnome.org/show_bug.cgi?id=605920
<ubottu> Gnome bug 605920 in general "Switch to (g)udev for device detection/support (deprecation of HAL)" [Normal,New]
<slangasek> robert_ancell: even after fixing plymouthd to not mind if /proc is missing?
<seb128> slangasek, would be nice for lucid, and correct for the start
<robert_ancell> slangasek, yeah, did that ages ago.
<robert_ancell> seb128, is gudev an official GNOME dependency?
<slangasek> robert_ancell: mmk; is there some way I can get my hands on a running environment of what you're working on, to poke at directly?
<seb128> robert_ancell, yes, there was no python bindings though
<slangasek> (not that I'll have time until Friday, but)
<seb128> robert_ancell, pitti get that solved now
<robert_ancell> seb128, that's what I was going to ask pitti - is the halsectomy an ubuntu goal and/or a GNOME goal?
<seb128> both I guess
<seb128> not an official GNOME goal that I know
<seb128> but they work toward deprecating it too
<slangasek> bryceh: is this note about not having wacom support obsolete in a3?  I see xserver-xorg-input-wacom is in now
<bryceh> slangasek, that's correct, wacom is good to go
<slangasek> \o/
<Sarvatt> well usb wacom support at least, serial digitizers still need an xserver change thats in git
<Kai_> why is there a distribution upgrade available? I'm running lucid alpha 2.
<persia> Kai_: Probably as part of the testing for the upcoming Alpha-3: you might get a more detailed answer in #ubuntu+1
<Sarvatt> next xserver upload will have it, most tablet pc's need that
<Kai_> okay, thanks
<ccheney> is there a known issue with lucid that when you do autologin it doesn't seem to change to the X server
<ccheney> i see the xcursor but not the rest of X
<ccheney> 16.5s boot from upgraded lucid (not clean install by any stretch) not bad at all :)
<ccheney> it just doesn't show X properly for some reason :-\
<ccheney> hmm it worked after trying again
<ccheney> seems to not be completely stable for me for some reason
<slangasek> mdeslaur, zul: where did /etc/network/if-up.d/samba go in samba 2:3.4.5~dfsg-2ubuntu1 ?  this should have been kept until the conversion to upstart could be done (bug #526659)
<ubottu> Launchpad bug 526659 in samba "nmbd fails to start at boot time" [Undecided,New] https://launchpad.net/bugs/526659
<slangasek> ccheney: bug #521175; would love it if you could figure out *why* autologin is different
<ubottu> Launchpad bug 521175 in plymouth "Plymouth AND Automatic Login enabled system freezes" [Undecided,Incomplete] https://launchpad.net/bugs/521175
<mdeslaur> slangasek: looking now
<slangasek> mdeslaur: if it's broken anyway, I'm inclined to just upload for bug #523868, I'm just surprised to see this regression
<ubottu> Launchpad bug 523868 in samba "FFe request: samba upstartification" [Low,New] https://launchpad.net/bugs/523868
<ccheney> slangasek: it didn't actually freeze for me, some of the times the xcursor showed up but not the rest of the desktop, other times it came up all the way but then x would crash after a short time, but would respawn ok
<ccheney> on intel x4500
<slangasek> ccheney: all the same thing.  Does gdm come up ok when *not* using autologin?
<ccheney> slangasek: yea
<ccheney> slangasek: and even when x didn't come up all the way i could still switch vt's
<slangasek> ccheney: yep.  So somewhere in the gdm logic to interface with plymouth, there's a bug when autologin is used; but I couldn't find it when I tried to trace the gdm code
<smoser> can someone accept nomination for lucid for https://bugs.launchpad.net/ubuntu/+source/euca2ools/+bug/526697
<ccheney> oh ok
<ubottu> Launchpad bug 526697 in euca2ools "euca-describe-images has incorrect order of ramdisk and kernel" [High,Confirmed]
<ccheney> on the times i booted up and xcursor was all that showed it played the login music with just the black screen, one time i switched vt's and the desktop showed up, iirc it crashed soon afterward though
<ccheney> so maybe some kind of bug with the vt switching in plymouth/gdm, but not really sure
<Sarvatt> every time that's happened to me ureadahead was reprofiling, could just be a coincidence though.
<slangasek> there very definitely seems to be something different in gdm's interaction with plymouth when using autologin
<slangasek> if someone can figure out what, that's probably the bug
<slangasek> (and knowing what it is might help me fix other plymouth bugs, fwiw)
<mdeslaur> slangasek: looks like the samba in lucid never got the if-up.d file added to debian/samba.files
<mdeslaur> zul: ^
<slangasek> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/462169/comments/64
<ubottu> Launchpad bug 462169 in samba "nmbd dies on startup when network interfaces are not up yet" [High,Fix released]
<zul> mdeslaur: i remember putting it in lucid its in lucid-updates as well
<mdeslaur> zul: you forgot to add it to debian/samba.files
<mdeslaur> zul: http://launchpadlibrarian.net/38098612/samba_2%3A3.4.3-2ubuntu1_2%3A3.4.3-2ubuntu2.diff.gz
<zul> frig...
<zul> my bad
<slangasek> huh, ok :)
 * mdeslaur votes for the upstart job :)
<zul> as do i :)
<homebrewcider> anybody use dvbcut? i get an error message saying "the chosen file *** contaqins no video"    anybody come across the before?
<micahg> !support | homebrewcider
<ubottu> homebrewcider: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<homebrewcider> oops sorry
<homebrewcider> clicked the wrong room
<persia> happens to everyone once :)
<ScottK> Some much more frequently than that.
<mohaa> o/
<mohaa>   /usr/lib/claws-mail/plugins/notification_plugin.so: undefined symbol: menu_create_items
<mohaa> i'm having issues with 2 plugins in claws-mail
<mohaa> notification and att_remover
<mohaa> is that here that i should adress  or to maintainer ?
<jdong> mohaa: best to file a bug on launchpa
<jdong> d
<jdong> ubuntu-bug claws-mail
<mohaa> doing it
<mohaa> likely, it's too complicated :D
<jdong> awesome, thank you.
 * mohaa mad at maintainers not using their builds  :P
<jdong> we're not being mean and trying to send you to the proverbial RT, just the bug tracker is the best way of getting the attention of those who care, so to speak.
<mohaa> actually in this case CLAWS-MAIL has been upgraded  and not the plugins   -_-
<mohaa> so we have fresh client  and plugins compiled for an older version of claws :-\
<jdong> is this on karmic or lucid?
<mohaa> :o
<mohaa> 9.04
<jdong> groan... yikes.
<mohaa> i don't use this system much so....
<jdong> ugh *rant mode* plugin packagers should properly depend on the version of the parent program they need....
<mohaa> :D
<jdong> *end rant* :)
<ScottK> IIRC the one Ubuntu dev I know of that uses claws mail wasn't that active during Jaunty development.
<ScottK> jdong: It probably just needs a rebuild.
<mohaa> i see it
<jdong> why am I getting a deja vu moment.
<mohaa> it's still on 3.6 series  :-\
 * ScottK used to need to care about claws when it has clamav plugin.
<mohaa> ScottK_san it still has it  ;)
<nigelb> mohaa: you probably could check this ppa https://launchpad.net/~claws-mail/+archive/ppa
<mohaa> nigelb  thx :)
<mohaa> i'm using a quite old buntu so...
<syn-ack> hey, didnt Alpha 3 drop today?
<bryceh> Thursday
<syn-ack> I could have sworn the timeline said today
<bryceh> February 25th
<syn-ack> Must have confused it with the rebuild test
<jdong> I think a 3-day pushback.
<syn-ack> Ok, so I'm NOT nuts
<jdong> just got the freeze announcement this morning
<jdong> which mentioned a schedule delay :)
<jdong> so no, you probably correctly marked your calendar
<mohaa> jdong: https://bugs.launchpad.net/ubuntu/+source/claws-mail/+bug/526831   ;)
<ubottu> Launchpad bug 526831 in claws-mail "Claws-mail : plugins built against different parent program" [Undecided,New]
<ScottK> jdong: Milestone releases are always on Thursdays.
<jdong> ah, gotcha
<ScottK> Freeze on Tuesday and release on Thursdays for Alphas.
<nasserash> hello everyone: I'm trying to compile with gcc a program and I need the -lsocket library, I installed "happycoders-libsocket-dev" but I still get an error that says "/usr/bin/ld: cannot find -lsocket" any ideas ?
<mohaa> bye you guys
<mohaa> o/
<det> Is it known if Lucid will ship with Mono 2.6 ?
<det> It is currently using 2.4, and 2.6 was released in December and contains many bug fixes
<micahg> det: it will probably be 2.4 as that's an LTS
<micahg> det: 2.6 will most likely be in lucid +1
<det> That is very unfortunate, but thanks for the info
<micahg> det: it would be more unfortunate to have an unsupported version of mono in an LTS :)
<det> What do you mean by unspported ?
<micahg> det: mono only supports branches for certain amounts of time, so if we ship a short support branch in a long term release, then we'll have a period of time w/out upstream fixes/patches
<det> Do you happen to know that Mono 2.4 is a long term support branch, while 2.6 not?
<micahg> det: http://www.mono-project.com/Roadmap
<det> I understand now, thanks.
<micahg> det: np :), LTS's aren't the place for latest and greatest anyways..people want stability more than features in tehm
<det> Perhaps some of the bug fixes I am interested in from 2.6 are backported into the 2.4.3 release
<micahg> det: maybe and if they're not, maybe it can be requested
<det> I will test out the Lucid alpha-2
<micahg> det: alpha 3 is coming thursday
<det> Well, I am interested in testing mono 2.4.3, which I think alpha-2 has
<det> I tried 2.6 from a suse live cd, and it solved some problems in an application
<pitti> Good morning
<StevenK> Hi pitti!
<pitti> bryceh, slangasek: so the two remaining use cases of hal in lucid are: (1) pitivi, and (2) gnome-power-manager uses hal to change the backlight on devices which don't have XBACKLIGHT support (which is still the majority)
<pitti> slangasek, bryceh: hal was switched to d-bus activation, i. e. it does not start up on systems with xbacklight support on boot
<pitti> slangasek: I'm afraid we are stuck with that in lucid
<StevenK> pitti: I guess pitivi uses hal for hardware notifications?
<pitti> yes
<pitti> finding cameras, etc.
<StevenK> Bleh
<bryceh> pitti, is the xbacklight issue already known upstream?
<StevenK> However, g-p-m is the much harder one to kill :-/
<pitti> bryceh: yes, for a long time
<bryceh> brb, gotta help put kiddo to bed
<pitti> bryceh: it's a matter of getting driver support for it
<pitti> argh! a dist-upgrade here wants to install chromium now, WTH?
<StevenK> Wow, what's pulling that in ...
<bryceh> pitti, any work arounds?  Can whatever hal does be extracted into something more standalone?
<pitti> argh, nevermind
<StevenK> pitti: False alarm?
<pitti> bryceh: in theory yes, but in practice it'd be better to add xrandr support to drivers; otherwise you keep having two things which are responsible for the backlight control
<bryceh> pitti, hmm, well waiting for stuff to get added to drivers (X drivers at least) can take a while...
<pitti> right
<pitti> but I think there's no way we can make even a workaround happen in lucid
<dholbach> good morning
<slangasek> pitti: ok, makes sense
<Mamarok> is something wrong with the repo main server? it is extremely slow
<nigel_nb> Mamarok: yep.  same here
<mtx_init> to much tv
<pitti> aah, I tracked down the reason for the major udisks boot time increase \o/
<ogra> geez, our armel images exploded in size ... darn openoffice
<pitti> ogra: when? which version of rhythmbox-ubuntuone-music-store do you have?
<ogra> pitti, did we inherit the new langs from you guys ?
<pitti> ogra: today's netbook images exploded by 40 MB, due to a wrong dependency in above
<ogra> pitti, the image from 22 is 540 vs 690 today :)
 * ogra check RB
<pitti> ogra: we dropped most languages from our seeds
<ogra> *checks even
<ogra> +rhythmbox-ubuntuone-music-store 0.0.2-0ubuntu2
<pitti> that's it
<ogra> http://paste.ubuntu.com/382809/ is the manifest diff
<pitti> ogra: you can substract 40 MB once  0.0.2-0ubuntu3
<pitti> is published
<ogra> ah, cool
<ogra> still bloated :)
<ogra> 540MB was so convenient :)
<pitti> +default-jre 1.6-34
<pitti> there you go
<pitti> don't do that
<ogra> i think that came in with oo.o
<ogra> we didnt change our seeds at all, we only use what you guys use for netbook now
<pitti> ogra: don't seed oo.o-base
<persia> It's the *same* seed.
<ogra> it will go again once the online office spec is fully implemented
<ogra> until then we'll live with oo.o i guess ... its not oversized yet
<pitti> hm
<pitti> -base is not seeded
<ogra> and 40MB less gets us back to 650 at least
<pitti> so some wrong dependency pulls it back in
<pitti> it's not on the i386/amd64 ones
<ogra> strange
<ogra> the seeds are identical, as persia stated abov
<ogra> e
<pitti> ogra: we recently had that problem on i386/amd64 as well
<ogra> what was the issue ?
<pitti> some oo.o translation package depended on language-support-writing-en | openoffice.org
<pitti> something like that
<pitti> but that got fixed during the sprint
<ogra> weird, there shouldnt be any armel specific deps
<pitti> it's definitively not a seed problem
<pitti> +openoffice.org-report-builder-bin 1:3.2.0~rc4-1ubuntu1
<pitti> nobody ever seeded stuff like that
<ogra> Reverse Depends:
<ogra>   openoffice.org-report-builder
<ogra>   openoffice.org
<ogra> hmm, the same on x86
<pitti> ogra: perhaps some package is out of date on armel?
<lifeless> pitti: in my laptops dmesg
<lifeless> pitti: actually, I lie
<lifeless> I was sshed into a linode ;P ignore that
<pitti> hm, I'm pretty sure we disabled it in karmic
<pitti> heh
<lifeless> I do see udev spam on boot
<lifeless> probably stale rules or something
<pitti> lifeless: I see them from calibre
<pitti> but I'm sure there's plenty of other broken/obsolete rules in packages out there :/
 * pitti will fix calibre soono
<pitti> s/o$//
<lifeless> calibre? free californians?
<pitti> heh
<pitti> lifeless: e-book organizer/converter/creator
<lifeless> nice
<lifeless> I was trolling :>
 * pitti remembers to stop taking you seriously from now on :)
<pitti> lifeless: how's your Klingon these days?
<lifeless> pitti: you should, when I'm not serious
<lifeless> pitti: terrible, I don't know it
<lifeless> pitti: I only set it up for you guys :>
<lifeless> pitti: however, FF has a klingon pack too, now.
<tseliot> cjwatson: any ideas as to why "DEB_SHLIBDEPS_INCLUDE_$(PKG_driver) := debian/$(PKG_driver)/$(DRIDIR)/fglrx/:/$(DRIDIR)/" doesn't work with cdbs in this case? http://pastebin.ubuntu.com/382879/
<cjwatson> I don't really know cdbs ...?
<tseliot> oh
<cjwatson> maybe try 'export DH_VERBOSE=1' and run the relevant commands by hand to dig into it?
<tseliot> cjwatson: ok, but you know debhelper. Basically what's happening here is that a binary depends on a library shipped by the same package
<tseliot> ok
<tseliot> by hand?
<persia> tseliot: Since debian/control is not supposed to change at build-time, can't you just hardcode the dependency for that library into debian/control?
<cjwatson> at a shell prompt
<tseliot> persia: the binary and the library it depends on are in the same package
<persia> tseliot: The same source package or the same binary package?
<tseliot> persia: both things
<persia> tseliot: Then why do you care about shlib:Depends there?  You know it's provided.  Just ship a symbols file for things that build against it.
<persia> tseliot: If you're working around debug packages, you may want to request debhelper >= 6.0.3, but as long as you have debhlper >= 6.0.0 you shouldn't need -l anyway (which is what DEB_SHLIBDEPS_INCLUDE sets)
<Noisi> hi there! i try to cross compile with arm-linux-gcc a sqlclient to arm720t and i need lib mysqlclient. Must i compile it from soucre? How?  it would give me great pleasure for some tip.
<tseliot> persia: it's a proprietary library and it can get even messier. I've found out that my cdbs option works if I create a link (libfglrx_gamma.so.1) to libfglrx_gamma.so.1.0 (the actual library)
<tseliot> persia: as the error was dpkg-shlibdeps: error: couldn't find library libfglrx_gamma.so.1
<persia> tseliot: Ugh.  That's just messy.
<tseliot> persia: welcome to the world of fglrx ;)
<persia> Noisi: #ubuntu-arm might be a better forum.  There are precompiled binaries that might or might not work properly in a primarily cross-compiled environment.
<Noisi> persia: Thanks :-)
<tseliot> persia: with that link I don't even need DEB_SHLIBDEPS_INCLUDE_
<persia> tseliot: So, you're operating with binary blobs?  I suspect a gap between filenames and information presented from introspection (nm might let you confirm).  Drop the -l, add the symlink, and generate a symbols file just to verify stuff.
<persia> tseliot: Well, if you use debhelper 5 you'd still need it :)  The fix is with debhelper 6.  What's debian/compat?
<tseliot> persia: 7
<persia> Yeah, then you very much don't need DEB_SHLIBDEPS_INCLUDE
<tseliot> cjwatson, persia: ok, thanks for your help
<qense> If we would like to get bug #506125 fixed we'd have to sync Nautilus Actions, because the fix is in 2.29.4. Otherwise I'd remove nautilus-actions since it now just doesn't work. Will nautilus-actions be synced to 2.30 in time for the Lucid release?
<ubottu> Launchpad bug 506125 in nautilus-actions "nautilus-actions-config-tool assert failure: NA-nact:ERROR:nact-ibackground-tab.c:381:get_folders_treeview: assertion failed: (GTK_IS_TREE_VIEW( treeview ))" [Medium,Triaged] https://launchpad.net/bugs/506125
<cjwatson> Noisi: you might also like to look into dpkg-cross
<cjwatson> (requires some setup)
<soren> Keybuk: Mind if I bother you for a sec? In VMBuilder, I routinely mkfs some devmapper devices. Immediately afterwards, I use blkid to extract the uuid. Occasionally, blkid fails (exit code 2).
<soren> Keybuk: I tried adding a "udevadm settle" in between the two, but it still happens every once in a while.
<soren> It's rare, so I thought the "udevadm settle" fixed it, but it just happened again, so now I'm back to square 1.
<Keybuk> soren: the mkfs will cause udev to run blkid itself, and rearrange symlinks
<Keybuk> which way do you run blkid?
<Keybuk> with -p or without?
<Keybuk> if you run without, it's possible the cache is out of date
<soren> without.
<soren> Right.
<Keybuk> right, run with -p
<soren> Hm. I thought that was frowned upon.
<Keybuk> you shouldn't need the settle
<Keybuk> -p is a physical probe of the block device
<soren> I thought the idea was that only udev would need to do that.
<soren> I understand.
<Keybuk> without means "whatever was in the cache"
<Keybuk> yeah
<Keybuk> but you need to wait for udev to do that
<Keybuk> you can steal the wait-for-root code out of initramfs-tools if you like
<Keybuk> that has the logic to wait properly
<Keybuk> if you use that, you can just call blkid
 * soren looks at that
<soren> Can you explain why -p is needed? I thought that when mkfs let go of the device node, it would trigger an inotify event upon which udev would react, and that "udevadm settle" wouldn't return until udev was done processing this event (and thus, calling blkid -p and updating the blkid cache).
<soren> Which part is mistaken?
<soren> Keybuk: ^
<Keybuk> that "udevadm settle" knows what you meant to wait for
<soren> Keybuk: Could it be that my "udevadm settle" occurs before udev even sees the inotify event and thus does not think there are any unprocessed events?
<Keybuk> udevadm settle simply waits for udev to be idle
<Keybuk> events could be still somewhere en-route to udev
<Keybuk> when we initially added the inotify stuff, it was true that udevd would force the inotify queue to be drained on settle
<Keybuk> on the assumption that any file close instantly resulted in the entry being added to the inotify queue
<Keybuk> but inotify has been entirely rewritten since then (replaced in-kernel with fsnotify)
<Keybuk> so that may no longer be true
<Keybuk> it might be possible for there to be a gap between the mkfs call, and the inotify event being queued for udev to receive
<soren> Right, ok.
<Keybuk> it would be worth reading some kernel code to find out whether or not that's changed
<soren> Keybuk: You said "when we initially added the inotify stuff, it was true that udevd would force the inotify queue to be drained on settle"... Does it not attempt to drain this queue anymore? (Yes, I understand that the event might not be in the queue at all yet, this is just a side-question)
<Keybuk> soren: udevd does, yes
<soren> Ok.
<Keybuk> *inotify*, in the kernel, has been completely rewritten
<Keybuk> so it's possible that the act of mkfs closing the device node does queuey things in the kernel
<Keybuk> that no longer guarantees that udevd's inotify socket polls for reading *by the time close() returns*
<Keybuk> if that bit has gone async in the kernel, you'd have a race where after mkfs exits, udevd may not yet have received the inotify event for the block device
<soren> *nod*
<Keybuk> that'd be worth some investigation
<soren> Keybuk: udev still uses the inotify /interface/, right?
<Keybuk> yes
<soren> alright
<cjwatson> Keybuk: so yesterday I started converting console-setup to upstart in order to fix its interaction with plymouth, which is a little bit involved due to how it glues into the installer.  Am I duplicating work you've already done and should I stop? :-)
<cjwatson> (I didn't get very far as it was at the end of the day - just wrote initial job sketches)
<Chipzz> Keybuk: ugh, too much *notify's and fa*'s ;P
<Chipzz> starting to get really confusing :)
<Keybuk> cjwatson: no, you're doing work I felt was far too scary for me ;P
<Keybuk> I couldn't work out when we'd actually run console-setup
<Keybuk> since plymouth is *always* running from startup through to power off
<Keybuk> I thought we might need to use ConsoleKit to run console-setup when switching away from X
<Chipzz> inotify, dnotify, fanotify, fam...
<Chipzz> which ones am I forgetting? :P
<Chipzz> fsnotify
<Keybuk> Chipzz: fam is not a kernel interface
<Keybuk> Chipzz: and all those you mentioned are the same in-kernel code
<Keybuk> just different user-space interfaces for the underlying fanotify code
<Keybuk> or is it fsnotify
<Chipzz> Keybuk: I know, but all these technologies fall into the same "realm"
<Keybuk> Chipzz: they're all the same technology from the kernel POV
<Chipzz> just different iterations :P
<Keybuk> the difference between inotify, dnotify and fanotify is the difference between open(), creat() and socket()
<Keybuk> no, not even iterations
<Keybuk> *the same code*
<cjwatson> Keybuk: I was thinking of running it 'on starting plymouth-splash'
<cjwatson> roughly
<Chipzz> wasn't dnotify replaced by inotify?
<Chipzz> s/replaced/obsoleted/
<soren> Chipzz: Yes.
<Keybuk> Chipzz: dnotify was implemented using inotify
<soren> Chipzz: And then inotify was replaced by fsnotify.
<Keybuk> cjwatson: right, that's about the only point we can do it
<Keybuk> the problem then is racing gdm
<Keybuk> you could be doing console-setup and hold up plymouth --show-splash
<Keybuk> meanwhile gdm starrs
<Keybuk> and starts X
<cjwatson> this would suck less if the kernel sucked less
<cjwatson> it's ridiculous that we need an active text-mode console in order to set the console font
<Keybuk> agree
<Keybuk> it would suck less if upstart sucked less too
<cjwatson> using consolekit would sort of work, but wouldn't be effective on server-type installations
<cjwatson> since ttx filed the bug in question ... :-)
<cjwatson> (well, one instance of it)
<Keybuk> well, on server plymouth does exit at the end of rc2
<Keybuk> so that's one obvious place to run console-setup
<cjwatson> yeah, true
<cjwatson> we used to do that for usplash
<cjwatson> could shove it in plymouth's stop script
<Keybuk> it's desktop that's tricky, because getting to a console is really only by C-A-F1
<Keybuk> cjwatson: on stopping plymouth plz :p
<cjwatson> fair enough :)
<Keybuk> shoving other things into upstart scripts is not the upstart way ;)
<cjwatson> ok, so I'm happy to make this my problem if I'm not stepping on your toes and you don't mind occasional requests for criticism
<Keybuk> sure
<Keybuk> I'm happy for it to be your problem
<Keybuk> gives me more time for plymouth itself to be my problem <g>
<cjwatson> maybe I should just fix the damn kernel
<Keybuk> Jim Leib tried that
<Keybuk> he died
 * cjwatson is not Jim Lieb
<cjwatson> :-)
 * ogra grins
<Keybuk> no, indeed; you're unlikely to have to learn ANSI C just to read the kernel source
 * sebner has faith in our mighty cjwatson :D
<cjwatson> well, this is something that's defeated me in the past, so we'll see
<cjwatson> the basic problem (AFAICR) is that vgacon stores the font only in video memory
<Keybuk> we're not using vgacon anymore though, right?
<Keybuk> we're always using fbcon
<cjwatson> Keybuk: for a kernel bug report, I'd want to cover all possibilities
<cjwatson> *kernel patch
<cjwatson> Keybuk: and that's the basic reason why there's a != KD_TEXT guard in console-impl-independent code
<Keybuk> yeah, I recall
<Keybuk> didn't we find a different ioctl() that didn't have that guard?
<Keybuk> my memory on this is hazy
<Keybuk> though that may be the fact I just downed 8 different tablets ... whee drugs :p
<cjwatson> Keybuk: I don't remember that, though that's not to say it didn't happen - I'd rather fix it so it doesn't need the guard though :)
<Keybuk> right
<seb128> "ubi-partman failed with exit code 141"
<seb128> I guess it's not today I will manage to reinstall that mini
<seb128> "Device /dev/sda1 not found is os-prober"
<seb128> "Device /dev/sda1 not found is os-prober output"
<seb128> rather
<seb128> what component should be bugged about that?
<cjwatson> device not found> irrelevant message
<cjwatson> bug on nubiquity
<cjwatson> *ubiquity
<cjwatson> please reproduce with debug-ubiquity on the kernel command line before filing the bug, and use ubuntu-bug from within the live session to file it
<seb128> cjwatson, ok will do
<pitti> cjwatson: gnome-user-share does not have any uploaders in edit_acl at all; can you please fix this?
<lamont> some of the ppa buildds are undergoing a little maintenance atm.  Just fyi
<dholbach> bryceh: could it be that your script went beserk on bug 520796? :)
<ubottu> Launchpad bug 520796 in x11proto-dri2 "Sync x11proto-dri2 2.2-1 (main) from Debian unstable (main)" [Undecided,Incomplete] https://launchpad.net/bugs/520796
<uelapeppa> hi
<balboa> hi
<balboa> i've tried to make an ubuntu lucid remix folowing this how-to :https://help.ubuntu.com/community/LiveCDCustomizationFromScratch but when i try to install it i get "AssertionError: Missing filesystem.size." from ubiquity
<seb128> cjwatson, bug #527057
<ubottu> Launchpad bug 527057 in ubiquity "ubi-partman failed error on partitions change" [Undecided,New] https://launchpad.net/bugs/527057
<seb128> seems similar to bug #525081
<ubottu> Launchpad bug 525081 in ubiquity "ubi-partman failed with exit code 141" [Undecided,Incomplete] https://launchpad.net/bugs/525081
<seb128> "PartmanOptionError: partman/choose_partition should have finish (None) option"
<seb128> cjwatson, I get the issue every time on the mini so let me know if you need any detail
<ev> balboa: you need /casper/filesystem.size on your CD.
<balboa> ev: and how can i create it?
<ev> well, if you haven't changed the squashfs at all, you can simply reuse the existing one.  If you have changed the squashfs, then:   printf $(du -sx --block-size=1 /path/to/the/mounted/squashfs | cut -f1) > filesystem.size
<balboa> ev: i made the iso from scratch so for "/path/to/the/mounted/squashfs" can i use the path of my chroot?
<ev> (updating that wiki page now with this)
<ev> yes
<balboa> ev: thank you =) i'll try it
<ev> balboa: sure thing
<ev> good luck! :)
<pitti> ev: oh, nice! the keymap guesser is in ubiquity now
<balboa> ev: i get some errors from du : it can't read some directories
<ev> balboa: stick a sudo in front of it
<ev> printf $(sudo du...
<ev> pitti: yup :)
<cjwatson> pitti: gnome-user-share> done
<pitti> cjwatson: cheers
<pitti> chrisccoulson: ^ FYI
<chrisccoulson> pitti / cjwatson - thanks
<balboa> ev: i'm stupid -.- i've put sudo in front of printf
<chrisccoulson> pitti - is that part of the packageset i can upload?
<pitti> chrisccoulson: edit_acl says ubuntu-desktop, yes
<chrisccoulson> cool, thanks:)
<pitti> chrisccoulson: when will you apply for core-dev?
<chrisccoulson> pitti - soon hopefully
 * pitti holds up his fanboy cardboard sign
<chrisccoulson> heh :)
<seb128> chrisccoulson++
<ogra> Keybuk, i see "ureadahed-main terminated" messages on boot of armel live images, do i need to worry ? (i dont see that on installed systems, ureadahread seems to work fine there)
<ogra> (do we actually use it in live images)
<Keybuk> ogra: what exit code?
<ogra> i have to reboot for that, gimme a bit
<cjwatson> seb128: investigating
<seb128> cjwatson, thanks
<ogra> Keybuk, it says status 4
<ogra> wow, JamieBennett is a hero, the live image on armel boots really really fast !
<Keybuk> ogra: that's ok, that's just ureadahead saying "I don't have anything to read for this mount point"
<ogra> 1:48 ... vs ~4min in karmic
<ogra> Keybuk, perfect, thanks
<cjwatson> seb128: ah.  bug occurs when there is a partition that partman doesn't know how to resize
<seb128> cjwatson, it shouldn't need to resize anything in my case though?
<seb128> cjwatson, I delete one partiton and use the space to create a new one + a swap
<cjwatson> seb128: sure, but it still scans
<seb128> ok
<cjwatson> it's the cache-building bit that falls over
<seb128> let me know if you want me to test a fix or something
<cjwatson> are you in a position to edit a file before ubiquity starts?
<seb128> cjwatson, yes, I'm back to livecd desktop
<seb128> I can edit and run ubiquity again
<cjwatson> seb128: you'd probably better restart in "try ubuntu" mode, I don't want to deal with possible wreckage in the live session
<seb128> ok, doing that
<seb128> it's an usb key so it's quick to boot ;-)
<cjwatson> seb128: could you apply http://paste.ubuntu.com/382990/ to /usr/lib/ubiquity/plugins/ubi-partman.py, please?
<zul> james_w: thanks for the samba branch
<james_w> zul: it's a little out of date at the moment due to dpkg-dev weirdness, looking in to it right now
<seb128> cjwatson, ok, trying that
<zul> james_w: cool
<seb128> cjwatson, that seems to work, at least I can get to the next screen without error now
<seb128> cjwatson, continuing the install, I will let you know how it works
<seb128> bah
<seb128> ubiquity segfault now
<seb128> is apport running on the livecd?
<seb128> pitti, ^
<pitti> seb128: yes, it is
<cjwatson> segfault?  it's python
<cjwatson> iz gtk bug?
<seb128> cjwatson, http://paste.ubuntu.com/382995
<seb128> cjwatson, iz glib bog? ;-)
<seb128> I don't get a .crash though
<james_w> zul: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558485
<ubottu> Debian bug 558485 in patch "patch creates backup files with 000 perms for newly created files" [Normal,Fixed]
<james_w> zul: that's not fixed in hardy where it matters for this, so I will have to implement a workaround.
<cjwatson> seb128: committed the fix for 527057 anyway, thanks
<seb128> cjwatson, thanks!
<zul> james_w: sounds good to me
<cjwatson> seb128: mm, a few people have reported that kind of thing, I'd tentatively put it down to image errors but if you're seeing it maybe you can figure out what's causing it?
<seb128> cjwatson, I will try, shame that apport is not working
<seb128> bah, it works if I kill -11 gedit
<Laney> is archive.u.c sick?
<james_w> yes
<seb128> cjwatson, any idea what process I should use gdb on?
<seb128> cjwatson, ubiquity exit with code 0377
<seb128> I've gdb --args python /usr/bin/ubiquity
<cjwatson> that'll miss privilege elevation
<seb128> ok
<cjwatson> err
<seb128> let me start again
<seb128> and sudo gdb -p it
<cjwatson> you probably want:
<cjwatson> sudo -E devkit-disks --inhibit -- gdb --args /usr/bin/python /usr/lib/ubiquity/bin/ubiquity
<cjwatson> or something like that
<cjwatson> though yes, attaching to the running process would probably be easier
<didrocks> cjwatson: thanks for the netbook seed fix :)
<cjwatson> no problem, hope it works ;-)
<seb128> cjwatson, http://paste.ubuntu.com/383006/ not really useful ...
 * seb128 tries valgrind
<cjwatson> public service announcement: please can everyone STOP trying to find an existing ubiquity bug report that describes their problem and attaching logs to it
<cjwatson> just file new bugs
<cjwatson> suggests that a main loop source got trashed?
<cjwatson>           prepare = source->source_funcs->prepare;
<seb128> could be yes
<geser> bryceh: do you really need the xorg.log and the output from lspci for a bug about a insufficient dependency (bug 507618)?
<ubottu> Launchpad bug 507618 in xserver-xorg-video-ati "xserver-xorg-video-radeon has insufficient (even missing) dependency on libdrm-radeon1 " [Undecided,Incomplete] https://launchpad.net/bugs/507618
<cjwatson> seb128: do you think I should go ahead with a ubiquity upload for a3 anyway, to get rid of the partitioning bug, or do you think this is likely to need a change in ubiquity?
<seb128> cjwatson, I've no real clue about this crasher atm, I would guess it's an ubiquity issue though since we didn't get similar bugs otherwise
<cjwatson> I don't understand how python code could cause a segfault unless the python binding libraries are broken
<seb128> cjwatson, still I'm not sure the crash bug will be fixed quickly and since it doesn't happen to everybody I would fix the partioning issue to start
<cjwatson> ubiquity used to have some python bindings of its own, but we got rid of those a while back
<seb128> cjwatson, well you could be doing something wrong, like using gtk after exiting the mainloop
<cjwatson> ok, I'll upload .27 then
<seb128> cjwatson, pygtk tends to not handle always such cases in a pythonish way, ie raise exceptions
<seb128> it rather crashes
<seb128> same if you try using gtk without a display set
<cjwatson> hmm, I suppose that's possible
<cjwatson> we do some funny things with the main loop
<cjwatson> could I get a separate bug for this with debug logs?
<seb128> cjwatson, yes, let me try to valgrind first :-)
 * cjwatson nods
<seb128> $ unset DISPLAY; alacarte
<seb128> Erreur de segmentation (core dumped)
<seb128> just as an example of pygtk is not friendly with errors ;-)
<cjwatson> main loop's a bit more likely, DISPLAY isn't going to get magically unset :-)
<seb128> right
<seb128> bah, installing valgrind on the livecd = fail
<seb128> enospace
<cjwatson> mine more memory
<kirkland> pitti: re: https://bugs.launchpad.net/bugs/503180, could you nudge that karmic-proposed eucalyptus to karmic-updates?  I have another SRU pending for upload to -proposed ;-)
<ubottu> Launchpad bug 503180 in eucalyptus "[SRU] eucalyptus-cloud doesn't reply to requests (eucalyptus doesn't work after reboot or services restart issues due to upstart networking behavior)" [High,Fix committed]
<cjwatson> or --no-install-recommends, it might not really need libc6-dbg too badly
<cjwatson> oh, that's a depends, ignore me
<pitti> kirkland: ah, it's just 7 days old today, fine; moving
<kirkland> pitti: cheers, thanks ;-)  i've been keeping my eye on it ;-)
<pitti> didrocks: ah, so you broke the armel netbook images ;)
<didrocks> pitti: me? sure? :-)
<pitti> didrocks: please don't seed language-support-${Languages} for anything else but -en
<pitti> language-support-* is huge, and it also pulls in the entire openoffice.org including java
<pitti> ogra: ^ FYI
<didrocks> pitti: oh, so we need to add [!armel] to the language pack?
<didrocks> (there was -en and -es before my change, FYI)
<ogra> didrocks, oh, pleasse dont :)
<ogra> we want the translations on armel as well
<pitti> --- live2010-02-22 16:00:21 +0000
<pitti> +++ live2010-02-24 14:59:02 +0000
<pitti> - * language-support-${Languages}
<pitti> ogra, didrocks: r1448 in netbook.lucid seed
<ogra> didrocks, the prob is that -support pulls in *everything*, you only want the stuff thats actually needed on a live image for space reasons
<didrocks> pitti: ogra: but it was there before (see in r1441.1.3), only with -es
<ogra> didrocks, there should be -en but no other langs
<didrocks> pitti: ogra: I just add aditionnal language, is there an exception of -es so?
<pitti> didrocks: no, l-support-es shouldn't be there either
<ogra> no, -en is the only language we fully install
<pitti> but -es doesn't have a hyphenation package
<pitti> didrocks: language-pack-* is okay; language-support-* is a no-go for shipping
<seb128> cjwatson, while looking around I found an another issue, you call devkit-disks in ubiquity
<seb128> cjwatson, there is no such command now, it's "udisk"
<didrocks> pitti: so, it was an error on the previous version of the seed, right? The issue was just not triggered because -es has no hypenation package?
<seb128> cjwatson, do you want a bug about that? or just fix it now?
<pitti> argh, sorry about that
<pitti> it's "udisks", not "udisk"
<seb128> ups
<pitti> I checked through the reverse depends, but since it's not a dependency that slipped my attention
<cjwatson> seb128: ah, I can fix that now, no need for a bug
<seb128> cjwatson, thanks
<seb128> cjwatson, it's udisks (plurial as pitti pointed before)
<seb128> I guess you will get it right but just pointing in case ;-)
<pitti> cjwatson: it's a pure rename of the command, CLI syntax stayed the same
<cjwatson> yep - committed
<imran> hello
<rbrunhuber> hi, is there a list of feature freeze exceptions for lucid and more important does it contain php5.3?
<zul> rbrunhuber: im in the process of doing it
<rbrunhuber> zul : The list or the ffe for php5.3?
<zul> rbrunhuber: working on the ffe for php5.3
<rbrunhuber> zul: How likely do you think is it that the ffe is getting approved?
<zul> rbrunhuber: no idea
<qense> Python 2.5 was removed from Lucid?
<nigelb> qense: yes
<qense> nigelb: ok, thanks
<rbrunhuber> zul : Is there anything I can do to help you with the ffe?
<zul> rbrunhuber: nope you just have to be patient
<rbrunhuber> zul : Ok, thanks.
<didrocks> jono: around? I heard you plan to do a new lernid release today? (so that I can push it into universe)
<jibel> mvo, hi, I pushed a fix for the xapian search in synaptic. Could you please review it when you have a minute ?
<jibel> mvo, it fixes relevancy of the results, large performance improvement and add boolean operators.
<mvo> jibel: yes, I merged it locally already, looks fine, but I did not have time for a proper review
<mvo> jibel: the relevance set is now gone, right? I'm not sure of how much practial value it really is/was, but it was meant to improve things when debtags is around
<jibel> mvo, it's still there but user configurable.
<cjwatson> Riddell: did you mean to close bug 526534 in your ubiquity upload?  you used a syntax in the changelog that does not close the bug
<ubottu> Launchpad bug 526534 in ubiquity "kubuntu ubiquity crashes after first page" [Undecided,New] https://launchpad.net/bugs/526534
<jibel> mvo, I mainly dropped the expansion stuff since it's done by xapian.
<Riddell> cjwatson: no, hiding the progress bar is a workaround, I'd like to find the cause after the alpha
<mvo> jibel: aha, ok. I need to have a proper look :) thanks a lot for working on it
<jibel> mvo,  and limit the resultset based on the estimate returned by the search engine.
<cjwatson> Riddell: ok.  and should bug 526456 still be alpha-3?
<ubottu> Launchpad bug 526456 in ubiquity "shutdown does not work" [Undecided,New] https://launchpad.net/bugs/526456
<cjwatson> Riddell: I'll move 526534 to beta-1, then
<Riddell> 526456 can be moved to beta-1 as well
<cjwatson> ok
<cjwatson> done
<jono> didrocks, hey, on a call, but yep, planning on a release :)
<jono> didrocks, will ping you in a bit
<mbudde> jono: I'd like a have a talk with you too :)
<didrocks> jono: cool :)
<jono> mbudde, yeah, sorry for the delay on Lernid - I was traveling last week
<jono> mbudde, I think just a little more visibility on the tweet button and we are good to go
<didrocks> mbudde: do you have a FFe under the hand? do you need some help? :)
<mbudde> didrocks: sorry, haven't started on it yet.
<pitti> seb128: is bug 527098  what you got as well?
<ubottu> Launchpad bug 527098 in ubiquity "ubiquity crash segfault error 4 in libglib-2.0.so.0.2304.0" [Undecided,New] https://launchpad.net/bugs/527098
<pitti> (just spotted from the iso tracker)
<seb128> pitti, yes
<pitti> seb128: is that a dupe then? or did you just debug it on IRC?
<seb128> pitti, I didn't open the bug yet, I've been fighting to get details but the bt is useless
<seb128> and valgrind doesn't work
<seb128> I can't go pass the partitionning stage when running valgrind
<pitti> ok, fine; well, then that is "the" bug report
<seb128> pitti, not quite, I will open one with ubuntu-bug debug infos
<cjwatson> well, "a" bug report
<cjwatson> one with ubuntu-bug will likely be a bit more useful :)
<seb128> I'm just redoing my key and upgrading to .27
<pitti> absolutely
<seb128> I did too many hacking changes to get valgrind running
<pitti> seb128: good luck!
<seb128> like unpack in tmp and ln in usr
<lool> cjwatson: endianess issue > not sure, the initrd was built on real hardware (buildd) and the kernel as well, so I'm not sure why these would suddenly be wrong; did you have a particular explanation in mind?
<cjwatson> just a vague memory that cpio endianness is funny
<cjwatson> I've written assembler code to byte-swap it
<cjwatson> I thought the kernel dealt with that though
<james_w> "Unable to read [...] FileExists (2: No such file or directory)" <- nicely done
<Keybuk> pitti: did you do any investigation into this rsyslog bug?
<pitti> Keybuk: I sketched what the daemon would need to do, but no C implementation
<Keybuk> pitti: but it does that already
<pitti> i. e. seteuid(rsyslog), read()
<Keybuk> it has this whole klogWillRun() thing
<pitti> EPERM -> seteuid(0), keep it
<pitti> works -> setuid(rsyslog) to drop permanently
<Keybuk> so if it gets EPERM, it should just disable klog
<Keybuk> not spin
<pitti> I didn't look at that
<cjwatson> when it happened to me, rsyslog itself didn't seem to be spinning, but the entire rest of the system slowed to a crawl, load average went through the roof, and I had to reboot
<cjwatson> I can't prove it was rsyslog, but it was right after the rsyslog package was upgraded
<cjwatson> I wasn't really in a position to debug it accurately, but I speculated that everything else was getting stuck on full buffers or something
<Keybuk> but this is only klog, the thing that picks up dmesg
 * ogra thought that was a missing kernel feature or was that a different bug ?
<ogra> i definately saw rsyslogd eating 100% CPU when it hit me on armel
<pitti> ogra: it's fixed in current lucid kernel and in linux trunk
<seb128> today is ubiquity bug day
<pitti> but not during upgrade, etc.
<ogra> pitti, right and in the imx51 .31 kernel
<ogra> where we only saw it last week
<pitti> Keybuk: isn't it all just one process in rsyslog?
<Keybuk> pitti: no, rsyslog seems very modulised
<pitti> I only have a single rsyslogd -c4 process here
<pitti> which has fds to /proc/kmsg as well as /var/log/*.log
<Keybuk> sure, but internally it's doing everything through a linked list of structs, etc.
<Keybuk> if it can't open the klog thing, afaict, it will be just missing that module
<Keybuk> which is odd for "CONSUMES 100% CPU ARGH!"
<Keybuk> :p
<pitti> Keybuk: it can certainly open it
<Keybuk> oh, the open() doesn't fail, the read() does?
<pitti> Keybuk: rsyslogd starts as root, opens files, keeps fds, and then drops prifs
<pitti> privs, even
<pitti> and then read() fails with EPERM
<pitti> (see bug description)
<Keybuk> pitti: not entirely sure that's true
<Keybuk> runInputModules() happens *after* the de-rooting
<Keybuk> pitti: the bug description isn't very helpful
<pitti> but if it would drop privs before opening /proc/kmsg it wouldn't work on current lucid at all
<Keybuk> Feb 18 05:04:22 ubuntu kernel: last message repeated 1327321 times
<Keybuk> is about as much detail as it gives :p
<Keybuk> pitti: I don't follow?
<Keybuk> ah, no, I see
<Keybuk> the fact this works is an accidental side-effect of testing to see whether it works :p
 * Keybuk is guessing deroot.patch is yours?
<pitti> Keybuk: right now it seems to open() as root and read() as rsyslog
<pitti> Keybuk: no, I never touched rsyslog
<Keybuk> hmm, the deroot.patch is ubuntu-specific
 * pitti rtfs
<Keybuk> ah, it's mterry's
<Keybuk> pitti: yeah that'd fit
<Keybuk> current lucid - you need to open as root?
<pitti> right
<pitti> -r-------- 1 root root 0 2010-02-24 07:42 /proc/kmsg
 * seb128 files bug #527199 now
<ubottu> Launchpad bug 527199 in ubiquity "ubiquity returned an error after the langpacks installation" [Undecided,New] https://launchpad.net/bugs/527199
<pitti> Keybuk: in previuos kernels, the bug was that not only the open(), but also the read() needed root privs
<pitti> Keybuk: which is why we needed that dd process to shovel it to a fifo
<Keybuk> ok
<Keybuk> so I don't see at all what you thought might work
<pitti> now it behaves as usual, open() obeys file perms, and read() just needs an fd, without checking capabilities
<pitti> Keybuk: so on an older kernel, read() will -EPERM
<Keybuk> ok
<pitti> so one possibility would be to just stop the klog module on that
<Keybuk> yeah, that seems the only possibility here
<pitti> the other would be to temporarily drop privs with seteuid(rsyslog), do the first read() (or peek()), check for -EPERM, and then re-raise or permanently drop privs
<Keybuk> there is no peek()
<pitti> which would work on older kernels as well
<Keybuk> that read() could cause rsyslog to block forever
<pitti> but is more tricky to implement
<Keybuk> if there was no kernel log pending, or the level was set high, then the read() would forever block waiting for data
<pitti> Keybuk: right, it'd require some fcntl with O_NONBLOCK, etc.
<Keybuk> if you read non-blocking, it'd return EAGAIN not EPERM
<pitti> that's where the "more tricky to implement" bit comes in :)
<Keybuk> then suddenly when there was data, EPERM and go back to 100% CPU
<pitti> Keybuk: "EAGAIN not EPERM" > are you sure?
<Keybuk> pitti: yes
<Keybuk> reasonably
<pitti> the kernel capability check was pretty early
<Keybuk> it's certainly *permitted* to return EAGAIN without a cap check
<Keybuk> and we wouldn't want to rely on kernel behaviour here
<pitti> Keybuk: and in the python snippet on bug 515623  I had read() block as well (when running as root)
<ubottu> Launchpad bug 515623 in linux-fsl-imx51 "Do not require CAP_SYS_ADMIN for reading from /proc/kmsg" [Medium,Fix released] https://launchpad.net/bugs/515623
<pitti> but immediately -EPERMing as non-root
<pitti> it didn't block
<pitti> Keybuk: but even if it does, certainly rsyslog currently has blocking calls as well?
<pitti> the blocking shouldn't really matter
<pitti> it just needs a little state machine to remember whether it's the first read
<Keybuk> I don't think we can unload modules looking at this
<Keybuk> once the module is loaded, it looks like it's impossible to unload it
<Keybuk> too many unprotected linked lists
<Keybuk> it'd turn 100% CPU into SIGSEGV
<pitti> ok, let's not do that then
<Keybuk> I wonder what read(0) would do here
<Keybuk> >>> import os
<Keybuk> >>> fd = os.open("/proc/kmsg", os.O_RDONLY)
<Keybuk> >>> os.read(fd, 0)
<Keybuk> ''
<Keybuk> >>> os.seteuid(1000)
<Keybuk> >>> os.read(fd, 0)
<Keybuk> Traceback (most recent call last):
<Keybuk>   File "<stdin>", line 1, in <module>
<Keybuk> OSError: [Errno 1] Operation not permitted
<Keybuk> --
<Keybuk> that seems to work
<Keybuk> whereas
<Keybuk> >>> os.seteuid(0)
<Keybuk> >>> os.read(fd, 0)
<Keybuk> ''
<Keybuk> >>> os.read(fd, 1)
<Keybuk> (still blocking)
<pitti> "If  count is zero, read() returns zero and has no other results. "
<pitti> but if it -EPERMs, that's great
<Keybuk> sure, but it should at least go through the cap check ;)
<pitti> makes it much easier to imiplement
<pitti> bah, tpying is hrad
<Keybuk> ok, so that's the trick then
<Keybuk> do a zero-byte read after opening
<Keybuk> if we get EPERM, then decline
<pitti> s/decline/not drop privs/?
<Keybuk> no, don't think we can do that
<Keybuk> drop privs is WWWWAAAYYY above this code
<Keybuk> just decline to do kernel logging
<Keybuk> this is inside an alternate backend code, inside a module, inside a configurable part of the build tree, etc.
<Keybuk> and for the upgrade case, rsyslog has already dropped privs, it can't undecide ;)
<pitti> fair enough
<pitti> Keybuk: no, we restart rsyslogd on upgrade (that's where the problem comes from in the first place)
<Keybuk> ah ok
<pitti> Keybuk: we could _not_ restart rsyslogd on upgrades with an older kernel running
<pitti> if we want to retain kern.log for upgrade bug reports, or anythign like that
<Keybuk> the point still stands though that it's already decided whether or not to drop privs before it loads modules
<Keybuk> extending the rsyslog module interface just to let modules say "hey, I can't!" seems like a massive patch
<pitti> right, which makes it hard to work with older kernels
<Keybuk> adding a read(0) to the "will the klog module work" function seems much easier
<pitti> so let's not do that
<pitti> that> turn the implementation upside down, I mean
<pitti> Keybuk: oh, it just occurs to me that most apport bugs use dmesg anyway instead of attachign kern.log
<pitti> so that should be fine
<Keybuk> yeah, I just don't see a way of doing what you suggest
<Keybuk> rsyslog just isn't engineered that way
<pitti> Keybuk: at the time when it opens /proc/kmsg, can it reach its option dictionary? it coudl do the read() test there, and unset the "drop privileges" option?
<pitti> but oh well, not having klog when running older kernels doesn't seem like a big issue
<Keybuk> pitti: no, it can't
<cjohnston> mbudde: ping
<mbudde> cjohnston: pong
<Keybuk> /proc/kmsg is opened in the "is this module supported on this system?" function
<Keybuk> it doesn't have config or anything yet
<Keybuk> modules only get that in other functions fwictr
<Keybuk> but again, it doesn't change the fact that main() is already in a different if() statement because it's decided to be de-rooted
<cjohnston> Hey dude.. We had a couple ideas for Lernid if you have a few.. based on some things with ClassBot
<mathiaz> cjohnston: hi - does grub2 support booting from devices part of a raid1 array?
<cjohnston> I dunno
<mathiaz> cjwatson: hi - does grub2 support booting from devices part of a raid1 array?
<mathiaz> cjohnston: sorry - wrong nickname
<cjohnston> I figured.. ;-)
<cjwatson> mathiaz: in general I think so, but there are some known bugs, like it doesn't support the latest mdadm metadata format
<mathiaz> cjwatson: hm - would this be the reason why grub-install would fail?
<mathiaz> cjwatson: http://paste.ubuntu.com/383141/
<cjwatson> err buggadifino
<cjwatson> grub-install --debug might be a bit more informative
<cjwatson> actually, that's weird
<cjwatson> I think you should just install to /dev/md0
<mathiaz> cjwatson: that's from d-i
<cjwatson> did something pick /dev/vda /dev/vdb /dev/vdc for you, or did you enter that yourself?
<mathiaz> cjwatson: let me pull up the preseed
<Keybuk> pitti: http://people.canonical.com/~scott/deroot.patchpatch
<mathiaz> cjwatson: http://people.canonical.com/~mathiaz/raid5.preseed
<Keybuk> pitti: does that smell/look right to you?
<cjwatson> mathiaz: ok, bug on grub-installer I guess, then
<cjwatson> all a bit odd, no idea where it gets /dev/vd[a-c] from there
<cjwatson> a syslog with DEBCONF_DEBUG=developer might help
<mathiaz> cjwatson: ok - I'll retry an installation
<mathiaz> cjwatson: DEBCONF_DEBUG=developer should be set on the command line?
<mathiaz> cjwatson: the *kernel* command line?
<cjwatson> yes
<mathiaz> cjwatson: ok - I'll respun an install a file a bug against grub-installer
<Keybuk> pitti: actually, that won't work :-/
<bryceh> geser, I use scripts to work on bugs in LP.  The scripts parse and use info from the .log and lspci.  So you don't have to provide that info, but it makes it less likely your bug will get attention.
<cjwatson> mathiaz: thanks!
<Keybuk> pitti: I guess seteuid(<arbitrary number>) would upset you?
<pitti> Keybuk: re
<Keybuk> pitti: so there's no way for the klog module to know the uid that syslogd is going to use
<pitti> Keybuk: it shouldn't matter which uid it is, though
<Keybuk> right
<pitti> "nobody" (65534) shoudl be fine
<Keybuk> so is there any random uid I can use that won't upset you? :p
<Keybuk> ok
<seb128> re
<pitti> read() shouldn't check user at all
 * seb128 shakes fist at plymouth which got installed back
<pitti> Keybuk: so the patchpatch code runs under setuid()? or as root?
<Keybuk> pitti: as root
<seb128> and keeps crashing my box on user switch
<pitti> Keybuk: ah, then wrapping into seteuid(65534)/read()/seteuid(0) ought to work
<pitti> Keybuk: 1 is a static uid "daemon", that also seems appropriate
 * pitti checks LSB
<seb128> slangasek, Keybuk: I still get the "user switching lead to a cursor over a text vt taking over my xorg"
<Keybuk> pitti: updated patch
<seb128> slangasek, Keybuk: if you need debug infos or something feel free to ping me
 * seb128 uninstall plymouth
<pitti> Keybuk: right, "daemon" is required, but it doesn't prescribe uid 1; but it shouldn't matter
<Keybuk> yeah, will just use 65534
<pitti> Keybuk: looks okay to me (why don't you just use saved_errno in the LogIntMsg()?)
<Keybuk> pitti: in case there are other reasons it gets used later I guess
<Keybuk> like what that ksyslog() call does
<pitti> ah, it's not a libc function, I see
<pitti> looks fine to me; many thanks!
<Keybuk> right
<Keybuk> now to make quilt update the patch
<Keybuk> quit --please --please --please --ill --do --whatever --you --ask --just --do --what --i --want
<pitti> quilt push foo.patch
<pitti> patch < patchpatch
<pitti> quilt refresh
<pitti> quilt pop -a
<pitti> shoudl work
<pitti> Keybuk: oh, please don't call "quit"! we still need you!
<Keybuk> pitti: doesn't want to work
<Keybuk> quilt refresh didn't do anything
<Laney> quilt import?
<slangasek> seb128: I'm in a holding pattern on plymouth; Keybuk tells me much of this should be getting fixed upstream
<Laney> or quilt push blah; quilt shell; hack; exit; quilt refresh
<pitti> "quilt shell"? that's news to me
<Keybuk> Laney: so, the state I am currently in:
<Keybuk> I have applied the quilt patches
<slangasek> seb128: that particular bug may fall out from some of the other fixes for the boot-time problems everyone is seeing, so I'm not going to dig into it right now
<Keybuk> I have modified the working tree
<pitti> Keybuk: did "quilt push foo.patch" work?
<Keybuk> now how do I get the working tree changes *back into the patch* ?
<Laney> you have to quilt add the files you changed
<Laney> then quilt refresh
<pitti> "quilt refresh" ought to do that
<Laney> (I think)
<pitti> Laney: its' not adding new files
<Keybuk> pitti: No patches in series
<slangasek> Laney: if you've already modified them, it's too late to do a 'quilt add'
<Laney> oh...
<Keybuk> quest rsyslog-4.2.0% quilt refresh
<Keybuk> Patch deroot.patch is unchanged
<seb128> slangasek, ok, fair enough
<Keybuk> FWIW, I did the "quilt add" in advance
<Keybuk> it said
<Keybuk> quest rsyslog-4.2.0% quilt add plugins/imklog/linux.c
<Keybuk> File plugins/imklog/linux.c is already in patch deroot.patch
<pitti> right, if you change an already patched file, you don't need to add it again
<pitti> it's differently complicated than git :)
 * ogra is happy to see that even Keybuk struggles with that user-unfriendlyness 
<Laney> use quilt edit or quilt shell to be safe
<ogra> i get beaten up all the time if i complain about it
<Laney> it's knobbly and annoying
<cjwatson> I don't beat people up for complaining about it - I just find all the alternatives worse in different ways :)
<pitti> what is really (un)funny is to generate 99autoreconf with quilt
<seb128> or not so
<Laney> pitti: that's where you want quilt shell
<ogra> cjwatson, so why dont we have quilt-edit-patch that does all the ugly stuff for me ?
<pitti> indeed, I didn't know about quilt shell, that's handy
<Keybuk> so
<Keybuk> any ideas?
<pitti> Laney: thanks
<cjwatson> nowadays what I do is to work in bzr (doing a temporary bzr init .; bzr add if necessary) and then punt necessary stuff into quilt afterwards
<cjwatson> ogra: mvo has been working on an edit-patch wrapper
<Keybuk> stuff in working tree, patch on top
<Keybuk> how do I make quilt update the patch?
<ogra> cjwatson, oh, you just made my day !
<pitti> Keybuk: quilt push deroot.patch; quilt shell; patch < patchpatch; exit 0 <- perhaps?
<cjwatson> quilt shell does appear to be The Right Thing
<cjwatson> it's basically what people complain about not having
<slangasek> Keybuk: if you did the 'quilt add', then 'quilt refresh' should DTRT; it's not?
<Keybuk> pitti: quilt push says "No patches in series"
<pitti> push/refresh has usually worked for me as well, but perhaps there's some differnet assumption here which I'm not aware of
<pitti> Keybuk: oh, hang on
<Keybuk> slangasek: quilt add says "File plugins/imklog/linux.c is already in patch deroot.patch"
<pitti> Keybuk: export QUILT_PATCHES=debian/patches
<pitti> do you have that?
<cjwatson> lp:~mvo/+junk/edit-patch
<pitti> it defaults to ./patches
<Keybuk> pitti: no?
<pitti> I just set that in my .bashrc
<cjwatson> may be worth using that - it includes all of the tips listed in this channel so far
<pitti> Keybuk: check if it created a ./patches/deroot.patch; you might need to clean that up
<Keybuk> pitti: it didn't create that
<Keybuk> but setting that makes it work
<cjwatson> http://paste.ubuntu.com/383162/ is the quilt bit of it
<Keybuk> \o/
<cjwatson> or was, he's updated it a little since I last looked
<pitti> Keybuk: I have that in my .bashrc, since I only ever use it for debian/patches; everything upstreamish is bzr/git anyway
<cjwatson> I picked up http://paste.ubuntu.com/383163/ in ~/.quiltrc from somewhere, and it generally DTRT
<slangasek> "from somewhere" - that's in /usr/share/doc/quilt/README.source
<slangasek> (which is hardly an obvious place for it)
<cjwatson> seems plausible
<Keybuk> cjwatson: ooh, handy thanks
<cjwatson> for true horror, try slang2
<Keybuk> slangasek: do you want this in the queue/archive?
<cjwatson> dpkg-source v3 *and* dbs
<slangasek> Keybuk: "this"?
<pitti> boggle
<Keybuk> slangasek: rsyslog
<pitti> cjwatson: tar-in-tar?
<cjwatson> yep
<Keybuk> "I can put it anywhere"
<slangasek> Keybuk: sorry, my current context was truncated somewhere in the midst of quilt discussions :-)  yes, please upload rsyslog to the archive
<Keybuk> cjwatson: YADA
<cjwatson> and the change was together with a new upstream release, so there isn't even the excuse of not wanting to rev the .orig.tar.gz
<slangasek> heh
<slangasek> Keybuk: yada.m4
<seb128> slangasek, can I upload a libgnome-keyring fix?
<seb128> slangasek, http://git.gnome.org/browse/libgnome-keyring/commit/?id=5e37e8cc09712fd8cab60e42636f260f23bacd7e
<Keybuk> rsyslog is a bit crazy
<seb128> slangasek, basically right now gnome-keyring doesn't ask the "do you want to create a keyring" if there is none
<Keybuk> it's like someone looked at syslogd and thought "what this *really* needs is a plugin architecture"
<seb128> slangasek, which makes desktopcouch crash because it can't use gnome-keyring
<seb128> slangasek, and probably cause some other issues on new installs
<ogra> seb128, oh, wait
<slangasek> seb128: you can upload, but I'm not thinking this should be cause for a respin
<seb128> ogra: it's in libgnome-keyring, not gnome-keyring, ie not what ftbfs for you
<ogra> bug 527179 should have a gnome-keyring debdiff too
<ubottu> Launchpad bug 527179 in gnome-keyring "FTBFS fix for armel" [Undecided,New] https://launchpad.net/bugs/527179
<slangasek> seb128: once the user upgrades libgnome-keyring after install, they should get correct behavior, yes?
<seb128> slangasek, yes
<ogra> seb128, hmm, i thought they FTBFS both
<seb128> slangasek, I don't think it's worth an alpha respin
<slangasek> seb128: yep - so we should push to the archive but not respin
<seb128> ogra: I will look at this too
<ogra> seb128, thanks
<seb128> slangasek, thanks, I was just checking if upload was ok or would create issues with current respins
<seb128> ogra: np
<ogra> :)
<slangasek> ogra: why hasn't anyone from your team uploaded the gnome-keyring change before now, when the fix has been known for > 24h?
<ogra> slangasek, look when the bug was filed, NCommander has connection issues after he wrote the fix
<ogra> *had
<ccheney> mvo: ping
<ccheney> mvo: are echo's from install scripts somehow supressed in the DpkgTerminalLog.txt?
<slangasek> ogra: bug, yes; but the fix was discussed in #ubuntu-release 24h ago as I said, it's not clear to me why this should have waited for NCommander to file a bug report again
<ogra> slangasek, he said he would provide me a debdiff so i was waiting ... then he vanished from the sufrface of the earth until some hours ago, because i didnt expect that we still could upload and pitti was in the last rounds of respins already i asked him to file the bug so the fix doesnt get lost
<mvo> ccheney: they shouldn't be - do you have a example where it does not work?
<ogra> slacker_nl, i'll do the upload after the freeze unless seb128 has picked it up by then
<ogra> err
<ogra> slangasek, ^^
<slangasek> tseliot: linking bug #526892 to foundations-lucid-boot-experience in place of the corresponding whiteboard item, as long as people are filing bugs we might as well use them :)
<ccheney> mvo: i'm not sure if it is working for openoffice.org-emailmerge.preinst
<ubottu> Launchpad bug 526892 in plymouth "Plymouth uses fallback blue ASCII progress bar; no splash" [Medium,Triaged] https://launchpad.net/bugs/526892
<ccheney> mvo: i am still getting weird errors from users like http://launchpadlibrarian.net/39732587/DpkgTerminalLog.txt
<mvo> ccheney: ok, let me have a look
<mvo> ccheney: what is the bug accociated with it?
<ccheney> bug 527168
<mvo> ccheney: hm, emailmerge - that rings another bell (a history of maintainer script problems :(
<ubottu> Launchpad bug 527168 in openoffice.org "package openoffice.org-emailmerge 1:3.1.1-5ubuntu1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1 (dup-of: 450569)" [Undecided,New] https://launchpad.net/bugs/527168
<ubottu> Launchpad bug 450569 in update-manager "package openoffice.org-emailmerge 1:3.0.1-9ubuntu3.1 failed to install/upgrade: " [Undecided,Confirmed] https://launchpad.net/bugs/450569
<tseliot> slangasek: right ;)
<ccheney> mvo: yea i backported the current preinst fixes and it still does the same type error
<slangasek> ogra: ubiquity was a 2h17 build, gnome-keyring is ~30min; had this been uploaded in parallel at any point, you would have the up-to-date gnome-keyring on the next ISO. <shrug>
<ogra> well ...
<mvo> ccheney: from looking at the current preinst exit 1 is also done after the debconf prompt, no prompting then (in current lucid)
<mvo> ccheney: you will see nothing in the terminal when users use gnome debconf (the default in u-m)
<ccheney> ubuntu-mobile?
<mvo> ccheney: update-manager, sorry
<ccheney> oh ok :)
<ccheney> so we do display debconf messages?
<mvo> ccheney: is there a way to make OOo exit (and save work)? then you could make the default debconf action to send graceful-kill
<mvo> ccheney: yes, via the gnome frontend by default
<ccheney> oh ok
<mvo> unless people upgrade explicitely with non-interactive
<mvo> (which is not default and not something we encourage)
<ccheney> yea in non-interactive case it should be logging though, so i think they are just ignoring the message and filing a bug :-\
<mvo> something like "You are running OOo, we can close it for you"
<mvo> right
<mvo> the default action should therefore (if that is possible) to kill OOo and make it write a recover file. and if people do not like it they can select a different debconf option
<ccheney> mvo: not sure if there is a way to cause it to shutdown
<mvo> (and complain)
<mvo> kill -9 :P
<mvo> (not really)
<ccheney> well if we kill it leaves the lockfile which i think it might be using to do the recover bit
<mvo> you could of course simply add a "echo user closed, but OOo still running" and create a bug pattern that auto-closes these reports
<ccheney> yea
<ccheney> i think i will add that
<mvo> I personally think the default for any debconf question during a upgrade should be "continue in some sensible way"
<mvo> and not "fail"
<mvo> but I know that its not always possible (especially for server packages)
<jml> is there a schedule for lucid+1 somewhere?
<ccheney> yea :-\
<jml> we're looking at shifting Twisted to releasing every three months and we want to be in sync w/ Ubuntu
<jml> (we missed the feature freeze for lucid, unfortunately)
<ccheney> jml: well the release date is very likely to be Oct 28, but it doesn't seem to have a release schedule yet
<jml> ccheney, feature freeze is what I care about the most, I guess.
<jml> ccheney, maybe I can make a guess based on karmic's schedule
<ccheney> jml: yea probably will be about the same as jaunty/karmic
<ccheney> hmm did the wiki go down?
<ccheney> my ff is just sitting waiting for response
<ccheney> working now, hmm
<ccheney> jml: guesstimate would be final freeze on aug 26
<jml> ccheney, ok, thanks.
<tkamppeter> pitti, hi
<mpt_> asac, are you able to answer Joanmarie's question in <http://launchpad.net/bugs/433104>: "what is the cut-off point for Ubuntu including a newer release of WebKitGtk?"
<ubottu> Launchpad bug 433104 in software-center "Ubuntu Software Center "Get Software" screen contents not read in Orca" [High,Incomplete]
<asac> mpt_: the cut off point was FF ... everything on top needs careful review and approval
<asac> is there anything upstream yet for that?
<asac> answered in bug
<mpt_> asac, ok, thanks for the answer
<asac> np
<alex-weej> is there some reason rpm/alien is now a dependency of my karmic install? or is it some dodgy package upgrade i have?
<slangasek> alex-weej: rpm is a dependency of lsb-core, so if you have any of the lsb support installed that would do it
<alex-weej> my karmic install is many months old -- why is it being brought in now?
<slangasek> dunno, would have to see an upgrade log to tell you
<mpt> asac, incidentally, it's kind of weird that <https://launchpad.net/webkit> (a) talks about WebKit being an "attempt" and (b) has, as its latest download, a Firefox variant
<asac> mpt: i am hopefully not the owner of the webkit launchpad project ;) ... am i?
<mpt> asac, true, but it also shows up on https://launchpad.net/ubuntu/+source/webkit
<cjwatson> jml: yes, add a year to karmic's schedule and you'll be within a week or two of m's
<alex-weej> question: i'm very interested in doing some system testing, especially regression testing between releases. is there a formal team that i can join?
<alex-weej> ideally i want to make sure a wide range of macs are included in testing
<alex-weej> as many of my friends are quite upset with regressions etc.
<ion> Dunno if this idea is insane, but anyhoo, bug #527292. :-)
<ubottu> Launchpad bug 527292 in ubuntu-meta "Recommend lsb-invalid-mta to satisfy other packagesâ MTA recommendation by default" [Undecided,New] https://launchpad.net/bugs/527292
<jcole> is it possible to have the "guest" session start in an xnest by default?
<slangasek> alex-weej: I think that's in scope for https://wiki.ubuntu.com/Testing
<alex-weej> is there an official set of test hardware that canonical uses btw?
<slangasek> ion: I'm kinda leaning toward 'insane', yes; sendmail is specified in the LSB with the expectation that *it can be used to send mail*, if it should be made optional then that should be done in the LSB instead of bodging it in the distro
 * jcole pokes at files in gdm-guest-session
<ion> slangasek: True. But on that basis, shouldnât the package itself have never been added to Ubuntu in the first place?
<slangasek> ion: ugh, that's an Ubuntu-specific add-on?
<slangasek> pitti: you seem to have sponsored this; why do you think this is reasonable?
<ion> slangasek: It seems to be, judging from the packageâs changelog.
<ion> FWIW, iâm happy a package like it appeared in Ubuntu. Things no longer want me to install a MTA to my desktop boxes. :-P
<slangasek> ion: install ssmtp instead of a full MTA?
<ion> slangasek: It expects me to have constant access to a certain forwarder. Doesnât really work for my laptop. I rather just have no sendmail or a have sendmail binary that just fails.
<slangasek> packages depend on an mta when they rely on being able to use /usr/sbin/sendmail to deliver messages to the system admin.  I care not one whit if that gets delivered to a local mailbox, or sent over SMTP, or delivered over *twitter* if that's what you want, but deliberately dropping them on the floor is wrong
<ion> I didnât mean packages that depend on an MTA, but packages that recommend one. I want my apt-listchanges just to show the changes, not mail them. I wouldnât need mdadmâs email functionality on a hypothetical desktop box with RAID.
<lamalex> Does anyone know how to debug debootstrap/cowbuilder/pbuilder?
<lamalex> it's dying with a very generic error
<lamalex> http://paste2.org/p/687241
<jcole> lamalex: are you running it with sudo
<lamalex> jcole: no, but I don't need to when I do cowbuilder-dist <ubuntu release> create
<lamalex> it works fine then
<lamalex> but I'm trying to set up cowbuilder to work off of a different distro
<geser> cowbuilder-dist might call cowbuilder with sudo (check the source)
<geser> and you need to "sudo cowbuilder" if you don't use "cowbuilder-dist"
<lamalex> geser: it does
<lamalex> i should have said that,sorry :P
<lamalex> i think the problem is an incomplete mirror
<qense> I'm working on giving Guake AppIndicator support and I would like to include something like C's preprocessors in the code to allow people to not use AppIndicator. Does anyone know how to do such a thing? The project is using a makefile and not something like python-distutils.
<seb128> qense, the code is python?
<qense> seb128: yes, so preprocessors won't do the trick
<seb128> qense, well at runtime should work then
<seb128> look at jockey
<seb128> just try: the import
<seb128> no?
<qense> seb128: thank you! I'll have a look at jockey.
<Caesar> What package provides the system status info in /etc/motd on Ubuntu Server?
<jpds> Caesar: update-motd?
<Caesar> jpds: thanks
<ccheney> update-motd claims that libpam-modules does it now
<jcole> is there an irc room for the ubiquity ubuntu installer
<lifeless> here usually, I think
<stgraber> jcole: ubuntu-installer
<jcole> perfect, thanks
#ubuntu-devel 2010-02-25
<quidnunc> Is it possible to have a package as of now that has build-depends on package versions not available in the repositories?
<crimsun> meaning "may I upload a source package that build-depends on packages that no longer exist?"  No.
<quidnunc> crimsun: No, meaning does it make sense that a package that was uploaded build-depends on a package version that was not?
<crimsun> quidnunc: if the source package in question hasn't been rebuilt in quite some time, yes, it's quite possible.
<quidnunc> crimsun: THanks
<jono> can anyone tell me where lernid is in the build queue?
<superm1> jono, it appears to be in the NEW queue: https://edge.launchpad.net/ubuntu/lucid/+queue
<superm1> an archive admin needs to release it
<jono> superm1, any archive admins around?
<jono> ideally we need it available for the kick off of some python sessions tomorrow
<pwnguin> by my math its like 5am in the uk
<lifeless> pwnguin: fortunately they archive admins aren't UK people
<lifeless> pwnguin: only some are.
<persia> I didn't think any of today's archive admins were (for various values of "Today")
<pwnguin> ive no clue who runs the archive
<lifeless> persia: james_w
<persia> lifeless: Is it not Thursday?
<persia> Well, I suppose it's also Wednesday
<persia> But it's *definitely* not Monday anymore.
<lifeless> persia: I wasn't aware that they lost access on non rota days
<persia> Personally, I think it's Wednesday in TX and Thursday in NSW, if one is hunting an archive admin right now.
<persia> lifeless: Well, no, but they tend to make themselves more available on rota days.
<jono> there must be a list archive admins somewhere
<cody-somerville> ~ubuntu-archive
<jussi01> https://edge.launchpad.net/~ubuntu-archive
<jussi01> heh
<jono> StevenK, around?
 * StevenK prods jono
<jono> StevenK, :)
<jono> Lernid is in NEW - any chance you could move it along?
<jono> we need it for opp dev week starting tomorrow
<StevenK> Maybe. How much beer is on offer?
<jono> StevenK, two pints
 * persia prefers https://wiki.ubuntu.com/ArchiveAdministration because it helps ping the right folk on the right days
<jono> thanks persia
<StevenK> jono: Accepted.
<persia> jono: Well, you've already spent the quart, so it doesn't matter so much to you, but maybe for the next person who needs one :)
<jono> thanks StevenK!
<jono> :)
<jono> sounds awesome, good to know, persia :)
<lucent> Hi, can someone walk me through the process of submitting a patch that fixes a bug?  I know which lines of code I want to change in the package "lirc" but I don't know how to generate a suitable patch against the package
<persia> lucent: Do you use bzr?
<lucent> persia: I do not
<persia> https://wiki.ubuntu.com/Bugs/HowToFix
<lucent> okay I will read
<persia> There used to be simpler instructions there :/
<persia> https://wiki.ubuntu.com/Bugs/HowToFix?action=recall&rev=16
<lucent> persia: I get yelled at when I submit plain diff -uprN patches
<lucent> it is kind of bewildering to me but I will try to learn more about this
<persia> Who yelled at you?
<persia> Which bug?
<persia> That should *never* happen.
<persia> The process for submitting patches is as follows:
<persia> A) If you use bzr, branch the package, change it, commit, push a branch, request a merge
<persia> B) If you don't use bzr, attach a perfectly normal patch to the bug, make sure the "this is a patch" checkbox is checked.
<persia> That's it.
<lucent> oh, before I heard this I thought I was doing something wrong
<persia> Anything else is just extra messiness because someone thinks you're trying to learn how to be an Ubuntu Developer.
<persia> No, you weren't doing anything wrong.
<persia> We specifically have the Ubuntu Reviewers team (which more people should join! ) which reviews the patches.
<lucent> thank you :)
<persia> Not all of them get uploaded right away.  Sometimes they get pushed upstream first, etc.
<persia> Submitting a debdiff with all the correct tweaks to integrate to packaging, etc. makes it *harder* to get it upstream.
<lucent> unrelated second question, there's no cdrtools in Ubuntu... is cdrtools a "not done here" for Ubuntu Karmic?
<persia> (although it's what we expect from developers who can't upload a given package)
 * persia has no idea
<lucent> I don't want to step on toes if I branch the existing PPA and fine tune it to work with Karmic
<lucent> a little Google research had vague references to Mark Shuttleworth rumored to be saying no... it was all kind of unconfirmed
<persia> Nothing you do in a PPA affects Ubuntu.
<tumbleweed> lucent: however, debian and ubuntu both use cdrkit, not cdrtools
<lucent> I am aware of that, in fact am helping to test code for the libburn and libcdio projects (yet a third iteration of burning software)
<lucent> the devels for libburn and libcdio refer to cdrecord as the baseline
<tumbleweed> lucent: aah. yes, go wild in your ppa (never heard of libcdio, looks into it...)
<lucent> the GNU project supports libcdio "in name only" (I'm sure you will be familiar with that concept?)
<lucent> I think there's maybe 5 developers between the two projects libcdio and libburn
<lucent> it is GPL license and actively developed
<lucent> I guess the rumor was that cdrkit development is stalled
<pitti> Good morning
<rainct_> Hey
<pitti> slangasek: invalid-mta> well, FSVO "reasonable"; this was discussed to death with the LSB folks, and they are not willing to remove the sendmail requirement; so to finally fix pulling in postfix with every LSB package you isntall, this seems like a lesser evil to me; and it won't change a thing if you already have an MTA installed
<pitti> there simply is no frigging way we can sensibly install a real MTA without any questions
<lamont> pitti: +1
<pitti> nor is it sensible to install MTAs on nowaday's desktop boxes in teh first place
<pitti> ... (says one who has running a local postfix, but with nicely configured SSL certificates for relaying to his server)
<pitti> and ssmtp is even less useful; you don't have an MTA to relay to by default
<dholbach> good morning
<sladen> ccheney: can you go through the dups for bug #450569 and friends and demerge all the ones you just demerged.  The Pre-Depends: loop is _not_ related to some random process running in the background.  It should be possible to separate them again based on package number.  1:3.1.1-5ubuntu1  is where the Pre-Depends loop is (current), and 1:3.0.1 is where the process hang was (six months ago)
<ubottu> Launchpad bug 450569 in docvert "package openoffice.org-emailmerge 1:3.0.1-9ubuntu3.1 failed to install/upgrade: " [Undecided,In progress] https://launchpad.net/bugs/450569
<csurbhi> good morning #kernel
<dholbach> csurbhi: this is  #ubuntu-devel ! :-)
<dholbach> hehe
<Noisi> hi there! i try to cross compile with arm-linux-gcc a sqlclient to arm720t and i need lib mysqlclient. Must i compile it from soucre with arm-linux-gcc?  it would give me great pleasure for some tip.
<slangasek> pitti: we could have a package which provides m-t-a, and interfaces with UbuntuOne to send all your root mail there or something :P
<dholbach> hey slangasek! :)
 * dholbach hugs slangasek!
<slangasek> dholbach: heyo. :)
<persia> Would it be terribly difficult to have an m-t-a that just delivered to /var/spool and had a config widget that let you set up the equivalent of postfix's sasl _passed and sender_relay maps to real smarthosts?
<persia> (and by default forward *all* mail to the first configured user on the machine)
<slangasek> persia: AIUI one of the concerns with that is that on a modern desktop, the user will never know they even have local mail in that case
<persia> slangasek: We could ship the mail clients with a default spool configuration?
<slangasek> maybe
<persia> Personally, I find lots of stuff I try to do ends up complaining that I don't have mail set up.
<slangasek> or we could turn every mail into a notification
<slangasek> :-)
<persia> As a result, I inevitably set up postfix without much confidence.
<persia> But I know I don't need that.
<slangasek> mvo: does https://wiki.ubuntu.com/LucidLynx/TechnicalOverview#Issue%20when%20upgrading%20from%20Lucid%20Alpha%202 seem like something you would want update-manager to do for us, and would you have time to implement it for Lucid?
<slangasek> TheMuso: do you know if anyone is planning to test UbuntuStudio so it can be included in alpha 3?
<sivang> Hi all
<sivang> why is libapache2-mod-wsgi in universe and not in main ?
<persia> sivang: Nothing in main either Depends or Build-Depends on it.
<sivang> persia: this is going to be the next gen web gateway technology
<sivang> persia: and is already used int he python web world
<sivang> persia: ubuntu being a python in mind distro, should get it into main
<sivang> persia: I can take care of it's maintainerhip if that's required
<persia> sivang: It's not about maintenance.  It's about dependencies.  If you think it's essential, get something to depend on it.
<sivang> persia: what if I wanna use it under an ubuntu machine? do I need to switch to fedora where it is sort of officially supported?
<sivang> persia: what's the dependency argument has to do with an emerging web technology
<sivang> :)
<persia> sivang: How isn't it supported in Ubuntu?  It's present, isn't it?
<mvo> slangasek: yes, I can do that
<sivang> persia: in univeser
<sivang> mvo !!
<sivang> mvo: How have you been you family man?
<sivang> :)
<Daviey> persia: will libapache2-mod-wsgi get 5 years LTS support in universe?
<sivang> Daviey++++++
<mvo> hey sivang - good, good (les sleep than before)
<persia> Daviey: Depends on people being interested, but there's nothing blocking it.
<sivang> mvo: a child ?
<sivang> persia: people interested == python web community worldwide
<sivang> persia: Is that enough? ;)
<persia> sivang: Quite likely, as long as they care to keep the version we ship in Lucid in shape, and some people watch the status in Ubuntu.
<persia> sivang: But that's completely irrelevant to the universe/main distinction (which we're overdue abolishing anyway).
<sivang> persia: whom do I need to talk to or do I need to create a wiki page for the promotion ?
<sivang> pitti: ^^^
<persia> sivang: What's your goal?  Just having it work and getting regular security updates?
<sivang> MainInclusionReport was the last time I checked
<sivang> persia: security
<sivang> persia: my only concern
<persia> sivang: OK.  and are you willing to track the security status of it in Lucid and make sure any required patches are tested and made available in a timely manner?
<sivang> persia: "I do." :)
<sivang> but I need to get my membership fixed again
<Daviey> sivang: Whilt it shouldn't make any difference, there is certainly a difference in love packages in main recieve compared to universe.  If you want to try and get it promoted, I would add it as a ubuntu-server agenda item for the next meeting.  If you get the support of -server, then i think it's more likely.
<sivang> Hmmm... red tape.....
<sivang> ;
<persia> sivang: Great.  So file "security" bugs whenever one is needed with the tested patches and ask folk in #ubuntu-hardened if they aren't getting uploaded in a timely manner.
<sivang> ;)
<persia> Then you have a supported solution.
<persia> Only bother with the MIR if you need it as a dependency or build-dependency of something on the shipping images.
<sivang> persia: not yet, that will come, but not yet.
<slangasek> Daviey: sure, because any time anyone loves a package in universe they push to have it in main, which isn't exactly scalable. :)
<sivang> slangasek: true
<sivang> but if I use ot now
<sivang> now
<sivang> who gurantees it won't screw my server?
<persia> Daviey: There really isn't any difference based on component.  I've found *lots* of packages in main that were completely disfunctional and ignored (and tossed them out of main).  The differnence is just that more people tend to care about more of the packages in main.
<persia> sivang: You?
<persia> sivang: and anyone you recruit to help you (Daviey seems like a good candidate)
<Daviey> persia: i entirely agree, but the server team seems to think diffently - based on posts such as http://ubuntumathiaz.wordpress.com/2009/11/30/rfp-packages-to-promote-to-main-and-demote-to-universe-for-lucid-lynx-lts/
<persia> There's no warranty for the vast majority of software in Ubuntu (even in main), and most of it has a waiver for fitness for any particular purpose.  That it works is because people care about it and because we trust each other, rather than because of any contractual arrangement.
<persia> Daviey: Some members of the server team are sadly benighted about the meaning of "support".  Just do it :)
<Daviey> heh
<sivang> persia: I hope no one of my customers ever hear that when I seel them Ubuntu Servers:)
<sivang> sell
<sivang> "sell" => offer them to use ubuntu server on their VDS
<sivang> when they hear "no warranty" they run out and cry "RHEL, RHEL!!!"
<sivang> ;)
<sivang> anyway, to go back to a more fruitful discussion and less trolling :)
<sivang> so, just file bugs and make sure someone cares aboiut it?
<sivang> or cares "enough" about it
<sivang> ?
<persia> sivang: Go read the licenses of RHEL software.  It's the same software under the same licenses and comes with the same specific disclaimer of usefulness.
<persia> That doesn't mean it isn't useful, just that nobody guarantees it.  If you, completely separately, decide to enter into a contract with a customer to provide support or warranty for some return, that's between you and your customer.
<sivang> persia: sure, I try to explain that to them, however, you say that even if a [pacakge in main that's not gurantee for security, I don't think this is the right statement
<sivang> one of the first tasks
<sladen> charge them $10,000 and provide the guarantee yourself
<sivang> I got from pitti as a mentor, was to do security review for warty
<sivang> for everything we importedfrom debian
<persia> OK.  Packages in main only get security support if someone either identifies the problem in a clear way to Ubuntu or if a CVE is published.
<sivang> persia: that's what I want, is it so hard to achive ?
<persia> That's nice, but it's certainly not anything like a guarantee.
<sivang> persia: it is *something*
<sivang> better than *nothing* inuniverse
<sivang> ahh I need a real latpo
<sivang> aptop
<sivang> right, I rest my case:)
<sivang> this kbd is the worst ever
<persia> sivang: Like I said before, just do it, and provide the guarantee.  You're effectively asking someone else to do something so that you can get paid.  I'm unsure why they would want to do that.
<sivang> no, I'm asking this so I could promote Ubuntu as a wsgi hosting platform
<sivang> irrelavant to my pay
<sivang> seriously
<sivang> I've done so much for ubuntu without seeing a dime, so I don't think this request is out of place.
<sivang> I am promoting ubuntu regardless of my commercial itnerest in it.
<sivang> oh, and I've contributed with will :-)
<persia> sivang: I think you miss my essential point.  If you want it to be supported, support it.  That's all it takes.
<persia> If you want someone else to support it, then find some way to incentivise them.
<sivang> so I don't feel like ubuntu is owning me something, to make straight
<sivang> persia: okay, noted.
<sivang> persia: I'll start with it and then find someone else to care for it.
<sladen> sivang: your contribution _to_ Ubuntu would be _the support_ of $package
<sivang> sladen: right, what's the comitte these days to get main upload right for a specific package?
<persia> sivang: I'd love to see the package well maintained.  I think you're perfectly capable of doing it.  I know that the universe/main distinction is meaningless and that we've been working to abolish it for the last two years.
<sladen> sivang: either provided directly by yourself, or through pursuading somebody else to take on that support
<sivang> sladen: you have main upload rights?
<sivang> sladen: would you sponsor me?
<sladen> sivang: I'd sponsor a sane-looking patch to a package that was already there
<persia> sivang: The security team would *love* to sponsor all your security updates.  They are constantly looking for new people to submit tested patches.
<sivang> okay cool
<sladen> sivang: but I wouldn't _gaurantee_ to do so ('gaurantee' is a very strong word)
<sivang> I'll start playing with mod-wsgi
<sivang> sladen: I know, but you still have main upload rights yes?
<sladen> sivang: last time I checked, yes
<sivang> sladen: so once it's tested and working, we're good to go?
<sladen> sivang: whether I use them as much as I should, is another question
<sivang> sladen: good, cause I Have no interest in going throught the red tape for main right
<sivang> sladen: :-)
<Daviey> sladen: I'm not entirely sure gaurantee is a word :)
<sivang> Daviey: haha
<sivang> in Israel surely it is not.
<sivang> NOTHING is guranteed here.
<sivang> ;)
<sivang> what's the right omitte to file a universe upload rigths again?
<Daviey> sivang: If you care about the package as passionately as you seem to.. Just unoffically taking on burden of checking for security and bugs, submitting patches (either plain or debdiff), is enough to allow someone else to sponsor the package
<Daviey> sivang: This means that you can personally guarantee support, and everyone wins
<persia> And there's only a few people who can push to -security anyway (not everyone with main upload rights can do this).
<ogra> lool, do you happen to have a working qemu lucid atm ? i cant get iso-codes to unpack here running rootstock, i wonder if you can in an interactive setup
<lool> ogra: You mean apt-get install iso-codes?
<ogra> yeah
<ogra> rootstok hangs forever in
<ogra> Selecting previously deselected package iso-codes.
<ogra> Unpacking iso-codes (from .../iso-codes_3.12.1-1_all.deb) ...
<ogra> and i wonder if it has to do with the bz2 tarball or the 3.0 source format, though i would expect more packages to be in that format if i install the ubuntu-netbook task
<cjwatson> neither the source tarball compression method nor the 3.0 source format can possibly have anything to do with whether the binary package installs successfully
<lool> ogra: it works in qemu-system-arm for me
<persia> Neither the source tarball nor the source format should have any impact on binary installation.
<cjwatson> snap
<persia> Indeed.
<ogra> lool, hmm, k, then it must be my VM setup i guess :/
<lool> Schnipschnapschnappy das kleine Krokodil
<ogra> LOL
<lool> ogra: it's you again and your bad karma
<ogra> yeah, apparently :/
<lool> I'll try in qemu-arm-static too
 * ogra needs to do something about that karma thing
<lool> works with syscall emulation as well
<ogra> cjwatson, well, repackaging in 3.0 was the only significant difference i found to the karmic package (which unpacks fine) ... apart from several new upstream releases
<ogra> but i think lool has just proven it must be my VM ... and since we use the same kernel i suspect it can only be my setup ... either i'm missing something in the rootfs or in the qemu call
<persia> ogra: The key is that nothing in how the source package is packed or unpacked *can* affect the binary package, which is always constructed in accordance with debian/rules.
<ogra> lool, do you use MALLOC_CHECK_=0 in yours ?
<ogra> persia, indeed ... but as i said, it was the only significant changelog entry i found
<lool> ogra: no
<ogra> aha
<ogra> i should probably try without then
 * ogra does that ... we'll see in 1h :)
<lool> But MALLOC_CHECK_=0 when the source package is built is not going to affect the binary packages!
<ogra> i'm not building anything :)
<ogra> i'm getting stuck installing a binary
<lool> I know, but I'm hungry, my jokes get worse every minute
<ogra> ah, french humor :) get some lunch !
<lool> If the chicken isn't ready in 10 minutes it's going to be awful
<persia> Can anyone suggest a better fragment than `while [ ! -f /var/lib/partman/persia ]; do sleep 5; done; tail -f /var/lib/partman/persia` to start viewing a low-volume file once it appears?  I'm sure there's some cool fsnotify thing.
<lifeless> is there a timeout in the new lvm, for drive probing?
<persia> I haven't noticed one (and needed to press 'C' once to get the boot to finish when swap didn't want to come up)
<ion> persia: tail -F /var/lib/partman/persia
<lifeless> persia: hmm, I would quite like it to stop and drop me into busybox ;)
<persia> ion: Nifty.  Is that smart, or does it poll like my snippet?
<ion> It probably just polls.
<ion> Yeah, it has an open-sleep loop, just straced it.
<persia> lifeless: What letters show up while it's waiting?  Press them one at a time to see if you get a useful result.  I *think* C is Cancel, but I'm kinda guessing (there's no docs I've found)
<soren> slangasek: I have a user who says that since upstart 0.6.3-11 landed, his ssh and apache servers don't start on boot. Does this sound familiar?
<lifeless> persia: letters?
<persia> ion: I'll probably use that next time because it's less typing, but it ought be done the smart way.
<ion> Yeah
<lifeless> persia: I'm talking about 'probing all drives, please pe patient this may take a while\n'
<Keybuk> persia: C is cancel fsck
<persia> lifeless: So, you should have something like "Waiting for foo [CSM]" and that seems to mean you can press 'C' , 'S', or 'M' for different (undocumetned) effects.
<slangasek> soren: yes, his /etc/network/interfaces is broken and he should help verify the SRU for bug #497299
<ubottu> Launchpad bug 497299 in ifupdown "upstart not starting init-scripts (event net-device-up IFACE=lo missing)" [High,Fix committed] https://launchpad.net/bugs/497299
<Keybuk> persia: only [SM] for that one ;-)
<ion> lifeless: mountall just stopping at that request instead of continuing until device appears or user hits a key is a known bug and will be fixed.
<Keybuk> S = Skip this filesystem (pretend it's marked nowait in fstab)
<Keybuk> M = Give me maintenance shell
<lifeless> persia: no prompt at all
<lifeless> ion: thanks
<Keybuk> I = Ignore fsck errors (and try to mount anyway)
<lifeless> Keybuk: what needs to be installed to get that prompt?
<Keybuk> F = Run fsck -y (after an fsck failure)
<Keybuk> lifeless: nothing
<Keybuk> lifeless: just mountall and plymouth
<lifeless> hmm,  I suspect plymouth is missing.
<ogra> you should get a message about that on boot
<lifeless> libplymouth is installed
<ion> A couple of small functions just need to be added to plymouth to make it integrate to other main loop than its own, and then mountall needs to be changed to be asynchronous with the boredom timeout query.
<ogra> mountall will complain it cant connect to plymouth
<persia> Keybuk: Thanks for the summary of options.  Is this already in /usr/share/doc/ somewhere, or would it be useful for me to put it in a text file and add it somewhere (and to which package?)
<Keybuk> persia: no, and no
<Keybuk> the fact you just see letters is very temporary
<Keybuk> the idea is that the new theme will have a much nicer message
<Keybuk> e.g. say "Press C to cancel" etc.
<persia> Ah, cool.  Nevermind then.
<slangasek> Keybuk: aren't those strings verbatim from mountall?  You intend the theme to fix them up?
<lifeless> I don't think anything in the kernel|initramfs dependency set drags in plythmouth itself
<Keybuk> slangasek: the new theme will require changing the messages, yeah
<slangasek> lifeless: ubuntu-standard :P
<lifeless> slangasek: perhaps,  but you really don't want to know what I'm up to :P
<slangasek> Keybuk: a little unnerving that this is considered tied to a theme
<slangasek> (and yes, I've been in the plymouth theme code)
<soren> slangasek: Great, thanks for the hint. I'll point him to that.
<Keybuk> slangasek: we need the ability to put messages in different places on the screen
<Keybuk> and also resolve the issues where the "Fsck in progress" messages are built into the theme, instead of from mountall
<Keybuk> etc.
<slangasek> ah
<Keybuk> and as ion says, mountall instead of just going into a "reading from plymouth" loop for each key press needs to work asynchronously
<Keybuk> so if the volume arrives while waiting, it cancels the prompt and carries on with its work
<persia> Keybuk: Is there a way that one can provide hints to say "don't wait on this"?  I never want to wait on swap for boot (although I'd like it mounted at some point).
<Keybuk> persia: nobootwait in fstab is the hint
<persia> Nifty.  I thought I'd get pointed at some code that needed fixing.  Thanks!
<lifeless> slangasek: so, the new lvm doesn't want to find stuff at boot
<lifeless> slangasek: any pointers before I start climbing through hoops?
<slangasek> lifeless: WFM, worked for kees
<slangasek> I disavow all knowledge beyond that :-)
<lifeless> hah
<cjwatson> dpm: re bug 518718, bug 527052 implies that it should be just "Ubuntu Netbook", not "... Edition"?  that's what current cdimage code says too
<ubottu> Launchpad bug 518718 in ubuntu-translations "Change "Ubuntu Netbook Remix" messages to "Ubuntu Netbook Edition"" [Low,In progress] https://launchpad.net/bugs/518718
<ubottu> Launchpad bug 527052 in gfxboot-theme-ubuntu "live cd bootscreen has untranslated "Try Ubuntu * without installing" and "Install Ubuntu *"" [Undecided,New] https://launchpad.net/bugs/527052
<lifeless> slangasek: FYI - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488332
<ubottu> Debian bug 488332 in lvm2 "LVM sysfs_scan with newer 2.6.x kernels needs deprecated sysfs layout" [Normal,Open]
<lifeless> appears to be it; I haven't dug deep enough to know if there is more under the hood, but I can get pvscan happy with the sysfs setting
<slangasek> lifeless: ummm, I definitely don't have CONFIG_SYSFS_DEPRECATED_V2 set here (stock Lucid kernel), and WFM
<lifeless> slangasek: this is stock lucid kernel too
<cjwatson> dpm: shall I just change the netbook strings in the obvious way here?
<cjwatson> dpm: since it involves removing a word, I can probably just update all the translations myself
<cjwatson> or most of them anyway
<slangasek> cjwatson: assuming you know the correct genitive->nominative conversion? :)
<lifeless> slangasek: should mountall depend on plymouth?
<cjwatson> slangasek: oh, I can leave those fuzzy
<slangasek> lifeless: I defer to Keybuk; mountall /works/ without plymouth, it just doesn't /talk/ to you
<tjaalton> how is it supposet to work on a serial terminal?
<tjaalton> -sed
<Keybuk> lifeless: udev doesn't work with deprecated sysfs layout anymore
<tjaalton> I find it strange that a server install pulls plymouth..
<Keybuk> so you can't have it ;)
<lifeless> Keybuk: Oh, I don't want it.
<Keybuk> tjaalton: why?  we still need something to arbitrate password prompts and suchlike during boot
<seb128> cjwatson, is debug-ubiquity supposed to send you in install only mode rather than livecd desktop?
<lifeless> I suspect that lvm in the initramfs is old, but I don't know why yet.
<cjwatson> seb128: debug-ubiquity is orthogonal to the try/install mode
<lifeless> Keybuk: I'm not quite back into the system to fiddle; root is mounted but I suspect upstart is in lala land
<tjaalton> Keybuk: no way to do that without plymouth?
<cjwatson> oh, heh, maybe it isn't
<Keybuk> tjaalton: plymouth works fine for doing that - there's no reason to invent a different way
<seb128> cjwatson, weird, I picked livecd desktop and got installer only
<seb128> cjwatson, I was wondering if that's due to me addign debug-ubiquity to the option, will try without
<cjwatson> seb128: yeah, bug I think, fixing now
<seb128> cjwatson, thanks
<cjwatson> well, that said
<tjaalton> Keybuk: ok then. as long as it works on a serial terminal as well ;)
<cjwatson> seb128: I think actually maybe it does make sense - the thing is that if you don't use install-only mode, then debug-ubiquity is a no-op
<cjwatson> the way you get debug mode in "try ubuntu" mode is to run 'ubiquity -d' in a terminal
<seb128> cjwatson, would it make sense to have debug-ubiquity in the f6 menu for unstable versions?
<cjwatson> so I think I'll leave it as it is and retroactively declare that it's meant to be that way ;)
<Keybuk> tjaalton: it does
<seb128> cjwatson, ok, makes sense
<cjwatson> seb128: hmm, the problem with debug-ubiquity is that it exposes your password in the logs
<cjwatson> admittedly it does tell you that it's doing so, but still, I'd prefer it to just be when we ask for it
<seb128> ok
<cjwatson> unfortunately the only way to fix that is by some really messy hacking in debconf that made both joeyh and I feel ill
<seb128> cjwatson, I don't get the crash in glib with today image btw, will make harder to report a bug about it, I delayed to have a version where the partition setup was working and now it's working all the way...
<cjwatson> how annoying
<seb128> yes
<cjwatson> let's hope (?) it recurs
<seb128> I will try again with yesterday's image later
<seb128> it was not an image recording issue, I did write the key several times to clean hacks I did on the stick
<cjwatson> seb128: yeah, I doubted it was
<ogra> lool, ha ! seems qemu doesnt like the use of a swapfile
<ogra> lool, running rootstock with --noswap makes iso-codes install
<ogra> (that wasnt an issue in karmic though)
<ogra> Riddell, in qt4-x11 4:4.6.0-1ubuntu2 you set -arch armv6, do you remember the reason for that ?
<Riddell> I did?
<Riddell> where?
<cjwatson> ogra: I do, it was because there was a specific armv6 implementation of some bits
<cjwatson> the default was arm, and wasn't good for armv7
<ogra> do you remember if it was assembler ?
<cjwatson> the armv6 code doesn't handle multicore, but is otherwise much better than what was there before
<cjwatson> yes
<ogra> ah, k, thanks a lot
<seb128> bah
<seb128> I almost success to install a3 now
<seb128> it's not moving from the "detecting other systems" now
<seb128> ie grub install
 * seb128 wonders if I should just power down the box
<seb128> cjwatson, anything useful I can get from an installer only install blocking on grub os detection?
<seb128> cjwatson, it's at 93% looking for other os for a while now
<cjwatson> syslog, ps axf maybe
<cjwatson> strace of whatever process it is that's looping
<seb128> cjwatson, there is a "blkid -o value -s TYPE /dev/sda2" running for some 8 minutes now
<cjwatson> can you strace it to see what it's doing?
<lifeless> Keybuk: 'mounted-dev main process (435) terminated with status 1
<lifeless> Keybuk: would that throw upstart off?
<Keybuk> wouldn't think so
<seb128> cjwatson, nothing apparently, strace -p <pid> stays there
<Keybuk> though it does mean something's wrong with your /dev ;-)
<Keybuk> if you don't have anything in there - then you'd have bigger problems
<lifeless> eh
<cjwatson> seb128: sounds like it's looping in internal logic then ...
<lifeless> root is mounted
<lifeless> lvm is happy
<cjwatson> seb128: kill the blkid process and see if it proceeds :)
<lifeless> I can see hundreds of nodes if I break=premount and look
<cjwatson> seb128: what is /dev/sda2?
<seb128> cjwatson, gdb says blkid_do_probe()
<seb128> blkid_verify()
<seb128> blkid_get_dev()
<lifeless> Keybuk: 177 to be precise
<seb128> cjwatson, it's an extended partitin
<seb128> +o
<Keybuk> lifeless: break=premount is a long way before the root fs
<seb128> cjwatson, which has sda5 and sda6
<lifeless> Keybuk: break=bottom has the root mounted
<seb128> which are the / and swap for the install
<lifeless> Keybuk: I've just checked
<Keybuk> lifeless: does mounted-dev fail consistently for you?
<lifeless> Keybuk: I see that error, yes
<Keybuk> lifeless: add "console output" to the job, then "set -x" in the script
<lifeless> the symptom I have is that the machine is stopped just after showing the root fs as clean
<slangasek> lifeless: 'break=premount' is while in the initramfs, though, so who knows what's going on in between that and chrooting?
<slangasek> s/going on/going wrong/
<lifeless> ctrl-alt-delete makes it reboot, and it kills the hw-clock only.
<lifeless> Keybuk: doing, thanks
<seb128> cjwatson, grub-install blocked on the same command, after killing it again it's downloading langpacks now
<seb128> cjwatson, thanks
<cjwatson> seb128: I'm not seeing that with the extended partition here - it would be good if you could manage to debug it independently?
<seb128> cjwatson, it's almost done installing langpacks let's see if that does it on the installed system
<seb128> oh plymouth joy
<seb128> "xorg crashes on enter"
 * seb128 uninstall
<seb128> at least the mini install worked ;-)
<Keybuk> bryceh: radeon should work with KMS right?
<Ixan> is there some complete documentation for preseed somewhere with all available settings for every subpart like partman somewhere? pretty please be so..
<persia> Yes.
<Keybuk> tjaalton: ^ ?
 * persia tries to remember the URL
<seb128> cjwatson, I don't get the blkid hang on the installed system
<seb128> cjwatson, I will try an another install and see how it goes
<persia> https://help.ubuntu.com/${release_number}/installation-guide/${arch}/index.html
<Ixan> yeah, seen that before. perhaps i was just secretly praying there were more paramteres i could configure
<cjwatson> there are a number of undocumented templates, but mostly they aren't useful for setting manually, and there's no comprehensive list - the guide is meant to be a list of all the ones that are actually useful
<cjwatson> what in particular are you missing?
<Ixan> using the crypto template for partman and setting a default password for luks
<Ixan> so users can change it themselves upon receiving it
<cjwatson> hmm, the current code explicitly disallows preseeding that I'm afraid
<cjwatson> which may or may not be an error - feel free to file a bug on partman-crypto
<Ixan> hirr, curses!
<tjaalton> Keybuk: yes
<Keybuk> tjaalton: all I get is a blank screen and a hang on boot
<Keybuk> seems to be about the point the driver would be loaded
<tjaalton> Keybuk: then try the mainline build
<Keybuk> tjaalton: -v
<tjaalton> .33 I mean
<Keybuk> tjaalton: newer kernel you mean?
<tjaalton> Keybuk: yes, 2.6.33 mainline build
<tjaalton> if you like deb's ;)
<Keybuk> I'd like a .iso ;P
<tjaalton> bah :)
<Keybuk> what driver would it be trying to use
<Keybuk> if I can blacklist it, I can see if I can install
<slangasek> Keybuk: you  linux-backports-modules-nouveau-lucid-generic
<slangasek> meh
<tjaalton> ah, well in that case you can disable kms
<slangasek> Keybuk: linux-backports-modules-nouveau-lucid-generic is present, right?
<cjwatson> slangasek: that's a good insult
<Keybuk> slangasek: how could I tell?
<tjaalton> but it was radeon, no?
<cjwatson> you linux-backports-modules-nouveau-lucid-generic, you.  (furthermore, your mother was a radeon.)
<slangasek> oh, radeon
<Keybuk> tjaalton: Radeon Xpress 1250 I think
<tjaalton> Keybuk: radeon.modeset=0
<Keybuk> (looking up the pci id)
<Keybuk> but
<Keybuk> saying
<Keybuk> that
<Keybuk> the NVIDIA based laptop doesn't work either
<Keybuk> just a nice greeish/cyanish/blueish screen
<slangasek> must be a plymouth bug
<slangasek> :-)
<Keybuk> slangasek: this is before I get to plymouth ;)
<pfr> sorry guys for asking this here, but the chance that some of you know what i need is the highest on this channel:  does Canonical have somebody like Jono Bacon who lives in Germany?
<Keybuk> pfr: there is nobody like Jono Bacon in Germany, Jono Bacon is illegal there
<sebner> pfr: dholbach
<pfr> or at least some community guy who speaks german?
<slangasek> Jono Bacon is unique in the world
<pfr> Keybuk: heh
<sebner> lol
<sebner> pfr: Ich spreche auch Deutsch aber du willst den dholbach ;)
<pfr> dholbach: yes, i think i want you :P
<sebner> heh
<Ixan> i learned all my german from special german movies from the 70s. best not uttered in public
<Keybuk> tjaalton: modeset=0 worked
<Keybuk> see, can't be a plymouth bug
<Keybuk> I now have a blue bar
<Keybuk> (I must patch that to be brown at some point <g>)
<sebner> Keybuk: please don't! :P
<tjaalton> Keybuk: try the newer kernel once you've installed, to see if it works with drm from .33
<Keybuk> tjaalton: ok
<Keybuk> awwh, the touch screen doesn't work in the installer's X session
<tjaalton> which device? serial wacoms don't work yet, but soon after a3
<Keybuk> tjaalton: it's a Dell XT
<Keybuk> the touchscreen did work in the live environment a while back, both in capacitive and resistive modes
<tjaalton> the old one or XT2?
<Keybuk> the old one
<tjaalton> what does "a while back" mean?
<tjaalton> looks like it's a wacom
<Keybuk> about the point that we dropped HAL
<Keybuk> it never worked properly before that
<Keybuk> then we dropped HAL
<tjaalton> sounds about right
<Keybuk> and it magically worked in both modes
<tjaalton> oh
<Keybuk> when HAL was around, it'd only work in resistive mode
<tjaalton> yeah sounds like the wacom isn't getting initialized, which is known. there's a patch waiting in git which doesn't make it filter the list of devices udevdb has. then the devices with subsys tty will work
<tjaalton> fixes vbox as well
<Keybuk> ah yeah, I think I saw that one go past on #udev
<tjaalton> then wacom needs an updated udev rules file and things should work. I have a thinkpad X61 tablet with the same issue
<Keybuk> I guess this is a case of "everything worked fine until somebody tried to make it work properly"
<tjaalton> something like that yes :)
<ion> There are recent tablet PCs that have a wacom connected to a *serial port*? Seriously? :-)
<Keybuk> it was probably the wrong resolution, and uncalibrated, and all those things that engineers hate
<Keybuk> but I COULD PRETEND TO BE JACK BAUER!
<tjaalton> ion: sure
<cjohnston> rickspencer3: could you please join #ubuntu-classroom-backstage when you get a chance
<Keybuk> cjwatson: silly question
<Keybuk> if I put radeon.modeset=0 on the kernel command-line when I install
<Keybuk> does that get copied to the kernel command-line of the installed system?
<ogra> i think it depends where you put it
<ogra> the -- has a meaning here
<Keybuk> ogra: as do many things in life
<cjwatson> Keybuk: if it goes after --, yes
<ogra> but i forgot if it has to be in front or behind
<ogra> ah
<Keybuk> cjwatson: yeah, it did copy it
<Keybuk> wow, I'm so used to everything Just Working on intel
<lifeless> Keybuk: it was haning because ifupdown hadn't been upgraded
<lifeless> Keybuk: and that meant lo wasn't being started
<lifeless> Keybuk: which meant rc-sysvconf never kicked in
<Keybuk> you don't need rc scripts anyway ;)
<lifeless> sorry, rc-sysinit.conf I think
<lifeless> no, but being able to login is nice.
<slangasek> lifeless: "because ifupdown hadn't been upgraded" - that upgrade is a workaround for a broken /etc/network/interfaces, why was yours broken?
<lifeless> slangasek: it wasn't broken: I din't have a network-interface.conf file
<slangasek> er, oh
<lifeless> slangasek: because I had hardy's.
<lifeless> slangasek: there is a missing versioned dep here, I think.
<lifeless> either breaks or depends, dunno which is appropriate.
<slangasek> breaks isn't appropriate
<lifeless> of course, this doesn't matter if the upgrade completes properly :>
<slangasek> it's upstart's rc-sysinit.conf that depends on the new ifupdown functionality, so if there's to be a dep, that's where it needs to go
<lifeless> yes
<lifeless> All I was saying about breaks was I didn't know which way around the relation needed to be expressed
<Keybuk> slangasek: probably a Breaks on the older version is better?
<Keybuk> actually I guess it needs a Dep now because of the fact the .conf file depends on the event
<Keybuk> which is likely to cause yet more buildd failures
<lifeless> breaks on older stops it being a hard dep
<lifeless> depends will bring it in if it has to be there
<slangasek> that's overloading the meaning of breaks though
<lifeless> slangasek: orly?
<lifeless> anyhow
<lifeless> bugs incoming.
<slangasek> lifeless: upstart doesn't break the old ifupdown, the absence of new ifupdown breaks new upstart :)
<Keybuk> in practice, if an Upstart job refers to an event generated by a job outside of its package, then it must depend on that package
<Keybuk> so Upstart should have a Depends: ifupdown
<Keybuk> and, since Upstart is supposed to work unconfigured, that has to be a Pre-Depends
<lifeless> bug 527829 is the mounted-dev issue
<ubottu> Launchpad bug 527829 in mountall "mounted-dev uses cp -n, should versioned dep on coreutils" [Undecided,New] https://launchpad.net/bugs/527829
<lifeless> its trivial
<Keybuk> ah, I didn't know it needed one
<lifeless> bug 527830 is the lo issue
<ubottu> Launchpad bug 527830 in upstart "upstart needs to depend on ifupdown" [Undecided,New] https://launchpad.net/bugs/527830
<lifeless> I filed another bug earlier tonight, there is a predepends loop
<lifeless> udev -> upstart -predep->mountall -> udev
<Keybuk> lifeless: can't be helped
<lifeless> so you can't actually install those three by hand without silly-buggery
<lifeless> Keybuk: I'm just reporting it
<Keybuk> mountall depends on udev (it copies out of /lib/udev/devices - which is created by udev's postinst)
<tseliot> Keybuk: do you mind if I modify the way mountall interacts with plymouth?
<Keybuk> udev should not depend on Upstart though?
<Keybuk> tseliot: be my guest
<tseliot> :-)
<Keybuk> lifeless: I can't see a udev->upstart dep here
<lifeless> Keybuk: technically it depends on upstart-job
<lifeless> right after libusb, before module-init-tools
<Keybuk> ah right, from misc:Depends
<lifeless> but as thats provided by upstart. ..
<Keybuk> right, again, it has to ;-)
<Keybuk> upstart has to depend on mountall because it uses "on filesystem"
<Keybuk> so there you go
<Keybuk> all those are correct
<lifeless> why does udev depend on upstart?
<Keybuk> lifeless: it ships an upstart job
<Keybuk> that's pretty much the definition of "depends on" :p
<Keybuk> the real problem is that upstart is using pre-depends I guess
<Keybuk> it doesn't *have* to
<lifeless> I think thats a pretty key driver for it, yes.
<lifeless> but its 2am, and I don't think I'm a good sounding board right now.
<Keybuk> we never made Upstart "Essential"
<lifeless> so I'm happy, my server is running lucidish now
<lifeless> I'm going to make email flow and go halt()
<Keybuk> coreutils 7.1 apparentlyt
<ttx> pitti: will the beta1 burndown charts reset their start date at the beginning of beta1 subcycle ?
<lifeless> Keybuk: which we never shipped ;>
<Keybuk> lifeless: that's ok, >= 7.1 will dtrt
<pitti> ttx: I just sent a mail to -platform about this, with a proposal
<ttx> pitti: ah, will read and comment if needed :)
<Keybuk> message:
<Keybuk>   merge Scott's fix for 524484
<Keybuk> ohhh, t'other Scott
<Keybuk> slangasek: OOI, wouldn't james_w's importer automatically have committed that upload?
<slangasek> yes, but without the full branch history, so
<Keybuk> slangasek: why without the full branch history?
<Keybuk> my understanding is that it would have checked out the lp:ubuntu/upstart branch
<slangasek> because it wouldn't know it was a merge of smoser's branch?
<Keybuk> slangasek: ah, smoser had a branch?
<slangasek> yes
<Keybuk> oh, of course, he must have done - you merged it
<slangasek> :-)
<Keybuk> did you overwrite the importer's own? ooi
<slangasek> shouldn't have clobbered anything the importer cares about
<lifeless> slangasek: ><
<lifeless> the right thing is
<slangasek> the importer is supposed to recognize that I've tagged the upload, and consider it equivalent to the archive
<lifeless> debcommit -r - that should tag it
<Keybuk> slangasek: indeed not, just curious - I overwrite the importer all the time ;)
<tseliot> Keybuk: does "Cc" stand for Ctrl-c ?
<slangasek> lifeless: I'm familiar :)
<Keybuk> tseliot: no, just C in upper or lower case - I don't really trust plymouth ;)
<lifeless> then when you push your upload is compared by the importer
<lifeless> if different, it will win
<slangasek> where by "win" you mean "everyone loses", right? :)
<Keybuk> lifeless: not if the importer has already done the import
<Keybuk> then you have to overwrite what it did with something better
<tseliot> Keybuk: ok. I guess we can't catch "Esc" as that's already in use, right?
<lifeless> Keybuk: thats why you push before dput, after building
<Keybuk> tseliot: right
<Keybuk> lifeless: as we've just followed - smoser couldn't push to the lp branch
<lifeless> Keybuk: why not?
<Keybuk> I was wondering whether steve had to "fix" the history after the upload or not
<Keybuk> lifeless: he's not a member of core-dev ?
<lifeless> Keybuk: if he can upload the package, he can push to the branch
<lifeless> Keybuk: doesn't matter; its all about 'can he upload'
<Keybuk> only via a sponsor I guess
<lifeless> which sounds like what slangasek did
<lifeless> 'sponsor' => merge + dput
<slangasek> Keybuk: no, I committed first, uploaded after
<Keybuk> right, so we've achieved the answer to my question :p
<Keybuk> I was just curious :)
<lifeless> \o/ working code, 6 years in :>
 * slangasek grins
<Keybuk> not that there's anything implicitly wrong with overwriting the importer
<lifeless> zomg, why is tla-load-dirs still in the archive.
<lifeless> Keybuk: well, there is on upstream changes.
<lifeless> Keybuk: unless you capture the pristine data precisely as the importer sees it
<slangasek> lifeless: how else are you going to run tla-buildpackage? :-P
<lifeless> slangasek: aieee
<Keybuk> lifeless: in Upstart's case, the branch is based off the upstream trunk - and I use merge-upstream to make releases ;)
<Keybuk> lifeless: do you know the bug# for your pre-depends loop report?
<lifeless> no, check my filed bug rss feed
<Keybuk> "bend over, I need to check your RSS"
<lifeless> bug 527722
<ubottu> Launchpad bug 527722 in upstart "pre depends loop" [Undecided,New] https://launchpad.net/bugs/527722
<Keybuk> thx
<lifeless> de nada
<Keybuk> all three bugs have fixes committed
<lifeless> thanks
<lifeless> I realise they are kindof corner case
<lifeless> at least for all our karmic->lucid upgrades
<Keybuk> we care about hardyâlucid upgrades this cycle though too, no?
<lifeless> yes
<lifeless> but even they would presumably typically be ok
<Keybuk> probably, always worth getting the ordering right
<lifeless> its because I ended up with an interrupted upgrade that this blew up
<Keybuk> they're obviously not critical for Î±3, but would be good to have for Î²1 since more people will test then
<lifeless> and yeah, +1 on trying to get it right, otherwise I wouldn't have diagnosed and reported ;)
<slangasek> Keybuk: bug #527605 looks like a dupe of the dep cycle report?
<ubottu> Launchpad bug 527605 in update-manager "kubuntu 8.04 -> 10.04 upgrade fails, due to likely dependency cycle" [Undecided,Confirmed] https://launchpad.net/bugs/527605
<Keybuk> yeah could be
<Caesar> Sigh. Does nobody use NFS any more?
<Keybuk> I use NFS
<ogra> for what ? sshfs is so much nicer :)
<Caesar> The number of things in Lucid that complain because $PWD is unreadable by root makes me sad
<Caesar> ogra: sshfs doesn't scale
<Keybuk> Caesar: so don't squash root ;)
<ogra> yeha
<Caesar> Keybuk: err, no
<Caesar> Keybuk: can I ask you the upstart questions I emailed you about?
<Caesar> or can you answer them now or something?
<Keybuk> Caesar: I am busy at the moment, I'll reply to your mail in due time
<Caesar> ok
<Keybuk> (probably today)
<Caesar> Thank you
<james_w> nigelb: hi, why do you keep proposing the merge for the apport hook in rhythmbox?
<nigelb> james_w: sorry for the spam.
<nigelb> I made plenty of mistakes
<nigelb> each time someone pointed something out, I had to keep correcting it
<nigelb> james_w: I think its perfect now though :)
<james_w> nigelb: you don't have to do those steps every time
<james_w> nigelb: you can just push to your branch and it will update
<nigelb> james_w: but my branch would diverge with every change and it would throw up an error
<james_w> nigelb: hmm
<james_w> what were you doing to make a change?
<nigelb> I was deleting the branch, uncomitting, making the changes, and pushing again, and requesting merge
<james_w> just make the changes and commit!
<james_w> you are using a version control system ;-)
<nigelb> james_w: I'm learning that now
<nigelb> james_w: I thought the commits and changelog should be matching
<nigelb> now I realized it doesnt have to be
<james_w> nah
<james_w> good :-)
<nigelb> james_w: sorry again for all that spam
<james_w> no problem
<james_w> just wanted to make sure you were finding the system pleasant to use, and it looked like you were doing more than you had to
<nigelb> yeah, I learned that now
<slynux_> can anyone suggest a good makefile tutorial
<slynux_> ?
<chrisccoulson> slynux_: i don't know any good tutorials, but i find that a good way of learning is to look at other packages as examples
<slynux_> ok
<chrisccoulson> you can generally learn a lot by doing that ;)
<Chipzz> I would disagree
<Chipzz> most Makefile's you'll see today are autogenerated by automake
<smoser> hi, i'm looking to make sure that bug 525003 gets fixed in lucid.  I'm not exactly sure how what i need to do.  i've linked a branch and proposed merging, i hope thats enough?
<ubottu> Launchpad bug 525003 in apport "apport's "is ec2 instance" check is out of date" [Medium,New] https://launchpad.net/bugs/525003
<Chipzz> and those contain so much cruft...
<mdz> ara, do you know where to find the script used to mark a bug (with duplicates) as a duplicate of another bug, moving all the duplicates across?
<nigelb> smoser: you could ping pitti :)
<nigelb> mdz: lp-set-dup?
<mdz> nigelb, that sounds promising
<ara> mdz, I am afraid not, bdmurray maybe knows better
<smoser> nigelb, yeah, i wanted to avoid bothering him if the above was sufficient and thought someone might know.
<micahg> mdz: ubuntu-dev-tools
<mdz> nigelb, thanks
<mdz> ara, lp-set-dup is it
<nigelb> mdz: happy to help :)
<pitti> smoser: can you please assign it to me? I only look at new bugs ever other week or so, if you subscribe or assign me I get it to know much faster
<ara> mdz, thanks
<smoser> pitti, ok. i just didn't want to explicitly pester you if it otherwise was fine.
<smoser> thanks.
 * mdz cleans up that batch of duplicates of bug 520824
<ubottu> Launchpad bug 520824 in gnome-app-install "update-app-install crashed with UnicodeEncodeError in __eq__()" [Medium,Triaged] https://launchpad.net/bugs/520824
<cjwatson> kirkland: bug 455746 - I notice that postfix is in the eucalyptus-cloud task, but not eucalyptus-cluster.  I think I was told that this should go in the cluster controller bit, but am I right in thinking we actually only need it on the cloud controller?
<ubottu> Launchpad bug 455746 in eucalyptus "postfix should be preseeded appropriately when pulled in by the UEC cluster controller installer target" [Wishlist,Triaged] https://launchpad.net/bugs/455746
<cjwatson> if that's right, then it's a trivial fix
<lamont> what controls writing to /etc/mailcap? (as in, how do I tell it about a diff handler ofr something?)
<cjwatson> update-mime(8) describes it
<ion> lamont: sed -nre '5p' /etc/mailcap
<lamont> doh
<kirkland> cjwatson: yes, as far as I can tell, it's only the front end of eucalyptus that sends mail (welcome mails to new users, etc)
<kirkland> cjwatson: there's two other things i wanted to get your input on
<kirkland> cjwatson: one is that we've run into some unfortunate timing issues on preseed installs of separated components
<kirkland> cjwatson: i think there's a bit of time where the, say CLC or CC is up, and broadcasting it's avahi message
<kirkland> cjwatson: and the installation of the next machine picks that up
<kirkland> cjwatson: but the webserver providing the preseed file is not quite up and ready
<lucas> how often are sync requests being processed?
<james_w> lucas: they probably haven't for a couple of days due to the milestone freeze
<james_w> should be ~every weekday apart from that
<lucas> ah ok, perfect
<lucas> I thought it was only once a week or something
<lucas> and started getting worried about the ruby mess ;)
<manjo> cjwatson , ping
<manjo> cjwatson, I am trying to install a EEEpc 1201N, the installer is stuck at 93% (looking for other operating system) and I am unable to chvt to another terminal to look at the logs...
<manjo> cjwatson, I got this image yesterday...
<kees> lifeless: have you gotten anywhere with your lvm issues?  I can try to help debug it.
<manjo> cjwatson, looks like its an issue with the nvidia graphics card
<manjo> that I am not able to see the VT1/2etc
<manjo> but if I chvt to 2 and do reboot it actually reboots
<Keybuk> tjaalton: still around?
<Keybuk> tried 2.6.33 and still no love for radeon
<tseliot> slangasek: do you think I need to implement the support for ask-questions in the boot theme?
<matti> Hello folks.
<matti> Is keyserver.ubuntu.com down?
<tjaalton> Keybuk: ah, too bad
<tjaalton> needs a bugreport then
<tseliot> wouldn't that require a new user space drm too?
<tseliot> (just asking)
<tjaalton> we already have 2.4.18 which is the latest release
<tjaalton> and that was made for nouveau
<tjaalton> though our version has the abi change reverted
<Keybuk> tjaalton: how would you like the bug report filed?
<cjwatson> kirkland: ok, fixed cloud preseed thing
<tjaalton> Keybuk: upstream :)
<cjwatson> kirkland: the design of the upstart jobs was meant to prevent that; as far as I'm concerned if we're seeing that that means that the job implementation is faulty ...
<kirkland> cjwatson: cheers, thanks.
<Keybuk> tjaalton: I don't have the no-how to talk to them, but would appreciate it if you could for me
<tjaalton> Keybuk: or if you feel like it you could poke airlied on #dri-devel
<cjwatson> manjo: sorry, without logs I'm as clueless as you - however it could be the blkid hang seb128 ran into earlier, don't know for sure
<kirkland> cjwatson: right, so I agree that publication should only occur after the bits are up and serving the preseed file
<kirkland> cjwatson: i need to check with ttx on that one, though, as he said that it shouldn't be that way
<tjaalton> Keybuk: ok, well just file it against -ati, it'll include what we need
<Keybuk> tjaalton: I'll do the poke
<kirkland> cjwatson: i'll dig deeper
<cjwatson> kirkland: I didn't really do much of the upstart stuff
<kirkland> cjwatson: no, i did most of it, i know it inside and out
<kirkland> cjwatson: one last question, ecryptfs related
<manjo> cjwatson, thought I will run it by you incase you had prior experience with this hang... I rebooted and started a reinstall and it seems to go past the 93% mark.. ie on 2nd install does not hang at 93%
<kirkland> cjwatson: actually, nevermind.  it's a hard one.  i'll think more on it.
<manjo> cjwatson, but do you think filing bug against ubiquity will be of any use at this point ?
<manjo> coz we lost data wrt to previous install attempt right ?
<cjwatson> manjo: not without logs
<Keybuk> slangasek: as well as the ENTER Kills My X Server issue
<Keybuk> people have reported a problem where typing corrupts the top of the screen
<Keybuk> right?
<slangasek> tseliot: ask-questions> I have no opinion, I didn't report that bug I just triaged it :)
<slangasek> Keybuk: yes
<Keybuk> slangasek: cool, I can replicate that one on the radeon machine
<slangasek> \o/
<tseliot> slangasek: ok
<chrisccoulson> cjwatson - somebody just reported a duplicate of bug 209410 against gnome-screensaver. i notice in that bug you mention that ubiquity already tries to inhibit the screensaver
<ubottu> Launchpad bug 209410 in ubiquity "installer goes to sleep / activates screen saver" [Low,Confirmed] https://launchpad.net/bugs/209410
<chrisccoulson> out of interest, how do you do this?
<chrisccoulson> ah, never mind. i found it now (gnome-screensaver-command --poke)
<chrisccoulson> i know why that doesn't work
<mathiaz> james_w: hi!
<mathiaz> james_w: what are we supposed to do with these kind of branches:
<mathiaz> james_w: https://code.launchpad.net/~ubuntu-branches/ubuntu/lucid/vsftpd/lucid-201002122353/+merge/19228
* slangasek changed the topic of #ubuntu-devel to: Lucid Alpha 3 released | Archive: Feature Freeze | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<soren> cjwatson: BjÃ¶rn seems happy with my latest stab at bug 246558. How about you?
<ubottu> Launchpad bug 246558 in openssh "ssh's init script should generate host keys if they're missing" [Low,Confirmed] https://launchpad.net/bugs/246558
<jibel> mvo_, Hi, I've found the problem (and solution) for the xapian search with an hyphen (hence searching for a package name)
<mvo_> jibel: ohhh - nice!
<mvo_> jibel: how?
<jibel> mvo_, the indexer uses it's own term generator instead of xapian TermGenerator and it does it the wrong way
<jibel> s/it's/its/
<mvo_> jibel: aha, good that I have you here, one thing that occured to me was that we problably want to only reapply the sort mode in xapian when its not in the default sort mode. because one nice feature of the xapian sort is sort by relevance
<mvo_> jibel: apt-xapian-index?
<jibel> yes apt-xapian-index
<mvo_> jibel: cool, if you give me the details I can fix that
<jibel> we sort by relevance but relevance is not shown anywhere, from a user point it's confusing
<mvo_> hm, right
 * mvo_ scratches head
<jibel> we have report where the users searches for pitivi and enters 'pit'
<jibel> but the qualitycutoff is so high that it's not displayed in the list
<mvo_> could we display relevant with little stars or something maybe?
<mvo_> utf-8 ftw ;)
<jibel> yes, it's a percentage
<jibel> mvo_, I'll push a fix for apt-xapian-index and synaptic, it won't be hard to port it software-center.
<jibel> but I'd like to know why enrico did it this way.
<mvo_> jibel: #xapian has been very responsive about questions like this in the past
<mvo_> jibel: I imagine that it might be because when he wrote it something in the xapian buildin was missing
<cjwatson> soren: I'll think about it.  I'm worried about doing lots of work at boot time.
<cjwatson> soren: but I will think about it.
<jibel> mvo_, indeed, I talked to ojwb yesterday about the pb with the phrase generator,he was very helpful
<jibel> mvo_, the patch for apt-xapian-index is at http://pastebin.com/3QYx9u5K
<jibel> the stemming part can be removed since it indexes only package names.
<mvo_> jibel: sweet, that is all?
<mvo_> jibel: *thanks* very much
<jibel> no that's not all.  This patch will generate correct index with terms at the right position
<jibel> e.g xserver-xorg-video-ivtv will be indexed xserver 1 xorg 2 video 3 ivtv 4
<jibel> the hyphen is the phrase generator so when you search for  xserver-xorg it search for an exact match for the term AND the position
<mvo_> jibel: aha, ok
<jibel> mvo_, with the current version of apt-xapian-search the key contains the hyphen and can't be searched
<jibel> mvo_, we also need to change the query string to replace the '-' by '%-'
<jibel> mvo_, this makes xapian expand the last term of the query and replacing the operator PHRASE by AND
<jibel> mvo_, you can then search for 'name:(xserver-com)'
 * mvo_ nods
<jibel> mvo_, and it will returns all package with a name containing xserver and com*
<jibel> I'll send you a piece of code it's easier.
<mvo_> ok
<mvo_> I need to leave for bed now, I will check it out tomorrow morning :)
 * mvo_ waves
<jibel> have a good night
<soren> cjwatson: Thanks. If you have other ideas about how to handle this for shared VM images, I'm all ears, though. This was just my initial reaction.
<mathiaz> bdmurray: hi - how often are the json search refreshed?
<mathiaz> bdmurray: for example: http://qa.ubuntu.com/reports/team-subscribed/server-team-subscribed-with-date.json
<TheMuso> slangasek: I thought a new testing group had been started to do just that, and since I'm not invovled with that, I don't know. GOing by the tracker, obviously not.
<Daviey> mathiaz: it's not like you could claim it's not regular enough!  "created": "2007-11-26T14:40:26.815940+00:00"
<bdmurray> mathiaz: I thought I'd mentioned in the e-mail that'd I run that once but could make it a cron job if it met your requirements.
<TheMuso> hrm ok amd64 still needs 3 more tests done.
<bdmurray> Daviey: that's likely a bug tasks' creation date
<Daviey> bdmurray: it is
<mathiaz> bdmurray: right - so I've loaded that in bughugger and it's a good start
<mathiaz> bdmurray: doing the query on the date is a bit awkward
<mathiaz> bdmurray: as what I'd like to express is: created <= yesterday UTC
<Daviey> looks like it was last updated Wed, 24 Feb 2010 00:30:02 UTC
<bdmurray> mathiaz: okay, I'll look at getting that to work in bughugger then
<mathiaz> bdmurray: the problem I'm trying to solve is that the dailynewbugs lists (http://qa.ubuntu.com/reports/ubuntu-server-team/dailynewbugs.ubuntu-server.thu.html) are quickly out-dated
<mathiaz> bdmurray: does bughugger check the *current* status of a bug when it works from a json search?
<bdmurray> mathiaz: no
<mathiaz> bdmurray: hm - fundamentally that's what I'd like to do
<mathiaz> bdmurray: I'll think about it a bit more
<mathiaz> bdmurray: server-team-subscribed-with-date.json may be a good starting point though
<mathiaz> bdmurray: are these reports generated using launchpad API or directly from the DB?
<bdmurray> mathiaz: the api
<james_w> mathiaz: currently they are probably bugs if the diff doesn't show something useful
<TheMuso> slangasek: ah ok alpha 3 released, missed the topic. Don't mind me
<Caesar> Is the only difference between the Ubuntu Server CD and the non-Server CD the installer?
<Caesar> or is there more to it?
<lifeless> kees: thanks for offering, yes all fixed.
<lifeless> kees: bugs filed; system happy
<kees> lifeless: cool; if you have them handy, what are the bug#s?
<lifeless> not handy sorry
<lifeless> uhm, I think one is invalid, and I might need to file one other, on consideration
<kirkland> lool: when you come around tyhicks has a few questions for you about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/524919; you can find him in #ecryptfs on irc.oftc.net
<ubottu> Launchpad bug 524919 in linux "ecryptfs breaks lstat/readlink size assumption" [High,Confirmed]
<lifeless> however, I was up to 3:30 or so doing the recovery, and its 9 now: I'm a little shattered
<lifeless> kees: gimme 15 to try and get my head together, and I can tell you what happened
<lifeless> kees: its all about sysfs scanning
<kees> lifeless: interesting, okay, no worries, get some sleep.  :)
<MattJ> As an upstream developer with a (new) package going into lucid... the version it is based on has known issues, is there a way we could get it updated?
<MattJ> I'm not sure which is best, since we weren't planning another bugfix release in that development branch (but could make one if necessary)
<MattJ> or you can tell me it's a lost cause and I'll just try not to think about it :)
<dupondje> is it fixed in debian ? or isn't it in debian ? :)
<james_w> MattJ: no, impossible, we love shipping with bugs ;-)
<MattJ> It's in debian, but also the same upstream version
<MattJ> Bugs are great, but not when their mine :)
<MattJ> *they're
<MattJ> See?
<james_w> heh
<james_w> MattJ: no problem
<james_w> you can either provide a patch fixing all the bugs, or make a new bugfix release from that branch upstream
<james_w> once you have either one wave it around here and find someone to help
<MattJ> Ok, great
<MattJ> I'll figure out what needs backporting and get that done ASAP, thanks :)
<jcastro> MattJ: I have been putting docs together for upstreams such as yourself to make it easy to find out this kind of info, any feedback on it would be appreciated! https://wiki.ubuntu.com/Upstream
<MattJ> Oh very nice, thanks :)
<lifeless> kees: ok, slighty fed etc
<lifeless> kees: uhm, hers the issue
<lifeless> here is the issue
<lifeless> if you say 'iz bug' I will file it a little bit later
<lifeless> I had an upgrade from hardy go queer, which wasn't a bug
<lifeless> however, I ended up with new kernel, old userspace
<lifeless> amongst the various problems I had, the old lvm2 needs sysfs to be in a now deprecated layout
<lifeless> or sysfs_scan=1 leads to actual block devices being skipped
<lifeless> upstart OTOH needs the newer layout, so the newer kernel is needed
<lifeless> so, I'm thinking kernels with the new sysfs layout should Breaks: lvm << version-that-added-the-new-layout
<lifeless> kees: let me know whether I should file that bug or not ;)
<kees> lifeless: would a Breaks: have actually helped that situation?
<lifeless> kees: yes
<kees> lifeless: I would say yes, then, open a bug for that.
<lifeless> kees: the new kernel would have required lvm to be in the same install set
<lifeless> and anyone doing surgery would have had dpkg whinging at them how the breaks was present
<lifeless> ok, I'll open a bug. Thanks
<shtylman_> what is the purpose of the linux-preempt kernel?
<shtylman_> does the generic kernel not have preempting ?
<jdong> the generic kernel does not CONFIG_PREEMPT, no.
<crimsun> shtylman_: lower latency with faster tick
<shtylman_> jdong: crimsun: thanks :)
<baffle> slangasek: Hi, I was just talking to Kirkland about libvirt-bin and the new upstart script he made for it. A quick question; Is /etc/default/ deprecated with upstart? Are configuration parameters supposed to be put directly into /etc/init/<deamon>.conf
<persia> Caesar: The difference between "server" and other alternate CDs is the contents of the pool on the CD and the selection of available preseed files.  The difference between "live" and "alternate" CDs is the installer.  That there doesn't happen to be a live CD for "server" is a coincidence (although an intentional one)
<baffle> slangasek: .. instead? I see that /etc/default/libvirt-bin is marked as "obsolete" in the package "Conffiles:" too.
<baffle> persia: Another difference between server installation CD and live CD is the exclusion of various network card modules; I noticed that "bnx2" is missing. "bnx2" is commonly used on servers.. I had to patch the liveCD to get networking to work on a server.. (I PXE boot the image)
<persia> baffle: comparing server alternate to Desktop live shows all sorts of differences.  Comparing server alternate to desktop alternate will show you how the contents differ (some stuff on desktop live is only in the pool).
<persia> baffle: If Desktop alternate doesn't work (or doesn't contain the packages you need) it may be worth filing a bug.  No promises it gets fixed (space considerations vs. number of users served, etc.).  If desktop alternate works and desktop live doesn't, *definitely* file a bug: that's likely just a documentation issue.
<baffle> persia: I'm not sure if it can be qualified as a *bug*. It is just that the live CD seems to be missing support for "server grade" network cards, and I had to patch them from the correct kernel-module udeb myself.
<cjwatson> bnx2 got fixed, I think
<baffle> cjwatson: Oh.
<baffle> cjwatson: Then it wasn't intentional. :)
<cjwatson> hang on, missing in the *live* CD?
<cjwatson> that's the other way round from the normal problem :)
<baffle> cjwatson: Yes.
<cjwatson> but it's certainly a bug either way
<cjwatson> bnx2 is complicated because it requires firmware
<baffle> cjwatson: But, nevermind, I was basing this on Karmic, I haven't checked out live on lucid.
 * persia would expect it to be in the pool for the liveCD but not in the squashfs if it's in desktop alternate, and if it's not in desktop alternate, believes it deserves a bug for tracking of the decision to include/not-include it
<cjwatson> please see if you can reproduce it in lucid if you can, and absolutely file a bug if it doesn't work
<cjwatson> ah yes
<cjwatson> initramfs-tools (0.92bubuntu34) karmic; urgency=low
<cjwatson>   * Remove bnx2 from the initramfs; it needs firmware, and at this stage we
<cjwatson>     only support network modules that don't need firmware loading (LP:
<cjwatson>     #394783).
<cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Tue, 07 Jul 2009 11:45:58 +0100
<cjwatson> so see bug 394783 for context
<ubottu> Launchpad bug 394783 in initramfs-tools "Broadcom BCM5708 "SIOCSIFADDR: No such device"" [Medium,Fix released] https://launchpad.net/bugs/394783
<cjwatson> since that's closed, please do open another bug if you actually need it, since that information is useful to us
<baffle> cjwatson: Well, *need* is maybe not the correct term. I found it practical to have the ability to get a full desktop system booted from PXE on some servers..
<baffle> cjwatson: I.e. if you need to do some hacking to fix broken RedHat/CentOS servers. :-)
<baffle> cjwatson: So it isn't really a typical use case.
<cjwatson> ok, well, you have the audit trail now...
<baffle> cjwatson: Thank you for your help. You wouldn't happen to know anything about upstart? Ref. my question to slangasek above..
<baffle> I just doesn't like posting bugs on packages if it is intended behaviour. Not others fault that I do weird stuff..
<baffle> s/doesn't/don't/
<cjwatson> baffle: my understanding from talking to the upstart author is that on the whole he prefers upstart jobs to be written in a way that's simple enough that you no longer really need a separate /etc/default/ file to make merging of customisations easier
<cjwatson> baffle: but there's no written-down standard as yet, so there's almost certainly some variance
<cjwatson> part of the historical reason why /etc/default/ exists was that it was pretty hard for admins to edit /etc/init.d/ scripts and then keep their changes merged across versions - it wasn't an original part of sysvinit, it evolved
<Chipzz> cjwatson: that's an interesting angle on /etc/default :)
<Chipzz> I always thougt of it slightly different
#ubuntu-devel 2010-02-26
<baffle> cjwatson: But doesn't this also apply to /etc/init/*.conf as well? Then you would have to define these as Conffiles as well; Or else they will get overwritten on upgrades.. And then you never will recieve new versions of initscripts from the package maintainers?
<baffle> cjwatson: As I see it, there is a very good reason for separating configuration and functionality.. The existing (well, old) system of initscripts and /etc/default/ are written to allow for a certain degree of customization/configuration wich is maintainable over time. RH does the same with its /etc/sysconfig/ ..
<cjwatson> baffle: but they are conffiles ...
<cjwatson> yeah, the question is at what point the configuration becomes simple enough that it isn't worth the added complexity of separate files
<cjwatson> upstart jobs are sort of on the edge of that
<cjwatson> init scripts are clearly not
<cjwatson> anyway, this isn't something I decided - if you want to debate it, better wait until Keybuk is around. :-)
<baffle> cjwatson: I'm just trying to understand if it is intentional or not. :-) And if it is, trying to think if it is a good idea..
<lifeless> kees: bug 528155
<ubottu> Launchpad bug 528155 in linux "needs a breaks: clause for lvm2 versions in hardy" [Undecided,New] https://launchpad.net/bugs/528155
<lifeless> I wonder, how btrfs would go on /dev/fd0
<jdong> lifeless: is that even enough space to store the metadata?
<jdong> isn't the first 1.0MiB of the ondisk format reserved for metadata explicitly?
<lifeless> no idea
<zul> lifeless: you still have a floppy drive? ;)
<lifeless> zul: on this server, yes.
<slangasek> TheMuso: oh; who's in this testing group? :)
<bryceh> slangasek, is there a way from a script on a user's system to determine if the system is running a development version or an official release?
<slangasek> baffle: /etc/default> note that if you have a file left around as an obsolete conffile, that's probably a bug in the owning package for not cleaning it up properly
<slangasek> bryceh: lsb_release -d?
<bryceh> aha!
<twb> Is there a way to get a unified change history of version migration into Lucid (particularly for the last fortnight)?
<twb> That is, something like the "news" section of http://packages.qa.debian.org/m/mg.html, but for a distro rather than for a package.
<nixternal> twb: https://lists.ubuntu.com/mailman/listinfo/Lucid-changes
<nixternal> like that?
 * twb looks
<nixternal> its actually worth subscribing too...you will get a lot of emails, but you will see all of the work going on, and you will find new packages and stuff that you may not have known about before
<twb> FSVO subscribe = turn it on in my gmane feed :-P
<RAOF> It's also aggregated as an RSS feed, if you prefer (I do).
<twb> RAOF: bah, RSS is for people too young to have a .newsrc
<nixternal> I don't have .newsrc, but I have .newsbeuter/config, does that make me to young?
<ScottK> nixternal: You definitely aren't too young.
<ScottK> I'm unsure of the exact topic, but that's a safe bet.
<nixternal> younger than you!
<ScottK> Not in years of FOSS experience.
<ScottK> BTW, younger than me doesn't help at all if you're shooting for "not old".
<twb> You're young if you never got your sleeve caught in a disk drive :-)
 * StevenK never managed to do that
<ScottK> You're young if you never had to sort a dropped deck of punch cards.
<twb> Yeah
<nixternal> pfft, disk drives, how about getting stitches from a magnetic disk on a Univac 90/60 or 90/70, can't remember, when I worked at Unisys in high school?
<nixternal> ScottK: good, I never had to sort the punch cards I dropped, so I am young according to your last statement...woohoo I win!
<ScottK> nixternal: If you're looking for excuses to call yourself young, you aren't.
<maco2> ScottK: he drinks like a young'n
<nixternal> pfft, I put a young'n to shame!
<crimsun> fogeys all ya
<ScottK> Get off my lawn....
<nixternal> dude, you are going bald, I can at least say I am not
<nixternal> hahahaha
 * maco2 notes ScottK  could be her dad
<crimsun> nixternal: who me?
<nixternal> yeah you
<nixternal> every event your hair is thinner and thinner
<maco2> nixternal: he's been balding since high school, iirc
<twb> maco2: you realize that might be taken as a criticism of your mom
<nixternal> booyah!
<crimsun> nixternal: that statement only works on people who actually care about their baldness. :-)
<nixternal> hahah
<ScottK> nixternal: Maybe you aren't the only one experiencing denial.
<maco2> twb: heh, i meant he was old enough
<nixternal> I shave my head now, so I don't care about baldness either
<nixternal> ScottK: no denial here, I am losing hair too :)
<nixternal> just not as fast as crimsun over there
<nixternal> and you can't blame it on the snow!
<maco2> nixternal: calling crimsun old doesnt work. he responds "and in the culture of my ancestors, being old is a thing to be proud of, so HA!"
 * RAOF has a glorious head of flowing hair. :P
<ScottK> nixternal: Hair isn't what you're in denial over.
<twb> crimsun: do you wax it, too, so the glare annoys passing motorists?
<crimsun> boom tish
<nixternal> ScottK: shush :D
<maco2> crimsun: look! a local IP!
<nixternal> wow, today has been a quiet inbox day, only 81 emails thus far..and I am to lazy to sort them right now
<maco2> nixternal: you know anything about .sip files?
<nixternal> funny you should ask, check kubuntu-devel :)
<maco2> good timing, eh?
<twb> nixternal: what does KDE have to do with VOIP?
<maco2> twb: .sip is the extension for c++-to-python bindings, afaict
<ScottK> twb: Different sip.
<nixternal> not that kind of sip :)
<twb> Silly qt
<nixternal> watch it now
<nixternal> you are surrounded by qt/kde devs right about now :)
<twb> Eh, I don't even run X, so I'm not worried.
<nixternal> well well, Richard Stallman is in the channel!
<nixternal> ;p
 * maco2 is excited to have written something with pykde that actually runs
<twb> nixternal: nah, RMS runs off a Yeelong, not an Eee PC.
<ScottK> Running is good.
<nixternal> i wrote a BSOD with pykde :)
<nixternal> http://www.nixternal.com/files/bsod.png
<twb> ScottK: "if it compiles, it's great; if it boots, it's perfect"
<ScottK> If it runs, ship it.
<maco2> ScottK: the trick was, i had to not use pykde4 for phonon and instead just use normal pyqt4 bindings for that. and so now i'm looking at these sip files trying to figure out how to fix them such that pykde is slightly less broken
<maco2> from what crimsun and seele say, i have the impression i'll be needing to try to fix pykde4 a few more times
<slangasek> ScottK: boost-defaults is settled at 1.40 for lucid, right?
<ScottK> slangasek: As far as I'm concerned, yes.
<ScottK> Debian may move to a later version due to freeze getting delayed, but that shouldn't change what we do for Lucid.
 * slangasek nods
<ccheney> you know those drug fact sheets... read those before taking the meds
<ccheney> because sometimes the drugs mess with your brain and you don't read them clearly enough and then you have issues, heh
 * ccheney will probably have to take off tomorrow and go back in to the doctor, the drug he was given is causing one of those immediately discontinue use side effects :-\
<lucent> ccheney: "Discontinue use if experiencing the urge to license software with the CDL" ?
<lucent> that one?
<ccheney> lucent: no, bad CNS effects, etc
<ccheney> and my wife claims more agitation than usual, heh
<ccheney> which is a symptom listed
<ccheney> and muscle pain :-\
<ccheney> feels like i really overdid it in the gym without barely walking around
<ccheney> the part i'm most worried about the CNS issues with my right wrist
<twb> Central Nervous System?
<ccheney> twb: yea
<lucent> ccheney: and seriously, I hope you are feeling better soon.
<ccheney> apparently some of the symptoms can end up being permanent if you are unlucky
<ccheney> the drug is ciprofloxacin (antibiotic)
<ccheney> lucent: i'm sure i will be ok, but the info about the drug online seems a bit scary
<lucent> yah
 * ccheney heads off to bed, ttyl
<lucent> do yourself and your CNS a favor, relax with some music and a book
<ccheney> yea typing in my present condition is probably not too good an idea, heh
<jdong> ccheney:you should be okay with the cipro.... the only common "yikes help!!" side effect you should watch out for is swelling/tender tendons / painful joints....
<jdong> (not a doctor, but have been on cipro before and had the adverse reaction)
<twb> See, I'm "old school".
<twb> My view is broadly that if you get sick, you ought to bloody well be sick, not try to weasel out of it with drugs
<nixternal> unless they are illegal drugs
<twb> nixternal: that's just economics
<nixternal> hahahahaha
<nixternal> black market baby
<twb> Having said that, I do take a lot of capsaicin and caffeine.
<twb> But more for recreation than medical reasons.
<nixternal> I don't take anything, as there is enough smog here in chicago to give you a great buzz
<twb> Heh, like London in `52.
<jdong> twb: yeah, I've got a degenerative connective tissue disorder, and I've seen the brink of death before and happily submit to my fancy schmancy genetically engineered medicine :)
<twb> I've been hospitalized with asthma a few times, but I doubt that really counts.
<jdong> I don't feel one really gains anything from the "hmm let's wait and see" approach...
<jdong> I don't know the statistics off the top of my head for how many people per year die from sepsis due to bacterial infection going into the bloodstream... but I have a feeling it's not a pretty number
<jdong> but anyway, totally offtopic for this channel!
<twb> I bet it's smaller than the number killed in auto accidents
<twb> At least in the first world
<jdong> granted, yes.
<jdong> but preventable deaths are preventable deaths IMO
<jdong> every one counts.
<twb> You could prevent auto accidents by removing all the autos :-P
<jdong> now that's not as practical as a bit of levaquin love, is it? :)
<jdong> (or at least a trip to the doc for a blood culture)
<twb> NFI, I'm not a materials scientist.
<dholbach> good morning
<mvo> hey dholbach
<dholbach> hola mvo!
<ogra> hmm, my system started to massively misbehave since the last upgrade
<toabctl> hi
<ogra> while i have an 8.9second boot (http://people.canonical.com/~ogra/osiris-lucid-20100226-4.png) i seem to end up at the wrong console (X cursor sits on black screen) switching consoles gets me to a running desktop with a keyring question waiting for input ...
<ogra> if i put in the PW i get dropped back to gdm
<twb> ogra: known lucid issue
<twb> (Re wrong tty by default)
<ogra> ah, k
<twb> I don't have the ticket number handy, sorry
<ogra> for the keyring i thought there was an upload though
<twb> I don't use GUIs, so I can't help you with the other part.  You probably want to ask #ubuntu about it.
<ogra> lol
<ogra> surely not :)
<ogra> but thanks for the hint :)
<ogra> seb128, morning
<seb128> hi ogra
<ogra> seb128, did you expect all keyring issues to be fixed with your last upload ? (on i386 that is)
<seb128> ogra: no
<ogra> seems i have a keyring prompt that kills my X session after entering the PW (just upgraded)
<ogra> ok
<seb128> I don't expect any issue to be fixed out of the "don't ask to create a keyring"
<seb128> you get x crashing on enter
<ogra> ah, good, then i'll file a new bug after next reboot
<seb128> seems rather this plymouth issue
<ogra> yep
<ogra> yeah, i also end up on the worng tty it seems
<seb128> uninstall plymouth
<ogra> will do (cant reboot atm to verify though)
<ogra> at least i got an 8.9 sec boot now ;)
<seb128> nice
<seb128> cjwatson, hi
<seb128> cjwatson, I opened bug #528290 about the segfault
<ubottu> Launchpad bug 528290 in ubiquity "crashes after the installation summary" [Undecided,New] https://launchpad.net/bugs/528290
<seb128> it doesn't have too much detail for the moment but I will try to get some later
<seb128> seems I've been lucky yesterday to get my install done
<seb128> it keeps crashing again since
<Ixan> cjwatson: followup to #526405 it's still broken :/
<Ixan> what's the proper conduct for reopening a bug? i opened one, there was a patch and it was marked as fixed, but a new bug appeared on the same topic. should i change from fix released to new? or just get out of Dodge
<azeem_> is it a new bug, or the same bug?
<Ixan> same bug, more or less
<cjwatson> Ixan: if you're kriberg on Launchpad, then from your comment on that bug, it would be best to open a new one
 * cjwatson prefers not to have a bug morph between crash causes
<ev> could I get another pair of eyes on http://paste.ubuntu.com/384362/ - does that look reasonable?
<cjwatson> the motivation seems OK to me and your control fields do what you say on the tin^Wchangelog
<seb128> cjwatson, ev: does running ubiquity from an install work correctly?
<seb128> I'm think it will be easier to install debug packages, valgrind etc on an install
<cjwatson> definitely not guaranteed
<ev> seb128: running ubiquity from an install wont work as you don't have /rofs (the aufs read-only mount of the squashfs)
<cjwatson> the partitioner in particular is likely to have trouble, and it will feel entitled to modify bits of configuration in /etc
<ev> cjwatson: thanks
<cjwatson> oh and that
<cjwatson> you could try a live image on a usb stick with persistence?
<seb128> "with persistence"?
<cjwatson> usb-creator has a slider for how much space on the stick you want to allocate as persistent storage, in other words space for work done while in the live session that won't be discarded on reboot
<seb128> oh ok, thanks
<seb128> the key I'm using is a 8G one
<seb128> so I can easily do that ;-)
<statik> doko, thank you very much for the oprofile upload
<seb128> cjwatson, I don't know if that's luck but I didn't get the crash this time after moving the slideshow dir away
<cjwatson> I was wondering if it might be related to the fact that the slideshow's currently broken
<cjwatson> ev is fixing that by way of moving to po4a
<seb128> still weird that it crashes
<seb128> but I don't know how the slideshow thing is working
<seb128> and it could mess up the ubiquity state by being broken
<cjwatson> it uses python-webkit
<cjwatson> so I can believe that that could crash
<doko> statik: still in binary NEW
<seb128> would the slideshow crashing take ubiquity down with it?
<cjwatson> it's in the same process, so yes
<seb128> cjwatson, ok, it seems to be something with the slideshow, I get the crash every time and didn't get it 3 times in a row without slideshow
<seb128> I put the slideshow back and it's crashing again
<cjwatson> ok, excellent, so the fact that the slideshow is currently known to be broken is probably implicated
<cjwatson> don't know if you noticed, but there's a slideshow parse error in the debug log
<seb128> yes I did
<seb128> that's what made me want to try without it
<cjwatson> which is because slides/index.html got flattened into one line by po2html, complete with JavaScript single-line comments
<cjwatson> which of course didn't work very well :)
<seb128> is there somewhere where I can download a correct index?
<seb128> just to see if replacing this one makes it not crash
<cjwatson> you can edit it and search for //, and do the obvious thing to unfold the line breaks
<seb128> ok, makes sense ;-)
 * seb128 tries
<ev> seb128: http://people.canonical.com/~evand/tmp/ubiquity-slideshow-ubuntu_15_all.deb
<seb128> ev: even easier ;-)
<seb128> thanks
<ev> sure thing
<ev> I'll be uploading something similar to that momentarily
<ion> Hmm. Why is the https://launchpad.net/ubuntu/+source/apt-mark-sync package not in lucid?
<Ng> ion: http://www.mail-archive.com/ubuntu-motu@lists.ubuntu.com/msg06320.html may be relevant to your interests
<ion> I guess i should just get it to Debian.
<ion> Thanks for the link
<mvo> ion: what is the problem with apt/aptitude? they should share the same db, at least they did in the past
<ion> mvo: They have switched to the same db since, but what i personally really want is to sync the debfoster db to the apt/aptitude one, since they donât offer debfosterâs functionality. Iâve been thinking of perhaps implementing something like debfoster in aptitude, but so far itâs just an idea.
<mvo> ok
<seb128> ev, cjwatson: the new slideshow version doesn't fix the crash
<ev> bah
<ev> seb128: what happens when you run the following: /usr/lib/webkit-1.0-2/libexec/GtkLauncher "file:///usr/share/ubiquity-slideshow/slides/index.html"
<ev> seb128: or if you've selected a locale, /usr/lib/webkit-1.0-2/libexec/GtkLauncher "file:///usr/share/ubiquity-slideshow/slides/index.html#locale=fr"
<ev> errr
<ev>  /usr/lib/webkit-1.0-2/libexec/GtkLauncher "file:///usr/share/ubiquity-slideshow/slides/index.html#?locale=fr"
<seb128> ev: segfaulty
<seb128> in the same function than ubiquity
<seb128> same stacktrace
<seb128> ev: so I guess iz webkit bog
<seb128> not ubiquity
<seb128> cjwatson, ^
<ev> hooray (sort of)
<seb128> that will make it much easier to debug, let me see if it crashes on my work machine too
<seb128> in which case I can talk to the webkit guys
<cjwatson> seb128: cool, thanks
<seb128> $ /usr/lib/webkit-1.0-2/libexec/GtkLauncher
<seb128> Erreur de segmentation (core dumped)
<seb128> go webkit go
<seb128> cjwatson, ev: ok, webkit guys have been useful
<seb128> seems to be bug #413994
<ubottu> Launchpad bug 413994 in enchant "enchant zemberek backend cause sylpheed crash" [Medium,Confirmed] https://launchpad.net/bugs/413994
<seb128> or similar issue
<seb128> I verify on ubiquity now
<seb128> but that fixed /usr/lib/webkit-1.0-2/libexec/GtkLauncher crashing
<seb128> that = moving zemberek.so away
<cjwatson> ah
<seb128> cjwatson, ev: ok, seems to be that indeed, ubiquity stopped crashing too
<seb128> cjwatson, ev: I will fix enchant
<ev> hooray!
<ev> seb128: thanks for tracking that down
<seb128> where "fix" there seems to be "stop using zemberek which is known to be broken"
<seb128> ev: np
<cjwatson> I recall seeing bugs about zemberek brokenness in the past
<seb128> the one I just pointed is there for a while
<ttx> seb128: I think I hit https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/526796 -- do you need input on it or is it a well-known issue ?
<ubottu> Launchpad bug 526796 in gnome-panel "No sound applet on the gnome panel" [Low,Incomplete]
<seb128> ttx, do you have an indicator applet on your gnome-panel?
<ttx> seb128: yes
<seb128> ie the one with the messaging icon
<seb128> ttx, are you sure?
 * ogra wonders if that happens to people that dont use update-manager 
<ttx> seb128: I can screenshot it if you want to check :)
<seb128> ttx, you have the messaging menu which lists empathy, gwibber, etc
<seb128> ttx, yes please ;-)
<ttx> seb128: lists empathy, evolution
<seb128> ttx, is indicator-sound installed?
<ttx> seb128: no
<seb128> ttx, ok then that's your issue
<seb128> ogra: it's a recommend so it should not
<seb128> ogra: if you don't turn recommends off...
<ttx> seb128: it's a lucid alpha2 install, fwiw
<seb128> ttx, did you upgrade using update-manager?
<ttx> seb128: no, installed lucid alpha2 then apt-get dist-upgrade every 2-3 days
<seb128> I blame apt then, check with mvo
<ttx> seb128: ok :)
<seb128> indicator-applet recommends indicator-sound
<mvo> ttx: how/when did you upgrade?
<seb128> and we install recommends by default
<seb128> mvo, will upgrading a package pulls in new recommends?
<ttx> mvo: installed from alpha2 ISO, then apt-get dist-upgrade every 2-3 days
<seb128> mvo, like indicator-applet got a recommends on indicator-sound
<ttx> fwiw "sudo apt-get install --reinstall indicator-applet" doesn't get me indicator-sound, I have to install it manually.
 * ttx restarts session to check fix
<ttx> seb128: ok, it's back, thanks. Will comment on the bug
<mvo> ttx: if you can attach your terminal log and your apt history, that would be nice (both in /var/log/apt/)
<ttx> mvo: done
<mvo> ttx: what is the bugnumber?
<ttx> mvo: https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/526796
<ubottu> Launchpad bug 526796 in gnome-panel "No sound applet on the gnome panel" [Low,Incomplete]
<mvo> thanks
<emgent> salut sabdfl
<sabdfl> hi emgent
<ttx> seb128: in the same vein, my rhythmbox status icon also disappeared recently (when I run RB, I have no icon up there anymore) -- is it expected ?
<ogra> ttx, do you have rhythmbox-plugins installed ?
<ttx> ogra: apparently not. Purging/Installing rhythmbox pulls it in, though.
<ogra> :)
<ogra> you server guys ...
<ogra> use update-manager :) it saves the world !
<ttx> ogra: I'll consider it :)
<mvo> ttx: there is also sudo apt-get install --fix-policy
<mvo> ttx: that should give you missind recommends
<ttx> mvo: ah thanks, that's the one I couldn't remember :)
<mvo> its not exactly obvious ...
<mvo> sounds like something for computer-janitor
 * ttx realizes he is missing 23 packages
<seb128> mvo, are new recommends meant to be auto pulled in?
<mvo> yes
<seb128> ok, I was not sure
<seb128> not sure it doesn't work for rhythmbox and indicator-applet then
<mvo> seb128: the trouble is if they are not installable it will forget about them, i.e. if you have pkg A with new recommends B and at the point you install A B is not installable it will forget about B
<seb128> that's not the first user to tell me indicator-sound or rhythmbox-plugins don't get installed
<seb128> mvo, ah I see
<mvo> that might explain it
<seb128> might be an issue rather for unstable users then
<mvo> otherwise I'm happy to debug
<mvo> yeah
<seb128> mvo, we just need to make sure those get installed in test upgrades
<seb128> mvo, do you have a checklist somewhere?
<seb128> or a diff between upgraded system and new install?
<mvo> seb128: no, but I think I could generate one, if the pkglist of a new instlal is available somewhere, that would make it massively easier
<seb128> mvo, will you take care of reassigning that bug where it should be?
<mvo> seb128: I can do that, but I'm not sure at this point where it belongs to
<seb128> mvo, apt or NOTABUG?
<mvo> yeah
<mvo> seb128: hm, lp does not let me login, can you re-assign to apt please (for now)
<seb128> mvo, ok
<ccheney> jdong: yep having those
<ccheney> jdong: even 12hr+ after last dose my muscles are still hurting :(
<alexmoldovan> bryceh: Hello, I just finished testing a laptop with a Core i5 M520 that uses the integrated CPU graphics and it works perfectly. Even the acceleration. Thanks!
<jibel> mvo, hi, I pushed a workaround for bug 282995 . commited to my branch r1713
<ubottu> Launchpad bug 282995 in synaptic "[quicksearch] New 'quick search' is unable to search for dashes '-'" [Low,In progress] https://launchpad.net/bugs/282995
<mvo> jibel: thanks, I check it out
<jibel> mvo, I talked with the xapian's guys this morning about it and searching for a term with an hyphen using a prefix is not possible with xapian :(
<jibel> mvo, so searching for a part of package name e.g pkg:xserver-xo is a bit problematic.
<mvo> jibel: oh :( sad to hear - are there plans from them to fix that?
<jibel> mvo, see comment#16 in the report. We need to talk to ojwb to get his opinion.
<hyperair> who should i subscribe to a bug to poke a retry build button for a package lying in main?
<hyperair> u-m-s or u-a?
<hyperair> or could someone here with super cow powers please poke it?
<hyperair> https://launchpad.net/ubuntu/+source/f-spot/0.6.1.5-2/+build/1465680
<sistpoty|work> hyperair: poked
<hyperair> sistpoty|work: thanks =)
<sistpoty|work> hyperair: only ia64?
<sistpoty|work> yqw
<sistpoty|work> -q
<hyperair> sistpoty|work: yes.
<magcius> Is UNR dead?
<ogra> magcius, yes, it was renamed
<magcius> ogra, to what?
<ogra> its the UN Edition now
<magcius> Alright...
<ogra> (UNE)
<cjwatson> I was going to say "no, it was renamed" :-)
<ogra> heh
<magcius> It looks like there are two forks of the Launcher
<magcius> One uses EFL. What does the other use?
<ogra> there are two launchers, right
<ogra> clutter and efl
<magcius> Alright, Clutter.
<magcius> Is there a reason that Canonical developed their own Netbook distribution instead of contributing to development of Moblin and such>
<magcius> Also, why not help build a non-OpenGL backend for Clutter?
<superm1> mvo, would you mind if i picked your brain a little bit?  I'm seeing this happen: http://paste.ubuntu.com/384146/ on a 'dpkg -G -i blah.deb' call.  Here's the postinst: http://bazaar.launchpad.net/~dell-team/dell-recovery/trunk/annotate/172/debian/postinst .  Interestingly enough, the grub.cfg is fully populated even though the stdout from the dpkg call doesn't agree so.   AFAIK, nothing is sending  SIGTERM to the dpkg call.  So could you se
<superm1> e any other scenario causing that to happen?
<slangasek> seb128: I gather appindicator has something to do with why my volume control no longer stays put on my panel across logins?
<jdong> ccheney: oh ouch, man, hope that clears up soon for you :-/. Yeah, cipro/levaquin are good antibiotics except when THAT happens. I feel your pain -- get better soon.
<seb128> slangasek, most likely yes
<slangasek> seb128: so... is there an ETA on having whatever the "right" mixer is landing, so I don't have to keep readding the old one by hand?
<seb128> slangasek, ok maybe I didn't parse you right
<seb128> slangasek, the right mixer should be there
<seb128> slangasek, is indicator-sound installed?
<slangasek> seb128: yes
<seb128> slangasek, you have the indicator applet on your config?
<seb128> slangasek, the one which does the message indicator thing
<seb128> slangasek, all indicator go in that container
<seb128> indicator*s*
<slangasek> seb128: I have the message indicator and session indicator, yes
<mvo> superm1: hm, is this reproducable?
<mvo> superm1: or just happend once?
<superm1> mvo, it is happening on 4.2% of factory shipped systems (that dpkg command runs as a late command)
 * Keybuk wants a department-of-homeland-security-alert-level-indicator
<slangasek> seb128: running /usr/lib/indicator-sound/indicator-sound-service by hand, it aborts immediately; thanks, that gives me enough info to file a bug
<superm1> mvo, so when it's happening it's a bit hard to investigate or speculate
<seb128> slangasek, np
<mvo> superm1: i see, hm
<mvo> superm1: I guess you can not run update-grub or the postinst with sh -x ?
<superm1> mvo, if i was able to reproduce it at my desk, that was the first inkling I had, but it's only being reproduced at the factories.
<superm1> i've tried interrupting the late_command to just rerun update-grub and the reload for dbus 10k times hoping to hit it, but alas still nothing
<superm1> so i'm starting to wonder what would happen if one of the children in the postinst got a SIGTERM, does it flow up to dpkg too?  or just cause dpkg to exit with a non-zero return code?
<Keybuk> superm1: signals aren't STDs
<superm1> haha
<cjwatson> there's no guarantee that the "Terminated" you're seeing there is from dpkg
<Keybuk> they're only sent to one process
<cjwatson> could be from any of them
<Keybuk> (the fact that there are extremely complicated rules about which process that is when a terminal is involved tends to confuse people)
<superm1> so without set -x in each, probably won't be able to figure much out then
<cjwatson> and yes, dpkg would probably get a non-zero return code, provided everything in the stack is handling exit statuses correctly
<superm1> cjwatson, hm, but if something in the postinst received the TERM, dpkg would have done something more like this though: dpkg: error processing dell-recovery (--install):
<superm1>  subprocess installed post-installation script returned error exit status 143
<Keybuk> superm1: depends on set -e
<Keybuk> if the postinst isn't set -e, the shell will just execute the next line in turn
<Keybuk> etc.
<superm1> well that postinst is launched as #!/bin/sh -e
<seb128> hyperair, please don't open bugs for builds that need a retry
<hyperair> seb128: er sorry.
<seb128> hyperair, we have better ways to track things which fail to build
<cjwatson> superm1: could be a script it calls that isn't correctly set -e all the way down, though
<hyperair> seb128: how?
<cjwatson> or even || true
<geser> hyperair: you know http://qa.ubuntuwire.com/ftbfs/ ?
<Keybuk> right, there's lots of shell things that "consume" exit statuses, like ||, &&, if, while, etc.
<hyperair> geser: well yes. but nobody knows if that one just needs a "retry build" or needs more poking without reading the logs.
<Keybuk> cjwatson: did I tell you about the time I got a patch from someone changing a line to "if something || true; then" to avoid "the shell exiting" ?
<superm1> okay well i'll get a more concise env together to capture that information
<seb128> hyperair, in any case f-spot is queued for build
<cjwatson> Keybuk: heh
<hyperair> seb128: thanks.
<seb128> hyperair, so your build can be closed
<seb128> hyperair, was not me
<cjwatson> Keybuk: I take it you replied with 'man bash'? :-)
<hyperair> eh?
<seb128> hyperair, well I just looked to give it a kick and it's waiting for build
<seb128> hyperair, somebody did it before apparently
<hyperair> i see.
<hyperair> whoops
<hyperair> sorry for the noise
<seb128> np
<seb128> <hyperair> or could someone here with super cow powers please poke it?
<seb128>  https://launchpad.net/ubuntu/+source/f-spot/0.6.1.5-2/+build/1465680
<seb128> <sistpoty|work> hyperair: poked
<seb128> <hyperair> sistpoty|work: thanks =)
<seb128> <sistpoty|work> hyperair: only ia64?
 * sistpoty|work likes that button :)
 * hyperair facepalms. i feel old and forgetful
<seb128> hyperair, you knew it had been retried apparently since you asked there for it...
<hyperair> seb128: what?
<hyperair> seb128: i filed the bug before poking
<seb128> hyperair, well then you could have closed the bug once somebody kick the retry ;-)
<geser> hyperair: for give-backs in universe you can do them yourself (through the web ui or the ubuntu-build script) and for main asking here is usually enough (if you don't it at unusual times e.g. middle of the (european) night or on weekends)
<seb128> kicked
<hyperair> seb128: sorry, like i mentioned, i've a bad memory and i'm poking several packages at once.
<hyperair> geser: okay cool.
<seb128> hyperair, ok, no problem, just avoid opening bugs for those
<seb128> mention it on IRC
<seb128> usually that's enough to have those picked
<hyperair> seb128: sure
<seb128> slangasek, you can use /usr/lib/libindicator/indicator-loader /usr/lib/indicators/3/libsoundmenu.so
<seb128> slangasek, libindicator-tools has the test software
<slangasek> seb128: well if I do that, it runs... :)
<slangasek> (though in a goofy window, not in my panel)
<sebner> seb128: are there pop-ups (notifications) planned for the AppIndicator stuff?
<seb128> sebner, what popup?
<seb128> sebner, we have notify-osd?
<sebner> seb128: I mean if you move your mouse over the old icons you get small pop-ups, transmission speed, musikplayer -> track + minutes etc
<seb128> slangasek, you are sure you have the indicator applet on your gnome-panel?
<seb128> slangasek, ie you run rhythmbox you see it as an indicator?
<seb128> or the bluetooth icon
<seb128> (indicators are menus, you can see the background colored when the menu is open to compared with old icons)
<slangasek> seb128: er, I don't know, I have indicators on my panel - indicator-session, indicator-me, etc?
<seb128> slangasek, well those are indicator session
<seb128> there are 2 applets
<seb128> (yes confusing)
<slangasek> ok, apparently I didn't have indicator-applet here
<seb128> ok, what I though ;-)
<seb128> that used to be the message indicator only
<seb128> ie the envelop icon
<seb128> but other things dock there now
<slangasek> so what was supposed to auto-add it, and why is that different than what's preventing gnome-volume-control-applet from running?
<seb128> what? it's supposed to be there since jaunty
<seb128> we will have to make sure to add it back though
<seb128> I guess many user didn't like the messaging thing and remove the applet
<seb128> removed
<slangasek> I don't think I've ever seen this before
<slangasek> maybe it looked very different
<seb128> the messaging indicator?
<seb128> it did
<seb128> it only had text, no icon
<seb128> and was like
<seb128> Empathy
<seb128>   Description
<seb128> Gwibber
<seb128>   Description
<seb128> and that's where you im messages go if you use an im client
<seb128> slangasek, anyway to reply to your other question we stop autostarting gnome-volume-control-applet
<seb128> since we have this indicator-sound
<sebner> seb128: I have the indicator-applet, e.g Transmission is already updated and the icons (horrible) looks the same as the others but there don't appear a pop-up if I mouse-over it which is really annoying
<seb128> and indicators are auto-loaded
<seb128> sebner, tooltip?
<seb128> sebner, no, there is no tooltip planned there
<sebner> seb128: ah, that is the word that I was looking for :D
<slangasek> seb128: "stop autostarting" - well how come if I start it by /hand/, and save my session, it doesn't come back on next login?
<seb128> the usually way is to click and have the info in the menu
<seb128> slangasek, that I don't know
<seb128> slangasek, did you try to add it in the session capplet?
<seb128> rather than saving your session?
<sebner> seb128: for transmission I have to do 2 clicks, the app maximizes and I have to minimize it again, that's horrible and pretty annoying compared to the tooltip from just moving the mouse over the icon
<seb128> sebner, you have to do that for doing what?
<slangasek> seb128: no, the session capplet offends me :)
<sebner> seb128: I was just an example. For doing what? For getting some information quickly evidently ...
<sebner> *it
<seb128> sebner, info should be in the menu
<seb128> sebner, you have the exact same mouse movement to do
<seb128> just to press your finger on the mouse button
<seb128> shouldn't be too much extra work
<sebner> seb128: and I have to close the app (e.g transmission) again, that is much extra work
<hyperair> seb128: i made a lot of noise about tooltips in #ayatana the other day.
<sebner> just to get some info
 * sebner strongly agrees with hyperair 
<hyperair> seb128: the verdict is that, sadly, lucid won't haev tooltips.
<seb128> sebner, why would opening the menu open transmission?
<hyperair> i meant to ping sebner by the way
<seb128> hyperair, what I was saying, why would it, menu bar don't have tooltips
<sebner> seb128: I have to click on "Show Transmission" to see some information ;)
<seb128> sebner, well that's a bug
<hyperair> seb128: let's consider it this way. menu bar buttons have text.
<seb128> sebner, infos which were in the tooltip should be in the menu directly
<sebner> seb128: Clicking on it is buggy too imho
<sebner> seb128: oh, Ic
<hyperair> seb128: given that fact, the new application indicators are more like toolbar buttons than menu buttons, don't you agree?
<hyperair> seb128: toolbar buttons have icons.
<hyperair> and why? because icons aren't always intuitive to everyone.
<hyperair> there are daft people around like me who don't understand what all the icons mean.
 * sebner doesn't like that all Apps now have the same icon (color)
<hyperair> especially if you switch your icon theme and suddenly get a new bunch of icons for everything.
<seb128> well they had the same issue with notification icons
<hyperair> seb128: what issue?
<hyperair> seb128: and what is "they"?
<seb128> non obvious icons
<seb128> those others who don't know what those icons are
<seb128> they didn't change between notification area and appindicator
<seb128> they are the same icons
<hyperair> seb128: right. but notification area has tooltips which tell me what the icon is.
<seb128> hum, need to run for some minutes
<seb128> hyperair, often they don't no, they give you random infos
<hyperair> seb128: now i have to open a menu, and depending on what the contents are, i may or may not understand what that app is.
<seb128> which you get now by opening the menu too
<hyperair> seb128: that is besides the point.
<seb128> you have the same info in the menu than the tooltip
<seb128> or you should
<seb128> anyway I'm not the designer
<magcius> Where can I find the source for the UNR EFL UI?
<hyperair> seb128: the point is that tooltips have been there as "alt text" for icons.
<seb128> but I've no real issue with the change
<hyperair> that they have been misused is another thing entirey.
<hyperair> entirely
<LaserJock> magcius: netbook-launcher-efl I think
<magcius> LaserJock, no project on LP
<geser> while talking about missing tooltips, is there a way to know what rhythmbox is currently playing without having to open the main window?
<LaserJock> magcius: that's the package, you can do apt-get source netbook-launcher-efl
<magcius> ah, sorry, I don't actually use Ubuntu
<cjwatson> magcius: http://archive.ubuntu.com/ubuntu/pool/main/n/netbook-launcher-efl/
<LaserJock> magcius: according to the package, https://launchpad.net/launch-lite-proj is the Launchpad project
<cjwatson> you want the newest .dsc, .diff.gz, and .orig.tar.gz
<magcius> Aha, thanks
<cjwatson> dpkg-source -x foo.dsc # if you have dpkg-source
<seb128> geser, not yet but that should go in the menu too probably
<magcius> hmm
<magcius> it looks like the EFL launcher uses a cairo backend for EFL, is that right?
<magcius> mterry, I think you'd be the guy to ask
<mterry> magcius, probably.  I inherited the current codebase, so I'm not super familiar with EFL, but I try
<mterry> magcius, it does
<mterry> magcius, (in answer to your question)
<magcius> mterry, alright, so it doesn't use the EFL software renderer?
<mterry> magcius, I don't think so
<magcius> mterry, do you know anything about Clutter?
<mterry> magcius, a bit
<magcius> alright
<magcius> Is there a reason it was developed using EFL instead of using cairo directly? Do you use any other parts of the EFL library?
<magcius> mterry, ^ ?
<mterry> magcius, oh, sorry.  Uhm, it was developed that way before I got involved.  We do use other EFL bits and widgets and theming support
<magcius> mterry, who developed it before you? Was it someone at Canonical?
<mterry> magcius, yeah, Gustavo Sverzut Barbieri <barbieri@profusion.mobi> did most of it
<seb128> slangasek, bug #528589 is NOTABUG
<ubottu> Launchpad bug 528589 in indicator-applet "indicator-sound doesn't start, exits when started by hand" [High,New] https://launchpad.net/bugs/528589
<seb128> slangasek, applet are not started, they are part of your config
<seb128> the indicator applet one is part of the default profile since jaunty
<seb128> and added on upgrade for upgraders
<seb128> slangasek, it's most likely that you got it at some point and changed your config and forgot about it
<hyperair> is lucid's libtool misbehaving?
<hyperair> i'm looking into cone's ftbfs, and it seems that no matter what i do, libtool complains about a version mismatch
<Laney> cjwatson: is grub2 supposed to work on md partitions with A3?
<Laney> ubiquity bombed because it couldn't install grub
<slangasek> seb128: hmm, ok; I guess I removed it because I could never figure out what it was ;)
<cjwatson> Laney: supposed to ...
<Laney> cjwatson: I haz logs
<Laney> http://paste.ubuntu.com/384601/
<cjwatson> Laney: I can haz bug?
<cjwatson> Laney: (did you select /dev/md0p1 explicitly as the grub installation target, or did it select that for you?)
<Laney> I didn't change what it wanted
<Laney> I think it said /dev/md0, even
<cjwatson> Feb 26 19:14:52 ubuntu grub-installer: info: Installing grub on '/dev/md0p1'
<cjwatson> it seems a bit confused about something else too.  do you have a /boot/grub/device.map in the target system?
<cjwatson> (ideally, you shouldn't)
<Laney> no
<cjwatson> ok, goo
<cjwatson> d
<Laney> well, there is another Ubuntu partition, maybe that confused it?
<cjwatson> shouldn't have
<Laney> who wants the bug? ubiquity or grub2? (I can't install grub manually either)
<seb128> hyperair, run autoreconf
<cjwatson> Laney: grub-installer for the moment, I think
<hyperair> seb128: that's what i've been doing.
<cjwatson> I'm not quite sure, I'll have to look into it in detail, probably not on a Friday evening
<Laney> sure
<cjwatson> Laney: could you make sure to attach /var/log/partman too?  if you still have the live session running, 'ubuntu-bug ubiquity' will do the job
<Laney> I just need to file it while I still have the info
<seb128> hyperair, auto*re*conf?
<Laney> will do, then I'll triage it to grub-installer
<Laney> thanks for advice
<seb128> hyperair, what package is that?
<hyperair> seb128: yes, auto*re*conf.
<cjwatson> wait, ubiquity?  that doesn't actually support raid
<hyperair> seb128: cone.
<cjwatson> not well, anyway
<Laney> I manually selected the partition
<cjwatson> after you've filed it, try with d-i to see if it acts any better, maybe?
<hyperair> seb128: it seems to be a bug common with combined autohell trees.
<cjwatson> ok, well I guess it might work
<hyperair> seb128: as in nexted autoconf
<Laney> well grub cannot install the bootloader in any case
<hyperair> seb128: could be out of date or something.
<cjwatson> Laney: let me know in the bug how I'd go about setting up a matching system, if you can
<Laney> but I will try d-i (I'll have to find out how to make it use an existing md array though)
<cjwatson> Laney: yeah, maybe don't bother trying d-i, you're probably right and it shouldn't matter
<seb128> hyperair, the build log suggests it runs aclocal and autoconf not autoreconf
<hyperair> seb128: this is a local build.
<seb128> hyperair, usually we want to make sure to run none or things in right order
<hyperair> seb128: i've been messing around with the source tree.
<seb128> k, dunno then
<hyperair> seb128: wait, you mean the build already runs aclocal and autoconf?
<seb128> hyperair, yes
<seb128> hyperair, see http://launchpadlibrarian.net/37421099/buildlog_ubuntu-lucid-i386.cone_0.79-2_FAILEDTOBUILD.txt.gz build log
<hyperair> oh for the love of..
<hyperair> screw cdbs.
<seb128> hyperair, it's not the build, it's autotools
<hyperair> and autohell >_>
<hyperair> make that badly implemented autohell by stupid upstreams.
<seb128> hyperair, usually that's happening when touching some configure or makefile
<seb128> you want to use maintainer mode to avoid that
<seb128> or don't touch autotools files in patches...
 * hyperair takes a look at the patch
<hyperair> ffuuuu
<cjwatson> or manually run around touching files after applying patches (ugh)
<cjwatson> or ACLOCAL=true AUTOCONF=true etc. :-)
<Laney> cjwatson: that's weird, I just installed grub-pc again and it worked Â¬_Â¬
<Laney> (in a chroot on the live cd)
<Laney> this was after installing grub. The device.map it created must have fixed things.
 * Laney writes all this down
<Laney> ok, filed 528670, hope that's alright
<cjwatson> good start, thanks.  the weird bit may be that you're using partitioned RAID.
<Laney> yeah I recently blew away all of the funny business
<cjwatson> normally (and the way the installer sets things up) you have RAID physical volumes on partitions, assemble a disk-like object (e.g. /dev/md0) on those, and write a filesystem to /dev/md0 directly
<cjwatson> but you have /dev/md0p1
<cjwatson> so it may not so much be that md support in grub isn't there, but that partitionable md support in grub isn't there
<cjwatson> as I say, will have to look into it more, that's just from a first look
<Laney> sure, I'll leave it with you
 * Laney restarts
<hyperair> seb128: it works now, thanks for pointing me in the right direction.
<seb128> hyperair, you're welcome, what did you change?
<hyperair> seb128: DEB_CONFIGURE_EXTRA_FLAGS = SENDMAIL=/usr/sbin/sendmail
<hyperair> seb128: and drop the patch.
<seb128> ok ;-)
<hyperair> seb128: now then, i've got a DD to fry.
<hyperair> honestly, patching configure and configure.in to change the patch of something in AC_PATH_PROG.
<hyperair> i'd have expected more from a DD.
<hyperair> E: cone: possible-gpl-code-linked-with-openssl
<hyperair> lolwut?
<xorl> Hey, there a quick way to package up a custom init scripts without a build script so I can maintain them debian style?
<xorl> so I have a custom init script, custom config files, just want to package em up in a deb, I am familiar with the debian package, just not 100% on the rules, not sure how to package it up with just config files when there is no make environment.
<cjwatson> foo.conf in your package, 'foo.conf etc/init' in debian/foo.install, /usr/share/doc/debhelper/examples/rules.tiny in debian/rules
<xorl> ah
<cjwatson> debian/foo.install is processed by dh_install; see its manual page for more information
<hyperair> wasn't there some plan to make a dh_installinit or something?
<xorl> perfect
<xorl> cjwatson: thanks!
 * xorl goes to rtfm
<cjwatson> there is a dh_installinit, actually yes you probably ought to use it
<cjwatson> debian/foo.upstart, in that case
<cjwatson> (instead of foo.conf and debian/foo.install)
<hyperair> or debian/foo.init
<cjwatson> right.  see dh_installinit(1)
<cjwatson> anyway, point is that make is entirely optional :)
<xorl> sweet, nice, thanks for the tips guys!
<xorl> Yeah, was confused for a second, thanks for the clarification, I was about to wonder off to a world of too much work to do something stupid simple
<cjwatson> sorry for misdirecting you to dh_install first off, not sure what I was thinking there; but on the other hand you can use that technique for other things
 * slangasek does the dh7 dance
<slangasek> (it's a very short dance, but very effective)
<cjwatson> slangasek: dh(1) use now at 19.47% in unstable, up from 12.69% when my records began in September
<slangasek> muhaha
<cjwatson> (corresponding cdbs numbers: 24.97% in September, 25.06% today)
<sebner> cjwatson: that's the bad part of your news :P
<xorl> hmm, I am making this more complicated for myself, just need to install a new mysql init, it's conf file and be on my way, using mysql-server as a guide (from the debian/* files) I think I have dug myself a hole.
<ccheney> jdong: they switched me to something different, not sure what yet, should have it in about an hour or so
<ccheney> jdong: the Dr seemed to think cipro can only cause tendon tears, not just joint pain, etc (which is also on the fact sheet)
 * ccheney thinks maybe he needs to find a better dr
<ccheney> he only switched me because i wanted him to, heh
<cjwatson> slangasek: http://people.debian.org/~cjwatson/dhstats.png; apologies for my inability to drive gnuplot prettily
<slangasek> wow, debhelper is that high a percentage?
<cjwatson> >97%
<cjwatson> interestingly, the raw number not using debhelper has increased by three since September; I'd expected it to drop
<ccheney> cjwatson: so manoj packages 3% of debian? :)
<cjwatson> the percentage has gone down though, 2.42% -> 2.3%
<slangasek> no, I have some packages I adopted from elmo that I haven't switched to dh7 yet :)
<cjwatson> ccheney: don't forget dexter ...
<cjwatson> I converted a Wichert package to dh7 recently
<cjwatson> oh, but I haven't uploaded that yet :)
<ccheney> cjwatson: ah
<cjwatson> I haven't quite dared to convert base-passwd yet
<ccheney> i need to convert my ubuntu specific stuff to cdbs/dh7
<lifeless> so, by using debhelper, do you mean calling dh_anything?
<cjwatson> lifeless: build-depending on debhelper
<xorl> cjwatson: that rules.tiny won't work stock will it?
<ScottK> For lots of packages it does.
<xorl> hmm, i have build-essential, devscripts installed, dh still not found
<cjwatson> you might be running hardy
<xorl> n/m
<ScottK> xorl: dephelper is none of those things.
<ScottK> dep/deb
<xorl> yeah, realized that, i spoke too soon :)
<xorl> error: must specify package since control info has many ()
<xorl> lovely
<cjwatson> xorl: you need to fix debian/control; you have no binary package stanzas in there
<cjwatson> (perhaps you need to *write* debian/control)
<xorl> I have debian/control with Package: mysql-st in there
<cjwatson> you've got something wrong - dpkg failed to parse it correctly
<jbebel> cjwatson, What's the difference between base-installer/kernel/image and base-installer/kernel/override-image?  The example preseed uses "image" and the server CD preseed uses "override-image".
<cjwatson> jbebel: override is a bit higher priority I think.  I forget the exact details, it was a while ago ...
<cjwatson> for most purposes I think you're ok to use image
<cjwatson> could one of the other archive admins process parted through NEW for me?
<cjwatson> I'd like to get the stuff that depends on it building
<slangasek> cjwatson: looking
<c_korn> is Ubuntu also invloved in the Debian GNOME bug hunt ? http://np237.livejournal.com/27754.html
<slangasek> cjwatson: accepted
<chrisccoulson> c_korn - we probably need a similar effort for gnome packages in ubuntu ;)
<diavel> hello
 * ccheney needs to learn how deb v3 works
<ccheney> anyone have a link that explains how the new stuff works?
<c_korn> chrisccoulson: wouldn't this double the effort ? the bugs will be opened in the upstream tracker. so ubuntu should also gain profit of it.
<chrisccoulson> c_korn, possibly. but we have significantly more bug reports on our tracker ;)
<c_korn> chrisccoulson: ok :) I will participate in the event. I think they will be happy to see some Ubuntu people helping Debian :)
<chrisccoulson> c_korn, yeah, i'm sure they will. thanks :)
<ccheney> cjwatson: do we have support for xz yet? looks like deb v3 supports it so we may to add it soon if we don't already
<ccheney> cjwatson: sounds like xz is a better version of lzma
<MTecknology> I just made a fix for a bug in the 'debian/' directory of xdm. Should I upload to revu, attach the debdiff, and assign it to the ubuntu-main-sponsors team?
<dyek> Hi! Where can I find pv-grub? Is there a package that contains this (Xen?) utility?
<ebroder> Are any core-devs around that could take a look at bug #497606? We just deployed CUPS 1.4 servers here, but have a lot of Hardy/Jaunty clients, so this bug is hitting us fairly hard
<ubottu> Launchpad bug 497606 in cupsys "lpstat in CUPS 1.3 can't list jobs on CUPS 1.4 servers" [Undecided,New] https://launchpad.net/bugs/497606
<cjwatson> slangasek: thanks
<cjwatson> ccheney: it went into dpkg trunk recently, but I'm not sure about that version for lucid yet
<ccheney> cjwatson: looks like the dpkg version in lucid should be fine (1.15.5) but not sure if launchpad would it handle it
<cjwatson> ccheney: launchpad uses current dpkg
<cjwatson> whether it handles the file extensions correctly I don't know, but that bit would be trivial
<cjwatson> I was actually thinking of http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=9bb208a8338253a1c9e1d0642cf1ef039a335951 and http://git.debian.org/?p=dpkg/dpkg.git;a=commit;h=54be54799fd73850a6e869e3a8e270b35a9f7384, although I see now that the former is for binary packages not source packages
<cjwatson> and the latter is just dependency reduction
<ccheney> cjwatson: ah ok, yea it would be good to get xz support into our dpkg for lucid also
<ccheney> cjwatson: er binary support
<barry> doko: optimistic ping
#ubuntu-devel 2010-02-27
<ccheney> hmm i'm seeing the plymouth/X black screen bug consistently on my desktop
<ccheney> i have a radeon 4350
<dyek> Hi! Is there anybody using Ubuntu as Xen PV Guest OS for development uses? Is Xen (PV Guest) a general productivity tool? Or not?
<xorl> is anyone going to conquer the upstart scripts for apache2 on lucid? didn't see anything in the bug tracker about it, possible on the devel mailing list?
<ScottK> xorl: #ubuntu-server is probably a better place for that question.
<xorl> ScottK: ah, ok, just checking, do you know how the upstart thing works? I've written an upstart job corresponding with a conf file in /etc/init/ yet, it says unknown job still
<xorl> upstart guys are *extremely* quiet
<ScottK> No.  Sorry
<slangasek> xorl: are you trying to run it in a chroot?
<xorl> slangasek: no, i created my conf, created the symlink to /lib/init/upstart-jobs and nothing
<xorl> Is that not te proper way to do it? (or upstate-job) whichever that binary was
<xorl> I haven't found any good docs on it
<slangasek> xorl: the symlink to /lib/init/upstart-job isn't relevant.  the other likely possibility is if you have the job syntax wrong, upstart will ignore it
<xorl> ah
<slangasek> xorl: try turning on debugging with 'sudo initctl log-priority info', touch your job file (to get upstart to rescan), and check /var/log/syslog
<xorl> slangasek: ah! Thanks for the pointers, great help
<ion> xorl: It being the middle of the night may have something to do with âupstart guys being quietâ.
<kamalmostafa> james_w:  hi james --  bzr branch lp:ubuntu/gpredict   explodes, yielding an error message which includes your email address.   i'm sure you're thrilled!
<xorl> slangasek: thanks for the help earlier, got apache working with upstart now
<slangasek> xorl: so it was a job syntax issue?
<xorl> slangasek: yes
<xorl> well, stanza
<xorl> forgot to put an env in front of a variable
<slangasek> ah :)
<xorl> some more working and now I got apache working
<xorl> re-wrote the apache2 init script and made it work with upstart
<JrodDCx> does anyone have an idea what the light theme looks like ?
<t3rm1n4l> hi
<shawnboy> is this suitable place to ask general question regarding C compared to C++?
<Kano> hi, who is responsible for the lucid installer
<arand> I know cjwatson does a lot of installer work, there is #ubuntu-installer as well..
<sgnb> can some archive admin take care of #526067 and #527633 quickly, please? ... the OCaml transition is stalled because of them...
<persia> sgnb: Archive Admin lag time tends to be considerably longer over weekends, unfortunately.  Someone might see the backscroll, but if not, poke one of the rota volunteers on Monday.
<pecisk> hi people, during last days LiveCD testing I encountered CD reading errors on two independent computers. Is there any known bug about this? Both computers have Nvidia video card, and on second one I sucesfully logged in Xorg nouveau demo session
<cjwatson> sgnb: I've done the round 3 bug.  Do I need to wait a bit for those to build before doing round 4?
<sgnb> cjwatson: non... please proceed... thanks
<ubuntu> hi there guys. just a thing that crossed my mind: with the new gwibber api, shouldn't we be able to tweet/dent/share what we're currently listening to?
<danyR> directly from rhythmbox?
<cjwatson> sgnb: doing now, except for mldonkey which still appears to require an FFe ack
<cjwatson> at least thus indicates the current bug trail
<sgnb> cjwatson: ok, thanks
<ogra_cmpc> hmm, whats the equivalent to gnome-mount in lucid ?
 * ogra_cmpc needs to trigger a manual device mount thats apparently not recognized by udisks
<ogra_cmpc> pitti, did you recently try to attach your ebook reader to lucid ?
<bluefoxicy> Why does my sound card make a pop just before something makes sudden sound?
<crimsun> bluefoxicy: it's powering up. Are you using jaunty, karmic, or lucid?
<bluefoxicy> current release.
<bluefoxicy> /etc/debian_version says squeeze/sid
<crimsun> bluefoxicy: what does 'lsb_release -r' return?
<bluefoxicy> 9.10
<bluefoxicy> okay, /etc/lsb-release says karmic
<crimsun> bluefoxicy: if it annoys you, then edit /etc/modprobe.d/alsa-base.conf and remove "power_down=10" from the "options snd-hda-intel..." line, then reboot.
<bluefoxicy> crimsun: the prior release emitted crackling noises through the speakers when the hard drive had activity
<bluefoxicy> yes I realize that's a really weird sounding problem.
<crimsun> bluefoxicy: that isn't related to this bug, (un)fortunately.
<crimsun> we've already fixed the powerdown/up pop, but half of the fixes are only in 2.6.33 (presumably the other half will land in 2.6.34 shortly).
<bluefoxicy> there's political discussions about how much better sound is in OSS4 instead of ALSA
<crimsun> that doesn't really mean anything until OSS v4.1+ lands in mainline.
<bluefoxicy> and I'm sitting here thinking, oh hell, I need to drop an Audigy into my computer if I really care.  Drivers won't fix my cheap on-board junk XD
<bluefoxicy> (yes, it makes a difference I can hear very clearly; the audigy's frequency response is better than my on-board, which doesn't supply continuous power when there's more low frequencies and thus has emphasis on mids and highs)
<bluefoxicy> crimsun:  is the powerdown/powerup pop driver agnostic?
<crimsun> bluefoxicy: it's currently only relevant for the hda-intel driver and any of its associated codecs.
<bluefoxicy> nods.
<bluefoxicy> crimsun:  does the X-Fi line work btw?
<bluefoxicy> I don't remember when it came out but there's probably drivers now.
<t3rm1n4l> hi
<t3rm1n4l> what dhcp mechanism does ubuntu network manager use
<t3rm1n4l> very fast ip grabber
<t3rm1n4l> udhcpc is very slow
<t3rm1n4l> how is that achieved ?
<jdong> t3rm1n4l: it uses standard dhclient3.
<hyperair> newer network-managers use dhclient3 wrongly =\
<hyperair> apparently they pass a -4 parameter which dhclient hates
<hyperair> and never gets an ip
<jdong> how new?
<hyperair> like PPA new.
<hyperair>      0.8-0ubuntu4~nmt4~karmic 0
<hyperair> judging by the version, it would seem it's a released version of network-manager
<jdong> ah.
<hyperair> jdong: are you on lucid?
<jdong> I have a VM on lucid
<hyperair> ah
<jdong> primary is not.
<hyperair> i see
<hyperair> nevermind, i'll just untar my pbuilder then
<hyperair> i was wondering if lucid's dhclient supports -4
<hyperair> hmm it doesn't
<hyperair> maybe it was another flag..
<Quintasan> Hi, any admin archive around? About bug #526002. I know that libjpeg7-dev was removed by latest upload but shouldn't libjpeg8-dev be available? kffmpegthumbnailer builds fine with libjpeg62-dev but I though I would ask before doing second upload
<ubottu> Launchpad bug 526002 in kffmpegthumbnailer "build-depends on non-existing package" [High,In progress] https://launchpad.net/bugs/526002
<t3rm1n4l> howto configure a wireless network manually
<t3rm1n4l> without using dhclient
<t3rm1n4l> i tried iwconfig essid "essid"
<t3rm1n4l> ifconfig wlan0 ip
<t3rm1n4l> but doesnt work
<apachelogger> Quintasan: build depend on libjpeg-dev
<apachelogger> Quintasan: seems to be what cups does anyway
<Quintasan> apachelogger: well, anyways I must win the fight with pbuilder first :P
<apachelogger> Quintasan: I do not think your pbuilder does funny things
<crimsun> bluefoxicy: X-Fi is a marketing term. Devices carrying that moniker can be enabled by one of three drivers: ca0106, ctxfi, hda-intel. IOW, "it depends."
<bluefoxicy> crimsun: ah so it's not like the Emu10k1 chipset at the heart of every single audigy
<crimsun> bluefoxicy: not every single Audigy was driven by emu10k1. Some were driven by ca0106. (Same goes for the Live line.)
<sarah93> wow you should check this http://bit.ly/bFi9I4
<sarah93> wow you should check this http://bit.ly/bFi9I4
<jpds> !ops | sarah93
<ubottu> sarah93: Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<sherr> sarah93: ^^^ SPAM! ABUSE to multiple channels ...
<bsmith093> a quick question regarding karmic to lucid upgrade has anyone fisured out the sound problems yet
<arand> bsmith093: might be more relevant in #ubuntu+1 (and a bit more active)
<bsmith093> ok thanks
<andreasn_> hyperair, ping
<hyperair> andreasn_: pong
<andreasn_> hyperair, you're the banshee ppa dev, right?
<andreasn_> just a bit curious about the 1.5.4-really-1.5.3 thing
<andreasn_> I was looking for the data reporting checkbox but couldn't find it and wondering if that's the cause
#ubuntu-devel 2010-02-28
<hyperair> andreasn_: yes, i'm the maintainer of that PPA.
<hyperair> andreasn_: the 1.5.4 really 1.5.3 means it's really 1.5.3, but the version needed to be bumped due to an accidental upload of the wrong package.
<hyperair> andreasn_: i accidentally uploaded something meant for the daily PPA (a daily snapshot) to the banshee-team ppa instead.
<nenolod> zul: you here?
<andreasn_> hyperair, ah, I see. Thanks for the explanation
<StevenK> lifeless: How about prodding me to sync it when it's actually hit dinstall? :-)
<lifeless> StevenK: hey, rmadison shows it in debian :)
<shawnboy> Can someone clear up my confusion about C/C++ and OO?
<shawnboy> obj-oriented?
<shawnboy> nobody talkative tonight.
<persia> shawnboy: What are you trying to have answered?
<shawnboy> persia, I've read conflicting things about whether C fully supports OO. I want to learn either C or C++. For some reason I lean toward C, but I do want to learn OO.
<shawnboy> some say no, some say yes it can technically but why would u, and other say sure it can fully do OO
<persia> Both languages allow various styles of programming (both OO and not, as well as other orientations).  This is not a good forum to ask such questions: they will be ignored unless someone happens to be bored and there is no other traffic.
<persia> Unfortunately, I have no suggestions as to what would be an appropriate forum to get more information about these topics.
<shawnboy> i knew this maybe isn't the perfect forum, but hoped that people doing actual devel on Linux would be good group to ask.
<shawnboy> i tried ##programming but that channel isn't working for me for some reason, and that's only other one I knew of.
<shawnboy> U have no opinion one way or another on the matter?
<persia> None whatsoever.
<micahg> shawnboy: there seems to be a ##c++-basic channel
<shawnboy> micahg, ok. I can try that one. Isn't this for linux developers? Isn't straight C used for linux?
<micahg> shawnboy: this channel is for Ubuntu development specifically
<shawnboy> micahg, ok. so if I want linux developers opinions on my question... I'm out of luck?
<hile> absolutely.
<shawnboy> hile, ok. seems odd... but... ok.
<micahg> shawnboy: this isn't a linux development channel (Ubuntu has a separate kernel channel), also stuff for ubuntu is probably written in a dozen languages
<persia> Many more than a dozen.
<persia> And it contains examples of many, many, many different programming paradigms in each language.
<hile> most certainly this is not any kind of programming discussion channel.
<shawnboy> hmmm. well, I learned something then. I didn't know that. I'll give another place a try. thanks for at least responding.
<persia> shawnboy: Good luck in your search.
<shawnboy> persia, thank you. g'night all.
<chrisccoulson> sladen - i'm not sure why you ended up with epiphany-browser installed, but gnome-panel and gnumeric don't pull them in (they only suggest epiphany-browser, and suggests aren't installed by default)
<sladen> chrisccoulson: apt-mark showauto | grep epiphany   shows it as having been automaticallly installed
<chrisccoulson> have you configured your system to install suggests?
<micahg> sladen: aptitude why epiphany-browser
<sladen> thunderbird-locale-en-gb -> language-support-translations-en -> gimp-help-en -> www-browser -> epiphany-browser
<chrisccoulson> that dependency chain is ok
<micahg> not really, tb-locales doesn't depend on that package anymroe
<micahg> *anymore
<micahg> sladen: what version of the thunderbird-locale package do you have/
<sladen> thunderbird-locale-en-gb          1:2.0.0.14+1-0ubuntu2
 * micahg wonders if the locales got out of NEW
<micahg> yes, sladen, that's not the latest version in lucid
<micahg> do you have thunderbird 3 yet?
<lifeless> sladen: thunderbird-locale-thr-gb is more fun
<sladen> micahg: The only .*thunderbird.* package I have is 'thunderbird-locale-en-gb'.  (eg. I run with the defaults in order to dogfood)
<micahg> sladen: than the issue is language-support-translations which should have been removed...I'd move your bug to update-manager...
<sladen> micahg: done, and CC'ed mvo
<micahg> I subscribed as well
<sladen> lifeless: I'm still puzzling over what language code 'thr' is.  Is it for some remote British island colony or something?
<lifeless> klingon
<StevenK> And it's tlh
<lifeless> oh, my fail.
<lifeless> StevenK: so why couldn't you sync it ?
<StevenK> lifeless: It wasn't in unstable yet?
<lifeless> StevenK: rmadison thought it was
<lifeless> StevenK: which I guess is what requestsync uses.
 * StevenK kicks cocoplum
<lifeless> StevenK: I mean, I didn't do any silly buggery, I just ran requestsync --lp -d unstable testresources
<lifeless> and figured it would complain if it was too early.
<lifeless> StevenK: should I be doing something different?
<StevenK> lifeless: Nah, sounds like an okay process
<StevenK> lifeless: Synced.
<lifeless> thanks!
<muelli> heya, https://launchpad.net/~ubuntu-bugs-auftrags-killer/+archive/muelli claims that my PPA is signed with a key, but http://ppa.launchpad.net/ubuntu-bugs-auftrags-killer/muelli/ubuntu/dists/karmic/Release.pgp does not exist. How can I get the repository signed?
<al-maisan> muelli: is your ppa new or was it recently created?
<al-maisan> muelli: under normal circumstances a signing key is created for a PPA shortly after it was created
<muelli> al-maisan: yeah, it's newish. three days old or so. And as I've said: The website claims it's signed, but the Release.pgp is missing.
<micahg> muelli: try asking in #launchpad
<muelli> micahg: thx. will do
<al-maisan> muelli: that's out of the ordinary .. it should not take 3 days to generate the signing key
<muelli> al-maisan: interestingly enough, I imported that key manually, so it exists at least :)
<al-maisan> muelli: great :)
<flower> in which package is  update-initramfs?
<micahg> flower: initramfs-tools
<flower> micahg: thx
<muelli> flower: I use http://packages.ubuntu.com to search the packages that contain files :)
<Lex79> I can't build the new version of kdebindings, something in mono is in "New" I think
<Lex79> http://pastebin.ca/1814542
<Lex79> https://launchpad.net/ubuntu/+source/mono/2.4.4~svn151842-1ubuntu2
<directhex> Lex79, yes, i was about to ask for an archive admin to intervene
<directhex> Lex79, the cross-platform parts of mono are stuck in NEW (because the i386 build is stuck in NEW)
<Lex79> ok thanks :)
<directhex> because libmono-rabbitmq2.0-cil_2.4.4~svn151842-1ubuntu1_all.deb and libmono-messaging-rabbitmq2.0-cil_2.4.4~svn151842-1ubuntu1_all.deb are actually new this upload.
<Lex79> oh, I see
<ebroder> Are any core-devs around that could take a look at bug #497606? We just deployed CUPS 1.4 servers here, but have a lot of Hardy/Jaunty clients, so this bug is hitting us fairly hard
<ubottu> Launchpad bug 497606 in cupsys "lpstat in CUPS 1.3 can't list jobs on CUPS 1.4 servers" [Undecided,New] https://launchpad.net/bugs/497606
<ebroder> I've had a tested debdiff sitting there for 2 months now
<Amaranth> ebroder: in about 12-16 hours there will be a bunch
 * ebroder sighs. Damn time zones
<jdong> ebroder: do you need sru bits too?
<jdong> </toolazytoclick>
<jdong> ebroder: I do see core-devs alive right now but I'm afraid I'll be kidnapped in my sleep for revealing them ;-)
<jdong> *keeps mouth shut*
<directhex> jdong, how about archive admins? :p
<jdong> directhex: am I not spying in the right channels?
<ebroder> jdong: Yeah, it's an SRU
<ebroder> Thanks
<ebroder> jdong: Can you accept nominations on that bug? Or do you have to be able to upload the package to do that?
<ebroder> (cupsys+hardy, cups+intrepid, and cups+jaunty should be accepted, and all the others should be rejected)
<Laney> yah boo
<jdong> ebroder: no, that's still core-dev only I'm afraid
<lifeless> kees: bug 528115
<ubottu> Launchpad bug 528115 in xserver-xorg-video-ati "Mouse cursor does not show after startup" [Undecided,New] https://launchpad.net/bugs/528115
<lifeless> bah
<lifeless> kees: bug 528155
<ubottu> Launchpad bug 528155 in linux "needs a breaks: clause for lvm2 versions in hardy" [Undecided,New] https://launchpad.net/bugs/528155
<lifeless> kees: thats the lvm issue I ran into last week
<kees> lifeless: yup, hopefully the kernel team will catch it.  I'll milestone it.
<lifeless> kees: thanks
<_Groo_> can anyone tell me if sun-java6 was pulled out of lucid?
<mdeslaur> _Groo_: it will be moved to the partner repo
<_Groo_> mdeslaur: ah ok, but is the partner repo already activated in alpha3?
<mdeslaur> _Groo_: there was a problem putting sun-java6 into the partner repo this week, it should be fixed shortly
<Lex79> directhex: no news about mono issue? :(
<directhex> Lex79, i haven't noticed an archive admin skulking about yety
<directhex> or anyone i know to be an archive admin
<_Groo_> mdeslaur: ok thanks... i almost had an heart attack lol
<Lex79> ok
<jdong> hmmmm any upstart/bootup deities in here?
<jdong> http://jdong.mit.edu/~jdong/bootchart_lucid.png
<jdong> my system seems to stall at bootup for $a_long_time doing nothing
<jdong> and bootchart seems to confirm that
<jdong> any hints for debugging this?
<slangasek> jdong: what makes you think it's stalling?
<jdong> no disk IO, just mouse pointer on a console background
<slangasek> "mouse pointer on a console background" - standard plymouth bug
<jdong> slangasek: ah
<jdong> it just seems like from 13 seconds to 57 seconds nothing's "happening"
<slangasek> jdong: because your X is wedged.  Ctrl+Alt+F2, Ctrl+Alt+F7 to fix it (maybe)
<jdong> ah
#ubuntu-devel 2011-02-21
<bdrung> TheMuso: can you help me finding the reason for portaudio19 to FTBFS? portaudio19 builds in my natty pbuilder instance but fails on the lp farm: https://launchpad.net/ubuntu/+source/portaudio19/19+svn20101113-1
 * TheMuso looks
<TheMuso> bdrung: Weird. What environment are you building it in locally?
<bdrung> TheMuso: it builds on maverick, and in pbuilder (sid, maverick, and natty). all amd64
<TheMuso> Ok. Give me a bit, and I'll try it in sbuild.
<bdrung> thanks
<TheMuso> bdrung: hrm builds fine here in sbuild.
<robert_ancell> StevenK, can you sync libsoup2.4 from debian experimental?
<StevenK> robert_ancell: Sure. Is there a bug?
<robert_ancell> StevenK, Bug #718480
<ubottu> Launchpad bug 718480 in libsoup2.4 (Ubuntu) "Merge with Debian 2.33.6-1" [Wishlist,Triaged] https://launchpad.net/bugs/718480
<StevenK> robert_ancell: No? :-) Looks like glib-networking has to be promoted first, and the bug you linked has no rationale for a sync
<robert_ancell> StevenK, oh, glib-networking was supposed to be promoted, see bug #718477 - why has it not?
<ubottu> Launchpad bug 718477 in glib-networking (Ubuntu) "[MIR] glib-networking" [Wishlist,Fix committed] https://launchpad.net/bugs/718477
<StevenK> robert_ancell: It's been approved, it's waiting for an archive admin to do it -- which I'm doing now
<robert_ancell> ok, and why is there no rationale for a sync then?
<StevenK> robert_ancell: Because there's no comment listing the Ubuntu changes and that's it's perfectly fine to drop them
<robert_ancell> there are no ubuntu changes, it's just not being autosynced
<StevenK> Oh, duh
<StevenK> robert_ancell: Sorry, I should really learn to read.
<robert_ancell> :P
<robert_ancell> I blame the complex process
<StevenK> robert_ancell: glib-networking promoted, remind me to sync libsoup2.4 in an hour
<robert_ancell> ok, thanks
<ohsix> cjwatson: another thing re: the livecd/installer; something that checks dmesg every 30 seconds or so for media errors and tells the user the disc might be damaged or need to be burned differently would be cool, cuz it's hard to really see if you don't know where to look
<ScottK> lamont: Seems to work fine here (tested with tls/smtp-auth using both policy server and milters).  I didn't try postscreen.  Here's some additional changes for pacakge modernization (and some stuff I found from Debian bugs): http://pastebin.com/AmdCTBtZ
<robert_ancell> StevenK, time for soup?  libsoup?
<StevenK> robert_ancell: Sorry, fighting with tools.
<StevenK> robert_ancell: Done, sorry for the delay.
<robert_ancell> StevenK, thanks, np
<pitti> Good morning
<micahg> good morning pitti
<RAOF> Howdie pitti
<twb> Never mind, I worked it out.
<dholbach> good morning
<TheMuso> ogra_: Alsa driver, lib, tools and plugins are entering natty now. Utils is coming in the next day or so, as we finalize a few changes relating to setting audio settings. You need not worry, your omap changes are still included, and will be usable.
<TheMuso> setting audio volume even.
<tkamppeter> pitti, hi
<pitti> hey tkamppeter, how are you?
<didrocks> good morning
<tkamppeter> pitti, fine. I only want to ask you whether you will update CUPS to 1.4.6 before FF. I wanted to ask you on Fri, but it seems that you have taken that day off.
<pitti> tkamppeter: right, I was on holiday Thu/Fri
<pitti>       cups |    1.4.6-1 |         natty | source, amd64, i386
<pitti> tkamppeter: ^ you mean this? :-)
<tkamppeter> Yes.
<pitti> tkamppeter: retroactively done
<tkamppeter> pitti, you did on Sat, great. I did not "bzr pull" on CUPS that day.
<tkamppeter> pitti, the Avahi patch appplied without changes?
<pitti> tkamppeter: yes, it did; 1.4.6 only had some five bug fixes, it wasn't that intrusive
<pitti> tkamppeter: btw, we can update to 1.4.x versions after FF as well; the microreleases usually only get bug fixes
<tkamppeter> pitti, OK. Yes, I remember. Mike said that these releases are bug-fix-only.
<smb> @pilot-in
<udevbot> Error: "pilot-in" is not a valid command.
<smb> @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: smb
<pitti> good morning smb, happy piloting!
<smb> pitti, Morning. But you know that I am a similar good pilot as Indiana Jones? ;-P
<pitti> smb: just use your whip then :)
<smb> pitti, Did not help him either when trying to land. :)
 * dholbach hugs smb
<smb> :)
<cdbs> debian-archive-keyring in maverick doesn't contain the new Sid and squeeze keys.
<cdbs> Should I SRU?
<cdbs> The problem with that is, pbuilder-dist sid create fails in maverick
<pitti> cdbs: sounds good to me
<pitti> for lucid as well, if you feel inclined :)
<cdbs> pitti: okay, /me gets to work!
<pitti> cdbs: thanks!
<cdbs> pitti: looks like I must backport the whole package, the package contains files signed by the Release team. If I modify stuff, I can't re-sign
<pitti> cdbs: sounds fine as long there are no structural changes in the package (new binaries, newer dependencies etc.)
<cdbs> pitti: the package had changed a lot structurally, but its b-ds look good to run on maverick/lucid. The whole key generation technique has changed, and this seems to be the only way
<cdbs> shouldn't cause regressions, its a key package
<pitti> cdbs: i. e. the binaries look the same?
<cdbs> pitti: hmm? I didn't get you. The binaries of what?
<pitti> cdbs: the .debs
<cdbs> the binaries are much the same, but the natty package is better in forming the .gpgs
<pitti> *nod* sounds fine then
<cdbs> it uses jetring, unlike the maverick package which is hard-coded by the release team, and cannot be modified without key access
<cdbs> pitti: ^
 * cdbs gets to work
<pitti> cdbs: jetring is in universe, though
<cdbs> pitti: d-a-k is also in  universe
<pitti> ah, right
<cdbs> pitti: the release number should be the old one + .1, right? This is a whole package backport, so things may differ
<cdbs> 2010.08.28 is the natty version, maverick/lucid is 2009.01.31ubuntu1
<pitti> cdbs: I'd use 2010.08.28~maverick and ~lucid
<cdbs> :o
<cdbs> pitti: its a native package, so 2010.08.28~maverick.1 or?
<pitti> cdbs: the .1 doesn't really matter
<cdbs> okay
<cdbs> pitti: meh, build fails in maverick, because of Debian bug #560692 . Natty binary works well, I just tested on my EC2 instance
<ubottu> Debian bug 560692 in gnupg "[gnupg/1169] gnupg: first-run check error with self-contradicting message" [Normal,Fixed] http://bugs.debian.org/560692
<cdbs> so will need to SRU that first. :(
<pitti> perhaps at this point it becomes a matter for maverick-backports?
<cdbs> maybe?
<cdbs> pitti: well, I have a workaround, create the homefir manually.
<cdbs> *homedir
<persia> 560692 looks SRU-worthy, and backports is by-policy-not-for-bugs
<cdbs> EC2 helps a lot, I can't go ahead build 3 packages at a time on my laptop . :)
<lool> doko: Did you get my email about binutils-multiarch?
<cjwatson> is anyone on the desktop team looking at doing an MIR for libquvi?  it's a build-dep of totem-pl-parser
<Riddell> mvo: yo
<Riddell> mvo: is -proposed enabled during upgrades?
<mvo> Riddell: no
<Riddell> mvo: is there a way to do so?
<mvo> Riddell: it will not be disabled, but if the user has not enabled it, the upgrade will not do that either
<Riddell> I need a test case for bug 721269
<ubottu> Launchpad bug 721269 in kdepim-runtime (Ubuntu Maverick) "newer kdepim in lucid than in maverick" [High,In progress] https://launchpad.net/bugs/721269
<Riddell> mvo: ok so just enabled -proposed before upgrade and it'll stay enabled?
<mvo> Riddell: that should be no problem, if the tester just enabled proposed that should work
<mvo> yeah
<Riddell> groovy, thanks
<nobuto> Could someone review this merge request Bug #718122? This include some bug fixes described in Debian's changelog.
<ubottu> Launchpad bug 718122 in ttf-takao (Ubuntu) "Please merge ttf-takao 003.02.01-4 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/718122
<debfx> cjwatson: have you read my email about the kubuntu package set?
<cjwatson> debfx: yes, but not acted on it yet, sorry
<cjwatson> it's in the queue :-/
<debfx> ok, just wanted to make sure that it's not lost in your inbox ;)
<\sh> slangasek: I think bug #525154 introduced a nice regression regarding unattended installation of ubuntu in a chroot where statd can't be started inside nfs-common.postinst because all the "pls upstart start this service" is diverted to /bin/true ... since before the bugfix this worked out of the box, now I have an nfs-common package failing to install properly
<ubottu> Launchpad bug 525154 in nfs-utils (Ubuntu Natty) "mountall for /var races with rpc.statd" [High,Fix released] https://launchpad.net/bugs/525154
<hyperair> http://laudecioliveira.org/blog/?p=282
 * hyperair rofls
<ari-tczew> cjwatson: did you look on MoM why it;s hanged?
<pitti> cjwatson: FYI, checked libquvi for MIR and sent the report; I sub'ed you, as you seem interested in seeing this progressing
<cjwatson> pitti: thanks
<ari-tczew> mdeslaur: do you know script sponsors-patch?
<mdeslaur> ari-tczew: yes
<ari-tczew> mdeslaur: I encourage to use it for sponsoring patch in bzr, like nbd today.
<jamespage> doko: please could you MIR review bug 676904 for me?  its required to support a long pending sync from Debian
<ubottu> Launchpad bug 676904 in jansi-native (Ubuntu) "[MIR] jansi" [Medium,Confirmed] https://launchpad.net/bugs/676904
<ari-tczew> mdeslaur: It will merge branches and upload package via dput.
<debfx> I wonder whether bug #722563 is caused by a bug in glibc, X or VirtualBox.
<ubottu> Launchpad bug 722563 in virtualbox-ose (Ubuntu) "vboxvideo DRI driver crashes Xorg on startup" [Undecided,Confirmed] https://launchpad.net/bugs/722563
<mdeslaur> ari-tczew: that tool doesn't fit my workflow, but I'll try it again soon.
<ttx> dpm: is the whole translations process (including binarypkgmangler) explained somewhere ?
<slangasek> \sh: please file a bug, with logs; statd would not have been startable inside a chroot even before the fix for bug #525154, and should still not-start in the same way after the fix, but maybe something else has broken
<ubottu> Launchpad bug 525154 in nfs-utils (Ubuntu Natty) "mountall for /var races with rpc.statd" [High,Fix released] https://launchpad.net/bugs/525154
<\sh> slangasek: will do
<dpm> hey ttx! Here's an overview: https://wiki.ubuntu.com/Translations/TranslationLifecycle
<dpm> and here's some more info on pkgbinarymangler: https://wiki.ubuntu.com/UbuntuDevelopment/Internationalisation/Packaging
<ttx> dpm: cool ! thanks.
<dpm> ttx, if something is not clear there, just ping me if I can give a hand
<ttx> dpm: no, it makes sense, thanks :)
<dpm> cool :)
<jono> I see Unity, indicators and some other things are held back, is it safe to dist-upgrade or should I wait?
<seb128> jono, it's safe to dist-upgrade
<seb128> jono, it should only remove libindicator2
<seb128> the stack got rebuilt since
<seb128> if it wants to remove other things for some reason maybe comment there though
<jono> thanks seb128
<seb128> you're welcome
<ari-tczew> I just got kernel panic after put CD into dvdrw >.<
<smb> @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> lamont: Did you get my ping back re postfix?
<Otacon22> ohsix, it is happening again
<ohsix> you'll have to refresh my memory
<debfx> RAOF: the last xorg-server upload breaks X with the virtualbox driver: bug #722563
<ubottu> Launchpad bug 722563 in xorg-server (Ubuntu) "vboxvideo DRI driver crashes Xorg on startup" [Undecided,Confirmed] https://launchpad.net/bugs/722563
<RAOF> debfx: Thanks.
<debfx> seems like the dri driver fails to load and then X crashes while trying to load a driver from the alternates dir
<highvoltage> debfx: I ran into that this afternoon too, quite nasty
<kklimonda> 2 /b 30
<RAOF> debfx: Do you have an Xorg.0.log for a successfull boot with the previous X server?  It looks like vboxvideo is doing crazy things.
<ricotz> bdrung, hello
<debfx> RAOF: http://paste.ubuntu.com/570269/
<RAOF> Bah.  It's playing silly buggers.
<RAOF> Impressive to SEGV in libdl, though.
<Otacon22> ohsix, the indicator-session-applet is using too much memory
<ohsix> ah
<bdrung> ricotz: hi
<ricotz> bdrung, did you read the last comment?
<bdrung> just no
<bdrung> w
<ricotz> bdrung, should be the best to follow the current decisions with dropping them
<RAOF> debfx: Oh, whoops.  I think I know what the problem is.  Do you want to test?
<bdrung> ricotz: i checked -3 and debian/gpgv-win32.install says: "usr/share/win32/"
<ricotz> bdrung, hmm, http://svn.debian.org/wsvn/pkg-gnupg/gnupg/trunk/debian/gpgv-win32.install
<bdrung> ricotz: i looked at the dsc file
<ricotz> bdrung, i pulled it from svn, it wasnt uploaded while i merged it
<bdrung> ricotz: you are right that we have to drop mingw32 from B-D (because it is in universe)
<bdrung> so the install location discussion is irrelevant
<debfx> RAOF: sure
<ricotz> bdrung, ok
<bdrung> ricotz: "debian/[control,rules}" => [ -> {
<RAOF> debfx: Want prebuilt packages (what arch?) or a source package?
<ricotz> bdrung, alright
<ricotz> bdrung, fixed
<debfx> RAOF: if you have amd64 binaries that's fine, otherwise I'll take the source package
<RAOF> I'll make with the building then.
<ari-tczew> when is Feature Freeze? while night Wednesday -> Thursday?
<ari-tczew> or Thursday -> Friday?
<highvoltage> it's in effect from Thursday
<sparr> I've just discovered that there is a spammy comment to a bug on launchpad attributed to me but not visible on my activity history. Is anyone here in a position to discuss how that could have come to be?
<lifeless> sparr: #launchpad
<sparr> thanks
<RAOF> debfx: http://www.cooperteam.net/Packages - you'll want xserver-xorg-core and xserver-common.  And to ignore the dependency problems for all your drivers; they'll work.
<alisalaah> I am a developer, who has never developed for a Linux distro but knows how to code and such.. wondering how i would browse some bug fix sites and get involved etc
<alisalaah> found good information on almost anything out there except; how to contribute to Linux
<highvoltage> alisalaah: great! starting with ubuntu is a great way to get involved
<axp2> alisalaah: try 100 papercuts on launchpad
<highvoltage> alisalaah: this page has lots of information and links to more: https://wiki.ubuntu.com/ContributeToUbuntu
<axp2> https://launchpad.net/~papercuts-ninja
<axp2> alisalaah: i would go to the site that highvoltage suggested first to get a good overview of how to get started. if you decide you want to try fixing some small bugs (in various packages and languages) then papercuts ninja is a good mailing list
<axp2> this is where i started fixing bugs
<alisalaah> reading now :)
<virtuald>  
<broder> alisalaah: http://harvest.ubuntu.com/opportunities/ will also show you bugs that have been labelled as "bitesize" - meaning that somebody thought they would be easy to take on
#ubuntu-devel 2011-02-22
<cody-somerville> Hey. Are there any fellow DMB members kicking around with a few minutes to spare?
<directhex> Laney?
<slangasek> pitti: I would be interested in your input on bug #722933
<ubottu> Launchpad bug 722933 in cdbs (Ubuntu) "cdbs doc linking behavior is different when building with -b vs. -B" [High,Triaged] https://launchpad.net/bugs/722933
<Chipzz> slangasek: if you want my 2c, the correct solution is to walk the dependency chain when creating those symlinks
<slangasek> Chipzz: what dependency chain?  You mean look at packages outside the current build?
<Chipzz> I mean
<Chipzz> libfoo-dev: depends: libfoo
<Chipzz> the symlink should be from libfoo-dev to libfoo
<slangasek> that's what it already does
<slangasek> but it does so inconsistently where arch: all packages are concerned
<Chipzz> sorry, rather late here and I didn't think my comment through 100%
<Chipzz> probably should have shut up and not wasted your time ;)
<slangasek> no worries... :)
<Chipzz> trying to recall the difference between arch: all and arch: any at 4AM tends to not be very productive ;p
<Chipzz> I always get these 2 mixed up
<Chipzz> the similarity between the 2 words is rather unfortunate
<ScottK> Chipzz: All means one package works on all archs (~same as rpm noarch).  Arch any means you can build the package for any arch, but you have to built it for that arch.
<Chipzz> ScottK: yeah, I can recall when I look it up :) the problem is having to look it up
<Chipzz> which I didn't at 4AM ;P
<ScottK> Once I started thinking of it like that ^^^ I was finally able to remember it.  YMMV.
<Chipzz> I just thought of a better way ;)
<Chipzz> .all.deb is sth that exists, .any.deb doesn't
<Chipzz> so all refers to the archs it will be able to installed on
<Chipzz> +be
<poolie> scottk, hi
<poolie> thanks for your feedback
<ScottK> poolie: Hello.
<poolie> i think a debian/control field would work well
<poolie> i'm just wondering how that would come to be set on a package: who would decide about it?
<ScottK> I think that can be decided on a team by team basis.
<ScottK> In my mind there's a huge difference between "Hey, if you don't use UDD someone will come and hunt you down if you didn't have a really good reason" and the package upload is impossible.
<poolie> right
<ScottK> As long as it's put in debian/control and not hard coded in launchpad somewhere, we can iterate on how best to manage it.
<poolie> and, indeed, there's another one to the left of that which is "let's make sure there's a bug explaining why it wasn't or couldn't be used"
<ScottK> Perhaps.
<poolie> well, it can be on the server and still controllable by teams
<ScottK> Perhaps, but I think the package is a more natural place to find it.
<poolie> ok
<poolie> one draw back is that it would take one update per package to flip it
<poolie> perhaps that's not a big deal
<ScottK> If it's a package someone wants to set this on, I doubt it's a big deal.
<ScottK> It'll be getting uploaded anyway.
<ScottK> I don't know about the need for filing a bug.  Most of the reasons I can think of for not using UDD with such a package are very tactical: trying to get an ISO to build and needed to push a quick fix and didn't want to mess with bzr.
<poolie> ok
<ScottK> For packages where UDD is problematic (e.g. kernels),  the flag won't be set anyway.
<poolie> can you tell me more about the "trying to get an iso to build" case?
<ScottK> Just an example where time is of the essence.
<poolie> ok
<poolie> i'll update the lep to suggest that then
<ScottK> Thanks.
<poolie> should that warning come from dput, or soyuz, or maybe somewhere else?
<broder> poolie: do you think it's reasonable to assume that any package that a team wants built solely from branch will also be carrying ubuntu changes?
<broder> i guess if you need to build from a branch in the first place you almost certainly have a change of some sort
<poolie> broder, it seems likely
<poolie> though, i guess, that policy could carry over from one ubuntu cycle to the next even if there are no new changes from debian
<broder> oh look, someone beat me to the punch on-list
<ScottK> poolie: I'd suggest from dput parsing the .changes file.
<poolie> scottk, that seems reasonable
<poolie> as i said on the list this is not the first thing we need
<poolie> i guess it's good to know there's a way to do it eventually
<poolie> perhaps it should have been removed from the lep
<ScottK> Right, just recognize that some people are going to go ballistic at anything that smells of making this mandatory.
<poolie> i know :)
<poolie> i'd almost rather have it out there and answer it than have them suspect though
<poolie> success for me here means having people use it and like it, not having them use it at any cost
<ScottK> I suspect that for people who tend to touch the same package or a few over and over this is a relatively easy sell.  For people who work on different packages all the time, I think it's going to be harder because branching performance is more important.
<poolie> right
<poolie> we've worked on that and we'll do more
<poolie> the idea that came up in January was basically that for people who _can_ use it, we ought to connect the dots all the way through
<ScottK> Which makes sense.
<poolie> then we can come back and make things smoother or faster
<ohsix> UDD?
<StevenK> Ubuntu Distributed Development
<pitti> Good morning
<pitti> slangasek: as we don't have access to the arch:all binaries on !i386, I don't see another way than the one you proposed
<pitti> slangasek: is there any documentation about this "Multiarch: foreign" field? it seems very weird to me that you have to mark an arch:all package with that (regardless of what it does)
<slangasek> pitti: https://wiki.ubuntu.com/MultiarchSpec
<slangasek> pitti: specifically, https://wiki.ubuntu.com/MultiarchSpec#Dependencies%20involving%20Architecture:%20all%20packages
<pitti> ah, thanks; I wonder why this isn't already the implicit default behaviour for arch:all packages then
<slangasek> pitti: because of the explanation given there - existing packages can assume that the dependencies of the arch: all package are fulfilled by packages of the same architecture (think python + python extensions)
<slangasek> so if we suddenly change the behavior and let the dependencies be satisfied by packages from other architectures, things will break
<cdbs> @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: cdbs
<tjaalton> slangasek: you probably want the libx11 multiarch change to ubuntu as well? i've got a merge ready, could pull that in too
<tjaalton> oh
<tjaalton> it was uploaded already :)
<slangasek> tjaalton: yeah; I didn't want to step on anyone's toes by merging, but as I'm going to be looking at quite a lot of the X library stack in the coming days, if there are other libs you'd like me to merge up I'm happy to do so :)
<tjaalton> slangasek: there shouldn't be any left, a bunch of them were synced on friday, and only a couple of them have ubuntu changes
<tjaalton> so push the changes to debian and then we can sync again
<tjaalton> depending on the package
<tjaalton> slangasek: http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
<tjaalton> that shows which packages have changes
<slangasek> tjaalton: right, I'll be pushing these changes directly to Debian first; there probably aren't too many packages I can actually change for this round, most of my work is still staged in ppa
<didrocks> good morning
<tjaalton> slangasek: okay
<dholbach> good morning
<kklimonda> 05:49           ScottK | It'll be getting uploaded anyway.
<kklimonda> 05:49           ScottK | I don't know about the need for filing a bug.  Most of the reasons I can think of for not using UDD with such a package are very tactical: trying to get
<kklimonda>                        | an ISO to build and needed to push a quick fix and didn't want to mess with bzr.
<cdbs> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
 * dholbach hugs cdbs
<dholbach> patch pilots FTW!
<cdbs> thanks dholbach
<cdbs> dholbach: probably my last session of patch piloting before my exams :(
<dholbach> cdbs, all the best with your exams!
<cdbs> thanks dholbach
<debfx> RAOF: X doesn't crash anymore with you packages, thanks :)
<RAOF> debfx: Awesomeo.
<ricotz> bdrung, hi
* bdrung 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:hi
* bdrung 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:
<bdrung> hi
<ricotz> bdrung, you looked at the current debian/changelog, and you are not happy with what is looks like?
<bdrung> (stupid focus)
<ricotz> bdrung, using a new "*" doesnt look right to me
<bdrung> ricotz: yes
<bdrung> ricotz: why not?
<ricotz> has this something to do with make it work with a script?
<bdrung> ricotz: no, it's just common practice.
<ricotz> i my opinion it is a change to the debian packaging
<ricotz> so if there were only one commit you would have been happy with it?
<bdrung> no, it's not the number of commits.
<bdrung> look for example at http://packages.debian.org/changelogs/pool/main/p/portaudio19/current/changelog
<ricotz> since it is going to be merged to the real branch, the commit message can be pretty
<ricotz> bdrung, ok, this is done with git-dch?
<bdrung> ricotz: it's not about commit messages, it's about what's in debian/changelog
<ricotz> there are many styles to list the changes of a package
<bdrung> one "*" for every distinct change. you did two: keep the remaining changes from last merge and drop the win32 package
<ricotz> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gnupg/natty/revision/29/debian/changelog
<bdrung> the drop of the win32 package is not a subitem of "remaining change"
<bdrung> re the link: that were all remaining changes
<ricotz> https://launchpad.net/ubuntu/lucid/+source/gzip/+changelog
<ricotz> gzip (1.3.12-9) unstable; urgency=high
<bdrung> http://changelogs.ubuntu.com/changelogs/pool/universe/v/vlc/vlc_1.1.7-1ubuntu1/changelog
<tkamppeter> pitti, hi
<bdrung> ricotz: there we have one old change "build and install the libx264 plugin" and a new one "v4l is gone from the kernel. Build only v4l2."
<ricotz> bdrung, have you looked a the gzip one?
<ricotz> https://launchpad.net/ubuntu/natty/+source/cpio/+changelog
<ricotz> bdrung, ^ this might be the most recent example
<ricotz> which is the same thing
<bdrung> ricotz: look at cpio 2.9-13ubuntu1 -> http://changelogs.ubuntu.com/changelogs/pool/main/c/cpio/cpio_2.11-6ubuntu1/changelog
<bdrung> ricotz: since that version, it is a "remaining change"
<ricotz> bdrung,  now i see what you mean
<ricotz> bdrung, ok :), i will change this, anything besides that?
<bdrung> ricotz: probably not
<ricotz> bdrung, done
<bdrung> ricotz: uploaded
<ricotz> ricotz, thanks
<bdrung> soliloquy :)
<ricotz> i mean, bdrung, thanks ;)
<lifeless> erm
<lifeless> 2363 robertc   20   0 1182m 694m 1844 S    0  9.1   4:03.13 gnome-power-man
<lifeless> -not cool-
<persia> When managing power, the first step is accumulation: only once all power is claimed can it be distributed to others (and even that is risky)
<cjwatson> gnome-power-robin-hood
<ogra> accumulated power can get risky though (see lybia)
<ogra> Riddell, ScottK, so what about QT ? FF is soon and there only seems to be a symbian related bug holding it up, could we get a package before FF ?
<persia> ogra: Isn't the difference between 4.7.1 and 4.7.2 covered by the "Upstream microreleases" clause from https://wiki.ubuntu.com/FeatureFreeze ?
<ogra> might be, my concern is that we are waiting for a feature we need to test asap
<Riddell> ogra: feel free to package a git snapshot, I'll package 4.7.2 when it's out but I don't have time or need to do anything before
<ogra> hmm
<ogra> k
<ogra> Riddell, just be aware that if NEON runtime detection doesnt work and we dont get a fix in by release i will have to turn it off statically again
<ogra> to my knowledge it hasnt been tested upstream and the bugfix is only based on assumptions
<mok0> I'm looking for a program that will accept input from stdin (from a GTK app) and display it in a window
<persia> mok0: zenity?
<mok0> persia: hm, don't know that one... let me check it out
<persia> (you might have to fiddle a bit with redirects and such, but ...)
<mok0> persia: the problem is, this graphical app outputs a lot of error info and such via stdout, but you don't see that if the app is started from the menu
<persia> (unless you look in .xsession-errors)
<persia> That sounds like the application itself needs to be fixed.  It oughtn't do that.
<persia> Wrapping in a display tool doesn't strike me as ideal.
<mok0> persia: me neither
<mok0> persia: I could pipe the output to a file in the users home dir, but that doesn't strike me as ideal either
<persia> That's already implemented: .xsession-errors
<mok0> persia: heh I completely forgot about that
<mok0> persia: haven't worried about .xsession-errors for years
<persia> The application is still buggy, but if you're digging for the output for some reason, it is saved locally.
<mok0> persia: I suppose it is partly to help developers
<Riddell> ogra: yeah, with KDE not compiling on ARM, Qt on ARM isn't much of a priority for me :(
<ogra> tell that to the unity guys
<mok0> persia: this program embeds Python, and the user is free to create scripts and so on; these output stuff on stdout
<Chipzz> seems like the output is not properly redirected then
<persia> Ah, that's a different issue.  That ought be trapped, etc.  File an upstream bug: help them there if you have interest, as this will surely be invasive.
<mok0> persia: I am working with them already, but I doubt they would give it any priority. It's quite slow to get even small patches accepted
<persia> Well, architecturally, I'd probably approach the solution as follows: 1) trap stdout in the launched python scripts, and redirect to some internal buffer
<persia> 2) Add some window or view that allows users to view the internal buffer (or perhaps just some window into it)
<mok0> persia: hm, xconsole might do the job
<persia> 3) Add some control to show/hide the window/view
<mok0> persia: I agree that would be a good solution. But, as I said, I doubt the developer(s) would give it any priority.
<persia> xconsole doesn't seem like an ideal solution: you'd still have to trap/redirect stuff to /dev/console rather than inherited STDOUT (.xsession-errors), *AND* you break if someone has an actual device attached to /dev/console
<mok0> persia: I think you can run xconsole with a different device, using the --file switch
<persia> You're planning to initiate a new pty?
<mok0> persia: no, just wondering if it might work using a file
<persia> It won't: read the manpage.  "This does not work on regular files ..."
<mok0> persia: it actually does
<mok0> persia: if I append to the file (using cat >> ) it appears in xconsole
 * persia would be very suspicious and check the code path when the manpage says "this does not work" but it appears to work: there's probably N subtle bugs
<mok0> but ugghh it's ugly :-)
<mok0> persia: yes. It's a bad solution anyway
 * mok0 ponders if he could use the notification system :-/
<mok0> persia: I would also have to deal with shutting down xconsole when the user quits the program. That would be quite hacky
<persia> Not if you write a good wrapper.  Parent opens xconsole child, then opens other child, and waits.  When other child exits, send signal to xconsole.
<persia> Annoying in shell, but not hard in other languages.
<mok0> Could probably be done in Python ...
<persia> http://docs.python.org/library/subprocess.html
<pitti> hey tkamppeter
<mok0> persia: then I might as well write a wrapper program that opens a nicer window
<persia> Indeed :)
<mok0> persia: Hm, I'll give it a thought. Seems like a nicer solution. There are other issues as well. The program is designed for users to navigate to their working directory, and then invoke the program from the CLI
<mok0> persia: then it tries to read status files in that dir when starting
<mok0> persia: but perhaps I can deal with that using python magic :-)
<tkamppeter> pitti, around?
<pitti> tkamppeter: yes; I was out for some errands and an appointment
<tkamppeter> pitti, I succeeded that the Debian maintainer accepted all my Ubuntu changes into the Debian package of foo2zjs (except apport hook). Now I want to merge back the Debian package before FF, but it does not appear on https://merges.ubuntu.com/f/. Will there still be a refresh before FF?
<tkamppeter> pitti, if not, is there a program for merging the debian/changelog? I do not want to do this manually.
<pitti> tkamppeter: it's supposed to run
<pitti> tkamppeter: you could try your luck with the new world's UDD branches
<pitti> tkamppeter: i. e. check out lp:ubuntu/fo2zjs and bzr merge lp:debian/foo2zjs
<pitti> (if the latter is current)
<tkamppeter> pitti, what are the "new world's UDD branches"?
<Chipzz> tkamppeter: I don't know how practical this is for merging changelogs, but I have found vimdiff invaluable in the past for merging various other things
<pitti> tkamppeter: using bzr merge on the ubuntu/debian imported branches
<Chipzz> (if you know how to drive it, which isn't very dificult)
<pitti> tkamppeter: "bzr lp-open lp:debian/foo2zjs" -> hm, this looks out of date
<pitti> tkamppeter: personally, in these cases I just write a detailled summary of "Remainign Ubuntu changes:" into the changelog, and drop the older stuff
<tkamppeter> pitti, packages.debian.org already shows it and AFAIK the upload was Sunday.
<pitti> tkamppeter: as this is only the apport hook now, that's easy to do
<pitti> tkamppeter: the Debian changelog has the other changes from us already, after all
<pitti> and the older changelogs remain on Launchpad as well, so they aren't lost
<pitti> tkamppeter: i. e. take the Debian package, add the apport hook, and that's it
<pitti> tkamppeter: btw, if you can commit to the debian repo, you could commit the apport hook there as well, and only install it when building under Ubuntu
<tkamppeter> pitti, OK, then I will simply do it this way.
<pitti> tkamppeter: http://git.debian.org/?p=pkg-utopia/udisks.git;a=blob;f=debian/rules;h=82db4040c633833183d2f42576758ebbdba95152;hb=HEAD
<pitti> tkamppeter: line 27 to 29
<pitti> erm, 25 - 28
<tkamppeter> pitti, what is planned for the future is that I will make packages for Debian where someone at Debian sponsors the upload and after a certain amount of such uploads they want to make me DM, and then one lets all packages auto-sync in Ubuntu. WDYT?
<pitti> tkamppeter: that sounds great
<pitti> tkamppeter: that's what I do as well with most of my packages
<tkamppeter> pitti, so if in some time they will avaluate my DM approval, please add a good word for me.
<pitti> my pleasure!
<tkamppeter> pitti, thanks for the help.
<lamont> ScottK: postfix_2.8.0-1~build1 uploaded to natty
<lamont> freshening things to build for sid now
<cjwatson> slangasek: I multiarch-foreign-ified binfmt-support in unstable - hope I did it right
<cjwatson> will sync into Ubuntu in a bit
<mdz> pitti, can you tell me what this retracer error means? https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/720895
<ubottu> Error: Bug 720895 is private
<seb128> mdz, it means the retracing didn't give a valid stacktrace
<mdz> seb128, can we guess why?
<mdz> it seems to be happening with a number of bluetooth-applet crashes
<pitti> hey mdz
<seb128> #2  0x00007ffffe672e70 in ?? ()
<seb128> No symbol table info available.
<seb128> those symbols are lacking
<seb128> let me look at the procmaps
<pitti> mdz: that's a bit misleading indeed, as the obsolete package really doesn't contribute to the stack trace being bad
<pitti> mdz: but all in all it's better to err on this side rather than keeping bugs with useless stack traces open
 * pitti checks the logs
<seb128> mdz, the libdbusmenu debug symbols didn't work it seems
<pitti> what the heck, it's missing two metric tons of debug symbols
<seb128> pitti, the only revelant ones a libdbusmenu-glib3-dbgsym missing
<pitti> http://paste.ubuntu.com/570585/
<pitti> oh, wait, this is misleading
<pitti> that's noise added by a recent patch, that tries to find both -dbg and -dbgsym
<seb128> pitti, can you see what libdbusmenu versions were installed?
 * pitti fixes that in trunk
<seb128> pitti, fix what? the -dbg thing?
<pitti> seb128: the confusing warnings about missing -dbg packages
<pitti> seb128: I can't see the installed libdbusmenu versions in the log, but it tries to install the one from Dependencies.txt
<pitti> libdbusmenu-glib3 0.3.97-0ubuntu3
<seb128> pitti, can you see what dbgsym was brough in?
<seb128> there was no version changes for some days before that crash
<seb128> the ddeb binaries should have been current and working
<seb128> or we are back to the gdb failing to load symbols issue we discussed yesterday
<pitti> http://ddebs.ubuntu.com/pool/main/libd/libdbusmenu/ even has both still
<pitti> seb128: if it's too old gdb, then it's a different breakage; https://i64539621.restricted.launchpadlibrarian.net/64539621/Stacktrace.txt doesn't complain anywhere about DWARF opcodes
<seb128> mdz, can you trigger that crash easily?
<mdz> seb128, it happens pretty regularly, debugging with cyphermox right now
<mdz> but on the phone
<seb128> ok
<seb128> mdz, can you submit the crash and give me the number before it's retraced if you have a chance?
<seb128> mdz, I want to try to retrace it manually to see what's going on
<mdz> seb128, it may not be the same one but my most recent crash is https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/723166
<ubottu> Error: Bug 723166 is private
<seb128> mdz, I was going to suggest opening also a but with a stacktrace, seems a libdbusmenu issue
<seb128> but->bug
<seb128> then we can ping ted about it
<seb128> but if cyphermox is debugging it that works as well
<pitti> seb128: just telling him how to get to mdz's unretraced bug and how to use apport-retrace
<seb128> pitti, I want to figure why the retracing is failing
<seb128> pitti, debug symbols work locally, I've been doing indicator valgrind and gdb logs recently and didn't get issues
<pitti> that'd be great; good luck!
<seb128> danke
<pitti> seb128: you could locally install gdb 6.8 and see whether that makes it fail?
<pitti> as a first step for bisecting where the problem is
<seb128> pitti, ok
<pitti> seb128: if it's 6.8, then I'll move back the gdk-pixbuf and udisks issues that'd be next in my queue, and start debugging that in the fakechroots
<seb128> why the heck isn't the apport-retrace auth thing working on the retracers
<seb128> ok, let me downgrading gdb locally first
<pitti> seb128: apport-chroot login --auth $HOME/.lpcookie chroots/natty.tar.gz
<pitti> seb128: --auth needs an absolute path, that's a common trap
<seb128> pitti, I did that
<seb128> and then apport-retrace --auth /tmp/auth
<pitti> right
<pitti> cat /tmp/auth works?
<pitti> if you use e. g. --auth ../.lpcookie, it'll fail
<seb128> pitti, ok, that was it, thanks
<pitti> seb128: fixed apport-chroot in bzr for doing os.path.abspath() now
<seb128> pitti, thanks
<ricotz> pitti, hi, could you look at the libbluray package in upload queue?
<pitti> ricotz: which queue?
<ricotz> pitti, natty new queue
<pitti> seb128: hm, gdk-pixbuf builds just fine here locally..
<pitti> ricotz: maybe later today, after meetings
<pitti> natty queues are usually done by the archive admins
<ricotz> pitti, alright, thanks
<seb128> pitti, it might be using system libraries for itself or something?
<seb128> pitti, it built fine there as well before I uploaded
<pitti> right, that was my idea; I'll try to remove them first
<seb128> ricotz, Riddell is archive admin of the day
<ricotz> seb128, thx
<ricotz> Riddell, could you take a look at the libbluray package in the natty new queue it will be needed to build a bluray-capable mplayer
<Riddell> ricotz: I'll be doing New queue reviews shortly
<ricotz> Riddell, thanks
<pitti> seb128: ah, there; that was it, building against libgdk-pixbuf2.0-dev
<seb128> pitti, ok, explains why it works locally
<doko_> mterry: about 555901, I opened it myself, I can't review it
<mterry> doko_, oh, must have missed that
<Riddell> mterry: could bug 718774 get some love?  we have a feature freeze deadline coming
<ubottu> Launchpad bug 718774 in pyudev (Ubuntu) "[MIR] pyudev" [Undecided,New] https://launchpad.net/bugs/718774
<mterry> Riddell, sorry, I've been doing feature freeze stuff of my own.  I can look at it today
<raphink> hi there :-)
<Riddell> hi raphink
<raphink> what's up?
<Riddell> feature freeze in two days!
<raphink> I know Riddell
<raphink> trying to get some people motivated to release augeas 0.8.0 before so I can upload it :-)
<Riddell> mpoirier: ** linux-n900 could not be accepted due to The source linux-n900 - 2.6.35-1.1 is already accepted in ubuntu/natty and you cannot upload the same version within the same distribution
<mpoirier> persia: ^^^^^^^
<Riddell> I accepted the first upload and rejected the second
<vila> cjwatson: after banging my head for quite some... time, I finally came across: http://paste.ubuntu.com/570627/
<vila> cjwatson: I'm more than willing to add my own thanks but I still don't understand what is going on
<vila> cjwatson: are such handlers inherited ? The case at hand is a python process spawning a shell itself spawning a 'yes' process
<vila> cjwatson: if I kill the shell, it turns into a zombie but the the parent python process can still read the 'y' sent by the 'yes' process 8-/
<siretart> who rejected libbluray in NEW and why?
<cjwatson> vila: signal dispositions set to SIG_IGN are preserved across fork and execve
<vila> cjwatson: if I use the subprocess_setup in the paste above, the 'yes' dies with the shell... I'm probably close to understanding why but... not there yet
<Riddell> siretart: https://lists.ubuntu.com/archives/ubuntu-archive/2011-February/039665.html
<cjwatson> vila: meeting, I'll get back to you in a bit
<vila> cjwatson: ok
<siretart> Riddell: ah, I see. thanks
<siretart> ricotz: I guess you are already on it?
<ricotz> siretart, hi, actually not, should have looked the copyright file :(
<siretart> ricotz: I'm pretty busy today with work stuff. do you have time to have a look?
<ricotz> siretart, not sure, was it accepted in debian?
<siretart> ricotz: still in NEW
<hyperair> DktrKranz: ping. got a moment to look at a NEW banshee-community-extensions? ;-)
<siretart> ricotz: if you can, please fix it in our git and upload from there. or ping me or someone to upload
<ricotz> siretart, ok, will see if i have some time
<ScottK> lamont: Coolness.  Thanks.
<mdz> is there a bug open about the excessive U1 notifications in natty? I get them constantly
<Riddell> ogra: W: libqtdee2: breaks-without-version libqtdee1
<hyperair> DktrKranz: actually forget it, we have new extensions, so wait til 1.9.4
<pitti> ? shouldn't different sonames be coinstallable?
<lamont> pitti: that is sort of why we have sonames in package names
<ogra> Riddell, thanks
<Riddell> pitti: the package contains some data files
<pitti> ah, that should be moved to a -common package then
<seb128> pitti, ok
<seb128> pitti, http://paste.ubuntu.com/570635/
<seb128> pitti, on the same return process locally with gdb 6.8 and7.2
 * ogra is currently busy with libqtbamf, i'll care for qtdee afterwards
<pitti> seb128: ok, so I'll sit down and have a deep look at this gdb 7.2 breakage after the TB meeting
<pitti> seb128: which bug # were you using for testing again? (in the fakechroots)
<seb128> pitti, I didn't find one which fails in today's queue and all the old retracing which failed has their crashdumps cleaned
<pitti> seb128: which one were you using for above pastebin?
<seb128> pitti, let's wait a bit i'm sure we will receive another crash to play with
<seb128> pitti, I just attach gdb to a running indicator and put a breakpoint
<pitti> seb128: well, at some point we need to update to gdb 7.2 anyway; it alreayd hurt us with x.org
<pitti> seb128: ah
<seb128> pitti, I guess you can sig11 an indicator and copy the crashdump to the dc and play with gdb on it
<pitti> seb128: I'll find one
<pitti> right
<pitti> seb128: https://launchpad.net/ubuntu/+source/gdk-pixbuf/2.23.0-1ubuntu3 \o/
<seb128> pitti, danke!
<pitti> de rien
<seb128> wth with the i386 retracer as well
<seb128> pitti, oh btw I commented the 10.10 amd64 retracer because I screwed the tarball for it
<seb128> I will fix that later on
<pitti> seb128: that's ok; it will fail anyway, as maverick's apport is still trying to talk to edge
<seb128> (I did Ctrl-C the wrong command and stopped it while it was doing the update)
<pitti> seb128: you can "exit 1" (or anything non-zero) in a --save chroot to abort the saving, btw
<pitti> that's the "oh sh**" ejection seat
<seb128> right, I know, but that was a run of the crash-digger
<seb128> i.e same command as the cron
<GunnarHj> ScottK: Hi, the lists of backports bugs are alarmingly long. Is there any chance to draw your attention to bug 719815, which I have prepared with branches that should be ready to build from?
<ubottu> Launchpad bug 719815 in maverick-backports "Please backport gdm and language-selector to Lucid and Maverick" [Undecided,Confirmed] https://launchpad.net/bugs/719815
<ScottK> GunnarHj: For something as central to Ubuntu Desktop as gdm, I'd want someone from the Desktop team like seb128 to review it.
<ScottK> If you can get seb128 (or whoever he wants to look into it) to concur with the backport, then ping me.
<seb128> no opinion on that one, pitti has been sponsoring the work in natty and is probably better placed to comment
<GunnarHj> ScottK: I see. I'll ask Martin P. then, since he sponsored me when uploading the things in Natty.
<ScottK> That'd be fine too.
<pitti> tseliot, bryce: AFAIR nvidia or nvidia-common now have postinst magic to do the necessary xorg.conf additions; do we still need to do any of them in jockey? We currently set DefaultDepth=24 (all versions) and AddARGBGLXVisuals=True (for version 96)
<pitti> and it also disables the dri2 module
<pitti> AFAIR the actual driver doesn't need to be set any more, as x.org now autodetects it and prefers nvidia > nv, right?
<tseliot> pitti: nvidia-common, in addition to the libraries which Jockey uses, has some debconf magic to handle obsolete drivers but I don't think it deals with xorg.conf in any way
<tseliot> pitti: the code that touches xorg.conf files is all in Jockey's handlers. And we definitely need the NoLogo option even though DefaultDepth is now set by default when no xorg.conf is available
<pitti> tseliot: ah, ok, thanks; seems I misremembered then
<pitti> might have mixed it up with the blacklisting in wl
<tseliot> pitti: yes, that's likely (about wl). I keep forgetting about nvidia-common too ;)
<slangasek> cjwatson: looks good to me :)
 * slangasek giggles at the implications of a multi-arch: foreign binfmt-support
<cjwatson> thought you might like it
<sebner> tseliot: is the new linux blob beta driver compatible with new xorg already?
<tseliot> sebner: nope
<sebner> tseliot: :(
<sebner> tseliot: well, still 2 months time ^^
<tseliot> yep
<GunnarHj> ScottK: Martin added a short comment on bug 719815. His remark about l-s not working was made before he realised that I prepared custom branches. (He is in a meeting now.)
<ubottu> Launchpad bug 719815 in maverick-backports "Please backport gdm and language-selector to Lucid and Maverick" [Undecided,Confirmed] https://launchpad.net/bugs/719815
<kirkland> seb128: pitti: didrocks: hey guys;  you helped me get alt-tab working in Gnome last week;  i'm *trying* to use unity now, and alt-tab is disabled there
<seb128> kirkland, try to run unity --reset
<ScottK> GunnarHj: OK.  I'm just heading out for a $work meeting.  Please ping me again tomorow.
<kirkland> seb128: pitti: didrocks: I went back to compiz settings in unity and enabled application switch and all hell broke loose
<kirkland> seb128: okay, i'll do that, but can you tell me what unity --reset does, and why i need to run it daily?
<didrocks> kirkland: enabling disabling plugin make compiz crash
<seb128> you shouldn't need to run it daily
<GunnarHj> ScottK: Ok, will do.
<didrocks> kirkland: did you change other plugins?
<seb128> kirkland, it reset your compiz unity profile
<kirkland> seb128: hmm, well i have to run it every time i ask a question about unity
<didrocks> normally, staticswitcher is enabled by default
<didrocks> I didn't run it for weeks here
<seb128> kirkland, well seems resetting your normal profile worked last time you might have the same issue in your unity profile
<didrocks> it's just resetting all your unity and compiz config to default
<seb128> kirkland, you shouldn't have to run it again if you don't play with ccsm settings
<kirkland> didrocks: seb128: okay, i've run unity --reset, still no alt-tab
<kirkland> seb128: i never play with ccsm settings
<seb128> ok so you probably have a different issue, I will let didrocks deal with that
<kirkland> seb128: thanks
<kirkland> didrocks: help?  :-)
<kirkland> didrocks: i haven't changed any settings;  any settings that might have been changed can be killed
<didrocks> seb128: only dealing with easy answers?  :p
<kirkland> didrocks: all i want is alt-tab to work, and i want super-L to push-to-talk in Mumble
<seb128> kirkland, what videocard do you have?
<didrocks> kirkland: ok, so now that you resetted
<didrocks> kirkland: can you try two things
<seb128> didrocks, we all need to recon our competence limits :p
<didrocks> Super + W
<didrocks> seb128: heh :)
<didrocks> then, look at ccsm and look if staticswitcher is enabled
<kirkland> seb128: intel, in an x201
<kirkland> directhex: what is Super + W ?
<didrocks> kirkland: it's supposed to trigger the expo mode
<directhex> snuh?
<didrocks> (same that if you click on the ws switcher button)
<didrocks> directhex: I think the question was for me :)
<kirkland> directhex: sorry
<kirkland> didrocks: right, what keys are Super + W ?
<didrocks> what keys? Not super to understand the question
<didrocks> sure*
<kirkland> seb128: http://pastebin.ubuntu.com/570658/
<kirkland> didrocks: what do i press on my keyboard to activate Super + W ?
<kirkland> didrocks: ie, I press the Windows key to activate Super + L
<kirkland> didrocks: what do i press to do you what you asked me to do, Super + W?
<seb128> kirkland, super = windows key
<seb128> so super - W = windows_key - W
<kirkland> seb128: okay, when i press that, all of my windows zoom out to little thumbnails
<didrocks> kirkland: ok, so the expo effect (used by staticswitcher is there)
<kirkland> didrocks: ^
<pitti> seb128: I sent an RT ticket for the dchroot error message cron spam, FYI
<didrocks> kirkland: so, look at ccsm now
<didrocks> is staticswitcher enabled?
<kirkland> didrocks: hmm, i'm kind of afraid of ccsm right now;  when i changed something in there 10 minutes ago, my whole desktop when bonkers....
<kirkland> :-)
<kirkland> didrocks: okay, application switcher is not enabled
<kirkland> didrocks: i don't see anything called "static switcher"
<didrocks> kirkland: right, activating/deactivating plugins make compiz crash
<kirkland> didrocks: aint that a shame
<didrocks> kirkland: a bug rather
<seb128> it will be fixed before natty
<didrocks> kirkland: ok, you don't have compiz-plugins-main installed I bet
<didrocks> let me look for the exact package name
<didrocks> kirkland: compiz-fusion-plugins-main
<kirkland> didrocks: right, that wasn't installed
<kirkland> didrocks: installing now
<kirkland> didrocks: okay, installed, now what?
 * kirkland bets he has to unity --reset again
<didrocks> kirkland: hum, maybe not :)
<robertknight> The blueprint page for the 'ThirdPartyApt' spec states that it has been superseded (https://wiki.ubuntu.com/ThirdPartyApt) but I couldn't see what it was replaced by.
<didrocks> kirkland: not sure if compiz changes the keys
<kirkland> didrocks: okay, now i have the static switch in compiz config thingy
<kirkland> didrocks: and it is enabled
<didrocks> kirkland: ok, just restart unity then :)
<kirkland> didrocks: how do i do that?
<didrocks> launch unity
<kirkland> didrocks: logout and log back in?
<didrocks> $ unity
<didrocks> or logout and log back
<didrocks> as you want :)
<kirkland> can i launch unity from within unity?
<didrocks> yeah :)
<kirkland> didrocks: okay, thanks, now i can alt-tab, thanks
<kirkland> didrocks: indulge me with one more question ...
<didrocks> sure :)
<kirkland> didrocks: why do my icons go back and forth, back and forth from colored icons, to the monochrome ones, every day?
<kirkland> didrocks: like the ubuntu symbol in the top left?
<didrocks> kirkland: when you hover the ubuntu icon?
<didrocks> yeah, it's fading
<kirkland> no
<didrocks> I can ensure you it's fading, I wrote it :p
<didrocks> so, basically, the idea is:
<kirkland> didrocks: that's not what i mean
<kirkland> didrocks: http://people.canonical.com/~kirkland/Screenshot.png
<kirkland> didrocks: see how i have the 3-color ubuntu symbol right now?
<didrocks> oh
<didrocks> gnome-settings-daemon is crashing for you
<didrocks> I think there is a known crasher right now, seb128 ? ^
<kirkland> didrocks: if i reboot or logout/login later, i might have the colored one, or, i might have the black-and-white monochrome theme
<seb128> kirkland, run gnome-settings-daemon
<pitti> seb128: purging the launchpadlib cache helped, i386 retracer runs again
<kirkland> didrocks: and if i logout/in later, it might be back to the colorful one
<seb128> pitti, oh, weird but nice as well
<didrocks> yeah, g-s-d in any case
<seb128> kirkland, it seems g-s-d is crashing
<seb128> didrocks, yes, several known crashers
<kirkland> didrocks: seb128: i don't care much which it is;  i'm just kinda tired of the back and forth, back and forth :-)
<kirkland> seb128: okay
<kirkland> let me run that
<seb128> there is a race with the gdm g-s-d which makes the user one try to run before the gdm one exit on modern hardwares
<pitti> seb128: ~/.launchpadlib/api.launchpad.net/credentials/ had ".lpcookie       apport-collect  debug", that looked confusing asa well
<seb128> in those case it fails to start
<kirkland> seb128: http://pastebin.ubuntu.com/570665/
<pitti> seb128: I don't restart them yet, though, while I'm debugging
<seb128> pitti, that was me trying to figure what ./subscribe... tries to use
<seb128> pitti, the directory was empty earlier
<pitti> ah, ok; so it was something in the cache then
<seb128> pitti, I started by copying the debug one api.edge
<seb128> one from api.edge
<ogra> Riddell, what data files were you referring to above in libqtdee ?
<Riddell> ogra: qml files no?
<Riddell> ogra: my issue is that Breaks should be Conflicts (at least that's what lintian said, I'm not too bothered)
<ogra> Riddell, /usr/lib/qt4/imports/dee/qmldir which contains the plugin name
<ogra> i think its needed by the lib to function properly
<ogra> Riddell, yeah, i see that lintian warning, i wonder why a check of the source doesnt reveal it and i'm a bit confused, i thoght all Confilcts are supposed to be replaced by Breaks nowadays
<ogra> pitti, ^^^ ?
<ogra> wasnt theer a policy change ?
<Riddell> not all
<ogra> ah
<Riddell> http://lintian.debian.org/tags/breaks-without-version.html
<pitti> ogra: it needs to be versioned then, if the breakage is only due to a bug (and getting fixed), and not permanent
<ogra> well, its mainly just a transition to a new ABI number
<pitti> "Conflicts should be used ... in other cases where one must prevent simultaneous installation of two packages for reasons that are ongoing (not fixed in a later version of one of the packages)"
<pitti> http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts
<cjwatson> vila: I'm not sure I quite understand the context of your question.  Can you give me some?  An 'strace -f' would help too
<pitti> ogra: as this is clearly a bug in the package which should be fixed (and should have been caugth in MIR review, FWIW), Breaks: is actually correct :)
<ogra> pitti, it was v1 during MIR review
<ogra> ABI bump just happened with recent upload
<pitti> ogra: right, but library packages must not ship non-SONAME specific paths
<vila> cjwatson: hmm, strace would be tricky there as it's in a test and can't reproduced on demand :-/ but,
<ogra> pitti, oh, you mean i need to create a whole package for the one file that tells the lib where to find its plugin ?
<ogra> (it wont function without that one file)
<vila> cjwatson: roughly it's subprocess.Popen('yes', shell=True, stdout.PIPE, sterr.PIPE)
<ogra> that seems a bit overkill
<pitti> ogra: that, or make the one file obsolete, or moving it to a subdir which is named after the soname
<pitti> ogra: why do you need a file which tells you where to find another file?
<ogra> i'm not sure upstream will still work afterwards
<cjwatson> vila: ok, and what results are you trying to get?
<vila> cjwatson: then os.kill(proc.pid)
<ogra> pitti, no idea, i'm just taking upstreams branch and upload it, i have no clue how QML works
<vila> cjwatson: and I want both '/bin/sh' and 'yes' to die
 * ogra will try to find out
<vila> cjwatson: I got that most of the time, but sometimes, I get '/bin/sh' zombie and 'yes' still alive
<vila> cjwatson: so the preserved SIG_IGN was at least a valid scenario, but after tens of tests, the zombie is back (not that surprising for a zombie you might say but still)
<cjwatson> vila: I would do subp.stdout.close(); subp.wait()
<cjwatson> vila: if you've done that subprocess_setup thing to fix python's broken defaults, then that will cause the yes process to get SIGPIPE and die, and then its parent sh will die too
<cjwatson> assuming there are no other dups of subp.stdout
<vila> cjwatson: that will work for 'yes' but I use it only for tests, I want to capture stderr/stdout until the death in the general case
<vila> cjwatson: that's what I thought too, but evidence disagrees :(
<cjwatson> your current code has nothing to do with that SIG_IGN thing
<cjwatson> you're not sending it SIGPIPE so the disposition of SIGPIPE is at best relevant only by chance
<cjwatson> SIGPIPE only happens when a process tries to write to a pipe with no open readeres
<cjwatson> *readers
<vila> cjwatson: so even if the ssh is a zombie the pipes are still alive between 'yes' and my python 'process' ?
<cjwatson> yes
<vila> s!ssh!/bin/sh!
<cjwatson> the data from yes does not go through the sh process
<vila> ok
<vila> and but the SIGTERM signal should still be received by 'yes' no ?
<cjwatson> no, why would it?
<cjwatson> you're only killing the sh
<cjwatson> if you want to kill all the subprocesses, then you need to create a new process group
<cjwatson> os.setpgrp
<cjwatson> then you can os.kill(-proc.pid) (note the -) to send a signal to all the processes in the process group
<vila> cjwatson: the group can start at the subprocess level ? (aka the /bin/sh one)
<cjwatson> yes, you can do setpgrp in a preexec_fn
<vila> haaaa
<vila> that's it then
<cjwatson> you may still have some other problem; consider races between the kill and your subprocess forking something
<cjwatson> it's difficult to fix this if you don't want to close subp.stdout
<vila> cjwatson: not in my case
<cjwatson> you have at least one fork even in your dummy example
<vila> at least if the progress group is inherited
<vila> cjwatson: two forks, one for /bin/sh, one for yes, correct ?
<cjwatson> yeah, two, and of course you have no control over whether the kernel pauses for a week between scheduling the two of them
<cjwatson> you should be OK as long as none of the processes have SIGTERM handlers
<cjwatson> you could follow the strategy of SIGTERM, wait a bit, SIGKILL
<vila> you mean I can manage to kill /bin/sh while 'yes' is still llimbo ?
<vila> s/llimbo/in limbo/
<cjwatson> no, in your case it will be OK
<cjwatson> it would only be for processes that have "clever" SIGTERM handlers so that they might go on to fork something else even after you've sent SIGTERM
<vila> right, out of scope for me indeed
<cjwatson> I would say, though, that any and all uses of Python's subprocess module to do anything other than forking another Python process should use that SIGPIPE fragment
<cjwatson> I have a bug open to make it the default
<cjwatson> I should push that further up the hill at some point
<vila> the subprocess aren't supposed to play tricks like that
<vila> cjwatson: but then, if the subprocess is a python one, won't it re-install the handler for its own need ?
<cjwatson> that's why I said "anything other than forking another Python process", because as you say Python will reinstall the handler
<vila> cjwatson: so your fragment can be safely used in all cases
<cjwatson> oh, certainly
<cjwatson> it's just not mandatory in that exceptional case :)
<vila> ok great
<cjwatson> (and honestly, who does that ...)
<vila> cjwatson: well, I was about to switch to shell=False and stick to python to be honest ;)
<cjwatson> shell=True is usually a bad idea anyway
<cjwatson> there's no reason for it except in very lazy programs
<vila> cjwatson: or very simple tests from an unsuspecting dev :-}
<cjwatson> shell=False saves a process, avoids going through the shell's command parsing, and encourages clearer thinking
<cjwatson> (and saves kittens)
<vila> hehe, well, 'false', 'yes', 'true' are good and simple commands to think about when concentrating on other stuff ;)
<vila> cjwatson: thanks a lot anyway (I found this snippet while grepping madly, glad you were the right Colin ;)
<cjwatson> heh, yeah, I'm the one obsessed with minutiae of spawning subprocesses
<cjwatson> pitti: could you look at utouch-frame in NEW?
<cjwatson> needed to fix d-i
<ogra> pitti, what does the policy gain us here Kaleo and i are discussing the package, the lib wont work without the dir, QML needs the file ... if i package a -common package with the one file included we wont gain anything
<vila> cjwatson: well, we're two ;)
<cjwatson> ogra: the purpose of the policy is to simplify future upgrades by ensuring that multiple versions of libraries are coinstallable
<Kaleo> ogra: one thing though: the lib works without the QML plugin
<Kaleo> ogra: the QML plugin can be made a separate package that depends on the lib
<cjwatson> ogra: non-coinstallable libraries create complications for apt
<ogra> ah
<vila> cjwatson: and I think I found the problem in my test: I was probably killing /bin/sh *before* it could fork 'yes', adding os.setpgrp made it fail at one point highlighting the race
<ogra> Kaleo, so should i create a -common package for ./usr/lib/qt4/imports/dee/ then ?
<Kaleo> ogra: not really
<cjwatson> vila: if you killed it before it forked yes, it wouldn't have forked it, I'd expect
<ogra> how else do we solve it ?
<Kaleo> ogra: more of a package named libqtdee-qml or libqtdee-declarative
<ogra> sigh
<cjwatson> vila: perhaps sh has a race where if you kill it just after it forks a subprocess it forgets that it needs to clean it up
<ogra> that needs changes in a lot of additional places then
<ogra> assuming that libqtdee-qml will now be our toplevel
<cjwatson> or perhaps killing sh doesn't reliably kill its subprocesses in the first place; I try to avoid relying on that kind of thing
<vila> cjwatson: could be, and tests may not be the best place to ... right
<Kaleo> ogra: libqtdee-qml would depend on the libqtdee and unity-2d would depend on libqtdee-qml
<ogra> Kaleo, thats what i mean, yeah
<bcurtiswx> is there an apt command to view the changelog from a package?
<Kaleo> ogra: actually I don't think we use libqtdee-qml in Unity 2D anymore, let me check
<vila> cjwatson: sounds like the best option anyway, too many obscure edge cases there that I can safely avoid by sticking to python
 * Kaleo has the feeling he is talking shit
<ogra> Kaleo, you mean it could go completely ?
 * ogra is confused
<Kaleo> ogra: well, it *could* go because nobody is using it today; it does not mean it should go: it is a very useful QML plugin on its own
 * ogra tries to find an ARM employee to get him access to the coffee bar ... one sec brb
<Kaleo> ogra: but in terms of dependency for Unity 2D we don't need it; we can depend as we do today on libqtdee
<Kaleo> ogra: and just split out in a separate binary package the qml plugin
<Kaleo> ogra: would that be ok?
<cjwatson> bcurtiswx: apt-get changelog, as of natty.  not in earlier releases.
<Kaleo> ogra: but I am not sure it helps the purpose of the policy
<Kaleo> ogra: essentially the QML plugin is a library
<bcurtiswx> cjwatson, OK so if I'm on a maverick machine looking for a natty changelog, i should just use packages.ubuntu.com ?
<Kaleo> ogra: and right now multiple versions of libraries are not coinstallable
<Kaleo> ogra: and it won't help to create another package I am afraid
<cjwatson> bcurtiswx: yes, or launchpad
<bcurtiswx> thanks
<ogra> Kaleo, well, if pitti hadnt complained i wouldnt have been inclined to even think about changing it
<ogra> (sorry for the interruption)
<Kaleo> ogra: don't worry :)
<Kaleo> pitti: what's your take on it? (I was not on the chan before, sorry)
<jono> is anyone having playback issues with Banshee in Natty?
<jono> I am getting this when running it in the terminal:
<jono> [Warn  10:21:46.152] Service `Banshee.MediaEngine.PlayerEngineService' not initialized: Broken pipe [EPIPE].
<davidascher> barry: ping
 * ogra wonders if jono secretly switched to arm hardware ... we are used to such errors in banshee :)
<jono> ogra, strange
<jono> I assume my alsasink is not working in gstreamer
<ogra> yeah, something like that
<ogra> there is a debug flag you can run mono apps with
<ogra> see --help of banshee
<slangasek> pitti: so do you think we need to worry about package size increases on i386 if I make this cdbs change?
<pitti> re
<pitti> ogra: we will gain upgradeability
<pitti> ogra, Kaleo: as I said, you could store the qml file in a per-SONAME path
<pitti> i. e. not /usr/share/myproject/foo.qml, but /usr/share/myproject/0/foo.qml
<ogra> pitti, then QML wont work anymore
<ogra> it looks in that specific path
<pitti> the hackish alternative would be to have all libfooN Replaces: libfoo(N-1), libfoo(N-2), etc.
<pitti> but that piles up over time
<pitti> ogra: the cleanest solution really is to move the QML file away from the library
<ogra> and have a -common package ?
<pitti> ogra: why does it need to be in the lib? it could be in unity-2d itself?
<pitti> or another one which is suitable
<ogra> i think a -common package or a -qml package would be cleaner
<pitti> slangasek: alternates will certainly go up a bit, but as the difference to amd64 hasn't gone up significantly, I'm not too worried about this
<ogra> instead of tainting unity-2d sources
<slangasek> pitti: ok
<pitti> slangasek: and anyway, we don't have much choice here, do we?
<slangasek> pitti: well, we could defer this change until the beginning of natty+1 and I could use $CDBS_NO_DOC_SYMLINKING for anything I need to touch right now
<slangasek> pitti: but I prefer to fix cdbs if that's ok with you :)
<tkamppeter> mterry, I have uploaded the ghostscript version which needs gs-cjk-resource now. Can you please move gs-cjk-resource into main before FF? Thanks. Bug 718692.
<ubottu> Launchpad bug 718692 in gs-cjk-resource (Ubuntu) "[MIR] gs-cjk-resource" [Undecided,Fix committed] https://launchpad.net/bugs/718692
<tkamppeter> pitti, or can you move an approved MIR, too?
<mterry> tkamppeter, I'm not an archive admin, so I can't do it
<tkamppeter> pitti, I have uploaded ghostscript 9.01~dfsg-1ubuntu1 which depends on gs-cjk-resource at run time, but not during build. Does this cause any problem with gs-cjk-resource being moved to main?
<pitti> tkamppeter: it will cause CDs to become uninstallable
<pitti> (main dependency to universe)
<pitti> does it have an approved MIR?
<tkamppeter> pitti, the MIR is filed as bug 718692 and already set to "Fix committed" by the MIR approval team.
<ubottu> Launchpad bug 718692 in gs-cjk-resource (Ubuntu) "[MIR] gs-cjk-resource" [Undecided,Fix committed] https://launchpad.net/bugs/718692
<pitti> tkamppeter: ah, sweet; let me promote it then, to avoid uninstallability
<cody-somerville> Can anyone confirm that marking a bug as incomplete after a bug has been verified and triaged and we're just waiting to confirm a patch fixes the issue is *not* standard process?
<tkamppeter> pitti, thanks.
<pitti> done
<pitti> cody-somerville: I have used "incomplete" in that way -- for me it generally means "the assignee cannot continue working on this bug wwithout further data from the reporter"
<pitti> not sure whether that's being frowned upon, though
<tkamppeter> pitti, thanks.
<cody-somerville> pitti, It seems wrong to me that a bug would get expired because the reporter decided not to build their own kernel to test a patch when clearly the bug had enough information for a developer to come up with a tentative patch.
<pitti> cody-somerville: that seems extreme, yes; I usually build a package with a patch in a PPA if I can't reproduce the problem and am unsure whether my patch fixes it
<pitti> I think it should be acceptable to ask a bug reporter to try a PPA
<pitti> (if you ensure that it has nothing else/crackful in it)
<pitti> building kernels with a patch, not so much
 * cody-somerville happens to be the reporter who has a kernel bug marked incomplete waiting for him to test a kernel patch <g>.
<cody-somerville> pitti, what would you recommend as a status instead? maybe in progress?
<pitti> sounds ok, but it would interfere with my bug list
<pitti> I'd actually recommend "needs info", but ask for a test kernel in a PPA or some people.c.c. URL :)
 * cody-somerville nods.
<cody-somerville> pitti, Are you on Maverick?
<pitti> no, natty COTD
<cody-somerville> pitti, Do you have a usb headset by any chance?
<pitti> cody-somerville: I had until a few months ago, then the cable broke, and I threw it away
<cody-somerville> ah
<pitti> I have an USB sound card, though
<pitti> i. e. USB to standard mike/headphone jack
<pitti> I found that more flexible, as usually I want to use my laptop's normal jacks
<cody-somerville> pitti, not sure if that would trigger it but if I unplug my usb headset while audio is playing my kernel panics - a number of other folks have reported the same issue. Seems like a nasty little regression in maverick. :(
<\sh> anyone has a clue how to determine reliable a chroot environment (without tweaking the shell prompt, pls ;))
<\sh> cody-somerville: should I unplug my usb headset now to test?
<\sh> eventually switching before that to tty0?
<cody-somerville> \sh, after saving your work, be my guest. I've gotten a kernel traceback and vmdump but if you do see anything interesting not already in the bug report (LP #715318) feel free to add.
<ubottu> Launchpad bug 715318 in linux (Ubuntu) "Disconnecting USB headset while audio playing results in kernel panic" [Undecided,Incomplete] https://launchpad.net/bugs/715318
<cody-somerville> \sh, If you can reproduce and also happen to enjoy compiling your own kernel, I'd be most grateful if you tested the proposed patch as well :)
<pitti> cody-somerville: just tried that here in current natty, works fine
<\sh> cody-somerville: the stacktrace is written somewhere while it crashes or should I enable crashdump writing support somehow?
<slangasek> pitti: do you want to review my cdbs patch before I upload, or are you happy as long as it passes my shallow testing?
<pitti> slangasek: I trust the test suite enough to prevent major damage, but I'm happy to peer review; is it in bzr?
<cody-somerville> \sh, I installed 'crash', ran sudo mkdir -p /var/crash/, and tweaked a few files in /etc/defaults/ for good measure turning all the crash related stuff I could find on, lol
<pitti> slangasek: hm, nothing new in the branch right now
<slangasek> pitti: not yet, let me push it there (gimme 10 minutes, I don't have the branch downloaded yet)
<\sh> cody-somerville: ok..will do the same :) just to be sure...but give me a couple of minutes I need to tweak our firewalls first
<slangasek> I only looked at the UDD branch, which is out of date ;)
<pitti> "Vcs-Bzr:" is the right onw
<pitti> one
<pitti> (dinner ready, back in a bit)
<pitti> slangasek: anyway, feel free to upload; there are enough version numbers :)
<slangasek> heh
<pitti> but please commit it to bzr as well
<cody-somerville> \sh, Note that if you have apport enabled it'll churn over the dump for awhile generating a crash report after crashdump reboots the system for you.
<slangasek> pitti: yes, will do
<barry> davidascher: hiya!
<davidascher> barry: question for you about smtpd.py...
<davidascher> although i think i figured out most of what i wanted.
<cody-somerville> \sh, I also found apport complained (sadly) about 'TypeError: Incorrect padding' but I just ignored that, downloaded the debug kernel, and used crash to extract the log data myself. A second go at it seemed to work alright but then Launchpad gave apport a server error at the very end of the very long upload :(
<barry> davidascher: goforit
<davidascher> is there something better?  I don't actually need TLS right now, but it seems that some parts of ESMTP are worth doing.
<davidascher> i think i figured out the other q's i was going to ask.
<barry> davidascher: there's nothing better in the stdlib.  it's possible twisted has something more feature full.  i do remember a patch to smtpd.py that added a bunch of useful esmtp commands.  i need to dig up where i saw that thow
<barry> er, though
<slangasek> pitti: my UDD wish of the day: documentation for how to merge a pre-existing bzr packaging branch into a UDD branch without losing any history from either :-)
<\sh> cody-somerville: looks like I need to postpone the testing towards tomorrow morning ... real life work haunts me ...
<cody-somerville> \sh, no problem :) ty anyways
<highvoltage> hey, on the edubuntu daily builds, the packages shipped on the live disk aren't added through apt-cdrom when booting from a live USB disk
<ricotz> Riddell, i have fixed the copyright file of libbluray you can take a second look if you dont mind
<highvoltage> this used to work on maverick, I'll file a bug on it, but is there anyone I should poke about it?
<highvoltage> it seems like the usb disk used to be mounted as /media/cdrom before, but that doesn't seem to be happening anymore for some reason
<pitti> slangasek: seconded
<slangasek> huh; how do we get a branch format update for a vcs-import branch?
<soren> slangasek: There used to be a button on the launchpad web ui.
<slangasek> soren: only for branches you have write access to :-)
<slangasek> which I don't, for ~vcs-import
<soren> Point.
<siretart> Riddell: ricotz: libbluray reuploaded
<RoAkSoAx> vish: ping
<psusi> pitti: I threw in a UDF DVD+RW the other day and it was not being mounted with uid=,gid= options.  Does udisks only add those for fat/ntfs or something?
<pitti> psusi: no, they are in udf_defaults[]
<pitti> psusi: perhaps you had the drive in /etc/fstab?
<psusi> pitti: I'm pretty sure I don't have it in fstab... it's auto mounted when inserted...
<psusi> I'll check though
<psusi> so it should be adding the options for udf as well then?
<pitti> psusi: fstab doesn't preclude automounting, it just overrides udisks' default options
<pitti> psusi: yes
<psusi> ahh, cool... probably that then.. I'll check and get rid of it.
<psusi> I wonder if I should add those options for ext4 too?
<pitti> ext4 doesn't have uid/gid
<psusi> would be kind of nice to be able to use that for removable media
<pitti> it's a real file system
<psusi> right... I have been thinking I shuold add it
<psusi> be nice to be able to disable permissions for removable media
<psusi> udf can store proper ownership, but lets you disable it
<psusi> be nice if ext4 did the same
<zul> skaet_: is there a way to nominate a bug for a later release?
<ogra_> zul, ubuntu-later as milestone ?
<ogra_> iirc we had that once
<zul> nm i think i figured it out
<slangasek> zul: there are pre-populated release series for O, P in launchpad
<pitti> ev: got bug 723223 working in trunk now; I have some other refinements to make; do you want me to upload this now, and do the refinements later, or can it still wait a bit?
<ubottu> Launchpad bug 723223 in jockey (Ubuntu Natty) "Jockey should provide a way to run noninteractively without dbus" [High,Fix committed] https://launchpad.net/bugs/723223
<seb128> pitti, speaking of jockey, bug #712685 seems to have some recent duplicates
<ubottu> Launchpad bug 712685 in jockey (Ubuntu) "jockey-gtk crashed with UnboundLocalError in install_package(): local variable 'repository_added' referenced before assignment" [Undecided,New] https://launchpad.net/bugs/712685
<seb128> pitti, bug #719523 as well but that might be due to the svg breakage
<ubottu> Launchpad bug 719523 in jockey (Ubuntu) "jockey-gtk crashed with GError in function(): Icon 'jockey-disabled' not present in theme" [Undecided,New] https://launchpad.net/bugs/719523
<pitti> seb128: the latter should be fixed now
<pitti> should be a dupe of bug 715753)
<ubottu> Launchpad bug 715753 in jockey (Ubuntu Natty) "jockey-gtk crashed with GError in function(): Icon 'jockey-disabled' not present in theme" [High,Fix released] https://launchpad.net/bugs/715753
<seb128> pitti, ok, I'm just doing some cleanup of apport-crash bugs
 * pitti dupes
<seb128> pitti, thanks
<pitti> seb128: thanks for pointing out the first one, this looks easy to fix
<seb128> yw
<cnd> Riddell, I've been working on the multitouch stuff, and I've got a patch to enable multitouch in qt
<cnd> I'm cleaning it up and testing it right now
<cnd> I'd like to get it in before feature freeze
<cnd> what are your thoughts?
<pitti> seb128: fixed :)
<seb128> pitti, ;-)
<seb128> pitti, bug #717776 could be an easy one as well
<ubottu> Launchpad bug 717776 in jockey (Ubuntu) "jockey-gtk crashed with ValueError in install_package(): Package nvidia-glx-195 does not exist" [Undecided,New] https://launchpad.net/bugs/717776
<seb128> not sure if that's a list of nvidia drivers to update?
<pitti> that's a bit more tricky, I'm afraid; I'll keep it on the radar, thoug
 * pitti waves good nigth
<seb128> pitti, ok, there is also bug #710194 and some similars
<ubottu> Launchpad bug 710194 in jockey (Ubuntu) "jockey-gtk crashed with UnicodeEncodeError in update_tree_model(): 'ascii' codec can't encode characters in position 0-12: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/710194
<seb128> but enough for today indeed
<seb128> pitti, 'night!
<Riddell> cnd: hi
<Riddell> cnd: that's interesting
<Riddell> cnd: the first question from Kubuntu with regards to patches is always is there a path to getting it upstream
<cnd> Riddell, the patch came from a qt developer
<cnd> he had to step away from the project
<cnd> but it will get into upstream one way or another
<cnd> though it may not be in exactly this form
<cnd> the patch adds about 600 lines of code
<Riddell> lovely
<Riddell> cnd: then does it add unstable interfaces?
<cnd> Riddell, nope
<cnd> api is the same as always
<cnd> just that touch events now are possible on linux
<cnd> the touch api has been available since qt 4.6, and it works for win and mac
<Riddell> ah, I didn't know that
<cnd> this patch just hooks up the plumbing from the new xi 2.1 that I've been working on
<Riddell> cnd: sounds good then, we should get some packages made
<Riddell> cnd: are you into packaging or are you looking for me or something to do it?
<cnd> Riddell, in fact, I've already got a package in ppa:utouch-team/xorg-unstable
<cnd> I can package it up (just throwing the patch in)
<cnd> how do you normally take things?
<cnd> bzr merges?
<cnd> copy the new source package somewhere?
<Riddell> cnd: we use ~kubuntu-members/qt/ubuntu for the packaging
<Riddell> so a merge into that would be lovely
<cnd> Riddell, ok, I'll work on that
<cnd> Riddell, when do you need it by to review and upload for feature freeze?
<Riddell> cnd: not sure when feature freeze is going to be declaired but within 24 hours would be sensible
<cnd> Riddell, ok, I think I can make that
<valavanisalex> Hi All... Packaging query: does the X-Ubuntu-Gettext-Domain key need to go under the [Desktop Entry] group in a .desktop file, or can it just go anywhere?
<Riddell> ricotz: ping
<Riddell> ricotz: http://thread.gmane.org/gmane.comp.audio.libcanberra.general/199
<JontheEchidna> valavanisalex: it's automatically added to .desktop files that need it
<JontheEchidna> by the ubuntu build daemons
<JontheEchidna> you don't have to worry about that unless it needs to be customized for some reason
<ricotz> Riddell, huh? you mean robert_ancell ;)
<valavanisalex> JontheEchidna: ah OK.  The Inkscape package currently contains a manual patch to add the line.  However, it appears at the end of the .desktop file inside a different group
<valavanisalex> JontheEchidna: Is it best to remove the manual patch then, and allow automatic configuration?
<robert_ancell> Riddell, thanks.  That's a very indirect way of contacting the Ubuntu developers :)
<JontheEchidna> valavanisalex: if there's a patch manually setting it, there is probably a reason
<Riddell> ricotz: I don't think so, your name is down as adding the patch which makes that change
<ricotz> robert_ancell, i have upload the g-s package
<ricotz> Riddell, where?
<Riddell> ricotz: libcanberra debian/changelog says [ Rico Tzschichholz ] - add 90-patch-theme-for-ubuntu.patch
<valavanisalex> JontheEchidna: The trouble is that a new dpatch patch has been added recently, which creates a new group in the .desktop file.  The X-Ubuntu-Gettext-Domain key is appended afterwards by debian/rules, so the key ends up being added to the new group rather than [Desktop Entry].  Is this a problem?
<ricotz> Riddell, mhh, i see, i think it was an inline patch which i extracted
<JontheEchidna> valavanisalex: I don't know, it depends on how gnome's menu implements .desktop file translations from external .po's
<JontheEchidna> It shouldn't be a problem for KDE's setup, iirc
<Riddell> ricotz, robert_ancell: ok well if one of you could fix that libcanberra issue and e-mail the mailing list he posted to saying it's fixed that would be great
<JontheEchidna> valavanisalex: oh, actually that would cause problems
<JontheEchidna> pkgbinarymangler should probably be made more smart, and put X-Ubuntu-Gettext-Domain in the right group
<ricotz> robert_ancell, could you look into this? perhaps it could be updated to libcanberra 0.27 too
<robert_ancell> ricotz, ok
<valavanisalex> OK, thanks.  So I guess I could remove the manual patching from debian/rules, and add the key to the dpatch instead?
<ricotz> Riddell, did you have time to look at libbluray again? siretart also accidently uploaded again
<ricotz> robert_ancell, thanks
<Riddell> ricotz: hah I tried looking for that earlier and it wasn't there, turns out blueray isn't spelt proper
<ricotz> Riddell, right ;)
<Riddell> ricotz: is there anything in here equivalent to libdvdcss?
<ricotz> Riddell, yes, but not appropriate for the repo
<Riddell> ricotz: so there's a separate bit for the DRM that isn't included in this upload?
<ricotz> Riddell, yes, this package makes it possible to read not encrypted blurays
<ricotz> Riddell, libaacs would be the drm workaround which also exists
<Riddell> ricotz: groovy accepted
<Riddell> ricotz: I find "Most commercial Blu-Ray are protected by AACS or BD+ technologies" very biased language though, I'd strongly think that should be changed to "restricted"
<ricotz> i see
<ricotz> Riddell, thanks for your time
<broder> kees: ooc, is patching mountall actually easier than generating a patch to debugfs to take -o mode=?
<kees> broder: based on the reception of my upstream patches; yes.
<broder> ugh, ok
<kees> the other problems is that debugfs is a singleton like /sys so "mode=" would actually take global affect.
<kees> so I'm just going with a chmod, and we'll see what shakes out. it's been a frustrating path. :P
<kees> bryceh: what triggers the GPU lockup apport hook thing? I want to make sure I'm not smoking crack and breaking that hook
<bryceh> kees, it's triggered by code in the kernel intel drm driver
<kees> whoa, in the kernel driver?
<bryceh> yes
<kees> bryceh: do you have a string I can search for? call_usermodehelper_fns() doesn't show up in the drivers/gpu/drm tree
<bryceh> specifically, there is code in there that will reset the gpu when it locks up
<bryceh> (unfortunately, it seems to rarely work, but...)
<bryceh> so there is code in there which also fires off some sort of event.  we register the apport hook to be triggered off that (via an upstart rule)
<kees> oh, interesting
<kees> upstart, not udev?
<bryceh> udev, sorry
<bryceh> SUBSYSTEM=="drm", ACTION=="change", ENV{ERROR}=="1", RUN+="/usr/share/apport/apport-gpu-error-intel.py"
<bryceh> # Jesse Barnes on ubuntu-devel@lists.ubuntu.com:
<bryceh> #   You'll get three events, one when the error is detected, one before the
<bryceh> #   reset and one after.  Each has a different environment variable set; the
<bryceh> #   initial error has ERROR=1, the pre-reset event has RESET=1 and the
<bryceh> #   post-reset event has ERROR=0.
<kees> ah-ha!
<kees> nice, okay, yeah, that totally runs as root.
<Keybuk> (you could also do that with:
<Keybuk>  start on drm-device-changed ERROR=1
<Keybuk>  exec /usr/share/apport/apport-gpu-error-intel.py
<Keybuk> )
<Keybuk> :p
<kees> Keybuk: don't hurt me too hard for my mountall upload! ;)
#ubuntu-devel 2011-02-23
<Keybuk> heh, you think I'm reading -changes? :p
<Keybuk> ah that
<Keybuk> I look forwards to your ureadahead upload <g>
<TheMuso> grrr haven't built i386 packages with sbuild for ages, and now I find it desn't just work when using an i386 chroot on an amd64 machine.
<StevenK> TheMuso: What's the error? It ought to work
<TheMuso> StevenK: hrm hang on maybe I was doing something wrong.
<TheMuso> No I wasn't.
<TheMuso> E: Build architecture (amd64) is not the same as the chroot architecture (i386)
<TheMuso> I: Please specify the correct architecture with --arch, or use a chroot of the correct architecture
<TheMuso> But when I use --arch=i386 I get this.
<RAOF> Works for me?  Let me check my sbuild settings.
<TheMuso> Chroot natty-i386 for architecture i386 not found
<RAOF> What's your schroot called?  AFAICT sbuild only really cares about the chroot personality, as specified in schroot.conf (or chroot.d/*)
<TheMuso> Oh I have to set a personality now... Ok will update my schroot.conf.
<TheMuso> ...but this was not needed in the past... *grumlbes*
<TheMuso> Ok that doesn't help, still get the same above errors.
<psusi> any of the rest of you guys use emacs?  since I upgraded from emacs22 to emacs23, I can't debug properly since running gdb with sudo hangs after entering the password.
<broder> TheMuso: do sbuild -d natty --arch i386
<TheMuso> broder: Thats what I have been trying.
<broder> not -d natty-i386 or -c natty-i386?
<TheMuso> sbuild -d natty-i386 filename.dsc is what I normally use.
<TheMuso> or -d natty-amd64
<TheMuso> Ok order of args does not make a diff.
<broder> don't use -d natty-amd64
<broder> sbuild isn't clever enough to extract the architecture
<broder> you need to pass it as a separate argument
<broder> sbuild -d natty --arch amd64
<TheMuso> ah ok.
<TheMuso> THis is stupid, that used to work.
<broder> the sbuild maintainer is super responsive, for what it's worth
<TheMuso> I'll get used to it I guess, but a while back, I didn't have to specify any arch or personality, just the chroot name.
<RAOF> broder: sbuild's clever enough to work for me when I sbuild -d natty-i386?
<broder> yeah, it'll pick the right chroot, but i bet there's something new in the setup code that cares about the arch and isn't getting it
<TheMuso> RAOF: yeah thats what I *was* doing.
<RAOF> Hm, yeah, you're right.
<RAOF> Something's changed since my last i386 build, which would have been mere days ago.
<RAOF> Oh, I see.
<RAOF> That's a deliberate change in 0.60.9-1
<TheMuso> Yeah just saw that.
<RAOF> Well, that's annoying :)
<TheMuso> Agreed.
<TheMuso> On one hand I understand why the change was made, but, it now means that one has to type in more when running sbuild. Oh well, I'll get used to it.
<TheMuso> It will eventually become muscle memory.
<kees> lamont: postfix is uninstallable.
<StevenK> kees: "Feature"
<kees> StevenK: hehe
<ScottK> lamont: Also postfix 2.8.1 is out, so time to turn once more around the course ....
<robert_ancell> StevenK, how do I remove a package from the archive?
<StevenK> robert_ancell: You file a bug
<StevenK> Well, it depends.
<StevenK> More information, please
<robert_ancell> StevenK, the gtk3-engines-murrine package no longer builds, but it's also obsolete as GTK3 change it's themeing so much it no longer works.  I want to remove it so no-one can install it from natty when it's released
<StevenK> robert_ancell: Then file a bug against it stating that and asking that the source and binaries are removed from natty, subscribing ubuntu-archive
<cody-somerville> hmm... pidgin + MSN doesn't work anymore :(
<cody-somerville> I guess its time to migrate to empathy finally.
<micahg> cody-somerville: what version of pidgin?
<micahg> ah, it's explicit, no MSN fix yet :(
<cody-somerville> micahg, seems to affect all versions - you can't add new contacts anymore :(
<achiang> cody-somerville: the real bug is using MSN. ;)
<micahg> I remember the pidgin devs putting out a call for help with the MSN support a while back
<cody-somerville> achiang, the real bug is you... now leave me be... I'm busy playing Klondike solitaire :P
<cody-somerville> bam. I've become so pro at solitaire it ain't funny ;)
 * cody-somerville has Keybuk to thank for this.
<pitti> Good morning
<alexbligh1> Does anyone know if the current Natty development version of cobbler is supposed to support multiple interfaces with static IP? (i.e. generate ubuntu style networking scripts rather than redhat)
<lamont> ScottK: yeah - and we want 2.8.1 for a segv fix
<didrocks> good morning
<dholbach> good morning
<lag> If I want to use multiple (3) monitors, which graphics card manufacturer is most likely to work and least likely to be a bugbear?
<rishi> Which package provides the debug symbols for hostapd on Ubuntu 10.04?
<lag> rishi: Perhaps there isn't one
<lag> rishi: You could always build it yourself and include the symbols: sudo apt-get source hostapd
<kklimonda> rishi: you can enable ddebs repository and install hostapd-dbgsym
<kklimonda> (ddebs repository being the repository mentioned in https://wiki.ubuntu.com/DebuggingProgramCrash)
<rishi> kklimonda: Ok. Thanks.
<rishi> So, packages coming from Universe do have their -dbg counterparts in the repositories by default?
<kklimonda> rishi: no
<kklimonda> rishi: -dbgsym packages are created automatically, by the builders. -dbg packages have to be explicity enabled by package maintainers.
<kklimonda> (all binary packages have -dbgsym counterparts, but only some packages ship -dbg)
<ogra> jhunt, how is the serial world of upstart looking (i have a workitem for A3 i would like closed at some point)
<ogra> (or is that already in and i just missed the changelog entry)
<jhunt> ogra: last I heard we were waiting for SpamapS to tweak the .conf file?
<ogra> ah, k, i'll wait until he gets up to poke him ... and offer help if he needs any
<cdbs> Hi, I am uploading a new package to Ubuntu which would enter Debian very soon. I am MOTU. Do I need to file needs-packaging bug?
<pitti> cdbs: usually not; just upload it
<cdbs> pitti: okay
<zyga> hi, what is the recommended way to package python stuff? I'm reading https://wiki.ubuntu.com/PackagingGuide/Python and it specifies two options cdbs and debhelper
<cdbs> zyga: I'd recommend debhelper, its the better way
<cdbs> zyga: and preferably dh_python2
<zyga> cdbs, dh_python2? is that a third choice?
<zyga> cdbs, any official guide/hints?
<cdbs> zyga: dh_python2 is the debhelper8 way of doing python packaging
 * cdbs g2g
<zyga> cdbs, thanks
<zyga> cdbs, does dh_python2 make python central/support obsolete?
<cjwatson> it's intended to, AIUI
<cdbs> zyga: ^
<pitti> ev: uploading jockey with the --no-dbus option now
<zyga> thanks
<pitti> ev: I haven't changed the nvidia driver to autoinstall yet
<ev> pitti: you're my hero, thanks!
<zyga> I'm googling for docs about how to use it
<pitti> ev: that should be something like http://paste.ubuntu.com/571047/, if you want to experiment
<pitti> ev: (it's not just "True", as there might be several versions available, and we just want the 'best' one
<ev> pitti: I don't think we want it as autoinstall, actually.  That would cause it to get installed in the live session when ubiquity calls jockey-text -a for the wireless driver.  My intention was to call jockey-text -C in the chroot to get the nvidia driver.
<pitti> ev: ah, even better then :)
<ev> :)
<pitti> ok, I need to disappear for ~ 2 hours
 * zyga now reads http://wiki.debian.org/Python/Packaging
<mvo> @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: mvo
 * dholbach hugs mvo
<dholbach> yooohooo
<mvo> !!!
<mok0> I am looking for an example of sophisticated option parsing in C++
<mok0> anyone? ^
<didrocks> someone know if there is a policy when you upgrade a package and replace a hard link by a file? (IIRC, dpkg doesn't remove the inodes before the upgrade, so the file content will be erased with the new one for all linked inode?)
<didrocks> my issue is that the compiz hook is a hard link to the xorg one. I want know to ship a real separate hook for compiz than xorg
<cjwatson> a hard link is a file
<cjwatson> there should be no problem, anyway
<cjwatson> dpkg will unpack the new contents of the file and rename it into place
<cjwatson> the effect of that will be to decrease the link count of the inode that was previously there
<cjwatson> or IOW to break the hard link
<cjwatson> you don't need to do anything special
<siretart> are NEW packages uploaded today going to make it for feature freeze?
<didrocks> cjwatson: excellent, thanks for the info :) (I was wondering if they could have been an issue)
<mbiebl> james_w: ping
<cjwatson> siretart: yes, AA delay is not taken into account
<siretart> excellent, thanks!
<james_w> hi mbiebl
<mbiebl> james_w: hi
<mbiebl> I was asked by the debian gnome maintainers for polkit 0.100
<mbiebl> and was wondering what to do about your patch
<mbiebl> it no longer applies
<mbiebl> and in the upstream bug report you wrote that you can no longer reproduce the issue
<mbiebl> http://bugs.freedesktop.org/show_bug.cgi?id=30515
<ubottu> Freedesktop bug 30515 in daemon "Race means that client can get no response from agent" [Normal,New]
<james_w> mbiebl, I've never been able to reliably reproduce
<james_w> I don't think the bug will be gone with the changes that were causing the conflicts when I last looked
<mbiebl> james_w: what would you suggest we do? drop the patch for now?
<mbiebl> update it for the new upstream release?
<apw> cjwatson, just a heads up on bug #672699, i have just pushed some changes to enable speakup-modules in natty, will be in the next upload
<ubottu> Launchpad bug 672699 in linux (Ubuntu Natty) "screen-reader does not work " [Medium,Fix committed] https://launchpad.net/bugs/672699
<apw> it was unclear if there was more work to be done on the installer or not to my eye
<james_w> mbiebl, update it, I see no reason for the bug to be gone otherwise, and it does affect a lot of people and makes polkit pretty useless for them apparently
<mvo> bdrung: hi, I just looked at the poedit sponsoring request, looks fine to me, do you mind if I upload or would you rather want to coordinate with debian?
<mvo> (bug #717168 )
<ubottu> Launchpad bug 717168 in poedit (Ubuntu) "Please update poedit to 1.4.6.1" [Wishlist,Confirmed] https://launchpad.net/bugs/717168
<bdrung> mvo: upload it! the ff is coming and waiting for debian may take too long. we still can sync it later on
<mvo> bdrung: great, thanks. that is my feeling as well
<bdrung> mvo: do you process the upgrade requests first?
<mvo> bdrung: I currently go over the list from top to bottom, but I'm happy to look at specific stuff too
<bdrung> mvo: please look at the type=upgrade items first (due to the nearing ff)
<mvo> ok
<seb128> bdrung, do you know how is the "upgrade" set?
<bdrung> seb128: i don't get your question.
<seb128> bdrung, what is the logic which makes "upgrade" show in the type column
<seb128> bdrung, the pango and gtk binding updates are not tagged as upgrade
<seb128> they should
<bdrung> seb128: either the bugs are tagged with 'upgrade' or ... let me check
<cjwatson> apw: thanks.  I don't expect we need to change anything
<mvo> the nice thing about the sposnoring is that you always learn about new packages. ucommon - sounds like a misisng n (but that has tradition I guess)
<cjwatson> er, well, wait, not sure
<bdrung> seb128: or upgrade-software-version tag or 'new upstream version' in the title
<cjwatson> will have to look latere
<cjwatson> *later
<cjwatson> apw: I've created a debian-installer task
<seb128> bdrung, ok
<bdrung> seb128: let me know if there are other ways to detect it
<seb128> mvo, well in any case the pango and gtk bindings ones should be trivial if you want to upload those
<seb128> bdrung, not that I know about, I was just curious because those are not tagged and you asked mvo to review tagged things :p
<rniamo> hi, will libmapi be packaged soon? A new version fixed this bug http://www.ubuntuupdates.org/packages/show/281187
<rniamo> here is the bug on gnome bugtracker: https://bugzilla.gnome.org/show_bug.cgi?id=632784
<mvo> seb128: looking at the pangomm one now, that 2.27.1 version is fine? 2.27 is not some unstable version or somesuch?
<mvo> seb128: or if it is then you want it, right?
<seb128> mvo, it's unstable on the way to 1.28 which is our pango version
<seb128> the bindings are just a bit behind
<seb128> but we do want the update
<seb128> it's required for the gtk bindings update to 2.24
<mvo> ok
<pitti> oh ergh, why does jockey still show the nvidia driver
<ari-tczew> cjwatson: what about lilo merge?
<tjaalton> anyone on natty, other than radeon/intel/nvidia gfx, and virtual consoles do/don't work? at least on my ancient thinkpad with savage there's just a blinking cursor
<tjaalton> installed today
<bdrung> ari-tczew: it doesn't show up in the sponsors queue
<ari-tczew> bdrung: I leave this one for cjwatson, but there is special case, very close to FFe, do you would like to take sponsorship?
<bdrung> ari-tczew: no
<bdrung> just wondered that it doesn't appear on the list
<ari-tczew> ;]
<tjaalton> cjwatson: when editing the grub options from the grub boot menu, should the variables be expanded or not? I see 'set gfxpayload=$linux_gfx_mode', and only by changing it to 'text' or removing completely do I get working vc's
<cjwatson> tjaalton: variable expansion is probably not your problem.  linux_gfx_mode is likely set to 'keep'
<cjwatson> tjaalton: I bet you'll see the same thing if you say set gfxpayload=keep
<cjwatson> tjaalton: see https://wiki.ubuntu.com/FoundationsTeam/Grub2BootFramebuffer/Whiteboard etc.
<tjaalton> cjwatson: with 'keep' I have a grub message on every vt ('booting a command list')
<tjaalton> but yeah, equally broken anyway
<RoAkSoAx> vish: ping?
<cjwatson>  xserver-xorg-input-evdev-udeb : Depends: xserver-xorg-core (>= 2:1.9.99.902-2ubuntu1) but it is not installable
<cjwatson> agh, I wish d-i builds would stop breaking
<tjaalton> cjwatson: do you see actual bugs, or is it just bad timing?
<cjwatson> tjaalton: udebs depending on non-udebs is clearly a bug.  I'm investigating why this regressed
<tjaalton> cjwatson: ah, ok
<cjwatson> oh wow, it's even an explicit dep
<cjwatson> broken in xserver-xorg-input-evdev 1:2.6.0-1ubuntu7 - I'll upload a fix
<vish> RoAkSoAx: hi, pong..
<tjaalton> cjwatson: oh, duh...
<tjaalton> bad cnd :)
<ari-tczew> doko__: what does it mean "spring time, drop all Ubuntu changes" ?
<vish> ari-tczew: spring cleaning?
<ari-tczew> vish: yea, why does it mean?
<ari-tczew> why we are cleaning?
<vish> oh, why i dont know :)
<doko__> context?
<ari-tczew> doko__: https://launchpad.net/ubuntu/+source/jasperreports/3.7.4+dfsg-1ubuntu2
<Laney> I assume it means that the FTBFS no longer happens.
<RoAkSoAx> vish: hi there! You created the icons for TestDrive right :)?
<doko__> well, look at the previous version ...
<tjaalton> cjwatson: should I file a bug about 'keep' not working with savage, or that it should use 'text' instead?
<ari-tczew> doko__: yes, I saw, I was an uploader then
<doko__> then I don't get your question
<ari-tczew> doko__: OK Laney
<ari-tczew> 's answer is enough for me.
<cjwatson> tjaalton: https://lists.ubuntu.com/archives/ubuntu-devel/2010-December/032244.html
<vish> RoAkSoAx:  yup. :)
<RoAkSoAx> vish: would you like, and have the time, to create a new one for the IndicatorApplet I just added (but just to draw attention, such as one in red or something like that :))
<vish> RoAkSoAx: sure, no probs. to match the ubuntu-mono icons or just general?
<vish> RoAkSoAx: and by when do you want them done..?
<RoAkSoAx> vish: just a general one. I mean, the same icon as we are currently using, but with another color that will draw the attention. The indicator applet will appear only when something X happens, and it needs to be a visible icon that draws the attention (For example, the messaging indicator icon is white, and green when drawin attention)
<RoAkSoAx> vish: I don't have an exact date, but would be nice to have it by alpha3 :)
 * vish checks alpha 3 date :)
<cnd> cjwatson, tjaalton: sorry!
<vish> RoAkSoAx: hmm, ok.. if you have a bug open for it you can just assign it to me â¦
<cnd> I should have depended on xserver-xorg-core-udeb?
<RoAkSoAx> vish: will do. Thanks a lot :)!!
<vish> np.. :)
<cjwatson> cnd: yes, I made that chance
<cjwatson> *change
<cnd> cjwatson, thanks
<cjwatson> udebs must never depend on debs, or vice-versa
<cnd> yeah
<cnd> I should have realized that
<dholbach> barry, heya - what do you think we should do about the packaging guide merge proposal?
<dajhorn> bdrung: You should cancel the lshw sync because it is phoning home again.  The last time this happened,  Kees Cook authorized an NMU on it.
<tjaalton> cnd, cjwatson: the drivers should get correct deps on build
<cnd> tjaalton, it's because there's an explicit dependency on the new xi 2.1 stuff in that server
<tjaalton> cnd: that's why serverminver was bumped on the server?
<tjaalton> meaning that drivers built against it will get the correct dependency
<cnd> tjaalton, maybe that's how it should be done?
<cnd> I don't really know about all the debian x packaging dependency stuff
<tjaalton> cnd: it's the ${xinpdriver:Depends} field in control which is then substituted with the value from the xserver it's built against
<cnd> tjaalton, ok, then the depends probably wasn't necessary
<tjaalton> but it doesn't matter too much, it should be possible to drop it from the next upload
<tjaalton> cjwatson: thanks, i'll file one with those instructions
<dajhorn> bdrung: Nevermind.  Resolution in the Launchpad ticket.
<lool> cjwatson: Eh did you see joeyh did the same Maintainer: change to debootstrap as I had pushed for the dpkg toolchain issue?  :-)
<cjwatson> yeah - I figured whatever
<lool> cjwatson: Ah, and I was expecting a clash of the titans!
<lool> oddly enough, he didn't close my bug
<apw> i assume the current threat to remove ubuntu-desktop is a temporary publishing glitch
<Chipzz> cjwatson: 15:53 < cjwatson>  xserver-xorg-input-evdev-udeb : Depends: xserver-xorg-core (>= 2:1.9.99.902-2ubuntu1) but it is not installable
<Chipzz> cjwatson: why do udebs have different names from regular debs anyway?
<cjwatson> because it was easier to manage the archive that way
<Chipzz> I thought debs and udebs where different "namespaces" anyway
<Chipzz> ?
<cjwatson> no, they share a namespace
<Chipzz> maybe I should phrase that better
<cjwatson> certainly not going to change that now :)
<Chipzz> udebs are a collection in itself
<Chipzz> debs are a collection in itself
<cjwatson> whatever
<cjwatson> their names can't collide
<cjwatson> maybe we would design it differently if we were doing it again, but it is not worth changing now
<cjwatson> one example of where it's a shared namespace:
<cjwatson> https://launchpad.net/ubuntu/natty/+package/xserver-xorg-core
<cjwatson> https://launchpad.net/ubuntu/natty/+package/xserver-xorg-core-udeb
<cjwatson> (that reflects namespacing in the LP database, and dak is similar)
<cjwatson> actually, TBH, I find it better this way, as an installer developer
 * lool throws tdebs at Launchpad and dak
<cjwatson> it means that you can unambiguously talk about the dependencies of <package name>
<cjwatson> without being confused about those being different depending on whether you mean a deb or a udeb
<cjwatson> sure, no doubt a computer could resolve the differences, but it's clearer for human developers
<Chipzz> cjwatson: my usage of the word "namespace" was badly chosen, let me clarify: I meant the collection of debs and the collection of udebs are independant in the same way as say, the collection of .i386.deb's and .amd64.deb's are independent
<Chipzz> they are directed graphs with no overlap
<cjwatson> that's as may be, but I hope my comments above are a sufficient answer
<Chipzz> anyway, if it's more convenient to you, by all means keep it
<Chipzz> who am I to argue with someone who works on the installer
<cjwatson> your comment about i386 and amd64 is about to become a lot less true, mind you ;-)
<Chipzz> the point I was trying to make is that them having different names causes a different set of issues, like the one from above, because certain tools need to have special cases
<cjwatson> fortunately, foo_i386.deb and foo_amd64.deb usually look fairly similar
<Chipzz> right :)
<cjwatson> whereas foo_i386.deb and foo-udeb_i386.udeb are typically significantly different in terms of e.g. their file lists and metadata
<cjwatson> they really aren't the same type of thing, and it's worth the effort to call them by different names
<cjwatson> makes debian/control less confusing too
<cjwatson> and in fact debian/ in general - you can have debian/foo.install and debian/foo-udeb.install, and it all falls out nicely
<cjwatson> it could have gone either way at the start (it was debated), but I quite like the way it's ended up
<Chipzz> you're right about debian/foo.install vs debian/foo-udeb.install of course, that would have causes a different set of special casing
<Chipzz> *caused
<Chipzz> I guess you get to choose between different sets of issues :)
<cjwatson> yeah
<Chipzz> I don't agree with you on this though: 17:26 < cjwatson> it means that you can unambiguously talk about the dependencies of <package name>
<Chipzz> since dependencies can be arch-specific anyway
<Chipzz> but that's a nitpick I suppose
<cjwatson> yeah I realise that, but in practice they're not usually wildly different
<Chipzz> anyway, decision has been made, little point in discussing it further, I'll leave you to your job :)
<cjwatson> whereas they almost always need to be different between debs and udebs
<cnd> Riddell, I've posted a merge request for the qt touch stuff: https://code.launchpad.net/~utouch-team/ubuntu/natty/qt4-x11/xi2.1/+merge/50952
<hrw> hi
<hrw> mvo: thanks for review of gcc-4.5-armel-cross
<mvo> hrw: sure, you are welcome
<mvo> should be in natty by now
<hrw> ok
<cnd> Riddell, I'm building this package in ppa:utouch-team/xorg-unstable right now, though it works properly on my machine
<hrw> mvo: next week will get new version anyway
<hrw> but I finally applied for UD/UC status
<mvo> @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:
<mvo> hrw: hm, I only just now saw the message about that I should not upload. if you want to avoid this for the future, its probably best to just remove the merge request (as otherwise it will appear in the sponsoring queue and someone like me will look at it and act on it)
<hrw> mvo: ok, will take care next time
<hrw> mvo: having updated version in archive is not a problem anyway
<mvo> hrw: ok
<ogra> SpamapS, where do we stand wrt serial support in upstart ? (/me has a workitem he would like to close)
<SpamapS> ogra: Its been proposed as a merge, and debated upstream.. but nobody has pulled the trigger on merging it. Nobody has -1'd it either yet...
<ogra> hmmm
<ogra> i thought we wanted to make it a package patch
<SpamapS> ogra: yes, and thats where the MP sits
<ogra> why do we need to wait for an upstream merge for a distro patch ?
<SpamapS> we don't.. we, as in, I, have no upload rights. ;)
<SpamapS> hopefully changing soon
<SpamapS> ogra: IIRC, cjwatson also wanted to see if we could incorporate the same logic that d-i uses to configure serial console for the kernel to create this file.
<ogra> no, he wanted that we look at the d-i implementation to not run into the same probs that were solved there already another time
<SpamapS> ogra: so instead of just always installing it, we'd only install it if the install was over serial console.. otherwise it would be something like /etc/init/tty-serial.conf.disabled
<ogra> that doesnt help me at all
<SpamapS> ogra: unfortunately jhunt and I have been swamped with critical bugs in the boot and shutdown and haven't been doing much feature work. :(
<SpamapS> ogra: well for the time being the proposed fix is to just install it and let it do its thing as you wrote it.
<ogra> on arm you might do your install graphically but still want a serial console if the console=ttySX option is set, it shoudl react on the ernel option not be based on installation procedure
<ogra> that would be fine too
<SpamapS> ogra: the concern is, as you know, that there is some small delay in opening and reading /proc/cmdline
<ogra> yep
<SpamapS> ogra: but upstart has no simple way to pass along the console= options that the kernel is happily copying into its environment now.
<SpamapS> ogra: So.. the best course of action may be to bump cjwatson or keybuk and see if they'd be amenable to accepting the patch from the bug fix that I proposed. If I could do more .. I would. :-P
<ogra> yeah, i understand, i just need to know what to do with my workitem, i can leave the hack in place that creates the .conf file on all arm installs
<bdrung> mvo: did you upload the fix for bug #494096?
<ubottu> Launchpad bug 494096 in metacity (Ubuntu Lucid) "Clicking the title of a window is bringing a window underneath it into focus" [High,Triaged] https://launchpad.net/bugs/494096
<chrisccoulson> bdrung / mvo, that's been sat in the lucid-proposed queue for a while already
<bdrung> ups, i looked at the maverick queue. there i couldn't find it...
<chrisccoulson> yeah, mvo did upload it, so it is in the queue twice now
<ari-tczew> when FF is starting?
<ogra> ari-tczew, tomorrow evening UTC i was told
<ogra> or texan lunch time, as you wanna put it ;)
<ari-tczew> ogra: so we have ~29 hours for uploading?
<ogra> 28h 7min and 13sec
<ogra> :P
<ogra> no idea, really
<ogra> i can just say what our release manager said when i asked
<ogra> around lunch time TX
<micahg> ogra: tomorrow UTC?  so we get an extra day?
<ogra> micahg, ??
<ogra> here its the 23rd still
<micahg> ogra: freezes start at midnight according to the wiki
<alkisg> I'm a little mixed up about LP bug #494096, so are we (users that are interested in getting the bug fixed on lucid) to test the maverick version of gnome-session, or are we to wait until gnome-session gets approved in lucid-proposed?
<ogra> thats not what skaet_ said
<ubottu> Launchpad bug 494096 in metacity (Ubuntu Lucid) "Clicking the title of a window is bringing a window underneath it into focus" [High,Fix committed] https://launchpad.net/bugs/494096
<hrw> hi ari-tczew
<ari-tczew> hello hrw
<cjwatson> micahg: realistically, freezes start whenever it's convenient for them to start, on the given day :)
<micahg> cjwatson: right, but generally, they've started the UTC morning after UTC midnight on the day in question, I was just quoting from the second bullet here: https://wiki.ubuntu.com/NattyReleaseSchedule
<ogra> yeah ... papers
<ogra> dont belive everything you read ;)
<micahg> cjwatson: when will be the last sync run before feature freeze?
<Laney> usually anything requested before is OK
 * ogra feels the level of pre-freeze panic rising :D
<cjwatson> micahg: I was about to start one; then maybe one tomorrow morning or so
<mvo> chrisccoulson: hrm, haven't seen that. I unsubscribe ubuntu-sposnors now to ensure its not uploaded a third time
<micahg> cjwatson: ok, thanks
<chrisccoulson> mvo - thanks
<mvo> chrisccoulson: did you do the other upload? would be nice to mention it in the bugreport (and verify that my sru instructions are good)
<chrisccoulson> mvo - i should have commented really. pitti sponsored my upload
<mvo> chrisccoulson: ok, not a big deal, patch is tiny
<hrw> ogra: ;)
<hrw> ogra: no one said that feature freeze == feature complete
<barry> mvo: are you still around?
<maco> aw crud, feature freeze is tomorrow huh?
<barry> it is :)
<maco> oh damn, utc...
<maco> i wont even be home from work tonight by the time FF kicks in
<micahg> maco: we were chatting about that earlier, you have a little more time than that apparently
<maco> well i have a feature to write into gally that promised highvoltage i'd have in there for natty
<skaet_> all, just to be clear feature freeze will be at 1800 UTC Feb 24th for Natty,  after that please follow the https://wiki.ubuntu.com/FreezeExceptionProcess if something needs to get uploaded.
<highvoltage> I'm sure that would be fine for an FFe :)
<highvoltage> (well, we can at least try, right?)
<micahg> skaet_: ok, thanks for the clarification
<maco> skaet_: thanks
<maco> highvoltage: i finally got internets! i can hack again!
<Daviey> doko, Are you around?  I could do with some ld help :)
<highvoltage> maco: \o/
 * Laney ponders
 * Laney ponders in the wrong channel
<Chipzz> Laney: are you pondering what I'm pondering? ;)
<Laney> whether it's OK to upload new versions of quickcheck, mtl, src-exts for the new Agda? ;-)
<Chipzz> I guess you missed the reference to Pinky & The Brain then ;)
<Laney> deliberately :P
<mvo> barry: yes
<Chipzz> p&tb rule :)
<barry> mvo: hi.  leonard has signed off on the update of launchpadlib to 1.9.7, so we'd like to get that into natty.  i have a merge proposal for that, however, it will require MIR of python-keyring 0.5.1
<barry> mvo: mir is bug 686257
<ubottu> Launchpad bug 686257 in python-keyring (Ubuntu) "[MIR] python-keyring 0.5.1" [High,In progress] https://launchpad.net/bugs/686257
<barry> mvo: merge proposal is: https://code.launchpad.net/~barry/ubuntu/natty/python-launchpadlib/bug-702375-1.9.7/+merge/50818
<barry> is there anything you can do to help? :)
<mvo> barry: ok, will you do the MIR?
<mvo> barry: aha, ok
 * mvo looks
<barry> mvo: thanks.  i'm not sure if we need more in the mir bug comments
<mvo> barry: ok, looks good, mir got approval, so uploading should be fine now
<alkisg> mvo, sorry for the ping, about LP bug #494096, I still don't see gnome-session in lucid-proposed.
<ubottu> Launchpad bug 494096 in metacity (Ubuntu Lucid) "Clicking the title of a window is bringing a window underneath it into focus" [High,Fix committed] https://launchpad.net/bugs/494096
<barry> mvo: awesome, can you do both packages for us?
<alkisg> Erm nor metacity
<mvo> alkisg: someone needs to manually approve it first, it should appear soon (tomorrow, the day after tomorrow)
<mvo> barry: does the other one require a update as well?
<alkisg> OK, I thought it was already there since the 15th, thanks
<barry> mvo: ah, no i guess it doesn't.  python-keyring 0.5.1-0ubuntu1 is already in natty, so we just need launchpadlib updated
<barry> mvo: thanks!
<mvo> barry: uploaded
<cnd> bryceh, do you know how to set a bug so that it has two ubuntu packages for it?
<barry> mvo: awesome, thanks
<mvo> thank you for the update!
<cnd> bryceh, oh, I think it's in "also affects distribution"...
<cnd> so nm :)
<m4n1sh> bdrung: ping
<bdrung> m4n1sh: pong
<m4n1sh> bdrung: AFAIK  you have expertise packaging firefox addons
<m4n1sh> am I right?
<bdrung> yes
<m4n1sh> I have one addon
<m4n1sh> which I would like to get packaged
<m4n1sh> is the process somewhat unusual than other packages?
<m4n1sh> bdrung: it is zeitgeist firefox dataprovider
<m4n1sh> for pushing events in the daemon
<bdrung> no, but addons won't be accepted in ubuntu unless they are architecture specific and needs to be compiled.
<m4n1sh> bdrung: they are
<bdrung> m4n1sh: the extension specific things are explained in http://wiki.debian.org/mozilla-devscripts
<m4n1sh> it links against libzeitgeist
<m4n1sh> which is a native libraru
<m4n1sh> *library
<bdrung> other question: is it a XUL extension or plugin?
<pitti> cjwatson: back now; do you want me to copy the maverick-proposed kernel, or did you already?
<m4n1sh> bdrung: plugin
<m4n1sh> bdrung: http://bazaar.launchpad.net/~zeitgeist-dataproviders/zeitgeist-dataproviders/trunk/files/head:/firefox-libzg/
<bdrung> hm, mozilla-devscripts is for xul extensions. dunno if it helps packaging plugins
<m4n1sh> it is written in C++
<m4n1sh> it does have XUl files
<m4n1sh> XUL
<m4n1sh> for UI i think
<cjwatson> pitti: just finished doing it
<pitti> ah, good
<bdrung> looking at the link, it's a xul extension. so you can use mozilla-devscripts
<pitti> cjwatson: sorry, had to be away for the afternoon, but back now
<m4n1sh> thanks.. if I have some problems, I might ask you if you are free
<bdrung> m4n1sh: yes. build the xpi file with the upstream makefile, then use xpi-install to install the xpi file
<NCommander> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<NCommander> @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: NCommander
<NCommander> :-)
<m4n1sh> bdrung: you mean to say for checking whether it works or not OR for packaging it?
<bdrung> NCommander: recommendation due to the nearing FF: please review the items with type=upgrade first.
<bdrung> m4n1sh: for packaging
<m4n1sh> thanks
<NCommander> bdrung: indeed
<cjwatson> pitti: np
<micahg> NCommander: if you're piloting now, maybe I'll wait until 0:00 UTC
<bdrung> micahg: why?
<micahg> bdrung: some we don't end up working on the same things
<micahg> *so
<NCommander> micahg: you could take now, I can go later
<micahg> NCommander: no, it's fine
<bdrung> micahg: you can coordinate by assigning bugs to yourself and by beeing verbose on irc
<bdrung> *being
<NCommander> bdrung: how do I see type=upgrade?
<bdrung> NCommander: http://reports.qa.ubuntu.com/reports/sponsoring/ -> click on the column type
<jcastro> anyone know who's running backports these days?
<jamespage> doko, kees, mterry, didrocks, asac: please could one of you review MIR bug 676904; I'd like to get the associated sync with Debian (bug 661230) complete before FF - thanks
<ubottu> Launchpad bug 676904 in jansi-native (Ubuntu) "[MIR] jansi" [Medium,Confirmed] https://launchpad.net/bugs/676904
<ubottu> Launchpad bug 661230 in groovy (Ubuntu) "[BLOCKED] Sync groovy 1.7.4-1 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/661230
<pitti> kees: dapper/hardy/karmic kernels are v-done now, want me to copy to -updates and -security?
<kees> pitti: if they have CVEs, yes
<pitti> kees: shall I just copy, or send a ping somewhere?
<pitti> (I'll update the bugs, of course)
<kees> pitti: if you can for now do the copies (and related ABI packages) and then email security@ubuntu.com, that would be appreciated.
<pitti> roger
 * kees hugs pitti
 * pitti hugs you back
<apw> is the language-selector triggering a deinstall of ubuntu-desktop a known, is it transient?
<kees> lifeless: remember the ancient gpg bug you opened about it keeping the keyring locked after running it?
<kees> lifeless: I have a work-around, if you still are interested.
<kees> lifeless: to my ~/.gnupg/gpg.conf file, I added "no-auto-check-trustdb" and then added this to my crontab:  37 5 * * * gpg --check-trustdb 2>&1 | egrep -v '(depth: | needed,|next trustdb check)'
<lifeless> kees: *blink*
<lifeless> kees: shouldn't we, uhm, fix the bug ? :)
<kees> it's not technically a bug
<kees> it's updating the trust db.
<kees> so you have to wait for it.
<kees> it's an annoying feature.
<lifeless> kees: evolution killing gpg, and gpg not cleaning up when killed - thats the bug
<kees> so I turned off the feature.
<kees> oh. :(
<kees> didn't remember that was the issue. :)
<lifeless> kees: I don't mind the process taking a bit to do the auto check. Thats -fine-
<kees> it's been a while
<lifeless> kees: when there is no gpg running and a lock file, thats not expected behaviour ;)
<lifeless> theres a cluster of bugs
<lifeless> gpgme or whatever it is that evolution uses to run gnupg doesn't handle an autocheck occuring properly.
<lifeless> thats one
 * kees nods
<lifeless> secondly, it doesn't handle the gpg process lifetime properly - *or* - gpg has a bug around locks and signals.
<kees> I'm curious if turning off autocheck would fix it for you, though.
<lifeless> it would address the former cosmetic issue of the output being treated as meaning a gpg error had occured
<lifeless> I doubt it would /fix/ the stale lock problem - lots of other folk encounter the gpg handling issue
<lifeless> it might reduce the frequency
<pitti> StevenK, wgrant: hm, did anythign change wrt. copy-packages.py recently? copying the hardy/karmic kernels to -updates takes aaaages (it's sitting there for 10 min already doing nothing)
<lifeless> pitti: our servers are rather busy
<pitti> I already ^C'ed it twice, and it seems to get stuck in recalculateBugHeatCache
<StevenK> pitti: I'm personally not aware of anything. Hm, perhaps bug heat is broken. :-(
<lifeless> if its called
<lifeless> bah
<lifeless> so
<lifeless> there is a bug about bug heat calculation being expensive
<lifeless> what its doing is refreshing the heat across -all- bugs for that source package
<pitti> I guess I'll just let it sit there then and hope that it'll finish at some point?
<lifeless> which is more than a little crazy
<lifeless> it will, yes
<pitti> lifeless: ugh, and as this is linux, there will be many thousands
<lifeless> see lib/lp/registry/model/distributionsourcepackage.py
<lifeless> that function in that module
<pitti> shouldn't it only touch the bugs referenced in the changelog, i. e. the ones that it closes automatically?
<lifeless> is what you may be hitting
<lifeless> or are you in BugTarget.recal...
<lifeless> ?
<pitti>   File "/srv/launchpad.net/codelines/soyuz-production-rev-12381/lib/lp/registry/model/distributionsourcepackage.py", line 222, in recalculateBugHeatCache
<pitti>     BugTask.status.is_in(UNRESOLVED_BUGTASK_STATUSES)).one()
<lifeless> pitti: context bug heat is defined with a global algorithm
<lifeless> pitti: yeah, thats the one I thought it might be.
<lifeless> pitti: please file a bug and let me know the number
<pitti> against soyuz? or malone?
<lifeless> pitti: note that if it takes > 10 seconds you'll be causing timeouts in the webapp.
<lifeless> pitti: launchpad.net/launchpad
<pitti> lifeless: it's shell command on cocoplum
<lifeless> pitti: I know
<lifeless> pitti: if it takes > 10 seconds, all bug updates in the context that you're working on will queue in the db for the source package row lock.
<pitti> ah
<lifeless> foreign key constriants ftw
<lifeless> constraints
<lifeless> once a transaction starts a write on row X with FK Y, a row lock on the FK table row Y is taken out.
<lifeless> to prevent the FK relationship being  broken.
<kees> pitti: my the ABI checker is complaining that lucid's -update for linux-mvl-dove does not match linux-meta-mvl-dove (209 for meta, 211 for the kernel)
<lifeless> pitti: the 10 second figure is because the timeout is 14 seconds
<lifeless> and many updates are reasonably quick, so letting them have 4 seconds is probably ok.
<pitti> lifeless: filed as bug 723955
<ubottu> Launchpad bug 723955 in Launchpad itself "copying a kernel to -updates takes very long now" [Undecided,New] https://launchpad.net/bugs/723955
<lifeless> thanks
<pitti> thanks to you
<pitti> kees: uh, that's right; at least the ones in -proposed now seem to match
<kees> pitti: so we should just wait for those to verify?
<pitti> sconklin: ^
<sconklin> reading back
<pitti> sconklin: as the current linux-mvl-dove in lucid-proposed is v-failed, would it be possible to upload a fixed mvl-dove-meta to lucid-updates?
<pitti> kees: FYI, I copied dapper to -updates/-security, but as karmic/hardy take ages to copy, I might not finish those two; I have the email to security@ staged
<pitti> kees: finish tonight, I mean
<sconklin> I'll check with Tim, who has been making those kernels
 * pitti ^Cs again and runs in screen
<kees> pitti: you can move processes into screen... http://blog.nelhage.com/2011/01/reptyr-attach-a-running-process-to-a-new-terminal/
<kees> might need to turn off ptrace restriction briefly.
<kees> anyway.
<kees> pitti: that's fine about the kernels as long as they're not uninstallable.
<pitti> kees: which I probably can't do on cocoplum
<kees> ah-ha
<pitti> but locally that sounds great, /me reads
<kees> we have to do 1 USN per kernel anyway now because the CVE fixes are not contiguous any more.
<pitti> queued up all copy commands, will hopefully finish over night
<pitti> kees: ah, ok
<GunnarHj> NCommander: Hi Michael, do you possibly have time to sponsor https://code.launchpad.net/~gunnarhj/language-selector/lp-533159/+merge/50265 ?
<NCommander> GunnarHj: looking
<GunnarHj> NCommander: Ok, thanks.
<broder> kees: hmm...you know what would be awesome? a shell builtin that does the PTRACE_ME prctl for a child :)
<cjwatson> wow, ghc6 takes long enough to build
<kees> broder: hung.
<cjwatson> glad my laptop has loads of memory
<kees> er, hunh
<kees> broder: isn't that just exporting LD_PRELOAD?
<broder> doesn't help with an already running process
<pitti> barry: new python-launchpadlib is missing the python-keyring dependency; it's crashing now
<kees> sure, but nothing in the shell could help with that.
<broder> kees: i guess i actually want a shell builtin that ptraces a given child, and calls the prctl from there, which is even more Awesome
<kees> heh
<sconklin> pitti, ot sure what you're asking for on mvl-dove. There are packages on the PPA ready to be copied out which replace the ones in -proposes and resync the ABI numbers
<kees> yeah, that would be wild.
<kees> broder: honestly, if you're running into it that much, just turn off the ptrace restrction instead. :P
<pitti> sconklin: it's the ones in -updates which are broken
<pitti> sconklin: oh, there are? I wasn't aware of that
<sconklin> I wasn't either until I just looked
<mterry> tedg, bam! https://code.launchpad.net/~mterry/indicator-datetime/clock-prefs/+merge/51013
<sconklin> pitti: hold up, there's a regression in the ones on the ppa
<sconklin> pitti, kees: There is a regression in the mvl-dove kernel that is affecting devices in the field, and the meta package was held back in updates to prevent updates to the known bad kernel
<tedg> mterry, Cool!
<sconklin> There's no fix known yet but kernel folks in Taipei are working on it
<pitti> sconklin: how did we manage to catch the regression before updating the metapackage and yet had this copied to -updates?
<sconklin> I don't know. I'm relaying this from Tim Gardner, he knows the details
<bjf> pitti, we just got "lucky"
<kees> sconklin: ah-ha! okay, good to know; thanks
<sconklin> I'm going to delete the packages from our PPA, since they are known bad also
<micahg> pitti: yeah, I haven't had a chance to rethink the pidgin-facebookchat SRU yet
<pitti> no problem, I just stumbled over it when doing SRUs
<kees> pitti: I was expecting to see QA sign-off on 716472. am I looking in the wrong place?
<kees> sconklin-afk: ^ ?
<pitti> kees: it's security only, so there are reduced tests (only the regression tests)
<kees> pitti: right; I see no "verification-done" on it. Where is the link to the QA test report. i.e. https://wiki.ubuntu.com/QATeam/KernelSRU-karmic-2.6.31-22.73
<pitti> hm, where did I see that..
<pitti> there were a lot of duplciated tracking bugs this time, probably was on one of those
<wgrant> pitti: Hi.
<micahg> NCommander: FTR, from what I've been told, we generally don't bump standards in Ubuntu when updating ahead of Debian since it's an unnecessary diff
<kees> pitti: based on the USN history, smb tested 2.6.15-55.91. I was expecting QA to test 2.6.15: 2.6.15-55.93.
<kees> marjo: ^^
<kees> sconklin: ^^
<Quintasan> jcastro: ping
<NCommander> micahg: I bump standards personally, and I'm not going to veto a diff that does.
<jcastro> Quintasan: hi
<Quintasan> jcastro: If I am applying for sponsorship, any idea why should I fill in https://forms.canonical.com/udsreg/ before I get sponsorship?
<jcastro> not sure
<micahg> NCommander: I personally wouldn't have vetoed, just reverted it and uploaded
<jcastro> I guess it doesn't hurt
<charlie-tca> Quintasan: near as I can tell, that was a mistake, since you can't actually fill it in before you get sponsored and get the flight booked
<Quintasan> charlie-tca: I concluded the same thing and asked
<Quintasan> jcastro: Huh, apparently I have already requested sponsorship @_@
<jcastro> did you apply before?
<jcastro> I see your submission
<Quintasan> jcastro: I think I did but I was told it was a test form and I would have to reapply
<jcastro> I can delete it if you want, up to you, then you can reapply
<Quintasan> jcastro: Please do.
<jcastro> Quintasan: ok, all set
<Quintasan> jcastro: Thanks :)
<Quintasan> jcastro: applied, can you check if it is there?
 * cjwatson notices the source package lwjgl
<cjwatson> are we naming packages with pwgen now?
<ion> apt-cache search '^[bcdfghjklmnpqrstvwxz]{5,}$'
<kees> ion: that's an alarmingly long list
<ion> Which piece of software do you prefer? ltspfsd, sgmlspl, fstrcmp, ncmpcpp, ppthtml, qpsmtpd, rbldnsd or wzdftpd
 * cjwatson wonders why apache2-mpm-event is showing up theree
<cjwatson> even with -n
<cjwatson> ion: haha
<highvoltage> jono_: are you around? the process on http://uds.ubuntu.com/participate/sponsorship/ is a bit flawed (if you click on the first step you'll see why)
<jono_> jcastro ^
<highvoltage> thanks :)
<jono_> :-)
<jcastro> highvoltage: what do you mean?
<jcastro> highvoltage: ok got it
<jcastro> I've just removed that form
<jono_> thanks jcastro
<highvoltage> jcastro: cool bananas
<kees> tedg: haha, love it. debconf frontend. you could totally do that, too.
#ubuntu-devel 2011-02-24
<robert_ancell> StevenK, can you sync glib-networking and libsoup2.4 from debian experimental?  Do you need bugs (we have no Ubuntu changes, we just need to keep syncing until stable release)
<StevenK> robert_ancell: Again? :-)
<robert_ancell> StevenK, yeah, GNOME keeps making releases!
<StevenK> Bad!
<robert_ancell> they have a schedule and everything
<cnd`> Riddell, are you on?
<cnd`> I think a net split has screwed things up on me
<NCommander> @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:
<bjf> i'm thinking now is not a good time to get today's updates: an apt-get dist-upgrade says that "The following packages will be REMOVED: ubuntu-desktop"
<broder> jcastro: i don't need to worry if i submitted my uds sponsorship app before jono's post, do i?
<micahg> @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: micahg
<micahg> can we upload from a UDD branch without an upstream tag?
<janimo> doko_, him what exactly should I check after eglibc build finishes?
<doko_> janimo: just installation and desktop start, I'll look at the test results too
<pitti> kees: argh, then what I have seen must have been the .91 result
<janimo> doko_, for the packages listed in that PPA?
<doko_> janimo: just eglibc
<janimo> ahuman, ok
<janimo> ahuman, ok
 * janimo hits xchat autocompletion
<dholbach> good morning
<RAOF> Anyone have touchpad problems since the most recent Xserver/synaptics upgrade?
<RAOF> If so, we want you!
<htorque_> RAOF, http://ubuntuforums.org/showthread.php?t=1694007
<bryce_> booyah
<bryce_> htorque_, awesome
<RAOF> Bah.  They haven't tried rolling back to the previous synaptics. :)
<htorque_> just doing updates, maybe i'm hit too
<RAOF> That would be helpful; I don't have access to any systems which are broken.
<htorque_> RAOF, :( touchpad's working fine here
<bryce_> RAOF, can you attach a downgrade script on bug #724051?
<ubottu> Launchpad bug 724051 in xserver-xorg-input-synaptics (Ubuntu) "upgrade to 1.3.99+git20110116.0e27ce3a-0ubuntu4 breaks touchpad " [High,Confirmed] https://launchpad.net/bugs/724051
<bryce_> RAOF, then I guess reassign the bug to cnd - will you be around when he gets up?
<RAOF> I can be around, yes.
<bryce_> alright, I'll check in on things in my morning
<RAOF> I'll do so.
<didrocks> good morning
<RAOF> Hey didrocks.  How's your touchpad? :)
<didrocks> RAOF: hum, alive, why? ;)
<RAOF> Oh, I'm just looking for someone who can reproduce bug #724051 :)
<ubottu> Launchpad bug 724051 in xserver-xorg-input-synaptics (Ubuntu) "upgrade to 1.3.99+git20110116.0e27ce3a-0ubuntu4 breaks touchpad " [High,Confirmed] https://launchpad.net/bugs/724051
<RAOF> It doesn't affect any of the hardware any of us X maintainers have access too.
<didrocks> RAOF: not sure I'm on that version because of nvidia :)
<RAOF> Man up and install nouveau! :P
<didrocks> RAOF: I prefer to keep what we install to our users :)
<didrocks> and not triggers new bugs
<RAOF> Eh.  Supported 3D drivers are for the weak!
<didrocks> ;)
<pitti> apw: yes, apparently language-selector was gratuitously renamed to l-s-gnome in 0.14, and the seeds weren't updated, and there is no transitional package iether
 * pitti cleans up behind that
<pitti> Riddell: ^ (that sponsored l-s was pretty broken..)
<micahg> @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:
<cdbs> micahg: :o
<cdbs> micahg: nice job!
<apw> pitti, thanks for hoovering up
<jamespage> doko_, asac, didrocks: do any of you have time to look at a long standing MIR for me?
<didrocks> jamespage: not from me, sorry :/ I finished a last MIR round yesterday but I won't be available at all today for that. Maybe ask mterry when he's here
<jamespage> didrocks: I'll pester mterry when he appears then unless doko_ or asac can help me out :-)
<tkamppeter> pitti, hi
<pitti> hey tkamppeter, how are you?
<tkamppeter> pitti, fine. Did you solve the problem of the automatic printer driver download not working with proxies completely?
<pitti> tkamppeter: I think so; I responded to the mail with some further questions, but didn't get a response
 * pitti digs out the old mail
<tkamppeter> pitti, I have digged it out, too. Yuji Saito from Avasys never responded.
<tkamppeter> pitti, I have sent a reminder now.
<mdz> seb128, my nautilus crasher bug 724202 is retraced now, and the stack has image_notify_cb rather than theme_changed_cb as in bug 721915. are you sure it's the same?
<ubottu> Bug 724202 on http://launchpad.net/bugs/724202 is private
<ubottu> Launchpad bug 721915 in libdbusmenu (Ubuntu) "gnome-terminal crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,Confirmed] https://launchpad.net/bugs/721915
<didrocks> seb128: pitti: I think that we should rename the compiz-fusion package to compiz as upstream has this name since 0.9. Is there a process for blacklisting sync from debian as they still have the old source package name?
<seb128> mdz, no, seems different, the other bug you pointed was a duplicate
<mdz> oh
<pitti> didrocks: yes, add it to /srv/launchpad.net/dak/sync-blacklist.txt
<pitti> didrocks: that is a bzr dir, so please commit the change as well
<seb128> mdz, I wish the retracers were working but gdb 6.8 produce broken stacktrace and gdb 7.2 is broken in the fakechroot environment
<didrocks> pitti: excellent, thanks :)
<seb128> didrocks, see 5.2 on https://wiki.ubuntu.com/ArchiveAdministration
<mdz> seb128, also, the "usr_lib_nautilus" info from the apport hook is hard to read because there's no whitespace between the items. would you like a trivial patch for that?
<mdz> e.g. usr_lib_nautilus: nautilus 1:2.32.2.1-0ubuntu6ubuntuone-client-gnome 1.5.4-0ubuntu1ubuntuone-client-gnome 1.5.4-0ubuntu1file-roller 2.32.1-0ubuntu3evince 2.32.0-0ubuntu10seahorse-plugins 2.30.1-3ubuntu2brasero 2.32.1-0ubuntu2deja-dup 17.90-0ubuntu3ubuntuone-client-gnome 1.5.4-0ubuntu1deja-dup 17.90-0ubuntu3deja-dup 17.90-0ubuntu3gnome-disk-utility 2.32.1-0ubuntu4nautilus-share 0.7.2-14ubuntu1totem 2.32.0-0ubuntu9nautilus-sendto 2.32.0-0ubuntu1quick
<mdz> ly-ubuntu-template 11.03.1-0ubuntu2
<mdz> I think putting newlines in there would be good
<didrocks> seb128: yeah, I read this, I was thinking about "official process" like sending an email or opening a bug :)
<pitti> didrocks: I don't quite understand -- our compiz source package is already called compiz, not compiz-fusion?
<seb128> mdz, that would be better indeed, I think they used to have space or new lines, I'm wondering if anything changed from the apport side, any patch would be welcome ;-)
<didrocks> pitti: the main and other plugins
<didrocks> pitti: those are multiple source packages
<didrocks> pitti: compiz-fusion-plugins-main for instance
<seb128> mdz, do you still have the .crash for this nautilus crash?
<seb128> mdz, #526743 has http://launchpadlibrarian.net/39673544/usr_lib_nautilus.txt
<mdz> seb128, yes I do
<seb128> mdz, i.e the list used to be a file and not inlined, not sure what changed
<mdz> seb128, apport automatically inlines it if it is <5 lines or so
<seb128> mdz, well, the source_nautilus.py didn't change and it used to have new lines, anyway that's a detail
<mdz> seb128, that's very weird, looking at the hook I do not see how it could have newlines
<mdz> if it did, it would probably be a bug in hookutils.package_versions
<siretart> do we have plans to remove qt3 from natty?
<seb128> mdz, can you install libdbusmenu-gtk3-dbgsym libdbusmenu-glib3-dbgsym and get a stacktrace from using gdb on the crashdump or use apport-retrace locally?
<seb128> mdz, right
<bdrung> raphink: re http://www.raphink.info/2011/02/version-number-suggests-ubuntu-changes.html - the correct way to deal with it is to run update-maintainer once you modified the changelog
<mdz> seb128, I can apport-retrace locally, sure
<siretart> I'm getting bugged about a package that uses qt3, which is supposed to be removed from unstable 'in the next 3 months'
<seb128> mdz, the retracers are screwed, they still run gdb 6.8 because 7.2 is borked under fakechroot or something and 6.8 has issues in natty now
<seb128> pitti tried to debug it without success
<pitti> to be precise, gdb 7.2 was just as broken locally with core dumps
<seb128> you picked a broken example
<pitti> none of the three bugs I tried it with had any difference in the retracer chroot vs. local gdb 7.2
<pitti> seb128: maybe, I could have been unlucky
<seb128> I can give you way to try easily on a running process
<seb128> 6.8 doesn't work here
<pitti> I checked strace on 7.2 in the retracer chroots, there were no obvious errors which looked like being fakechroot bugs
<seb128> where 7.2 does
<mdz> why does apport-retrace give me so many warnings about unavailable -dbg and -dbgsym packages? they should be available
<pitti> seb128: I didn't try that, just gdb program core
<pitti> mdz: the -dbg ones are bad warnings and fixed in trunk; -dbgsym> do you have ddebs.u.c. apt source?
<seb128> pitti, let me see if we have some apport-failed-retracing bugs with an i386 dump on launchpad today
<seb128> so I can try that as well
<mdz> dpkg: error processing /var/cache/apt/archives/nautilus-dbg_1%3a2.32.2.1-0ubuntu6_amd64.deb (--unpack):
<mdz>  trying to overwrite '/usr/lib/debug/usr/lib/libnautilus-extension.so.1.2.0', which is also in package libnautilus-extension1-dbgsym 1:2.32.2.1-0ubuntu6
<seb128> doh
<seb128> that could explain broke retracings as well
<seb128> pitti, is installing the -dbg a new thing?
<pitti> not really, they use -u --no-pkg
<pitti> seb128: adding -dbg is a relatively new thing, it was contributed by someone who said it'd improve things
<pitti> mdz: for local retraces you might try removing line 426 in /usr/lib/python2.7/dist-packages/apport/packaging_impl.py
<pitti> i. e.
<pitti>                     dependency_versions[pkg+'-dbg'] = dependency_versions[pkg]
<raphink> bdrung, like I said, the maintainer is a canonical employee
<raphink> bdrung, so I'm not sure updating the maintainer is the best option
<bdrung> raphink: that's not a reason to not change the maintainer
<pitti> brb
<varunthacker> has the ideas list for GSOC 2011 from Ubuntu been released yet?
<pitti> seb128: just to make sure we could of course remove -dbg package installation from the retracers as well
<pitti> seb128: (sorry, currently working on somethign else)
<seb128> pitti, well it seems likely the crash mdz just had will break the installation and the retracing
<seb128> not sure what we win from using the dbg when everything has a dbgsym
<mdz> seb128, I have a patch for the apport hook for you. email, bug report or bzr?
<pitti> seb128: it was added becuase a lot of dbgsym are missing
<seb128> mdz, either work, what is easier for you
<pitti> seb128: it's slightly better in trunk now
<seb128> mdz, or just commit and push if you worked on a checkou
<seb128> checkout
<seb128> pitti, well it seems obviously broken if it install conflicting dbg and dbgsym binaries, I would turn it off until someone debug it
<mdz> seb128, emailed
<seb128> mdz, thanks
<mdz> there was also a weird issue where attach_gconf was called but not imported
<mdz> something else must have imported it, because it seemed to work
<mdz> pitti, sorry, missed your earlier question: yes, I do have the ddebs source
<mdz> deb http://ddebs.ubuntu.com/ natty main restricted universe multiverse
<raphink> bdrung, nxvl is still the official maintainer (unless you want to change that nxvl )
<mdz> but I get e.g. WARNING: package libxcb1-dbgsym not available
<raphink> bdrung, afaik, the Maintainer field is not supposed to be changed at every upload
<mdz> pitti, and removing line 426 helped a lot, thanks
<bdrung> raphink: but on every merge
<raphink> it's not a merge
<mdz> seb128, I have a gdb session for my nautilus crash now
<pitti> mdz: that's actually correct, libxcb1-dbgsym is missing from http://ddebs.ubuntu.com/pool/main/libx/libxcb/
<pitti> (meh - want soyuz ddeb support enabled..)
<seb128> pitti, it's not?
<seb128> http://ddebs.ubuntu.com/pool/main/libx/libxcb/libxcb1-dbgsym_1.5-2_amd64.ddeb
<mdz> seb128, backtrace in http://paste.ubuntu.com/571641/
<pitti> seb128: that yes, but 1.7-2 is current
<seb128> oh right
<pitti> the udeb dbgsym made it for some strange reason
<seb128> mdz, hum, it's not better than the retracer one
<mdz> seb128, stack frame #2 has the same address as the data= parameter to the callback
<mdz> that doesn't seem right
<mdz> #1  0x00007f16efdcba9e in image_notify_cb (widget=0x2718810,
<mdz>     pspec=<value optimised out>, data=0x2026120)
<mdz> #2  0x0000000002026120 in ?? ()
<seb128> indeed
<mdz> I'm not surprised it can't find any debug symbols for the stack :-)
<mdz> I don't know what's wrong with #4 though, that one looks like a shared library
<seb128> mdz, thanks for trying locally, so it's a different issue from the retracer one
<seb128> mdz, the ProcMaps has no mapping for it though
<seb128> "7f16e0000000-7f16e02d9000 rw-p 00000000 00:00 0
<seb128> 7f16e02d9000-7f16e4000000 ---p 00000000 00:00 0 "
<mdz> weird
<pitti> seb128: indeed gdb 7.2 works just fine if I run it against a "synthetic" core file in the retracer chroot; so perhaps 7.2 is more sensitive to missing dbg symbols than 6.8, so that it produces much worse results on incomplete dbgsyms?
<seb128> pitti, could be
<seb128> should we just upgrade the version in the retracer and see how it goes?
<pitti> we could, sure
<pitti> seb128: FTR, I'm commenting out the pinning in /etc/apt/preferences
<seb128> pitti, ok thanks
<pitti> it'll get even worse, though
<seb128> pitti, why?
<pitti> as I said, all retraces I tried got worse with 7.2
<pitti> but let's try this for a few days and review how they look nw
<pitti> now
<seb128> pitti, you can take https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/719156 as an i386 example
<ubottu> Ubuntu bug 719156 in compiz (Ubuntu) "compiz crashed with SIGSEGV in nux::GpuRenderStates::SubmitChangeStates()" [Undecided,New]
<seb128> pitti, gdb on the dump locally produce a better stacktrace
<pitti> ah, good; trying
<seb128> pitti, http://paste.ubuntu.com/571646/
<seb128> pitti, is what I get on my natty box with the dump from this bug
 * pitti runs that in the retracer
<seb128> pitti, compared to http://launchpadlibrarian.net/64377347/Stacktrace.txt
<seb128> which is what the retracer got
<pitti> looks better now
<pitti> still a lot of "No symbol table info available.", but at least I get a similar stack to your's
<pitti> seb128: ^ ok, so let's run with that for a bit and cross fingers :)
<seb128> pitti, ok!
<seb128> pitti, do you need to keep the bug as an example or can I retag it need-i386-retrace?
<pitti> seb128: you can re-tag it
<pitti> seb128: in fact, let's do that and see what the fully automatic mode makes of it
<seb128> let's see how it goes
<seb128> pitti, right
<seb128> tagged
<seb128> pitti, the retracers are on?
<seb128> pitti, next cronjob is in 1 minute iirc
<pitti> yes
<PetrHH> Hello
<PetrHH> I'd like to release my app as version 1.0.0 alpha1
<PetrHH> and create my own repository
<PetrHH> How apt recognize new version of my app, after I relase 1.0.0 alpha 2?
<PetrHH> Yes, I'll put version in changes file but I'm afraid if it will work.
<raphink> PetrHH, apt bases itself on version number
<raphink> you can use dpkg --compare-versions $v1 lt $v2 && echo y || echo n
<raphink> to see which version dpkg/apt consider higher
<raphink> PetrHH, as far as versionning an alpha1 program, you sould use 1.0.0~alpha1 as the version, because ~ will make sure that 1.0.0~alpha1 come before 1.0.0
<raphink> so the package will be upgraded when 1.0.0 is out
<PetrHH> raphink, Thank you for explanation
<PetrHH> and will be upgrade also after I release alpha2 or beta1?
<raphink> yes PetrHH
<PetrHH> Great! Thanks a lot.
<raphink> 1.0.0~alpha1 < 1.0.0~alpha2 < 1.0.0~beta1 < 1.0.0~rc1 < 1.0.0~rc2 < 1.0.0
<raphink> thanks to the alphabetical order in which a < b < r
<PetrHH> it is great
<PetrHH> so I'll use ~
<raphink> yes
<PetrHH> Do you know any good how to create own Ubuntu repository?
<raphink> and the first package version will be 1.0.0~alpha1-0ubuntu1
<raphink> if you use a PPA and you plan to get your package in Ubuntu one day, the version will be something like
<raphink> 1.0.0~alpha1-0ubuntu1~ppa1
<raphink> -0ubuntu indicates that it's the first version in Ubuntu, not based on a Debian version (hence the -0)
<raphink> and ~ppa1 makes it a private PPA version that comes before the official one, so if ever your package ends up in Ubuntu officially, the official version will replace the PPA one
<PetrHH> I don't know how to use ppa. I'm already registered but my program needs CVS version of IDE to be build. So I must wait till new version will be released and added to Ubuntu repository. Because of this, I'd like to create own repo, first.
<raphink> a PPA is a personal repository, that's what you want I think
<raphink> if you have an account on Launchpad, just go to your page and activate your PPA
<raphink> it's much (much) easier than setting up your own local repository
<raphink> https://help.launchpad.net/Packaging/PPA
<PetrHH> Can I use packages from external repository?
<raphink> what kind of external repositories?
<PetrHH> My development enviroment is there
<PetrHH> SVN version of it
<raphink> PPAs can depend on official repositories as well as other PPAs
<PetrHH> great!
<PetrHH> hopefully it is also in ppa :-)
<mdz> pitti, are you going to remove the -dbg thing or keep it?
<pitti> mdz: it's already much better in trunk
<mdz> ah
<pitti> mdz: in the retracer chroots it increases the chance of getting debug symbols, as long as ddebs.u.c. i still separate and unreliable, so I'd actually like to keep it
<pitti> mdz: I could only enable it if --no-pkg is given, though
<pitti> that should DTRT on local retraces
<ricotz> who is the current friendly archive-admin for NEW package reviews?
<mdz> pitti, --no-pkg isn't on the man page; does that just unpack the debs without dpkg?
<pitti> mdz: yes
<ogra> ricotz, look at the wiki
<pitti> mdz: it's actually kind of deliberate
<mdz> heh
<pitti> mdz: you shoudl never ever use that option on a real system
<pitti> it's going to mess up everything
<pitti> mdz:  --help has it
<pitti> mdz: committed to trunk
<ricotz> ogra, thanks, which specific page would that be?
<mdz> pitti, if it only unpacks things in /usr/lib/debug, that doesn't sound so bad
<pitti> mdz: no, that applies to all packages
<mdz> oh
<pitti> mdz: I get too much breakage with using dpkg in fakechroots, and it's also taking too much time
<ogra> ricotz, ArchiveAdministration
<mdz> pitti, even with --force-unsafe-io?
<pitti> and as the entire chroot is just wiped after retracing, I don't care about the packaging system
<pitti> mdz: it's due to all the maintainer scripts, preinsts, etc., not so much due to I/O (which is slow either way)
<cjwatson> pitti: could you please push the final commit(s) in udev 166-0ubuntu1?
<mdz> ah, right
<mdz> I keep forgetting that the retracer has to install regular packages as well, not only the -dbgsyms
<ricotz> ogra, ty
<pitti> cjwatson: done, sorry
<cjwatson> thanks.  it's broken d-i and I wanted to investigate
<PetrHH> raphink, So it is not. I must wait till Carlos Laviola update his ppa to new version and developers release it. Two dayes a go, the created brach in svn for new release but still no official release4 info on their website.
<Riddell> janimo: you fixed the python-qt on ARM issue?!
<pitti> cjwatson: you mean the last upload? 165-0ubuntu2 still worked?
<cjwatson> not certain
<cjwatson> think so though
<pitti> interesting, the diff is tiny
<cjwatson> I think I know what it is
<janimo> Riddell, with the new uploaded package it works locally.
<cjwatson> a bunch of the _id tools moved to be guarded by --enable-extras
<janimo> Riddell, unfortunatly it does not build on buildd and I am not sure why
<cjwatson> I'll figure it out and fix it up
<pitti> cjwatson: ah, we do need the extras in the udev?
<pitti> ok, thanks
<janimo> Riddell, http://launchpadlibrarian.net/65061885/buildlog_ubuntu-natty-armel.python-qt4_4.8.3-0ubuntu3_FAILEDTOBUILD.txt.gz
<janimo> Riddell, the pyqt4 issue was fixed a while ago but the fix dropped recently hence the current FTBFS list
<cjwatson> pitti: yes, some of them but not all
<pitti> seb128: arh, lp borkage in i386 retracer again
<seb128> pitti, :-(
<seb128> pitti, like the same issue than the other day?
<pitti> yes
 * pitti cleans cache and restarts
<seb128> how did you solve it the other day? cleaned .launchpadlib?
<pitti> right
<seb128> why would the cache breaks it this way...?
<pitti> ERROR: connecting to Launchpad failed: ValueError
<pitti> awesome
<pitti> that seems to be the new launchpadlib now
<cjwatson> pitti: (d-i has been broken for other reasons for a bit, hence me only noticing this now)
<cjwatson> gosh, over a week ...
<pitti> seb128: ah, this gets a "504: Gateway Time-out" now with the new launchpadlib; I guess this is talking to a new server now and needs un-firewalling
<pitti> seb128: this stuff all seems to have conspired against us.. :(
<pitti> bah, works under strace, I guess it really was transient
<pitti> seb128: above crash got retraced, see http://launchpadlibrarian.net/65063086/Stacktrace.txt
<Riddell> janimo: hmm, some general qt issue there it looks like, I'll investigate
<janimo> Riddell, it is strange as it seems to me those package versions are installable on natty/arm
<elmo> what does stuff in brackets in a seed mean?
<elmo> and if something is in brackets on http://people.canonical.com/~ubuntu-archive/seeds/ubuntu.natty/desktop - can I assume it's on the natty (ubuntu) live CD?
<cjwatson> elmo: germinate(1) should document all the syntax
<cjwatson> elmo: if you mean (), that turns into Recommends in metapackages
<seb128> pitti, quite better :-)
<cjwatson> you can assume that it's intended to be on the live CD, but not that it actually is - you need to check the .manifest and .list files on cdimage for that
<cjwatson> pitti: so remind me how I build a working udev source package out of bzr?  it's complaining about stuff under test/ - I've hit this in the past but forget how I handled it
<elmo> cjwatson: ah, thanks I was reading SeedManagement on the wiki - didn't think to RTFM
<pitti> cjwatson: dpkg-buildpackage -S works
<pitti> cjwatson: it seems that debuild -S ignores the tar-ignore options in debian/source/options
<pitti> cjwatson: (or diff-ignore)
<elmo> what the heck is amd64+mac ?
<cjwatson> pitti: ah, thanks
<cjwatson> elmo: the amd64 CD built without UEFI support so that Macs can boot it
<cjwatson> (and some other machines - it's a slight misnomer)
<elmo> ah
<Riddell> janimo: the qt install issue is just waiting for this to compile on arm https://launchpad.net/ubuntu/+source/libx11
<ricotz> Riddell, hello :), could you accept the libbluray binaries?
<Riddell> ricotz: is there a pressing need?
<ricotz> Riddell, i was hoping siretart wants to update mplayer to use
<janimo> Riddell, if so the buildd errors are surely misleading.
<Riddell> janimo: soyuz being confused by build-depend issues isn't rare :)
<janimo> Riddell, good to know. First time I see this though :)
<ricotz> Riddell, and since you have the insights after reviewing it, might be useful you would also do this
<zyga> hi, where can I find some documentation about the purpose of debian/package.doc-base?
<cjwatson> zyga: man dh_installdocs
<cjwatson> and man install-docs
<zyga> cjwatson, I read the first one, I'm still not familiar with what doc-base is
<zyga> cjwatson, is it some debian global documentation registry?
<mdz> pitti, I committed a couple of tiny improvements to hookutils in apport trunk; should I be documenting things like that in NEWS?
<cjwatson> zyga: yes, pretty much
<pitti> mdz: I usually do that along with the actual patch, and then have a script "newscommit" which works like debcommit for NEWS
<cjwatson> apt-cache show doc-base
<zyga> cjwatson, how does one use it in practice?
<mdz> pitti, oh, neat
<pitti> mdz: http://people.canonical.com/~pitti/scripts/newscommit FYI
<cjwatson> zyga: it doesn't sound like you've read the doc-base documentation - could you do that, and then come back if it's still unclear?
<zyga> sure, let me find it
<pitti> mdz: as long as you use standard (LP: #xxxx) syntax, it also tags the bugs appropriately
<mdz> I see
<rniamo> hi, under natty i have segfault with gnome : http://pastebin.com/3Nt2v0Ee
<seb128> rniamo, try getting a stacktrace https://wiki.ubuntu.com/Backtrace
<rniamo> seb128: how can i do to debug, it is gdm
<seb128> rniamo, what is gdm? the log you copied is a gnome-panel crash
<zyga> cjwatson, okay I think I got it now, thanks
<rniamo> seb128: in fact when i start each time i open a gnome window it crash
<zyga> cjwatson, how can I check that the documentation is properly registered with doc-base? yelp did not manage to find my package
<rniamo> here is the stacktrace i can have: http://pastebin.com/uYMvgBRg
 * ogra glares at a buildlog
<ogra> geeez, world is broken !
<cjwatson> zyga: you can use 'install-docs -s <document-id>'
<rniamo> seb128: http://pastebin.com/uYMvgBRg i had this
<ogra> is there something wrong on a very low level ? or am i insane ?
<zyga> cjwatson, so it shows some output, should that convince me that everything is okay?
<seb128> rniamo, seems similar to bug https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/710678
<ubottu> Error: Bug 710678 is private
<rniamo> seb128: yes i can't access this page even being loggued
<seb128> rniamo, try again
<cjwatson> zyga: probably.  you could try dwww or something
<rniamo> seb128: it seems to work, thanks
<mdeslaur> @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: mdeslaur
<zyga> how can I test that my package will build on lucid + maverick + natty using pbuilder? do I need to sudo pbuilder --create --distribution=$foo and then sudo pbuilder --build *.dsc ?
<raphink> zyga, you can use pbuilder-dist with multiple configurations
<raphink> that will work as a wrapper so you can have several pbuilders on the same machine and run each of them on the source
<raphink> see man pbuilder-dist
<mterry> doko_, what's the story with twm then?  You don't like pulling in all of metacity's dependencies?
<zyga> raphink, how can I purge existing pbuilder data safely?
<zyga> pbuilder --clean?
<raphink> zyga, pbuilder clean
<zyga> thanks
<doko_> mterry: it's sometimes broken, and pulls the whole world with libcanberra
<mdz> pitti, I'm still surprised how many package hooks don't use the convenience functions in hookutils, and reimplement things like checking the versions of related packages, even attaching files and running commands
<mdz> there is also some good stuff in package hooks which should be factored out into hookutils
<ogra> someone should blog about it ;)
<ogra> (no, i'm not volunteering :) )
<mdz> I just noticed that the example in https://wiki.ubuntu.com/Apport/DeveloperHowTo didn't use hookutils, so I fixed that
<cnd> cdbs, are you still around?
<cnd> I'm wanting to tackle the trackpad bug
<raphink> ogra, a blog entry on hooks would be great
<mdz> raphink, I don't know what there is to blog about which isn't already in https://wiki.ubuntu.com/MeetingLogs/devweek0909/ApportPkgHooks and DeveloperHowTo
<raphink> maybe just a blog post to let people know that this page exists :-)
<mdz> JFo, is https://bugs.launchpad.net/ubuntu/+source/apport/+bug/614421 fixed/obsolete?
<ubottu> Ubuntu bug 614421 in apport (Ubuntu) "linux package hook needs updating" [Medium,Triaged]
<mdz> raphink, sounds more like a dent :-)
<raphink> mdz dents are probably read by less people than planet
<mdz> raphink, perhaps so
<raphink> ;)
<jamespage> mterry: any chance you could review bug 676904 for me? As FF is nearly here I'd like to get it sorted one way or the other.
<ubottu> Launchpad bug 676904 in jansi-native (Ubuntu) "[MIR] jansi" [Medium,Confirmed] https://launchpad.net/bugs/676904
<mterry> jamespage, yeah, I'm in the middle of it
<jamespage> mterry: just noticed - thanks!
<zyga> how can I emulate a PPA environment with pbuilder, I want to build a package that depends on a more recent version of a package (than available in ubuntu) that I keep in my ppa. I'd like to test this setup before actually uploading to a ppa
<cody-somerville> zyga, You can create a pbuilder chroot that has your PPA in the sources.list.
<m4n1sh> zyga: login to your chroot image
<zyga> cody-somerville, is there some --option for that or just do that manually?
<m4n1sh> pbuilder --login --save-after-exec
<m4n1sh> OR
<m4n1sh> pbuilder --login --save-after-login
<siretart> Riddell: do we have plans to remove qt3 from natty? I'm being bugged about a package that uses qt3, which is supposed to be removed from unstable 'in the next 3 months'
<cdbs> cnd: back
<Riddell> siretart: Qt 3 is part of LSB, so I think it depends if we care about LSB
<cdbs> cnd: I did a half-revert upload to my PPA as a test, which used the new ABI for building, and except for that, it was the same as -0ubuntu3
<cnd> cdbs, can you perform the steps I just posted to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/724051
<ubottu> Ubuntu bug 724051 in xserver-xorg-input-synaptics (Ubuntu) "upgrade to 1.3.99+git20110116.0e27ce3a-0ubuntu4 breaks touchpad " [High,Confirmed]
<siretart> Riddell: do you have a reference at hand?
<Riddell> siretart: reference to what?
<siretart> to 'Qt 3 is part of LSB'
<Riddell> google for LSB?
<cdbs> cnd: okay, doing
<siretart> thanks
<cnd> Riddell, hey, did you get my email?
<Riddell> cnd: yep, qt didn't compile with the libxi from the PPA last night but it seems to be compiling fine with the libxi in the archive now so I'll upload that once it's done here
<cnd> Riddell, great!
<cnd> thanks!
<cnd> thanks cdbs!
<cdbs> cnd: followed, mailed to bug (will take some time for comment and attachments to come up in LP as I posted through email)
<cnd> cdbs, thanks!
<cnd> cdbs, I can reproduce the issue now, thanks!
<vila> james_w`: thanks for the reviews ! The code is now running on jubany
<vila> james_w`: there are a bunch of outstanding jobs due to a os.environ difference between my test env and jubany which led to massive failures on first restart. Fixed now.
<james_w`> vila, great, thanks for the branches
<james_w`> and the tests!
<vila> james_w`: my pleasure, just mentioning the new deployment so if you see something unusual you had the right context
<james_w`> thanks
<vila> james_w`: hmm, I wonder if the bad restart caused all previous failures to be overridden...
<hrw> morning
<mdz> jhunt, any guesses what could cause bug 710983?
<ubottu> Launchpad bug 710983 in apport (Ubuntu) "package apport 1.17.1-0ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/710983
<mdz> (upstart related)
<kklimonda> pitti: did tor get an SRU exception?
<pitti> kklimonda: oh, is that back in teh archive?
<pitti> so it is
<pitti> in dapper, hardy, and natty
<pitti> seems we didn't remove it hard enough then
<pitti> kklimonda: it did get an SRU exception back then, when someone said he'd take care of updates and testing
<kklimonda> I think it was removed after hardy
<jhunt> mdz: this is a duplicate of bug 707971 (I've just marked it as such).
<ubottu> Launchpad bug 707971 in upstart (Ubuntu Natty) "package apport 1.17.1-0ubuntu3 failed to install/upgrade: invoke-rc.d: initscript apport, action "start" failed." [Critical,Fix released] https://launchpad.net/bugs/707971
<kklimonda> pitti: ah, I guess I've asked the wrong question then, I do remember the original discussion about it but it was some time since then.
<kklimonda> pitti: afair there were two issues - lack of manpower dedicated to tor, and the issue of how trusted our uploads are? my memory is getting fuzy here, but I remember talking about keys, and getting the debian maintainer on board.
<mdz> jhunt, oh, thanks
<pitti> kklimonda: mainly because tor releases constantly need to be kept up to date in stable releases, even across major versions
<pitti> kklimonda: and as there is nobody who looks after that, we felt that it's better to not ship it at all
<pitti> I'm not sure how it landed back in natty
<cjwatson> somebody promised to do it
<kklimonda> ah, I've found the bug: bug 689188
<ubottu> Launchpad bug 689188 in tor (Ubuntu Natty) "Unblock Tor auto-syncing from Debian" [Undecided,Fix released] https://launchpad.net/bugs/689188
<kklimonda> also bug 697407 - so something is happening. :)
<ubottu> Launchpad bug 697407 in tor (Ubuntu) "Please update Tor in older versions of Ubuntu" [Undecided,New] https://launchpad.net/bugs/697407
<cnd> hi all, we've broken some synaptics trackpads: https://bugs.launchpad.net/ubuntu/+source/utouch-frame/+bug/724051
<ubottu> Ubuntu bug 724051 in utouch-frame (Ubuntu) "upgrade to 1.3.99+git20110116.0e27ce3a-0ubuntu4 breaks touchpad " [High,New]
<cnd> we're looking for a sponsor to upload a fix
<cnd> need a core-dev
<kklimonda> Jacob is apparently a core developer of tor
<kklimonda> but he doesn't have upload rights to tor in Ubuntu, so we still need either developer interested in tor, or someone who can help Jacob get PPU for tor.
<apw> i assume we are aware that unity is in a heap _again_
<didrocks> apw: downgrade gsettings-desktop-schemas, the new version add a Breaks:
<rydberg> hi, a tiny tiny bugfix to a huge huge problem we managed to introduce yesterday: https://bugs.launchpad.net/ubuntu/+source/utouch-frame/+bug/724051
<ubottu> Ubuntu bug 724051 in utouch-frame (Ubuntu) "upgrade to 1.3.99+git20110116.0e27ce3a-0ubuntu4 breaks touchpad " [High,New]
<mdz> cjwatson, is bug 712677 by design? (apport dialog not being triggered during "install Ubuntu" session)
<ubottu> Launchpad bug 712677 in apport (Ubuntu) "Does not report crashes during "Install Ubuntu" installs" [Undecided,New] https://launchpad.net/bugs/712677
<mdz> jhunt, is bug 723670 a dupe of that one as well?
<ubottu> Launchpad bug 723670 in apport (Ubuntu) "package apport 1.18-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/723670
<apw> didrocks, i assume that'll stop anyone who is still ok from getting fooked ?
<didrocks> apw: the breaks: will avoid apt-get upgrade yeah
<apw> didrocks, will downgrade and see if that resolves me
<apw> i hate unity
<didrocks> apw: keep me updated
<didrocks> that really help the conversation, but I have more than 15 packages still to upload, so I won't raise itâ¦
<cjwatson> mdz: ev would know for sure, but I don't believe it is.  that would be a ubiquity bug
<ev> definitely not by design
<jhunt> mdz: yes, I think it is (the description text is possibly misleading).
<apw> didrocks, as you can probablaly tell from the delay its not much better after the downgrade
<apw> didrocks, i had a blank screen on login with about a dozen crash things
<apw> didrocks, i had unity and compiz still alive, but had to unity --reset on VT1 to get anythihng working
<apw> didrocks, and i now have doubled indicators
 * apw calls that fali
<didrocks> apw: I'm not sure about the indicator, ask tedg
<didrocks> apw: weird that you had to reset to get unity working though, as you just downgraded an unrelated package
<apw> at least i have indicators now after the --reset
 * apw will try a afull reboot ... like it was windows
<cnd> cody-somerville, is the process for creating a new package set documented somewhere?
<cnd> I'm interested in creating one for the utouch packages
<apw> didrocks, seems like applyiing the 7Rs to it seemed to work, must be some other interaction with the glib downgrade which survived logout
<didrocks> apw: maybe some gsettings, right
<cody-somerville> cnd, I believe the lp API is used to manage them. However, I think you'll need a member of the TB to set it up.
<cody-somerville> cnd, with approval from the DMB
<apw> didrocks, unity seems to hate me
<cnd> cody-somerville, that's the technical "how to create a package set", but I need to know what the process is for asking the DMB or TB :)
<cnd> do I add it to the agenda myself?
<cnd> make a wiki application page?
<cody-somerville> cnd, Ah. Yes.
<didrocks> apw: well, the changes will be way less draster after today's upload, so it should be better
<cody-somerville> cnd, And yes (doesn't need to be anything too formal, just describing what you want).
<cnd> cody-somerville, to be sure I understood you right, I should make a wiki page for the application, and I should add it to the agenda?
<cody-somerville> cnd, Aye.
<apw> didrocks, heh heres hoping
<cnd> cody-somerville, ok, thanks!
<mdz> mvo, around?
<mvo> hey mdz
<mvo> yes
<mdz> mvo, I'm wondering whether it's more correct to fix bug 573594 (and others like it) in apt or in package_hook
<ubottu> Launchpad bug 573594 in apport (Ubuntu) "apport files bugs for dpkg: Exec format error messages" [Undecided,Confirmed] https://launchpad.net/bugs/573594
<mdz> currently we check for some cases in each place
<mdz> it actually seems like what we want is a global bugpattern
<mdz> which would be much easier to maintain than all of this code
<mvo> mdz: indeed, the package_hook has various advantages, its more logical to put it there than in apt and its also python so the string parsing/maniplution is easier
<rydberg> anyone wants to sponsor a one-liner with great bug heat? https://bugs.launchpad.net/ubuntu/+source/utouch-frame/+bug/724051
<ubottu> Ubuntu bug 724051 in utouch-frame (Ubuntu) "upgrade to 1.3.99+git20110116.0e27ce3a-0ubuntu4 breaks touchpad " [High,New]
<mdz> mvo, the advantage of doing it in apt is that it can look up the translated string
<mdz> and it doesn't bother the user with a useless crash report
<mvo> mdz: we should be able do that with dgettext("apt", msg)  too
<mvo> mdz: but yeah, the bothering the user is a problem
<mdz> mvo, ah yes, true
<mdz> harder in a bugpattern :-)
<mvo> mdz: this is the advantage of the bugpattern, right? that will filter it out before it reaches the user?
<mvo> mdz: indeed :)
<mdz> mvo, no, the bugpattern is actually the latest check
<mdz> apt â package_hook â apport â bugpatterns
<kklimonda> pitti: if tor already has an SRU exception, would it be possible to update hardy package to the current stable, as per upstream request? I'm pretty sure anyone interested in tor at this point is already using it from the upstream repository, this update would help us assess the amount of work future updates would take. I can work on that, as I use tor semi-regulary (whenever I put my tin-foil tat
<kklimonda>  on).
<mdz> the experience for the user should be pretty much the same for package_hook and a bugpattern
<mdz> sorry, I actually meant general-hooks/ubuntu.py, not package_hook
<pitti> kklimonda: not only possible, but desirable; actually doing that was part of the deal from the start :)
<mvo> mdz: what about adding a apport_apt_filter? so that apt calls a external filter before passing it on to apport?
<kklimonda> pitti: the only problem I see right now is that tor's developers advise users not to use packages that were not signed by people who are mentioned on https://www.torproject.org/docs/verifying-signatures.html.en - debian maintainer is on this list, but no one from Ubuntu is.. and this is one of the issues mentioned in the bug 413657
<ubottu> Launchpad bug 413657 in tor (Ubuntu) "Please sync tor 0.2.1.26-6 (universe) from Debian testing (main)" [Wishlist,Fix released] https://launchpad.net/bugs/413657
<mdz> mvo, I'd probably suggest adding that functionality to apport instead, so that other packages can benefit
<mdz> the "silently throw away this crash report" feature
<mvo> mdz: sounds good, a generic pre-report filter
<mdz> mvo, then we could add a bugpattern scan to general-hooks/ubuntu.py
<mdz> if we wanted to
 * mvo nods
<mdz> pitti, what would you think of having a global bugpattern list in addition to the per-package ones?
<pitti> mdz: sounds fine to me; shouldn't be too hard to implement
<pitti> mdz: in fact, we could also only use a global list
<pitti> when I started this, I wasn't sure how big our list would actually get, and wanted to minimize XML parsing
<pitti> but it turns out that we don't actually have hundreds of entries, and a lot of them are necessary only temporarily
<pitti> so the rules could additionally match on "Package" and all be in one file
<pitti> (and we should remove the ones whose bugs were fixed long ago)
<mdz> pitti, 273 by my count ;-)
<pitti> mdz: right, bug I suppose 250 can be dropped now :)
<mdz> if the package match is always listed first, it should be very inexpensive
<pitti> we need to keep the per-package ones around (on people) for stables, but they aren't that relevant (mostly for packagage upgrade failures, not so much for crashes)
<Chipzz> kklimonda: I fail to see your issue?
<Chipzz> kklimonda: I quote from the page: "To verify the signature of the package you downloaded, you will need to download the ".asc" file as well."
<Chipzz> but that assumes you *download* something from their site, which you don't since you're installing with apt?
<kklimonda> Chipzz: what I mean is that neither source nor binary package in Ubuntu is going to be signed by one of the keys listed on this website.
<Chipzz> kklimonda: and what I'm saying is that matters exactly zarroo
<Chipzz> since the packages are signed by the ubuntu archive keyring
<Chipzz> or rather
<Chipzz> they have their checksum in a file which is signed
<Chipzz> ...
<ScottK> kklimonda: I think the final resolution on TOR was that ubuntu-archive signature was good enough.
<ScottK> We'd need them to update their web site to say so though.
<highvoltage> if there's an archive admin on duty today, it would be really nice if they could look at the 4 schooltool packages in NEW, they have FFe's filed already and are in good shape and shouldn't take too much time
<kklimonda> Chipzz: what I'm saying is that it matters to people who use tor, that the signature on the package isn't listed on the page. At least that has been one of concerns that were raised during the discussion. I haven't seen the part of the discussion when it has been decided that the ubuntu-archive key is enough, if it is then it's great - we just have to make them update their website . )
<Chipzz> kklimonda: for one, your comment seems to be misleading
<Chipzz> https://bugs.launchpad.net/ubuntu/+source/tor/+bug/413657/comments/4
<ubottu> Ubuntu bug 413657 in tor (Ubuntu) "Please sync tor 0.2.1.26-6 (universe) from Debian testing (main)" [Wishlist,Fix released]
<Chipzz> you talk about signed packages
<Chipzz> which is incorrect
<kklimonda> Chipzz: it's not mine :)
<Chipzz> Oh I was assuming that comment was yours
<Chipzz> but you make the same mistake
<Chipzz> I can't see how the signature on the *package* matters
<Chipzz> the package would be the .deb you download and extract, and which is signed by the ubuntu archive. But this .deb is cleaned out when you do apt-get clean, so it matters not
<ScottK> highvoltage: As long as they are uploaded before FF, they don't have to be accepted by FF to get in.
<Chipzz> what I *can* see mattering is the signature of the *executable*
<Chipzz> which is a different thing altogether
<kklimonda> Chipzz: by signature on package, I mean signature confirming that the downloaded package has been uploaded by someone trusted.
<kklimonda> Chipzz: it obviously doesn't mean the executable hasn't been tampered with.
<cjwatson> Chipzz: .debs are not signed directly by the Ubuntu archive
<cjwatson> the signature on .debs is via the Packages and Release files
<Chipzz> cjwatson: that's what I said above:
<kklimonda> (but the source packages are signed, and they can be downloaded, and verified)
<Chipzz> 17:21 < Chipzz> or rather
<Chipzz> 17:22 < Chipzz> they have their checksum in a file which is signed
<GunnarHj> doko_: Hi Matthias, any chance that you can help fixing bug 710151?
<ubottu> Launchpad bug 710151 in language-selector (Ubuntu) "Language selector reminds user about missing language support for OpenOffice.org instead of LibreOffice" [Undecided,Confirmed] https://launchpad.net/bugs/710151
<cjwatson> fair enough.  you didn't say it very clearly just now. :)
<Chipzz> cjwatson: I was "shortening" it for the sake of the discussion
<Chipzz> cjwatson: I could have repeated that, but than I might just as well have used the complete terminology in the first place ;)
<cjwatson> I think just saying "indirectly signed" would be good in future to avoid confusion
<cjwatson> since there *is* a technology for signing .debs directly, it's just not generally used by distributions because signing the archive is more convenient
<highvoltage> cjwatson: who should I give a poke to let them know that live USB disks doesn't add the repositories on the disks when booting? (LP: #723357)
<Chipzz> kklimonda: and what I mean is that "it matters to people who use tor, that the signature on the package isn't listed on the page" is completely irrelevant
<cjwatson> highvoltage: I don't know
<Chipzz> kklimonda: since apt-get does the downloading and verifying FOR you
<cjwatson> highvoltage: I mean I suppose me, but you've already poked me
<kklimonda> Chipzz: but there is nothing preventing someone from tampering with tor before uploading it to archive.
<Chipzz> kklimonda: ideally, users do not even look at the .deb
<cjwatson> and I'm not sure I'm going to have time to investigate it
<Chipzz> kklimonda: yes there is.
<highvoltage> cjwatson: yeah stgraber said I should poke you, but I think you already have too much stuff to do
<Chipzz> kklimonda: ppl are supposed to be trustworthy before they can upload
<Chipzz> kklimonda: in debian you have a keyring, the NM process, and lots of other measures to assure that
<kklimonda> Chipzz: "are supposed to be" being a key - but we don't check if people are who they say they are before giving them upload rights. I know the argument is academic one, but people who use tor are not exactly people who thrust others easily.
<Chipzz> kklimonda: in ubuntu you have similar infrastructure/rules to achieve sth similar
<Chipzz> kklimonda: well when you start using that argument, I stop this discussion
<Chipzz> because by that reasoning every package in ubuntu is untrustable
<kklimonda> Chipzz: I don't even think it is the issue, but I don't know if it has been addressed.
<ScottK> Chipzz: One major difference is that in Ubuntu there's no process tie the uploader to a real identity.
<cjwatson> the entire purpose of tor is to be ultra-paranoid and to trust virtually nobody
<cjwatson> it's hardly surprising that many of its users might have stronger trust requirements than we provide
<Chipzz> and if you assume that every package is untrustable, you might as well format your harddisk
<cjwatson> but indeed, Ubuntu doesn't require web-of-trust before upload rights
<Chipzz> isn't that an inherent problem with ubuntu then?
<cjwatson> so "in ubuntu you have similar infrastructure/rules" does gloss over quite a bit
<cjwatson> arguably; of course there are reasons for it
<maco> i know one person who wouldnt be a motu if keysigning was required. she lives on the opposite side of russia from the DDs
<Chipzz> one solution would be to upload tor to main/restricted then, since the number of ppl who can upload to main is much smaller, and the ppl who can upload can be trusted
<Chipzz> but, that of course creates another set of problems
<Chipzz> like someone with main upload rights having to maintain (or at least upload) the package
<ScottK> It could also be in an exclusive packageset that only select people could upload.
<kklimonda> the best solution would be to work with Jacob, who has said that he's interested in maintaining tor for Ubuntu, to get PPU rights.
<mdz> pitti, the apport unit tests are blowing up on me because there's a /bin/cat process running (child of zeitgeist-daemon)
<cjwatson> I don't think we'd be willing to support it in main
<Chipzz> ScottK: that's possible?
<ScottK> Sure.
<kklimonda> or even what ScottK has said
<cjwatson> it's theoretically possible
<ScottK> I think so.
<cjwatson> it's never been ussed
<Chipzz> I guess I'm not up-to-speed with launchpad features
<cjwatson> *used
<cjwatson> and it does present its own problems
<ScottK> cjwatson's the expert though.
<pitti> mdz: yeah, I sometimes have that as well, and just killall cat
<maco> pitti: how cruel! :P
<pitti> I know, it's an useless use of cat!
<mdz> pitti, I wonder if it does anything important
<mdz> I don't see an invocation of cat in the zeitgeist source
<pitti> mdz: it doesn't always exist, I wonder if it's a leaked process somehow
<Chipzz> pitti: no, it's a usefull use of cat, since now you can kill (the) cat to fix it ;)
<pitti> heh
<mdz> this is one of those days where you need to enforce a stack size limit
<mdz> if you keep looking for the next bug, you never get to the bottom
<mdz> s/you/I/g
<cjwatson> a system I use once developed a one-bit error in /bin/cat
<cjwatson> it's amazing how much stuff kept on working anyway
<SpamapS> anybody having iphone tethering working in natty? I'm told it works fine in maverick but my natty box just refuses to work. :-/
<cjwatson> e.g. the entire news server and clients continued to work fine
<ion> cjwatson: We really need a checksumming filesystem Ã  la btrfs, zfs.
<mdz> cjwatson, I bet an awful lot of stuff goes wrong if you try to boot :-)
<cjwatson> probably ...
<cjwatson> that box isn't rebooted often :)
<ion> I wonder if one can already trust btrfs with her data?
<mdz> pitti, I killed it, and now it's a zombie and the test suite still fails :-)
<mdz> have to kill the whole of zeitgeist
<pitti> mdz: it's a cat, you need to kill it 9 times :)
<ion> haha
<mdz> pitti, I did!
<cjwatson> of course checksumming filesystems have their own problems; they mean that we need to use a different approach instead of /boot/grub/grubenv
<mdz> isn't that what kill -9 does?
<ion> cat should be patched to count the number of SIGTERMs and die on the ninth one.
<ion> mdz: :-D
<cjwatson> (we don't really want to implement writing to the checksum tree in the boot loader)
<pitti> mdz: good point! but you also need --disable-schroedinger, otherwise it's still alive if you don't run ps aux and look at it
<ari-tczew> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: mdeslaur, ari-tczew
 * ari-tczew gets syncs for universe.
<Chipzz> pitti: you'ld say killing it with kill -9 would be equivalent to killing it 9 times :)
<ion> cjwatson: Perhaps a filesystem could support an ioctl (or something) to create files saying âno checksum for the data, please â i donât care about potential corruption hereâ.
<cjwatson> we're going to use the reserved boot loader area in btrfs instead
<mdz> pitti, I used ps to look, and the result was indeterminate (the zombie is neither alive nor dead)
<cjwatson> it leaves 64KB at the start
<ion> cjwatson: Ah
<kklimonda> at what hour does freeze start?
<cjwatson> 1800 UTC
<ari-tczew> so about hours left
<ari-tczew> hour*
<cjwatson> 19:12 <skaet_> all, just to be clear feature freeze will be at 1800 UTC Feb 24th for Natty,  after that please follow the https://wiki.ubuntu.com/FreezeExceptionProcess if something needs to get uploaded.
<pitti> mdz: FYI, you can catch multiple exceptions with "except (IOError, ValueError):
<mdz> pitti, ah, thanks. shall I fix that or have you done it already?
<cjwatson> pitti: could you please review bug 721622?  you removed the package
<ubottu> Launchpad bug 721622 in Ubuntu "Sync greasemonkey 0.9.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/721622
<pitti> mdz: haven't touched any code, just noticed your question fly by in the MP
<pitti> cjwatson: looking
<mdz> pitti, I thought specifying a tuple to except would invoke the old "<type>, <variable>" style
<pitti> mdz: no, "excecpt (E1, E2, E3) as e:" works fine even in Python 3
<pitti> mdz: comma doesn't work any more, right (it's "as" now)
<pitti> cjwatson: can I close it as wontfix?
<cjwatson> pitti: up to you
<mdz> pitti, fixed and pushed
<pitti> will do that then with a coment
<cjwatson> I'm just working through the sync queue and noticed that that one seemed off
<cjwatson> odd
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ari-tczew
<bdrung> cjwatson: all xul extension were removed (too high maintaince cost)
<cjwatson> bdrung: I know
<cjwatson> that's why it struck me as odd, so I asked pitti because he did the removal
<cjwatson> in this case
<micahg> cjwatson: we didn't publicize it, so people might still think they can request them :)
<pitti> cjwatson: just to ensure that I'm not missing anything -- in https://merges.ubuntu.com/a/avahi/avahi_0.6.28-2ubuntu2.patch we can really drop our delta in the init.d scripts, as we use upstart anyway, right?
<pitti> cjwatson: (asking you because you did the last merge)
<cjwatson> pitti: I guess so, though those diffs ought to go to Debian
<vila> james_w`: weird, it seems that too many packages were requeued, but on the other hand I see a fair number of successful imports...
<vila> james_w`: are they false positives ?
<tseliot> cjwatson: if I wanted to blacklist all ati cards (so as to unset gfxpayload=keep) I should use this expression, right? v00001002d*sv*sd*bc03sc*i*
<cjwatson> that looks plausible though I haven't checked the details
<cjwatson> that's only in the fglrx packaging, right?
<tseliot> cjwatson: yep
<james_w`> vila, hmm, yeah, looks like everything got requeued?
<vila> james_w`: not everything, but ~5000
<james_w`> vila, well, everything that had failed
<vila> ha, depends on what failure wre' re talking about :-/ There was ~500 packages with known failures
<james_w`> right, but there are only a few with known failures now, which is why I think that
<vila> james_w`: AIUI, running import_package.py for a successfully imported package is harmless right ?
<james_w`> vila, yeah
<vila> james_w`: so I'm only concerned about the newly created branches here
<vila> james_w`: either we failed to trigger an import earlier or we are creating bogus branches
<pitti> ev: saw your ubiquity upload, did the jockey --no-dbus thing work for you then?
<vila> james_w`: I suspect the former but why would that be the case ?
<james_w`> vila, do you have an example?
<james_w`> I'm not sure what you are referring to with "newly created branches"
<vila> james_w`: the ones mentioned in the log with a leading:  INFO - Success
<vila> james_w`: avscan a couple of minutes ago
<vila> james_w`: or https://code.launchpad.net/+recently-registered-branches for a more accurate source
<pitti> mdz: I guess the displayed fiff at https://code.launchpad.net/~mdz/apport/504340-kernel-threads/+merge/51149 is outdated now? (werid, usually LP shows a "updating diff.." yellow box)
<james_w`> vila, yeah, looks to me like all failures were requeued, and we are just seeing some failures that were fixed
<james_w`> vila, so they are now importing ok
<mdz> pitti, latest revno is 1858
<james_w`> vila, it's a shame we don't have historical information on failures though
<vila> james_w`: cool, thanks for confirming :)
<james_w`> well, we do to some extent, one second
<pitti> mdz: right, it got that, but it still shows the open() outside of the try:
<vila> james_w`: a bit can be extracted from the logs, but may be the db has more ?
<mdz> pitti, it also doesn't show the test
<james_w`> the db doesn't
<james_w`> AssertionError: Can't find the needed upstream part for version 3.2.2-openssl-1build1~feisty1
<james_w`> that was avscan
<james_w`> so we fixed that error at some point
<mdz> pitti, it's missing all 3 subsequent revs
<mdz> pitti, do I need to tell LP to update the merge proposal manually somehow?
<vila> james_w`: from the explanations file ?
<bdrung> cjwatson: ~7 new sync requests were acked
<vila> no
<pitti> mdz: no, it should notice by itself
<james_w`> vila, from logs/avscan
<pitti> mdz: *shrug*, I'll just merge locally and check the diff
<vila> james_w`: !
<mdz> I can't believe that https://code.launchpad.net/~mdz/apport/504340-kernel-threads doesn't offer a link to show (and download) a diff...
<cjwatson> bdrung: cutting it fine? :)
<pitti> mdz: it does, at the top of the displayed diff
<pitti> -> Download diff  [x] Show line numbers
<pitti> mdz: ^
<james_w`> vila, do you know what causes: AssertionError: repository.user_url 'bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gtk-vnc/natty-201102220618/' does not match URL from server response ('bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/gtk-vnc/natty/' + '') ?
<cjwatson> mdz: it's in the merge proposal, link text "Ready for review"
<pitti> mdz: anyway, looks fine now, thanks! Please go ahead and merge into trunk
<pitti> mdz: (updated MP)
<bdrung> cjwatson: yes. :)
<pitti> Keybuk: hello, how are you?
<mdz> pitti, cjwatson, I was pointing to the page for the branch itself
<cjwatson> bdrung: amazingly quick turnaround on bug 721995 ...
<ubottu> Launchpad bug 721995 in love (Ubuntu) "Please sync love 0.7.1-1 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/721995
<pitti> Keybuk: what was the reason again why we moved dbus-daemon from /usr into / ?
<pitti> mdz: ah
<mdz> LP knows it has a parent branch elsewhere in LP, so a diff seems like a natural thing to want, e.g. if someone from upstream comes by looking for it
<bdrung> cjwatson: i checked https://bugs.launchpad.net/~ubuntu-sponsors for remaining syncs ;)
<pitti> Keybuk: it's quite a large delta to Debian, keeps breaking stuff at every merge, and as it needs /usr/share/dbus-1/ anyway
<pitti> ... it won't work without /usr
<mdz> pitti, done
<Keybuk> pitti: hey, not too bad thanks, you?
<Keybuk> pitti: because Upstart depends on dbus?
<pitti> Keybuk: pretty good, thanks!
<Keybuk> I mean, you can make /sbin/init a symlink to /usr/sbin/init if you like ;-)
<Keybuk> but GOOD LUCK WITH THAT :p
<Keybuk> plus mountall depends on dbus, and mountall mounts /usr
<Keybuk> a better question is why Debian hasn't moved D-Bus to /
<Keybuk> since that's the recommended practice upstream
<pitti> Keybuk: mbiebl says that it won't work without /usr/share/dbus-1/interfaces/ anyway, so he kept it in /usr
<Keybuk> and would then match Ubuntu, Fedora, SuSE, etc.
<Keybuk> it works just fine
<Keybuk> D-Bus reparses that directory when it's available
<Keybuk> you just can't do activation until /usr is mounted
<ari-tczew> cjwatson: do you will do all syncs until 30 minutes?
<Keybuk> but then you likely don't need to for the things outside /usr
<vila> james_w`: sorry, got interrupted, no, never saw that one
<Keybuk> I've actually *shock* tested the NFS /usr case ;-)
<vila> james_w`: but user_url is supposed to gives user-readble URLs :-.
<james_w`> vila, it's cropped up a few times, seemingly after 2.3 on the client, or maybe after a change on LP
<pitti> Keybuk: ok, good to know; thanks for the heads-up!
<mbiebl> Keybuk: hi, what about /var/lib/dbus/machine-id?
<pitti> Keybuk: another question, would it be possible to commit the 5 upstart patches upstream? took some effort to port them even to a new microrelease
<Keybuk> pitti: which 5 upstart patches?
<Keybuk> have they been sent to upstart-devel ?
<Keybuk> mbiebl: we don't suppose NFS /var - I don't think anyone does
<pitti> Keybuk: in dbus, for upstart service activation
<Keybuk> suppose? support!
<mbiebl> but a separate /var you support?
<Keybuk> pitti: oh, there is a bug open and discussion happening on the dbus mailing list
<Keybuk> I've sent a few variants of those packages
<pitti> ah, cool
<Keybuk> mbiebl: yes, dbus is started on local-filesytems in ubuntu
<Keybuk> it's in / to support a networked /usr, networking in ubuntu needs NFS
<mbiebl> Keybuk: but upstart works just fine without a running dbus
<Keybuk> argh, patches not packages
<Keybuk> mbiebl: no, it works "mostly fine"
<mbiebl> what's broken besides unprivileged user access?
<bdrung> jamespage: you are working on the groovy sync? the clock ticks. ~ 20 mins till FF
<Keybuk> mbiebl: that is what's broken
<Keybuk> plus obviously receiving signals (plymouth uses them)
<Keybuk> etc.
<Keybuk> though I'm not sure whether colin did that via a direct connection or not, you'd have to ask him
<Keybuk> *shrug*
<Keybuk> sorry, I don't get the "this all works, can I change it and break it?" attitude
<mbiebl> hm, what?
<Keybuk> well, boot works in Ubuntu right now
<Keybuk> with dbus-daemon in /
<Keybuk> moving it to /usr seems to be "let's break things for the hell of it" :-)
<Keybuk> especially since Debian is afaik the only distro with dbus-daemon in /usr
<jamespage> bdrung: yep  -  sync needed a patch for ubuntu as well - zul reviewing now
<cjwatson> plymouth uses an ordinary connection to the system bu
<cjwatson> *bus
<Keybuk> cjwatson: that's what I thought
<pitti> Keybuk: I think Fedora also has NM in /, to support networked /usr better
<cjwatson> it might be worth changing that
<Keybuk> pitti: we did for a while
<cjwatson> but the direct-connection stuff looked kind of private to upstart IIRC
<Keybuk> but I put it back in /usr since networked /usr was mostly covered by /e/n/i
<Keybuk> the way our configuration stuff worked
<Keybuk> cjwatson: no, you did it right - direct-connection is supposed to be for things in upstart's tarball only
<mdz> pitti, my branch was --fixes lp:blah, will that propagate into trunk or do I need to do something to make sure the bug gets closed?
<cjwatson> oh good
<cjwatson> (I suppose I could have made it upstart-plymouth-bridge instead, but ...)
<pitti> mdz: it won't be propagated through merges unfortunately
<pitti> mdz: but the ubuntu task will get closed via debian/changelog once that hits the ubuntu branch and get uploaded
<Keybuk> pitti: the only reason for having NM in / was if you wanted to do an NFS /usr on WiFi
<Keybuk> oh, on WPA WiFi
<pitti> Keybuk: that sounds a little on the crazy side to me..
<cjwatson> ah, that's right, I made plymouth-upstart-bridge be 'start on started dbus'
<Keybuk> pitti: crazy wasn't the problem, it was the "so where do the keys come from, then?" that was the problem :)
 * cjwatson had a brief moment of self-doubt there :)
<Keybuk> cjwatson: rofl
<Keybuk> cjwatson: I never doubted you for a moment
<mbiebl> pitti: NM is still in /usr on F14
<mbiebl> unless they changed it in rawhid
<cjwatson> obviously my code is at all times perfect.  er, or something.
<ogra> oh, das Keybuk !
<ogra> good to see you around :)
<mbiebl> Keybuk: fwiw, I wasn't telling pitti to move dbus-daemon back to /usr in Ubuntu, I was just telling him why it was still on /usr in Debian
<mbiebl> Keybuk: so, if dbus-daemon is started after local-filesystems
<mbiebl> how do you communicate with plymouth before?
<mbiebl> e.g. fsck progress bar etc
<Keybuk> fsck progress bar is done by plymouth's own native communication
<Keybuk> the upstart->plymouth is done via dbus
<mbiebl> cjwatson: what does plymouth communicate with upstart then?
<cjwatson> job changes
<Keybuk> mbiebl: "apache started"
<mbiebl> why does plymouth need to know that?
<cjwatson> mbiebl: http://lists.freedesktop.org/archives/plymouth/2010-November/000464.html
<cjwatson> (and thread, spread over a few months of the archives)
<cjwatson> because otherwise even a non-"quiet" boot doesn't tell you anything about services starting
<cjwatson> upstart doesn't print anything on the console when a job starts
<cjwatson> this lets us show useful progress again
<mbiebl> ok, but all those services will start after remote_fs anyway in Debian
<cjwatson> it's not exactly identical to the output from init scripts, but it should make server people feel a bit more at home
<mbiebl> so it doesn't really make a gread difference if dbus-daemon is started after local_fs or remote_fs
<mbiebl> imho
<cjwatson> depends what you're trying to debug
<cjwatson> it might well be very useful to you to see that your server is hanging at boot in "Mounting remote filesystems"
<mbiebl> Keybuk: when did you last try starting dbus without /usr being available?
<mbiebl> does it install an inotify watch in / or how does it work?
<Keybuk> mbiebl: each time you attempt to activate an interface, if it hasn't got an interfaces list, it goes to walk that directory
<Keybuk> if the directory doesn't exist yet, the activation fails, but it'll try again next time
<Keybuk> if the directory exists, then I believe it does use an inotify watch rather than reload each time
<Keybuk> as to when
<Keybuk> probably 2 years ago
<Keybuk> when we made the change
<mdz> pitti, I'm seeing an intermittent test failure in report.py (readelf: Error: core: Failed to read file's magic number), ever seen that before?
<ari-tczew> 10 minutes requires, don't close :D
<pitti> mdz: I think I did, once in about 10 times; but I never took the time to track it down
<Daviey> doko_, around?  Could really do with some ld help
<Keybuk> mbiebl: doesn't systemd also use dbus? :)
<doko_> Daviey: what about?
<mdz> pitti, ok, I didn't think I broke that but just checking :-)
<mdz> pitti, what do you think is a good name for the package-independent bug pattern file? ANY.xml?
<jamespage> any chance somone can sponsor bug 661230 for FF (yeah I know) - zul was sponsoring but has gone offline with connection issues.
<ubottu> Launchpad bug 661230 in groovy (Ubuntu) "Sync groovy 1.7.4-1 (main) from Debian testing (main)" [Medium,In progress] https://launchpad.net/bugs/661230
<pitti> mdz: I think I'd just use patterns.xml and obsolete the per-package ones
<mbiebl> Keybuk: sure it does :-)
<mdz> pitti, if we eliminate the per-package ones, we can just use the URL from crashdb.conf verbatim
<mdz> instead of as a base
<pitti> *nod*
<mdz> pitti, is anyone other than Ubuntu using bugpatterns?
<pitti> mdz: I don't think so; we are pretty much the only disto using apport at all
<mvo> CA?
<kees> cjwatson: say... isc-dhcp doesn't mention apparmor in the merge changelog and half of the apparmor logic got dropped.
<cjwatson> :set ignorecase
<cjwatson>     - Add enforcing AppArmor profile for DHCP client and server.
<cjwatson>   * Drop preinst code to set AppArmor to complain mode on upgrades from very
<cjwatson>     old Ubuntu releases, predating the last LTS.
<kees> weird, I wonder how the symlink got lost
<mbiebl> Keybuk: fwiw, I didn't know about the plymouth<->upstart interaction via dbus
<cjwatson> if I missed something, sorry, and feel free to put it back :)
<kees> cjwatson: yup, I will. thanks!
<mbiebl> and before shuffling stuff around from /usr to / I need a good reason why it's necessary
<Keybuk> mbiebl: of course, we can hope that dbus-daemon goes away soon enough
<mbiebl> AF_DBUS ftw
<Keybuk> no, multicast AF_UNIX1
<Keybuk> s/1/!/
<Keybuk> http://alban.apinc.org/blog/2011/02/16/introducing-multicast-unix-sockets/
<mbiebl> yeah, I know about that : http://lists.freedesktop.org/archives/dbus/2010-September/013531.html
<vila> james_w`: sorry, got *massively* interrupted
<kees> cjwatson: actually, sorry, it's there (isc-dhcp-client.links), but dpkg seems to have ignored it. anyway, I'll track it down and fix it.
<Keybuk> *nods*
<vila> james_w`: so, regarding the wierd URLs, that only bell it ringing is 'fallouts from +branch handling', but that's rather ancient now so...
<pitti> good night everyone!
<vila> james_w`: .. pretty unlikely
<kees> cjwatson: ah! dh_link is missing from rules. easy fix
<vila> g'night pitti !
<cjwatson> kees: ah, righto, that would have been easy to miss
<cjwatson> silly non-dh(1) packages
<kees> hehe :)
<james_w`> vila, ok, we'll see if any appear again, and we can debug
<vila> james_w`: in other news: more packages flirting with > 400M and up to 700M, that's also something we want to monitor for robustness and also to drive memory optimizations on the bzr side
<vila> james_w`: yup
* cjwatson changed the topic of #ubuntu-devel to: Archive: feature freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper ->  maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots: ari-tczew
<james_w`> vila, ok, thanks for keeping an eye on that
<cdbs> skaet_: heh, your announcement refers to natty as lucid
<cdbs> skaet_: the announcement about the feature freeze
<cjwatson> heh, I didn't notice when moderating that ...
<vila> james_w`: thank to you, I appreciate your support
<Daviey> doko_, bug 724470
<ubottu> Launchpad bug 724470 in eucalyptus (Ubuntu) "apache2: symbol lookup error: /etc/eucalyptus/axis2/services/EucalyptusNC/libEucalyptusNC.so: undefined symbol: rampart_print_security_processed_results_set" [High,Confirmed] https://launchpad.net/bugs/724470
<cdbs> cjwatson: :o You moderate -announce?
<doko_> Daviey: did you apply the existing patch?
<Daviey> doko_, to axis2c?
<cjwatson> cdbs: -devel-announce, yes
<cdbs> hmm
<doko_> Daviey: which package does /usr/lib/axis2/services/EucalyptusNC/libEucalyptusNC.so belong to?
<Daviey> doko_, binary package eucalyptus-nc, source package eucalyptus
<doko_> Daviey: then fix eucalyptus ;-P
<Daviey> doko_, Easy to say :)
<doko_> it's not about ld, it's about searching the patch in the launchpad ...
<Daviey> doko_, I'm not quite sure why it's compiling seemingly ok, but not ld correctly
<proti> cjwatson: bug 723482, we answered your questions.
<ubottu> Launchpad bug 723482 in mountall (Ubuntu) "system hangs on boot after updates from 2011-02-22" [High,New] https://launchpad.net/bugs/723482
<Daviey> doko_, searching the patch?
<cjwatson> proti: yep, thanks, I'm going to have to set up a test environment, which is blocked on getting the server CDs working again, ...
<proti> Good luck with this one.
<cjwatson> (in progress)
<doko_> Daviey: ahh, there was a new upload ... well, it looks like object files are placed before libraries when linking a library. dpkg-shlibdeps should have given warnings about unresolved symbols
<proti> cjwatson: ok thanks. I you need testers, My machine is dead and 2 others at works.
<proti> If you need*
<cjwatson> thanks
<doko_> Daviey: gcc -shared generated/*.o server-marshal.o handlers.o  -L/usr/lib/axis2/lib -lcap -lz -lrt -lpthread -lneethi -lmod_rampart -lm -laxutil -laxis2_parser -lguththila -laxis2_http_sender -laxis2_http_receiver -laxis2_http_common -laxis2_engine -laxis2_axiom -L/usr/lib/axis2/modules/rampart -L/usr/lib/axis2/lib   ../util/misc.o ../util/euca_auth.o ./gl-client-marshal-adb.o -o libEucalyptusGL.so -lssl -lcrypto
<doko_> Daviey: that's not the only one
<Daviey> doko_, i tried http://pb.daviey.com/U2O6/raw/
<Daviey> ( see i have dupes)
<doko_> dupes don't matter
<doko_> in this order
<Daviey> yeah, but that didn't work
<doko_> Daviey: of course it doesn't work
<Daviey> doko_, ok, let me try your entry
<doko_> there's no lib after the .c file which can used to resolve *any* symbol
<Daviey> ahhhh!
<Daviey> doko_, that makes sense!
<doko_> Daviey: http://wiki.debian.org/ToolChain/DSOLinking
<Daviey> doko_, perfect!  thanks
<doko_> Daviey: again, this is not the only lib ...
<skaet_> cbs, drat - missed one.
<skaet_> cdbs,  thanks for flagging.  yup s/lucid/natty/.  (sigh,  thought I caught them all :P )
<cdbs> skaet_: well, you missed more than one
<Daviey> doko_, yeah, i assume you mean the other libs with a build.sh file?
<cdbs> skaet_: looks like you ran s/lucid/natty but not s/Lucid/natty
<cdbs> ubuntu-bug announcement :D
<cdbs> ahh, nautilus needs a rebuild
<doko_> Daviey: I just pasted one line from the build logs, search for '-shared'
 * cdbs confirms nautilus' fate
<skaet_> cdbs,  yup and did a manual scan too...   /me shakes head and figures its time for lunch.
<Daviey> doko_, Okay, great - how did you identify the other libs that need -l'ing?  I got my list from running ldd on the lucid binary, is that the best way?
<doko_> <doko_> Daviey: I just pasted one line from the build logs, search for '-shared'
<Daviey> doko_, ok, thanks
<kklimonda> kirkland: hmm.. I have a really interesting problem, I've used ecryptfs-migrate-home to encrypt my home directory, but I don't have the $HOME/.ecryptfs/wrapped-passphrase which I should probably backup. I can still login, and all my data is fine.
<mdeslaur> barry: does this make sense: bug #724494
<ubottu> Launchpad bug 724494 in python-launchpadlib (Ubuntu) "[natty] python-launchpadlib needs Depends on python-keyring" [Undecided,New] https://launchpad.net/bugs/724494
<mdeslaur> barry: can I just add the depends an upload it?
<barry> mdeslaur: yep.  i was actually trying to test that fix in my ppa, but i'm certain it will fix the problem
<barry> mdeslaur: thanks!
<mdeslaur> barry: np!
<barry> mdeslaur: i'm actually having more problems getting python-keyring built for maverick so leonardr can test it ;)  not your problem tho!
<mdeslaur> barry: what's "maverick"? :)
<barry> mdeslaur: exactly :)
<mdeslaur> barry: why isn't it building for maverick?
<mdeslaur> barry: (now you've got me curious :) )
<ari-tczew> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | 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> mdeslaur: when i build it in my mav schroot it keeps wanting to pull in sysvinit as a dependency.  but obviously that's not in maverick
<barry> mdeslaur: i probably won't matter for natty, but in my ppa test i added Depends: python-keyring (>= 0.5.1)
<mdeslaur> barry: that's exactly what I put
<barry> mdeslaur: beauty.  thanks
<mdeslaur> barry: hmm...that sounds like a sbuild issue that got resolved a while ago (sysvinit)
<barry> mdeslaur: maybe i should blow away my mav chroot and rebuild it.  i do keep it up to date
<till_> hello, got a quick debhelper question
<till_> anyone about?
<ScottK> !ask | till_
<ubottu> till_: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<till_> aight
<till_> so, i have a piece of software, i run ./configure && make and then usually copy a single file after 'make' to finalize the install. i debianized the configure and make part, trying to figure out how to tell my package to 'cp' to the designated path/location.
<ScottK> till_: man dh_install probably has your answer.
<bryce_> ev, any chance you're about?
<bryce_> ev, ok well if/when you're back to within working hours, here's the skinny
<bryce_> ev, for the past month or so we've been fielding some X crash issues that people using livecd have been reporting to us.  The crashes are caused by an out of memory situation.  The X crashes themselves are just trivial null pointer derefs and easy to fix but the core issue is the OOM situation
<bryce_> ev, unfortunately pinning that down is proving to be much more challenging.  However, we *suspect* it is an X client app rather than X itself which is leaking memory massively
<bryce_> ev, best guess at this point is maybe it's the installer, since people see the issue only while in livecd environment and usually (always?) while the installer is in use
<bryce_> ev, but we're unsure how we can debug this further, and hope you can give us some tips on how to debug ubiquity or other bits that you think could possibly be involved
<bryce_> ev, for reference, the first reported bug in the sequence was bug #705078, from mid-Jan.  Suggesting that perhaps the issue arose around the timeframe of ubiquity 2.5.6
<ubottu> Launchpad bug 705078 in xf86-video-intel "Xorg crashed with SIGSEGV in pixman_image_set_has_client_clip()" [High,Confirmed] https://launchpad.net/bugs/705078
<till_> ScottK: would i override the dh_install target in my rules?
<ScottK> till_: That or make a {packagename}.install file.
<till_> ok
<hallyn> anyone else having trouble with apt-cacher-ng in natty?
<hallyn> it keeps hanging for me, both with libvirt guests and schroots
<ScottK> hallyn: Caching any Debian releases?
<hallyn> don't think so
<till_> ScottK: any idea how long an initial release of a package takes to build on launchpad?
<ScottK> It varies considerably.  For PPAs, you can ask in #launchpad for help.
<till_> ScottK: ok, will do
<hallyn> ScottK: then again, i did have trouble with it before, but now i have just as much trouble without apt-cacher
<hallyn> is anyone else having trouble with us.archive.ubuntu.com?
<ScottK> I asked about Debian because they recently added sha-512 to their release files and lots of packages didn't handle it well.  It's being/been reverted.
<hallyn> ScottK: well i left the default .conf file, but /var/cache/apt-cacher-ng doesn't have any debian.org subdirs
<ScottK> OK. So that's not it.
<hallyn> Thu Feb 24 14:15:18 2011|/var/cache/apt-cacher-ng/uburep/dists/natty-updates/Release
<hallyn> Thu Feb 24 14:16:40 2011|Warning, disconnected during package download
<ion> Iâve built the apt-cacher-ng package from natty on my karmic box and it segfaults every once in a while. Havenât got around to investigating it, since iâll upgrade the box anyway soon and that may fix the problem.
<hallyn> i've turned it off and pointed everything at us.archive.ubuntu.com directly.  still hanging
<janimo> ScottK, retried the build myself now
<ScottK> Just imagine i replied to that on this channel and not #ubuntu-arm.
<ScottK> lamont: Running 2.8.1-1 on my test server.  Seems all good here.
<Fjodor> Hi all. https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/650539?comments=all is reported as fixed, but it isn't for me. Does anyone else see that, and how and what can I do to diagnose?
<ubottu> Ubuntu bug 650539 in xorg-server (Ubuntu Maverick) "SRU: Launching a Qt app crashes X when using Xinerama" [High,Fix released]
<barry> mdeslaur: nope, rebuilding my maverick chroots did not help :(
<mdeslaur> barry: got a build log somewhere I can see?
<barry> mdeslaur: http://pastebin.ubuntu.com/571920/
<mdeslaur> barry: how are you calling sbuild, and are you running natty?
<mdeslaur> barry: https://bugs.launchpad.net/ubuntu/+source/sbuild/+bug/684931
<ubottu> Ubuntu bug 684931 in sbuild (Ubuntu) "cannot build stable release packages due to ESSENTIAL dep phase" [Critical,Fix released]
<barry> mdeslaur: that's the bug that's hitting me.  my build host is maverick.  i've already installed a locally backported sbuild to pick up the (nice!) feature of keeping the session alive when the build fails.  i guess i'll build natty's current sbuild for maverick (in my ppa :) for my maverick build machine
<barry> or well, i could just remove sysvinit locally
<mdeslaur> barry: cool
<barry> mdeslaur: thanks for the bugclue :)
<bryce_> kirkland, you around today?
<bryce_> are any archive admins around?  I've got a package stuck in NEW I think
<ScottK> What package?
<bryce_> ScottK, wayland
<ScottK> Yes.  It's in binary New.
<ScottK> https://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=wayland
<bryce_> ScottK, ok, what needs to happen to get it moved along?
<ScottK> It'll still get in since it was uploaded before FF.
<ScottK> It needs an archive admin with more time than I have right now to review and accept it.
<bryce_> I see
<ScottK> Also, it's generally preferable to wait until it's built on all archs (but not required).
<bryce_> the only arch remaining is powerpc, and it's been nearly 24 hrs
<ScottK> It's way behind.  It's mostly needing an archive admin with time.  Not sure who's day this is.  There's a list somewhere.
<micahg> bryce_: https://wiki.ubuntu.com/ArchiveAdministration#Archive days
 * StevenK quietly rescores wayland on powerpc
<bryce_> ScottK, would it help if I just removed powerpc as an arch and reuploaded?
<ScottK> bryce_: No.  I'd look up who's day it is and ask them to review it.
<bryce_> hi StevenK, thanks
<micahg> bryce_: with the rescore, it'll probably be ready by morning and jdstrand is the AA on duty tomorrow
<TheMuso> lol
<StevenK> It amused me that the rescore took its estimated start time of 23 hours and changed to 23 minutes
<jdstrand> bryce_: what do you need?
<bryce_> jdstrand, trying to get wayland in the archive
<seb128> bdrung_, what was that nautilus upload?
<bryce_> jdstrand, so far I've spoken about it to slangasek, riddell, dustin kirkland, stevek just rescored it moments ago, and now I have your ear :-)
<jdstrand> bryce_: unlike the others, I will help you ;)
<jdstrand> oh, snap!
<bryce_> heh, all have been helpful, I think I'm working on building a straight flush.  Just need to get cjwatson ;-)
<jdstrand> :)
<micahg> TGIAF
<bryce_> jdstrand, the source package has been reviewed by riddell and kirkland and approved by dustin kirkland, but I gather the binaries need reviewed/approved separately?
<StevenK> Yes, but binary NEW is much easier
<bryce_> jdstrand, amd64, i386, and armel packages have built, ppc is still TBD, but wayland only works on amd64 and i386 so lack of ppc is pretty irrelevant I figure
<jdstrand> bryce_: yes. I am doing it. Riddell and kirkland are the real heroes here
<bryce_> ok cool
<bryce_> if it helps, I've tested the package (via ppa) on 4 different boxes with 2 gfx card architectures
<bryce_> I have one more box which has never had wayland or its deps installed, primed to test a clean install from the archive
<RAOF> Gak!  Is dhclient broken?
<kees> RAOF: yes, fixing
<kees> https://bugs.launchpad.net/bugs/724556
<ubottu> Ubuntu bug 724556 in isc-dhcp (Ubuntu) "[Natty] isc-dhcp update breaks network connection" [Undecided,New]
<RAOF> Ta.
<jdstrand> bryce_: accepted. ppc will float in when it does. I even filed the first bug! :)
<bryce_> jdstrand, yay thanks!
<bryce_> heh, man pages
<bryce_> jdstrand, ok thanks for the lintian, I forgot to doublecheck that
<jdstrand> bryce_: well, yeah, that's the noise. there was a library one in there too though
<jdstrand> bryce_: anyhoo, I'll leave that in your able hands :)
<bryce_> jdstrand, thanks on it
<jdstrand> sure, np
<bdrung_> seb128: sorry for not checking the vcs field
<seb128> bdrung_, I've fixed the vcs now
<bdrung_> thanks
<seb128> bdrung_, but please before uploading desktop packages next time check with #ubuntu-desktop, for one thing there is no recent gio upload so the rebuild doesn't make sense, and you screwed the vcs
<bdrung_> gvfs instead of gio?
<seb128> bdrung_, no, not since week or the week before
<seb128> since this week or...
<chrisccoulson_> is this for nautilus?
<seb128> yes
<chrisccoulson_> i did suggest in #ubuntu-desktop that we should try and figure out what actually broke. did that not happen?
<seb128> no, people did a random no change rebuild update without considering the vcs or the change in there
<chrisccoulson_> hmmmm, that's not very good :(
<seb128> not it's not, well I rebased and did a new upload now, it still doesn't explain what was broken and why
<chrisccoulson_> yeah, we should figure that out, especially if it's just a rebuild which fixes it...
<seb128> chrisccoulson_, do you think it could be libdbusmenu?
<chrisccoulson_> hmmm, i'm not sure. i don't think we've made any ABI breaking changes there
<seb128> chrisccoulson_, well I noticed the bug while testing rodrigo's patch today and I don't think I upgrade this box this week out of getting the new libdbusmenu to do some valgrinding
<chrisccoulson_> but doing a random rebuild definitely isn't a very scientific way of approaching it :(
<seb128> upgraded
<chrisccoulson_> i guess it could be that. i can have a look later and try and figure out what broke
<seb128> so I wouldn't be surprised if it had something to do with it
<seb128> chrisccoulson_, if you want to I will not stop you ;-)
<RoAkSoAx> .wub 19
<cnd> Riddell, where are we at with the qt package?
<Riddell> cnd: just about to upload it now
<cnd> Riddell, cool :)
<Riddell> sorry for the delay, the builder I was using to test ran out of disk space and I had to learn about eleastic cloud volume things
<cnd> hah
<cnd> np
<cnd> thanks a bunch!
<Keybuk> kees: given that the kernel community seem unhappy with your plan to make debugfs root-only, are you going to revert the mountall patch?
<kees> Keybuk: nope
<kees> Keybuk: they're wrong
<kees> Keybuk: all the interfaces in there are designed to be used by the root user.
<Keybuk> /sys/kernel/debug/usb/devices isn't
<Keybuk> that's intended for all users
<kees> then it should move
#ubuntu-devel 2011-02-25
<kees> upstream has stated that debugfs "should not be used on production systems".
<kees> there are things being used, though, so we should move towards getting rid of it.
<Keybuk> no, upstream has stated that it should be used on production systems
<kees> they have said both things.
<Keybuk> http://article.gmane.org/gmane.linux.kernel/1104038
<kees> what they said was "it should not be used on production systems, except for ftrace, which should move out of debugfs"
<kees> I asked what the "good reasons" where, and it boiled down only to ftrace
<Keybuk> well, ftrace and that usb/devices file
<kees> both should move :)
<Keybuk> ftrace is the hugely important interface I'm worried about
<kees> ftrace is root-only, so, again, it doesn't matter
<Keybuk> things like blktrace too
<kees> as root :)
<Keybuk> <g>
<kees> anyway, I was convinced to not _remove_ the mount. ;)
<Keybuk> if only ubuntu didn't let users login as root ;-)
<Keybuk> kees: were you? your change to mountall suggests you want to remove it still
<kees> I do still want to remove it; but due to ftrace and drm debugging, I left it, available to root only, for now.
<Keybuk> you realise that the buggy things will just end up back in /proc and /sys again?
<Keybuk> or we'll end up with a thousand kernel filesystems again
<kees> Keybuk: debugfs remains a dumping ground. at least there are rules for /proc and /sys
<kees> Keybuk: if it was totally a theoretical danger, I would have left it as it was. but now with multiple privilege escalation vulnerabilities coming out of there, I want nothing to do with that filesystem. it is dangerous in the general case.
<Keybuk> there were just as many bugs in /sys with files that were world-writable, no?
<kees> none that were so drastically horrible, though
<Keybuk> what was the drastically horrible case in debugfs?
<kees> http://jon.oberheide.org/files/american-sign-language.c
<Keybuk> that's exactly the kind of interface that will simply get moved to /sys though
<Keybuk> with probably the same bugs it has in debugfs
<kees> well, /sys has rules, and debugfs doesn't, so I suspect people will think twice before putting crap into /sys
 * Keybuk hands you a F in history
<Keybuk> debugfs was created because people *were* putting crap into /sys without thinking
<kees> right, and now they can continue doing that without endangering people since it'll be root-only
<Keybuk> on Ubuntu only ;-)
<Keybuk> so are you going to manually check all incoming software
<Keybuk> including things like vmware? :p
<kees> I already produced a list of all the supported software (in main) that uses debugfs.
<kees> if you have have special case, adjust the mounted-debugfs.conf file.
<Keybuk> well, vmware was the one I was thinking of
<Keybuk> I don't know how they use it this week
<Keybuk> it took them long enough to stop using the older interfaces and update to that
<Keybuk> but then you probably don't care on the basis that vmware's kernel modules are probably buggy
<kees> people should be using kvm.
<lifeless> s/probably//
<kees> also that
<Keybuk> kees: hehe, the first stumbling block is that the kvm ubuntu documentation appears to have been raped by the server team
<Keybuk> "you don't want this, you want lib-ubuntu-virt-builder!"
<cnd> Riddell, still around?
<cnd> the qt package ftbfs for arm
<maco> cnd: it's 3am for him
<cnd> ahh
<cnd> maco, thanks
<cnd> I'll send him an email then
<blahsphemer> I'd like to discuss a gsoc project. Is anyone available?
<lamont> ScottK: nice
<didrocks> good morning
<pitti> Good morning
 * pitti fixes python-aptdaemon-gtk component to fix CD builds
<Daviey> persia, I noticed you assigned yourself bug #231060... How are you getting on, and do you think it's a bug we can target for a natty milestone?
<ubottu> Launchpad bug 231060 in libvirt (Ubuntu) "packages dnsmasq and libvirt-bin conflict with each other" [Low,In progress] https://launchpad.net/bugs/231060
<pitti> ev: is the pygi port of usb-creator going to make it? or should we just postpone that to o?
<ev> pitti: going to have to postpone.  I got caught up in the installer partitioner redesign in the end.
<pitti> ev: ack
<mok0_> I need a recommendation for  a good XML library for C (C++)? It doesn't matter if it's SAX or DOM, it just needs to be easy to use. I just need it to parse a rather small data file
<ev> expat?
<mok0_> ev:  I've looked at expat, but it's not exactly easy to use :-)
<ev> ah, fair enough
<mok0_> ev: I was hoping for "Everyone uses ... and it's great" :-)
<ev> have you tried libxml2?
<ev> I don't recall it being particularly difficult to use
<GunnarHj> ScottK: Hi Scott, can we talk about bug 719815?
<ubottu> Launchpad bug 719815 in maverick-backports "Please backport gdm and language-selector to Lucid and Maverick" [Undecided,Confirmed] https://launchpad.net/bugs/719815
<GunnarHj> dpm: Hi David, are you there?
<dpm> hey GunnarHj
<GunnarHj> dpm: Wondering about bug 710151 - guess that somebody ought to fix it before Natty is released.
<GunnarHj> dpm: It's apparently /usr/share/language-selector/data/pkg_depends that needs to be altered. Do you know which changes are required exactly?
<ubottu> Launchpad bug 710151 in language-selector (Ubuntu) "Language selector reminds user about missing language support for OpenOffice.org instead of LibreOffice" [Undecided,Confirmed] https://launchpad.net/bugs/710151
<dpm> GunnarHj, no, sorry, I don't know, perhaps pitti or someone else with more packaging knowledge can answer best? ^^
<pitti> right, that needs to be update
<pitti> d
<pitti> but I'm not sure what will happen with all the -hyphenation and -thesaurus packages, as they haven't been renamed yet
<pitti> dpm, GunnarHj: (asking Sweetshark in #u-desktop)
<dpm> thanks pitti
<GunnarHj> dpm, pitti: Tried to reach doko_ yesterday, since he is a member of the LibreOffice Packaging team (didn't succeed).
<GunnarHj> dpm, pitti: switching to #ubuntu-desktop
<dpm> GunnarHj, Sweetshark is the new office stack maintainer
<GunnarHj> dpm: Aha, didn't know. Thanks!
<beuno> ev, ping. I've been trying to do a fresh install of natty on my maverick since the 21st, but I can't get neither the alternate nor the live-cd to install. Are there any known bugs?
<pitti> tseliot: hey, how are you?
<tseliot> hi pitti, I'm fine, thanks, you?
<fta> mvo, hi, http://paste.ubuntu.com/572181/  known?
<mvo> fta: no, could you run in --debug --dry-run mode?
<mvo> fta: and mail me the deb where it fails?
<fta> mvo, brltty: http://paste.ubuntu.com/572183/
<mvo> fta: thanks, could you plesase file a bug? I think its some stupid static buffer being too small
 * mvo has some vague memory about this particular code path
<ev> beuno: amd64?
<beuno> ev, nope, i386. I tried running ubiquity in debug mode, and there isn't anything intersting in the logs either
<ev> beuno: is it crashing or hanging?
<beuno> the alternate cd (installing from pendrive) says it can't find the cd
<beuno> ev, hanging
<beuno> and the live cd hangs after the screen that checks for power, internet, etc
<ev> oohhh, perhaps it's the bug in partman-auto
<beuno> just the installer hangs
<ev> do you have unpartitioned space on one of your disks?
<chrisccoulson> huh? http://launchpadlibrarian.net/65125588/buildlog_ubuntu-natty-amd64.firefox_4.0~b12%2Bbuild1%2Bnobinonly-0ubuntu2_CHROOTWAIT.txt.gz
<beuno> ev, ah, probably, yes. I nuked the partitions at some point trying to get things moving forward
<beuno> the last I can see in debug logs are about partitions
<chrisccoulson> ^^ lamont - any idea what happened there?
<ev> beuno: yeah, entirely my fault (bug 722198).  The next daily{,-live} CD should have the fix.
<ubottu> Launchpad bug 722198 in partman-auto (Ubuntu Natty) "installation hangs on 15reuse w/ blank disk" [Critical,Fix released] https://launchpad.net/bugs/722198
<lamont> chrisccoulson: I don't suppos you want to give me the (acutally useful for looking at things) URL for the build record???
<chrisccoulson> lamont, https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu2/+buildjob/2286209
<fta> mvo, bug 724994
<ubottu> Launchpad bug 724994 in unattended-upgrades (Ubuntu) "SystemError: E:Unparsable control file" [Undecided,New] https://launchpad.net/bugs/724994
<lamont> chrisccoulson: uh.. yeah, I have an idea, and I'm going to go cry for a bit in a little while.  meantime, I'll get it fixed.  thanks
<chrisccoulson> lamont, excellent, thanks :)
<ev> beuno: if you'd rather not wait, hit Try Ubuntu on the live CD, then patch this in and run the installer again: http://paste.ubuntu.com/572185/
<beuno> ev, I'll give that a try, at least to help confirm it. I'm also up for doing anything that will help debug further or whatever
<ev> thanks, let me know if that doesn't do the trick then
 * beuno tests
<mvo> fta: I commented in the bug, a tiny test app seems to work for me
<beuno> ev, still seems to hang for me, in the debug log the last I see is:  <-- GET partman-auto/disk, followed by: --> 1
<beuno> (compiz crashed, but I don't think that would change anything)
<ev> beuno: can you stick a set -x towards the top of /lib/partman/automatically_partition/15reuse/choices and pastebin /var/log/syslog after another run through?  You might want to check to make sure the parted_server process isn't running before you start ubiquity.
<beuno> ev, sure
<ev> thanks
<cnd> Riddell, hey, just saw your email
<cnd> ARM has doubles
<cnd> otherwise X wouldn't work at all
<cnd> the issue is only that qt's qreal is typedef'd as a float on ARM
<cnd> so the size of qreal != size of double on ARM
<cnd> if you typecast as you wrote in the email, it will actually runtime break
<Riddell> cnd: but if you use a double there then further uses which expect a qreal will break no?
<Riddell> e.g. qreal value = (*values++ - tdi.xivPosX.min) / (tdi.xivPosX.max - tdi.xivPosX.min)
<cnd> Riddell, in that line, *values will be a double
<cnd> and the end result will be a double casted into the float qreal
<cnd> the conversion will happen automatically at assignment time
<cnd> however, if you typecast values to qreal *(i.e. float *)
<cnd> then values++ will advance the pointer by 4 bytes instead of 8
<beuno> ev, here's the closest I can do to pastebin: http://plixi.com/p/79872527
<ari-tczew> tseliot: beer for new nvidia drivers!
<tseliot> :)
<Riddell> cnd: ok you convinced me
<cnd> Riddell, I'm crossing my fingers too
<cnd> I wish I had an arm machine to test :)
<cnd> we can probably ask a mobile team dev to test it out
<cnd> to make sure
<ev> beuno: does `sudo parted_devices` work or does it output an error?
<Riddell> cnd: how would you test?
<cnd> Riddell, the easiest would probably be to connect an apple magic trackpad
<cnd> and then run one of the qt touch examples
<cnd> though, some of the arm dev kits now have multitouch screens I believe
<cnd> so they should work too
<cnd> barry! just the person I need :)
<cnd> (sorry to pounce :)
<janimo> cnd, there is an arm machine in the data center, kakadu.canonical.com if you want to test things. You may need an account from IS
<cnd> janimo, I'd need someone's finger too :)
<cnd> Riddell, actually, now that I think of it
<janimo> ah you mean test beyonf simply building it
<cnd> I can emulate a touch device
<cnd> so if I could get remote access to an ARM machine I could test it
<Riddell> cnd: ScottK can probably give you access
<cnd> Riddell, ok, are we going to test before we push?
<cnd> or vice versa?
<cnd> I'm pretty confident it will work as I described
<cnd> it's just to verify really
<Riddell> cnd: well that involves building which takes days, I think we should just upload then test once it's in the archive
<cnd> Riddell, sounds good
<cnd> it won't break anything other than the qt touch examples
<cnd> which won't work anyways without the patch :)
<janimo> cnd, I think having it build is a good first step
<janimo> if it has bug later the arm team will help look into them
<cnd> janimo, ok, thanks!
<janimo> it's not as if it is a regression so noone will be roveolted if it does not work perfectly
<doko__> smoser: about bug #634487: "Any other tasks can be closed as 'invalid' or anything" ?
<ubottu> Launchpad bug 634487 in linux (Ubuntu Natty) "t1.micro instance hangs when installing java" [High,Confirmed] https://launchpad.net/bugs/634487
<smoser> doko, well, it is clearly a kernel bug.
<doko> ok
<smoser> so, you could make the java tasks invalid. the only reason i didnt' do that was because that seems like it might reduce the find-ability
<smoser> you have thoughts on that ?
<doko> mvo: ^^^
<smoser> i say clearly a kernel bug because obviously no user space process should be able to wreak such havoc
<beuno> ev, it works, it outputs the hd and the usb drive
<ev> beuno: I don't suppose there are any exceptions in /var/log/partman.log?
 * beuno looks
<doko> smoser: thanks!
<beuno> ev, nope, it looks pretty normal
<ev> rubbish :-/
<ev> beuno: can you rsync/usb disk the logs off of there and attach them to a new bug report?
<ev>  /var/log/installer/debug, /var/log/syslog, and /var/log/partman
<beuno> ev, sure, I'll do it now
<ev> thanks
<smoser> mvo, can you mark the linux-ec2 task as invalid on natty and maverick please ? for some reason it doesn't do anything when i do it.
<tgall_foo> doko,   I'm working on a very minimal system image for arm systems, from dpkg -r --no-act it would appear that for python the only dep is lsb-release    and python-minimal just reports that it's an essential pkg but nothing deps on it .. does that sound right ?
<fta> mvo, commented back
<ari-tczew> pitti: you might be interested in looking on bug 721399
<ubottu> Launchpad bug 721399 in hal (Ubuntu) "FTBFS in natty: fatal error: linux/videodev.h: No such file or directory" [High,Triaged] https://launchpad.net/bugs/721399
<pitti> ari-tczew: I already fixed that in upstream git and in Debian, it's pending upload; I'll update the bug
<mvo> smoser: trying it now, LP is not in a good mood today
<ari-tczew> pitti: ok thanks
<doko> tgall_foo: sorry, asac can't do without bitching
<mvo> smoser: sorry, I keep getting oopses, timeouts now
<doko> tgall_foo: for that you'll have to rewrite lsb_release in something else than python
<tgall_foo> doko, understandable
<ari-tczew> pitti: did you use BlackZ's patch?
<tgall_foo> doko, in the grand scheme for a minimal system is lsb-release really necessary ?
<beuno> ev, hm, I didn't create storage space on the usb installer and it's not mounting other usb drives (and also, no network!). I'll have to re-create the installer with some storage and go through it again. Will take a bit longer  :)
<pitti> ari-tczew: no, I fixed it 4 days before already
<pitti> ari-tczew: http://cgit.freedesktop.org/hal/commit/?id=8f624253f0135ca77a893ad4e8168f51ef90d4da
<ari-tczew> pitti: okok
<asac> doko: thanks!
<asac> :-P
<ari-tczew> pitti: nice
<ev> beuno: okay
 * pitti uploads a debian svn snapshot then to get this off the radar
<doko> tgall_foo: I don't know which scripts depend on it, maybe just search for lsb_release?
<tgall_foo> doko, ok thanks!
<mvo> thanks for the update fta!
<ari-tczew> doko: how do you checking which library is missing? e.g. undefined reference to 'fs_element_added_notifier_add'
<doko> ari fgrep -r 'fs_element_added_notifier_add' /usr/include, and then dpkg -S ?
<soreau> I downloaded a maverick love image a couple days ago but when I try to install it, after clicking the forward button the installer just sits there with busy cursor. Is this expected behavior?
<soreau> er..
<fta> ari-tczew, or google :) http://farsight.freedesktop.org/apidoc/farsight2/FsElementAddedNotifier.html
<soreau> I downloaded a natty live image a couple days ago but when I try to install it, after clicking the forward button the installer just sits there with busy cursor. Is this expected behavior?
<ari-tczew> fta: google failed :9
<ari-tczew> :(
<fta> really? wfm
<ev> soreau: yes - the desktop CDs have a bug whereby the installer hangs when there's unpartitioned space on any of the disks.
<ev> Fixed CDs will be generated once the live filesystems can be rebuilt.
<soreau> ev: ok thank you. Is there any way to install it without this fix?
<ev> soreau: you can try patching this in after quitting the installer and killing parted_server: http://paste.ubuntu.com/572185/
<soreau> ev: thanks again
<ev> sure thing
<lamont> chrisccoulson: given back
<chrisccoulson> lamont, excellent, thanks!
<lamont> that is, I gave back all the afflicted natty/amd64 packages
 * pitti scratches his head about the weird hal FTBFS on the buildds
<pitti> lamont: would you know any buildd specific issue which could cause a failure like
<pitti> chmod -x /build/buildd/hal-0.5.14/debian/tmp//usr/lib/hal/scripts/hal-functions
<pitti> chmod: /build/buildd/hal-0.5.14/debian/tmp//usr/lib/hal/scripts/hal-functions: new permissions are rw-r-xr-x, not rw-r--r--
<pitti> make: *** [install/hal] Error 1
<lamont> nice.
<lamont> whcih build is that?
<pitti> http://launchpadlibrarian.net/65129778/buildlog_ubuntu-natty-i386.hal_0.5.14-5%2Bsvn1_FAILEDTOBUILD.txt.gz
<pitti> (other arches fail as well)
<pitti> not locally, though
<lamont> ah, cool.  I'm going to let you keep scratching... because I don't understand it at all, unless fakeroot faceplanted
<lamont> (the only things I'm interested in right now are build failures on yellow.)
<pitti> lamont: this line was added in 2007, nothing that changed recently
<pitti> lamont: ok, thanks
<pitti> it did build on armel, though
<pitti> lamont: another upload just failed with "dpkg-deb: control directory has bad permissions 700 (must be >=0755 and <=0775)"
<pitti> why do builds suddenly start failing on permission issues..
<lamont> I wonder if something is causing umask issues again...
<pitti> Daviey: actually it's eucalyptus b-deps libgwt-user-java; and gwk needs swt-gtk
<pitti> chrisccoulson: ^
<chrisccoulson> pitti - yeah. there's no runtime dependency either, which is a little suspicious
<pitti> so actually there's another alternative to remove swt-gtk from gwt
<pitti> chrisccoulson: eucalyptus-java-common binary depends on libgwt-dev-java
<chrisccoulson> pitti - libgwt-dev-java doesn't have a runtime dependency on swt-gtk though does it?
<pitti> oh, right
<Daviey> pitti / chrisccoulson: libgwt-user-java is already heavily modified, and feature restricted to build without a bazillion depends... I suspect it's going to be a world of pain :)
<Daviey> Has a bug been raised yet?
<pitti> Daviey: by the sound of it, euca could actually need gwt, right?
<pitti> Daviey: i. e. do you think it'd be more promising to build euca without gwt, or gwt without swt-gtk?
<Daviey> pitti, well the web ui is generated via part of libgwt
<pitti> ok, then we should focus on the latter
<Daviey> It's Google Web Toolkit btw...not GWT as in Java GWT.
<Daviey> pitti, but yes, the later makes more sense IMO... I'm just fearful of how hard it's going to be.  As it was, we didn't suck in a new upstream version of gwt because it seemed like we had to patch out more than 50% of the upstream code to build it.
<proti> bug 586786 is really nasty if one wants to use grub with newer kernels.
<ubottu> Launchpad bug 586786 in jetty (Ubuntu) "Committed before 404 null" [Undecided,New] https://launchpad.net/bugs/586786
<proti> Oups
<proti> bug 586756
<ubottu> Launchpad bug 586756 in grub (Ubuntu) "update-grub ignores pvops kernels on Xen domU" [Undecided,New] https://launchpad.net/bugs/586756
<proti> It cause the update-grub to ignore every kernel having CONFIG_XEN_PRIVILEGED_GUEST=y for normal boot.
<proti> Every kernel since 2.6.37-9 for amd64.
<doko> seb128, didrocks, pitti: are any more gnome updates planned? if yes, when (asking for an archive rebuild)
<didrocks> doko: for unity/compiz, nothing more until Monday, I think that kenvandine has still some indicators to update
<ari-tczew> tseliot: wow, 108MB change file in new nvidia driver!
<tseliot> ari-tczew: ??
<doko> didrocks: no, I mean at or around an alpha/beta time, and not before Mar 9
<ari-tczew> tseliot: diff from 260.19.29-0ubuntu1 to 270.29-0ubuntu1 (108.8 MiB)
<ari-tczew> tseliot: looks lige gigantic upgrade ;-)
<didrocks> doko: for GNOME itself, we are staying with the 2.32 stack
<tseliot> ari-tczew: this diff? http://launchpadlibrarian.net/65129241/nvidia-graphics-drivers_270.29-0ubuntu1_270.29-0ubuntu2.diff.gz
<didrocks> so no big changes there
<ari-tczew> tseliot: no, one previous
<didrocks> doko: then, we have weekly dx update on Thursday (apart in freeze time) for unity, indicatorsâ¦
<tseliot> ari-tczew: aah, the new upstream release, yes
<doko> didrocks: and no gnome updates?
<didrocks> doko: nothing apart from a . release and cherry-picking some patches from newer version AFAIK
<zyga> how can I chroot into something crated with pbuilder-dist
 * zyga discovered pbuilder login
<ari-tczew> pitti: shouldn't be hal uploaded *5~ubuntu1 or something?
<chrisccoulson> lamont, https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu2/+buildjob/2286209 failed again :(
<chrisccoulson> dpkg-deb: control directory has bad permissions 700 (must be >=0755 and <=0775)
<lamont> yeah - I'm guessing something changed in natty today maybe?
<lamont> nothing changed on the server that should affect that
<chrisccoulson> i'm not too sure. perhaps pitti might know, but i think he's finished for the week
<seb128> doko, we will have some updates but they don't plan a new tarball rounds on the serie we are using
<kenvandine> chrisccoulson, did you figure out why builds are failing?
<chrisccoulson> kenvandine, no, not yet. it started off as amd64, but now the i386 builds are all failing with the same problem too
<chrisccoulson> i'm not sure what's changed this afternoon
<kenvandine> yeah
<chrisccoulson> cjwatson, ^^^
<kenvandine> armel is working
<chrisccoulson> any ideas?
<kenvandine> all of mine are failing too
<chrisccoulson> https://launchpad.net/ubuntu/+source/evolution-indicator/0.2.14-0ubuntu3/+buildjob/2286589
<chrisccoulson> friday night is not a good time for the world to break :(
<micahg> I've had 2 daily updates show archive packages not authenticated today, anyone else seeing this?
<kenvandine> i don't think it is something in natty that broke though
<kenvandine> pbuilder was still working for me about an hour ago
<kenvandine> micahg, i haven't seen that
<chrisccoulson> kenvandine, i'm not so sure. lamont thinks it might be, and the way the failure trickled slowly across architectures might suggest that it's a package that recently built
<xnox_> micahg, me neither. But it depends which mirror you use and when you caught it with "apt-get update"
<chrisccoulson> i guess armel still works because that's slow ;)
<kenvandine> my notify-osd upload from this morning failed on both amd64 and i386
<micahg> xnox: us.a.u.c
<xnox_> micahg, check on lp what is the status for that mirror, how upto date it is for natty. I'm in UK so I get updates slightly quicker ;-) my mirror is a push one from a.u.c
<cjwatson> do you have timestamps for when it started breaking on each of amd64 and i386?
<cjwatson> even roughly
<cjwatson> one problem is that I think lamont is now on a plane, so recovery may be difficult
<chrisccoulson> cjwatson, here is the first failure i saw on amd64 - https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu2/+buildjob/2286209
<chrisccoulson> the i386 build a short time before that worked ok - https://launchpad.net/ubuntu/+source/firefox/4.0~b12+build1+nobinonly-0ubuntu2/+buildjob/2286211
<kenvandine> cjwatson, just by looking at commit mail, it looks like the yelp commit was the first to break, and that failed on both i386 and amd64
<kenvandine> gbgoffice succeeded on both arches 4 hours ago
<kenvandine> yelp failed on both areas 3 hours ago
<kenvandine> s/areas/arches
<zyga> how can I use custom hooks / archives with pbuilder-dist?
<zyga> it will still read .pbuilderc but I'd like to be able to customize this file for each distribution
<Sarvatt> nvidia-graphics-drivers failed on amd64 only 5 hours ago https://launchpad.net/ubuntu/natty/+source/nvidia-graphics-drivers/270.29-0ubuntu1
 * cjwatson upgrades a natty chroot to see if he can reproduce these build failures
<cjwatson> the toolchain upgrades at the start of a successful vs. failed build logs are identical
<cjwatson> if somebody could find two successive builds of different versions of the same package on the same architecture, the first of which succeeds and the second of which fails with these permissions errors, that would be very helpful
<cjwatson> the previous version of yelp succeeded, but it was over a month ago; something a bit closer would be good
<cjwatson> evolution-indicator looks like a good candidate
<cjwatson> none of the changed build-dependencies between the failing and succeeding versions of evolution-indicator/i386 are present at all in the failing hal build
<cjwatson> so I'm rather tempted to rule out that this is due to a change in natty
<psusi> cjwatson: I think you had an opinion the other night on the 'p' partition separator issue for dmraid devices, but I forget what it was.  Did you think it should only be there if the previous character was a digit, and not otherwise?
<cjwatson> that sounded reasonable to me but I don't want to force my opinion in this case
<kenvandine> cjwatson, yeah, there was 1 line change in the two versions of evolution-indicator
<kenvandine> and it builds in pbuilder, realy doesn't feel like natty is broken
<psusi> well, I'm trying to figure out if I should work on patching dmraid and parted to drop the 'p' when it is not needed, or not... I got a patch for gparted from upstream to disable its broken handling and rely on libparted to take care of it, so that fixes the bug... propsed for merge and waiting review
<cjwatson> though that said that does create an ambiguity - imagine if you're silly enough to create two partitioned devices, one of which is called foo1 and the other of which is called foo1p
<cjwatson> yes, I saw your merge request, but I've been head-down on other stuff
<psusi> that's the problem gparted had...
<cjwatson> it's on the list of stuff the foundations team needs to look at
<cjwatson> I don't expect it will be forgotten
<psusi> very bad since it can decide that one is not mounted and delete the partition, when the other is mounted
<cjwatson> so meh, I don't know, I'd rather people who deal with this stuff more work it out
<psusi> I suppose that having the 'p' there when it isn't needed isn't hurting anything for now, after gparted is fixed and we don't use kpartx so it doesn't really matter that it has a different idea
<cjwatson> are there any natty builds anyone can find that are still succeeding?
 * psusi dives back into the swsusp and plymouth code
<cjwatson> cloud-utils worked recently, but I don't think that ships any code that pkg-create-dbgsym would have acted on
<cjwatson> ditto nova
<james_w> cjwatson, https://launchpad.net/ubuntu/+source/cobbler/2.1.0~bzr2002-0ubuntu1/+buildjob/2286770
<james_w> oh
<james_w> https://launchpad.net/ubuntu/+builds?build_text=&build_state=built
<james_w> xulrunner-2.0 finished 1 hour ago?
<james_w> started 3 hours ago
<cjwatson> right, I can't find a recent build that used any shared libraries though
<cjwatson> that was powerpc - it's not obvious that that's affected yet
<ev> debfx: are you planning on uploading that qt4 fix tonight?
<james_w> I can't see any recent successful builds on x86 that produced shared libraries
<cjwatson> there is misbuilding happening
<cjwatson> I'm ringing the IS emergency phone
<cjwatson> (successful builds with incorrect permissions on files in .debs)
<cjwatson> I recommend developers help by not uploading anything for the time being ;-)
<cjwatson> I got through to elmo, but he's not at a computer right now; he's going to try to contact some other folks
<hallyn> hm?  do we know what's going on with the builds?
<cjwatson> it looks like an incorrect umask
<cjwatson> they clearly need to be shut down pending investigation
<chrisccoulson> cjwatson, thanks for looking at this btw :)
<lifeless> profile defaults could account for this (if a recent chroot rebuild happened). Similarly, sbuild might have gone crazy if we did something silly in LP (but I don't recall anything going past like that)
<cjwatson> I'm going to escalate up my management chain and try to find somebody to take over, as it's 9pm on a Friday night and I'd rather like to be elsewhere
<cjwatson> (Rick's calling me back in a few minutes)
<kenvandine> cjwatson, thx
<lifeless> cjwatson: I'm tweeting that there is an issue
<lifeless> done - http://identi.ca/launchpadstatus
<lamont> chrisccoulson: what all architectures are you seeing this on?
<lamont> cjwatson: ??
<chrisccoulson> lamont, i386 and amd64 at the moment
<chrisccoulson> i haven't seen it on any others, not sure if anybody else did though
<cjwatson> what he said
<cjwatson> it doesn't seem to be happening on powerpc so far
<lifeless> lamont: can you disable all the buildds ?
<lifeless> lamont: for those arches at minimum
<cjwatson> lamont: I've diffed fail/success build logs and can find no relevant package differences
<lamont> ppa and archive? or just archive?
<cjwatson> don't know, unfortunately
<cjwatson> is there a URL somewhere listing recent PPA builds?
<lamont> no
<cjwatson> the build failures don't concern me (in an OMG STOP THE WORLD) kind of way, but the misbuilds certainly do
 * lamont put the world on manual
<cjwatson> is a process' umask visible in /proc/pid?
<broder> cjwatson: last time i looked for this, i think i concluded "no"
<cjwatson> I'm also failing to find it if it is
<broder> i thought i ended up having to gdb the process
<lamont> that's what I'm trying to figure out
<lamont> 2011-02-25 15:18:00 status installed libc6 2.7-10ubuntu8
<cjwatson> in what context?
<cjwatson> hm, hardy, I assume the root
<lamont> stupid system
<cjwatson> lamont: what was the previous version?
<lamont> hardy in the root
<cjwatson> I don't know exactly, but that's a plausible time for failures to have begun
<lamont> bah. that's libc6 triggers
<lamont> 2011-02-25 15:18:00 status triggers-pending libc6 2.7-10ubuntu8
<lamont> 2011-02-25 15:18:00 trigproc libc6 2.7-10ubuntu8 2.7-10ubuntu8
<lamont> 2011-02-25 15:18:00 status half-configured libc6 2.7-10ubuntu8
<lamont> 2011-02-25 15:18:00 status installed libc6 2.7-10ubuntu8
<lamont> thanks dpkg
<lamont> oh.
<lamont> so... what changed in sudo between hardy and lucid?
<lamont> anything about that environment cleaning that would affect umask?
<lamont> wow. c rap internet today
<lamont> that actually doesn't look all that promising
<lamont> interestingly, sbuild has a umask of 077
<kees> barry: I've exhausted the FAQs. can I ask you a python utf-8 question?
<barry> kees: sure, but sometimes this stuff hurts my brain (/me is a typical barely monolinguistic american :)
<kees> hehe
<kees> barry: it seems simple enough to me, but I don't know what I'm doing wrong.
<kees> barry: I have text I've read from a file. if I operate on it, python explodes with:
<kees> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2531: ordinal not in range(128)
<kees> when I try to call something like "strip()" on it
<broder> kees: what if you take the string and .decode('utf-8') it?
<cjwatson> https://wiki.ubuntu.com/IncidentReports/2011-02-25-Permissions-build-failures
<cjwatson> skeleton, please extend
<barry> kees: how are you opening the file?
<kees> broder: why isn't it utf-8 already?
<kees> barry: file(filename).read()
<barry> kees: also, we're talking python2 here, right? :)
<kees> barry: yeah, natty python
<kees> 2.7
<barry> kees: that's because you opened the file in binary, so you've got 8-bit data, not text
<barry> and probably not 8-bit data containing pure ascii
<kees> barry: ah, sorry, no, I used file(filename).readlines()
<kees> how do I communicate to python that it should treat this as utf-8?
<barry> (aside: built-in file is not the preferred way to open a file, use built-in open)
<kees> I thought they were the same?
<barry> kees: technically they are, but convention treats `file` as the type and `open` as the function
<barry> kees: http://docs.python.org/library/codecs.html
<barry> kees: use codecs.open(filename, mode, encoding='utf-8')
<barry> then read from that
<kees> hunh.
<kees> is there a way to have open be that instead?
<lamont> cjwatson: in the init-script, I print the umask (=022) and launch the buildd.  gdb on the process shows us at 077 inside the buildd
<lamont> post-jaunty, twistd accepts --umask as an option, before that it errors
 * cjwatson is handing over to skaet
<cjwatson> (who might draft in others)
<cjwatson> I'll be back in an hour or two
<cjwatson> (but not for long, that will be late for me)
 * skaet_ reading through the backscroll
<barry> kees: built-in open()?  not without evil and/or upgrading to python3 :)
<kees> heh, okay
<kees> barry: cool; thanks, that works.
<kees> barry: it will be a bit of a pain to fix all the file/open use to use codecs.open, but I'll just grind through it. :)
<barry> kees: take comfort that it will at least make your inevitable conversion to py3 easier
<barry> :)
<ohsix> anyone know offhand why the libasound2 dep in ffb12 was changed?
<ohsix> i had it pinned on mav but taking libasound2 with it breaks too many things, i'll have to stick with 11
<skaet_> lamont,  do you have any way of assessing which packages have been affected?
<lamont> skaet_: we can put together a query (not me, but someone with more db knowledge) of what builds were done today, that at least narrows it down
<lamont> fwiw, powerpc and armel are unaffected
<lamont> digging into the package list that broke things, but it's confined to hardy
<lamont> (for the underlying buildd host os)
<skaet_> jdstrand, ^^  can you help with this?
<skaet_> lamont, just to be clear,  problem is only natty images built today, or does it stretch beyond?  do we know when the bad builds started?
<lifeless> skaet_: can't answer that until we have a cause
<lifeless> skaet_: we're discussing it on #launchpad-ops (canonical internal channel) if you want the blow by blow
<lamont> skaet_: very unsure at this point
<skaet_> lifeless,  thanks
<jdstrand> I'm not sure in what way I can help, but I can ask a question
<jdstrand> lamont: you said that the underlying hardy os on the buildd is only affecting natty builds?
<jdstrand> lamont: did that host get the recent security updates for hardy?
<jdstrand> lamont: -security + -updates
<lamont> what's a quick build exhibiting this error?
<skaet_> james_w ^^ ?
<chrisccoulson> lamont, evolution-indicator is pretty quick
<ari-tczew> could anyone check this upload? http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/php-mcrypt/natty/revision/14
<ari-tczew> I'm wondering whether it's wrong cause there is only new entry in d/changelog.
<Laney> it got a new orig
<Laney> check the checksums
<lamont> skaet_: for completeness, we're working up a list of all the builds that happened during the bad time, failures we can get retried painlessly, the successes are going to be a list to review, I'm afraid
<wgrant> lamont: We shouldn't start the build farm until we review failures.
<lamont> wgrant: the virtual builders will come back enabled. :(
<lamont> though I suppose we could stop the buildd-manager
<wgrant> Kill it.
<skaet_> lamont, wgrant,  thanks.
<lamont> http://pastebin.ubuntu.com/572392/ <-- skaet_ here's your list of suspect builds
<lamont> wgrant: status == 2 is fail, correct?
<lifeless> lamont: all builds are suspect
<lifeless> lamont: even if they succeeded
<lifeless> by suspect, I mean probably broken.
<wgrant> lamont: 1 == success, 2 = fail
<wgrant> I only included those two.
<wgrant> depwait and stuff are safe, so aren't in that list.
<lamont> lifeless: correct.  hence the list... I'm going to go retry all the failures, but I can't do anything about the successes
<lamont> other than generate the list
<wgrant> lamont: If you haven't retried them already, don't.
<wgrant> We should just do a quick check of potentially problematic successes, if we can.
<wgrant> Or we may end up with cascading pain.
<wgrant> Most of them seem to be leaves.
<wgrant> But not all.
<lamont> ok
<wgrant> It looks like the primary archive is OK.
<cjwatson> nova was a problematic success that I noticed
<cjwatson> in the primary archive
<cjwatson> that's what made me pull the alarm bell
<cjwatson> it was only a few .png files, I think, but I didn't want to spend time assessing
<ari-tczew> Laney: so why source hasn't changed?
#ubuntu-devel 2011-02-26
<lamont> gah
<wgrant> Oh?
<hallyn> (that didn't sound encouraging)
<psusi> anyone got any advice on where to start debugging ubiquity hanging while detecting disks?
<psusi> hrm... or better yet, how to revert to the previous version... was changed yesterday for a new partman... sounds like a good candidate
<skaet_> all, known affected packages have been rebuilt now,  and the buildds have been turned on.
<skaet_> For those interested,  the list of packages can be found at: http://paste.ubuntu.com/572428/ .
<Chipzz> skaet_: what exactly was the cause?
<skaet_> Chipzz,  sudo on the builders was updated earlier today, and it had different default behaviour, so some of the packages created had the wrong permissions.
<hallyn> skaet_: thx for the heads-up
<skaet_> hallyn, you're welcome.
<psusi> ev, yesterday you enabled reuse/* in partmant-auto.  This seems to cause it to hang when detecting partitions in ubiquity on the daily live cd.  filed bug #725408
<ubottu> Launchpad bug 725408 in partman-auto (Ubuntu) "installer hangs detecting existing partitions" [Undecided,New] https://launchpad.net/bugs/725408
<microcai> gtk-window-decorator sigfault at /usr/lib/libdecoration.so.0
 * microcai emerald also segfault at /usr/lib/libdecoration.so.0 
<ohsix> is there anything that can be done by the kernel to keep harddrive temperatures down, or really by anything? i've had 2 drives basically get the bits annealed right out of them in my ubuntu laptop
<hyperair> try airing them out a bit
<hyperair> what's their temperatures like?
<cdbs> jdstrand: ping
<cdbs> jdstrand: according to DDs the info on repacks of tarballs should go to the Comment: field in DEP-5 debian/copyright
<cdbs> jdstrand: and you rejected dmedia, even though it contained the info:
<cdbs> Comment: Upstream's sources was repacked to remove unnecessary test files dmedia/tests/data/* from the tarball.
<ohsix> hyperair: well iv'e done everything that could be done about airflow, right now i have to monitor it and inject emergency air with something if it gets over 55c
<cdbs> ^^ taken from debian/copyright
<hyperair> ohsix: but i've never had any hard disk overheating issues before. what machine is that?
<ohsix> the drive sez it can do 60c but i've already lost some stuff from random stuff becoming unreadable, on a drive that's only been on for 200 hours; one that replaced a drive doing the same thing
<ohsix> compaq cq60
<hyperair> that sucks =\
<hyperair> i'd take the laptop back to the manufacturer, and complain really
<ohsix> try smartctl -l scttemp on your harddrive
<hyperair> around 43
<hyperair> doesn't get higher than that
<hyperair> and there's no airflow around my hard disk
<ohsix> what model?
<ohsix> and does smartctl -t long make the temperature go up
<hyperair> lenovo y410
<ohsix> nah, of the harddrive
<hyperair> this is a two year laptop that has gone through some serious I/O thrashing before without overheating the hard drive
<hyperair> the first was a scorpio blue
<hyperair> the second was a hitachi something or other
<hyperair> and this one is another wd hard drive
<ohsix> k
<hyperair> it seems the compaq cq60 is prone to frying hard drives
<ohsix> heard wd 2.5 drives were cool drives
<hyperair> well i didn't notice any difference between that and the hitachi
<hyperair> and i've got the sensors-applet stuck on my panel, so i see my hard disk temp all the time
<MTecknology> I wish I could get output from acpi -t
<ohsix> the drive i have now keeps going up in temp, if slowly; but that doesn't bode well if it's doing nothing
<MTecknology> it just returns nothing on this laptop :(
<cdbs> Hello all, this is my scenario:
<ohsix> where did you see that the cq60 has harddrive problems?
<cdbs> I uploaded a new package before FF, and it got reviewed yesterday
<cdbs> and it got rejected, saying there was no documentation on why the package was repacked
<cdbs> infact, there WAS clear documentation, which I guess the AA mistakenly missed
<cdbs> so, I need to re-upload, do I need an FFe (I guess yes)
<cdbs> ?
<ohsix> the awesome part is the previous overheated drive bricked the whole thing during a bios update
<ohsix> hyperair: but anyways; i'm looking for stuff to do that can be automated, like having the drive accessed less when the temperature is too high; so i don't have to do it manually
<ohsix> hyperair: this is the type of stuff i'm looking at http://paste.ubuntu.com/572512/
<ohsix> UGH haha, hddtemp returns "drive is sleeping" when it's spun down
<ohsix> reading the temp doesn't wake it up; and the point of me letting it spin down is to moderate the temperature, ufhg
<ohsix> ugh apparently hitachi has a vendor specific command to read the temperature without a spinup; but generally reading smart data means the drive accessing the task file, so a spinup; can't have both
<ohsix> hyperair: are you still here? what do you get for hdparm -M and -B?
<ohsix> hyperair: apparently the bios can set it, or it can be left entirely alone
<ohsix> but with both of them set to default even an idling disk will get very hot
<ohsix> heh hdparm.conf can only use /dev/sd? and /dev/hd? paths; the device order changes though so you either have global settings or none
<ohsix> hyperair: gotta go,  but if you could check -B & -M i'd be interested, they should be set to fast & no spindown, since its' set by a script in the hdparm package, and it's a dep of ubuntu-standard
<YokoZar> why is libgnomevfs2-0 in libs but libgnomevfs2-bin in universe/libs when they come from the same source package?  (Maverick)
<wgrant> I've taken most of the distro build farm down again, since it seems the problems of 12 hours ago are not entirely resolved.
<wgrant> Normal PPAs are unaffected, but distro and non-virtual PPA builds will be queued until this is sorted out.
<artfwo> I fixed a bug in libappindicator in my own bazaar branch. what's the procedure for review and inclusion? should I set the status to "fix committed", unassing myself or whever else?
<artfwo> is there a wiki page about submitting code patches?
<artfwo> bug 724917
<ubottu> Launchpad bug 724917 in libappindicator (Ubuntu) "Importing appindicator from python crashes with ImportError on undefined symbol" [Medium,Triaged] https://launchpad.net/bugs/724917
<cjwatson> artfwo: https://wiki.ubuntu.com/SponsorshipProcess
<artfwo> cjwatson, I've already proposed a branch merge according to the guide. Now I'd like to know if there's anything like MOTU bug workflow in the upstream projects (changing the bug status to "confirmed" and unassigning yourself, when ready for sponsoring)
<cjwatson> I don't know how much it matters.  I wouldn't recommend using Fix Committed though - to me, that means that it's committed in the branch that developers upload from.
<gaurav_pawaskar> Hi guys, has anyone written MD5 algorithm?
<m4n1sh> gaurav_pawaskar: which language?
<m4n1sh> framework etc?
<gaurav_pawaskar> m4n1sh: not language as such. I just need a little clarification
<m4n1sh> gaurav_pawaskar: I don't think everyone writes their own MD5 implementation
<cjwatson> I would recommend against reimplementing basic algorithms like MD5.  You're better off using a standard implementation
<m4n1sh> libcrypt contains it's implementation AFAIK
<gaurav_pawaskar> Actually I do not need final output of MD5
<gaurav_pawaskar> i need some intermediate data.
<m4n1sh> gaurav_pawaskar: #openssl people can help better
<m4n1sh> I think
<gaurav_pawaskar> okey I will try there. Thanks alot m4n1sh
<m4n1sh> gaurav_pawaskar: just ask them that you need to get the intermediate results
<m4n1sh> so how to do it
<m4n1sh> instead of asking "has anyone re-implemented it"?
<gaurav_pawaskar> yes sure.
<jdstrand> cdbs: no, you don't need an FFe. I responded in the email
<jdstrand> cdbs: I apologize for missing the info. odd, cause I looked for it...
<hjd> Hi. I stumbled across bug 709633, which is a package request for a package which was in Ubuntu earlier, but was removed from Debian (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547514). Should this be handled like normal package requests?
<ubottu> Launchpad bug 709633 in luxrender (Ubuntu) "luxrender needs packaging" [Undecided,New] https://launchpad.net/bugs/709633
<ari-tczew> hjd: what do you want to achieve? re-pack into Ubuntu?
<hjd> ari-tczew: I'm not sure. Sorry. I just stumbled across the bug report (not familiar with the software) and noticed it had been in Ubuntu earlier. So I wondered if that means if it should be treated like regular needs-packaging bugs or not. I first asked in #ubuntu-bugs, but it was suggested I could try to ask here.
<hjd> Basically I thought about adding "needs-packaging" to the title and tag it, but I wasn't sure if it should be treated differently as it has been included before...
<cdbs> jdstrand: re-uploaded
<cdbs> no problem
<jdstrand> thanks
<ari-tczew> hjd: it was removed parallel from Debian and Ubuntu
<ari-tczew> RM: luxrender -- RoM; RC-buggy; NPOASR
<ari-tczew> hjd: if you want bring bag this package, you have to open a new bug against Debian and Ubuntu. however, if luxrender was removed in the past due to RC bugs, we preffer to get it from Debian, so if you want to maintain this package, feel free to do it in Debian.
<hjd> ari-tczew: I see. I left a comment on the bugreport in case anyone else stumbles across it.
<gaurav_pawaskar> Is there any channel for c++ help?
<GunnarHj> SkottK: Ping?
<GunnarHj> ScottK: Ping?
<ScottK> GunnarHj: Pong.
<GunnarHj> ScottK: Hello! Do you have a minute to talk about bug 719815?
<ubottu> Launchpad bug 719815 in maverick-backports "Please backport gdm and language-selector to Lucid and Maverick" [Undecided,Confirmed] https://launchpad.net/bugs/719815
<ScottK> GunnarHj: Sure.
<GunnarHj> ScottK: Have you read the latest comments on the bug?
<ScottK> Looking now.
<ScottK> GunnarHj: I'm still looking for someone like pitti or seb128 to review and say the changes are appropriate.  pitti is correct that we prefer unchanged backports, but things can be adjusted if they need to be.
<ScottK> Personally I'm concerned that we want to be very careful with something as central as gmd.
<ScottK> gmd/gdm.
<GunnarHj> Scott: I have checked, and using the Natty packages without adjustments is not possible due to dependency issues etc.
<ScottK> Right.  Adjustments when needed are fine.
<GunnarHj> Scott: What I did so far is that I started with the last Lucid respective Maverick package and added some of the Natty revisions. To me it that appears to be the most convenient way in this case.
<ScottK> OK.
<ScottK> Why is this not suitable for SRU (since that's where you started)?
<GunnarHj> ScottK: Well, you can see Martin's comment at the bottom of bug 553162.
<ubottu> Launchpad bug 553162 in Ubuntu Translations "Set $LANGUAGE if the user picks a different locale in gdm, so that language-selector and gdm stop disagreeing" [High,Triaged] https://launchpad.net/bugs/553162
<ScottK> Looking
<GunnarHj> ScottK: It appears to me that the SRU policy is very restrictive.
<ScottK> It is, by design.
<ScottK> GunnarHj: What's the confusion when using ssh?
<GunnarHj> ScottK: If LC_MESSAGES is set, without that variable is set to the same value on the remote machine, translations don't work as expected.
<ScottK> And we didn't set it before?
<GunnarHj> ScottK: No. Which is one of the reasons that caused bug 553162.
<ubottu> Launchpad bug 553162 in Ubuntu Translations "Set $LANGUAGE if the user picks a different locale in gdm, so that language-selector and gdm stop disagreeing" [High,Triaged] https://launchpad.net/bugs/553162
<ScottK> OK.
<ScottK> I think that what you propose is reasonable for a backport, but because this is essentially updating the Lucid/Maverick pacakges and not a normal backport, I want someone from ubuntu-desktop to review and concur with the changes.
<ScottK> GunnarHj: These changes are in Natty already?
<ScottK> (that's also a requirement)
<GunnarHj> ScottK: Yes, it's all in Natty already. I'm confident that Martin is ready to approve it as soon as he gets the time needed.
<ScottK> OK.  Ping me again when he does.
<GunnarHj> ScottK: I'll do. But, as I wrote on the bug, I will add some more of the Natty revisions first. No reason to limit it to "bug fixes" when we are talking about backports, right?
<ricotz> ScottK, hello
<ScottK> Hello ricotz.
<ricotz> ScottK, do you have time to review a new package in the natty queue?
<ScottK> Unlikely today.
<ricotz> ScottK, it was reviewed by 3 motus already
<ricotz> ScottK, ok
<Renfield> Is this an appropriate channel in which to ask questions about creating a package?
<penguin42> Renfield: I think there is a #ubuntu-packaging
<Renfield> Yes there is. Thanks!
<Ampelbein> is by chance anyone from ubuntu-sru here and willing to look at bug 709194 to see if everything is ok?
<ubottu> Launchpad bug 709194 in vsftpd (Ubuntu) "SRU: vsftp 2.2.2-3ubuntu7" [Low,Triaged] https://launchpad.net/bugs/709194
<ari-tczew> Ampelbein: subscribe ubuntu-sponsors. now sponsors handle SRUs first, upload it and pitti looks on it in queue
#ubuntu-devel 2011-02-27
<Ampelbein> ari-tczew: oh, ok. thanks.
<ari-tczew> Ampelbein: is it fixed in newer releases? maverick, natty
<Ampelbein> ari-tczew: indeed it is. I'm unsure about setting fix released though as that will remove the bug from the standard view?
<ari-tczew> Ampelbein: not yet. let's nominate for maverick and natty and leave a comment that maverick and natty are fixed.
<Ampelbein> ari-tczew: I nominated for lucid as in maverick (and natty) the bug is fixed
<ScottK> Ampelbein: I accepted the Lucid task and marked it fix released since it's fixed in Natty.
<Ampelbein> ScottK: ok, thank you.
<ScottK> Ampelbein: Uploaded.  Thank you for your contribution to Ubuntu.
<Ampelbein> ScottK: thank you ;-) finally have the time to get back to development a bit, was busy with RL stuff for about 2 years and am a bit rusty
<ScottK> Ampelbein: No evidence of rust there.  I remember you from before.  Glad to see you back, your contributions were always good.
<ari-tczew> ScottK: where did you set it as fixed?
<ari-tczew> I see only triaged.
 * ScottK checks.
<ScottK> It's done now.
<ari-tczew> Yep.
<dylan-m> Hey, does anyone know if we're going to have a website specifically about Unity, for end users to look at? (Like what Gnome 3 has with gnome3.org)
<ion> http://unity.ubuntu.com/
<dylan-m> ion: Right now that one feels a little developer-heavy to me, though. Come to think of it, I just assumed it was meant to be. Err, have I been looking at it wrong? :)
<ohsix> hyperair: you there?
<hyperair> ohsix: yes i'm here.
<ohsix> neat
<ohsix> ok i was pluggin' around earlier, the laptop was really doing nothing and the hd had been asleep for 80% of the whole day, but it still overheated
<ohsix> that prompted me to look at what the drive might be doing itself periodically, and you can enable/disable automatic offline tests
<hyperair> i see.
<hyperair> did that help?
<ohsix> so the question, since you monitor your temps closely, can you do smartctl -o on on it, and see what yours does
<ohsix> well, i turned it off; can't say much yet
<hyperair> can i check whether it's enabled or disabled?
<ohsix> i think so, lemme look
<ohsix> some of the things are opaque though
<ohsix> ok
<ohsix> Offline data collection status: is zero with it off, 0x80 with it on; i don't see a specific query for it
<ohsix> (thats near the top in the output of -a)
<ohsix> the odd thing is the drive actually had extra airflow at the time but it still got very hot
<hyperair> ah it's disabled.
<hyperair> i just enabled it
<hyperair> let's see the temperature then
<ohsix> its supposed to do it every 4 power on hours apparently
<ohsix> it might not do it right away
<ohsix> i'm in for kicking my own ass  if this was it.
<hyperair> lol
<hyperair> well we'll see
<hyperair> i'll wait 4 hours and check
<ohsix> ok cool
<hyperair> actually why don't you remind me in 4 hours? =p
<ohsix> i dunno what "4 hours" might be, it's up to the drive
<hyperair> heh
<hyperair> it says 4 hours for mien
<ohsix> if it gets crazy hot i'm sure you'll remember :D
<hyperair> hmm
<hyperair> =p
<hyperair> what was that scttemp command you gave me the other day?
<ohsix> well its 4 hours in Power_On_Hours terms, my drive has been on for longer than it says here so i'm assuming they only track it part of the time, the drive hadn't been spinning down at all since i installed it
<ohsix> -l scttemp
<ohsix> its in the output of -x too
<hyperair> alright
<ohsix> i'm thinking the drive has a coast mode where it really doesn't do anything but kick the drive around, instead of when, if allowed; spinning down the drive
<ohsix> so power on hours would be awake awake & armature probably moving
 * hyperair shrugs
<hyperair> actually you know what?
<hyperair> i think i'll disable the auto offline test thing..
<hyperair> and force it to start the offline test now
<ohsix> i checked in win7 over some bleeting i saw on the googlenets, temperatures & AAM / APM data is the same stuff i setup
<ohsix> good idea, it'll heat it up just the same, just won't sbeak up on you :P
<ohsix> b->n
<hyperair> heh
<hyperair> i don't think it'll heat up that much
<hyperair> i've run an offline test on my previous hard disks before and nothing happened to them
<hyperair> did you try booting into some windows or other?
<ohsix> yep
<hyperair> and?
<hyperair> did it overheat?
<ohsix> just st read the values & see if anything magical was happening
<hyperair> did it overheat or not?
<ohsix> it was heating up at the same rate; i din't need to poke at it :P
<hyperair> yeah, so take your laptop back to the manufacturer and complain
<ohsix> it was just to see if it had magic or if it was dumb stuff people were doing
<ohsix> not an option
<hyperair> why?
<ohsix> plus automatic offline tests would never be turned on by the IHV, so they wouldn't have much to do with it
<hyperair> IHV?
<ohsix> out of warranty, and i can't really call it defective
<hyperair> independent hardware vendor?
<ohsix> independent har .. yea
<hyperair> heh
<hyperair> so it didn't start overheating until recently?
<ohsix> couldn't put a timeframe on it, the initial problems i had with the first drive was heat just making the sectors on the disk unreadable, randomly
<ohsix> it had been cooking the drive for a while though
<ohsix> probably a year, i wasn't watching the temps
<ohsix> i didn't think random stuff would go tits up either
<ohsix> as obvious as that may be to state it, i mean; heat is what makes magnetic domains go all mushy and anneal their data right out of them
<ohsix> people saying "high temperatures kill drives" AREN'T saying that, in fact the drive is fine, the data is not
<ohsix> you could probably run them until solder started melting if you weren't interested in the data on them
<ohsix> but, i can live with using augmented airflow when i run an offline scan; or defrag, its rare enough
<ohsix> hyperair: anything yet? should have beenlong enough to go higher than normal
<hyperair> ohsix: temperature hasn't gone above 45.
<hyperair> oh wait
<hyperair> it hit 46.
<ohsix> is it running the test? -x has a log of statuses
<hyperair> but it came back down to 45
<hyperair> it's running,i think
<ohsix> smartctl -l selftest /dev/sda
<ohsix> depending on the brand, actual ongoing status might only be in smartctl -l selective
<hyperair> it doesn't say it's running O-o
<ohsix> you did -t offline right
<hyperair> yes i did
<ohsix> hm\
<ohsix> it should at least sayit was cancelled
<ohsix> if it got the command at all and did anything with it
<hyperair> it said it was started and would end at some other time..
<hyperair> i ran a short selftest and that bumped up the temperature though
<ohsix> oh
<ohsix> you need -t long, not -t offline
<ohsix> most drives won't actually do a prompt offline scan
<ohsix> uff sorry, should have said that
<hyperair> meh
<ohsix> long does what offline does though
<ohsix> offline has a very specific meaning with regard to the smart values, its probably wht no drives do prompt tests with that name anymore
<hyperair> alright, it says it'll be done by 17:57
<hyperair> now it's 15:30
<ohsix> if you think about it, an offline test doesn't make sense to do prompted, "offline" is stuff the drive just does, but it can also do the test if you do -o on
<hyperair> ohsix: so anyway, temperature has risen to 51 degrees
<ohsix> keen
<hyperair> 52.
<ohsix> my hd has been 41-42 the whole time we've been chatting, but it's a very cool room
<ohsix> when you've had enough -X will abort the test :P
<hyperair> okay, it's peaked at 52
<hyperair> yeah i know about -X. smartctl mentioned it when i started
<ohsix> right
<hyperair> but yeah so it's peaked at 52, and this room isn't exactly very cool.
<ohsix> i bet you have metal nearby in the drive bay that wicks away some heat
<hyperair> yes
<ohsix> but all i needed to know was that it'd go right past normal doing it
<ohsix> thanks
<hyperair> the drive bay has this metal casing thing that screws onto the disk and keeps it in place
<ohsix> right, but i mean outside of that
<hyperair> 53 degrees.
<hyperair> no there isn't much metal outside of that
<hyperair> everything's plastic
<ohsix> like the railing or something under it
<ohsix> weird
<hyperair> nope
<ohsix> ok see how hot it will get, you should be good till 60c if it's not for more than a few hours, so you won't hurt anything
<hyperair> ok
<ohsix> knowing how fast it cools down after the test stops would be neat too
<hyperair> uh oh
<hyperair> smartctl -l scttemp /dev/sda showsError invalid Temperature History Size or Index
<ohsix> heh
<ohsix> have you tried to run it during a test before
<hyperair> nope
<ohsix> drive might not do it
<hyperair> well i had watch running on it every 2 secs
<hyperair> now i'
<hyperair> now i'm just watching hddtemp
<ohsix> ah
<ohsix> scttemp is neat, but only updates the log every 5 minutes
<hyperair> no, it was every minute for me
<hyperair> oh look i've got a log again
<hyperair>  127    2011-02-27 15:41    53  **********************************
<hyperair>    0    2011-02-27 15:42    54  ***********************************
<hyperair>    1    2011-02-27 15:43    54  ***********************************
<ohsix> http://paste.ubuntu.com/572965/ this is my log from today, you can see where it started the test huhuhu
<ohsix> the temperatures are at least stable now with the changes i made to AAM/APM, mainly setting them to the suggested value :|
<ohsix> i'm thinking of a good way ubuntu could do this for you; it doesn't make any sense to set it to the max performance number in all cases
<ohsix> you need heavy cooling to do anything above what the vendor suggests
<hyperair> no, not really.
<hyperair> i've actually never heard of hard disks overheating before
<hyperair> and i use ubuntu's default AAM/APM values
<hyperair> and like i mentioned, there's no airflow in the hard disk bay
<hyperair> also, the reason we set those values so high was because some broken hard disks kept parking the head
<hyperair> so the Load_Cycle_Count kept increasing
<ohsix> its down to the vendor
<ohsix> ya i know, checked out all the bugs
<hyperair> yep
<ohsix> pegging it to one value isn't great though, turns off automatic power management alltogether
<ohsix> i've not had a drive in my posession that would spin down when set to 128
<ohsix> couldn't palimpsest check and see if its increasing the head unload count during timespans it, by its configuration couldn't?
<ohsix> like if it was set to spin down every minute, but also set to 128, if it sees more than one or two in its smart sampling interval its probably doing it
<ohsix> er i guess udisks would do that
<ohsix> btw, people don't know their disks have been getting too hot until they've lost something, and probably not even then
<ohsix> the hdparm script could do it if it assumes they only happen at shutdown, and ignores changes when on battery, if the startup script knows then it can peg it on full blast
<ohsix> but i didn't think to check out that angle until the brand new drive i got did the exact same thing the one i replaced did :\
<hyperair> ohsix: you could get a SSD instead. i think those don't heat up as much
<ohsix> it's not for me
<ohsix> its for people that are baking their hard drives and have no way of knowing
<hyperair> well
<hyperair> i'm sure they'll notice if it feels hot
<ohsix> palimpsest could at least report if the temp is 55 or over like it does for bad sectors
<hyperair> my hard disk's at 58 degrees celcius now, by the way
<ohsix> nice
<hyperair> 55 is a safe temperature.
<hyperair> 60 isn't.
<hyperair> or rather.. 60 is the warning level
<hyperair> 80 is the max
<ohsix> laptops get hot in spite of having harddrives
<ohsix> i never got a warning at 60
<hyperair> i guess
<ohsix> my drive has a stated operating temperature who's upper bound is also 60
<hyperair> perhaps you could file a bug under gnome-disk-utility and smartctl
<ohsix> isn't it udisks & palimpsest that do that reporting & notification?
<hyperair> er
<hyperair> i'm not sure
<hyperair> i think they still use smartctl's database, no?
<ohsix> ok
<ohsix> well they couldn't be, not for the notifications i have gotten anyways
<ohsix> but that was for bad sectors; the drive has always had a fixed number of them too, i couldn't do anything but ignore the drive entirely to shut it up
<ohsix> bad sectors are bad, but unless they're growing at a certain rate it should be easy to dismiss it without removing all reporting
<hyperair> well i don't know much about this
<hyperair> you'd probably get better feedback about this by talking to the smartmontools devels
<ohsix> i'm not sure what they have to do with it
<ohsix> i'm the only one using smartmontools; udisks doesn't
<ohsix> palimpsest just shows info from udisks and lets you make udisks do stuff
<hyperair> i'm just saying that they're more informed about hard disk operating temperatures and hard disk health and thel ike
<hyperair> i'm pretty clueless when it comes to this
<hyperair> i do recall some google research saying that hard disk temperatures didn't really affect their lifespan
<ohsix> their lifespan doesn't say anything about whats on the drives though; i read the same thing
<ohsix> and like i said, you could run the things until the solder melts, but that doesn't say anything about the stuff on the disk
<hyperair> right, and the people who are more informed about this are the smartmontools developers
<hyperair> not me
<ohsix> o i c
<ohsix> what could i practically do with the information; i've got mine under control
<hyperair> i don't know
<ohsix> but someone is annealing their bits right now with ubuntu
<ohsix> setting apm to 128 was half of the solution btw
<ohsix> with 256 it would slowly heat up, ever so slowly, but it didn't have a hard knee where cooling was beating heating like it does at 128
<ohsix> er 254
<ohsix> 200 would probably be a good middle ground even, though for my circumstance it'd take a while to measure
<ohsix> if i can find out if 200 solves the problem enough here, can the number be bumped down some?
<ohsix> hi cjwatson
<Daviey> !regression-alert (potential) bug #725635, had 5 reports of failed to install within 18 hours... looks like squid wasn't running when restart was called, causing exit 1
<ubottu> Launchpad bug 725635 in squid (Ubuntu) "package squid 2.7.STABLE7-1ubuntu12.1 failed to install/upgrade: el subproceso instalado el script post-installation devolviÃ³ el cÃ³digo de salida de error 1" [Undecided,New] https://launchpad.net/bugs/725635
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<Daviey> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<chrisccoulson> Daviey, i'm guessing https://launchpad.net/ubuntu/+source/squid/2.7.STABLE7-1ubuntu12.2 fixes that
<Daviey> chrisccoulson, It could be, but it could also be related to log file rotation.... I managed to reproduce the same behaviour by removing the log files, and performing a restart.
<Daviey> Doesn't look like doing that caused squid to seg fault, so not quite sure how upstart managed to loose it's grip on squid based on doing that
<Daviey> but looking at the diff for the current proposed package, it would probably handle that situatiob
<Daviey> It does resolve it.
<kirkland> andersk: hi
<andersk> kirkland: Hi.
<kirkland> andersk: i'm concerned about your ecryptfs error;  i have a few minutes to try and debug this, if you like....
<andersk> Sure.
<andersk> I discovered that âkeyctl clear @uâ is enough to make âecryptfs-mount-privateâ work again.
<andersk> (After looking at https://bugzilla.redhat.com/show_bug.cgi?id=495143 )
<kirkland> andersk: oh, hmm, interesting....
<ubottu> bugzilla.redhat.com bug 495143 in ecryptfs-utils "Private directory does mount after login but files are still encrypted" [Medium,Closed: errata]
<kirkland> andersk: right, there's some new code in ecryptfs-utils that tries to clean that up
<kirkland> andersk: i'm trying to figure out if and how a regression crept in
<kirkland> andersk: are you running latest/greatest natty?
<andersk> I wonder if my problem is triggered by having the OpenAFS client installed, since that also uses the kernel keyring.
<andersk> Yes.
<kirkland> andersk: oh, hrm;  yeah, i was about to start asking keyring questions
<kirkland> andersk: i just responded to your bug, asking for the output of 'keyctl list @u'
<kirkland> andersk: when you're getting the error
<andersk> Posted.
<andersk> (Bug 725862, in case anyone listening is curious about the context, BTW.)
<ubottu> Launchpad bug 725862 in ecryptfs-utils (Ubuntu) "Canât ecryptfs-mount-private after ecryptfs-umount-private" [High,Incomplete] https://launchpad.net/bugs/725862
<andersk> I can reproduce without the openafs module loaded (after keyctl clear @u; ecryptfs-mount-private; ecryptfs-umount-private; ecryptfs-mount-private).
<andersk> Oh wait, the hex number listed after âInserted auth tok with sigâ is different when it succeeds and when it fails.
<andersk> And after it succeeds, I have two keys in @u, one with each value.
<andersk> ecryptfs-umount-private only deletes the right one, so the wrong one stays around and apparently breaks it.
<andersk> kirkland: Iâm off to sleep, but thanks for looking, and let me know if thereâs any other info I can provide.
<kirkland> andersk: k, thanks
<cdbs> My exams are beginning, so I won't respond here on IRC or anywhere until they get over on March 16th. Leave me a mail if you need to contact me immediately.
 * cdbs /aways now for 18 days
<penguin42> cdbs: Good luck!
<rniamo> hi, do you have any idea how many times is needed to fix this bug https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/710678 ?
<ubottu> Ubuntu bug 710678 in gnome-panel (Ubuntu) "gnome-panel crashed with SIGSEGV in _panel_applet_frame_update_flags()" [Medium,New]
<belak> Is there a way of debuggin ubiquity? I'm trying to make a change to remove the option to encrypt home in the installer used in 10.04 because it crashes it...
<belak> s/debuggin/deugging/
<belak> Ok, I give up on the spelling thing...
<charlie-tca> belak: by running ubiquity --debug from a terminal
<charlie-tca> it gives you a pretty good log you can go through to find the issues
<charlie-tca> You can also set breaks, where it will stop automatically, but I can not remember how to do it.
<belak> ok. thanks. :)
<RAOF> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | 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
<Laney> WOO
<RAOF> Wooo?
<Laney> It's always good when a pilot shows up. Makes me feel I am no longer on a ship travelling blind through the dark.
<RAOF> :)
<StevenK> Other people can also answer questions?
<bdrung_> DktrKranz, james_w: can you update python-launchpadlib in debian unstable?
<DktrKranz> bdrung_: python-keyring (>= 0.5) is required for that
#ubuntu-devel 2012-02-20
<TheMuso> superm1: You're a core-dev, so you should hae direct commit access to lp:~ubuntu-audio-dev/pulseaudio/ubuntu.precise
<slangasek> lamont: did you file a bug about the nm-applet memory usage problem?  I'm seeing the same problem here (though I noticed it at < 3GB, I didn't wait for it to hit 6GB)
<RAOF> slangasek: lifeless was also seeing that; I believe he filed a bug.
<slangasek> RAOF: right, bug #930491 then - thanks
<ubottu> Launchpad bug 930491 in network-manager-applet (Ubuntu) "Large memory leak in nm-applet" [High,Confirmed] https://launchpad.net/bugs/930491
<micahg> slangasek: I think cyphermox said he fixed some of that with the latest nm upload, but there's more to do
<slangasek> micahg: ah, well, it's possible that fixing that bug is why nm-applet now won't *restart* for me ;)
<slangasek> (glibc free() assert)
<Sarvatt> 31mb usage after 2 days uptime here, nm-applet is definitely much better that it was here
<cyphermox> slangasek: ah, will look into it. could you get me a backtrace (things work here, so it might be that you have some device I couldn't test and messed up)
<slangasek> cyphermox: bug #936644
<ubottu> Launchpad bug 936644 in network-manager-applet (Ubuntu Precise) "nm-applet assert failure: *** glibc detected *** nm-applet: free(): invalid pointer: 0x0000000001eb1370 ***" [High,Confirmed] https://launchpad.net/bugs/936644
<cyphermox> thanks
<slangasek> so it's related to the new patch changes
<cyphermox> yeah
<cyphermox> I know what causes this, weird that this doesn't affect  me too though
<lifeless> cyphermox: slangasek:
<lifeless>  2386 robertc   20   0 3014m 1.8g  12m S    0 24.1  27:53.58 nm-applet
<lifeless> Sarvatt: ^ not that much better :P
<cyphermox> indeed
<cyphermox> actually, it depends a lot on how much noise is around -- if there's a lot of changes in scan results, it tends to go up faster
<lifeless> well, i have an N network
<lifeless> and iwlwifi
<cyphermox> something is still broken in the menu updates but I'm having a hard time tracking it down
<lifeless> so my network reconnects like crazy
<cyphermox> lifeless: ah
<cyphermox> guess that would make sense yeah :/
<lifeless> combined with it not remembering my credentials, thats pretty annoying (which is presumably related to the lack of themeing ...)
<Sarvatt> wow, yeah the networks barely ever change here
<cyphermox> Sarvatt: you're seeing it behaving better because before it was updating on every signal level change... a little too agressivel
<superm1> TheMuso: yeah I realized that shortly later.  I pushed it through
<TheMuso> superm1: ok thanks.
<wzssyqa> gpg --export-secret-subkey xxxxxxxx > sub.gpg give an error: gpg: key yyyyyyyy: not protected - skipped why?
<superm1> could someone clarify a seed question for me?  mythbuntu isos are fairly oversized right now.  if something that is only pulled in via recommends of something seeded is added to the mythbuntu.precise/blacklist file, will that keep it from getting pulled in or have some other undesirable effect?
<dholbach> good morning
<micahg> doko: would it be nice to drop gnat-4.4 for precise
<Sweetshark> Hi there, looking for an package sponsor as piiti is on vacation.
<tumbleweed> !sponsorship|Sweetshark
<ubottu> Sweetshark: You can find out about the package sponsorship process here http://wiki.ubuntu.com/SponsorshipProcess - For !UDS sponsorship see http://uds.ubuntu.com/participate/sponsorship/
<Sweetshark> tumbleweed: ok thx, let put that different: as pitti in on vacation, i need somebody else daring to upload libreoffice-3.5.0-1ubuntu1 to precise. its already parked on chinstrap and waiting to be picked up.
<tumbleweed> ah, libreoffice. I can see why you may not want the usual queue
<Sweetshark> tumbleweed: ;)
<geser> Sweetshark: have you considered to apply for PPU rights for libreoffice so you can upload yourself in future?
<dholbach> geser, https://wiki.ubuntu.com/BjoernMichaelsen/YourDeveloperApplication :)
<Sweetshark> dholbach: ;)
<Sweetshark> i found a victim on #ubuntu-desktop it seems.
<tumbleweed> more victims are also useful for endorsements on that PPU application. We like people to have worked with multiple sponsors
<micahg> good, I was worried I was going to have nightmares worrying that it'll still need sponsoring in the morning my time :)
<Sweetshark> micahg: the Linux philosophy is "laugh in the face of danger" http://groups.google.com/group/linux.dev.kernel/msg/74ee0b1d6420cd08
<hrw> doko: what do you think about http://u.42.pl/2HXy patch? it is needed to get cross compiler built for multilib arm - I am keeping it in gcc-4.6/cross package
<doko> hrw: why is this necessary?
<hrw> doko: dpkg-shlibdeps otherwise is not able to find libc6 for armhf
<hrw> doko: and vice versa if build for armhf
<cortexuvula> Hi all. I have written an Quickly app and started a project on Launchpad. I have updated setup.py with the url of the project.   Clicking on Help-> Report a problem produce an error that this is not an ubuntu package
<cortexuvula> my question is: How do I link the app and the project
<kelemengabor> cyphermox: hi, could you take a look at the merge proposal for bug #875017 ?
<ubottu> Launchpad bug 875017 in Ubuntu Translations "Translation for "Wired Connection %s" not displayed" [Medium,Triaged] https://launchpad.net/bugs/875017
<cyphermox> kelemengabor: got my comments?
<kelemengabor> cyphermox: yes
<kelemengabor> I'll resubmit it, thanks
<peaceZ> hello all
<peaceZ> i wanted to burn de cd of pangolin to make some test but it is 715mb and i could not overburn it using brasero and k3b on a 700mb cd :d
<peaceZ> what to do please except than buy 800mb cd ? is it some files i can delete without problems ? as languages files or anything low importance ?
<apw> jodh, is this one actually upstart? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/936256
<ubottu> Launchpad bug 936256 in linux (Ubuntu) "kernel panic on boot" [Undecided,Confirmed]
<jodh> apw: Just marked it as dup of 935585.
<cyphermox> peaceZ: no, you pretty much need all the files (or what you could remove isn't likely to give you enough space). as an alternative you could burn the ISO image to a USB key if you have one large enough
<apw> bug #935585
<ubottu> Launchpad bug 935585 in upstart (Ubuntu) "[kernel panic] init: log.c:786: Assertion failed in log_clear_unflushed: log->remote_closed" [Undecided,Confirmed] https://launchpad.net/bugs/935585
<apw> is the unity-video lens nailing the crap out of their disk for anyone else?
<seb128> apw, not that I noticed but I'm on a ssd and I don't watch ios closely, you should open a bug if that happens to you in any case ;-)
<apw> seb128, it seems to be reading everything in my home directory
<seb128> urg
<apw> its been humping my disk for 10m now
<apw> -o /home/apw/.cache/unity-lens-video/videos.db -l 0 -U /home/apw
<apw> it doesn't seem to be limiting itself to my videos directory
<seb128> apw, report a bug please, what value has XDG_VIDEOS_DIR in .config/user-dirs.dirs?
<apw> $ grep XDG_VIDEOS_DIR ~/.config/user-dirs.dirs
<apw> XDG_VIDEOS_DIR="$HOME/"
<apw> this is one of those where if you remove empty directories which you don't use the desktop loses its mind, isn't it
<seb128> apw, that might be part of the issue
<seb128> apw, yes ;-)
<apw> that happened with pictures as well, as they were empty i don't have them
<seb128> well it fallback to the dir under the one your deleted
<seb128> so Videos -> user dir
<seb128> it's a bad idea to delete the standard xdg dirs
<seb128> not sure how we can message that to users though
<peaceZ> cyphermox, my laptop does not enable usb boot, unluckily, thank you for your reply
<seb128> one way would be to recreate them for you at every login :p
<apw> or perhaps we could just behave sensibly in the face of resonable user behaviour
<apw> seb128, if i remake it will the world recover ?
<seb128> apw, prompt a dialog asking if you are sure to want to remove those directory with a warning of the side effects?
<apw> seb128, and against what do i file a bug, i'd not like to blame unity when its not
<seb128> apw, you can just tweak .config/user-dirs.dirs to whatever dir you want the video dir to be
<apw> seb128, ok i'll do that, i should file a bug, even if it gets closed 'Don't do that', so that others can find the symptoms
<seb128> apw, right, I'm trying to figure what they do, if they just index the video dir it's technically not a bug on their side, it's not especially new
<seb128> we keep getting bugs about nautilus getting really slow because people delete "Templates"
<apw> the video lens is brand spanking new though isn't it
<seb128> and the dir fallback to the user dir
<seb128> then nautilus tries to build templates with your whole userdir content
<apw> perhaps we should fall back to '.empty' and make one thats empty
<seb128> apw, right, the issues due to xdg dirs deletions are not new though
<apw> seb128, oh i probabally have that too
<seb128> apw, ideally we would lock down the dirs on the fs and don't let users delete them or something
<seb128> or at least display a warning dialog when somebody does saying they are asking for issues
<apw> its a bit of a strange paradimn though, as it makes sense to keep everything say to do with ones 'wedding' in one place
<seb128> apw, well, we could fallback to an empty dir yes, but then you would get i.e no video indexed and not understand why
<apw> so forceing me to put my videos in one place and pictures in another for an event ... is going to hurt heads
<seb128> apw, until we get something that doesn't suck to replace inotify we can't do much better
<apw> what is inotify missing which prevents this from working ?
<seb128> apw, you can't watch your whole user dir
<seb128> it's limited to 32k watches or something
<seb128> so basically you have to watch the main dir and go through all the subdir every time something change
<seb128> you can't tell inotify "just let me know when something in the user dir change"
<seb128> or rather "let me know what changed"
<seb128> apw, well in any case yes please open a bug on "unity-lens-video", I will comment on it
<apw> seb128, i can see why, that would be vastly expensive for the kernel to do
<seb128> apw, I think it should be easy to just not index if the Video dir is the user dir
<apw> it would have to know that someone was watching somewhere higher in the hierachy
<seb128> apw, well the bottom line is that there is no way to monitor files through an user dir which is not io expensive
<apw> whcih would be a lock heavy and extremly time consuming operation on every single io
<apw> seb128, how about we have a Media directory instead
<seb128> apw, well we have music, pictures and videos
<seb128> they could be subdir of a media though
<seb128> apw, but yeah, those could do with some design thinking
<apw> i wonder what happens if i point them all to Media/ which is what i mean really
<seb128> thing is that you don't want shotwell to index your music for example
<apw> so i can have Media/wedding/*
<seb128> or rhythmbox to index your photos
<apw> i would hope shotwell would know that a tarball isn't something it can index
<apw> and same with rhythmbox
<seb128> I guess design will said that the solution would be to have one application doing music, video and photos
<seb128> apw, right, they still watch their library though
<apw> yeah probabally
<seb128> the more you watch, the more you wake up looking at stuff to see that you don't care about those
<seb128> anyway
<seb128> going back to the issue
<seb128> please open a bug on unity-lens-video saying that it gets confused when the video xdg got deleted
<seb128> and please subscribe me to the bug ;-)
<seb128> I doubt we will address the different directories for different medias this cycle
<seb128> but we can probably handle the cases where some xdg dir needed got deleted
<apw> no probabally not as i am not sure design agree my concern is valid anyhow
<apw> in their model i mean
<seb128> would it be by displaying a dialog at login telling about the issue and the side effect it has an asking you if you want to pick another dir for $MEDIA
 * apw will file something, and go remake these directories
<seb128> login or whenever it detects that the directory is being deleted
<apw> does anyone know what the offical matrix key binding is? as i have it appearing at random
<seb128> apw, alt
<apw> seb128, doing what with alt?  single press?
<seb128> apw, that's a known bug, should be fixed this week, it appear if you alt-tab sometimes or if you alt-screenshot
<seb128> apw, yes, a simple tap, i.e just press and relax without using other keys
<seb128> apw, though it's buggy and i.e alt-printscreen or sometimes alt-tab done quickly will trigger it
<seb128> bug #925293
<ubottu> Launchpad bug 925293 in Unity Distro Priority "Plugins can't tell the difference between a modifier key-tap, and a modifier key-release (after being used to modify other keys)" [High,Fix committed] https://launchpad.net/bugs/925293
<seb128> apw, ^
<apw> ahh ok, thats odd as i didn't think it was single-tap from playing with it, but double, strange
<apw> seb128, are cursors mean to work once you have typed a term ?
<seb128> apw, cursors?
<apw> seb128, i am looking for something to select anything other than the first entry in the suggestions list
<seb128> oh, you mean in the hud? down arrow should work
<seb128> it works for me
<apw> it seems to highlight the first one, nothing seems to work here
<seb128> keypad arrows don't work though
<seb128> if that's what you try
<seb128> but the normal "down" arrow should go down
<apw> seb128, what keysym is it bound to ?
<apw> doesn't work with any of the down arrows on any of my keyboards
<seb128> dunno, it works for me with
<seb128>     state 0x10, keycode 116 (keysym 0xff54, Down), same_screen YES,
<seb128> i.e "Down"
<apw> seb128, ok mine is producing Down, and no dice
<seb128> you might want to ask on #ubuntu-unity about it
<apw> i'll file a bug
<apw> any idea what one files matrix things in ?
<seb128> apw, https://code.launchpad.net/~gordallott/unity/hud/+merge/90085
<seb128> that was the feature merge
<seb128> it might have code clues
<seb128> gord, ^
<seb128> apw, gord might be able to help you, he did most of the unity side of the hud
<apw> seb128, Videos thingy filed and you sub'd
<seb128> gord, is there any known issue where down doesn't work to navigate through the hud suggestions?
<seb128> apw, thanks
<apw> seb128, interesting the keys which produce Left and Right work to move in the entry box ok
<gord> seb128, saw the same issue with the dash earlier, not looked at it yet though
<seb128> unity bug then I guess...
<apw> gord, xev says my up and down arrows produce Up and Down as keys, so i am a bit confused
<apw> seb128, i've got those numbers stuck on again, having fiddled with hud for a bit, perplexing
<seb128> apw, what numbers?
<apw> seb128, the black numbers in the launcher, when you hold for a while on Super
<apw> the hints for the Super+<n> functionaolity
<apw> have one of my launchers with them stuck on
<seb128> oh, weird
<apw> seb128, so is the hud bug to be filed against unity?
<seb128> apw, yes
<seb128> gord, should that down arrow bug assigned to you?
<apw> how odd, when yo uhave the launchers on the screen a
<apw> and hit alt, all your launchers go away even though only one needs to
<apw> is that intended
<gord> seb128, i guess, I don't really know enough about it to say where the issue is really, i'll farm it off wherever once i know more so can't hurt
<seb128> gord, ok, thanks
<seb128> apw, not sure, doesn't hurt to open a bug and get design to look at it
<apw> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/937025
<ubottu> Launchpad bug 937025 in unity (Ubuntu) "HUD: cursor up/down keys are not working with hud searches" [Undecided,New]
<apw> seb128, ^^ for the HUD cursor issue
<seb128> apw, thanks
<apw> gord, ok i just logged out and back in to fix my launcher icons, and i seem to have hud up/down working now
<apw> so it may be random whether they work or not
<apw> seb128, ^^
<seb128> seems so, gord said he got it once as well
<m4n1sh> ev: ping
<ev> m4n1sh: pong
<m4n1sh> ev: do you have time to refactor the whoopsie code
<ev> m4n1sh: yup, been working on it all day
<m4n1sh> and split it out of ccpanel_foo_init method
<m4n1sh> cool
<m4n1sh> I cant seem to get my way around it
<m4n1sh> i am bad at C
<ev> no worries
<ev> I'm on top of it
<m4n1sh> yeah!!
<m4n1sh> :)
<ev> I'll propose a branch hopefully by the end of the day
<m4n1sh> releasing on wed
<m4n1sh> yes, All my worries gone
<m4n1sh> thanks
<lamont> slangasek: nm memory - I was waiting to reproduce it since I had upgraded a bunch of things
<noodles775> Hi. Are there known issues with precise upgrades at the moment (nvidia perhaps?). I've just updated an hour ago (hadn't done so for a while), and after reboot can only login to a recovery console.
 * noodles775 takes a photo.
<noodles775> http://people.canonical.com/~michaeln/tmp/IMAG1140.jpg
 * noodles775 checks if nvidia issue from the other week was resolved.
<noodles775> Hrm, checking dpkg.log seems to show that most of y system has been removed (I blindly did `sudo apt-get dist-upgrade` and hit Y without checking the packages) :/
<damg> noodles775, I've installed today's daily today and had this issue after login for 30 seconds, then X logged me into unity
<damg> after that I've installed proprietary though and didn't experience the problem anymore
<noodles775> damg: yeah, as above, I've just checked my dpkg.log and seen that it's unrelated to a driver issue, but rather that many packages were removed when I just updated (including essential stuff like software-center, gnome-panel, unity-2d etc.)
<damg> hehe
<noodles775> `cat /var/log/dpkg.log | grep 2012-02-20.*remove | wc -l` -> 52
<damg> how does unity decide whether an application window will be managed by it. it seems that it ignores blender in alt-tab or on its icon clicks.
<damg> hm, it doesn't even get focus. pressing alt calls the menu of the next app below it.
<bulldog98> cjwatson: hello we the kubuntu team is working on an active image (aka mobile) could you please build following seed? lp:~kubuntu-active/ubuntu-seeds/kubuntu-active-seed/
<bulldog98> thanks
<slangasek> lamont: looks like the nm memory bug is well understood now
<Riddell> bulldog98: it's not quite as easy as just asking cjwatson to build a seed :)  I'm looking at script to be fiddled now
<bulldog98> Riddell: ok ping me if finished, Iâll test it then
<slangasek> hallyn: the AT_EMPTY_PATH issue now also affects qemu-linaro, apparently
<Riddell> bulldog98: it's probably not today, needs bits put on servers that I don't have access to
<bulldog98> Riddell: ah ok
<lamont> slangasek: cool
<int_ua> I want to report a bug against renice but I can't find it's upstream bug tracker.
<int_ua> Can anyone help me?
<int_ua> Since it's bsdutils I don't think that nor Ubuntu neither Debian bug trackers are the best choice
<int_ua> but since it's fundamental part
<int_ua> Anyone?
<pitti> mdz: hey Matt, are you there for TB meeting?
<jodh> Hi - is there anyone about with build-rescore-superpowers that can bump
<jodh> https://launchpad.net/~jamesodhunt/+archive/bug-935585/+packages ?
 * jodh double-checks to see if emacs has a build-rescore function...
<stgraber> jodh: done
<jodh> stgraber: thanks very much! emacs drew a blank. Wonder if it's got
<jodh> a make-me-a-build-rescore-function function?...
#ubuntu-devel 2012-02-21
<bemagri> hello
<bemagri> anyone?
<RAOF> !ask > bemagri
<ubottu> bemagri, please see my private message
<bemagri> I don't have any questions for now... I'm just looking for an open source project to join
<RAOF> Ok; but you presumably have a question, even if it's âhow do I join the Ubuntu projectâ :)
<bemagri> oh well... you got a point there!
<bemagri> so, how do I join the Ubuntu project?
<penguin42> bemagri: http://www.ubuntu.com/community  has some pointers depending what you want to do
<bemagri> i wan't to start a new project, so I wanted to know what kind of applications do you guys miss in ubuntu?
<penguin42> bemagri: Obviously there are lots of bugs in bugs.launchpad.net, there are also some larger scale designs on https://blueprints.launchpad.net/ubuntu many of which some people have already started
<bemagri> penguin42, i will take a look, thanks
<penguin42> bemagri: However, it's normally best if you ask what _you_ miss!
<bemagri> penguin42, it's harder to ask that question! :)
<smoser> slangasek, aroun d?
<smoser> bug 937352, maybe someone else has thoughts.
<ubottu> Launchpad bug 937352 in cloud-initramfs-tools (Ubuntu) "root partition in may not be grown" [Undecided,New] https://launchpad.net/bugs/937352
<smoser> it would appear there, that, in initramfs:
<smoser>  mount /dev/sda1
<smoser>  umount /dev/sda1
<smoser>  sfdisk ... (to grow /dev/sda1 to fill extra unallocated space)
<smoser>   but there, "BLKRRPART: Device or resource busy"
<smoser> the only thing i can think of that would have the resource busy would be the 'mount', but clearly the umount did finish and returned succesfully.
<penguin42> something like ureadahead or udisks ?
<psusi> smoser, it sounds like the resize patches may hit mainline soon and hopefully can get applied to the precise kernel
<smoser> psusi, well, that'd be good.. but i dont know that i'd likely pick up user space changes for that.
<smoser> i really do appreciate your help on it, but just think it would be a 12.10 thing at this point.
<psusi> that would be a shame
<psusi> 12.04 will be around for a long time
<smoser> what all do i need from user space ? are there utilities i can use ? ie, can i do this in the same amount or less code than i already have doing it?
<smoser> moving it out of initramfs is nice
<psusi> smoser, you can either switch from sfdisk to parted, or ignore the BLKRRPART error, and run partx -u to update the in kernel tables
<psusi> or sfdisk could be patched to use the BLKPG ioctl instead of BLKRRPART the way I did to parted, but that would be a bit more involved
<psusi> easiest thing is probably just to ignore the error and run partx -u
<smoser> partx -u requires update to parted?
<psusi> no... requires a patch to partx that I wrote a few months ago ;)
<smoser> right.
<smoser> did you get it upstream ?
<smoser> i remember you tried
<psusi> I submitted it, they said it looked good but wanted to wait for the kernel patch to hit mainline
<smoser> ah
<psusi> hopefully that will happen here soon and then it can be applied to util-linux and hopefully both backported to ubuntu... I've had a bug filed to apply the patch to the ubuntu kernel for months without any comment... hopefully if it gets merged mainline the right person can be poked to apply it to precise
<psusi> then a sponsor can merge the util-linux branch that has been waiting in the wings, and you're good to fix the cloud package to run partx -u
<psusi> hopefully by 12.10 I'll have gparted taking advantage of it
<psusi> I'm even kicking around the idea of btrfs being able to relocate the start of the partition on the fly ;)
<psusi> smoser, by the way, why don't the cloud images just not use a partition table at all?
<smoser> grub complains about being installed onto a disk without a partition table.
<smoser> but i suppose it is perhaps not a real requirement
<psusi> well, you don't need it for pv domUs
<psusi> but if you're doing full hardware virtualization then I guess you do
<smoser> well.. .we make availalbe 2 types of images.
<smoser> one is "raw partition" (ie, no partition table).  that is what is used on EC2, where pv-grub loads the kernel from inside the image without being installed.
<smoser> (without being installed anywhere in the image at all)
<smoser> the other is "full disk". which is what we recommend to use on full virt (kvm) and has grub installed in the MBR.
<smoser> its much more traditional disk
<psusi> smoser, have you seen the recent discard option to e2fsck?  I found a bug in it today while playing with it, but seems like it would be useful for virtual machines to be able to trim the unused space from the virtual images
<smoser> i did not know e2fsck had trim support. that is awesome.
<smoser> i dont know if it is in the qcow kvm driver though
<smoser> do you?
<smoser> i knew ext4 had trim support but i'm assuming you mean i can run 'e2fsck' with '--trim' or some such and it will make the trim calls at that point. that would be useful.
<psusi> smoser, not sure if it does it via TRIM, but you can now run e2fsck on a sparse raw disk image and it will use fallocate() to punch holes in it returning the unused sectors to sparse
<psusi> e2fsck -E discard, yea
<psusi> e2image also can now create a qcow2 image from a raw block device or sparse image and vice versa..
<psusi> and I submitted a patch the other day to add a switch allowing it to actually include all of the data blocks instead of only the metadata for debugging
<smoser> psusi, given e2image writing qcow2...
<smoser> i could use qemu-nbd for a qcow disk, point e2image at /dev/nbd0 and make a re-sparsified qcow image
<smoser> which is useful.
<william1234> h
<micahg> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg
<nigelb> "Morning" micahg
<micahg> nigelb: it *is* morning for me :)
<nigelb> Wait, where are you today?
<micahg> nigelb: it's after midnight :)
<nigelb> See, I did have in my mind that you were in Chicago and its horribly late there :)
<micahg> nigelb: yes :)
 * micahg will brb
<nigelb> :)
<micahg> can I get a TB member to set this to merged: https://code.launchpad.net/~l3on/ubuntu/natty/gdevilspie/fix-for-783568/+merge/89717
<pitti> Good morning
<ajmitch> morning pitti
<micahg> hi pitti, can you set the above merge to merged?
<pitti> micahg: done
<micahg> thanks
<nigelb> Morning pitti!
<nigelb> evening ajmitch :)
<ajmitch> hi nigelb :)
<dholbach> good morning
<micahg> pitti: with https://launchpad.net/ubuntu/+source/packagekit/0.7.2-2ubuntu3, did you mean to drop the packagekit recommends as well and not just the aptd alternative?
<pitti> micahg: yes, I did; libraries should not usually depend on a daemon
<pitti> I explained some details in the recent PK sync request
<pitti> we can reintroduce the alternative depends if we explicitly seed aptdaemon-pkcompat
<micahg> ah, haha, sorry, didn't scroll down far enough apparently :-/
<micahg> pitti: so, the new version has all the ubuntu patches, should I go ahead and seed the pkcompat alternative and if so where specifically?
<pitti> micahg: yes, please; in the ubuntu "desktop" seed
<micahg> ok, will do
<pitti> cheers
<GunnarHj> micahg: Hi Micah! Could you please merge https://code.launchpad.net/~gunnarhj/gnome-settings-daemon/patch43/+merge/91210 ? It ought to be harmless, since it's just a description update. :)
<micahg> GunnarHj: sure, I can have a look when I'm done with packagekit
<GunnarHj> micahg: Great, thanks.
<micahg> pitti: is a recommends in the seed enough or do we need a depends?
<pitti> micahg: recommends is fine
<micahg> pitti: I assume I need a meta upload before I can sync packagekit?
<pitti> micahg: it should actually work without it these days
<micahg> ok, are we worried about packagekit being pulled into desktops?
<pitti> micahg: the metapackage is just for upgrades, I think livefses are built out of the seed bzr branches
<pitti> micahg: yes, we don't want PK, we want aptdaemon-pkcompat
<micahg> oh, right, desktops will already have the alternative fulfilled :)
<pitti> PK is slow, doesn't work with debconf etc., and the aptcc backend doesn't support plugins, etc.
<micahg> I was worried about it being pulled in on upgrade, but that shouldn't happen
<pitti> micahg: well, we do need a -meta upload at some point of course
<micahg> pitti: the apt backend is enabled in Debian now, do we want this?  I guess this needs an FFe as well
<pitti> micahg: yes, we want this
<micahg> pitti: can I take that as an FFe as well :)
<pitti> it has tests and is the more active one
<micahg> pitti: also, do we need your apt_fixes patch now?
<pitti> micahg: and again, we don't even install it by default, so fine for me
<pitti> micahg: it would make sense now, but I don't depend on it
<pitti> I think it's fine to wait for a new upstream release to get the fixes
<pitti> until then, plugins will only work with aptdaemon
<pitti> micahg: the only patch that we need is the backport for the LANGUAGE_SUPPORT enum
<micahg> yep, that one is there
<micahg> ok, syncing
<jokerdino> here i am
<micahg> jokerdino: are you familiar with bzr at all?
<jokerdino> the problem is my network blocks the bzr port
<micahg> you can do bzr over ssh
<jokerdino> guide me please.
 * micahg thought the default was bzr+ssh
<micahg> bzr branch lp:software-center
<jokerdino> i branched it and edited the file there.
<micahg> jokerdino: you're most of the way done then, just bzr push lp:~yourusername/software-center/nameyourbranchhere
<jokerdino> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<jokerdino> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<micahg> after that you should be able to bzr lp-open and propose a merge the gui way or bzr lp-propose should let you skip a step
<jokerdino> The network is blocking the port, i think
<micahg> ah, let me see if I can find out what to do about that
<astraljava> screwcork?
<astraljava> err... corkscrew :D
<micahg> jokerdino: unfortunately, launchpad doesn't have a workaround for your issue at the moment, but now you can make a proper diff, (bzr diff -c-1) and attach that to the bug
<jokerdino> i see. thanks!
<astraljava> jokerdino: If you can install corkscrew, it can be easily configured so it reroutes ssh protocol through http port (80) proxy, which is what I'd presume your network utilizes (when they're blocking port 22 anyway).
<jokerdino> yeah it only allows port 80
<jokerdino> what parameters should I pass for corkscrew to work?
<astraljava> It needs a conf file. Let me find a link that explains how you configure it.
<astraljava> jokerdino: http://wiki.linuxquestions.org/wiki/Corkscrew  -- Actually, you configure your ssh to tunnel through that, sorry. Have a go, if you like. But be aware, that this might be against your information management policies. :-/
<jokerdino> astraljava: i tried but i get this error.
<jokerdino> Couldn't establish connection to proxy: Network is unreachable
<jokerdino> ssh_exchange_identification: Connection closed by remote host
<astraljava> jokerdino: Did you find out your proxy server and port?
<jokerdino> oh, ooops. i put the wrong one.
<jokerdino> where do i find the proxy server and the port?
<sveinse> For development: Does anyone know what the apt.config option is for setting options to dpkg? --force-confnew to be specific?
<astraljava> jokerdino: I don't know, do you have browser auto-configuration maybe? It might have that information somewhere in the settings.
<astraljava> jokerdino: Otherwise, maybe see the hops when you're tracing them to a website or something.
<jokerdino> astraljava: i don't seem to make much progress here. i am just going to heave a sigh of frustration and leave it aside. :/
<astraljava> jokerdino: Yeah, just go with the patch route micahg suggested. That was a long shot, anyway.
<astraljava> It works in some networks, but not nearly all of them, and I have no idea why.
<jokerdino> yeah, touch luck here.
<jokerdino> anyway, i appreciate your help
<astraljava> No worries. It's just a handy tool, if you get it working.
<micahg> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  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:
<Whoopie> Hi, I would like to get 2 patches pushed for the remmina package. It's bug report #926619 and #931336. The patches are two usability patches to re-add the desktop file and tray icon (appindicator) support.
<tumbleweed> !sponsorship | Whoopie
<ubottu> Whoopie: You can find out about the package sponsorship process here http://wiki.ubuntu.com/SponsorshipProcess - For !UDS sponsorship see http://uds.ubuntu.com/participate/sponsorship/
<mainerror> Stupid question incoming. What does "PTS BTS" mean on the build failures site?
<tumbleweed> PTS = package tracking system. BTS = bug tracking system
<tumbleweed> (they're both Debian systems)
<mainerror> Oh, I see. Thanks. :)
<Whoopie> tumbleweed: ok, both bug reports already have ubuntu-sponsors subscribed as a debdiff was attached. But how long should I wait to get feddback from a sponsors member? Because I don't want to be impolite or impatient.
<tumbleweed> normally, a couple of days
<tumbleweed> You could ask Ubuntu desktop people to look at it, the missing .desktop file is fairly important
<tumbleweed> the package currently doesn't deviate from Debian, so it would be nice if those changes could be included in Debian (eventually)
<seb128> Whoopie, tumbleweed: I will try to get the patch reviewed today
<ryao> Are all packages in Ubuntu Precise being compiled with GCC 4.6.2?
<ryao> I am specifically interested in knowing how grub is being compiled: http://packages.ubuntu.com/precise/grub
<ryao> Nevermind. I will ask in the kernel team channel.
<ryao> I am back here because cking asked me to ask my GCC question in this channel.
<Whoopie> seb128: thanks!
<cnd> didrocks, are you an archive admin who can approve NEW packages?
<pitti> cking: FYI, http://www.piware.de/2012/02/power-usage-report-find-power-drain-causes/
<didrocks> cnd: yes
<cnd> didrocks, do you have time to review xorg-gtest (and hopefully approve)?
<cnd> it was uploaded right before feature freeze :)
<didrocks> cnd: will have a look, sure :)
<cnd> thanks!
<evfool> jibel, when you'll have the time, please my synaptic merge proposal at lp:~evfool/synaptic/ancientfixes
<evfool> ^*please review
<ryao> cjwatson: Do you know if the grub package in 12.04 is being compiled with GCC 4.6 or who would know?
<ajmitch> ryao: the build logs are linked from the launchpad page - from the log, it appears that gcc 4.6.2 is used
<ryao> ajmitch: How do I view that?
<ajmitch> ryao: from https://launchpad.net/ubuntu/+source/grub, you can see the version in precise, the build logs are on the amd64 or i386 links in that section
<ryao> Cool. Thanks. :)
<cking> pitti, I'll spread the word too
<pitti> Daviey, zul: will there be some kind of formal regression testing on the oneiric-proposed nova upload? (It's been in -proposed for two months now)
<GunnarHj> micahg: Added a comment to https://code.launchpad.net/~gunnarhj/gnome-settings-daemon/patch43/+merge/91210. I think the description is ok, after all.
<jdstrand> doko: hi. fyi, I just filed bug #937825. I am not blocked but thought I would at least file the bug as it might affect others.
<ubottu> Launchpad bug 937825 in python2.7 (Ubuntu) "change in urlopen behavior" [Undecided,New] https://launchpad.net/bugs/937825
<beuno> pitti, this new awesome power usage tool, I installed it and it seems to want a specific version of powertop not in Precise: powertop-1.13 not found, please install it.
<pitti> beuno: sudo apt-get install powertop-1.13
<pitti> beuno: unfortunately the current powertop doesn't provide what we need any more
<beuno> pitti, ah! :)  thanks
<beuno> should it be a dependency of fatrace?
<pitti> beuno: well, admittedly fatrace is not the most appropriate place for the script
<pitti> but I didn't think of a better one
<pitti> fatrace itself has nothing to do with powertop
<pitti> it started out as just a script somewhere, but it seemed useful to put it into the distro
<jdstrand> barry: hi!, you may be interested in ^ as well
<beuno> pitti, 1.13 seems to have a problem installing: https://pastebin.canonical.com/60652/  (and apport hit MaxReports again somehow!)
<pitti> powertop-1 1.13-0ubuntu1~dooz1
<pitti> beuno: ^ that's not ubuntu's fault
<pitti> seems you previously activated some PPA or so
<beuno> ah
<barry> jdstrand: looking
<jdstrand> I'm not sure what we want to do as the bug says that './' is incorrect usage, however, it seems people will hit this issue
<doko> **ck ... third X crash today :-(((
<Whoopie> seb128: Would you prefer 1 debdiff with all patches included for remmina? I could prepare it.
<seb128> Whoopie, that would be better, but wasn't one of the debdiff including both fixes? just had a quick glance to the comments
<seb128> Whoopie, btw did you test that indicator works? pitti said he tried to enable it but nothing was displaying under unity
<Whoopie> seb128: no, both debdiffs include 1 fix. I prepare one.
<pitti> Whoopie: I just enabled the build time option and added the build dep, it's in ubuntu-desktop
<pitti> but I coudln't make it work
<seb128> Whoopie, he didn't use your version, just compiled with it enabled (the build log shows it's using it)
<Whoopie> seb128: regarding unity, I need to check. running gnome-session-fallback here.
<seb128> Whoopie, did you try with indicator-applet on gnome-session?
<Whoopie> seb128: yes, working fine.
<Whoopie> seb128: ah, I ran Unity by accident some days ago, and the remmina tray icon was shown.
<seb128> Whoopie, ok, don't worry then, I will test in a bit and let you know if I have issues
<Whoopie> seb128: preparing the debdiff right now.
<pitti> janimo`: are you going to upload a new linux-meta-ac100 soon?
<pitti> janimo`: for 3.0.19-1
<m4n1sh> ev: I still get undefined symbol  whoopsie_daisy_preferences_new
<m4n1sh> full log here
<m4n1sh> https://code.launchpad.net/~ev/activity-log-manager/whoopsie/+merge/93899
<ev> m4n1sh: I'll have a look in a bit - buried in something else at the moment
<m4n1sh> sure
<m4n1sh> just informed you. take your time. Will release it tomorrow same time
<ev> sure thing
<ev> cheers!
<Whoopie> seb128: I attached the all-in-one debdiff to bug report #931336.
<janimo`> pitti, yes planning to, just making sure noone had a regerssion
<janimo`> is it holding up something/confusing some tools?
<seb128> Whoopie, thanks
<pitti> janimo`: it's preventing the removal of the old binaries (http://people.canonical.com/~ubuntu-archive/nbs.html)
<pitti> janimo`: that's how I noticed
<janimo`> pitti, ok. I was trying to be conservative and letting people test the package but not autoupgrade yet, thanks for the prod though
<pitti> janimo`: ah, ok; it's not that urgent, just wanted to ensure it's known and handled; thanks!
<janimo`> pitti, yes, known and soon handled :)
<pitti> cjwatson, barry, SpamapS, infinity: FYI, I updated britney to have armhf on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html now, and armel on http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html
<pitti> (with the next run)
<pitti> and then we need some more hamster food to make LibO finish building on armhf :)
<moustafa> ping ubuntu-devel
<moustafa> Is there any documentation as to what's installed (or not installed) when a user selects the free software only option from the installation disc?
<jml> I appear to have a broken apt: http://paste.ubuntu.com/851468/
<jml> "E: Internal Error, No file name for libc6"
<doko> hallyn, please could you add a reproducer to bug #933045?
<ubottu> Launchpad bug 933045 in linux (Ubuntu) "headers incompatible with eglibc" [Medium,Triaged] https://launchpad.net/bugs/933045
<doko> pitti: looking at /etc/init/lightdm.conf ... is there a preferred why how to look for the currently running/active login manager?
<doko> seb128, mterry: ^^^
<seb128> not that I know about
<seb128> doko, /etc/X11/default-display-manager has the default login manager
<seb128> but nothing garante you it's the running one
<seb128> i.e you can sudo stop lightdm and sudo start gdm
<mterry> not that I know of either
<mterry> doko, for active, you could try various dbus addresses to probe for which is active
<doko> mterry, do you have a shell snippet to do that?
<doko> and: should lightdm restarted on NSS updates, like gdm was?
<mterry> doko, no...  but I believe gdm registers org.gnome.DisplayManager and lightdm does org.freedesktop.DisplayManager.  Not sure about kdm
<cyphermox> moustafa: to answer your question, I believe all it changes is whether restricted and multiverse are enabled (and thus whether packages like ubuntu-restricted-* are installed, or drivers such as the nvidia ones)
<chrisccoulson> doko - mozilla bug 694594 wasn't a compiler bug after all ;)
<ubottu> Mozilla bug 694594 in JavaScript Engine "Crashes with gcc 4.4.3" [Critical,New: ] http://bugzilla.mozilla.org/show_bug.cgi?id=694594
<chrisccoulson> or, at least i don't think it is
<moustafa> cyphermox, So, little to no info?
<cyphermox> moustafa: what do you mean?
<moustafa> cyphermox, The person asking is looking for a list.  No mention of how specific that list should be
<cyphermox> moustafa: I guess from there you could easily grep through Packages for multiverse and restricted to generate that list, if it's indeed the only different
<doko> chrisccoulson, heh, interesting investigation, I assume ...
<chrisccoulson> yeah ;)
<moustafa> cyphermox, Good point
<cyphermox> moustafa: also keep in mind that there's probably a very small list if what you're worried about is just what would get installed by default
<cyphermox> moustafa: fwiw I checked by looking at the code in ubiquity. it would be worth looking at d-i as well maybe
<Whoopie> seb128, pitti: I know why pitti's compiled version didn't work. Mine works because I wrote a patch to re-add trayicon support. The -i option was missing. Just FYI.
<pitti> Whoopie: right, I didn't have that patch
<seb128> Whoopie, yours doesn't work for me, just looking at it
<pitti> Whoopie: but there's a configuration tab to enable applet support, nobody will explicitly specify it on the command line?
<Whoopie> pitti: true, but the -i option is used when you tick the option in the applet.
<pitti> aah
<Whoopie> seb128: strange. Do you have the remmina-applet.desktop in ~/.config/autostart ?
<seb128> Whoopie, I didn't restart my session, but there is no remmina-applet installed here
<seb128> $ find remmina-1.0.0 -name remmina-applet*
<seb128> $
<Whoopie> seb128: did you enable the option in the applet. It should write the desktop file then.
<seb128> Whoopie, what applet? I apt-get sourced the precise version, applied your patch, debuild, dpkg -i *.deb and I'm running remmina now
<Whoopie> seb128: there's no remmina-applet installed. It's still the remmina binary which got appindicator support. Please enable Settings -> Applet -> Start tray icon automatically.
<Whoopie> seb128: Then check if the desktop file is written under ~/.config/autostart
<seb128> Whoopie, my build is buggy, hate quilt ;-)
<seb128> Whoopie, rebuilding
<Whoopie> seb128: and if you run remmina, you should see the appindicator icon.
<Whoopie> seb128: ok
<seb128> Whoopie, apt-get source unpackaged and applied the patches, patch -p0 < debdiff applied the diff but debuild built without applying the new patches
<seb128> i.e I had an half serie applied
<seb128> Whoopie, ok, it works now ;-)
<seb128> the menu starts by a separator but otherwise it works ;-)
<pitti> seb128: nice!
<Whoopie> seb128: uff, great. ;-)
<seb128> Whoopie, I don't like that "create an autostart for me though"
<seb128> what I want is an indicator when I run remmina
<seb128> not remmina to start with every session when I need it once a week
<seb128> it's eating my boot time for no good reason this way :-(
<Whoopie> seb128: right, but if you tick that option, you need that -i option. Otherwise, remmina isn't started.
<Whoopie> seb128: you don't need to enable the option to have an appindicator. It's independent.
<seb128> Whoopie, ok, that seems to work fine, I clicked that option for the same reason than pitti, to try to get an icon when it was buggy
<seb128> Whoopie, I will sponsor that in a bit, thanks for the work!
<Whoopie> seb128: thanks! and very welcome!
<pitti> doko, infinity: looks like armhf needs a bootstrap of gnat-4.6; is that planned, or sohuld we just ignore the depwaits/failures for this on armhf?
<Whoopie> pitti: regarding report #937548, does it mean that we wait until vpnc hits testing? Or can it be synced "right now"?
<pitti> Whoopie: technically it can be synced right now
<pitti> Whoopie: do you know if anyone actually tested the new version with our network-manager plugin etc.?
<Whoopie> pitti: I did. :-)
<pitti> nice
<Whoopie> pitti: that's why I wanted to get it synced. I tested a build in my PPA.
<pitti> Whoopie: synced, thanks
<Whoopie> pitti: awesome, thanks!
<moustafa> cyphermox, Why did I just see your Ubiquity response:?
 * moustafa slaps self
<cyphermox> err, I don't know. bad IRC? :)
<dholbach> barry, could it be that sphinx is waiting on python-whoosh to go to main?
<dholbach> seems it's needed for the test-suite
<dholbach> barry, it seems if you just drop python-whoosh the tests using it are skipped (not many AFAICS)
<dholbach> but I'll leave the decision to you
<SpamapS> dpkg experts.. anybody have ideas about this one:
<SpamapS> http://paste.ubuntu.com/851662/
<SpamapS> Never seen 'E: Internal Error, No file name for libc6'
<m_3> SpamapS: googling for related bugs seemed to hint at multiarch
<m_3> SpamapS: and a purge, then reinstall all avail archs worked for them
<m_3> SpamapS: but on libc6...
 * m_3 sad
<jdstrand> stgraber: fyi, I tested your isc-dhcp packages (client). the apparmor bits seem to be working fine
<stgraber> jdstrand: thanks
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  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: barry
<micahg> barry: if you get a chance, can you merge claws-mail-extra-plugins from Debian (one of the last things holding clutter-gtk-0.10 in precise)
<jtaylor> barry: is sphinx shill going to get sorted out? I can'f find a mir for it
<jtaylor> the numpy transition is done btw
<barry> jtaylor: i'm doing a test build right now to drop whoosh dep (after consultation with upstream maintainer).  will upload when local build completes
<barry> jtaylor: yay on numpy!
<barry> micahg: yep, will do
<micahg> thanks
<barry> micahg: hmm. i think we'd need to upgrade both claws-mail and claws-mail-extra-plugins to 3.8.0.  we currently have 3.7.10.  i'm a claws users so i do care and will continue to watch it closely, but i think we're going to need an ffe for this.  what do you think?
<barry> micahg: fwiw, i'd be in favor of moving to 3.8.0
<micahg> barry: probably needs an FFe
<barry> micahg: yeah.  i'll get that started
<barry> aarg, the bongos are back!
<ska> Can someone test TexLive's envlab ? I think i found a problem and fixed it but need confirmation.
<ska> I'll provide the letter.tex file to test with.
<ska> should I contact the maintainer directly?
<barry> ScottK: thanks!
<ScottK> barry: I knew you'd watch after it.
<barry> yep :)
<dobey> ScottK, Riddell: i attached .debian.tar.gz and .dsc for pyqt4 splitting work to bug #934270
<ubottu> Launchpad bug 934270 in ubuntuone-control-panel (Ubuntu) "We need to drop the current GTK+ UI in favor of the Qt UI" [Undecided,New] https://launchpad.net/bugs/934270
<ScottK> dobey: Could you attach a debdiff from the current package.
<dobey> ScottK: is there an easy way to generate a debdiff, from the bzr branch?
<ScottK> No idea.
<ScottK> But if you've got the .dsc it's easy enough to do.
<ScottK> Where's the bzr branch?
<ScottK> I should be able to look at that diff (same content as the debdiff, I hope)
<TheMuso> barry: Just mute audio in unity-greeter, problem solved.
<barry> TheMuso: if that only mutes the greeter and doesn't mute the session, then that would be fine
<TheMuso> barry: I think at the moment it does, or it did. I know there are plans to sync the user's audio settings with their logged in session.
<barry> TheMuso: that would be ideal.
<dobey> ScottK: lp:~dobey/ubuntu/precise/python-qt4/split-work
<ScottK> dobey: That's going to break any package that depends on python-qt4 and uses the extensions you've now split out.
<dobey> ScottK: yes, well. eggs omelette. that is obvious, and i don't knkow what packages those are. and we can't just Recommends: the spllit packages, because they'd then also end up on the CD which would defeat the whole purpose of splitting them out
<ScottK> I understand.
<ScottK> So that means there needs to be some way to figure it out and fix the relevant packages.
<ScottK> We're post Feature Freeze, so "Meh, we'll sort it out later" isn't going to cut it.
<broder> dobey: wait, why can't you recommends the split packages?
<dobey> well it should be easy to sort out, if a tiny bit tedious
<ScottK> I'd also need to sort it out before I could accept it in Debian, so it still needs to be sorted.
<broder> i haven't looked at the work, but why not split it out into python-qt4-{core,gui,etc} then only depend on what you need?
<dobey> broder: because recommends would get pulled onto CD if we stick it on the CD
<broder> then python-qt4 is a compatibility package that pulls everything in
<ScottK> broder: What about the existing packages that depend on python-qt4 and need some of all those?
<ScottK> Right, something like that might work.
<dobey> broder: yes, that's basically what i'm doing, except "core" is still python-qt4
<broder> dobey: so why not split it out as well?
<ScottK> Although if you're making all new packages, you ought to follow python policy and make them python-pyqt4.core, etc.
<dobey> broder: because i was trying to minimize the change set, and only add split packages; not re-do the whole package
<ScottK> I don't think it's avoidable.
<dobey> meh, there's quite a bit of stuff that depends python-qt4 too :-/
<ScottK> Yes.  Yes there is.
<ScottK> So if you can make python-qt4 a dependency package that ends up with exactly the same stuff installed, you can avoid yourself a lot of work.
<ScottK> Then you can depend on exactly the bits you need.
<dobey> though if we're not going to find space on the CD for what we need anyway, i think i'd rather avoid making the change in precise, and just do it in quetzel
<infinity> No, split now.
<infinity> And make python-qt4 depend on the split bits.
<infinity> Having that established in an LTS will get people used to the new world order.
<infinity> Worst case, nothing changes at all.
<infinity> Best case, you shuffle around deps on a lot of packages and potentially slim down install footprint here and there.
<dobey> well, except i don't want to spend a lot of time doing that work, when it doesn't gain my team anything in the release, when i could be spending my time fixing bugs and doing stuff we need to get done, instead :)
<ScottK> By the time Precise is released, Debian freeze for Wheezy will be close.
<ScottK> I wouldn't support doing this split as an Ubuntu only change.
<ScottK> Better do it now if you think you want it for questionable.
<barry> jbicha, Riddell ping
<barry> or ping anyone else on ~ubuntu-core-doc
<barry> so here's my question: this merge proposal is obviously correct and i can easily sponsor it: https://code.launchpad.net/~dpolehn-gmail/kubuntu-docs/fix-818500/+merge/90239
<barry> but it's a native package and i can't commit to lp:kubuntu-docs.  i'm leery of uploading the package w/o committing to trunk since they'll skew.  maybe i should just not sponsor it?
<ScottK> barry: Can you ping Darkwing on #kubuntu-devel about it?
<barry> ScottK: yep, thanks
<stgraber> slangasek: GrueMaster tells me our live-build images now have /etc/resolvconf/resolv.conf.d/tail containing Canonical DC information ;)
<slangasek> hmmmm
<slangasek> I guess we should fix that!
<infinity> If this is the new world order (and I suppost resolvconf's postinst makes some sense), maybe the solution is just to whack /etc/resolvconf/resolv.conf.d/tail in the cleanup phase in live-build.
<infinity> And /etc/resolvconf/resolv.conf.d/original
<infinity> Or, really, the entire contents of /etc/resolvconf/resolv.conf.d/ :P
<stgraber> base and head should be safe, the rest shouldn't be there indeed
<infinity> Mmkay, I shall apply that hammer, then.
<infinity> Seems less fiddly than worrying about it either in resolveconf.postinst or in various installers.
<stgraber> there's really no good reason to have DC dns data on the system anyway, so we probably should a rm -f of tail and original sounds good
<slangasek> infinity: yes, I certainly wasn't looking at resolvconf for the fix
<slangasek> live-build cleanup seems like a good place to whack it
<slangasek> infinity: are you taking care of this then?
<infinity> stgraber: Yeah, live-build used to already delete resolv.conf in the cleanup phase, so we just need to do the new equivalent of the same.
<infinity> slangasek: Sure.
<slangasek> ta
<stgraber> infinity: I already have a live-build patch for resolvconf, so we'd need to update it and forward the change to Debian (where the previous patch was recently merged)
<infinity> stgraber: Righto.
<GrueMaster> So for now I can just wipe the tail and reboot?
<stgraber> GrueMaster: removing tail and running "resolvconf -m" should do trick
<slangasek> or wipe the tail and run service resolvconf restart
 * slangasek nods
<stgraber> *resolvconf -u
<GrueMaster> Still have an issue where it is only looking to 127.0.0.1 for nameserver.
<GrueMaster> Doesn't seem to matter though.
 * GrueMaster is lost & confused.
<infinity> Are installing dnsmasq or something by default now too?
<infinity> That would explain the 127.0.0.1
<slangasek> yes
<slangasek> nm pulls in dnsmasq-base and runs it by default
<slangasek> provides better responsiveness in the case of unreachable servers, and enables better split-dns handling with vpns
<infinity> Makes resolvconf feel vaguely redundant, if it's all being managed by dnsmasq anyway.
<slangasek> dnsmasq is only on the desktop :)
<slangasek> resolvconf also fixes some server-side issues
<slangasek> like dhclient trying to write to /etc before it's rw
 * infinity nods.
<infinity> Seems like, in that case, you coud replace the whole resolvconf mechanic with a simple early-run init job that just does mkdir /run/resolvconf && ln -s /run/resolvconf/resolv.conf /etc/resolv.conf
<slangasek> what creates /run/resolvconf/resolv.conf?
<infinity> Well, dhclient happily writes its own.
<infinity> Perhaps a touch would be required.
<slangasek> nah, it writes it to /etc/resolv.conf
<infinity> Yes, hence the link.
 * slangasek looks puzzled
<slangasek> oh, you mean let dhclient write through the link?
<infinity> Yeah.
<slangasek> haven't tested that it'll do that
<slangasek> don't really want to, because it's ridiculous to have 10 different code paths for updating resolv.conf
 * Chipzz wonders where the time went linux was simple
<Chipzz> this all sounds like a bunch of crack tbh
<slangasek> it was never simple, it just failed in a familiar way
<infinity> *shrug*... If the whole world works with resolvconf eventually, I don't much care.  I just have so many horrible memories. :P
<GrueMaster> Chipzz: We released the 2.0 kernel.
<Chipzz> exactly how many *daemons* do you want running on a desmtop system?
<slangasek> infinity: yes; foundations has taken ownership of resolvconf though, and I've been pruning ;)
 * Chipzz shakes his head in disbelief
<infinity> slangasek: I guess I was just driving at the idea that "pruning" could have just been a question of providing a link and making sure other things correctly wrote through a link. ;)
<slangasek> yeah, I know
<slangasek> but that leaves corner cases unaddressed
<slangasek> which means you'd still have *two* ways to manage /etc/resolv.conf, and have therefore not actually simplified ;)
<Chipzz> seriously, maybe some things should just fail in a natural way?
<Chipzz> what's next? installing quagga becuase your ISP's routing might be broken?
 * infinity won't admit to doing that.
<Chipzz> is it really ubuntu's job to account for broken DNS servers?
<broder> Chipzz: absolutely. no question
<broder> every other major os does this
<broder> and broken DNS is responsible for a significant percentage of perceived connectivity problems
<Chipzz> yes, and people should complain to their ISPs
<Chipzz> your fixing symptoms, not problems
<Chipzz> *you're
<infinity> Hrm.
<infinity> slangasek: Nothing breaks if a proper /etc/resolv.conf exists, right?
<RAOF> And sometimes fixing the symptom is the best you can do.
 * infinity is just wondering is perhaps resolvconf should be added to the ubuntu-core packageset.
<Chipzz> I'm not convinced at all that the problem should be fixed, really?
<slangasek> infinity: define "proper"?  on install and by default (debconfable), resolvconf moves aside any static /etc/resolv.conf
<Chipzz> you're not fixing a problem inherint to ubuntu
<Chipzz> *inherent
<infinity> slangasek: Right, but if resolvconf isn't on the system at all, life goes on for all the bits that (used to?) write to /etc/resolv.conf?
<Chipzz> you're not even fixing symptoms inherent of/caused by ubuntu
<slangasek> infinity: right, pretty much
<infinity> slangasek: Or have we made it so that resolvconf pretty much must exist.
<infinity> ?
<slangasek> infinity: it's a dependency of ubuntu-minimal, so ;)
<slangasek> (so yes, it should be in ubuntu-core)
<infinity> slangasek: Yes, but minimal isn't guaranteed to be installed.
<slangasek> really?
<infinity> slangasek: (And minimal isn't in core)
<slangasek> ubuntu-core subsets minimal?
<infinity> Yeah.
<slangasek> that's interesting; I wasn't aware of that decision
<infinity> By a lot.
<infinity> The core definition is basically "what you need to run apt".
<slangasek> previously, the view was "if you don't have the dependencies of ubuntu-minimal installed, you get to keep all 6 pieces"
<slangasek> ok
<slangasek> so I think it would be a good idea to have resolvconf in core
<RAOF> Chipzz: No, you're fixing a problem in the environment surrounding Ubuntu.  You wouldn't say that a kernel fix to not use an instruction known to provoke hardware bugs on certain CPUs isn't a fix; this is similar.
<slangasek> but perhaps you'd prefer to Wait and See ;)
<Chipzz> RAOF: this is not similar in any way
<infinity> slangasek: If we're to the point of saying your system is broken without resolvconf, we should just mark it Essential.
<infinity> slangasek: At which point, core gets it for free.
<Chipzz> RAOF: hardware cpu bugs are still *local*
<Chipzz> they're caused by the setup ubuntu runs on
<slangasek> infinity: that would be a serious abuse of the Essential flag
<infinity> slangasek: If it's not actually Essential, we need to make sure the world works without it.
<slangasek> we don't even have the upstart dep chain Essential :P
<slangasek> nah, alternatively we could make it non-essential-but-a-dependency
<infinity> slangasek: Well, that still makes it essential.
<infinity> slangasek: Hair-splitting.
<slangasek> moi?
<Chipzz> broken DNS is, again, an external problem. meanwhile you're bloating the desktop, installing daemons that have no place on there whatsoever
<slangasek> jamais
<infinity> slangasek: Toi.
<Chipzz> this is madness.
<RAOF> Chipzz: I don't understand why that's an interesting distinction.  If the user can't connect to the internet unless we frob $FOO; why isn't not frobbing $FOO a bug?  If the CPU will hang unless we frob $FOO, even if it's not in the spec, you agree not frobbing $FOO is a bug.
<slangasek> #ubuntu-sparta
<Chipzz> slangasek: yeah ^^ :)
<infinity> slangasek: My argument isn't so much about the flag itself but rather that is we're at a point where our networking has an undeclared dep on resolvconf to function, we need it to land in essential one way or the other.  Or fix that undeclared dep to no longer be true.
<infinity> s/that is/that if/
<slangasek> infinity: right.  nothing currently has an undeclared dep on it; and if we were to gut other packages such that they no longer work without it, I would add the dep
<Chipzz> RAOF: technically he *can* connect to the internet
<slangasek> but I'd rather talk to Debian first before that, since otherwise we pick up a delta for no good reason
<infinity> slangasek: Okay, that was the initial question.  So, not having resolvconf isn't a problem, per se, and core can go on living life as it does.
<slangasek> ok
<RAOF> Chipzz: And I'm sure that they're *super* pleased that, technically, they can connect to the internet.  They just need to manually frob some stuff in order for it to be useful at all.
<infinity> Chipzz: The internet without DNS is only the internet to a pretty tiny subset of users.
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  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: barry, TheMuso
<Chipzz> infinity: please tell me, exactly how many external problems do you intend to work around?
<infinity> Seven.
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  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: TheMuso
<Chipzz> IMO there's a distinction between diagnosing a real problem, and bloating the desktop for everyone in order to avoid a problem that MAY exist for some users
<broder> Chipzz: why *shouldn't* we do as many things as we possibly can that make clear improvements to the user experience?
<broder> there's no may here. shitty dns servers are a real problem
<Chipzz> seriously?
<broder> without question
<broder> i've run into them
<Chipzz> I've been on several ISPs. not even once have I had the kind of dns problems you describe
<slangasek> would you know if you had?
<Chipzz> I would
<slangasek> or would you just have had slower DNS resolution for a bit?
<Chipzz> there are alternatives to trying to fix the problems IMO. a *much* saner alternative would be to provide a diagnostics tool that says: "Hi, your ISPs DNS is broken. Please contact your ISP with the following information, or use nameserver x.y.z.w"
<stgraber> even in the perfect world where all the ISPs know how to run their DNS servers, they'll still advertise more than one so that you have a fallback in case of failure
<stgraber> that's all nice but the libc doesn't do that fallback in a very pleasant way
<stgraber> as in, you have to wait 3s every time you do a DNS query for the fallback to kick in
<stgraber> instead, having a local resolver will fix that as the daemon can keep state (that a library obviously can't) and so won't cause the delay every single time
<Chipzz> meanwhile what you ARE doing is diverting from existing standards, and make things a lot more opaque, for, what exactly?
<stgraber> instead you'll see a 500ms second delay the first time, then the daemon will try and reach the server in the background and use it again when it's back
<stgraber> please point me to the standard saying that OS shouldn't run a local resolver, because if such standard exists, well, pretty much nobody respects it
<infinity> Chipzz: To be fair, the subest of people who care about opacity of /etc/resolv.conf are the same tiny subset of people who also know how to use the internet without DNS resolution.
<infinity> Chipzz: We're trying to fix things for the other 99% of users.
<Chipzz> infinity: I know how /e/r.c works. doesn't mean I know the IP of facebook by heart and telnet to it on port 80 :)
<infinity> Chipzz: No, but you understand what "DNS" means.
<infinity> Chipzz: Ask my mom if she does.
<barry> of course, that even assumes the isp knows how to fix the problem, or that you can even find a person on tech support that knows what "DNS" stands for
<infinity> Chipzz: And the part where you know what /etc/resolv.conf is either means (A) you got copy and paste instructions from a forum (those are so useful to follow!), or (B) you understand what it's for.
<Chipzz> so you're much happier with a status-quo of broken ISP DNS servers then?
<infinity> Chipzz: If you're in the latter camp, I'd contend that you can sort out why it might not be working.
<TheMuso> c
<TheMuso> whoops
<Chipzz> infinity: and I would be puzzled why in the name of f*ck localhost is in my resolve.conf
<Chipzz> stgraber: what's wrong with nscd?
<Chipzz> if you insist of giving the libc example
<Chipzz> *on
<Chipzz> infinity: next thing I would do is take a very deep breath, sigh, wonder where the world has gone to and install debian
<stgraber> Chipzz: no split DNS support, only caching nss entries so no particular DNS protocol awareness, does unwanted negative caching and that's before looking at the current stability issues and bugs
<stgraber> Chipzz: though it indeed as some nice feature like per-user caches and the integration in the nss stack is interesting, we actually have these mentioned in the DNS spec for Precise
<slangasek> oh man, to list all the things wrong with nscd
<Chipzz> maybe the next step should be to install squid on the desktop too
<Chipzz> you know, in case facebook goes down, people can still get a locally cached page
<slangasek> I liked the quagga idea better
<Chipzz> except that probably won't work :P
<Chipzz> but IMO you seriously need to ask yourself the question where you draw the line
<Chipzz> and IMO this is crossing the line
<infinity> stgraber: Your patch confuses me.
<infinity> stgraber: The goal was to have it not Truncate if resolv.conf was a symlink, right?
<stgraber> infinity: right
<infinity> stgraber: Oh, or only if it's a dangling link, I guess.
<infinity> stgraber: Cause if it's not dangling, [ -e ] is still true.
<stgraber> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657640
<ubottu> Debian bug 657640 in src:live-build "lb_chroot_resolv fails when /etc/resolv.conf is a symlink (resolvconf)" [Normal,Fixed]
<bdmurray> slangasek: where does /etc/apt/sources.list come from on a live cd?  I've a strange line in mine on the latest daily build
<infinity> bdmurray: How strange?
<stgraber> infinity: that was for when resolv.conf was an absolute symlinks to /run/resolvconf/resolv.conf, now we made it a relative symlink, so that code probably no longer does much (as -e will indeed succeed)
<bdmurray> infinity: cdrom:... dists/precise/main/binary-i386/
<bdmurray> infinity: whoops not that one
<bdmurray> cdrom:... precise main restricted
<infinity> stgraber: Well, yeah. ;)
<infinity> bdmurray: Depending on the contents of [...], that might be just fine.
<slangasek> bdmurray: these days I believe it's live-build
<stgraber> slangasek: if it was only for my setup and not the 99.9% of the other users, I'd definitely +1 quagga by default ;)
<bdmurray> cdrom:[Ubuntu 12.04 LTS _Precise Pangolin_ - Alpha amd64 (20120221)]/ precise main restricted
<stgraber> oh, well, then I'd also need strongswan though, because everybody needs BGP over IPSEC over IPv6 ;)
<bkerensa> stgraber: How can I set a different default pastebinit url? :)
<infinity> bdmurray: Does apt not like that?  It seems like a reasonable CD URI.
<stgraber> bkerensa: you'll need to use the ugly ~/.pastebinit.xml file for that
<stgraber> bkerensa: there's an example in the manpage
<infinity> stgraber: I'm not sure if I should be entertained or a bit annoyed that Debian took your patch wholesale without refactoring it. :P
<infinity> stgraber: Anyhow, whatever.  It DTRT on both dangling and not, I'll just add my own kludge on top.
<slangasek> infinity: oh, it embeds the CD .info, right; in that case, how is the apt repo set up?  casper?
<slangasek> apt sources.list I mean
<infinity> slangasek: On the installed system, or the livecd?
<slangasek> livecd
<stgraber> infinity: hehe, the biggest issue is that we changed resolvconf's behaviour twice since that patch was merged in Debian ;) at some point we were back to a regular file until first boot, then went with relative symlink
<slangasek> because the livefs itself can't know the CD's .info ahead of time
<bdmurray> infinity: no it didn't like it.  there are 2 lines in sources.list with cdrom in them and it liked 'dists/precise/main/' and did not like 'precise main restricted'
<stgraber> infinity: AFAIK Debian's resolvocnf still uses the absolute symlink, so I guess the check for the dangling symlink still makes sense for them :)
<infinity> slangasek: May well be some casper hackery there.
<bkerensa> stgraber: Is there anyway to make pastebinit prompt for a password for pastebin.com when sending to it?
<bkerensa> :D
<stgraber> bkerensa: no, authentication on pastebin.com doesn't work, the only pastebin supporting authentication in pastebinit is the KDE pastebin
<infinity> stgraber: Oh, I'm not even complaining about the dangling bit (it's a useful test), I'm whining a bit that it now has the "mv foo foo.orig" call twice.  I would have refactored it. ;)
<broder> slangasek, infinity: /usr/share/initramfs-tools/scripts/casper-bottom/41apt_cdrom
<bkerensa> stgraber: Oh :( ok then might as well leave it to paste.ubuntu.com  thanks for your time
<stgraber> bkerensa: pastebin.com's authentication would require a lot of scrapping or for it to be exposed on their API (which pastebinit doesn't support yet)
<broder> "chroot /root apt-cdrom -o Acquire::cdrom::mount=/cdrom -o Dir::Media::MountPath=/cdrom -o Acquire::cdrom::AutoDetect=false -m add"
<slangasek> righty-o
<stgraber> bkerensa: I'm expecting authentication to be much better supported once I get around to rewritting pastebinit entirely and having some XML/JSON RPC support in the core...
<bkerensa> :D
<stgraber> infinity: yeah, I guess the diff would have been a bit more confusing if I did that, though the Debian maintainer indeed could have done it ;) I'm guessing it'd be just as long though as you'd need to move the Truncate call into an if statement so it only applies to the non-dangling case (or, really, test -f)
<bkerensa> stgraber: It is still a nice script :)
<infinity> stgraber: Yeahp, just being anal about organisation, I guess.  Runtime wouldn't change at all.
<stgraber> bkerensa: yep, it does the job and did for a while now, so I'm a bit scared of the rewrite as it's indeed needed (looking at the feature requests I'm getting recently) but has a pretty high potential for breakage
<stgraber> unless we leave in that perfect world where people don't change their APIs
<stgraber> though so far for pastebins, I've noticed screen scrapping and filling web forms seems to be a lot more reliable than using their "well defined" APIs ;)
<infinity> stgraber: Look sane? http://lucifer.0c3.net/~adconrad/live-build.diff
 * infinity notes that needs another linefeed to match the live-build coding style.
<infinity> Some day, I'll stop editing diffs by hand.
<stgraber> infinity: yep, that should do the trick. Might be worth running a grep -r of the DC DNS server in the resulting live image just to make sure we didn't miss anything ;)
<stgraber> infinity: use quilt :P
<infinity> stgraber: Hand-editing is faster.
<infinity> If you speak fluent diff...
<stgraber> yeah, I end up doing the same quite often, then fight with quilt telling me the patches were already applied and now obviously don't match ;)
<infinity> Oh, I just patch -R, edit the patch, and re-apply.
 * infinity double-checks an image to make sure there's no more DC DNS leakage.
#ubuntu-devel 2012-02-22
<GrueMaster> So, I just found another interesting resolvconf failure.  Inside an ubuntu-core image, run "apt-get update && apt-get install ubuntu-minimal".  It will fail on resolvconf.
<GrueMaster> start: Unknown job: resolvconf
<GrueMaster> invoke-rc.d: initscript resolvconf, action "start" failed.
<GrueMaster> dpkg: error processing resolvconf (--configure):
<infinity> GrueMaster: Is that running on top of overlayfs?
<GrueMaster> No, just chroot.
<infinity> GrueMaster: Oh, uh.  It's because you don't have upstart running in the chroot.  Which is somewhat expected.  Sorry, already turned my brain off for the day. :P
<GrueMaster> (assume sudo su): tar -C Core -zxvf precise-core-armhf.tar.gz && cp /etc/resolv.conf Core/etc && chroot Core.
<infinity> GrueMaster: A policy-rc.d that prevents you from starting things would help.
<GrueMaster> Ah.  Well, this is a problem.
<infinity> GrueMaster: Installing any upstart service in a chroot would have the same result.
<GrueMaster> So, why do none of the other packages in ubuntu-minimal have this issue?
<GrueMaster> I assume there are other apps that use init.
<infinity> Because none of them install upstart services and try to run them?
<infinity> Basically, the only two ways upstart can know about a new service is either (A) running some cryptic command that I've now forgotten (but I think we should probably add it as a dpkg trigger), or (B) if upstart is running, it has an inotify hook on /etc/init.
<SpamapS> FYI, upstart works fine in chroots
<broder> initctl reload-configuration
<SpamapS> yeah that works
<broder> but you need, uh, natty's upstart or newer outside the chroot
<SpamapS> yeah
<GrueMaster> Ah, well that would be problematic then.
<SpamapS> and you don't need initctl reload-configuration for the initial start/stop .. but you do need it after that if you are chrooted on top of overlayfs, because overlayfs is broken
<SpamapS> (some inotify bug)
<GrueMaster> I wonder how our buildds did it on the babbages?
<broder> a dpkg trigger wouldn't be an unreasonable way to work around overlayfs+inotify sucking
<SpamapS> GrueMaster: no build will work if it depends on an upstart job AFAICT
<SpamapS> broder: well in mk-sbuild chroots, policy.d denies starting jobs anyway
<broder> SpamapS: right, but there's a livecd issue
<SpamapS> policy-rc.d rather.. or whatever its called
<SpamapS> broder: I think we should actually be able to fix overlayfs.. very troubling to me that its broken.
 * SpamapS wanders off to eat dinner.
<broder> good plan :)
<infinity> SpamapS: Fixing inotify in overlayfs is a much tougher problem than it looks like at first blush.  apw and I have talked circles around it a few times.
<infinity> GrueMaster: buildds have no issues with it because we use a null policy-rc.d during livefs builds.
<GrueMaster> ah
<kees> any ubuntu folks going to https://events.linuxfoundation.org/events/collaboration-summit/request-an-invitation ?
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  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:
<sephthir> I have a question regarding Ubuntu install image ISO creation, but no one seems to ever be in the #ubuntu-iso channel. Does anyone have contact info for someone who might be able to answer my question?
<broder> sephthir: just asking in here has a decent chance of finding an answer
<sephthir> Alright, I wasn't entirely sure if this was a decent place to ask. What I really need is the method by which the Ubuntu alternate install discs are created, but I can't seem to find any documentation on it. Does anyone know where I might be able to find info on how they're created?
<pitti> Good morning
<tjaalton> theres no ubotu on #ubuntu-x, how to get it back?
<micahg> tjaalton: ask in #ubuntu-irc I think
<tjaalton> micahg: ok, thanks
<micahg> pitti: for gmime2.4, if dh-cli is useful, why not duplicate it in the arch dependent build deps?
<pitti> micahg: becuase it pulls in a gazillion build depends
<pitti> and I think meebey's main point of having it in B-D-I was to allow much quicker -B builds
<micahg> ah, ok
<pitti> it's how the previous debian/rules worked
<pitti> I just inadvertently broke it when moving from "-include cli.mk" to "dh --with cli"
<pitti> (the "-" was the trick)
<micahg> \o/ powerpc backlog clear
<pitti> micahg: wait until Laney starts the ghc transition :)
<pitti> or ":(" rather
<andy7534211> I have two packages in ubuntu that have updates that I would like to get in for precise
<andy7534211> i submitted update requests last week (Bug 933299 and 933303) with a link to the packages in my PPA, but it was suggested that I wait for them to get into debian first and then get a Feature Freeze exception
<ubottu> Launchpad bug 933303 in aweather (Ubuntu) "Please upgrade aweather to version 0.7" [Undecided,New] https://launchpad.net/bugs/933303
<ubottu> Launchpad bug 933299 in libgrits (Ubuntu) "Please upgrade libgrits to version 0.7" [Undecided,New] https://launchpad.net/bugs/933299
<micahg> pitti: most of ghc won't go very far on powerpc due to ghc-ghci being dropped (unless it was added back)
<pitti> meh, is it just me, or does pretty much every UDD branch fall over due to pre-applied quilt stuff?
<andy7534211> however, they still haven't made it into Debian. should i keep waiting or should I ask someone to upload the packages from the PPA?
<micahg> andy7534211: if you're the Debian maintainer, see if one of the Ubuntu DDs would be willing to sponsor it for you
<micahg> andy7534211: since they're team maintained, have you asked in #debian-science?
<andy7534211> i emailed the debian-science list yesterday after i was unable to contact the sponsor for the packages, but i guess he saw that email because he uploaded one of the packages (it's in the Debian New queue now)
<andy7534211> but the second packages (aweather) depends on the first, so that's not in the queue yet
<micahg> ah, ok, so we should just wait then
<andy7534211> ok, i was wondering because the beta freeze is coming up and i wasn't sure if it would be possible to get a freeze exception for that
<micahg> as tumbleweed  mentioned they're leaf apps (well, co-dependent leaf apps), so an FFe shouldn't be that hard
<andy7534211> ok, so that's still true during the beta freeze as well?
<andy7534211> oh, i guess there's a `feature freeze' period between the two beta releases..
<micahg> final freeze for universe if a few days before release, that's the only period it would be almost impossible to get an exception, I don't suggest waiting an inordinately long time, but just past beta 1 (about a week from now) shouldn't be much of a problem
<micahg> s/if/is/
<andy7534211> great, thanks for clarifying that for me
<sephthir> does anyone know where I might find more information about how the ubuntu install isos are built?
<micahg> pitti: have you seen http://blog.bazaar.canonical.com/?p=405
<pitti> micahg: yes, I did; but that doesn't seem to be in precise yet
<pitti> bzr: ERROR: unknown command "quilt-commit-policy"
<poolie> mm i think this needs to be in ~/.bazaar/builddeb.conf or something
<poolie> yes
<poolie> it's not a command
<pitti> oh
<poolie> hth, let me know
<dholbach> good morning
<micahg> to refresh my memory, we can only not explicitly depend on stuff that's Priority: required and Essential:yes, right?
<kklimonda> hey, any idea if debian/ubuntu allows init scripts to take arguments?
<kklimonda> (arguments additional to status/start/stop etc.)
<kklimonda> so you can call them like "/etc/init.d/service status X")
<tumbleweed> kklimonda: http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit the single action argument is a "should" not a "must", so it's not entirely illegal.
<kklimonda> tumbleweed: hmm, not entirely illegal makes it sound like not entirely good idea :)
<tumbleweed> kklimonda: as long as it's an extra feature and "status" still works as expected, I don't see any problem
<Laney> pitti: actually I think infinity will be pulling the trigger this time ;)
<Laney> plausible deniability
<pitti> *chuckle*
<kklimonda> tumbleweed: hmm, makes sense - thanks
<pitti> Laney: I'm fairly sure the powerpc buildds won't care much :)
<Laney> heh
<tumbleweed> whoah, no ppc build queue, I'm impressed
<tumbleweed> Laney: fix that
<Laney> any one of you can start it; it's an easy merge :P
 * Laney is doing some rebuilds in Debian instead, for now
<Laney> actually two easy merges (ghc and haskell-devscripts)
<pitti> diwic, seb128: I like the new audio settings capplet; it makes more sense than the old one
<seb128> pitti, yeah, kudos to ronoc on #ubuntu-desktop as well who did most of the ui work
<diwic> pitti, thanks :-)
<seb128> (and is still doing)
<diwic> ...and christian, and Allan Day from gnome design, and...
<seb128> diwic, is that work going upstream?
<seb128> because right now we have a forked codebase :-(
<diwic> seb128, I intend to try once PulseAudio 2.0 is released
<seb128> diwic, great
<diwic> seb128, we're having some distro patches to PulseAudio 1.1 for this functionality to work, and they will (most likely) go in PulseAudio 2.0
<seb128> ok
<diwic> so I doubt upstream Gnome would take it before they have a stable PA release to test it agains.
<diwic> s/agains/against
 * diwic notices that today's updates brings in version "1.0.0-1pitti1" of remmina, and recognised the name in the version more than the application itself
<JokerInDisguise> I was following this guide http://mhall119.com/2012/02/contributing-to-unity-for-non-developers-quicklists/ . "bzr branch ubuntu:totem" fails with "OUT-OF-DATE" error. Any idea?
<Hi_the> About GoogleSoC2012
<Hi_the> improving speed of code generate by gcc
<Hi_the> sets
<Hi_the> ?
<brendand> JokerInDisguise, that's not an error. at least i see the same thing and the branch is succesful
<JokerInDisguise> brendand: not successful for me. http://paste.ubuntu.com/852530/
<brendand> JokerInDisguise, this is the error: bzr: ERROR: Target directory "" already exists.
<brendand> JokerInDisguise, what command did you run exactly?
<JokerInDisguise> bzr branch ubuntu:totem
<brendand> JokerInDisguise, does the directory 'totem' already exist?
<JokerInDisguise> bradm: No, its empty folder.
<doko> chrisccoulson, what was the reason for dropping libxul.pc?  apparently the headers are still there
<JokerInDisguise> brendand: wrong mention, sorry..
<chrisccoulson> doko, nobody should be using libxul.pc. it only existed for embedders and extensions that needed to link against libxul
<dholbach> Laney, seb128: did any of you have a bit of time to review goocanvasmm-2.0 or libgdamm5.0 in my PPA? :)
<chrisccoulson> the only thing that was using it was mozvoikko, but that is now pure-JS, so there should be nothing at all in the archive using it
<chrisccoulson> the headers might go at some point too ;)
<Laney> no sorry, just go ahead; there's nothing that can't be fixed later i'm sure
<doko> chrisccoulson, I hope not before the lts. and what should be used instead?
<chrisccoulson> doko - the only headers that should be used are the npapi headers (which i wouldn't get rid of)
<dholbach> thanks Laney, seb128
<seb128> dholbach, thanks for working on that
<dholbach> thanks murrayc and the openismus folks :)
<doko> chrisccoulson, ok, thanks
<doko> chrisccoulson, #include <npruntime.h>
<doko> #include <npfunctions.h>
<doko> are these kept as well>?
<chrisccoulson> doko, yeah, those are fine
<dholbach> seb128, Laney: uploaded
<seb128> dholbach, danke
<Laney> dholbach: sorry for not doing it
<Laney> i want to help it get into debian, but not enough fingers for all of the pies
<dholbach> I'm sure that if we stay on top of things and get glom in, we can help Murray and the Openismus maintain it afterwards - they defacto maintain it in their PPA anyway already
<doko> seb128, g_thread_init was deprecated, wasn't it? and what was the replacement?
<seb128> doko, yes it is
<seb128> doko, nothing, glib init it for you
<seb128> doko, just drop the call
<doko> seb128, and for which glib/gtk versions do I need to keep it?
<seb128> doko, it's deprecated since 2.31
<seb128> i.e this cycle
<seb128> well things should just build fine with it if you don't use G_DISABLE_DEPRECATED
<doko> hmm, glib_init isn't called in the library
<brendand> JokerInDisguise, i can't directly see what the problem is without being able to poke around. Are you using Precise?
<JokerInDisguise> brendand: yeah, I'm on Precise, fully updated.
<dholbach> geser, could it be that the results of the application of nataliabidart was not announced yet? or did I miss a memo?
<geser> dholbach: could be, the DMB lacks sometimes to reply with the result to an application on devel-permissions
<dholbach> ok
<geser> checking right now it it was acted on at least
<geser> dholbach: it was acted on, nessita has upload right for the ubuntuone packageset, so only the announcement is missing
<dholbach> excellent
<dholbach> thanks a bunch geser
 * nessita feels the ping
<nessita> hello everyone!
<dholbach> hey nessita :)
 * dholbach hugs nessita
<nessita> hola dholbach! /me hugs back :-)
<debfx> doko: yodl MIR ping, bug #920436
<ubottu> Launchpad bug 920436 in yodl (Ubuntu) "[MIR] yodl" [Undecided,New] https://launchpad.net/bugs/920436
<debfx> I really want to update zsh this cycle
<dholbach> doko, I'm not sure if barry noticed, but sphinx FTBFS because python-whoosh is in universe (it's just needed for a fraction of the test suite and builds easily without it) - what do you think we should do about it?
<tumbleweed> dholbach: I thought he uploaded a fix
<dholbach> oh yeah?
<tumbleweed> yip, it's in NEW
<dholbach> oops, yeah, you're right
<dholbach> nevermind then :)
<Cas-> doko, are you able to apply https://bitbucket.org/tarek/distribute/changeset/191f38f47256 as it's a fix to a bug introduced in distribute (0.6.16-1) update
<Cas-> this is for Oneiric
<doko> Cas-, can you file an issue and prepare a SRU?
<pitti> ev: btw, how is apport/whoopsie supposed to work after release?
<pitti> ev: usually we disable it completely in /etc/default/apport
<pitti> ev: but I suppose that would also stop whoopsie-daisy?
<seb128> ev, pitti: how is that apport,whoopsie thing supposed to work? do we still get bugs in launchpad the same way as before?
<ev> pitti: funny you should mention that. I was discussing it this morning with apw this morning
<pitti> seb128: yes, we want to, at least until the crash db can create bug reports by itself
<pitti> seb128: for now we need to upload them twice
<seb128> good
<ev> pitti: I'll have to craft a branch to move the check of /etc/default/apport to when it wants to open the browser and file in launchpad
<seb128> I was wondering if the work I put on improving GNOME hooks was going to be wasted
<pitti> ev: I noticed a couple of other regressions, e. g. it lost the ability to display an existing bug if it has a DuplicateOf field; I guess I'll file bugs for that and the issues identified in the MP
<ev> pitti: please do
<pitti> ev: we should be aware that leaving /e/d/apport enabled (i. e. the core dump and zipping) is a rather large overhead for stable releases
<pitti> as it consumes quite a bit of CPU and IO, and leaves the crashing program in limbo during that
<seb128> ev, pitti: yeah, please don't do that
<seb128> it leads to user having things "freezing" for a minute rather than going down and respawning
<ogra_> hey, but its fun on arm :P
<ev> hmm
<ev> I'm struggling to think of a way in which we do that only if the crash signature has been seen before
<ev> as the database/launchpad/whatever might not be contactable at this time
<pitti> we need the core dump to determine the crash signatuer
<ev> ah and then there's that :)
<ev> could we at least factor out the zipping?
<pitti> yes, that should work
<pitti> although that might not actually help
<ev> I was tempted to look into Snappy anyway, as it might be a bit better than gzip for sending this out
<pitti> as core dumps compress well
<pitti> so instead of writing 0.5 MB compressed you'd then write 50 MB
<pitti> so trading CPU against much larger IO
<ev> of course we could stick to gzip; what I just said is not really relevant to the discussion
<ev> right
<ev> hm
<pitti> what could help is to write data/apport in C or Vala, or find a quicker way to do the gzipping
<seb128> ev, pitti: if you let in on one stable you want at least display a dialog when the collecting start explaining which cpu usage raise and stuff hang
<ev> oh god please not vala :)
<seb128> ev, pitti: we already get quite some users in unstable series confused by that nowadays
<seb128> like their bug description is "was doing nothing and then nautilus froze for 5 minutes and closed"
<seb128> the froze for 5 minutes is apport
<pitti> ev: or we find a clever way of piping it through /bin/gzip instead of using python's gzip module
<pitti> I haven't checked whether that helps significantly
<pitti> ev: actually, writing it into a tmpfs uncompressed ought to work
<pitti> /var/run/
<pitti> then the process can die quickly at least
<ev> yeah
<ev> as for compression, I believe there are several algorithms that are less resource intensive than gzip, snappy included
<ev> whether that bit is something we can fit into 12.04, *shrugs*
<pitti> ev: I was thinking, apport could feed it without compression to /var/run/<tmpfile>
<pitti> ev: then close stdin, so that the process can die
<pitti> and then do whatever it wants with the tmpfile
<ev> right, and I guess it doesn't matter what it does after that as the process is gone
<pitti> instead of piping it thorugh the gzip module
<ev> indeed
<pitti> well, it still uses CPU/IO, but at least it doesn't hang the process
<ev> right
<pitti> and if we only want a crash signature, we don't even need to compress it, etc.
<seb128> that would be much better indeed
<pitti> we can just run gdb right away
<pitti> it's quite a different way of doing things than we do right now, though
<pitti> and in development/Launchpad bug filing mode it's not really optimal
<pitti> as you'd do the gdb call all the time, even if you don't want to file a bug
 * pitti is just brainstorming here
<ev> sure, though we should optimize for the common case, which would be the release being out the door and people using this thing for years :)
<seb128> I'm still unsure those people want to be bothered at all about software issues
<pitti> ev: bug 938700 FYI
<ubottu> Launchpad bug 938700 in apport (Ubuntu Precise) "1.92 regression: Does not open already existing bugs any more" [High,Triaged] https://launchpad.net/bugs/938700
<pitti> seb128: oh, AFAIUI the apport UI shouldn't pop up any more
<pitti> I mean, not the full one, anyway
<seb128> pitti, well still having any ui popping is annoying
<pitti> I understand it'd only send the sig to whoopsie-daisy
<pitti> it's still bothering, of course
<pitti> (and I can't say I'm a fan of that)
<ev> seb128: the only way we're ever going to get a real picture of the most pressing issues is if we ask everyone
<pitti> I still think we should disable it after 6 months or so after it's out
<ev> hey, I'd love it to all happen in the background
<seb128> ev, well, users are not beta testers ;-)
<seb128> especially seeing how few issues we fix on stable compared to the number of report
<seb128> we keep getting annoyed user asking why we bother them and make them send feedback if we don't fix bugs in stable anyway
<ev> seb128: I'm not pretending users are beta testers. But if we don't find out what's going wrong on people's machines post-release, regardless of whether they're a developer, technical user, or anyone else, then we'll only have a very narrow and potentially inaccurate picture of the quality of the software we ship
<seb128> which is a somewhat misleading view, we fix bugs, but yeah we know about issues before shipping stable
<seb128> ev, we know our software is buggy and we know before shipping it
<ev> we're not filing bugs with this, and that's part of the point. The interface isn't creating an expectation that something's going to be fixed and there's something you can follow along with
<ev> seb128: :D
<ev> it's definitely a fire and forget thing here
<seb128> ev, well I still think it annoys users for no good reason
<seb128> we already know about the major issues and we already don't work on those because we don't have the manpower, priorities, etc
<ev> we don't know about the major issues
<seb128> we do
<ev> what if there's a problem in a piece of software that's more commonly used by the vast majority of our users than by developers and beta testers?
<seb128> or said differently, your system applied to an unstable cycle gives enough metric to know
<ev> ah
<ev> that still falls under my previous point
<seb128> but otherwise what pitti said
<seb128> we should probably disable it after 3 months of a stable cycle then
<ev> it will skew the results to the behavior of early adopters
<seb128> by then we get enough datas
<seb128> no point to annoy user for 5 years when we don't fix most bugs on stable anyway
<seb128> it could be different if we were actively maintaining stable versions
<ev> seb128: and if something completely falls apart four years in and affects 80% of our users on a stable release? Shouldn't we at least have the data so we can make an informed decision on whether we should be investing the resources in fixing it?
<ev> every other serious operating system out there does this
<ev> on OSX and Windows, crash reporting is a continuous thing, throughout the entire lifecycle of the product
<seb128> ev, yeah, sorry for sidetracking the discussion on that
<seb128> ev, it's something I always hated in microsoft oses and liked in Ubuntu, no annoying dialog about issues in stable versions
<ScottK> I think it's an assumption that you learn enough about the crashes pre-release to consider what needs post-release changes.
<seb128> ev, I got people who stop what they are doing and call for help when they get one of those under windows
<ev> seb128: you can turn it off very easily via the control center
<seb128> ev, the people who stop what they were doing and come to call for help when they get one of those dialogs don't go to system settings though
<seb128> ev, but yeah, it's a tradeoff, I'm not convinced the change is a win
<seb128> but that's not a situation where there is a clear win
<seb128> there are side cost either way
<ev> seb128: we'll surely see whether we know more or not once the release is out the door and this project has had a bit of time to mature
<seb128> right
<seb128> ev, it's just that I've the feeling that we know about hundred of importants bugs but don't have any resources to work on them anyway
<seb128> so adding to that list is not going to help a lot
<seb128> but let's see maybe it shows a different picture and will be useful ;-)
<ev> indeed, just think of it as a better bug heat algorithm, if that helps :)
<seb128> I will be interested to compare what comes out of it and how that matches or not our current picture
<seb128> ev, if the pictures are similar though I might try pushing to have it turned off in stable versions for the benefit of users :p
<ev> seb128: you're welcome to make any argument you want. I'll be sure to have plenty of counter arguments ready :-P
<seb128> ev, ;-)
<ev> and failing that, pistols at dawn!
<pitti> ev: my current collection: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=whoopsie-merge
<seb128> ev, anyway I didn't mean that discussion to be negative, I'm really looking forward have a db and all your work landing
<pitti> ev: I subscribed mpt to the two design-ish ones, as you said in teh MP
<seb128> ev, I'm mostly discussing details ;-)
<ev> seb128: absolutely, and I appreciate that
<ev> pitti: cheers!
<ev> pitti: I'll add to that tag as I see bugs, and fix them as quickly as I can
<sforshee> seb128, re bug 933710, gnome upstream has commented on the upstream bug report that the workaround I supplied makes sense, as the required support isn't likely to be added to X in the short term. Can we go ahead and get the workaround (or something similar) applied?
<ubottu> Launchpad bug 933710 in xserver-xorg-video-intel (Ubuntu Precise) "Laptops with eDP panels do not suspend when lid closed" [Critical,Confirmed] https://launchpad.net/bugs/933710
<pitti> ev: I guess we'll leave the two design ones for mpt to return?
<pitti> ev: (I don't think either is particularly importnat)
<pitti> ev: the "known bug" one is fairly important, though; do you want to look into this, or want me to?
<pitti> ev: nice gtk test suite, btw!
<ev> pitti: I don't mind, I can look at it now if you're busy
<ev> pitti: cheers on the test suite. If you're unfamiliar with Mock and need help understanding it, do let me know
<pitti> ev: I'm chasing apport bugs, but different ones
<ev> it's a wonderful tool in small doses
<ev> okay, I'll have a look
<pitti> ev: I have recently used a different mocking library (in aptdaemon), but not this one
<pitti> ev: so @patch.object(GTKUserInterface, 'can_examine_locally')
<pitti> ev: that means, you can pre-set a return value, and it records if it was called, and delivers that?
<pitti> ev: I do that in the main test suite, but with something like myobject.mymethod = lambda self, args: return 'foo'
<ev> pitti: it means, turn the member can_examine_locally into a Mock object.  At the end of this method, return the member to its original value
<ev> the
<ev> any call to the mock object will succeed, and any member or method on that mock object will magically exist
<ev> return_value sets what actually gets returned on method calls
<ev> and yes, it also tracks calls
<ev> so you can assert that a function was called with particular arguments
<ev> For what it's worth, Michael Foord, who works for Canonical, is the upstream author
<pitti> ev: I guess we'll leave the two design ones for mpt to return?        self.app.get_desktop_entry.return_value.getIcon.return_value = 'nonexistent'
<pitti> eek, how did that happen
<ev> :D
<pitti> ev: so for that call, it would mean that get_desktop_entry() would return an object with a getIcon() method which returns 'nonexistant'?
<ev> and yeah, he'll be back on the 27th
<ev> correct
<pitti> I just pressed middle mouse, and weechat decided to also reply one of my earlier IRC messages, d'oh
<ev> :)
<barry> mdke: ping: https://launchpadlibrarian.net/92012331/buildlog_ubuntu-precise-i386.ubuntu-docs_12.04.2_FAILEDTOBUILD.txt.gz
<chrysn> i'm having trouble tracing a ppa's build failure down; it's about the openscad - 2011.12-2precise2 build on the https://launchpad.net/~chrysn/+archive/openscad/+packages archive
<chrysn> i reproduced the build setup by installing an lxc virtual machine, made sure the dependencies are met with exactly the versions the build server used, and removed abundant packages (a -dev recommended another -dev) until the diff between my and the server's build log was reduced to build directory path differences
<chrysn> nevertheless, i get an undefined reference error where i know from the line number that the file used on the ubuntu build server contains the #include <GL/glu.h> line, and i've looked at the package the build server downloaded to satisfy the respective dependency, and it has a GL/glu.h which does define what the error is about
<chrysn> any ideas what i could have been missing?
<pitti> ev: hang on, that dupe problem is not your fault; unless you started on it already, I'll take it
<ev> pitti: I haven't gotten to it yet, so by all means :)
<infinity> chrysn: It should fail the same locally too, that's not a PPA issue.
<pitti> seems it's due to some recent Launchpad change
<ev> ahh
<infinity> chrysn: And it's probably due to the order of arguments on your linking line.
<chrysn> is there a way to fetch the intermediate files from the build server to look for differences there?
<infinity> chrysn: Nope, it's all thrown away after the build and the VM reset.
<chrysn> but that would show up anyway in the build log, wouldn't it? and that is the g++ line that fails is the same both on my system and the build server
<Cas-> doko, i'm just filling out an issue what should I put for SRU?
<doko> Cas-, a branch, or a debdiff
<Cas-> its in distribute release
<Cas-> this seems like a lot of hoops for such a simple fix
<Cas-> doko, https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/938786
<ubottu> Launchpad bug 938786 in distribute (Ubuntu) "Import issue with namespace packages in pkg_resources" [High,New]
<doko> Cas-, and subscribe ubuntu-sru
<Cas-> k
<pitti> ev: https://launchpadlibrarian.net/93753132/Traceback.txt (from bug 938625) looks very weird -- could this be a threading issue?
<ubottu> Launchpad bug 938625 in apport (Ubuntu) "apport-kde crashed with AttributeError in addbutton(): 'NoneType' object has no attribute 'addButton'" [Undecided,New] https://launchpad.net/bugs/938625
<doko> Cas-, I can't see a branch or a debdiff in the report
<ev> pitti: my initial suspicion is that something is calling addbutton for the bug report dialog, which doesn't have a button box anymore. Digging.
<ev> pitti: presumably something like this would work: http://paste.ubuntu.com/852898/ but I'm still trying to see what is calling addbutton for that dialog
<bdmurray> psusi: is zeroing the superblock the right way to get your array going again in bug 925280?
<ubottu> Launchpad bug 925280 in mdadm (Ubuntu) "Software RAID fails to rebuild after testing degraded cold boot" [Medium,Confirmed] https://launchpad.net/bugs/925280
<psusi> bdmurray: no, you don't want to zero the superblock, doing that and then adding the drive is like adding a completely new drive
<bdmurray> psusi: then what would be the right thing?
<psusi> bdmurray: you either need to enable the write-intent bitmap when you set up the array, and then you can --re-add the removed drive, or you need to --add --run ( both switches together ) to add the drive back, or zero the superblock, then -add it
<psusi> best is to just enable the write-intent bitmap, then you can --re-add the drive and it will sync back up fast
<bdmurray> is there a way to enable that for an existing array?
<psusi> sure, just pass the -b internal switch same as when you create the array
<stgraber> infinity: any idea about bug 938867?
<ubottu> Launchpad bug 938867 in live-build (Ubuntu) "live-build fails to build on precise" [Undecided,New] https://launchpad.net/bugs/938867
<infinity> stgraber: Oh, ugh.  The tidying in hacks doesn't run late enough.
<infinity> stgraber: (Which now makes me wonder why any of said tidying is in that block of code...)
<infinity> stgraber: I'll just revert that for now, and then look for a better way to do it a bit later.
<infinity> stgraber: Uploaded a revert.  I'll try to sort out a better place to do cleaning a bit later (and probably move all the other cleaning from _hacks at the same time)
<Cas-> doko, why can't the upstream versin of distribute be used?
<barry> mdke: ping
<mdke> barry: (In case I'm not around at the moment, please provide a bit of information about what you want and I will respond when I get back)
<barry> mdke: https://launchpadlibrarian.net/92012331/buildlog_ubuntu-precise-i386.ubuntu-docs_12.04.2_FAILEDTOBUILD.txt.gz
<doko> Cas-, we only fixing issues in stable releases, not updating to new upstream versions
<Cas-> i understand that but surely for such a crucial part of python the bugs should not be just left and fixed ad-hoc
<Cas-> http://pypi.python.org/pypi/distribute#changes
<micahg> infinity: please refresh my memory, if it's not essential:yes + priority: required, it needs to be depended on in some form?
<seb128> jdstrand, hey
<seb128> jdstrand, evince has some apparmor related bug and I would like your input, that's the best way? subscribe you or ubuntu-security? irc pings?
<broder> micahg: i thought you had to explicitly depend on anything that wasn't essential:yes
<broder> micahg: http://www.debian.org/doc/debian-policy/ch-binary.html#s-dependencies is the relevant policy snippet
<micahg> fun, AFAICT, there's not an awk providing binary that's essential :)
<broder> wait, was the conclusion from yesterday that you get to keep the pieces of a system without ubuntu-minimal breaks?
<broder> because if so, it's purely an exercise in pedantry
<micahg> I seem to have missed that discussion
<micahg> but I do have a bug report :)
<broder> micahg: http://irclogs.ubuntu.com/2012/02/21/%23ubuntu-devel.html#t22:53
<micahg> umm, well, this one's a little different, a system can in theory live just fine without awk
<broder> right. the relevant portion of the discussion was whether or not you're allowed to run ubuntu without ubuntu-minimal installed
<micahg> I guess I should start a thread on ubuntu-devel
<micahg> well, that seems to be a difference of opinion :)
<broder> well, if you're not allowed to complain about things being broken without ubuntu-minimal, then effectively everything in ubuntu-minimal becomes "essential", and you don't have to depend on them explicitly
<chrisccoulson> huh, since when can a system run fine without awk?
<micahg> since I had to a while back add a dependency for locales to firefox which is in minimal, I don't think this is much more of a stretch
<chrisccoulson> it's a pre-depend of an essential package (ie, base-files)
<chrisccoulson> which makes it, essential
<micahg> ah, it's transitively essential then :-/
<broder> essential-ness isn't transitive. it *is* guaranteed to be installed, but that's an implementational detail
<micahg> right
<broder> so you're still *supposed* to depend on it if you need it
<chrisccoulson> awk is a virtual package, so it can't be made essential
<chrisccoulson> but it is essential by virtue of being a pre-depend of an essential package
<micahg> right, so we'd have to make an implementation of it essential to fulfill the pre-depends
<chrisccoulson> if awk isn't installed and configured, your system is screwed ;)
<broder> micahg: no, you just have to make an implementation priority:required
<micahg> oh, well, we already have that
<broder> right
<broder> but, the only dependencies you don't have to explicitly list are packages which are themselves essential:yes
<broder> and for the purposes of dependencies, that essential-ness is not transitive
<broder> technically you're *supposed* to depend on awk
<micahg> well, that's the thing, mawk isn't essential: yes, but is priority:required
<broder> micahg: then if you have a package that uses it, you're supposed to depend on it
<broder> but because it's pulled in by an essential package, this is all pedantry and not relevant to actual practice
<micahg> right, but since an essential package needs it, maybe it should be essential as well
<chrisccoulson> you can't make a virtual package essential
<broder> no, i don't think that's how it works
<broder> the entire essential dependency chain doesn't need to all be essential
<broder> just priority:required
<broder> e.g. you don't tag libraries essential, even though they're obviously depended on by essential packages
<broder> (and you don't want to, because then you'd never be able to remove the old version in the case of a SONAME bump)
<micahg> ok, then we should add the pre-depends for awk like base-files has
 * micahg googles for discussions in Debian on this point
<micahg> ooh, the discussion almost pre-dates some Ubuntu contributors :) http://lists.debian.org/debian-policy/1998/02/msg00072.html
<chrisccoulson> nothing should need to pre-depend on awk when base-files already does
<micahg> chrisccoulson: that's a technicality
<broder> well, the thread makes it pretty clear that the intent was to treat awk as essential
<micahg> yeah, I guess so, so I'll just close the bug as an issue with the uses's system I guess
<micahg> kenvandine: please try to remember -v in your merges :)
#ubuntu-devel 2012-02-23
<Cas-> the distribute log for oneiric is a mess
<Cas-> https://launchpad.net/ubuntu/+source/distribute/+changelog
<Cas-> can i propose that oneiric simples get the same version as in precise?
<micahg> Cas-: what do you mean the log is a mesS?
<Cas-> i mean that the version 0.16.6 is just patched and patched instead of just pulling release versions
<micahg> we don't update release version in stable releases unless they are totally broke beyond fixing
<micahg> backports are possible for some applications
<Cas-> we i think this is one of them
<micahg> Cas-: is there something wrong with the version in precise?
<micahg> err...oneiric
<Cas-> yes
<micahg> bug #?
<Cas-> https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/938786
<ubottu> Launchpad bug 938786 in distribute (Ubuntu) "Import issue with namespace packages in pkg_resources" [High,New]
<Cas-> basically a fix from 0.16.7 was applied to 0.16.6 that was actually broken and then fixed in 0.16.8
<micahg> Cas-: as soon as the current package in -proposed migrates to -updates, we can upload this fix
<Cas-> the list of changes for distribute is very small http://pypi.python.org/pypi/distribute#changes so thats why i suggested oneiric should match  precise version of 0.6.24
<micahg> yeah, we generally don't do that, are there other specific fixes needed for oneiric besides this one?
<Cas-> not that i have specifically encoutered
<micahg> ok, so let's just do one more SRU then, I"ll give you a bug task, but I'm not comfortable uploading the change, I'd prefer someone with a python background review it, do you want to prepare a debdiff? (it can be sponsored on your behalf then and go straight in the sponsorship queue)
<Cas-> the only change that matters is the tab indent in pkg_resources.py
<Cas-> i dont have a setup for debdiff
<micahg> bzr branch works also
<Cas-> well it's late here i'll need to sort it 2mw
<pitti> Good morning
<pitti> is LP being upgraded or so? it's horribly unstable ATM
<lifeless> pitti: we're looking at it
<lifeless> pitti: no, its not mid-deploy (and that doesn't cause instability anyhow); we're seeing broken connections to the db master and currently divide-and-conquering the path
<pitti> lifeless: ah, thanks
<lifeless> we've just tried something; tell us if its better worse ?
<pitti> I did three changes now, they all succeeded
<pitti> before I needed to try each bug state change some 5 times
<lifeless> cool
<lifeless> thanks
<pitti> bzr commit worked as well
<pitti> ev: FYI, I fixed the ui.py test failures in apport trunk now
<pitti> cjwatson, slangasek, StevenK: it seems /srv/launchpad.net/ubuntu-archive/ubuntu-germinate/ does not get updated any more; any hint how I could debug this? is that being called by soyuz or by some cronjob which I fail to see?
<slangasek> pitti: hmm, I suppose this would be related to cjwatson's changes this cycle to speed up publishing, but I'm afraid I don't know the details
<pitti> it just stopped two days ago
<StevenK> That's what I was thinking.
<pitti> three now
<slangasek> ah
<slangasek> so it's still supposed to be done as part of the publisher run
<pitti> and I figure that's rather bad, as I assume live CD builds etc. depend on this?
<slangasek> but there's been some restructuring
<pitti> (not to mention breakign http://people.canonical.com/~ubuntu-archive/component-mismatches.txt etc.)
<slangasek> well, that output impacts the task fields in the archive
<pitti> right, so our recent seed changes will probably not take effect
 * slangasek nods
<slangasek> infinity: hmm, wubi livefs build failure, "mount: unknown filesystem type 'ext4'" - is that related to the changes I saw you making?
 * ogra_ wonders where infinity's live-build upload went 
<Adri2000> I'm not sure if it's useful to say this, or if it's done regularly anyway: libhighgui2.1 and libcv2.1 binary packages are NBS and can now be removed
<pitti> Adri2000: I did so an hour ago or so
<pitti> after sitplus finally built on powerpc
<pitti> Adri2000: I'm watching this regularly, yes
<dholbach> good morning
<diwic> good morning dholbach
<dholbach> hey diwic
<Adri2000> pitti: cool. btw, I can't find anymore the list of removed packages (no removals.txt at http://people.canonical.com/~ubuntu-archive/), where is it?
<pitti> Adri2000: I don't know whether there is a replacement
<Adri2000> it was useful in some cases :)
<geser> Adri2000: do you need a list of removed packages or the reason (and date) when a package got removed? the later can be found in LP
<Adri2000> geser: even binary package removals can be found in LP? how?
<geser> Adri2000: sure, e.g. https://launchpad.net/ubuntu/oneiric/amd64/libcv2.1 should mention it once it's removed (don't have a better example right now)
<Adri2000> ok, https://launchpad.net/ubuntu/precise/amd64/libcv2.1 mentions it so it's good :)
<geser> ah right, forgot to replace the release in the url
<pitti> also, e. g. https://launchpad.net/ubuntu/+source/libaws/+changelog
<pitti> or https://launchpad.net/ubuntu/+source/libaws/+publishinghistory (with more data)
<tkamppeter> Anyone taking care of bug 911436? It leads to crashes of the CUPS daemon, especially when the CUPS package gets updated and therefore the daemon restarted.
<ubottu> Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
<tkamppeter> slangasek, you have set bug 911436 to "Triaged" a while ago, are you working on solving it?
<ubottu> Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
<ev> pitti: cheers!
<pitti> lamont, infinity: temporarily stealing some buildds for i386 for the langpack upload, as it's all quiet otherwise
<pitti> (just FYI)
<pitti> ev: so AFAICS from yesterday's discussion we still need a way to disable apport's LP bug filing, but not whoopsie submission post-release, right?
<chrysn> how can i, in build conflicts, conflict against a specific range of versions?
<chrysn> (in particular, libglew released packages using 1.5.2 code as "1.5.7.is.1.5.2", which makes it kind of tricky to depend on what you'd normally call libglew1.5-dev (>= 1.5.4) )
<tjaalton> I need a quick FFe for wayland, which now has a real upstream release instead of the git snapshots we've had before. it's also a build-dependency of the new mesa bugfix release I'm preparing
<tjaalton> nothing else depends on it, so risk of regression is negligible
<pitti> tjaalton: eek, that would mean wayland needs to go into main?
<tjaalton> it is already
<tjaalton> ok sorry, I'll rephrase
<pitti> eek :)
<tjaalton> the new mesa build-depends on this release :)
<pitti> tjaalton: so, otherwise this sounds fine
<tjaalton> it has that build-depend already
<tjaalton> *has had
<tjaalton> so the bugfix mesa release needs this new wayland to build libwayland-egl
<tjaalton> mesa will fix a bunch of crashers, at least bug 926379
<ubottu> Launchpad bug 926379 in mesa (Ubuntu) "compiz crashed with SIGSEGV in intel_miptree_release() (Needs mesa-8.0.1)" [High,In progress] https://launchpad.net/bugs/926379
<tjaalton> pitti: so I take it that it's ok to update wayland too?
<pitti> tjaalton: yes, fine for me
<tjaalton> thanks!
<pitti> tjaalton: you might want to coordinate with bryce, he did the wayland updates before
<tjaalton> these are maintained in pkg-xorg git, so yeah he should know what's happening :)
<tjaalton> Sarvatt did the previous upload
<tjaalton> pitti: there's also the default wayland compositor, weston, that could be synced from experimental (NEW)?
<pitti> tjaalton: no idea about that; that seems less urgent and more invasive, and should probably get an FFE bug
<tjaalton> yes less urgent
<tjaalton> I'll leave it for now
<infinity> slangasek: Potentially.  I'll look at it in the morning.
<bryceh> pitti, yes the merge is fine by me; I have no plans to look at or work on wayland this cycle
<bryceh> pitti, also since no one really uses the compositor I don't really see any harm in letting that be sync'd in.  It's really only existing for testing purposes, for people who want to observe compositors crashing a lot.
<pitti> *chuckle*
<dholbach> what is whoopsie and why does it use 89% of 8G of RAM? :)
<pitti> ev: ^
<pitti> dholbach: ev's new crash reporting daemon
<ev> gah
<pitti> the joys of C programs?
<ev> :)
<ev> I did run it through memcheck
<ev> dholbach: do you have any .upload files in /var/crash?
<dholbach> 28294 whoopsie  20   0 37.0g 7.0g 1116 S    0 90.4   0:33.84 whoopsie
<dholbach> ev, no, just a bunch of .crash files
<ev> interesting
<ev> did you elect to report any crashes using the new apport UI?
<dholbach> yes
<ev> dholbach: could you pastebin a ls -la of /var/crash
<ev> curious to know if there's anything particularly large in there
<dholbach> ev, http://paste.ubuntu.com/853789/
<dholbach> ev, maybe it's struggling with the one owned by daniel.daniel?
<ev> dholbach: well, it's not supposed to touch anything at all if there isn't a matching .upload file for it
<dholbach> aha
<ev> dholbach: could you possibly do sudo stop whoopsie; CRASH_DB_URL=http://localhost /usr/bin/whoopsie -f > whoopsie.log 2&>1 for a bit
<dholbach> sure
<ev> and see if it starts growing out of control
<ev> much appreciated
 * ev goes memleak hunting
<dholbach> ev,
<dholbach> aniel@daydream:~$ sudo stop whoopsie; CRASH_DB_URL=http://localhost /usr/bin/whoopsie -f > whoopsie.log 2&>1
<dholbach> whoopsie stop/waiting
<dholbach> Trace/Breakpoint ausgelÃ¶st (Speicherabzug geschrieben)
<dholbach> daniel@daydream:~$
<dholbach> hum, let me try to find a translation for this :)
<dholbach> in any case it crashed
<dholbach> whoopsie crashed with signal 5 in __libc_start_main()
<dholbach> "Trace / breakpoint is triggered (dump written)"
<ev> dholbach: if you would be so kind, CRASH_DB_URL=http://localhost gdb --args /usr/bin/whoopsie -f
<ev> r then bt
<dholbach> I guess I will need some debug symbols - right now it's useless
<ev> :)
<ev> dholbach: https://bugs.launchpad.net/ubuntu/+source/whoopsie-daisy/+bug/939392 for the memleak bug
<ubottu> Launchpad bug 939392 in whoopsie-daisy (Ubuntu) "Large memleak in whoopsie" [Undecided,New]
<dholbach> ev, http://paste.ubuntu.com/853800/
<ev> ah, whoops
<ev> I'll fix that, but...
<ev> sudo CRASH_DB_URL=http://localhost /usr/bin/whoopsie -f >whoopsie.log 2&>1
<pitti> http://daisy.ubuntu.com/ doesn't seem to exist/
<pitti> ?
<ev> pitti: not yet - IS is working on that
<dholbach> ev, I'll let you know if anything interesting turns up
<ev> dholbach: cheers, and sorry about this
<dholbach> no, no - it's fine
<jml> hello
<jml> something has happened such that my local apt is broken and I can no longer upgrade
<pitti> jml: did you try sudo apt-get -f install?
<pitti> (withouth the '?')
<jml> pitti: hah. of course. :)
<pitti> jml: what does it say?
<jml> pitti: http://paste.ubuntu.com/853832/
<jml> E: Internal Error, No file name for libc6
<pitti> erk
<pitti> and mvo is on holiday
<pitti> jml: perhaps try this:
<pitti> sudo rm /var/lib//apt/lists/* /var/cache/apt/*cache*
<pitti> sudo apt-get update
<pitti> sudo apt-get -f install
<jml> pitti: ok. will try that
<pitti> jml: perhaps save the caches before, for later investigation
<jml> oops :)
<jml> pitti: /var/lib/apt/lists/partial still exists. Should I remove that?
<pitti> jml: keep the dir
<pitti> you can remove the files in it
<jml> o
<jml> k
<pitti> jml: by gut feeling is that the caches were broken, the apt lists are usually okay
<pitti> modulo memory/fs corruption of course
<jml> pitti: still get the same error on apt-get -f install
<pitti> jml: can you please show me "apt-cache policy libc6"?
<jml> pitti: http://paste.ubuntu.com/853840/
<pitti> that looks fine
<pitti> jml: does "sudo apt-get install --reinstall libc6" work?
<pitti> i. e. does it know about the package name ther?
 * jml tries
<pitti> jml: oh, wait
<pitti> jml: perhaps it thought it already downloaded the libc6 .deb, but didn't
<pitti> jml: rm /var/cache/apt/archives/* might helP?
<jml> yay
<jml> boo
<geser> googling suggests that it might be related to /var/lib/dpkg/status
<pitti> I don't know how to regenerate status, though
<jml> http://paste.ubuntu.com/853844/
<geser> there should be a backup file
<geser> see bug #859188 for a similar problem
<ubottu> Launchpad bug 859188 in apt (Ubuntu) "can't apt-get install --reinstall when foreign-arch version is present (E: Internal Error, No file name for libgl1-mesa-glx)" [High,Fix released] https://launchpad.net/bugs/859188
<jml> geser: 'status-old' is identical to 'status', fwiw.
<geser> try "apt-get install --reinstall libc6:i386 libc6:amd64"
<jml> geser: $ sudo apt-get install -y --reinstall libc6:i386 libc6:amd64
<jml> Reading package lists... Done
<jml> Building dependency tree
<jml> Reading state information... Done
<jml> You might want to run 'apt-get -f install' to correct these:
<jml> The following packages have unmet dependencies.
<jml>  libc-dev-bin : Depends: libc6 (< 2.14) but 2.15-0ubuntu2 is to be installed
<jml>  libc6 : Depends: libc-bin (= 2.15-0ubuntu2)
<jml>  libc6:i386 : Depends: libc-bin:i386 (= 2.15-0ubuntu2)
<jml>  libc6-dev : Depends: libc6 (= 2.13-24ubuntu4) but 2.15-0ubuntu2 is to be installed
<jml>  libnih1 : Depends: libc6 (< 2.15) but 2.15-0ubuntu2 is to be installed
<jml> E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).
<jml> sorry
<jml> I honestly hit C-c on the URL in the browser
<geser> hmm
<geser> there are some more backups in /var/backups/dpkg.status.*
<jml> (I could swear that something about recent Ubuntus introduces a lag on keyboard input when switching windows/desktops)
<jml> well, here's the diff between current status and the first one that has a difference: http://paste.ubuntu.com/853852/
<geser> is this an upgrade precise -> precise?
<pitti> jml: that libnih1 is old
<geser> I'm wondering why it doesn't want to upgrade the other packages
<pitti> especially since he already  has libc6 2.15
<jml> geser: yes, it is.
<pitti> jml: apt-cache policy libnih1?
<jml> http://paste.ubuntu.com/853853/
<geser> does it upgrade libc6 if you leave out the --reinstall?
<pitti> jml: sudo apt-get install --reinstall libc6 libnih1 libc-dev-bin libc6:i386
<geser> and try adding libc-dev-bin libc6-dev libnih1 to the list of packages to install
 * pitti ^5s geser
<jml> hmm
<jml> pitti: the --reinstall command just errors out with unmet dependencies...
<pitti> jml: you can try adding all the unmet ones until it works
<geser> or you get a meaningfull error
<diwic> jml, I had that problem when upgrading precise a while ago and found in some bug (don't remember number) that "sudo dpkg -i /var/cache/apt/archives/libc...." was the right way to resolve the problme
<jml> http://paste.ubuntu.com/853861/
<diwic> after that you can continue with "-f install" and the "dist-upgrade"
<jml> after I add packages, I get the original libc6 error again :\
<geser> bah :(
<jml> diwic: oddly, I don't have a libc6 deb in my apt/archives folder
<diwic> bad luck
<diwic> :-/
<geser> apt-get download libc6
<pitti> ... and sudo dpkg -i libc6_*.deb
<pitti> (it'll land in the current folder, not the apt cache)
<geser> as this seems to be a multi-arch issue (as mentioned in that bug) perhaps slangasek knows how to get out of it (he commented on that bug)
<jml> ok
<jml> so the libc6 install failed because libc-bin wasn't at the right version, but I installed (dpkg -i) libc-bin from apt/archives and then tried installing the downloaded libc6. That seemed to work, and apt-get -f install seemed to finish successfully
<jml> (although weirdly, the config system used readline rather than the pretty aubergine TUI)
<hrw> who maintains ubuntu-seeds?
<pitti> jml: great!
<pitti> hrw: the "owners" of the respective derivatives, e. g. ~ubuntu-core-dev, ~xubuntu-dev, and so on
<jml> and apt-get dist-upgrade is downloading a lot of stuff now :)
<hrw> pitti: thx
<jml> pitti, geser, diwic: thanks so much!
<diwic> jml, np - but it has happened on two machines here so I assumed it was generic enough that someone would actually fix it, but we'll see...
<pitti> diwic, TheMuso: WDYT about bug 930703 ?
<ubottu> Launchpad bug 930703 in pulseaudio (Ubuntu) "wishlist: demote pulseaudio-esound-compat to Suggests" [Undecided,New] https://launchpad.net/bugs/930703
<pitti> I think it's about time
<diwic> pitti, I don't know of any application using the esound interface; that said, I tend to err on the side of caution at this part of the cycle
<diwic> pitti, but I guess such applications would then bring this in through some kind of dependency, huh?
<pitti> diwic: I think we should promote libesd0's Suggests: pulseaudio-esound-compat to Recommends:
<pitti> then everythign which still actually needs esound will still get it
<pitti> but we avoid installing it by default
<pitti> not that it takes much space or so, but it offers a wildly obsolete API
<diwic> pitti, that sounds okay to me
<Q-FUNK> jibel: pitti suggested that I talk to you about adding a check for $(dpkg-query -W -f='${Conffiles}\n' | grep obsolete | awk {'print $1'}) to https://jenkins.qa.ubuntu.com/view/Precise/
<pitti> jibel: hm, that's perhaps something which could be added to ./AutoUpgradeTester/post_upgrade_tests/test_lts_upgrade_system.py ?
<pitti> jibel: OOI, for changes to these scripts, is it enough to commit, or does it need an upload?
<pitti> jibel: IOW, are you running from bzr or from the pacakge?
<Q-FUNK> jibel: for reference, you can check how I use that stanza in src: upgrade-system
<pitti> ev: before you continue to hack on apport, please pull trunk into your branch (your branch is merged)
<ev> will do
<pitti> ev: I made quite intrusive structural changes to the tests
<ev> cool, will have a look
<pitti> ev: the tests are now all in test/ and all look alike
<ev> yay!
<pitti> ev: this also makes it possible to run them against the installed system libs, too
<pitti> hm, thehre are now 4889 LOC in apport/ and 8462 LOC in test/
<ev> :D
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<apw> pitti, heard of apport exploding when trying to submit bugs?  crashing python in fact:
<apw> *** glibc detected *** /usr/bin/python: double free or corruption (fasttop): 0x000000000378bf60 ***
<pitti> apw: not on my radar; sounds like a bad transfer annotation somewhere in GTK
<pitti> apw: are you able to reproduce this?
<apw> pitti, i tried to submit an xorg bug, and its failed twice, not sure its identicle symptoms tho
<pitti> apw: ah, not a crash, just "apport-bug xorg"?
<pitti> what did you click?
<apw> pitti, ok so ubuntu-bug xorg, clicked the first two entries in the first dialog, the last one in the second, then hit 'Send' without changing anything in the third
<apw> last two are identicle heap corription thingies
<tkamppeter> pitti, I got the Ubuntu-branded test page today. I will put it into the cups-filters package. I will put it into debian/local/ (where the apport hook is) and replace the upstream page by this one in the case that the package is built for Ubuntu. Is this OK?
<pitti> apw: second question is about lightdm log files; yes or no?
<apw> pitti, sorry i also said yes to that one
<pitti> tkamppeter: sure; could you do this in debian/rules with if dpkg-vendor --is ubuntu; then ... ?
<pitti> tkamppeter: then we can keep it in sync with Debian
<apw> so i was saying its 'reproducible' and 'happened more than once'; they could have my logs; and i would 'do anything' to get it fixed
<pitti> apw: meh, works fine here
 * apw ubuntu-bug ubuntu-bug's to see what happens
<apw> ok that seems to work ... so i can file a bug about not being able to file a bug
<pitti> apw: the .crash report might be more useful, though
<pitti> full GTK stack trace and such
<apw> so will there be a crash report for the apport crash?
<apw> i'd assume it suppressed there to prevent circles
<pitti> no, it shouldn't
<pitti> apport has plenty of crash reprots
<pitti> most of which are not very useful of course, but still, they are there
<apw> hmmm, so i ran it three times, and got 3 aborts on my terminal, but only one maybe in /var/crash, does it do local dup detection ?
<pitti> apw: the file name is by program name and user id, so yes
<ev> didrocks: are you planning on uploading activity-log-manager 0.9.2 today? I only mention it because it should Breaks and Replaces on whoopsie < 0.1.10, as its taking ownership of the GNOME Control Center stuff.
<apw> pitti, ok so i have a crash here, so how do i tickly apport to make a bug out of it
<pitti> apw: usually it pops up by itself, but you can apport-bug /var/crash/*apport*.crash
<apw> ev, would i expect all my reports in /var/crash to be readable by woopsie?
<apw> pitti, seems i have like 10 in there, and i can't be bothered to handle them all right now
<pitti> apw: just the _usr_share_apport_apport-gtk.crash one
<didrocks> ev: yeah, it's on my schedule :)
<apw> pitti, i ran the command you suggested, and have a dialog saying, "The application Report a problem ... has closed unexpectly."  and saying 'leave closed' and 'relaunch'
<tkamppeter> pitti, how do I add the new test page to the package? If I put it into debian/local/ I get
<didrocks> ev: thanks for the update! Will add the Breaks:/Replaces:
<tkamppeter> dpkg-source: info: using source format `3.0 (quilt)'
<tkamppeter> dpkg-source: error: unwanted binary file: debian/local/default-testpage.pdf
<tkamppeter> dpkg-source: error: detected 1 unwanted binary file (add it in debian/source/include-binaries to allow its inclusion).
<pitti> tkamppeter: well, it pretty much says what it wants :)
<didrocks> ev: no need for a FFe? the whoopsie part was already in precise?
<tkamppeter> pitti, now I see.
<ev> didrocks: correct; the whoopsie part was already in precise and cjwatson said this would be a UIFe
<ev> apw: yes, should be
<didrocks> ev: ok, and we will even upload before UIF, so all good! thanks :)
<ev> cheers!
<ev> I'll sort an upload of whoopsie without the control center stuff now
<apw> ev, ok something isn't hnouring that, as most are, but i suspect one which was triggered by me running ubuntu-bug is not
<ev> apw: is it 0600? or not group owned by whoopsie?
<apw> ev, just got an error trying to submit a bug 'cannont connect to crash database'
<apw> ev, its apw:apw 660
<apw> -rw-r----- 1 apw apw      32993298 Feb 23 11:58 _usr_share_apport_apport-gtk.1000.crash
<ev> huh? /var/crash should be g+s
<ev> I take it that it's not?
<tkamppeter> pitti, is debian/source/include-binaries a directory for the binaries or a list of the binaries?
<apw> drwxrwsrwt 2 root whoopsie 4096 Feb 23 12:17 /var/crash
<pitti> tkamppeter: I think a file
<apw> ev, yes it is
<tkamppeter> pitti, it is working now, it is indeed a file listing the exceptions.
<ev> apw: I'm baffled as to how that happened then
<apw> ev, its only the default ownership, so i guess somethign must have changed it, in apport
<ev> oh, I didn't realize you could ignore it
 * ev digs
<apw> you can chgrp anything in there you own
<apw> so i could go and do it myself, as they are my files
<apw> pitti, ok finally got it filed: bug #939466
<ubottu> Error: Launchpad bug 939466 could not be found
<pitti> apw: thanks; need to wait on retracer
<tkamppeter> pitti, I have pushed a new version of cups-filters. Can you upload it to Debian and Ubuntu, it contains the new test page and therefore needs to get uploaded before UI Freeze today.
<tkamppeter> pitti, and when you are at it, can you also upl;oad CUPS to Debian and Ubuntu? I have fixed auto-config for PS printers in it.
<Q-FUNK> ev: whoopsie seems to be missing the package description.
<ev> Q-FUNK: fixing
<Q-FUNK> ev: or well, it has the short description, but the long one doesn't appear.
<tkamppeter> slangasek, hi
<dholbach> ev, nothing interesting in ~/whoopsie.log, but in ~/1 there's http://paste.ubuntu.com/853954/ -- whoopsie doesn't seem to be leaking right now
<Riddell> cjwatson, mdz: message in ubuntu-devel-announce for review/approval
<ev> dholbach: I think I may have found part of the problem. If it fails to parse a report it will keep trying every time it processes the report queue (every hour or so)
<ev> I've fixed that in trunk and will push an upload shortly
<dholbach> cool
<dholbach> thanks for your work on this ev
<ev> thanks for your help in debugging it
<dholbach> I just tried not to stand in the way too much ;-)
<ev> dholbach: I don't suppose I could convince you to tar up /var/crash and send that my way? I'd be interested to know why it's failing to parse one of those reports, if that's the case.
<ev> haha
<dholbach> ev, I'll first need to find out how to do it in a way where the other coworking space people don't kill me :)
<ev> dholbach: sure :) whenever you can. Doesn't need to be right now
<dholbach> ev, ok, I'm uploading it using trickle right now - I'll be walking the dog now and let you know where you can find it later on
<ev> dholbach: cheers!
<pitti> tkamppeter: yes, can do
<kklimonda> hmm, any idea why is cdrom-detect/try-usb=true added to the kernel cmdline when usb disk is being generated using usb-creator-gtk?
<mterry> ev, new apport looks nice.  I'd include mpt too, but he's not here
<kklimonda> or rather what is checking for this option?
<ev> mterry: cheers!
<jincreator> pitti: Hi. As result of fontconfig package now have information about fonts-nanum, I think bug #835304 is not invalid now. What do you think about it?
<ubottu> Launchpad bug 835304 in ttf-nanum (Debian) "contained fontconfig setting files force to make it default font" [Unknown,Fix released] https://launchpad.net/bugs/835304
<pitti> ev: mterry | pitti, did you do the revamp of the apport dialog?  Looks nice
<pitti> ev: FYI :)
<ev> :)
<xinyi> join #ubuntu
<pitti> ev: btw, I now put Package:, ExecutablePath: and Stacktrace: on the top of the details list, so that it's easier to see the affected package
<pitti> ev: having "ApportVersion" at the top is not exactly the most interesting thing :)
<ev> pitti: brilliant!
<ev> heh
<pitti> it's not enough yet to alleviate bug 938707 , but an improvement at least
<ubottu> Launchpad bug 938707 in apport (Ubuntu) "Hard to see which program crashed for "Internal error" reports" [Medium,Confirmed] https://launchpad.net/bugs/938707
<Riddell> ev: ping "Notify Evan Dandrea to remove the disclaimer from Ubiquity's first page "
<ev> Riddell: on it
<Riddell> elmo: ping "Notify James Troup to remind mirrors to check free disk space "
<pitti> tjaalton: https://launchpad.net/ubuntu/+source/mesa/7.11-0ubuntu3.1
<pitti> tjaalton: any idea where the armhf build went to?
<jibel> pitti, Q-FUNK auto-upgrade testing is running from bzr so a commit is enough or file a bug against u-m, attach the unittest script you want to run and assign it to me.
<pitti> tjaalton: argh, unping; picked the wrong one
<Q-FUNK> jibel: I have no idea of how to implement the scripts or where they would go.
<Q-FUNK> jibel: I was simply asking pitti if LP has any tags for reporting packages that leave obsolete configs in place after an upgrade (as detected using the snippet above).
<Q-FUNK> jibel: he recommended talking to you because it could be a good idea to automate such checks.
<jibel> Q-FUNK, and he is right, it's a good idea to automate such checks :)
<jibel> Q-FUNK, I looked at upgrade-system
<jibel> Q-FUNK, the idea is to run $( dpkg-query -W -f='${Conffiles}\n' | grep obsolete | awk {'print $1'} ) post-upgrade
<jibel> Q-FUNK, and check that the list is empty ?
<Q-FUNK> jibel: essentially, yes. if it's not empty, to auto-file bugs against the packages concerned, indicating which files are concerned.
<Q-FUNK> you can see what it does if you try:  sudo FLAUSCH=jah upgrade-system
<pitti> infinity, lamont: FTR, buildds back to normal
<Q-FUNK> jibel: these days, due to Debian making automated runs of piuparts, there's fewer of these orphan configs than bebore -- but upgrading LTS to LTS+1 leaves a lot of cruft.
<Q-FUNK> jibel: currently, on my ubuntu+1 desktop, I only found 3 packages with such obsolete configs. on my LTS+1 host, it's close to 50 packages.
<jibel> Q-FUNK, bug auto-filing, we are not here yet, but I can add the test to the daily auto-upgrade tests. That will give a good picture of the status of main and universe.
<Q-FUNK> jibel: assuming that you would generate an automated bug report, packages that have such an obsolete config would need to call dpkg-maintscript-helper via debian/*maintscript to move or delete.
<pitti> tkamppeter: cups and cups-filters uploaded
<jibel> Q-FUNK, I filed bug 939528
<ubottu> Launchpad bug 939528 in update-manager (Ubuntu) "auto-upgrade-tester: Add a post-upgrade test to check for obsolete files" [Medium,Triaged] https://launchpad.net/bugs/939528
<Q-FUNK> jibel: ah, auto-upgrade-tester is a part of update-manager?
<dholbach> ev, it's in chinstrap:~dholbach
<jibel> Q-FUNK, yes, I'm working on separating them, but it will be done post B1.
<Q-FUNK> jibel: ok. good to know. :)
<ev> dholbach: cheers! I've grabbed it, so feel free to delete.
<dholbach> ev, thanks
<lenios_> does anybody know how to get the $ARCH in a makefile when building with pbuilder?
<lenios_> it looks like it was working until 11.10, but now doesn't with 12.04
<geser> are you looking for "dpkg-architecture -qDEB_BUILD_ARCH"?
<lenios_> i used to set ARCH in my pbuilderrc
<lenios_> or call ARCH=i386 pdebuild --configfile /etc/pbuilderrc
<infinity> lamont: You around?  What releases are kapok and cardamon running?
<infinity> lamont: And is it possible that they're running a kernel that doesn't grok ext4?
<ogra_> infinity, i thought just a missing modprobe or some such
<ogra_> infinity, but generally all our panda kernels and even the babbage ones always had ext4
<infinity> ogra_: Unless they're also not running udev, a modprobe shouldn't be necessary.
<infinity> ogra_: This is x86.
<ogra_> well, do they run udev ?
<ogra_> oh
<ogra_> indeed
 * ogra_ slaps foreheadf
<infinity> Still, I'm pretty sure ext4 has been builtin on Ubuntu kernels for quite a while, so either they're running ancient releases or custom kernels.
<infinity> (Well, maybe not ancient, I don't remember if it was =y or =m in lucid)
<ogra_> or mount is broken
<infinity> mount being broken seems less likely.
<pitti> lucid has it built in, anyway
<ogra_> well, as likely as a kernel without ext4
<infinity> Not entirely unlikely, but I'm going to stop speculating until I get a response from IS. :P
<ogra_> does livecd-rootfs have a versioned dep btw ? i.e. does the new live-build pulled in automatically ?
<infinity> The builds apt-get upgrade before they start.
<ogra_> k
<infinity> Which is obviously happening, or I wouldn't have ext4 errors. :P
<ogra_> why ? -f ext4 comes from buildlive, no ?
<infinity> Oh, fair point.  All I changed in live-build was a filename.
<infinity> Still half asleep here.
<infinity> Either way, yes, it's auto-upgraded.
<lenios_> geser, oh, DEB_HOST_ARCH looks like what i was looking for
<cyphermox> blueyed: poke.
<pitti> Riddell: hm, did you do anything to make lightdm-gtk-greeter have no reverse depends any more?
<pitti> Riddell: I thought xubuntu, studio, lubuntu, etc. were using it?
<pitti> now it's on http://people.canonical.com/~ubuntu-archive/nbs.html
<pitti> Riddell: also, there was one libokularcore1 rdepends waiting for koffice removal, but koffice is still in the archive?
<pitti> can it be removed now?
<Riddell> pitti: have faith, I've taken care
<infinity> ogra_: Feh, so they're running hardy. :/
<pitti> Riddell: great, thanks
<Riddell> pitti: the okular package was a rename from ages ago so that's fine
<pitti> Riddell: I was just curious, as I heard there was a package for the greeter on alioth or so
<Riddell> pitti: the lightdm one robert moved into a new source package so it's up to xubuntu etc to package, maybe micahg is doing it
<ogra_> infinity, LOL
<pitti> Riddell: right, I know
<pitti> Riddell: I just wonder where all the rdepends went
<pitti> xubuntu-desktop and friends Depend: on it
<pitti> or NBS is gone haywire and telling lies
<pitti> if we remove it now, we'll render them uninstallable
<pitti> so we need to take care to not accidentally do it
<Riddell> pitti: so we'd best hope micahg is packaging it :)
<pitti> Riddell: so you didn't apply any magic?
<pitti> then NBS has gone mad somehow
<seb128> Riddell, pitti: the packaging is reading in debian
<ogra_> infinity, joining the final arm meeting ?
<infinity> ogra_: Oh, it's that time.
<seb128> http://anonscm.debian.org/viewvc/pkg-xfce/goodies/trunk/lightdm-gtk-greeter/debian/
<seb128> Riddell, ^
<Riddell> pitti: oh I deleted it, it's up to xubuntu to fix it and I believe that's what is happening
 * Riddell deletes koffice for good measure
<Riddell> seb128: tell it to micahg :)
<pitti> uh; well, let's hope it happens quickly then
<pitti> also, it'll get caught in binNEW again
<pitti> we usually wait until there are no rdepends
<pitti> but oh well, it's done
<Riddell> I'm doing New now too, happy to be pinged for anything that's needed for beta
<pitti> thanks Riddell
<mdeslaur> tedg: are you able to reproduce the xchat-gnome clipboard crash on demand? I can't seem to reproduce it
<mdeslaur> tedg: I select text in the chat window, and then click like a mad man, and nothing happens
 * tedg checks
<mdeslaur> click here --->
<mdeslaur> no, here -------->
<mdeslaur> :)
<tedg> mdeslaur, Well, apparently not... but it does happen quite a bit...
<pitti> tkamppeter: did you see that cups-filters FTBFSed on missing fontconfig?
<mdeslaur> tedg: ok, thanks
<tedg> mdeslaur, I'm not quite sure what the click pattern is.  I wonder if it's a middle click thing....
<mdeslaur> tedg: this happens with your touchpad?
<tedg> mdeslaur, Yeah
<pitti> ev: erk -- I just released and uploaded 1.93, saw your MP too late
<pitti> ev: will do a followup upload
<ev> no worries
<pitti> ev: oh, it was the chown which subverted the sgid flag?
<ev> pitti: it was for me, yes
<pitti> ev: there's no bug # for that, right?
 * pitti is writing the NEWS entry and wondering
<ev> oh, I actually didn't check
<ev> it was just from conversation in here
<pitti> yeah, I guess nobody else noticed yet
<pitti> I didn't see one this morning, anyway
<ev> :)
<pitti> ev: doesn't that affect the Python one, too?
<pitti> ah, no, that's written as user
<pitti> and thus, sgid should apply
<ev> indeed
<pitti> ev: btw, you merge trunk instead of pull?
<ev> this was the only call to chown I found
<pitti> (criss-cross merged)
<ev> oh, interesting
<ev> I've always done it this way out of habit
<ev> I'll give that a bash next go around
<pitti> pull basically unifies the history
<pitti> it checks that everything is merged, of course
<pitti> if not, it'll say "diverged"
<pitti> and you know that you have something to be merged still
<pitti> but anyway, if "merge" works, it shoudl be fine
<ev> cool
<Riddell> tjaalton: ping
<Riddell> tjaalton: gstreamer-vaapi has a .git directory in it, shall I reject or accept?
<tjaalton> Riddell: grr, reject :I
<tjaalton> I'll reupload
<Riddell> tjaalton: rejected!
<lamont> infinity: if it isn't arm/ppc, it's hardy on the buildds
<lamont> so.. 2.6.24-$mumble
<lamont> prolly somewhere between 27 and 30
<infinity> lamont: Yeah, already confirmed by gsa-ng for me. :/
<tjaalton> Riddell: reuploaded with a fixed tarball. upstream doesn't provide one so I created it myself but forgot about the .git dir..
<Riddell> pesky upstreams
<tjaalton> yep.
<Riddell> tjaalton: accepted!
<tjaalton> Riddell: thanks!
<mahmoh> infinity: bug 939240
<ubottu> Launchpad bug 939240 in linux-armadaxp (Ubuntu) "armadaxp kernel slow to unmount" [Undecided,New] https://launchpad.net/bugs/939240
<infinity> mahmoh: Danke.
<mahmoh> it has all the details but it appears that "05:14:37 umount("/boot", 0)             = 0" is hanging
<ogra_> is /boot using a weird filesystem ?
<infinity> mahmoh: Oh, err.  Is /boot an SD?
<mahmoh> infinity: SATA ext3 and ext2 both hang, I think the ext4 rootfs also exhibits the same problem
<infinity> Okay, so it's just a general "umounting sucks" issue, not actually related to the init sequence, now that I read the bug.
<infinity> That should be slightly less awkward to look at, potentially more awkward to fix.
<infinity> (And yeah, could be linux-armadaxp-specific, then)
<mahmoh> should be, hopefully easier to fix
<tjaalton> sigh, "No packages found matching gtk-doc-tools." on the buildd's, gstreamer-vaapi builds fine on sbuild though
<tjaalton> though it's listed in build-depends-indep, does that matter?
<infinity> tjaalton: Which build is this?
<tjaalton> infinity: gstreamer-vaapi, every arch failed
<tjaalton> https://launchpadlibrarian.net/93986127/buildlog_ubuntu-precise-amd64.gstreamer-vaapi_0.3.4-0ubuntu1_FAILEDTOBUILD.txt.gz
<tkamppeter> pitti, saw it now, strange, as I only added some small patches which should not have added new library dependencies, perhaps your libpoppler-private-dev caused a problem. I only built my changes locally for testing, I did not know about libpoppler-private-dev before I pushed my stuff.
<infinity> tjaalton: But yeah, if it's in -indep, that's wrong, if arch-specific builds need it. :P
<pitti> tkamppeter: private-dev is empty right now
<tjaalton> infinity: ahah, ok. I probably copied it from the upstream debian dir
<tjaalton> never used -indep before
<pitti> tkamppeter: but yes, it did build in Debian
<tkamppeter> pitti, perhaps some APIs got pulled out with the most recent Poppler, but my system is up-to date and it built.
<pitti> tkamppeter: so it builds with 0.16, but not with our 0.18
<tkamppeter> pitti, on my Precise is 0.18.
<pitti> tkamppeter: I guess libpoppler-private-dev is missing a libfontconfig-dev dependency or so
<infinity> tjaalton: Though...
<infinity> tjaalton: That doesn't explain the i386 failure.
<infinity> tjaalton: Still, if doc-tools is needed for the other builds, it's in the wrong field.  But, yeah, i386 is still failing even with it installed.
<tkamppeter> pitti, does the dependency on empty libpoppler-private-dev replace ano old dependency?
<tjaalton> infinity: ok I'll check that one too
<pitti> tkamppeter: not sure; perhaps some other dependency changed in the meantime, I didn't look
<sladen> tkamppeter: FTBFS: https://launchpadlibrarian.net/93976747/buildlog_ubuntu-precise-amd64.cups-filters_1.0.2-1_FAILEDTOBUILD.txt.gz
<sladen> tkamppeter: checking for FONTCONFIG... configure: error: Package requirements (fontconfig >= 2.0.0) were not met:
<cnd> didrocks, have you had a chance to look at xorg-gtest?
<doko> Daviey, ruby ping
<tkamppeter> pitti, sladen, seems that some package of cups-filters' build dependencies has dropped the dependency on fontconfig.
<didrocks> cnd: no sorry, rush of UIF. I plan to do it tomorrow morning in a quieter time
<tjaalton> infinity: yeah there was some stupid indep confflags trickery that didn't work, so --enable-gtk-doc wasn't passed on to configure
<cnd> didrocks, ok, thanks :)
<didrocks> cnd: but no worry, it's on my list :)
<infinity> tjaalton: Which explains the i386 failure, and the other failures were just due to the missing build-dep?
<larsu> pitti, tkamppeter, I heard cups-filters doesn't build? Can I help?
<tjaalton> infinity: yep
<infinity> tjaalton: Shiny.
<Daviey> doko: ruby pong
 * Daviey wonders if a ruby ping differs from a traditional ping
<doko> Daviey, it's a ping with context ;)
<Daviey> doko: can i give you a java ping? :)
<doko> Daviey, I didn't manage to make 1.9 the default for the lts. but would it be possible to get your server applications running using ruby1.9 explicitly? it may make the support easier for the lts
<doko> Daviey, are your minecraft games broken? ;-P
<Daviey> doko / jamespage: Any idea what introduced bug 939631
<ubottu> Launchpad bug 939631 in mythbuntu-meta (Ubuntu) "Java stack pulled into mythbuntu precise build" [Undecided,New] https://launchpad.net/bugs/939631
<Daviey> doko: heh
<doko> Daviey, hmm, no
<tkamppeter> pitti, sladen, larsu, I committed now a version with explicit build dependency on libfontconfig1-dev,
<tkamppeter> pitti, can you upload this to Debian and Ubuntu, thanks.
<Daviey> doko: Server flavour doesn't have an specific interest in ruby, there are a few things that are 'interesting' things for server.. but not something we are putting direct work into right now.
<Daviey> doko: I really don't think we have the manpower to validate things against 1.9 atm.
<Daviey> doko: puppet is probably the primary interest, but i'm nervous about committing to that.
<pitti> tkamppeter: to Ubuntu is enough for now, thanks!
<doko> Daviey, it maybe would be worth it (maybe jdstrand would like to comment too)
<Daviey> lynxman: do you have the capacity to validate puppet against ruby1.9 atm?
<lynxman> Daviey: puppet has unit tests so it's quite easy, I'll be glad to help
<Daviey> lynxman: that would rock my world.
<lynxman> Daviey: no prob, shall we wait for 2.7.11? or is it already in the Precise repo
<lynxman> 2.7.10 was marked as a bad release
<Daviey> lynxman: precise has .10
<lynxman> Daviey: that's why I'm asking :)
<infinity> Daviey: Speaking of puppet, do you know if IS's "we can't upgrade to precise because of puppet" issues have been resolved?
<Daviey> lynxman: so does Debian, i think we are stuck with .10 unless you know something i don't?
<infinity> Daviey: Or is that intractable client/server mismatch issue that just plain can't/won't be solved?
<lynxman> Daviey: this thread http://groups.google.com/group/puppet-users/browse_thread/thread/f1e764d3b55cf968/8a65af62664fd06e?show_docid=8a65af62664fd06e&pli=1
<lynxman> Daviey: 2.7.10 breaks a good list of regression tests
<Daviey> infinity: sorry, i haven't been following that issue.. :(
<jdstrand> Daviey, lynxman: we need 2.7.11 for a security update and because upstream has declared 2.7.10 'bad'
<seb128> pitti, mdeslaur, slangasek: do you have any opinion on bug #939595 (from design)
<ubottu> Launchpad bug 939595 in gnome-control-center (Ubuntu) "User can't set simple passwords for his local machine" [Undecided,New] https://launchpad.net/bugs/939595
<seb128> pitti, mdeslaur, slangasek: i.e basically not forcing user to enter a secure password but just warn them
<pitti> tjaalton: (CC: Riddell) on armhf we currently have
<lynxman> jdstrand: that's why I was asking, saw your emails
<pitti> libegl1-mesa: Depends: libwayland0 (= 0.1.0~2-1ubuntu1) but 0.85.0-1ubuntu1 is to be installed
<pitti> which causes the mess on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html
<Daviey> lynxman: OK... do you have capacity to look at a new upstream version of puppet, working against ruby1.9 .. discussing it with the DM's? :)
<lynxman> Daviey: I do! Can do it tom morning if that's fine
<lynxman> Daviey: or late tonight
<mdeslaur> seb128: I'll respond
<pitti> tjaalton: ah, so the new wayland also requires the new mesa, I see
<seb128> mdeslaur, thanks
<pitti> and it's building
<infinity> Daviey: You might want to talk to some IS folks.  AFAIUI, puppet is the single reason they can't upgrade any individual machines to precise without doing the entire DC at once, or some such.
<Daviey> lynxman: okay, it'll need an FFe.. but based on your input, upstream and jdstrand's.. it would seem like a good idea.
<lynxman> Daviey: I think it'd be more than recommendable indeed
<pitti> seb128: no strong opinion, but as we also offer autologin by default it makes sense for a desktop
<jdstrand> does it actually need an FFe? it is both a security update and bug fix. upstream declared it as unsupportable
<pitti> seb128: is it really g-c-c which adds obscure there?
<lynxman> infinity: I reckon they can't upgrade yet due to something they're using that is kinda broken so they need to change their modules in order to upgrade (from the top of my head)
<jdstrand> Daviey: ^
<seb128> pitti, no, passwd behaves the same
<slangasek> seb128: architecturally speaking, it's non-trivial to allow without making password strength checking useless in other cases
<Daviey> jdstrand: well it no doubt introduces features?
<slangasek> tkamppeter: 911436> no, 'triaged' means there's enough information for someone to work on it, not that someone is working on it yet
<seb128> slangasek, ok, can you comment on the bug saying that and,or subscribe to the bug. Is there any way for a client (i.e g-c-c) to override this security?
<jdstrand> Daviey: http://groups.google.com/group/puppet-users/browse_thread/thread/2d5daed2291962c2
<jdstrand> Daviey: "The security changes in 2.7.11 address CVEs 2012-1053 and 2012-1054. The maintenance changes are to address regressions in 2.7.10."
<Daviey> jdstrand: I sit corrected!
<slangasek> seb128: the only way to bypass that is to set a password as root
<jdstrand> https://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#2.7.11
<jdstrand> ok, I'll stop supporting myself then :)
<slangasek> seb128: mdeslaur seems to have beat me to the bug :)
<seb128> slangasek, mdeslaur: ok, thanks
<lynxman> jdstrand: Daviey: so you want me to do the unit testing against ruby 1.9 before we get 2.7.11 into the archive or after?
<jdstrand> lynxman: well, we need it in the archive regardless
<Daviey> lynxman: makes sense to do it concurrently. :)
<lynxman> jdstrand: yeah was just wondering the chicken and egg connundrum, its very ruby-esque
<jdstrand> lynxman: are you planning to get 2.7.11 into the archive?
<lynxman> jdstrand: hmm I could
<jdstrand> lynxman: I just meant that whether we use 1.8 or 1.9, we need 2.7.11
<lynxman> jdstrand: oh yeah definitely
<lynxman> Daviey: I'll also ask the puppet core developers for extra reassurance, afaik puppet was almost 100% ruby 1.9 compatible on 2.7.2 already
<jdstrand> lynxman: as for the timing of 2.7.11, I just figured someone would merge 2.7.11 when it hit Debian
<jdstrand> lynxman: I'm guessing that will be soonish
<seb128> mdeslaur, slangasek: I'm not sure I agree with the wontfix, the rational is raisonnable, there is no reason to force most users to set a complex password, i.e it seems a valid request to have g-c-c only giving you indication on how secure is your password, though I agree that if it's technically difficult to let g-c-c skip that security it might be wontfix for technical reasons
<lynxman> jdstrand: yeah I reckon so as well
<Daviey> lynxman: Have a conversation with the Debian Maintainers, always a shame to double up on workload.
<jamespage> Daviey: I think it is moin that is pulling java into the mythubuntu precise build
<lynxman> Daviey: ahoy
<Daviey> jamespage: right!  Seems to be the case, but moin isn't in those seeds
<mdeslaur> seb128: How about this compromise: we disable the password quality checking, but the default user isn't in the admin group? :)
<Daviey> the moin mention in the platform seed has been there since 2009
<seb128> mdeslaur, or how to make you box useless? ;-)
<seb128> your
<mdeslaur> seb128: useless but secure! :)
<seb128> lol
<seb128> mdeslaur, well I think for an home user it's reasonable to put a weak password
<seb128> mdeslaur, like think a netbook your let around for free use (sort of tablet usage)
<mdeslaur> seb128: removing the password quality check could be something that ubuntu-tweak could change
<seb128> mdeslaur, well, the issue is default install, normal users don't got and install ubuntu-tweak
<seb128> got->go
<jamespage> Daviey: so is your question why is moin in the seed?
<Daviey> jamespage: no, my question is why java is in seeds it wasn't previously.. :)
<Daviey> i don't think it's moin related fwiw.
<Daviey> i think it just /looks/ like it is.
<didrocks> ev: I don't see any .so for whoopsie in activity-log-manager
<Daviey> it's the reason, but not the cause, if that makes sense.
<didrocks> ev: there is the .ui, the polkit part
<tkamppeter> slangasek, bug 911436 causes around 5 new bug reports about CUPS update failures per day, therefore I was asking what the progress with this bug is.
<ubottu> Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
<ev> didrocks: indeed, it doesn't build a library for it
<didrocks> ev: it's bundled into the a-l-m one?
<didrocks> ok :)
<ev> as it's being shoved into a tab in the a-l-m page
<ev> so it doesn't need to create a library for g-c-c
<jamespage> Daviey: I can see a [build]dependency chain from moin to java tho
<ev> but it still needs the ui for itself and the dbus/polkit backend to apply the preferences
<didrocks> ev: ok, wasn't sure it was or not really bundled, ok, make sense then! :)
<pitti> janimo`, ogra_: !!!!!!!
<pitti> https://launchpad.net/ubuntu/+source/libreoffice/1:3.5.0-1ubuntu2/+build/3230659
<ev> thanks for checking with me
<ampelbein_> Can a arch-all package be forced to build on a specific architecture in ubuntu? In this case, openbios-ppc, needs to be built on a ppc arch. Is this what packages-arch-specific is for?
<ogra_> pitti, yes ?
<jamespage> Daviey: its in that seed for oneiric...
<pitti> ogra_: well, it's the first time ever that it built on armhf
<tkamppeter> pitti, OK, will upload itr to Ubuntu, we do the next synced upload with 1.0.3 with all the bugs on https://bugs.launchpad.net/bannertopdf fixed by larsu.
<pitti> ogra_: it was responsible for 111 uninstallable packages on armhf, which should now be fixed
<pitti> tkamppeter: already did
<ogra_> pitti, yeah, janimo rocks !!!
<ogra_> yippie
<pitti> ogra_: and I switched http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html from armel to armhf now, as I understand it's our primary arm arch now?
<ogra_> yep, armel is "community supported" now
<ogra_> pitti, and armhf has to be supported by ubuntu platform since with monday the ubuntu-arm team is history
<ogra_> (with help of the former ubuntu-arm team members indeed)
<tkamppeter> pitti, thanks.
<pitti> tkamppeter: it built everywhere now
 * ogra_ sighs, thats the third xorg lockup today since i upgraded
<hakaishi_> Hi, may I ask how to turn off the desktop effects with gnome3? Or how can I set gnome-fallback? Since the login doesn't work for me, I can't choose it there... How else can I set it?
<arand> hakaishi_: That's probably a question for #ubuntu rather
<hakaishi_> oh.. okay, thank you
<hakaishi_> I'd like to mention something that bugs me quit a bit. I reported it here -> https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/931565
<ubottu> Launchpad bug 931565 in gnome-session (Ubuntu) "The methods Shutdown and RequestShutdown in org.gnome.SessionManager do the same" [Undecided,New]
<lynxman> Daviey: by doing some bug hunting looks like 1.9 is still not fully supported (http://projects.puppetlabs.com/projects/puppet/issues?query_id=107) I'll get an answer from upstream in some hours as well
<tjaalton> pitti: yeah we'll drop the hard dep since wayland is ~api stable
<micahg> Riddell: why would you remove the flavor meta packages this would almost always seem to be the wrong thing to do
<micahg> Riddell: can I just upload a new meta now for xubuntu and fix the greeter later tonight?
<micahg> I'm really supposed to be working on other things during the day :)
<ogra_> micahg, its evening here
<ogra_> :)
<slangasek> seb128: I rather agree with the wontfixing of that bug; I don't think insecure-by-default is reasonable.  Maybe this should be a topic for UDS so that we can discuss our options in finer detail?
<slangasek> bdmurray: is there a bug pattern for bug #911436 that tkamppeter mentions (far) above?  we should probably be blocking those
<ubottu> Launchpad bug 911436 in p11-kit (Ubuntu) "https crashed with SIGSEGV in lookup_or_create_bucket()" [Critical,Triaged] https://launchpad.net/bugs/911436
<seb128> slangasek, yes, I'm fine with the current situation for precise, I just think it's a valid request
<seb128> slangasek, I don't agree that allowing bypassing the weak password warning is "insecure-by-default" though
<seb128> slangasek, there is plenty of users who don't need a password, especially not an hard one
<slangasek> then let them configure their system for passwordless autologin
<slangasek> the threshold for "hard" passwords is not particularly high
<seb128> slangasek, well, we don't offer them that option
<slangasek> we don't?
<bdmurray> slangasek: yes, I'll make sure it is working
<seb128> the installer has autologin, password, or protected
<seb128> not passwordless
<slangasek> bdmurray: ta
<slangasek> seb128: from the installer you can set as weak a password as you want, too, because that's done as root
<slangasek> so this seems to only be a problem for users who are somehow concerned about password rotation but not password strength? :)
<seb128> slangasek, well, another reason to let g-c-c do the same as the installer
<seb128> slangasek, I don't think it's a real problem in practice
<seb128> but I got annoyed by it as well in the past and wished the g-c-c dialog would let you click "I know I'm setting an insecure password but that's fine, I can deal with it"
<slangasek> well, if you can arrange for g-c-c to invoke passwd as root, you can do that
<mdeslaur> hrm, it appears g-c-c fails miserably if it gets a failure on the first try
<seb128> slangasek, I think the issue is not worth the effort, I'm fine with the Opinion status ;-)
<seb128> I just found the request fair on theory
<slangasek> you're cutting a fine line between wontfix and opinion ;)
<seb128> slangasek, well the comment mdeslaur added was rather a "we won't do it because we don't like the idea"
<seb128> rather than "we won't do it because it's work and we have better things to do"
 * slangasek nods
<slangasek> jibel, mvo: do you know why https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/job/precise-upgrade-lucid-main/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/30/artifact/lts-main-all-amd64/apt-term.log only shows packages being removed?  This seems to be a log from the second apt pass of the upgrade, where no-longer-needed packages are being removed
<slangasek> ah, no mvo
<barry> mdke: https://bugs.launchpad.net/ubuntu-docs/+bug/939729
<ubottu> Launchpad bug 939729 in ubuntu-docs (Ubuntu) "FTBFS due to broken translation" [Undecided,New]
<sladen> larsu: tkamppeter: there might be a regression in there.  It's trying to print a testpage that is page size 'iP-B4'
<sladen> larsu: presumably the PDF that is going out of the door is oversize, and/or not being cropped/forced to the printer papersize setting
<larsu> sladen, sounds like the next bug on my list: https://bugs.launchpad.net/bannertopdf/+bug/921073
<ubottu> Launchpad bug 921073 in bannertopdf "Scale-to-fit the generated page onto the printer's page size" [Critical,Confirmed]
<sladen> larsu: tkamppeter: or.  perhaps something bigger.  http://localhost:631/printers/Canon-iR-ADV-C5000s-B1-PS-V1.0  shows "PDF files is damanged - attempting to reconstruct xref table"
<larsu> sladen, okay that sounds like a different thing. I have to go off now, I'll look into it tomorrow. Which PPD are you using for that printer?
<sladen> larsu: "Generic PostScript Printer Foomatic/Postscript (recommended) (color, 2-sided printing)"
<larsu> sladen, thanks. See you tomorrow!
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  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: bryceh
<slangasek> jibel: ahwell, tried to post to ubuntu-qa@lists and I'm in the mod queue, hopefully someone can approve me :)
<bdmurray> slangasek: is there some way I could recreate that bug?  there are some bugs that were reported matching the pattern and I'd like to sort out why
<slangasek> bdmurray: if you dpkg --unpack the new version of the package providing the conffiles in question, without dpkg --configure'ing it, that should let you reproduce it
<apw> slangasek, which package does one file a bug aginst for the 'pretty stufff' one sees during install
<mr_pouit> xubuntu-default-settings_12.04.7_all.deb (19.1 KiB) NEW <<< Riddell: I don't know why you removed the package, but that's really messed up
<lamefun2> does Software Center implement AppStream?
<ogra_> apw, ubiquity-slideshow-ubuntu ?
<apw> ogra_, sounds plausible ... title still says 11.10
<ogra_> the other option would be ubiquity itself i guess
<stgraber> apw: I think I saw at least 150 people report that bug ;)
<stgraber> apw: so feel free to click on "affects me too" but I guess we're waiting on a completely new slideshow so it's not worth fixing the current one really
<stgraber> apw: ev would know the details
<apw> stgraber, heh nope as long as its there, i wish the duplicate detection ever found anything
<stgraber> apw: most people reported the issue against ubiquity instead of the slideshow
<apw> yeah, but you'd think they'd all find the duplicate ... but hey
<ogra_> if you use ubuntu-bug it does that for you :)
<stgraber> https://bugs.launchpad.net/ubuntu/+source/ubiquity-slideshow-ubuntu/+bug/899503 is the master bug I believe
<ubottu> Launchpad bug 899503 in ubiquity-slideshow-ubuntu (Ubuntu) "first slide on 12.04 thinks it's 11.10" [Medium,Triaged]
<apw> ogra_, in theory, though most of the bugs i filed this week had duplicates it couldn't point me to
<ogra_> wow
<apw> perhaps my use of english is just toooo odd to match
<ogra_> well, i'm probably spoiled by dealing with arm ... where we have only 1% of the open bugs
<ogra_> or 0.1%
<ogra_> or so
<stgraber> ogra_: I can give you half of the ubiquity ones, then you'll have plenty to go mark as dupe and test apport on ;)
<ogra_> stgraber, lets talk about that next week :)
<stgraber> ogra_: ;)
<ogra_> today and tomorrow i'm teamless ... from monday on we're teammates :)
<infinity> Dear chrimium, paths like these really inspire confidence:   CXX(host) out/Release/obj.host/protobuf_full_do_not_use/third_party/protobuf/src/google/protobuf/generated_message_reflection.o
<infinity> chromium, too.
<cnd> where's the release notes so I can add something about clickpads?
<cnd> bryceh ^^?
<bdmurray> cnd: hard to say https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
<jbicha> barry: can you try rebuilding ubuntu-docs? it should build now that itstool has been updated to not fail on translation errors
<barry> jbicha: will do, thanks
<sveinse> On a Natty system in an upstart service, do I need to use su to be able to run the service as a non-privileged user. Are there other ways?
<sveinse> The app does not support setuid(), so it need to be demoted prior to its execution
<bryceh> skaet, ^^ see cnd's q about the release notes for beta1
<barry> jbicha: yay!  ubuntu-docs rebuilt successfully
<skaet> bryceh, cnd - just put the comments you want in https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview itself right now.   I'll be populating the template into it tomorrow, and will carry make sure that any comments added to the wiki page are included.
<jbicha> barry: thanks, I probably should have found someone to try rebuilding it sooner
<barry> jbicha: no worries at all, thanks for letting me know
<cnd> skaet, bryceh, thanks!
<bryceh> skaet, thanks
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Precise Feature Freeze in effect.  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> sveinse: you should use start-stop-daemon, not su; su starts a PAM session, which you don't want for a system service
<slangasek> broder: I haven't seen any new SRU uploads for bug #858122, are you still working on that?
<ubottu> Launchpad bug 858122 in sysvinit (Ubuntu Oneiric) "incomplete migration to /run (shutdown script order has been demolished)" [High,Triaged] https://launchpad.net/bugs/858122
<broder> slangasek: yeah, real work just got in the way. i think i can get something uploaded today
<slangasek> broder: ok, cheers :)
<sveinse> slangasek: On my system it seems start-stop-daemon is associated with /etc/init.d and not /etc/init. So using start-stop-daemon from an upstart script is not frowed upon?
<slangasek> sveinse: start-stop-daemon is part of dpkg; you'll find much more use of it in /etc/init.d than in /etc/init, because many of the things it does are not needed with upstart.  But uid switching is one use case where it's still the right tool, at least up until upstart 1.4.
<sveinse> yes. thanks
<slangasek> in contrast, su is always wrong in an upstart system job :)
<micahg> does someone want to tackle bug 939842, this is the second one I saw for it
<ubottu> Launchpad bug 939842 in activity-log-manager (Ubuntu) "package activity-log-manager-control-center 0.9.1-0ubuntu2 failed to install/upgrade: trying to overwrite '/etc/dbus-1/system.d/com.ubuntu.WhoopsiePreferences.conf', which is also in package whoopsie 0.1.10" [Undecided,New] https://launchpad.net/bugs/939842
 * slangasek blinks
 * micahg is also confused by it, but didn't look into it
<slangasek> kind of a gratuitous collision
<broder> didn't ev say yesterday that he was rolling whoopsie into the activity log?
<slangasek> I don't know
<seb128> he said he would roll the preference ui there
<seb128> but that's only part of whoopsie I think
<seb128> it's maybe missing a conflicts,replace
<slangasek> breaks/replace
<seb128> whoopsie-daisy (0.1.11) precise; urgency=low
<slangasek> but yeah
<seb128>   * Drop the GNOME Control Center page for controlling crash reporting.
<seb128>     This has been moved into the activity-log-manager package and these
<seb128>  
<seb128> seems so
<slangasek> mmk
<slangasek> seb128: shall I upload?
<seb128> slangasek, feel free
<slangasek> Breaks: whoopsie (<< 0.1.10)
<slangasek> offbyone
<seb128> indeed ;-)
<slangasek> seb128, micahg: uploaded
<micahg> thanks
<bdrung> cyphermox: re bug #869635, i have not enough time to digg out the patches. i am happy to test patches if they are easily installable.
<ubottu> Launchpad bug 869635 in wpasupplicant (Ubuntu Oneiric) "long delay at shutdown/reboot - network-manager doesn't close correctly" [Undecided,Confirmed] https://launchpad.net/bugs/869635
<cyphermox> bdrung: well, really it's patches to NM, wpasupplicant and isc-dhcp, it all need to land to notice much changes
<cyphermox> bdrung: I'll see if I can put all this in a PPA, but complexity seems kind of high for a SRU
<seb128> slangasek, thanks
<micahg> anyone know offhand where the proper place to set CHROOT_MOUNT_LOCATION for schroot is?
<slangasek> I'm surprised you would want to set it
<slangasek> what's wrong with the provided default?
<micahg> slangasek: not enough space on the partition
<slangasek> not enough space to *mount*?
<slangasek> that doesn't make sense
<slangasek> what is it you're actually trying to change :)
<slangasek> CHROOT_MOUNT_LOCATION is only the mount point
<micahg> oh, where the chroot is being used
<micahg> ah, yeah, that's not right then
<slangasek> is this a type=directory chroot?
<slangasek> you probably need to fiddle with /etc/schroot/schroot.conf, I think
<micahg> ok, I think I know what I messed up, thanks
<lamont> dpkg: serious warning: files list file for package `libmount1' missing, assuming package has no files currently installed.
<lamont> what does that mean? ^^ slangasek ?
<slangasek> lamont: er, are you mixing multiarch and non-multiarch dpkg?
<lamont> does it mean that I needed to do more than just remove /etc/dpkg/dpkg.cfg.d/multiarch to disable multiarch?
<lamont> oh.  yeah maybe
<slangasek> it means the version of dpkg you're running doesn't *see* /var/lib/dpkg/info/libmount1:$arch.list because it doesn't have multiarch support
<slangasek> there's no supported downgrade path there
<slangasek> (actually, I think there technically is a supported downgrade path, but I suspect you've actually done a cross-grade)
<slangasek> you can manually move the files around in /var/lib/dpkg/info if you need to
<lamont> slangasek: worse.  I'm running dpkg outside of the chroot.  thank you for diagnosing my pain
<slangasek> :)
<lamont> I shall now go find a corner to bang against
<Daviey> infinity: Do you plan to fix bug 759545? :)
<ubottu> Launchpad bug 759545 in grub2 (Ubuntu Precise) "user prompted to update unmodified grub configuration during Ubuntu server upgrade" [Medium,Triaged] https://launchpad.net/bugs/759545
<SpamapS> Shouldn't the channel topic say Beta Freeze in effect?
<Laney> yes, and luckily it isn't locked so anyone can do it
<Laney> ;-)
* slangasek changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  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> words, words
<Laney> do-ocracy
<slangasek> :P
<doko> slangasek, about but 927423, is this seen for openjdk-6 as well?
<doko> bug 927423
<ubottu> Launchpad bug 927423 in openjdk-7 (Ubuntu) "jre/lib/security/cacerts symlink is broken" [High,Triaged] https://launchpad.net/bugs/927423
<slangasek> doko: it hasn't been reported for -6, so I don't know
<slangasek> I don't see it here on my continuously-upgraded system
<slangasek> nor in a clean chroot with -6
<doko> slangasek, just to confirm, you don't see it on 7 either?
<slangasek> I'm not using -7 and haven't tested... I happened to have a chroot around with -6 installed
<doko> ok
#ubuntu-devel 2012-02-24
<infinity> Daviey: It's on my TODO.
 * infinity wonders what the new mesa broke in EGL that makes qt4 unhappy.
<broder> slangasek: ok. just uploaded the insserv SRUs; apologies for the stalling
<maco> cyphermox: woooooah, somebody's actually looking at that bug
<maco> i forgot about it
<RAOF> infinity: Oh, what's happening?
<infinity> RAOF: qt4-x11 no buildy on arm{el,hf}, whining about GLES not functioning.
<RAOF> Hm.  Got a buildlog url handy to save me the trouble?
<infinity> RAOF: I haven't looked into it yet, in the (perhaps misguided) hope that the folks who uploaded the shiny new mesa upstream may either be (A) aware of it, or (B) prepared to take responsibility and dig deeper.
<cyphermox> maco: yeah, at it would take the best of 50 seconds to implement ;)
<infinity> RAOF:
<infinity> https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.0-1ubuntu8
 * RAOF would be one of the people responsible for mesa, soâ¦
<infinity> RAOF: Same failure pattern on armel and armhf, so pick randomly.
<RAOF> Huh.  Cannot find -lEGL on armel and armhf, but not i386 or amd64?  Oddness.
<infinity> RAOF: Not odd in the least, x86 links against OpenGL, arm links against OpenGLES.
<infinity> RAOF: So, EGL is /probably/ broken on all platforms, but it's only showing up on ARM because QT4 uses GLES on ARM.
<RAOF> Right.
<JontheEchidna> fwiw, the latest updates (dist-upgrade) wants to remove the egl stack from my computer.
<RAOF> JontheEchidna: You're probably seeing multiarch archive skew.
<JontheEchidna> yes, I did notice some 386 packages involved
<JontheEchidna> ah, yeah. looks like the ia32libs update is causing the issues
<RAOF> EGL doesn't *seem* to be broken on amd64.
<infinity> RAOF: Hrmph.  So the breakage was tailor-made just for ARM?  How kind. :P
<RAOF> Hm, no.
<RAOF> Aha.  There it is.
<smoser> hey...i shoved a 'ps w' into initramfs, and see http://paste.ubuntu.com/854829/
<smoser> does that seem right?
<smoser> bah. first one missing some. second
<smoser> http://paste.ubuntu.com/854831/
<infinity> smoser: Could be a tiny bit excessive.
<RAOF> infinity: Ah, yeah.  We dropped a symlink on the floor.
<infinity> smoser: Is it actually eating CPU time, or is it just a ton of idle chilren spawned during the initial event storm on boot?
<infinity> RAOF: Glad it's something that simple.
<smoser> well, its not the cpu time i'm concerned about.
<smoser> i was debugging bug 937352
<ubottu> Launchpad bug 937352 in cloud-initramfs-tools (Ubuntu) "root partition in may not be grown" [Undecided,Confirmed] https://launchpad.net/bugs/937352
<RAOF> infinity: Presumably you'd like that to make B1? :)
<infinity> RAOF: If you could be so kind.
<smoser> and trying to find out what might cause 'BLKRRPART: Device or resource busy'
<smoser> i'm not sure that any of the processes in that output have an open handle (as this run didn't fail to resize)
<smoser> infinity, you think each of those udevadm processes is handling an event ?
<infinity> s/adm/d/
<infinity> smoser: No, they're probably all idle.
<infinity> smoser: But on a massive event storm (such as initial boot), a ton of children can spawn to handle them.
<smoser> ah.
<infinity> smoser: In theory, they get reaped.
<infinity> smoser: (And on the pivot to real root, I think udev gets restarted, which effectively reaps them anyway)
<infinity> slangasek: Can explain it all better than I, but I'm assured that it's basically like a ghetto implementation of apache's prefork child model, and "nothing to be concerned about" (as long as they're not spinning your CPU to death)
<infinity> Err, s/://
<smoser> yeah.. i'm not too concerned about it.
<smoser> but basically, for that bug, i'm trying to figure out what it is that had a open handle on /dev/vda
<smoser> to see what was keeping it busy
<infinity> I don't suppose your growroot code shares any common ancenstry with jasper_growroot?
<smoser> the current suspicion is that there are some udev processes (like blkid) around at that time, and in racey conditions, i'm hitting sfdisk failure.
<infinity> Cause I remember fixing a few races in that last cycle.
<smoser> if that is the case, then udevadm settle would fix it
<smoser> no relation to jasper_growroot.
<smoser> i dont know which came first
<infinity> Hrm.  Maybe they should consider mating.
<smoser> but i only learned of jasper_growroot a while ago.
<smoser> yeah.
<infinity> Duplicate code offends me. ;)
<smoser> link to jasper growroot source?
<infinity> But given that we do the same basic thing on SD cards (which, due to their horrible speed, are WAY more racy than anything you're writing to), maybe it's just an ordering thing, or something.
<smoser> well... you might be surprised at disk speed.
<infinity> I might be. :)
<smoser> this particular case is qcow disk backed by a file on a filesystem.
<infinity> Still not sure that beats SD.
<smoser> so even reads are going read -> qcow-delta -> qcow-backing file -> filesystem file -> disk
<infinity> Anyhow, lp:ubuntu/jasper-initramfs is the source.
<infinity> It's hackish (your is probably prettier, though I haven't looked, it's a fair assumption), and makes assumptions about device names, but the general step-by-step resizing bit is solid and doesn't seem to break no matter how we stress it.
<smoser> the next big move is to ditch the initramfs code all together.
<smoser> as psusi (probably spelling name wrong) says that new kernel features allow us to resize a partition that is mounted
<maco> cyphermox: i know you're an ubuntu member. does lwn.net say you are or arent a subscriber?
<infinity> smoser: Yup.  Moving jasper-initramfs resize into partman in d-i is on my agenda.
<infinity> smoser: At which point, I might be able to reach some magical fairytale land of being able to do preinstalled/copy installed to/from the same media!
<smoser> well, in my case it doesn't have to be in initramfs or installer (cloud images)
<smoser> it would just run on first boot
<smoser> (or every boot, and do nothing if not needed)
<infinity> smoser: (ie: use "normal" live media to both do a live install to another disk, or to just resize itself)
<smoser> you maybe shoudl look at 'growpart' which is the primary code in 'growroot'
<smoser> (growroot just calls growpart)
<smoser> and it may be prettier, i dont know.
<smoser> same basic idea, using sfdisk.
<infinity> I didn't write jasper, and if asked, Oliver will admit that it's hideous. ;)
<infinity> But yeah, when the "move it all to d-i" thing happens, I'll rewrite, and look at other implementations.
<smoser> growpart is in cloud-utils. it has a dry-run, so you can test it out.
<cyphermox> maco: I think I didn't have an account. I may be able to respond tomorrow, assuming their system updates regularly for this stuff
<maco> cyphermox: oh ok. nvm then
<infinity> RAOF: If you fix mesa for me, be sure to poke me, so I can massage it through the queue.
<RAOF> I'm fixing now.  I'll prod you once I've uploaded.
<infinity> RAOF: My hero. ;)
<infinity> Sweetshark: Does libreoffice-voikko need some massaging to build with the new LibO upstream?
<infinity> Sweetshark: https://launchpadlibrarian.net/94071457/buildlog_ubuntu-precise-armhf.libreoffice-voikko_3.2-2_FAILEDTOBUILD.txt.gz
<infinity> Sweetshark: (Or perhaps the new LibO is missing some SDK bits?)
<micahg> infinity: new version in sid, don't know if that'll fix it
<infinity> micahg: Hard to say, since it built against LibO 3.4.5 in sid.
<micahg> one way to find out, /me kicks off a build
<micahg> infinity: nope, doesn't work
<micahg> infinity: would you be willing to process removals from Ubuntu that happened in Debian?  /me wants to fix FTBFS over the weekend, but figures quite a few are in that category
<RAOF> infinity: Sitting in the queue now.
<slangasek> broder: insserv> yay, thanks
<scientes> where is KMOD?
<pitti> Good morning
<nigelb> Morning pitti
<scientes> where is the ubuntu kmod?
<pitti> scientes: we don't have it yet; it's a bit too young to put into an LTS at this time, we'll get it next cycle
<broder> pitti: did we not at least get it into universe?
<pitti> seems not; we don't need it anywhere yet, and it will quickly get outdated, so backports etc. sound better for this
<micahg> pitti: I see some upgrade failures because cups can't be configured, can you take a look (bug 939977 and bug 939979)
<ubottu> Launchpad bug 939977 in bluez (Ubuntu) "package bluez-cups 4.98-2ubuntu1 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/939977
<ubottu> Launchpad bug 939979 in hplip (Ubuntu) "package hplip 3.12.2-1 failed to install/upgrade: ErrorMessage: dependency problems - leaving unconfigured" [Undecided,New] https://launchpad.net/bugs/939979
<pitti> micahg: yes, in a sec
<micahg> sure, no rush
<pitti> infinity: linux-meta-armadaxp builds a linux-tools-armadaxp which depends on a nonexisting linux-armadaxp-tools-3.0.0-1500
<pitti> infinity: is that supposed to exist, or copy&paste error when creating the -meta?
<infinity> pitti: The tools build is turned off in the kernel temporarily because it was broken and getting a kernel uploaded was more important than fixing the tools, AIUI.
<pitti> infinity: ack; so it's supposed to be there and will come back then?
<pitti> erk, I just got another wubi build failure due to ext4
<infinity> pitti: In theory, the tools will come back, yeah.  If not, we'll drop them from the meta.
<infinity> pitti: And, err.  ext4 failures shouldn't happen anym--... Unless I forgot to pull my branch on nusakan.
<infinity> Which I did. >:(
<infinity> pitti: Fixed now.
<pitti> infinity: cheers
<dholbach> good morning
<micahg> janimo`: did libreoffice-voikko build for you?  it failed for me earlier this evening
<infinity> micahg: And just failed on all the buildds.
<micahg> infinity: we had this conversation 6 hours ago ;)
<infinity> micahg: But at least the sync has the advantage of hilighting that it's not an arch-specific problem, so someone will perhaps fix it. :P
<micahg> infinity: the archive rebuild did that :P
<infinity> micahg: People pay less attention to rebuilds than I'd like. :/
<infinity> (We need to figure out how to fix THAT)
<micahg> we've fixed >100 since the last rebuild happened
<micahg> ~270 failures superseded
 * nixternal remembers when micahg used to be in bed at like 9pm here in chicago
<nixternal> grr, that was supposed to be in a totally difference channel. hit enter instead of alt+p to get to our chicago chan. sorry
<micahg> heh
<slangasek> now we know about your secret backchannel
<slangasek> you'll all have to move to Wisconsin
<micahg> or Portlandia :)
<nixternal> Wisconsin? that place still exists?
<micahg> it's Dellicious :)
<slangasek> is that the new catch phrase?
<nixternal> didn't the government go on strike there? though I shouldn't joke about that, since our government here in Illinois & Chicago is constantly going to prison
<infinity> micahg: So, voikko upstream claims 3.3 works with LibO 3.5 (in fact, is has 3.5-specific features), so I suspect the failure is in our LibO packaging breaking the SDK.
<micahg> ok, so that means Sweetshark^^ :)
<RAOF> Hm.  How hard is it to create a C++ function that takes a unary function and returns a nullary function?
<infinity> micahg: (I have no hard evidence to back up my assertion, mind you) :P
<Sweetshark> infinity, micahg: oh, great. I will have a look.
<infinity> Sweetshark: Thanks.
<micahg> Sweetshark: Mirv is the Debian maintainer, so it shouldn't be too hard to coordinate :)
<pitti> RAOF: creating functions on the fly in C++?
<pitti> RAOF: or just returning a pointer to one out of N existing functions?
<RAOF> Creating functions on the fly.
<RAOF> Now that I *say* this, I know it's possible, but that I'll be overloading operator ().
<pitti> RAOF: in C++? (or any compiled language for that matter..)
<RAOF> pitti: Well, it's more: take a function f(x) taking a single parameter, and a parameter z, and return a function which evaluates to f(z)
<pitti> RAOF: haskell FTW
<pitti> RAOF: so just "return f(z)" is too simple, I guess
<ion> Haskell â¥
<RAOF> Right.  I need a nullary function :)
<pitti> i. e. you really want f o z, and want to call it yourself
<Sweetshark> RAOF: 'on the fly' as in 'not known at compiletest' => impossible. of course you could write an interpreter *mumble* every language becomes a dialect of lisp at some point in time.
<slangasek> RAOF: is the function type fixed?
<RAOF> Sweetshark: Well, the underlying function f is known at compile time; I basically want to specialise a closure.
<slangasek> or do you have to cope with arbitrary function signatures? :P
<Sweetshark> ROAF: functors/function objects are your friend then
<Sweetshark> RAOF: for variable meanings of friend
<RAOF> slangasek: Indeed it is fixed.  Now that I've said this out loud I know I (a) can do it, (b) can get the outcome I want without all this faffing around.
<slangasek> ok :)
<Sweetshark> RAOF: http://www.boost.org/doc/libs/1_48_0/doc/html/lambda/le_in_details.html#lambda.bind_expressions <- if you want to get nifty
<RAOF> Yeah, I think I'll keep my niftiness for features rather than arcane language extensions :)
<Sweetshark> RAOF: yes, that kind of niftiness caused a coworker of mine preaching to gcc, MSVC and SunStudio compilers from his Bjarne-C++-Standardbook, because once he had it so that MSVC wouldnt complain anymore, SunStudio would barf at him -- with both implementations being valid C++ by the book.
<RAOF> Ah, Mr Undefined Behaviour!
<Sweetshark> RAOF: it not so much an issue with one compiler.
<Sweetshark> RAOF: No, it was defined behaviour, but MSVC and SunStudios brains were to small for the insanities of the C++ standard.
<RAOF> Ah.  Right, that other form of C++ fun.
<ion> Some quotes from a #haskell bot. :-) <lambdabot> mikeash says: you may have noticed that templates being turing complete theoretically allows you to add any language capability to C++.... so did the boost guys.   <lambdabot> kmc_ says: you should take a look at Boost, they implement things like Maybe and tuples in only a few thousand lines of C++
<Sweetshark> (and did spit out template errormessages pagewise)
<ion> Also, http://pikersden.eu/~eclipser/err.txt
<Sweetshark> ion: what to have a fibonacci sequence, but you dont have execution rights on your /home? use templates as an interpreted language: http://blog.emptycrate.com/node/271
<ion> heh
<Sweetshark> ion: boost::spirit is its own kind of insanity.
<Sweetshark> ion: also boost is just a implementation of greenspuns 10th rule of programming
<broder> RAOF: C++11 has lambdas
<broder> though i'm not sure if you can represent a function type in pure C++ or if you need to pull in boost::function
<broder> i guess you can just use a function pointer? the memory management there isn't really clear
<Sweetshark> broder: http://ask.slashdot.org/comments.pl?sid=2659339&cid=38964635
<broder> i think as long as i capture by value i can do what RAOF wants
<broder> http://paste.ubuntu.com/855140/
<broder> (build with g++ -std=c++0x)
<RAOF> Turns out I can do it just as easily with a static class funtior.
<RAOF> Although I forgot how crazy initialising a static member in C++ is.
<Sweetshark> infinity, micahg: openclipart and voikko soon fixed upstream at debian it seems.
<Sweetshark> (kudos to _rene_)
<infinity> Sweetshark: Kay.  So, not a LibO packaging goof?  I just heard the buildds breathe a sigh of relief.
<Sweetshark> infinity: no. from 3.5 on the basis-link stuff has changed and that needs to be adjusted in packages relying on it.
<infinity> Sweetshark: Fair enough/
<Sweetshark> infinity: I have enough fun for the buildds in the pipe still :/
<Sweetshark> infinity: btw I made the disc usage of the package quite a bit smaller by using hardlinks/symlinks in the build and testinstall ...
<infinity> Sweetshark: *cups his hands over the Pandas' ears*
 * Sweetshark pads pandas on the heads.
<Sweetshark> They do a good job. Much faster than the old buildds.
<infinity> Yup.  We have much faster hardware in the pipe, we just need to get some vendors to admit it exists and, like ship it.
<dholbach> Happy Fix It Friday!
<sladen> dholbach: https://wiki.ubuntu.com/Membership/LWN  is that ACLed?
<sladen> dholbach: I'm trying to update it to add the details about expiry
<dholbach> sladen, unless I'm VIP, no
<sladen> dholbach: you were the last person to edit it (in 2009)
<Guest43539> Hi, I joined ubuntu-mobile yesterday however that channel now seems closed. I am interested in the Ubuntu for Android project and well helping in contributing towards it's development. Can anyone direct me to the right place?
<dholbach> sladen, are you logged in?
<sladen> dholbach: yes
<dholbach> does logging in/out fix it? I wouldn't know how to unACL it or where to check if it is
<ajmitch> dholbach: if it's an ACL, it should be at the top of the raw text
<ajmitch> (iirc)
<dholbach> ajmitch, no, there's nothing there :/
 * ajmitch can edit the page, so it doesn't look to be locked
<janimo`> micahg, no it does not build. I just synced form Debian so we get it FTBFS on all arches and it does not look like an armhf specific thing which may lead people down the wrong paths
<janimo`> was that a bad thing to do?
<infinity> janimo`: It's all good, _rene_ is all over fixing it in Debian and filing bugs.
<janimo`> infinity, yes, noticed just a few mionutes ago in the LibO-dev channel
<infinity> janimo`: But the sync was probably unnecessary, people were aware it wasn't arm-specific.
<ajmitch> sladen: manage to edit it?
<janimo`> infinity, I was not, and maybe other arm ftbfs hunters were in the same boat
<janimo`> I automatically skip all-red rows in the table whereas arm column only jump out :)
<infinity> sladen: My usual advice for wiki ACL issues is "hit Ctrl-R harder".
<janimo`> I then saw there was an i386 bug filed on voikko, from the autobuilds
<infinity> sladen: (It has no ACL that I can see)
<apw> ev, i just got a package installation error and when the crash detect stuff fired, it said 'This report is damaged and cannnot be processed.", reporting an IOError(13, 'Permission denied')
<sladen> infinity: dholbach: ajmitch: ta.  Eventually managed it using a separate 'lynx' sessions running in a terminal
<dholbach> wow
<ajmitch> that's pretty special
<ajmitch> useful to know about the expiry time though
<sladen> the crash reporting process about the crash crashed, so we've fired up a crash reporting process to report the crash that was being reported when it crashed
<infinity> drwatson used to have that bug...
<infinity> Infinite watsons on early NT4 was no end of fun.
<ogra_> hmpf, why are the sound settings so screwed up since yesterdays upgrade
<ogra_> the hardware tab is gone, so i cant select the mode my BT headset uses anymore
<pitti> that hardware tab was really confusing
<pitti> ogra_: the mode is in the output tab now
<ogra_> pitti, well, its the only way for me to make my BT headset not run in hifi mode (e.g. as an actual headset to use the mic)
<exco> what package do I file bugs in carl9170 against?
<pitti> ogra_: hm, that seems to work fine here
<ogra_> its greyed out (as it always was ... apart from the HW tab i could set it nowhere)
<pitti> ogra_: oh, indeed; same here
<ogra_> pitti, i could imagine that settings that can only apply globally (in *and* output) become greyed out
<pitti> diwic: ^ who worked on that again?
<ogra_> i can select output for the builtin speaker vs the plugged headset
<ogra_> but cant change a thing for settings that need to apply for both, in and out at the same time anymore
<diwic> pitti, me and ronoc
<pitti> ogra_: in the past I didn't even have to -- my headset just used the low-quality bidir mode in mumble and friends
 * ogra_ wonders if there is a cmdline way to tell his BT headset to not use hifi mode
<diwic> ogra_, there is
<diwic> ogra_, want me to tell you? :-p
<ogra_> diwic, that would be awesome :)
<diwic> ogra_, anyway the easiest workaround is to install pavucontrol which is an alternative GUI
<ogra_> ok
 * ogra_ does so
<diwic> ogra_, you should be able to set profile from the "configuration" tab in that application
<ogra_> ok
<diwic> ogra_, but also file a bug against the gnome-control-center package, please
<ogra_> will do
<diwic> ogra_, out of interest, what profiles can you select between?
<ogra_> HSP/HFP and A2DP
<diwic> ah, same as here then
<diwic> I should be able to reproduce it
<ogra_> hmpf, the mumble setup wizard just hangs after i selected the device :(
<Sweetshark> that would mean rolling back the sacjava, libbase MIRs as they are only needed for reportbuilder and (no libloader=no reportbuilder). meh.
 * Sweetshark needs to take a walk.
<pitti> Sweetshark: don't worry about the rollback; they will semi-automatically fall out of main again as soon as you drop the b-deps
<jibel> slangasek, re upgrade of main - no idea why apt-term.log shows only removals. It looks like a bug in update-manager.
<jibel> slangasek, the only log file I found which shows which packages have been upgraded is dpkg.log. It is attached to the test results
<jibel> slangasek, I saved the VM if any one want to look into this.
<infinity> Sweetshark: Are you already aware of the need for a !armhf fix for the libreoffice-report-builder-bin depdency in the libreoffice metapackage?
<infinity> Sweetshark: (Or, alternately, building it for armhf, I guess, but it's not currently)
<Sweetshark> infinity: unfortunately the solution is dropping it, as reportbuilder pull in a huge java mess called maven in.
<infinity> Sweetshark: Actually, I'm confused now.  Is it built anywhere anymore?
<infinity> Sweetshark: The version in the archive on other arches seems to be stale.
<infinity> Sweetshark: So, that dep should just be dropped from the metapackage entirely, for all arches...?
<TLE> pitti: hallo
<Sweetshark> infinity: yes, I enabled building it in the last upload, but it turned out it would require MIRs we cannot fullfill. So I am not building it anymore, and drop the dep in the metapackage.
<infinity> Sweetshark: And I should clean the old NBS libreoffice-report-builder-bin binaries from the archive, so this stops looking like an arm-specific issue.
<TLE> pitti: I was wondering what the status is of the natty lang pack export
<infinity> Sweetshark: Alright, the stale binaries are removed.  When do we see the upload with the fixed meta deps? :P
<Sweetshark> infinity: source package is building
<Sweetshark> infinity, pitti: libreoffice_3.5.0-1ubuntu4 in /home/bjoern on chinstrap
<infinity> Sweetshark: Poking it with a stick.
<Sweetshark> infinity: it hisses
<Sweetshark> pitti: so only now only the libexttextcat automake1.7 dep remains right?
 * infinity watches debdiff cripple his laptop.
<infinity> La la la.
<pitti> Sweetshark: ah, you dropped the extra build deps?
<pitti> infinity: oh, are you sponsoring already?
<infinity> pitti: Yeah.
<pitti> TLE: sorry, I didn't deal with that yet, too much stuff going on
<infinity> pitti: Well, if this command ever returns, I'm reviewing and sponsoring. ;)
 * infinity goes to find a coffee and cigarette.
<Sweetshark> infinity: argh, that one it buggy still
<infinity> Sweetshark: Oh.  Then I'll wait for another. ;)
<Sweetshark> (additional comma at the end of the deps)
<infinity> Oops.
<infinity> Sweetshark: I'll go find that coffee, ping me when the shiny new one's up.
<Sweetshark> infinity: well, I removed the last dep in the list :/
<TLE> pitti: no problem, let me know when you find the time
<doko_> jamespage, maven wants to promote again ...
 * jamespage sighs
<Daviey> jamespage / doko_ : For 12.10, should we look at allowing maven in main?
<doko_> Daviey, if it's maven3, maybe
<doko_> jamespage, ahh, scroll up, it's libreoffice reportbuilder
<jamespage> doko_, I was just gazing at this - http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<doko> jamespage, Sweetshark: and libloader ...
<jamespage> doko, Sweetshark: if that is what is pulling it in it might be possible to drop maven by disabling testing in libbtm-java
<jamespage> Daviey, we could but the star chart is impressive - http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<Daviey> jamespage: happy, happy, joy joy
<jamespage> doko, Sweetshark: or demote libehcache-java to Suggests? I'm not familiar with libloader
<pitti> it's being handled Sweetshark already has a new version prepped
<pitti> (image a comma there)
<pitti> argh TGIF -- "imagine"
 * jamespage stands down
<pitti> jamespage: it's not just the recommends, it's also build deps
<pitti> I guess c-m gets a bit confused with so many packages
<jamespage> pitti, looks like it - I see
<jamespage> pitti, Sweetshark - what fix are you going for?
<pitti> Sweetshark | pitti: so only now only the libexttextcat
<pitti> jamespage: so I guess he dropped the new build deps again
<pitti> LibO has some stripped down internal libraries, I guess he's using those
<pitti> in sum they'd probably take much less space like this, too
<pitti> libexttextcat can be fixed to use automake instead of -1.7
<Sweetshark> infinity, pitti: 3.5.0-1ubuntu4 FIXED on chinstrap.
<vanhoof> herton: hi
<herton> vanhoof, hi
<vanhoof> herton: dont think we're going to get the ack on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/906832 from the original reporter
<ubottu> Launchpad bug 906832 in linux (Ubuntu Oneiric) "Broadcom bluetooth device BCM20702A0 [0a5c:21e3] not supported" [High,Fix committed]
<vanhoof> we (hwe) got involved with that one since it's quite similar to two others (different device ids) in this current SRU
<vanhoof> but we don't have that specific chip in house yet to verify on our own
<vanhoof> have even emailed the guy directly a few times.
<vanhoof> assuming the deadline is COB today?
<herton> vanhoof, yes, looks like the guy isn't going to test it. We can wait until monday, since this is verification week.
<vanhoof> herton: ack ok
<vanhoof> herton: if i hear back in email I'll let you know
<vanhoof> herton: and post to the bug :)
<herton> vanhoof, ok, thanks
<jibel> slangasek, the problem with upgrade test of main seems to be a bad interaction with the way we capture debconf prompts
<didrocks> cnd: ping me when you are around, some remarks on xorg-tests package
<cnd> didrocks, pong
<didrocks> oh, already? :)
<jibel> slangasek, I disabled debconf prompt capture, re-ran the test and it seems to proceed with the upgrade. result in 4 hours
<didrocks> let's switch to pm to not annoy people :)
<jibel> slangasek, it was faster than expected. Now main upgrade failed but for a good reason :)
<pitti> Sweetshark: roger, uploading
<pitti> Sweetshark: so this is the good one for b1? or does anything else need to be sorted out?
<pitti> Sweetshark: it basically reverts to ubuntu2, right?
<Sweetshark> pitti: it revert parts, but not all. some MIRs went well, so lets keep them.
<pitti> Sweetshark: ah, good
<Sweetshark> now, if I am not mistaken we only need to drop the automake1.7 dep in libexttextcat.
 * Sweetshark has a source package already.
<pitti> yes
<pitti> Sweetshark: toss it over? It's a good thing to fix either way
 * Sweetshark fuddles it out of the virtualbox
<pitti> Sweetshark: ubuntu4 uploaded (CC: infinity)
<Sweetshark> pitti: tweaked libexttextcat in on chinstrap
<pitti> Sweetshark: can you please upload libexttextcat_3.2.0-1ubuntu1.dsc?
<pitti> Sweetshark: (you uploaded libexttextcat_3.2.0-1.dsc)
<Sweetshark> pitti: ugh
<Sweetshark> pitti: done
<pitti> Sweetshark: uploaded; would be nice if you could send this to Debian, too
<bkerensa> https://code.launchpad.net/~bkerensa/ubuntu/precise/ubuntu-wallpapers/fix-for-296538/+merge/92592
<pitti> bkerensa: ^ lots of conflicts
<pitti> bkerensa: also, it needs to be called .png for backwards compat reasons
<pitti> barry: how much would you hate me when we switch lsb-release back to py2.7 and drop python3 from the CDs again? we are a bit despearate on size now
<pitti> barry: and we only carry it for the tiny lsb-release script
<pitti> barry: from next cycle on we'll have bigger images and can keep it, promised
<pitti> barry: (already talked to stgraber, doko, ScottK, and skaet)
<barry> pitti: i will hate you forever
<barry> pitti: kidding :)  do what you have to do
<pitti> barry: thanks, taking the bullets *sob*
<barry> pitti: i'm very happy with the progress we made, and i'm confident we'll see py2 relegated to universe for 14.04!
<pitti> sounds like a plan
<pitti> barry: and indeed, lots of new py3 modules in precise, including py3-dbus which was a major blocker indeed
<pitti> barry: now we just need launchpadlib
<barry> pitti: yep, we'll get there
<pitti> Sweetshark: now, that's much better: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<Sweetshark> pitti: nifty!
<pitti> Sweetshark: promoting textcat now
<pitti> Sweetshark: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt has the demotions now, doing them as well
<Sweetshark> pitti: although its a bit boring. It invokes the same urge in me as precise did in chrisccoulson (according to the quotes page): "Can I break it?!"
<slangasek> jibel: oh, you mean it wasn't doing the upgrade at all? :(
<pitti> Riddell: will calligra drop the recommends: lyx? (http://people.canonical.com/~ubuntu-archive/component-mismatches.svg)
<pitti> Daviey: ^ on the same page, do you know the status of the keystone MIR?
<pitti> this has been there for months
<slangasek> jibel: thanks for identifying the problem, though
<Riddell> pitti: I don't know, wasn't aware of it, but I expect it can yes
<jibel> slangasek, it was doing the upgrade, but not completely
<jibel> slangasek, there is a bug in apt or update-manager here any way
<Daviey> pitti: yes.. it's blocked
<Daviey> pitti: The underlying code is being changed next week
<Daviey> (rewrite from scratch)
<Daviey> Once that is introduced into the platform, jstrand's team will need to re-do the audi.. sadly.
<pitti> Daviey: new nova needs new MIRs: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<pitti> Riddell: ^ FYI
<pitti> will depwait, so no immediate archive breakage
 * pitti waves good bye, have a nice weekend everyone
<dholbach> pitti, you too
<slangasek> jibel: where did you see that the upgrade was incomplete then?
<m_3> cjohnston: hi.. how many django app servers are typically used in a single summit deployment?
<cjohnston> m_3: just 1
<m_3> cjohnston: gracias!
<cjohnston> :-)
<chrysn> once again, i'd need some help finding out why my ppa builds don't work:
<chrysn> in the chrysn/openscad ppa, i'm trying to build opencsg-1.3.2-2lucid1, for which i've collected some backports in the same repository
<chrysn> i've previously made the experience that the builder uses the ppa itself to satisfy build-depends.
<chrysn> but now, it complains about missing build dependencies "libglew-dev (>= 1.5.4)" -- but the build dependency says "libglew-dev (>= 1.5.4) | libglew1.6-dev | libglew1.5-dev (>= 1.5.4)", and i provide libglew1.6-dev in the ppa
<chrysn> admittedly, libglew-dev is (in that ubuntu version) also a virtual package whose version can't be satisfied, but it shouldn't bee too uncommon to have alternative build-depends whereof the first is virtual
<Ampelbein> chrysn: I think the sbuild version LP uses doesn't support resolving alternate dependencies.
<arand> chrysn: I'm not sure, but the log seems to indicate that you should not use the metapackage?
<micahg> it doesn't support alternatives where the one is versioned
<micahg> bug 594916
<ubottu> Launchpad bug 594916 in Launchpad Auto Build System "buildd does not install alternate dependency for versioned ORed build-dependencies" [Low,Triaged] https://launchpad.net/bugs/594916
<chrysn> thanks you all. i guess i'll work around it by building an explicitly depending pakcage for the moment
<chrysn> arand, the reason i'm using the "metapackage" is that the newest version (1.7) doesn't build a libglew1.7-dev but a generic libglew-dev
<adam_g> anyone have any knowledge of the squid -> squid3 transition? are there blueprints from last cycles around, or mailing list discussion anywhere to get some context around the decision?
<ansgar> Hi, I was wondering if Ubuntu might want to sync libquvi and cclive from experimental.  It not really usable right now (#874554).
<ansgar> For your entertainment this would also include a soname change, but libquvi only has two reverse dependencies (cclive and one other).
<micahg> ansgar: I count 3 reverse dependencies in the archive, but feel free to file the request if it's broke (requestsync -e -d experimental), by the way, what's keeping them from being uploaded to unstable?
<micahg> it'll still need release team approva
<micahg> *approval
<ansgar> micahg: Waiting for Debian's release team to ack the upload to unstable.
<micahg> ah, ok
<maco> >_>   <_<   new vm wants to use nano when i type "dch -i" setting EDITOR=/usr/bin/vim in bashrc and sourcing it didn't change this. where does dch keep its notion that i want nano?
<cody-somerville> maco, try running select-editor
<maco> ooh didnt know that existed
<maco> thanks cody-somerville
<maco> my next guess was going to involve ln -s
<cody-somerville> maco, dch uses sensible-editor which will look at VISUAL and then EDITOR
<maco> cody-somerville: its been a while since ive doen this. whats that thing for making pbuilders real easy, and what package is it in?
<cody-somerville> maco, There are a number of different things out there - but the only thing that I know of that is packaged is pbuilder-dist in ubuntu-dev-tools
<cody-somerville> maco, I personally just use a .pbuilderc file and environmental variables: http://pastebin.ubuntu.com/855806/
<maco> pbuilder-dist is what i was thinking of. thanks!
<cody-somerville> maco, You're most welcome :)
<cody-somerville> If you have any further questions, don't hesitate to ping me.
<slangasek> stgraber: should the values on dns-nameservers lines always be numeric?
<slangasek> stgraber: to be precise: does [0-9.]+ cover it as a regexp?
<slangasek> (thinking specifically of ipv6 here)
<stgraber> slangasek: if you extend your definition of numeric to contain ":" then we should be fine, yes
<slangasek> ok
 * stgraber is quickly checking on a system using dns-nameservers with ipv6
<slangasek> some things like to put ipv6 addresses in brackets, didn't know if this was one
<stgraber> slangasek: at least resolv.conf doesn't use brackets but I'll quickly check for resolvconf
<slangasek> stgraber: also, I believe we have to remember that a-f are numbers for this purpose? :)
<slangasek> does netcfg give us upper or lower case?
<stgraber> good questions, it's probably taking them as-is from the RA so I'd say lowercase
<slangasek> the RA is text?! :)
<beuno> so, switching workspaces is broken, right?
<bryceh> beuno, try <super><shift><arrow> ?
<stgraber> slangasek: netcfg doesn't deal with RDNSS directly at the moment, it uses rdnssd if around which returns the IP in lowercase
<slangasek> stgraber: ok
<stgraber> slangasek: I'm checking what's dhclient's behaviour for dhcpv6 now
<stgraber> slangasek: actually, netcfg doesn't write these to /etc/network/interfaces, it'll just mark the interface "iface ethX inet6 auto" or "inet6 dhcp"
<beuno> bryceh, nope, not working either
<slangasek> stgraber: so we only have ipv4 to worry about?
<beuno> tried it, it's what the overlay says now
<stgraber> slangasek: so the only case where dns-nameservers contains an IPv6 value as a result of an install is when installing with static
<stgraber> slangasek: and in static, it's whatever the user entered
<slangasek> stgraber: ok, so upper+lower case are valid
<stgraber> yep
<bryceh> beuno, dunno then.  does the icon switcher thingee work?
<beuno> bryceh, it does
<beuno> I'll file a bug
<beuno> thanks bryceh
<slangasek> stgraber: how's this look to you? ;)
<slangasek> grep -Eq '^[[:space:]]*(iface[[:space:]]+.*[[:space:]]+inet[[:space:]]+dhcp|dns-nameserver[[:space:]]+[0-9A-Fa-f.:]+[[:space:]]*(#.*)?$)' /etc/network/interfaces
<barry> slangasek: can you sanity check something for me?  try to apt-get the oneiric source for kexec-tools and build the source package w/debuild -S.  does it work or fail for you?
<stgraber> I think we could extend to cover "inet6 dhcp" too but it's not going to be a common use case ;)
<stgraber> it needs to be "dns-nameservers" (plural)
<stgraber> and can be dns_nameservers
<slangasek> barry: build it on what environment? oneiric, precise?
<stgraber> other than these, it looks good (though my brain's regexp parser is far from perfect ;))
<slangasek> yeah, I fed it a couple of examples here
<slangasek> but of course I missed the variable name misspelling
<slangasek> thanks
<slangasek> stgraber: resolvconf uploaded, then
<slangasek> stgraber: I'll have a look at ifupdown a little bit later
<stgraber> slangasek: thanks!
<stgraber> slangasek: btw, blog post published, will see how many people complain about it in the comments ;)
 * infinity starts trolling stgraber's blog.
<slangasek> stgraber: just block everything from quagga_fan_in_calgary
<infinity> >:(
 * broder resists the urge to make canada jokes
<stgraber> slangasek: I'll just add a new static route to my quagga to route quagga_fan_in_calgary to a blackhole ;)
<barry> slangasek: i'm just trying to get a source package built :/
<slangasek> barry: yes, but which environment are you trying to build it in :)
<barry> slangasek: i've tried on precise, but also in an oneiric chroot.  i've tried from apt-get source and from the udd branch, all fail in the same way
<infinity> barry: With the build-deps installed?
<barry> infinity: doesn't even get that far.  `debian/rules clean` fails because it can't unpatch
<slangasek> barry: ok, having a look
<infinity> barry: But, I dunno, if you're just patching the pristine source, and thus don't need a clean, cheat and debuild -S -nc :P
<infinity> barry: Yes, but unpatch may rely on the build-deps being installed.
<barry> infinity: yeah, may have to do that ;)
<slangasek> barry: right, 'debian/rules clean' isn't guaranteed to work without the build-depends installed
<slangasek> debian/rules:12: /usr/share/dpatch/dpatch.make: No such file or directory
<slangasek> make: *** No rule to make target `/usr/share/dpatch/dpatch.make'.  Stop.
<slangasek> like so
 * infinity nods.
<barry> gotcha, okay, thanks
<infinity> You could just install dpatch.
<infinity> But if you're sure you're doing things cleanly, -nc is fine.
<slangasek> in a chroot in a container in a vm in a pocket universe
<slangasek> where it won't contaminate anything
<barry> i actually thought i had it installed but apparently not ;)
<infinity> Just double-check your debdiff after an -nc build to make sure you didn't introduce cruft.
<barry> slangasek, infinity actually, no.  on precise i *do* have dpatch installed.  installing build-deps in an oneiric chroot does pull in dpatch, but `dpatch deapply-all` still fails
<barry> so i will try -nc, but this seems like a problem with the package
<infinity> Or a problem with how you fiddled with patches in your upload?
<infinity> After you do that -nc build, dpkg-sourc -x it to a new directory and make sure it builds. :P
<barry> infinity: i haven't uploaded anything yet, just apt-get source && debuild -S
<infinity> Oh.
<infinity> Though it may now be dirty from previous sadness.
<infinity> That would be a bug, mind you. :P
<infinity> clean making things unclean isn't, sadly, uncommon.
<barry> infinity: that's what i was looking for :)
<barry> :(
<infinity> (That said, we expect build-deps to be installed for all steps, so if it works correctly from a fresh download with build-deps installed, the rest is a wash)
<barry> cool, infinity, slangasek thanks for the confirmation
<barry> infinity: right, but it doesn't so i'll file a bug
<barry> actually, i should check the precise version.  it's not worth an sru
<slangasek> but you're doing an SRU anyway? :)
<slangasek> so it might be worth fixing the build system along the way
<barry> slangasek: think so?  i thought it was generally frowned on to mishmash fixes.  but if not, and it's an easy-ish fix, it would be wroth it
<barry> worth it even
<barry> slangasek, infinity yep, precise is happy
<infinity> I'm curious how the original source package was built if it is, indeed, broken.
<barry> infinity: my question too!
<micahg> well, it's using dpatch, that's strike 1 :)
<barry> yes :)
<slangasek> it's frowned upon to include low-priority fixes in an SRU; but fixing things like "the build system is fubar" warrant coming along for the ride
<infinity> Indeed.
<infinity> Let me double-check this.
<barry> fair enough, yep, and thanks
<infinity> barry: I hate to be the bearer of confusing news for you, but in an oneiric chroot, with build-deps installed (all build-deps, mind you), a freshly-unpacked kexec-tools source builds itself just fine.
<infinity> Even several times in a row.
<barry> infinity: dang, but okay that's very interesting and makes me more optimistic.  thanks for the confirmation
<infinity> barry: I suspect you're working in a dirty source tree from previous no-build-deps-installed clean failures, or sometihng.
<infinity> barry: So, a fresh download, a fresh unpack, and making sure ALL the build-deps are installed before you build your source should do it.
<barry> infinity: trying that...
<infinity> (The kicker being that it not only needs dpatch to build the source, but also autoconf/automake)
<infinity> But just check with dpkg-checkbuilddeps before you build. :P
<barry> infinity: the combination of building in the distroseries chroot + installing build-deps before debuild -S seems to solve the problem
<infinity> barry: Good deal.
<slangasek> adam_g, zul: is this new upstream version of glance needed/wanted/expected for beta-1?  (currently sitting in the freeze queue)
<slangasek> and should it have a FFe for the new upstream version?
<adam_g> slangasek: hmm, im not sure? the other parts of openstack were uploaded at the same time
<adam_g> slangasek: that new upload does have a new dependency that is not in main, though
<slangasek> adam_g: well, that new dep is already on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt due to nova
<slangasek> so that wouldn't seem to be a blocker IMHO
<adam_g> slangasek: hm then im not sure, the new version is expected to be uploaded with the rest of openstack every week, not sure why it'd need a FFE in this case
<slangasek> adam_g: n/m, there's a standing FFe that I wasn't aware of
<slangasek> so that's good to go in
<slangasek> but someone probably needs to fix those new deps on universe
<adam_g> slangasek: what is the policy on new MIRs for such things this late?
<slangasek> adam_g: MIRs aren't subject to the freeze
<slangasek> it's the changes to the packages already in main that are usually dubious :)
<slangasek> (in this case it's fine, and someone needs to follow through on the MIR)
<adam_g> slangasek: gotcha
#ubuntu-devel 2012-02-25
<L3top> Is anyone particularly familiar with livcd preseeding? (ubiquity)
<L3top> Mine is either not found or ignored and I don't know how to tell which what or why.
<Daviey> slangasek: If you get this, we have 3 options as i see it:
<Daviey>  - Get the MIR achieved in time
<Daviey>  - Revert the upload
<Daviey>  - Rely on the fact that it's dep-wait, causing the old binary to be part of beta-1.
<Daviey> The way i see it, we'll see if 1 is possible, but fallback to 3.
<nava> Hi all, i have some simple mock up for software centre, where should i show it ?
* Ampelbein changed the topic of #ubuntu-devel to: Precise Beta-1 Freeze in effect.  Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/xmGdCW | #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:
<Ampelbein> (updated link to build failures to the latest rebuild results)
<infinity> Ampelbein: Thanks.
<jokerdino> Ampelbein: linky? :))
<Ampelbein> jokerdino: In the /topic
 * jokerdino *facepalms*
<Ampelbein> ;-)
<jokerdino> ok so, i was looking at this bug https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/898463
<ubottu> Launchpad bug 898463 in software-center (Ubuntu) "GParted is in USC "Themes & Tweaks" section rather than "System"" [Undecided,Confirmed]
<jokerdino> and not sure where to start
<infinity> jokerdino: Well, it's either going to be a bug in gparted's desktop file, or a stale desktop file in app-install-data, or (less likely, but possible) a bug in software-center's parsing of gparted's desktop file.
<jokerdino> the gparted desktop file is fine.
<jokerdino> Categories=GNOME;System;Filesystem;
<jokerdino> need to look into the other two
<jokerdino> so i would have to branch the app-install-data to check?
<slangasek> Daviey: glance isn't dep-wait, it has a binary dep but no source dep
<slangasek> Daviey: I would certainly recommend the MIR option
<SpamapS> I'd recommend that they use python-dateutil instead.
<SpamapS> already in main.. much better implementation
<slangasek> oh, well in that case
<slangasek> :)
<slangasek> but yeah, I don't think reverting the upload is the first choice
<SpamapS> I mean, might require code changes.. but I've done patching to do that exact replacement.. very simple
 * SpamapS would do a git checkout of glance and see about fixing it.. but his cable provider has decided to get DoS'sd today
<ScottK> SpamapS: Dont you have some magic cloud place so that's not a problem?
<SpamapS> ScottK: I'm experiencing about 2s lag on all keypresses in ssh :(
<SpamapS> so.. no
<SpamapS> I can jump on 3G
<SpamapS> but its Saturday
<SpamapS> and sunny
<ScottK> You're in LA it's always sunny.
<SpamapS> Heh.. true. :-P
<SpamapS> Ugh, its like txaws all over again.. nova is build-depending on python-tz ... which is also covered by python-dateutil
<SpamapS> seems like OpenStack has made a tradition out of adding new dependencies late in their release cycles
<tumbleweed> not having looked at the source here, dateutil can't do everything that tz can, one often needs both
<SpamapS> yeah, perhaps python-tz does belong in main
 * SpamapS is always against expanding main unless absolutely necessary. :-P
<SpamapS> ok time to go enjoy this Saturday
#ubuntu-devel 2012-02-26
<srini_> hi anyone help me regarding ubuntu?
<srini_> may i know for wat purpose ubuntu-devel is used?
<srini_> please help me
<Ampelbein> srini_: see the /topic ;-)
<srini_> Ampelbein, what is that?
<Ampelbein> srini_: The channel topic describes what the channel is about.
<srini_> Ampelbein, where can i get to know the uses of upcoming ppa ? please dont show me your hand to launchpad..am new to this..i can't understand in that site
<jokerdino> srini_: what ppa are you talking about? if you give us more info, we can help you better
<Ampelbein> srini_: I don't understand the question. Do you want to know what a ppa is, or how to use one, or how to create one?
<srini_> Ampelbein, i need to know the upcoming releases of ppa.And also i need to know the details of it.
<micahg> how to create a PPA -> #launchpad, how to create packages for a PPA -> #ubuntu-packaging
<srini_> micahg, am writing a blog regardiing linux.i need something new to write post about ubuntu.
<srini_> pls help me
<astraljava> srini_: I suppose #ubuntu-marketing could help you out.
<srini_> astraljava, thank u
<micahg> ls
<micahg> oops :)
<iulian> .
<iulian> ..
<iulian> Bah, too late.
<geser> cjwatson: Hi, as you sponsored my vim merges in the past: bug #927642 is awaiting sponsoring if you want to grab it
<ubottu> Launchpad bug 927642 in vim (Ubuntu) "Merge vim 2:7.3.429-2 (main) from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/927642
<infinity> geser: There may be sentimental reasons why some of us would like to keep the changelog delta going back to warty.
<geser> infinity: even if the real remaining delta is around 30-40 lines and the changelog entries over 1000 lines?
<penguin42> they get truncated from the binary package these days anyway don't they?
<tumbleweed> geser: and the first entry is a merge, there is already missing history
<tumbleweed> penguin42: yes
<geser> forget about it that the changelog is truncated now
<geser> will re-add those 800 lines of changelog delta which I truncated
<penguin42> otherwise it would have been silly to dominate the size of vim.tiny by the changelog :-)
<geser> I was trying to find a balance between preserving history and to ease the reviewer (by making it easier to find the real changes in the debdiff)
<geser> https://launchpadlibrarian.net/85975298/vim.debdiff is the debiff of the last merge (with complete changelog delta)
#ubuntu-devel 2013-02-18
<pitti> Good morning
<Quintasan> Good morning.
<dholbach> good morning
<scientes> gm
<zequence> diwic: Hi. I was just giving PA 3 a go. Seems to work a lot nicer with jack. There are a few odd things that I'm wondering about. PA is able to use multiple interfaces at once, correct? As I start jack, I need to set PA to use jack of course. Let's say rhythmbox is using PA all along this process. Then, when I stop jack, and start it again, PA is now not using jack anymore, but Rhythmbox is.
<zequence> diwic: I'm thinking it might make good sense to have the module set PA to use jack automatically. Optimally, one should be able to set this in user settings somehow. But, initially, I think that's what people would expect to happen. What do you think?
<diwic> zequence, module-jackdbus-detect should do this
<zequence> diwic: the sink and source are created, but PA is not set to use the jack sink and source. I do that manually
<diwic> zequence, but it is possible that streams need to be moved manually in PA from the hardware sink to the JACK sink and back again as you start/stop jack
<diwic> zequence, right. This is all part of the routing, which currently has a non-scalable solution, pending a better one that is currently implemented...we hope
<zequence> diwic: will this happen before the release of 13.04?
<diwic> zequence, no
<diwic> zequence, 3.0 is what's going to be in 13.04.
<zequence> Ok, I think I might want to patch the module meanwhile. I'll have a look at that next week (studying for a A+ certificate this week)
<zequence> ..or see what is possible, and what would be a good thing to do
<diwic> zequence, ok, patches welcome :-)
<diwic> zequence, but given that 13.04 is two months from release, there is not much time.
<diwic> zequence, Feature Freeze is 7th of March
<zequence> diwic: Yep. Should be ok
<hrw> ech, FF... I wonder will I get chromebook support in archive to that time
<zequence> hmm, ok. I should probably do that pretty soon then
<hrw> zequence: I do wonder when audio in linux will get automatic output switch on hdmi plug in x86 world
<zequence> hrw: That sounds like something for the pulseaudio people to do :). I'm a developer for Ubuntu Studio, and am mainly concerned with jack and PA interoperabilty. I use hdmi for my monitor. I use a TV as my monitor. I don't want the TV to be my speaker. I have two studio monitors for that
<zequence> hrw: I suppose one could have a advanced setting toggle for that kind of thing somewhere, given that hdmi can be detected in smart ways
<hrw> zequence: I gave new netbook for my wife as birthday present. amount of problems with 'hdmi connect, audio on speakers' is arghhh
<hrw> zequence: and I do not want her to go to PA settings each time to switch default output hdmi<>speakers
<zequence> hrw: I could see the point in having that as an option, and maybe also as a default. Probably the more technical person, who might not want things to always happen automatically is also the kind that more easily would be able to change that in somwhere in settings
<mterry> pitti, mind if I swap patch pilots days with you?  I have this Thursday, but would like to have your slot next Monday
<pitti> mterry: no problem
<mterry> pitti, thanks
<pitti> mterry: I updated my calendar
<mterry> k
<caribou> I have a total nOObie's python question: should I concentrate learning directly on Python 3 or python 2.7 ?
<pitti> caribou: I'd recommend py3
<pitti> caribou: you are going to get a much cleaner understanding of e. g. byte arrays vs. strings, and py 3 has some nicer API in some places
<caribou> pitti: that's what I thought
<pitti> caribou: but it depends a bit, e. g. the juju world is still firmly py2
<xnox> caribou: this is not really the right channel for such questions. #ubuntu-app-devel is better for questions about developing on ubuntu or targetting ubuntu. This channel is about developing the core ubuntu operating system. But yes, I'd also recommend python3 directly, and if need be its easy to write python3 which is also happens to be valid python 2.7.
<pitti> the desktop world is rapidly moving towards 3
<caribou> xnox: understood, but I only needed a quick opinion and I hate joining a channel just for a question. Looks like I'll add #ubuntu-app-devel to my list
<xnox> ;_
<xnox> ;)
<caribou> xnox: thanks for the info
<caribou> xnox: tbh, the code I'm hacking at is apport which is py3 so I knew that pitti was hanging around here ;-)
<alkisg> Hi, with the Precise 12.04.2 CD having the quantal-lts kernel, samba is unusable due to this bug: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1016895
<ubottu> Ubuntu bug 1016895 in samba (Ubuntu Precise) "smbd crashed with SIGABRT in dump_core()/setgroups being passed a -1 group is causing crashes." [High,Triaged]
<xnox> caribou: if you are hacking on apport, all irc channels policy is waved and you can ask us anything on any channel!
<alkisg> That's fix-released in quantal, but for some reason the planned backport never happened
<alkisg> Can I do something to help in SRU'ing it?
<caribou> xnox: :D
<pitti> caribou: FYI, apport still needs to run with 2.7 as well, so please don't use py3 only API (or fallbacks, the code has a few already)
<caribou> pitti: don't think I'm smart enough on python to do any of those, I'll only use very basic things but I'll keep an eye on it
<xnox> caribou: if sys.version < '3':
<xnox> easy
<caribou> xnox: /usr/bin/kernel_crashdump already invokes /usr/bin/python3
<xnox> alkisg: you could update the bug description as per https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
<caribou> xnox: but I'll take a note of that
<alkisg> xnox: is that enough? I saw jamespage was working on it, but I don't know why the work stopped...
<xnox> alkisg: what do you mean " by enough"? SRU template with a testcase is the next step one should complete, then anyone can upload it into -proposed unapproved queue, then SRU team will review it, then publishing will happen, then verification, then released into -updates
<alkisg> xnox: maybe I need to prepare a debdiff or a branch + file a merge request too...
<alkisg> There's an upstream commit link, but not a fresh debdiff afaik
<xnox> alkisg: start with an SRU template. The exact fix/patch is known such that a debdiff is easy to generate.
<alkisg> Thanks, doing so...
<xnox> alkisg: and nobody can/will sponsor a debdiff without SRU template filled.
<alkisg> Sure, I was just asking if someone was working on it and if it was blocked for some reason, so any time I put on writing an SRU template would be in vain... (as were some others in the past)... Thanks, doing the SRU.
<alkisg> Done
<hrw> btw - who (except infinity) has power to take packages from NEW?
<jamespage> alkisg, I'm not working on it but would be happy to sponsor unless xnox wants to
<xnox> hrw: members of ~ubuntu-archive team
<xnox> the AA team =)
<hrw> gracias
<alkisg> jamespage, xnox: I've done the SRU description, is that enough?
<jamespage> alkisg, no - I need a merge proposal or debdiff as well for precise
<jamespage> I need/it needs
<ogra_> hrw, see the wikipage for archive administration, there is a schedule with the daily AA
<hrw> thanks ogra_
<cjwatson> Some of that schedule may even not be mythical
<alkisg> jamespage: thanks, I'll do that in a while as one of my kids is sick today
<melodie> hello
<melodie> I am seeking some information about how Casper operates, and about the packages which come along for it to fulfill it's task. can someone help me ?
<cjwatson> melodie: depends on what exactly you need to know
<cjwatson> it's just a fairly complex initramfs hook
<melodie> hi cjwatson
<melodie> I am searching for what makes it trigger autologin in a Live CD, for a spin I try to do and which don't land on the desktop, but on the lightdm login scree ?
<melodie> s/scree/screen/
<cjwatson> scripts/casper-bottom/15autologin
<melodie> I look, thank you !
<cjwatson> It has explicit support for various DMs so it's possible it needs some tweaking
<melodie> so ?
<melodie> I am going to look in the last version of my spin and will compare with what I find in Lubuntu/Xubuntu in vbox
<melodie> cjwatson, the support for various DE ok, but see: when I stripped off some dev packages, and some ibus packages from Lubuntu, in a customized version, after there was no more autologin, when I put it back, autologin was back. But in the other version I try to do, it only brought the choice for languages at the start of the live, when selecting "try without installing". so I also wonder if there are not some packages which should be depend
<melodie> s to casper, or even to a higher level of core packages ?
<cjwatson> Impossible to tell given only that information.  Trace it, find out exactly what's going wrong, and then think about a solution
<cjwatson> You can use break=casper-bottom as a boot parameter and then start running scripts in /scripts/casper-bottom/ by hand (perhaps under sh -x)
<melodie> that sounds interesting.
<cjwatson> Or boot with 'debug' and you should get a giant log in /run/initramfs/initramfs.debug
<melodie> ok, I look at the casper-bottom scripts first, then I will try the debug method with large debug log.
<melodie> if I have an idea what I will be looking for in there
<cjwatson> Well, just look for where the autologin script starts and trace through its execution against the code
<melodie> ok, I will do that
<melodie> cjwatson, thank you
<melodie> I have one more question
<melodie> I have added a script which I was provided, to add 2 icons/launchers on the desktop ("home" and "trash")on the live, and that works, but I don't know how to make the 2 launchers follow at post-install ? any idea ?
<cjwatson> melodie: see the ubiquity-hooks/ directory in the casper source packag
<cjwatson> e
<melodie> cjwatson, ok I will. thank you very much!
<doko> stgraber, #1123588 looks like an issue in upstart
<xnox> doko: loads of nih_* memory commands allocate new, or realloc memory. and we use malloc attribute all over the place.
<doko> xnox, looks like the real issue is that at least job_new caches the pointer, and expects that the latter assignments will have some effect
<jamespage> Laney, around? I have a question re backports (and Jenkins)
<Laney> yes
<Laney> what's up holmes
<jamespage> Laney, do backports build against backports? I'd like to start doing backports of Jenkins but its pretty much always Jenkins + Associated Jenkins Deps that need updating
<Laney> jamespage: there's a bug there :(
<Laney> https://bugs.launchpad.net/launchpad/+bug/888665
<ubottu> Ubuntu bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Triaged]
<Laney> see the assignee? give him crap about it :-)
<jamespage> Laney, ah - I see this has been rolling on for some time....
<jamespage> Laney, thanks for the backport of mininet yesterday btw....
<Laney> np! hope it's useful
<Quintasan> Laney: Did maliit make it out of NEW?
<Laney> Quintasan: yeah
<Quintasan> Laney: Splendid. Now I can legitmately whine about Plasma Active 3 being not done \o/
<Laney> no whining, just doing
<Laney> :P
<Quintasan> shadeslayer: do plasma active 3
<shadeslayer> I already did
<shadeslayer> didn't I
<Quintasan> Kidding me?
<shadeslayer> it's in raring!
<Quintasan> \o/
<shadeslayer> !info plasma-mobile raring
<Quintasan> Laney: Now I have nothing to do
<ubottu> plasma-mobile (source: plasma-mobile): transitional package for plasma-active. In component universe, is extra. Version 2.0+git2012071701-0ubuntu1 (raring), package size 3 kB, installed size 41 kB
<Laney> sure you do
<shadeslayer> though last I checked it was stuck in proposed
<shadeslayer> no idea why
<Laney> im-config integration
<Laney> build it against qt5 ;-)
<shadeslayer> Quintasan: help us automate Kubuntu QA
<shadeslayer> :P
<Quintasan> Laney: im-config should be there
<Quintasan> Laney: That xinput stuff in debian/ was there to make it working
<Laney> only im-switch is
<Quintasan> oh
<Quintasan> that behaves differently?
<Laney> yeah apparently you patch im-config itself for new IMs
<Laney> seems like a pain to me
<Quintasan> well, it IS a pain
<Quintasan> I'll get to it
<Quintasan> shadeslayer: It involves Python, I don't want it :P
<shadeslayer> haha
<Laney> Qt5 would be a good thing to do though, so we can build the nemo keyboard
<Quintasan> Laney: We do have Qt5 packages somewhere don't we? I remember mikhas kind of implying it should work
<xnox> some qt5 is stuck in -proposed as far as i remember
<Quintasan> Laney: Well, if that's the case I'll get to it after I'm done with input methods in Kubuntu
<Laney> It does build apart from a change to QSKIP: https://gitorious.org/maliit/maliit-framework/merge_requests/239
<Laney> I'm not clear what it does to Qt4 applications though as Qt5 contains the input context stuff itself so maliit-inputcontext-qt4 goes away
<Laney> will need to check if they keep on working / we care if they don't
 * Quintasan really really needs to learn how to code
<RZAFC> can someone help?
<RZAFC> <RZAFC> I can't compile c program in gcc
<psusi> see topic
<xnox> RZAFC: this channel is for development of the ubuntu operating system. for programming help on ubuntu see #ubuntu-app-devel
 * xnox wants a factoroid for this.
<RZAFC> ok
<aPpYe> I am building a custom system based on the mini.iso and am using the various *buntu-desktop packages as a reference.  I am wondering why anacron is listed as a dependency... Do thhe update managers use cron/anacron to schedule daily updates?
<mdeslaur> pitti: could pygtk need to be adjusted for the new glib behaviour described here? http://blogs.gnome.org/desrt/2012/11/05/a-warning-about-glib/
<mdeslaur> pitti: I'm hitting the warning when running meld on raring: bug 1103170
<ubottu> bug 1103170 in meld (Ubuntu) "meld crashed with TypeError in <lambda>(): <HistoryFileEntry object at 0x1e58960 (HistoryFileEntry at 0x1f08540)>: unknown signal name: changed" [Medium,Confirmed] https://launchpad.net/bugs/1103170
<pitti> ugh, pygtk
<mdeslaur> hehe :)
<pitti> mdeslaur: I thought on the last hackfest someone mentioned that they ported it to GI and gtk3
<mdeslaur> pitti: I see some other things also, like dia: bug 1102960
<ubottu> bug 1102960 in dia (Ubuntu) "dia crashes on startup" [Undecided,Confirmed] https://launchpad.net/bugs/1102960
<pitti> mdeslaur: too bad, meld git head is still on pygtk
<mdeslaur> :(
<pitti> mdeslaur: I guess it's possible, yes; no idea how much effort it will be, I'm not familiar with the pygtk code; but for pygobject it was half a day's work
<alexbligh1> If package A depends on package B, and both packages are upgraded through the same apt-get line, is it possible to arrange matters so the ordering of the start/stops of A and B guaraateed? (preferably stop A, stop B, start B, start A)
<xnox> stop A, stop B, start B, start A - usually happens when package B depends on A.
<xnox> alexbligh1: you could in package A postinst to do restart B, before restart A.
<ogra_> and if your upstart jobs are sane :)
<alexbligh1> So if A depends on B, and just B is upgraded, then that will stop and start A (whilst B is upgraded) too?
<Laney> you'll want a versioned depends if you want that configuration order
<alexbligh1> Can't really do that as I'd have to change package A whenever I rebuild B, which is pretty much all the time.
<xnox> alexbligh1: package B can also have a postinst snippet to restart A
<infinity> Sounds to me like B just wants to stop A before itself and start A after itself.  This can easily be confined to B's maintainer scripts.
<xnox> alexbligh1: or job A can have "stop on stopped B" and "start on started B", and then whenever B is stopped/started you will get the behaviour you are describing.
<xnox> alexbligh1: and job B's pre-stop also needs stop A.
<infinity> Or if, indeed, they depend on each other being started/stopped even not during upgrade scenarios, xnox's suggestion about upstart dependencies is sane.
<alexbligh1> The issue I have is this: I have an OCFS2 package and an openiscsi package. Both very similar to ubuntu mainline, but fortunately (or not) we need a couple of local patches or a version that isn't upstream. Neither depends on eachother right now. When I upgrade them, iscsi's prerm calls the init script (not upstart, sadly) to stop it, and it disconnects iscsi, despite OCFS2 using it for heartbeat. OCFS2 then fences the box a
<alexbligh1> nd does a hard restart.
<alexbligh1> Obviously this behaviour is undesirable.
<alexbligh1> I am trying to think of a general fix for this (i.e. one I can get upstream)
<alexbligh1> Currently AFAICT iscsi is unupgradeable in various situations - the above being an obvious one.
<xnox> iscsi prerm call should not stop hard-drives
<alexbligh1> iscsi prerm removes kernel modules!
<xnox> see for example mdadm package which never stops raid arrays on upgrade.
<alexbligh1> it also closes the initiator.
<xnox>  /o\
<xnox> that's like so totally not safe.
<alexbligh1> This seems to be because icssi's initiator works a bit like nbd, ad the fd starts in user space to do the initiation, then gets passed to the kernel.
<alexbligh1> We have tried the obvious fixes (like not doing that) but the world gets confused.
<alexbligh1> I have no idea how iscsi even runs with root on iscsi.
<alexbligh1> xnox, indeed it's not. I think hard reboot without sync (OCFS2 fence action) is about the most exciting consequence.
<xnox> and the packages in ubuntu-archive do this?
<alexbligh1> I filed LP #1123192, but I am not sure how to fix it
<ubottu> Launchpad bug 1123192 in open-iscsi (Ubuntu) "open-iscsi removes modules on stop but should not" [Undecided,New] https://launchpad.net/bugs/1123192
<alexbligh1> Yes they do
<xnox> assigned to myself
<alexbligh1> I only noticed the modprobe when I first filed it. But you can see stop() calls stopalltargets()
<xnox> I will ponder about it, over a cup of green tea =)
<alexbligh1> xnox, much appreciated. We are pulling our hair out a bit. And I haven't got much left.
<infinity> Those two 'modprobe -r' lines should be no-ops if the module is in use (ie: if root is on iscsi), surely?
<alexbligh1> infinity, indeed. Those two cause us (and probably only us) problems because we manipulate /proc/scsi/scsi ourselves. It's the 'stop all targets' thing that is the real problem.
<alexbligh1> stoptargets() {
<alexbligh1>         log_daemon_msg "Disconnecting iSCSI targets"
<alexbligh1>         sync
<alexbligh1>         # only logout if daemon is running, iscsiadm hangs otherwise
<alexbligh1>         if pidofproc -p $PIDFILE $DAEMON > /dev/null; then
<alexbligh1>                 $ADM -m node --logoutall=all > /dev/null
<alexbligh1>         fi
<alexbligh1>         log_end_msg 0
<alexbligh1> }
<alexbligh1> So the line starting $ADM logs out targets other than the targets that were logged in with the conf file.
<alexbligh1> IE everything
<xnox> !pastebin
<ubottu> For posting multi-line texts into the channel, please use http://paste.ubuntu.com | To post !screenshots use http://imagebin.org/?page=add | !pastebinit to paste directly from command line | Make sure you give us the URL for your paste - see also the channel topic.
<alexbligh1> Which it seems to have to do, in order to stop the daemon
<alexbligh1> xnox, yeah sorry - confusion with internal IM
<xnox> alexbligh1: also there is handy pastebinit command line tool which can paste from command line e.g. $ pastebinit mylog.txt or $ run-command | pastebinit
<alexbligh1> xnox, ty. I know. I just forgot different etiquitte on 3 different IM systems.
<alexbligh1> xnox, part of the issue here is that OCFS2 heartbeat does not use an FS mounted device. It just finds what device it's on, then O_DIRECT opens the block device, and carries on writing to it. This seems to die when iscisd gets restarted. At the least it needs a cluster stop and cluster start, but ocfs2 has no obvious way of knowing about iscsid.
<infinity> lool: It's somewhat pointless to have an ifneq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) wrapping your CC setting, if you're setting to $(DEB_HOST_GNU_TYPE)-gcc
<infinity> lool: Since that will work just as well in native builds, you could replace five lines of vague confusion with just one export CC.
<cjwatson> infinity: I prefer the ifneq myself since it avoids confusion if you later have to add in e.g. $(DEB_HOST_GNU_TYPE)-ar
<infinity> cjwatson: Which should also work just as well in either case, no?  But, to each their own.
<cjwatson> No, i686-linux-gnu-ar doesn't exist here
<infinity> Oh, except that that's $(DEB_HOST_GNU_TYPE)-gcc-ar-4.7 here.  What a pleasant path construct.
<cjwatson> And I think -gcc-ar-X.Y is kind of internal - gcc-ar-4.7(1) indicates that that's a wrapper adding --plugin
<infinity> It could be considered a bit of a misfeature/bug if we're not providing the same paths for native builds as we do for cross.
<infinity> GCC does it, surely binutils can too.
<cjwatson> Maybe.  It also kind of depends on whether you prefer uglifying debian/rules or uglifying build logs.
<infinity> cjwatson: Perhaps, yeah.  I like my build logs matching between native and cross, easier to compare.  But I can see the opposite argument.
<infinity> cjwatson: Then again, I maintain something with eight billion character compiler calls, a few more doesn't really make it worse.
 * xnox remembers that at one point calling $(DEB_HOST_GNU_TYPE)-gcc was causing it to start cross-compiling for native arch. glad it's ok to use that directely now. but so far, yeah I have been exporting CC in ifneq as well.
<wookey> infinity: It would make sense if we put in more native fully-qualified names. so that you could just use <arch>-command (at least for binutils and pkg-config stuff).
<wookey> Can we do this generically with some kind of trap? because <BUILD_ARCH>-command should always map to command
<wookey> rather than putting in a thausand symlinks
<wookey> And we should think about things like when we recommend ifeq (BUILD, HOST) blah, vs just making arch explicit always.
<wookey> Packagers need 'suggested standard proactice' for this stuff
 * xnox somehow thinks that cdbs & dh should as if almost export CC when ifneq (BUILD, HOST)
<xnox> that would fix so many packages out of the box.
<wookey> it would. We actually need a proper solution to setting CC that covers llvm as well
<wookey> currently it a mess
<infinity> xnox: But there's no x86_64-linux-gnu-cc, only x86_64-linux-gnu-gcc, so having debhelper cleverly rewrite CC to $(DEB_HOST_ARCH)-$(CC) wouldn't work as expected.
<wookey> with way too much hard-coding for no good reason
<wookey> because that's currently to only way to make it work
<wookey> the
<infinity> If we had x86_64-linux-gnu-cc, that would solve the llvm and cross use-cases together.
<infinity> Since cc and HOST-cc should be alternatives, in that ideal world.
<xnox> infinity: if dh already cleverly passes correct --build & --host when cross-compiling, it can as well figure out & export a cross-CC as well ;-)
<wookey> infinity: right - something along those lines
<infinity> xnox: See above, re: clang.  If it's figuring it out for you, it's also (in the currently world), forcing you to use gcc.
<xnox> ok. i see what you mean now.
<infinity> Not that I mind forcing GCC right now, clang's not really all that useful on more than one and a half arches, but still.  If you're going to do it, do it right.
<wookey> exactly - and more clang use is obviously headed our way, so to ignore it at this stage would be fgoolish
<infinity> It would definitely be great if I could just define CC at the top of my rules (or leave it undefined, which uses the make default of "cc"), and let debhelper DTRT, though.
<infinity> So, CC=gcc-4.6 or CC=clang or CC=cc would all Just Work for native and cross.
<wookey> A log of things have invented cc_for_build to mess that up. We'd probably have to fix those more generically too.
<wookey> lot
<infinity> cc_for_build is BUILD_ARCH, not HOST_ARCH, but yes, that needs dealing with.
<infinity> Still something DH could probably cleverly divine on its own.
<infinity> (Then again, --host/--build with autotools, combined with $(CC) being set to a generic, is MEANT to DTRT out of the box, regardless.  Sadly, this isn't often the case when people fight against autotools because they think they know better)
<wookey> well DH can easily set BUILD, HOST and CC correctly, but it doesn;t know what the package has called BUILD-CC-when-it-differs-from-cc
<infinity> wookey: Know, but we could export/set a few of the more common ones, perhaps.
<wookey> exactly. there is quite a lot of historical bodging to undo to make this actually nice
<wookey> but I'd like to try :-)
 * infinity wonders how his fingers turned "No" into "Know".
<infinity> Cleary a sign that I shouldn't be on IRC on a holiday.
<zyga> bryce: ping
<zyga> bryce: I still have my X crashed under gdb
<zyga> bryce: if you want some data to https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1127497/
<ubottu> Ubuntu bug 1127497 in xserver-xorg-video-intel (Ubuntu) "Xorg crashes when exiting steam" [High,New]
<zyga> bryce: now is the time to tell me
<wookey> If autotools and cmake just defined CC (=HOST-CC) and BUILD-CC then everyone could use that and life would be great.
<slangasek> zyga: fwiw, it's a public holiday in the US today so I don't know that bryce is around
<zyga> wookey: hey, long time no see
<zyga> ah, right, boo
<wookey> hi there < in voice of eddie the shipboard computer>
<melodie> hi
<temporary_> hi, i think i found some files that do not match their md5 or sha checksums on http://releases.ubuntu.com/ does anyone here know what to do about it?
<infinity> temporary_: Example(s)?
<temporary_> http://releases.ubuntu.com/12.04.2/wubi.exe appears to not match it's checksums
<temporary_> they sha1sum i see is 79d2efd6992d969e4790b088b782c0173281639c
<temporary_> but it should be 40b3aac9a6e0464d7a9724f93b28515771e6c43a
<temporary_> the other checksums don't seem to match up either
<infinity> Yeahp, looks broken on the master mirror too.  Lovely.
<infinity> cjwatson: You oopsed the publishing of 12.04.2, wubi.exe got the wrong sums.
<infinity> cjwatson: Not sure if that means we have the wrong wubi.exe in simple/precise, or if updating the sums just didn't DTRT for you.
<temporary_> so i guess it's just a small mistake?
<infinity> temporary_: Yeah, it's one of two potential mistakes, we'll sort it out.  Thanks for the heads-up.
<temporary_> i was wondering if a third party had inserted some malicious code and got all paranoid
<infinity> temporary_: Paranoia's generally the right response to mismatched hashes.
<infinity> temporary_: I can confirm that the wubi.exe on the master mirror is 79d2efd6992d969e4790b088b782c0173281639c however.
<infinity> temporary_: So, no MITM attacks or anything.  Just something wrong on our end with the sum versus the file.
<temporary_> oh cool, that's good to know
<temporary_> i'm sometimes lazy about verifying hashes, so this has been interesting
<cjwatson> infinity: I did oops that at one point but I thought I'd fixed it
<infinity> cjwatson: nusakan disagrees.
<cjwatson> Ah, I ran checksum-directory and it decided all the timestamps are up to date
<cjwatson> Or something
<cjwatson> Possibly my code is too clever for its own good
<infinity> cjwatson: I'd have just resummed the directory, but given that ancestry of the signed wubi.exe binary is a pain to sort out if you're not the person who put it there, I figured I'd let you sort out if the binary or the sums are wrong. :P
<cjwatson> I'll double-check but 99% sure it's the sums
<cjwatson> temporary_: OK, fixed checksum files syncing out now - sorry about that
<cjwatson> Whether it was the code or the operation of it, it was my fault either way ...
<cjwatson> Ah
<cjwatson> The reason it didn't get resummed automatically was that the timestamp of wubi.exe from the build had been preserved
<infinity> cjwatson: The last time I ran into all that clever code, I was unconvinced that caching the sums was buying us anything except pain.
<infinity> I mean, it's a great speed optimisation, but it's optimising for (in theory) the non-common path.
<infinity> And when it breaks, it's confusing. :P
<cjwatson> It's critical path for release publication and makes a giant difference to the length of said critical path
<cjwatson> Originally I had no caching and it was awful
<cjwatson> Also, the code should be much clearer now than the last time you ran into it ...
<infinity> Hrm, yeah, I guess for the daily->release path, it's critical.
<cjwatson> Anyway, I've tweaked the process to recommend publishing wubi.exe first, which would have avoided this in practice
<infinity> cjwatson: Clearer being a matter of perspective, if it's changed languages. ;)
<cjwatson> This was a case where the implementation language made a big difference - it'd outgrown shell
<cjwatson> And I'll fix it to honour ctime as well as mtime, which will permanently avoid this problem
<temporary_> cjwatson, infinity: ah cool, thanks for update and fixing things so quickly
<temporary_> now i don't need to spend all week checking my computer for rootkits :)
<lool> infinity: That's a good point!  I had to think hard now at why it is that we have this in packages, and I guess it is only important for autotools packages as to not trigger cross-compilation mode, but clearly it would be much simpler to always use $triplet-gcc; thanks for the tip
<infinity> ScottK: pkgkde-symbolshelper seems to really hate qscintilla.
<infinity> ScottK: I tried feeding the -2 build logs to it, and the result still doesn't build.  Silly thing.
<infinity> ScottK: Oh, I wonder if this is because I fed the Debian -2 build logs at it and then tried the build on Ubuntu.  Compiler version mismatch fun. :/
 * infinity tries that build on experimental.
<chilicuil> NCommander: ping
<NCommander> chilicuil, pong
<chilicuil> NCommander: sry to bother you, could you come to #ubuntu-mx just a momment?
<ScottK> infinity: Thanks for looking at it.  Agreed.  C++ symbols are a PITA.  They symbolshelper takes them down from impossible to really annoying.
#ubuntu-devel 2013-02-19
<IDWMaster> Is this the appropriate channel for discussing software development on Ubuntu?
<IDWMaster> Not app development, but library development
<xnox> IDWMaster: any most development goes on at #ubuntu-app-devel. Unless it's something major / widespread framework you'd expect the core desktop/os to use a lot.
<xnox> then it's appropriate for this channel.
<xnox> IDWMaster: better just ask ahead =) and we redirect you if this is not the right channel ;-)
<xnox> infinity: at least with wubi, it's signed with microsoft ssl cert and it should be valid.
<IDWMaster> I'm receiving realtime signal 34 for some odd reason:
<IDWMaster> And it's crashing my program
<IDWMaster> It's crashing on pthread_cond_wait
<IDWMaster> I'm not sure how to debug such an error
<IDWMaster> Sometimes it crashes on read() as well within getch
<IDWMaster> Any idea what could be causing this?
<IDWMaster> Crashes with the message: Program received signal SIG34, Real-time event 34.
<IDWMaster> Backtrace from GDB indicates it's crashing in read() from getch
<Chipzz> IDWMaster: NO, this is NOT the approrpiate channel for that
<infinity> IDWMaster: You probably want #ubuntu-app-devel (see /topic)
<IDWMaster> OK
<IDWMaster> Thanks
<infinity> Chipzz: You could be a bit more polite about your redirects.
<Chipzz> (was that too harsh?)
<Chipzz> sorry, my bad
<xnox> Chipzz: NO, it was NOT the approrpiate voice for that redirect.
<xnox> ;-)
<infinity> Oh, hi /topic, I've been patch piloting for how many days now?  Oops.
<infinity> @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:
<Chipzz> xnox: LOL :)
<xnox> How did that read to you?! =))))))
<Chipzz> xnox: but why did you not redirect him right away instead of saying this could be the right channel?
<Chipzz> xnox: IME, if people are asking that question, the answer is almost always "no"
 * xnox thought to teach not to ask a question to ask a question.
<infinity> Every once in a while, an "app devel" question actually ends up being a "why is the compiler buggy?" question, or similar.
<xnox> and hopefully let somebody else redirect. =)))))
<Chipzz> the very fact that they ask (in most cases) means they're uninformed and hence by definition shouldn't be here
<infinity> In his case, definitely not.  He was just writing a poorly-threaded application.
<lifeless> thus having two problems
<xnox> lifeless: =)
<Chipzz> infinity: I would argue that if it involves such a problem, the people encountering those problems tend to more informed, and thus come here for a reason
 * xnox always jumps a little when lifeless just appears and makes a comment once in a blue moon
<infinity> Chipzz: Eh.  Not always.  Tripping over new and exciting bugs isn't limited to the experienced.
<Chipzz> infinity: no it isn't, but in 99% of the cases the fact that people are asking "is this the right channel?" is a very good indicator that it's not ;)
<Chipzz> because like I said, informed people *know* wether or not this is the right channel. and informed people read the topic :)
<scientes> if only
<Chipzz> and I'ld argue that tripping over a compiler error isn't very common. and even if it is, one could argue that the correct avenue is to ask in #gcc or something of the kind first
<Chipzz> infinity: but like I said, the moment I hit enter I realized my sentence could have done with less caps. meh
<xnox> cannot find Python.h would be #ubuntu-app-devel, right until we uploaded multiarched python and /broke the world/ and suddently it's a very #ubuntu-devel on topic.
<Malsasa> Hello, lintian says copyright-file-contains-full-gpl-license, i have read lintian page about it and debian policy manual, but i don't understand. What should I fill in copyright file? I have filled it with copy of GPL text...
<scientes> Malsasa, the gpl header text
<Malsasa> scientes: i don;t know what is that... any example what should I write in the copyright file?
<scientes> this is the short versino: http://paste.debian.net/235443/
<scientes> but you really should include the no warranty clause as well
<scientes> (per the GPL)
<Malsasa> scientes: TKP
<scientes> Malsasa, like this http://paste.debian.net/235444/
<Malsasa> scientes: TKP again
<Malsasa> scientes: thank you... i will try to copypaste them i copyright
 * Malsasa am learning debian packaging
<scientes> make sure to differentiate between GPL and LGPL
<scientes> and the v3 text is differn't to v2 text, even the header
<Malsasa> scientes: oooh, okay
<Malsasa> scientes: okay
<Malsasa> scientes: if i confused, i wanna ask you again here... :)
<scientes> and there is a LGPL-2.1
<Malsasa> scientes: okay
<Malsasa> scientes: so, in the point, i should fill only 1 copyright in that file?
<infinity> Malsasa: You might find http://dep.debian.net/deps/dep5/ informative
<Malsasa> infinity: waaah, thanks!
<scientes> Malsasa, http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
<scientes> that superceeds dep5
<Malsasa> scientes: wow, thank you again. TKP
<infinity> Oh, indeed.  I just always remember it as DEP5, and Google it as such.  Someone should edit DEP5 to put a link to the proper spec at the top.
<Malsasa> infinity: thank you
<Malsasa> infinity: my problem about copytight file solved
<Malsasa> scientes: i copied another deb's copyright , i've checked it befire by lintian
<ScottK> infinity: Any more luck with qscintilla2?
<infinity> ScottK: Oh, I stopped looking right around when I whined at you.
<ScottK> Oh.  Rats.
 * ScottK adds it back to TODO.
<infinity> ScottK: I could rewrite the symbols files by hand and probably do a better job than the helper script, which keeps failing.
<infinity> ScottK: Just had no motivation today.  Day off, and I was still working. :/
<ScottK> Understood.
<vibhav> Should libnotify depend on glib?
<vibhav> Shouldnt*
<vibhav> /usr/include/libnotify/notify.h:25:18: fatal error: glib.h: No such file or directory
<pitti> Good morning
<dholbach> good morning
<brendand> does anyone remember the name of the python module which converts ubuntu release numbers to series names and vice versa?
<pitti> brendand: python-distro-info
<pitti> (or python3-distro-info)
<brendand> pitti, how robust is it?
<brendand> pitti, if i install it on a lucid box will it still be able to tell me 13.04 is raring?
<pitti> brendand: AFAIK it's supposed to be the definitive place for this now, and being used by several developer tools
<brendand> pitti, and so on continuing into the future
<brendand> pitti, cool
<pitti> brendand: I don't know; it did get a few SRUs for newer releases
<pitti> brendand: I don't think lucid's got SRUs to add raring etc.; if you need this always, it's probably better to query launchpad
<brendand> pitti, how would you query launchpad?
<brendand> pitti, i mean not in general (obviously using launchpadlib), but to get the series name from release number
<pitti> brendand: http://paste.ubuntu.com/1680511/
<geser> brendand: you can also use "ubuntu.getSeries(name_or_version='13.04')" to get the right series object instead of needing to iterate the list to find it
<brendand> geser, i was wondering that
<tumbleweed> pitti: we SRU to add new releases
<tumbleweed> otherwise ubuntu-dev-tools breaks (it needs to know development release names, in tools that don't use LP)
<pitti> tumbleweed: oh right, I was looking for a lucid SRU, but distro-info isn't in lucid yet; my bad
<doko> barry, xnox: could you have a look at shiboken again? ftbfs
<xnox> doko: ok. cjohnston was looking at it yesterday.
<doko> ahh, cool
<xnox> (and I do mean cjohnston this time around ;-) )
<doko> stgraber, upstart ping
<brendand> pitti, tumbleweed - it happens that the script i'm writing has to use launchpadlib anyway so i will just use that method
<cjwatson> vibhav: Er, it does.  apt-cache show libnotify-dev | grep glib
<cjwatson> vibhav: I suspect that whatever you're building isn't using the proper compiler flags, as emitted by 'pkg-config --cflags libnotify', so is missing the correct include directory for glib
<cjwatson> infinity: By the way, I fixed the cdimage checksumming bug from last night.  https://bazaar.launchpad.net/~cjwatson/ubuntu-cdimage/mainline/revision/974
<cjwatson> hallyn: FYI, bug 1129571, if you haven't seen it already
<ubottu> bug 1129571 in qemu (Ubuntu) "libreoffice armhf FTBFS" [Undecided,New] https://launchpad.net/bugs/1129571
<ogra_> cjwatson, hmm, do the launchpad buildds actually use qemu ? i thought only PPAs do
<ogra_> would have helped if it mentioned the builder in the bug ... the log seems gone too
<cjwatson> ogra_: Uh, the bug was about a failure on virtualised PPAs
<ogra_> well, nothing in the bug indicates that
<cjwatson> ogra_: My comment does
<cjwatson> ogra_: I have context from a lengthy IRC conversation yesterday
<ogra_> oh
<ogra_> yeah, i thought so
<ogra_> (that there was side conversation)
<cjwatson> Getting Alex to escalate this qemu bug was one of the conditions for working around the problem temporarily by making the PPA devirtualised
<cjwatson> And that state shouldn't go on too long
<ogra_> yeah
<Daviey> cjwatson: Happen to know what version of qemu is in use (& maybe what kernel)?
<cjwatson> Daviey: Whatever's on archive.admin.c.c
<cjwatson> 1.3.0+dfsg-1~exp3ubuntu8~3.IS.12.04 I think
<Daviey> cjwatson: Ok, thanks.
<cjwatson> And for the kernel, check any virtualised PPA armhf build log
<caribou> pitti: looks like I'll have to do my apport MP against a raring branch as I have a change to debian/apport.upstart which is not in trunk
<pitti> caribou: you can do two MPs
<caribou> pitti: ah, didn't think of that
<pitti> caribou: if you do just one, I'll pick it apart myself, i. e. apply the matching bits to trunk
<pitti> caribou: trunk has a sysv init script
<cjwatson> Daviey: (commented to that effect)
<caribou> pitti: fine, then I'll adapt the upstart change to the sysv script in trunk and do a separate one for upstart
<Daviey> cjwatson: thanks
<pitti> caribou: great, thanks!
<caribou> pitti: should I do the upstart one on lp:ubuntu/raring-proposed/apport ?
<pitti> caribou: not -proposed, just raring; please, yes
<caribou> pitti: ok, will do
<zequence> diwic: Any chance you will be updating pulseaudio to a newer upstream version before feature freeze?
<diwic> zequence, 3.1 might happen if it's released, but that would not be any huge change compared to 3.0.
<zequence> diwic: I prepared a patch that adds the channel config thing to the jack module http://paste.ubuntu.com/1681367/
<zequence> Was a little unsure of what would be the best way to forward it
<zequence> I haven't actually tested the patch. I should probably do that :P
<diwic> zequence, it seems to be missing an entry in debian/changelog
<diwic> zequence, hmm, or maybe you just posted the patch file, not the debdiff
<zyga> bryce: hey
<zyga> bryce: it still crashes with xorg-edgers
<mjt> how does ubuntu use qemu for building stuff?
<mjt> it looks like some arches are built in qemu (qemu user mode emulation), right?
<mjt> according to LP:1129571
<zyga> mjt: I don't think we use qemu for building packages
<cjwatson> Virtualised PPAs use qemu for some architectures
<cjwatson> Specifically ARM
<mjt> that's arm :)
<cjwatson> I've answered this twice in this channel in the last hour or so :)
<cjwatson> mjt: Yes, and this bug is about ARM
<zyga> ah ;)
<mjt> oh. i see it in the scrollback
<cjwatson> And yes, it's qemu-user-static + binfmt_misc in roughly the obvious way
<mjt> i was going to say, more or less, that it's better to replace this with qemu-system, if possible... :)
<cjwatson> Unlikely to happen
<cjwatson> I asked Alex to escalate this bug because that clearly ought to be done; I doubt there's any time to entirely rewrite the way virtualised PPAs are handled
<mjt> i see
<mjt> well. if the root cause of this is hat i think it is, it won't be fixed in a few seconds in qemu either.
<cjwatson> Not to mention that that would doubtless have its own set of problems, e.g. with finding a machine to emulate that can use all the memory of the build system
<cjwatson> mjt: Sure, didn't claim it would
<cjwatson> Any real bug tracking system has hard bugs in it
<mjt> this should ebe a good testing ground for qemu and building stuff this way, anyway
<Malsasa> Hello, is Size field necessary in debian/control file? Or just Installed-Size field?
<mjt> both fields are generated automatically
<leighman> how can I get a launchpad recipe to build with debug symbols/a -dbg package?
<xnox> leighman: one should add a -dbg package in the control file and dh_strip should put the symbols there. and one should make sure package is compiled with debug symbols on.
<lantizia> Lo... I just bought a Nexus 4 (mainly because I'm sick of using a dead OS called Maemo on my N900 and I'm finally admitting it's time to use android - but ALSO because of this Ubuntu Mobile beta coming out in 2 days time) but it'll take 2 weeks to get here
<xnox> (they are by default but some crazy packages overwrite it)
<lantizia> I'm wondering... how likely is it I can dual boot Android and Ubuntu Mobile on it?
<lantizia> or maybe load one from the other?
<xnox> lantizia: see #ubuntu-phone channel.
<lantizia> xnox, ah I tried #ubuntu-mobile but it says to go to #ubuntu-devel!
<xnox> lantizia: sorry about the loop.
<xnox> lantizia: #ubuntu-mobile is obsolete channel, latest Phone OS is on #ubuntu-phone.
<ogra_> yeah, #ubuntu-mobile kind of turned towards #ubuntu-arm a few years ago .... and the phone is separate and new
<zequence> diwic: Hi. Got cut off the internet before
<mterry> didrocks, what's the new sdk package name?
<diwic> zequence, yeah, I wrote something about missing debian/changelog but I'll take it back because I realized you just pastebinned the patch, not the full debdiff
<didrocks> mterry: it's not in raring yet
<mterry> didrocks, oh, I misread something
<zequence> diwic: Yes, I was having a bit of trouble with it. I suspect I need to test this first, cause I only realized later I actually didn't know if it'll work. Bit busy now, but will give it another shot this evening. Ping you tomorrow, maybe
<diwic> zequence, won't be around tomorrow, back on Thursday
<zequence> diwic: ok
<diwic> zequence, my workflow for adding a pulseaudio patch would, roughly, be: bzr branch lp:~ubuntu-audio-dev/pulseaudio/ubuntu ; cd ubuntu ; bzr bd-do ; quilt push -a ; quilt import <patch> ; quilt push ; exit ; dch -i ; bzr add debian/patches/* ; bzr commit ; bzr push
<diwic> zequence, and bzr-buildpackage for testing
<leighman> xnox: so it should have debug symbols as is or dh_strip only adds them if there is a -dbg package?
<hrw> leighman: if build is done on buildd then dh_strip will create dbgsym ddeb package
<leighman> hrw: should http://bazaar.launchpad.net/~leighman/evolution-force/evolution-force-packaging/files/head:/debian/ in a recipe produce something that gives a reasonable backtrace or do I explicitely need a -dbg package?
<leighman> hrw: sorry, total package noob
<hrw> leighman: sorry, I lack knowledge of cdbs
<diwic> seb128, hi
<seb128> diwic, hey
<xnox> leighman: if you are building in a ppa, unlike ubuntu archive, there are no automatic dbgsym packages. By default dh_strip either saves detached debug symbols in $pkg-dbg or discards them.
<xnox> leighman: if that's too hard just `export DEB_BUILD_OPTIONS='nostrip'` and that should keep debug symbols attached to the objects.
<leighman> xnox: I'm don't understand half of those words :P
<diwic> seb128, with PA 3.0 finally in Raring I'm experimenting with a patch to g-c-c that will give us better icons, i e a speaker icon instead of the card icon.
<seb128> nice
<diwic> seb128, the problem seems to be that some of the icons, e g the speaker icon, is not present on the system.
<xnox> leighman: in that case seek further help in #ubuntu-packaging channel.
<leighman> xnox: ahha, ok, cool
<diwic> seb128, but e g the HDMI icon and the mic icon works fine
<diwic> seb128, the question is what to do about that?
<seb128> diwic, do we need those icons added to our icon theme or...?
<diwic> seb128, yeah I think they need to be added somewhere, and I'm not an icon expert :-)
<seb128> diwic, the issue is not to have them added, it's to have them "made"
<diwic> seb128, let me look up the icon names
<diwic> seb128, the names are "audio-headphones" and "audio-speakers" I believe
<diwic> seb128, so, in short, do you know how to "get icons made"?
<diwic> seb128, if you think it's worth the effort?
<seb128> diwic, talk to the design team, but I guess it's too low priority that will be work on it any time soon
<seb128> be worked on*
<seb128> diwic, I would stay with what we have
<diwic> seb128, is it possible to use Gnome's icons if they have them?
<diwic> seb128, just copy them in to our theme or so
<diwic> seb128, it looks like audio-speakers is shipped in gnome-icon-theme-full eg
<xnox> diwic: we should auto-fallback correctly to some theme that has them already.
<cjohnston> doko, xnox: fwiw, I continued to get error after error with shiboken... I am at a loss as to why it builds in debian but there are so many issues in ubuntu
<xnox> cause we do have a number of fallbacks.
<xnox> cjohnston: it doesn't build in clean debian sbuild any more.
<cjohnston> oh
 * xnox did say that me and ScottK did poke it extensively (and both having DD and ubuntu hats....)
<stgraber> doko: upstart pong
<cjohnston> xnox: yup.. :-)
<doko> stgraber, see email
<stgraber> doko: ok, will do in a minute
<diwic> xnox, so I do have a working speaker icon if gnome-icon-theme-full is installed - maybe we can move that icon from gnome-icon-theme-full to gnome-icon-theme?
<xnox> how big is the package?
<xnox> (despite raising the limits on normal desktop, fully installed default experience still has every MB to account for on devices that do not have the luxury of TBs of space ;-) )
<cjwatson> Well, diwic was just talking about moving one icon
<diwic> there's still the missing headphones icon though, which is not shipped in our theme, nor in gnome's.
<hallyn> cjwatson: yup, i did notice it yesterday.  glad Peter took a look for a start.
<stgraber> doko: thanks for the analysis. I'd rather have jodh look at the changes and get upstart and libnih fixed though. I think he's out today so hopefully this can be done tomorrow.
<hallyn> cjwatson: all right i'll see what i can do with that today.  maybe i can at least bisect it.
<cjwatson> hallyn: *nod* thanks
<doko> seb128, not sure if you are the right one to track this ... qtcreator will stay in -proposed unless powerpc binaries are removed, or qtjsbackend-opensource-src is built on powerpc
<seb128> didrocks, ^
<seb128> doko, didrocks is rather
<didrocks> doko: either way, I think we can remove the binary for now and let it go to raring
<doko> didrocks, in this case, please identify all the depending binaries
<didrocks> doko: I will, just not right now though, trying to get most of what we are focusing the sprint on, and then, will list that
<didrocks> or maybe Riddell, as he sponsored part of the stack as well
<geryon6> When I'm looking at a Launchpad bug marked âFix Releasedâ (e. g. LP #964897), how do I know which version actually fixes the bug?
<ubottu> Launchpad bug 964897 in unity (Ubuntu) "compiz crashed with SIGSEGV in std::basic_string<...>::basic_string() from unity::launcher::HudLauncherIcon::HudLauncherIcon()::{lambda} from unity::UBusManager::OnCallback" [Critical,Fix released] https://launchpad.net/bugs/964897
<geser> geryon6: look at the changelog from the janitor (comment #7)
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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: stgraber
<geryon6> geser: Unfortunately that's the wrong one, because the bug was reopened and fixed again later.
<geser> geryon6: in such cases it's probably best to ask the person who set the bug to "Fix released" again (perhaps it's tracked in a different bug now)
<geryon6> It would be nice if that information would be shown next to the âfix releasedâ at the top. Am I the only one who is missing this feature?
<geser> geryon6: I guess not, I'm pretty sure other people would like to see LP have versioning support for bugs
<cjwatson> doko,didrocks: qtcreator has only one reverse-dep on powerpc, namely qt-sdk, which is Architecture: all
<cjwatson> If the new qtcreator is urgent then it might be best to leave that intentionally broken for now rather than trying to work around it; qt-sdk itself has no reverse-dependencies
<cjwatson> (As in, remove the powerpc binaries knowing that it will create one extra uninstallable)
<geryon6> geser: I've found LP #163694 which more or less covers this. Seems this issue is known for years already.
<ubottu> Launchpad bug 163694 in Launchpad itself "Fix Committed/Released distinction is confusing and Fix Committed is not functionally different to Confirmed/Triaged/In Progress" [High,Triaged] https://launchpad.net/bugs/163694
<cjwatson> geryon6: Explicit version tracking was in the initial design for Launchpad Bugs, but was later removed/long-term-deferred
<cjwatson> At this point it's very unlikely to be added in (at least) the medium term
<geryon6> cjwatson: That's sad to hear because it confuses me quite often. Sometimes I can see the fixed version number in the comments, but not always. And if it is there, it is not easy to find.
<cjwatson> geryon6: You're preaching to the choir :)
<cjwatson> It was in the initial design for Launchpad Bugs because when we designed it I had recently added the corresponding feature to debbugs
<cjwatson> But, as things worked out, I ended up working on Ubuntu rather than on the bug tracker
<mlankhorst> at least you get to make a lts pointrelease ;)
<geryon6> cjwatson: I see. :)
<xnox> ev: ubiquity-dm crashed but "it's no longer installed" since well it's removed at the end of the oem-config, can we still whitelist that?
<didrocks> cjwatson: I agree, there is no rush for qtcreator to go outside proposed, and we  need to wait for mirv to be back from vacations for pushing the ubuntu sdk as well
<infinity> didrocks: Well, as long as it depends unconditionally on a v8 JS engine, it ain't gonna build on PPC, so we need to either sort out how to turn some bits off for !x86/ARM, or we need to just drop the binaries that fall out of that chain.
<didrocks> infinity: I would go for dropping, but prefer to check with mirv first
<infinity> didrocks: This'll be a bigger deal as this all gets pushed to Debian, where the majority of their arches have no v8 port (while for us, it's only one arch), so someone, somewhere, is going to have to come up with a pleasant solution.
<ev> xnox: I'd much rather see if we can drop that check. Digging through the code, it looks like we only need the package installed to determine its origin.
<ev> (we could compromise and set it to [origin: uninstalled])
<infinity> didrocks: But we can certainly remove the binaries in Ubuntu and push back on the Debian maintainers to find a more elegant solution for arches without V8 ports, and we'll pick up whatever they decide to do.
<didrocks> infinity: urgh, interesting, not sure why they didn't discuss that yet as he ensured me they sync together. Let's see how it goes
<didrocks> infinity: agreed
<infinity> (I really wish V8 had a generic C implementation for non-native ports, but unless you know a V8 engineer at Google who wants to make that happen, it's certainly not a weekend project I intend to get sucked into)
<hallyn> pitti: slangasek: bug 1092715 is causing headaches with automated testing.  so until both it and inotify kernel bugs are definately resolved, i'd like to remove the udev rule hack i had in place (which isn't reliable anyway) in favor of expliclty doing chown/chmod/setfacl in postinst.  just until the other bugs are fixed.
<ubottu> bug 1092715 in qemu-kvm (Ubuntu Raring) "udevadm trigger --action=change not working in quantal and raring" [High,Confirmed] https://launchpad.net/bugs/1092715
<Malsasa> Hello, anybody can help me? http://ubuntuforums.org/showthread.php?p=12518579#post12518579 <<< How to Write Correct copyright File?
<slangasek> hallyn: go for it.  Where are we wrt kernel inotify bugs, though?
<hallyn> slangasek: i'm not sure.  i *thought* it was supposed to be fixed,
<hallyn> but comments by jamespage suggest they may not be
<hallyn> infinity: ^ do you know if all inotify bugs are supposed to be fixed in raring's current kernel?
<infinity> hallyn: I'm not familiar with the bug you were working around, so I can't say.
<hallyn> infinity: oh i'm sorry, i thought you were the one who had pointed it out to me.  nm.
<infinity> hallyn: Well, we've had different inotify bugs.  The one where it was causing leaks and you'd eventually run out of inotify handles has been fixed.
<infinity> hallyn: But if it's just a case of "inotify doesn't work right, and I don't know why", that could be a bug in the application, not the kernel.
<hallyn> app being udev - possible to be sure
<hallyn> lunch (and not me) - biab
<kieppie> well done with the new table, mobile & tv stuff guys. just watched the vid. very nice!
<kieppie> can hardly wait for stable code repo's
<kieppie> 13.04?
 * kieppie can't wait to see the fan/parody vids....
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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:
<zyal> Helo
<zyal> Can anyone help me out here?
<sarnold> zyal: irc tends to work best if you ask a specific question upfront :)
<zyal> Okay =D
<zyal> I'm trying to install the Ubuntu SDK
<zyal> but am stuck at the qtchooser package
<zyal> Running sudo-apt-get -f install yields:
<zyal> Unpacking qtchooser (from .../qtchooser_0.0.1~git20121229.g8f08405-0ubuntu1~precise1~test5_i386.deb) ...
<cjwatson> Where's the web page with the instructions you're starting from?
<zyal> dpkg: error processing /var/cache/apt/archives/qtchooser_0.0.1~git20121229.g8f08405-0ubuntu1~precise1~test5_i386.deb (--unpack):
<zyal>  trying to overwrite '/usr/bin/xmlpatterns', which is also in package qt4-dev-tools 4:4.8.1-0ubuntu4.4
<zyal> No apport report written because MaxReports is reached already
<zyal>                                                               Processing triggers for man-db ...
<zyal> Errors were encountered while processing:
<zyal>  /var/cache/apt/archives/qtchooser_0.0.1~git20121229.g8f08405-0ubuntu1~precise1~test5_i386.deb
<zyal> E: Sub-process /usr/bin/dpkg returned an error code (1)
<cjwatson> Yeah, whatever way you slice it that's a bug *somewhere*
<zyal> http://developer.ubuntu.com/get-started/gomobile/
 * cjwatson looks
<zyal> I followded it to the tee
<cjwatson> zyal: What Ubuntu version are you running?
<cjwatson> I assume 12.04, from that log
<zyal> Yes
<zyal> Do I have to 12.10 >.<
<cjwatson> No, just one minute while I set up a reproduction environment
<zyal> Okay
<cjwatson> zyal: Did you already have qt4-dev-tools installed before starting this?
<cjwatson> Or was it one of the new packages installed?
<zyal> I think I've installed qt4-dev-tools before
<zyal> For what reason I dont know why
<GuidoPallemans> ph
<GuidoPallemans> oh
<cjwatson> I ask because it's only a recommendation here, so if you didn't have it installed already then that'd be a workaround
<zyal> okay
<cjwatson> But I want to check this out anyway - just waiting for it all to download
<zyal> alright
<cjwatson> Hmm, doesn't look like qt4-x11 has had qtchooser support added to it in precise.  https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-proper/+packages shows it for raring (though it's in the primary archive there anyway) and quantal, but not precise
<zyal> aw shicks
<zyal> Does this mean no SDK for me in precise?
<cjwatson> So my reading of this is that Timo needs to fix that
<cjwatson> I suspect you can make it work for now by 'sudo apt-get remove qt4-dev-tools; sudo apt-get install ubuntu-sdk notepad-qml qt4-dev-tools-'
<cjwatson> But I haven't got far enough through this download to be able to test that
<zyal> that's the thing
<cjwatson> If you wait 10-15 minutes or so I should be able to verify
<zyal> my installer is locked up
<cjwatson> Oh, that's just apt, that's recoverable
<zyal> How should I?
<cjwatson> sudo dpkg --configure -a
<cjwatson> sudo apt-get -f install
<cjwatson> Then if it's still busted, paste the error into paste.ubuntu.com and post the URL you get
<zyal> http://pastebin.com/cQYUi9BU
<cjwatson> zyal: sudo dpkg --remove qt4-dev-tools; then repeat the two commands above
<zyal> cjwatson: Same Errors
<cjwatson> zyal: Can't possibly be exactly the same; paste again
<zyal> Oops your right
<zyal> sec
<cjwatson> (If nothing else, I would expect an error from the first command if it didn't resolve the second/third)
<zyal> http://pastebin.com/h1hYQYUL
<cjwatson> zyal: Meh, you're going to have to remove a fairly large chunk of Qt4 to make this possible as it stands - is that something that will cause a problem?  (e.g. if you were running Kubuntu or Unity-2D it would not be a good plan)
<zyal> cjwatson: No sir, I use DWM anyway
<zyal> No unity
<cjwatson> You can, I believe, do this with "sudo dpkg --remove libqt4-dev libqt4-opengl-dev libqtwebkit-dev qdbus qt4-qmlviewer" and then those same two commands again
<zyal> Somewhat related: I dont need unity to develop though, right?
<cjwatson> Don't ask me, I'm a foundations developer :)
<cjwatson> But I'll mail Timo and remind him that qt4-x11 is busted
<zyal> Ah okay
<zyal> So how do i atleast get the term working again?
<cjwatson> Have you tried that command above yet?
<zyal> Oops slipped my eyes
<zyal> Success?
<zyal> Yes
<zyal> no error this time
<cjwatson> GOod
<zyal> Does this mean ubuntu-sdk is installed?
<cjwatson> If the last command's output ended with "Setting up ubuntu-sdk (0.1~bzr20130204-0ubuntu1~precise1~test1) ...", you should be good
<cjwatson> You can always repeat "sudo apt-get install ubuntu-sdk notepad-qml" to make sure
<cjwatson> I've sent that mail, so hopefully this can get sorted out properly rather than by this kind of hack
<cjwatson> Thanks for reporting
<zyal> Thanks alot cj..
<zyal> should I report this officially.. I have no experience
<cjwatson> It's in a PPA so that's a bit awkward
<cjwatson> I've already mailed the person I believe to be the responsible developer, which should be enough here
<zyal> Alright sweet
<zyal> What do you do as a foundations dev?
<cjwatson> bottom layer of userspace; personally, boot loaders, installers, package archive infrastructure
<zyal> ooh sounds like hard work
<infinity> zyal: As a general rule, if it's pretty, we don't touch it ("we" being "foundations developers")
<zyal> LOL
<infinity> The installer being the only possible exception to that rule.
<zyal> Ive always wondered do you guys ever get to talk to Shuttleworth?
<cjwatson> It wasn't desperately pretty for a fair while ...
<zyal> other than the summits
<zyal> or do you just work under a branch
<cjwatson> Now and again; he's a busy man
<infinity> Most of us probably talk to Mark a lot less than we did 8 years ago.
<infinity> See above, re: busy man.  Plus, the company is much larger.
<zyal> I can imagine
<infinity> I haven't had strange 5am phone calls in a long time.
<zyal> But you guys have met him in the early years tho
<cjwatson> It's not that we're not allowed to talk to him, it's just that if he tried to talk to several hundred employees and goodness knows how many community members directly he'd never sleep at all
<infinity> Yeah.  When we were all much younger and slightly more silly.
<zyal> Ah
<zyal> As a FOSS dev.. do you guys have any alternative $$ making gigs on the side? Did your FOSS credit help you guys in your fields?
 * cjwatson digs
<cjwatson> 2026     Feb 18 Mark Shuttlewor (  19) New Debian-related project
<cjwatson> :)
<zyal> Just curious on the whole scene actually
<zyal> ;D
<sarnold> cjwatson: cool :)
<cjwatson> Eh, Canonical employs me, I don't have time for two jobs
<infinity> cjwatson: I like Scott's version better than the real thing.
<jcastro> we're coming up on 10 years of Ubuntu!
<cjwatson> But certainly the fact that I'd been doing free software for several years beforehand got me this job
<infinity> jcastro: Getting there, yeah.
<cjwatson> Hey, yeah, that mail was 9 years yesterday
<infinity> cjwatson: Hrm.  Tempted to wiggle the 12.04.4 release date to 2014-02-18, and make a 10th anniversary thing out of it.
<cjwatson> It's only a tenth anniversary in a weird internal sense
<infinity> Thankfully, I hate editing wikis, and I'll forget in a year.
<cjwatson> Besides, pretty sure Scott was already on the payroll (such as it was) by then
<infinity> cjwatson: True, the 10th anniversary of warty is probably more interesting.
<cjwatson> I seem to remember he said he had to go to considerable effort to keep his mouth shut in MÃ¡laga
<cjwatson> (er, Open Source World Conference, held there around that time; at least he and I and Tollef were there)
<jcastro> infinity: we need to find something clever for no-name-yet.com too
<infinity> jcastro: You'd have to ask Matt nicely, it's his, not the company's.
<infinity> jcastro: Or, so says the all knowing registrar.
<jcastro> I'm sure we can find some kind of scheme
<lifeless> cjwatson: I don't think scott was on the payroll on the 18th
<lifeless> cjwatson: would have to dig up evolution to check though :)
<lifeless> warty release as 10th anniversary makes lots of sense to me
<cjwatson> lifeless: Maybe not as such but he certainly knew about the project then
<lifeless> cjwatson: certainly
<lifeless> cjwatson: you can pick jan 16th or thereabouts if you want 'when folk knew' :)
#ubuntu-devel 2013-02-20
<samburg> hey guys where is the caoacal channel im suppose to talk to oreneeshy
<Malsasa> Hello, http://ubuntuforums.org/showthread.php?p=12518579#post12518579 <<< How to Write Correct copyright File?
<alkisg> Hi, we're trying to create and test a debdiff to SRU lp bug #1016895
<ubottu> Launchpad bug 1016895 in samba (Ubuntu Precise) "smbd crashed with SIGABRT in dump_core()/setgroups being passed a -1 group is causing crashes." [High,Triaged] https://launchpad.net/bugs/1016895
<alkisg> But the build fails, even if we don't modify the source tree at all (!), with "tar: samba-3.6.3/.bzrignore: Cannot stat: No such file or directory ==> /usr/bin/pristine-tar: command failed ==> bzr: ERROR: bzrlib.errors.BzrCommandError: Generating tar from delta failed": https://launchpadlibrarian.net/131626440/buildlog.txt.gz
<alkisg> Any help there?
<infinity> alkisg: Are you doing this with bzr branches, or just against the source package from the archive?
<alkisg> infinity: we started with bzr branch lp:ubuntu/precise/samba, then pushed in our own copy of the branch
<infinity> Yeah, I figured.
<alkisg> The build succeeds locally...
<alkisg> Are we using a wrong method?
<infinity> Well, I'm not sure why you'd be using a recipe build for an SRU.
<alkisg> Just as an easy way to test the resulting package
<infinity> Anyhow, is this the only patch required: http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=c4fd9ff890e2640ef90b4d7129621e3fe800a61e
<infinity> ?
<alkisg> Yes
<infinity> Right, so there's already a pending SRU in the queue.  I'll replace it with one that also includes that patch.
<alkisg> Thank you so much :)
 * alkisg moves on to the vbox SRU, lp bug #1081307 ...
<ubottu> Launchpad bug 1081307 in virtualbox (Ubuntu Quantal) "I'm upgrading the 12.04.1 to quantal 3.5 kernel - virtualbox-dkms 4.1.12-dfsg-2ubuntu0.2: virtualbox kernel module failed to build" [Undecided,Confirmed] https://launchpad.net/bugs/1081307
<alkisg> infinity: where are you checking for pending SRUs? They're not listed in http://people.canonical.com/~ubuntu-archive/pending-sru.html ...
<infinity> alkisg: https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<alkisg> Thanks :)
<pitti> Good morning
<ikepanhc> @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: ikepanhc
<pitti> tjaalton: wrt. libxi, if you don't have time would you mind if I change the .pc file?
<tjaalton> pitti: oh i thought you did already? i can fix it later today
<pitti> tjaalton: ah, I thought you said you wanted to; sorry for the misunderstanding
<pitti> tjaalton: I was just asking to avoid breaking a packaging git, etc.
<tjaalton> right, that's generally not a big issue, we've applied diffs there after uploads :)
<pitti> tjaalton: ok, I'll do that then; thanks!
<tjaalton> and appreciate the heads up
<tjaalton> cool
<dholbach> good morning
<pitti> tjaalton: sorry for delay, was still busy with g-i/pygi; how does http://paste.ubuntu.com/1688884/ look?
<pitti> tjaalton: I folded it into the existing patch so that we don't forget to remove it when we remove the reversion
<pitti> tjaalton: I'll upload that; it does what we need, and is minimally intrusive IMHO
<tjaalton> pitti: yes, looks fine, thanks
<seb128> hum
<seb128> who rejected the samba SRU from precise-proposed?
<tjaalton> pitti: i actually have the 'clean' version staged in a ppa, so merging just the changelog part to git :)
<seb128> slangasek, infinity: any idea who rejected samba from precise's SRU queue?
 * seb128 grrrrs at SRU team rejecting items without giving any info to the uploader or on the bugs listed in the changelog
<ikepanhc> @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:
<cjwatson> seb128: 05:11 <infinity> Right, so there's already a pending SRU in the queue.  I'll replace it with one that also includes that patch.
<cjwatson> (samba)
<cjwatson> alkisg wanted a fix for bug 1016895 added
<ubottu> bug 1016895 in samba (Ubuntu Precise) "smbd crashed with SIGABRT in dump_core()/setgroups being passed a -1 group is causing crashes." [High,In progress] https://launchpad.net/bugs/1016895
 * alkisg has a branch with it and can test any SRU packages available, but his recipe won't build
<seb128> cjwatson, thanks, I joined IRC after that I guess
<alkisg> Also debfx says there's a pending SRU for vbox not working at all with the lts-quantal kernel (LP bug #1081307), but I couldn't find it...
<ubottu> Launchpad bug 1081307 in virtualbox (Ubuntu Quantal) "I'm upgrading the 12.04.1 to quantal 3.5 kernel - virtualbox-dkms 4.1.12-dfsg-2ubuntu0.2: virtualbox kernel module failed to build" [Undecided,Confirmed] https://launchpad.net/bugs/1081307
<cjwatson> yay new devscripts
 * cjwatson will be able to use dch -r faster now :)
<doko> ?
<cjwatson> oh, fix for subsecond granularity because I often went  dch -r / immediately save+exit editor / oh damn dch -r didn't actually update the changelog
<tumbleweed> you don't use dch -r "" ?
<cjwatson> I think I like to let my hindbrain have a brief look at the changelog or something
 * cjwatson is a creature of habit when it comes to uploading stuff
<tumbleweed> not a bad idea :)
<pitti> heh, same here; I trained my fingers to do i <space> <esc> u :x
 * tumbleweed tries to remember to read the .changes file before uploading
<cjwatson> I do that too
<cjwatson> pitti: What do you think of http://paste.ubuntu.com/1689896/  ?
<cjwatson> It's working well in my local tests
<xnox> tumbleweed: /me did dch -r -m '' didn't know i can drop the -m part ;-)
<tumbleweed> xnox: yeah, you want -m for some when sponsoring
<pitti> cjwatson: sorry, was busy; looking
<pitti> cjwatson: the patch looks good to me; I'm just curious how that affects the installation process
 * pitti reads the bug
<pitti> oh, of course *slaps head*
<pitti> cjwatson: thanks for the fix!
<cjwatson> It's a slightly baroque bug and perhaps the installer could do things in some other order to avoid it, but since it seems like a bug to me I thought I'd rather just fix it
<cjwatson> Thanks, I'll get that uploaded now
<Riddell> ogra_: ping :)
<ogra_> Riddell, same thing as in -release ?
<Riddell> yep
<doko> ScottK, https://launchpad.net/ubuntu/+source/qscintilla2/2.7-2 still symbol issues, did sync too early
<doko> pitti, seb128: vala expertise needed: https://launchpadlibrarian.net/130057165/buildlog_ubuntu-raring-amd64.rygel_0.16.3-2_FAILEDTOBUILD.txt.gz
<doko> Riddell, could kubuntu have a look at https://launchpad.net/ubuntu/+source/hupnp/1.0.0-1 ?
<Riddell> doko:  ack
<doko> xnox, libavg ftbfs in -proposed, could you have a look?
<seb128> doko, pitti: fixing it
<xnox> doko: yeah. I've tried fixing it generally, but that failed in debian due to python2.6. I'll just upload the fix directly into ubuntu.
<xnox> doko: can you upscore https://launchpad.net/~ubuntu-nexus7/+archive/ubuntu-nexus7-installer/+build/4314721 and https://launchpad.net/~ubuntu-nexus7/+archive/ubuntu-nexus7-installer/+build/4314723
<xnox> as one needs those to flash nexus7 if it got upgraded to 4.2.2 and is blocking many people.
<xnox> anybody else with magical upscore powers? =)
<ogra_> NCommander, ^^^
<seb128> hum
<cjwatson> xnox: they seem to be built/building now
<seb128> re rygel build issue, in fact robert_ancell synced the gupnp from debian experimental
<xnox> \o/
<seb128> it would probably be easier to sync gupnp-av and rygel from there as well, the new version uses vala 0.18 and gst1
<seb128> Laney, ^ do you think you could have a look to that? just see if we those versions would fix the rygel build (would be another stuff ported to the new gstreamer as well)
<Laney> are they in sync aleady?
<Laney> (yes)
<xnox> Also for precise please: https://launchpad.net/~ubuntu-nexus7/+archive/ubuntu-nexus7-installer/+build/4314749 https://launchpad.net/~ubuntu-nexus7/+archive/ubuntu-nexus7-installer/+build/4314751
<xnox> =) please rescore (=
<cjwatson> xnox: done
<xnox> cjwatson: merci.
<hrw> hello
<hrw> cjwatson: wiki lists you are archive admin on duty. can we discuss moving chromebook packages out of NEW?
<ogra_> hrw, and then implement community images, with the tablet and phone images you can then fully go ubuntu on google HW :)
<hrw> ogra_: both of them require touchscreen ;D
<cjwatson> Yeah, you know what, that on duty thing has been fictional for me for a long time; I distribute throughout the week
<ogra_> hrw, i mean the phone image on the phone. tablet image on your nexus tablet and desktop on the chromebook indeed
<ogra_> :)
 * cjwatson removes himself from that list
<hrw> ogra_: I do not have nexus tablet
<hrw> cjwatson: ok
<cjwatson> hrw: I'll look at your packages shortly, though
<ogra_> hrw, you still have time to get one before thu.
<hrw> ogra_: and after using omap4430 powered archos I prefer to not buy tablet - it just do not fit to my use
<ogra_> ;)
<hrw> ogra_: my daughter is much better tablet user then me :) 5y old
<hrw> cjwatson: thanks
<hrw> ogra_: it was fun when on one event she used ipad for first time and after few minutes shown other kids how to get to games
<ogra_> heh
<ogra_> i guess thats because you take her to technics museums all the time ;)
<hrw> ogra_: so far we visited only the one in Szczecin. Next one will be Berlin in March
<herton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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: herton
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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: herton, mdeslaur
<ScottK> doko: qscintilla2 is on my TODO list, hopefully I can take another shot at it today.
<Reezz> Hey guys, when I'm trying to run make on a package it doesn't automagically find my includes in /usr/include and /usr/local/include (they are there, but in subfolders..) Any ideas?
<cjwatson> No single general answer.  Sometimes it is correct to refer to headers using the full relative path from /usr/include (e.g. <sys/types.h>).  Sometimes you are supposed to refer to them by a truncated version of that path (e.g. <glib.h>) and use an -I option to the compiler to add extra header search directories.  In the latter case you are often also supposed to use pkg-config to get the necessary compiler options.  ...
<cjwatson> ... Consult the documentation for the header files you're using for advice.
<Reezz> cjwatson: Thanks :)
<mdeslaur> kirkland, tyhicks: any reason why ecryptfs-utils (102-0ubuntu1) reverted all the changes from 1.0.1-0ubuntu2 and 1.0.1-0ubuntu3?
<mdeslaur> kirkland, tyhicks: oh actually, it's just part of the changes that got reverted, and the changelog
<lool> smoser: Thanks for checking the updated euca2ools, I had missed the "please verify this package" update on the bug
<smoser> lool, no worries. i was reminded of it when testing https://bugs.launchpad.net/ubuntu/precise/+source/cloud-init/+bug/1077020 in precise.
<ubottu> Ubuntu bug 1077020 in cloud-init (Ubuntu Precise) "cloud-init ca-certs leaves a blank line in /etc/ca-certificates.conf" [High,Fix committed]
<smoser> lool, i think you opened (and fixed) one other bug around that time related to the images... do you recall that ?
<smoser> i just have a vague memory of it and wasn't able to find anything searching though
<Denommus> hi
<Denommus> I'm trying to use the Ubuntu SDK, but it gives me the error 'module "QmlProject" is not installed'
<Denommus> what does this mean?
<geser> Denommus: I guess you mean for the Ubuntu phone? if yes, then #ubuntu-phone is probably the right channel
<Denommus> geser: thanks
<herton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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: mdeslaur
<smoser> lool, ^
<stgraber> doko: ldm should be fixed now (just uploaded). The problem was the introduction of a versioned dependency against ldm-themes which we don't have in main but have packages in main provide. I simply reverted that change which should put us back to where we were when we released quantal.
<doko> stgraber, thanks
<lool> smoser: oh sorry, I missed the question; checking
<lool> smoser: LP #1098096 perhaps?
<ubottu> Launchpad bug 1098096 in euca2ools (Ubuntu) "euca-describe-group(s) broken/missing" [High,Fix released] https://launchpad.net/bugs/1098096
<lool> smoser: ended up not affecting quantal though
<lool> smoser: also filed LP #1117184, but that's wishlist
<ubottu> Launchpad bug 1117184 in Ubuntu "cloud-images.u.c still uses "uec-images" as rsync module name" [Undecided,New] https://launchpad.net/bugs/1117184
<smoser> lool, right. thanks.
<smoser> lool, are you doing automated things with cloud-images ?
<lool> smoser: I'm mirroring them
<lool> smoser: but I'm likely to stop doing that soon; a) this dates back from me using them to deploy local vms b) I actually have a real bandwidth here now and don't need to worry about caching things overnight anymore  ;-)
<smoser> lool, ok. we're working on data and tools to allow you to more easily mirror (without rsync), which would also hopefully allow you to mirror just disk1.img files or amd64 files ... more easily.
<lool> smoser: Ack; the json data model thing would be nice
<lool> smoser: BTW you might want to wrap it as a jsonp rather than json; I guess thats usual practice though
<cjwatson> hrw: chromium-mali-opengles: I can't see how the Google Terms of Service are necessarily relevant as a licence; but, if they are, they do not appear to grant redistribution permission to us or our mirrors (and in any case the copyright holder is ARM, not Google, so I'd expect to see a licence from ARM).  The only relevant section I can see is "About Software in our Services", which says "You may not copy, modify, ...
<cjwatson> ... distribute, sell, or lease any part of our Services or included software, [...] unless laws prohibit those restrictions or you have our written permission".  Am I missing something?
 * doko watches Laney preparing for rygel from experimental ...
<Laney> https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/tumblr_mch9dvLnHL1qiv6pvo1_400.jpg secure beneath doko's watchful eyes
<Laney> ;-)
<slangasek> seb128: samba reject> no, no idea
<seb128> slangasek, cjwatson helped me thanks, seems like infinity rejected it to reupload with another fix included
<hallyn> slangasek: hey, on qemu-linaro you used to pass CFLAGS += -fno-var-tracking for arm, to save memory space.  Was that just memory when building it, or memory when running it?
<slangasek> hallyn: that was when building it
<hallyn> slangasek: drat, thanks :)
<TheMuso> c
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and 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:
<hrw> cjwatson: ok, will check it. please reject
<ion> cjwatson: Re: <https://bugs.launchpad.net/ubuntu/+source/apt/+bug/923876>, apt should probably run /etc/kernel/postinst.d/apt-auto-removal in its postinst.
<ubottu> Ubuntu bug 923876 in aptitude (Ubuntu Quantal) "FR: Limit and clean-up kernel images and headers automatically in LTS" [Undecided,Confirmed]
<hrw> cjwatson: thanks for accepting kernel
<cjwatson> hrw: rejected, thanks for checking
<cjwatson> ion: â infinity since he uploaded it
<cjwatson> er, IIRC.  but is a good victim for this anyway :)
<ion> heh
<xnox> Laney: so I copy across wifi settings as seen in /etc/NetworkManager/system*/$ssid into the nexus7 image under /etc/Network/Manger/system*/last_active_connection (note static name)
<xnox> and the network manager does not auto-connect for me =(
<xnox> well it tries but fails.
<Laney> meet cyphermox
<xnox> Is there any other magic I need to do to setup network-manager unattended?
 * xnox doesn't want to use nmcli, cause copying the full cfg seems like it will manage to setup things more correct.
<xnox> cyphermox: ^ =) please help me ;-)
<cyphermox> xnox: do you also have the $ssid file?
<cyphermox> if both have the same UUID it will fail
<cyphermox> look at /var/log/syslog, NM complains there if it can't make sense of the connection files
<xnox> cool. i'll check that on next redeploy.
<xnox> I'll ping you when I have more info ;-)
<xnox> doko: libavg fixed and uploaded into debian, can be synced when possible.
<davmor2> Hey guys I've just done a fresh 12.04.2 i386 install in virtualbox and it is constantly in low graphics mode and won't reconfigure is there anything I can do.  This is the version of virtualbox download direct from oracle as our version is so out of date and raring is the host
<superm1> davmor2: https://bugs.launchpad.net/ubuntu/+source/libpciaccess/+bug/1122072 perhaps?
<ubottu> Ubuntu bug 1122072 in libpciaccess (Ubuntu Precise) "[Precise on VirtualBox] "Fatal server error: no screen found" in Xorg.0.log" [High,Fix released]
<xnox> davmor2: this not really a question about developing ubuntu core operating system. It is known that guest additions do not correctly build with the backported quantal stack that is in the 12.04.2 images. The bug is on launchpad, assigned and is of high priority and will be fixed soon.
<davmor2> xnox: oops sorry didn't realise it was a meeting
<xnox> davmor2: support for stable release is available in #ubuntu channel. Or you can discuss bugs on #ubuntu-bugs as well.
 * cjwatson suspects davmor2 knows about #ubuntu-bugs ;-)
<davmor2> cjwatson: I might
<xnox> davmor2: =) as a work around you can install the stable x-stack and or install using 12.04.1 image and upgrade ;-)
<xnox> (upgrading does not move one to the upgraded stack)
<davmor2> xnox: I'll try the upgraded stack and see if that fixes the issue
<xnox> davmor2: the quantal stack is default on 12.04.2 iso and it is broken with virtualbox. using original kernel/X stack works (e.g. via install using 12.04.1 images and upgrading)
<Sarvatt> davmor2: https://bugs.launchpad.net/ubuntu/+source/libpciaccess/+bug/1124660 thanks for reminding me that needs to be SRUed :)
<ubottu> Ubuntu bug 1124660 in libpciaccess (Ubuntu Precise) "Precise 20120213 i386 live session fails in virtualbox" [High,Triaged]
<davmor2> xnox, Sarvatt: thanks guys I'm just installing 64bit too which doesn't seem effected which is even more weird :)
<davmor2> Sarvatt: when the fix lands if you give me  a ping I'm more than happy to update and see if it fixes it :)
<tyhicks> mdeslaur: The python multiarch changes in 101-0ubuntu3 were dropped in 102-0ubuntu1 because I had already fixed the python multiarch issues in a slightly different way upstream before 101-0ubuntu3 was uploaded
<mdeslaur> tyhicks: yeah, I figured that out...one of the other changes was missing in the debian/rules
<mdeslaur> tyhicks: I asked him to submit a merge proposal upstream for the missing bit
<tyhicks> mdeslaur: There may have just been a miscomunication between kirkland and I about what he could drop when he uploaded 102-0ubuntu1
<mdeslaur> tyhicks: https://code.launchpad.net/~nobuto/ecryptfs/fix-empty-window/+merge/149634
<tyhicks> mdeslaur: Thanks, I'll take a look
<mdeslaur> tyhicks: the fact that the debian/changelogs entries got removed made me though the changes got dropped, but it was just one part of one of the changes wasn't merged upstream
<tyhicks> kirkland: ^ I wonder if your release scripts dropped the changelog entries from ubuntu2 and ubuntu3?
<BenC> Is it a known issue that whoopsie is stuck in a crash loop on raring right now?
<BenC> At least on my system
<BenC> [ 1294.259124] init: whoopsie main process (12696) killed by SEGV signal
<BenC> [ 1294.265696] init: whoopsie main process ended, respawning
<ev> no, it is not
<slangasek> BenC: there've been a few issues with whoopsie this week, seemingly related to NM api calls; I haven't heard that issue reported
<slangasek> but now that I look, I see that whoopsie is not running on my system
<ev> BenC: I don't suppose you could get me a stacktrace
<BenC> ev: rebuilding with debug syms so I can get a better trace
<ev> BenC: thanks!
<BenC> ** (./test_identifier:20444): CRITICAL **: whoopsie_identifier_sha512: assertion `source' failed
<BenC> Getting that during buildâ¦maybe related
<slangasek> yeah, I've got the same issue here, and a crash file for it
<BenC> ev: http://paste.ubuntu.com/1691526/
<BenC> ev: I'm assuming active_connections == NULL
<BenC> no check for that before the for loop
<ev> yup
<ev> bingo
<ev> ugh
<ev> BenC: http://paste.ubuntu.com/1691559/ - that look reasonable to you?
<ev> xnox: ^ can you give me a branch for your whoopsie changes so I don't blow them away with the next upload
<BenC> ev: I added "network_available = FALSE;" before the return
<BenC> Seemed to make sense
<ev> good call
<slangasek> ev: do you want a bug report to link to it too?
<ev> sure
<slangasek> I can send this crash report up
<BenC> ev: Give me a sec and I'll test it...
<ev> http://paste.ubuntu.com/1691570/
<slangasek> bug #1130823
<ubottu> Error: Launchpad bug 1130823 could not be found
<BenC> ev: I'd also like to fix this test case failure
<ev> happy to take branches
<xnox> ev: nexus7 & ubiquity-dm almost never have active connection on boot.
<slangasek> xnox: does that mean your change can be dropped in favor of the segfault fix?
<xnox> ev: i'd rather you blow my changes away and see if this is a fix for the world, the universe and everything.
<ev> :)
<ev> h'okay
<xnox> ev: or i can test it on the nexus quickly.....
<slangasek> bug #1130823
<ubottu> bug 1130823 in whoopsie (Ubuntu) "whoopsie crashed with SIGSEGV in g_closure_invoke()" [Undecided,New] https://launchpad.net/bugs/1130823
<slangasek> better
<Laney> I can do that fairly easily, but I don't think that it's the same thing
<BenC> ev: That does indeed fix the segv
<BenC> ev: I have a fix for the test case but it only appears to affect when the tests are run as root, so not that important to the buildd's
<ev> still happy to take it
<BenC> two secs...
<Laney> xnox: no fix here
<xnox> ev ^ giving you my branch in a sec.
 * Laney finds a file called ':wq'
<mlankhorst> :o
<BenC> ev: http://paste.ubuntu.com/1691633/
<BenC> ev: feel free to fix up my tab/space mis-tabbing
<xnox> ev: lp:~xnox/whoopsie/no-ubiquity
<ev> thanks guys
<BenC> ev: Thank you
<ev> uploaded
 * ev home
<hallyn> jjohansen: mdeslaur: is apparmor policy stacking off the table for r?
<mdeslaur> hallyn: jjohansen is working on it. I've postponed a few things though, like getting it upstream.
<mdeslaur> jjohansen: what's the status?
<hallyn> mdeslaur: ok - cool, don't mean to distract, just saw the blueprint update and wasn't sure.  thanks :)
<mdeslaur> hallyn: had to pick some $RANDOM ones to postpone so the burndown chart looks good :P
<hallyn> :)
<jjohansen> hallyn: I'm and making some revisions and fixing some bugs, there should be a new version to play with at the eow/start of next
<hallyn> jjohansen: awesome, thanks
<smoser> anyone know if there is a way to make schroot not say:
<smoser>  Sessions still open, not unmounting
<smoser> schroot --quiet --run-session --chroot "$schroot" -- some-command
<smoser> annoyingly prints that
<barry> smoser: that one always bugs me too, but no i don't know how to shut it up ;)
<hallyn> mdeslaur: since i seem to be subject to stupid mistakes, does http://paste.ubuntu.com/1693657/ look good for actually fixing the bug with admin users placed into group libvirtd?
<hallyn> zul: bug 1129107, i'm tempted to just push a fix having debian/rules touch /usr/bin/collie
<ubottu> bug 1129107 in libvirt (Ubuntu) "Backend Sheepdog is not compiled" [Low,New] https://launchpad.net/bugs/1129107
<hallyn> (asked on #virt about downsides to that...  i suspect the check can just be removed from configure...  we'll see)
<sarnold> hooray, adduser complains if you try to add a user with : or , in the username :)
<infinity> hallyn: If it's autoconf, you can preseed the location, so it doesn't look for it.
<infinity> hallyn: ac_cv_path_COLLIE=/usr/bin/collie ./configure ...
<infinity> hallyn: Or possibly --with-storage-sheepdog=/usr/bin/collie
<hallyn> i *guess* that's cleaner than touch /usr/bin/collie :)
<infinity> hallyn: Well, touch won't work, you're not root.
<hallyn> as builder?  oh...
<hallyn> ok, thanks, i'll go with one of those
<slangasek> "Backend Sheepdog" is the name of my folk metal band
<infinity> hallyn: I'm testing quickly here.
<hallyn> infinity: jinkeys - no need, i don't want to take up your time, i'll do it!
<infinity> hallyn: Too late? :P
<hallyn> infinity: thanks :)  so, if we enable that, should sheepdog go into suggests?
<infinity> hallyn: Probably, yes.
<hallyn> kthx.  think i'll ask zul to look over this one before i push (since he maintains sheepdog pkg)
<zul> hallyn: sure
<infinity> hallyn: http://paste.ubuntu.com/1693989/ <-- This gives me plausible configure output.
<infinity> hallyn: The packages don't currently suggest half the world, so I'm not sure adding sheepdog is necessary (but not wrong to have it suggest everything it can potentially make use of either)
<infinity> Hrm, maybe I should see how that's actually being AC_SUBSTed before I say it works. :P
<hallyn> infinity: yeah i'ts actually not looking like it's getting set to true like that
<hallyn> or wait
<hallyn> no yeah, capitalization is throwing me off, but i think it's working
<infinity> Nah, it's not being substed.
<hallyn> infinity: (i forewent doing a WITH_SHEEPDOG variable...  not sure if we have a general packaging preference)
<hallyn> i see configure: Sheepdog: /usr/sbin/collie
<infinity> Yeah, which isn't doing the right thing in the makefiles.
<hallyn> all right i need to go afk.  will look tomorrow.  thanks for the help - ttyl
<kieppie1> hi guys
<kieppie1> the new releases look pretty good
<kieppie1> thanks for the hard work
<kieppie1> I'm just wondering if there will be some sort of unifying experience
<kieppie1> i.e ubuntu on desktop, netbook, tablet, mobile & TV, and if/how I'd be able to maintain & manage a unified session across nodes
<infinity> hallyn: Okay, got it all sorted.
<infinity> hallyn: Maybe I'll just upload this, so it doesn't get lost later. :P
<hallyn> infinity: if you do, do you mind adding http://paste.ubuntu.com/1693657 ?
 * hallyn sneaks afk again
<infinity> hallyn: Surely, you want getent there, not grepping of group...
<infinity> hallyn: Though I see there's precedent with the sudo one.
<hallyn> infinity: well yeah i guess...  i like to follow precedent usually, but you're right
<hallyn> infinity: so if you prefer to punt and i'll properly fix later, that makes sense.
<infinity> hallyn: Is the sudo thing from Debian, or is that our own ickiness?
<infinity> hallyn: While I was in here, I noticed another package where I missed enabling libaudit linking, so I'll do that too.
<hallyn> infinity: the sudo thing was originall admin (i did sed -i s/admin/sudo).  it comes from debian though
<infinity> hallyn: Alright, if this construct is in the Debian packages too, I'm fine with including your bit on top.  But suggesting they could do it better wouldn't be awful either. :P
<hallyn> no i think i jut slied
<hallyn> infinity: we're not merging libvirt from debian right now anyway
<hallyn> zul takes it straight from usptream
<infinity> Yay for collaboration. :/
<hallyn> well they were slow for awhile.  not sure the rationale works anymore...
<hallyn> but yeah it's taken an opposite trajectory from qemu
<infinity> Yeah, Debian doesn't have this code snippet for the sudo thing.  It's Ubuntu-specific.
<infinity> I'll just add your bits, and then convert both to getent for my own peace of mind.
<hallyn> infinity: thanks.  (really leaving now)
<cjwatson> kieppie1: we don't really have all the specifics yet, but unifying the experience has been a consistently theme of the recently-released videos about phone and tablet
<cjwatson> *consistent theme
<smoser> barry, http://serverfault.com/questions/415602/getting-sessions-still-open-not-unmounting-when-exiting-psql-what-does-this . do you use encrypted home?
<smoser> (i do)
<barry> smoser: but of course :)
<smoser> so, yeah, its probably coming from somewhere down that path.
 * barry nods
<mdeslaur> hallyn: yeah, looks good to me
#ubuntu-devel 2013-02-21
<slangasek> barry, cjwatson: how is the update-manager build supposed to work with python3-distutils-extra + debhelper?  Attempting a simple build fails if python is present at all, because debhelper picks /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm for the buildsystem which invokes python, not python3
<slangasek> and this doesn't seem to be anything that's changed recently in any of the related packages...
<slangasek> oh, I see; the package has overrides that bypass this for dh_auto_{build,install} but not _clean, heh
 * slangasek passes -nc :P
<slangasek> hmm, still fails, because it calls dh_auto_install rather than completely bypassing it
<slangasek> stgraber: ^^ looks like you did much of the python3 changes initially?  any thoughts here on what I'm missing?
<slangasek> perhaps I'll just switch to pybuild
<stgraber> slangasek: hmm, I last touched it during the python3 sprint but it's an mvo package, so you need to make sure to run the script that's in the branch (can't remember the name, sorry) and then use bzr bd to trigger the build
<stgraber> I don't remember having to do anything else back then
<slangasek> well, this branch no longer has a pre-build script
<stgraber> ah, ok, I guess that's a good thing ;)
<slangasek> that went away back in June when mterry split the branches
<slangasek> so I think I can just condense debian/rules down to "dh $@ --with=python3 --buildsystem=pybuild" now... but I really have no idea why this stopped working
<barry> slangasek: i haven't tried building it in a while, but i hated that pre-build script. :/   +1 for --buildsystem=pybuild, and i have no idea why it's stopped working recently either
<cjwatson> Me neither; I thought I was fairly careful to get all the overrides right
<slangasek> well, launchpad was ok with your overrides at the time you uploaded :)
<slangasek> but it definitely fails for me now
<barry> slangasek: local sbuild from trunk branch is happy
<slangasek> hmmm
<slangasek> furthermore, building with pybuild gives a failure because it can't find debian/tmp/usr/share/locale... but I don't see anything that installs that
<barry> slangasek: you're seeing buildd failures?
<slangasek> barry: no, local failures; not a pristine sbuild, I'm trying to bzr bd in a chroot
<slangasek> (so python is installed, since bzr needs python)
<barry> slangasek: i'm not sure i'd call my local raring chroot "pristine" ;)
<barry> but it's *fairly* sparse
<slangasek> right, so if I build in an env with no /usr/bin/python, it /happens/ to build successfully
<barry> slangasek: wow.  and indeed, my chroot does not have /u/b/py
<pitti> Good morning
<dholbach> good morning
<alkisg> Good morning
<alkisg> I'm trying to solve a bug in LTSP that might even result in data loss... could someone point me on how to write a cleanup handler for an X application (called LDM) that runs even if Xorg crashes (in which case I think Xorg kills all its childs) ?
<alkisg> It doesn't look like an atexit() handler would do, would I need a TERM signal handler instead?
<kieppie1> cjwatson: re unified experience - that was my impression too. I'm just curious re the underlying tech that would achieve that.
 * Laney prods SpamapS with https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/1074606/comments/19
<ubottu> Ubuntu bug 1074606 in gparted (Ubuntu Quantal) "gparted identifying incorrect raid arrays" [High,In progress]
<Laney> It's not an accident - this is new-ish behaviour; it's correct to upload with just the bare release as the target
<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
<TheMuso> diwic: Good catch. at one point I remember thinking that all used vlc, but I didn't really make the connection.
<diwic> TheMuso, I'm uploading a fix for those two (1129990 and 1127872) within an hour
<TheMuso> Ok great.
<TheMuso> Thanks.
<diwic> TheMuso, but while troubleshooting I discovered that autospawn seems to have stopped working, can you confirm that?
<diwic> TheMuso, I also discovered that PA does not work at all on guest accounts due to just filed bug 1131139
<ubottu> bug 1131139 in lightdm (Ubuntu) "Guest cannot create /run/user/<name>/ subdirectory" [Undecided,New] https://launchpad.net/bugs/1131139
<TheMuso> diwic: Afaik autospawning works fine, as thats how pulse is brought up, at lesat I think so...
<TheMuso> But I'll try and manually confirm in a bit on a text console when I'm logged out.
<diwic> TheMuso, just execute "pulseaudio -k", then try to use pulse and see if it autostarts
<TheMuso> Ok.
<TheMuso> Yes.
<TheMuso> It does.
<TheMuso> But I am using the completely new pulse config here, I have nothing to do with pulse in my home dir.
<diwic> TheMuso, ok, good. Then I probably screwed up something here.
<TheMuso> I/c
<diwic> ok, 0ubuntu3 uploaded
<pitti> seb128: WDYT about bug 1130956?
<ubottu> bug 1130956 in gnome-system-monitor (Ubuntu) "Update gnome-system-monitor to 3.7.90" [Wishlist,New] https://launchpad.net/bugs/1130956
<pitti> seb128: specifically, moving leaf packages to 3.8 if they work with our 3.6 base
<TheMuso> I/c
<seb128> pitti, I'm fine updating as long as the people doing the update keep up with the bugs due to the unstable version they upload
<seb128> pitti, g-s-m is fine, I would like to avoid e.g nautilus until 3.8 stable
<pitti> seb128: yeah, absolutely (that bug mentions this also)
<seb128> pitti, wfm then ;-)
<pitti> seb128: ok, thanks; it's API/ABI freeze now and all that, so 3.8 should work as well
<seb128> cool
<ricotz> seb128, pitti, hi :)
<seb128> ricotz, hey
<ricotz> oh , 3.8 apps in raring
<ricotz> seb128, btw, gtk 2.24.16 is probably a candidate for raring?
<seb128> ricotz, yeah, it's in the desktop team ppa, I was planning to land that with attente's unity menu work
<ricotz> ah, i see
<ricotz> good
<pitti> hye ricotz, wie gehts?
<ricotz> pitti, hey, danke gut!
<ricotz> und dir?
<ricotz> pitti, i was tempted to ask if you could give those build a little bump https://launchpad.net/~gnome3-team/+archive/gnome3-staging/+builds
<ricotz> pitti, btw is the /media vs /run/media patch in udisk2 still wanted?
<pitti> ricotz: yes, slangasek was rather adamant on keeping /media/
<pitti> ricotz: it could soon be superseded by a better solution, though; some days ago there was some discussion on the ML about this topic, but I don't think that landed already
<pitti> ricotz: oh, you packaged current udisks? that was on my TODO list in a week or two, I'll look at your pacakges then
<pitti> dholbach: are you already sponsoring https://code.launchpad.net/~logan/ubuntu/raring/cpptest/1.1.2-0ubuntu1/+merge/149667 (as you committed recently), or want me to?
<ricotz> pitti, it is there for some time, it was already needed for an ealier gnome-dist-util version
<ricotz> pitti, due some refactoring a huge part of the media-patch gone obsolete (i could be wrong here though)
<pitti> ricotz: I guess it's not that important for the gnome 3 ppa
<ricotz> pitti, it working fine afaics, the actual run/media>media change is still present and working
<pitti> ricotz: ah, I guess David may have refactored that because he wanted to support a new udev property UDISKS_USE_MEDIA or so
<pitti> ricotz: that's what I meant with "going to become much eaiser"
<ricotz> pitti, alright
<dholbach> pitti, I sponsored it already
<pitti> dholbach: ah, you didn't push the merge then, I guess; I'll mark it as merged
<dholbach> thanks pitti
<zyga> hey, I have a patch for pastebinit to work in python3 venv, the patch fixes the shebang line from "/usr/bin/env python" to "/usr/bin/python". I made the patch to current raring package using quilt, how can I contribute that and get it applied to raring
<zyga> I also added a debian/changelog entry and tested the package
<asac> zyga: from looking at changelogs i would talk to stgraber for pointers
<asac> https://launchpad.net/ubuntu/+source/pastebinit/+changelog
<zyga> stgraber: ping
<zyga> I made a debdiff
<zyga> stgraber: I'm not exactly sure what to do next, the debdiff is here http://paste.ubuntu.com/1698728/
<asac> zyga: the official answer is most likely to read and follow https://wiki.ubuntu.com/SponsorshipProcess
<zyga> asac: sorry, having read that page I don't know what to do, should I start with the lp:ubuntu/... package and re-do the change so that I can submit a merge request?
<asac> The traditional process involves:
<asac>  1. File an Ubuntu bug in Launchpad
<asac>  2. Attach your work  (note: debdiff is one option there)
<asac>  3. Subscribe ubuntu-sponsors
<asac> from that point on the process should automatically unfold through discussion in bug. if nothing happens for a while, a gentle ping of last uploader asking for help is appropriate
<zyga> asac: ah, thanks
<asac> zyga: thats copied out of the wiki page btw
<hrw> zyga: and that's best way to do such stuff
<hrw> zyga: not everyone tracks irc whole day
<bryceh> zyga, looks like pitti is the patch pilot today; if you get stuck, or when you think you're ready for review, you can (should) ping him
<bryceh> (see topic)
<pitti> zyga: sure, I can upload that
<pitti> zyga: but please forward this upstream, too
<zyga> pitti: this is not an upstream bug
<zyga> pitti: this is just the packaging, normally debhelper patches that but here it's not detecting this as a python package
<zyga> pitti: I'll open a merge request after the meeting now
<zyga> pitti: I suspect there's a ton of identical issues in other packages
<zyga> hrw, bryceh: yeah, thanks, I was looking for input on how to contribute that
<pitti> right, in general packaged python scripts should use /usr/bin/python..., not env
<zyga> right
<smartboyhw> Hello. Can somebody try to tell me what was wrong in https://launchpadlibrarian.net/131963515/buildlog_ubuntu-raring-i386.calligra_1%3A2.6.1-0ubuntu5_FAILEDTOBUILD.txt.gz ?
<pitti> zyga: no MP necessary, the patch is fine
<pitti> zyga: I'm worried about adding the patch, not the form in which to sponsor it
<smartboyhw> Only one make[1]: *** [all] Error doesn't help...
<pitti> zyga: it's this kind of annoying patches which we have to carry forever unless we agree with upstream what the shebang should be like
<pitti> and it's not really a blocker for running with py3, you can just run python3 pastebinit, after all
<zyga> pitti: but the shebang _is_ right upstream, it's a bug in debhelper not fixing all scripts this way
<zyga> pitti: it's not a problem with python3, only with virtualenv -p python3
<pitti> zyga: if debhelper changes the hashbang to use env, how does the patch help then?
<zyga> pitti: where it breaks because python == python3
<pitti> eh?
<pitti> python == python3 is really wrong
<zyga> pitti: it does for python packages, it does not look at all scripts to check
<bryceh> smartboyhw, /usr/include/qt4/QtWebKit/qwebpage.h:1:55: fatal error: ../../../../Source/WebKit/qt/Api/qwebpage.h: No such file or directory
<pitti> that's what Arch is doing, and it's just plain broken
<zyga> pitti: that's virtualenv
<pitti> zyga: we better fix that then IMHO
<zyga> pitti: virtualenv -p python3 /tmp/omg &&  . /tmp/omg/bin/activate
<pitti> python != python3
<zyga> pitti: that's specified upstream behavior, python3 does that too
<pitti> no, it's not
<zyga> pitti: the real problem is in packaging I'm afraid
<pitti> unfortunately the PEP does not explicitly forbid it
<pitti> but the only ones guaranteed are "python2" and "python3"
<pitti> if something calls "python" and gets python3, we cannot blame that something
<zyga> pitti: still, it's broken in terms of our own policy
<zyga> pitti: I'm glad to work on dh to actually fix that on arbitrary executable scripts
<zyga> pitti: that would make this patch obsolete
<zyga> pitti: note that many python developers use virtualenv (especially non-system developers) and this breaks a very popular program in practice
<pitti> or fixing virtualenv
<zyga> pitti: on the upside python3 is not really common yet
<zyga> pitti: I can check if that's a vaiable fix but I suspect that'd be a patch for virtualenv that we carry and a difference from all other systems, I'm not sure we want that either
<zyga> pitti: though I agree that virtualenv behavior is annoying
<zyga> pitti: I'll ask virtualenv upstream
<pitti> no, that's certainly something to fix in virtualenv upstream
<zyga> pitti: would you be happy with dh automatically patching all 'env python' to 'python' scripts?
<pitti> but even if we have to patch it there, it's IMHO better to patch in one place than in lots of packages
<pitti> zyga: if that's the right thing to do, not 100% sure; barry, ScottK, any opinion about changing #!/usr/bin/env python hashbangs automatically?
<zyga> (me talks to virtualenv commiter he knows)
<ScottK> pitti: It kind of depends.  For "normal" python packages that makes sense.  For things developers use, they may want to override that somehow.   I think barry is the best person to ask.
<pitti> I guess the root of all evil is http://www.python.org/dev/peps/pep-0394/
<pitti> "python should refer to the same target as python2 but may refer to python3 on some bleeding edge distributions"
<pitti> that's quite frankly just plain stupid
<zyga> pitti: note
<pitti> as some distros like arch, and maybe the virtualenv authors will refer to that
<zyga> pitti: that's python3.3 behavior
<pitti> as that essentially invalidates "python" to be anything meaningful
<zyga> pitti: run pyvenv-3.3
<zyga> pitti: well, in a way it's sensible outside of unix+packages world
<pitti> so in theory everything needs to say "python2" or "python3" now
<zyga> pitti: you install "that python" and "python.exe" is "that python"
<pitti> unless you carefully port your py2 programs to work on both py2 and py3
<zyga> pitti: but it's already larger than virtualenv as python3.3 with standardized virtualenvs is what we have in the future
<pitti> but it breaks pretty much every non-ported python2 program out there
<zyga> pitti: note that shebang was not something that was in python scope until python3.3
<zyga> pitti: not python2 or python3, but system packages must use an absolute path for the interpreter
<pitti> zyga: yeah, that PEP is quite recent, 2011
<zyga> yes
<zyga> pitti: note that it also fixes shebangs on windows
<pitti> zyga: no, that's not the problem; "/usr/bin/env python" should still get you python 2.x
<pitti> (it might not be policy compliant for other reasons, that's my question to barry)
<zyga> pitti: in theory yes but look that all windows releases have 'python.exe'
<zyga> pitti: so no version-encoded executabales
<pitti> well, same problem
<zyga> pitti: 3.3 fixes that a bit
<zyga> pitti: with a new program that interpretes shebangs for python
<zyga> pitti: to work for 2.* - 3.*
<pitti> zyga: it looks at the source code and tries to figure out whether it's for py2 or 3?
<zyga> pitti: sadly it's something we've been doing but that's not "the python way", so the solution might be painful
<zyga> pitti: no, it reads the shebang
<zyga> pitti: and the shebang is special
<zyga> pitti: let me show you the spec
<pitti> but that's the one that they just invalidated as a reliable source of information
<zyga> http://www.python.org/dev/peps/pep-0397/
<pitti> the root cause is that py3 breaks compat with py2 in many ways, i. e. it is really a new language
<pitti> so you can't call it like the old one
<zyga> pitti: scroll down to "Shebang line parsing"
<zyga> pitti: that's true
<zyga> pitti: I think we really need barry to tell us his opinion
<pitti> zyga: well, that shebang line parsing is ceratinly helpful
<zyga> pitti: at this time, we'd have to patch virtualenv and python3.3+ to fix this
<pitti> but it seems orthogonal to determining for which python version a program is
<zyga> pitti: actually
<zyga> pitti: could we do something as crazy as binfmt support to use 3.3 launcher on all python files?
<pitti> wouldn't that even aggravate the problem?
<zyga> pitti: it does support python2 versions
<pitti> we can't run any py2 program through py3
<zyga> pitti: that launcher just re-exes the right version of pytohn
<pitti> how does it determine the right version?
<pitti> if the hashbang says "python", then you really could just guess
<zyga> pitti: according to the spec
<pitti> (in the world of PEP-394)
<zyga> pitti: I don't know off the top of my head
<pitti> in the actual world, python has meant 2.x for years
<pitti> (which again is why PEP-394 is broken)
<zyga> pitti: yeah but we need to deal with 'bug that became a feature' unless we can fix it upstream somehow
<zyga> pitti: it says that /usr/bin/python2 automatically locates python2.* installation
<zyga> pitti: it's pretty long, I'm in a meeting, let me read that in the background
<zyga> pitti: ping me if barry sends a word
<pitti> zyga: yes, no problem with "python2" and "python3"
<Snow-Man> pitti: think any more about having clusters able to use the same port? :)
<pitti> Snow-Man: not recently
<Snow-Man> it's frustrating to not be able to use the cluster tools. :/
<stgraber> pitti,zyga: IIRC I already switched to /usr/bin/python3 in current upstream trunk
<vibhav> Apparently, python is somewhat broken in Raring
<vibhav> os.sync() is broken
<pitti> indeed
<vibhav> Can anyone review https://code.launchpad.net/~jderose/ubuntu/raring/python3.3/fix-1131183/+merge/149838
<vibhav> Jason has submitted a fix
<stgraber> pitti,zyga: next release of pastebinit will be python3 only with /usr/bin/python3 as shebang. I don't really have an ETA though as I'm not spending much time on it usually
<zyga> stgraber: cool, thanks
<pitti> vibhav: thanks
<vibhav> pitti: thank Jason DeRose :)
<mitya57> dholbach: so docutils support for named links has landed! ... and I'm going to backport it to raring
<dholbach> mitya57, great
<mitya57> (though it's a bit ugly `like this <ref_>`_)
<mitya57> ah, and I also wanted to do a sphinx sru
<dholbach> mitya57, ubuntu-packaging-guide ftbfs right now - did you see the build log?
<mitya57> dholbach: I've fixed it yesterday
<dholbach> h no
<dholbach> great
<dholbach> :)
<mitya57> I think we should upload 1.3.1 before the feature freeze
<mitya57> (after I finish the python 3 port) :-)
<doko> pitti, can you check that your sponsoring for #1131183 works on the buildds?
<pitti> doko: sure; I built it locally and confirmed that both os.sync and fsync work
<doko> pitti, local builds were not the issue
<pitti> I'll do it again with the packages from the buildds
<doko> thanks
<dobey> what was the link for the udd branch import status/log/whatever?
<Laney> package-import.u.c
<dobey> ah, thanks Laney
<dobey> oh
<dobey> why is it so backed up?
<dobey> there's 845 outstanding jobs :-/
<dobey> one of which i am doing a new release of
<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:
<pitti> doko: amd64 has built, the buildd binaries are fine
<roaksoax> slangasek: howdy!! Just wanted to let you know I have uploaded python-django (ubuntu1.6) and python-tx-tftp as part of the MAAS SRU!
<kirkland> jamesh: hiya!  I was wondering if you had a chance to look at https://code.launchpad.net/~kirkland/upstart/no-scold/+merge/148816 yet?
<kirkland> slangasek: howdy!  I was wondering if you had a chance to look at https://code.launchpad.net/~kirkland/pam/sbin-update-motd/+merge/148559 yet?
<infinity> kirkland: You probably meant jodh, not jamesh.
<kirkland> infinity: ah!  thanks!
<kirkland> infinity: does he generally hang out here?
<infinity> kirkland: Generally, though he seems to adhere rather strictly to a concept of work hours. :)
<kirkland> infinity: lucky dog
<kirkland> infinity: thanks, I'll try to grab him earlier tomorrow
<infinity> slangasek: Did you and Colin come up with anything when unwinding the update-manager partial last night?
<kirkland> infinity: perhaps I'm catching slangasek on the right side of the sun, though :-)
<infinity> slangasek: I mean, it's correct that u-m doesn't generally want to remove packages, do we need to be doing mid-cycle quirking to allow specific bits like this to happen?
<cjwatson> The problem with quirking is that we only know the quirk is needed post facto, so we'd need to upgrade update-manager to apply the quick
<cjwatson> *quirk
<cjwatson> (Besides, it sounds like a lot of messing around rather than honouring the metadata)
<infinity> cjwatson: Oh, fair point.
<cjwatson> I was starting to attempt to write a test case for this
<infinity> cjwatson: Well, be default, it's meant to be as conservative as "apt-get upgrade", as in, it'll add packages, but never remove.
<infinity> s/be/by/
<infinity> cjwatson: I'm not sure how far we can relax that before we accidentally let it remove half of -desktop on a bad resolver run.
<cjwatson> I think mvo's idea of "permit removal as long as there's a direct c/p/r" would be ok ...
<infinity> cjwatson: Probably, yeah.  Any fallout from that will be obvious packaging bugs that should be fixed anyway.
<cjwatson> at least that way if there were a chain of packages involved then (worst case) you could work around it by c/p/ring them all
<infinity> cjwatson: Though, if such fanciness is being attempted, that almost belongs in the apt resolver itself, so upgrade (and other libapt consumers) can get a similar behaviour.
<cjwatson> I dunno, I sort of like the strict behaviour of upgrade - it's at least simpl
<cjwatson> e
<infinity> It is that.
<cjwatson> And this is something that's being explicitly forbidden by u-m
<cjwatson> It does depcache.upgrade(True) and checks depcache.del_count by hand
<infinity> Well, yes, I realise u-m is a bit different under the hood.  But even if it was just forking "apt-get upgrade", the result would be the same in this case.
<cjwatson> So it doesn't seem particularly wrong to relax it in u-m too
<cjwatson> It would, but I don't agree that it's a good model for it to be emulating apt-get upgrade
<cjwatson> Because I think apt-get upgrade is generally wrong
<infinity> Heh.
<infinity> Which goes back to "maybe upgrade should be less wrong".
<cjwatson> For instance if you're in the habit of using apt-get upgrade all the time then you'll lose out on new Recommends
<infinity> But making it less wrong while still unlikely to break computers is hard.
<cjwatson> Which is not how the system is meant to work
<cjwatson> (And, more to the point, you have no way to notice that you're losing out on new Recommends)
<infinity> That said, if we're worried about breaking computers, u-m is where we need to be most worried.  So if we get the logic right there, surely having all apt consumers do the same thing is fine.
<cjwatson> Honestly, any apt consumer that's driving depcache in an upgrade-like way rather than a dist-upgrade-like way is already wrong
<cjwatson> The right fix is to have them drive it in a dist-upgrade-like way
<infinity> And then to check delete counts and guess if it's okay?
<cjwatson> And forget about upgrade as hard as possible
<cjwatson> Or whitelist particular packages
<infinity> Where "guess" means "duplicate the same PCR checking"?
<cjwatson> (And TBH crazy delete counts are much less of a problem nowadays)
<infinity> Well, as you point out, whitelisting only works after the fact, which is chicken and eggy.
<cjwatson> No, I mean whitelist important things like -desktop
<infinity> Oh, right.
<infinity> Which is pretty much the dist-upgrader approach.
<infinity> Allow violence, repair.
<cjwatson> I just don't think that starting with apt-get upgrade is the right way to get a safe and correct upgrade path, so I'm not really so interested in fixing it
<cjwatson> Starting with dist-upgrade or similar makes a lot more sense to me
<infinity> Yeah, that's fair.  I haven't actually *run* apt-get upgrade in years (a decade, maybe?) for reasons stated.
<infinity> Then again, I don't run update-manager for similar reasons, so perhaps this highlights your view well.
<cjwatson> Right now, u-m is half-way in between.  It allows installing new packages but refuses to remove.
<cjwatson> (AFAIK anyway.)
<slangasek> mlankhorst: I'm confused by bug #1130974, I cannot reproduce this build failure here
<ubottu> bug 1130974 in xserver-xorg-video-nouveau (Ubuntu Precise) "mesa_8.0.4-0ubuntu0.3 fails to build on 12.04.2" [Undecided,Fix committed] https://launchpad.net/bugs/1130974
<mlankhorst> slangasek: needs libdrm >= 2.4.34 to fail
<mlankhorst> so if you don't have updates pocket enabled, it will just work
<slangasek> mlankhorst: hmm.... ok, I do have -updates enabled but apparently didn't apt-get update
<mlankhorst> :-)
 * mlankhorst has enough sru's to verify now!
<slangasek> roaksoax: hi - how is the new python-django upload different from the previous one?  I still had an action item from the last TB meeting to re-review the previous upload
<slangasek> kirkland: haven't looked at it yet, sorry... it's in the queue though
<kirkland> slangasek: no worries, thanks
<slangasek> infinity, cjwatson: so is there a consensus that we should go ahead with having u-m handle the c/p/r specially?
<roaksoax> slangasek: the new upload drops the GenericIpAddressField
<roaksoax> slangasek: which is now implemented in MAAS
<slangasek> roaksoax: ok.  if that's your preference, I'll review that one instead - I guess it should be a quicker review
<roaksoax> slangasek: indeed!! :)
<cjwatson> slangasek: I think that's what I picked up.  I started working on it but have been a bit derailed into trying to make u-m's test suite actually pass for me reliably so that I have a solid base to work on
<slangasek> ok :)
<infinity> slangasek: That seems less scary than just letting it tear things out willy-nilly, yes.
<cjwatson> (I have some kind of test isolation bug that's breaking my brain at the moment)
<slangasek> me, I'm still stuck trying to get it to build reliably without adding a Build-Conflicts with python
<infinity> Side note: Our UI needs more opportunity to use present users with options involving the word "willy-nilly".
<slangasek> pybuild is nearly there, but for some reason the install_data target isn't installing the .mo files
<cjwatson> Not to mention SERIOUSLY CAN WE STOP HAVING NETWORK-DEPENDENT TEST SUITES
<infinity> s/use //
<cjwatson> slangasek: mterry posted a dh9 branch - don't suppose that makes a difference?
<mterry> for update-manager?  yeah, it prevents the shebang from being stripped down to python2 by dh_pysupport
<slangasek> oh, is that what's been happening?
<slangasek> yeah, that might be a quicker fix
<mterry> cjwatson, the test suite is unreliable for you?
<mterry> cjwatson, hmm, I see the pep8 test fails...  and the port-listening test, which I agree is a pain
<cjwatson> mterry: yeah, got a failure in test_update_list which is order-of-tests-dependent
<cjwatson> mterry: I fixed the pep8 tests, update
<cjwatson> no port-listening failure here
<mterry> cjwatson, probably because you have installed an ssh server locally
<cjwatson> heh, but of course I have a local openssh server
<mterry> cjwatson, if port 22 isn't open, it fails
<cjwatson> stupid test
<mterry> cjwatson, which is a stupid test  :)
<cjwatson> Might have a go at that later
<cjwatson> Trying to narrow down the one I'm actually seeing first
<cjwatson> For me this fails reliably in test_update_list.GroupingTestCase.test_app if I have previously run test_cache.TestCache and test_meta_release_core.TestMetaReleaseCore in the same nosetests3 run, but not if I've run only one of those or neither.
<cjwatson> And if you remove test_meta_release_core.TestMetaReleaseCore.testnewdist then test_meta_release_core.TestMetaReleaseCore.test_url_downloadable falls over in a heap.  Hateful thing.
<cjwatson> Which I think is actually a genuine failure masked somehow ...
<larsgk> hi guys - now where ubuntu-phone is flooded ... do you know of a channel for ubuntu phone core app devs?
<slangasek> cjwatson: ok, the dh9 still doesn't make a difference... that only avoids dh_pysupport mangling the files post-install, it doesn't prevent the build system from invoking setup.py wrong
<xnox> larsgk: #ubuntu-arm =)
<larsgk> xnox: cool - thanks
<bdmurray> sbeattie: bug 982619 could use a test case
<ubottu> bug 982619 in apparmor (Ubuntu Precise) "aa-logprof wrongly transforms PUx to UPx" [High,In progress] https://launchpad.net/bugs/982619
<sbeattie> bdmurray: thanks
<bdmurray> sbeattie: oh and bug 1091642
<ubottu> bug 1091642 in apparmor (Ubuntu Precise) "apparmor parser fails due to matchflags not being reset" [Undecided,Triaged] https://launchpad.net/bugs/1091642
<bdmurray> sbeattie: let me know when they do and I'll rereview / approve
<sbeattie> the latter has a testcase incorporated in the source as part of the patch
<sbeattie> but yeah, I can tease that out and include it in the bug description.
<mdeslaur> shadeslayer: think you could get someone to verify the transmission package you have in quantal-proposed? I'm waiting on it to prepare a transmission security update...
<jtaylor> transmission from proposed still works fine, let me quickly install qt to see if the bug is fixed
<jtaylor> ok how do I use the magnet link?
<jtaylor> (and what is a magnet link?)
<jtaylor> pasting it in chromium just gets to me to a google index ._.
<sarnold> jtaylor: paste it into your torrent client. on rtorrent, backspace <paste>...
<jtaylor> sarnold: in the bug testcase "* Try to open same magnet link using chromium,"
<sarnold> jtaylor: ah :D
<jtaylor> it works from firefox though, is that enough?
<YokoZar> Can I upload proposed SRU's with just "precise" in the changelog file or do I still have to manually change that to precise-proposed?
 * jtaylor always adds -proposed
<jtaylor> I think the automatic proposed is just raring, but I could be wrong
<stgraber> YokoZar: just "precise" will work fine
<stgraber> jtaylor: the rewrite works for all series
<jtaylor> nice
<xnox> YokoZar: yes, you can.
<jtaylor> https://wiki.ubuntu.com/StableReleaseUpdates should be updated then
<jtaylor> it still says upload to -proposed
 * ScottK always writes -proposed in debian/changelog.  
<ScottK> (for SRUs)
<ScottK> jtaylor: It's automatic everywhere.
<timrc> hallyn, maybe I need to upgrade to raring because I'm not finding armhf lxc containers in quantal even remotely stable... even when I get a container that's bootable and capable of being logged into, I get hangs :(
<timrc> armhf-on-x86, to be more specific
<hallyn> timrc: like i say there will still be issues on raring, but i can actually do real work in an armhf container in raring
<hallyn> just dont' run java
<hallyn> it segfaults - i need to check actually whether physical arm host maybe does the same thing
<timrc> hallyn, keyboard is still responsive in the lxc console (I can ctrl-z, for example)
<timrc> hallyn, anywho, I'll give it a whirl in raring :)
<shadeslayer> jtaylor: interesting, from what I tested firefox didn't handle magnet links but chromium did :P
<xxiao> could not find lxc in 12.10 for ppc
<xxiao> E: Unable to locate package lxc
<xxiao> https://launchpad.net/ubuntu/quantal/powerpc/lxc does show it
<stgraber> xxiao: do you have universe enabled in /etc/apt/sources.list?
<xxiao> stgraber: thanks. was comparing it to x86 12.04, indeed universal is not enabled
<xxiao> stgraber: i built the rootfs from ubuntu-core, it has universal disabled by default
<stgraber> yeah, that was my guess when you said you couldn't find lxc in 12.10
<xxiao> now it's ok, thanks!
<lefteris> hi
<lefteris> I'm interested in getting an SRU for LP bug #1081307 but debfx there says there's already a pending SRU which although I cannot find
<ubottu> Launchpad bug 1081307 in virtualbox (Ubuntu Quantal) "I'm upgrading the 12.04.1 to quantal 3.5 kernel - virtualbox-dkms 4.1.12-dfsg-2ubuntu0.2: virtualbox kernel module failed to build" [Undecided,Confirmed] https://launchpad.net/bugs/1081307
<lefteris> could someone tell me if I need to prepare a debdiff, or just need to wait?
<jtaylor> debfx: ^
<jtaylor> I can't find it either, its also not in the queue, maybe it was rejected?
<lefteris> can i prepare a debdiff for https://launchpad.net/bugs/1081307 or just need to wait?
<ubottu> Ubuntu bug 1081307 in virtualbox (Ubuntu Quantal) "I'm upgrading the 12.04.1 to quantal 3.5 kernel - virtualbox-dkms 4.1.12-dfsg-2ubuntu0.2: virtualbox kernel module failed to build" [Undecided,Confirmed]
<ScottK> lefteris: You can prepare a debdiff without waiting.
<lefteris> ScottK: ok, thanks
<GuidoPallemans> is there any way to save settings for an app in qml?
<slangasek> barry, doko, pitti: so I'm looking for some advice on an interaction between python3-distutils-extras and pybuild.  build_i18n works by extending data_files with the list of generated .mo files to install; this works fine if build_i18n is called from the same process as install, but when they're called from separate processes, the info doesn't get passed anywhere... and pybuild seems to be clever enough that it doesn't call build_i18n a 
<slangasek> ... in the 'install' target.
<slangasek> not sure which bit to consider this a bug in
<sarnold> slangasek: you were cut off at "it doesn't call build_i18n a"
 * doko never touched distutils-extra
<slangasek> sarnold: orly?  should have wrapped to a second irc message
<barry> slangasek: interesting.  do you have a branch to show this?  total wag would make me think that it's p-d-e that should work better in that case
 * slangasek has splitlong.pl enabled
<slangasek> doko: that doesn't prohibit you from having opinions :)
<sarnold> slangasek: it didn't seem to flow into the second message well, ".. call build_i18n a in the 'install' target"
 * barry has futz with p-d-e a few times
<slangasek> barry: sure, let me twiddle my update-manager branch into something pushable
<barry> +1
<slangasek> sarnold: heh, then apparently splitlong and freenode disagree about how long is long :P  "second time"
<ScottK> slangasek: It did wrap into a second message fine here.
<barry> slangasek: could you port splitlong to elisp so i can use it in erc? :)
<slangasek> barry: I'm sure someone has implemented it for erc before... :)
<sarnold> slangasek: heh :)
<slangasek> barry: lp:~vorlon/update-manager/pybuild
<slangasek> barry: in principle, do you think the right answer is for build_i18n to stash its state somewhere and have a separate install_i18n target that picks it back up, or for pybuild to call setup.py in a way that build_i18n gets run again?
<barry> slangasek: my gut feeling is that `pythons setup.py <command>` should be stateless and pybuild should adjust for that
<barry> *python
<slangasek> ok
<barry> slangasek: well, otoh install does install everything from the build directory, so build; build_i18n; install should work
<slangasek> what I really don't understand is why /usr/share/perl5/Debian/Debhelper/Buildsystem/python_distutils.pm invokes setup.py install in such a way that build_i18n is run again, but pybuild does not
<barry> slangasek: maybe ping piotr over in debian-python?
<slangasek> ok
<barry> probably just a bug in pybuild is my guess
<barry> slangasek: is this the symptom of the problem:
<barry> cp: cannot stat './debian/tmp/usr/share/locale': No such file or directory
<barry> dh_install: cp -a ./debian/tmp/usr/share/locale debian/update-manager-core//usr/share/ returned exit code 1
<barry>  
<slangasek> barry: yes
<slangasek> is meant to be installed by the debian/rules install target; isn't
<barry> slangasek: one thing that's interesting is that it looks like pybuild build s into .pybuild/pythonX.Y_3.3/build/ but the mo directory is left in build/
<slangasek> hmm
<barry> slangasek: wag, maybe pybuild isn't passing --install-layout to build_i18n?
<slangasek> barry: it's evidently not passing --install-layout to any of the setup.py invocations
#ubuntu-devel 2013-02-22
<xnox> looking at distutils-extra the built_target is quite naive and hardcodes build/
<xnox> (not sure if it's intentional to use the same mo_dir for all runs.
<barry> slangasek: gotta run, but will check the scrollback when i'm back later tonight
<slangasek> barry: ah, k - is the --install-layout stuff a likely cause of the issue?
<GuidoPallemans> where can I find the source for the ubuntu phone internet application?
<slangasek> barry: aha, so pybuild creates .pybuild/pythonX.Y_3.3/.pydistutils.cfg, which sets 'skip-build=1'... I'm guessing that's the issue
<slangasek> barry: sure enough, omitting skip-build=1 fixes the issue
 * slangasek files a bug on python-defaults
<xnox> yeah, cause there is no sane way to override .pydistutils.cfg =/
<xnox> alternatively, distutils-extra should provide install_* commands.
<slangasek> it could, but wouldn't that effectively be an interface change for the users of distutils-extra?
<xnox> yes.
<slangasek> so, not my first choice
 * xnox is failing to use --before-install option
<xnox> slangasek: http://paste.ubuntu.com/1702914/
<xnox> works, but it's ugly......
<slangasek> xnox: easier: I just added skip-build=0 to setup.cfg
<xnox> =)
<xnox> slangasek: all shebangs are wrong. they are all 3.3
<xnox> but should be python3
<slangasek> tsk
<slangasek> so why is that?
<xnox> because the scripts got build with python3.3 not python3
<slangasek> well, why did pybuild do that?
 * xnox does override_dh_python3: dh_python3 --shebang=/usr/bin/python3 (to fix this)
<xnox> I am constantly told that "dh_python3 does that out of the box by default" but it doesn't seem to for me ever without override.
<xnox> Also, I often find a need to select py2 or py3 for the scripts.... and there is no way to say build py2/3 modules, but py2 scripts.
<xnox> and vice versa.
<xnox> slangasek: i recommend to raise compat to level 8 or the default 9.
<xnox> as currently it ends up calling python_support (if available)
<slangasek> right, mterry has a branch for that already
<xnox> ok.
<barry> slangasek: interesting.  thanks for filing that bug
<pitti> Good morning
<pitti> slangasek: so from what I understood from scrollback, the problem is that ./setup.py build_i18n dynamically adds the generated .mo files (which are put into ./build/mo, but that shouldn't matter) to data_files, but a subsequent ./setup.py install loses that information, right?
<pitti> slangasek: i. e. to be able to split the commands in that way, the dynamic data_files need to be put into a file instead of just in distutils' brain?
<pitti> stgraber: hey
<pitti> stgraber: do you know if inotify is supposed to work in LXC containers?
<pitti> stgraber: we run jhbuild in lxc, and inotify_init() always fails with EMFILE (Too many open files)
<Whoopie> Hi, seb128 was so kind to sponsor the upload of usbmuxd, and it's now in the unapproved queue. What needs to be done to get it approved?
<Whoopie> mdeslaur: Hi, I just saw that you sponsored iptables (bug 1074923). There's already another upload in the queue. Perhaps, both upload should be merged?
<ubottu> bug 1074923 in iptables (Ubuntu Quantal) "iptables-save doesn't write --hex-string pattern correctly" [Medium,In progress] https://launchpad.net/bugs/1074923
<Whoopie> mdeslaur: and a look into the debian-changes-1.4.12-1ubuntu4 should also be done, as it reverts some parts of 0001-libxt_recent-Add-support-for-reap-option.patch
<geser> Whoopie: wait till a SRU member reviews it (I assume it's about the SRU)
<Whoopie> geser: alright. so it's "just" a matter of time and ressources?
<Whoopie> mdeslaur: I made a debdiff for the iptables merge in bug 1074923.
<ubottu> bug 1074923 in iptables (Ubuntu Quantal) "iptables-save doesn't write --hex-string pattern correctly" [Medium,In progress] https://launchpad.net/bugs/1074923
<mpt> Which package provides the default locale data? E.g. the default time format for each locale
<slangasek> mpt: that bit should come from eglibc
<mpt> slangasek, thanks, I moved bug 1130501 there
<ubottu> bug 1130501 in eglibc (Ubuntu) "Spanish; Castilian (Puerto Rico) and Spanish; Castilian (United States) Regional Formats use 24-hour format by default" [Undecided,New] https://launchpad.net/bugs/1130501
<slangasek> heh, pretty sure there is no es_US locale
<slangasek> but there does seem to be an es_PR, so that's valid
<slangasek> (for es_US, that may be related to an installer bug cjwatson has been working on recently)
<tjaalton> doko: so.. how urgently do you need clang/llvm fixed? :)
<doko> tjaalton, well, it makes it a bit unusable ... so within a week or so?
<tjaalton> doko: oh, early next week for sure
<tjaalton> i'm away this week though
<doko> just want it be tracked, and afaics there is currently no workaround
<tjaalton> and discussing this with upstream so there's a sane resolution
<tjaalton> current upstream has touched the intrinsics again..
<zyga> pitti: hey
<zyga> pitti: I talked to virtualenv upstream and they would be glad to take a patch that fixes the issue we talked about yesterday
<zyga> pitti: have you had a word from barry?
<zyga> pitti: the solution I talked about would involve not creating 'python' symlink when virtualenv is called with -p python3.*, instead python3 symlink would be created
<zyga> pitti: if we make that patch in the next week it will be included in the pip next pip release which we could just pull to ubuntu
<zyga> pitti: and I meant virtalenv release, not pip release
<cjwatson> slangasek: as it happens, there is an es_US
<cjwatson> Which makes sense given the number of speakers
<pitti> hey zyga
<pitti> zyga: no, barry didn't answer to this
<pitti> zyga: it can always create a python3 symlink, it's the "python -> python3" symlink which hurts
<diwic> pitti, hi, may I assing bug 1131139 to you?
<ubottu> bug 1131139 in lightdm (Ubuntu) "Guest cannot create /run/user/<name>/ subdirectory" [Undecided,New] https://launchpad.net/bugs/1131139
<diwic> s/assing/assign
<pitti> diwic: oh right, please
<pitti> XDG_RUNTIME_DIR
<diwic> pitti, thanks a lot!
<zyga> pitti: it creates three executables actually, (well, one and two symlinks)
<zyga> pitti: for python, pythonX and pythonX.Y
<zyga> pitti: I'll patch virtualenv to skip the 'python' one for python3
<zyga> pitti: we'll review the patch and I'll push it upstream
<pitti> zyga: splendid, thanks!
<Quintasan> Hello
<TheMuso> Do any of our python gurus know whether we have http://bugs.python.org/issue16327 fixed in raring?
<GuidoPallemans> anyone else having trouble with qt creator since installing the sdk?
<GuidoPallemans> none of my plugins will load any longer
<mlankhorst> could anyone look at https://bugs.launchpad.net/precise-backports/+bug/1131173
<ubottu> Ubuntu bug 1131173 in Precise Backports "Please backport evemu 1.0.11daily13.02.20-0ubuntu1 (universe) from raring" [Undecided,New]
<mlankhorst> I need to make a similar one for xorg-gtest too, but iirc it needs some patching so I need to push that fix to raring first
<Laney> will do, sec
<Laney> mlankhorst: we'll need to backport to quantal as well to maintain the upgrade path so please also test there
<Laney> (g'day)
<mdeslaur> Whoopie: ah, thanks for noticing that...I had not realized there was one in the queue already. I'll take a look later on today.
<GuidoPallemans> anyone else having trouble with qt creator since installing the sdk?
<mlankhorst> Laney: sure np
<mdeslaur> tkamppeter: is there a public source code repo somewhere for hplip?
<mlankhorst> so what's the recommended way with dealing with xorg-gtest? it fails to build in the ppa because it expects a kernel module when running tests
<mlankhorst> https://launchpadlibrarian.net/130037138/buildlog_ubuntu-precise-i386.xorg-gtest_0.7.0-0~ubuntu0~ppa1_FAILEDTOBUILD.txt.gz
<vibhav> mlankhorst: I do my exactly know the build procedure for xorg-gtests, but what does it need tye kernel module for?
<vibhav> s/do my/don't/
<mlankhorst> running the tests during verification phase
<vibhav> mlankhorst: How does it use the kernel module?
<mlankhorst> uinput simulates input events it wants
<vibhav> Ah
<mlankhorst> easiest workaround is to skip tests though
<TheMuso> \/c
<cjwatson> GuidoPallemans: #ubuntu-app-devel might have more people with relevant expertise
<vibhav> mlankhorst: you took the package from Raring?
<vibhav> s/package/package source/
<mdeslaur> anybody have any tips on quilt failing miserably to patch a file with crlf terminators?
<diwic> mdeslaur, quilt push -f, patch -p1 < patchname, quilt refresh ?
<diwic> mdeslaur, just a guess though
<mdeslaur> diwic: as soon as I quilt pop and quilt push, it won't apply again
<diwic> mdeslaur, okay, then I have no idea
<mdeslaur> oh, wait, it's when I edit the patch to add the patch tags...
<mdeslaur> my editor fixes the line breaks, which then beaks quilt
<mdeslaur> diwic: nm, got it
<mdeslaur> thanks
<GuidoPallemans> cjwatson: thanks
<zul> mterry: ping
<mterry> zul, hello!
<zul> mterry:  can we get a quick review of oslo-config please (https://bugs.launchpad.net/ubuntu/+source/oslo-config/+bug/1130196)
<ubottu> Ubuntu bug 1130196 in oslo-config (Ubuntu) "[MIR] oslo-config" [High,New]
<zul> mterry:  its pretty simple package and should be ready to go
<mterry> zul, looking
<zul> mterry: thanks
<GuidoPallemans> anyone else having trouble with qt creator since installing the sdk?
<cjwatson> GuidoPallemans: like I say, #ubuntu-app-devel, please
<mterry> zul, the right package name would be python-oslo.config
<zul> mterry: uh?
<mterry> zul, rather than python-oslo-config
<zul> mterry: why?
<diwic> TheMuso, feel like sponsoring bug 1074673 to make jackd2 start on the nexus7?
<ubottu> bug 1074673 in ubuntu-nexus7 "JACK server fails to start" [Medium,Triaged] https://launchpad.net/bugs/1074673
<mterry> zul, package names are supposed to be python-XXX where XXX is what you use to import the module
<mterry> zul, see for example python3-zope.event
<zul> mterry:  ok this is blocking a new openstack upload to raring can i get a provisional ok provided that that package renaming?
<mterry> zul, yeah, it seems fine beside.  let me comment in bug
<zul> mterry: cool thanks
<stgraber> pitti: it should work, but you may have hit the limit of inotify watches on the host
<pitti> stgraber: yeah, we figured this out; thanks!
<stgraber> pitti: np. Did you just bump the limit in /proc/sys/fs/inotify?
<pitti> stgraber: right, we did
<TheMuso> diwic: Sure.
<diwic> TheMuso, thanks!
<Daviey> mterry: erm, the binary package is already called what you described.. no?
<Daviey> https://launchpad.net/ubuntu/+source/oslo-config/2013.1~b3-0ubuntu1
<zul> Daviey:  not python-oslo.config
<mterry> Daviey, dot instead of hyphen
<mterry> small nit really
<mterry> But if we're going to fix it, the sooner the better
<Daviey> mterry: sorry, i've never seen that in policy.. can you point me to it?
<TheMuso> diwic: has this been tested on armhf?
<TheMuso> diwic: Oh and you forgot to run update-maintainers on the package.
<mterry> Daviey, so obviously http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names has the basics, which is just that "if your module is foo, name it python-foo", which is ambiguous in such cases as a submodule.  I asked the question a while ago of barry, and he told me that dots were preferred to hyphens
<barry> mterry, Daviey yes, e.g. python-foo.bar
<mterry> Daviey, so..  "no, but I can point you to barry"  :)
<barry> python-zope.interfaces
<mterry> barry, could that be made clearer in the above python policy documetn?
<Daviey> yeah.. there are a few packages i have NEW reviewed that haven't got this.. and a few that have been MIR'd i've noticed already
<barry> mterry: hmm, would have thought it would be but i don't have that document tattooed to the back of my eyelids ;)
<Daviey> barry: Policy is your friend. Trust the Policy. Love the Policy. Obey the Policy. :)
<TheMuso> barry: Perhaps you can tell me whether we have the fix for http://bugs.python.org/issue16327 in our python toolchain yet. I've got a python 3 process here thats leaking file descriptors under particular circumstances. I'm working with upstream to get this solved, and was pointed to this bug.
<barry> http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names
<barry> so, yeah this should be added
 * barry files a bug
<mterry> Daviey, yeah it's not a commonly-followed aspect of the policy since it isn't actually written in it
<barry> TheMuso: looks like that was applied to the 3.3 branch on 2012-11-11 so i would expect it should be in raring's 3.3 snapshot, which doko is pretty good at keeping up to date with hg head.  i'd have to investigate a bit to see if it's been backported
<TheMuso> Hrm ok thanks.
<Daviey> whilst decimals are fugly in package names IMO, if it is standardised and written intopolicy, i am happy. :)
<stgraber> hallyn: hey, pitti and jibel strongly suspect some kernel bug that'd prevent inotify watches setup by containers from being properly freeed on container exit. Any idea how we'd go about debugging this?
<stgraber> s/by/inside/
<stgraber> this leads to the machine running out of watches (default being 8192) and then inotify stopping to work completely
<vibhav> stgraber: Can inotify be used outside the kernel?
 * vibhav was reading about inotify yesterday 
<stgraber> vibhav: yeah, tons of stuff in userspace use inotify watches. I don't think the kernel itself uses those, it just provides the API.
<vibhav> stgraber: AFAIK, inotify provides inotify_rm_watch for freeing watches, are you saying that this routine has a bug?
<stgraber> vibhav: either that (but we probably would have noticed on a regular desktop) or the fact that a container can be killed at once (killing all the processes and destroying the various namespaces) somehow causes a race which prevents those watches from being freeed
<doko> TheMuso, barry: it's in raring
<TheMuso> doko: Thanks.
<hallyn> stgraber: uh, one sec,
<stgraber> pitti, jibel: do you already have some kind of reproducer script? (something that registers as many watches as possible until it reaches the limit)
<pitti> stgraber: we don't yet, we just discovered about an hour ago that rebooting the host helps
<vibhav> stgraber: Maybe I could write the reproduced script. What should it exactly do?
<vibhav> reproducer*
<hallyn> stgraber: vibhav i doubt many ppl use inotify_rm_watch, it's teh cleanup at task exit that's likely at fault
 * vibhav takes a look 
<vibhav> hallyn: Does a process using inotify automatically cleanup during exit?
<vibhav> (even if it doesn't use rm_watches)
<hallyn> vibhav: yes
<hallyn> well, once all tasks using the inotify watch close
<vibhav> Gotcha
<hallyn> stgraber: well really i guess a little python script using pyinotify to open 8000 watches should help
<hallyn> run it ina container, shut down container, restart,
<hallyn> then try it without container, and with lxc-share
<vibhav> When a process exits, exit_files() and exit_fs() are called
<vibhav> To destroy objects related to file system data
<vibhav> hallyn: If not with rm_watch, there could be a bug with exit_fs
<vibhav> Which probably doesn't free the inotify watch
<stgraber> hallyn: I'll do a quick test script, walking the FS and setting up a watch for everything it sees until it fails because it reaches the limit, after that it should just be a matter of killing the container and see if they got freeed
<vibhav> stgraber: containers rely on cgroups, right?
<stgraber> vibhav: lxc uses cgroups but cgroups aren't an actual requirement of containers. It's just that without them you don't get any kind of resource control (but you still get the namespacing).
<hallyn> stgraber: i've got a script, hold on,
<hallyn> i think the bug only triggers AFTER you max out the inotify_user_watches
<hallyn> stgraber: http://33ad.org/pb/3YJ
<hallyn> I ran this in a container, killed the container, could still keep running it,
<hallyn> but after i ran it in a container *and* tried to run it on host at same time, i had trouble
<hallyn> and now, i'll have to reboot :)
<hallyn> no, ran it twice concurrently on the host
<hallyn> hm, no,
<hallyn> it just took awhile for the watches to clean up
<vibhav> stgraber: void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp) destroys a c group
<hallyn> stgraber: (do a 'for i in `seq 0 6000`; do touch x-$i; done' before running that script)
<vibhav> What about a bug there?
<hallyn> ok i'm moving back to libvirt until there are more details (seems to be working right for me here)
<hallyn> stgraber: btw, paste.ubuntu.com was hiccoughing when i tried to paste that script into it
<stgraber> hallyn: script looks fine here, so the paste worked. I'll poke at it in a bit.
<stgraber> pitti: can you share some details on the setup? are those standard fs backed containers (simple /var/lib/lxc entry without fancy lvm)? is the fs for / and /var/lib/lxc the same?
<jibel> stgraber, it's a very standard 12.10 server, ext4 witouth lvm and everything on the same fs
<stgraber> jibel: ok, I'll setup a VM with the same setup then. Thanks
<jibel> stgraber, we are building gnome modules on this machine with the test suites that comes with the packages
<jibel> stgraber, the cotnainer is raring amd64
<jibel> *container
<seif> hey guys
<seif> how do i access the terminal on the tablet
<seif> ?
<Daviey> stgraber: hey, is there any news on that precise apparmor lxc issue we discussed a few weeks ago?
<stgraber> Daviey: yep, SRUs for precise and quantal are in -proposed and all bugs have been verified, just waiting for the 7 days wait period
<Daviey> stgraber: entered -proposed on the 20th?  with the changelog date being the 7th!?
<Daviey> stgraber: to confirm, it includes the fix we discussed.. as you mentioned it missed one of the uploads
<mterry> seif, I think you have to do such things over adb
<seif> seriously?
<stgraber> Daviey: yeah, with 12.04.2 it took a while to get the sru accepted into proposed
<stgraber> Daviey: I uploaded on the 7th, then had to reject+fix an issue I spotted at the last minute, so final upload was on the 8th and they were accepted on the 20th
<mterry> jono, heyo!  http://developer.ubuntu.com/get-started/gomobile/ is telling people to install ubuntu-sdk, but the PPA just has qt-components-ubuntu
<jono> hey mterry
<jono> dpm, ^
<jono> mterry, dpm should be able to get that fixed
<dpm> mterry, I assume this is Raring: didrocks did some packaging changes, but I didn't know ubuntu-sdk had been removed?
<Daviey> stgraber: ah, thanks
<dpm> mterry, I can see ubuntu-sdk in https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-proper?field.series_filter=raring - which PPA are you using?
<mterry> dpm, this is P, Q, and R.   I don't know if ubuntu-sdk is old or new name, but all I've ever seen in that PPA is qt-components-ubuntu.  I believe the web page used to recommend downloading that name.  this is the first time I've heard the name "ubuntu-sdk"
<dpm> mterry, which PPA are you using?
<mterry> dpm, ah!  It's in the qt5-proper PPA.  I'm not using that, just the ubuntu-sdk-team/ppa PPA
<mterry> dpm, since I'm on raring, I figured the qt5-proper PPA didn't hold anything of interest for me
<mterry> (since raring has qt5 natively)
<dpm> mterry, for now it's still the instructions on http://developer.ubuntu.com/get-started/gomobile/ (2nd step instructs to add that PPA)
<mterry> dpm, sure.  My own fault for not following the instructions correctly
<mterry> dpm, (though, I would have expected the sdk to be in the ubuntu-sdk-team's PPA.  Seems natural)
<dpm> mterry, no worries, glad to hear it's not a packaging issue. Let me know if it woks.
<stgraber> hallyn, pitti, jibel: right, so I've been playing with pyinotify on 12.10 with a 13.04 container, trying to use watches on both host and container, randomly killing the container. All the watches are properly cleared...
<zul> can an archive admin promote python-oslo-config please? https://bugs.launchpad.net/ubuntu/+source/oslo-config/+bug/1130196
<ubottu> Ubuntu bug 1130196 in oslo-config (Ubuntu) "[MIR] oslo-config" [High,Fix committed]
<jibel> stgraber, ok, thanks for looking. For the moment I increased the number of inotify instances and restarted the server. I'll see if the problem occurs again.
<stgraber> jibel: ok. If it does, it'd be interesting to kill all containers, then run: http://paste.ubuntu.com/5555887/
<stgraber> this will try to setup 9000 watches and will print you how many it managed to setup
<stgraber> on your setup, it should be 9000 unless something is wrong, then you'd get the number of free watches (if any) back
<gkcn> has anybody experienced this evince crash: http://paste.ubuntu.com/5555900/
<gkcn> on raring. it seems to be realted with libgeis1
<gkcn> (filed a bug report https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1131886)
<ubottu> Ubuntu bug 1131886 in evince (Ubuntu) "Evince frequently crashes at startup due to libgeis1" [Undecided,New]
<infinity> hallyn: Your new qemu conflicts with itself all over, thanks to the kvm conflict being unversioned.
<infinity> hallyn: Oh, or because you added qemu-kvm, kvm to provides for all arches, while Debian only has it for x86...
<infinity> hallyn: Though, that's not thinking ahead on Debian's part, since other arches could get kvm ported to them (I know it's coming for ARM).
<hallyn> infinity: feh, i did it right in 1.3.0, did i mis-rebase?
<infinity> hallyn: Anyhow, for now, britney won't let it through (and rightly so), cause it's all uninstallable.
<infinity> -Provides: ${sysprovides:arm}
<infinity> +Provides: ${sysprovides:arm}, qemu-kvm, kvm
<infinity> (and the same for other arches)
<infinity> That bit makes it uninstallable.
<infinity> Since qemu-system-x86 conflicts with kvm.
<infinity> And then qemu-system can't be installed, cause it wants to install both.
<hallyn> infinity: so if you kick that, can i re-use that version #?
<slangasek> no
<slangasek> once it's accepted into the archive, the version number is forever
<hallyn> k
<hallyn> yes, but i didn't knwo whether it made it into the archive
<hallyn> no idea where 'britney' sits
<infinity> hallyn: What he said.
<infinity> hallyn: britney is the bit of code between proposed and release.
<infinity> hallyn: http://people.canonical.com/~ubuntu-archive/proposed-migration/
<hallyn> oh
<hallyn> infinity: the breaks/replaces in qemu-system-* to kvm was versioned in 1.3.0.  that got dropped
<infinity> hallyn: That's not the problem.
<infinity> hallyn: The problem is the provides versus conflicts.
<infinity> hallyn: You didn't used to provide kvm from all the other arches.
<hallyn> hm.  and i don't need to, as it was ever just a metapackage
<hallyn> infinity: so i should be able to drop that, and keep the non-versioned B/R in qemu-system-* ?
<infinity> hallyn: No, those should be versioned as well.
<hallyn> ok
<infinity> Replaces should, as a general rule, always be versioned, except in the special case of P/C/R.
<hallyn> qemu-system-x86 did Provides: kvm in 1.3.0
<infinity> Yeah, but none of the others did.
<infinity> So, now qemu-system-x86 conflicts with qemu-system-arm.
<hallyn> right
<hallyn> thanks, will push fix asap
<infinity> hallyn: Before you upload, you might want to test that the new world order still upgrades smoothly from, say, precise.
<infinity> hallyn: Lots of mangling seems to have gone on here, and it was all pretty fragile to start with.
<hallyn> infinity: i've pushed the proposed fix to github.com/hallyn/qemu # de.feb20.ubuntu2 ; will probably not push to archive until monday, after testing
<infinity> hallyn: Sounds good.  britney's preventing the archive from exploding, so it's not urgent.
<hallyn> infinity: testing from precise ...  is there a way to have do-release-upgrade itself look at /mirrors/debian?  Will it automatically do so if it's listed in sources.list?
<hallyn> should i suppose... i was thinking ppas which are disabled, but this should work
<infinity> hallyn: do-release-upgrade is a bit heavy-handed here, I'd just install qemu-kvm in a precise chroot, s/precise/raring/ in sources.list, and try a dist-upgrade. :P
<infinity> hallyn: In fact, if a dist-upgrade works, that also means do-release-upgrade needs no painful quirking, which is a Good Thing.  The less release-upgrader needs to fix, the better.
<hallyn> will try
<Dimensional> Anyone here an official Ubuntu system developer?
<Dimensional> I'm having a question/idea I'd like to discuss.
<SpamapS> Dimensional: quite a few are. But its best to just ask the question and wait for an answer. Note that ubuntu-devel-discuss@lists.ubuntu.com may also be a better place to discuss big questions
<Dimensional> Hmm.
<cjwatson> zul: Done
<cjwatson> Er, in theory, change-override seems to be taking a while ...
<cjwatson> Ah, there it goes
<Dimensional> The question involves the fact that each install CD is now too big to be on CD's, and barely take up a DVD themselves. The idea is that if possibly done right, one could package both images into the same DVD, and use some ISO bootloader to select which one to boot into. If it was integrated, it could make essentially a Universal Ubuntu Install DVD.
<Dimensional> Installing 32 or 64 bit systems.
<Dimensional> I now realize that's less of a question and just an idea.
<cjwatson> It's been suggested but isn't high up the list at the moment
<Dimensional> oh
<Dimensional> Cool
<cjwatson> I think last time it came up our DVDs were >half the limit so it didn't make sense
<Dimensional> ?
<cjwatson> Ages ago
<cjwatson> On the other hand - it would mean having people download considerably more than they need, and bandwidth still isn't so plentiful that that's ignorable - it's not a completely obvious trade-off
 * Dimensional was able to do it, but wishes it could be more integrated. Something that could also detech which hardware architecture the disc was running on, and if it saw it was a 63-bit, would give a boot option to which architecture to install on.
<Dimensional> It's an obvious tradeoff when you account for the fact that you'd be burning 2 DVDs instead of one. They might be cheap, but not that cheap.
<cjwatson> Eh, only if you need both!
<sarnold> 63 bit? :) is that a new IBM machine similar to their 31-bit z/OS? :)
<Dimensional> 64*
<Dimensional> I shall make a new system. It shall have a 2-bit architecture, because I can't stand 1-bit of competition. :P
<cjwatson> I suspect that for me the bandwidth cost of an extra few hundred megabytes may actually exceed the cost of a blank DVD - would have to sit down and do the sums
<sarnold> I'd personally prefer something be thrown overboard and drop back to CD-R size. I've got another 20 or so CD-Rs from a 50-pacl bought ages ago, and never had a need to buy any writable DVDs before..
<cjwatson> In any case, I can see the point of it a bit more now that UEFI has meant we don't have a common image that boots on all 32-bit machines
<sarnold> Dimensional: lol
<clue_h> I think it would be good for folks with a couple of machines and want to install a minimal on one and full on the other etc. But people prefer the different options they have for the ISOs they download
<cjwatson> sarnold: really, really unlikely to happen, I'm afraid - we fought that battle for many years and eventually lost
<sarnold> cjwatson: I figured it wasn't given up lightly :(
<Dimensional> ok
 * Dimensional is a little lost.
<cjwatson> s/boots on all 32-bit machines/boots on all x86 machines/ in my last-but-one comment
<zul> cjwatson: thanks
<Dimensional> ok
<Dimensional> Hmm.
<Dimensional> So you were meaning of combining the DVD images and using a UEFI bootloader?
 * Dimensional is still lost, he might have found the map.
<Dimensional> no. Not a map.
<Dimensional> With UEFI, the possibility of putting them both onto a single DVD is more likely?
<cjwatson> Dimensional: No, what I mean is that the advent of widespread UEFI means that the 32-bit image is no longer a sane default that works on most systems; when we had that sane default there was little reason to bother with a "universal" image
<Dimensional> ah
<cjwatson> So it perhaps makes it more likely that we might do this; but of the people who work on this kind of thing their plates are all very full for a good while to come already
<Dimensional> kk
<cjwatson> It's worth us thinking about again, though, I agree; thanks
<infinity> cjwatson: It's probably worth just revisiting what the "default" image is again, too.  New 32-bit systems are vanishingly rare (or nonexistent?)
<infinity> cjwatson: Last time it came up, Atom was the killer, but new Atoms are x86_64.
<infinity> (Personally, I'd still like to see the default be an amd64 kernel, x32 userspace, and i386 multiarch for binary blob support, but we're years away from that being viable, I suspect)
<cjwatson> amd64 kernel and i386 userspace is viable, though, and is more power-efficient IIRC
<cjwatson> At least more memory-efficient
 * infinity nods.
<infinity> It can lose out on performance, due to the LCD being rather low.
<cjwatson> LCD?
<infinity> (And the lack of registers)
<cjwatson> Oh, right
<cjwatson> Yeah
<infinity> Lowest Common Denominator.
<Dimensional> I can see some day that 32 bit systems will be gone, and we'll remove the 'long' flag from the CPU and just have it default to 64. So the new 'long' flag would refer to a 128-bit architecture.
<infinity> 128-bit computing is probably much further out than people think (or never going to happen in general purpose CPUs).
<sarnold> hunh. my largest process only has a vsz of 2042M...
<cjwatson> I confidently predict that nobody will ever be silly enough to remove the "long" flag
<infinity> Eventually, we hit the brick wall of how small you can make parts.
<cjwatson> Not while remaining otherwise architecturally compatible, at any rate
<infinity> Trinary quantum computing could change all that, but that changes EVERYTHING anyway, not just address space. :P
<infinity> And also hurts my brain to start thinking in a different number system.
<Dimensional> yup
<Dimensional> heh
 * Dimensional already thought about another numbering system and ways of implimentation. Head still hurts, but so worth it.
<dobey> infinity: don't think of it as a different number system. just think of all the bits being both on and off at the same time :)
<infinity> dobey: Thanks.  That didn't give me an aneurysm at all.
<Dimensional> For me, I had thought it over more like directions. For hard drives, in order to tell if something is a 1 or a 0, it checks two bits on the hardware. Two magnetic pieces. If their polarity is the same, it's a 0. If they are different, then it's a 1. So what if we worked on increasing the accuracy of the head and instead read it with directions. Both left, 0. one left, one right, 1. Both right, 2
<melodie> hi
<Dimensional> hello
<dobey> infinity: haha. it's ok though. you're still alive, even if you're dead. all the bits are zombies!
<infinity> dobey: http://www.youtube.com/watch?v=ueBZuZAoglE
<dobey> lol
<hallyn> infinity: well dist-upgrade from precise mostly went fine (no complaints/refusals from qemu itself), but my archive seems to have ended up somewhat b0rked, I get things like
<hallyn> E: Internal Error, No file name for libblkid1
<infinity> hallyn: Hrm.  Can you reproduce that?  I'd love a solid reproducer for that, so I can hunt it down.
<hallyn> infinity: i assume so, but as my victim box was already running precise I first tested on the bare metal.  gotta frst reinstall and set up some containers to test in.
<infinity> Ahh.
<hallyn> (well i guess i can let the archive rot, and use a container anyway)
<hallyn> (trying that for the sake of time)
<hallyn> infinity: i can definately reproduce it with the new qemu packages, let me try without them
<hallyn> i think it's a bug in how i make my local mirror
<hallyn> well i dunno, it only does it when i start from precise, follow https://wiki.ubuntu.com/SergeHallyn_localrepo and actually put the new qemu debs into the local mirror, sed -i 's/precise/raring/' sources.list, and update/dist-upgrade...
<hallyn> so it almost seems like it insists that deps for the pkgs in local mirror must also be in the local mirror
 * hallyn out
#ubuntu-devel 2013-02-23
<lifeless> cjwatson: So I have a puzzler; grub2 (quantal), 3TB drives, GPT, ef02 + mdraid 1.2 metadata, lvm on that - grub2 doesn't seem to see the md volume (ls doesn't show anything other than (hd*,gpt*) items.
<lifeless> cjwatson: AFAICT it *should* all work, the raid is raid6 left symmetric, the diskfilter,mdraid1x,raid6rec drivers are in the core image.
<lifeless> cjwatson: I would appreciate some pointers on how to pinpoint why its not working; I don't know if its PEBKAC or a bug - should I file a bug ?
<Dimensional> hmm
<Bluefoxicy> I guess Chromium was destroying my drive.
<Bluefoxicy> iotop said "[jbd2/sdb1-8] was eating 80% of whatever it's measuring
<Bluefoxicy> while my drive is cranking and cranking loudly by itself
<Bluefoxicy> so I started killing things until it stopped.
<Bluefoxicy> This happens sometimes.  The system just decides to do something that hammers a spinning drive, with no explanation.  :|  Don't know if that's a bug or not.
<lifeless> blktrace will let you track more details about it down
<Bluefoxicy> ah ok
<psusi> lifeless, your bios is limited to 32 bit lbas?  what does ls -l show the size to be at the grub prompt?
<lifeless> psusi: BIOS shows 3TB in its config, will check ls -l and report back.
<lifeless> psusi: 1565563759 sectors
<lifeless> psusi: at 512 byte sectors I make that to be 746G which is very bogus, and at 4K (the native size), 6TB, which would also be wrong.
<cjwatson> lifeless: perhaps if you can manage to dump enough bits of the disk that I could reconstruct it in a test environment, then a bug would be handy
<lifeless> cjwatson: I'll try and trigger it in qemu then
<cjwatson> you're right that in principle that assembly should work
<cjwatson> debugging this sort of thing by teleoperation takes eons though :)
<cjwatson> ideally grub-probe/grub-fstest would reproduce it somehow; if not it would involve an image built with --debug-image=all (or less verbose) and then staring at the output for a while ...
<lifeless> cjwatson: psusi suggests that the BIOS may be failing to honour > 2TB LBA BIOS int13h (or whatever the interface is these days) calls
<lifeless> cjwatson: ls -l in a grub image on a usb stick does return an odd sector count - doesn't match disk size for either 512 or 4K sector sizes
<lifeless> cjwatson: anyhow, I'll fiddle round a few times and see if I can make a reproducable emulated setup
<lifeless> cjwatson: how does one use grub-fstest
<cjwatson> it's possible, but the 1.2 mdadm metadata lives at the start of the device ...
<cjwatson> start with grub-probe, grub-fstest is less interesting most of the time
<cjwatson> and I can never remember its interface :)
<lifeless> heh :)
<lifeless> so grub-probe returns the (AFAIK) correct list of modules - mdraid1x, raid6rec, ext2, diskfilter, part_gpt
<lifeless> I think it returns lvm too, I can double check
<lifeless> sudo grub-probe -t abstraction /boot/grub/
<lifeless> diskfilter mdraid1x raid6rec lvm
<lifeless> ext2 from the fs probe
<cjwatson> which indeed suggests that it's understood the device well enough to parse the fs
<lifeless> while the array was rebuiling that would fail
<lifeless> I saw a bug report in debian about that though
<cjwatson> anyway, sorry, I have to go and do family stuff - like I say if you want me to debug it it's probably better done asynchronously by way of dumps of disk metadata
<lifeless> yeah
<lifeless> I'm not sure what disk data you want though.
<lifeless> e.g. first <x bytes> of the drive + each partition ?
<cjwatson> where x is say 2^20, yeah
<cjwatson> that's usually enough
<lifeless> ok, I'll file a bug and arrange that
<cjwatson> ta
<lifeless> hmm, that may pickup some user data too
<lifeless> I'll make it a private bug i think, though I will eyeball it for personal stuff.
<cjwatson> well, the md data's fairly close to the start.  64KB is probably enough
<lifeless> ok; if you need more I can add that later
<lifeless> I will probably file it tomorrow - thanks for the chat.
<jtaylor> is it intentional that phonon-backend-gstreamer and libphonon-dev are not coinstallable?
<jtaylor> seems somewhat weird
<jtaylor> ok seems intentional phonon-backend-null has Conflicts: phonon-backend
<jtaylor> weird
<jtaylor> so how to fix pyside now
<hyperair> when should an arch: all package be marked as m-a: allowed rather than foreign?
<JanC> slangasek / wookey / lool : ^^^ sounds like a question one of you can best answer (as you were involved in creating the multiarch spec :) )
<shadeslayer> is there a channel for ubuntu touch development?
<shadeslayer> I keep getting : http://paste.ubuntu.com/5559201/
<JanC> shadeslayer: there is #ubuntu-touch & #ubuntu-phone
<shadeslayer> ack
<slangasek> hyperair, JanC: when it's a package like 'python', which exists as an abstraction over python2.x which itself provides both architecture-dependent (extensions) and architecture-independent (interpreter) interfaces
<jbicha> I believe uploads are broken, I mentioned it on #launchpad but it's the weekend and SCALE and everything https://answers.launchpad.net/launchpad/+question/222660
<tumbleweed> uploads are overrated :)
<elmo> jbicha: try now, please?
<jbicha> elmo: sftp uploads don't seem any different but I think ftp uploads are working now
#ubuntu-devel 2013-02-24
<xxiao> i can do python setup.py fine on x86, but it always gave me 'illegal instructions' on ppc, am I missing something on python build env?
<Chipzz> logout
<Chipzz> *facepalm* my bad, ignore pls :P
<infinity> xxiao: If you can sort out what the illegal insn is... Python could be miscompiled (perhaps has AltiVec enabled when it shouldn't)
<infinity> xxiao: All our buildds support AltiVec, so we don't catch that in production when it slips in. :/
<xxiao> infinity: on this particular chip i actually had altivec
<xxiao> yes i'm trying to chase it down
<infinity> xxiao: Oh, kay.  I knew some of the fsl chips BenC was working with didn't have Altivec, so that was my shot in the dark.
<infinity> xxiao: Seems unlikely that python is just plain fundamentally broken on PPC, or it would break a huge number of builds in the distro.
<xxiao> so far i had no idea on how to debug python setup.py breakage, googling
<xxiao> i wrote a simple setup.py and it worked
<xxiao> so probably some 'import' caused this trouble
<xxiao> i bootstrapped the rootfs from 12.10 ubunut-core for ppc
<xxiao> the kernel is 64bit
<xxiao> the python setup.py died immediately, i.e. even 'python setup.py help' will not run
<xxiao> from sphinx.setup_command import BuildDoc Illegal instruction
<xxiao> seems like the illegal instruction has something to do with BuildDoc and sphinx
<xxiao> maybe I'm missing some sphinx pkgs?
<xxiao> everytime i saw documentation related errors from debian/ubuntu it scares me
<xxiao> now I can reproduct this easily: put one liner to a python script:
<xxiao> from sphinx.setup_command import BuildDoc
<xxiao> then run it, it will illegal instruction
<xxiao> s/reproduct/reproduce/
<xxiao> ahh...i could not run sphinx at all, "sphinx-quickstart' will crash on ppc right away
<infinity> xxiao: Which version of python-sphinx is that?  The one from quantal or raring?
<xxiao> quantal
<infinity> Although, hrm.  Can't be sphinx's fault, it's arch:all.
 * infinity spins up a PPC machine to test this.
<xxiao> thanks
<infinity> xxiao: So, you say that 'sphinx-quickstart' just crashes instantly for you?
<infinity> xxiao: Works fine on my POWER5 here, on both raring and quantal.
<infinity> xxiao: http://paste.ubuntu.com/5560511/
<xxiao> correct, it crashes on my t4240 box
<infinity> Or do I need to fill in some values, does it crash later?
<infinity> Hrm, no, seemed to go all the way through fine.
<xxiao> http://paste.ubuntu.com/5560515/
<infinity> Well, your kernel seems to be living in the distant past, but that's probably not the issue.
<xxiao> we're upgrading 3.0 to 3.8 these days, will math-emulation matter?
<infinity> Possibly.  BenC probably knows the answer to that better than I do.
<infinity> I'm really unfamiliar with the fsl cores.
<xxiao> it seems t4240's FPU has one special instruction that diffs from power5
<infinity> My house is full of old Motorola cores, and new IBM ones.
<xxiao> i c, will talk with BenC then
<xxiao> meanwhile I will try math-emu
<xxiao> thanks for the help
<infinity> Let me try this on an old PPC750
<xxiao> I assume you have math-emu on?
<infinity> I have... Whatever our distro kernels have.
<xxiao> i'm bulding kernel with math-emu
<xxiao> had to do this with yocto, which means 30 minutes to get a clean build, sigh
<BenC> xxiao: Shouldn't matter
<BenC> xxiao: You're going to be in Austin next weekend, right?
<xxiao> BenC: yes
<BenC> Flying out there tomorrow
<xxiao> that's early
<xxiao> but...welcome to Austin
<BenC> Going to Dallas on Monday (Servergy office) and coming back to Austin later on in the week
<xxiao> whenever i saw doc-related crash, i thought about fpu, which is troublesome for fsl chips
<infinity> BenC: Want to try to sort out this illegal insn issue xxiao is seeing?  I can't reproduce here, and I don't have the right hardware to dig deeper.
<xxiao> we will have weeklies with servergy
<BenC> just cheaper to round trip to Austin (and drive to/from Dallas) rather than make a 3-point trip
<BenC> infinity, xxiao: Can you give me a repro case?
<infinity> BenC: Install python-sphinx, and run sphinx-quickstart
<infinity> BenC: Possibly quantal-specific.
<infinity> xxiao: Did you try on raring?
<xxiao> infinity: not yet
<xxiao> i will try it on raring tomorrow
<infinity> BenC: Can't reproduce on any of the IBM cores I throw it at.
<BenC> infinity: should crash on start?
<infinity> (Well, I'm still debootstrapping to test on my 750, but I imagine it'll be fine)
<xxiao> BenC: or one liner python : from sphinx.setup_command import BuildDoc will trigger it
<BenC> raring doesn't seem to show it
<infinity> BenC: Crashes at startup, yeah.
<BenC> On e500mc that is
<infinity> BenC: http://paste.ubuntu.com/5560515/
<BenC> Checking quantal
<infinity> BenC: Then again, I'm willing to blame xxiao's sketchy kernel there, too. ;)
<BenC> xxiao: what does gdb show as the illegal instruction?
<xxiao> hold on
<BenC> Doesn't crash on e500mc on quantal
<infinity> Works fine on a 15-year-old PPC750 too.
<xxiao> crappy t4240 then
<xxiao> sphinx* is all pythin scripts, don't know how to gdb the instruction
<xxiao> it happens when "from sphinx.something import somefunc"
<BenC> xxiao: gdb python
<BenC> xxiao: set args -f sphinx-quickstart
<xxiao> http://paste.ubuntu.com/5560553/
<infinity> *blink(
<infinity> Under gdb, I get a SIGILL.
<infinity> Double-U Tee Eff.
<xxiao> __sqrt_finite ()
<xxiao> I KNEW it!
<xxiao> last time a floating related PHP bug on ppc haunted me for two days
<xxiao> i ended up using integer to work around that, instead of compiling all those php stuff from source
<infinity> xxiao: Is it dying in OPENSSL_cpuid_setup() for you, or elsewhere?
<xxiao> the pastebin is all I saw
<xxiao> why is openssl involved here, curious
<infinity> Oh, mine's a false alarm.
<infinity> OPENSSL_cpuid_setup just can't trap SIGILL when run under gdb.
<infinity> xxiao: Nevermind me, I'm just being a doofus.
<infinity> xxiao: Your crash is elsewhere, and more interesting. :P
<infinity> xxiao: disassemble 0x0fe9aa94
<xxiao> http://paste.ubuntu.com/5560579/
<Bluefoxicy> ffs I need to replace the wall in this room with a big white board.
<xxiao> BenC: math-emu seems helped
<xxiao> infinity: with math-emu now it's ok
<xxiao> is there nodejs for ppc?
<BenC> xxiao: nopeâ¦v8 needs a lot of porting for ppc
<infinity> Yeah. :/
<infinity> There's a lot of v8-using stuff out there these days too.
<xxiao> BenC: i'm 'recommending" freescale to become openstack member asap
<BenC> xxiao: We were going to bring up v8 with Freescale this week :)
<infinity> BenC: I stumbled on a v8/ppc "port" on github a while back, but I suspect it stalled before it ever really got started.
<xxiao> the openstack guys mandated nodejs for its dashboard, that kills ppc/mips
<BenC> infinity: It's completely empty from > 1 year ago
<infinity> BenC: I'd love if someone just wrote a *&%! generic C implementation of v8, to be honest.
<infinity> BenC: Sure, it might be slow, but at least it would work everywhere.
<BenC> infinity: amen...
<infinity> xxiao: There's a MIPS v8 port that actually works, AFAIK, it's just not upstream.
<infinity> xxiao: But yeah, nothing for PPC.
<BenC> xxiao: That's fantasticâ¦openstack is right where we want to position CTS-1000 hardware
<infinity> BenC: If you can talk anyone into putting resources into v8/ppc, that'd be awesome.  If you can talk anyone into generic C, I won't complain. :P
<BenC> infinity: I have a feeling I'll be buying lots of jaeger bombs this weekâ¦let's see if it gets things moving
 * infinity can't help but think this is the sort of thing IBM would have thrown money/people at 10 years ago, but trying to convince them of it today would be hard.
<infinity> But perhaps worth asking benh, on the off chance they've been doing something there and just not been vocal.
<xxiao> ok lxc/12.10 is up
<xxiao> time to tie it with openstack via cli, as no dashboard can run without nodejs
<Bluefoxicy> infinity:  no way, Websphere is infinitely superior to nodejs, and you should be using it instead.  Ask IBM.
<infinity> Bluefoxicy: v8's embedded in a lot of products other than nodejs.  Lacking the port sucks period.
<Bluefoxicy> infinity:  Also, MySQL sucks terribly, but if you need something better there's this database called Oracle that the folks who currently control MySQL would be happy to help you deploy...
<infinity> (And lacking a generic implementation sucks for new arches)
<erickLee> hi
<BenC> xxiao: openstack-dashboard works for me
<erickLee> can anyone tell me what is the safe package to attempt modifications?
<xxiao> http://paste.ubuntu.com/5560653/
<BenC> Although, I think I used it on x86
<xxiao> what the hack, it takes 2 minutes for lxc to get a login prompt
<Bluefoxicy> infinity:  I suffered major stage 12 burnout recently and have come out incredibly, terribly critical and horrible somehow.  I make no excuses or apologies for this, but keep your eyes peeled for cynicism.
<xxiao> BenC: which openstack version? they mandated nodejs for folsom
<xxiao> if you're doing Essex it might be fine
<BenC> xxiao: I don't know the versions, but that's from raring
<xxiao> BenC: hmm need try that then
<xxiao> BenC: i'm building the whole thing from source, maybe I should do deb install instead
<BenC> xxiao: Might save you some time :)
<xxiao> build it from source is easy to hack in lxc support, which is not officially supported
<infinity> nova-compute-lxc is packaged.
<infinity> You shouldn't need to build from source for that.
<xxiao> yeah will try the package install tomorrow
<infinity> It's how we currently do openstack on ARM, due to the lack of paravirt solutions there.
<xxiao> i spent the whole day to get it fully built from devstack, just missing nodejs
<vibhav> You can get away with misaligned access on x86, right?
<xxiao> not sure how ubuntu bypassed that
<infinity> vibhav: Yes, but don't.
 * vibhav grumbles 
<infinity> vibhav: For two reasons.  (a) it's bad practice that creates unportable code and (b) it's slower, cause you waste cycles on fixups.
<vibhav> infinity: Indeed. Thoggen had failed to build on arm for this reason
<vibhav> And I was finding ways to fix it
<xxiao> BenC: who can I ask further on openstack/raring/ppc?
<xxiao> esp the openstack version and nodejs dependency
<lifeless> xxiao: whats wrong with nodejs ?
<BenC> xxiao: If there was a nodejs dep, I would not be able to install it :)
<BenC> lifeless: it doesn't run on ppc
<BenC> xxiao: *wouldn't
<BenC> err, had it right I guess
<xxiao> ok will try install from pkgs tomorrow
<xxiao> http://packages.ubuntu.com/quantal/python-django-horizon shows no nodejs
<xxiao> http://changelogs.ubuntu.com/changelogs/pool/main/h/horizon/horizon_2012.2-0ubuntu2/changelog
<xxiao> Drop node-less dependency (LP: #1024326)
<ubottu> Launchpad bug 1024326 in horizon (Ubuntu Quantal) "node.js is required for access to the dashboard" [High,Fix released] https://launchpad.net/bugs/1024326
<xxiao> that is it I think
<lifeless> BenC: ah; shallow or deep issues do you think ?
<BenC> lifeless: deepâ¦v8 needs to be ported
<BenC> xxiao: right, but it jut means you need nodejs to access it, not to run it, right?
<BenC> I'm wrong, looks like it needs it on the host system
<BenC> xxiao: But it does look like it's fixed in quantal and raring
<lifeless> so the nodejs dep
<xxiao> BenC: yes
<lifeless> is currently just as a compiler for lesscss
<lifeless> so you can run that once per revision on any architecture and then its done.
<xxiao> BenC: basically it tells openstack don't do dynamic compilation, use a pre-built css instead
<xxiao> i'm pulling that into devstack now, will see how it goes
<lifeless> however its likely upstream will want to do much more dynamic things later, so I wouldn't bet on it staying as an indefinite workaround
<xxiao> lifeless: that's why I want to ask freescale to get on openstack paid membership to vote against this tech decision
<xxiao> or port v8/nodejs to ppc
<lifeless> paid membership gets a board position; nodejs is a tech decision that the board doesn't vote on
<xxiao> requires nodejs just for the sake of css seems odd to me
<lifeless> the way to get technical leverage is to contribute
<lifeless> technically
<lifeless> you could write a python LESS compiler
<lifeless> then get the nodejs dep dropped, as long as it has not expanded in scope
<jbicha> hi, could we get a rebuild of cmake, gvfs, and packagekit for the libarchive transition?
<Laney> jbicha: what about all the others?
<infinity> Laney: I'm working on the whole stack right now.
<infinity> Laney: Though cmake might be stuck on an FTBFS in the testsuite.  *sigh*
<jbicha> infinity: thanks
 * infinity scratches his head at cmake's newfound hatred for its testsuite.
<xxiao> I was told turning on math-emu is the wrong thing to do, not sure if that's a correct suggestion
<xxiao> infinity: for ppc of  course, if kernel has math-emu off, will the sphinx-quickstart abort?
<xxiao> I would assume ubuntu rootfs is soft-float by default?
<xxiao> BenC: pinh
<xxiao> ping
<infinity> xxiao: Why would you assume Ubuntu is soft-float?
<xxiao> infinity: just guessing, is it?
<infinity> Isn't soft-float on PPC a reasonable new (and incompatible) ABI?
<xxiao> infinity: in my case, ppc rootfs in embedded space is mostly soft-float
<xxiao> esp those e500 chips
<xxiao> if everything is hard float, then why we need math-emu?
<infinity> I'm not familiar with the math-emu you keep talking about.
<infinity> Is this specific to fsl kernels?
<infinity> If so, it's probably trapping instructions that don't exist on your cores.
<xxiao> math-emu is a kernel option that traps floating point instruction if there is no fpu
<wooo>  What is vnode? Is is somewhat similar to inode?
<gkcn> wooo, http://www.linuxquestions.org/questions/linux-kernel-70/difference-between-inode-and-vnode-657954/
#ubuntu-devel 2014-02-17
<edwin> q
<dholbach> good morning
<Unit193> seb128: Hello.  Sorry to bother you again, but is there a chance you can take a look at https://bugs.launchpad.net/bugs/1060543 ?
<ubottu> Launchpad bug 1060543 in software-properties (Ubuntu) "Additional Drivers is not discoverable in Quantal" [Critical,In progress]
<seb128> Unit193, hey, I'm not working on software-properties, maybe try mvo when he's around?
<Unit193> Ah, sorry.  Saw your name on last uploader.  He's been quite busy and normally is on the wrong timezone for me. :P
<seb128> if you have a patch just subscribe ubuntus-sponsors to the bug
<Unit193> seb128: Just a "mockup" of a desktop file.
<mlankhorst> ok so all upgrade bugs from lts to lts are fixed \o/
<brendand> does anyone know of any good information on the file POTFILES.in? what is it used for , and information on the format
<seb128> brendand, did you try man intltool-update?
<brendand> seb128, that's the tool i was looking for, thanks
<seb128> brendand, yw!
<brendand> seb128, sorry - what about the format? does it support globs?
<brendand> seb128, and also types. some of the files i want to translate are qt/qml
<seb128> brendand, not sure about those, I guess so
<seb128> brendand, you should maybe look at some project using similar techs to yours as an example.
<seb128> ?
<seb128> hum
<seb128> the ppc64el seem all on "manual", is that normal?
<infinity> seb128: Yeah, it's temporary.
<infinity> seb128: We're rebootstrapping the entire archive.  Nothing to see here.
<seb128> infinity, does it mean things are sutcked in trusty-proposed until that's resolved?
<brendand> seb128, hmm seems qml apps avoid using POTFILES.in
<infinity> (Should be back to autobuilding in an hour or so)
<brendand> seb128, i guess intltool-update only supports gettext
<infinity> seb128: For a little bit, but not long (see above).
<seb128> brendand, could be, I'm not the best person to ask about that
<seb128> infinity, thanks
<brendand> dpm ? ^
<dpm> brendand, could you give me more context on your question about POTFILES.in?
<brendand> dpm, i'm trying to figure out the best way to set up translations for my c++/qml package
<brendand> dpm, i guessed intltool-update would be best to use, but it seems to not support qml
<brendand> dpm, are there ubuntu touch core apps that have a c++ component?
<Laney> brendand: take a look at ubuntu-system-settings
<dpm> brendand, yes, that or lp:reminders-app or lp:ubuntu-weather-app (the latter has an up-to-date README.translations file that provides more context)
<seb128> Laney, dpm: just for the record I didn't point him to e.g u-s-s because it would be handy to have intltool working, our current setup is inferior in several ways (including the fact that we can't simply update the template by running intltool-update, we need to generate a build tree to run the make command and copy manual back)
<brendand> seb128, i'm not the guy to make that happen though :)
<seb128> well, you were looking at it, who knows, maybe you would have found a way
<brendand> seb128, we're trying to get this package into main so we need translations set up
<dpm> brendand, can you point me to the lp project? I can try to help, but this week is rather full, so unfortunately I can't make any promises
<brendand> dpm: it's in lp:checkbox but in the checkbox-gui directory
<dpm> seb128, yeah, I see it that way too. But I couldn't figure out a way to replicate intltool-update with cmake without calling cmake and make, either :/
<dpm> with qmake it was a bit easier, but still not optimal
<infinity> seb128: compiz and bamf built, were those the ones you were worrying about?
<seb128> infinity, I'm watching the builds, nux and unity still
<seb128> infinity, but yeah, those 2 were part of the unity update
<Laney> seb128: yeah, but I think the problem is that intltool just doesn't support qml at all, let alone ubuntu sdk qml
<Laney> the xgettext call we have encodes 'tr' as a thing to look for
<seb128> Laney, right, I need to look at making our "make pot" at least not output the fullpath in the template, that makes the whole template change every time we run the command
<seb128> dholbach, the cordova binaries are a bit weird, they install their .so in /usr/share ... is that wanted?
<infinity> It's never wanted.
<infinity> Unless those are magical arch-indep libraries.
<seb128> that package is quite hackish, I don't like much
<seb128> but I'm not wanting to fight over details since I don't have a better suggestion/I'm not interested enough into the topic to spend efforts on it
<infinity> If they're not following FHS, that's absolutely a reason to reject.
<seb128> infinity, they are not, but that package is weird, it's basically a "provide files for clicks to copy/embed"
<infinity> Ahh, binaries in /usr/share make sense in that context.  But they still shouldn't overlap between arches, if they currently do.
<seb128> /usr/share/cordova-ubuntu-3.4/www/libcoreplugins.so
<seb128> so yeah, they do
<infinity> Yeah, so no indication of what arch that .so is for...
<seb128> dholbach, can we get that fixed?
<infinity> It's not multi-arch:same, of course, so there's allowed to be overlap.  It just seems like a bit of a messy design.
<seb128> infinity, feel free to accept the binaries from the queue if you are fine with them ;-)
 * seb128 has no strong opinion, as said that package is a bit hackish
<seb128> but if it does the job/unblock people...
<infinity> I'd probably want to talk to the people behind it to get more context before I accepted them.  Which I'm unlikely to do at 4am after working all weekend.
<seb128> infinity, yeah, you should get some sleep!
<seb128> infinity, have a good night
<infinity> seb128: I'll try. :)
<dholbach> seb128, AFAIK (I'm just trying to help the team get things landed): the SDK will download <package>:<arch> from the archive and bundle that the runtime in the click package
<seb128> dholbach, what if you try to dev for e.g i386 and armhf on the same machine?
<seb128> those conflict atm
<dholbach> seb128, AFAIK they're not necessarily required to be installed on the developers machine, but I might be wrong
<seb128> well, they are in the archive, so nothing prevent you to apt-get install them
<dholbach> dbarth and team would be the people to answer this - maybe we should discuss it on https://launchpad.net/bugs/1279814?
<ubottu> Launchpad bug 1279814 in Cordova Ubuntu "[needs-packaging] Get cordova-ubuntu-3.4 into trusty release" [Critical,Fix committed]
<seb128> well, as said before, I'm busy enough with other things and I don't know much about the cordova thing
<dholbach> ok
<seb128> so I'm going to letting infinity a chance to comment on that later on, and if he doesn't I think I'm just going to wave the binaries in
<seb128> they are a bit hackish/wrong but that's not the end of the world imho
<dholbach> thanks seb128, infinity
<seb128> yw
<seb128> do we have any buildd admin around to bump the score of https://launchpad.net/ubuntu/+source/unity/7.1.2+14.04.20131106.1-0ubuntu5/+build/5606463 ?
<cjwatson> done
<seb128> cjwatson, thanks
<cjwatson> (not really here, just going again)
<seb128> (good timing for not being here, thanks again ;-)
<infinity> That really wasn't necessary...
<infinity> seb128: Everything in the release pocket is being rebuilt, there's no particular reason to score any of it up, as we still have all the old binaries.
<cjwatson> oh, that was a release pocket build?
<cjwatson> right, matters not
<cjwatson> *shrug* it'll all churn through anyway
<cjwatson> I expect seb128 actually identified the wrong build from proposed-migration
<seb128> shrug, indeed
<seb128> I wanted https://launchpad.net/ubuntu/+source/unity/7.1.2+14.04.20140214.1-0ubuntu1/+build/5607904
<infinity> The proposed one is dep-waiting for a publisher cycle.
<cjwatson> which is needs-build now and about to start
<infinity> Or, was.
<seb128> I got confused by the lp table lines order and clicked on the wrong version
<cjwatson> everything in -proposed will build before anything in the release pocket
<seb128> cjwatson, infinity: thanks
<seb128> oh, nice
<cjwatson> so actually your request slowed more important things down
<cjwatson> oh well, not by much
<seb128> :-(
<seb128> sorry about that
<infinity> S'ok.  I'm still banking on main being done in just over a day.
<seb128> I cancelled the build of the other version
<cjwatson> you still planning to commandeer more hardware?
<cjwatson> seb128: just leave it please
<infinity> cjwatson: Yeah, but not until Tuesday, when I can get pinky to twiddle some cables.
<infinity> And main will probably be done by then.
<seb128> too late, sorry again :-(
<cjwatson> seb128: rule of thumb for today: don't try to micromanage ppc64el :)
<seb128> yeah, I just learnt that I think
<cjwatson> I've retried that cancelled build for consistency's sake
 * seb128 justs wants that unity in trusty :p
<seb128> anyway, we should be good once the proposed build finish
<seb128> so I'm staying away from builders now
<seb128> thanks again ;-)
<cjwatson> infinity: I'd certainly expect the whole thing to be quicker than the predicted five days
<infinity> cjwatson: I gave myself a lot of padding in my estimates.
<infinity> cjwatson: Years of "5-minute-fix" engineering estimates have taught me some valuable lessons.
<infinity> cjwatson: Of course, it's also feature freeze week, which means everyone and their dog will be vomiting their last two months of pending local changes to every package ever, so that churn will slow us down a tiny bit.
<wgrant> cjwatson, infinity: There's were ~700 buildd-hours of successful builds in the release pocket at the time of the purge, from what I can see.
<infinity> wgrant: So, 3 days on the current setup.  Add a couple for proposed churn, subtract for extra hardware on Tuesday, carry the 1...
<wgrant> Plus the failures, which I'll work out in a moment.
<infinity> Right, well.  I'll set up the other two machines tomorrow "just in case", so they can be lit up as soon as they have a network.
<wgrant> Yep
<infinity> And if we don't need 'em, whatever.  But handy to have them.
<wgrant> Looks like about 950 if we include failures.
<wgrant> Still, not very many days.
<infinity> 4 days, plus an extra for proposed churn, I'd say...
<infinity> Hits my 5 day mark almost on the head.  But 8 more VMs will win the day.
<ogra_> doko_, infinity .... why does libgcc nowadays depend on gcc-4.9 ?
<ogra_> seems a recent change pulled the compiler into the touch image
<infinity> ogra_: It doesn't.
<infinity> ogra_: gcc-4.9-base isn't a compiler.
<infinity> ogra_: You already had gcc-4.8-base
<ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140214.3.changes
<ogra_> ah
<ogra_> why isnt 4.8 not dropped then ?
<ogra_> -not
<infinity> ogra_: libgcc1 is 4.9, but you still have other libs from 4.8 (probably libstdc++6, at least)
<ogra_> hmm, k
<xnox> ogra_: because 4.8 is default for C/C++, whilst 4.9 is default for Go on armhf/arm64/ppc64el
<infinity> ogra_: So, you need both -base packages.  They're tiny, no big deal.
<ogra_> ok
<doko> neither pitti nor jibel online ... and python2.7, python3.3, python3.4 autopkg tests are failing. did the test env change?
<ogra_> they are on oakland iirc
<ogra_> should come online in a while
<seb128> right, QA is in Oakland this week
<infinity> Oh, one more rebuild-related thing: archive admins, please ignore the heck out of component-mismatches for the next few days, it'll be full of lies.
<infinity> cjwatson, doko, seb128 ^
<seb128> infinity, noted, thanks
<brendand> dpm, hello again
<brendand> dpm, all the packages you pointed to seem to involve cmake at some stage
<brendand> dpm, can we avoid introducing cmake into the chain?
<dpm> brendand, you can try with qmake, which for translations was pretty lightweight. Have a look at the weather app, 3 or 4 revisions back from trunk
<dpm> that was before the cmake switch
<jamespage> doko, any ideas? https://launchpadlibrarian.net/166508215/buildlog_ubuntu-trusty-ppc64el.gccgo-go_1.2-0ubuntu5_FAILEDTOBUILD.txt.gz
<jamespage> that upload failed with the same error on armhf, powerpc and ppc64el
<doko> yes, known
<jamespage> doko, ok
<pitti> Good morning
<doko> neither pitti nor jibel online ... and python2.7, python3.3, python3.4 autopkg tests are failing. did the test env change?
<pitti> I just saw
<pitti> I added proxy vars so that tests can talk to the network
<pitti> but apparently that's confusing some things
<seb128> pitti, when did you add them?
<pitti> I wanted to revert that for now, but now I can't build any fresh VMs any more
<shadeslayer> pitti: morning :)
<pitti> it seems the latest cloud-image upload from Feb 14 broke VM building entirely, looking at that now
<pitti> seb128: Feb 11 or so
<seb128> k
<shadeslayer> pitti: so regarding the upgrade tests for Kubuntu + Backports PPA , we have http://bazaar.launchpad.net/~kubuntu-dev/auto-upgrade-testing/auto-upgrade-testing/files/head:/share/profiles/kubuntu-full-backports/
<seb128> I guess the software-properties tests started failing for another reason
<shadeslayer> pitti: which apparently requires a script to be added, wouldn't that be needed in main auto-upgrade-testing?
<pitti> smoser: so since Feb 14 (new cloud-init), ssh connections to the cloud images keep timing out; did you hear any report about this already and already have an idea why?
<shadeslayer> pitti: so, any thoughts?
<pitti> shadeslayer: sorry, stack overflow
<shadeslayer> hah :D
<pitti> tons of IRC scrollback, and I mostly wanted to see whether I can catch smoser before Europe goes EOD
<shadeslayer> pitti: tl;dr http://bazaar.launchpad.net/~kubuntu-dev/auto-upgrade-testing/auto-upgrade-testing/files/head:/share/profiles/ < has some kubuntu profiles, thoughts on getting that merged into auto-upgrade-testing since we have some scripts in there too that can't be added to jibel's branch
<pitti> yes, if we want to run them, we'll merge that; jibel wanted to merge his +junk branch into lp:a-u-t, too
<pitti> doko: so in short, it's on my radar, I'll fix it today
<doko> cool, tanks
<pitti> as soon as I find out what changed in cloud-init and I get working VMs again, I'll fix or revert the proxy settings and retry all failing tests
<pitti> smoser: do the current cloud images (with latest cloud-init) work for you at all? they just hang eternally in qemu for me, with no useful output or possibility of logging in
<shadeslayer> pitti: ack, I'll try and update the branch
<pitti> smoser: last known working image is from Freb 14
<pitti> Feb
<spineau> doko: hello, we've uploaded checkbox 0.17.4 but surprisingly, that didn't trigger any component mismatches, two mir'ed dep are still not in main (bug 1278822 and bug 1277408)
<ubottu> bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [Undecided,Fix committed] https://launchpad.net/bugs/1278822
<ubottu> bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [Undecided,Fix committed] https://launchpad.net/bugs/1277408
<spineau> doko: Ideally we'd like to see both of them in main before Thursday
<pitti> smoser: http://paste.ubuntu.com/6949086/ is the output from ttyS0; this still worked with the very same cloud-init iso until Feb 14; any idea?
<ogra_> pitti, check your serial cable
 * ogra_ grins
<Laney> did anyone notice that gpg-agent has stopped saying which key it's prompting you for?
<xnox> Laney: is it the result of using ssh-agent, instead of gnome-keyring secrets agent?
<Laney> doubt it, this is inside a container
<mapreri> Godd afternoon! I'm wondering why 4.5.0-2 is stuck in proposed https://launchpad.net/ubuntu/+source/insighttoolkit4 ....
<mapreri> (Architecture field in the control file state only "amd64 i386", so builds are ok http://sources.debian.net/src/insighttoolkit4/4.5.0-2/debian/control )
<cjwatson> mapreri: stale library left around in -proposed, looking
<mapreri> cjwatson: great, thank you!
<cjwatson> plastimatch will need to be rebuilt against the new version
<cjwatson> let me quickly do that now
<mapreri> cjwatson: can I know how do you find it? (just to learn something new...)
<cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#insighttoolkit4
<cjwatson> plus experience
<cjwatson> and checkrdepends against an archive mirror to find the reverse-deps of that library in -propsoed
<cjwatson> *-proposed
<mapreri> uh
 * mapreri takes note....
<cjwatson> mapreri: ok, I've uploaded a no-change rebuild of plastimatch and removed the stale libinsighttoolkit4.4/i386 binary from -proposed, so that should clear it up shortly assuming plastimatch builds
<mapreri> cjwatson: I'll check in a few hours, thanks again
<seb128> does anyone know what is missing to make indicator-datetime/unity-control-center migrates?
<seb128> indicator-datetime stopped building unity-control-center-datetime
<seb128>  unity-control-center C,R,P it
<seb128>  so the binary should be NBS and provided by u-c-c
<seb128>  that should be enough no?
<pitti> doko: I re-ran python2.7, that failed many tests, but they don't sound network/proxy related; I'll have a look later after breakfast
<pitti> seb128: so it seems gjs is due to the new version? Error: Requiring GjsPrivate, version none: Typelib file for namespace 'Gtk', version '3.0' not found
<pitti> seb128: sounds like it now grew a missing gir1.2-gtk-3.0 test dep?
<pitti> (or perhaps binary dep, not sure)
<seb128> pitti, looks like
<seb128> darkxst, ^ can you look at that/get it sorted out (since you did that update)
<seb128> is britney supposed to resolve provides?
 * seb128 wonders why it doesn't consider the unity-control-center providing unity-control-center-datetime as valid/enough
<geser> does britney consider those two packages together or each for it's own if it can transition?
<doko> rbasak, could you have a look at the php5 merge?
<seb128> geser, each one it seems
<seb128> Laney, can you hint britney to consider both together?
<Laney> worth a try
<seb128> Laney, thanks
<rbasak> doko: ack.
<Laney> seb128: if it doesn't work I guess you can remove the package and fix the seeds to not pull it in
<seb128> Laney, right, the seed need fixing anyway, but robert_ancell and pitti stacked work, and robert_ancell wants to transition to unity-settings-daemon as well, so I was sort of letting one of them deal with an upload
<Laney> jus' saying, that'll probably help with the migration
<seb128> right
<seb128> let's see at the next run with the hint
<apw> cjwatson, just updated an old clunker, and am getting "diskfilter writes are not supported" with a press any key to continue, from grub2, expected ?
<rbasak> doko: you mean 5.5.9, right? 5.6 is in experimental, but I'm not sure that's a good idea.
<hakermania> Can anyone remind me the process of updating a package from the repos? I want to update Wallch to the version 4.0. I remember that I have to post a bug report somewhere and link to the ppa but I don't clearly remember the process...
<seb128> geser, Laney: britney hint worked ;-)
<Laney> neat
<brendand> dpm, do you have any more detail on how translations work with sdk apps? are the qml files installed with the translations merged in, or does it work some other way?
<dpm> brendand, it's quite similar to e.g. python apps on the desktop. We're using gettext: the qml files load the translations at runtime, and translations are shipped as .mo files in the .click packages, using the same gettext paths as in the desktops, with the difference that they are installed within the click package's installation folders
<dpm> and not in the system
<seb128> pitti, huuuummm
<seb128> pitti, why did gtk migrate to the release pocket while gjs tests are still red?
<seb128> pitti, not that complain about gtk migrating, but that seems buggy
<Laney> adt migration bugs are usually jibel
<pitti> seb128: we had the same problem last week with the libgcc bug
<Laney> he was looking into it iirc
<apw> cjwatson, seems to only affect my 32bit box ... amd64 seems happy
<seb128> jibel, ^
<doko> rbasak, yes, 5.5.9, please not an alpha ;)
<pitti> stgraber: can you leave in the lxc proxy hack? I'm going to revert it from the VMs for now
<pitti> stgraber: it breaks too many things, and e. g. glib and python have different ideas about how these variables work
<stgraber> pitti: ok
<stgraber> pitti: oh and I was just about to ping you about logind, any chance you can get me a PPA build or something of the systemd version we'd like to have for Trusty?
<doko> doko, any hint about https://launchpad.net/ubuntu/+archive/test-rebuild-20140127/+build/5518972 ?  there are about 100 build failures like this one
<pitti> stgraber: I don't currently have any plan of changing what we have in a major way
<doko> rbasak, ^^^
<pitti> stgraber: unless you plan on landing the cgroupmanager and compat API? But even then, upgrading to systemd 208 would be quite a bold step at this point IMHO
<stgraber> pitti: right, I was asking specifically because of that. We have cgmanager working fine now and I'm looking at the next steps.
<pitti> oh, nice
<stgraber> pitti: if you don't plan on updating systemd at this point, then that's fine, I'll just patch logind directly to talk to cgmanager, if you plan on updating systemd, then I should be working on the shim instead.
<pitti> stgraber: yes, agreed
<pitti> stgraber: but TBH I'd leave that to 14.10
<stgraber> well, I can't, we need logind to do the right thing for unprivileged containers in 14.04... so I guess I'll just patch our current logind to talk to cgmanager and look at systemd-shim for 14.10 instead.
<pitti> doko: hm, I get all kinds of failures even locally now ("cannot allocate memory" and other  strange stuff); could that be related to the new glibc?
<stgraber> pitti: I'll try and get the logind patching done this week and will send you a patch or branch so you can sanity check it
<pitti> stgraber: thanks; we are on a sprint this week, so I probably won't have too much bandwidth for large patches; but I guess if that's only against 204 it should not be too big
<stgraber> pitti: right, it should really just be some code to detect cgmanager and do 3 dbus calls (per controller) instead of the matching cgroupfs writes
<cjwatson> apw: won't have much to do with 32-bit, I expect that's because it's trying to write to a /boot/grub/grubenv on RAID or LVM
<cjwatson> stgraber: we still want the shim to work properly for Debian, though, right?
<stgraber> cjwatson: right and for 14.10 (probably) but I'm not going to rush into doing that for 14.04 if our logind doesn't use that API anyway
<apw> cjwatson, ahhh yes this is the machine i got rid of the separate /boot from because it was far toooo small
<cjwatson> apw: it's a relatively harmless error - main side-effect is that the logic to display the boot menu if the previous boot failed won't work
<cjwatson> (also some other side-effects of similar kinds, but that's the one you're most likely to notice)
<apw> cjwatson, yeah and it makes teh boot ugly suddenly, i assume it is something new with the beta?  anyhow this setup is a very odd one i am sure
<cjwatson> dunno about that
<tseliot> stgraber: hi, can you approve bug #1279229 please? I've verified the fix
<ubottu> bug 1279229 in jockey (Ubuntu Precise) "Jockey is unable to check Saucy's xserver ABI" [High,Fix committed] https://launchpad.net/bugs/1279229
<pitti> stgraber: I'm writing a little script which is supposed to run every day to create a fresh container and (almost) atomically replacing the previous one with the new one: http://paste.ubuntu.com/6950426/
<pitti> stgraber: but of course that rips out the underlying FS for any running containers
<pitti> stgraber: are you aware of an existing solution how to provide daily updated containers when they also might be running?
<stgraber> pitti: as in, you have containers using that one as a base with overlayfs or aufs?
<pitti> right, with ephemeral
<pitti> stgraber: I want to use that on the machines that run autopkgtests (arm/ppc64el)
<stgraber> hmm, best guess would be to create your .new, then rsync the rootfs
<pitti> stgraber: I can of coure add some lock file mechanism so that the update job always runs alone
<stgraber> so you'll never end up with an empty underlay, and it should update pretty quickly
<pitti> stgraber: but if I rsync the new rootfs into the old container, doesn't that also create inconsistent file systems?
<stgraber> (rsync -A --numeric-ids --sparse --hard-links --delete trusty.new/rootfs/ trusty/rootfs/)
<stgraber> yeah, it'd be inconsistent for a tiny bit of time
<stgraber> it's a tradeoff, either you have an update script as yours which will only apply to new containers
<pitti> stgraber: ah, and I would never actually move/rename the .new container to the old one, but just always keep the one existing "trusty" container?
<stgraber> or you have something using rsync which will also apply to running containers
<stgraber> right, no reason to copy a new config, fstab, ... those don't change, you only really care about the rootfs
<pitti> stgraber: ack
<pitti> stgraber: many thanks!
<stgraber> jdstrand, doko, infinity: any of you (probably security) has time to review bug 1279048? I'm going to release LXC 1.0 this week and I'd very much like it to use cgmanager by the time I upload it...
<ubottu> bug 1279048 in cgmanager (Ubuntu) "[MIR] cgmanager" [Undecided,New] https://launchpad.net/bugs/1279048
<stgraber> this is also very soon going to become a blocker for landing of logind, libvirt, libcgroup and upstart features, so would be nice if we could have this processed soonish
<doko> pitti, glibc didn't change yet. (I mean glibc-2.19 wasn't yet uploaded)
<pitti> doko: ah, so what triggered the run was only the two ppc64 patches in https://launchpad.net/ubuntu/+source/eglibc/2.18-0ubuntu7
<ogra_> robru, hmm, seems since the last update the G+ webapp on the desktop uses the QML browser ... which just tells me that the browser is unsupported after login
<robru> ogra_, hmmm? my understanding is that all the webapps are supposed to be using the qml container on the desktop. that was a transition that we tried to get in last cycle, but it wasn't ready before feature freeze, so it got delayed until this cycle...
<ogra_> robru, yes, thats why i ping you, because i know you were involved
<ogra_> robru, G+ does definitely not work with that
<robru> oh...
<ogra_> (most likely needs a hacked user agent)
<robru> ogra_, is there a bug filed?
<ogra_> not by me, i just noticed it before i pinged you
<robru> ogra_, ok, please file a bug and assign it to justinmcp
<nvrpunk> anyone know why I am getting:  can't build with source format '3.0 (quilt)'
<ogra_> robru, against what, webapp-contsainer ?
<ogra_> *container
<robru> ogra_, nah, unity-webapps-googleplus
<ogra_> ok
<nvrpunk> nvm, got it
<sergiusens> robru, ogra_ g+ app is owned by xnox
<sergiusens> robru, ogra_ nvm, wrong channel :-) just the click one ;-)
<xnox> sergiusens: well, i've submitted g+ app update, but it got rejected
 * sergiusens checks
<sergiusens> xnox, just add --webappUrlPatterns
<nvrpunk> I dput a new build in my ppa for tahr and it isn't showing up, what should I check?
<nvrpunk> if I try to reupload it says package exists
<nvrpunk> I don't see it in my build queue etc
<infinity> nvrpunk: Which PPA?
<nvrpunk> tim.l.nelson/ppa
<nvrpunk> err
<nvrpunk> tim-l-nelson/ppa
<nvrpunk> nvm
<nvrpunk> i think i got it
<infinity> Mmkay.
<nvrpunk> i think i need to create a new ppa, my first one was for Saucy
<Unit193> You can use the same PPA for trusty, saucy, precise, etc.
<teward> ^ that
<infinity> nvrpunk: What matters is what distribution is in the .changes file.
<infinity> nvrpunk: (Or, alternately, the magic path you dput to, but that's a bit sketchier)
<nvrpunk> Version: 8.6.1-4ubuntu1ppa1
<nvrpunk> Distribution: trusty
<nvrpunk> looks like my versioning and distribution are correct, I just don't see it queued to build etc
<nvrpunk> I dput it an hour ago or so
<nvrpunk> it should show in my "recent activities" correct?
<Ampelbein> nvrpunk: did you upload the same version before and then delete the packages from your ppa?
<nvrpunk> no
<nvrpunk> unless I uploaded 8.6 months ago and forgot, but I don't recall doing that
<nvrpunk> and if I did it was most likely rejected because I had no clue what I was doing months ago
<nvrpunk> yeah, I am at a loss
<nvrpunk> never had this happen
<sem> i have installed gnome-shell package in my kubuntu box ==> unable to login
<sem> this is not nice
<wgrant> nvrpunk: You signed the .changes file with an OpenPGP key that isn't associated with your Launchpad account.
<wgrant> nvrpunk: If you get no email from Launchpad at all, that usually means that there was no signature, or the signature was unable to be verified.
<teward> wgrant: are the PPA uploaders lagged at the moment?
<teward> oops i meant to point to #launchpad but I hate laptop touchpads, they clicked me to here
<teward> >.>
<wgrant> teward: No, no issues.
<wgrant> teward: Are you seeing delays?
<teward> wgrant: yeah, 5 - 10 minute upload gap between amd64 and i386
<teward> was causing bug triage problems for an upstream project, hence why i meant this to go to #launchpad
<teward> it *just* resolved itself
<wgrant> teward: Oh, binary uploads?
<teward> mhm
<teward> wgrant: yeah, the upload of the built binaries
<teward> not the upload of the source package
 * teward was imprecise in his explanation of the issue
<nvrpunk> wgrant: well I imported my keys from my old install ~/.gnupg
<wgrant> A couple of minutes of lag there is normal at high-traffic times. Are you sure it wasn't rather different build times?
<nvrpunk> wgrant: then set my DEBFULLNAME and DEBEMAIL and I assume that should be my old key?
<nvrpunk> if I no longer have my key how do I update that?
<teward> wgrant: since Launchpad doesn't report the actual timestamp of when the build started, both i386 and amd64 show the same build start time
<teward> but you're right the completion was a different issue
<wgrant> nvrpunk: debuild will have told you which key it used. Compare that to the one at https://launchpad.net/~/+editpgpkeys
<wgrant> teward: You can hover over an "X minutes ago" timestamp to get the precise time.
<teward> wgrant: still, it took a while even *after* building to upload, and it seemed uncharacteristically slow
<wgrant> Nothing's been delayed by more than two minutes in several hours.
 * teward shrugs
<teward> wgrant: maybe i'm impatient because the bug is a High priority bug that prevents installation of the nginx PPAs but meh
 * teward yawns
<teward> i shouldn't be doing packaging stuffs while tired >.<
<wgrant> Heh
<nvrpunk> wgrant, thanks I updated my key
<nvrpunk> will that cause them to build now?
<nvrpunk> or will i have to wait on some form of rejection?
<wgrant> nvrpunk: No, you'll need to upload the package again
<nvrpunk> ok lol
<wgrant> All your existing uploads were rejected.
<wgrant> Because the key was unverifiable.
<nvrpunk> Package has already been uploaded to ppa on ppa.launchpad.net
<wgrant> dput -f
<nvrpunk> does that matter?>
<nvrpunk> ok
<nvrpunk> it's like you read my mind :D
<nvrpunk> or saw my failure
<wgrant> The latter, I'm not that good.
<cjwatson> infinity: Holy crap, the rebuild finished main already.
<cjwatson> (Modulo builds in progress.)
<wgrant> Yeah
<wgrant> I didn't believe it, but I can't see that anything went wrong.
<wgrant> I've given back various plausible retries, and they've mostly worked now that the deps are rebuilt.
<wgrant> Still several -O3 failures, though
<cjwatson> Imagine my surprise :-/
<wgrant> All the errors have been the same, but who knows how many miscompilations have gone unwarned :)
<nvrpunk> wgrant: does debuild create binaries?
<wgrant> nvrpunk: It does by default, but you can tell it to build only the source package with -S
<nvrpunk> ok
<wgrant> You must use -S for a Launchpad upload.
<nvrpunk> yes
<nvrpunk> hence why I asked, thanks :)
<cjwatson> wgrant: The firefox and thunderbird failures are a bit suspicious.  I guess some dependency isn't really rebuilt yet
<stgraber> hmm, so who screwed up tha indicator-datetime upload? it wants to pull half of the archive on my machine including unity8
<stgraber> ah, looks like it's failing to find unity-control-center 14.04.3 and so fallbacks to ubuntu-system-settings which in turns pulls all of the touch stuff on my machine
<wgrant> cjwatson: Oh, I didn't look at them since they never worked.
<stgraber> robert_ancell: ping
<wgrant> http://people.canonical.com/~wgrant/ppc64el-prepurge-logs/primary-trusty-ppc64el.html is the pre-purge page, for reference.
<robert_ancell> stgraber, hello
<stgraber> robert_ancell: hey, that last indicator-datetime is trying to pull half of ubuntu touch on my machine, can you please fix ASAP?
<robert_ancell> stgraber, do you have gnome-control-center-datetime installed? Do you normally?
<stgraber> robert_ancell: you put a recommend on unity-control-center >= 14.04.3 but only 14.04.2 exists in the archive, so apt then fallsback to ubuntu-system-settings which in turns pull all of touch on my system
<infinity> cjwatson: That firefox failure is the same one we always had.
<robert_ancell> stgraber, this is edubuntu right?
<stgraber> robert_ancell: I appear to have this package installed, yes, though I certainly didn't install it manually
<wgrant> cjwatson: The firefox failure looks the same as http://people.canonical.com/~wgrant/ppc64el-prepurge-logs/primary-failure-logs/buildlog_ubuntu-trusty-ppc64el.firefox_25.0+build3-0ubuntu0.13.10.1_FAILEDTOBUILD.txt.gz
<cjwatson> oh right, ok
<cjwatson> I didn't check prepurge :)
<stgraber> robert_ancell: nope, that's my laptop, so standard Ubuntu desktop
<robert_ancell> stgraber, ok
<infinity> cjwatson: IBM has patches for it, we're trying to talk them into upstreaming it, so we don't have to maintain it.
<cjwatson> k
<stgraber> robert_ancell: so I guess the question is, are we supposed to have indicator-datetime on our desktops?
<robert_ancell> stgraber, ok, will fix it. Yeah, we're off by one for the version
<robert_ancell> stgraber, yes
<stgraber> ok, good, so yeah, get that down to 14.04.2 and we should be fine
<infinity> cjwatson, wgrant: http://paste.ubuntu.com/6951641/
<infinity> Probably easier than hunting for "failures that matter".
<infinity> binutils is intentionally scored down, and the cross toolchain will need fixing later anyway.
<wgrant> A couple of them are pretty weird
<infinity> modemmanager is fairly obviously -O3 fallout.
<infinity> dbus-test-runner is a mystery to me.
<wgrant> squid3 is -O3 too
<wgrant> And a few others that I forget
<wgrant> I don't see how libecap ever worked.
<infinity> Oh, erm.  It's just symbols out of whack?  Yeah, that's weird.  Have an old log handy?
<wgrant> http://people.canonical.com/~wgrant/ppc64el-prepurge-logs/primary-all-logs/
<wgrant> Beware, the listing is large
<wgrant> http://people.canonical.com/~wgrant/ppc64el-prepurge-logs/primary-all-logs/buildlog_ubuntu-trusty-ppc64el.libecap_0.2.0-1ubuntu3_UPLOADING.txt.gz
<wgrant> Oh
<wgrant> Warnings are there, but non-fatal
<infinity> Okay, so it's just that one symbol that went byebye.
<wgrant> Could be -O3, I suppose
<infinity> I wonder if it disappeared on all arches due to a dep changing.
<infinity> Or possibly -O3...
<wgrant> Given what it is.
<infinity> iterator?  Yeah, maybe.
<infinity> Looks like something that should be ignored anyway.
<infinity> C++ symbols, for the loss.
<infinity> Lemme have a poke at it.
<infinity> So, handily, the only thing that links to it is squid3, which is FTBFS.
<infinity> So, dropping the symbol is pretty much a non-issue even if it was referenced before.
<infinity> But, for kicks, let's see if squid3 uses that symbol on x86...
<wgrant> aptitude's link failure is somewhat disturbing, and not reproducible on amd64
<infinity>   2567: 0000000000175e10   179 FUNC    WEAK   DEFAULT   13 _ZNSs12_S_constructIPcEES
<infinity> Looks optional to me.
<infinity> wgrant: aptitude is probably -O3, but unwinding why makes my head hurt.
<wgrant> Indeed, I can't see what else it could be.
<wgrant> But it's still pretty weird that it breaks like that.
<pitti> infinity: hm, no binutils on ppc64el?
<infinity> pitti: There will be.
<pitti> dpkg-dev is uninstallable on ppc64el apparently
<infinity> wgrant: Testing aptitude now.
<infinity> pitti: I'll get it built in a sec.
<infinity> Actually, I guess it can happen now.
<pitti> infinity: ah, I wondered how I ran those autopkgtests on ppc64 yesterday; I re-bootstrapped the containers today, and it now magically got broken
<pitti> but from what you say it has never existed yet
<infinity> pitti: It existed in the previous incarnation of the archive. :P
<pitti> infinity: ah, so I'm not going mad :)
<infinity> pitti: You might also be doing that.
<pitti> infinity: well, I'm going mad for a lot of other reasons, yes :)
<pitti> (not to the least about killing two of my four ppc64el nodes already..)
<infinity> pitti: Right.  So, I may not have warned everyone.  By the way, I broke ppc64el last night.
<infinity> (Blame RedHat)
<pitti> infinity: with the eglibc upload?
<pitti> infinity: oh, perhaps that's the reason what killed wolfe04..
<infinity> pitti: Yeah.  Dropped all the symbol versions from @2.18 to @2.17, dumped the contents of the archive, and rebuilt the world.
<pitti> hah
<pitti> infinity: so that explains the binutils lobotomy, thanks
<wgrant> So the ppc64el linker is currently a complete hack.
<infinity> COMPLETE HACK.
<infinity> MORE UPPER CASE NEEDED.
<wgrant> It remaps @GLIBC_2.18 to @GLIBC_2.17
<pitti> ah, I've seen a complaint about that symbol earlier on
<wgrant> So we don't have to do a full cross rebootstrap, just rebuild everything with the new eglibc
<infinity> (And a hacked binutils)
<wgrant> Some builds will explode until their build-deps are sane
<wgrant> But it's been reasoanbly well behaved so far.
<infinity> It's all working remarkably well, to be fair.  Not just reasonably well.
<infinity> I'm waiting for the other shoe to drop.
<wgrant> Indeed
<infinity> pitti: Check the diff for 2.18-0ubuntu7 if you want to lose a small portion of your remaining sanity.
<infinity> wgrant: aptitude happy with -O2, uploading hack^Wfix.
<infinity> Well, it passed that link failure anyway.  Watch it fail later, now that I've uploaded.
<wgrant> Heh
<infinity> I need a way to tell soyuz "don't accept the binaries for this upload until I've looked at the build log because the maintainer doesn't believe in failing on testsuite breakages".
 * infinity stares at binutils.
<wgrant> :(
<infinity> Kay, looks good.  Yay.
<infinity> So, binutils in the archive should work fine for linking against any NEW binaries.
<infinity> But will have an incredible sad trying to link against old stuff.
<wgrant> You have a greater version in bootstrap, right?
<infinity> wgrant: Yeahp.
<infinity> wgrant: 3.1 instead of 3
<infinity> wgrant: And doko's agreed not to upload binutils until I say it's cool (or will warn me first so I can reapply my hack)
<infinity> But the way we're going, we probably only have a couple of days left, at most.
<infinity> Assuming I get those other 8 VMs online tomorrow morning.
<infinity> wgrant: And yeah, per our previous discussion, this seems to be the only "clean" way to change optimisation in a dh(1) package:
<infinity> http://launchpadlibrarian.net/166583882/aptitude_0.6.8.2-1ubuntu3_0.6.8.2-1ubuntu4.diff.gz
<wgrant> ew
<wgrant> But yeah, another 8 VMs will have us done by Thursday.
<wgrant> Easily.
<infinity> wgrant: Which is just so many forms of icky.  Must see if we can do something less gross in debhelper or dpkg.
#ubuntu-devel 2014-02-18
<shadeslayer> whom can I poke to mass close bugs?
<ScottK> shadeslayer: Do it yourself with the LP email interface.
<miseria> "ajedrez batalla entre negros y blancos, al final del final el blanco no tendra peones y el negro prevalecera" bienvenidos: http://castroruben.com *temo_a_un_ser_sin_rival*
<WHAT_UP> I don't know if this is more applicable here or in #ubuntu-app-devel, but would anyone know of any problems that would occur were I to add a "queue" command to APT so that "apt-get queue install foo" adds the installation of foo to a queue and installs it once all dpkg locks have been released?
<sarnold> WHAT_UP: #ubuntu-app-devel is more about phone/tablet/etc click packages .. I don't know if this place is best, but better than #ubuntu-app-devel anyway :)
<WHAT_UP> Oh. Hah. Okay, thanks!
<sarnold> WHAT_UP: I like that queue idea, I've got such a short attention span I hate waiting the minute or two for large piles of installs / removals before continuing
<WHAT_UP> Or more than a minute if you make the mistake of installing something like texlive-full over a slow connection :P.
<sarnold> ha! I was swearing at texlive just last week..
<infinity> WHAT_UP: Filing a wishlist bug on apt in Debian would probably be the most appropriate place to discuss it.
<_nedr> Hello ubuntu developers thanks for the great work... Just a request when... you're doing your nautilus replacement it would be nice to have as many options in about:config like in firefox...  this achieves the triple goal of 1. keeping things modular, 2. gives linux power-users freedom, 3. allow you to change something without the community bursting into flames(we can revert most changes  ), 4. allow for great addon ecosystem.. Firefox's addon market-pla
<_nedr> ce (which predates Apple's App Store) is something Ubuntu (as a whole) should really study to try an emulate
<_nedr> utorrent is another great example that everyone should strive to emulate in my opinion... 1. It is high-performance 2. Super-sane defaults with more advanced features ready to present itself when (and only when) you want it, 3. Users get more functionality via Preferences (without being overwhelmed), 4. Has an about:config to tweak those settings which only 0.1% of (very vocal and important ) users would ever need...
<dholbach> good morning
<dholbach> can an archive admin have a look at the list of file names in http://paste.ubuntu.com/6953343/ and see if that resolves the discussion here: https://bugs.launchpad.net/cordova-ubuntu/+bug/1279814/comments/11? - I'd like to be a bit more certain before the next upload :)
<ubottu> Launchpad bug 1279814 in Cordova Ubuntu "[needs-packaging] Get cordova-ubuntu-3.4 into trusty release" [Critical,Fix committed]
<tvoss> doko_, good morning :)
<tvoss> doko_, I encountered an interesting issue when trying to use ThreadSanitizer with gcc in trusty
<xnox> dholbach: that looks wrong.
<xnox> dholbach: only arch independant files are allowed under /usr/share (no tripplets)
<tvoss> doko_, a very simple example fails to link with gcc but works flawlessly with clang, I sent you a stripped down test case by mail
<dholbach> xnox, have you seen the discussion in the bug comment? these files are meant to be embedded, not to be used on the local machine - the .deb is a container
<dholbach> or well, a mechanism so make those files available
<xnox> dholbach: it should be /usr/lib/<tripplet>/ubuntu-html5-platform-3.4/*
<dholbach> <seb128> infinity, they are not, but that package is weird, it's basically a "provide files for clicks to copy/embed"
<dholbach> <infinity> Ahh, binaries in /usr/share make sense in that context. But they still shouldn't overlap between arches, if they currently do.
<dholbach> xnox, ^
<xnox> dholbach: i see, crazy =)
<xnox> dholbach: i will not get involved then =)
<dholbach> xnox, fair enough - thanks for the review anyway :)
<tvoss> xnox, hey there. Could you give me a hand with some symbol files I'm struggling with?
<brendand> dpm, i have another translations question :)
<dpm> go for it :)
<spineau> doko_: Good morning, I've just checked http://people.canonical.com/~ubuntu-archive/component-mismatches.svg, the universe dependencies of checkbox-gui are still not mentioned in this report. As their mir bugs are Fix committed, could it be possible to move them to main? bug 1277408 and bug 1278822
<ubottu> bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [High,Fix committed] https://launchpad.net/bugs/1277408
<ubottu> bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [High,Fix committed] https://launchpad.net/bugs/1278822
<xnox> tvoss: sure, what's up?
<tvoss> xnox, the mp in question is https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols
<tvoss> xnox, the symbols work on amd64, but they fail on 32 bit platforms. I tried tracking down the issue for a few days now, without success
<brendand> dpm, in checkbox we use intltool-merge for the .desktop file. did you manage to do something similar in phone apps?
<dpm> brendand, we generally don't use intltool-merge. In Ubuntu translations from the desktop file are not in the .desktop file, but are rather loaded from the .mo files
<dpm> brendand, the only think you need to worry about is to extract the translations from it and make sure they're in the .pot file, you don't need to merge them afterwards
<brendand> dpm, oh say maybe checkbox is doing it wrong :)
<brendand> dpm, is there an example?
<dpm> brendand, lp:ubuntu-weather-app (see the README.translations file) if you are using cmake. If you're not using cmake, have a look at the same branch about 3 or 4 revisions ago on how to do the same with qmake (README.translations should also give you the info for qmake there)
<brendand> dpm, yeah i saw the code but i'm a bit unsure what the end result is. what does the .desktop file look like?
<dpm> brendand, it should look like a regular desktop file with no translations, and it needs to have the X-Ubuntu-Gettext-Domain key specified and pointing to the translations domain
<brendand> dpm, why does it have no description?
<brendand> dpm, as in the Description: field
<dpm> brendand, descriptions are not shown on the phone. That metadata is stored in the software store
<brendand> dpm, oh i see
<dpm> the descriptions should be translatable in the store, but I still haven't spend time to figure out how to upload translations to the store, I need to talk to beuno about that
<dpm> *spent
<brendand> dpm, do desktop apps also use the same method of translating the desktop file?
<brendand> looks like it
<dpm> brendand, yes, in Ubuntu we always specify the X-Ubuntu-Gettext-Domain and don't have inline translations in the .desktop file. They're loaded at runtime from .mo files, as the rest of the translations in the source code itself
<xnox> tvoss: it looks ok (sans the http://paste.ubuntu.com/6953591/ which is not committed?)
<tvoss> xnox, well, Jenkins complains about missing symbols for 32 bit platforms
<xnox> tvoss: do you have link?
<tvoss> xnox, armhf: https://jenkins.qa.ubuntu.com/job/dbus-cpp-trusty-armhf-ci/98/console
<xnox> tvoss: yeah, it looks like includes are borked a bit. (experimented with a few options). On the other hand per-arch rules files work correctly, so i've instead used symlinks.
<xnox> tvoss: however, it appears (during i386 build) that 32bit symbols are incomplete/different.
<tvoss> xnox, I checked all of the symbols for armhf and the symbols reported as missing are definitely in the file. Even copying them into the toplevel symbols file does not work for me
<xnox> i've proposed this https://code.launchpad.net/~xnox/dbus-cpp/symbols/+merge/206880 and will see what jenkins build says about it at https://code.launchpad.net/~xnox/dbus-cpp/symbols/+merge/206882
<brendand> dpm, apologies. i'm having a hard time understanding how the translation of the desktop file works in ubuntu-weather-app
<brendand> dpm, from what i can see, the 'make pot' target creates a .js file in .build/, and that has a string extracted for translation
<dpm> brendand, exactly
<brendand> dpm, and that does end up in the template, but i don't see how that's then related to the .desktop file itself
<brendand> dpm, #: ../.build/ubuntu-weather-app.desktop.js:1
<brendand> msgid "Weather"
<brendand> msgstr ""
<dpm> brendand, it's similar to what intltool does (not a .js file, but an intermediate .h header). intltool is just a frontend to xgettext: what it does is to convert the .desktop file (which xgettext does not understand) into a format xgettext understands and can parse to extract strings for. You can ignore that intermediate file.
<dpm> so in the case of intltool that intermediate file is a .h file and in our case it's a .js file. With that script in the .pro file we're mimicking what intltool makes, but with qmake.
<dpm> the goal is to extract the translatable string from the .desktop file and put it in the .pot template
<brendand> dpm, but the string in the pot file is marked with the name of the .js file - doesn't that matter?
<dpm> brendand, it does not matter. This is just an aid for translators to know the source file where the translation comes from, it's not used for any build rules or anything. It might be slightly confusing for translators, but most of them will know from experience that it comes from the .desktop file, if they ever need to trace it back
<brendand> dpm, how does it know that particular translation refers to that string though?
<dpm> brendand, gettext does lookup based on the original string. So when it sees "Weather" thrown at it, no matter where it comes from, it returns e.g. "El temps"
<brendand> dpm, is it possible the same string can be translated differently?
<dpm> brendand, yes, you can specify a context, but I don't think we support that in our SDK yet
<brendand> dpm, i guess the domain has something to do with it too
<dpm> brendand, yes, you could do that with two different domains, but I'd advise against it unless you really need it, just to keep things simple and have one domain per app
<brendand> dpm, I notice there were some comments to translators in the weather app pot file
<brendand> dpm, are those added manually?
<dpm> brendand, yes. Generally you put them as a code comment above the line of code you want to provide more context for. These are picked up by xgettext when creating the .pot file and put in there. For core apps we added an argument to the xgettext call that means comments will only be picked up if they are prefixed by the word TRANSLATORS:
<brendand> dpm, ah right i see
<brendand> dpm, that makes sense. so it goes in the code, not directly in the pot file
<dpm> exactly
<tvoss> xnox, seems like Jenkins is a bit unhappy: https://jenkins.qa.ubuntu.com/job/dbus-cpp-trusty-amd64-ci/101/console
<xnox> tvoss: yeah, it doesn't seem to like symlinks with 1.0 source format =(
<infinity> xnox: That's because diff/patch can't represent symlinks...
<infinity> xnox: You can only have symlinks in your Debian delta if they'll land in a tarball (ie: a 3.0 source format, or native)
<tvoss> xnox, so what do I need to do now?
<xnox> infinity: yeah, and dpkg broke force generating packages of a given format - e.g. i can't force 3.0 (quilt) without a tarball and a - version, or 3.0 (native) with a - version.
<infinity> tvoss: Either symlink those files at build time (and clean them appropriately), or use a source format that can represent symlinks in debian/
<infinity> xnox: I reduced the is_native checks to a warning ages ago.
<tvoss> infinity, I'm a bit lost here, sorry.
<infinity> xnox: Not that that's the right answer here anyway.  One should actually pick a sane format. :P
<infinity> xnox: If 1.0 non-native is fine for this package, surely 3.0 (quilt) would be too.
<infinity> xnox: And if they don't want broken out patches, 3.0 (quilt) with --single-debian-patch.
<xnox> infinity: flipped it to 3.0 (native) for now, to get jenkins build going. Not sure what the rest of ci/releasy/machineries expect.
<infinity> 3.0 (quilt) with --single-debian-patch ends up being pretty much the same as 1.0 non-native, but with the added bonus of debian/ being a tarball, not a diff.
<beuno> dpm, they are translatable in the web UI
<infinity> xnox: native is wrong, it has an orig...
<infinity> xnox: Oh, also, we could just fix the buggy symbols usage and let them keep it format 1.0
<tvoss> infinity, I wonder what buggy means, could you help me understand that?
<xnox> infinity: true. it's native during merge-proposals, and then ci-train generate the tarball and makes it non-native....
<infinity> tvoss: So, you probably should drop the symlinks and instead 'echo #include "libdbus-cpp1.1.symbols.32bit"' > libdbus-cpp1.1.symbols.i386
<xnox> infinity: at least the top level version number is native in lp:dbus-cpp ....
<tvoss> infinity, I didn't add the symlinks
<tvoss> infinity, xnox introduced that for testing purposes
<infinity> tvoss: Using includes instead of symlinks also allows you to add arch-specific symbols, should you ever need to.
<infinity> xnox: Oh, it's your fault.  So, see above.
<doko_> stgraber, cgmanager needs a bug subscriber
<xnox> infinity: yeah, that was me. we had (arch=!amd64 !arm64)#include "...symbols.32bit" and that did not do the right thing.
<infinity> xnox: Hrm?  It should DTRT.  Maybe there was a typo. :P
<xnox> infinity: https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols and https://jenkins.qa.ubuntu.com/job/dbus-cpp-trusty-armhf-ci/99/console
<xnox> infinity: http://bazaar.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/view/head:/debian/libdbus-cpp1.1.symbols
<xnox> infinity: (missing ppc64el, but still)
<dpm> beuno, yes, I just have to spend some time to figure out how it works. When you've got a minute, could you comment on bug 1237992 ? Desktop file translations is the last big bit remaining to get a localized UI, and I think at least for the default apps, they should be loaded from the translations already available from the .mo files, but I'd like to hear your thoughts
<ubottu> bug 1237992 in unity-scope-click (Ubuntu) "Need to load translations from .desktop files for click apps" [Medium,Triaged] https://launchpad.net/bugs/1237992
<infinity> xnox: Erm, the reason that didn't work is cause that build was on armhf, and the symbols file didn't reference it.
<infinity> Oh, wait.  !foo.  Nevermind.
<infinity> dpkg-gensymbols and I might want to have a chat.
<xnox> infinity: it appeared to have not done the second #include what's so ever...
<infinity> Oh.  I think I know why that is.  And my suggested fix would work.  But there's another option.
<infinity> So, if you read the manpage, it's not that those *files* get included on the arches you specify.
<infinity> It's that the files all get included, and their SYMBOLS get tagged with the preceding tag.
<infinity> So, you essentially tagged everything twice.
<infinity> Because most of the symbols are in both files.
<infinity> The more common approach is a symbols.common with all the intersecting symbols, and .32-bit and .64-bit would only contain the ones that actually change.
<tvoss> infinity, but that wouldn't explain why all of the symbols from the .32bit file are reported missing
<infinity> tvoss: Because the second include takes precedence, and it all goes a bit wonky.
<tvoss> infinity, I tried adding the "raw" symbols to the top-level .symbols file, too. And that did not work either
<infinity> You start out with (!amd64)foo@ver, and then overwrite it with (amd64)foo@ver, which then means there's no record of that symbol needing to exist on armhf (or, indeed, on anything but amd64).
<infinity> tvoss: Includes override anything previously declared.  If a symbol overlaps, the last declaration wins.
<tvoss> infinity, hmmm, trying to understand if that's a bug then or in accordance with the man page (as I understood it differently)
<infinity> tvoss: That's how the manpage reads, it's just not how people read it.
<infinity> If that makes sense.
<infinity>            As a result, all symbols included from file-to-include will be considered to be tagged
<infinity>            with tag ... tagN by default.
<infinity>        The  symbols  files are read line by line, and include directives are processed as soon as
<infinity>        they are encountered. This means that the content of the included file  can  override  any
<infinity>        content  that  appeared before the include directive
<tvoss> infinity, ack
<infinity> tvoss: So, simple solution is foo.symbols.amd64 == #include "foo.symbols.64-bit", more "correct" solution is foo.symbols is three lines, an include of common symbols, and then two conditional includes of non-overlapping 64/32-bit symbols.
<tvoss> infinity, okay, I will go for the short term solution first to see if jenkins is happy with that
<infinity> tvoss: Oh well, at least I learned something today.  I also read that manpage wrong until just now.
<infinity> tvoss: I think we both read what we wanted it to say, and entirely missed all the words telling us we were wrong. :)
<tvoss> infinity, it's admittedly interesting behavior if the per symbol tags are different, though
<infinity> (Would probably be nice to have an arch-qualified include directive in addition to the 'add these tags to the include' directive)
<rbasak> I think I've inadvertently broken all packages that depend on virtual package phpapi-20121212, provided by php5-common, on i386. How can I find all packages in the archive that depend on this? I've tried "apt-cache rdepends" and "reverse-depends" but these don't see anything. Is this because it's a virtual package that I'm looking for?
<infinity> rbasak: Yeah, reverse-depends doesn't do virtuals.  How did you break it?
<infinity> rbasak: Or do you just mean that the phpapi bumped and you need to do a transition, which is entirely normal?
<rbasak> infinity: yeah, effectively. I fixed LFS support, which caused the generated provided package to change to phpapi-20121212+lfs.
<rbasak> I can see that I need to do a no change rebuild of php5-json to fix the php5 dep8 tests, which should be straightforward.
<infinity> rbasak: Are you sure you fixed it?
<rbasak> I'm wondering what else I need to rebuild it.
<rbasak> infinity: /me checks
<infinity> rbasak: I fixed it literally a decade ago and backed it all out because some of PHP's deps didn't support it properly.
<infinity> rbasak: Searching the changelog for "LFS" is an englightening history lesson.
<infinity> enlightening too.
 * rbasak was unaware of this
<rbasak> It seemed to me that Debian intended to build LFS support, but due to a minor oversight it wasn't happening in debian/rules
<rbasak> Indeed, yes. It seems that LFS was happening in Quantal.
<rbasak> bug 1280044 and the corresponding Debian bug
<ubottu> bug 1280044 in php5 (Ubuntu) "dpkg-buildflags wipes out LFS support in package build" [High,Triaged] https://launchpad.net/bugs/1280044
<rbasak> The reporter thought it was a regression, and the build logs suggest to me that it was.
<infinity> rbasak: Ahh, indeed.
<infinity> rbasak: Kay, carry on with your transition then. :P
<infinity> Seems the LFS history is, indeed, history.
<rbasak> I tested on amd64 only (well that was stupid, for an LFS fix), and the dep8 tests passed fine :-/
<rbasak> infinity: so, back to the original question. How can I detect everything that needs rebuilding?
<infinity> rbasak: grep-dctrl is likely the easiest.
<rbasak> infinity: ah, of course. Thanks!
<infinity> rbasak: Except... You didn't bump the Provides?
<infinity> Version: 5.5.8+dfsg-2ubuntu1
<infinity> Provides: php5-mhash, phpapi-20121212
<rbasak> infinity: it didn't occur to me that it would be a problem, or that there would even be a transition here. So, no. But the packaging seems to have done it for me, which is nice.
<infinity> Version: 5.5.9+dfsg-1ubuntu1
<infinity> Provides: php5-mhash, phpapi-20121212
<rbasak> infinity: it's now phpapi-20121212+lfs
<infinity> Oh, maybe only on 32-bit arches?
<rbasak> infinity: are you looking at i386?
<rbasak> Right
<infinity> Gross.
<rbasak> And this is why I didn't realise there was anything amiss. I tested only am64 :-/
<infinity> rbasak: http://paste.ubuntu.com/6954185/
<infinity> rbasak: Or perhaps more helpful: http://paste.ubuntu.com/6954186/
<rbasak> infinity: thanks! I'd just started downloading Packages files. Didn't think to use /var/lib/apt/lists. Can you tell I don't do this often?
<rbasak> infinity: so, just to check, this all seems sane to you? I should need a no-change rebuild against each of these, right?
<infinity> rbasak: Yeahp, a no-change of all the sources (minus php5, obviously) should do the trick.
<rbasak> infinity: thanks! I appreciate your help.
 * rbasak gets to it
<infinity> rbasak: Double-check that the +lfs thing actually happened on all 32-bit arches before you do.
<rbasak> OK
<rbasak> https://launchpad.net/ubuntu/trusty/armhf/php5-common/5.5.9+dfsg-1ubuntu1 and https://launchpad.net/ubuntu/trusty/powerpc/php5-common/5.5.9+dfsg-1ubuntu1 both list Provides:  phpapi-20121212+lfs so I think that means yes.
<tvoss> xnox, infinity still no luck with: https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/+merge/206359
<tvoss> xnox, infinity that is, with arch-specific symbol files that include .32bit and .64bit, respectively
<infinity> tvoss: shouldn't need the arch qualifiers in there anymore.
<infinity> Also, the lack of trailing newlines are a bit hard to read...
 * infinity fixes those bits up and sees how it fares locally.
<infinity> tvoss: So, this diff on top of your branch works smashingly for me: http://paste.ubuntu.com/6954321/
<tvoss> infinity, pushed here, let's see what jenkins says :)
<tvoss> https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/+merge/206359
<doko_> stgraber, could you merge the changes from ifenslave-2.6 into ifenslave?
<rbasak> What happens to packages that FTBFS in universe that don't end up getting fixed? Are they removed, or do we ship the previously built binaries anyway?
<rbasak> ffmpeg-php failed the rebuild test. My php change will make it uninstallable on i386, but I can see that a no change rebuild will fail on it.
<rbasak> The package is already gone from Debian testing. It seems like a longer term issue that can't easily be fixed: https://bugs.launchpad.net/ubuntu/+source/ffmpeg-php/+bug/1277603
<ubottu> Launchpad bug 1277603 in ffmpeg-php (Ubuntu) "FTBFS against libav 9" [High,New]
<tvoss> infinity, so do you still have a .symbols file around then, or just the arch-specific symbol files?
<tvoss> infinity, https://code.launchpad.net/~thomas-voss/dbus-cpp/force_gcc_4.7_and_symbols/+merge/206359 isn't happy
<infinity> tvoss: I had the symbols file there, but it's removable cruft.
<tvoss> infinity, yeah, I kept it around, too
<infinity> Okay, how the heck is yours different from the testbuild I *just* did on i386?
<tvoss> infinity, I have no idea, except for it is running somewhere in jenkins
<infinity> tvoss: Your branch just built fine on i386 here.  Grr.
<tvoss> infinity, wtf?
<doko> Sweetsha1k, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg please use openjdk-7 in nlpsolver (not 6)
<doko> bdmurray, cjwatson: please can you subscribe the foundations team to bug reports for libconfig-auto-perl and dpkg-cross?
<doko> or slangasek ^^^
<doko> cyphermox_, network-manager recommends wader, which is not in main
<cjwatson> doko: done (cc bdmurray, slangasek)
<brendand> dpm, time to bother you again...
<dpm> brendand, then do bother me with a question, rather than with a ping, and I'll be happy to answer :)
<brendand> dpm, do we always have to update .pot files manually, or is there a way to get launchpad to do it for us?
<brendand> dpm, i would guess LP only updates the .po files (from what I've seen)
<dpm> brendand, in summary, yes, you do have to update the .pot files manually. LP in principle supports updating .pot files for autotools-based projects, but that's a feature that has not seen much usage and I'm not sure about its status tbh
<shadeslayer> pitti: poke
<rbasak> OK this is awkward. php5-common built by src:php5 depends on php5-json, built by src:php-json, which build-depends on php5-cli, which depends on php5-common.
<cjwatson> Yes, that cycle requires manual bootstrapping as I remember
<rbasak> cjwatson: any advice on unsticking this? Should I upload a php5 that does not depend on php5-json, or something?
<cjwatson> No, don't do in the archive
<cjwatson> *do it in ...
<cjwatson> Is this dep-waiting right now, or are you still staging this?
<rbasak> php5 is stuck in -proposed, and I just uploaded (via sponsor) a no change rebuild of php5-json. Only now do I realise the issue (sorry)
<rbasak> So the php-json FTBFS
<shadeslayer> tseliot: pitti regarding proprietary drivers, should I only show a notification if the proprietary drivers are available and recommended, or should I show it regardless of whether or not the proprietary drivers are recommended
<cjwatson> Let me get some lunch and then I'll unstick it.  My recollection is that I just need to temporarily rip out the php5-common -> php5-json dependency in a bootstrap archive.
<cjwatson> (I've done this once before, although it was a while back.)
<rbasak> cjwatson: OK, thanks. I appreciate it. Is this something that I should be able to do in future, or does it require extra stuff I can't do?
<tseliot> shadeslayer: you'll get a recommended driver if more drivers are available for the same devices (such as nvidia-331, nvidia-304)
<shadeslayer> tseliot: right, but shouldn't there be no notification if the driver that is active is also the recommended one
<tseliot> shadeslayer: I guess not. I don't think we use notifications in any case though
<shadeslayer> tseliot: no, this is for Kubuntu :)
<shadeslayer> http://im9.eu/picture/qe2485
<tseliot> shadeslayer: if the driver in use is already the recommended driver, then I guess you can avoid showing a notification
<shadeslayer> *nod*
<shadeslayer> apachelogger: ^^
<bdmurray> cjwatson: thanks
<cjwatson> rbasak: It's only doable by archive admins
<rbasak> OK, thanks.
<stgraber> doko: I'm subscribed to the cgmanager bugs now. I expect the bug triagers of both foundations and server to subscribe too but I can't do that myself as I'm not an admin for those teams.
<stgraber> doko: for ifenslave2.6 => ifenslave, I plan on going through all network packages soon but probably not this week (or if so, after FeatureFreeze)
<dobey> hrmm. who is dealing with firefox these days? ins 27 going into trusty soon?
<seb128> dobey, chrisccoulson is doing work on it but it's not his primary focus
<seb128> dobey, the trusty migration is blocked by ppc issues, infinity said he's wanting to help get them resolved
<seb128> he said he should be able to have a look before beta
<dobey> ah
<dobey> ok
<seb128> dobey, you can get it from trusty-proposed
<dobey> ok
<chrisccoulson> "not my primary focus" is an understatement ;)
<seb128> chrisccoulson, hey ;-)
<roadmr> dholbach: hello! got time for yet another checkbox-related question?
<chrisccoulson> hi seb128 :)
<dholbach> roadmr, not right now - in a call - can you just ask in here and ping me in 30m if you didn't get a reply?
<roadmr> dholbach: will do, I can wait, not in a hurry, here goes
<roadmr> dholbach: ubuntu-desktop Depends: checkbox-qt. I will make checkbox-qt a transitional package, with Depends: checkbox-gui | checkbox-ng (as checkbox-gui doesn't build on powerpc and arm64, we have checkbox-ng as a fallback). This should cause checkbox to "fall off" the CD (no longer needed), and all of checkbox-gui (or checkbox-ng)'s dependencies to be included instead. Does this sound OK and is acceptable?
<xnox> roadmr: surely just the seed need changing. I've asked a few times in the past if checkbox is wanted on the cd or not.
<roadmr> xnox: oh so the seed needs changing? even if checkbox-qt is there already?
<xnox> roadmr: i believe it provides "System Testing" app that one can run manually. Do you still want it?
<xnox> roadmr: yeah, seed change is needed as well. (eventually it will be blocking from removing transitional package post-trusty) and it's best for seeds not to depend on transitional packages =)
<roadmr> xnox: yes, we'd like for it to be there. As seen here, we're replacing the old checkbox-qt with a new checkbox-gui app with an entirely new engine
<xnox> as we don't want cruft empty packages on the CDs ;-)
<xnox> roadmr: cool, so the new name is checkbox-gui?
<roadmr> xnox: sounds reasonable :) so would it be best then to ask for the checkbox-qt dependency in ubuntu-desktop to be replaced by "checkbox-gui | checkbox-ng" ?
<roadmr> xnox: yes, the only caveat is that checkbox-gui doesn't build on powerpc, ppc64el and arm64 (qtdeclarative5 dependencies missing), so the checkbox-ng fallback (it's a text-mode ui to the same engine) is needed so that I don't render ubuntu-desktop uninstallable on those archs :/
<xnox> roadmr: ubuntu-desktop -> is generated from the seed, so once i change it, and ubuntu-desktop meta is refreshed it will have new deps.
<xnox> roadmr: at the moment there is: checkbox-qt in desktop seed, checkbox-cli in server, checkbox-gtk in supported.
<xnox> roadmr: we also don't have ubuntu-desktop images on powerppc ppc64el and arm64, so that's ok.
<roadmr> xnox: ok, so the fallback wouldn't be necessary?
<xnox> roadmr: and the latter two don't have any hardware with graphics cards yet and/or ship with a display ;-)
<xnox> roadmr: yeah, fallback is not needed.
<xnox> roadmr: checkbox-ng to replace checkbox-cli on the server images?
<Laney> I think it'll just skip them on arches it's not available anyway
<roadmr> xnox: checkbox-ng on server images, yes. Just give me a second to confirm that works as intended
<cjwatson> rbasak: php-json/i386 rebootstrapped, doing armhf and powerpc now
<roadmr> xnox: ok, so for desktop seed we'd like checkbox-gui to replace checkbox-qt. The package exists already, and I'll make checkbox-qt a transitional package for upgraders anyway
<xnox> roadmr: sounds good.
<roadmr> xnox: for servers, I need to whip up a metapackage that pulls the cli and a job provider (cli is useless without it). Or would you prefer adding the two packages to the server seed?
<xnox> roadmr: well they are simply shipped in the pool at the moment. so one either does task-select and/or apt-get install checkbox-cli to install them.
<xnox> roadmr: so seeding two on the server image means that $ apt-get install provider-tests checkbox-ng works without network access and just the cd.
<xnox> roadmr: what's that other package that needs seeding?
<roadmr> xnox: checkbox-ng and plainbox-provider-checkbox would be needed in server
<roadmr> xnox: a problem is that people could install checkbox-ng which is useless without the provider, and not realize they also need the provider
<infinity> roadmr: If it's useless without another package, why doesn't it depend on it?
<roadmr> xnox: ^^ the metapackage would help here, it's just a helper for the user to get the right packages
<xnox> infinity: or the otherway around, why not depend on the provider, which depends on the "frontend virtual provides" and on the server iso that will resolve to the only one available - the cli one.
<roadmr> xnox: that's a good idea :)
<roadmr> infinity: that's a good point. checkbox-ng is useless without a provider but a user could conceivably get checkbox-ng and then create their own provider
<infinity> roadmr: A user could concievably install coreutils and their own libc too, but we don't let them do that.
<infinity> roadmr: Package dependencies exist for a reason.
<roadmr> infinity: we had that problem with old checkbox: the engine and the test library (what is now the provider) were completely glued, you couldn't use the core without that bunch of (possibly irrelevant) tests
<infinity> If it's literally useless without another package, it depends on that package, period.
<infinity> If that package is one of a class of packages, then it should "Provides: foo-package-class-lolz", and you should depend on that.
<infinity> So other packages can also provide it.
<infinity> But letting users install a package that is DOA isn't doing anyone favours.
<roadmr> infinity: you're right, let me think how best to organize this for server
<infinity> roadmr: Make it depend on "foo-provider-server-friendly-cli | virtual-package-for-foo-providers", and then explicitly seed the fancy gui one on desktop.
<infinity> roadmr: So desktop installs get the setup you want them too, but people manually installing it get the slim CLI version by default.
<infinity> s/too/to/
<roadmr> infinity: nice solution, thanks!
<bdmurray> stgraber: Could you have a look at bug 1279106 sometime?
<ubottu> bug 1279106 in casper (Ubuntu) "Customized LiveUSB setup cannot handle persistence" [Undecided,New] https://launchpad.net/bugs/1279106
<stgraber> bdmurray: sure, though that won't be very soon
<bdmurray> stgraber: I mention it because it seems to have a patch
<stgraber> bdmurray: yep, I saw that. Unfortunately that bit of the code is annoyingly fragile so I usually need a good test setup and a couple of days to go through the casper bugs.
<stgraber> (as in, it's about the 10th time we get patches for that bug and it always pops up somewhere else ;))
<bdmurray> stgraber: okay, thanks for looking
<u-foka> Can anyone help me debug gnome screensaver? Are there debug symbols for it somewhere?
<seb128> u-foka, there are debugs symbols for most binaries in Ubuntu, see https://wiki.ubuntu.com/DebuggingProgramCrash
<u-foka> seb128, thanks, i didn't know that these were moved to a separate repo :)
<pitti> shadeslayer: it should only show a notification if there are drivers which you can install
<shadeslayer> pitti: even if these drivers are not the "Recommended" ones?
<pitti> shadeslayer: well, in that case you'd usually have more than one available, and one should be the recommended one?
<shadeslayer> pitti: sure, but for eg. what if the recommended driver is radeon and I can also install fglrzx
<shadeslayer> *fglrx
<shadeslayer> should the notification be shown then? ( I already have radeon installed )
<pitti> do we actually do that?
<shadeslayer> yeah :D
<pitti> my gut feeling is "no" then
<rbasak> cjwatson: thanks, I can see i386 and armhf are built now. Are you doing powerpc? I might as well wait before rebuilding the reverse deps, I suppose.
<shadeslayer> pitti: http://im9.eu/picture/g16271
<seb128> bdmurray, ev: hey, do you know if the trusty e.u.c retracers are having issue? several of the recent issues/bugs have no retracing, e.g on the daily view the reports 4-5-7-9
<bdmurray> seb128: I'll have a look
<seb128> bdmurray, thanks
<bdmurray> seb128: daily view for all packages?
<seb128> bdmurray, yes, but restricted to trusty
<seb128> sorry, I forgot to mention
<seb128> bdmurray, e.g https://errors.ubuntu.com/problem/39bbce347f9a5260a0fe549c5b650e5f2ea53b6c
<seb128> or https://errors.ubuntu.com/problem/51867c7babfc41c749a4ed34ba54148f534a28c1
<seb128> https://errors.ubuntu.com/problem/844b51aadb0b772e8277eec836767fbd00c5f46e
<pitti> smoser: did you see my question yesterday wrt. the broken cloud-init images? should I file a bug about that?
<smoser> pitti, i'm sorry . i didn't see your question, but utlemming raised that.
<smoser> i fixed trunk just now
<smoser> i'll upload fix shortly.
<pitti> smoser: in short, all cloud images > feb 14 don't boot
<pitti> smoser: splendid, thanks
<smoser> well, they boto
<smoser> boot fine
<smoser> they just dont read your datasource
<pitti> right, they seme to ignore the seed image
<pitti> and just time out on trying to talk to 169.*
<utlemming> smoser: fwiw, I should probably have a QA story on using the seed image
<pitti> utlemming: well, we kind of do indirectly : http://d-jenkins.ubuntu-ci:8080/job/trusty-adt-setup-testbed/
<pitti> utlemming: it failed since Feb 14
<smoser> pitti, your url isn't any good.
<utlemming> pitti: and we didn't see the failure till now....
<pitti> smoser: yeah, it requires VPN; unfortunately that job isn't published to the public jenkins, jibel is just fixing that
<smoser> well, the images are used enough places that the local datasource gets tested via cloud-image seed reasonably well for regression :)
<smoser> pitti, utlemming just uploaded cloud-init_0.7.5~bzr952-0ubuntu1_source.changes
<pitti> smoser: splendid, thanks; so tomorrow's cloud images should work again
<smoser> yeah. sorry about that.
<smoser> we could do a dep-8 test for this.
<smoser> and fail build.
<smoser> er... wait.
<smoser> could we?
<smoser> can dep-8 test have access to download a cloud-image ?
<roadmr> smoser: hm did that thing with the seed image get reported other than here? (my own report): https://bugs.launchpad.net/cloud-init/+bug/1281305
<ubottu> Launchpad bug 1281305 in cloud-init "NoCloud source broken in Trusty cloud images" [Undecided,New]
<smoser> otherwise we'd have to build a image.
<roadmr> just so I know if my bug is a dupe :)
<smoser> roadmr, no. and i didn't see your bug. so i didn't comment in the changelog with it.
<smoser> but the upload surely should fix it.
<smoser> roadmr, fwiw, your use of genisoimage can be done with 'cloud-localds'
<roadmr> smoser: cool! well as long as it works, we should all be happy :)
<smoser> which is expliciltly for this purpose
<roadmr> smoser: oh cool!
<roadmr> smoser: then maybe the README for that NoCloud source could use updating to mention this
<smoser> it shoudl be.,
<roadmr> smoser: anyway, thanks for fixing this, my virtualization tests will look nicer (i.e. pass) now :D
<smoser> roadmr, if you see cloud images fail for something like this, please feel free/obligated to ping utlemming or I here
<smoser> and if we don't respond, email is fine too for me.
<roadmr> smoser: will do, we run daily tests on them (at least boot/ensure the NoCloud source is read) so I'll definitely do that
<xnox> stgraber: Yeah! latvia is through ;-) let's see how it goes against your other country affiliation game now ;-)
<stgraber> xnox: I have a felling I'm missing some context here :)
<xnox> stgraber: olympics - sochi - hockey
<roadmr> xnox: latvia stands no chance :(
<xnox> stgraber: latvia beat switzerland to go through to quater-finals. Next up against Canada.
<xnox> roadmr: eh, a few years back we beat russia 3-2, that was amazing ;-)
<roadmr> xnox: \o/ ok now I'm a bit more worried
<stgraber> xnox: ah, I must admit having only barely looked at some of the results on Google, been rather busy lately so not much time to follow the olympics ;) though it looks like Switzerland has a rather bad hockey team this year, those scores aren't particularly impressive (compared to past olympics anyway)...
<ochosi> xnox: watching olympics when you should be stressed out of your mind because of FF approaching with light-speed? :}
<roadmr> xnox: since checkbox-gui was added directly to the seed I no longer need checkbox-qt to be a transitional package; in fact it should just go away. If I just delete the debian/control section for it, I'll get "out of date" in proposed-migration, right? will this need admin attention?
<xnox> roadmr: you need transitional package.
<xnox> roadmr: otherwise upgrades will not upgrade from checkbox-qt to checkbox-gui, but instead would just be removed or left around at -qt version.
<xnox> roadmr: however checkbox-qt transitional binary might be published in universe and will not be present on the images.
<roadmr> xnox: ok, I see, so they can't just go away
<roadmr> xnox: thanks, let's fix that then
<roadmr> xnox: haha sorry for the dumb questions. Do dependencies of the package I'm transitioning need the same treatment? I'll make checkbox-qt transitional, it depends on checkbox which should also go away, do I also need checkbox transitional binary?
<xnox> roadmr: transitional binary package should be empty, old-name (e.g. Package: checkbox-qt), depends on the new one (e.g. Depends: checkbox-gui) and description stating that it's transitional package.
<xnox> roadmr: see / search other examples in the archive.
<xnox> roadmr: apt-cache show dummy, brings up a few.
<roadmr> xnox: yay! yes, I have an example here, thanks!
<sarnold> slangasek: hi! we (apparmor upstream team, security team) need some help with library versioning for libapparmor, do you have some free time to help?
<sarnold> slangasek: we have changed some of our interfaces (https://lists.ubuntu.com/archives/apparmor/2013-June/003878.html) -- but the interface in question was more an "internal" interface than public interface, and before the change was broken.
<sarnold> slangasek: here's our library versioning scheme for our 2.8.3 upstream release: http://paste.ubuntu.com/6956459/  and here's our versioning for our 2.8.95 "snapshot" (we want a bit more features in 2.9 still, and the .95 approach was chosen to help keep packaging happy with both rpm and dpkg downstreams)
<sarnold> slangasek: our 2.8.95 library versioning: http://paste.ubuntu.com/6956454/
<sarnold> slangasek: we also added new interfaces to our library in the meantime
<sarnold> slangasek: so, I prepared some new packages for trusty proposed, using the following debian/control file: http://paste.ubuntu.com/6956473/  but upgrading a trusty vm with these packages showed some problems: http://paste.ubuntu.com/6952650/
<jdstrand> sarnold: so, you might have missed it, but I think sbeattie, tyhicks and I thought we'd solve the man page issue by simply moving those to libapparmor-dev
<sarnold> slangasek: what do you think of the library versioning we've selected for the 2.8.95 snapshot? since the apparmor source package wouldn't build the libapparmor1 package any more, I think we'd need to add some Breaks: and Conflicts: to the libapparmor2 packaging, and rebuild dependent packages (lxc, libvirt, dbus, libusermetrics)
<jdstrand> sarnold: we'll need to do the same for apparmor-easyprof and python3-apparmor
<sarnold> jdstrand: yeah, that makes sense, but I figured it'd be best to show the current state of things
<jdstrand> sarnold: so I don't think slangasek needs to comment on those bits
<jdstrand> sure
<jdstrand> thanks
<jdstrand> especially since we're not sure about libapparmor2 vs libapparmor1
<jdstrand> anyhoo, I'll let you handle it :)
<sarnold> jdstrand: yes, even if we decide to go back to libapparmor1, it might still be worth moving the manpage
<pitti> cjwatson, infinity: there doesn't seem to be any test suite for britney at all ATM, is that right?
<pitti> I'm writing an initial one, so that we can recreate bugs like "package promoted although there were failing tests", etc.
<pitti> which hit us hard more than once already
<cjwatson> rbasak: sorry, yeah, I am doing powerpc but I was interrupted by my dad showing up for dinner
<cjwatson> pitti: there's a test suite in Debian, actually, but I've never quite got round to fixing it up to work properly with Ubuntu *guilty face*
<pitti> cjwatson: it wouldn't have the autopkgtest bits anyway, right?
<cjwatson> pitti: http://anonscm.debian.org/gitweb/?p=collab-maint/britney2-tests.git;a=summary
<cjwatson> pitti: no, that's right, but I expect it'd be a useful framework for that
<pitti> so far I just wrote enough code to produce a set of test data files with a convenient API, and got it to run there
<cjwatson> we should definitely have an Ubuntu branch of that
<pitti> cjwatson: nice, thanks for pointing that out
<pitti> ah, that uses static data/ dirs
<slangasek> sarnold: so libapparmor> so if there's an ABI break, it certainly makes sense to bump the soname as you've done here; you wouldn't need both Breaks: and Conflicts: however, though in this case since the manpages are shipped in the runtime library package you either need to fix that by moving them elsewhere (which I recommend), or having Breaks/Replaces on libapparmor1
<sarnold> slangasek: hi slangasek :) yes, moving the manpage seems like the polite thing to do; what's the next step? just the Breaks: line?
<slangasek> sarnold: if the manpages are moved, there is no step 2
<slangasek> (aside from making sure the runtime lib package is appropriately named to match the soname)
<sarnold> slangasek: that seems suspiciously easy :)
<sarnold> slangasek: do we still want / need the no-change rebuilds of the rdepends to update them to libapparmor2?
<doko> bdmurray, the php5-* issues were apparently tranistional. did build after given back
<jdstrand> sarnold: I can answer that. based on slangasek's advice (having libapparmor2, we need to rebuild the other packages to they don't keep the now NBS-libapparmor1 in the archive
<jdstrand> )
<jdstrand> meh, punctuation is not correct, but you get the idea
<cjwatson> rbasak: ok, php-json/powerpc rebootstrapped now as well, should publish soon
<jjohansen> jdstrand: that is just broken, I still maintain things that don't depend on new functionality should not need to be rebuilt against the new library :P
<cjwatson> we aren't going to keep old libraries that no longer have source in the archive
<jjohansen> emphasis on the should, it appears that that isn't reality
<jjohansen> cjwatson: sure
<jdstrand> jjohansen: they probably would work fine, but what I mentioned is an archive thing
<jdstrand> they were built with libapparmor1, so their depends has that, so if we didn't rebuild, libapparmor1 would stay in the archive
<jjohansen> jdstrand: again, I will claim this is wrong and should be fixed in debian packaging
<jjohansen> :P
<seb128> jdstrand, it would stay in the archive but your rebuilds/new version would not get out proposed
<seb128> jdstrand, nowadays britney ensures transitions are completes before migrating things
<seb128> out of proposed
<jdstrand> oh, I didn't know it was that smart. cool
<jdstrand> nice
<jjohansen> slangasek: so a library versioning question. Basically following libtool guideline http://www.gnu.org/software/libtool/manual/libtool.html#Updating-version-info
<jjohansen> the difference between just adding new interfaces is how AGE is set
<jjohansen> - new interfaces, revision = 0, current++, age++
<jjohansen> - break ABI         revision = 0, current++, age=0
<jjohansen> is this correct? Because as I understand it this would result in a new library version for packaging
<doko> tkamppeter, did you track any blockers to convert system-config-printer to python3?
<pitti> I hope you don't mean the UI -- wasn't there a plan to only use the backend from that?
<slangasek> jjohansen: I think that's correct; though if I were you I would try a test build and see what it spits out, I've always thought the libtool library versioning scheme was annoyingly baroque
<jjohansen> slangasek: yeah just looking at the rules, we kept asking is this really correct?
<doko> xnox, trying to compare
<doko> http://people.canonical.com/~ubuntu-archive/transitions/html/python3.4.html
<doko> https://release.debian.org/transitions/html/python3.4.html
#ubuntu-devel 2014-02-19
<doko> any reason for the differences?
<xnox> doko: you should compare with http://people.canonical.com/~ubuntu-archive/transitions/html/html/python3.3-4.html on ubuntu side i think.
<doko> xnox, why two sets of pages?
<xnox> doko: because you asked me for the second one =)
<xnox> doko: we appear to be diverged on the syntax with debian... do you want one that matches theirs?
<doko> no
<doko> just wanted to understand why the first ubuntu url was showing things that seemed odd
<tkamppeter> doko, no, I was completely into mobile printing, see https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind. I did not try to test s-c-p on Python3.
<tkamppeter> pitti, how far has the GNOME tool advanced? Is it ready for replacing s-c-p's GUI? Or should such stuff inm general be better done post-LTS?
<pitti> tkamppeter: I don't know, I'm afraid
<hyperair> has anyone successfully remapped keys using the new /etc/udev/hwdb.d stuff before?
 * hyperair is trying to swap alt and meta on apple keyboards
<infinity> TheMuso: The new speech-dispatcher seems to be pulling $world into main.
<infinity> TheMuso: festival-* deps look to be the culprit.
<dholbach> good morning
<infinity> TheMuso: Oh, that's just because the -dbg package now depends on speech-dispatcher-festival ... We can probably just drop the -dbg out of main to solve that.
<infinity> TheMuso: (Will do that now)
<rbasak> cjwatson: (re: php-json) I see it. Thank you! For next time, apart from some foresight and advance warning, is there anything else I could have done to cause less pain? I understand that an archive admin was needed to unstick it; is there anything I could have done to not get it stuck in the first place?
<tvoss> infinity, around?
<infinity> tvoss: Vaguely.  What's up?
<Saviq> pitti, hey, Q: so there's a bunch of ddebs in http://ddebs.ubuntu.com/pool/universe/u/unity8/ from PPAs, which are not indexed in http://ddebs.ubuntu.com/dists/trusty/universe/binary-armhf/Packages - does apport-retrace deal with that somehow?
<zyga> hey everyone
<tvoss> pitti, around?
<cjwatson> rbasak: It's sometimes possible to bootstrap this kind of thing in a devirt PPA with multiple uploads, and then copy the result in.  It's not always worth it though.
<rbasak> OK, thanks.
<tseliot> didrocks: hi, can you accept jockey into precise-updates please? (bug #1279229)
<ubottu> bug 1279229 in jockey (Ubuntu Precise) "Jockey is unable to check Saucy's xserver ABI" [High,Fix committed] https://launchpad.net/bugs/1279229
<didrocks> tseliot: I'm not part of the SRU team
<tseliot> didrocks: oh, sorry
<brendand> what's the difference between X-GNOME-Gettext-Domain and X-Ubuntu-Gettext-Domain in .desktop files?
<brendand> should i use one (which one) or both?
<brendand> dpm ^
<seb128> brendand, we support both
<brendand> seb128, but i guess gnome doesn't support X-Ubuntu-, so is X-GNOME- 'better' so to speak?
<infinity> brendand: Depends on if you plan to upstream it, but yes, probably.
<seb128> brendand, right, we added the X-Ubuntu one before, then got support accepted by GNOME iirc
<seb128> so yeah, use X-GNOME
 * cjwatson uses http://www.chiark.greenend.org.uk/~sgtatham/mp/ in production code
<cjwatson> Or at least a small amount of it :-)
<smoser> pitti, have you verified cloud image fixed?
<bluesabre> I know it's crunch time around here, but could somebody please review https://bugs.launchpad.net/light-locker-settings/+bug/1281536 ?
<ubottu> Launchpad bug 1281536 in light-locker-settings "[needs-packaging] light-locker-settings" [Wishlist,Confirmed]
<bluesabre> ochosi ^
<bluesabre> Seeking sponsorship for the above package, which will ship in xubuntu 14.04 assuming it can make it to the archive prior to FF
<ochosi> yup, +1 on that ^
<ochosi> would be great to get it in
<hakermania> What is the process of uploading a new version of an app into the repos?
<shadeslayer> tseliot: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1282059
<ubottu> Launchpad bug 1282059 in ubuntu-drivers-common (Ubuntu) "system_device_drivers should check for installedness" [Wishlist,New]
<doko> jtaylor, did you start looking at https://github.com/PyTables/PyTables/pull/311/commits ?
<tseliot> shadeslayer: you might want to ask pitti about that
<shadeslayer> pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-drivers-common/+bug/1282059
<ubottu> Launchpad bug 1282059 in ubuntu-drivers-common (Ubuntu) "system_device_drivers should check for installedness" [Wishlist,New]
<doko> https://launchpadlibrarian.net/166754677/buildlog_ubuntu-trusty-amd64.libpeas_1.8.1-2ubuntu2_FAILEDTOBUILD.txt.gz
<doko> DEB_MAKE_CHECK_TARGET unset, not running checks
<doko> HOME=/build/buildd/libpeas-1.8.1 xvfb-run /usr/bin/make check
<doko> xvfb-run: error: Xvfb failed to start
<doko> make: *** [build/libpeas-1.0-0] Error 1
<doko> mlankhorst, ^^^ any known issues with xvfb?
<mlankhorst> doko: yeah it tends to die when building xorg-server
<mlankhorst> for no good reason
<doko> so give back until the build succeeds?
<mlankhorst> erm say again?
<doko> dholbach, the synced nmap ftbfs on arm64 again
<caribou> I need to tell the duplicity package in Trusty that it breaks deja-dup versions prior to trusty
<caribou> deja-dup in Saucy is 27.3.1-0ubuntu1 and I added a "Breaks: (<= 27.3.1 ) in duplicity's control file but it doesn't seem to work
<caribou> am I missing something ? (I guess I do)
<cjwatson> You need a package name there, not just a version
<cjwatson> And I suspect << is more appropriate than <=
<cjwatson> So Breaks: deja-dup (<< 27.3.1)
<cjwatson> Actually, that's not right either
<cjwatson> I see you want to break the version in saucy, and 27.3.1 is less than 27.3.1-0ubuntu1
<cjwatson> I suggest you find out exactly which version broke, at a finer grain than "prior to trusty" - that is, find out exactly which deja-dup version you need
<caribou> cjwatson: I know, that's the first thing I tested
<caribou> then anything before and including 27.3.1-0ubuntu1
<caribou> cjwatson: ^^
<cjwatson> That's not logically correct
<cjwatson> At some point, deja-dup acquired the fix you need
<cjwatson> It wasn't in anything infinitesimally after 27.3.1-0ubuntu1
<cjwatson> It's quite possible that somebody has a 27.3.1-0ubuntu1ppa1 in some PPA, for instance, and you would want to break that too
<cjwatson> This is why you need to know the version where the change you need was introduced
<cjwatson> Am I making sense here?
<caribou> cjwatson: the fix is in deja-dup 29.5-0ubuntu2 (version in trusty)
<cjwatson> Was it introduced in exactly that version?
<cjwatson> The rm-full-path thing?
<cjwatson> That doesn't look right, that claims to be the fix for a DEP-8 test ...
<caribou> cjwatson: yes; and I need to backport it to saucy & precise
<caribou> cjwatson: the DEP-8 was in the same commit afaik
<cjwatson> And the DEP-8 test wasn't even in precise
<cjwatson> Could you give more detail?  Which upstream commit are we talking about?
<caribou> cjwatson: the revision history is a bit tedious upstream (3 commits to solve the problem)
<cjwatson> I'm hoping you'll tell me what the problem is :)
<cjwatson> Because it doesn't make sense to me that we'd need Breaks for just a test failure - so it must be something else
<caribou> cjwatson: 1527, 1528 and 1529 upstream
<caribou> cjwatson: duplicity in trusty introduces a locking mechanism based on a locfile in the cache directory
<caribou> cjwatson: deja-dup may not handle the lockfile properly prior to the version in trusty (those 3 commits do remove the lockfile)
<cjwatson> OK, this makes more sense.  From duplicity's point of view, it just needs 29.5
<caribou> cjwatson: it is a remote possibility (like if the user does kill -9 on deja-dup) but it may happen
<cjwatson> (-0ubuntu2 was further cleanup, but doesn't have compatibility relevance here)
<cjwatson> So I would advise Breaks: deja-dup (<< 29.5)
<caribou> cjwatson: ok, make sense; now how do I handle the backport of that 'evolution' to Saucy and Precise ?
<cjwatson> In the backports, you will need different Breaks versioning
<cjwatson> Breaks: deja-dup (<< first-backported-version-containing-the-fix)
<caribou> cjwatson: ah, ok I get it. But does the version needs to include the 0ubuntu{something} suffix ?
<cjwatson> (Assuming you aren't going to backport the entire new upstream)
<caribou> cjwatson: no, just that small fix
<cjwatson> For the backport, yes.  For trusty, no
<caribou> cjwatson: ok, makes total sense to me. I'll worry about trusty for now as I want it in before the freeze
<caribou> cjwatson: thanks a lot
<cjwatson> (Generally, things work better if you keep the specification minimal, so just the upstream version if you can; but that won't work for the backport)
<cjwatson> np
<cjwatson> Going back to the original example you gave, it *is* important to understand that <= 27.3.1 does not match 27.3.1-something
<cjwatson> You can use dpkg --compare-versions to check:
<cjwatson> $ if dpkg --compare-versions 27.3.1-0ubuntu1 le 27.3.1; then echo yes; else echo no; fi
<cjwatson> no
<caribou> cjwatson: hmm great test; I'll write it down somewhere
<dholbach> seb128, does the existence of https://launchpad.net/ubuntu/+source/unity8-desktop-session mean that the package was uploaded already?
<seb128> dholbach, uploaded to a ppa yes
<dholbach> ah ok
<dholbach> doko, I followed up on the sync request - thanks
<doko> dholbach, fix uploaded
<dholbach> doko, yep, I pointed that out on the bug - thanks a lot
<xnox> dholbach: or e.g. a branch is pushed =) like i now did -> lp:~xnox/ubuntu/trusty/dholbach/rules resulted in https://launchpad.net/ubuntu/+source/dholbach
<dholbach> xnox, so people can start filing bugs on 'dholbach' - great
<Laney> heh
<xnox> dholbach: [needspackaging]
<xnox> =)
<xnox> dholbach: actually that's very good for needs packaging bugs. push an empty branch to create package, then copy ITP from debian or file needs-packaging bug, but at least then you can close the needs-packaging bug with first upload.
<dholbach> yeah, that's right :)
<ritz> Sweetsha1k, hi, any thoughts on https://bugs.launchpad.net/ubuntu-advantage/+bug/1275574
<ubottu> Error: malone bug 1275574 not found
<seb128> ritz, have your seen sarnold comment on that bug? seems an accurate summary of where Ubuntu stands on the question
<ritz> seb128, hmm, thanks . so, we could ship this be default, but turned off
<seb128> right
<ritz> thanks a ton
<hallyn> jibel: oh yay, thanks for commit 84 to auto-upgrade-testing (fixing python3/distroinfo)  :)
<jibel> hey hallyn, yw
<seb128> bdmurray, hey, did you have any chance finding why retracings often don't work for e.u.c trusty reports?
<pitti> Good morning
<bdmurray> seb128: not specifically, I did notice that the trusty version of gdb often produces better results than the precise one
<bdmurray> seb128: I think that's a corner case though
<pitti> Saviq: when did unity8 get uploaded? index generation takes a few hours
<pitti> tvoss: hey
<seb128> bdmurray, the retracers run precise?
<bdmurray> seb128: the ones for errors do
<pitti> smoser: no, I'm afraid not: https://jenkins.qa.ubuntu.com/job/trusty-adt-setup-testbed/123/ARCH=amd64,label=wazn-adt/console
<seb128> bdmurray, can you have access to one of the reports and try to retrace manually to see if that hits an error?
<Saviq> pitti, well there's only one version in the indexes anyway, while the packages come from PPAs, so I assume they'd never end up in the index, would they?
<pitti> Saviq: ah; yes, if they are not in the distro, then they won't get indexed
<pitti> Saviq: and they will also get cleaned up again, as they really ought to live in the PPA only
<mapreri> dholbach: sorry, but I can't reproduce the bug you reported against liferea. I can start it even on a clean install on virtualbox...
<Saviq> pitti, indeed, any pointers on how to retrace .crashes from PPAs? can I download the ddebs and put them in the cache somewhere? would that help at all?
<bdmurray> seb128: I'll see what I can do
<pitti> Saviq: they should be in the PPA's Packages, are they not?
<pitti> Saviq: then, if you add an apt source for them it should Just Work
<dholbach> mapreri, maybe it doesn't work if you have preferences stored locally from a previous version?
<Saviq> pitti, ah are they?
<Saviq> pitti, http://pastebin.ubuntu.com/6960750/ doesn't look like it
<seb128> bdmurray, thanks
<smoser> pitti, yeah, i see that.
<smoser> so the 20140219 build is just not marked current
<smoser> utlemming, ^
<smoser> http://cloud-images.ubuntu.com/trusty/current/ is 20140218,
<smoser> did publish to ec2 fail ?
<mapreri> dholbach: I don't think so: I had a previous configuration from a quite old installation (during quantal maybe) and worked fine (after that I delete all config file to see what happen on a new installation). Can you try with a guest user to exclude user config issues (or confirm)?
<dholbach> mapreri, hah! now it works! :)
<dholbach> I have no idea what happened in the meantime
<mapreri> dholbach: automagically?
<dholbach> sorry for the noise - maybe it was intermittent
<dholbach> but I just started it again, just to try - because I had tried it at least 4-5 times earlier
<dholbach> now it works
<mapreri> dholbach: is the messaging menu working fine? (I had some trouble during the merging..)
<dholbach> mapreri, this is really bizarre
<dholbach> mapreri, yep, it works
<dholbach> mapreri, let me close the bug again
<dholbach> thanks for your work on this!
<mapreri> dholbach: yeah, casual failures are always "weired"
<dholbach> mapreri, if it should ever act up again, I'll let you know! :)
<mapreri> dholbach: good! let's go on with another piece of software :)
<dholbach> :)
<pitti> smoser, utlemming: yep, jibel forced a manual build with 0219 instead of /current, works fine again
<smoser> pitti, k. thanks.
<smoser> pitti, so is this a test taht coudl get done in a dep-8 package test ?
<smoser> i'd have to download the image, patch in the new cloud-init and then boot it.
<pitti> smoser: you mean s/i/it/ ?
<smoser> which is all reasonably well do able. with root and kvm.
<pitti> smoser: indeed
<pitti> smoser: if you boot the image with a seed the first time, it modifies the image, right?
<pitti> smoser: but even at the second time cloud-init is still active and needs the seed, so it would still be an useful test
<smoser> well, with root i'd just place it in
<pitti> smoser: or wait, we could qemu-nbd mount the image, schroot in, dpkg -i the new cloud image
<pitti> and then boot it
<smoser> right.
<smoser> i'd use mount-image-callback as that is why it exists. but that is somethign that is doable ?
<smoser> ie, its ok to require nbd kernel module loaded, access to root and to kvm ?
<pitti> ah, I wasn't aware of mount-image-callback, that sounds interesting
<smoser> i told you about it on your blog!
<pitti> smoser: yes, it is
<smoser> you should at least read your *own* blog :)
<pitti> heh; sorry, forgot about it
<pitti> smoser: so yes, as long as this test runs in a full qemu, that'll work fine
<pitti> qemu nests well
<smoser> "well"
<pitti> it won't work on arm/ppc64 in LXC containers
<pitti> but that's ok
<pitti> (and I'll soon add restrictions to declare which isolation level you need, it has recently been discussed in Debian)
<smoser> we could actually test part of it though lxc, althoguh i've not done it.
<smoser> you should be able to create a loop block device, and then present that to the container.
<smoser> thanks
<pitti> yes, but without nbd and qemu it's virtually impossible to mout and modify a qcow image
<pitti> smoser: but I don't expect the cloud-init/seed logic to be much platform specific, is it?
<pitti> i. e. testing it on x86 initially should be by and large sufficient
<smoser> pitti, right. its not arch specific.
<smoser> you dont need qemu to do qemu-nbd
<smoser> anyway. thanks
<pitti> smoser: right, but you need root, and modprobe nbd, which you don't have in lxc
<pitti> (you have root, but not modprobe)
<jtaylor> doko: pinged the maintainer about pytables
<pitti> hm, so pyzmq, dh_python, ubuntu-release-upgrader, and perhaps some other tests are now broken with py 3.4 as a default
<cjwatson> pitti: With pygobject/gi, is there any way to annotate a GVariant* parameter such that Python keyword arguments or maybe a Python dictionary get translated to/from a GVariant automatically, or do I have to write wrapper code for that?
<pitti> cjwatson: there is no implicit conversion, but there is an override class for GLib.Variant which makes this relatively easy
<pitti> https://git.gnome.org/browse/pygobject/tree/tests/test_overrides_glib.py#n11
<jtaylor> pitti: pyzmq just needs a rebuild
<jtaylor> I'm on it
<pitti> cjwatson: or rather, https://git.gnome.org/browse/pygobject/tree/tests/test_overrides_glib.py#n64
<jtaylor> just checking the build failure on ppc
<pitti> jtaylor: ah, thanks
<jtaylor> zeromq
<jtaylor> ipython is also in works
<cjwatson> pitti: GLib.Variant("a{ss}", {"foo": "bar"}) and suchlike?
<pitti> cjwatson: i. e. it's GLib.Variant(signature, pydict)
<pitti> cjwatson: right
<cjwatson> pitti: OK, that'll do, thanks; just the first time I've written a library with gobject-introspection support and I wanted to check I wasn't missing something cleverer
<cjwatson> Looks like roughly 3x/4x lines of code in C vs. Python, which I suppose isn't *terrible*
<smoser> pitti, ah. ok. that makes sense.
<hallyn> rbasak: uvt-simplestreams-libvirt sync release=quantal arch=i386   fails?
<hallyn> maybe i'm in a bad state...  this doesn't make sense
<hallyn> rbasak: http://paste.ubuntu.com/6961095/  does that look familiar to you?
<rbasak> hallyn: not seen that before, no. otp right now.
<hallyn> rbasak: kthx
<jtaylor> fun zeromq does nto fail in debian ppc porterbox ._.
<jtaylor> I assume we still don't have ubuntu porterboxes?
<hallyn> Hm, update/reboot didn't help, and even  uvt-simplestreams-libvirt sync release=saucy arch=amd64 dies
<pitti> fginther, barry: hey guys, how are you? greetings from Oakland!
<pitti> fginther, barry: would you mind giving me a quick heads-up about the current state of running py3 ap tests in CI?
<barry> pitti: hi!
<pitti> fginther, barry: AFAIUI, there were some blockers to that a few weeks ago
<pitti> I suppose once we can run py3 autopilot tests in CI at all, then the rest is just relatively simple porting that parallelizes well
<barry> pitti, fginther yeah, unfortunately i got totally sidetracked on a deep image upgrade issue.  but i think i have fixes for that now and plan on getting back to py3 ap
<pitti> and we'd like to do that on the sprint this afternoon
<barry> pitti: i have many ports in progress.  we need the ci infrastructure to support it.  xnox iirc landed phablet-test-run changes and i have some autopilot changes that thomi has looked at and needs fixing.  once we get the autopilot reexec branch landed, we can port individual tests one at a time
<pitti> barry: ah, so phablet-test-run is done
<pitti> re-execing ap sounds a bit scary :)
<barry> pitti: double check with xnox
<barry> pitti: naw, not scary!  clever and fun! :)
<pitti> barry: ah, you don't want tests to declare themselves whether they use py2 or 3?
<barry> pitti: (like just a few lines of code)
<pitti> barry: hehe, h4cks 4r3 us âº
<barry> pitti: we thought about that, but it's just temporary.  we *really* want everything ported to py3 by 14.04
<pitti> barry: yes, understood
<pitti> barry: ok, thank you!
<barry> pitti: np!  thanks for helping get the ci infrastructure working.  please let me know how that goes
<pitti> barry: I thought there was also some discussion about eliminating py2/3 from the installation, and building a chroot/virtualenv in $HOME for installing AP and the tests, or so?
<pitti> barry: hm, I can't see that on https://code.launchpad.net/autopilot/+activereviews
<barry> pitti: that was part of the "make tests work in read-only image and don't include autopilot in the sdk".  fginther and thomi might be able to answer that better. we had discussions about it in london, and came with some ideas, but i don't know what they decided
<barry> pitti: thomi put the mp on hold, which is why that doesn't show up: https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765
<pitti> barry: ah, so ATM we still have both and thus this ^ is independent from porting tests and making AP do the "guess which py version I want" trick
<pitti> ah
<barry> right
<pitti> barry: TBH I'm not that thrilled about that blatant violation of the py3 packaging policy by shipping both versions in python-autopilot
<pitti> as that's not just a temporary hack but a long-term commitment (we can basically never clean that up without breakage)
<pitti> barry: what's bad about having separate python3-autopilot* packages?
<barry> pitti: there is a python3-autopilot package, right?
<pitti> barry: yes, but I thought that MP removed it
<pitti> This also collapses all the python3-* packages into the python-* packages. This supports a transition where we'll eventually delete all Python 2 support.
<pitti> barry: I think that does quite the opposite
<pitti> with separate py2/3 packages it is much easier to remove py2 support without breakage
<barry> pitti: hmm.  i thought it would be easy to just remove /usr/bin/autopilot
<barry> (from the python-autopilot package)
<pitti> barry: but from the reverse depends of that hybrid python-autopilot you can never be quite sure whether they expect py2 or 3
<thomi> barry: if you need that branch merged, ping me, and I'll have a look at adding the tests that are required. It was put on hold because it regressed test coverage :)
<barry> pitti: i think i may have had other reasons for doing that too, but that's all been swapped out since london :/  please do me a favor and add a comment to the mp.  as long as we keep focused on getting rid of py2 on the phone, i'm for whatever makes the transition work best.
<thomi> but it sounds like there's some discussion that still needs to happen
<barry> thomi: yep, will do.  i really hope i can get back to that this week.
<thomi> ok
<pitti> barry: python3-autopilot could divert python-autopilot's /usr/bin/autopilot as long as it has your "reexec with py2" trick?
<pitti> if /usr/bin/autopilot-py3 is not working for some reason
<pitti> barry: ack, will do
<barry> pitti: thanks.  i'm multi-multi-tasking atm ;)
<barry> lifeless: http://bugs.python.org/issue20687
<lifeless> barry: yay
<barry> lifeless: yeah.  at least it's reported now.  given the changeset and age of the change, i'm not optimistic this will be fixed before 3.4 final :(
<barry> *maybe* by 3.4.1, but by then, you're kind of screwed
<pitti> barry: followed up
<lifeless> barry: I'd call this a regression though; whats the process for dealing with regressions?
<barry> lifeless: i would too.  if it's a critical regression, then it could hold up rc2.  you'd have to convince larry hastings (3.4 rm) about that.  probably a post on python-dev if you think it's critical enough, and bump the priority to release blocker
<pitti> xnox: so what does phablet-test-run do these days in terms of py2 vs. 3?
<lifeless> barry: well you must have opinions too ;) - what do you think, a break in a public API ?
<barry> lifeless: that's the question - was testtools relying on documented public api, or implementation details.  i probably have an opinion, but right now my stack is too deep and i get a recursion error when i try to access it :)
<barry> lifeless: so i would recommend commenting on the bug stating the public api that got broke.  if you need me to ping larry, i can do that, but not sure i'll have the resources to chime in
<barry> *cycles
<lifeless> barry: btw I'm rbcollins in the tracker
<barry> lifeless: ah, that's why i couldn't find you ;)
<lifeless> commented
<lifeless> thomi: are you working up a patch to fix Python3.4?
<barry> lifeless: i nosied larry and bumped it to release blocker
<pitti> xnox, barry: so thomi and I just discussed this, and we think the main problem that's left is how tests declare that they got ported to py3
<pitti> xnox, barry: for packaged tests we could check their deps, but that doesn't work for click and tests from bzr (which apparently we need to support)
<pitti> xnox, barry: so we found that it might be easiest to just add a magic comment or a global _AP_PY3 = True variable into the tests
<pitti> xnox, barry: and then phablet-test-run or /usr/bin/autopilot could check that and call autopilot-py3 (for p-t-r) or run python[3] -m autopilot (for /u/b/ap)
<pitti> xnox, barry: that ought to work for all scenarios, is explicit (i. e. we can measure/check the porting status), and we can drop that flag variable in the future again
<pitti> xnox, barry: we can also have a hangout if you wish
<pitti> I summarized that in https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765
<rbasak> hallyn: looks like maybe you have a corrupt or missing file in /var/lib/uvtool/libvirt/metadata/
<rbasak> hallyn: that might be a bug. I'm not sure if I atomically move new files in, or write them in place.
<rbasak> hallyn: fix: remove the offending file, and resync.
<pitti> barry: wow, this problem violates the laws of projectivity; it becomes bigger the closer you get to it :(
<barry> pitti: i need to be afk for a while.  can you set up a hangout with you, me, xnox, and thomi for tomorrow?
<hallyn> rbasak: after removing the cache i had to purge and reinstall uvtool-libvirt to get directories re-created with the right perms
<hallyn> rbasak: but now it's building, thanks
<pitti> barry: would tomorrow 1700 UTC work for you?
<hallyn> rbasak: another q: is there a way to shut up the 'Warning: this CLI is experimental and may change.' ?
<hallyn> (not very amenable to scripting)
<pitti> barry: done
<rbasak> hallyn: I've left a "uvt-simplestreams-libvirt purge" command that wipes all volumes (potentially breaking any existing VMs that might use them).
<rbasak> Though it's broken in Trusty (fixed locally; I'll upload before FF)
<hallyn> rbasak: what do you mean by 'left' ?
<rbasak> Er, working in Trusty, broken in Precise.
<rbasak> hallyn: as in it's there, though really intended for cleaning up after a mess; it's still a bug if a mess occurs.
<hallyn> ok
<hallyn> i'm slowly making progress;  now have an unbootable quantal vm, but at least i have it :)
<rbasak> hallyn: uvtool issues? Or elsewhere?
<hallyn> not sure.  i don't see where i had room (before this failure) to mess up the image...  but lemme try by hand
<rbasak> About the CLI experimental warning - I'm just about ready to drop that. Also before FF.
 * rbasak has a few more things to do today :-/
<hallyn> rbasak: oh, it's on stderr, so i should be able to tell subprocess to ignroe it
<rbasak> hallyn: ah yes; that's intentional for that reason.
<hallyn> i just didn't think subprocess would give me stderr by default
<rbasak> It does, but separately, IIRC.
<hallyn> actually no,
<hallyn> subprocess.check_output(["uvt-kvm", "list"], stderr=None)
<hallyn> Warning: this CLI is experimental and may change.
<rbasak> hallyn: None doesn't do what you think. You want:
<rbasak> with open('/dev/null', 'wb') as null_file:
<rbasak>   subprocess.check_output(["uvt-kvm", "list", stderr=null_file)
<jtaylor> *nitpick* os.devnull
<rbasak>                                             ^
<rbasak>                                             ]                  # :)
<rbasak> Oh, that exists?
<jtaylor> yes but only relevant for windows
<hallyn> rbasak: well that's a pain :)  ok, thx.  first to see why my vm wont' boot
<rbasak> Oh I see. Just the path, rather than a file object. Thanks ;)
<hallyn> hangs on 'booting from Hard Disk'.  maybe it's a qemu bug.
<rbasak> hallyn: two ways to debug. --log-console-output, then look at /var/log/libvirt/qemu/<machine>.log
<cjwatson> rbasak: There's also stderr=subprocess.STDERR, but that's new in 3.3
<rbasak> hallyn: or, no --log-console-output, and then "virsh console <machine>" to get an interactive VT
<cjwatson> err
<cjwatson> stderr=subprocess.DEVNULL I mean
<rbasak> Nice. I've always wanted that :)
<rbasak> Getting an interactive VT with "virsh console" races VM start though I think. Should be good enough if you're ready for it though.
<hallyn> rbasak: but so yes, uvt-kvm create xxx release=quantal arch=i386 --ssh-public-key-file ~/auto-
<hallyn> upgrade-tester/ssh-key
<hallyn> gives me an unbootable vm.  sigh
<rbasak> It really shouldn't do that.
<hallyn> mind you i'm nested
<rbasak> How many levels?
<rbasak> One level (of nesting) works fine for me. One additional level caused the middle kernel to hang, IIRC. I didn't experiment further.
<hallyn> just one level - running quantal vm in a trusty vm on precise
<jpds> You need to go deeper.
<rbasak> Each level does appear to run at a fraction of the speed :)
<hallyn> jpds: yup that'll solve it :)
<hallyn> you know, if my problem is a race condition when things run too fast
 * rbasak wonders if that's backwards
<frafu> Hi, We have just published an update of Onboard, the default on-screen keyboard shipping with Ubuntu. Could anybody please review the debian package I prepared for trusty before feature freeze is in place? Many thanks in advance.
<frafu> https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1282231
<ubottu> Launchpad bug 1282231 in onboard (Ubuntu) "Onboard update available (version 1.0.0) - debian source for trusty attached" [Undecided,New]
<infinity> Setting up python3-minimal (3.4~rc1-1) ...
<infinity> Exception ignored in: <bound method Popen.__del__ of <subprocess.Popen object at 0xf75c1610>>
<infinity> Traceback (most recent call last):
<infinity>   File "/usr/lib/python3.4/subprocess.py", line 897, in __del__
<infinity> TypeError: 'NoneType' object is not callable
<lifeless> classic
<infinity> doko: ^-- I'm seeing a lot of that.  Do you know what's going on?
<roadmr> can I get "apt-get install" to fully expand the list of unmet dependencies? e.g. it can't install X because it depends on Y, but it won't tell me why Y can't be installed (it may depend on Z which *is* uninstallable)
<cjwatson> roadmr: Sadly AFAIK you generally just have to keep supplying additional package names from the error output until you get a useful answer
<roadmr> cjwatson: oh bummer... that's what I'm doing but it's cumbersome :/ thanks anyway!
<frafu> TheMuso: I suppose that we missed feature freeze with this: https://bugs.launchpad.net/ubuntu/+source/onboard/+bug/1282231   ?
<ubottu> Launchpad bug 1282231 in onboard (Ubuntu) "Onboard update available (version 1.0.0) - debian source for trusty attached" [Undecided,New]
<pitti> cjwatson: jibel and I believe we understand what happened last week in britney with gccgo; I just committed a test case which reproduces that: http://bazaar.launchpad.net/~canonical-platform-qa/britney/tests/revision/397
<roaksoax> has something changed packaging wise that python mpackages are installing in /usr/lib/pythonX.y/etc/etc instead of creating the symlink to /usr/share/pyshared?
<cjwatson> roaksoax: https://launchpad.net/ubuntu/+source/python-defaults/2.7.5-5ubuntu3
<cjwatson> (I think.  Yes, anyway.)
<roaksoax> cjwatson: cool thanks!
#ubuntu-devel 2014-02-20
<xnox> pitti: i thought that was solved -> clicks declare x-tests:autopilot_dir= key in their manifest.
<xnox> pitti: that means they are ported.
<xnox> pitti: deb based tests, will ship modules in either python3 or python2.7 path (and thus import/re-exec test works for them)
<pitti> xnox: right, but I was told that for some cases/apps the tests would just be in bzr, and that there was no packaging for those
<pitti> xnox: anyway, is the meeting tomorrow ok for you?
<xnox> pitti: all click's tests are just in bzr.
<xnox> pitti: yeah, i'll be there.
<pitti> xnox: perfect, thank you
<xnox> pitti: and i should update my phablet-tools patch before that meeting.
<pitti> probably best to discuss that with everyone in the hangout
<xnox> pitti: is sergiusens on the call as well?
<pitti> xnox: not ATM, but I'm happy to invite him
<xnox> pitti: please do.
<slangasek> xnox, pitti: so I know this was discussed at the core sprint, but I have yet to see a write-up of what was decided there.
<slangasek> I gather that xnox and barry have a clear idea of what's required, but it hasn't been written up / shared, which should be remedied ASAP
<xnox> slangasek: and there is another sprint in progress across the pond, which may have new things....
<xnox> slangasek: i'll write something up early tomorrow such that we all should be on a similar page and with all steps clear (and their current status)
<slangasek> xnox: ok, thank you
<pitti> slangasek: I gave a summary to https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765
<pitti> slangasek: nothing decided really, we just discussed it and found that we agree on some things, but need xnox and barry for others
<pitti> slangasek: we just ruled out some possible proposals (such as this reexec trick or merging py2/3 modules into python-autopilot) as they wouldn't work
<slangasek> um
<slangasek> why does re-exec not work?
<pitti> because it's only done on import, not if there's a failed test
<pitti> importing py3 autopilot will always work, but you might get test failures on non-py3 compatible tests
<pitti> if you run tests from bzr you don't have separate install locations for py2 and py3 autopilot test modules
<slangasek> pitti: so xnox and barry did have a plan to address this
<slangasek> which xnox has agreed to write down where we can all discuss it, instead of rediscussing everything from scratch every other week :)
<xnox> pitti: re-exec trick works, if one uses phablet-test-run with my proposed branch to phablet-test-run.
<pitti> well yes, that's the bit which we don't understand yet, and I haven't seen a place which explains this
<xnox> pitti: indeed executing directly in the bzr checkout has a corner case, but everyone must use phablet-test-run, as during transition period we will not support anything else.
<xnox> pitti: right i'll write exactly that up.
<pitti> xnox: barry said that there are tests which don't use that
<pitti> if that's obsolete, then it makes the whole thing much simpler
<slangasek> pitti: IIRC the plan was to force use of phablet-test-run as a precondition for py3 tests, and let non-ptr callers continue to use python2
<pitti> slangasek: ah
<xnox> pitti: and the point of re-exec trick was that it live for a very short period of time: between the upload and until last pre-installed click ports to python3, at the point python2 from autopilot will be purged.
<slangasek> since we should be using ptr for everything, and should be using python3 for everything
<xnox> pitti: and we will _only_ support python3 with autopilot.
<slangasek> so it doesn't hurt to bundle the two
<pitti> ack
<pitti> so thomi and I were open to either reexec or checking a flag in the deb/click source in /usr/bin/autopkgtest to then run python[3] -m autopkgtest.run
<pitti> but thomi said we don't always have a click/deb source so we can't use a flag in the packaging, but it needs to be in the sourc
<xnox> pitti: the current proposal we had is that - phablet-test-run looks into click manifest (as it does now anyway) to fetch the bzr branch of the tests.
<pitti> xnox: click manifest or the deb depends .*python3* ?
<xnox> pitti: no, click manifest is either current (naked -> means python2) or has "autopilot_dir" key with the path to tests inside the branch.
<pitti> the only thing which I'm absolutely and firmly against is to put the python3 autopilot modules into python-autopilot together with the py2 modules
<pitti> xnox: yes; I mean, we need a corresponding metadata check for .deb packages, like dialer-app-autopilot
<xnox> pitti: apart from based on the flags in click manifest, phablet-test-run will fetch python2 or python3 tests into different paths. Then for python3 and python2 a different pythonpath is set and re-exec does the magic.
<pitti> but that's just Depends:.*python3* IMHO
<xnox> pitti: for debs it's different.
<xnox> pitti: as debs tests already encode which python version they are for inside the deb, so we similarly extract them into python2 or python3 pythonpath by phablet-test-run.
<pitti> xnox: ah right, those would trigger the import error for py3
<xnox> pitti: exactly =)
<xnox> pitti: pitti: there is no need for two /usr/bin/autopilot binaries as during _transition_ period we can force a given python version with: /usr/bin/python2 /usr/bin/autopilot
<pitti> xnox: so if we can assume p-t-r and that it can always tell whether the test runs py2 or py3, the p-t-r could just call /usr/bin/autopilot or /usr/bin/autopilot-py3
<pitti> that's the most straightforward and explicit way
<xnox> pitti: also, i don't understand the fetish about using a different binary package, cause that just forces people to do pointless uploads to depend one or the other package name.
<pitti> if you really prefer the re-exec hack, that would do as well, and while I don't particularly like it I don't veto it
<xnox> pitti: re-exec hack is best imho, as that will push python3 modules off the image quicker.
<pitti> how so?
<xnox> pitti: and requires less reuploads.
<pitti> p-t-r could just explicitly call ap-py3 or ap-py2
<pitti> because it knows which py version the test wants
<xnox> pitti: it's the same script.... autogenerated entry point.
<xnox> pitti: it's a relly like "dash" vs "bash" autopilot entry point is the same, and we want python3 to be the default and will drop python2.
<pitti> no, it should have a python3 hashbang
<xnox> pitti: and with re-exec it does, and is called "/usr/bin/autopilot" and really do not want to end up with "/usr/bin/autopilot-py3" forever.
<pitti> and it does
<pitti> xnox: yes, that's why I said I'm okay with the reexec hack, if people object to the autopilot3 name
<xnox> pitti: the python2 and python3 versions of the script are the same, thus "/usr/bin/python2 /usr/bin/autopilot" is equivalent to the current python2 autopilot.
<pitti> we'd need to divert /usr/bin/autopilot in python3-autopilot
<xnox> with re-exec hack, it's just transparent.
<pitti> and drop the autogenerated entry point and replace it wit ha simple shell script
<xnox> pitti: well, that's why we merged the two into a single package ;-) no need to divert things.
<pitti> but that's not too complicated
<pitti> and I'm certainly willing to do that
<xnox> pitti: please no shell...
<pitti> xnox: no, no, no, no
<pitti> merging the two into one will forever commit us to supporting ap-py2
<pitti> I want to drop python-autopilot after all tests get ported
<pitti> and ported packaged tests will change their dep to python3-autopilot
<xnox> pitti: i don't want to (a) encode /usr/bin/python3 (b) encode Depends: python3-autopilot (c) upload all of that (d) drop python2 autopilot (e) rencode s/autopilot-3/autopilot (f) reencode Depends:autopilot
<pitti> so we can simply measure which tests got ported, and we never break packages which still need python-autopilot
<xnox> pitti: we don't break any tests with my plan and have 3 transition steps instead of 5.
<pitti> *shrug*, if we want to assume that at no point we break anything existing that's what we have to do
<pitti> we need to upload the packages anyway to fix the tests
<xnox> pitti: as long as people use phablet-test-run to execute the tests (be it deb, or click)
<xnox> pitti: even longer route is to make all tests bilingual, not break anything at any point, and then drop python2 in any order....
<pitti> I'm not willing to break upgrades, the python policy, and reverse dependencies just because we are too lazy to properly switch dependency for ported packages
<pitti> that would be a tiny short-term benefit for long-term trouble
<pitti> xnox: I think your reexec trick is fine, given the new assumptions; but it doesn't require this blatant "merge py2/3 modules into one binary" hack
<xnox> pitti: what upgrades? also i don't see how python policy is violated at all.... and i don't see how we are doing anything lazy here.
<pitti> xnox: because at some point you'd drop the py2 modules from python-autopilot, and you have no way of knowing which rdepends of python-autopilot still expect py2, and which only py3
<xnox> pitti: sure you can have modules in any package. but imho autopilot is an app, and should have it's module in the same binary package.
<xnox> pitti: and ideally like ship them in /usr/share/autopilot/ anyway =)))))
<xnox> pitti: what do you think of the pyflakes package btw?
<pitti> err, no, autopilot is not an app
<pitti> or not only
<pitti> it's mainly a python API
<xnox> pitti: i really did not want the world to do: Depends: pyflakes, pyflakes3, just because they started to support python3.
<pitti> xnox: "pyflakes3" makes no sense indeed, as that's just a program
<pitti> python3-pyflakes would be required if applications would do "import pyflakes"
<xnox> pitti: it's only executable under autopilot binary controlled environment and it's users are private plugins. It's no different from e.g. bzr and bzr plugins.
<pitti> err, no
<xnox> pitti: i have at least 3 reverse-dependencies that import public pyflakes modules and do further or less processing.
<xnox> pitti: and i don't see how I violate any of the python policy.
<pitti> xnox: oh, you mean pyflakes, not ap
<pitti> xnox: if pyflakes has a public python module API, then you need a python3-pyflakes
<xnox> pitti: the only bit that i probably violate is python modules team naming scheme.
<xnox> pitti: i don't /need/ it, i just need to have it.
<pitti> xnox: the difference of pyflakes to ap is that pyflakes is only a CLI program and that the fact that it is written in python is an internal implementation detail
<xnox> pitti: i mean if ubuntu ever decides to drop python2 from main into universe, a split is welcome. Otherwise it's been absolutely pointless, especially for all the bilingual moudles.
<pitti> but this is not the case with ap
<pitti> it has a public user-facing python API
<pitti> it's not pointless
<xnox> pitti: it doesn't. the only way to use autopilot modules is by executing them through /usr/bin/autopilot and have that eventually setup environment and import your modules.
<pitti> you can't just randomly break reverse dependencies which expect python-ap to ship what it says on the tin: the python2 ap module
<pitti> xnox: no, you misunderstand that
<xnox> pitti: how does one write something that import autopilot and does something useful which is not a test script?
<pitti> xnox: all ap tests do "import autopilot"
<xnox> pitti: yes, but it's not "python -m my_test_module" it's "autopilot my_test_script"
<pitti> ap also has that /usr/bin/autopilot test runner (which is a CLI), but it has a public API
<xnox> pitti: at no time those tests that do "import autopilot" can do anything useful by themself.
<xnox> without the one and only /usr/bin/autopilot test runner.
<pitti> sure
<pitti> but we don't know whether the tests are py2 or py3
<xnox> pitti: autopilot broke it's api and moved to 1.4 without renaming =)
<pitti> and we don't control them all
<xnox> pitti: which it should have done, if I go by your "it's public api" ditto like cherrypy2 / cherrypy3
<pitti> it's the exact same reason why we have python3-apt, python3-pycurl, and what not
<xnox> pitti: and at the moment we do control all autopilot tests out there.
<pitti> xnox: err, no, we don't
<xnox> pitti: python3-apt / pycurl is different.
<pitti> we've shipped autopilot for a long time as ubuntu package, we don't know how people use it aside from our packaged tests
<xnox> pitti: then how did we broke and removed 1.3 api, if we don't control all fo them?!
<pitti> e. g. we use it in the ubiquity tests
<pitti> which just live in a branch somewhere
<xnox> pitti: and we control ubiquity tests, it's in lp:ubiquity.
<pitti> xnox: I never said that I thought that was a good idea
<pitti> xnox: no, not these; I mean the ubiquity autopilot tests
<pitti> but anyway
<xnox> pitti: ubiquity autopilot tests are long merged into lp:ubiquity and jenkins is running them off lp:ubiquity...
<pitti> I consider python-ap to be like python-apt or python-pycurl etc.
<pitti> xnox: ok, fine; it was just an example
<pitti> but there is a reason why we have separeate python3-* binaries in the archive, and that applies to ap as well
<pitti> and I see absolutely no reason why we should cause this long-term trouble
<pitti> we just flip the dependencies if we port a test, that takes like 2 seconds
<xnox> pitti: i agree there is a reason, i don't see a reason for ap though given that i thought the plan is to drop python2-ap and keeping "python3" in the name (or any abbriviation of thereoff) is a historical mistake =)
<pitti> and then we can clearly see what stuff is still using py2 by checking the rdepdns of python-autopilot
<pitti> how is it a historical mistake?
<pitti> python3 is a different programming language than python 2
<xnox> for debs we inspect content, for clicks look at manifest. it's clear.
<xnox> if deb is depends on python-autopilot -> not ported, depends on autopilot ported.
<xnox> clicks no autopilot_dir key -> not ported, with autopilot_dir key -> ported.
<xnox> pitti: under your naming scheme how or when are you going to drop "autopilot-py3" and just make it "autopilot" (shebang python3)
<xnox> ?
<pitti> seriously, that policy was made to provide a safe solution which works
<pitti> I don't see how it helps to arguing about it for hours and spending lots of time to check that we didn't break everything when we can just effing change depends: to python3-ap for ported tests in 2 seconds and know that it's right
<pitti> xnox: I thought we wanted to do that right now, with your reexec trick?
<xnox> pitti: yes. hence python3-ap is pointless with reexec.
<pitti> (and keep autopilot3 as a compat symlink)
<pitti> well, python-autopilot keeps /u/b/a as we have it today
<xnox> pitti: so you want policy compliant binary package names with re-exec hack?
<pitti> python3-autopilot diverts that and replaces it with a python3 hashbang
<xnox> (e.g. python3-autopilot owns /u/b/a which does re-exec if it needs to)
<pitti> the reexec trick will then run it as py2 if import with py3 fails
<pitti> it's ugly and non-explicit in my taste, but it works and I'm ok with that
<xnox> pitti: divert -> ok.
<xnox> pitti: do diverts work ahead of other package installation?! (thinking about it, they must)
<pitti> xnox: yes, they do
<xnox> (e.g. install python3-autopilot first, and maybe later python-autopilot)
<xnox> pitti: ok.
<pitti> xnox: i. e. you can install py3-ap, it installs the diversion
<xnox> cool.
<pitti> and then you install py-ap, dpkg will install its /u/b/ap into the diverted location
<xnox> pitti: ok then packaging will be sane and easy + divert.
<pitti> same the other way round
<xnox> + reexec
<pitti> xnox: yes, it would in both cases be the same autogenerated script, just with diversion instead of rename to autopilot3
<pitti> we then need the reexec trick
<xnox> pitti: exellent.
<pitti> but we have the code for that in barry's branch
<xnox> correct.
<robert_ancell> cjwatson, slangasek or others, can you get https://launchpad.net/ubuntu/+source/gnome-session/3.9.90-0ubuntu8/+build/5618671 out of the NEW queue? We need to split the old gnome-session binary into gnome-session and ubuntu-session. Also, will that automatically be in main?
<robert_ancell> RAOF, your in ~archive-admin but not an archive admin suitable for that right?
<RAOF> robert_ancell: Correct. I only NEW packages which are X-SRUish (so, things like the nvidia-drivers-34234234245234134-updates et al)
<robert_ancell> RAOF, know any archive admins who are awake by any chance?
<slangasek> E: base-files: file-in-etc-not-marked-as-conffile etc/legal
<slangasek> grr, we really ought to force that package to use debhelper
<StevenK> slangasek: Santiago is still allergic?
<slangasek> apparently?
<StevenK> I don't get why he is so against it, but hey, it's his battle.
<slangasek> well, and then people keep modifying the package in Ubuntu and adding new files under /etc, not realizing there's an additional manual step
<infinity> Yeah, I had to clean that up with os-release ages ago.
<StevenK> slangasek: Perhaps we need the build to fail in that case. Or we could just accidently switch to debhelper
<infinity> Luckily caught it before it was a big issue.
<slangasek> infinity: yeah, apparently we've gone since karmic without anyone ever reading the lintian output on the binary packages on base-files?
<infinity> slangasek: Seems plausible.
<infinity> I only noticed it with os-release, cause that's a file that actually changes on upgrade.
 * slangasek nods
<infinity> Hey, shiny, eglibc 2.19 passed the testsuite on amd64 and ppc64el.  Should probably slam it at a PPA to check the other arches, and then slide it in right before FF. :P
<infinity> Except that dinner made me too fat to think.
<slangasek> infinity: and regression-testing it in ubuntu-emulator too, right?
<infinity> I think my stomach is actually putting pressure on my brain somehow.
 * slangasek gives infinity a spinal tap to release the pressure
<infinity> slangasek: Are there destructions somewhere on how to do that?
<slangasek> infinity: https://wiki.ubuntu.com/Touch/Emulator
<slangasek> not sure if we should be worrying about an autopilot run, or if smoke testing is sufficient... you probably have a better feel for the 2.18->2.19 delta than I do, to answer that
<infinity> "The terminal will start an Ubuntu console by default, which can be used as any virtual console. Just be aware that hiiting Control + C will stop the emulator."
<infinity> Sliiiick.
<slangasek> yeah, qemu+stupidjobcontroltricks
<infinity> Sounds like someone just needs to use saner console redirection defaults.
<slangasek> mm?
<infinity> But anyhow... Let's see if I can make this all go after I get a PPA build running.
<slangasek> ok
<infinity> 1 new private symbol, 0 new public symbols.  Looks sane.
<slangasek> oh for the love of makefiles
<infinity> Also, why am I hungry?  I think my brain is broken.
<infinity> Sitting here unable to move, and thinking "yeah, I could really go for a snack."
<slangasek> yes, base-files, perfectly reasonable that I should have to also remember to manually install debian/postrm
<infinity> You're adding a postrm?
<slangasek> yes, dpkg-maintscript-helper
<infinity> To do the conffile migration?
<slangasek> to do a conffile removal
<infinity> rm_if_matches_md5sum
<infinity> See: http://launchpadlibrarian.net/120844030/base-files_6.5ubuntu6.3_6.5ubuntu6.4.diff.gz
<infinity> slangasek: I'm a fan of sticking with the way the package already handles this case.
<slangasek> yes, and I prefer full policy compliance. :)
<infinity> Mixed methods just seem icky.  I'm all for submitting a patch to Debian to change all of those bits to maintscript-helper, but just one seems odd.
<slangasek> it's just the one because it's an Ubuntu-specific file being removed
<slangasek> so post-trusty the delta can drop out again
<infinity> Kay.  Still would make sense to me to just use the same method, s'all.
<infinity> Smaller delta, more obviously readable in context, no new maintainer scripts, etc.
<slangasek> except that method is buggy, and I have no intention of fixing the bugs in it by hand
<slangasek> in fact, fixing the bugs in it requires adding a postrm anyway
<infinity> True.
<infinity> Though, this is only true for the rollback case, I'm not sure how much I'd care (I obviously didn't when I did os-release, but whatever)
<infinity> I suspect you have bigger issues if your system is so broken that base-files fails to upgrade and needs to abort/unwind.
<hallyn> pitti: stgraber: rbasak: rharper:  I'm sure there are problems left with it, but I opened https://code.launchpad.net/~serge-hallyn/auto-upgrade-testing/uvtool/+merge/207350  (managed to do a full adt run with it)
<infinity> pitti: How do we completely flush an arch from ddebs so we can re-retrieve it?
<inahandizha> http://VisitsToMoney.com/index.php?refId=386970
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<Noskcaj> dholbach, Could you look at some merges for xubuntu please?
<Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-panel/4.11/+merge/206601 is probably the highest priority
<dholbach> Noskcaj, yes
<Noskcaj> thanks
<Noskcaj> slangasek, bug 1280109
<ubottu> bug 1280109 in skype (Ubuntu) "Please, upgrade skype package to version 4.2.0.13" [Undecided,Confirmed] https://launchpad.net/bugs/1280109
<Noskcaj> dholbach, What's the text conflict? I didn't have that issue
<dholbach> Noskcaj, http://paste.ubuntu.com/6964186/
<Noskcaj> Could you try just resolving it locally? I think just take the new version, since it's an upstream change
<ochosi> Noskcaj: wait
<ochosi> those are our default settings, please don't mess with those
<Noskcaj> ok, could you check the changes then
<ochosi> link?
<ochosi> or is it only the conflict that was pastebinned?
<dholbach> ochosi, that's only the conflict
<dholbach> Noskcaj, to me it looks like the updated debian/patches/shimmer-layouts patch might have caused a bit of headache
<ochosi> yes, i think we should get rid of that debian patch, just haven't had the time to deal with that :/
<Noskcaj> ochosi, It's in debian, but i'm one of the maintainers there if you need a change
<dholbach> ochosi, Noskcaj: can you work together to agree on something?
<ochosi> dholbach: so, the "PLUGIN_AUTOSAVE: 1" can go in as an upstream change, it's a plugin that automatically saves tags every 15mins, so we want that
<dholbach> I'll leave it to you
<Noskcaj> ok
<Noskcaj> sponsor indicator now please?
<dholbach> I'm not an expert - if you agree on what to put in there, test it and tell me it's good to go, I'm happy to sponsor it
<dholbach> Noskcaj, one after the other - when I tried to build it 5m ago the panel build-dep wasn't in the archive yet
<ochosi> yeah, but simply dropping the debian-patch will potentially result in a lot of work, i didn't mean we should do that now
<Noskcaj> dholbach, Oh yeah, forgot that
<ochosi> i meant: i'll work with upstream to get these patches in so that you can get rid of the patch
<dholbach> ochosi, Noskcaj: can you update the MP once you resolved the issue and agreed on a way forward?
<Noskcaj> yep
<dholbach> thanks guys
<ochosi> thank you dholbach!
<ochosi> dholbach: btw, Laney advised me to also try bugreports/MR like the xubuntu-default-settings one, i'm not very experienced in this though, so just let me know if i messed up
<robert_ancell> slangasek, hey, gnome-session depended on ubuntu-session in case people didn't have ubuntu-desktop installed. These people will potentially have no session installed after upgrading to the new gnome-session binary. So, you can be on "sudo apt-get install ubuntu-desktop" reminding for them :)
<infinity> robert_ancell: Wouldn't it make more sense to have something like unity pull it in, if it's specific to ubuntu-desktop and not needed for GNOME?
<robert_ancell> infinity, yeah, we're doing that too, but that one takes longer to land
<robert_ancell> LSMSGCV: You just sent an email to
<robert_ancell> https://code.launchpad.net/~robert-ancell/unity/ubuntu-session/+merge/207346
<robert_ancell> wrong paste buffer there
<robert_ancell> infinity, so we'll just have a day or two where things could go wrong. I sent an email to ubuntu-devel to give people a heads up
<infinity> robert_ancell: Alright, so you intend to drop that dep as soon as unity is pulling it in, I guess?
<infinity> robert_ancell: That works.
<robert_ancell> yeah
<dholbach> Noskcaj, ochosi: I'm not quite sure I understand https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1282154 - there are a lot of branches for the same package - some of the MPs are approved, some are not - what exactly requires uploading? can you make sure all those branches are merged somewhere and you just propose one thing to be sponsored?
<ubottu> Launchpad bug 1282154 in xubuntu-default-settings (Ubuntu) "update default settings for trusty" [Undecided,New]
<ochosi> dholbach: the problem is that currently the devs who can merge to those branches are a bit MIA
<ochosi> so we cannot merge anything to xubuntu-default-settings ourselves
<ochosi> and the ppl whose review is still pending are those who could merge
<Laney> ochosi: you could merge into one branch yourself and ask for that to be sponsored
<seb128> shrug, daily CD build failed again on checkbox depends things
<Noskcaj> The other solution is i get my upload rights (and as a result get the push rights), but that's take 50 days now
<Noskcaj> *taken
<ochosi> Laney: sure, that's no problem, it has just evolved that way as separate MRs and i thought it should be kept that way
<ochosi> i'll try to take care of it asap and update that bugreport then
<dholbach> thanks ochosi
<ochosi> no problem, should i ping you again after the merges dholbach ?
<dholbach> ochosi, thanks - that'll make review a lot easier
<dholbach> yep, sounds good
<ochosi> thanks dholbach
<Laney> seb128: component-mismatches
<seb128> Laney, yeah, 2 days in a row
<Laney> you have the power!
<seb128> right, looking at it
<seb128> Laney, I promoted python3-plainbox, how do we get CD builds retried once the promotion is published?
 * Laney can do that
<ochosi> dholbach: ok, i've merged the different ones into a single merge-request, is it ok like this? https://code.launchpad.net/~ochosi/xubuntu-default-settings/trusty-updates/+merge/207376
<dholbach> ochosi, did you test build it and see if the settings all work as expected?
<dholbach> I'll take a look in a sec
<ochosi> for the merge-requests that i originally did, yes
<ochosi> i'm not really a packager, so i can't judge the changes of rev464 tbh
<dholbach> hum
<dholbach> anyone else from the Xubuntu crowd in here?
<ochosi> rev463 was tested, but not by me :/
<ochosi> i think Noskcaj had to take off, but bluesabre might be around in an hour or two
<dholbach> I'll review it as good as I can and put up test packages somewhere - could you ask a few xubuntu folks who are on trusty if they can test them?
<dholbach> I don't have a xubuntu installation around to test it
<dholbach> test packages are up at http://people.canonical.com/~dholbach/tmp/xubuntu/
<ochosi> thanks, that's very kind of you!
<ochosi> i'll test myself (i'm on trusty) and ask our testers too
<ochosi> and wow, that was quick :)
<dholbach> rock on
<infinity> pitti: *nudge*
<dholbach> ochosi, it looks like all the changes were merged into the branch successfully - let me know how the testing goes
<seb128> infinity, he's in Oakland, so probably not going to be online before a few hours
<infinity> seb128: Ahh.  And here I was, waiting up for him. ;)
<ochosi> dholbach: quick question, why would the greeter.conf file from rev462 end up as "lightdm-gtk-greeter.conf.dpkg-dist"?
<ochosi> (i installed your package)
<dholbach> ochosi, do you still have the installation log? did you do local modifications to ./etc/xdg/xdg-xubuntu/lightdm/lightdm-gtk-greeter.conf?
<dholbach> the package just ships /etc/xdg/xdg-xubuntu/lightdm/lightdm-gtk-greeter.conf but depending on what your local configuration looked like (local changes), it might be moved to dpkg-dist
<dholbach> you can diff the two files to see which differences there actually were
<ochosi> i used software center and i don't see any logs there
<dholbach> check /var/log/apt
<ochosi> yeah, nothing in the history or term.log
<ochosi> somehow ubuntu-software-center didn't write/keep any logs it seems
<ochosi> the .conf file is what was there before, the .dpkg-dist file has the changes done in rev462
<ochosi> i can downgrade the package, remove the dpkg-dist file and try to install with dpkg again if you think that'd help
<dholbach> yes, you could try that
<dholbach> and see what the other testers say as well
<seb128> Laney,  python3-plainbox | 0.4-4 | trusty | all
<seb128> Laney, can you retry the iso build?
<Laney> yup, thanks
<ochosi> dholbach: will do, thanks. so far i've tested the changes from rev 459, 460, 461 from your package (they all work)
<seb128> Laney, thanks
<seb128> Laney, can I see the build logs live somewhere or is that just "wait on an error email or an iso to be published"?
<dholbach> ochosi, I'll do a few other things now, but let me know when you and others concluded your testing and I'll go and upload (and update the branch)
<dholbach> thanks
<Laney> seb128: yeah, not live - they're copied out after the build is done
<Laney> to http://people.canonical.com/~ubuntu-archive/livefs-build-logs/trusty/ubuntu/latest/ and emailed
<seb128> ok, thanks
<ochosi> dholbach: just fyi, seems like software-center generated the dpkg-dist file. synaptic asks you what to do (keep old version or replace with pkg-maintainer-version) and "dpkg -i" just overwrites the old config. so rev 462 is actually ok...
<ochosi> and yeah, will leave you to do other things until i've got more tester-feedback. thanks again! :)
<rbasak> Almost done with this mini-php transition. Just three packages left, but need some help here please. Can someone sponsor a no change rebuild for graphviz and redland-bindings for me? And I think ffmpeg-php needs to go - it FTBFS already for porting reasons (seems non-trivial, and already removed from jessie), and is blocking the transition.
<doko_> Sweetshark, when do you plan your next lo upload?
<Sweetshark> doko_: libreoffice/libreoffice-l10n today if possible for there are urgent upstream fixes in that release.
<doko_> ok, thanks. just wan to have it built with python3.4 as the default
<Sweetshark> doko_: FWIW I saw your nlpsolver ping, will try to look into it still this week (together with other stuff in that package)
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> seb128: the build worked
<seb128> Laney, \o/
<seb128> Laney, the results are not copied yet though?
<Laney> I think that happens once per hour
<seb128> ok
<seb128> seems http://cdimage.ubuntu.com/daily-live/current/trusty-desktop-amd64+mac.manifest is updated
<seb128> good, gnome-control-center dropped from the default install, I was after that for some days
<seb128> there was a recommends left in gnome-bluetooth that I fixed tuesday, seems that did it
<Laney> cool
<Laney> got to get gsd out now
<seb128> yeah, I'm looking at that
<Laney> might just be totem-plugins
<seb128> seems to be
 * seb128 fixes that
<Laney> let me
<Laney> oh, ok!
<seb128> ok
<Laney> who? :P
<seb128> Laney, if you want to do it, please do
<seb128> I've enough landings I want to push through to keep busy
<Laney> ok
<seb128> thanks
<seb128> Laney, if you are not done yet, can you look at the patch on https://bugs.launchpad.net/ubuntu/+source/totem/+bug/1264547 while you are at it?
<ubottu> Launchpad bug 1264547 in totem (Ubuntu) "Apport Hooks Need Update gstreamer0.10 -> gstreamer1.0" [Undecided,New]
<Laney> okay
<seb128> thanks
<seb128> infinity, still around?
<seb128> is it fine to copy from https://launchpad.net/~canonical-libreoffice-builds/+archive/archive-staging to the trusty archive including binaries?
<seb128> or should we do a source copy instead?
<seb128> Sweetshark, ^
<infinity> seb128: I have no idea how that PPA is configured, but probably not fine, no.
<seb128> infinity, https://answers.launchpad.net/launchpad/+question/243446 if that helps
<seb128> infinity, it's supposed to be security updates friendly, so it should be archive friendly as well?
<seb128> wgrant, ^?
<infinity> seb128: Ahh, well, if it's "security-friendly", that would also mean that post-release pockets are turned off, which is devel-release hostile. :)
<wgrant> seb128, infinity: That PPA is a nonvirt and all archs, and no weird deps, so I don't really see a problem.
<infinity> wgrant: Does it also have all the right toggles on/off for a copyable archive with ddebs published to apache, etc? (see the kernel or security PPAs as examples)
<wgrant> infinity: Yes, that's just the nonvirt flag.
<wgrant> (totally insane, but true)
<infinity> wgrant: Right, I always forget and have to look at the ckt one.  So, build ddebs and publish ddebs both need to be off.  And then it builds ddebs. :P
<infinity> (So confusing)
<wgrant> Yup
<wgrant> The build ddebs flag puts them in the .changes
<wgrant> The publish ddebs flag additionally puts them in main/debug
<wgrant> With neither they'll just end up in Apache
<wgrant> (ew)
<infinity> To be security-friendly, it should also be set to build only against -security, of course.
<infinity> Which I still maintain is devel-hostile.
<wgrant> devel-hostile if there's a transition in -proposed, indeed.
<infinity> There are always transitions in proposed. :P
<infinity> seb128: Meh, just copy out the source.  If there's a transition it'll hang up on, I'd rather it get hung up and dealt with properly.  Unless there's some urgent reason we need it built right this instant.
<infinity> PPAs are cheap.  If we want to have one for libreoffice-devel and one for libreoffice-security, we should just do that.
<infinity> s/devel/proposed/
<infinity> Since it would also be fine for staging non-security SRUs.
<Sweetshark> infinity, seb128: This build is not urgent. Im essentially smoketesting this workflow, so that we _dont_ have these discussions _when_ its urgent.
<infinity> Sweetshark: Right, so I'd recommend a second PPA, so we're doing things "right".
<seb128> infinity, ok, I'm fine with source copy, I was just trying to spare some buildds cycles
<infinity> Sweetshark: a libreoffice-proposed that builds against all pockets for devel releases and SRUs, and a libreoffice-security that's used to stage security releases.
<infinity> And sane component mapping, but I assume wgrant did that last time he set this up.
<Laney> seb128: do you remember what this recommends is for?
<wgrant> infinity: I can't actual twiddle that bit on others' PPAs, but the owner can.
<infinity> Of course, with libreoffice constantly adding/removing language packages, this will run into the same skips-binary-new-and-lands-in-universe bug that kernels have. :(
<seb128> Laney, the g-s-d one?
<infinity> wgrant: Oh, I assumed commercial admins saw all those twiddles.  You're not actually all-powerful? :)
<Laney> yeah
<Sweetshark> infinity: understood (with the two ppas).
<wgrant> infinity: No, it's deliberately restricted to making changes that normal users shouldn't be able to make
<wgrant> infinity: (and also it lets you opt into seeing just about anything, but that's for debugging/support without invoking IS...)
<infinity> Sweetshark: You'll also need to set up the +edit-dependencies page for each.  One to use "security" and one to use "proposed", and then also set the "Ubuntu components" section to "Use the same components used for each source in the Ubuntu primary archive".
<wgrant> But write operations are pretty much restricted to heavily privileged bits.
<seb128> Laney, hum, not really, I guess it has to do with multimedia keys, eg https://bugzilla.gnome.org/show_bug.cgi?id=509438
<ubottu> Gnome bug 509438 in Plugins "media player keys plugin is causing gnome-settings-daemon to start" [Critical,Resolved: fixed]
<Sweetshark> infinity: right
<seb128> Laney,
<seb128> src/plugins/media-player-keys/totem-media-player-keys.c:			       "org.gnome.SettingsDaemon",
<Laney> but with G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START
<seb128> Laney, right, well it has integration with g-s-d so it recommends it I guess
<seb128> you can do that u-s-d | g-s-d
<seb128> or drop it
<seb128> I don't think it's very useful
<Laney> I think I will drop it
<Laney> ta
<seb128> yw
<seb128> that makes sense
<seb128> having desktop integration doesn't mean it should recommends/pull in the desktop it integrates with
<zequence> Would anyone like to sponsor this upload, please? It's a ubiquity plugin for Ubuntu Studio. Bug: 946591
<ubottu> bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
<bluesabre2> dholbach, ochosi: I can verify each of the fixes from http://people.canonical.com/~dholbach/tmp/xubuntu/
<bluesabre2> https://code.launchpad.net/~ochosi/xubuntu-default-settings/trusty-updates/+merge/207376
<doko> rbasak, I'm looking at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt  (end of page). Any hint about the failing ones?
<codfather> A quick question about SPICE support in 14.04 - is it going to be improved over that which was provided with 12.04?
<rbasak> doko: graphviz and redland-bindings presumably just need no change rebuilds - I don't have permission to upload them.
<rbasak> doko: ffmpeg-php looks more involved, since it already FTBFS. I think we should drop it from Trusty (it's been dropped from jessie)
<rbasak> doko: zeroc-ice I've rebuilt, but it seems to be a build issue that drops the LFS support. I haven't looked into it in detail yet.
<doko> rbasak, but why the rebuild at all? the php-api didn't check
<doko> rbasak, yes, removing the ruby1.8 zeroc binary
<rbasak> doko: on i386, php5-common used to provide phpapi-20121212. Now it provides phpapi-20121212-lfs instead.
<doko> ahh, ok. then rebuilding
<rbasak> Thanks!
<rbasak> doko: zeroc-ice has the phpapi dependency hardcoded, instead of using dh-php5 etc. If I just change the hardcoding, is that likely to break it? LFS-ness should be defined in the header files inside php5-dev, right? Or do I need to make sure that the macro definitions are usied during the build (which I think they aren't)?
<doko> rbasak, no clue ... only did fix the python3 issues in this package
<rbasak> OK, I'll dig deeper.
<dholbach> thanks bluesabre2
<dholbach> ochosi, bluesabre2: uploaded
<doko> rbasak, demoted ffmpeg-php, zeroc-ice should be the last one
<ogra_> oh my ...
<ogra_> systemd just swallowed network-manager
<doko> jtaylor, are you working on the qhull transition?
<ochosi> dholbach: thanks a lot!
<dholbach> ochosi, keep up the good work!
<ochosi> dholbach: will try to, in fact our seed also has a few merge-requests... :)
<dholbach> ochosi, I need to take care of a few other things now - I hope you can find somebody else in here who can help out now
<ochosi> dholbach: sure thing, thanks a lot for all you've done!
<ochosi> i know it wasn't very convenient sponsoring
<dholbach> anytime :)
<dholbach> no no, it was all right
<ochosi> ok, well thanks anyway :)
<shadeslayer> pitti_: ping
<shadeslayer> pitti_: thoughts on : https://bugs.launchpad.net/ubuntu/+source/kubuntu-notification-helper/+bug/1282095 : do you think "Proprietary drivers might be required to enable additional features" will work?
<ubottu> Launchpad bug 1282095 in kubuntu-notification-helper (Ubuntu) "driverevent makes incorrect assertations" [High,Triaged]
<mardy> cjwatson: hi! I've got a difficult question about click, please ping me back when you have a minute :-)
<hallyn> slangasek: good morning - bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734633 (which i mentioned in london) hasn't yet been addressed :(
<ubottu> Debian bug 734633 in libcap2 "Merge upstream 2.24" [Normal,Open]
<hallyn> did you ever hear back from the maintainer?
<hallyn> i'd sort of like to have it in trusty...
<cjwatson> mardy: ok
<cyphermox> ogra_: no, systemd just got some rewritten chunks to do... bridging, or whatever
<ogra_> well, matter of time i guess
<cyphermox> not in the way that it currently is
<xnox> ogra_: are you talking about sytemd-networkd? network-manager maintainer at redhat is pissed off about it =)
<cyphermox> it took years to get NM to the semi-working state it is in now
<cyphermox> so it will take years to get systemd-network to do half of what NM does
<ogra_> xnox, i thought so :)
<cyphermox> so it will be years more of this kind of conversation :)
<ogra_> xnox, next step ... sniff bash into systemd ;)
<ogra_> cyphermox, simply copy-paste job :P
<ogra_> *simple
<cyphermox> ahah yeah ;)
<cyphermox> ogra_: actually my bet is that systemd will either swallow emacs, or emacs swallow systemd
<ogra_> that sounds liek we could end up with some kind of moebius ...
<ogra_> if both try to swallow each other at the same time
 * cyphermox ducks, dons asbestos vest
<ogra_> might make the universe vanish or some such
<cyphermox> heh
<cyphermox> anyway, it's good that systemd does this
<cyphermox> some kind of nice competition going on there between systemd, n-m, connman... that might lead to some pretty cool innovation
<ogra_> heh, always thinking positive ... you are so canadian sometimes :)
<mdeslaur_> ogra_: he's just looking for an excuse to get out of maintaining nm :)
<ogra_> hehe
<ogra_> pitti_, for the demo images we would like to switch off apport on the phone ... do you think there is any issue with making /etc/default/apport writable by default on the phone image ?
<ThiagoCMC> Hello! Guys, I'm using Ubuntu 14.04 on my Desktop and, after the latest "aptitude update/safe-upgrade", Unity doesn't work anymore, only gnome-shell works now... Yes, I know it is devel branch but, I'm just curious...     =P
<psusi> #ubuntu+1 is the support channel
<jpds> People still use aptitude these days?
<ThiagoCMC> jpds, what do you use ?
<ThiagoCMC> psusi, tks!
<jpds> ThiagoCMC: apt-get.
<plugwash> does ubuntu have porterboxes available for packagers to debug their package's build failures on?
<plugwash> and if so what is the procedure for getting access to them?
<xnox> plugwash: there are no public porterboxes available.
<xnox> plugwash: which build failure in particular do you wish to debug?
<xnox> plugwash: if you are a dd/dm you can use debian porter boxes which should give you access to a few architectures which are present in ubuntu and are of similar environmnet.
<plugwash> I was asking as a result of a discussion in #debian-mentors on oftc relating to the failure of hexchat on ubuntu ppc64el
<plugwash> we suspect using dh-autoreconf would fix it but it would be nice to know such things before uploading
<pitti_> Good morning
<pitti_> ogra_: no, seems fine; one more brick in the wall of broken /etc :)
<Logan_> plugwash: I can take a look - I've fixed around 100 ppc64el failures at this point
<Logan_> plugwash: yes, we definitely need dh-autoreconf for that - do you want me to test and push a fix?
 * sney waves
<plugwash> Logan_, sney is the guy you was asking about the hexchat ppc64 failure over in #debian-mentors
<Logan_> sney: hey :)
<sney> hi
<Logan_> so I was just telling plugwash that dh-autoreconf (or a manual libtool file update) is necessary to fix hexchat's FTBFS on ppc64el
<Logan_> do you want me to push a fix to Ubuntu?
<sney> sure
<Logan_> okay one moment
<Logan_> well, more like 10 minutes
<Logan_> just so I can test and stuff :)
<sney> ok, I have to shower anyway
<ogra_> pitti_, great, thanks :)
<pitti_> ogra_: apport never writes that by itself, so we don't need the /etc/writable/ dance for that
<ogra_> pitti_, we need to make the file writable though ... just not the weird hack
<pitti_> right
<pitti_> ogra_: or, you just change the default in the image build process?
<ogra_> pitti_, that would change it for endusers too ....
<ogra_> we want to keep apporrt running for users
<ogra_> just not for demo images
<Logan_> sney, plugwash: uploaded: https://launchpad.net/ubuntu/trusty/+source/hexchat/2.9.6.1-1ubuntu1
<Logan_> I'll forward to Debian once we're sure it fixes the FTBFS on ppc64el
<pitti_> ogra_: I thought the demo images are different anyway (i. e. different build process)
<xnox> Logan_: also hexchat probably needs all of my usability patches =)
<Logan_> xnox: oh dear :P
<ogra_> pitti_, the same images, with one extra PPA
<Logan_> sney, plugwash: it built successfully - forwarding now
<ogra_> pitti_, this time we actually managed to get all essential stuff into the main image ... only some demoish extras are in the PPA
<pitti_> ogra_: so it seems the easiest would just be to upload apport to that PPA with the default file saying "disabled"?
<ogra_> pitti_, hmm
<ogra_> sounds like more work
<pitti_> ogra_: as you wish, both will work; it's just impossible to ever make a file non-writable again
<pitti_> hence uploading apport to the PPA is easier to revert
<ogra_> its easy to make a file non writable again
<sney> Logan_: groovy, thanks for your attention
<ogra_> unless you used the hackish approach ;)
<Logan_> sney: no problem, anytime :)
<ogra_> normal files just become readonly with a new image
<pitti_> ogra_: well, all of that is a complete hack :)
<ogra_> nah
<ogra_> is *design*
<ogra_> *g*
<pitti_> xnox: I read https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap and that sounds good, thanks for the write-up
<xnox> pitti_: cheers. it leaves out some implementation details.
<pitti_> xnox: AFAIU the p-t-r MP that should still work with the simplified ap approach that we discussed yesterday, right?
<xnox> pitti_: e.g. it doesn't matter what the binary package names / packaging of autopilot is for example.
<pitti_> i. e. only add the reexec thing and divert /u/b/ap instead of renaming it to ap3
<xnox> pitti_: correct. Althought, i think i failed to expand "p-t-r MP"
<xnox> =))))
<pitti_> xnox: https://code.launchpad.net/~xnox/phablet-tools/py2-3/+merge/205608
<pitti_> phablet-test-run merge proposal
<xnox> pitti_: correct, that one would still work.
<ThiagoCMC> jpds, hey man! apt-get installed the correct packages, Unity on 14.04 working again... I'll stop using aptitude...    =)
<ogra_> good move
<maxiaojun> command-not-found doesn't know about ruby2.0?
<xnox> maxiaojun: we didn't refresh command-not-found in ages.
 * ogra_ doesnt know about ruby2.0 either 
<maxiaojun> http://packages.ubuntu.com/trusty/ruby2.0
<maxiaojun> xnox: how are c-n-f data generated?
<smb> Just a quick question: is python3.4 known to currently have some Popen issues? Just saw some ignored exceptions during an upgrade,
<zequence> Would anyone like to sponsor this new upload, please? It's a fork of edubuntu-live, and should be simple enough to review. Bug: 946591
<ubottu> bug 946591 in ubuntustudio-live "Add ubuntustudio-live to trusty repositories" [Undecided,Confirmed] https://launchpad.net/bugs/946591
 * highvoltage looks at bug report
<highvoltage> zequence: also, good choice on basing on edubuntu-live ;)
<zequence> highvoltage: :)
<highvoltage> zequence: I'll be happy to sponsor it, anyone else from the ubuntu studio team who could also +1 it?
<bdmurray> my system is refusing to accept keyboard input on trusty and I've worked around this before by clicking the input method thing on the lightdm screen and then I can type.  however, I've no cursor either on this system.  Any ideas on how I can log in?
<zequence> highvoltage: Perhaps this is enough? It's the blueprint for ubuntustudio-live https://blueprints.launchpad.net/ubuntustudio-live/+spec/ubuntustudio-live-t
<seb128> bdmurray, try pressing the power button, it should trigger a session dialog
<zequence> highvoltage: The team is kind of small right now, and being the project lead, I feel I can vouch for the thing
<seb128> bdmurray, that might unblock it
<highvoltage> zequence: ok, uploaded
<zequence> Great :)
<bdmurray> seb128: it raised the dialog but I can't interact with it
<seb128> bdmurray, esc doesn't work?
<bdmurray> seb128: no
<bdmurray> seb128: I've tried removing usb devices and plugging them back in but that didn't help either
<hallyn> rbasak: rharper: the --disk command in uvt-kvm create, what does it take?  a filename?
<bdmurray> oh well my keyboard doesn't work in recovery mode so its probably something low-level
<jtaylor> doko: re qhull yes
<ahasenack> hi guys, I uploaded a package to trusty about an hour ago, and today is feature freeze, I'm just not sure if it means the freeze already started (0:00UTC today, then), or if today is the last day (I have until 23:59UTC)
<pitti> barry, xnox: where does it drop the -E option in https://code.launchpad.net/~barry/autopilot/reexec/+merge/203765 ?
<pitti> I thought it would need to do that to consider $PYTHONPATH from p-t-r after reexecing to py2
<mlankhorst> ahasenack: see topic ;-)
<mlankhorst> archive: open
<ahasenack> ah, that bit
<ahasenack> thanks!
<ahasenack> it was uploaded to proposed, so I guess a bot will soon move it to main?
<ahasenack> https://launchpad.net/ubuntu/trusty/+queue?queue_state=3&queue_text=landscape-client
<barry> pitti: i think xnox was testing something else?  that branch doesn't drop the -E
<shadeslayer> pitti: what does the jenkins instance use to run upgrade tests? LXC?
<pitti> shadeslayer: LXC for most tests, but there are a couple of _vm tests which use a full qemu
<pitti> shadeslayer: we want to minimize the QEMU ones, but we still need some for doing actual reboot tests
<xnox> pitti: os.rexec only rexecs with arguments "/usr/bin/autopilot"
<xnox> pitti: it does not re-exec with "-E"
<shadeslayer> yofel: ^^
<shadeslayer> pitti: we're getting these errors on our tests http://paste.ubuntu.com/6966771/
<xnox> barry: it does, it's just not obvious =)
<pitti> xnox: it looks like it execs "python2 sys.argv", wouldn't that include the -E?
<xnox> pitti: no, it would not.
<yofel> pitti: note: that ^ error happens on the first run when there's no upgrade container bootstrapped yet
<barry> xnox: comments in the code would probably help :)
<xnox> pitti: sys.argv only has /usr/bin/autopilot and onwards, not starting from /usr/bin/python3 -E ...
<pitti> jibel: does http://paste.ubuntu.com/6966771/ ring a bell?
<xnox> barry: # black magic below...
<pitti> jibel: (from yofel/shadeslayer above)
<xnox> barry: # end black magic?! =)
<pitti> xnox: ah, thanks
<ahasenack> sorry, network failed
<jibel> pitti, shadeslayer I've never seen this before
<pitti> yofel: is that a run on your machine, or in jenkins.q.u.c.?
<yofel> pitti: currently on mine as we first wanted to test the profiles before mering
<pitti> yofel: especially in saucy and earlier, LXC might need some additional tweaks for cgroups/apparmor/etc.
<jibel> shadeslayer, can you paste your profile (DistUpgrade.cfg) , I'll try it here
<yofel> ah, are those listed somewhere?
<yofel> the host is saucy
<shadeslayer> jibel: the best would be to branch lp:~kubuntu-dev/auto-upgrade-testing/auto-upgrade-testing :)
<jibel> shadeslayer, thanks
<ahasenack> hi, do I need to do something to move a package I uploaded to trusty ~1h ago from proposed to main, or does it happen automatically? It used to be automatic, but since today is feature freeze, i'm following closely :)
<slangasek> feature freeze is an advisory freeze, it doesn't change anything on the archive side
<slangasek> proposed->release pocket should all be automatic - what package?
<slangasek> (fwiw, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html shows the status of package migrations, but it's not the easiest to interpret)
<ahasenack> slangasek: https://launchpad.net/ubuntu/trusty/+queue?queue_state=3&queue_text=landscape-client
<slangasek> ahasenack: ok, the above page shows that it's waiting for arm64 to catch up
<slangasek> but there are no obvious blockers beyond that
<ahasenack> slangasek: I see, thanks!
<tjaalton> slangasek: we're probably not getting new openldap from alioth git for trusty? ;)
<slangasek> tjaalton: man... I haven't even had a chance to look at the openldap git repo yet
<tjaalton> hehe
<slangasek> tjaalton: I was hoping someone else would pick this up :/
<tjaalton> right
<tjaalton> the list has been silent, no one seems to care
<tarpman> tjaalton: fwiw thanks for working on that... I've been watching and hoping it would make it to trusty, but too busy to contribute
<tjaalton> tarpman: yeah I was meant to get this in first and then maybe add a separate library built against libnss.. (for 389ds) but meh
<slangasek> tjaalton: so looking at the git repo, there don't seem to be any tags for upstream releases?
<tjaalton> slangasek: oh you want those too?
<slangasek> is the 'upstream' branch a mirror of the actual upstream?
<tjaalton> yes
<slangasek> tjaalton: ultimately I want things that work with pristine-tar etc
<rharper> hallyn: uvt-kvm --disk should take a size, it's how big to make the qcow2 image for the VM; it uses the release cloud image as a backing file
<tjaalton> slangasek: yeah there are several workflows it seems :)
<hallyn> rharper: yup, already updated my tree
<hallyn> also implemented snapshot.
<hallyn> running a new set of tests now
<rharper> nice
<tjaalton> slangasek: so one is to keep the upstream branch as is but import the tarball only to pristine-tar
<tjaalton> I just tend to use uscan
<tjaalton> if there are tarballs that can be used
<slangasek> tjaalton: right, if the tarball has to be downloaded separately from the package git repo, I consider that a bug
<slangasek> and in this case, we have modified tarballs anyway
<pitti> thomi, xnox: https://code.launchpad.net/~autopilot/autopilot/py3-for-realz/+merge/207540
<pitti> xnox: it's still missing tests, and that breaks one test case, but thomi will look into that
<pitti> that's now barry's reexec trick plus the diversion packaging
<tjaalton> slangasek: indeed, and there's get-orig-source for the initial tarball build
<hallyn> jibel: hi - i've opened mp for https://code.launchpad.net/~serge-hallyn/auto-upgrade-testing/uvtool (and done some updates since then).  auto-upgrade-tester works for me, auto-install-tester is running but going good so far
<Ryu_Fitzgerald> I have a queston about ubuntu and I think only someone with a development level knowledge would know this
<Ryu_Fitzgerald> When you boot the computer, it writes where /dev/dvd looks.  Where is the file on the operating system that does this?
<roadmr> Ryu_Fitzgerald: it's done by a udev rule in /etc/rules.d/70-persistent-cd.rules
<sarnold> /etc/udev/rules.d/..
<roadmr> sarnold, Ryu_Fitzgerald: right, /etc/udev/rules.d (my bad)
<Ryu_Fitzgerald> i see a comment about the file being automatically generated.  Will this file get wiped on boot?
<roadmr> Ryu_Fitzgerald: there's a comment about how to add your rules and have them stick over reboots
<jtaylor> hm did the latest kernel update break perf?
<jtaylor> its saying please install -tools, but it is installed
<Ryu_Fitzgerald> i am not seeing any comment about rebooting or booting.  Where did you see it?
<Ryu_Fitzgerald> roadmr, i don't see that comment reguaurding how to make the rules stick through reboot
<Ryu_Fitzgerald> roadmr?
<Ryu_Fitzgerald> speaking of which how did you make you text light up for me
<Ryu_Fitzgerald> was it something like this
<Ryu_Fitzgerald> roadmr:  or what
<Ryu_Fitzgerald> Also i am not familiar wih how  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:90:f5:ea:f6:ba", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0" format.  Could you please explain it
<sarnold> Ryu_Fitzgerald: most irc clients will highlight for the user's nickname
<Ryu_Fitzgerald> did this highlight yours,   sarnold,
<sarnold> Ryu_Fitzgerald: people sending messages just need to use the nickname and for most people it will magically be awesome :)
<sarnold> Ryu_Fitzgerald: yes
<sarnold> Ryu_Fitzgerald: most clients also offer something like /lastlog -hilight which makes it easy to see all messages sent to you that are still in the scrollback buffer.
<tarpman> Ryu_Fitzgerald: about the directives in the rules file: man 7 udev or http://manpages.ubuntu.com/man7/udev
<Ryu_Fitzgerald> am i correct in assuming that once i finish reaeding through this/etc/udev/rules.d/70-persistent-net.rules and figure out how to construct a rule.  I would place the rule here?
<roadmr> Ryu_Fitzgerald: my 70-persistent-cd.rules says: "however you are also free to add your own entries provided you add the ENV{GENERATED}=1 flag to your own rules as well." I suggest you google "udev rules" for more information on how they work
<roadmr> Ryu_Fitzgerald: right, you should be able to put your stuff there
<seb128> hum, arm64 seems to be behind, is there an issue or are we supposed to have only a couple of builders?
<hallyn> man this is gonna take forever:  after an hour, i'm at Package dri2-utils: 441 of 7342 (6.006538.2)
<sarnold> hallyn: can you change to using e.g. mirror.anl.gov? it seems to be ten to twenty times faster than canonical mirrors for me
<jibel> shadeslayer, I reproduce your problem with kubuntu upgrade on trusty, I'll look into it.
<hallyn> sarnold: not sure.  i don't think netowrkis the issue though.  i think the install-tester starts a new install for every package install test
<sarnold> hallyn: SYN SYN ACK ACK HTTP GET ... oh my god that'll take forever
<hallyn> jibel: how long does an auto-install-test run usually take?
<Ryu_Fitzgerald> in this statement, what does hdc mean?  KERNEL=="hdc"
<hallyn> sarnold: ah no, it doesn't start a new vm each time - it does ssh $name apt-get install package; ssh $name apt-get remove package
<hallyn> on some packages i assume that destroy; recover snapshot; start vm would be faster :)
<Ryu_Fitzgerald> i also see KERNEL=="hdb"
<hallyn> on the bright side every package has passed so far
<jibel> hallyn, thanks for the MP, I'll review it. We don't use auto-install-tester, you can just ignore it. If auto-upgrade-tester works with uvtool it's fine
<hallyn> awesome
<sarnold> hallyn: time for a vacation? :)
<hallyn> but yes, auto-install-tester seems to be working so at least i don't appear to have regressed thigns there :)
<Ryu_Fitzgerald> i am thinking this is the command i want to write but i don'tknow what hdc means.  KERNEL=="hdc", SYMLINK+="/dev/dvd /dev/sr0"
<hallyn> sarnold: as soon as stgraber tags lxc 1.0, i'm quitting computer science
<sarnold> hallyn: I hear that.
<Ryu_Fitzgerald> or is this what I am looking for?  KERNEL=="sr0", SYMLINK+="dvd"
<Ryu_Fitzgerald> does the rule command i just pasted make a linking for /dev/dvd to /dev/sr0?
<arges> bdmurray: hi
<stgraber> Ryu_Fitzgerald: yes
<Ryu_Fitzgerald> thankyou
<Ryu_Fitzgerald> i'll try it out, hopeuflly it will work
<bdmurray> arges: hey
<Ryu_Fitzgerald> thankyou, it works great
<slangasek> hallyn: Debian bug #734633> so there's been no response, yes... remind me, was this something we needed in for trusty?
<seb128> slangasek, hey
<slangasek> seb128: hey there
<hallyn> slangasek: yes, without it userspace wont' knwo (from include files) about newer capabilities
<seb128> slangasek, do you know if there is any way to get gnome-session "unstalled on upgrade if nothing depends on it"?
<seb128> slangasek, I'm discussing with robert_ancell the rename and whether it's going to lead upgrades to get gnome-shell installed at some point or to have gnome-session uninstalled
<slangasek> hallyn: ok, so did you want this sponsored into trusty before FF?  (also, why are you not a core-dev?)
<slangasek> seb128: probably warrants a hook in update-manager, I guess?
<hallyn> slangasek, yes, that'd be great.  I'd really hoped to get it through debian instead, but...
<slangasek> seb128: are those changes something that's happening in 14.04, or is that next-cycle stuff?
<seb128> slangasek, do you think the hook is enough?
<seb128> slangasek, I think robert_ancell mentioned wanting to add the depends next cycle
<seb128> robert_ancell, ^
<slangasek> seb128: as long as we have things moreor less as-is for
<slangasek> seb128: for 14.04, I think an update-manager hook is enough
<robert_ancell> yeah, keep as is until post 14.04
<seb128> slangasek, k, thanks
<slangasek> seb128: does gnome-session show as manually or automatically installed for you?
<seb128> robert_ancell, let's go for that then
<slangasek> (apt-mark showmanual | grep gnome-session)
<seb128> slangasek, let me check on a system where it's still installed :p
<seb128> slangasek, it's listed in apt-mark showmanual on a trusty stock install (I think that vm is mostly stock)
<slangasek> ok, interesting/annoying
<seb128> yeah, what I though...
<slangasek> I think that's /etc/apt/apt.conf.d/01autoremove
<slangasek> so, update-manager is the only reasonable solution AFAICS; we don't exactly want to make some other package to conflict with gnome-session to force its removal
<seb128> slangasek, well, gnome-session is not outdated/deprecated, it's just for GNOME sessions only
<seb128> we don't want to remove GNOME on update for those usingit
<slangasek> yes, exactly
<seb128> I wanted to rename the binaries to gnome-shell-session and ubuntu-session and have gnome-session being a dummy depending on ubuntu-session | gnome-shell-session
<seb128> but robert_ancell thinks that's too much/not needed
<seb128> well, we can see if the update-manager way works and adapt from feedback during beta time
<robert_ancell> seb128, slangasek the safest logic is probably uninstall if don't have gnome-shell / mutter etc installed
<robert_ancell> then gnome-session doesn't actually do anything useful
<seb128> I don't know if if we the logic for "to things if <installed>"
<seb128> to->do
<shadeslayer> jibel: note that we have our own modifications to the code, so maybe that's buggy
<xnox> i think we might have a consistent / matching bootsplash logo across: netboot, desktop, plymouth for the first time.
 * xnox goes to check server images.
<ogra_> xnox, now just make the phones work too :)
<rbasak> hallyn: disk size, in GB.
<hallyn> rbasak: thanks :)  done with that code for now
<hallyn> trying to decide whether to update cgroup-bin to use cgmanager, or just package up some scripts to do the useful bits (cgcreate, cgexec, cgfreeze...)
<bluesabre2> thanks dholbach!
<doko> cyphermox, please could you have a look at http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg (network-manager recommends)
#ubuntu-devel 2014-02-21
<infinity> pitti: *poke*
<pitti> infinity: hey
<infinity> pitti: trusty-adt-libproxy-ppc64 <-- Why is that not using the dpkg arch (ppc64el)?
<infinity> pitti: ppc64 is very much not the same thing. :)
<infinity> pitti: (And don't go away, I have more important things to discuss)
<pitti> infinity: ah, thanks for pointing out; the view name etc. is right, just not the suffix; I asked jibel to rename them
<infinity> pitti: Alright, cool.  Simple annoyance, that one.
<infinity> pitti: So, the more important thing... We need to completely flush all the ppc64el ddebs/indices from germanium and re-import fresh from the buildds.
<infinity> pitti: My cron job that cleans old ddebs is intentionally off for now, so there should be a full set avaiable to scrape.
<pitti> infinity: ah, good; setting that off now
<infinity> pitti: Just make sure it's actually flushed sanely first, since I know ddebs operated on a naive first-come-first-published basis, and we've, of course, rebuilt the whole world with identical versions/filenames.
<pitti> infinity: I can make sure that the latest build wins, that ok?
<infinity> pitti: Still not quite ideal, as you may have ddebs that matchs things that don't exist anymore, as we had new FTBFSes.
<infinity> pitti: Is flushing really hard?
<pitti> *meh* need more interweb tubes here
<pitti> infinity: no, it's not; I meant the order of re-pulling them from the buildds
<infinity> pitti: If so, then yeah, latest-build-wins would probably work for now, and we can not care about those few.
<infinity> pitti: '*_ppc64el*deb' please.  Your will catch a few packages with ppc64el in the name on other arches. :P
<pitti> *nod*
<infinity> pitti: And if you go back a week, you should be fine.  Might want to limit it to just the 10 ppc64el buildds, so you're not reimporting EVERYTHING.
<pitti> infinity: hm, lp.builders objects have no .arch property or something like that? meh
<pitti> so, 'ppc64el' in .title
<infinity> pitti: Title should do.  Or just limiting to fisher*, denneed* and postal*
<cyphermox> doko: I can, but it's been that way forever, this isn't something I added recently
<cyphermox> that said, it's not a reason to keep this old thing around
<pitti> infinity: purged, slurping ddebs from the ppc64el builders (the title hack works)
<infinity> pitti: Huzzah.  Let me know when the slurping appears to have been successful, so I can un-hack my cronjobs and let them purge again.
<pitti> infinity: ah, it's now at feb 18; I guess that's the day of the Mass Rebuild Of Death, given how much time it spends on that one :)
<pitti> I started with Feb 14
<infinity> pitti: Started on Feb17, but definitely more packages in Feb18, yeah.
<pitti> infinity: all slurped; rebuilding indexes now
<infinity> pitti: \o/
<infinity> pitti: Thanks.
<ScottK> slangasek: Kubuntu wants Qt5 5.2 in.
<slangasek> ScottK: ok.  Is any further testing coordination needed wrt Kubuntu, or should we just get it in ASAP?
<ScottK> slangasek: Get it in ASAP.
<ScottK> We mostly want it in 14.04 so we can backport KDE Frameworks 5 after it's released.
<slangasek> ok
<ESphynx> hey guys :) still hope to have packages brought in? ;)
<dholbach> good morning
<ion> that
<ESphynx> hey nisstyre :)
<ESphynx> good morning dholbach
<dholbach> hi ESphynx
<ESphynx> dholbach: archive is still open eh?
<dholbach> ESphynx, I guess - I haven't heard otherwise
<ESphynx> I'm praying my release makes it in somehow :P
<fishor> hello devs. http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/ usually provide lates vanilla build. but last build there is 3.13.0
<fishor> should it be this way?
* Laney changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jhenke> hi guys
<jhenke> cjwatson do you have some time to look at bug #1272664 that had been assinged to you?
<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
<tkamppeter> OdyX, hi
<infinity> slangasek: Argh.  The new libcap-dev includes <linux/xattr.h> which conflicts with <sys/xattr.h>, which is the cause of your qemu FTBFS across the board.
<infinity> slangasek: I was about to blame my new glibc until I looked closer.
<infinity> slangasek: Though, it might be that I need to work around this in glibc headers with some undefs, like I did for P_* :/
<infinity> I really need to find the time to do some broader comparison of kernel/glibc type mismatches here.
<infinity> slangasek: Something like this might minimize the damage for now: http://paste.ubuntu.com/6970443/
<ScottK> pitti: Are you dealing with things like https://jenkins.qa.ubuntu.com/job/trusty-adt-postfix-armhf/ or should lamont and I care?  It looks like something test environment related rather than a package issue.
<rbasak> ScottK: did you see the announcement?
<cjwatson> jhenke: probably not for a while, sorry, am buried in libclick
<kenvandine> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: kenvandine
<jhenke> cjwatson okay, do you know anybody else who can help with that issue? If not, I can wait, just want to avoid that the bug get's completely forgotten
<ScottK> rbasak: I did (after I wrote that).
<stokachu> anyone willing to sponsor/upload bug 1282837 for me?
<ubottu> bug 1282837 in Ubuntu Trusty "FFe: new package cloud-install" [High,Confirmed] https://launchpad.net/bugs/1282837
<kenvandine> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<didrocks> stgraber: hey, once you have a second, I used a new fakeupdate parameter to test animation changes and so on, is it fine with you? https://code-review.phablet.ubuntu.com/#/c/183/
<mterry> pitti, what is the state of the art for faking a text message?  Is is still manually sending javascript to the phonesim daemon?
<pitti> Good morning
<mterry> (on the phone)
<mterry> pitti, good morning  :)
<pitti> mterry: by and large yes, but have a look at the messaging-app AP tests; they have a helper function which is by and large just receive(sender, text)
<mterry> pitti, OK will steal  :)  thanks!
<stgraber> didrocks: I already gave my +1 to sergiusens
<pitti> ScottK: the "AttributeError: 'NoneType' object has no attribute 'quit'
<pitti> ScottK: how is that an infrastructure problem?
<pitti> ScottK: it could be yet another fallout from switching default python3 to 3.4
<pitti> I haven't yet waded through all the failures
<didrocks> stgraber: ah, thanks :)
<smb> pitti, Just since you mention that, I saw those relatively often in update output
<pitti> another fallout is that a lot of packages' postinst now have some AttributeError in __del__()
<smb> Oh so that one actually
<rsalveti> xnox_: hey, would need gcc-i686-linux-androideabi or similar to be able to build the x86 emulator :-)
<ScottK> pitti: No idea.  I just know it worked last week on i386/amd64 and there's nothing armhf specific in the failure.
<pitti> ScottK: yeah, last week we still had py 3.3
<brendand> barry, i have a python itch to scratch and google isn't helping me - maybe you know the answer. it seems python memoizes recursive functions, but i was wondering how/when it does this - surely it's not as simple as when the function is called with the same inputs?
<ScottK> Right, so by "infrastructure", I meant not the package.
<pitti> ScottK: at least it worked on x86 yesterday
<pitti> ScottK: it might also be possible that it's due to qemu vs. LXC; the LXC runner is quite a bit stricter (it has less dependencies pre-installed, so a lot of failures are due to insufficient binary and/or test dependencies)
<pitti> s/less deps/less packages/
<pitti> and s/less/fewer/, but meh @ grammar :)
<pitti> ScottK: anyway, as I wrote on the annoucement this is pretty much a "throw everything against the wall and see what sticks" run, we don't gate on it for now
<barry> brendand: "memoizes recursive functions"?   not really sure what that means.  it does keep a recursion count and  will throw a RuntimeError if the recursion depth is exceeded.  sys.getrecursionlimit() and sys.setrecursionlimit() control that
<brendand> barry, memoization is where you store the result of a call in a table and don't bother to call the function if the result for the same inputs is already there
<brendand> barry, but i just realized the function i was working on wouldn't trigger this anyway
<xnox_> rsalveti: ok. I'll try to cook that.
<rsalveti> xnox_: thanks
<barry> (there are actually multiple meanings of "memoize"; in the python context i's mostly closely associated with pickling)
<barry> brendand: python doesn't memoize in the sense that you're describing, however it's pretty trivial to write a descriptor that does that for you.  that's used some times for expensive operations, but you have to be careful about the semantic differences it can imply
<xnox_> barry: doko: what's up with subprocess NoneType stuff? it seems to be triggered by py3compile.
<barry> xnox_: i've seen that too.  haven't had time yet to investigate
<xnox_> barry: it appears that __del__ of subprocess does "if not getaatr(self, '_child_created', False)
<doko> xnox_, didn't look at it yet
<xnox_> but.... self is NoneType?!
<dholbach> hey... can somebody check if ubuntu-html5-platform-3.4-dev (from the cordova-ubuntu-3.4 source package) is downloadable/installable in trusty proper?
<barry> xnox_: i wonder if this is happening at interpreter shutdown time.  maybe during cycle breaking by the gc?  when python shuts down it first sets all module attributes to None, but doesn't clear out its namespace.
<dholbach> according to https://launchpad.net/ubuntu/+source/cordova-ubuntu-3.4/3.4~pre3.r19 it should be there for amd64/i386/armhf - and not in binNEW
<dholbach> ^ maybe an archive admin can shed some light on this?
<dholbach> seb128, are you still around and know what might be the problem?
<dholbach> seb128, alex-abreu: false alarm
<dholbach> Get:1 http://archive.ubuntu.com/ubuntu/ trusty-proposed/universe ubuntu-html5-platform-3.4-dev amd64 3.4~pre3.r19 [2157 kB]
<dholbach> Fetched 2157 kB in 2s (965 kB/s)
<dholbach> alex-abreu, ^ we're fine
<Laney> it's not migrating to release though
<dholbach> ah, you're right
<Laney> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#cordova-ubuntu-3.4 is telling you that there's a leftover cordova-ubuntu-3.4-dev package in trusty-proposed
<alex-abreu> dholbach, ah its in proposed!
<dholbach> pbuilders have proposed enabled
<dholbach> Laney, what can we do?
<Laney> an archive admin will need to remove it
<dholbach> alex-abreu, can you maybe try talking to anyone of these folks about it? https://launchpad.net/~ubuntu-archive/+members#active
<alex-abreu> jdstrand, might be around
<dholbach> alex-abreu, got to go - drop me a mail if you need anything from me later on!
<alex-abreu> dholbach, sure
<alex-abreu> dholbach, I'll ry to unblock it
<dholbach> thanks a bunch!
 * dholbach hugs alex-abreu and Laney
<dholbach> have a great weekend evryone
<Laney> you too
<Laney> bye!
<xnox_> infinity: why do you hate venezuela? =)
<xnox_> # localedef -c -f UTF-8 -i es_VE es_VE.UTF-8
<xnox_> LC_MONETARY: value of field `int_curr_symbol' does not correspond to a valid name in ISO 4217
<xnox_> infinity: filed bug 1283152
<ubottu> bug 1283152 in eglibc (Ubuntu) "es_VE localedef is broken" [Undecided,New] https://launchpad.net/bugs/1283152
<jtaylor> is there some summary page of the difference between to adt runs in jenkins?
<jtaylor> artifacting dpkg -l or so would be useful
<jtaylor> then one could diff it
<cjwatson> looks like jdstrand has cleaned up the cordova-ubuntu-3.4-dev binary
<slangasek> infinity: ah, it's libcap-dev's doing?  ok - I think we should make hallyn fix it then, since he's the one who said we needed libcap updated :)
<hallyn> sup?
<dbarth> hiya, i'm looking for an archive admin to help unblock a package that is stuck in proposed
<alex-abreu> dbarth, done already :)
<dbarth> oops, scratch that,
<dbarth> sorry
<hallyn> slangasek: I'm not seeing anything obvious;  are you saying ppc64el is broken by the new libcap?
<slangasek> hallyn: qemu FTBFS because of the new libcap
<slangasek> so I thought you might like to have a look ;)
<hallyn> "I don't see how that relates to me"
<hallyn> i'll take a look, thanks
<jdstrand> cjwatson: I did
<jdstrand> and now cordova-ubuntu-3.4 has migrated
<Laney> happy daze
<hallyn> slangasek: well holy cheeseballs, /usr/include/linux/capability.h has mis-matched parens in the last define
<hallyn> oh no
<hallyn> i need new glasses
<jtaylor> hm libc 2.19 broke scipy :(
<jtaylor> any other known fallout by the upload?
<jtaylor> infinity: ^
<jtaylor> hm it might actually be that it fixed its math functions but scipy tests used wrong ulps
<infinity> hallyn: Check backscroll for my explanation to Steve.
<infinity> hallyn: Long story short, something like this would work around the mismatched macros between linux headers and userspace headers: http://paste.ubuntu.com/6970443/
<infinity> jtaylor: Nothing that I know of yet.
<hallyn> infinity: so you can't define something in enum that is #defined?
<hallyn> i wonder if there is a reason for those to be an enum
<infinity> hallyn: The reason for them being an enum is actually to guard against the inverse.
<infinity> hallyn: Which, I suppose, means one could also just include sys/foo.h before linux/foo.h to sort the issue.
<hallyn> oh i see now.  i simply could not reproduce the issue in a standalone c program, finally did
<hallyn> so yeah i think #include sys/foo.h is the way to go...
<infinity> jtaylor: And yes, jsm has been working hard upstream on making libm be less math challenged, so it's possible that some things that rely on its bugs may be a bit out of whack.
<jtaylor> well scipy tests against a infinite precision library
<jtaylor> so I chances are its worse now
<infinity> jtaylor: (I'd content that anything that relies on exact values from libm was always buggy to start with, since libm makes approximation commitments, not precision... If you need precision, you need something slow and correct, like GPM)
<jtaylor> but I'm still trying to extract the inputs :/
<infinity> s/content/contend/
<jtaylor> well C99 appendix gives bounds on what libc should provide
<jtaylor> most don't follow it though
<jtaylor> glibc is actually one of the better ones
<infinity> Yeah, we're working on being more compliant than we were. :)
<jtaylor> I still ahve a huge stack of complex trigonometry bugs to fowrard to glibc :/
<hallyn> infinity: (I don't have upload rights) do you  mind pushing the new libcap with that change?  I've emailed amorgan (the upstream maintainer) to let him know, in the meantime
<infinity> hallyn: Sure.  Might be worth a quick qemu test build against such a mangled header to make sure it doesn't blow up in new and exciting ways.
<infinity> hallyn: But that should do the trick.
<hallyn> yeah, and my first attempt failed,
<hallyn> but i may have left some garbage,
<infinity> hallyn: And by "that change", I assume you mean http://paste.ubuntu.com/6972335/ ?
<hallyn> i did.  if it turns out that didn't jsut break my qemu build even more
<hallyn> well hey, btrfs really *has* sped up on fsync in trusty
<infinity> It shouldn't, but I'll spin up a test here for paranoia's sake.
<doko> Trying easy from adconrad: ruby-defaults/1:1.9.3.4 ruby2.0/2.0.0.484-1ubuntu1 ruby1.9.1/1.9.3.484-2ubuntu1
<doko> leading: ruby-defaults,ruby2.0,ruby1.9.1
<doko> failed: ruby-defaults
<doko> but doesn't show anything anymore ...
<hallyn> all right.  it's noticably faster, but still eatmydata-worthy
<pitti> thomi: https://blueprints.launchpad.net/ubuntu/+spec/core-1311-python3-roadmap
<hallyn> infinity: looks like i'd left something in a bad state :) in a new environment it builds fine with that change
<infinity> hallyn: Yeah, getting to that conclusion here too.   Slowly.
<hakermania> Hello there! I am looking for a sponsor for my package, Wallch. If you want to sponsor it or you know someone interested, please let me know! https://bugs.launchpad.net/ubuntu/+source/wallch/+bug/1282830
<ubottu> Launchpad bug 1282830 in wallch (Ubuntu) "FFE: Wallch 4.0" [Wishlist,Confirmed]
<rcj> hallyn, if you get a qemu-util package for ppc64el built while you're working on this, could you put it up for me to grab?  I'm blocked at the moment waiting for qemu-img
<infinity> rcj: That will fall out from my libcap upload.
<infinity> (As in, the change you want is uploaded but FTBFS)
<rcj> infinity; thanks.  just trying to determine the fastest route to get back up and running with qemu-img.
<infinity> hallyn: Uploaded, I'll retry qemu when it's published.
<jtaylor> mh ok glibc 2.19 produces worse results
<infinity> jtaylor: :(
<infinity> jtaylor: In which function(s)?
<jtaylor> still checking where exactly, but mpmath is correct and the error is significant
<infinity> jtaylor: Could it, perhaps, be a need for -ffp-contract=off somewhere?
<jtaylor> I don't have fma
<jtaylor> also thats off by default in gcc4.9
<jtaylor> oh we are still 4.8
<infinity> 4.8 defaults to fast.
<jtaylor> 4.9 not, at least in c99 mode
<jtaylor> but its not out yet, got confused as I'm running with that since a while :/
<infinity> hallyn: http://launchpadlibrarian.net/167203424/libcap2_1%3A2.24-0ubuntu1_1%3A2.24-0ubuntu2.diff.gz has a slightly more upstream friendly explanation than just "Argh" in the patch header.
<jtaylor> oh no it goes into fortran code :(
<hallyn> rcj: I'm afraid I don't have any, sorry.  But should be building in archive soon iiuc
<hallyn> infinity: but to prevent more failures later, should the libc6 version put the enum inside a #ifndef XATTR_CREATE?
<infinity> hallyn: Possibly, yes.  I did this for another set of defines earlier for similar fallout.
<infinity> hallyn: But I think I need to bring this up upstream to see if we need to be doing a full userspace/kernel macro clash audit.
<hallyn> upstream glibc?
<infinity> hallyn: Yeah.
<infinity> hallyn: I still blame the kernel for its defines not being enum-guarded, but even if we get that fixed, glibc needs to work with some subset of old kernels, so we might need to sprinkle some idef guards around too.  Fun, fnu.
<apw> infinity, enum guarded
<apw> ?
<infinity> apw: Remember the P_ALL, etc issue we discussed a while back?
<apw> yeah i remember that issue, painfully
<infinity> apw: Right.  Basically ran into a redux of the same thing when one includes linux/xattr.h and sys/xattr.h out of order (ie: kernel before userspace).
<infinity> Not sure if this is spelled out somewhere as a big no-no (I mean, other than including kernel headers at all being a no-no), but there are clearly some larger issues at play here that I think warrant discussion.
<apw> its all a twisty maze with glass on the floor
<hallyn> arges: were you going to verify bug 1277157 ?
<ubottu> bug 1277157 in netcf (Ubuntu Quantal) "libvirtd restart due to assertion failure in libnl" [High,Fix committed] https://launchpad.net/bugs/1277157
<hallyn> the test case can't quite work for precise - bc libvirt isn't built against netcf there.  but even after rebuilding libvirt i coudln't reproduce it.  sadly.
<arges> hallyn: hi
<slangasek> infinity: qemu given back
<arges> hallyn: so the libvirt in the bug comes from the cloud-archive
<infinity> slangasek: Ta.
<arges> hallyn: i'm having the reporter verify this on his machine, is this blocking something for you?
<hallyn> arges: hm, as i said though a manually rebuilt libvirt with netcf support didn't reproduce it.  i can try cloud-archive in a bit...
<hallyn> thx
<hallyn> no, i just don't like to let things slip through the cracks
<hallyn> and then months down the road we have an unverified sru
<hallyn> thanks - i'll wait for results from teh reporter!  that's perfect
<arges> hallyn: i don't like unverified srus either : )
<arges> yea i'm also setting up my big machine to see if I can do some local testing too, let me know if you get anywhere with this one
<slangasek> hallyn: any reason not to push the qemu arm64 patches to Debian?
<hallyn> slangasek: now that they're upstream, probably not.
<hallyn> slangasek: mjt may want to just wait for 1.8
<slangasek> hmm; I suppose it is rather a large patchset, would be rude to foist that on Debian if the maintainers weren't prepared to absorb them :)
<hallyn> let's ask
<slangasek> I was just planning to push back the debian/control changes, and found a much bigger delta than I expected
<hallyn> stgraber: ok lemme address the missing --dir
<hallyn> slangasek: yeah the number of patches is impressive
<slangasek> hallyn: have you by chance been rebasing these branches, rather than merging them?  because 6c93231780ecc89ac9e64686dd3247437d4b0696 doesn't look like a merge :)
<slangasek> (guess I won't be cherry-picking ;p)
<hallyn> slangasek: they have to be rebased bc we also have the omap3 patchset
<slangasek> maaaan
<hallyn> oh that
<hallyn> slangasek: yes i *intended* with the latest merge to make it a complete sync.  However mjt calmed down from that...
<hallyn> wisely
<slangasek> ah, well
<hallyn> i worked toward it partially which is how i bricked some machines
<slangasek> it's still not a merge topologically :)
<hallyn> with the *next* merge i may make it completely syncable
<hallyn> what do you mean?
<slangasek> hallyn: do you know why /usr/share/qemu/OVMF.fd is in qemu-system-common, when all the other firmware bits are in qemu-system-x86?
<slangasek> hallyn: I mean that 'git log debian/qemu-system-common.links' shows that the history of this file starts and ends with the latest merge
<hallyn> not sure, i don't recall making a change there
<slangasek> seems to have happened with the binary package reorg, post-quantal
<hallyn> is OVMF useful on any other arches?
<slangasek> hallyn: *this* build of OVMF certainly isn't :)
<slangasek> there are open bug reports in both Ubuntu and Debian asking to build it for other archs beside x86_64, but then each of those would need its own symlink
<slangasek> so I think I'll just arrange to move that into qemu-system-x86
<hallyn> sounds good
<hallyn> slangasek: so how would the OVMF.fd filenames look if different arches were supported?  /usr/share/ovmf/ovmf-$arch.fd ?
<slangasek> hallyn: undecided :-)
<hallyn> ok
<hallyn> guess i need to be looking at that pkg.  i've been negligent there
<slangasek> I suppose I would leave /usr/share/ovmf/ovmf.fd in place for backwards-compatibility, and then use ovmf-$efiarchname.fd
<jtaylor> infinity: that doesn't look right: http://paste.ubuntu.com/6972824/
<hallyn> yeah
<jtaylor> though maybe its the debugger
<infinity> jtaylor: I'm pretty wildly unfamiliar with libm.  If you do find issues, an upstream bug report would probably work out better than trying to educate me. :)
<infinity> jtaylor: I know the testsuite passes within whatever acceptable ULPs upstream has defined, but that's about as far as my libm usage goes.
<jtaylor> k filed a bug
<jtaylor> http://sourceware.org/bugzilla/show_bug.cgi?id=16623
<ubottu> sourceware.org bug 16623 in libc "cos change of behavior in 2.19 causes scipy testfailures" [Normal,New]
<jtaylor> fwiw I think its a bug, that number should just still be in the range where glibc can give a right result
<jtaylor> at least +- 0.1
<ogra_> stgraber, wow, you got a special edition of the german ix magazine (professional it magazine) about LXC ! congrats !!
<ogra_> (and you are mentioned in the announcement, i bet they just translated your blog ;) )
<stgraber> ogra_: hehe, yeah, I saw a lot of hits coming from heise.de and referring to that magazine
<ogra_> yeah
<pitti> slangasek: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/ :)
<slangasek> pitti: whoo! thanks :)
<slangasek> pitti: the ppc64 junk jobs still need removing, I guess?
<pitti> slangasek: correct, that RT is still pending
<slangasek> ok
<pitti> slangasek: wolfe-05 ran out of disk space, I'll clean up (bah jenkins leaking all its files) and retry jobs
<pitti> *phew*, we've worked on hardly anything else than ppc/armhf tests this week, but finally getting there :)
<slangasek> pitti: infinity and I are looking at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest%20ppc64el/job/trusty-adt-coreutils-ppc64el/ ... coreutils passes its test suite at build time, so we're wondering if this is a problem with the test env
<hallyn> how weird - i install linux-image-3.2 in precise, and it grabs...   all of the old 3.2 kernels (-24, -25, -26, -26, ... -41, ...)
<slangasek> pitti: how can we reproduce the adt environment?
<slangasek> hallyn: linux-image-3.2 isn't a real package, so you're getting the benefit of a little-known misfeature that apt supports regexps for installation
<pitti> slangasek: debcheckout autopkgtest; sudo tools adt-build-lxc ubuntu trusty
<hallyn> slangasek: neat! :)
<pitti> slangasek: that's mostly equivalent to sudo lxc-create with the ubuntu template (debootstreap)
<pitti> slangasek: then for the actual test: ./run-from-checkout coreutils --- lxc -es adt-trusty
<slangasek> pitti: ok.  what does that give us as the backing filesystem? ext4, tmpfs, or some aufs madness? :)
<pitti> slangasek: I think --ephemeral defaults to tpmfs and overlayfs
<slangasek> pitti: and you're using --ephemeral?
<pitti> slangasek: let me run the test on amd64 in LXC
<pitti> slangasek: right
<slangasek> ok
<pitti> ah, need to create a trusty container; argh slow network
<slangasek> pitti: do you have more than one test running /in parallel/ using overlayfs against the same base chroot?
<pitti> slangasek: on the ppc nodes we have two parallel runs, on armhf just one
<pitti> slangasek: if I were to bet, I'd bet it was due to lxc/overlayfs, not ppc
 * pitti lets the container build and firefights the wolfes in the meantime
<slangasek> pitti: right, please do *not* use multiple overlayfs instances against a single directory on ppc64el; we've seen instabilities with this before
<slangasek> (instabilities == filesystem corruption)
<pitti> slangasek: ok, good to know; that'll halve our running slots, but I guess they shuld still be able to keep up
<slangasek> pitti: couldn't you run two chroots side-by-side?
<pitti> slangasek: with some extra hackery and lock files or so, yes
<slangasek> pitti: anyway, you do what you need to :) but yeah, parallel overlayfs is unreliable, so if you can fix that and retry the coreutil adt, that'd be keen
<slangasek> infinity: ^^
<pitti> slangasek: reconfiguring jenkins on our side is a bit tricky, as d-jenkins is broken; jibel will try
<infinity> pitti: Oh, if the lxc adt stuff is using overlayfs, we're going to see failures even without the parallel madness.
<infinity> pitti: Could I talk you into switching to aufs?
<pitti> infinity: it's just using lxc --ephemeral, so whatever it supports
<pitti> ah, --union-type
<xnox_> pitti: btrfs-snapshots are quite good with that.
<infinity> pitti: So, if you really want more parallelism, your better option is to spin up twice as many VMs and overcommit CPU.
<infinity> (This is what I've done for the buildds)
<pitti> infinity: sounds good; if smoser can give me four more VMs and we'll use only one run slot in each that'd simplify things indeed
<pitti> $ sudo lxc-start-ephemeral --union-type=aufs -o adt-trusty
<pitti> lxc_container: command get_cgroup failed to receive response
<pitti> hmmm; stgraber ^ ?
<pitti> infinity, slangasek: I get the same errors on trusty amd64 with a single container (but with overlayfs); trying with clone now
<pitti> still 2 test failures, although the output looks cleaner
<pitti> FAIL:
<pitti> File name too long at -e line 2.
<slangasek> "file name too long" - err?
<pitti> slangasek: coreutils' adt test is a subset of the upstream tests; if these two don't work in LXC, we can just drop them as well, in the worst case
<pitti> slangasek: we already run them during package build, the autopkgtest sohuld mostly be a smoke test
<pitti> slangasek, infinity: wolfes reconfigured to only use one running slot
<stgraber> pitti: that error is what you get for "generic startup failure" when not attached to the container's console (which is the case with start-ephemeral) so that's not terribly useful. Maybe you're lucky and you get the actual error in /var/log/lxc/ ?
<pitti> stgraber: hm, it doesn't create a log file in the first place
<pitti> stgraber: /var/log/lxc/ has gazillions of logs, just not for the --union-type=aufs one
<pitti> (are these ever cleaned up?)
<pitti> uh, apparenlty not, I've got logs from half a year ago
<stgraber> hmm, we probably should ship a logrotate config then :)
<stgraber> pitti: so one trick you could do is set those two options in your orig container (adt-trusty):
<stgraber> lxc.logfile = /dev/stderr
<stgraber> lxc.loglevel = debug
<stgraber> start-ephemeral will copy that to the aufs clone and you'll get the log output at startup on stderr
<pitti> done, but no output at all (except for the cgroup response and the failure notice)
<stgraber> that's slightly annoying... how about if you set it to some fs path?
<pitti> stgraber: if I run with --union-type=overlayfs the container starts, but still no debugging output
<pitti> but I did get /var/log/lxc/adt-virt-lxc-ewfdkd.log
<pitti> (zero bytes)
 * pitti logs to /tmp/log
<pitti> stgraber: got created, but empty
<pitti> stgraber: also empty with (working) overlayfs
<stgraber> pitti: what version of lxc is that?
<pitti> 1.0.0~rc4-0ubuntu1
<pitti> stgraber: I didn't dist-upgrade today, might that help?
<pitti> (last upgrade yesterday)
<stgraber> probably not
<stgraber> unless you're using btfs or xfs as your /var/lib/lxc
<stgraber> *btrfs
<pitti> no, good ol' ext4
<stgraber> pitti: ok, well, easiest way to figure this out will be to patch lxc-start-ephemeral, commenting the "if dest.defined: dest.destroy()" after the "The container '%s' failed to start"
<stgraber> pitti: that way the container will fail but will still exist on the system, you can then use good old lxc-start on it
<stgraber> which should be a bit more useful at telling you what's wrong
<pitti> hm, I did that, it still doesn't exist
 * pitti adds good old subprocess.call(['bash', '-i']) right after the error message
<stgraber> pitti: hmm, maybe that container is actually getting past that point, pass -k then
<pitti> still doesn't exist
<pitti> perhaps it fails on creation already?
<stgraber> pitti: well, let's try something simpler then :)
<stgraber> pitti: lxc-clone -o adt-test -n test -B aufs -s
<pitti> --keep-data also doesn't work
<pitti> lxc_container: No such device - aufs: error mounting /srv/lxc/adt-trusty/rootfs onto /usr/lib/powerpc64le-linux-gnu/lxc options br=/srv/lxc/test/delta0=rw:/srv/lxc/adt-trusty/rootfs=ro
<pitti> stgraber: ah, now we are talking
<stgraber> progress!
<stgraber> pitti: so let's look for the obvious problems: grep aufs /proc/modules
<pitti> no hit
<stgraber> pitti: modprobe aufs
<pitti> $ modinfo aufs
<pitti> modinfo: ERROR: Module aufs not found.
<stgraber> that'd explain it ;)
<pitti> that'd do it
<pitti> $ grep AUFS /boot/config-3.13.0-8-generic
<pitti> CONFIG_AUFS_FS=m
<pitti> LIES!
<stgraber> well, that or you didn't reboot the box in a while
<stgraber> it could be that the kernel you're running has been uninstalled
<stgraber> so the .ko no longer exist on disk
<pitti> no, still installed
<pitti> -11 is current, -8 is running, -7 to -11 are installed
<pitti> meh, and if I reboot I still get -8
<stgraber> do you have linux-image-extra-... installed too?
<stgraber> because apparently aufs is in that one, not in the main linux-image
<pitti> no, I don't; good point
<pitti> infinity: vmlinux -> boot/vmlinux-3.13.0-11-generic
<pitti> infinity: any idea why after rebooting I still get 3.13.0-8?
<stgraber> well, at least that's the case on x86 but since -extra also exists on ppc64el, that may be the case there too
<pitti> infinity: oh, nevermind; smoser` needs to reboot the VMs with an explicit -kernel qemu option
<pitti> hm, no metapackage for -extra
<bdmurray> bdrung: How would you feel about adding enabled architectures information to distro-info?
<infinity> pitti: Because smoser's VM setup doesn't have a bootloader.
<pitti> ah, linux-image-generic isn't installed
<pitti> infinity: right, so I'll need to ask him to reboot with -11
<infinity> pitti: Which host is it?  I *might* be able to figure out his setup.  Maybe.
<pitti> infinity: wolfe-03 to 06
<infinity> No promises that I can decipher his VM setup, it's more complex and abstracted than mine.  But let me have a poke.
<stgraber> pitti: so just wondering, are you using overlayfs because you want the overlay on tmpfs feature or just to save you the lengthy initial clone?
<pitti> stgraber: both really; whatever makes things faster
<pitti> stgraber: well, we haven't actually yet run into a test which is only broken by overlayfs, so it's not that urgent for now
<infinity> pitti: Okay, I think I might have it figured out.  Want to poweroff all your guests for me?
<infinity> pitti: As for "tests only broken by overlayfs", you'll find that glibc's testsuite fails. :/
<infinity> (And it's fine on aufs)
<stgraber> I'd also expect upstart's testsuite to fail on overlayfs, not sure about aufs
<pitti> infinity: ah, good; well, let's find out after the reboot with overlayfs
<pitti> err, with -11
<pitti> infinity: shutdown; that'll kill some tests, I'll retry them later
<sarnold> pitti: there's some trusty bugs that are failing the retracing, two at-hand examples: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1283000 https://bugs.launchpad.net/ubuntu/+source/doodle/+bug/1283259
<ubottu> Error: malone bug 1283000 not found
<ubottu> Error: malone bug 1283259 not found
<infinity> pitti: Just grabbing a kernel and scping it around.  Be with you shortly.
<pitti> sarnold: they can't find glib, gdk-pixbuf and friends, that's a bit odd
<pitti> sarnold: I can't spend much time on that now I'm afraid; could you send me a mail about this for next week?
<sarnold> pitti: sure
 * infinity wonders what's gone wrong with the pty setup on this machine...
<pitti> sarnold: oh, WTH -- are you using some PPA?
<infinity> [shared@wolfe ~]$ screen -S wolfe-03
<infinity> Cannot open your terminal '/dev/pts/8' - please check.
 * infinity grumps.
<pitti> WARNING: /lib/i386-linux-gnu/libglib-2.0.so.0.3990.0 is needed, but cannot be mapped to a package
<sarnold> pitti: dunno, I'm just trying to move bugs out of the security queue so they stand a chance of being fixed :)
<pitti> sarnold: nevermind, mis-looked
<infinity> smoser`: Don't suppose you're around to tell me what's up with your screen setup?
<pitti> sarnold: yeah, that's fine; we have no shortage of failed-to-retrace bugs, if someone wants to investigate all them we have enough work for 20 years :)
<infinity> Oh, might be a non-login shell issue.
<sarnold> pitti: ha! :) it just feels like lately there's more 14.04 bugs coming throuh than I would have expected, and I'd hate if some of them just didn't get the attention they deserved because they stayed locked up
<infinity> Rightm, problem solved.
<infinity> pitti: Can you check wolfe-03 appears to be the kernel you want?
<pitti> infinity: LGTM
<pitti> and look, aufs
<pitti> and it works with -ephemeral
<infinity> pitti: 4, 5, and 6 should be up now too.  Those were all the ones you had, right?
<pitti> infinity: right, these four; danke!
<pitti> infinity, slangasek: wolfes changed to run tests with aufs now; I retried a few packages, but as we now only have 4 executors it has some queue
<pitti> infinity, slangasek: do you think with aufs we can move back to two executors?
<bdmurray> pitti: could you look at an aptdaemon mp from me?
<infinity> pitti: Not sure.  Can 4 VMs really not keep up right now, or is there just a scary backlog?
<pitti> infinity: I think they can keep up, I'm just impatient :)
<pitti> infinity: just stop uploading more eglibcs and retriggering $WORLD :-P
<pitti> bdmurray: yes
<bdmurray> https://code.launchpad.net/~brian-murray/aptdaemon/bug-1266844/+merge/207276
<infinity> pitti: What's that?  I can't hear you over the sound of my uploads being AWESOME.  Maybe I'll do another.
<pitti> infinity: I have the entire setup of an adt slave scripted now; I could run it on you and make YOU do all the tests in your brain!
<infinity> pitti: My integer performance is pretty lousy, I don't think we want that.
<infinity> pitti: And don't even get me started on floating point...
<slangasek> not to mention *those* filesystem corruption issues
<pitti> there, unar fixed
<pitti> I'm tempted to upload postgresql-9.3 to fix its tests on lxc, but that'll trigger yet another 20 tests
<pitti> bdmurray: do you know under which conditions get_model() returns None?
<pitti> bdmurray: I'm afraid I don't quite understand the fix with some more context
<bdmurray> pitti: no, however bug 1024590 was fixed similarly in r963
<ubottu> bug 1024590 in aptdaemon (Ubuntu) "update-manager crashed with AttributeError in _on_download_changed(): 'NoneType' object has no attribute 'get_value'" [Medium,Fix committed] https://launchpad.net/bugs/1024590
<pitti> mdeslaur, sarnold: did you see my postgresql security update? anything you still need from me for that?
<sarnold> pitti: mdeslaur is on it, thanks for the fixes :)
<pitti> sarnold: great, thanks
#ubuntu-devel 2014-02-22
<mdeslaur> pitti: I tested them today, and will publish them on monday. Thanks!
<pitti> mdeslaur: cool, thanks
<pitti> mdeslaur: ah, you tested already; I ran into some failures which were due to the recent "nologin as default shell for system users" change
<pitti> mdeslaur: (schroot copies the host's /etc/passwd)
<pitti> easy enough to fix, but not entirely obvious at first sight
<mdeslaur> pitti: on what releases?
<pitti> mdeslaur: just with trusty as the host
<pitti> mdeslaur: I edited /etc/passwd in the schroot to have /bin/sh as nobody's shell, then it works again
<pitti> mdeslaur: that's fixed in trusty's postgresql-common but that's not backported to earlier releases
<sarnold> what is user 'nobody' used for?
<pitti> sarnold: for some test cases about per-user clusters; that user is always available
<sarnold> 'nobody' is supposed to be used only for nfs quashing, not actually running programs...
<sarnold> pitti: test cases only?
<sarnold> corners can be cut for testing, fair enough..
<pitti> sarnold: yes, of cousr
<sarnold> thanks pitti :)
<pitti> good night everyone, cd /airport and then cd ~ :)
<mdeslaur> pitti: good night, have a nice trip!
<sarnold> pitti: safe travels :)
<sarnold> is there an easy way to pull build logs from launchpad?
<xnox_> sarnold: there is launchpad api to fetch them.
<bdrung> bdmurray: sounds good to have architecture information in distro-info, too
<bdrung> but distro-info is for mapping devel & co to a distro.
<bdrung> once you have a distro you could pull information about this distro from some other tool
<doko> infinity, https://launchpadlibrarian.net/167193519/buildlog_ubuntu-trusty-i386.python-cffi_0.8.1-1ubuntu3_FAILEDTOBUILD.txt.gz
<jtaylor> doko: known 2.19 bug
<jtaylor> also breaks scipy
<jtaylor> hm its not exactly the same
<jtaylor> wow the math functions have really been screwed up in 2.19 :(
<jtaylor> there seems to be some global state added between calls
<jtaylor> probably rounding mode
<jtaylor> doko, infinity: filed a bug https://sourceware.org/bugzilla/show_bug.cgi?id=16625
<ubottu> sourceware.org bug 16625 in libc "sin gives wrong result with 2.19 on i386" [Normal,New]
<infinity> jtaylor: Is this i386-only?
<jtaylor> yes
<infinity> jtaylor: I'll see if I can get jsm to look at it this weekend.  He's the mostly like to (a) know what's broken and (b) have been the person who broke it in the first place.
<infinity> s/like/likely/
<infinity> ampelbein_: Dude.  Don't disable --as-needed to fix things, actually fix the bug. :/
<infinity> ampelbein_: Have you done that for more than ufsutils (the one I just noticed)?
<infinity> ampelbein_: Anyhow, solution is simple for ufsutils, since it's changed arch to kfreebsd-any, I'll just remove it. :P
#ubuntu-devel 2014-02-23
<Takyoji> Anyway way of contacting a package maintainer of a package lacking a needed dependency?
<Takyoji> (forget the second 'way', typo)
<Logan_> Takyoji: Which one?
<Takyoji> Because 'd-rats' needs a dependency of 'python-glade2' otherwise it won't be usable at all.
 * Logan_ looks
<Takyoji> and it's maintainer is listed as ubuntu-devel-discuss@lists.ubuntu.com
<Logan_> yeah, that's for all Ubuntu packages
<Logan_> let me see if a no-change rebuild pulls it in
<Logan_> Takyoji: okay, confirmed on my end
<Takyoji> That the package doesn't install python-glade2, and throws a Python error when ran after installation?
<Logan_> Takyoji: correct
<Logan_> how far does this go back?
<Logan_> I'm guessing to Precise
<Logan_> I'll have to SRU a fix to all of them...
<Logan_> Takyoji: follow this bug, I'll take care of it: https://bugs.launchpad.net/ubuntu/+source/d-rats/+bug/917204
<ubottu> Launchpad bug 917204 in d-rats (Ubuntu) "d-rats crashed with ImportError in /usr/lib/pymodules/python2.7/d_rats/mainwindow.py: No module named glade" [Medium,New]
<Takyoji> Subscribed.
<Logan_> Takyoji: I just pushed out a fix to trusty
<Logan_> I'll do it for the other stable releases as well
<Takyoji> Logan_, thank you.
<Logan_> np :)
<Logan_> Takyoji: uploaded a fix to Precise, Quantal, Saucy as well
<hakermania> I am looking for a sponsor for my package, Wallch ( https://bugs.launchpad.net/ubuntu/+source/wallch/+bug/1282830 ) Does anyone know where I should try my luck :) ?
<ubottu> Launchpad bug 1282830 in wallch (Ubuntu) "FFE: Wallch 4.0" [Wishlist,Confirmed]
<Noskcaj> Could someone please sponsor bug 1282937 ?
<ubottu> bug 1282937 in xfburn (Ubuntu) "Please package xfburn 0.5.0" [Undecided,In progress] https://launchpad.net/bugs/1282937
<Logan_> poor Noskcaj
<Noskcaj> Logan_, I've made the sponsoring queue pretty big again, enjoy
<Logan_> oh dear
<jtaylor> doko: our python2.7 has match_hostname from python3.4a1 but it doesn't seem to have the rfc6125 change added in 3.4a5
<jtaylor> is there a reason for that?
<jtaylor> its also in 3.3.3
<asac`> smoser`: server dashoard has been unhappy for a while: http://ci.ubuntu.com/smokeng/trusty/server/i386/20140221/6740/ ... can you forward to whowever might be interested in this on server team?
<asac`> tomcat and lamp are failing
<asac`> thanks
<infinity> xnox: Any idea what's going on in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739913
<ubottu> Debian bug 739913 in src:libnih "libnih: FTBFS on i386 ("killed with signal TERM after 150 minutes of inactivity" during configure)" [Serious,Open]
<infinity> xnox: Is that fixed in Ubuntu's libnih?  If so, can we NMU that patch to Debian?
<infinity> slangasek: ^
<shadeslayer> anyone attending MWC ?
<infinity> Ahh, no, that's not fixed in Ubuntu, the Ubuntu sources die the same way on Debian/i386...
<darkxst> spamassassin has broken ubuntu GNOME daily builds Bug 1283850
<ubottu> bug 1283850 in spamassassin (Ubuntu) "Spamassassin update broke Ubuntu GNOME daily builds" [Critical,New] https://launchpad.net/bugs/1283850
<darkxst> and I can't work out what is wrong...
#ubuntu-devel 2015-02-16
<pitti> Good morning
<pitti> stgraber: \o/ cheers; I noticed that the test went green again yesterday
<pitti> hallyn: so apparently slangasek sponsored the new cgmanager, great
<pitti> xnox: launchpadlib bugs> â¥
<xnox> pitti: ;-(
<xnox> pitti: ;-)
<xnox> i'm sure you will find more.
<xnox> how far is the apport port?
<pitti> xnox: oh wow, what an unusual time for you :)
<pitti> xnox: quite far actually; I locally worked around the four that I sent the other day, and I got several PASSes
<xnox> ah, cool. Well they should be all in now.
<pitti> xnox: I'll move my piece this morning, after the email flood ;)
<pitti> xnox: wrt. bug 1377624, nice that you got to the bottom of it
<ubottu> bug 1377624 in systemd (Ubuntu Trusty) "udev fails in trusty OpenVZ containers, when /etc/init/udev.conf is missing (OVH misconfig?!)" [Low,Opinion] https://launchpad.net/bugs/1377624
<pitti> xnox: I'm not sure why someone closed it as "opinion", that seems like a strange state
<xnox> "opinion" -> such that one can find the bug report. As it's merely documentation from now on.
<xnox> clearly a few of us affected, and clearly the vps provider is popular enough with many users affected.
<pitti> ah, so that was you; o :)
<xnox> yeah
<xnox> i'm now hunting for a VPS provider that will route /48 or /64 ipv6 allocation
<pitti> xnox: meh, already got the next bug, but it's not a blocker
<pitti> xnox: bug 1422249; I'll work around by logging in with py2
<ubottu> bug 1422249 in python-launchpadlib (Ubuntu) "TypeError crash if credentials are expired and needs to re-login" [Undecided,New] https://launchpad.net/bugs/1422249
<pitti> I guess I first ran the tests with py2 the last time, so I didn't notice this
<xnox> thanks =)
<pitti> xnox: I moved to https://www.netcup.de/ a few months ago, I'm really happy with them (/64 IPv6, kvm, good support)
<pitti> xnox: hm, I get eternal hangs from staging right now, I guess I'll have to do this at another time :/
<pitti> it hangs in createBug()
<pitti> infinity: FYI, bug 1404509 got verified now in trusty
<ubottu> bug 1404509 in systemd (Ubuntu Trusty) "[precise, trusty] udev does not automatically load modules with kernel >= 3.11" [Undecided,Fix committed] https://launchpad.net/bugs/1404509
<wolandtel> Hi.
<wolandtel> Trying to launch pure debian on T72X 3G (MTK 6582 / 8312). Can anybody explain how to build right initramfs?
<pitti> ogra_: dude!!
<pitti> ogra_: HAPPY BIRTHDAY! *hug*
<ogra_> haha, thanks !!
 * pitti wirft eine Luftschlange
<ogra_> wheee !
<pitti> ogra_: did you get a bunch of "Krapfen" instead of a cake? :-)
<highvoltage> Happy birthday Ogra :D
<highvoltage> I mean, ogra_
<ogra_> heh, thanks highvoltage
<ogra_> pitti, choco croissants ;)
<pitti> yummy
<mdeslaur> ogra_: happy birthday!
<ogra_> thanks a lot !
<smb> ogra_, Kalau! Err, Happy Birthday, too. :)
<ogra_> thanks smb
<flexiondotorg_> stokachu, Are you about?
<caribou> I'm working on backporting memleak fixes to rsyslog from v7.4.5 & v7.4.6.
<caribou> I have found 6 commits : should I build one single quilt patch for those six commits
<caribou> or one quilt patch for each of the commits ?
<hallyn> pitti: yup.  hopefully this finally takes care of the mounts propagation bugs
<rbasak> caribou: either way I think, and describe what's going on as best as you can in dep3, unless some here says otherwise. It starts to get tedious and less useful at six otherwise.
<caribou> rbasak: well, each commit msg is pretty descriptive. I may go for one patch/commit as it is more discriminative in case one single commit causes problem
<rbasak> caribou: sure
<rbasak> caribou: you can even have subdirectories in debian/patches I think. I'm not sure though.
<rbasak> pitti or jibel: could you retest vivid-adt-redmine please? I think it might be fixed now that I rebuilt ruby-mysql.
<pitti> rbasak, jibel: will do
<pitti> rbasak: ah, ruby-msql now succeeded
<rbasak> Yeah it just detected a version mismatch and assumed there was an ABI problem.
<rbasak> The ABI is actually identical (since the libmysqlclient sover says so!) so a rebuild for it to pick up the new version string to match against was all that was needed.
<jibel> rbasak, done
<rbasak> Thanks!]
<jibel> rbasak, same error, redmine depends on ruby-mysql2 not ruby-mysql
<rbasak> jibel: ah, sorry. I saw the same (unusual) error string and assumed it came from the same package. I'll reproduce locally and rebuild ruby-mysql2 if necessary.
<flexiondotorg_> stokachu, Hi
<flexiondotorg_> cyphermox, Are you about?
<cyphermox> flexiondotorg_: I am
<cyphermox> in fact coming up on my turn to sponsor.
<flexiondotorg_> cyphermox, stokachu Uploaded a bunch a Ubuntu MATE packages on Friday last week.
<cyphermox> yup
<flexiondotorg_> cyphermox, I can't see them in the archive anywhere? Err. New at this ð What happens next?
<cyphermox> they are brand new packages, so they are waiting in the NEW queue: https://launchpad.net/ubuntu/vivid/+queue
<cyphermox> flexiondotorg_: for a review from an archive admin; you could ping people in #ubuntu-release to see if someone is available to look at them\
<flexiondotorg_> cyphermox, Thanks.
<cyphermox> (I don't have these privileges)
<wer_ru> Hello I try to install Meshmixer by AutoDesk
<wer_ru> this program was disign for 14.04
<wer_ru> and i have problem with 14.10
<wer_ru> Meshmixer is depended on libsuperlu3
<wer_ru> but 14.10 has libsuperlu4
<davmor2> wer_ru: this is a development channel general help can be found on #ubuntu
<wer_ru> ok davmor2
<cyphermox> @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: cyphermox
<wer_ru> thanks
<jtaylor> hm why is byobo triggering an apt-check every few seconds?
<jtaylor> causes almost a load of 1, kind of wasteful for something you have running all the time
<jtaylor> not directly bug 1010505, as it is using flock ..
<ubottu> bug 1010505 in byobu (Ubuntu Precise) "byobu should not run apt-check so much" [High,In progress] https://launchpad.net/bugs/1010505
<aeoril> darkxst_ I am trying to find the function definition terminal_receiver_call_exec_sync() used in the gnome-terminal source.  I cannot find it anywhere on the web or in Ubuntu or in the source for gnome-terminal.  Do you have any ideas?
<darkxst_> aeoril, its autogenerated as part of gdbus
<aeoril> darkxst_ do you knwo what it does?
<aeoril> darkxst_ or where I can find source to figure out what it does?
<aeoril> darkxst_ I am trying to find in gnome-terminal (or wherever) the -e/--command command is actually executed (fork()'ed, pthread'ed, etc)
<aeoril> I am guessing it would be fork()'ed
<darkxst_> aeoril, look in your build directory
<darkxst_> it a dbus call on org.gnome.Terminal.Terminal0.Exec
<aeoril> darkxst_ sorry if this seems stupid, but what do you mean by "build directory"
<darkxst_> aeoril, like in gnome-terminal source directory after running 'make'
<aeoril> I grep'ed recursively for org.gnome.Terminal.Terminal0.Exec but found nothing
<darkxst_> aeoril, its defined in the xml file
<darkxst_> but you can see the generated code after 'make' runs
<aeoril> darkxst_ oh, i have not made it yet - that would require downloading all the build dependencies.  I have just been looking at code
<aeoril> ok, will do
<darkxst_> aeoril, apt-get build-dep gnome-terminal
<aeoril> yes, ok, thanks
<aeoril> darkxst_ there is no configure file - only configure.am.  But there is an autogen.sh.  I seem to remember some step that makes the configure file - do I just run autogen.sh?  Are there any specific command line parameters I need to pass autogen.sh?
<aeoril> (googling)
<aeoril> darkxst_ looks Iike I need to install autotools then do autoreconf -vi?
<darkxst_> aeoril, I think you can just run autogen.sh
<aeoril> darkxst_ ok, I was hoping - I'll give that a shot, its a git repon anyway ...
<aeoril> repo*
<aeoril> darkxst_ bad dependency versions - looks like I will have to run it on vivid, not trusty.  I hope that will work.  Any other way you can think of?
<darkxst_> aeoril, if you are building 3.14, you will need to do it on vivid
<aeoril> darkxst_ figured, will do - thanks
<darkxst_> aeoril, or inside a vivid schroot
<aeoril> darkxst_ yes, I was thinking about that ...
#ubuntu-devel 2015-02-17
<cyphermox> @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:
<hallyn> pitti: hi - so debian bug 777649 has the long sordid tale of trying to get an important cgmanager fix into jessie.  Looks like we're finally there.  Would you mind sponsoring http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.33-2+deb8u1.dsc ?
<ubottu> Debian bug 777649 in release.debian.org "unblock: cgmanager/0.33-2+deb8u1" [Normal,Open] http://bugs.debian.org/777649
<hallyn> (into testing)
<tnkhanh> Hi when will 14.04 have Java 8
<tnkhanh> I mean to install from apt-get
<tnkhanh> hello anyone?
<pitti> hallyn: yay, good
<pitti> hallyn: will do, but have to create a jessie schroot first
<tnkhanh> Hi when will 14.04 have Java 8
<tnkhanh> anyone? =='
<LocutusOfBorg1> good morning to everybody
<Unit193> Howdy.
<Mirv> tjaalton: Qt 5.4 landed with your openvg build dep removal included
<tjaalton> Mirv: great
<pitti> tjaalton: http://people.canonical.com/~ubuntu-archive/nbs.html \o/
 * pitti sheds a tear of joy
<pitti> that must be the earliest "empty NBS" of all releases :
<pitti> :)
<pitti> hallyn: uploaded
<tjaalton> pitti: enjoy while it lasts :)
<joern_> hi everyone!
<joern_> I'm looking for someone who could help debugging/triaging a problem with Ubiquity... maybe I should introduce myself, I am JÃ¶rn and I help the Lubuntu team. I've created a live iso with LXQt as a tech preview, but Ubiquity refuses to start (both GTK/KDE versions), and there seems to be no log file entry even with --debug
<joern_> Tim from Ubuntu Gnome mentioned the name xnox :D are you or some other able to help me?
<xnox> joern_: depends what with.
<xnox> joern_: in general ubiquity knows only about certain types of DEs / environments. Is LXQt Qt5 or Qt4?
<xnox> joern_: you should see logs in /var/log/installer/* as well as messages in /var/log/syslog
<joern_> hi xnox
<joern_> LXQt is now Qt5 only
<joern_> there are no messages in /var/log/syslog (even with --debug)
<joern_> wasn't /var/log/installer the place for logs on an installed system?
<joern_> the only kind of error I get is (I'm not sure if it is important): "umount: /run/udisks2/inhibit-polkit: not mounted"
<joern_> paste.ubuntu.com/10271088
<joern_> that is /var/log/syslog after running Ubiquity with --debug
<joern_> there is no folder /var/log/installer
<joern_> anything more informations I could give you?
<geser> pitti: a systemd question: as I permanently moved to systemd (and purged upstart instead of keeping it in removed state), I tried yesterday to boot with upstart but it sort of failed (only two messages visible on the terminal, otherwise blank and no boot progess visible, like starting lightdm). Booting with upstart should continue to work even after switching, right?
<pitti> geser: right, with upstart-bin
<pitti> hm, wait
<pitti> I have it removed, but not purged
<pitti> geser: indeed, the "upstart" package contains a ton of /etc/init/ jobs
<pitti> which one actually needs for booting with upstart
<pitti> geser: so these would need to move into upstart-bin or a new binary pacakge, or we need to put upstart's /sbin/init into a different binary
<geser> I guess I should switch back to upstart, then install systemd-sysv again to have upstart in removed state (for now) to have a working upstart fallback
<geser> pitti: should I file a bug (against upstart) about it?
<pitti> geser: yeah, can't hurt
<tnkhanh> Hi when will 14.04 have Java 8
<tnkhanh> I mean to install from apt-get
<bluesabre> pitti, would you mind reviewing https://bugs.launchpad.net/lightdm-gtk-greeter-settings/+bug/1295405 for inclusion in vivid? If possible, the xubuntu team would like to upload this to the archive and include it in the seed for this release. As I understand it, the Mate team is also interested in including this utility
<ubottu> Launchpad bug 1295405 in Settings editor for LightDM GTK+ Greeter "[needs-packaging] Package and upload to vivid" [Wishlist,In progress]
<pitti> bluesabre: sorry, busy; can you please just put it into the sponsoring queue?
<bluesabre> pitti: np, I've subbed ubuntu-sponsors, so it should be visible
<bluesabre> thanks for getting back to me so quickly
<jbassett_> Hello all
<jbassett_> Is this a place where I may make a suggestion, I do not believe it is a bug, more likely just not a realised use case I have a query about?
<rbasak> If you want the suggestion to be read by someone who is in a position to act on it, it might be better to file a "Wishlist" bug against the relevant package.
<Riddell> didrocks: any news on bluez 5?
<Riddell> pitti: any news on systemd transition?
<didrocks> Riddell: syncing with the Touch team is today (in a couple of hours), will keep you posted
<didrocks> Riddell: the desktop-side is almost fully ready, won't block anyway
<pitti> Riddell: still blocked on fixing bug 1312976 (slangasek), and updating juju and maas :(
<ubottu> bug 1312976 in nfs-utils (Ubuntu) "nfs-utils needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312976
<seb128> slangasek said he would have his bits done previous week, not sure what's going on with that :-/
<Riddell> pitti: thanks, do you expect that this cycle?  (feature freeze being next week)
<didrocks> Riddell: this week, rather? (not on Thursday?)
<Riddell> didrocks: good point
<pitti> Riddell: we know that juju will only release in March, but we could work around that by booting juju generated instances with upstart; as for NFS, I don't know -- I hope so
<pitti> Riddell: at that point we probably should have a meeting with the foundations team, to discuss the next steps
<mdeslaur> pitti: also need apparmor support before it can be default...ask tyhicks when that's planned
<pitti> mdeslaur: oh? that's news to me; from my POV that has worked for months, what's missing?
<mdeslaur> pitti: it needs to load the apparmor policy at boot like it does with selinux, smack, etc.
<mdeslaur> it currently doesn't
<mdeslaur> it uses an init script which loads policy after services have started (ie: too late)
<pitti> it's in rcS, so started very early
<mdeslaur> pitti: does boot wait for it to complete before starting other services, or can apache be started before it?
<pitti> so it sounds like we merely need to make sysinit.target block on this?
<pitti> mdeslaur: apache can't
<mdeslaur> pitti: well, the real solution is to fix it properly :)
<pitti> Before=sysinit.target
<pitti> that's what will ensure that apparmor starts in very early boot, before any real service
<pitti> mdeslaur: well, in my POV that *is* properly working
<mdeslaur> pitti: before network devices come up?
<pitti> mdeslaur: before NM and /etc/init.d/networking, but we can make that stronger (make network-pre.target come after apparmor)
<pitti> mdeslaur: so, there's no bug or work item for this, do you have a list of those concerns?
<mdeslaur> pitti: ideally, we should load in src/core/main.c at the name place where selinux and smack get done
<pitti> mdeslaur: yeah, certainly sounds faster than having to call an init.d script; but I thought that was mostly optimization
<mdeslaur> sure, there are work items, hold on
<mdeslaur> pitti: we kept getting races with it being a script in upstart, which is why we want it to be at boot in systemd...but this requires using a pre-compiled apparmor policy at boot so as not to hang for a couple of minutes...this exists, but hasn't been uploaded to vivid yet
<mdeslaur> pitti: that's why every there are apparmor bits sprinkled all over the upstart jobs :P
<pitti> mdeslaur: so, I'm happy to add a network-pre ordering for apparmor; services already come after sysinit.target (which apparmor is part of), just network devices have a separate dependency tree
<pitti> mdeslaur: ah no, I lie -- network-pre.target already comes after sysinit.target, so it's all good
 * pitti missed the DefaultDependencies=yes
<mdeslaur> pitti: tyhicks can take a look with you when he gets here
<pitti> so the only things that run without apparmor are mounting local and virtual file systems, swaps, cryptsetup unlock, starting udevd
<mdeslaur> except we'll hang boot while policy is being compiled
<pitti> and they are all needed to allow running apparmor or even getting enough of your file system, so nothing can't really run even earlier
<pitti> mdeslaur: on first boot, you mean?
<mdeslaur> every kernel update
<pitti> mdeslaur: how is that different under upstart?
<pitti> I mean, if we have a dpkg trigger to update the cache for a new kernel, that should apply to any init system?
<pitti> (or a kernel/postinst.d script)
<mdeslaur> in upstart, we've sprinkled apparmor policy in the different upstart jobs so only a few profiles get compiled during the boot process, the others are handled by the init script later on while the system is coming up
<pitti> mdeslaur: ah, so isn't that essentially the same then?
<mdeslaur> pitti: well, we _could_ defer the init script later on, and then sprinkle apparmor bits in a bunch of systemd units
<mdeslaur> but that's...ugh.
<pitti> mdeslaur: (don't get me wrong: if we can make it faster, let's -- but before that I'm interested in making it work correctly)
<ochosi> didrocks: since it just got uploaded to NEW (by Mirv) and we need an archive admin to approve (before FF), do you have a minute to take a look at this? https://bugs.launchpad.net/lightdm-gtk-greeter-settings/+bug/1295405
<ubottu> Launchpad bug 1295405 in Settings editor for LightDM GTK+ Greeter "[needs-packaging] Package and upload to vivid" [Wishlist,In progress]
<mdeslaur> we're pretty much ready with the ideal situation...the apparmor code to cache is written, just needs to be uploaded to vivid
<mdeslaur> at which point, the systemd patch is pretty trivial to load it at boot
<didrocks> ochosi: will do later today and keep you posted
<mdeslaur> and then we can add the postinst triggers to the kernel packages
<ochosi> didrocks: thanks a lot, it's much appreciated!
<didrocks> yw! :)
<mdeslaur> tyhicks: please discuss apparmor plans with pitti when you get here
<pitti> mdeslaur: ack, thanks for the heads-up!
<pitti> mdeslaur: so, the summary from this conversation for me is: it currently works correctly, but slow, and we have a "pre-build cache" in the works to avoid recompiling the policy at boot
<pitti> mdeslaur: does that sound right to you?
<mdeslaur> pitti: I don't know if it works correctly, someone needs to check. Based on your statement that it loads early in the process, it's plausible.
<mdeslaur> if it does work correctly with no races, then it's ok for vivid as-is
<mdeslaur> (my opinion)
<pitti> mdeslaur: *nod*; yeah, I'm fairly convinced that it runs just about as early as it could, and it can't plausibly run earlier
<pitti> mdeslaur: the one thing that potentially could move after it is udev, if we have an apparmor profile for udev
<pitti> everything else seems okay
<pitti> but given how udev rules are pretty much almighty, it doesn't seem to make much sense to try and confine it
<pitti> upstream runs udevd in its own mount namespace, but we have some bits that rely on that it doesn't
<mdeslaur> I don't care about confining udev...just about how udev handles having network devices pop up, for example
<mdeslaur> but I gather it waits for NM
<pitti> mdeslaur: right, that's already sorted; apparmor runs before sysinit.target which is a dependency of network-pre.target, and everything regarding network conf depends on that
<pitti> (both statically from /etc/network/interfaces and dynamically via ifup@.service, i. e. udev events)
<pitti> (FTR, network-pre.target is the place where firewalls and the like should hook into -- to run before the first interface is brought up)
<hallyn> pitti: thanks!
<mdeslaur> pitti: ok, so if it starts before networking, should be ok
<mdeslaur> good thing vivid isn't an LTS :P
<pitti> mdeslaur: heh, yes; we wouldn't swap out init in an LTS..
<mdeslaur> ;P
<pitti> then again, my doubts whether we'll actually switch in vivid are relatively high now, given how long the three last items have dragged on
<pitti> Riddell: are you asking just for personal interest, or does Kubuntu actually require/work better with systemd?
<mdeslaur> pitti: so you have a workaround for juju...what are the other two? nfs? does that mean nfs isn't currently handled in debian?
<Riddell> pitti: Plasma developers say they'll requre it from the end of this year, so no rush there.  and I was wondering if we'll need to worry about it for beta 1 or otherwise test this cycle
<pitti> mdeslaur: Debian uses NFS's init.d script; but our's is split into several upstart jobs, which slangasek wanted to keep; he said he'd rather do that himself
<mdeslaur> pitti: oh, I see
<pitti> Riddell: hm, I had expected KDE (or GNOME etc.) to rather use session systemd, and not really care about the system init?
<Riddell> pitti: yes of course, but aren't they related somewhat?
<pitti> Riddell: you need system systemd in order to run session systemd (I guess)
<pitti> but so far we are still using upstart for sessions
<tyhicks> pitti, mdeslaur: re apparmor changes> We're (upstream apparmor) currently discussing the libapparmor API changes to allow systemd to load apparmor policy cache files
<tyhicks> pitti, mdeslaur: v1 of that patchset is written and works great, but there are changes that need to be made to the API
<tyhicks> pitti, mdeslaur: After that lands, we need to add one more feature (support multiple apparmor policy caches) and then update kernel postinit script to generate a policy cache after installation
<tyhicks> pitti, mdeslaur: So, we're still a ways away from landing everything
<tyhicks> pitti, mdeslaur: But, jdstrand seemed to think that the init script is sufficient for now. (We all acknowledge that we want systemd to be able to do its own policy cache loads ASAP)
<tyhicks> pitti, mdeslaur: I haven't had a chance to look at the init script but what pitti said about it above is promising
<pitti> tyhicks: thanks for the update!
<pitti> tyhicks: right, that seems to confirm the "it works correctly but slowly" status quo, and how we'll improve it
<LocutusOfBorg1> hi, can anybody please sync virtualbox/guest additions from debian/experimental?
<LocutusOfBorg1> bug 1422134
<ubottu> bug 1422134 in virtualbox-guest-additions-iso (Ubuntu) "please sync virtualbox from debian experimental" [Undecided,New] https://launchpad.net/bugs/1422134
<caribou> is there any issue with package synchronization from Debian (experimental especially) ?
<caribou> I uploaded makedumpfile to experimental end of last week and it's still at the previous version in Vivid ?
<caribou> should I sync manually ?
<dobey> caribou: i think it's no longer auto sync after alpha or something like that perhaps?
<dobey> caribou: also did your change make it to unstable? i don't recall if we sync from experimental or unstable, but i think the latter
<caribou> dobey: no, unstable is frozen awaiting Jessie's release
<dobey> ah
<mitya57> pitti: Can you please look what happened to paramiko autopkgtest? The trace indicates that python(3)-crypto is not installed, however it should be pulled in via dependencies.
<caribou> dobey: but that's fine, I can sync manually I just wanted to be sure of the process
<didrocks> ochosi: accepted (building now)
<mdeslaur> infinity, slangasek, kees, stgraber: meeting?
<infinity> Oh, err.  Yes.  One of those.
<jdstrand> tyhicks (and pitti and mdeslaur): re apparmor init script as sufficient> I was speaking for Ubuntu Core and snappy apps. I don't know about system policy we ship in traditional desktop/server. that said, it sounds like pitti said it should be ok there too, so I guess I'm 'ok' with not landing it, but if systemd is pid 1 on the phone, the speed improvement would be quite good
<tyhicks> jdstrand, pitti, mdeslaur: I think we can land, in lp:apparmor, the changes needed for systemd to do policy loading in 1-2 weeks
<jdstrand> cool, let's continue to shoot for that
<cjwatson> caribou: We never auto-sync from experimental.
<cjwatson> dobey: import freeze is Thursday
<dobey> ah ok
<melodie> hi
<melodie> I would like to know what function the 3 following packages have: "libc-dev-bin", "libc6-dev:<arch>", "linux-libc-dev:<arch>", because they are in Ubuntu, they used to be in Lubuntu, when I made a custom version and didn't have them, the live iso booted to the login screen instead of booting to the desktop. What exactly is their function?
<melodie> I have had this question in mind for a real long time, and never had an opportunity to ask. now would be the time. :)
<melodie> especially as I have never seen them in the "ubuntu-standard" nor in the "ubuntu-minimal" packages...
<melodie> if anyone has a clue?
<dobey> apt-cache policy $package didn't answer it for you?
<melodie> I can see two of them come from the eglibc source, and linux-libc-dev is related to kernel headers.
<melodie> dobey if it's not in Lubuntu apt-cache policy would not answer. I was looking in the Ubuntu packages
<melodie> is there a command line which will say which package could possibly pull them in the flavors where they exist?
<dobey> err, not policy
<dobey> i meant apt-cache show
<dobey> seeded-in-ubuntu tells you where packages are seeded (if they are)
<dobey> apt-cache rdepends will show you what packages depend on them
<melodie> dobey I look thanks. I will perhaps try to read through eventual comments if any, in the sources
<melodie> dobey seeded-in-ubuntu brought me nothing because the packages I seek info are not "primary" packages, but rdepends says things. quite funny actually
<melodie> there are many reverse depends for each, what I notice is "libc6-dev" has one rdepends on "linux-libc-dev", and "linux-libc-dev" is also pulled in by "libc6-dev". (Several times in the list).
<melodie> isn't that strange?
<melodie> dobey I still don't know all the features they bring but I might have found why they are not in lubuntu
<jdstrand> sbeattie, tyhicks: hey, I had a question about apparmor 2.9 and ff
<tyhicks> hi
<jdstrand> sbeattie, tyhicks: this is prompted by two things: a) there is an apparmor 2.9 in the security proposed ppa, and b) bug #1422521
<ubottu> bug 1422521 in apparmor (Ubuntu) "mmap of ...mir/client-platform/mesa.so DENIED" [Undecided,Triaged] https://launchpad.net/bugs/1422521
<jdstrand> sbeattie: does 2.9 introduce features over 2.8.98-0ubuntu4?
<sbeattie> jdstrand: no, everything has been purely bug fixes in the polishing for the 2.9.0 and 2.9.1 releases.
<sbeattie> (well, there are minor things like supporting the generation of coverage information in the utils/ tests)
<sbeattie> but there should be no user visible features added between 2.8.98 and 2.9.1
<sbeattie> jdstrand: ^
<jdstrand> tyhicks, sbeattie: with that in mind, is there any urgency in getting 2.9 into vivid this week? it sounds like 1422521 is causing problems at least on the nexus 5
<jdstrand> and it we fixed that, it seems we would want to update to 2.9...
<jjohansen> more urgent than ecryptfs or systemd changes?
<jdstrand> well, I was thinking sbeattie would do it, and he isn't working on those as much, but certainly that is a consideration
<jdstrand> (to be clear, no I don't think more urgent than those)
<sbeattie> jdstrand: I'd been meaning to push 2.9 in to vivid for a while, but had gotten pre-empted by other priorities.
<jdstrand> right, hence the question here :)
<jdstrand> should it continue to be preempted or should it get uploaded
<jdstrand> tyhicks: thoughts? ^
<sbeattie> I ran the packages through qrt at one point, and I'm running them on my laptop, so I'm pretty confident in them.
<tyhicks> sorry, got distracted in another channel
 * tyhicks reads backscroll
<jdstrand> sbeattie: is what is in the ppa what you would want to push?
<jdstrand> (aforementioned bug aside)
<sbeattie> jdstrand: there are some minor fixes, mostly policy touchups, awaiting a 2.9.2 release.
<sbeattie> ... that have already been committed to the upstream 2.9.x branch.
<sbeattie> But I'd kind of like the gcc-5 issue to reach a statis point before releasing 2.9.2.
<tyhicks> sbeattie: how much work is it to cut 2.9.2, package, and test it?
<sbeattie> That said, we could come back with a 2.9.2 after FF, as it shouldn't have anything but bugfixes as well (other than what's needed for systemd support)
<sbeattie> tyhicks: not much, a day.
 * jdstrand notes https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor
<tyhicks> is 2.9.1 ready to push to vivid today?
<tyhicks> right - the test plan adds a bit to it
<jdstrand> tyhicks: we would need to run the test plan
<jdstrand> aiui
<sbeattie> okay, the test plan would take longer, as I haven't run through that before.
<jdstrand> it could be split up
<jdstrand> eg, I have a spare device I could do the touch testing on
<jdstrand> so the question is, test what we have and wait for 2.9.2 and upload that later, or wait for 2.9.2. I'm guesing systemd would be after that
<tyhicks> so if we get the gcc 5 fixes upstream today, cut a release tomorrow, and then test and upload on thursday, we could do 2.9.2
<tyhicks> jdstrand: systemd is definitely after that
<jdstrand> I don't think we need heroics for the ff since this isn't a ffe
<jdstrand> (since now I know it is just bug fix)
<jdstrand> so no it is simply is now a good time for sbeattie to do it or not
<jdstrand> now*
<tyhicks> sbeattie: what's your feeling?
<tyhicks> I'd assume that he's going to eventually cut 2.9.2 no matter what
<sbeattie> Yeah.
<tyhicks> but you're right, there's no need to rush around right before FF for a bug fix release
<sbeattie> I'd kind of like to get it in, as I imagine it would make the FFe for the systemd changes go easier if there aren't unrelated changes to go along with it.
<jdstrand> that said, we may not want to make 1422521 wait too long
<sbeattie> right.
 * tyhicks looks at the gcc 5 issues to get a feel for how long that'll take
<jdstrand> sbeattie: are you thinking 2.9.2 upstream will be ready some time this week?
<jdstrand> sbeattie: also, can I assign 1422521 to you?
<sbeattie> yeah, I was thinking that making sure the parser compiles under gcc-5 was worthy of cutting a release.
<sbeattie> (as I'm not sure of other downstreams timeframes for incorporating gcc-5)
<sbeattie> jdstrand: 1422521> sure.
<jdstrand> sbeattie: done (thanks)
<sbeattie> tyhicks: re 2.9.1 readiness> it's packaged and sitting in the sec-proposed-ppa, it could go after testing and incorporating the fix for 1422521.
<tyhicks> right
<tyhicks> sbeattie, jdstrand: lets go with 2.9.1 + the 1422521 fix
<tyhicks> sbeattie, jdstrand: no need to stress ourselves out for 2.9.2
<sbeattie> tyhicks: okay, that works.
 * jdstrand prepares spare device
<chiluk> did someone finally fix the lockscreen lockup problem?  I haven't had my desktop lockup in a few days now.
<melodie> good night
<arges> hallyn: around?
<zacthespack> Hello, out of interest how are the Ubuntu core rootfs generated? there are many build tools about but im interested in the best method to replicate a Ubuntu core rootfs from source
<zacthespack> if anyone has the info please drop me a PM or email: zacthespack@gmail.com
#ubuntu-devel 2015-02-18
<rsalveti> TheMuso: hey, do you have the src packages for pulse 6 around?
<rsalveti> TheMuso: could be the one you used to get the binaries for http://people.canonical.com/~themuso/pulse6-armhf/
<rsalveti> finally getting to validate it and wanted to review a few changes
<rsalveti> TheMuso: seems to be in sync with http://anonscm.debian.org/cgit/pkg-pulseaudio/pulseaudio.git/, so will use that :-)
<hallyn> arges: \o
<TheMuso> rsalveti: Pretty much, sorry was busy. The only change in the ubuntu branch of the git repo is using bluez 5, I just have to flip back to bluez 4 before doing the final upload.
<rsalveti> TheMuso: right, cool
<rsalveti> TheMuso: when rebuilding it locally it failed when executing the tests:
<rsalveti> FAIL: once-test
<rsalveti> both vivid and rtm, did you get that as well?
<TheMuso> rsalveti: What architecture?
<rsalveti> TheMuso: armhf
<TheMuso> rsalveti: Interesting, because I built it on real hardware and they passed.
<TheMuso> THey did fail for me in a qemu enabled chroot./
<rsalveti> hm
<TheMuso> rsalveti: And FWIW< the desktop team ppa is now enabled for armhf, and I got no failure there either with my recent upload.
<TheMuso> The transitions PPA.
<rsalveti> TheMuso: yeah, might be kernel
<rsalveti> http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-August/021066.html
<rsalveti> >>
<rsalveti> >> tests/once-test.c:74:F:once:once_test:0: Assertion
<rsalveti> >> 'pthread_setaffinity_np(pthread_self(), sizeof(mask), &mask) == 0'
<rsalveti> >> failed
<rsalveti> the same one I'm getting
<TheMuso> Can't remember what tests failed for me, since they weren't set to be verbose, but I know they did.
<pitti> jdstrand: on the phone is still quite some work to be done for systemd pid 1, that won't happen in time for vivid
<pitti> tyhicks: 1-2 weeks sounds like that should b perfectly applicable for an FFE
<pitti> mitya57: right, that just recently started failing, without a change in paramiko itself
<pitti> mitya57: python3-crypto does indeed not get installed any more
 * pitti looks
<Unit193> pitti: So what's the changes for systemd as default init in utopic?  A couple of us in the Xubuntu team have been wondering.
<pitti> Unit193: vivid, I take it :)
<Unit193> pitti: Think you'll pull in 219 since you got it mostly ready for exp?  Also, good morning!
<pitti> Unit193: good morning!
<Unit193> Err, yes, that..
<pitti> Unit193: yes, I'll merge it today
<pitti> Unit193: you mean how we'll actually do the switch? that should mostly be a seed change, but needs testing on upgrades of course
<Unit193> pitti: Well, more of when/if it'll still hit for vivid, ff being so soon.
<pitti> Unit193: we discussed this yesterday; still depends on bug 1312976; and to some degree on bug 1409639, but that's both scheduled to happen in March, and we could fall back to booting these instances with upstart
<ubottu> bug 1312976 in nfs-utils (Ubuntu) "nfs-utils needs systemd unit or init.d script" [High,Triaged] https://launchpad.net/bugs/1312976
<ubottu> bug 1409639 in juju-core (Ubuntu Vivid) "juju needs to support systemd for >= vivid" [High,Triaged] https://launchpad.net/bugs/1409639
<Unit193> pitti: Aha, sorry I missed that one.  Thanks!
<rsalveti> TheMuso: one change I saw that was missing: http://paste.ubuntu.com/10284738/
<TheMuso> rsalveti: Good catch, will add.
<TheMuso> rsalveti: Ok thats committed to the ubuntu branch.
<rsalveti> TheMuso: great, thanks
<TheMuso> rsalveti: Thank you for catching it. :)
<rsalveti> TheMuso: with the bluez4 build did you explicitly disabled bluez5?
<TheMuso> rsalveti: No, but I certainly can do that, and was actually thinking of doing so.
<rsalveti> TheMuso: yeah, might be better for now
<rsalveti> until we officially move to bluez5
<TheMuso> SOunds reasonable.
<TheMuso> Ok, committed, so I don't forget.
<ari-tczew> cjwatson: MoM is hanging on. (Generated at 2015-02-17 21:13:12 UTC.)
<rsalveti> TheMuso: so +1 after testing it, feel free to push to vivid
<rsalveti> at least from my perspective
<rsalveti> just replied the thread
<TheMuso> rsalveti: Ok cool. I've been running it on x86-64 in its various rc releases for a couple of months now, and whilst I haven't gone out of my way to test anything in particular, all seems ok for me here too.
<rsalveti> TheMuso: awesome
<Mirv> any early bird or late bird (bird=core-dev) to ack two pretty simple packaging changes to be landed? https://ci-train.ubuntu.com/job/ubuntu-landing-011-2-publish/lastSuccessfulBuild/artifact/packaging_changes_dbus-test-runner_15.04.0+15.04.20150218-0ubuntu1.diff + https://ci-train.ubuntu.com/job/ubuntu-landing-025-2-publish/17/artifact/packaging_changes_webbrowser-app_0.23+15.04.20150217.1-0ubuntu1.diff
<Mirv> oSoMoN did not explicitly state the latter's packaging changes in the changelog unfortunately, but they are in more detail at https://code.launchpad.net/~osomon/webbrowser-app/workaround-bug-1417118/+merge/248564 + https://code.launchpad.net/~osomon/webbrowser-app/on-close-requested/+merge/240437
<aeoril> darkxst does sbuild require a debian/Ubuntu package format?
<darkxst> aeoril, yes
<darkxst> you can login to a shell though and do manual builds, although thats probably better suited to a schroot
<mitya57> Mirv: in case you still need an ACK for those two changes, they LGTM
<Mirv> mitya57: \o/ yes, thank you. and if I didn't congratulate earlier on your core-dev:ness, I do it now. but I think I did :)
<mitya57> Thanks :)
<mitya57> You should also become one!
<Mirv> probably :) I usually take the slow route, but people are nudging me about it.
<seb128> slangasek, hey, any news about the systemd transition?
<aeoril> darkxst so all the patches in ChangLog will get applied to the stuff in src, resulting in an altered code base?  The code in src in the trusty package of libvte is dated pre-2011, but the latest patch in ChangeLog is dated 2013
<aeoril> darkxst I saw this:  http://packaging.ubuntu.com/html/patches-to-packages.html  I talked about quilt - now I am not sure what ChangeLog is for ...
<aeoril> darkxst I am not talking about debian/changelog, but ChangeLog in the directory with configure, autogen.sh, etc.
<aeoril> darkxst I went ahead and e-mailed a detailed report to chpe and asked for help
<darkxst> aeoril, Changelog is upstreams, debian/changelog is for debian/ubuntu packaging
<darkxst> quilt and debian/patches/series controls what patches are applied in a package
<aeoril> quilt and debian/patches/series control debian/ubuntu packages?
<aeoril> darkxst ^
<darkxst> aeoril, distro patches are applied with quilt
<darkxst> they live in debian/patches
<darkxst> and series defines which and in what order they are applied
<aeoril> darkxst yes, those patches in ChangeLog seem to be upstream patches.  It appears to have the form of a diff
<aeoril> series of diffs*
<darkxst> aeoril, you lost me here, debian/ubuntu patches maybe cherry-picked from upstream, but regardless they will be in debian/patches/ folder
<aeoril> darkxst I have made great progress.  I have found the code in vte and gnome-terminal where the child process is executed (in this case, vim, or whatever is fired off with the -e option)
<aeoril> darkxst no, the ChangeLog upstream patches file seems to be a series of diffs
<darkxst> gnome-terminal doesnt even have changelog
<darkxst> nor does vte
<darkxst> so I have no idea still, what you are talking about
<aeoril> darkxst why would the code in src predate 2011 for the trusty libvte?  The latest patches in the upstream patches file (ChangeLog) are dated 2013.  The ChangeLog I am talking about is in the "root" directory - the same one as configure is in, or autogen.sh
<aeoril> darkxst I thought you said earlier ChangeLog was upstream patches ...
<aeoril> (as opposed to debian/changelog)
<aeoril> [02:59] <darkxst> aeoril, Changelog is upstreams, debian/changelog is for debian/ubuntu packaging
<darkxst> aeoril, idk, changelog is documentation, its makes no sense for patches to be in there
<aeoril> darkxst so the ChangeLog I am talking about in the same directory as configure and autogen.sh doesn't actually do anything?
<darkxst> further these days with git, changelogs are useless
<darkxst> aeoril, it really shouldnt
<darkxst> it really should be a diff either, but even if it is I don't see how it would get applied during build (it can't)
<aeoril> darkxst I am very confused then - the code in src in the trusty source package seems to predate 2011 - that seems very old
<darkxst> aeoril, trusty may have had gnome-terminal 3.6?
<aeoril> darkxst I am talking about libvte (vte3).  It is ostensibly version 34.9.  From the git repo, 34.9 seems to be a commit dated 2013
<darkxst> aeoril, I am sure you will figure it out!
<aeoril> (using git log and searching for "34.9" I found a commit whose comment is "version 0.34.9" dated 2013)
<aeoril> ok, sorry - I'll stop bothering you
<aeoril> darkxst like I said, I sent an e-mail to chpe, so I am hoping that ends well.  Night.
<darkxst> it won't if the email was about the questions you just asked me!
<aeoril> darkxst no, not at all - I just told him the overall problem mentioning the race condition and if he remembered code to fix that
<aeoril> darkxst the questions I have just been asking have nothing to do with chpe - they are Ubuntu packaging questions
<aeoril> debuan/ubuntu
<aeoril> debian*
<darkxst> aeoril, ok, ping me again when/if you are really stuck,
<Mirv> Trevinho: hey! I was checking your pyotherside branch, but I get the following diff when comparing to actual git checkout of https://github.com/thp/pyotherside.git (the last commit on 20150111): http://pastebin.ubuntu.com/10288344/ - do you think you've made an error? both seem to build (I did some slight modifications to packaging)
<Mirv> Trevinho: having diff:d both from current 1.2.0 and your branch to the actual git master, yes it'd look like you've older git snapshot so I'll just go with the newer that seems to work as well
<flexiondotorg> Is there anyone in here who can review the Upload Queue? - https://launchpad.net/ubuntu/vivid/+queue
<Riddell> didrocks: what news from touch team and bluez5?
<didrocks> Riddell: they enabled two devices, still 2 which are more complex
<didrocks> Riddell: I wanted to know if they would get in time for FF, they aren't sure, ricmm is the one working on it
<didrocks> need to test something, rebooting quickly
<flexiondotorg> pitti, Could I request some assistance please?
<pitti> that's a really nasty trick question!
<pitti> (forgot the :) )
<flexiondotorg> pitti, The "glue" package for Ubuntu MATE were uploaded last Friday. They are in the upload queue.
<flexiondotorg> pitti, Could you find someone to review them please?
<flexiondotorg> https://launchpad.net/ubuntu/vivid/+queue
<flexiondotorg> All the *ubuntu-mate* packages and yuyo-gtk-theme are the ones I'm interested in.
<pitti> I'll spend some time on the queue after finishing my current SRU package
<flexiondotorg> pitti, Many thanks.
<pitti> utlemming: do you need bug 1420544 for precise, too?
<ubottu> bug 1420544 in systemd (Ubuntu Trusty) "Ubuntu instances on GCE should use NOOP scheduler" [Medium,In progress] https://launchpad.net/bugs/1420544
<pitti> flexiondotorg: why does grub2-themes-ubuntu-mate have a transitional grub-theme-ubuntu-mate package? that doesn't exist at all in Ubuntu?
<flexiondotorg> pitti, Ah. That isn't required. Agreed.
<flexiondotorg> It is a hangover from when those packages were shipped via a PPA.
<pitti> flexiondotorg: ok; want to reupload without it? I'll reject it from the queue in the meantime and will re-review after uploading?
<pitti> (looks ok otherwise)
<flexiondotorg> pitti, I will update the source package. But I have no upload rights.
<pitti> flexiondotorg: happy to sponsor it from vcs-bzr
<flexiondotorg> pitti, Thanks.
<flexiondotorg> Do I need to bump the version?
<pitti> flexiondotorg: no
<flexiondotorg> pitti, Do you want a new package-request bug?
<pitti> flexiondotorg: no, just tell me when you fixed, tested, and pushed
<pitti> (bzr push, I mean)
<flexiondotorg> pitti, It is done.
<pitti> flexiondotorg: rest NEWed
<flexiondotorg> pitti, ?
<pitti> flexiondotorg: I mean, I NEWed the other packages
<flexiondotorg> pitti, Thank you ð
<flexiondotorg> pitti, Also yuyo-gtk-theme is the official Ubuntu MATE theme.
<pitti> yep, getting there :)
<flexiondotorg> pitti, Right you are :)
<flexiondotorg> pitti, Question. If I find bugs in any of those packages I can request new version be uploaded after FF right?
<pitti> flexiondotorg: sure; bugs can be fixed until the bitter end
<flexiondotorg> Thought so
<pitti> i. e. right until when we prepare the final images
<pitti> flexiondotorg: "mate-meta" has a nice ring to it :)
<flexiondotorg> ;-0
<pitti> flexiondotorg: is it really desirable to ship both gtk 2 and 3 themes in yuyo-gtk-theme? that'll pull in gtk 2 even if you don't want/need it?
<flexiondotorg> pitti, Yes.
<flexiondotorg> MATE is currently built against GTK2.
<flexiondotorg> But the themes can integrate with GTK3 applications.
<flexiondotorg> So little bits of MATE use GTK3.
<pitti> ah, ok
<flexiondotorg> *Some
<flexiondotorg> pitti, There are some package that Ubuntu MATE depends on not uploaded yet.
<flexiondotorg> pitti, The plan was to get those package uploaded to Debian. But we are not going to make it before the Vivid FF.
<flexiondotorg> pitti, Do you anticipate any difficulty in getting sync exemptions for a few Debian packages after FF?
<Mirv> flexiondotorg: pitti: related to MATE, I'm also waiting for some archive admin to review the binNEW compiz-mate package at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021/+packages , summary of packaging changes https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/32/artifact/packaging_changes_compiz_1%3A0.9.12.1+15.04.20150213-0ubuntu1.diffâ
<Mirv> I mean, preNEW review, since that's how the train works
<rbasak> stgraber: on the kimchi (NEW) high port issue, it seems that the web app can't be changed to not use the root as the URL path.
<rbasak> stgraber: is this a sufficient reason to leave it for now, as the user will face a URL change later anyway to fix it properly?
<rbasak> can't (easily) be changed, anyway.
<rbasak> Upstream's concerned that he can't prepare a patch in time for feature freeze, so the only alternative is an FFe I think.
<flexiondotorg> Mirv, Thanks for the info.
<flexiondotorg> Mirv, pitti is ubiquity-slideshow-ubuntu-mate also held in a queue somewhere?
<Mirv> flexiondotorg: does not seem like it. compiz is just part of the CI Train so it does not show in the normal queues that it's waiting for approval (and it also needs manual pinging of archive admins like I'm now doing)
<flexiondotorg> Mirv, Understood. Thanks.
<pitti> flexiondotorg: not in https://launchpad.net/ubuntu/vivid/+queue?queue_state=0
<flexiondotorg> pitti, Thanks.
<pitti>  ubiquity-slideshow-ubuntu-mate | 92 | vivid | all
<pitti> flexiondotorg: ^ seems fine? :-)
<flexiondotorg> pitti, I've also been collaborating with the Xubuntu team.
<flexiondotorg> pitti, They have uploaded lightdm-gtk-greeter-settings which is required by both Xubuntu and Ubuntu MATE
<flexiondotorg> pitti, Thanks for clarifying ubiquity-slideshow-ubuntu-mate
<mitya57> pitti: did you manage to figure out what's wrong with paramiko?
<mitya57> I see that in a new build dependencies are still not installed
<pitti> mitya57: didn't get to that yet; still on my list
<mitya57> ok
<didrocks> @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: didrocks
<seb128> hallyn, pitti, didrocks, is cgmanager supposed to run under systemd with https://launchpad.net/ubuntu/+source/cgmanager/0.35-1?
<seb128>    Loaded: loaded (/lib/systemd/system/cgmanager.service; disabled; vendor preset: enabled)
<seb128> but it's inactive, not sure why
<pitti> seb128: on fresh installs, yes; if you upgraded from earlier vivid, the postinst doesn't enable itself
<seb128> oh ok
<seb128> why not?
<pitti> the changelog seemed to suggest that was on purpose, but I don't know why
<pitti> these days we need cgmanager mostly on the phone under systemd, AFAIUI
<didrocks> bug #1400394
<ubottu> bug 1400394 in cgmanager (Ubuntu) "Unity8 fails to start applications, cgmanager is not started under systemd" [Undecided,Fix released] https://launchpad.net/bugs/1400394
<didrocks> ah no, that was for the --enable
<didrocks> pitti: it should be enabled on upgrade from the changelog?
 * didrocks looks at the postinst
<didrocks> pitti: it is enabled by default, but I guess seb128 upgraded while we still had --no-enable on cgmanager
<seb128> didrocks, pitti, I'm asking because my unity8-desktop-next box still fails to start anything on vivid/systemd
<seb128> right
<seb128> I though that some upgrade would make untiy8 start working
<didrocks> seb128: yeah, if you upgraded before, you are screwed
<seb128> that seems suboptimal :-/
<didrocks> seb128: well, hence the long discussion on preset and default upgrades :)
<didrocks> that's exactly an example where we need that
<didrocks> not sure where xnox is with this patch as he decided to go on this while I proposed my help, but seems things are stuck now
<xnox> didrocks: que?
<xnox> didrocks: well, didn't address last review comments - code purge, yet.
<didrocks> xnox: I didn't see you posting another patch from the reviews comments
<xnox> didrocks: yeah, you are faster with the plymouth things =)
<didrocks> yeah, I would have hope we (ubuntu) can get it this cycle, but so close to FF, sounds hard now :p
<xnox> argh. i see =)
<didrocks> xnox: I don't want that we pile up debts with wrongly enabled/disabled services like cgmanager
<xnox> true.
<didrocks> seb128: so for now, I would say systemctl enable by hand
<seb128> didrocks, k, thanks
<pitti> mitya57: looking now; indeed this reproduces quite easily/fast with adt-run paramiko -d --- schroot vivid
<pitti> mitya57: oh! got it
<pitti> Package-Type: deb
<pitti> who does that.. ;)
 * pitti fixes autopkgtest's parser
<mitya57> pitti: haha
<pitti> mitya57: fix+test pushed, rolled out, paramiko running again
<mitya57> thanks!
<pitti> mitya57: ...green!
<mitya57> \o/
<stgraber> rbasak: New packages don't require FFes
<stgraber> rbasak: well, unless you intend to ship that thing in main or on a media
<rbasak> Oh. I didn't know that. I have filed FFes for them in the past, and had them approved.
<rbasak> stgraber: so you want this fixed in time for release? I'll ask for that, thanks.
<didrocks> @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:
<flexiondotorg> pitti, Thanks for your help today :)
<Noskcaj> Can we sync handbrake 0.10 from debian exp?
<mdeslaur> Noskcaj: you might want to add this if you do: http://paste.ubuntu.com/10295495/
<flexiondotorg> cyphermox, Hello
<cyphermox> flexiondotorg: hey
<cyphermox> how are you?
<flexiondotorg> Very well. Yourself?
<TheMuso> rsalveti: webrtc-audio-processing has an approved MIR: Bug 1325859
<ubottu> bug 1325859 in webrtc-audio-processing (Ubuntu) "[MIR] webrtc-audio-processing" [Undecided,Fix released] https://launchpad.net/bugs/1325859
<flexiondotorg> So, pitti got the remaining Ubuntu MATE into the official archive today.
<flexiondotorg> cyphermox, ^^^^^
<flexiondotorg> cyphermox, There are still a few packages missing from the official archive that Ubuntu MATE requires.
<flexiondotorg> cyphermox, But the ubuntu-mate-meta package is there.
<flexiondotorg> cyphermox, Can we (and I mean you here) start "trying" to build Ubuntu MATE image so I can at least see error logs and therefore what needs fixing?
<cyphermox> I think so, but maybe not today
<flexiondotorg> cyphermox, OK. No probs.
<flexiondotorg> cyphermox, When do you think we can ty this?
<cyphermox> flexiondotorg: I think it would end up being when infinity is no longer super-busy with trusty .2 release to review https://code.launchpad.net/~mathieu-tl/ubuntu-cdimage/ubuntu-mate/+merge/247939
<cyphermox> ^^ and check if we didn't forget something else
<flexiondotorg> cyphermox, I've got 2 more packages that are going in via Debian. Possibly one that won't make it now because the docs are GFDL so that will require a change to the seeds and meta package.
<cyphermox> ok
<flexiondotorg> cyphermox, Sure, no problem.
<cyphermox> well if you want to do the seed changes (because a missing, non-existing package will definitely make builds fail), I'll sponsor the metapacakge updates
<cyphermox> all up to whether debian can release your packages so we can sync them
<cjwatson> I'll review the cdimage branch
<cyphermox> cjwatson: cool, thanks.
<cyphermox> cjwatson: do you have an idea of about how long the builds take, on average?
<infinity> flexiondotorg: For the GFDL docs, you can do a main/nonfree split in Debian, and then in Ubuntu just introduce a tiny delta to make A depend on B if you wanted them both installed together or whatever.
<cyphermox> that way it would be easier for me to come up with a good crontab time
<infinity> cjwatson: Thanks for reviewing.
<infinity> cyphermox: crontab times are most irrelevant now, just slam it in somewhere.
<cyphermox> ok
<flexiondotorg> infinity, Thanks or the info.
<flexiondotorg> infinity, We are discussing this option now.
<infinity> cyphermox: I intend to pull all that staggered cron madness out at some point and just do it all in parallel at panic-o-clock, when I find a good time for that to be.
<cjwatson> cyphermox: <1hr I guess?  it's not really a big problem now that we have livefs in LP
<cyphermox> ahah cool ;)
<cjwatson> cyphermox: it just seems odd to have most of the builds staggered and then these two starting on top of each other.  I agree with infinity's long-term plan there though
<rsalveti> TheMuso: why it's not yet in main then?
<rsalveti> TheMuso: https://launchpad.net/ubuntu/+source/webrtc-audio-processing
<rsalveti> TheMuso: still shows as universe
<cyphermox> cjwatson: not a problem, I picked random different numbers.
<infinity> cjwatson: Did you ever give any thought to the unhandled-exit (SIGINT, maybe?) issue that causes ftpsync locking to break, or were you leaving that bug for me to learn to love your codebase more? :P
<infinity> Well, less about learning to love your code and more about learning how traps in python work.
<infinity> But that's probable a Google and a stackexchange away. :P
<cjwatson> I was pretty much leaving it for you.  It's not SIGINT, though, because SIGINT turns into a KeyboardInterrupt exception and that should be handled by the semaphore context manager stuff.
<cjwatson> Could be some signal that the Python runtime doesn't turn into an exception, such as SIGTERM.
<infinity> cjwatson: Kay.  I guess it'll take some experimenting to figure out if I can reproduce it.
<cjwatson> I think it's still only a hypothesis though.
<infinity> cjwatson: And then hope that whatever I reproduced is actually what's happening.
<cjwatson> Quite
<infinity> cjwatson: But if TERM's unhandled, that's worth fixing even if it's not the actual problem.
<infinity> cjwatson: Seems plausible, though, if people are starting backgrounded builds and then being filled with regret.  kill(1) is always close at hand.
<cjwatson> Could be.  I'm sceptical, it seems to happen a bit often for that.
<cjwatson> I'd suggest adding some logging of the semaphore state as a first step.
<cjwatson> That way we stand some chance of debugging, because one of the problems here is that we only find out about it days after whatever actually went wrong.
<infinity> I'd say it happens too often for manual start/kill to account for it, but the touch/core/snappy/etc people seem to do a lot of manual building.
<infinity> rsalveti did several today while I was point releasing. :P
<rsalveti> right, indeed common
<rsalveti> :-)
<cjwatson> manual builds, yes, but I would have thought "argh, Ctrl-c" was a much more common response to regret than "argh, find another shell, look up pid, kill"
<TheMuso> rsalveti: No idea...
<infinity> cjwatson: Don't know about others, but I'm sort of 33/33/33 between start-and-background, screen-and-start-in-foreground, and start-in-foreground-oh-crap-no-screen.
<rsalveti> infinity: do you know why webrtc-audio-processing is still in universe? it should have moved to main by looking at https://bugs.launchpad.net/ubuntu/+source/webrtc-audio-processing/+bug/1325859
<ubottu> Launchpad bug 1325859 in webrtc-audio-processing (Ubuntu) "[MIR] webrtc-audio-processing" [Undecided,Fix released]
<infinity> cjwatson: So, I'd have a 33% chance of needing to kill if there was regret. :P
<infinity> rsalveti: If I had to guess, I'd say it fell back into universe due to nothing depending on it.
<rsalveti> infinity: could be, it took a few months for the new pulseaudio to land
<cjwatson> ah, I have an "s" wrapper which is exec ssh -t "$1" screen -ARD
<cjwatson> so it's actually less typing for me to ssh-and-screen than just ssh
<rsalveti> infinity: what should I do to request it to be moved to main again?
<infinity> rsalveti: This is enough.
<infinity> rsalveti: Is something trying to build against it and failing?
<rsalveti> infinity: pulseaudio 6, had to revert that dependency to make it to build (so I could get an image for wider testing)
<rsalveti> and now checking why that package was in universe
<infinity> rsalveti: I don't see it showing up in component-mismatches.  Oh, cause you reverted.
<rsalveti> TheMuso just found out about this mir
<infinity> rsalveti: So, yeah, I can re-promote, but use it today, please, or it'll just get bumped down by someone else again.
<rsalveti> infinity: yup, can revert my revert right after
<infinity> rsalveti: Go nuts.  Re-promoting now.
<rsalveti> infinity: lovely, thanks!
<cyphermox> cjwatson: infinity: would it be too early or too taxing on resources to kick off an ubuntu-mate build to check where we're at?
<cjwatson> cyphermox: I don't much care but don't know if it gets in the way of trusty point releasing
<cjwatson> oh, might need to create the livefs object in LP
<cjwatson> that's done, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/vivid/ubuntu-mate
<infinity> cyphermox: Won't hurt my feelings if you try, I'm most concerned that if you're merging code into ubuntu-cdimage and pulling it on nusakan, you might introduce a bug that breaks me if I have to respin.
<infinity> cyphermox: Resource contention shouldn't be an issue though.
<infinity> cyphermox: Of course, we may have another ubiquity bug to hunt down, if elfy's crash wasn't cosmic rays. :P
<cjwatson> infinity: er yeah oops kind of too late on that bit
<cjwatson> wind back a revision if you care :)
<infinity> cjwatson: You haven't been gone long enough to be a cowboy yet.
<cjwatson> yee-ha
<flexiondotorg> cyphermox, I think the ubiquity-slideshow-ubuntu-mate package is broken somehow.
<flexiondotorg> When I look at the other slideshow packages for other flavours version 92 is shown as in [unviverse].
<flexiondotorg> http://packages.ubuntu.com/vivid/ubiquity-slideshow-xubuntu
<flexiondotorg> Package: ubiquity-slideshow-xubuntu (92) [universe]
<flexiondotorg> But this is how it reads for http://packages.ubuntu.com/vivid/ubiquity-slideshow-ubuntu-mate
<flexiondotorg> Package: ubiquity-slideshow-ubuntu-mate (92)
<flexiondotorg> cyphermox, Consequently ubiquity-slideshow-ubuntu-mate is not installable.
<cyphermox> ah, right
<infinity> Having it in main wouldn't make it uninstallable.
<infinity> Though it shouldn't be there, I assume.
 * infinity demotes.
<flexiondotorg> infinity, Thanks.
<flexiondotorg> infinity, Many, many people helped upload stuff last Friday. I lost track of who did what but it seems ubiquity-slideshow-ubuntu-mate was misplaced.
<infinity> flexiondotorg: If you're having installability issues, that wasn't it, for the record.
<cyphermox> infinity: if anything breaks, we'll need to add a new test I guess.
<flexiondotorg> I don't think it should be in 'main'.
<infinity> flexiondotorg: It was in main because it's produced by a source in main, and it defaulted there.
<infinity> flexiondotorg: Not a big deal.  universe is a superset of main, your ISO contains lots (and lots) of packages in main. :P
<flexiondotorg> infinity, Thanks for your help.
<flexiondotorg> infinity, How soon will that repo change be reflected?
<infinity> flexiondotorg: 30-60 minutes.
<flexiondotorg> Perfect
<cjwatson> you have no reason to wait for it for anything, though
<flexiondotorg> cjwatson, I still have my cobbled together iso build system so I can test stuff.
<flexiondotorg> That is complaining that ubiquity-slideshow-ubuntu-mate is missing.
<cjwatson> I find it very difficult to believe that that is due to it being in main
<cjwatson> as infinity says, a large number of critical packages that you use are in main
<cjwatson> unless you're actually manually downloading it from pool/universe/blah
<flexiondotorg> It does appear to know it is in main.
<flexiondotorg> Or wasin main.
<flexiondotorg> I use live-build.
<rsalveti> infinity: seems just the arm64 package is waiting for the missing dep: https://launchpad.net/ubuntu/+source/pulseaudio/1:6.0-0ubuntu3/+build/6990338
<rsalveti> which is available (guess migrating to main still?) https://launchpad.net/ubuntu/+source/webrtc-audio-processing
<infinity> rsalveti: Just started building too soon, I imagine.
<infinity> rsalveti: A retry should make it happy.
<rsalveti> great, thanks
<cyphermox> flexiondotorg: I'd expect live-build to get it the right way, not downloading "manually" but rather building a proper livefs with debootstrap or something, could you paste the errors if it still fails later, just in case? I'll look when I get back
<flexiondotorg> cyphermox, Sure.
<flexiondotorg> cyphermox, I may try again tomorrow. So, I'll ping you then if there is a problem.
<cyphermox> ok
#ubuntu-devel 2015-02-19
<nickSwe> Is it possible in some way to have the top unity panel 100% transparent? I have tried all (compiz, unity tweak tool etc).. All is set to 0 opacity but it is still slightly shaded. I think it is a bug in unity. But is there a workaround? For example a png file somewhere that I can modify to 100% transparency?
<nickSwe> This is Ubuntu 14.10
<pitti> Good morning
<pitti> flexiondotorg: you're welcome!
<Unit193> Howdy.
<pitti> meh, syntax error in /usr/lib/python3/dist-packages/DistUpgrade/DistUpgradeViewKDE.py breaks the world
<pitti> ah, that was from https://launchpad.net/ubuntu/+source/ubuntu-release-upgrader/1:15.04.6 which has been removed since
 * pitti restarts a gazillion tests then
<Unit193> Heh, I have a merge for that package pending.
<kenvandine> pitti, thanks!
<kenvandine> i was just looking at the excuses page :)
<pitti> kenvandine: yeah, my ubuntu mailbox greeted me this morning with tons of jenkins failures
<kenvandine> good morning seb128!
<seb128> kenvandine, hey! you gave up on sleeping? ;-)
<kenvandine> seb128's up... i should really go to bed
<kenvandine> :-p
<seb128> hehe
 * kenvandine goes to get some sleep
<pitti> bonjour seb128
<pitti> seb128: you're up early, too!
<seb128> pitti, salut, same as every day (maybe started IRC some 15 minutes earlier)
<dholbach> good morning
<dholbach> @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: dholbach
<dholbach> bdmurray, can you take a look at https://code.launchpad.net/~unit193/ubuntu-release-upgrader/core-upgrades/+merge/250224?
<dholbach> slangasek, do you know who could take a look at https://code.launchpad.net/~tj/grub-installer/lp1354730/+merge/250100?
<dholbach> smoser, can you take a look at https://code.launchpad.net/~niedbalski/ubuntu/vivid/curtin/fix-1263181/+merge/250163 please?
<dholbach> seb128, can somebody take a look at https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/1340067?
<ubottu> Launchpad bug 1340067 in gnome-terminal (Ubuntu) "Drop 20_add_alt_screen_toggle_ui.patch - it does nothing with vte3 >= 0.34.9" [Medium,Confirmed]
<seb128> dholbach, don't ask me? no idea about vte or g-t, maybe larsu or Laney know
<dholbach> seb128, sorry, I thought you could ping somebody on the desktop team to look at it
<darkxst> dholbach, it should already be dropped
<seb128> dholbach, you can just join #ubuntu-desktop and ask there :-)
<dholbach> darkxst, can the bug be closed then?
<seb128> dholbach, that's a good way to ping the desktop team on IRC ;-)
<dholbach> seb128, I'm looking at lots of open sponsorship bugs right now :-(
<Laney> it's asking for a SRU
<darkxst> dholbach, no, I don't thinks its been dropped though you are correct it does nothing
<Laney> I don't think there's much point bothering
<Laney> pretty sure it is gone
<seb128> dholbach, yeah, just saying that pinging channels works better than asking individuals
<dholbach> Laney, darkxst: so what do you want me to do now? close the bug and say we won't SRU?
<Laney> dholbach: There's some UI which doesn't work due to it, so it might be worth uploading on that basis
<Laney> should be "Fix Released" for vivid and confirmed for trusty & utopic afaics
<dholbach> GunnarHj, happyaron: do you know if anyone is looking into getting 1377370 merged?
<Mirv> would an archive admin ack compiz that has a new compiz-mate binary package? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-021 + https://ci-train.ubuntu.com/job/ubuntu-landing-021-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.1+15.04.20150213-0ubuntu1.diff - I also asked on Tue + Wed, but today would be FF so it'd be useful to get it in
<dholbach> LocutusOfBorg1, I'll fake a new changelog entry for bug 1416651
<ubottu> bug 1416651 in inkscape (Ubuntu) "Please merge inkscape 0.91-3 from Debian experimental (main)" [Medium,Triaged] https://launchpad.net/bugs/1416651
<LocutusOfBorg1> oops dholbach hold on
<LocutusOfBorg1> debian has the -3 upload now
<LocutusOfBorg1> let me update it
<dholbach> yes, I know
<Laney> Mirv: why don't you upload it and get them to ack in the queue as would be normal?
<dholbach> LocutusOfBorg1, I did it already
<LocutusOfBorg1> you rock man! ;)
<Laney> (or don't you have upload rights to compiz?)
<Mirv> Laney: because CI Train goes past it ...
<Laney> huh
<Laney> I remember that it used to, but copies certainly work for UNAPPROVED - why not NEW?
<Mirv> sil2100: can you confirm what's the current behavior ^ I'm working on the assumption that the text at the top of the diff is still right
<dholbach> LocutusOfBorg1, is http://paste.ubuntu.com/10305574/ what you would have done?
<dholbach> LocutusOfBorg1, what about debian/patches/0006_add_unity_quicklist_support.patch?
<sil2100> Mirv: from what I remember binary packages get pass NEW and go straight to -proposed
<sil2100> Mirv: new source packages only get stuck in NEW
<dholbach> Laney, could it be that debian/patches/0006_add_unity_quicklist_support.patch was just mentioned in inkscape (0.48.5-3ubuntu1) but never added?
<Laney> anything could be
<LocutusOfBorg1> dholbach, they seem already applied to the source
<LocutusOfBorg1> https://sources.debian.net/src/inkscape/0.91-3/inkscape.desktop.in/
<Laney> dholbach: am I to blame? :P
<dholbach> Laney, you uploaded that version, but the patch file is not in the source package :)
<Mirv> Laney: ^ what sil2100 said, so we need that preNEW acceptance from archive admin instead.
<LocutusOfBorg1> dholbach, not a problem, the patch is not needed anymore
<LocutusOfBorg1> :)
<dholbach> LocutusOfBorg1, ok
<highvoltage> .wub 47
<Laney> dubstep wub wub wub
<LocutusOfBorg1> if you look the source it is already included
<dholbach> LocutusOfBorg1, I was just confused and thought, if we drop a patch we should probably mention it
<highvoltage> (oh dear)
<LocutusOfBorg1> dholbach, if we didn't apply it how can we mention the drop? :D (just joking)
<dholbach> LocutusOfBorg1, move along, nothing to see here
<dholbach> ok, nevermind then :)
<dholbach> I'll do a test-build and upload it later on
<dholbach> thanks Laney, thanks LocutusOfBorg1
<LocutusOfBorg1> :) you are welcome
<LocutusOfBorg1> I already did the test rebuilds on my ppa IIRC
<LocutusOfBorg1> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+packages
<LocutusOfBorg1> just armhf has failed I guess because of a qemu stack problem (as usual)
<Laney> wait what
<Laney> dholbach: LocutusOfBorg1: laney@iota> GET https://launchpad.net/ubuntu/+archive/primary/+files/inkscape_0.48.5-3ubuntu2.debian.tar.xz | tar tJ --wildcards debian/patches/0006_add\*
<Laney> debian/patches/0006_add_unity_quicklist_support.patch
<Laney> ?
<dholbach> sorry, I found the mistake
<dholbach> I had the unstable version unpacked locally
<dholbach> LocutusOfBorg1, ^ I'll add something to the changelog entry explaining the patch is upstream now
<Riddell> bdmurray: thanks for fixing ubuntu-release-upgrader, I'll do another upload now
<Riddell> pitti: ubuntu-release-upgrader_15.04.7 up â
<seb128> dpm, pitti, wgrant, how often are we supposed to have vivid langpack updates?
<dpm> seb128, exports are set up weekly (although it seems 2 weeks ago it wasn't generated) -> https://translations.launchpad.net/ubuntu/vivid/+language-packs I think pitti has langpack-o-matic for vivid to follow that
<pitti> seb128: the cronjob is running every Tuesday
<wgrant> Yeah, they're triggered weekly.
<wgrant> But the Launchpad side of it is very fragile. Should be a bit happier now that we have SSDs, though.
<pitti> https://launchpad.net/ubuntu/+source/language-pack-de/+publishinghistory
<seb128> why is the current one from 0202 then?
<pitti> indeed that's usually weekly, but we missed the two recent ones
<pitti> https://translations.launchpad.net/ubuntu/vivid/+language-packs
<pitti> so ther was no export on Feb 09
<dpm> yeah, but there was one on the 16th
<LocutusOfBorg1> thanks dholbach :)
<pitti> seb128: ah, and Tuesday I indeed got a cron failure from langpacks as it tripped over a still running utopic import
<pitti> so, two rare conditions hit within a week
 * pitti restarts the one from this week
<seb128> pitti, danke
<pitti> apw, ogasawara: nice to see the kernel autopkgtests landing now! note that there's one failure, see https://jenkins.qa.ubuntu.com/job/vivid-adt-linux/
<pitti> https://jenkins.qa.ubuntu.com/job/vivid-adt-linux/60/ARCH=i386,label=adt/artifact/results/ubuntu-regression-suite-stdout is probably the smallest/most useful log to look at
<pitti> (the complete log is 4.5 MB due to also having the package build output)
<apw> 09:58:33 INFO | END GOOD--------timestamp=1424339913localtime=Feb 19 09:58:33
<apw> pitti, doesn't that say "i worked just fine?"
<pitti> apw: the last test succeeds, yes; but scroll up :)
<pitti> 09:29:26 INFO |         END ERROR       ubuntu_seccomp.seccomp  ubuntu_seccomp.seccomp  timestamp=1424338166    localtime=Feb 19 0
<apw> oh i see that is just bile as normal ... can you say "i hate test suites which have GOOD at the bottom of logs"
<pitti> 9:29:26
<apw> pitti, yeah that is UTTERLY USELESS :)
<pitti> grep FAIL /tmp/ubuntu-regression-suite-stdout
<pitti> that's more useful
<pitti> apw: let's just say this is a test that britney actually holds back a kernel with regresssion :)
<apw> pitti, yeah, the damn test suite should grep that out for sure into a summary log ... sigh
<apw> pitti, but yes indeed
 * pitti wants to look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#linux but people.c.c seems down?
<apw> pitti, scheduled maintenance apparently
<apw> pitti, as so do i :)  so i can see what it looks like, to detect and report it
<apw> pitti, and rmadison is gone ... ugg, my world just become a spew of urllib.urlopen failures
<pitti> apw: there's also the "Jenkins failed" mail that the uploader gets -- in this case, ogasawara
<pitti> which gives you the notification and the public+private jenkins links
<apw> pitti, yeah but frankly that is too specific a person as they might be sleeping etc
<pitti> apw, ogasawara: so, if landing that kernel is urgent, it's ok to mark that as "skip bad test", as it's just a new test and not really a regression
<pitti> apw: yes, we can surely fine-tune that
<apw> pitti, there is a .yaml for this kind of thing, so i assume it is usable to find this issue
<pitti> seb128: bah -- langpack build failed for the same reason as people.u.c. etc. being down
<Laney> oh noes, can't syncpackage either
<Laney> terrible!
<seb128> pitti, k, I guess to retry later :-/
<apw> pitti, i think we are about to replace this kernel with a 3.19 so there is no rush at all, and it being in this mess should be investigated, and it serves to allow tooling to detect it to be written
<apw> ONCE people.c.c comes back of course
<pitti> apw: the jenkins logs work, it's just the britney output that's currently AWOL
<apw> pitti, yeah i am pretty sure i was looking yesterday and tehre is a nice parsable output we cna use to find the list of tests and see if any say Regression
<apw> pitti, we should consider pumping those into #ubuntu-devel :)
<pitti> uh, you don't want that :)
<pitti> not with the gazillion failures that I get every day
<apw> :) no i am sure i don't
<pitti> last week it was the jenkins hiccup which broke hundreds of tests
<pitti> last night the python-dist-upgrader one, etc. (although this one might have actually been useful)
<Odd_Bloke> dholbach: I'd love it if you could have a look at https://bugs.launchpad.net/ubuntu/+source/irssi/+bug/1423499 :)
<ubottu> Launchpad bug 1423499 in irssi (Ubuntu) "Please merge irssi 0.8.17-1 (main) from Debian testing (main)" [Undecided,In progress]
<dholbach> Odd_Bloke, ok
<dholbach> Odd_Bloke, responded
<Odd_Bloke> dholbach: Thanks; taking a look.
<Odd_Bloke> dholbach: Concern addressed; I've removed those files.
<dholbach> ok cool
<pitti> apw: people is back
<apw> pitti, thanks
<Laney> tyhicks: ooh, I see apparmor stuff is landing in dbus upstream now!
<dholbach> @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:
<xnox> pitti: address the ubuntu-drivers-common review -> will you merge and cut a release, or shall i cherry-pick into the ubuntu package?
<xnox> https://github.com/tseliot/ubuntu-drivers-common/pull/11/files
<xnox> well.
<xnox> https://github.com/tseliot/ubuntu-drivers-common/pull/11
<GunnarHj> dholbach, happyaron: As regards bug #1377370 we are simply waiting for a core dev to get it in, I suppose.
<ubottu> bug 1377370 in ubuntu-meta (Ubuntu) "ubuntu-desktop should depend on ibus-gtk" [High,Confirmed] https://launchpad.net/bugs/1377370
<pitti> xnox: ack, thanks for fixing! I'll merge/upload
<xnox> pitti: thanks.
<xnox> seb128: yo, the unity-settings-daemon patch is not enough to get highdpi ubiquity.
<xnox> seb128: however, booting unity7 desktop on vivid (livecd) does not do highdpi right either out of the box.
<seb128> xnox, hey, hum, ok, does it make any visible difference?
<xnox> seb128: upping the scale factor in the unity-control-settings-panel make things look right
<dholbach> GunnarHj, ok
<xnox> seb128: everything is same size.
<seb128> xnox, can you gdb/printf debug the code added to unity-settings-daemon to set what dpi it gets and what factor it computes?
<dholbach> GunnarHj, uploaded
<pitti> xnox: done, thanks!
<GunnarHj> dholbach: Tnx
<xnox> seb128: well, not now/today. gave the hardware up. However, ubiquity does rescale itself correctly when the scaling-factor is bumped. So i'm happy with that.
<seb128> xnox, yeah, and the u-s-d patch should set the factor, maybe it didn't think your screen was hi-dpi enough to do that though?
<seb128> xnox, can you check next time you have access to the hwd?
<xnox> yeah, i will.
<seb128> thanks
<xnox> seb128: you don't have hidpi hw do you?
<xnox> bregma: help us =)
<bregma> I can queue that up for later, what's the bug number?
<xnox> bregma: vivid livecd looks crap with highdpi -> both ubiquity & live desktop sessions.
<seb128> xnox, no, I don't
<seb128> xnox, that statement is weird, live session runs unity and should have working hidpi
<seb128> xnox, maybe your screen is not what we flag/consider as hidpi?
<xnox> bregma: there is a patch to unity-settings-daemon from seb128 at https://code.launchpad.net/~seb128/unity-settings-daemon/non-unity-sessions-need-scaling/+merge/250153 which suppose to fix ubiquity
<xnox> seb128: well it's a laptop, and it clearly is highdpi. i'll poke the values that are being checked.
<xnox> bregma: a confirmation that unity live desktop in vivid looks good in highdpi would be a good start =)
<cyphermox> good morning!
<xnox> bregma: and whether the seb's patch above fixes it for ubiquity as well would be good. -> boot on kernel cmdline with "maybe-ubiquity debug-ubiquity" -> get into live session / tty install the updated packages, and on tty1 do $ service lightdm restart -> to get a new ubiquity session up, but running patched unity-settings-daemon.
<Odd_Bloke> mvo: https://code.launchpad.net/~ubuntu-on-ec2/livecd-rootfs/cpc/+merge/250313 is the livecd-rootfs MP we discussed a little while ago.
<flexiondotorg> cyphermox, Hi ð
<flexiondotorg> cyphermox, Are you up for some sponsoring?
<cyphermox> sure
<flexiondotorg> cyphermox, Thanks!
<flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu/+bug/1423581
<ubottu> Launchpad bug 1423581 in Ubuntu " [needs-packaging] mate-menu" [Undecided,New]
<tyhicks> Laney: yes! it landed yesterday :)
<tyhicks> Laney: I plan on backporting the patches that landed to our vivid package and uploading today
<didrocks> cyphermox: hey, it seems that network-manager only enable now (with dhcp) to provide additional DNS, not replacing the primary one?
<didrocks> "nmcli device show wlan0" shows that I have 2 DNS (the one configured by the dhcp provider and then mine)
<cyphermox> didrocks: I don't quite follow? it should be working as it was before
<cyphermox> ah
<didrocks> cyphermox: see the nmcli comment, the string changed as well it's "additional DNS"
<cyphermox> maybe?
<cyphermox> I think it's already how it was
<didrocks> cyphermox: hum, so you can't override the primary with nm?
<cyphermox> but it's worth checking
<Laney> tyhicks: are they planning a release?
<cyphermox> didrocks: I don't know, don't think you could, but I'll ask on #nm
<didrocks> cyphermox: thanks :)
<cyphermox> didrocks: together with dnsmasq it shouldn't be that much of a problem?
<didrocks> cyphermox: I guess I should configure dnsmasq, right
<cyphermox> didrocks: you had deconfigured it?
<cyphermox> if you tell me what precisely you're trying to achieve with the DNS servers I can offer some tricks maybe :)
<didrocks> cyphermox: just want to replace the DNS servers from the ISP provider by other ones as primary (they have some technical issues right now and so, quite slowâ¦)
<cyphermox> ah, yeah
<tyhicks> Laney: not quite sure - they did a 1.9.12 release, which includes AppArmor support, but we'd need to wait for 1.10 for it to have security support
<cyphermox> dnsmasq is probably going to help you there.
<cyphermox> flexiondotorg: any other ubuntu developer checked it out to review it?
<flexiondotorg> cyphermox, Not Ubuntu. But it was checked by a Debian developer.
<cyphermox> didrocks: would you happen to have time to review the package in bug 1423581?
<ubottu> bug 1423581 in Ubuntu " [needs-packaging] mate-menu" [Undecided,New] https://launchpad.net/bugs/1423581
<cyphermox> I'm doing a review right now and will upload
<mvo> Odd_Bloke: sure, I have a look
<didrocks> cyphermox: can do the new review after yours, yeah
<didrocks> cyphermox: just ping me
<cyphermox> ah, so do you think I should just ignore the part about two ubuntu devs reviewing before upload?
<cyphermox> I'm sponsoring, it's not my own package ;)
<bdmurray> Riddell: thanks, there are some pep8 errors found when using bzr-buildpackage too.
<Odd_Bloke> mvo: Thanks. :)
<didrocks> cyphermox: well, it will go to the NEW queue, so that will be the second review and I can ack directly :)
<cyphermox> fair enough :)
<cyphermox> flexiondotorg: ah, mate-menu doesn't work yet with python3?
<flexiondotorg> cyphermox, It does not. python2 only.
<flexiondotorg> I will consider a python3 port in the next cycle.
<cyphermox> ok
<cyphermox> what provides git clone libmatedesktop and libmatepanelapplet?
<flexiondotorg> cyphermox, ?
<cyphermox> it's in the build-depends for mate-menu
<flexiondotorg> libmatedesktop comes from mate-desktop, already in the 15.04 archive.
<cyphermox> ah
<flexiondotorg> libmatepanelapplet comes from mate-panel, already in the 15.04 archive.
<cyphermox> hmm, weird, they weren't coming up
<cyphermox> ah, the name may be wrong there
<cyphermox> flexiondotorg: also, you're missing a debian/watch file so I can't download the source tarball
<flexiondotorg> cyphermox, I'll fix the watch file shortly.
<Trevinho> Mirv: hey, for some reason yesterday I missed your pings on pyotherside here... No notification at all... Btw... new pyotherside has been released http://thp.io/2011/pyotherside/
<Trevinho> so, if we want to sync that from debian instead...
<flexiondotorg> cyphermox, mate-menu has been updated.
<cyphermox> flexiondotorg: ok
<flexiondotorg> cyphermox, Also ð
<flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu/+bug/1423597
<ubottu> Launchpad bug 1423597 in Ubuntu "[needs-packaging] mate-tweak" [Undecided,New]
<Mirv> Trevinho: yep, so to clear any confusion what I uploaded was the real git snapshot, not your branch, so it should be pretty up-to-date. I'm EOD, but if you can get someone to a) upload 1.4.0 to Debian, b) sync it from there to Ubuntu during the next 5 hours and 20 minutes, it's still possible to make the version number neater :)
<Trevinho> Mirv: yes I saw you fixed my mistake (sorry)...
<Trevinho> Mirv: so ubuntu version includes now latest git, a part from one missing commit fixing a crash... But well,  we can live without...
<LocutusOfBorg1> dholbach, what about syncing tomcat8 from debian experimental?
<Trevinho> Mirv: so, no worries... Enjoy your evening and thanks... Do you know anyone here that could do that?
<LocutusOfBorg1> also tomcat7 would be nice to see updated :)
<dholbach> LocutusOfBorg1, I have no idea about tomcat
<cyphermox> flexiondotorg: can you please add (LP: #xxxx) to the changelog for mate-tweak to close the needs-packaging bug as the upload gets done?
<flexiondotorg> cyphermox, Sure.
<flexiondotorg> cyphermox, (LP: #xxxx) added to mate-menu and mate-tweak.
<cyphermox> thanks. It's a little late for mate-menu though
<cyphermox> I uploaded it without (oops)
<cyphermox> we'll see if didrocks feels forgiving :)
<flexiondotorg> cyphermox, I won't tell if you don't ð
<Mirv> Trevinho: it's not lowNMU so your best luck would be Zygmunt himself (the maintainer) or anyone on the Debian Python team
<didrocks> it won't close them anyway
<didrocks> as there is no mate-tweak or any other task
<cyphermox> oh, true
<cyphermox> well, I'll upload mate-tweak soonish
<flexiondotorg> cyphermox, You're a star thanks.
<cyphermox> ah crap, I forgot about what I told you of libmatedesktop too
<cyphermox> I'm trying to do too many things at once without coffee
<flexiondotorg> cyphermox, Get coffee ð
<flexiondotorg> cyphermox, I know this place by the central station ;)
<cyphermox> my coffee is already brewed and has been waiting for me in the machine for the past >30 minutes
<ScottK> tkamppeter: I have an HP Officejet 6700 that is giving me really weird print results (sometimes offset and generally rotated to varying degrees) to the point it's pretty useless.  This is with 12.04.  Is this something you've heard of?  Suggestions on how to troubleshoot?
<bdmurray> dholbach: I will
<dholbach> thanks bdmurray
<didrocks> flexiondotorg: cyphermox: doesn't make sense for me to NEW it before libmatedesktop and such are sponsoring though, so waiting (but on urgent debugging right now)
<cyphermox> didrocks: I was about to tell you to reject it, since that piece is wrong
<cyphermox> AIUI it should be libmate-desktop-dev and libmate-panel-dev, the names as they are are most likely remnants of previous naming
<cyphermox> er,, not -dev but ykwim
<didrocks> cyphermox: ok, flushing
<cyphermox> sorry
<didrocks> no worry, it's a click away :)
<didrocks> done
<cyphermox> hmm.. the big deal is that libmatedesktop is a Provide from libmate-desktop-2-17 (and any other), coming from mate-desktop
<cyphermox> didrocks: ^ as flexiondotorg pointed out earlier with fewer details
<didrocks> oh ok, yeah, sounds like this shouldn't be a Provide but dep on the soname
<dholbach> can somebody help fix bug 1368801?
<ubottu> bug 1368801 in libcitygml (Ubuntu) "libcitygml ftfs with new openscenegraph" [High,Triaged] https://launchpad.net/bugs/1368801
<Unit193> dholbach: Thanks for the upload!
<dholbach> Unit193, anytime
<slangasek> dholbach: https://code.launchpad.net/~tj/grub-installer/lp1354730/+merge/250100 -- cyphermox :)
<cyphermox> yes, going to merge this
<slangasek> pitti: why do you say that systemd is blocked on updating juju and maas?  I thought those could be dealt with out-of-band?
<pitti> slangasek: juju potentially yes; I don't know how we would deal with maas? (but I'm not familiar with it at all)
<dannf> infinity: any comments on https://code.launchpad.net/~dannf/debian-installer/arm64-cleanup/+merge/249738 ? i've posted an MP for lp:maas-images for smoser so that side of things should be good
<pitti> slangasek: and there's NFS too?
<slangasek> pitti: nfs is critical path, yes, and I'm going to get that sorted out today
<infinity> dannf: Not until after today's point release happens, I'm in multitasking hell.
<dholbach> thanks cyphermox, slangasek
<slangasek> pitti: I don't remember what the issue is with maas?
<dannf> infinity: ack
<slangasek> hum. what the heck is grilo-plugins and why is it being pulled into main?
<slangasek> gnome-music?  is that used on the Ubuntu desktop?
<pitti> slangasek: I figure primarily the fact that it has three upstart jobs, but no systemd units or sysv init scripts; I don't know whether it dynamically creates upstart jobs
<slangasek> ok
<infinity> slangasek: According to the MIR, it's totem.
<slangasek> pitti: I don't see maas broken out as a work item on https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration... have you spoken with anyone on the maas team about this?
<pitti> I thought we had a representative from the maas team on the last meeting, but indeed I don't see a bug
<slangasek> roaksoax: ping - is someone working on making maas work with systemd?
 * pitti creates one
<slangasek> rbasak: hey, so re: bug #1417328, I see that mariadb-10.0 is failing to migrate to trusty because several of the binaries that it builds are showing as uninstallable; do you know what's happening there or should I investigate?
<ubottu> bug 1417328 in percona-xtradb-cluster-5.5 (Ubuntu) "Please remove 5.5 versioned MySQL and variants from vivid" [Undecided,New] https://launchpad.net/bugs/1417328
<infinity> slangasek: It needs a smooth transition of mysql-5.6 with it, IIRC.
 * pitti files bug 1423613
<ubottu> bug 1423613 in maas (Ubuntu) "maas needs to support systemd for Ubuntu >= 15.04" [Undecided,New] https://launchpad.net/bugs/1423613
<rbasak> slangasek: I'm on top of it, with infinity's help. percona-xtradb-cluster-5.6 needs accepting first ideally. Then we can delete all the 5.5 packages, remove the old binaries, and everything should work.
<rbasak> In theory. There will inevitably be something I've missed.
<rbasak> slangasek: oh, for your specific question - yes - new mariadb binaries need the new mysql-common from src:mysql-5.6.
<slangasek> ok
<slangasek> rbasak, infinity: right, checked and confirmed that these packages are installable within vivid-proposed, so looks like percona-xtradb-cluster-5.6 will do the trick
<rbasak> BTW, percona-xtradb-cluster-5.6 depends on percona-galera-3, but the latter is relatively trivial.
<tkamppeter> ScottK, this behavior is not known to me. You should report a bug to HPLIP upstream (https://launchpad.net/hplip/). When reporting the bug follow the instructions on https://wiki.ubuntu.com/DebuggingPrintingProblems.
<ScottK> tkamppeter: Thanks.
<flexiondotorg> cyphermox, Is there anything additional I need to do with mate-menu or mate-tweak?
<ScottK> tkamppeter: Maybe I should try and backport hplip from vivid first and see if that fixes it.
<cyphermox> flexiondotorg: hold on, I'm on something else for a minute
<flexiondotorg> cyphermox, Sure
<cyphermox> flexiondotorg: I haven't reviewed mate-tweak yet
<infinity> rbasak: Speaking of the mysql-5.6 transition, php5 in vivid-proposed is failing to install build-deps with:
<infinity> The following packages have unmet dependencies:
<infinity>  mysql-server : Depends: mysql-server-5.6 but it is not installable
<infinity> E: Unable to correct problems, you have held broken packages.
<infinity> rbasak: Is that the same old "5.6 can't install while 5.5 still exists" bug that really needs to be understood and fixed, or something worse?
<rbasak> infinity: yeah. I'm a bit confused about that. AFAICT, it is installable in vivid-proposed, and my local sbuild succeeds on it
<rbasak> So I was going to retry after mysql-5.6 migrates.
<rbasak> It might have been something temporary while stuff was changing round or something.
<rbasak> (I've done so many uploads of mysql-5.6 and mariadb-10.0 and the deps are complicated enough that I can't contemplate the appropriate dependency history in my head right now)
<rbasak> I wonder. Is it a main vs. universe thing?
 * infinity wonders why and when php5 got a build-dep on mysql-*server* anyway.
<rbasak> mysql-server-core-5.6 binary for example is in universe.
<rbasak> msyql-server virtual package is in main.
<rbasak> Maybe that's it.
<infinity> rbasak: Oh, hrm.  I don't see that on component-mismatches-proposed.
<rbasak> I'm only guessing.
<infinity> Oh, yes I do.
<infinity> I'm blind.
<infinity> The whole mysql-5.6 source is in universe, that's why.
<infinity> I was looking at the binary-only section.
<infinity> So, yes, that needs fixing. :P
<rbasak> Ah. I was expecting to ask someone to fix that after things had migrated and settled.
<rbasak> I presume no MIR is needed for this one.
<infinity> rbasak: No MIR needed.  post-migration is the wrong time to ask for the fixing.
<Bluefoxicy> okay so
<rbasak> Oh. OK.
<rbasak> infinity: please could you fix? :-P
<infinity> rbasak: Doing so. :P
<Bluefoxicy> installing Ubuntu 14.04.1 LTS creates a dangling link /initrd.img -> /boot/initrd-3.13.0-32-generic
<Bluefoxicy> causing linux-image-3.13.0-32-generic to fail to install
<Bluefoxicy> causing linux-extra-blahblahblah to fail dependencies
<Bluefoxicy> causing install to halt.
<infinity> Bluefoxicy: Good thing we're just hours away from releasing 14.04.2 then.
<Bluefoxicy> ... this is from the 14.04.1-LTS server install on AMD64
<Bluefoxicy> infinity, oh good.
<Bluefoxicy> infinity, point me at the latest release plz.  I'll tell you if it's broken in like 10 minutes.
<tkamppeter> ScottK, yes, I think ths would be a good idea. 12.04 is rather old.
<ScottK> Actually I meant 14.04, but it's still older.
<Bluefoxicy> http://cdimage.ubuntu.com/trusty/daily-live/current/ is this it?
<Bluefoxicy> ... need server amd64
<infinity> Bluefoxicy: Should do.
<infinity> Bluefoxicy: Err, server.  You want /ubuntu-server/ in there.
<infinity> http://cdimage.ubuntu.com/ubuntu-server/trusty/daily/20150218.1/
<Bluefoxicy> aha, thanks.
<infinity> Bluefoxicy: Though that dangling link thing sounds like something more people would have noticed.  I'm curious how it's just you.
<Bluefoxicy> infinity, I'm using a 2GB ext2 /boot, LVM for the rest of that disk, with a separate /log and /var/spool/mail.  /boot is noatime,nodiratime,sync,nodev,noexec,nosuid,user_xattr
<Bluefoxicy> I don't think any of that would affect the ability to create the initrd file
<Bluefoxicy> k sec, my download is slow, currently coming at 28MB/s, give me a minute
<roaksoax> slangasek: as in the init jobs? no we have not looked at that.
<roaksoax> slangasek: is there some kind of spec?
<Bluefoxicy> still fails
<alexbligh1> how long in general does it take for a new release to appear on http://cdimage.ubuntu.com/releases/ ? 14.04.2 has been in the repo several hours, but the CD image isn't up. I'm guessing there is some kind of automated test process. I know I could use the daily build, but presumably that has *not* been through the test process yet.
<Bluefoxicy> infinity, http://i.imgur.com/b0BzWmZ.png
<Bluefoxicy> I get that out of console 4 ando ut of a chroot /target dpkg --configure -a
<infinity> alexbligh1: 14.04.2 doesn't exist until I say it does, essentially. :P
<Bluefoxicy> infinity, does console 4 log go anywhere I can extract full log from?
<infinity> Bluefoxicy: So, (a) this isn't a regression (obviously), and (b) it's pretty specific to you.  So, I'd love to debug it, but I won't be blocking 14.04.2 on it. :/
<alexbligh1> infinity, ah, the manual process of administering divine blessing :-)
<infinity> Bluefoxicy: /var/log/syslog should have the whole installation.
<Bluefoxicy> infinity, it looks like it fails to mount things
<Bluefoxicy> oh I see
<slangasek> roaksoax: spec is https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration
<Bluefoxicy> it tries to mount every partition to see what it is; it can't mount LVM physical volumes to /tmp/AnonTW or whatever
<slangasek> roaksoax: I'm trying to remember now what was discussed during the systemd sprint - did blake come to that?  Maybe it had been proposed that maas set a boot arg to continue booting upstart, until this is supported?
<Bluefoxicy> infinity, do you get a lot of getfattr Operation Not Permitted errors on syslog?
<Bluefoxicy> Operation Not Supported rather
<infinity> Bluefoxicy: If you feel your setup is sane and should be supported, please do file a bug on whatever's perpetrating the evil.
<Bluefoxicy> infinity,  I'm actually about to try a default install for a baseline.  It's just vmware esx
<jamespage> pitti, are we enabling the biosdevname equiv feature in systemd (as in http://fedoraproject.org/wiki/Features/SystemdPredictableNetworkInterfaceNames) for vivid?
<pitti> jamespage: no, we don't
<jamespage> pitti, so we'll still rely on biosdevname?
<pitti> we haven't enabled it yet in ubuntu, stgraber has some reservations about this
<pitti> jamespage: no, I thought we don't want the fancy names at all?
<pitti> the problem wasn't biosdevname or the udev equivalent itself, but too much software expecting the names to be "eth0" or "wlan0"
<Bluefoxicy> okay, the getfattr thing is normal; breakage is not.  I'll track it down and see what I can find out.
<Bluefoxicy> infinity, thanks
<jamespage> pitti, hrm - I think a stock server install on 14.04 installs biosdevname
<jamespage> pitti, did we take it out again post 14.04?
 * rbasak thought the same as jamespage
<pitti> oh, I don't know
<pitti> last time I discussed that with stgraber he said "we don't want this"
<jamespage> pitti, I'm pretty sure it does
<pitti> if we do, we can certainly enable that
<slangasek> I think the last time it was discussed was when we were being pushed to enable it via SRU
<pitti> we definitively don't install it on a desktop
<jamespage> pitti, there is some debate as to whether we do want to enable this
<jamespage> or disable it
<jamespage> pitti, agreed on desktop installs
<rbasak> https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/891258
<ubottu> Launchpad bug 891258 in biosdevname (Ubuntu) "Biosdevname auto enabled on Dell HW" [Medium,Fix released]
<rbasak> Dells only?
<cjwatson> no I'm pretty sure I refused to make that hw-specific
<rbasak> https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/891258/comments/18
<rbasak> That was when it was enabled by default. You're right - no reference to hw-specific there.
<pitti> ah, we got stuff like bug 1293633
<ubottu> bug 1293633 in ubuntu-meta (Ubuntu) "alternate install sets up biosdevname by default" [Undecided,Confirmed] https://launchpad.net/bugs/1293633
<cjwatson> but I enabled it on firm instruction and under protest
<pitti> so it's not desktop vs. server, it's ubiquity vs. alternates?
<rbasak> https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1347859 exists
<ubottu> Launchpad bug 1347859 in ubuntu-meta (Ubuntu) "Introduction of Predictable Network Interface Names (aka biosdevname) breaks working systems" [Undecided,New]
<cjwatson> so I am not advocating for it :)
<infinity> Maybe the systemd equivalent fixed all of this, but biosdevname was racy as heck and would leave interfaces in weird half-done "rename" states.
<infinity> It was not a pleasant solution to what, for most people, is a non-problem.
<slangasek> infinity: you're thinking of the precursor to biosdevname
<slangasek> or the precursor to its proper integration
<infinity> slangasek: I'm definitely thinking of biosdevname.
<infinity> slangasek: Yeah, I know the udev persistent rules also had that issue, but that was fixed.
<roaksoax>  slangasek nope, he didn't go to the systemd sprint
<slangasek> roaksoax: didn't he?  it was a virtual sprint and I thought he was there part of the time, but ok
<roaksoax> slangasek: i'll review the spec and probably have this looked at this week
<roaksoax> slangasek: we are sprinting now, so it probably makes sense for us to look at it
<roaksoax> now
<stgraber> jamespage, pitti: server has biosdevname, everything else doesn't
<slangasek> roaksoax: perfect, thanks
<bdmurray> shadeslayer: could you update bug 1375786?
<ubottu> bug 1375786 in Kubuntu PPA ".desktop files can not start apps with kdesu" [High,Confirmed] https://launchpad.net/bugs/1375786
<Bluefoxicy> Methinks it simply does not like having that many file systems mounted during install
<alexbligh1> in a Depends file, what is the correct way of depending on the version of Ubuntu? I want a package that will install on both P and T but the dependencies are different
<Bluefoxicy> infinity, Potential cause:  tar complains it can't remove /var/spool/mail.  I mounted something on /var/spool/mail.  Files can't be found in /var to build the initrd.  Perhaps the installer dislikes having a separate partition for mail.
<alexbligh1> s/Depends/control/
<Bluefoxicy> It's a decent enough use case for servers, because something as simple as a crontab * * * * * /bin/do_something_that_emits_output could make gigabytes of crap in /var/spool/mail/root which, by design, can't be rotated with logrotate.
<infinity> Bluefoxicy: Pretty please file a bug with syslog attached and your thoughts/debugging of the matter.  I'm far too busy today with the point release to give it proper attention.
<Bluefoxicy> infinity, nod.  Just fishing for info.  I'll add a bug later when I've done more testing.
<aeoril> darkxst I contacted cphe via e-mail and he thinks the bug is not in vte or gnome-terminal, but somewhere else in Ubuntu.  Unless someone else has any really helpful ideas, I am thinking of admitting defeat at this point
<happyaron> dholbach: thanks for merging 1377370, I'm on spring festival holidays, :)
<dholbach> happyaron, of course you are - enjoy the break! and happy new year!
<happyaron> xD
<zyga> pitti: hey, what's the best way to get pyotherside 1.4 into ubuntu today?
<pitti> zyga: hah, just talking to Trevinho :)
<zyga> yeah, we work together on this
<pitti> zyga: I'm currently sponsoring it to exp and I was wondering if that was agreed with you
<zyga> pitti: the updated version is in debian svn, I'm trying to get it moved to collab-maint
<zyga> pitti: yes though I did make changes since his version was pushed
<pitti> https://ftp-master.debian.org/dinstall.html
<zyga> Trevinho: ^^
<pitti> zyga, Trevinho ^
<pitti> so it should hit launchpad in maybe 4 hours, then someone can sync
<pitti> I'm quite sure that if we sync it tomorrow (Europe) morning, the world won't crumble either
<zyga> pitti: ok, but how do we get it into debian :)
<zyga> pitti: I cannot push it there
<pitti> pitti | zyga: I'm currently sponsoring it to exp [...]
<zyga> pitti: ah, ok, which version did you get?
<pitti> 1.4.0-1 from http://debomatic-amd64.debian.net/debomatic/experimental/pool/pyotherside_1.4.0-1/
<Trevinho> pitti: http://anonscm.debian.org/viewvc/python-modules/packages/pyotherside/trunk/ would be better
<zyga> pitti: and if possible, could you get the last one from dpmt svn (on it's way out of dpmt) please?
<Trevinho> if it's not too late
<zyga> pitti: there were some minor changes later:
<pitti> no, I just built, I didn't uplaod yet
<Trevinho> or... zyga in case prepare a -2
<pitti> someone please toss me a .dsc
<zyga> http://anonscm.debian.org/viewvc/python-modules/packages/pyotherside/trunk/debian/control?view=log
<pitti> (multiplexing/overloaded/late already, sorry0
<zyga> sorry, ok
<Trevinho> zyga: you handle that, right?
<zyga> Trevinho: I think, I never worked that way before
<pitti> bdmurray: bug 1420544> I'm afraid that's something the reporter or utlemming has to test themselves, as this requires being on a google cloud instance
<ubottu> bug 1420544 in systemd (Ubuntu Trusty) "Ubuntu instances on GCE should use NOOP scheduler" [Medium,In progress] https://launchpad.net/bugs/1420544
<utlemming> bdmurray, pitti: I'll confirm that today
<pitti> utlemming: do you need that for precise, too, BTW?
<pitti> utlemming: and before that can go to -updates, we need some plan what to do for vivid onwards; i. e. fix this properly in the driver (the SRUed rule is more like a hack really), or whatnot
<utlemming> pitti: eventually, yes
<pitti> Trevinho, zyga: I need some dinner; ping me once you have a dsc to be sponsored, then I can uplaod to Debin experimental
<zyga> pitti: ok
<pitti> Trevinho, zyga: ideally before https://ftp-master.debian.org/dinstall.html :)
<flexiondotorg> cyphermox, I see new "stuff" in the upload queue ð Thanks for your help!
<zyga> Trevinho: can you help me build that somewhere?
<zyga> Trevinho: I've copied all of that to pi.zygoon.pl/~zyga/
<zyga> Trevinho: can you test-build it using deb-o-matic
<Trevinho> yes
<cyphermox> flexiondotorg: oh, yes
<cyphermox> flexiondotorg: just make sure to update-maintainer in each of these branches, it's the only change I did
<Trevinho> zyga: the build in amhrf failed in deb-o-matic due to a segfault on testing, but maybe it's just there
<zyga> Trevinho: hmmm
<zyga> Trevinho: that's not good
<zyga> Trevinho: what was in the segvfault?
 * zyga tries on arm locally
<Trevinho> zyga: http://debomatic-armhf.debian.net/distribution#experimental/pyotherside/1.4.0-1/buildlog
<Trevinho> zyga: libEGL warning: DRI2: failed to open swrast (search paths /usr/lib/arm-linux-gnueabihf/dri:${ORIGIN}/dri:/usr/lib/dri)
<Trevinho> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
<zyga> yeah
<zyga> hmm
<Trevinho> not sure in experimental, but it was doing it fine in vivid
<Trevinho> last time I built that
<zyga> I think I saw that earlier
<Trevinho> zyga: building at http://debomatic-amd64.debian.net/distribution#experimental/pyotherside/1.4.0-1/buildlog
<zyga> Trevinho: did you change anything?
<Trevinho> zyga: no, but I had to resign the dsc with my key in order to get that built
<zyga> ah, right
<zyga> Trevinho: building locally, we'll see
<zyga> Trevinho: builds and tests on x86 are ok
<Trevinho> zyga: I've just made sure that you're getting an account on deb-o-matic btw
<pitti> slangasek: so if we still want to push for the switch in vivid, and assume that maas/juju land in time (or get a workaround), and assume that NFS lands soon: the actual flip would mostly be a seed change, right? or do you see anythign else there?
<zyga> Trevinho: thanks!
<pitti> slangasek: I guess I could stuff an updated ubuntu-meta into a PPA and test dist-upgrade from utopic and trusty with that, to ensure apt gets along with the removals etc.?
<slangasek> pitti: I don't recall whether we discussed the mechanics of the change.  Probably a seed change - maybe xnox has looked at it?
<zyga> pitti: we have a deb but it failed testing on deb-o-matic armhf (DRI related), still, its our best bet
<slangasek> pitti: sounds like a good test
<pitti> slangasek: no, I don't think we discussed it in depth; it should mostly just be a seed change indeed
<pitti> slangasek: ack, I'll do that then
<zyga> pitti: otherwise it builds and tests fine on sid-amd64
<zyga> pitti: dget http://pi.lan/~zyga/pyotherside_1.4.0-1.dsc
<pitti> curl: (6) Could not resolve host: pi.lan
<pitti> zyga: .lan sounds like something local? :-)
<zyga> d'oh
<zyga> pitti: pi.zygoon.pl
<zyga> :D
<zyga> yes
 * zyga needs to get that hisilicon board instead
<zyga> as all the arm boards around have just a gig of ram tops
<pitti> wow, it needs that much RAM to build?
<zyga> pitti: it's lintian clean, the upstream hash checks out and packaging changes are minimal
<pitti> yes, debdiff looks good
<zyga> pitti: no, it's not that, just having so little ram is annoying
<zyga> pitti: adt tests just finished, passing
<pitti> zyga: ah good, I just started them with teh sbuilt binaries two mins ago
<pitti> but I guess I can just as well let them finish, still 40 mins to go
<zyga> pitti: do you run adt on arm as well?
<pitti> done
<pitti> no, just amd64
<zyga> pitti: yeah, same here
<zyga> pitti: I should setup something running ubuntu as armhf is (especially in our team now) almost front and center
<pitti> zyga, Trevinho: uploaded
<zyga> pitti: thanks a lot!
<zyga> Trevinho: what else remains to sync it to ubuntu?
<zyga> next sync in 38 minutes
<pitti> well, that's the debian dinstall run; after that it takes a couple of hours to hit the Debian mirrors and get imported into LP
<pitti> zyga, Trevinho: if it's urgent, I could upload it as ~fakesync to vivid, and "properly" sync again tomorrow
<zyga> Trevinho: what do you think?
<Trevinho> pitti: well, not that urgent
<Trevinho> pitti: it depends if we can do it tomorrow as well... :)
<Trevinho> pitti: the thing is that vivid has already basically the same version minus a commit that fixes a crash, so pushing there is mostly a bug fix
<pitti> oh, indeed!
<pitti> Trevinho: no urgency at all then
<pitti> Trevinho: so there are no other ubuntu changes to keep, we can sync tomorrow?
<pitti> (bug fixes and syncs which only bring in bug fixes are possible any time)
<Trevinho> pitti: yes, no worries
<Trevinho> pitti: thanks
<zyga> thanks to both of you!
 * zyga EODs
<zyga> see you
<pitti> mvo: hm, it seems merely changing ubuntu-minimal to drop upstart and ureadahead and adding systemd-sysv doesn't convince apt enough to replace the packages
<xevious> Is the 14.04.2 release still on track for today?
<pitti> mvo: i. e. uninstall upstart+ureadahead and install systemd-sysv
<pitti> mvo: a Replaces/Provides: upstart would be clearly wrong, is there some other way we could do this?
<Unit193> bdmurray: Added hopefully enough info to give you some background.
<pitti> slangasek: ^ FYI (not that simple for updates); I guess we don't need to figure this out today, and for people who don't have ubuntu-minimal installed we need some fallback solution anyway; but it's still too early to more forcefully drop the upstart package IMHO
<slangasek> pitti: drop ureadahead> so has that still not been addressed?  I heard there was confusion about ureadahead being "obsolete", which it's not
<slangasek> AIUI systemd does not embed equivalent functionality
<pitti> slangasek: it used to up to 215, but as nobody maintained it it was dropped, yes
<slangasek> mm
<pitti> slangasek: we have a WI to investigate if it's still necessary/useful, and revive it to work with systemd too
<pitti> or bring back systemd-readahead
<pitti> (mostly for the phone)
<pitti> ATM it mostly gets uninstalled because it Depends: upstart, and only has upstart jobs
<pitti> actually, fixing ureadahead could already help enough, I'll look at that
<ogra_> yeah, please dont drop it ... it helps a lot on slow I/O devices
<ogra_> (gained me ~5sec of the phone boot to read all files at once)
<pitti> mterry: any chance you could have a look at the two python libs in bug 1407695? these have blocked keystone in -proposed for over a month
<ubottu> bug 1407695 in xmlsec1 (Ubuntu) "[MIR] python-saml2, python-repoze.who, xmlsec1" [High,New] https://launchpad.net/bugs/1407695
<pitti> sarnold: ^ that one also has xmlsec1 which is assigned to you; any chance you could have a look at it?
<pitti> ogra_: *nod*
<sarnold> pitti: hey, I think they're blocked on security team
<sarnold> pitti: I'm going to work on them soon, thanks for the ping
<mterry> pitti, will look at the non-security ones today or tomorrow
<pitti> mterry: cheers
<mterry> pitti, they fell off my radar after passing off the security one, thanks
<bdmurray> Unit193: how does the desktop manifest file show the the xubuntu-core package uses ubuntu-release-upgrader-core? I installed xubuntu-core and ubuntu-release-upgrader-core was not installed. I'd expect people installing from the mini iso to upgrade via apt-get after changing soruces.list
<Unit193> bdmurray: Aha, sorry.  I seem to have misunderstood.  For Lubuntu, I've seen this problem pop up a few times on IRC, mailing list, and I believe a bug though I don't know where.  Generally speaking Ubuntu support channels tell you not to upgrade that way as well.  So, did you install the xubunt-core metapackage, or the task?  From all tests done by our team, when you install the task (like we're
<Unit193> recommending, it works out far better than the meta), ubuntu-release-upgrader-core does end up getting pulled in anyway, and since that's what all the documentation tells you to use, users get an unexpected result.
<bdmurray> Unit193: How do you have people install the xubuntu-core task?
<Unit193> bdmurray: The mini.iso generally uses tasksel, which is one very common way to do it.  Another option of course is  apt-get install xubuntu-core^
<pitti> mvo, slangasek: ah nice, fixing ureadahead actually makes the dist-upgrade work
<pitti> replacing one package with another is apparenlty ok, replacing two with one another isn't :)
<pitti> s/one another/another/
<pitti> well "an other", too late for grammar
<Unit193> bdmurray: You still with me?
<bdmurray> Unit193: I'm installing from the mini.iso now
<Unit193> Aha.
<infinity> pitti: Isn't the solution to "people don't have ubuntu-minimal installed" to promote "init" to Essential, and have it flip the dep?
<infinity> Though, that would have gone better if we'd had it in trusty...
<infinity> Actually, apt always tries to install new Essential packages, I think, so that would still work.
<utlemming> bdmurray: SRU'ified bug #1420544...sorry about that
<ubottu> bug 1420544 in systemd (Ubuntu Trusty) "[SRU] Ubuntu instances on GCE should use NOOP scheduler" [Medium,In progress] https://launchpad.net/bugs/1420544
<flexiondotorg> cyphermox, Ping?
<cyphermox> flexiondotorg: what's up?
<flexiondotorg> cyphermox, Was wondering when we can start killing some kittens?
<flexiondotorg> cyphermox, I mean, try some builds ð
<cyphermox> flexiondotorg: I think that's up to infinity at this point, whether he reverted the ubuntu-cdimage changes and whether he can spare a minute to poke the right buttons, but I know he's busy with Trusty right now
<infinity> cyphermox: I didn't revert anything, but I'm in the middle of publishing 14.04.2 right now, so I'd appreciate others not mucking around on cdimage.
<cyphermox> infinity: totally understand
<flexiondotorg> cyphermox, OK. I seen that Trusty .2 has dominated peoples attention. Fair enough ð
<cyphermox> fwiw, *I* have no access to touch any of this
<tyhicks> Laney: fyi - I've attached a dbus debdiff of the backported-from-dbus-upstream apparmor patches to https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1362469/comments/9
<ubottu> Launchpad bug 1362469 in dbus (Ubuntu) "AppArmor unrequested reply protection generates unallowable denials" [Medium,Confirmed]
#ubuntu-devel 2015-02-20
<pitti> Good morning
<Unit193> Howdy.
<pitti> infinity: hm, maybe; I was hoping we could avoid requiring an init system in every chroot, but if that' an actual issue we may still go that way
<pitti> infinity: but wouldn't that mean that we need to promote systemd and systemd-sysv to essential too?
<pitti> then we could just as well do that for systemd-sysv and keep skipping "init"
<pitti> we don't really need "init" as we don't want to support multiple init systems at the same time
<pitti> speaking of which, something utterly broke systemd boot yesterday
<pitti> Laney: ^ I now get this as well
<pitti> so yay reproducability
<infinity> pitti: essential isn't a closed set.
<infinity> pitti: If it was, you'd be in a world of pain with libraries.
<pitti> oh, right
<pitti> so we might just need to bump some package priorities
<infinity> pitti: The point of 'init' being essential in Debian while the init systems aren't is to make sure you have one, but not require any specific one.  We may as well follow suit to keep the delta low in spirit, even if our "init" only has one dep.
<infinity> pitti: And upstart has been transitively Essential for ages anyway.
<pitti> so that would pull it in again in chroots
<infinity> pitti: We're not really changing the status quo here.
<pitti> right, it would just have been a slight improvement
<infinity> pitti: "again"?  You have magic chroots without init?  I don't.
<infinity> Oh, wait, maybe that was fixed in vivid and my chroots are dirty.
<infinity> Oh, or even as far back as trusty?
<pitti> no, my schroots do have /sbin/init -> upstart
<infinity> Clearly, I'm behind the times.
<infinity> pitti: But they don't have to.
<pitti> no, I can purge upstart just fine
<pitti> infinity: I created them before we juggled the sysvinit bits
<infinity> So, that's really just a failure on mk-sbuild's fault for creating chroots that are too fat. :P
<infinity> Oh, or a failure on my/your part for copying old chroots to new series'...
<infinity> At least I'm not entirely insane, upstart was transitively Essential in precise.
<infinity> pitti: So, okay.  Hrm.  I think it's not an awful goal to want a chroot without init if we don't actually need it.  But I'm then back to the drawing board on how you force an upgrade. :P
<infinity> pitti: And if Debian's okay with this init->initsystem Essential bit, I don't suppose it hurts terribly to follow suit.
<pitti> infinity: yes, it's nothing I'd spend an undue amount of time on; as you say, it's not a regression
<infinity> pitti: We could drop it after 16.04, perhaps.
<pitti> right
<infinity> pitti: Well, it's a regression from trusty, where upstart is removable.
<infinity> pitti: But also, I doubt many people care.
<infinity> pitti: Anyhow, first step is to see if apt will give you the right sort of love.  Rebuild 'init' with Essential: yes, and swap the dep from upstart to systemd-sysv, toss it in a local repo, and see what damage it inflicts.
<pitti> infinity: right; yesterday I just  tried with swapping the seeds around, which fortunately already DTRT (assuming that ureadahead gets fixed, which I'm working on)
<pitti> upgrading utopic to vivid plus https://launchpad.net/~pitti/+archive/ubuntu/systemd works
<infinity> pitti: Assuming we don't obtusely drop any of Debian's sysvinit compat, this also gives downstreams like Mint a simple "change one package" approach to swapping init systems, if they so feel the urge.
<pitti> infinity: yeah, or ubuntu touch :)
<infinity> pitti: Sure, swapping seeds works if you have minimal installed. :)
<pitti> infinity: it doesn't work with current vivid's ureadahead, so this was still an useful exercise
<infinity> pitti: So, yeah, I'd try the local Essential init and upgrading a non-minimal (err, very minimal?) chroot and see if apt does the correct magic.
<infinity> I'm pretty sure it does, though.
<pitti> yep, I'll try that too
<infinity> I think that's how I ended up with 'init' in some chroots in the first place, before we un-essentialled it. :P
<pitti> infinity: yes, my chroots don't have ubuntu-minimal installed
<infinity> pitti: And once we're sure V->V and U->V work, the next is T->V, and maintaining that upgrade path all the way to 16.04.  Whee.
<infinity> pitti: By which time, I assume someone will have released a better init system, and 16.04 will be using the no-longer-cool systemd.
<pitti> infinity: yay, congrats to 14.04.2, just saw the announcement
<pitti> infinity: openrc, clearly
<infinity> pitti: I have high hopes for uselessd, if they have enough motivation and time to live up to their mission statement.
<infinity> pitti: So, less about "new and better" and more about "a fork that doesn't annoy me as much".
 * pitti off IRC to some laptop boot testing
<dholbach> good morning
<didrocks> ricmm: rsalveti: hey, mind updating us once you are awake on the bluez5 situation?
<jamespage> Laney: can I get your opinion on https://bugs.launchpad.net/precise-backports/+bug/1422417 please?  its not going to conform with the typical backports process.
<ubottu> Launchpad bug 1422417 in Precise Backports "ceph radosgw needs mod-proxy-fcgi for apache 2.2" [Undecided,New]
<geser> pitti: Hi, re my boot problem with systemd as default: do you have an idea why the initram complains with "/init: line 307: chroot: not found" (also for line 325) before the kernel panic?
<pitti> geser: hm, that does sound relevant indeed; it might call chroot to resolve symlinks or so; sorry, firefighting right now, could you please add that info to the bug report?
<ogra_> why would there be a chroot call in the /init script
<pitti> well, obviously geser's has one
<ogra_> oh, yeah, i see it
<ogra_> checktarget="$(chroot ${rootmnt} readlink ${checktarget})"
<ogra_> geser, fyi /usr/share/initramfs-tools/init is that script :)
<Laney> jamespage: possibly - is there a sane upgrade path to newer releases?
<jamespage> Laney: good point - lemme take a think at that
<jamespage> Laney: for 14.04 the separate package would be superceeded by the module provided in apache2-bin
<jamespage> Laney: so we would need an associated SRU fix into 14.04 to deal with upgrades
<Laney> jamespage: as long as the packaging makes that happen cleanly
<Laney> I think it's plausible
<Laney> I'd like ScottK's thoughts
<jamespage> Laney: ack - we'd make that part of the testing plan
<ricmm> greyback: what was the reason to have qtmir acquire wakelocks? I know I proposed it, but now I forgot :)
<ricmm> didrocks: hey, the update is that we still dont have it fully woking on the touch kernels, sadly
<ricmm> working real hard on it
<greyback> ricmm: need to keep the wakelock until the app was SIGSTOPPed, so it could clean up. Sometimes cpu clocked down before app had cleaned up
<didrocks> ricmm: I hope we'll get a FFe for it, keep us posted
<ricmm> greyback: got it, so unrelated to music-app's lifecycle
<ricmm> salveti's bug confused me, as that logic is handled by media-hub
<greyback> ricmm: it might be as music app lifecycle excepted, the wakelock is always held
<ricmm> ah right of course
<ricmm> because the ->suspend() never goes
<greyback> yeah
<ricmm> greyback: should probably move the logic to still have the suspend() be called and the QTimer fired
<ricmm> and then check there for the lifecycle exception -> no signal/no sigstop
<geser> ogra_: do you know by chance if chroot is a build-in or a real binary in the initramfs?
<ogra_> geser, i guess it is busybox ... but i think the erorr is that chroot doesnt find one of the variable contents in that line
<ogra_> how does your init= on the kernle cmdline look like ?
<geser> ogra_: I've installed systemd-sysv (making systemd the default in my vivid VMware VM) and without a init= it doesn't boot at all (kernel panic with attempt to kill init), but it boots with init=/lib/systemd/systemd
<geser> ogra_: see bug #1421117
<ubottu> bug 1421117 in systemd (Ubuntu) "fails to boot with "Attempted to kill init" in VMWare, absolute /sbin/init symlink does not work" [Undecided,Incomplete] https://launchpad.net/bugs/1421117
<ogra_> well, that command tries to call "readlink /lib/systemd/systemd" inside the mounted rootfs
<ogra_> i assume it is either unhappy that /lib/systemd/systemd isnt a link or your rootfs isnt mounted at all at this point
<ogra_> both conditions should be catched by the above "if" line though ... which is weird
<geser> ogra_: I booted earlier today with break=bottom and tried "chroot /root readlink /sbin/init" which returned /lib/systemd/systemd
<ogra_> funny
<pitti> geser: ah, that chroot is for "Work around absolute symlinks"
<pitti> $ zcat /initrd.img |cpio -tv | grep chroot
<pitti> -rwxr-xr-x 141 root     root            0 Oct 27 09:40 sbin/chroot
<pitti> geser: does that exist for you too? (it should be a hardlink to busybox)
<geser> pitti: nope, the only output I get is "105117 blocks"
<pitti> a-ha!
<ogra_> heh, how did that get there
<geser> pitti: I just did a test with "break=init" and checked the output from env: init=/bin/sh doesn't look what I'd expect
<pitti> ogra_: you mean how did it not get in there?
<pitti> ogra_: "it" == /sbin/chroot; or do you mena something else?
<ogra_> oh, i thought it was supposed to be busybox's by default
<pitti> ogra_: it is, it's a hardlink to /bin/busybox
<pitti> or at least supposed to
<ogra_> /usr/share/initramfs-tools/hooks/busybox
<pitti> look at the link count (141)
<pitti> geser: do you have BUSYBOX=y in /etc/initramfs-tools/initramfs.conf? and busybox-initramfs installed?
<ogra_> i see it removing the klibc one but not create a link to the busybox binary
<pitti> ogra_: yeah, but it seems to work for everyone else
<ogra_> nor does it copy_exec the one from the filesystem
<geser> pitti: yes to both (BUSYBOX=Y and installed)
<geser> /usr/lib/initramfs-tools/bin/busybox lists chroot in its functions and according to that hook a real chroot binary should get removed (if I read it right)
<ogra_> geser, right, it removes the klibc one
<ogra_> but it doesnt create a /bin/chroot link to busybox
<ogra_> which i aways thought is required to make use of a busybox module
* Laney changed the topic of #ubuntu-devel to: Archive: open, feature freeze | 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:
<geser> I can use chroot in the busybox shell (break=bottom or break=init)
<cjwatson> y
<ogra_> (but i'm probably wrong)
<cjwatson> oops, wrong window
<ogra_> geser, right, and pitti obviously has a sbin/chroot above
<ogra_> so the link must come from somewhere else
<geser> the if check in that hook should fail for pitti otherwise there shouldn't be a chroot binary
<pitti> geser: right, but in the busybox shell chroot probably counts as a builtin
<pitti> check with "type"
<pitti> and not /sbin/chroot, as that doesn't exist for you
<ogra_> pitti, but where does sbin/chroot in your unpacked initrd come from then ?
<pitti> I don't know
<ogra_> ubuntu@localhost:~$ grep -r chroot /usr/share/initramfs-tools/*
<ogra_> /usr/share/initramfs-tools/hooks/busybox:	rm -f ${DESTDIR}/bin/chroot
<ogra_> /usr/share/initramfs-tools/init:			checktarget="$(chroot ${rootmnt} readlink ${checktarget})"
<pitti> I have it on my laptop and my VMs, and lots of other folks are booting with systemd-sysv
<pitti> so I'm certanly not the only one
<ogra_> there is nothing that puts it in place
<pitti> so if explicitly adding it to /usr/share/initramfs-tools/hooks/busybox helps, then let's do that
<pitti> it certainly sounds plausible to explicitly link it
<pitti> geser: to double-check, could you add that to /usr/share/initramfs-tools/hooks/busybox, then sudo update-initramfs -u, and check that it works then?
<pitti>         ln -s busybox ${DESTDIR}/bin/busybox
<pitti> err
<pitti>         ln -s busybox ${DESTDIR}/bin/chroot
<pitti> # ... and we need readlink to support /sbin/init to be a symlink LP: #1351295
<ubottu> Launchpad bug 1351295 in initramfs-tools (Ubuntu) "Boot fails if /sbin/init (or init= arg) is an absolute symlink" [Undecided,Fix released] https://launchpad.net/bugs/1351295
<pitti> that indicates that we had to do that for another shell command for this
<geser> with the ln call it works
<pitti> geser: cool, thanks for testing
<pitti> geser: I'll get that uploaded then
<ogra_> pitti, well, i'm still curious where it comes from for people that have it
<pitti> yeah
<ogra_> we might clash with something if we just try to link it
<pitti> I also have busybox-static which also has an initramfs-tools hook
<pitti> but that's in ubuntu-standard
<ogra_> well, do vmware images use -standard or just -minimal ?
<geser> I've neither ubuntu-minimal nor ubuntu-standard installed if it matters
<pitti> ogra_: ah, purging that indeed drops /sbin/chroot from initramfs
<pitti> mystery solved
<ogra_> :D
<geser> pitti: I hope I didn't distract you from your firefighting too much
<pitti> geser: that's ok; simple bug for a change :)
 * ogra_ wonders if we could even call it a bug :P
<ogra_> ubuntu without ubuntu-minimal isnt really ubuntu IMHO :)
<pitti> ogra_: that was without ubuntu-standard
<ogra_> ah
<ogra_> well, geser said he has neither installed
<geser> ogra_: but IYHO only missing ubuntu-minimal isn't really an Ubuntu anymore, you didn't say anything about a missing ubuntu-standard :)
<ogra_> well, standard is comfort :) -minimal is ... well. the minimal set of packages making up an ubuntu system :)
<geser> hmm, perhaps I should add an ubuntu-minimal depending on systemd-sysv instead of upstart into my PPA :)
<ogra_> oh, systemd-sysv conflicts ?
<geser> yes, indirectly as systemd-sysv conflicts upstart which is a dependency of ubuntu-minimal
<ogra_> right, well, then not having it installed is indeed right in this case :)
<LocutusOfBorg1> hi folks
<Riddell> mhall119: I want to use â¬66 for pizzas for the plasma sprint so we can continue to work effectively with them
<dholbach> Riddell, the process is still the same one you used before: http://community.ubuntu.com/help-information/funding/
<rbasak> chiluk: looking at bug 1420647
<ubottu> bug 1420647 in ceph (Ubuntu) "Please apply nofile limit fix of ceph-osd to trusty, utopic" [Medium,Confirmed] https://launchpad.net/bugs/1420647
<rbasak> chiluk: is this fixed in Vivid please?
<Riddell> dholbach: I've been told I need to pre-apply now
<dholbach> right
<dholbach> that's what the vast majority of requests did already, ie "we're going to do X at Y and need Z"
<dholbach> using the same request form
<dholbach> just some time in advance, rather than afterwards
<dholbach> Mirv, thanks a lot for fixing the libcitygml ftbfs
<Mirv> dholbach: eh yeah I didn't know what I got into though, since it's kind of still continuing ;) (OSG 3.2.1 migration)
<Mirv> but progress anyway, helping is a pleasure
<cyphermox> good morning!
<xnox> sil2100: are you about?
<flexiondotorg> cyphermox, Morning.
<sil2100> xnox: hey, what's up?
<xnox> sil2100: did you see email from pitti a while back?
<sil2100> xnox: uh, I might have missed it by accident, what was it about?
<pitti> the train not doing proper upload verification?
<xnox> sil2100: citrain modifications that developer membership board wants to get implemented.
<xnox> pitti: yeah, that.
<sil2100> xnox, pitti: trying to find it in my e-mail, but so far I don't see it, depending how long ago that was
<pitti> Subject: CI train upload privilege escalation [was: Upload Permissions]
<pitti> Date: Mon, 16 Feb 2015 08:46:10 +0100
<flexiondotorg> cyphermox, Can we try a build?
<cyphermox> flexiondotorg: could you ping #ubuntu-release for this? since I don't have access, all I can do is copy your request there :)
<sil2100> pitti: thanks, looking
<sil2100> pitti: hm, filtering returns no results, where did you sent the e-mail to?
<pitti> lukasz.zemczak@canonical.com
<pitti> sil2100: I can bounce it someplace else if you want?
<pitti> or just again to the same address?
<sil2100> pitti: if you could send it to lukasz.zemczak@ubuntu.com
<sil2100> Maybe this time I'll get it
<sil2100> hm, maybe it's filtered out somewhere
<pitti> bounced
<pitti> sil2100: got it now?
<ScottK> Laney: Commented in the bug.
<pitti> sil2100: mx.canonical.com accepted it, anyway
<pitti> sil2100: but then again, teh @c.c worked as well a few days ago..
<flexiondotorg> cyphermox, Who could help with testing a build?
<cyphermox> flexiondotorg: can't you?
<cyphermox> or do you mean with starting the build?
<cyphermox> if so, just wait for someone in the release team to be up and kick it off :)
<flexiondotorg> cyphermox, OK.
<sil2100> pitti: hm, still nothing ;/
<pitti> sil2100: spam filter?
<sil2100> pitti: yeah, found it in spam ;)
<sil2100> Thanks! Let me read up
<chiluk> rbasak it is fixed in vivid
<chiluk> rbasak that's why I only submitted debdiffs for trusty and utopic
<rbasak> chiluk: thanks. Just need to wait on the current ceph SRU to go through first then I guess.
<chiluk> yeah..
<chiluk> rbasak I was thinking we might want to push it through ceph stable
<chiluk> instead and get it pulled in that way.
<rbasak> chiluk: it's fine either way, thought I think the SRU team should be made aware of the conffile prompt issue in both cases.
<rbasak> I don't see any particular reason to prefer one way over the other - since it's fixed in Vivid, and Ubuntu is probably the only upstart-using Ceph distribution anyway?
<rbasak> jamespage: ^^ ceph upstart ulimit fix for Trusty and Utopic. Through a distro patch in an SRU, or through Ceph stable. Any preference? I don't suppose it really matters.
<jamespage> rbasak, not fussed either way - but I think there is a minor point release in proposed still so this may block things a bit
<jamespage> rbasak, I need to get that flushed through
<rbasak> jamespage: ack
<rainbowtux> Hi all, is there somewhere a good tutorial for creating .deb packages? That seems unnecessarily hard :/
<mdeslaur> rainbowtux: start here: http://packaging.ubuntu.com/html/
<caribou> Does the PlusOne maintenance team still exist ?
<caribou> I'm looking at the FTBS for deja-dup : it builds find locally but fails on the builder
<caribou> seems that it doesn't like the message saying that appdata-validate is deprecated
<DaGoaty> I'm making a custom distro based on Ubuntu with an extra repo added to the disk containing my additional packages. In 14.04.1 I replaced the ubuntu-archive-keyring.gpg file in the squashfs with one which had my public gpg key added. This no longer works with the 14.04.2 disk. Is there a 'proper' way to include additional public gpg keys?
<DaGoaty> I may have found my problem. I replaced the /usr/share/keyrings/ubuntu-archive-keyring.gpg but not /etc/apt/trusted.gpg
<tarpman> DaGoaty: instead of modifying existing files, consider shipping an additional keyring in /etc/apt/trusted.gpg.d
<DaGoaty> inside the squashfs?
<tarpman> wherever you're currently making your changes
<DaGoaty> okay, thanks
<Noskcaj> Can someone please upload a no-change rebuild of nant? It's needed for nunit 2.6.3 to migrate
<cjwatson> Noskcaj: monogame too, right?
<cjwatson> (For a different reason, but still)
<cjwatson> Noskcaj: nant done
<cjwatson> Noskcaj: ah, monogame is harder, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765120
<ubottu> Debian bug 765120 in src:monogame "monogame: support monodevelop 5" [Serious,Open]
<cjwatson> and https://bugs.launchpad.net/ubuntu/+source/monogame/+bug/1400216 ... will process that
<ubottu> Launchpad bug 1400216 in monogame (Ubuntu) "Remove from archive" [Undecided,New]
<cjwatson> Noskcaj: OK, hopefully that'll migrate in a publisher run or two now
<infinity> rbasak: percona-galera has that same "Breaks/Replaces where we mean Conflicts/Replaces" thing going on.
<infinity> rbasak: And so does xtradb.  Whee.
<rbasak> infinity: yeah. When they're all in the archive, then I can file a bug with tasks against all of them
<infinity> rbasak: They're all in, I held my nose and accepted after the licenses and general other packaging checked out sane enough.
<rbasak> Oooh, thanks!
<infinity> rbasak: But wherever this unversioned Breaks/Replaces thing started in MySQL packaging land, I do hope the people responsible are being educated.
<rbasak> I will do so.
<rbasak> Everyone is quite happy to fix things when pointed out.
<rbasak> It's hard to coordinate and track them though. Now that they're all in Ubuntu, Launchpad should help with it.
<infinity> rbasak: Breaks/Replaces should always be versioned, and always used for replacing files.  Conflicts/Replaces is the construct for replacing whole packages.
<rbasak> Every issue can just have a bug, and we can track their progress against every package.
<rbasak> Understood.
<infinity> I do feel like dpkg could do with a solid README on this.. Or a pointer to where Policy attempts to define it, and maybe a cleanup there.
#ubuntu-devel 2015-02-21
<lamont> I seem to have lost my window manager with a recent vivid upgrade... is this expected?
<darkxst> lamont, you using nvidia blob?
<lamont> darkxst: yes
<lamont> nvidia-{313,319,331,340}-updates are installed
<lamont> darkxst: is it worth testing it without nvidia-updates?
<darkxst> lamont, something killed mine today also
<darkxst> I upgraded to nvidia-346 from xorg-edgers and it worked again
 * lamont gives it a stab
<darkxst> though with no recent kernel updates seems a bit odd, something else is probably going on
 * lamont watches the download crawl
<lamont> darkxst: 346 is worse (from vivid)
<darkxst> lamont, working perfectly here, but I am on gnome-shell
<lamont> downgrading compiz doesn't fix it either, ditto nautilus+compiz
 * lamont sleeps
<aeoril> darkxst I am no longer working on the bug you have been helping me with - it is just too hard for my first bug.  You indicated there was another good "beginner bug" to me - is that still open?  I would be glad to work on it since you suggested it and you have helped me so much.  Thanks.
<aeoril> sarnold thank you as well for helping me on my first bug.  Too bad I could not figure it out.
<darkxst> aeoril, ok, maybe you could look at bug 1422113
<ubottu> bug 1422113 in ubiquity (Ubuntu Vivid) "Missing complete icon" [Medium,Triaged] https://launchpad.net/bugs/1422113
<darkxst> and bug 1422176 is also similar
<ubottu> bug 1422176 in Ubuntu GNOME "Missing icon for new bug report" [Medium,Triaged] https://launchpad.net/bugs/1422176
<aeoril> darkxst ok, will do - funny, I just got back and hopped on like 5 minutes ago!  Been gone all day!
 * darkxst just woke up
<aeoril> darkxst do you think anyone will pick up on my bug I tried to work on and triage it and fix it?
<aeoril> darkxst did you see I contacted chpe and he said he thought it was something in Ubuntu, not vte or gnome-terminal?
<aeoril> darkxst good morning! :)
<darkxst> aeoril, I did see that
<aeoril> darkxst do you have any input on that?  It seemed to me to really be pointing to vte3 or gnome-terminal, especially as I looked into the code
<darkxst> its possible chpe includes, running old versions of code as Ubuntu problem
<aeoril> darkxst I tried to explain to him that I was trying to find the fix to backport, but he seemed really busy and probably did not really have time to read my e-mails thoroughly - I bet he stays very busy ...
<aeoril> darkxst in other words, your presumption seems very plausible in light of our e-mail interaction
<aeoril> darkxst 1422113 looks at first blush like a one line change - probably just change a pathname somewhere
<darkxst> aeoril, yes, you need to rename the icon
<darkxst> I would also suggest you check there are no other affected icons in the package
<aeoril> darkxst yes, in the xml file
<aeoril> ok, I could do that - is there something I need to do "officially" to get started on this?  Or just start fixing it and when I get it working, let you know?
<darkxst> aeoril, make a bzr branch, fix it, then link to bug
<aeoril> darkxst ok, will do - I guess ubiquity is just the standard installer for Ubuntu?
<darkxst> yes, and ubuntu is upstream for ubiquity
<aeoril> oh, I guess that makes it easier ...
<aeoril> (thanks :)
<darkxst> aeoril, lp:ubiquity
<aeoril> darkxst ok, cool - thanks :)
<aeoril> darkxst I guess I should do this with sbuild?
<aeoril> darkxst bbl - gotta run to the store
<nickSwe> I am running Ubuntu 14.10 on a laptop with a external HDMI monitor running on 1080 resolution. On the login screen on initial boot up the login screen is scaled incorrectly and I see some graphic issues like strange lines on the side. It appears it is scaling the login screen to whatever my laptop resolution is set to. How can I change this so that it scales properly on the external monitor?
#ubuntu-devel 2015-02-22
<mitya57> pitti, you can kill vivid-adt-lintian4python as the package has been removed from vivid
#ubuntu-devel 2016-02-22
<slangasek> pitti: morning! looks like autopkgtest runners are stalled on amd64,i386,ppc64el; the juju node seems to show some sort of image mastering job running for the past couple of hours; is this expected maintenance?
<cpaelzer> good morning
 * Son_Goku sighs
<Son_Goku> I was really hoping that my patches to ondrej for php7.0 would have been merged in by now
<Mirv> @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: Mirv, pitti
<pitti> Good morning
<pitti> slangasek: php-* migrated, so I suppose this got sorted out with my infra cleanups yesterday evening
<pitti> slangasek: runners stalled> yeah, I got tons of worker failures over the weekend, apparently some neworking cloud trouble again
<pitti> slangasek: but all good now
<cpaelzer> pitti: I didn't realise that was the difference between autopkgtest and auto-package-testing - thanks for fixing the tagging in the bug
<pitti> cpaelzer: no worries, that's a bit subtle indeed :)
<dholbach> good morning
<slangasek> pitti: right, lots of things being rebooted for the security update, wonder if these systems should recover more automatically
<pitti> slangasek: well, apparently they did
<slangasek> ah, ok
<pitti> slangasek: I didn't do anything this morning
<slangasek> :)
<pitti> well, I'm reviewing failures on excuses.html, but no manual infra work
<pitti> slangasek: every six hours there is a cronjob which deletes orphaned instances and restarts all workers
<pitti> slangasek: that usually cleans up after networking or other scalingstack issues which happen and get fixed within a few hours
<slangasek> pitti: as far as php-* migrating, it still looks buggy to me that britney triggered tests against the -proposed version and then this didn't get dispatched... I think I wound up manually retriggering those tests I mentioned
<pitti> slangasek: ah, that's only a display bug -- britney does not trigger a particular version of a test
<slangasek> hmm, ok
<pitti> slangasek: it just says "run tests for package foo against the proposed version of bar"
<pitti> i. e. the trigger is versioned, but not the test
<pitti> and once the test actually ran, britney shows the "real" version
<pitti> but for the "in progress" it apparently currently shows the -proposed version, which is wrong more often than not
<pitti> I guess I should just not show it at all
 * pitti adds a WI
<pitti> ah well, that's not actually that easy UI wise, as all arches are grouped on one line as long as the version matches
<pitti> so maybe -- if there is a line with *only* "in progress", don't show a version
<doko> pitti, slangasek: dns problems on Sunday
<Mirv> @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: pitti
 * dholbach hugs Mirv 
<Mirv> pitti: hmm I guess you're not pilotting anymore since you did on Friday?
<pitti> @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:
 * Mirv hugs dholbach 
<pitti> Mirv: indeed, thanks
<doko> LocutusOfBorg, is the powerpc ftbfs in insighttoolkit4 fixed in your last upload?
<LocutusOfBorg> doko, I don't think so
<LocutusOfBorg> specially because seems more a compiler ICE
<doko> and the i386 test failures?
<LocutusOfBorg> should be
<infinity> That's not an ICE.
<infinity> But it probably means some large function needs splitting.
<LocutusOfBorg> I don't remember the reason, I'm trying to get the package migrate, and i386 is the blocker AFAICS
<doko> LocutusOfBorg, any reason why you build with 8 cpu's in parallel on amd64?
<LocutusOfBorg> you disabled the parallel build on amd64, and the build was taking something like a week. I did a parallel=2 and it worked, I did a parallel=4 and it worked, today I did a parallel=8. I'm not sure why you disabled it
<infinity> LocutusOfBorg: Don't set an explicit parallel= unless you're trying to set it *lower* than the buildds do.
<LocutusOfBorg> infinity, do the amd64 builds defaults to 8?
<infinity> (pretty please)
<doko> the build now takes 16h, the machine swapping ...
<infinity> LocutusOfBorg: They default to 4 these days, probably.
<LocutusOfBorg> ough, sorry, I thought it was 16
<infinity> LocutusOfBorg: (They default to $(nproc))
<LocutusOfBorg> for some reasons I had 16 in my mind, probably because DebOMatic is defaulting to that
<infinity> "Initiating build PACKAGEBUILD-9048365 with 4 jobs across 4 processor cores."
<LocutusOfBorg> bad monday
<LocutusOfBorg> I can cancel it if needed and reupload
<infinity> +  * Drop intrinsics patch: upstream.
<infinity> LocutusOfBorg: You also don't need to mention that in every upload. ;)
<LocutusOfBorg> that was a copy-paste error, I thought about removing, but probably forgot that :)
<pitti> cjwatson, infinity: did we disable autosyncs? (we should as we are in FF, but last Friday during my sponsoring shift it appeared as if they were still on)
<pitti> cyphermox: can you please have a look at bug 1548252? I'm fairly sure that this used to work at some point, as I often do that to investigate handling of cryptsetup devices during boot
<ubottu> bug 1548252 in ubiquity (Ubuntu) "creating LUKS partitions with manual partitioning fails to format" [Undecided,New] https://launchpad.net/bugs/1548252
<doko> pitti, they are disabled
<pitti> doko: thanks
<doko> The following packages have unmet dependencies:
<doko>  php-symfony-proxy-manager-bridge : Depends: php-proxy-manager (< 2~~) but 2.0.0-1ubuntu1 is to be installed
<doko> slangasek: according to the changelog you fixed the tests to work with php-proxy-manager 2
<cjwatson> pitti: I disabled them last thing Thu / early Fri morning, so it would've depended on your criteria :-)
<pitti> cjwatson: ack, thanks for confirming
<Kryczek> Hi! I do not know much about the Ubuntu project apart from being a very happy user of it since 5.04, and I apologize if this has been mentioned to you already several times, but as far as I understand the Ubuntu live media are made using live-build which is now sadly orphaned: https://packages.qa.debian.org/l/live-build.html . I offered my help of course but I have neither the knowledge nor the time
<Kryczek> to contribute much so I am wondering if by any chance the Ubuntu community with all its might could perhaps save this crucial software?
<LocutusOfBorg> fixed and reuploaded itk4
<doko> cjwatson, https://launchpadlibrarian.net/241356698/buildlog_ubuntu-xenial-amd64.haskell-bindings-sane_0.0.1-7build1_BUILDING.txt.gz (showed up in the ghc transition tracker). any idea about the ftbfs?
<doko> apw, any idea when the linux block-proposed issue gets removed?
<cjwatson> doko: yes, I know about that, it's because of IIRC libsane's pkg-config version having a ~ in it or some such, need to figure out how to work around that in cabal
<doko> LocutusOfBorg, please could you use the -v<last ubuntu version> option when merging packages?
<LocutusOfBorg> ok, I wasn't aware of this
<LocutusOfBorg> ok
<xnox> bdmurray, could you please subscribe foundations bugs to libica package for the MIR 1546987 ? it's an s390x specific thing.
<rbasak> doko: btw, I don't think we have any process of telling new uploaders how to do such things. People get upload rights but no instructions on dput, etc, and of course before direct uploading, sponsorees don't need to know.
 * rbasak bets that caribou doesn't know either
<rbasak> The wiki could do with a "Congratulations, so you're a new uploader!" page with instructions on dput, -v<last ubuntu version> for merges, etc, and get the DMB to point to that.
<Laney> Like https://wiki.ubuntu.com/MOTU/New ?
<ginggs> it is mentioned here: https://wiki.ubuntu.com/UbuntuDevelopment/Merging#Get_your_work_uploaded
<doko> xnox, bdmurray: done
<doko> rbasak, like Laney said
<rbasak> Ah, great!
<rbasak> Nobody pointed me to that page when I became an uploader/MOTU though. Maybe that's the only missing link then.
<xnox> doko, thanks.
<doko> rbasak, please could you address https://launchpad.net/bugs/1546957 ? now blocking another transition (or you might want to fight with Laney about the bug subscription ;)
<ubottu> Launchpad bug 1546957 in lua-lpeg (Ubuntu) "[MIR] lua-lpeg, needed by nmap" [High,Incomplete]
<caribou> rbasak: doko: I found out by reading your merge doc; I used it for clamav
<Laney> boring troll
<caribou> rbasak: oh, I didn't know about dput, I thought you meant dpkg-buildpackage
<rbasak> doko: tons of !server stuff depends on lua. So why should this be a server bug subscription? I accept the nmap rdep, but this seems pretty generic. I'll defer to jgrimm I think.
<rbasak> (why uses nmap with lua anyway?)
<rbasak> who
<doko> rbasak, fix it to rmove the dependency
<rbasak> doko: I'll add it to our queue to look at.
<flexiondotorg_> I have a package update I'd like beg gets sponsored.
<flexiondotorg_> Anyone able to help? - https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1548133
<ubottu> Launchpad bug 1548133 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 16.04.3 new release [debdiff and tarball attached]" [Undecided,New]
<pitti> doko: I'm looking at the tomcat7 â tomcat8 change on component-mismatches, unless you already did
<pitti> it seems some packages need to be updated for libservlet3.0-java â libservlet3.1-java
<doko> pitti, sure, please make sure to revert seb128's change for hsqld1.8
<pitti> doko: right, that's another step
<seb128> it's not "my changes", I only merged that package because nobody else was doing it
<pitti> seb128: yeah, it was entirely right at the time, that wasn't a blame
<seb128> good :-)
 * doko never blames
<pitti> Debian's dependency is also wrong
<pitti> Depends: libservlet2.5-java, ${misc:Depends}
<pitti> <pathelement location="/usr/share/java/servlet-api-3.1.jar"/>
 * pitti will file a b gu
<pitti> bug too
<pitti> l
<jamespage> please could an archive admin promote python-openvswitch to main; its source is already in main and its needed for neutron
<jamespage> looks like it popped into main for a bit and then when back to universe?
<pitti> jamespage: done
<jamespage> pitti, ta
<pitti> jamespage: just FYI, I'm tracking the tomcat7 â 8 changes on bug 1539903
<ubottu> bug 1539903 in libcommons-logging-java (Ubuntu) "tomcat-8 in main for upcoming 16.04 LTS" [Undecided,Fix committed] https://launchpad.net/bugs/1539903
<pitti> there might be some temporary hiccups, but I'm tracking component-mismatches etc.
<abeato_> pitti, hi, I have a patch for ntp (bug #1526264), who should be best to take a look?
<ubottu> bug 1526264 in Canonical System Image "ntpdate fails with invalid argument when device is set to a date in the future (delta > 2^16)" [High,Confirmed] https://launchpad.net/bugs/1526264
<pitti> abeato_: please subscribe ubuntu-sponsors
<abeato_> pitti, ok, and then should I send an e-mail to the list?
<doko> I'm planning to start an archive test-rebuild this week, maybe tomorrow, once the current linux/bind9/gcc-5 migrate. Is there anything which should be included? If yes, what?
<doko> pitti, jamespage, rbasak, Laney, seb128, smoser, apw: ^^^
<xnox> infinity, glibc 2.23? ^
<seb128> doko, nothing special on the desktop side
<Md> I am testing the 16.04 installer, but I have noticed that my custom partman recipe now creates an extended partition instead of a primary one. has something changed?
<xnox> Md, better ask on #ubuntu-installer. and/or highlight cyphermox. Loads of things have changed in 16.04 installer, as a lot of d-i components got upgraded.
<Md> I have not tested debian/unstable, but the same recipe works as expected with the debian/stable installer
<ben__> hi, could someone from the archive team please have a look at the binary removal request (bug #1542398)? the old armhf binary is blocking the new version from migrating to release for two weeks now
<ubottu> bug 1542398 in polymake (Ubuntu) "please remove armhf from old package" [Undecided,New] https://launchpad.net/bugs/1542398
<doko> rbasak, please subscribe to tomcat8 bug reports (like for tomcat7), so that pitti's uploads can build
<pitti> doko: nothing that needs squeezing in from my side
<seb128> doko, we might have a poppler soname change, better before or after?
<doko> seb128, well, upload today and start the transition today
<rbasak> doko: tomcat8> done. I'm not sure I understand why it would be a problem for pitti, but it needs doing anyway.
<seb128> doko, ok
<pitti> rbasak: it's just for completing the demotion of tomcat7 and promotion of tomcat8
<doko> rbasak, he already promoted; or else he would only see dep-waits
<pitti> stuff is building now
<rharper> I've a bug that's now fixed in xenial, but not fixed in trusty;  how do I add task entry for say Trusty ?  I see the Also affects project, distro/package and nominate; not sure which one of those (or something else) I'd use to indicate it's also broken in trusty (so I can propose an SRU)
<rbasak> rharper: nominate Trusty
<rharper> rbasak: thanks!
<doko> rbasak, fyi, https://launchpad.net/ubuntu/+source/nmap/7.01-2ubuntu1  but some features are disabled
<doko> pitti, does virtualbox need testing against proposed (kernel)?
<pitti> doko: you mean -7 regresses virtualbox and that holds back the proposed virtualbox?
<pitti> doko: that's a special case for the kernel team indeed, they want to test DKMS stuff against the proposed kernel always
<pitti> so we don't do apt pinning for the kernel
<pitti> doko: but it's clearly not a regression of that rebuild itself, so I'm fine with allowing that rebuild to unblock the transition
<pitti> it's a glaring red regression on http://people.canonical.com/~kernel/status/adt-matrix/xenial-linux-meta.html, so it should be on apw's radar
<apw> pitti, regressions on virtualbox and spl-linux are almost always not regressions, as we have the same version in the kernel and that errors, but i hint them on manual review
<marlinc> cking, you around?
<marlinc> Anyway, the default ZFS compression algorithm is lz4 not gzip-6
<cking> marlinc, ok, i'll correct that in the wiki
<sarnold> I thought the default was lzjb? and that folks -should- change it to lz4?
<cking> bah, I can't recall now, I need to double check that
<Son_Goku> wasnât it lzo for speed?
<pepee> sarnold, did I talk with you about this bug a few days ago?  https://bugs.launchpad.net/ubuntu/+source/linux-lts-wily/+bug/1545401
<ubottu> Launchpad bug 1545401 in linux-lts-wily (Ubuntu) ""kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/mm/memory.c:3146!"" [Undecided,New]
<sarnold> pepee: I think before you filed it, yes; I hadn't seen the report thuogh. nice.
<sarnold> pepee: jeeze, good thing your reproducer is a thuosand times easier than "just install mosix and migrate a process". sheesh.
<sarnold> pepee: interesting, looks like the rhat bug was filed via a vmware guest.. yours has vbox modules linked in; can you reproduce it with a kernel that doesn't have vbox loaded? (best if it -never- had vbox modules loaded..)
<marlinc> sarnold, The  current default compression algorthm is either lzjb or, if the lz4_compress feature is enabled, lz4.
<marlinc> lz4_compress is enabled by default :)
<marlinc> Thanks cking!
<cking> lz4 is by default, had to check that for sure
<marlinc> cking, is it possible for others to work on that document?
<pepee> sarnold, mine isn't a VM, though
<marlinc> sudo zpool create example raidz /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg
<cking> marlinc, it should be editable by anyone with wiki acess
<marlinc> That should be raidz3 :)
<sarnold> pepee: yeah; still, those modules are .. iffy.
<marlinc> '3 parity bits, allowing for 3 disk failures before losing data with performance like RAIDZ2 and RAIDZ. Example, create a 3 parity 6 VDEV pool:'
<doko> barry, did you omit the python-pip merge by intent?
<pepee> sarnold, I linked to the sources, I guess (wild guess...) that there is a problem with some API
 * cking fixes that too, thanks for spotting that marlinc
<sarnold> marlinc: ah! good. lz4 is a much better default. is that something speicific to zfsonlinux implementatio or is that common to all openzfs now?
<marlinc> I don't think I have that cking
<pepee> sarnold, true... I'd have to test later, I'm not using 4.2 anymore, too risky :(
<sarnold> pepee: heh, the source is what made me wonder -- why was your memory allocation going through a numa-aware code-path. seemed funny on a laptop. ;)
<marlinc> Not sure sarnold, I looked it up in the ZFS man pages on my Ubuntu install
<sarnold> marlinc: woo :)
<cking> bah, wiki timeouts
<pepee> sarnold, my laptop is loading numa stuff, not sure why... I think I installed some packages and that came as dependency
<marlinc> :)
<pepee> in fact, my laptop doesn't even support iommu and other things being loaded, heh
<barry> doko: yes, i think we can drop the ubuntu deltas.  i merged --user by default to the debian version and i believe the shebang should be correct now too.  i'll double check the proposed version and look at excuses
<marlinc> What should I do if I find something else cking?
<pepee> anyway, thanks sarnold, I'll do some testing later
<cking> marlinc, if you can't edit it, ping me, or email me colin.king@ubuntu.com
<sarnold> pepee: ha! click around on that a bit -- the _one_ caller checks to _ensure_ that the page is PROT_NONE before calling do_numa_page
<sarnold> pepee: .. but do_numa_page BUGs on that specific condition
<marlinc> Okay cking :p
<pepee> sarnold, the caller is follow_page_pte()?
<sarnold> pepee: handle_pte_fault()
<sarnold> apw: the kernel team's demotativation bug bot hasn't commented on 1545401 yet -- is it hooked up to look for bugs in the linux-lts-* packages too?
<pepee> sarnold, oh, I see... I think, you mean   3265  if (pte_protnone(entry))      3266  return do_numa_page(mm, vma, address, entry, pte, pmd);  ?
<pepee> shouldn't the dev that made the patch have also change the other functions/files?
<apw> sarnold, quite possibly not ... bjf ^
<apw> sarnold, i would hope they would get retargeted to linux as things need to be fixed in the primaries first in the main
<sarnold> apw: yeah, that'd make sense, but e.g. linux-lts-utopic is a bit strange, as linux in utopic is eol ..
<bjf> sarnold, apw, i haven't looked but no the bot most likely isn't looking at those
<sarnold> pepee: yeah, some time with git blame to figure out what happened to the code might help figure out if that's just missing a ! before the call or if this is going to be a huge change..
<pepee> sarnold, https://lists.ozlabs.org/pipermail/linuxppc-dev/2014-December/123285.html
<apw> sarnold, yep, that one is a strange one for sure, and that one filing direct does make sense, so that isn't confusing at all
<sarnold> pepee: heh, he's one of the few who I might have expected to understand this code :) haha
<pepee> sarnold, the earliest one I could find:  http://lkml.iu.edu/hypermail/linux/kernel/1411.1/05082.html   ,  patchset is  http://lkml.iu.edu/hypermail/linux/kernel/1411.1/05086.html
<pepee> sarnold, apw: what does invalid means?
<apw> pepee, invalid where?  in a bug it normally means that the bug is not applicable to a specific task (series/package combination)
<pepee> apw, ah, ok. I submitted bug # 1545401
<apw> bug: #154401
<ubottu> bug 154401 in xserver-xgl (Ubuntu) "after uninstalling xserver-xgl gnome keyboard layout question at login" [Medium,Won't fix] https://launchpad.net/bugs/154401
<apw> bug: #1545401
<ubottu> bug 1545401 in linux (Ubuntu Wily) ""kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/mm/memory.c:3146!"" [Undecided,Incomplete] https://launchpad.net/bugs/1545401
<apw> pepee, right in that one the bug is reported against linux-lts-wily in xenial, which makes no sense
<apw> pepee, so you are seeing me targetting it to trusty where that kernel exists and adding linux tasks as we
<pepee> ah, heh
<apw> pepee, have to fix it there first, the invalid ones are mostly non-existant combinations
<pepee> I hadn't noticed, sorry
<pepee> I had no idea this was a security bug
<ginggs> doko: dpkg: error processing archive /var/cache/apt/archives/libtesseract4_3.04.01-2_amd64.deb (--unpack):
<ginggs>  trying to overwrite '/usr/lib/libtesseract.so.3.0.4', which is also in package libtesseract3v5 3.04.00-5ubuntu1
<doko> Laney, ^^^
<Laney> Someone synced it
<Laney> and that person was doko
<doko> ahh, crap, we need the Breaks/Replaces ... will fix
<doko> ginggs, hmm, can you file a Debian issue? that should show up for unstable as well, it has the conflict, but misses the replaces?
<ginggs> doko: ok
<doko> and the somebody not merging was Laney
<ginggs> doko: looks like it is already filed, debian #815056
<ubottu> Debian bug 815056 in libtesseract4 "libtesseract4: fails to upgrade from libtesseract3" [Serious,Open] http://bugs.debian.org/815056
<doko> argh
<infinity> Uhh, why does a package named libtesseract4 contain libtesseract.so.3?
<infinity> Someone doesn't know how SONAMEs work.
<sarnold> pepee: I hit the 'security' flag because a series of user-space operations appeared to put the kernel in a state that it certainly didn't expect
<pepee> sarnold, ah
<pepee> you are right... I'm a bit slow
<pepee> sarnold, wondering if it's exploitable :P
<sarnold> pepee: my first guess is that it's not exploitable for privilege escalation but it may have other surprising effects
<pepee> I just noticed, http://lxr.free-electrons.com/ident?v=4.2;i=do_numa_page says do_numa_page() is referenced in its own definition and in the bugged line... what's the point of that function, then?
<pepee> bah, I wish I knew more about kernel dev'ing
<sarnold> the function is defined on the first (3133) and called on the second (3266)
<sarnold> because it's only called from one place it -could- have been written inline in the handle_pte_fault() function and avoid the function call, but that kind of programming leads to thousand-line functions that are impossible to think about :)
<pepee> ah, ok
<doko> barry, did you omit the python-pip merge by intent?
<barry> doko: did you see my previous response?
<barry> <barry> doko: yes, i think we can drop the ubuntu deltas.  i merged --user by
<barry>         default to the debian version and i believe the shebang should be
<barry>         correct now too.  i'll double check the proposed version and look at
<barry>         excuses  [12:12]
<barry>  
<barry> doko: the pkg looks good.  i don't know why python-virtualenv is holding it back.  a local adt-run passes and the a.u.c artifact is mysterious
<doko> hmm, didn't see the reply.
<barry> doko: anyway ^^
<doko> barry, it's because python-pip-whl is not installable
<barry> doko: seems to be here: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160222_195823@/log.gz
<doko> barry, python-virtualenv is not considered for migration, because the tox autopkg tests fail
<barry> doko: right, but i cannot reproduce that locally in adt-run with -proposed enabled
<doko> barry, well, ask pitti to hint it
<barry> pitti: ^^ any thoughts?
<doko> python-setuptools shows some regressions too, and afail python-pip has a breaks to the version in the release pocket
<pitti> barry: local adt-run> did you enable -proposed?
<pitti> ah, you did
<barry> pitti: i used a xenial-amd64 chroot w/-proposed enabled and verified the python-virtualenv and python-tox versions that got installed there.  passes beautifully for me
<pitti> barry: let me first re-run the test against all of -proposed, maybe there's some hidden dependencies there
<doko> barry, and setuptools triggers virtualenv failures
<barry> pitti: thanks
<mdeslaur> cyphermox: any plans on merging sudo?
<barry> doko: that looks like it's using the old virtualenv pkg, but that has no tests
<doko> plus pbgenomicconsensus and python-pex
<doko> barry, pitti: can you retry with -proposed enabled?
<pitti> doko: just did
<barry> as did i
<Noskcaj> Could someone please upload the newest youtube-dl to xenial? I've test built it, but this package needs to be treated almost like a rolling release for it to function properly (A number of it's releases are compatibility fixes)
<pitti> retry-autopkgtest-regressions | sed 's/run-autopkgtest/& --all-proposed/' | sh
<pitti> err, and a | grep python
<barry> pex may be intermittent.  /me retries
<pitti> doko, cjwatson, infinity, slangasek: FYI: I added a --all-proposed option to run-autopkgtest the other day that disables apt pinning
<cyphermox> mdeslaur: if it's rush, feel free to do it.
<cyphermox> I'm assuming you ask because of sudoedit?
<doko> pitti, am I allowed to use this as well?
<pitti> doko, cjwatson, infinity, slangasek: FYI: easier than cobbling together tons of --trigger options
<mdeslaur> cyphermox: yeah, and I'd like to backport the version we're going to ship in xenial into the stable releases after
<pitti> doko: sure; I thought you used run-autopkgtest/retry-autopkgtest-regressions yourself before we had the web-clicky stuff?
<mdeslaur> cyphermox: and I'd rather do it with 1.8.15
<cyphermox> mdeslaur: yeah, I understand
<barry> pitti, doko pex failures are reproducible locally
<doko> probably a missing build/test dependency,
<doko> pitti, is there consensus to ignore pbgenomicconsensus? ;)
<pitti> but it has *such* a funny package name!
<barry> doko: that's probable, since it shuts off pypi and it's a connection refused.  i need to update pex anyway
<pitti> doko: yep, the history is fairly red-heavy, I'll hint it
<cyphermox> pitti: up in the top 10 with datefudge and all.
<doko> barry, it would be nice to modify pip to print out what it wants to fetch for such cases ...
<barry> doko: at least desktop is down to just samba keeping py27
<barry> doko: indeed, i've wanted that for a long time.  next time it bugs me too much i'll give it a look
<pitti> cyphermox: libcatalyst-authentication-credential-authen-simple-perl absolutely belongs in that list too
<pitti> Package: how-to-trigger-buffer-overflows-in-dpkg-parser-codes
<pitti> doko: ah, it already has a hint, just needs a version bump
<barry> doko: server has nothing keeping python python2.7 on it so i guess it just needs to be deseeded
<barry> and i think smoser has a todo for that
<smoser> i'm open to someone else doing that.  i dont think it is seeded anywhere is it
<smoser> i have a TODO to blacklist it from the images
<smoser> https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-python3-only
<pitti> doko: hinted aplpy/s390x too while I'm at it
<barry> smoser: i grabbed today's daily and `apt-get purge python2.7 libpython2.7`.  it only purges those, nothing else
<barry> smoser: yes.  time to add that blacklist?
<pitti> barry: http://autopkgtest.ubuntu.com/running.shtml#pkg-tox doesn't look good, several Fs
<infinity> It shouldn't need blacklisting.
<smoser> so how'd they get there?
<smoser> we wanted blacklist to fail build
<infinity> If it's ending up on the images, we should figure out why, not hack around it.
<smoser> i agree with infinity, but i thought the intent was to make things fail
<barry> pitti: huh.
<barry> smoser, infinity that's what i thought too
<doko> barry, ahh, should be @builddeps@, not @
<infinity> smoser: There are lots of packages we don't want on images, we shouldn't force a failure every time one pops up.  python's not really special here. :P
<infinity> But definitely, if there's no clear reason it's showing up in all those tasks still, we might want to investigate.
<barry> doko: hmm, maybe so since it's running its own self tests
<doko> barry, fixing this, while you prepare a new upstream
<barry> doko: in tox, right?
<barry> not pex
<barry> or did you mean pex?
<doko> I thought pex
<barry> doko: oh, i was looking in the wrong place, just a sec
<barry> doko: hmm, i don't think pex should use builddeps
<barry> doko: textwrap comes from stdlib
<doko> barry, not even the execute.sh test?
<barry> doko: right, not even that.  it's entirely possible something's changed tho
<barry> doko: but i'll verify as i prep the new version
<infinity> smoser: FWIW, python2.7 isn't in the server livefs manifest anymore.
<infinity> barry: How did you install server?
<barry> infinity: grabbed xenial-server-amd64.iso from here: http://cdimage.ubuntu.com/ubuntu-server/daily/current/
<smoser> that is old.
<smoser> due to some failing tests.
<barry> infinity: installed in fresh vm, no downloads during install
<smoser> :-(
<smoser> fudge.
<smoser> the change that would have released it went into postfix today
<smoser>  https://bugs.launchpad.net/ubuntu/+source/postfix/+bug/1538198
<ubottu> Launchpad bug 1538198 in postfix (Ubuntu) "python in xenial cloud image" [High,Fix released]
<doko> smoser, why not installing an image, then trying to remove python2.7-minimal and libpython2.7-minimal?
<barry> smoser: ah, okay!  so maybe it'll be gone in the next successful image
<smoser> er... it says 20th, but lamont made it sound like today i thought.
<smoser> doko, ? i didnt come up with the idea to blacklist.
<smoser> i think it is fine to test other ways for sure.
<barry> smoser: it came up in the last uos session, but i don't remember who suggested it
<barry> smoser: just that you didn't have your finger on your nose :)
<infinity> smoser: Anyhow, please don't blacklist.  I'm on VAC today (see how well I'm doing), but if a plain install still pulls in python2, let's fix it tomorrow.
<smoser> deal
<barry> wfm
<infinity> python2.7 is still in the "server" task, so something likely needs a nudge, but let's do it rightish.
 * infinity goes back to ignoring IRC for a bit.
<doko> coreycb, python-ironicclient wants some MIRs
<coreycb> doko, thanks I'll take a look
<doko> coreycb, python-restructuredtext-lint and python-doc8
<coreycb> doko, ok I think we can drop those
<coreycb> I'll work on it
<pitti> ah, forgot one last tomcat7 dep apparently
<pitti> https://launchpad.net/ubuntu/+source/libcommons-dbcp-java/1.4-5ubuntu2, thanks doko
<smoser> i'm sure this is obvious to many of you
<smoser> what am i doing wrong here ; http://paste.ubuntu.com/15174005/
<smoser> or what am i suppsoed to do to have autoconf re-run
<doko> smoser, never use 'configure' as a target
<doko> you probably want a cdbs hook
<smoser> i read that from https://wiki.debian.org/Autoreconf
<doko> hmm, but that's in the autotools-dev section ...
<doko> cdbs should die
<sarnold> doko: also here https://wiki.debian.org/Autoreconf#debhelper_packages
<doko> sarnold, and above that is the cdbs section
<sarnold> doko: is your advice to not use 'configure' as a target specific to cdbs? or for all package types?
<smoser> ok. so used
<smoser>  +include /usr/share/cdbs/1/rules/autoreconf.mk
<doko> sarnold, it's used as a dependency on a file, and when it get's regenerated, the time stamp changes, and it's run again during the build or the install
<smoser> instead, and it got me back to why i went down that rathole.
<smoser> http://paste.ubuntu.com/15174062/
<sarnold> doko: it seems like a dangerous thing to do in general :) but there it is, in the wiki, twice :) hehe
<smoser> what is pulling CPPFLAGS of -Werror=date-time
<doko> sarnold, if you want to read a scary rules file, see ucommon
<sarnold> doko: wow, that looks like highly unstable spaghetti.. i'd certainly be afraid of making any changes to that package
<doko> smoser, export DEB_CFLAGS_MAINT_STRIP = -Wdate-time before including the dpkg-buildflags.mk
<doko> sarnold, yep, took me some time to find something to fix the build :-/
<doko> smoser, but the better option would be to use the system libltdl. but that maybe for another time ...
<slangasek> LocutusOfBorg: looking for the wrong name, I guess ;)
<smoser> doko, yeah, this is really just to test a  newer squid on trusty.  merge with debian is being done by rbasak.
<barry> doko, pitti new pex uploaded.  now we just have to wait for sync to xenial
<lamont> smoser: it got hung up in autopkgtest
<lamont> sadly
 * lamont is fighting with that still, 3.0.4-1 is the current "I think it works, adt doesn't" version
<infinity> Man, poor NoneType is always being called out for its lack of attributes.
<lamont> infinity: we should get it some attributes, yes?
<lamont> :*(
<lamont> mostly I'm just being sick today
<infinity> lamont: testlib and test-postfix just seem to be entirely full of sad.
<cjwatson> NoneType totally has attributes.  __class__, __repr__, ...
<sarnold> infinity: *cough* vacation *cough* :)
<lamont> tbf, I had nothing to do with them
<lamont> cjwatson: hah
<infinity> cjwatson: But never the attributes people want. ;)
<cjwatson> Picky
<infinity> sarnold: Oh, right.  That.
<infinity> lamont: FWIW, the quick hack (if this is the fault of the py2->py3 porting of tests) could be to just revert all changes to debian/tests/* and then add python to debian/tests/control deps.
<infinity> lamont: adt tests don't need dep closure with package deps.
<infinity> (Fixing the bugs would be nicer though...)
<cyphermox> pitti: have you seen https://bugs.launchpad.net/ubuntu/+source/upower/+bug/1548524 ?
<ubottu> Launchpad bug 1548524 in upower (Ubuntu) "/usr/lib/upower/upowerd:11:g_variant_is_trusted:g_variant_builder_add_value:g_variant_valist_new:g_variant_new_va:g_variant_new" [Undecided,New]
<juliank> cyphermox: Sounds similar to http://bugs.debian.org/815590
<ubottu> Debian bug 815590 in upower "upowerd: can be crashed easily with upower -d" [Grave,Open]
<cyphermox> indeed, I hadn't seen that one
<cyphermox> lemme add links
<juliank> It looks like something in the dbus-glib -> gdbus transition is messed up
<cyphermox> yup
<cyphermox> I'm familiar enough with dbus-glib, but not so much gdbus to tell what's wrong there
<cyphermox> I looked a bit, seems like maybe device is NULL, but I haven't dug in more to find out why
<juliank> It should be easily reproducible though, I just had to run upower -d about 2 to 3 times in a terminal.
<juliank> On my Debian side, systemd-coredump lost the coredump ...
<tjaalton> so how exactly does one create a git 'project' on the lp user account? simply pushing a branch fails with "project foo does not exist"
<cyphermox> juliank: yeah, I got it from running upower -d too
<tjaalton> ok, had to rename the project it seems.. 'linux' works, 'ubuntu-xenial' didn't
<tjaalton> and still wrong, think I got it now :)
#ubuntu-devel 2016-02-23
<lamont> is it bad that I did a dist-upgrade on wily and time stopped on my topbar?
 * lamont reboots for giggles
<pitti> juliank, cyphermox: seb128 pointed  out the upower bug to me yesterday, but I wasn't aware of that reproducer, thanks!
<pitti> cyphermox: I suppose bug 1547518 is just a duplicate of that
<ubottu> bug 1547518 in ubiquity (Ubuntu) "ubiquity crashed with dbus.exceptions.DBusException in call_blocking(): org.freedesktop.DBus.Error.InvalidArgs: No such interface '/org/freedesktop/UPower'" [Critical,Confirmed] https://launchpad.net/bugs/1547518
<dholbach> good morning
<doko> pitti, python3.5's libreoffice hint needs a version update
<pitti> done
<Mirv> is there someone to whom cookies, TLDs and rfc6265 ring a bell? something changed between Wed and Fri last week causing bug #1548686, and I'm wondering if it's Ubuntu or something on the Internet (but builders shouldn't have access to the network anyway so I guess nothing should normally change)
<ubottu> bug 1548686 in qtbase-opensource-src (Ubuntu) "7 cookiejar tests started failing" [Undecided,New] https://launchpad.net/bugs/1548686
<LocutusOfBorg> slangasek, probably :D
<Mirv> well I'm testing a wily build now. if it succeeds, something changed in xenial. if it fails too, something changed in the world.
<doko> sil2100, the last ubuntu-keyboard upload still depends on fonts-droid
<sil2100> eh, let me get the dev
<ginggs> pitti, xnox: what is the reason for keeping pybootchartgui around until *after* the LTS? LP: #1353587 It is one of the three packages remaining in Ubuntu that directly depend on python-support
<ubottu> Launchpad bug 1353587 in bootchart (Ubuntu) "superseded by systemd-bootchart, remove after LTS that has switched to systemd (16.10 the earliest)" [Low,Triaged] https://launchpad.net/bugs/1353587
<pitti> ginggs: I thought xnox wanted to keep it for measuring ubuntu-touch
<pitti> I don't mind removing it, we can always get it from wily or a PPA, though
<pitti> on touch you can't directly apt-get install it anyway
<ginggs> pitti: sounds good, what else needs to be done to get rid of python-support? LP: #1535318
<ubottu> Launchpad bug 1535318 in python-support (Ubuntu) "deprecation of python-support" [Undecided,New] https://launchpad.net/bugs/1535318
<ginggs> shall I add the rdepends as affected packages?  they are listed in the bug description
<pitti> yeah, makes them easier to find
<ginggs> pitti: launchpad had a few timeouts, but i've now added firmware-addon-dell and qdigidoc (but not the reverse-recommends bootchart and phablet-tools)
<Mirv> ok qtbase succeeded on wily so the bug is on xenial
<Odd_Bloke> rbasak: How is work on the git importer going?
<rbasak> Odd_Bloke: check with nacc please
<rbasak> Odd_Bloke: BTW, I have some tooling to import things manually, apart from one tweak to the format of the commit that cjwatson convinced me to make.
<rbasak> (if that's helpful to you)
<Odd_Bloke> rbasak: Ack, will do; I didn't see him online yesterday so didn't know if he was on VAC or somesuch. :)
<Odd_Bloke> rbasak: We're happy to wait; just don't want to wait unnecessarily. :p
<Saviq> pitti, hey, shouldn't the qtmir/qtmir-gles builds against proposed mir be proposed qtmir, too? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir
<pitti> Saviq: normally not, as they are separate packages
<pitti> Saviq: you can either force that by versioned Depends:/Breaks: (if the new mir breaks qtmir, that's cleaner), or if this is a test-only issue I can also re-run them against all of -proposed
<Saviq> pitti, I thought this was taken care of (like you guys marked mir and qtmir to always run together from -proposed)
<pitti> Saviq: no, there's no way to mark that
<pitti> Saviq: the way to say "foo/2 can only work with bar >= 3" is "Depends: bar (>= 3)" :)
<Saviq> pitti, well, yeah, it'd have to be Breaks: in this case, since it's the old qtmir that fails with new mir
<Saviq> and that's expected
<Saviq> pitti, can you tell why the armhf version tested was the -proposed one, actually?
<pitti> Saviq: it hasn't been tested yet
<pitti> autopkgtest for qtmir 0.4.7+16.04.20160219-0ubuntu1: armhf: Test in progress
<pitti> that version is meaningless
<Saviq> ack
<pitti> and I have a work item to not show it
<pitti> Saviq: so, want me to re-run against all of -proposed?
<doko> pitti, please hint diffoscape for python-setuptools
<Saviq> pitti, well, can you please restart them with all of -proposed and I'll file a bug against mir to add Breaks: as part of a release
<pitti> Saviq: queued
 * Saviq always felt weird about Breaks:, not that I have a better solution...
<pitti> doko: it already had a hint, bumped the version
<pitti> that'd be another useful case of hinting diffoscope/ppc64el instead of a version
<pitti> Saviq: well, it's weird in either case -- that means that Mir broke its ABI without bumping the soname?
<Saviq> pitti, well, actually... the real problem is likely the dummy test qtmir has - it really just tries to rebuild the package, which fails against new Mir
<Saviq> /likely/
<Saviq> pitti, I meant to drop that test since it ~doesn't make sense in autopkgtest
<Saviq> it was my try to find out when a package in proposed would break a downstream build
<xnox> ginggs, pitti: indeed, touch uses upstart. i don't mind, we can drop it. Or like port it to dh_python[23] which should not be that hard.
<Saviq> pitti, a Breaks: doesn't make sense here, either, exactly why you said - sonames are bumped as needed, so that will enforce dependencies to be correct
<pitti> doko: FYI, before you waste time on the libgps21 NBS: I filed bug 1548811, will track that down
<ubottu> bug 1548811 in geoclue-providers (Ubuntu) "FTBFS -- remove package?" [Undecided,New] https://launchpad.net/bugs/1548811
<doko> pitti, I think I filed one too ... can't find it
<doko> pitti: what was the outcome for gsoap, override the virtualbox test failure?
<ginggs> xnox: how was firmware-addon-dell 'fix released'?
<xnox> ginggs, it doesn't build-depend nor use python-support.
<xnox> ginggs, Convert to dh_python2. -> since 2013. So no actions are needed for it.
<ginggs> xnox: true, i only added it today because it is a reverse-depends of firmware-tools (see comment #34 in that bug)
<xnox> ginggs, yeah, that one still needs fixing, which i'm doing.
<xnox> ginggs, it doesn't make sense to add reverse-depends like that.
<ginggs> xnox: noted.  the only other reverse-depends i added there was qdigidoc
<pitti> doko: ah, can do
<xnox> ginggs, once my uploads migrate, i believe we will be good to remove python-support.
<ginggs> xnox:  \o/
<ginggs> xnox: i see you uploaded rather than removing, what do you think of fixing firmware-extract which was removed?
<ginggs> i believe it's a plugin for firmware-tools
<xnox> Â¯\_(ã)_/Â¯ -> really not my problem =) and i have no clue what these tools are, and wether they work at all anymore.
<doko> pitti, ta, python-setuptools now waits for britney to learn about the fixed python-pex
<xnox> ginggs, i think all of that is replaced with uefi capsules updates these days, rather than firmware-tools stuff.
<xnox> superm1, are firware-tools still in use/required to do things?
<superm1> xnox: not on workstation or client
<superm1> Possibly on server
<xnox> superm1, well it gained brand new support for dh-python2 instead of python-support, so it will live another lts untouched, hopefully =)
<sil2100> LocutusOfBorg: hey! Is there an LP bug for getting rid of fonts-droid ?
<seb128> sil2100, see "Fonts-droid has been deprecated and removed, please update your dependency :)" on ubuntu-devel@
<seb128> you replied to that discussion you should know about it?
<seb128> there is a bug mentioned in the discussion as well
<seb128> shrug, did optipng become slower on xenial? I remember it taking a while but now it takes ages it feels like
<LocutusOfBorg> sil2100, nope, I didn't open any bug :)
<sil2100> seb128: yeah, I know, I didn't remember seeing a bug on the initial e-mail
<sil2100> But there was one later on I see now
<smoser> hey. we're seeing server iso test failures
<smoser> https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/59/
<smoser> what seems key there to me is the syslog: https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/59/artifact/log/utah-10459.syslog.log
<smoser> which shows failure to install packages because of
<smoser> The following packages have unmet dependencies:
<smoser>  libpam-systemd : Depends: systemd (= 229-1ubuntu2) but 229-1ubuntu4 is to be installed
<smoser>  lxc : Depends: iptables but it is not going to be installed
<smoser> Unable to correct problems, you have held broken packages.
<smoser> the word 'held' seems probably important there. the install seems to have access to the archive, but I dont know why 'iptables' would not be available.
<Kryczek> smoser: may I ask what tool chain do you use to build server ISOs? I tried to look at the log but I am guessing it is firewalled :)
<smoser> Kryczek, fudge. i can pastebin the log for you.
<smoser> i'm pretty sure its 'debian-cd'
<smoser> but i've never actually touched any of that.
<smoser> i'd have to ask cyphermox  or infinity for that info.
<smoser> Kryczek, http://paste.ubuntu.com/15180824/
<cyphermox> yes, CDs are built by debian-cd, among other things
<cyphermox> that's not a cd build issue though
<cyphermox> it happens regularly that systemd isn't done transitioning, that's usually fixed by the next build
<Kryczek> ah ok, not the Debian Live (live-build) tool chain then? Just wanted to point out that it is unmaintained unfortunately
<cyphermox> oh, missing iptables too
<utlemming> pitti: er, seeing something really odd. If you define 'console=ttyS1' for the kernel CLI, then systemd just hangs
<Kryczek> smoser: thank you for the paste
<utlemming> pitti: the change happened about a week ago
<cyphermox> Kryczek: some builds do use live-build, I'm not sure which precisely.
<doko> pitti, barry, virtualenv still triggers test failure for tox
<Kryczek> cyphermox: would be funny if it was "precise" ;D
<smoser> cloud-image builds use live-build
<cyphermox> there we go ;)
<smoser> cyphermox, 'isnt done transitioning'
<smoser> ?
<smoser> as in only parts of systemd got into xenial/ from xenial-proposed  ?
<barry> doko, pitti yeah, that makes no sense and i can't reproduce it locally :(  any thoughts on how to debug the problem?
<pitti> manjo: what's the status on bug 1548120? it's "block-proposed", and thus blocks further uploads of i-t
<ubottu> bug 1548120 in initramfs-tools (Ubuntu) "[xenial][initramfs-tools] support uppercase and lowercase uuids" [High,In progress] https://launchpad.net/bugs/1548120
<cyphermox> smoser: the systemd failing to install in that paste means, IIRC, that systemd wasn't all done moving from proposed to releae at the time the CD was built, yeah. I may be oversimplifying this, but it's an issue that happens with the dailies and you don't have to do anything special.
<pitti> barry: socket.timeout: timed out
<pitti> barry: is that trying to call out to the interwebs without using the $*_proxy vars perhaps?
<manjo> pitti, I need to test apw's version of the patch
<barry> pitti: do you see that timeout in the tox test?  i don't
<pitti> requests.packages.urllib3.exceptions.ConnectTimeoutError: (<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7faf4e29dd68>, 'Connection to pypi.python.org timed out. (connect timeout=15)')
<pitti> barry: this looks pretty clear?
<pitti> I mean that it tries to get stuff from the network, apparently not using the proxy?
<barry> pitti: yes, but which log is that in?
<apw> pitti, i made it block-proposed deliberatly because what is in the current -proposed isn't something i want out
<pitti> barry: the one linked from excuses, e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160222_203430@/log.gz
<pitti> apw: ok; my upload isn't urgent at all, so ok for now
<apw> pitti, if you want to send me over the diff i can merge it with the "next" one
<apw> with the fixed fix for this mess
<barry> pitti: i'm looking at 20160223_blah
<barry> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160223_151914@/log.gz
<barry> it ends in pkg_resources.extern import error
<pitti> ah, that's a different one indeed
<barry> pitti: you'd expect that to be locally reproducible with, e.g.: `adt-run tox -- schroot xenial-amd64` yeah?
<pitti> --apt-pocket=proposed -U tox
<barry> (assuming of course -proposed is enabled in that chroot)
<pitti> but I just run that (with qemu), and it works
<barry> pitti: yeah, that's weird right? :)
<smoser> cyphermox, hm.. well, it'd seem a general issue if we're moving parts of a source package at a time from -proposed.
<smoser> i'd have thought that would be all at once for a source package.
<cjwatson> it's not possible to move parts of a source package at once, so no, that doesn't happen
<barry> pitti: the error happens when trying to install pytest>=2.3.5, pytest-timeout.  we have pytest 2.8.7.  yeah it passes for me too
<smoser> cjwatson, not possible ?
<smoser> as in only one binary package can be moved at a time?  or just as in not implemented.
<cjwatson> what
<cjwatson> no, the opposiute
<cjwatson> the primitive operation here is "copy source package (with binaries)"
<smoser> right.
<smoser> thats what i would have thought.
<smoser> so then it must be the 'held' part of the message that causes the failure ?
<smoser> "Unable to correct problems, you have held broken packages."
<cjwatson> not relaly
<cjwatson> the message you quoted does not contain enough information to work it out
<smoser> woudl you take a look at the link or the paste ?
<cjwatson> "is not going to be installed" is apt-speak for "this package is available, but when I try to install it I get broken dependencies, and I'm not going to tell you why"
<cjwatson> apt typically doesn't print enough information to diagnose this class of problem just from its output
<cjwatson> you have to set up a matching environment (in chdist or whatever) and test-install things with increasing constraints until it gives you useful answers
<cjwatson> however, in this case it could be that the squashfs base system is out of date
<smoser> i'd guess you're right that the squashfs is out of date.
<smoser> but then why wouldn't it pull whatever it needs from the archive.
<cjwatson> well, we could spend hours investigating that, or I could go fix the stuck builds that are causing the OOD squashfs
<cjwatson> the latter being the correct solution anyway :)
<pitti> barry: I just ran it in production (manually), and get the socket timeouts again
<sil2100> LocutusOfBorg: hey! Could you answer some questions regarding the fonts-droid deprecation to Elleo?
<sil2100> LocutusOfBorg: Elleo is the person responsible for ubuntu-keyboard
<cjwatson> the key bit of log output here is noting the presence of "Parallel build" near the top of http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/xenial/daily-20160223.log
<sil2100> And it seems the switch of that is not as obvious
<smoser> so what is to be done to fix stuck builds ? im' fine with that other than it just means this happens at some other point.
<Elleo> LocutusOfBorg: heya, just removing fonts-droid we lose some characters we need for chinese, but it seems impractical to replace it with fonts-noto-cjk as that's nearly 100MB larger than fonts-droid (and space is a concern issue on touch images)
<cjwatson> when more than one build is happening at once on cdimage, then we don't sync the archive because doing that in the middle of another build is bad news
<cjwatson> this is normally allowable, but if it gets confused for some reason then we can end up *never* syncing cdimage's mirror
<Elleo> LocutusOfBorg: unless you know of any other smaller font package that could do the job?
<cjwatson> and that's bad, and eventually people notice due to this kind of thing
<cjwatson> now, I fixed most of the common causes for this a while back
<cjwatson> but I suspect that the reboot of nusakan the other day happened at a suboptimal time, and left some confusion around
<cjwatson> because the semaphore of "how many builds are running" has a value two higher than it ought to be
<LocutusOfBorg> Elleo, fonts-droid-fallback?
<cjwatson> so I've manually decremented it twice ("semaphore decrement-test /srv/cdimage.ubuntu.com/etc/.sem-build-image-set" as cdimage@nusakan) and that should clear things once the build that's currently in flight finishes
<barry> pitti: can you figure out what it's trying to download from pypi?  odd too that the timeout is completely different from the autopkgtest log traceback
<LocutusOfBorg> or fonts-noto?
<LocutusOfBorg> I don't know about the chinese issue, and I'm not understand why debian is not aware of it
<Elleo> LocutusOfBorg: fonts-noto doesn't include chinese characters
<barry> pitti: and *that's* strange because the traceback doesn't at all match the code i get locally when i create the tox environment form the `built` test
<Elleo> LocutusOfBorg: will give fonts-droid-fallback a go and see if that has what we need
<cjwatson> logs suggest that this situation started on the 20th, which would match up with nusakan's reboot on the 19th
<pitti> barry: it's not, it's exactly the same log as https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160223_151914@/log.gz
<pitti> barry: as for that other error, I don't know what that means, maybe transient?
<LocutusOfBorg> thanks Elleo
<Elleo> LocutusOfBorg: I don't see a fonts-droid-fallback package anywhere?
<barry> pitti: okay, but in that log file you just pasted, search for "socket".  the only 2 occurrences have nothing to do with socket.timeout
<smoser> cjwatson, thank you. we'll hope it works itself out.
<smoser> nuclearbob, ^ matsubara ^
<cjwatson> I think maybe ideally we'd have a sort of multi-pid-file rather than a counting semaphore there
<cjwatson> then it would be possible to automatically recover from this sort of situation
<cjwatson> but fortunately it's not all that common after the fix I applied in December
<cjwatson> (cdimage r1557)
<pitti> barry: sorry, that was the link you posted; I meant https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160222_203430@/log.gz
<matsubara> thanks cjwatson for kicking things again
<LocutusOfBorg> Elleo, https://launchpad.net/ubuntu/+source/fonts-android
<matsubara> and you too smoser
<LocutusOfBorg> fonts-droid-fallback_6.0.1r16-1_all.deb (1.7 MiB)
<barry> pitti: ah 20160222
<Elleo> LocutusOfBorg: ah, thanks
<nuclearbob> smoser: fwiw, the problem seemed to be that the already installed version of systemd (presumably in the squashfs) was higher than the version of libpam-systemd in /pool on the cd
<barry> pitti: so, if we ignore 20160223 and look at 20160222, then maybe i can make more progress, but it bothers me that we have two different failures, neither of which is reproducible locally ;)
<cjwatson> nuclearbob: ah yes, that's why it doesn't just pull whatever it needs from the archive, because in this case that archive is on the ISO and the result would be a downgrade
<barry> pitti: is there a way for you to run tests on production without an upload?
<pitti> barry: yes (that's what I just did)
<cjwatson> and apt doesn't do downgrades by default
<smoser> but how would the archive have older ?
<pitti> barry: I can also run it, use --shell, and then give you ssh to it
<smoser> the cd was built from the archive
<cjwatson> smoser: not quite
<cjwatson> smoser: it was built from an rsynced mirror of the archive
<cjwatson> smoser: which, due to the situation explained above, hadn't actually been rsynced for several days
<cjwatson> smoser: but the squashfs is built on LP directly from the archive
<barry> pitti: that could help.  what i'm thinking is that i could make an educated guess as to the failure, make a change and hand you a source package to see if production passes or not
<smoser> ah.
<smoser> ok. that makes sense then.
<cjwatson> so if cdimage's mirror gets stuck this way then it's possible for it to be older
<barry> pitti: but ssh would definitely let me poke around some more
<barry> (i.e. put the "educated" in "educated guess" :)
<cjwatson> in normal circumstances it isn't possible for it to be older, because we deliberately try to sync the archive after doing the squashfs build
<cjwatson> for exactly this kind of reason
<pitti> barry: ok, it'll take some minutes until the test finished
<Elleo> LocutusOfBorg: fonts-droid-fallback seems to work thanks, still need to test it a bit more to be absolutely certain but it looks promising
<LocutusOfBorg> wonderful!
<LocutusOfBorg> thanks a lot for the feedback/fix
<pitti> apw: the transitional linux-meta packages on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt -- these should be seeded, I suppose?
<apw> pitti, a good point, do we have to seed them alllll explicity or is there something else we should be doing in the kerenl package
<pitti> apw: they are just for upgrades from previous releases, they'll all go after xenial, right?
<apw> pitti, that indeed
<pitti> apw: so they won't be a dependency of anything, hence they need seeding, yes
<pitti> apw: if *all* binaries from linux-meta should be in main, then seeds have a syntax for that
<apw> pitti, i don't believe we have any primary packages (.deb) which are not for main in any of our packages
<apw> pitti, but that they are listed explicity is worrysome
<pitti> apw: in supported-kernel-common? yeah
<pitti> apw: and a lot of them are obsolete too
<pitti> supported-kernel-common: * linux-signed-generic-lts-quantal
<apw> pitti, i would normally look at infinity at this point, as he would have gotten us as far as here
<pitti> apw: I figure it'd be a lot simpler to just replace all of that with "all sources of linux-meta" (whatever the syntax was)
<pitti>  * (srcpkgname)
<pitti> perhaps?
<apw> pitti, i can't see a reason that would be wrong these days, we did use to have split flavours once-upon-a-time
<pitti> ah no, those were recommends
<pitti> apw: aah, man germinate
<pitti>  * %linux-meta
<pitti> apw: ^ this should do it
<apw> pitti, cool thanks for fixing our messes :)
<pitti> apw: oh, I wasn't actually changing the seeds, but I can if you confirm that's the right thing
<pitti> that == all binaries of linux-meta
<apw> pitti, i'll take it and figure that out definatlvly and get back to you
<apw> (or to me, depending)
<pitti> apw: I figure we could start with replacing the entire supported-kernel-common with just %linux-meta, and then see what falls out of that?
<pitti> i. e. wait for a publisher cycle and check component-mismatches
<apw> pitti, if its not going to cause chaos, that sounds like a plan
<pitti> apw: well, I figure kexec-tools and thermald should stay, but all others
<pitti> apw: no, not at all; supported-* isn't defining images, just stuff that's in main despite *not* being on any image
<pitti> apw: we might have soem linux-meta-$flavor which should stay in universe, all others should be there in the seed
<apw> pitti, we have other linux-meta-foo sources which produce things whihc should be, but not from linux-meta i don't think any more
<apw> 'should be in universe"
<cjwatson> snakefruit (proposed-migration, people.canonical.com/~ubuntu-archive/, etc.) will be going down for reboot for a little while shortly; I've shut down archive cron jobs there in preparation
<cjwatson> snakefruit back
<cyphermox> pitti: could you point me to your bug about setting up multiple crypted drives in the installer you mentioned yesterday? I can't find it anymore
<pitti> cyphermox: bug 1548252 ?
<ubottu> bug 1523194 in partman-crypto (Ubuntu) "duplicate for #1548252 Can't install /home into separate LUKS encrypted volume" [High,Triaged] https://launchpad.net/bugs/1523194
<nacc> slangasek: now that FF is in effect, how do syncs with Debian work? e.g., for php7.0 to pass its autopkgtests, we need (at least) php7.0.3-6 (7.0.3-7 is in unstable as well). Do I need to file a bug to request the sync (technically it's mentioned in LP: #1547738)
<ubottu> Launchpad bug 1547738 in php7.0 (Ubuntu) "Request: Sync with Debian to get upstream fixes for autopkgtests" [Undecided,New] https://launchpad.net/bugs/1547738
<nacc> slangasek: actually, i guess they are merges now, since we have a delta ... I can do that merge (and I think we can drop some of the delta now that xmlrpc-epi is in main). So would i put the resulting debdiff in that bug then? and mark it as a FFe?
<cyphermox> pitti: thanks
<jdstrand> tyhicks: fyi, not sure if you noticed but your apparmor upload got stuck
<jdstrand> tyhicks: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says 'autopkgtest for systemd 229-1ubuntu4: ppc64el: Test in progress'
<jdstrand> tyhicks: iirc, it has said that for days
<pitti> ah, that's not tyhicks's bug
<pitti> sorry, I'll unstick it
<tyhicks> thanks pitti!
<pitti> i. e. I re-run the test, the reason for the temporary failure got fixed
<jdstrand> cool
<jdstrand> thanks pitti :)
<jamespage> pitti, thanks for working the tomcat8 transition through btw
<doko> nacc, slangasek: it's not yet available for syncing, doing it later
<nacc> doko: 7.0.3-6 is available, i think ... but we can wait for -7, do you want a debdiff for the merge to do it?
<cjwatson> smoser: OK, I might have accidentally slipped and rewritten cdimage's locking code so that it tracks multiple pids rather than just a count and automatically removes dead processes from its tracking.  Not committing it quite yet because there are builds in progress, but I'll deploy it once everything's quiet.
<cjwatson> http://paste.ubuntu.com/15181704/
<doko> nacc, no, will sync it when I'm back home tonight
<nacc> doko: ok, thanks!
<xnox> pitti, doko, cjwatson: please RM python-support
<xnox> https://bugs.launchpad.net/ubuntu/+source/python-support/+bug/1535318
<ubottu> Launchpad bug 1535318 in python-support (Ubuntu) "deprecation of python-support" [High,Triaged]
<pitti> w00t!
<xnox> all clear.
<doko> me, me ...
<pitti> doko: do you want to ... have the honor?
<pitti> yeah, I'll leave it to doko, he really deserves it more
<pitti> . o { https://launchpad.net/~ubuntu-cruft-busters ! }
<doko> Comment: fiiiiinally, lp: #1535318, remove python-support
<doko> 1 package successfully removed.
<ubottu> Launchpad bug 1535318 in openmeeg (Debian) "deprecation of python-support" [Unknown,New] https://launchpad.net/bugs/1535318
<xnox> doko, i see that landscape client is python2 and twisted, do we have working python-twisted-conch|-core|-web in python3 yet?
<xnox> i see that those bits are in python3-twisted.
<doko> xnox, yes, everything which is in the package should be supported
<Pharaoh_Atem> nacc: did you see my message on LP #1547738?
<ubottu> Launchpad bug 1547738 in php7.0 (Ubuntu) "Request: Sync with Debian to get upstream fixes for autopkgtests" [Undecided,New] https://launchpad.net/bugs/1547738
<seb128> bdmurray, hey, do you have any opinion on https://code.launchpad.net/~seb128/software-properties/newtab-enable-proposed/+merge/286626 ? I know you suggested dropping it but that let a graphical way to enable proposed and that's what willcooke suggested doing after talking to ara and mpt
<nacc> Pharaoh_Atem: yeah
<seb128> I've no opinion either way, I think it's better than we have now so I'm trying to land it, we can still do other changes later if something else is decided
<bdmurray> seb128: I think I suggested dropping it if the release is still in development, but I didn't see an easy way to do that. And yes this does seem like an improvement.
<nacc> Pharaoh_Atem: it should get sync'd tonight
<xnox> barry, is there 2to2and3 tool yet? cause the output 2to3 generates is questionable.
<xnox> e.g. ideally i want "from __future__ import print function" et.al.
<barry> xnox: http://python-future.org/automatic_conversion.html
<xnox> omg, i love this "pasteurize"
<barry> cute, huh? :)
<nacc> slangasek: doko: if we want to pull the xmlrpc binpkg back in, when we sync with 7.0.3-7, would you want a bug & debdiff for that?
<Pharaoh_Atem> nacc: is that tonight in US timezone or UK timezone?
<nacc> Pharaoh_Atem: doko's timezone :)
<Pharaoh_Atem> so CEST+1
<Pharaoh_Atem> which means it'll sync now?
<Pharaoh_Atem> ;)
<nacc> Pharaoh_Atem: it'll sync when it syncs :)
<nacc> Pharaoh_Atem: would you have some time to look at LP: #1548442 ?
<ubottu> Launchpad bug 1548442 in php7.0 (Ubuntu) "php7.0: segmentation fault running twig test suite" [Undecided,New] https://launchpad.net/bugs/1548442
<Pharaoh_Atem> nacc: yeah, sure
<nacc> Pharaoh_Atem: thanks, working on package builds and stuff
<Pharaoh_Atem> errm
<Pharaoh_Atem> I'm getting hash sum mismatch errors for "apt update" in universe
<sarnold> try again in a few minutes
<nacc> Pharaoh_Atem: yeah, it happens :)
<coreycb> arges, bdmurray, Hi, we have a ceilometer SRU in the wily queue that could use a review
<arges> coreycb: ok
<coreycb> arges, thanks
<Pharaoh_Atem> nacc: welp, I'm getting two different errors on two different machines (ubuntu 16.04 + php7.0-7.0.3-3, CentOS 7.2 + php70-7.0.3-1.el7.remi)
<Pharaoh_Atem> and the best part? neither of them are giving me the error you got
<Pharaoh_Atem> I'm compiling php7.0-7.0.3-6 for debian 8 and giving it a go to figure out what's going on here
<arges> coreycb: so bug 1530913 is going to be superceedd by this
<ubottu> bug 1530913 in nova (Ubuntu Wily) "[SRU] liberty point releases" [Undecided,Fix committed] https://launchpad.net/bugs/1530913
<coreycb> arges, yes, that was the prior point release
<arges> coreycb: well it is still in proposed, does it need to be released first, or is this bug fixing something with that
<coreycb> arges, oh..  I didn't realize that.  no as far as I know the old one was tested and is ok.
<arges> coreycb: ok
<coreycb> arges, thanks, let me know if it's stuck for a reason
<arges> coreycb: ok done
<coreycb> arges, thanks1
<coreycb> explanation point fail
<coreycb> I can't type
<nacc> Pharaoh_Atem: ok, thanks, the above was seen was with 7.0.3-5
<slangasek> nacc: FFe is only needed if the changes you're making (whether by merge from Debian or otherwise) are features.  If this is just bugfixes, no FFe is required.
<slangasek> doko: sorry, don't know why you hightlighted me, what was not available for syncing?
<nacc> slangasek: i think php7.0.3-7, just for your reference
<slangasek> ok
<slangasek> which I think is not meant to be a sync anyway
<nacc> slangasek: ok, it could be a bit of both? as php7.0 is under active dev, but will wait to see what doko says
<nacc> slangasek: right, it'd be a merge now, aiui?
<slangasek> yes
<nacc> slangasek: ok, so for pkg-php-tools, looks like one fix is upstream already (in debian's git). I am sending the other one in now
<slangasek> excellent
<slangasek> nacc: I'm probably not available to help with sponsorship for the next day or so fwiw
<nacc> slangasek: not sure how to make the test make sense for them, as the error message will vary between php5 and php7, and it's a phpunit comment that provides the matching string, but they'll know what to do
<nacc> slangasek: ok, np
<nacc> slangasek: would it be better for me to provide a debdiff from what is currently in xenial to a level that works or request a fresh sync and provide a debdiff to that?
<slangasek> nacc: a sync is *only* ever for a package that we want to have a package uploaded to Ubuntu that's identical to the one in Debian.  Otherwise it's a merge; for a merge you can provide a debdiff against either the existing Ubuntu package (xenial-proposed or xenial), or against the new Debian version that you're asking to have merged
<slangasek> nacc: and merges.ubuntu.com is your friend
<nacc> slangasek: got it, thanks
<xnox> slangasek, i have things in NEW, do that need FFe or not?
<slangasek> xnox: source NEW - no, it just requires securing an AA's time
<xnox> slangasek, gotcha. hope you are having fun =) and not spending too much time on irc =)
<slangasek> xnox: yeah, I'm about to run away ;)
<xnox> \o/
<Unit193> Alright, I give up.  How do I specify the filesystem that filesystem.squashfs should be mounted udf, not iso9660?
<xnox> Unit193, filesystem.squashfs is a squashfs =)
<Unit193> xnox: I know, but it sits on media, which has a filesystem.
<Unit193> And I don't know how to continue boot from busybox after remounting /cdrom with -t udf.
<Unit193> Ooh, worked to recover from busybox this time.  Though it's still trying iso9660 which is not going to work.
<barry> doko, pitti: new tox syncpackaged.  let's see if that gets us past proposed
<Unit193> xnox: So, no ideas?
<stefanct> hi there. i am the upstream maintainer of flashrom. the debian maintainer has not updated his package for a while but did so now... however as you know the LTS freeze is in place and we would need an exception
<stefanct> the now published debian package is of an upstream rc and thus will probably become outdated in a week when we do a full release
<stefanct> id like to know what is preferable... getting an exception for the rc now and request a pull in about a week or if we should wait till the full upstream release is done and packaged for debian in about a week
<tarpman> stefanct: freeze? debian isn't in any freeze right now AFAIK
 * tarpman looks at what channel he's in and shuts up
<stefanct> :)
<stefanct> flashrom was always pulled in from debian
<sarnold> stefanct: i'm guessing a week's delay would be fine, though it might not be a bad idea to start the paperwork early
<stefanct> sometimes with a sponsored upload after a freeze... but we never had to build a package (someone of you always helped out so far ;)
<stefanct> but yes, the bug report is there but we need to fill it
<nacc> doko: fwiw, the merge with -7 isn't exactly straightforward (and the delta changes, i'm testing my debdiff now, but i can file a bug and send it your way if you want)
<doko> nacc, ta, I'm just back, best thing would be a bug report, and subscribe me
<nacc> doko: will do, want to make sure the build works fine, then will file, is it ok if i use the bug report that was already filed requesting we pull in the debian fixes?
<nacc> Pharaoh_Atem: around?
<stefanct> oh wow... s390 O_o why was that added? :)
<sarnold> because someone wants to sell them :)
#ubuntu-devel 2016-02-24
<doko> s390x, not the 31bit variant
<nacc> hrm, weird bug here -- trying to figure out why php-zeta-base tests are failing. Set up parallel sid and xenial chroots (as sid successfully passes the tests). Took a look at what exactly is failing and it's a size miscompare for a file from php-zeta-unit-test (specifically, /usr/share/php/data/UnitTest/design/class_diagram.png). In Debian that file is 163K, in Ubuntu it is 74.5K. Is this the result of
<nacc> the "PNG optimization" stuff I see run?
<nacc> and is the solution, where the tests are actually looking to compare the sizes returned by some API, to update the tests in Ubuntu to use the correct size?
<nacc> seems annoying to carry that delta just because of that
<nacc> "pkgstripfiles: Running PNG optimization (using 4 cpus) for package php-zeta-unit-test ..."
<nacc> hrm
<doko> nacc, you can disabled that by: export NO_PNG_PKG_MANGLE=1
<doko> for Debian, that wouldn't have any effect
<nacc> doko: how do i disable that in the ubuntu build?
<nacc> oh, in the rules?
<doko> yes
<nacc> ah ok, i'll submit a patch :)
<doko> pitti, barry: new lava-dispatcher autopkg test failure triggered in python-setuptools :-/
<nacc> slangasek: pitti: well, twig failures now are not segfaults :) (with 7.0.3-7) ... still failures, but something at least
<cpaelzer> good morning
<pitti> stgraber: I uploaded lxd for bug 1549133 as that wreaks havoc; can you please commit the fix to your git too?
<ubottu> bug 1549133 in lxd (Ubuntu) "upgrade failure" [Critical,Fix committed] https://launchpad.net/bugs/1549133
<pitti> I had to downgrade lxc on all autopkgtest hosts, the new one fails completely :(
<cjwatson> mfisch: Would you mind if I stole your debmirror merge?
<cjwatson> mfisch: (you touched it last, but in 2013)
<pitti> doko: tests are ok now
<pitti> doko, apw: ah, virtualbox tests fail because our kernel now ships the vboxguest module pre-compiled; I guess we should remove the DKMS module from vbox then?
<pitti> apw: linux-{goldfish,manta} and a few others still have a dependency to module-init-tools
<pitti> apw: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/l/linux-goldfish/20160224_065132@/log.gz doesn't seem to like that
<pitti> apw: but either way this is obsolete, so changing it to "kmod" in git would be appreciated
<infinity> pitti: The original intent in shipping the vbox dkms modules still was in case they updated out of sync, but I think the syncing mechanism that pulls from the vbox source package the linux source package might make that pointless.  Andy and I will discuss when I'm legit awake.
<infinity> pitti: And yeah, they're well aware that all the Android kernels are a mess. ;)
<dholbach> good morning
<infinity> pitti: Seems the flavours are still getting no love with your upower fix in #-release
<pitti> infinity: hm, so the ubiquity crash is separate after all?
<pitti> i. e. bug 1548362
<ubottu> bug 1547793 in Upower "duplicate for #1548362 upowerd crashed with SIGSEGV in g_variant_is_trusted()" [Critical,In progress] https://launchpad.net/bugs/1547793
<infinity> pitti: Perhaps.  If you could get them to feed you backtracey things (or try it yourself), that might be nice.
<infinity> pitti: ubiquity apparently crashes on launch, so not tough to repro.
<pitti> unduped for now
<infinity> pitti: If you do find the issue, can you pre-upload to Ubuntu, rather than Debian and sync, since the flavours are trying to pull off a Beta?
<pitti> infinity: sure, that's what I did yesterday
<infinity> Ta.
<pitti> infinity: I started the current live system, and ubiquity comes up fine
 * infinity raises brow.
<pitti> so the reproduction instructions need to be a tad more precise, I'm afraid
<infinity> Try xubuntu or Ubuntu GNOME?  They were the two complaining, AFAIR.
<LocutusOfBorg> Adri2000, what about updating filezilla in debian too? I can sponsor a dsc
 * pitti restarts it with giving it an actual hard disk image, so that I get beyond the initial greeter
<pitti> ok, moving to #u-r
<LocutusOfBorg> can anybody please retry https://launchpad.net/ubuntu/+source/rhythmbox/3.3-1ubuntu5 on s390x?
<pitti> LocutusOfBorg: done
<LocutusOfBorg> thanks
<LocutusOfBorg> and thanks for syncing spooles
<LocutusOfBorg> it was on my todo
<pitti> doko: python2.7 landed, python-setuptools is a valid candidate, but causes uninstallability (I guess that's not a surprise due to the -wxl removal?)
<Adri2000> LocutusOfBorg: hi, I thought I sent you links for review in /query and now realize I did that on the wrong IRC server :s let me try again
<doko> pitti, argh, yes. until now it only showed the breaking pip whl
<LocutusOfBorg> what appened to node-tap autopkgtest for amd64?
<LocutusOfBorg> http://autopkgtest.ubuntu.com/running.shtml#pkg-node-tap
<LocutusOfBorg> not only node-tap, but it is what I was waiting to migrate
<LocutusOfBorg> OverLimit: Quota exceeded for ram: Requested 1536, but already used 50688 of 51200 ram (HTTP 413) (Request-ID: req-a67b23c2-bd77-4c59-9675-0b3823421f22)
<LocutusOfBorg> ERROR: Quota exceeded for ram: Requested 1536, but already used 50688 of 51200 ram (HTTP 413) (Request-ID: req-a67b23c2-bd77-4c59-9675-0b3823421f22)
 * LocutusOfBorg wonders if it is really a problem, or something that will be automatically fixed
<bigon> 52
<cpaelzer> lamont: I was configuring a postfix on xenial this morning which just got the merge to 3.x
<cpaelzer> lamont: I was seeing this http://paste.ubuntu.com/15186744/ and wanted to ask you if the old default config was kept intentionally or if it is worth to file a LP bug for it
<doko> coreycb, 1548512 is missing a bug subscriber
<rbasak> pitti: around? My pending squid merge is racing systemd on pidfile creation (after the parent process exits 0, using an /etc/init.d/squid script). What can I advise upstream?
<rbasak> A sleep before the init script exits after start works around it.
<rbasak> Is there some mechanism by which we can tell systemd to wait for the pidfile to be created? Or perhaps I should do that in the init script?
<coreycb> doko, sorry, working on adding a bug subscriber
<bzoltan> xnox: ping
<xnox> bzoltan, hello
<bzoltan> xnox: hi there... I would like to ask your help if you have few minutes
<xnox> bzoltan, depends what it is about =)
<bzoltan> xnox:  I have a strange s390x build failure .. only on xenial and only that arch - https://launchpadlibrarian.net/242402456/buildlog_ubuntu-xenial-s390x.ubuntu-ui-toolkit_1.3.1862+16.04.20160224-0ubuntu1_BUILDING.txt.gz
<bzoltan> xnox:  that is the part http://pastebin.ubuntu.com/15187078/
<bzoltan> xnox:  this branch does it -> https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/OTA10-landing-2016-01-20/+merge/283385
<xnox> bzoltan, there is nothing strange about it, and the compiler tells you exactly what is missing.
<xnox> bzoltan, it appears to be underlinked again, as the compiler says...
<bzoltan> xnox: it is missing the libUbuntuToolkit.so.5 yes
<xnox> "warning: libUbuntuToolkit.so.5, needed by /<<BUILDDIR>>/ubuntu-ui-toolkit-1.3.1862+16.04.20160224/tests/unit/../../qml/Ubuntu/Components/libUbuntuComponents.so, not found (try using -rpath or -rpath-link)"
<xnox> it appears that the library in question is moved / not present in the -L specified repositories.
<xnox> last time, i send a patch to add it in, later it was shuffled around/removed.
<xnox> bzoltan, i suspect that things are not done right everywhere, it's just s390x is bloody fast and does more things in parallel =) exposing bugs in the configury-buildsystem you have done.
<bzoltan> xnox: I see
<xnox> are you sure that (a) libUbuntuTOolkit.so.5 is built (b) linked (c) the dependencies are set right that e.g. said test depends on Toolkit to be built (d) -L linking is included.
<xnox> bzoltan, i don't know which buildsystem you are using, but you should be able to carefully check that imperically.
<bzoltan> xnox:  for the src space we used this patch from cjwatson http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/staging/revision/1000.84.1#src/src.pro
<marlinc> What would happen to ZFS updates once 16.04 gets out? Will we for example still get 0.7 in 16.04?
<xnox> bzoltan, e.g. it looks like "-L/<<BUILDDIR>>/ubuntu-ui-toolkit-1.3.1862+16.04.20160224/tests/unit/../../qml/Ubuntu/Components -lUbuntuComponents" is done right. But I don't see similar for e.g. "toolkit".
<xnox> bzoltan, and/or possibly components, should have a correct dep on Toolkit, such that whenever linking to Components is requested appropriate "-L/<<BUILDDIR>>/ubuntu-ui-toolkit-1.3.1862+16.04.20160224/tests/unit/../../qml/Ubuntu/Toolkit -lUbuntuToolkit" or some such is included there too.
<xnox> bzoltan, that change looks good, however it should also have src_test.depends = sub-toolkit or some such. Or the sub-components should have a dep on sub-toolkit, or some such.
<xnox> bzoltan, cjwatson: i don't speak QMake (?!) at all =)
<xnox> bzoltan, but yeah it is high-parallelisation race discovered.
<bzoltan> xnox:  cool, thanks. I understand the issue.
<xnox> bzoltan, sorry, i can't like patch qmake .pro files to do that =/
<xnox> i only have a yellow qt-foo belt.
<ginggs> xnox, superm1: fyi i uploaded a fixed firmware-extract to go with firmware-tools that xnox fixed, it is currently in NEW
<bzoltan> xnox: :)
<cjwatson> xnox: I hope you're not under the impression that I immediately knew how to fix that one :)
<cjwatson> I seem to remember spending quite a while experimenting
<xnox> cjwatson, but you have +1 lines of code of QMake experience over me =)))))
<xnox> pitti, systemd does not boot
<cjwatson> xnox: that is indeed about the sum of it
<pitti> xnox: that's a little vague :)
<xnox> pitti, so the bug is https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1546714
<ubottu> Launchpad bug 1546714 in systemd (Ubuntu) "System not booting when /home is on separate LUKS-encrypted partition" [Undecided,New]
<xnox> pitti, to reproduce, use installer, switch to "medium" priority and choose guided partitining to do "full disk, separate /home"
<pitti> rbasak: what do you mean? the pid file specified in PIDFile= isn't created late/early enough, i. e. systemd considers the daemon as running too early/late?
<xnox> pitti, i see fstab unit generated for home.mount with a wantedby local-fs.target or some such, but it fails to boot.
<xnox> i'm not sure of a better term, it did boot, cause we are past kernel and initramfs. I guess we "fail to reach default.target" =)
<pitti> xnox: what do you see? does it ask you for the password, etc?
<pitti> journal would be very helpful (debug shell)
<lamont> cpaelzer: it's a known thing, but yeah, a bug report would not be amiss
<rbasak> pitti: it's an init.d script only, no systemd service unit definition shipped by the package.
<rbasak> pitti: the init.d script exits with the daemon started but with no pidfile created.
<rbasak> pitti: "# pidfile: /var/run/squid.pid" is in the init.d script header which I think systemd picks up?
<xnox> pitti, this is without encryption at all. just /home on a separate partition from /
<xnox> pitti, ok, let me try to recover something from this vm.
<pitti> rbasak: right, it parses a pidfile: in the LSB headers, but if the init script doesn't create it it's fairly useless indeed
<xnox> pitti, also it looks like "recovery" boot option, and "system recovery shell" conflict with each other, and i booted to a messed up thing.
<pitti> xnox: ah, the bug speaks about a LUKS encrypted partition :)
<cpaelzer> lamont: ok I'll add that later on - thanks for the feedback
<xnox> pitti, the devil is in the last sentence =) "This does also happen, when you put LUKS on top of an LVM setup or if you even place the /home partition on a separate DASD. The problem is the same."
<xnox> pitti, so on amd64 this is totally reproducible with just normal install, using "guided paritioning, but /home on a separate partition".
<rbasak> pitti: it does create it, just late.
<pitti> well, I've always had /home on a separate partition
<rbasak> (after exit)
<pitti> rbasak: so the point of the PIDFile= option is that the service is "starting" while it doesn't exist, and the service is considered "started" (i. e. dependencies can start) once it does exist
<xnox> pitti, removing "quiet splash" makes it boot. SIGH
 * xnox adds back splash
<pitti> xnox: add systemd.debug-shell, let it fail, switch to shell, capture journal, attach it to the bug please?
 * lamont sometimes wishes that the default server install did "noquiet nosplash"
<xnox> pitti, i'm now blaming "splash"
<rbasak> pitti: "Job for squid.service failed because a configured resource limit was exceeded." when I run "systemctl squid start".
<pitti> lamont: I do believe servers don't use splash
<rbasak> pitti: unless I add a sleep before the init.d script exits
<xnox> lamont, default server installs do not specify "quiet splash", it's just empty -> thus should be chatty!
<lamont> even beter
<rbasak> pitti: I assumed that was a pidfile creation race, but I suppose it could be something else?
<rbasak> pitti: so my question is: what's a better way of fixing this, then a "sleep" workaround?
<pitti> rbasak: not sure, "sudo systemctl status -l squid" should have some details?
<rbasak> pitti: http://paste.ubuntu.com/15187272/
<barry> doko, pitti tox & python-virtualenv are all passing now
<pitti> rbasak: hmm, I guess to actually create the pid file before exiting? is it actually written?
<rbasak> pitti: no, it isn't written - I'm sure of that race.
<pitti> rbasak: ah, well, then that explains that failure
<rbasak> pitti: unfortunately I don't think I can easily persuade the daemon to do that.
<rbasak> pitti: right. So what's a good workaround?
<pitti> rbasak: drop the pidfile: from the init.d script then, if it isn't reliable?
<rbasak> pitti: upstream will fix in time, but I need something for the archive for now. Should I for example not tell systemd about the pidfile?
<rbasak> pitti: OK, makes sense. Thanks.
<doko> barry, yes, had to upload a new python3.5, venv not depending on python-setuptools-whl. Maybe it would have been better if python-pip-whl would provide that, but I didn't want to touch this stack again when all tests pass ... now waiting for the python3.5 autopkg tests
<xnox> pitti, oh blimey
<xnox> i think i end up being on a wrong tty.
<xnox> cause tty7 has "/dev/vda1: clean," message
<xnox> whilst tty1 is the one that has login.
<xnox> but on e.g. s390x there is no multiple ttys.
<barry> doko: agreed, and thanks!  you're probably right, but let's get all this stuff promoted and then try to improve.
 * xnox ponders what's going on.
<xnox> pitti, i do have splash quiet vt.handoff=7 -> no idea why i saw the fsck message though, and got stuck on tty7.
<lamont> oh cool, after rebooting, the clock at the top of the screen is working again.
<pitti> xnox: oh, so no debug shell for you either then
<xnox> pitti, so systemctl is-system-running -> says running.
<xnox> yet i don't have getty on tty7, plymouth has been terminated, and all i have there is a leftover fsck message.
<pitti> getty isn't supposed to be on tty7, only 1 to 6
<xnox> pitti, true.....
<xnox> however i don't have a display manager in this case =)
<pitti> xnox: so what is this, an s390x server install?
<pitti> or an amd64 VM?
 * pitti is confused
<pitti> xnox: is lightdm running? some /var/log/Xorg.0.log error perhaps?
<xnox> this is a netboot-install, amd64, VM, thus "server" which has separate /home, and ended up with "splash quiet" + plymouth + no dispalay manager + no-X, yet vt_handoff=7.
<pitti> meh, vt_handoff with a server install?
<xnox> yeap.
<pitti> xnox: so I take it /home is mounted after all
<xnox> yes.
<xnox> i don't think our mini.iso knows at all what's it's doing. But e.g. all s390x installs, are essentially "netboot" code path.
<pitti> I don't have a vt_handoff on cloud images, but they are fairly different from netboot indeed
<xnox> ubuntu server.iso takes the pre-bootstrapped code path.
<xnox> (whatever it's called when the squashfs filesystem is used, instead of "installing the base system bootstrap")
 * xnox live-installer ?!
 * xnox ponders if our base-installer method is borked.
<xnox> I can test verify this!
<jamespage> xnox, just looking at your -no-pie patch in qemu - do you think it would be possible to make that dynamic? i.e. only set -no-pie if the toolchain default is pie?
<xnox> jamespage, because you are backporting? we can do it per-release / if toolchain supports the flag.
<jamespage> xnox, basically yes
<xnox> jamespage, so xenial and up toolchains (and debian stretch) suppor the -pie / -no-pie flags, and we will have many architectures with -pie by default in the future.
<xnox> jamespage, s390x is a pilot one...
<jamespage> xnox, so really we need a check to see if -no-pie is supported, and then use if so
<xnox> jamespage, i can do that, i guess.
<xnox> yeap.
<xnox> doko, is there a good/imperical check ^
<xnox> jamespage, to be honest qemu does have support for "pie" builds, but i guess they don't support fully the "-no-pie" or e.g. toolchains with pie by default.
<xnox> doko, echo "" | gcc -fsyntax-only -no-pie -xc - ? is that ok.
<rbasak> cpaelzer: for the DPDK MIR, we just need to do whatever will pull DPDK into main, by a dependency or by seeding directly.
<doko> xnox, jamespage: -no-pie works in xenial on all archs
<rbasak> In this case we want it in main because of ovs, so presumably the right parts of ovs will get seeded and as soon as they depend on the bits of dpdk needed, they will generate a component mismatch.
<rbasak> jamespage will manage that I guess.
<xnox> doko, yeah, but jamespage is backporting qemu to cloud-archive, and gcc there does not support -no-pie =)
<xnox> jamespage, urgh, i patched upstream makefile.
<rbasak> Then because the MIR is already approved, an AA will issue the component override to actually make the change and put the dpdk source and right binaries into main.
<rbasak> Essentially main inclusion isn't a thing in its own right; it's a consequence of being seeded or being an indirect dependency of something that is seeded.
<cpaelzer> rbasak: ah ok, that I might do with jamespage then when he combines openvswitch-dpdk into openvswitch
<rbasak> In server we also have a special seed for stuff that we want to have in main but not ship or be seeded elsewhere, but use of that is fairly rare.
<rbasak> cpaelzer: right. You shouldn't have to do anything further - getting the MIR approved is enough.
<cpaelzer> rbasak: I only thought of the explicit seeding before - makes sense, thank you
<rbasak> np!
<xnox> jamespage, how do i test it? sbuild -A -d trusty qemu*.dsc -> should just work?
<jamespage> xnox, almost
<jamespage> you'll need to build against ppa:ubuntu-cloud-archive/mitaka-staging
<xnox> jamespage, how about i test build xenial, and you test build that. before i upload =)
<jamespage> xnox, that works for me
<jamespage> xnox, thankyou :-)
<xnox> jamespage, note this is not the only package with -no-pie... =)
<jamespage> xnox, only one I'm tripping over in the b-o-m right now
<jamespage> (backport-o-matic for reference)
<xnox> jamespage, but e.g. xenial is the "last" release to be backported onto things pre-xenial, right?
<xnox> e.g. we are not backporting Yummy packages to trusty-wily in the cloud archive?
<jamespage> xnox, yes thankgod
<xnox> jamespage, good, cause then we can drop these -no-pie extra stuff in Yummy Yak
<jamespage> love the name
<jamespage> not sure whether sabdfl takes suggestions or not :-)
<jamespage> cpaelzer, rbasak: my multi-ovs-vswitchd upload will pull it in - just working that now
<cpaelzer> there is not so much positive left other than yummy http://adjectivesstarting.com/with-y/ :-)
<jamespage> cpaelzer, dpdk is still i386 and amd64 only right?
<cpaelzer> jamespage: yes
<cpaelzer> jamespage: the ppc things where moved to (at least) 16.10 by the taco team
<jamespage> well at least I'll only extend two package builds x2
<cpaelzer> jamespage: and the IBM buy in was there, but not super huge
<xnox> cyphermox, cjwatson, pitti - i wonder if ".iso" based installs use preseeds to tweak default behaviour. With bare netboot defaults skewed for desktop, rather than server.
<xnox> which works ok mostly everywhere, apart from the crazy s390x.
<cyphermox> xnox: they do, but nothing comes to mind, from what I remember of it, that would break s390x
<cyphermox> what is it exactly that you see is wrong?
<xnox> cyphermox, like vt_hadoff splash quiet
<cjwatson> that's done in grub-installer/debian-installer-utils iirc
<xnox> on amd64 is specified, when using ubuntu mini.iso
<xnox> right, so that can't ever affect s390x.
<cjwatson> in fact vt.handoff is done in grub2
<cjwatson> splash quiet are done in grub-installer I believe
<cyphermox> yeah
<xnox> horum.
<xnox> jamespage, sorry it's taking so long, i by accident did non-parallel build, and now it's too late to kill and restart =/
<cyphermox> cjwatson: if there is a need to change anything in grub2 I have another change too
<cyphermox> xnox: is it just vt_handoff that breaks things?
<xnox> cyphermox, cjwatson, pitti: i think amd64 mini.iso is borked, installing using that media and just doing a bog standard install of nothing (i.e. just minimal utils et.al.) ends up with "quiet splash vt_handoff=7" instead of ending up like the server.iso with "ro"
<xnox> cyphermox, net effect one ends up booting on tty7, with nothing, and no idea what's going on.... unless one like switches to tty1.
<cyphermox> ok
<xnox> not a biggie, but is annoying and confusing to the remote-hands people.
<xnox> aka local users.
<xnox> however, that doesn't explain my s390x troubles =)
<cyphermox> sure, but I see removing splash would get you no vt handoff
<xnox> yeah. it feels to me that somewhere rather "quiet splash" is default, and we toggle that off in server.iso. Where imho, it should be "" by default, and toggled on in the desktop.iso. And/or installer somehow checking "aha" you chose to install a "desktopy" metapackage you probably want "quiet splash".
<xnox> cyphermox, no spalsh, no vt-handoff, i would then endup on tty1, where getty is spawned at the end of boot and live is wonderful.
<xnox> so that's a separate bug, and not the bug i was looking for though however!
 * xnox ponders if on s390x we end up on wrong serial console, or not enough gettys on all serial consoles etc.
<xnox> jamespage, could you try http://paste.ubuntu.com/15187794/ ?
<xnox> that still works for me on xenial, and should work in b-o-m
<cyphermox> xnox: well, the only issue you mentioned was the handoff ;)
<xnox> cyphermox, touche =)
<tych0> this is going to sound like a crazy question, but did something change in the way the gcc in xenial is computing include paths? i have a project that on older xenial gcc's was compiling, but now it isn't.
<stgraber> pitti: yep, I will. Sorry about that, I forgot to update that part when moving from postinst to preinst and my test was in a clean VM so not an upgrade...
<LocutusOfBorg> doko, insighttoolkit4 is ICE on amd64, do you have any clue/workaround?
<LocutusOfBorg> I don't have access to ubuntu porterboxes
<doko> LocutusOfBorg, read the build log please, x86_64-linux-gnu-g++: internal compiler error: Killed (program cc1plus)
<LocutusOfBorg> sorry isn't Internal Compiler Error called "ICE"?
<doko> no, not "Killed"
<LocutusOfBorg> ah ok, and what does it mean? I retried the build and it failed again
<LocutusOfBorg> lower the parallel build number?
<doko> yes, just build with two
<LocutusOfBorg> sad thanks
<doko> well, wait until the other builds finish, and then enable that only on those archs that need it
<LocutusOfBorg> nacc, I'm going to steal your gdcm merge :)
<nacc> LocutusOfBorg: heh, thanks!
<nacc> LocutusOfBorg: can you add it to the bug, too? LP: #1546823
<ubottu> Launchpad bug 1546823 in swig (Ubuntu) "swig: disable PHP bindings until PHP7 support exists" [Wishlist,Fix released] https://launchpad.net/bugs/1546823
<LocutusOfBorg> oops too late, I dropped the bug reference in the merge
<LocutusOfBorg> do you want me to have a new upload?
<nacc> LocutusOfBorg: no, it's ok, I think -- i'll put it in manually
<nacc> it's mostly for my own tracking so when i do get swig fixed, i know what all to go back and fix up :)
<LocutusOfBorg> nacc, isn't this a debian issue too?
<LocutusOfBorg> I'm wondering why you are not doing this work there and sync it
<nacc> LocutusOfBorg: it will be when they move to only php7.0
<nacc> LocutusOfBorg: because we're dropping php5 in xenial
<LocutusOfBorg> *only* php7? wow
<LocutusOfBorg> huge move
<nacc> LocutusOfBorg: so had to get stuff in before FF
<nacc> LocutusOfBorg: yeah
<LocutusOfBorg> yes sure :D
<LocutusOfBorg> I'll try to remember it on the next merge
<xnox> jamespage, uploaded fixed up qemu, hopefully when that builds, freeze is lifted (if tangled up) and it migrates and b-o-m picks it up.... it will just work (tm) =)
<nacc> LocutusOfBorg: the plan is to send it all to Debian once I've got all the builds kicked off and hopefully php5 out :)
<jamespage> xnox, looked ok to me as well
<jamespage> xnox, b-o-m picks from proposed so that's good
<xnox> jamespage, cool! =)
<LocutusOfBorg> btw nacc there is a new php7.0 upload in debian (two actually) :)
<LocutusOfBorg> s/is/are
 * Laney remembers his PHP days
<Laney> happy times
<nacc> LocutusOfBorg: yes, sync for 7.0.3-7 is requested already, but i was told 7.0.3-9 is preferred, possibly (by debian maintainer)
<nacc> doko: --^
<nacc> doko: will send a new debdiff
<LocutusOfBorg> I see -7 in proposed, this is why I wondered about the last -8 and -9
<xnox> doko, i giggle at your changelogs =) i always new there are multiple doko's working in ubuntu and debian. The only way to explain an NMU from doko to doko's package. I hope doko doesn't disagree with doko on that one =) https://launchpad.net/ubuntu/+source/twisted/+changelog
<LocutusOfBorg> I would put both doko@d.o and doko@u.c in the uploaders field :)
<doko> xnox, it's a twisted package
 * xnox har har har
<bdmurray> seb128: Could you have a look at bug 1545517?
<ubottu> bug 1545517 in popularity-contest (Ubuntu) "xenial popularity-client regards successful popcon.ubuntu.com submissions as failures" [Undecided,New] https://launchpad.net/bugs/1545517
<stgraber> who's maintaining indicator-datetime nowadays?
<stgraber> it looks like it's the reason why I still have systemd-shim installed on my machine here despite it running systemd
<stgraber> any chance it could be changed to depend on "systemd | systemd-shim" instead?
<stgraber> Laney: any idea who's maintaining this? I could just upload to the archive but I seem to remember folks not being very happy about me doing that last time I did :)
<Laney> stgraber: umm charles and/or ted probably
<Laney> I'd do a merge proposal and then zap them a link to it
<stgraber> they don't seem to have a 16.04 branch...
<Laney> looks like lp:indicator-datetime is it
<Laney> despite the series
<stgraber> yeah
<stgraber> context is I'm trying to get rid of cgmanager on default installs
<mjeanson> doko: any chance you could upload new versions of gcc-4.8-*-cross in trusty to rebuild against the SRUed gcc-4.8-sources?
<cyphermox> cjwatson: is there a way to tell germinate to ignore recommends for just one package in a seed?
<stgraber> tedg: https://code.launchpad.net/~stgraber/indicator-datetime/fix-deps/+merge/287068
<stgraber> Laney: ^
<tedg> stgraber: Cool, that's actually charles' now, but he's out today.
<Laney> stgraber: systemd-services is a thing Provided by systemd
<Laney> I guess you can delete that one too
<infinity> cyphermox: No.  Fix the package to stop recommending the thing you don't want?
<cyphermox> infinity: yeah, that's what I'm looking at
<doko> mjeanson, please could you file a bug report, and validate the SRU once it is built?
<cjwatson> cyphermox: The reason germinate won't support this is that it would become impossible for its behaviour to be consistent with that of apt if it did
<stgraber> Laney: so I'm not entirely sure what to do with systemd-services. It appears to only be provided by systemd in the archive right now but I thought that phone people were still using upstart so I'm not sure how that works at all.
<cyphermox> cjwatson: oh, indeed
<stgraber> Laney: I guess I'll turn that into "systemd | systemd-services" in case they have something in the crazy phone archive thing that provides it somehow for a non-systemd system
<Laney> stgraber: I thought that's what -shim was TBH
<stgraber> Laney: me too but it's not providing it :)
<Laney> I mean that "systemd | systemd-shim" is probably alright :P
<stgraber> yeah, just that one should do, lets drop the systemd-services thing entirely then
<Laney> at least I hope that they seed -shim
<jamespage> infinity, is there any type of policy on automatically using a binary that requires more than Ubuntu's baseline feature set?
<jamespage>  I'd like to auto-enable the dpdk binary for ovs now that dpdk is in main which would require the ssse2 cpu flag - fairly easy todo when configuring the alternatives
<infinity> jamespage: Define auto-enable.  You mean you want all x86 installations to use it, regardless of their baseline ISA?
<jamespage> infinity, no
<infinity> jamespage: Could you perhaps ship both versions, and use a wrapper to call one or the other based on cpuinfo?
<jamespage> the package contains two binaries for ovs-vswitchd - one vanilla which works with the baseline ISA
<jamespage> and one which requires ssse3
<jamespage> I'd like to use the ssse3 enabled binary on installs that can support that
<cjwatson> (obligatory whine about why have people not heard of perfectly good hwcap/ifunc mechanisms)
<jamespage> infinity, https://git.launchpad.net/~james-page/ubuntu/+source/openvswitch/tree/debian/openvswitch-switch.postinst
<infinity> jamespage: Don't do it in postinst.
<jamespage> cjwatson, pointer? I'd like to read more
<infinity> jamespage: That means that preimaged installs (for instance) wouldn't DTRT.
<jamespage> infinity, hmm - yeah
<jamespage> ok that does make sense
 * jamespage thinks
<infinity> jamespage: Make /usr/bin/foo a wrapper that checks for the flag and then execs /usr/lib/foo{-variant} as appropriate.
<nacc> jamespage: `man getauxval`, iirc
<nacc> jamespage: that's for C, and hwcap, at least
<doko> barry, the pip mess migrated \o/
<infinity> (And, yes, if this is something you can do in a single build with hwcap, that would be cleaner, and upstreamable)
<barry> doko: \o/
<teward> is the wiki down for anyone else...?  (Can't get to the Freeze Exception page to find out what i'm missing in an FFE request bug)
<teward> (sorry to interrupt)
<barry> doko: MIR filled
<cjwatson> jamespage: hwcap works by putting most of it in a library, installing to special library directories, and letting the linker auto-resolve whichever path is best
<jamespage> cjwatson, can that apply to binaries as well?
<infinity> jamespage: No.
<infinity> hwcap is for libraries only.
<jamespage> okies
<jamespage> I understand the current challenge to be with dpdk headers - but I'll recheck that
<cjwatson> jamespage: ifunc is I think reasonably googleable; that would be usable in binaries without needing to split out libraries, probably as long as it isn't too ridiculous a number of functions that need variants
<infinity> ifunc is decidedly more complex, and lets you create stub functions that are pointers to variants of the real function, based on arbitrary conditions (like hwcaps), but that's a lot of work to rewrite something to do that.
<infinity> It's work I wish upstream would have done, but not work I'd expect a downstream to do for them.
<cjwatson> https://gcc.gnu.org/onlinedocs/gcc-5.3.0/gcc/Function-Attributes.html documents ifunc
<cjwatson> I agree that neither is great as a downstream, that's why it was a whine rather than "you have to do this"
<infinity> jamespage: Anyhow, for now, I think a 5-line (ish) shell script that execs the right binary would be fine.
<hallyn> huh, wiki down?
<jamespage> infinity, ack - I'll work that through tomorrow
<mjeanson> doko: sure, here you go #1549421
<teward> hallyn: i just asked if it's down for anyone else - is it showing down for you?
<teward> (shows me a 500 error)
<jamespage> thanks for the feedback - cjwatson- thanks for the pointers - I'd like to look at the for dpdk and erasurecoding stuff next cycle...
<doko> mjeanson, thanks, will look at this this week
<mjeanson> doko: thanks, I'll test the packages when they hit proposed
<hallyn> teward: nope down for me :(
<teward> hallyn: sounds like Canonical IS should be notified
<cjwatson> https://wiki.ubuntu.com/FreezeExceptionProcess e.g. loads for me
<infinity> jamespage: Speaking of dpdk, are we going to be pulling ARM patches and turning it on there too?
<infinity> jamespage: Or has no one looked at that yet?
<hallyn> cjwatson: hm, me too.  yet https://wiki.ubuntu.com/SergeHallyn does not
<teward> cjwatson: mmm... still a 500 for me.
<teward> getting "Connectoin Refused" actually now
<teward> "connection to 91.189.89.111 failed"
<cjwatson> I know that bits of prodstack were just being rebooted, so maybe just wait a little bit
<teward> ok
<smoser> horay, cloud image today has no python2 at all. not even libpython. http://cloud-images.ubuntu.com/daily/server/xenial/20160223.1/xenial-server-cloudimg-amd64.manifest
<cjwatson> well done
<nacc> Pharaoh_Atem: ping
<Odd_Bloke> smoser: \o/
<Pharaoh_Atem> nacc: pong
<Pharaoh_Atem> nacc: what's up?
<nneul> I'm trying to figure out how/what in the apache2* packages is causing the population of /etc/rc*d - I can't find any reference to update-rc.d or similar that is populating the files/scripts. Am I missing something obvious?
<nacc> Pharaoh_Atem: i think i figured out the twig issue, or why it's happening -- utf8 invalid character encoding coming back
<Pharaoh_Atem> ah
<sarnold> nneul: insserv perhaps?
<Pharaoh_Atem> nacc: well, funnily enough, I'm not getting that error locally
<Pharaoh_Atem> I'm getting a different one
<Pharaoh_Atem> but I think it's because I'm running an older build of the package
<infinity> (base)adconrad@nosferatu:/var/lib/dpkg/info$ grep update apache*
<infinity> apache2.postinst:		update-rc.d apache2 defaults 91 09 >/dev/null
<infinity> apache2.postrm:	update-rc.d apache2 remove >/dev/null
<infinity> nneul: Looks there to me.
<nneul> where is that in the actual source of the package - unless I'm grabbing the wrong files - I'm totally missing it.
<infinity> nneul: dh_installinit would be adding it, probably.
<nneul> That's it! Thank you!
<nneul> btw, I find your handle most amusing, I'm connecting from a machine named infinity. ;)
<nacc> Pharaoh_Atem: what are you seeing? segfaults?
<Pharaoh_Atem> nacc: segfaults, but a different kind of error
<Pharaoh_Atem> nacc: http://fpaste.org/328674/45634226/
<Pharaoh_Atem> however, what's even MORE interesting, is that I also tested against Remi's php70 SCL on CentOS 7 and I get no segfaults
<Pharaoh_Atem> but I get two valid failures
<Pharaoh_Atem> nacc: http://fpaste.org/328676/45634237/
<Pharaoh_Atem> I think the root issue is the same
<Pharaoh_Atem> but I get different failures in different systems
<nacc> Pharaoh_Atem: segfaults were fixed in 7.0.3-7, i think
<nacc> possibly 7.0.3-6
<Pharaoh_Atem> okay
<Pharaoh_Atem> I'll rerun it
<nacc> yep that error is exactly what we get now with 7.0.3-9 (and 7.0.3-7)
<nacc> but you're saying centos sees it too
<Pharaoh_Atem> yes
<nacc> that's a good sign :)
<Pharaoh_Atem> I like eliminating variables
<Pharaoh_Atem> though I'm a Systems Engineer now, I started as a QA Automation Engineer
<Pharaoh_Atem> so QA is still ingrained in me :)
<nacc> I *think* it might be a bug in php7.0 -- that it's asserting the character is invalid when it's not, but i've not started down that path yet
<Pharaoh_Atem> yeah
<Pharaoh_Atem> I wanted to confirm my findings with Remi, but I got sidetracked last night because of the build issues I kept having
<Pharaoh_Atem> I killed several of my private builders in attempting to build php7
<nacc> heh
<Pharaoh_Atem> apparently, a build that can take more than 40 minutes isn't a good thing :/
<Pharaoh_Atem> I moved it to build.opensuse.org and it was able to handle it
<Pharaoh_Atem> one of my private OBS instances was able to build it, but it took FOUR HOURS
<nacc> on my laptop, it takes about an hour, the newer versions are supposed to be faster, but i've not noticed much of a diff
<Pharaoh_Atem> in comparison, the php70 RPM doesn't take anywhere near as long
<nacc> Pharaoh_Atem: heh, ondrej suggested installing php-mbstring, which resulte in segfaults :)
<Pharaoh_Atem> haha
<Pharaoh_Atem> yep, I don't have it installed
<Pharaoh_Atem> installing it on my CentOS box
<nacc> the same segfaults i was getting before, i think ... interesting
<Pharaoh_Atem> nacc: yep, segfaulted
<Pharaoh_Atem> I'm able to reproduce the issue after installing the php-mbstring package on CentOS, as well
<nacc> Pharaoh_Atem: do you know where I should expect to find the php7.0-dbg package now (after http://anonscm.debian.org/cgit/pkg-php/php.git/commit/?h=master-7.0&id=4af02aad4a772363e21ff5cb4dba618aa37162c8)?
<Pharaoh_Atem> nacc: they're using more black magic stuff now
<Pharaoh_Atem> it should be autogenerated
<nacc> hrm
<Pharaoh_Atem> https://wiki.debian.org/AutomaticDebugPackages
<Pharaoh_Atem> nacc: now, if only Debian would adopt sdebs (source debs)
<Pharaoh_Atem> it's one of the things I like about debbuild
<nacc> Pharaoh_Atem: heh
<nacc> Pharaoh_Atem: does that len look off to you? :) http://pastebin.ubuntu.com/15190497/
<Pharaoh_Atem> O.O
<Pharaoh_Atem> wtf
<Pharaoh_Atem> that looks... off
<seb128> bdmurray, k, I don't have much clue about the ubuntu popcon server, I don't think that's well maintained and I'm unsure it's useful in any way, but yeah we should at least make the client and the server not be incompatible
<nacc> Pharaoh_Atem: weird... it's this line:
<nacc> ZVAL_STRINGL(&tmp, last_match, &subject[offsets[0]]-last_match);
<bdmurray> seb128: it looks like it got lost in the merge
<nacc> Pharaoh_Atem: http://paste.ubuntu.com/15190567/
<bdmurray> see also bug 1545515
<ubottu> bug 1545515 in popularity-contest (Ubuntu) "xenial popularity-client submits compressed reports" [Undecided,New] https://launchpad.net/bugs/1545515
<seb128> bdmurray, thanks
<Pharaoh_Atem> ah
<seb128> pjdc, do you know who is maintaining the popcon server and if there is any chance it could be updated to modern standards?
<seb128> like handling compressed reports
<nacc> Pharaoh_Atem: does that look backwards to you?
<nacc> Pharaoh_Atem: hrm, it's the same (roughly) in php5
<Pharaoh_Atem> nacc: it looks odd to me, but then again, the source code for php is a bit inscrutable
<nacc> Pharaoh_Atem: i filed https://bugs.php.net/bug.php?id=71659
<Pharaoh_Atem> nacc: how do you register to file bugs on php.net?
<Pharaoh_Atem> oh, I see
<Pharaoh_Atem> you do it when you file a bug
<Pharaoh_Atem> :/
<nacc> Pharaoh_Atem: yeah it's weird
<stefanct> gcc-hppa64-linux-gnu is broken on xenial
<stefanct> (well, the gcc-hppa64-linux-gnu package installed on 15.10 is broken while other similar cross compilers work fine)
<stefanct> http://dpaste.com/3ABHJZA
<doko> stefanct, there is no 64bit runtime
<stefanct> right. there is no libc6-dev-hppa-cross
<stefanct> that makes the whole thing rather useless, no? :)
<stefanct> i also noticed that gcc-5-alpha-linux-gnu did not made it into 16.04 (yet). are there any plans to get the cross compilers in completely?
<doko> stefanct, it's used to build the kernel
<doko> stefanct, please send in patches
<stefanct> in this case apparently all that is needed is syncing/adding the mentioned package from debian?
<doko> stefanct, please send in *tested* patches
<nacc> slangasek: doko: fwiw, debian's php-imagick is also failing and i noticed in my own sbuild, i specifically had to tell imagemagick to not use multiple threads (or you'd get segfaults -- a known imagemagick issue, afaict)
#ubuntu-devel 2016-02-25
<nacc> slangasek: doko: php-rrd failure is an obvious thinko in debian ... bug filed
<nacc> Pharaoh_Atem: can you look at the php7.0 failures on armhf and s390x? (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
<nacc> slangasek: doko: i think i can fix imagick, it looks to be another relatively obvious issue with debian's package, will work on it tmrw
<nacc> but i think most of the php7.0 excuses are now covered
<cpaelzer> good morning
<pitti> Good morning
<dholbach> good morning
<LocutusOfBorg> good morning!
<pitti> stgraber: oh, looking forward to learn what the replacement of lxc-clone/ephemeral will be :)
<darkxst> dholbach, did it occur to you that its beta1 release eve, how was I going to pilot! anyway I moved it to next week ;)
<dholbach> darkxst, I'm just putting together a rough schedule as a reminder
<dholbach> if I took into account all local holidays, freeze dates and everything else, it'd take me weeks to put together :-)
<dholbach> thanks for moving to another day
<darkxst> dholbach, ha, yeh, didnt think of it like that ;)
<darkxst> anyway no problem
<darkxst> its been a bumpy beta1 ;(
<dholbach> luckily there's still some time to fix bugs
<darkxst> yes
 * darkxst waiting on upload to migrate so I can re-spin images and hopefully fix 4 or so bugs
<pitti> slangasek, infinity, doko, Laney: please be aware of http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/579
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html is updated for that now
<pitti> slangasek, infinity, doko, Laney: TL/DR: hinted regressions are now shown in yellow as "Ignored failure", so all red "Regressions" are "real"
<Laney> pitti: nice
<pitti> makes the output much easier to read, no more searching for the "ignored failure foo" 20 lines below
<pitti> and makes retry-autopkgtest-regressions more useful
<pitti> as it won't retry the known-failing ones
<pitti> and e. g. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-numpy is much easier to read now
<infinity> pitti: Nice.
<StevenK>  /wii pitti
<StevenK> Ah
<doko> LocutusOfBorg, ping on llvm3.8 rc3?
<LocutusOfBorg> ping sylvestre, I never packaged a new upstream release
<LocutusOfBorg> I already pinged him about llvm-3.7
<FourDollars> cyphermox: cjwatson: pitti: dholbach: mdeslaur: I would like to apply to become a MOTU. Could you help to endorse me on https://wiki.ubuntu.com/ShihYuanLee/MOTUApplication? Thx.
<dholbach> FourDollars, sure, adding it to my TODO list :)
<FourDollars> dholbach: Thx a lot.
<LocutusOfBorg> https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=email&sponsoree=fourdollars%40gmail.com&sponsoree_search=email
<LocutusOfBorg> https://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Shih-Yuan+Lee&sponsoree_search=name
<LocutusOfBorg> FourDollars, ^^^ maybe you want to add them to the wiki page
<LocutusOfBorg> so your sponsor knows what they sponsored to you :)
<FourDollars> LocutusOfBorg: I leave http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi?render=html&sponsor=&sponsor_search=name&sponsoree=Shih-Yuan+Lee*&sponsoree_search=name on the wiki.
<FourDollars> LocutusOfBorg: Please also check Ubuntu Sponsorship Miner <-
<FourDollars> LocutusOfBorg: Maybe I should raise it up. Thx.
<LocutusOfBorg> oh... I found it
<LocutusOfBorg> sorry then :)
<FourDollars> LocutusOfBorg: np. I should put it in the first line so people can easily find it.
<LocutusOfBorg> I didn't change the link in my MOTU application
<LocutusOfBorg> https://wiki.ubuntu.com/GianfrancoCostamagna/MOTUApplication
<LocutusOfBorg> so it was "searchable" with find tool
<LocutusOfBorg> :)
<FourDollars> I see.
<FourDollars> Let me refine my wiki page.
<jamespage> infinity, changed my mind on using the dpdk binary by default as it also requires hugepages to be configured otherwise it borks
<jamespage> cpaelzer, hey - are you working on the underlinking issue in dpdk?
<cpaelzer> jamespage: yes
<cpaelzer> jamespage: I have this one fixed along with a few others, there are some itches left
<jamespage> cpaelzer, awesome! I've uploaded ovs with dpdk enabled and requested that ovs-dpdk be removed from the archive
<cpaelzer> jamespage: if things go well I'll prepare an upload for review today - if not I hope tomorrow
<cpaelzer> jamespage: I've seen the bug updates seeing dpdk pulled into main by that - huge thanks for that
 * cpaelzer hugs jamespage
<jamespage> cpaelzer, no problem - thanks for the dpdk work
<jamespage> cpaelzer, I decided not to enable by default based on cpu features...
<cpaelzer> jamespage: the underlinking itself will be fixed for sure, it is just not certain yet how much more I can fix in this one upload
<cpaelzer> jamespage: so is it !default in general (because we are afraid of regressions) or is it "default = sse3 ? openvswitch-dpdk : openvswitch"
<jamespage> cpaelzer, no - you just install openvswitch-switch and then switch between versions using alternatives
<jamespage> so no extra package
<jamespage> cpaelzer, its really ssse3 + hugepages configured correctly
<jamespage> I guess we could do that but I'd rather make it a little more explicit for now
<cpaelzer> jamespage: I clearly prefer not being the default as long as it needs to mature so much IMHO
<jamespage> cpaelzer, agreed
<jamespage> cpaelzer, https://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/openvswitch
<jamespage> I've updated the Vcs fields in the repo - they will go with the next upload
<cpaelzer> jamespage: cool, I did the same for DPDK already which will be in the next upload as well (VCS)
<cpaelzer> jamespage: btw the underlinking and other changes should (tm) not change anything for you or did you address the "static" linking in openvswitch-dpdk already?
<jamespage> cpaelzer, I did for xenstore and pcap - but I hit a dl one when backporting atm
<jamespage> (that's on 14.04 only)
<cpaelzer> jamespage: ok we can try that with the new version then as soon as I'm done with it
<jamespage> cpaelzer, ok
<rbasak> doko: I'm going to drop the symbols file delta you added to libecap so it's just a sync. You hadn't sent that to Debian, and based on https://launchpad.net/ubuntu/+source/libecap/0.2.0-1ubuntu5 it looks like we're just ignoring any disappearing symbols anyway. Any objection?
<rbasak> Also libecap is only used by squid. It's barely a shared library.
<doko> rbasak, don't do that
<rbasak> doko: OK, well can you merge libecap then please?
<doko> rbasak, symbols files are a requirement for MIRs
<rbasak> A symbols file that is useful, or a symbols file that is present only to meet the wording of a MIR and actually serves no purpose?
<doko> rbasak, it belongs to the server team, so it's your task
<doko> rbasak, why?
<rbasak> It's only used by squid, so is barely a shared library at all. It might as well be static.
<rbasak> And, when symbols disappeared, all we did was ignore them. The symbols file caught it, it FTBFS, and we update the symbols file to match.
<rbasak> So what's the point?
<hrw> hello
<doko> and you mean just because you update squid every two years, it's not necessary?
<hrw> can someone remove linux-chromebook from archive for me?
<hrw> I am still listed as maintainer when no one is using this package and I do not even have hardware for it.
<cjwatson> hrw: Could you file a bug against it with an explanation, and subscribe ubuntu-archive?
<rbasak> I mean that the symbols file appears to be to be providing no benefit or protection, so is busywork for the sake of it and is pointless to do.
<cjwatson> Gives us an audit trail
<hrw> cjwatson: thanks, will do
<rbasak> doko: if you disagree, then please explain how the symbols file could be useful in this case.
<cjwatson> apw: ^- do you agree with hrw's request above, since you uploaded it yesterday?
<doko> rbasak, it will remind you when a soname bump is needed, or a package rename is needed if upstream dops symbols without changing the soname
<doko> and I probably didn't forward the patch to debian, because it was outdated
<doko> debian had the new version for a long time
<rbasak> doko: except that upstream dropped symbols without changing the soname, and we just updated the symbols file to match. See https://launchpad.net/ubuntu/+source/libecap/0.2.0-1ubuntu5. I know I did it in that case, but since that was the outcome, the symbols file didn't help us there.
<apw> cjwatson, linux-chromebook, if you want it gone that makes my life easier -- i was simply trying to fix the module-init-tools deps i do not care about the package
<hrw> cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux-chromebook/+bug/1549782
<ubottu> Launchpad bug 1549782 in linux-chromebook (Ubuntu) "Please remove it from archive" [Undecided,New]
<doko> rbasak, so the savings is just for you, because you don't care to rename the package for these cases?
<rbasak> doko: as I said, it is only squid that uses it.
<hrw> apw: as the only maintainer of it I would love to see it gone ;d
<rbasak> doko: and we don't know what the formal ABI is, anyway.
<apw> hrw, works for me, it is anchient
<doko> sorry, I don't get it why we have this discussion. no, you can't know if external software uses it
<hrw> apw: it was when got added but at that time it was acceptable solution
<rbasak> Which is fine, but what am I supposed to do when the symbols file flags an ABI difference?
<rbasak> Everyone else seems to just change the symbols file.
<rbasak> doko: because you don't care> and you didn't care to send the change to Debian, so what's the difference?
<rbasak> doko: I'm just going to sync this, as I want to make progress and I don't see the downside. I'll take input from others if anyone else wants to chime in.
<doko> rbasak, you're wrong. I couldn't send anything to debian, because the versions didn't match
<rbasak> doko: unless you want to take the merge?
<cjwatson> hrw: subscribe, not assign :)  (fixing)
<hrw> cjwatson: long time since I used launchpad ;D
<doko> rbasak, that's blackmailing
<rbasak> doko: and you're just creating work for me with no justification.
<rbasak> (I would really like someone else to chime in here, please)
<rbasak> I'm happy to accept it if I'm wrong, but I would like someone to actually consider what I'm saying. I don't feel that you are.
<rbasak> Look at the history of libecap uploads in Ubuntu.
<rbasak> I have a symbols file here ready to go if needed, but given the previous history, I expect it to immediately FTBFS on other architectures and create more work to fix it.
<cjwatson> hrw: done
<hrw> cjwatson: thanks a lot
<hrw> apw: thanks for reminding me (by upload) that this package still exists
<apw> hrw, heh you are very welcome :)
<pitti> doko, rbasak: IMHO, that changing of symbols files is merely the symptom -- the real cause is upstream not maintaining a stable ABI or properly maintaining their soname
<pitti> doko, rbasak: so the only two sane options that I see are to either beat some sense into upstream for proper versioning, or drop the shlib and provide a -dev package with a static lib only
<hrw> bye
<rbasak> pitti: sure, I understand that. I think I'm saying that "maintaining" a symbols file in an Ubuntu delta is pointless.
<pitti> if it's just one consumer, then there's little point to even pretend that it woudl be a generally usable library
<pitti> rbasak: it's not
<pitti> rbasak: if you build a shared library, you make a commitment and a promise
<pitti> and if you don't want to keep that, don't build a shared library
<rbasak> pitti: sure. Sorry, I mean in this specific case, not the general case.
<rbasak> pitti: I mean "maintaining", not maintaining. We're just paying lip service if in reality we just update the symbols file every time symbols change.
<pitti> rbasak: exactly my point :)
<rbasak> That's what I'm saying is pointless. Given that we're doing this, why maintain the symbols file at all?
<rbasak> I'll accept that not shipping a shared library the right answer, but unfortunately we're just downstream of Debian here.
<pitti> it's not pointless, it's pointing you towards the real error: your library broke ABI
<pitti> well, then file an RC bug against Debian and let it get auto-removed, or something
<rbasak> I think the answer is: 1) stop creating extra work for ourselves, since that makes less time available to fix it properly; and 2) explain upstream and ask them nicely to fix it properly.
<pitti> changing ABI without soname bump for sure is an RC bug, as it will cause squid to crash on partial updates, unless they manually craft their dependencies
<doko> rbasak, pitti: In the of a static lib, you have to communicate to the security team, that thy need to update squid together with libecap. static libs come for a price as well. maybe you save some work, but you increase the work for others
<pitti> but that's what a static library is for then
<pitti> doko: *nod*
<rbasak> pitti: incidentally the ABI change was historical and in libecap2. They've had a soname bump now.
<rbasak> So I can't really file an RC bump now, seeing as they have bumped the soname.
<rbasak> An RC bug that is.
<pitti> rbasak: ah, if they did, what's the problem then?
<pitti> on a soname bump it's totally legitimate to update the symbols files
<rbasak> pitti: I feel that I'm recreating the symbols file again for no real reason.
<rbasak> pitti: given the history of symbols files being arbitrarily changed.
<pitti> well, changing symbols files without soname bump -> don't do that
<pitti> changign symbosl files with a soname bump -> normal operation
<rbasak> pitti: in fact I'd go a bit further and say that in general having a symbols file in an Ubuntu delta to meet MIR requirements is a bit pointless too for this reason. A stable ABI is for upstreams to maintain; we can't maintain that in an Ubuntu delta.
<pitti> well, I disagree
<rbasak> (like you said, it'a a symptom)
<rbasak> If there is no symbols file, then that suggests that there isn't a stable ABI, and _that_ is the problem, not the lack of the symbols file.
<pitti> if we have a package in main and want that to work properly, then things like symbols files are a great help to avoid breaking stuff
<pitti> and an FTBFS due to symbols mismatch is infinitely better than having to scrape off apport crash reports after the fact
<doko> rbasak, symbols files are part of the packaging, not about upstream
<doko> some upstreams have symbol versioning
<pitti> and if it's FTBFS due to a symbols mismatch, the consequence is *not* to just adjust the symbols file :)
<doko> introducing tens of diffs dropping php swig support, and discussing a symbols file for 20min ...
<rbasak> The problem with that is that without knowing the actual public ABI (as opposed to a list of symbols), we don't know whether the public ABI inadvertently changed or not.
<doko> rbasak, sure, we should just drop all symbols files for that reason
<pitti> well, *shrug*, you asked for another opinion, I gave it, not going to repeat it as that would just annoy you more :)
<rbasak> pitti: I appreciate your opinion, thanks. Based on that I'll just add the symbols file and adjust for other archs if needed I guess.
<rbasak> And I'll bring this up again if/when we get an FTBFS similar to the libecap2 ones.
<pitti> rbasak: just to avoid doubt, that was for a soname bump, right?
<rbasak> pitti: yes, libecap2->3
<pitti> rbasak: and it's totally useful to send that to debian
<rbasak> doko mentioned that he couldn't before due to some mismatch. How would I check for this?
<pitti> arch specific symbols files are very rare for C; they are unfortunately the norm for C++, if it uses that
<pitti> if you send the delta right after mering, that should by definition be current
<pitti> merging, even
<doko> rbasak, wrong. I said that we had an older libecap in the archive
<rbasak> Ah, OK, thanks.
<rbasak> http://paste.ubuntu.com/15196806/ is what I have right now.
<pitti> ah, C++
<rbasak> I used 1.0.1-2~ since -1 was prior to the gcc 5 transition
<rbasak> So presumably the symbols were different then.
<pitti> it often (but not always) works to demangle them, then one can often avoid the per-arch symbols files; but I don'thave too much experience with those
<rbasak> Does that make sense for Debian? Or would that be wrong for them since they published libecap3 before the GCC transition also?
<pitti> rbasak: Debian might need to adjust it then, but Debian has current g++ 5 now, so either way they need the current version of teh symbols
<pitti> (they might need to rename it libcap3v5 then if the new g++ changed the ABI)
<rbasak> OK, thanks.
<pitti> (syncing that should be a no-op for us mostly, so we can do that if we want)
<doko> rbasak, on a first look I don't see anything arch specific. it could be that some symbols are missing on ppc64el due to -O3.
<pitti> these can be marked as (optional) then
<pitti> particularly stuff which is not part of the real ABI, but just leaking from standard libraries
<pitti> yay C++
<doko> rbasak, this might help you, if there are too many architecture differences: http://pkg-kde.alioth.debian.org/symbolfiles.html
<rbasak> doko: you mean I should use those tools? They're not KDE specific? I was looking at sed 's/ \(_.*\) \(.*\)/ (c++)"\1" \2/' libfoo.symbols | c++filt from https://wiki.debian.org/UsingSymbolsFiles
<pitti> c++filt is nice indeed, makes these actually readable and less platform specific
<pitti> :w
<doko> rbasak, it's not KDE specific. you create a symbols file using pkgkde-symbolshelper create, then upload, download all the build logs and update using pkgkde-symbolshelper batchpatch
<rbasak> OK, thanks.
<doko> but the symbolshelper is not aware of the unmangled notation, afaik
<rbasak> I'm finding this quite confusing. Lots of information from different sources rather than a single set of steps to follow. If I just use c++filt for now, will that be OK?
<rbasak> Well apparently not, that just FTBFS.
<doko> sure
<doko> how does it fail?
<rbasak> http://paste.ubuntu.com/15196904/ - I assume I'm doing something quite essential wrong.
<doko> you're using c++ with the mangled names, not the unmangled ones
<doko> at least for the first symbol
<rbasak> The symbols file has unmangled names
<doko> the missing symbol is unmangled
<doko> I mean, mangled
<rbasak> Ah
<rbasak> Yes, that line does exist in my symbols file. Most of the lines are unmangled.
<rbasak> Some seem to remain mangled.
<rbasak> http://paste.ubuntu.com/15196979/
<rbasak> Line 85
<rbasak> That's the only one I see, so perhaps I could just leave that one mangled.
<Laney> run it through c++filt and put that in its place
<rbasak> c++filt seems to leave it unchanged
 * Laney plays the x-files theme
<Laney> so it does
<doko> looks like a bug
<doko> in the demangler
<doko> or mangler
<rbasak> I left that line undemangled, and the build succeeds.
<rbasak> I guess that's OK to upload then? I'll clean up the merge first. Thank you for your help.
<doko> sure
<doko> rbasak, might be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69687
<ubottu> gcc.gnu.org bug 69687 in c++ "Buffer Overflow in libiberty" [Normal,Unconfirmed]
<rbasak> Thanks. I guess it's safe to just work around for now by not demangling that symbol?
<pitti> infinity, Laney: I taught britney about force-badtest hints for a specific arch but all versions now: http://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/1444
<pitti> infinity, Laney: with that we enforce tests on the non-broken arches again, and don't have to constantly bump the versions for those
<pitti> so please use that new syntax from now on
<rbasak> Looks like i386 and powerpc failed. https://launchpadlibrarian.net/242789112/buildlog_ubuntu-xenial-i386.libecap_1.0.1-3ubuntu1_BUILDING.txt.gz
<rbasak> Some extra symbols, some missing symbols.
<rbasak> Should I just mark the missing ones as optional, and forget about the extra ones?
<rbasak> doko: ^
<doko> ahh, 32/64bit differences
<doko> rbasak, is it intended that you build without optimization?
<rbasak> doko: I haven't touched Debian's packaging in this area.
<rbasak> Looks like the packaging just uses trivial CDBS.
<doko> rbasak, I'll have a look, because it's likely that the symbols will change again with optimization
<doko> mvo, does snappy build on powerpc?
<doko> ohh, neither on s390x
<mvo> doko: its fixed on s390x, I will upload the right today
<mvo> doko: powerpc is a gccgo issue, I am not sure I can fix that myself
<pitti> tseliot: hey Alberto, how are you?
<pitti> tseliot: I have two other tiny bits for udev/trusty -- I suppose you want  bug 1536438 SRUed?
<ubottu> bug 1536438 in systemd (Ubuntu Trusty) "Need add uaccess tag for /dev/dri/renderD*" [Undecided,Triaged] https://launchpad.net/bugs/1536438
<pitti> tseliot: would make sense to bundle those three
<tjaalton> doko: do you know of a llvm bug where it doesn't detect avx support on skylake properly? mesa fails llvmpipe tests if built on skylake
<tjaalton> with 3.8
<tjaalton> apparently it has issues detecting what kind of avx support it has
<doko> tjaalton, sorry, no.
<tjaalton> alright
<ahasenack> doko: hi, could you please take a look at https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1549819 ? It has a 6 line reproducer script
<ubottu> Launchpad bug 1549819 in python-apt (Ubuntu) "SIGSEGV when reloading cache after setting architecture" [Undecided,New]
<ahasenack> or point us at the current maintainer?
<ahasenack> doko: a landscape-client unit test started core dumping like that in xenial
 * doko stares at mvo ... 
<doko> ahasenack, could you check if a python-apt rebuild helps? we recently upgraded apt. juliank might want to comment too
<doko> hmm,not rebuilt in Debian
<ahasenack> doko: I'll try that
<ahasenack> doko: also, do you know where I can find the core dump?
<ahasenack> ubuntu@landscape-client-xenial:~$ ./foo.py
<ahasenack> Segmentation fault (core dumped)
<ahasenack> it's nowhere, not in /var/crash or $PWD
<ahasenack> ulimit -c says unlimited
<mvo> ahasenack: what doko said, a rebuild would be nice first, if that does not help I can have a look later
<ahasenack> installing build deps...
<mterry> mvo, looking at the ubuntu-snappy MIR, those golang packages don't have the right naming schemes.  Which means when Debian adds packages for them, we won't be in sync at all
<mvo> mterry: uh, could you please comment in the bug so that I can sort it out?
<tjaalton> doko: it's a mesa bug after all, was fine with 11.1 but 11.2rc breaks
<ahasenack> mvo: it still core dumps after I rebuild and reinstall python-apt
<ahasenack> mvo: it's inside a xenial lxd, if that matters
<juliank> There's a bug somewhere in APT's cache generation
<mvo> ahasenack: interessing, I get http://paste.ubuntu.com/15197818/ when I run your script
<mvo> juliank: can you redproduce the segfault?
<ahasenack> mvo: on a real xenial host, or vm?
<mvo> ahasenack: real systemm
<mvo> system
<juliank> mvo: Have not tried it, but there's still some seg fault in the cache generation not fixed yet, so I'd love to get a complete backtrace
<ahasenack> juliank: I can't find the core dump file
<juliank> We probably missed a stringview that needs to be moved when the cache is moved
<ahasenack> ulimit -c is unlimited, nothing in /var/crash or $PWD
<juliank> Any service for core dumps installed? For example, I use systemd-coredump which stores them into /var/lib/systemd/coredump
<juliank> there can be other handlers
<ahasenack> let me check
<ahasenack> that directory is empty here
<ahasenack> I can remove apport
<juliank> You could also run it in gdb if you have the debugging symbols available.
<ahasenack> it's a python script
<juliank> and how is that problematic?
<ahasenack> still no core dump even with apport removed
<juliank> Anyway, apt-cache gencaches should crash as well if you pass it a config file with -c that contains APT::Architecture "";
<juliank> For mvo, it works correctly.
<juliank> FTR, this is likely http://bugs.debian.org/812251
<ubottu> Debian bug 812251 in apt "apt: suddenly segfaults after "apt update"" [Important,Fixed]
<juliank> Try this reproducer: http://paste.ubuntu.com/15197886/
<juliank> Of course, setting Architecture to an empty string won't work, but it should at least build a cache
<ahasenack> juliank: that crashed here
<juliank> Great
<ahasenack> juliank: I'm trying to find all the dbg packages I need
<juliank> Only interested in libapt-pkg5.0 ddeb
<ahasenack> the bt isn't that great yet
<ahasenack> http://pastebin.ubuntu.com/15197906/
<juliank> I'm not sure where the dbgsym are in the archive, but this one should be it: https://launchpad.net/ubuntu/xenial/amd64/libapt-pkg5.0-dbgsym/1.2.3
<juliank> But that seems like a bad place to crash in
<tseliot> pitti: hi. Yes, I'd like that SRU. Where do I find the other changes?
<ahasenack> juliank: ok, now I have something more
<juliank> Do bt full
<pitti> tseliot: it's bug 1473800 and bug 1535255
<ubottu> bug 1473800 in systemd (Ubuntu Trusty) "restarting logind during systemd update causes screen to lock" [Undecided,Triaged] https://launchpad.net/bugs/1473800
<ubottu> bug 1535255 in systemd (Ubuntu Trusty) "Inconsistency in /usr/share/initramfs-tools/hooks/udev file causes configuration failure" [Undecided,Triaged] https://launchpad.net/bugs/1535255
<pitti> tseliot: but if you want I can upload the SRU for all three, your's is quite simple too
<ahasenack> juliank: http://pastebin.ubuntu.com/15197953/ still a few "optimized out" bits
<tseliot> pitti: yes, please
<pitti> tseliot: ack, will do
<tseliot> pitti: thanks
<stgraber> pitti: lxc-copy
<pitti> stgraber: ah, thanks; I didn't see an announcement yet on the homepage
<juliank> ahasenack: I see. But it just crashes because you specified an invalid empty architecture there, AFAICT.
<ahasenack> well, yes
<juliank> But that's not really problematic.
<pitti> stgraber: OOI, will lxc-clone remain in xenial? I wonder if I need to teach autopkgtest's lxc runner to get along with both, or whether it can just continue to call lxc-clone
<juliank> Who specifies "" as an architecture in real life?
<juliank> You told APT that your system has no architectures.
<stgraber> pitti: we will keep lxc-clone and lxc-start-ephemeral around in Xenial, yes. Removing them now would cause too much breakage I think.
<ahasenack> juliank: it's something that < xenial was ok with we had it as a unit test, and it started failing
<stgraber> pitti: we'll likely get rid of them immediately after y opens though
<juliank> ahasenack: This has to fail. But it should not crash
<pitti> stgraber: thanks for the heads-up
<ahasenack> right
<juliank> It also does not fail on multi-arch systems
<ahasenack> juliank: it seems to crash only on a container, though
<juliank> because they'll have the secondary architectures set from APT::Architectures
<ahasenack> juliank: that tells me something else is going on
<juliank> Read what I wrote
<ahasenack> irc lag, I'm sure you are used to it
<mterry> bdmurray, can you add ~snappy-dev to your package-subscribers list?
<juliank> ahasenack: Should be fixed in a few mins
<juliank> Writing a test case now
<ahasenack> juliank: thx a lot
<ahasenack> I attached your reproducer and the bt full to the bug
<bdmurray> mterry: yep
<seb128> davmor2, cyphermox, those upgrade issues with fontconfig look like the binary is updated before the lib and the cache update fails on missing symbol, updating the libfontconfig shlibs would likely do the trick
<mterry> cheers
<juliank> ahasenack: Fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=9de2fd4
<juliank> There will be a 1.2.4 release shortly
<ahasenack> juliank: \o/
<ahasenack> thx a lot
<davmor2> seb128: nice, thanks
<seb128> davmor2, yw
<juliank> I'm still hoping I can reproduce (1) the other APT crash when building the cache and (2) the messed up index files sometime (part of last line is repeated)
<juliank> Well, (2) might be fixed these days
<juliank> (1) will be easy once there's a backtrace
<cyphermox> seb128: ack
<pitti> xnox: the cloud images are achingly fat, so it's quite a bit of a purge fest to minimize them
<pitti> xnox: the images.linuxcontainers.org are much nicer, only 1/8th the size, faster, and minimal
<pitti> xnox: right now I'm using the lxc "ubuntu" template which is similarly small
<pitti> xnox: but anyway, I do have the purge list, I mostly just didn't get around to setting this up with lxd yet
<xnox> pitti, horum. if they are "fat" we can trim them. I understood they have cloud-init + nested lxd, and that's it.
<pitti> xnox: this morning I accidentally had cloud-init in a container, which completely breaks them :)
<pitti> (although with lxc plain, maybe lxd has some provision for them)
<nacc_> slangasek: so twig is unlikely to build (test) for a bit, as i think it triggers an actual bug in php7.0, which is then going to gate symfony and php-doctrine-bundle. Any recommendations? I've filed the PHP bug, but not sure how quickly it'll get looked at
<pitti> xnox: ah, maybe the s390 ones are smaller? x86 cloud images have apt-xapian-index, cryptsetup, ureadahead, lxc, lxd, lvm2, mdadm, ppp, w3m, vim, and loads of other stuff that doesn't belong into a container
<nacc_> Pharaoh_Atem: ping
<rbasak> smoser: ^
<rbasak> Also kirkland ^
<rbasak> About "fat" cloud images.
<rbasak> This comes up every so often. Either we want them to be slim or we want them to be "comfortable". We cannot have both.
<Odd_Bloke> Doesn't belong in a container, but does belong in an Ubuntu-server-that-works-on-a-cloud image.
<Odd_Bloke> Well, not all of those things, perhaps.
<rbasak> There's also a goal to make the Ubuntu experience the same regardless of whether you're using a VM or a container.
<Odd_Bloke> (Looking at you, ppp)
<rbasak> This comes at the cost of having some stuff that doesn't make sense in a particular environment, but the win is that users don't get surprises switching from mode to another.
<smoser> Odd_Bloke, ppp is gone i think
<Odd_Bloke> Oh, cool.
<smoser> yeah, i dropped hat a while ago.
<smoser> cloud-image and server are now basically the same.
<smoser> http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.xenial/revision/2413
<smoser> we also dropped wireless-tools wpasupplicant and memtest86+.
<smoser> xenial cloud imags smaller than wily
<smoser> thats the first reduction in quite some time.
<pitti> rbasak: well, most container workloads shouldn't/don't have a "human experience"
<smoser> i am absolutely not goign to say there is no fat. but i believe that just about everything in the seed is justifiable.
<pitti> they should be managed completely automatically, and be as dense/efficient as possible
<pitti> indeed, the x86 ones got trimmed recently, thanks for that; some 380 MB to 290 MB
<pitti> but, container images are 65 MB
<rbasak> pitti: I think there are a bunch of different desires that work against each other here. No single answer will suit everyone. A container you describe is certainly useful, but so is a fat one.
<Odd_Bloke> pitti: Definitely; but that isn't what the cloud images are designed to be. :)
<pitti> rbasak: sure, hence the need to have either two images, or a simple way to install the "comfy" bits
<rbasak> pitti: ultimately kirkland has to balance whose things.
<pitti> with a cloud-init option, or "apt-get install ubuntu-server-standard" or so
<rbasak> those things
<rbasak> AIUI, we don't ship the minimal thing you want right now, and I'm not aware of any plans to do so, apart from "core" as it used to be called.
<pitti> with "one size fits it all" you either provide a really bad "interactive"  experience, or you penalize every container/juju workload by shipping tons of unnecessary stuff
<pitti> rbasak: actually we do, I'm quite happy with teh images.linuxcontainers.org images
<rbasak> Is it really a "penalize" though?
<pitti> sure
<Odd_Bloke> The argument for favouring the "comfy" use case is probably that anyone doing serious container stuff will be customising the images anyway.
<pitti> it's 5x the download, HD size, unpack, upgrade size, plus the longer boot time etc.
<rbasak> How expensive is it really?
<rbasak> Right, but how expensive is _that_ really? :)
<pitti> well, how expensive is "5x expensive" -- I'd say "5 times"? :-)
<Odd_Bloke> rbasak: A major selling point for containers is density, so it does make a substantial impact in those terms.
<pitti> (storage space)
<pitti> it's less well defined for dist-upgrade and boot time of course
<smoser> wasted processor use and memory are one thing, and we can and should make packages disabler themselves if they're not in an environment where they'd be used.
<rbasak> It's mostly disk space. That isn't the bottleneck for container density, AIUI.
<pitti> but it's much easier to install a metapackage to an "interactive" cloud workload where/when you actually need it (which should not be the common case)
<rbasak> "5 times" more expensive is nothing if it's $0.00000001 to $0.00000005.
<pitti> than maintaining an ever-growing list of packages to purge, as that's really error prone
<pitti> well, here's the thing:
<rbasak> "maintaining an ever-growing list of packages to purge" is just because your use case isn't currently supported, and what you're doing is a workaround.
<pitti> if you say that 5x the download size isn't a noticeable penalty, what's wrong with enabling the apt-get install of a "comfy" metapackage when you enable it
<pitti> as that'll download the same things, but much less often
<rbasak> The time is a penalty when doing interactive work.
<rbasak> It doesn't matter so much for non-interactive work.
<rbasak> Developer time is what is most expensive.
<pitti> well, as I said, I'm quite happy with the images.linuxcontainers.org images
<pitti> rbasak: developer time> exactly
<pitti> cf. "maintaining an ever-growing purge list"
<pitti> I know how brittle and maintenance-intense it is because I'm doing it
<pitti> I have to do it for x86/ppc64el images anyway, but I don't need to for the arches where I'm currently using LXC/LXD because these already have small images
<pitti> anyway, this just started out as an explanation to xnox why I prefer the lxc images
 * hallyn points rbasak to the cost of bandwidth over satelite :)
<pitti> no doubt the classic "ubuntu server" experience shouldl have vim and stuff installed, as these are more geared towards humans
<Odd_Bloke> hallyn: Ah, yes, the classic cloud use case. ;)
<pitti> but "noninteractive container/VM" and "interactive server" are quite different use cases, and unifying them will always make people unhappy
<Odd_Bloke> I guess it does potentially go through literal clouds...
<hallyn> Odd_Bloke: i rest my case
<rbasak> hallyn: if you're using satellite, you are presumably already caching the images. The one-off hit is still presumably insignificant.
<rbasak> Anyway, I defer to kirkland. I understand there are use cases where "comfortable" is a pain.
<rbasak> pitti: I don't think we're unifying them. We're just not doing the slim one right now.
<pitti> the one package which is the most contentious one is probably cloud-init
<xnox> Odd_Bloke, pitti - it's just lxd images are used as "full cloud images" in e.g. openstack-lxd. And they are also used as minimal bootstrap chroots in like "juju" case or the stuff you do.
<xnox> imho there is room for more minimalistic lxd image.
<hallyn> rbasak: i think the cost is wroth it, i just object to your over-trivialization of the cost :)
<pitti> xnox: lxd images are fairly minimal, mostly debootstrap really
<xnox> pitti, when i say lxd images -> i mean the lxd image we publish at cloud-images.ubuntu.com. not the stgraber image =)
<sergiusens> barry, hey, is a fix for this coming soon http://paste.ubuntu.com/15198707/
<pitti> xnox: ah, let's call them "cloud images" to avoid confusion
<xnox> ack.
<sergiusens> barry, there are many other conflicts that follow the same pattern
<pitti> tseliot: I uploaded systemd to trusty-proposed with all three patches; can you still add an SRU test case to bug 1536438 please?
<ubottu> bug 1536438 in systemd (Ubuntu Trusty) "Need add uaccess tag for /dev/dri/renderD*" [Undecided,In progress] https://launchpad.net/bugs/1536438
<pitti> tseliot: I meant, uploaded to the SRU review queue, of course (~ubuntu-sru still needs to review/process)
<barry> pip 8.0.2-8 should fix those
<rbasak> doko: thank you for the libecap fixes.
<doko> rbasak, I'll forward these once they are visible in the release pocket
<rbasak> doko: appreciated
<tseliot> pitti: sure, I'll do it tomorrow. Thanks
<seb128> bdmurray, arges, sru_team: is there anything blocking the wily libreoffice update to be accepted? it was supposed to be a 0 day SRU at the beginning but seems it's stucked there forever now
<bdmurray> seb128: I don't know but will have a look.
<seb128> bdmurray, thanks
<bdmurray> seb128: it looks like wily had a security update recently :-(
<marlinc> My GRUB broke since the latest updates, not sure why. Getting 'error: sparse file not allowed' while booting. It then jumps into the UEFI menu
<marlinc> The only way get it to boot is to press esc so it goes into the actual GRUB screen instead of trying to boot immediately
<bdmurray> seb128: also fonts-stix is in universe in wily but was added to main for xenial. would that need to change?
<seb128> bdmurray, oh, right, going to need to rebase ... or discard at this point, I'm unsure it's still worth it but I'm just wondering for the record what went wrong and why it's ignored by the SRU team since octobre
<seb128> I guess it would
<jdstrand> bdmurray: hey-- I wouldn't normally mention this since it has only been a couple of days, but the trusty squashfs-tools sru is important for snappy
<jdstrand> and seb128 scared me :)
<bdmurray> jdstrand: are the two in the queue the same?
 * jdstrand looks
<jdstrand> I uploaded one, then deleted it cause I wanted to tweak the changelog
<jdstrand> and uploaded another
<bdmurray> jdstrand: I still see 2 in the queue
<jdstrand> bdmurray: ok, somehow the first didn't get deleted.
<jdstrand> bdmurray: I did just now. if you refresh, you should see only one
<bdmurray> jdstrand: okay
<gpiccoli> cyphermox: ping
<cyphermox> gpiccoli: hey
<gpiccoli> hello! May I pm you?
<cyphermox> sure
<gpiccoli> thanks!
<nacc_> lol, fun to finally figure out that imagemagick in debian/ubuntu backported a fix that was then reverted upstream
<nacc_> slangasek: --^ that will resolve our php-imagick failures, i think
<barry> pitti: still around?
<nacc_> doko: for clearing out the excuses queue, do you want me to subscribe you to the bugs that fix those packages up? or should i just let it go through the normal channels?
<doko> nacc_, both works
<Son_Goku> nacc_: pong?
<nacc_> Son_Goku: hey, two things
<Son_Goku> yes?
<nacc_> Son_Goku: i pinged yesterday if you could look at those failures on non-x86 archs for php7.0?
<nacc_> Son_Goku: and also, if you could help provide a twig testcase for php upstream?
<Son_Goku> nacc_: I donât have access to any non x86 hw
<nacc_> Son_Goku: i'm pretty bogged down with just getting packages turned over
<nacc_> Son_Goku: sure, but can you look at the logs and see if it's something obvious?
<Son_Goku> ah, sure
<nacc_> thanks
<Son_Goku> Iâm unusually bogged down today, though
<Son_Goku> Iâm closing on my house
<nacc_> Son_Goku: oh congrats -- it's fine, i just needed to delegate some of that, as i want to make more progress on the other packages
<Son_Goku> yeah, Iâll take a look at them
<nacc_> Son_Goku: thanks
<nacc_> Son_Goku: the non-x86 arch issue may not be a big deal, as it appears to have always failed there
<Son_Goku> ah
<Son_Goku> well, so itâs a âno changeâ situation
<nacc_> doko: ok, subscribed you to the bugs that should unblock all but php-imagick (and php7.0, but not sure if the latter will go away automatically once the others do -- the two failures are "always failed" currently)
<carldani> Can anyone in here help me with a Feature Freeze Exception request? I have just created my first one and hope I didn't screw up. Any criticism or RTFM pointers are highly appreciated. https://bugs.launchpad.net/ubuntu/+source/flashrom/+bug/1547144
<ubottu> Launchpad bug 1547144 in flashrom (Ubuntu) "[FFe] sync flashrom_0.9.9~rc1+r1942-1 from Debian unstable" [Low,New]
<tumbleweed> carldani: looks reasonable. A full debdiff is always good to include
<sarnold> perhaps a mention of testing of any dependant packages, if any -- if none, a mention of that too
<tumbleweed> and if it's seeded on any release media
<tumbleweed> this has neither, so it's it's a pretty easy FFe candidate
<carldani> tumbleweed: how do I determine whether a package is on release media?
<tumbleweed> carldani: seeded-in-ubuntu (in ubuntu-dev-tools)
<carldani> oooh nice
<tumbleweed> and reverse-depends for reverse-depnedencies :)
<tumbleweed> I'm quite happy to dust off my release-team hat and approve that :)
<carldani> thank you!
<carldani> there's one catch, though
<carldani> I'd rather mention it upfront
<sarnold> it's not done yet? :)
<carldani> flashrom doesn't build on s390, and AFAICS Ubuntu 16.04 will have s390
<tumbleweed> that's not a regression, though
<tumbleweed> https://launchpad.net/ubuntu/+source/flashrom/0.9.7+r1852-1.1
<tumbleweed> if it builds on at least those architectures, you're fine
<carldani> We (flashrom developers) do have S390 support in upstream svn since a few hours, and plan to release 0.9.9 final soon which will have s390 support.
<tumbleweed> all the more reason to do it
<tumbleweed> carldani: oh, if you're looking for things to talk about in FFes. Test coverage is useful, gives us an idea of risk levels
<carldani> arm64 and ppc64el (broken in the old 0.9.7+r1852-1.1) are compiling just fine in the package mentioned in the ffe
<carldani> tumbleweed: thank you! that was quick. wow.
<tumbleweed> you happened to find a not-very-active release team member, with spare cycles, staring at IRC :)
<stefanct> with a very descriptive nick too ;)
<carldani> sarnold: ah yes, and flashrom will probably never be finished... people find flash chips in so many weird locations, flashrom even has a driver for reflashing monitor firmware over i2c over vga
<sarnold> carldani: that's simultaneously cool and scary :)
<carldani> sarnold: indeed.
#ubuntu-devel 2016-02-26
<psusi> I've had a patch atached to bug #1250109 to fix a very long standing annoying problem making upgrades very slow due to the massive number of update-grub invocations since December.  could someone *please* upload it?
<ubottu> bug 1250109 in linux (Ubuntu) "Please use dpkg-triggers" [Wishlist,Triaged] https://launchpad.net/bugs/1250109
<psusi> also I've been trying since about then to get upgraded from contributing developer to core so I could upload things like this myself, and would appreciate your endorsement: https://wiki.ubuntu.com/PhillipSusi/DeveloperApplication2
<sarnold> psusi: does the grub2 debdiff need refreshing?
<psusi> sarnold, apparently there have been a few new uploads since I posted that...
<sarnold> psusi: I figured, the zfs stuff alone probably got a few..
<sarnold> psusi: maybe re-fresh, re-test, re-upload, and re-bug apw :)
<sarnold> it'd sure be nice to have it fixed, that bothers me every time I updae.
<psusi> yea.. I just autoremoved' like 6 kernels
<psusi> and watched the long, slow, update-grub for every one of them
<psusi> I just saw a headline about that on slashdot and still don't get this insane belief that any kernel module is a derived work of the kernel and so zfs can't be licensed under something other than the gpl2
<infinity> psusi: That "insane" belief is held by a lot of free software people and a lot of kernel copyright holders, so the debate is certainly heated.
<psusi> by that logic, every hardware device driver that contains binary blobs in the kernel violates it
<infinity> Yes.
<psusi> and that's basically most of the most important ones
<infinity> Hardly.
<sarnold> which is why there's a linux-firmware package..
<infinity> Unless you mean firmware, which is executed on the device, not the host CPU.
<psusi> putting it in a separate package doesn't change the way the way the licenses effect it
<psusi> doesn't matter where it is executed... if the argument is that the code is combined with the kernel that makes it a derived work and must be under the same license
<infinity> It's widely accepted that the GPL linking clause doesn't attach across CPUs like that.  Not that it makes the firmware free without source (it's not), but the firmware doesn't taint the kernel code, as it's not linked to it in any way.
<psusi> also by that logic, any executable program loaded by the kernel is a derived work and must be gpl2
<infinity> No, that's not how linking works.
<infinity> Reading the GPL helps before arguing for or against it.
<sarnold> psusi: the first few lines of the kernel's COPYING file:
<sarnold>    NOTE! This copyright does *not* cover user programs that use kernel
<sarnold>  services by normal system calls - this is merely considered normal use
<sarnold>  of the kernel, and does *not* fall under the heading of "derived work".
<psusi> "linking" isn't something that is part of copyright law... being in the same address space on the same cpu doesn't make something a derived work
<infinity> psusi: It's not part of copyright law, but it *is* part of the license, ergo the copyright holders can withdraw your license if you violate it.
<psusi> by that logic, WINE is a derived work of MS windows....
<infinity> psusi: And then you no longer can copy.
<psusi> no... they can't withdraw their license depending on how you *use* the work
<infinity> Of course they can.
<psusi> first sale doctorine
<psusi> once you sell it to me I can use it however I choose
<infinity> Yes, but you can't distribute it.
<infinity> Copyright licenses are about distribution, not use.
<infinity> And you absolutely can have your rights to distribute terminated.
<psusi> compilations... they can't say that you must distribute it alone and not as part of a larger collection with other software
<psusi> i.e. they can't say that you can redistribute linux, but not as part of an OS that contains non gpl2 software
<infinity> " If a compilation utilizes material under copyright by someone else, compilation protection does not grant the compiler rights to that material or permission to use it without license"
<infinity> A copyright license can restrict your distribution rights in ANY WAY THEY WANT.
<infinity> Especially given that it's not a restriction at all, it's a grant.
<infinity> By default, you can't distribute anything that's copyrighted.
<infinity> That's how copyright works.
<psusi> no.. it can't... they can't for instance, say that you can distribute it, but only if the servers you use to host it aren't running windows
<infinity> Not that the GPL (and any GPL work) ever claims that the whole OS needs to be GPL.
<psusi> I don't see any distinction between that and claiming that all kernel modules you distribute with it must be GPL
<infinity> psusi: They really could.  Just as they can state that you must post advertisements, or hop on one foot.
<infinity> psusi: You're being *granted* a distribution license on their terms.  It's a contract.  Some bits of that contract could certainly be tested in some courts and found unenforceable, but there's no list of "you can't" assigned to it.
<infinity> psusi: The distinction is both how the GPL defines linking, and that the kernel copyright license itself even goes out of its way to clarify.
<psusi> no.. they can't... the courts have upheld that there are reasonable things they can require, and unresonable things they can not, including that you can not demand that it not be distributed as part of an OS that contains propietary software
<infinity> psusi: Good thing no one's demanding that (also, where's that case, since I've not heard of it, since I know of no licesense that would cause that to be tested in a court in the first place)
<psusi> there were plenty of software vendors in the 80s that did not like their software being distributed on cds with hundreds of other programs...
<infinity> Those are collections, which are clearly not derived works.  The GPL claims linking creates a derived work.  It's not just a collection at that point, as a transformation more significant than copying to a filesystem has occurred.
<psusi> yes, and that is the claim that is fallacious... if linking created a derived work, then MS would have a copyright claim on every single piece of windows software ever created
<psusi> and every windows software vender would have a copyright claim on WINE
<sarnold> I suspect windows had a EULA that allowed linking to their APIs without having to share the license
<psusi> maybe to *theirs* but not to WINE's
<infinity> Derivative works are not copyright violations of the original work.  But putting them together is also not a naive collection.
<sarnold> wine's API use is likely covered by the oracle / google 'can you copyright an API' question.
<psusi> same applies to kernel modules using the kerne's apis
<psusi> it doesn't seem any different to me than MS trying to copyright the use of INT21 and saying that dosbox violates their copyright for implementing it, or every dos program ever written does and so they can stop anyone they want from writing a DOS program
<psusi> what the hell is wrong with patch?  I unpacked the latest grub2 source into ~/grub2-2.02~beta2... in there I run patch -p1 and paste in the old patch and it complains that it can't find grub2-2.02~beta2/debian/grub2.postinst.... Ummm.. the -p1 means strip off the gurb2-2.02~beta2 prefix and look instead for ./debian/grub2.postinst... why isn't it?
<psusi> oh... now htat's weird... that file isn't there
<nacc_> psusi: the naming has changed, i think? i see postinst.in, e.g.
<psusi> hrm.. I think someone fscked up the package uploads... last I patched this, it went from 2.02beta2-ubuntu1 to 2.02beta2-ubuntu2... the current changelog only shows 2.02~beta2-32 followed by 2.02-beta2-33
<nacc_> it's up to ~36
<psusi> i.e. 2.02beta2-ubuntu1 is now missing from the changelog
<psusi> i.e. someone updated to the new debian release and discarded the previous ubuntu releases from the changelog
<psusi> kind of like how I recently tried to upload a gparted package to debian discarding the previous NMU
<nacc_> psusi: i think ~36 is sync'd direct from debian, there's no delta (afaict)
<sarnold> with a version like "2.02~beta2-36" doesn't that mean it was synched right from debian?
<nacc_> sarnold: that's my reading, as well
<psusi> aren't the previous ubuntu changelog entries supposed to be preserved?
<psusi> just like I'm supposed to preserve NMU uploads in debian when I issue a new update there?
<sarnold> maybe with merges but unlikely with syncs, after all, it's just copied from debian.. whoever does the sync is supposed to ensure the delta is no longer needed
<psusi> hrm... seems odd that it s ok to discard changelog entries for previous revisions... but.. shouldn't stop my patch from applying... hrm...
<sarnold> if we had to retain all previous ubuntu changelog entries we'd never be able to blindly sync from debian for any package ever again
<psusi> damn... I can not figure out how to reconsile these changes
<psusi> there is no longer a grub2.triggers but instead a postinst.in
<psusi> grub2.postinst rather
<psusi> .triggers was the new file I added
 * psusi kicks cjwatson to the rescue
 * psusi may have to try again tomorrow when he's sober
<sarnold> pitti: what are the chances the systemd-logind restart also loses my xset dpms setting? I know it's stretching but the same day I test the new systemd-logind my X11 didn't suspend .. heh :) thanks
<pitti> Good morning
<pitti> sarnold: is that on trusty or xenial? xenial's xorg now directly integrates with logind, trusty's didn't yet
<pitti> barry: I am now
<dholbach> good morning
<cpaelzer> I have a package with a dep8 test and realized by adding a new one without needing isolation-machine that the only thing preventing them to run on armhf and s390x was that restriction
<cpaelzer> now the new test without that obviously ran on those arches and failed by "Test dependencies are unsatisfiable"
<cpaelzer> and please excuse me in case that is a silly question, but I can't find the right pointer to start via search engines, but - what is the "right" way to guard architectures for dep8 tests?
<cpaelzer> to be honest I'm even more puzzled by ppc64el failing with the same dependency but instead of a regression it lists them as "Always failed"
<cpaelzer> seems that a former "SKIP", but then adding a fail counts as regression while in fact no test ever ran successfulyl on those
<cpaelzer> but my real question/issue is around how to properly flag/guard toward only supported architectures
<cpaelzer> jamespage: since you were kind of involved FYI ^^
<cpaelzer> it's obvisous I could just add "isolation-machine", but that can't be right - is it?
<cpaelzer> an architecture list for the Depends field of d/t/control maybe?
<jamespage> cpaelzer, I'm surprised that as that package only builds for x86 archs, that the tests are even running...
<jamespage> pitti, ^^ any pointers?
<cpaelzer> jamespage: that is exactly what threw me off
<pitti> cpaelzer: you can add arch qualifiers to test dependencies, just like with binary dependencies
<pitti> so you can say "Depends: foo [i386 amd64]" if foo is only available there
<pitti> and then have your test skip the parts that need foo if it isn't available
<pitti> there is no "Architecture:" field in debian/tests/control
<pitti> if a package isn't built on a particular arch, it doesn't get tested there either
<pitti> so it should not normally be necessary
<pitti> cpaelzer: right, if it never succeeded on ppc64el it counts as "always failed", so it doesn't block propagation
<cpaelzer> pitti: but it "never worked" on s390/armhf either but now lists it as regression
<cpaelzer> that is what I meant with only SKIP seems not to count as "fail"
<pitti> cpaelzer: ok, what is "it" here? which packages?
<cpaelzer> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html look for dpdk
<pitti> cpaelzer: right, so http://autopkgtest.ubuntu.com/packages/d/dpdk/xenial/armhf/ did succeed before
<cpaelzer> pitti: yeah with 1/1 tests being SKIPed
<cpaelzer> pitti: I'm totally fine, I just didn't expect that skip only would have been considered "working" and adding a new one that fails a "regression then"
<cpaelzer> we will work on arch flagging the other tests which then should skipped as well and the regression gone
<cpaelzer> pitti: but as you said - "if a package isn't built on a particular arch, it doesn't get tested there either"
<cpaelzer> pitti: but we can add the arch qualifiers and things should be fine
<cpaelzer> pitti: thank you
<cpaelzer> maybe it is the -doc packages because they coem from the same source and are for all archs ?
<cpaelzer> pitti: would that cause the package be tested on all archs ^^ ?
<pitti> cpaelzer: it would be a bit harsh to count a test as failed just because we can't provide "good enough" testbeds
<cpaelzer> pitti: yeah, with that point of view I totally agree to you - thanks
<cpaelzer> jamespage: I'll push the changes + the revert of the revert of the VCS things to the repo the next minutes
<pitti> cpaelzer: -doc package> right, that's it, so it'll count as "available" on s390x
<cpaelzer> jamespage: would you reupload that then so we see if it resolves the test issue
<cpaelzer> pitti: ahh, and one more thanks for that confirmation - great
<cpaelzer> now everything makes sense and a solution is ahead
<pitti> cpaelzer: just adding the arch qualifiers will fish the "test dep not available", you still need to make sure that your tests skip gracefully if dpdk isn't available
<cpaelzer> pitti: ah you mean it won't install the package because we properly flagged its arch dep but the test then still wants to run and would fail
<pitti> right
<cpaelzer> ok, thank
<cpaelzer> that saves one extra upload
<pitti> cpaelzer: for this corner case there's currently no declarative way to say that, I'm afraid
<pitti> so it needs to be done in the test code for the time being
<pitti> cpaelzer: at some point we could add an Architecture: field to d/t/control of course, but it doesn't exist ATM
<cpaelzer> pitti: no SW can be perfect and autotest is great as-is - we can handle that minor thing for now
<cpaelzer> I wonder we are the first to run into that
<cpaelzer> maybe the others just didn't have to ask ...
<pitti> cpaelzer: I faintly remember that it came up once before, but it's indeed not very common
<dholbach> can somebody remind me how to find all the packages which depend or build-depend on a binary package of a given source package? :-)
<Mirv> pitti: hi! I'm unable to submit an autopkgtest rety request ("does not have any test results") when trying the i386 ubuntuone-credentials from https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-049/excuses.html
<cpaelzer> dholbach: apt-rdepends -r [-b] ?
<cpaelzer> dholbach: [-b] for depends and build-depends
<dholbach> thanks
<dholbach> looks like -r and -b won't go together
<cpaelzer> yeah the -r if for the bin, wait I had something for reverse build as well
<Mirv> dholbach: or you might want to check reverse-depends with or without -b
<Mirv> from ubuntu-deve-tools
<Mirv> -e
<dholbach> ah, great
<dholbach> thanks a bunch! :-)
<cpaelzer> yeah that is the second one I had
<Mirv> one needs to iterate through the binary packages though
<cpaelzer> dholbach: I documented all kind of this dependency stuff in this section https://wiki.canonical.com/ServerTeam/ServerReleaseHandling#Messing_around_with_dependencies
<cpaelzer> including e.g. how to iterate over the binary packages and so on
<dholbach> excellent
<cjwatson> Mirv: src:
<Mirv> !! all these years...
<ubottu> Mirv: I am only a bot, please don't think I'm intelligent :)
<LocutusOfBorg> dholbach, reverse-depends -b binary works :)
<Mirv> reading the man page would have helped easily
<LocutusOfBorg> and reverse depends works also with a given release series
<LocutusOfBorg> reverse-depends -r xenial fonts-droid
<Mirv> what about reverse depends of a Provides: provided virtual package? :)
<LocutusOfBorg> oops Mirv I did answer before reading your answer :)
 * LocutusOfBorg did rebuild itksnap, elastix, plastimatch, lets see insighttoolkit4.9 migrate today!
<Mirv> I'm using synaptic to list binary packages that depend on qtbase-abi-[version] or qtdeclarative-abi-[version], but I'd actually need a way to get the list of source packages that have binary packages that depend on them
<pitti> Mirv: can you please file a bug against auto-package-testing about that for now? (sorry, can't look into that right away)
<pitti> Mirv: did the retry work for qtmir?
<pitti> Mirv: requeued the ubuntuone-credentials test
<Son_Goku> nacc_: after a session of debugging with Remi Collet, I found out the problem: https://bugs.launchpad.net/ubuntu/+source/php7.0/+bug/1548442/comments/2
<ubottu> Launchpad bug 1548442 in php7.0 (Ubuntu) "php7.0: segmentation fault running twig test suite" [Undecided,New]
<LocutusOfBorg> nacc_, a new php7 upload hurray!
<LocutusOfBorg> I mean in Debian :)
<pitti> Mirv: well, I just restarted it too
<Mirv> pitti: ok, filing, qtmir hadn't failed yet at that point but seems to work (retry), and thanks
<Mirv> and because of timing I guess qtmir is now twice in the queue :)
<pitti> Mirv: ah, snap :)
<pitti> Mirv: yep -- http://autopkgtest.ubuntu.com/running.shtml#pkg-qtmir :)
<flexiondotorg_> I'd like to submit a one line patch to gnome-language-selector to fix an issue with MATE.
<flexiondotorg_> I see lp:language-selector is retired.
<flexiondotorg_> Should I just prepare a debdiff for the language-selector package, as can't find a source repository.
<Saviq> pitti, hey, I'm putting our autopilot tests into autopkg, will britney be happy with this https://code.launchpad.net/~saviq/unity8/autopilot-dep8/+merge/287228 ? Will the "isolation-machine" restriction make it skip it?
<pitti> Saviq: that looks a bit odd still
<pitti> Saviq: why is it isolation-machine?
<pitti> Saviq: that will skip the tests on the arches that use LXC (armhf and s390x)
<Saviq> pitti, those tests are only meant to run on phones
<pitti> Saviq: oh, autopilot's input device emulation I figure?
<Saviq> pitti, not just that, we just need a full unity8 session
<pitti> Saviq: but "initctl --session" will fail on the normal infra
<pitti> as there is no unity session
<pitti> Saviq: so either you actually start one, or you should gracefully skip the test if it's not running
<Saviq> pitti, well, my goal is to skip that test on britney altogether (unless it has touch devices available)
<Saviq> pitti, that's what I'm doing
<Saviq> pitti, see line 10 of the diff
<pitti> Saviq: pidof unity 8 || { echo "Not running under unity8, skipping"; exit 0; }
<pitti> something like that
<pitti> Saviq: ah, of course
<pitti> Saviq: yep, that's fine
<Saviq> pitti, just wanted to skip it altogether where it doesn't make sense, should I not add the isolation-machine bit, then?
<pitti> Saviq: in the future we can use something like "Class: ubuntu-touch", but that's not implemented yet
<pitti> Saviq: i-machine is fine
<Saviq> pitti, will it not trigger the test unnecessarily on some dedicated hardware, though? where it could just as well fail in a container/chroot?
<Saviq> s/fail/gracefully exit/
<Mirv> pitti: when you have time, retry unity8 i386 silo 049 (https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-049/excuses.html). added that one to the bug report too.
<pitti> Saviq: it will be skipped on containers/schroots, and not do much in qemu
<pitti> Mirv: done
<Saviq> Mirv, that's our last flaky test, will fix asap
<pitti> Saviq: "our last flaky test" â famous last words :)
<Saviq> pitti, no, for real! :)
<Saviq> (outside of armhf, that is :P)
<doko> jamespage, smoser: jdk-default-headless hit xenial. enjoy to reduce the size of images/whatever
<Mirv> thank you
<Mirv> Saviq: :)
<blaze> was unity8-lxc tested on xenial?
<blaze> not working for me here
<LocutusOfBorg> doko, itk4 is migrating now I think
<caribou_> barry: won't the regression on python-pip 8.0.2-8 block your new python-pip upload ?
<doko> apw, please could you take care about http://people.canonical.com/~ubuntu-archive/nbs.html (module-init-tools), and then telling me that it can be removed?
<doko> I'll take care about the cross-toolchain-* packages myself
<Saviq> pitti, did you consider having adt-run generate a .xml test report file?
<pitti> Saviq: it didn't come up before; we have a json file for the test environment data so far
<Saviq> pitti, I'm asking because we're constructing a dummy .xml file containing a fail when adt-run exits with a "failed" exit code, to mark the job unstable instead of plain FAILED
<Saviq> pitti, I'll parse the summary file for this, but it would probably be easier for adt-run to do this for us :)
<pitti> exactly as easy or hard, I'd say :)
<barry> caribou_: i hope not 8.0.3-1 should fix the problem
<nacc_> Son_Goku: can you put that in the php bug too?
<nacc_> LocutusOfBorg: :)
<barry> LP seems slow in picking up new debian versions
<cjwatson> barry: do you have an example?
<cjwatson> the cron job is every six hours which matched dinstall last I checked, but it does depend on exactly where in the cycle your upload falls
<barry> cjwatson: python-pip and python-virtualenv.  both were uploaded to debian yesterday but i still can't syncpackage them
<barry> cjwatson: definitely > 6h ago
<cjwatson> looking
<nacc_> Son_Goku: so, i *think*, that ubuntu's package just directly has whatever is in upstream php for ext/pcre ... and some of the patches in the repo you mention (fc23) are present (or mostly so...) and some aren't
<cjwatson> barry: well, 8.0.3-1 isn't actually in unstable's Sources file yet
<barry> maybe it's debian?
<cjwatson> I just looked on coccia
<barry> cjwatson: looks like both are in buildd-unstable?
<cjwatson> barry: dak's DB appears to have it, sure, but we sync from Sources files
<cjwatson> barry: I don't know why those are taking so long to update, but it's on the Debian side AFAICS
<barry> cjwatson: ack.  okay, thanks!
<nacc_> Son_Goku: i can build with the patches applied and narrow it down here, i think, there are few that seem likely
<cjwatson> 11:41 <jcristau> looks like yesterday's 1952 dinstall broke
<cjwatson> 11:42 <jcristau> in the pdiff stuff
<cjwatson> 11:42 <jcristau> and then exited at the same point in the 0152 and 0752 ones
<cjwatson> 11:44 <jcristau> http://paste.debian.net/405058/
<cjwatson> barry: ^- from #debian-ftp
<cjwatson> that probably explains it
<cjwatson> barry: apparently it should be fixed for the dinstall running recently/nowish
<barry> cjwatson: thanks.  i'll keep an eye on it over the next few hours, and we'll see how it falls in with the cron job cycle
<Saviq> pitti, about the "isolation-machine" again, will that not affect the existing test, that happily runs in chroots today?
<teward> any chance I could get a bug reviewed for an FFe to get the latest nginx upstream mainline version into Xenial?   Wasn't sure if I have to get the FFe approved before I uploaded, though...
<nacc_> Son_Goku: so i think ubuntu, at least, has not patched pcre 8.38 at all ... btw, did you reproduce this with debian too? can you, if possible, i do see we have a delta in ubuntu specifically about JIT
<nacc_> Son_Goku: looks to just be some symbol mangling, probably not the issue
<nacc_> Son_Goku: i'll backport the lot and see if it fixes it locally first
<Son_Goku> nacc_: it was a problem for me on Debian 8
<Son_Goku> I donât have anything on Debian sid
<Son_Goku> so I canât test there
<nacc_> Son_Goku: ok, np
<smoser> pitti, are you around ?
<rbasak> Am I right in thinking that there's no need for <package>.dirs to specify a directory that <package>.install already installs into (with debhelper)?
<cjwatson> rbasak: that's right
<cjwatson> it's relatively common redundancy but it is indeed redundant
<rbasak> Great, thanks.
<pitti> Saviq: a test with isolation-machine isn't run with adt-virt-schroot, no
<Saviq> pitti, I know, but that's the thing, we have one test without isolation-machine, another with, I just don't want the former to unnecessarily hog something
<Saviq> anyway
<pitti> Saviq: what do you mean, if it can run in a chroot, why wouldn't we run it?
<Saviq> pitti, do the tests get split up when they have different requirements?
<pitti> Saviq: each test is run separately anyway, and those which the testbed can't satisfy are skipped
<Saviq> anyway, it's running in https://requests.ci-train.ubuntu.com/#/ticket/1053 so we'll know soon enough
<Saviq> pitti, ack, if they're run separately then we should be good, thanks!
<nacc_> Son_Goku: is the pcre fix needed in pcre or in the php extension? i assumed the former?
<Son_Goku> the former
<Son_Goku> as far as I know, anyway
<Son_Goku> nacc_: that said, Remi does have some pcre patchesâ¦ https://github.com/remicollet/remirepo/tree/master/php/php70
<Son_Goku> but I donât think they apply to Xenial
<jdstrand> pitti: hey, so isc-dhcp got hung up in a network-manager regression, but all it fixed as an apparmor denial which should only make dhclient work better
<jdstrand> test_open_b_ip6_dhcp() is what failed, but I fail to see how adding the openssl abstraction to the profile would've caused that
<jdstrand> hmm, artificats does not have syslog in it...
<jdstrand> looking at wpa-dhclient-stdout, I don't see anything, but the fact that the other 3 tests passed suggests to me it is not the isc-dhcp upload
<nacc_> Son_Goku: yeah, doesn't look like it to me either
<nacc_> Pharaoh_Atem: ok, i rebuilt pcre3 with a fairly clear bugfix, and am now rebuilding php7 with that pcre, to see if it fixes the issue
<nacc_> Pharaoh_Atem: wasn't just that one patch, as i hpoed it was ... and the tests are failing when i backport the set (might have made a mistake on my part, of course)
#ubuntu-devel 2016-02-27
<bdmurray> cjwatson: Do you have any plans to get the fix for debian bug 814416 into 16.04 or other releases?
<ubottu> Debian bug 814416 in debmirror "Doesn't supoprt mirroring dep11 metadata" [Normal,Fixed] http://bugs.debian.org/814416
<Pharaoh_Atem> nacc_: damn
<cjwatson> bdmurray: Yes, I just need to sort out a merge for xenial and then I'll do precise and trusty backports.  But probably next week, travelling shortly.
<juliank> ahasenack: The empty-architecture bug #1549819 is fixed in apt 1.2.4 in Debian now. Someone can sync this starting tomorrow, I think.
<ubottu> bug 1549819 in landscape-client (Ubuntu) "SIGSEGV when reloading cache after setting architecture to """ [Undecided,Confirmed] https://launchpad.net/bugs/1549819
<juliank> Future Warning: Later releases may throw an error that "" is not a valid architecture.
<stefanct> any groff experts around?
#ubuntu-devel 2016-02-28
<ginggs> nacc, Pharaoh_Atem: did you see https://packages.qa.debian.org/p/pcre3/news/20160227T165039Z.html ?
<Pharaoh_Atem> ginggs: hmm, maybe that'll fix the php segfaults
<Pharaoh_Atem> ginggs: that's one of the things Fedora patched to fix
<Pharaoh_Atem> but can someone please tell me why pcre has a soversion of 3 in Debian/Ubuntu but nowhere else?
<ginggs> Pharaoh_Atem: and pcre2 is the new version
<Pharaoh_Atem> yeah
<Pharaoh_Atem> in Fedora it makes sense, because pcre kept the soversion 1
<Pharaoh_Atem> so pcre2 is named correctly
<Pharaoh_Atem> it's the same way in openSUSE, where they actually put the soversion in package names
<Pharaoh_Atem> it's libpcre1
<Pharaoh_Atem> it's a really bizarre ABI change that seems to be exclusive to Debian/Ubuntu
<Pharaoh_Atem> ginggs: do you have any idea, as the pcre maintainer in Ubuntu?
<Pharaoh_Atem> ginggs: this is not a patch that makes me very happy... https://sources.debian.net/src/pcre3/2:8.38-2/debian/patches/soname.patch/
<ginggs> i think i recall reading aomething about that
<ginggs> upstream where bumping the SONAME unecessarily
<ginggs> *were
<ginggs> you can look back through the changelog http://metadata.ftp-master.debian.org/changelogs/main/p/pcre3/unstable_changelog to see where pcre2 and pcre3 appeared
<Pharaoh_Atem> oh geez
<Pharaoh_Atem> I see how it happened
<Pharaoh_Atem> they patched and bumped the soversion when major versions were introduced
<Pharaoh_Atem> but that's not irreversible now... unless they don't have a tool that rebuilds all the reverse depends, I guess?
<ginggs> Pharaoh_Atem: are you able to test if pcre3 2:8.38-2 fixes the php segfaults?
<Pharaoh_Atem> atm no, I have to rebuild everything :/
<Pharaoh_Atem> which... takes hours
<cjwatson> stefanct: groff> somewhat, depending on what you need
<stefanct> cjwatson: sorted it out myself. i dont really understand why but adding \{ and \} to a branch containing a macro definition (.de) helped to avoid "warning: macro `.' not defined" at the end of that definition...
<stefanct> http://dpaste.com/3MX4WYK
<stefanct> and no, the line break within the .de is not the problem (alone)
<cjwatson> stefanct: that would make sense.  if you don't have the \{ there, then the .el only executes the next request, I'm not very surprised that that would have strange interactions with .de without \{ \}
<stefanct> well but executing the next request is exactly what it should do... just because that request has multiple lines i would not expect it to fail
<cjwatson> stefanct: I think technically the single line containing .de is the request, and then that request copies subsequent lines of input into a buffer
<cjwatson> stefanct: so if the .de isn't executed, then you have subsequent lines of input that will just be executed there and then
<cjwatson> stefanct: the .. (or whatever the macro closure is) is in fact a separate request after that telling troff to stop the macro definition
<cjwatson> stefanct: basically the parser is less smart than you were giving it credit for, but you have arrived at the correct answer :)
<stefanct> yes, i think you are right
<stefanct> in any case... lintian should now be happy so i am too :)
#ubuntu-devel 2017-02-20
<cpaelzer> good morning
<momken> hello
<momken> I want to ask about "Ubuntu Make"
<momken> I know I can install my ideas using ubuntu make
<momken> But
<momken> 1. What version will it install? Would it download the latest version from its site? (like from code.visualstudio.com or from jetbrains website)
<momken> 2. Where will it install the ide?
<pitti> jbicha: I can't any more, I left ~u-release
<alkisg> Hi, suppose I'm both upstream and debian maintainer for software1.0, and debian is in freeze. At that point, I happen to release software2.0 upstream, and want to make it available for e.g. Ubuntu 17.04. Is it "proper" to upload this to e.g. debian experimental and sync to ubuntu from there, or is it considered as wasting debian server resources, and I'd need to upload it directly to Ubuntu?
<pitti> alkisg: IMHO it's fine to upload to experimental and sync; some Debian users might want to use 2.0 too
<pitti> it's very common to package newer versions in exp during freezes
<alkisg> pitti: thank you, because we had an argument about that with the debian co-maintainer of those packages. Do you happen to have in mind some package that did that, so that I give it to him as an example?
<pitti> alkisg: we have done, and will soon do that again for systemd
<alkisg> Thanks a lot :)
<pitti> alkisg: but, I don't think it's worth starting a fight over that -- if the Debian maintainer doesn't want that, just upload it to Ubuntu..
<alkisg> I don't mind uploading to ubuntu, but the main argument is that he wants the whole debian/ dir to be frozen while debian is freezed; thus I would have to fork it to do an ubuntu release... :(
<alkisg> (while most of the debian/ dir was written by me anyways...)
<pitti> alkisg: that's what git branches are for..
<pitti> alkisg: e. g. we'll (RSN) branch systemd's master as stretch and continue unstable uploads from there, and use master for packaging new versions and uploading to experimental
<pitti> or use an experimental branch
<pitti> (the former makes more sense IMHO, but both work and it's a matter of taste)
<alkisg> " and use master for packaging new versions and uploading to experimental" ==> that's exactly what  I was suggesting, but he said, "no, master should be debian unstable, if you want daily builds or ubuntu releases, keep forking master whenever you need"
<pitti> vim is better than emacs, obviously
<alkisg> And I would hate to have to maintain a fork for software where I wrote both the code and the packaging... :(
<pitti> it's not really much more work
<alkisg> Yeah, it's amazing how strong opinions can come between developers for such small issues
<pitti> after the release, rename master to stretch and rename experimental to master
<pitti> (which I find stupid, and why I'd prefer using a stretch branch right away, but, bikeshed)
<alkisg> Nah I think he'll just want to "backport" whatever changes I did to his "master" branch; and I'm afraid that he might leave some out, thus making a diff from debian to ubuntu, which is another thing I hate. Oh well we'll see. Thanks again for your input!
<cult-> xnox: when it will be ok to set the label to verification-done ?
<cult-> tag
<Saviq> robert_ancell, hey, about bug #1654365, what else can we do to track this down? I'm certain /etc/X11/Xsession.d is in effect as removing use-session-dbus from Xsession.options makes the problem go away
<ubottu> bug 1654365 in ubuntu-touch-session (Ubuntu) "Session dbus lauched by /etc/X11/Xsession.d/75dbus_dbus-launch dies immediately" [Undecided,New] https://launchpad.net/bugs/1654365
<robert_ancell> Saviq, I think you know more about this than I do. Have you asked desrt?
<Saviq> robert_ancell, no, we got stuck at your feedback, thinking it's lightdm running the Xsession bits
<Saviq> knowing who to talk to next is definitely helpful
<robert_ancell> Saviq, I'm not sure who would know this best, but it probably would have been her or pitti
<Saviq> ack, will talk to Allison tomorrow
<Saviq> thanks
<robert_ancell> Saviq, lightdm is launching the xsession bits, but it really has no idea what they do
<Saviq> robert_ancell, didn't you say it shouldn't do that for Mir sessions?
<robert_ancell> Saviq, it runs xsession regardless, with the convention being that xsession will change behaviour if appropriate if it needs to (i.e. it detects it's running in Mir instead of X)
<Saviq> aha
<robert_ancell> xsession is a horrible mess of old-fashioned scripts that have got more complex over the years. I'd love to get rid of this but it was too hard to do at the time.
<Saviq> yeah I can relate
<Saviq> so the question is, then, why is dbus-launch going away now
<robert_ancell>  Â¯\_(ã)_/Â¯
<robert_ancell> there be dragons
<robert_ancell> Saviq, for completeness, what lightdm does is run the session command (got from the .desktop file) through /usr/sbin/lightdm-session. That's provided by the distro (i.e. debian/lightdm-session) in our case. That in turn runs the sysadmin provided scripts in Xsession.d
<Saviq> ack, tx
#ubuntu-devel 2017-02-21
<cpaelzer> good morning
<cult-> xnox: when it's going to be released just out of curiosity?
<cpaelzer> hmm, when I upgrade from A to a newer A' which now has a recommends to B will be auto-installed on the upgrade
<cpaelzer> I know it would on install
 * cpaelzer heads raeading docs (but would be happy if one just knows)
<LocutusOfBorg> yofel, please merge/sync libqapt and baloo? I have not enough knowledge for doing it by myself sorry
<pitti> Laney: the two UPSTREAM_PULL_REQUEST=4670 ones in http://autopkgtest.ubuntu.com/running#pkg-systemd-upstream seem to loop; are there any errors in the logs?
<pitti> Laney: yesterday they still ran and failed; then https://launchpad.net/ubuntu/+source/ifupdown/0.8.16ubuntu1 landed, maybe that changed/broke something
<Laney> hey pitti
<Laney> let me see
<Laney> all arches?
<pitti> Laney: both i386 and amd64, yes
<pitti> (I didn't trigger s390x, no point)
<Laney> pitti: don't those upstream ones run on xenial?
<Laney> why would an ifupdown in zesty break that?
<pitti> Laney: I  manually triggered test runs on zesty, as this is useful for that PR
<Laney> oh right
<pitti> Laney: that uses the new unified cgroup hierarchy on kernels that support enough of it, which isn't the case yet on xenial
<Laney> ok, let me look for that then
<pitti> so xenial is for "this doesn't break stuff on older kernels and continues to use cgroupsv1", and zesty is "this doesn't break on unified hierarchy"
<Laney> there's one running, /me tail -fs that
<pitti> Laney: I have a feeling that it already has ran several times since yesterday evening; they usually take 1:30 hours or so
<pitti> Laney: so I was wondering if there's any nova console log (or similar) in the journal already
<Laney> I just see the testbed failure
<Laney> ah wait, there's an aborted worker
<Laney> Feb 21 08:03:28 juju-prod-ues-proposed-migration-machine-3 sh[5696]: Selecting previously unselected package libio-html-perl.
<Laney> it just ends on a package installation
<Laney> Feb 21 06:57:03 juju-prod-ues-proposed-migration-machine-3 sh[5839]: Selecting previously unselected package autoconf.
<Laney> Feb 21 06:21:49 juju-prod-ues-proposed-migration-machine-3 sh[5669]: Get:71 http://ftpmaster.internal/ubuntu zesty/main i386 libip4tc-dev i386 1.6.0-3ubuntu2 [6,534 B]
<Laney> hmm
<Laney> pitti: is this helpful?
<Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.128242] Unable to open file: /etc/ima/ima-policy (-2)[    2.129043] IMA: policy update failed
<Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.129613] audit: type=1802 audit(1487638604.548:2): pid=1 uid=0 auid=4294967295 ses=4294967295 op="policy_update" cause="fa
<Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.141903] ip_tables: (C) 2000-2006 Netfilter Core Team
<Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.146335] systemd[1]: Failed to create symlink /sys/fs/cgroup/net_cls: Operation not permitted
<Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: [    2.147550] systemd[1]: Freezing execution.
<Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: ---------------------------------------------------
<Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: <VirtSubproc>: failure: Timed out on waiting for ssh connection
<Laney> Feb 21 01:01:46 juju-prod-ues-proposed-migration-machine-3 sh[26926]: autopkgtest [01:01:42]: ERROR: testbed failure: unexpected eof from the testbed
<xnox> pitti, we landed 4.10 kernel too
 * ogra_ hopes 4.10 passes quickly ... always makes me think "oh the warty kernel"
<pitti> Laney: sorry, long phone call
<pitti> Laney: it looks related, yes; /sys/fs/cgroup/net_cls wouldn't exist any more with the unified hierarchy, just not sure why this would cut the ssh connectino
<pitti> xnox: oh right, only 10 hours ago, that could be relevant
<Laney> pitti: Someone posted "Freezing execution" on the PR too
<Laney> seems that was with 4.9 though
<pitti> Laney: any chance you could put the /tmp/autopkgtest.*/binaries/*.deb somewhere? I'd like to see if I can reproduce this locally with today's cloud image
<pitti> worked fine yesterday still
<pitti> Laney: I could also rebuild it myself, but the binaries should already be there in the running tests, so convenience..
<Laney> one second
<Laney> got to pull this string
<pitti> Laney: ah bummer, current retry is still at package building stage
<Laney> no I've got binaries
<pitti> oh, cool
<Laney> no version in the filename
<Laney> is that normal?
<Laney> pitti: http://people.canonical.com/~laney/weird-things/systemd.tar.xz
<pitti> Laney: yes, that's normal
<pitti> Laney: many thanks!
<Laney> pitti: just got them out in time ;-)
<Laney> (died now)
<Laney> I'll filter these out now if you don't mind
<pitti> Laney: yes, please
<pitti> [    2.080076] systemd[1]: Failed to create symlink /sys/fs/cgroup/net_cls: Operation not permitted
<pitti> gotcha
<pitti> trivial to repro locally
<Laney> it killed the VM too?
<Laney> I should throttle debmirror somehow, kills SSH latency when it's running
<pitti> Laney: yep, same "freezing execution", I followed up to the PR
<pitti> Laney: so presumably it's a regression from the followup pushes yesterday  evening
<pitti> unfortuantely ridiculously hard to detect by heuristics
<pitti> unless we add "Freezing execution" to the list of strings it watches out for; we now have strings for kernel crashes, don't we ?
<pitti> similar to f9b3ee01e9
<Laney> pitti: could do, if that always indicates a failure
<Laney> bit of whack a mole, but what can you do?
<doko> apw, infinity: what's the estimate for linux 4.10 and glibc 2.25 in z? asking for the test rebuild
<pitti> doko: linux 4.10 landed yesterday (there's some fixes in -proposed, but hopefully shouldn't affect the headers much?)
<doko> ahh, I see
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | 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: mdeslaur
<Laney> pitti: https://paste.ubuntu.com/24040277/ ?
<pitti> Laney: nice! thanks
<Laney> pitti: ok, deployed, could you trigger the test again to test it please?
<Laney> just pick one arch
<pitti> Laney: triggered amd64
<Laney> merci
<pitti> Laney: merci Ã  toi ! I'll trigger i386 after amd64 failed "properly"
<pitti> (although, that doesn't really tell us anything, nevermind)
<Laney> You'll get a nice 'x' on the PR :P
<pitti> I already get that with one failure
<Bluefoxicy> I wish apt and update-manager had an integrated system to pull all process ids, identify all loaded binaries, and list everything using a binary which has been replaced
<Bluefoxicy> that way when you update e.g. openssl, you can list everything running that's still using the previous version, and restart services or browsers
<Snow-Man> uh
<Snow-Man> check_libs
<Snow-Man> Does basically exactly that...
<Bluefoxicy> oh cool
<Snow-Man> I agree that it'd be nice if apt would tell you too.
<Bluefoxicy> command not found
<Snow-Man> nagios-plugins-contrib: /usr/lib/nagios/plugins/check_libs
<Snow-Man> heh
<Bluefoxicy> oh lol
<Snow-Man> lsof works too tho
<Snow-Man> and is what check_libs runs
<Saviq> wgrant, hey, looks like builders got a kernel upgrade again? https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2457/+build/12039740
<ilmaisin> hi
<ilmaisin> how do i report a disruptive user in launchpad?
<ilmaisin> blacksheep001 keeps spamming some internet connection questions to cups bug reports
<ilmaisin> won't believe when i ask him to stop
<seb128> ilmaisin, you can try asking on #launchpad but I think the recommended way is to use https://answers.launchpad.net/launchpad/+addquestion
<ilmaisin> seb128: thanks
<seb128> ilmaisin, yw!
<tinoco> cpaelzer: are u also taking care of qemu for trusty ?
<tinoco> qemu/libvirt
<cpaelzer> tinoco: as much as possible :-)
<tinoco> cpaelzer: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1317491
<ubottu> Launchpad bug 1317491 in libvirt (Ubuntu Trusty) "virsh blockcommit hangs at 100%" [Medium,In progress]
<tinoco> i'll probably block the "block-commit" feature in libvirt for Trusty
<tinoco> (just for active block devices)
<tinoco> its broken anyway
<tinoco> cpaelzer: could u review it for me so I can prepare the SRU ?
<cpaelzer> tinoco: yes, but not today
<tinoco> cpaelzer: cool, i'll prepare the debdiffs and wait for you
<cpaelzer> tinoco: drop me a mail and I'll look at it then
<tinoco> cpaelzer: ill attach them to the case and email you
<tinoco> cpaelzer: tks buddy
<smoser> xnox, around ?
<xnox> smoser, sure! what's up?
<smoser> i saw you re-ran some tests or open-iscsi once
<smoser> i filed https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1666573
<ubottu> Launchpad bug 1666573 in open-iscsi (Ubuntu) "transient systemd ordering cycle in boot with overlayroot ver read-only open-iscsi root" [Medium,Confirmed]
<smoser> with some diagnosis comparing the pass and fail, and wanted to know if anything jumped out as you asa the reason for the transient results.
 * xnox learns a new word "posterity"
<smoser> the top 4 runs at http://autopkgtest.ubuntu.com/packages/o/open-iscsi/zesty/amd64 show pass and fail of identical runs
<xnox> smoser, what updates the /etc/fstab? is it done in the initramfs before systemd is started?
 * nacc has noticed for a few packages in excuses that the oldest success has no logs -- is that something that can be avoided (i'm assuming maybe it got pushed off the bottom of the list, but still shows up on the web UI, e.g.: http://autopkgtest.ubuntu.com/packages/p/puppet/zesty/amd64)
<smoser> overlayrooto before intiramfs
<smoser> er...
<smoser> in initramfs
<smoser> by overlayroot
<xnox> smoser, there is possibly a race between fstab-generator and /etc/fstab being updated; if the update is not done in the initramfs.
<xnox> ah, good.
<smoser> the attached .tar.xz has "short" logs (just the tgt-boot-test output)
<smoser> and they actually compare side by side reasonably well with vimdiff
<smoser> cpaelzer, ^ i think that could be part of your issue with open-iscsi tests
 * cpaelzer reads backlog
<zul> doko: ping can you review os-faults wen you get a chance its a new dependency for rally
<doko> zul: yes, will do it tomorrow morning
<zul> doko: thank you
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | 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:
<nacc> is there a convenient way for me to test the exact environment the autopkgtests run in? That is, http/https proxies and all. I think the puppet failure is due to https_proxy being set, but I'm not 100%
<jgrimm> nacc, i'm interested in that too
<nacc> jgrimm: will keep you posted
<jgrimm> tx
<nacc> Laney: --^ you may know
<Laney> afraid not
<nacc> Laney: np, thanks!
<nacc> Laney: you've just educated me on several other autopkgtest nuances :)
<nacc> jgrimm: ah, i think i see the puppet failure a bit clearer now (and why my initial 'fix' does workaround it, but is incorrect). I think the tests assume a host-naming pattern of 'puppet'.
<nacc> jgrimm: so when it attemps to use https://puppet... it will alias to localhost when Debian tests
<jgrimm> nacc, aha.  tho, i was more interested in the part of your question that asked how to create the exact autopkgtest environment. :)
<nacc> jgrimm: understood, just fyi :)
<nacc> stgraber: `lxc --sudo --name puppet-1487554013 adt-sid-amd64` -- would that set the container's 'hostname' to puppet-1487554013 ?
<nacc> stgraber: ah nm, that's an autopkgtest-virt-lxc option
<Laney> nacc: yes, it's passed to lxc-start --name
<nacc> Laney: yep, i see that now, thanks!
<Laney> nacc: One way to do your thing might be to make the lxc/d runner apply a profile, and construct one of those which blocks network access other than to a proxy
<Laney> Assuming you can make such profiles (I don't actually know that)
<nacc> Laney: yeah, that's a thought. I think a much simpler one (looking at the test case ruby now), would be to just have puppet use the actual hostname at run-time, rather than assuming it's 'puppet' (and accessible at that hostname). There's nothing in the tests that asserts that's true.
<Laney> nacc: That helps for this one problem, but not in general :P
<nacc> Laney: yeah :)
<Laney> Well done potentially finding the issue though
<Laney> you can invoke autopkgtests against a PPA FYI
<nacc> Laney: only because in this case, I don't think the proxy is actually the problem
<Laney> so no need to upload to the archive to verify your fix if it's environment dependent
<nacc> Laney: ah that would be great -- documentation for it?
<Laney> ...
<Laney> I knew you'd ask that
<nacc> heh
<jgrimm> nacc, or bileto!
<nacc> LP: #1550280 implies it's not present
<ubottu> Launchpad bug 1550280 in Launchpad itself "autopkgtest: allow testing against private PPAs with private results" [High,Triaged] https://launchpad.net/bugs/1550280
<nacc> jgrimm: good point
<Laney> private no, but public ones sure
<nacc> Laney: err, right!
<Laney> meh, got to get this from the source
<Laney> nacc: ok, I think it's &ppa=user/ppa (https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=puppet&ppa=nacc/myppa)
<Laney> if that works, would appreciate a sentence on https://wiki.ubuntu.com/ProposedMigration :-)
<nacc> Laney: ack, will test that!
<nacc> Laney: https://autopkgtest.ubuntu.com/request.cgi?release=zesty&arch=amd64&package=puppet&ppa=nacc/lp1570472&trigger=puppet/4.8.2-3ubuntu2~ppa1, FYI
<nacc> Laney: will update the docs
<Laney> nacc: it got published already?
<nacc> Laney: my upload to my PPA did yeah
<Laney> wowzers
<Laney> things are fast these days
<nacc> Laney: yeah, faster than I expected :)
<Laney> next challenge is finding the results :P
<nacc> :) was just going to ask
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-nacc-lp1570472/?format=plain
<nacc> hrm, I get Unauthorized
<Laney> the container is made when the first result is uploaded
<Laney> oops, and I've just clicked on a huge text file which has killed firefox for the next X months
<nacc> Laney: so... once it's done, should i be able to access the above log?
<Saviq> wgrant, hey, did you see my message before about arm64 builders crashing in QML again? (bug #1630906)
<ubottu> bug 1630906 in linux (Ubuntu) "QML segfault on arm64 due to builder kernel change" [Undecided,Confirmed] https://launchpad.net/bugs/1630906
<Laney> nacc: yup
<Laney> well, it'll be an index, and then you construct the path from that
<Laney> you can see that the UX here has had a lot of thought :/
<Laney> to be fair it was mostly designed to be driven by machines
<Laney> but I'm sure we could make it more user friendly somehow
<nacc> Laney: totally understood
<smoser> xnox, i did manage to catch a failure that i have emergency console access to if you were looking at bug 1666573 and needed anything
<ubottu> bug 1666573 in open-iscsi (Ubuntu) "transient systemd ordering cycle in boot with overlayroot ver read-only open-iscsi root" [Medium,Confirmed] https://launchpad.net/bugs/1666573
<nacc> Laney: and i'll update the wiki to indicate you can see it running on the main autopkgtest page
<xnox> smoser, a dump of journal would be nice
<Laney> nacc: Aye - you can see the formula for getting the index from that URL I gave
<xnox> if you can save / extract / copy if somwhere
<Laney> autopkgtest-release-username-ppaname
<Laney> in fact that's documented at https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Container_Names
<Laney> but that tells you more than you need to know
 * Laney imagines a CLI tool for all this
<Laney> ok, those rocks aren't going to climb themselves
<Laney> o/
<nacc> Laney: thanks and enjoy!
<nacc> jgrimm: in case you didn't see it: "Testing against a PPA" at https://wiki.ubuntu.com/ProposedMigration
<jgrimm> nacc, tx
<nacc> Laney: just fyi, my autopkgtest seems wedged
<nacc> if anyone else has access: http://autopkgtest.ubuntu.com/running#pkg-puppet ran that aginst my PPA
<nacc> it looks like it's done and passed, but i've not seen any log change in a while now
<nacc> and I can't access the underlying logs until the jobs is done, afaict
<nacc> Laney (and anyone else): nevermind, it worked, it was just taking a while to extract the logs, i think
<robru> anybody around that can help with an autopkgtest issue? sqlparse update is held back because failing autopkgtest with python-django-debug-toolbar 1.5, the issue is fixed by 1.6, which is in -proposed, but it's invalidated by sqlparse, which is invalidated by the autopkgtest run from 1.5. Not sure how to kick that autopkgtest with 1.6 which should work (I
<robru> checked the source and the traceback is resolved in 1.6)
<nacc> robru: have you tried rerunning the test?
<nacc> robru: i think it should use the new version if it's in z-p now
<robru> nacc: yeah, gives very strange output where it claims to be installing 1.6 deb but traceback references 1.5 source tree (and same traceback): https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/p/python-django-debug-toolbar/20170221_180502_a55de@/log.gz
<nacc> robru: ah it's using the z-p to satisfy the debends, but the test it is running is from the 1.5 src
<nacc> *depends
<robru> nacc: any thoughts how to fix that?
<nacc> robru: thinking -- there is a proposed flag we can pass to the test to use proposed for everything, but i'm not sure if that's what we need here or not
<robru> nacc: I have no idea. I mean the log already shows it's installing the correct version of the deb, so I'm not sure where it's even getting the 1.5 source tree from
<nacc> robru: because that's the version the test is running (earlier you can see it downloads the 1.5 src)
<nacc> robru: the way it works is that only sqlparse will come from z-p by default
<nacc> robru: for this specific run
<nacc> --apt-pocket=proposed=src:sqlparse
<robru> nacc: oh well, can you rerun with --all-proposed then? should fix it
<nacc> robru: let me try it
<robru> thanks
<nacc> robru: trying amd64 first, let's see if it passes
<robru> nacc: I just double checked, v 1.6 absolutely fixes this traceback, no doubt.
<robru> maybe some other problem will arise, not sure, but this specific traceback is for sure fixed by 1.6 ;-)
<nacc> robru: ack
<pitti> Laney: nice, that worked! proper failure with useful log now; thanks!
<robru> nacc_: oooh I see the pass, thanks!
<robru> nacc_: try the other arches please ;-)
<jbicha> barry: hi, systemd-resolved hasn't been working smoothly here, bug 1666021
<ubottu> bug 1666021 in systemd (Ubuntu) "zesty systemd-resolve timeout" [Undecided,Confirmed] https://launchpad.net/bugs/1666021
<nacc> robru: ok, looks like it passed on amd64, will trigger the others
<nacc> robru: will take excuses a bit to see the passes, ithink
<barry> jbicha: interesting.  i haven't seen this, but then i don't suspend
<jbicha> well the initial report wasn't about suspend, it was about first boot
<jbicha> maybe there's multiple issues combined into one report but I didn't know where to split it
<barry> jbicha: i have seen problems with resolving names right after first boot, but that predates the recent n-m or systemd uploads.  e.g. after first login, i have chromium set up as a start-up app, but after first login post-reboot, most of the tabs cannot load.  reloading always fixes it, so there is definitely something going on around boot
<jbicha> ok, but with the symptoms I experienced and the workaround (just restart resolved), it's very convenient to blame resolved now
<zul> doko: networking-bagpipe and networking-bgpvpn as well please
<nacc> robru: yeah, amd64 just ticked over, at least, looks like it's passing elsewhere too
<robru> nacc: thanks!
<nacc> robru: and sqlparse is now a valid candidate
<robru> nacc: yay, thanks!
<nacc> robru: np!
<scootergrisen> Can anyone help me get danish translation into the Ubuntu ISO live?
<scootergrisen> So when i select danish language during boot its translated to danish without having to install danish language.
<robru> nacc: http://people.canonical.com/~ubuntu-archive/proposed-migration/zesty/update_excuses.html#libseccomp all these regressions appear to me to be transient network issues, can you retry them?
<nacc> robru: looking
<nacc> robru: done
<robru> nacc: thanks!
<wgrant> Saviq: Not at 4am. Fixing.
<Saviq> wgrant, duh, was sure you're closer than that on the timezone front... thanks :)
<nacc> jgrimm: ping
<jgrimm> nacc, pong
<nacc> jgrimm: I *think* your openvpn upload may have inadvertently broken the Canonical VPN cxn with NM on upgrades :) related to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848062 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848062
<ubottu> Debian bug 848062 in openvpn "Warn users of removed tls-remote option" [Normal,Fixed]
<nacc> specifically, i get "Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: tls-remote (2.4.0)"
<sarnold> nacc: from #distro "You have to change VPN -> Advanced -> TLS Authentication -> "Server certificate check" to "Verify name exactly" and remove the /CN: or whatever it is"
<jgrimm> nacc, fun times!
<nacc> sarnold: yeah, we should put that somewhere, though -- release notes, or in a NEWS file?
<jgrimm> yeah, release notes at very minimum
<nacc> sarnold: but thank you for the pointer!
<nacc> sarnold: as to the remove the '/CN: ...' it doesn't let that be empty (understandably, i think) -- so does that mean remove the value for /CN?
<nacc> sarnold: nm, i undestand now
<sarnold> nacc: I assumed it meant the non-data annotations..
<nacc> jgrimm: so in that particular case, elide the '/CN:' string specifically
<jgrimm> nacc, correct
<nacc> jgrimm: will you follow up on that with the release notes? i have a feeling it will bite people
<jgrimm> nacc, yeah i'll go add a blurb now
<nacc> jgrimm: thanks
<Laney> nacc: FYI you can add extra triggers instead of all-proposed
<Laney> when retrying tests
<Laney> they translate into src:proposed things basically
#ubuntu-devel 2017-02-22
<nacc> Laney: ah! ok so each trigger gets specified?
<nacc> Laney: good to know
<nacc> slangasek: is someone from foundations looking at the remaining perl autopkgtest regression? I spent some time last week, but don't know if I should invest more time this week (libembperl-perl). The root cause is some sort of double evaluation of they DynaLoader module
<nacc> mdeslaur: thoughts on (me) possibly looking into if we can separate out http2 support into its own pacakge which could live in universe? there isn't a precedent for that in src:apache2, but a lot of other apache2 modules are in universe.
<sarnold> isn't that what we have today?
<nacc> sarnold: no, we don't build it at all
<nacc> sarnold: our apache2 has no mod_http2 available
<nacc> sarnold: because it's not its own package in debian (so the above suggestion would be delta)
<nacc> we might still pursue the MIR eventually, etc., but I'm trying to think of something that can resolve the lack of http2 at all in the short-term without that
<nacc> Laney: do you mind if I document that on the same wiki page?
<nacc> RAOF: thanks for the ping, doing it now
<RAOF> nacc: Oh, sweet!
<RAOF> Thanks.
<nacc> RAOF: done
<nacc> RAOF: thank you for the reminder!
<RAOF> nacc: ...and released!
<slangasek> nacc: I don't know that anyone is tracking that, no
<nacc> slangasek: ok, i'll try and debug it more tmrw
<josvaz> Morning!
<josvaz> Phil's daugther has a high fever (>40C = >104F) so he won't be in, at least in the morning
<josvaz> wrong channel sorry
<Laney> nacc: go for it
<cpaelzer> Hey I'm involved in reviewing and sponsoring an SRU - it seems the last two SRUs (different problems) vanished in proposed (not verified and denied after timing out)
<cpaelzer> I'm wondering if it is "ok" to just leave out the two versions in the changelog
<cpaelzer> For the user they never happened, so it would be the correct changelog
<cpaelzer> but I would like to have anybody confirming that it is ok to jump version.17 version.20 (with .18 and .19 being those that never made it through)
<mdeslaur> nacc: can't it wait for z+1? we can MIR the http2 library as soon as z+1 opens...creating a universe package that you'll have to transition back is a lot of work, no?
<rbasak> nacc: I'm not sure about that either. If something isn't in main due to quality (eg. "considered experimental upstream"), then I don't think it should be in universe either unless somebody else commits to looking after all the upgrade path issues etc. I don't think it's worth our time to do that.
<rbasak> I think the expectation of quality here matches that of a PPA, so it should be in PPA if anywhere. It should be made very clear to users that the usual expectations of quality (eg. a best-effort-to-be-smooth upgrade path to new releases) don't apply to this module.
<rbasak> IOW, I don't think it's OK for us to "throw" something into universe that we don't want to support in main.
<rbasak> OTOH, if somebody else wants to commit time to maintaining something in universe by spending the effort to maintain it at better quality, then that's fine.
<sil2100> slangasek, infinity: hey! I was reviewing the thunar SRUs for xenial and yakkety and I think I would need a TB approval on getting this in
<sil2100> slangasek, infinity: it's a new microrelease which doesn't mark all the bugs fixed through LP, and they don't have autopkgtests (or a good test suite)
<sil2100> slangasek, infinity: the SRU process mentioned I'd need a single TB member to approve it in this case
<zul> doko: ping
<sil2100> The release makes sense in overall (besides needing a small tweak in the version number) - all changes look like welcome additions
<rbasak> sil2100, tjaalton: in bug 1639896, is there any thought to testing users who are on AMD but not using Polaris?
<ubottu> bug 1639896 in xserver-xorg-video-amdgpu (Ubuntu Xenial) "Backport support for AMD Polaris" [Undecided,Fix committed] https://launchpad.net/bugs/1639896
<rbasak> We don't want to regress those users accidentally, right?
<rbasak> For example, if the code that detected what card was in use was broken and was accidentally "always Polaris of course".
<tjaalton> rbasak: all such tests use pci-id's. this adds new to support polaris
<tjaalton> old radeons use -ati
<tjaalton> this is for gcn1.0 and up iirc
<rbasak> I'm talking of "regression risk in case our understanding is wrong", not "what is our understanding".
<tjaalton> "code that detected" is in the driver
<tjaalton> you assume it's broken
<rbasak> I assume that broken-ness is unknown without some method to try to ensure that it's not.
<tjaalton> it's in 16.10
<tjaalton> guess we'd have heard by now
<rbasak> That's fair.
<tjaalton> also on 16.04.2
<rbasak> Oh? 16.04.2 pulled from xenial-proposed for this package?
<tjaalton> no, same version
<tjaalton> x-x-v-amdgpu-hwe-16.04
<rbasak> xserver-xorg-video-amdgpu is 1.1.0-1 in xenial release, doesn't exist in xenial-updates and is 1.1.2-0ubuntu0.16.04.1 in xenial-proposed, now?
<rbasak> Oh, I see.
<rbasak> OK
<tjaalton> yes and zesty has 1.2.0
<tjaalton> amd made 1.1.2 to add support for polaris in 1.1.x code
<tjaalton> actually 1.1.2 was a one-commit fixup release. 1.1.1 had the other commits
<Unit193> tjaalton: I don't suppose you saw my poking of jcristau in #debian-devel?
<tjaalton> Unit193: what about?
<Unit193> tjaalton: In regards to 60x11-common_xdg_path, which adds DESKTOP_SESSION to the XDG_CONFIG_DIRS path.
<tjaalton> no
<tjaalton> did not
<Unit193> Before I had asked one of the Ubuntu devs if it was pushed to Debian, and at the time he said they didn't want it.  jcristau seemed to know nothing about it, and it's very useful in live-build ISOs.
<Unit193> Do you happen to know?
<tjaalton> nope
<Unit193> Huh.  Alrighty, thanks.
<tjaalton> needs a bug on debian side
<tjaalton> if you want it there
<Unit193> Yeah I was just trying to find out why not, but seems there might not be a reason so time to file.
<juliank> cjwatson: We have a user in #debian-apt on oftc wondering how to best create a local partial mirror of Ubuntu archives. Seems that with apt-mirror he always runs into inconsistencies. Ideas?
<cjwatson> not at the moment sorry
<cjwatson> I mean I'd probably start with debmirror
<cjwatson> but partial mirroring is always somewhat fiddly
<juliank> cjwatson: I think the problem is mostly that the mirror they are mirroring updates while they are mirroring, causing parts to be from the old state and parts from the new state.
<juliank> How often are they updated? Every 30 minutes?
<cjwatson> juliank: multiple times an hour, not on a fixed schedule exactly
<juliank> ah, ok
<cjwatson> juliank: sounds like something that might be fixed by having the mirroring tool use by-hash index files
<cjwatson> juliank: the stay of execution for everything else is generous enough that that should be enough
<caribou> barry: can I trusk sysconfig.get_config_vars() to return _EXACTLY_ the CFLAGS used to build the python interperter ?
<barry> caribou: yes, should be accurate.  iirc it reads them right out of the makefile
<caribou> barry: ok, thanks
<smoser> hey. wonder if anyone has a solution.
<smoser> rharper has been working some systemd-networkd bugs and support in cloud-init
<smoser> we dont know how we can express what we want correctly
<smoser>  https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/317917
<smoser> has more info. but basically , as rharper said
<smoser> we don't have a way to express the idea that *if* you're using networkd  as your $networking_service *then* you need systemd >= X and resolvconf >= y
<rbasak> You might be able to express that using virtual packages, but I don't know if that would be appropriate.
<rbasak> (or metapackages)
<rbasak> networkd Depends: systemd-networkd-support, systemd-networkd-support Depends: systemd >= X, etc.
<rbasak> (or, virtually, a high enough version of systemd Provides systemd-networkd support)
<rbasak> Seems ugly to me :-/
<rbasak> (also I've never seen that done before, so perhaps there's a reason or better way)
<juliank> apt 1.3.5 patch list: https://github.com/Debian/apt/compare/1.3.y...julian-klode:1.3.y?expand=1 - if someone thinks I missed something, or can drop some changes, let me know.
<juliank> This brings yakkety up to 1.4~rc2 in terms of important bug fixes
<juliank> Highlights: * Bugfix for partial requests on slashdot * The icon tarball thing fixed * sanitized environment for privilege dropping processes * installation ordering / progress fixes
<juliank> I think most of that, excluding the installation ordering/progress stuff will also apply to 1.2 (xenial)
 * juliank should force himself to more regular SRUs
<juliank> Changelog: https://paste.ubuntu.com/24047071/
<juliank> Some fixes are not really that important, but tiny, so I still picked them
<juliank> stuff like "bash-completion: Only complete understood file paths for install"
<nacc> mdeslaur: rbasak: ack, was just thinking through alternatives, as I read through your prior discussions on the topic
<juliank> Oh, is there a way to search for apt bugs where I added xenial or yakkety tasks?
<rbasak> juliank: https://bugs.launchpad.net/ubuntu/xenial/+source/apt
<rbasak> Linked on the right at https://bugs.launchpad.net/ubuntu/+source/apt
<rbasak> No idea how to "union" that with yakkety though.
<juliank> rbasak: thanks, that's OK
<juliank> rbasak: It's more of an or anyway :)
<rbasak> Good point :)
<juliank> Now I just have to annotate the commits with the proper launchpad bugs
<caribou> barry: ah, that would explain why I don't see the LTO optimisation flags, they're passed in the make command during the build
<juliank> Heh, we now have coverage information on the whole 1.3.4 to 1.3.5 diff, that seems useful: https://codecov.io/gh/julian-klode/apt/compare/15f32c417545d6e19d459004d510b7101bf6683f...e5f9d66fcc67c1cad96cbb3efa6cc1226ba0ccbf/diff
<cult-> when is this bug going to be released? https://bugs.launchpad.net/ubuntu/+source/libodb/+bug/1588330
<ubottu> Launchpad bug 1588330 in libodb-sqlite (Ubuntu Yakkety) "Incompatible builds of libodb and libodb-mysql" [Undecided,Fix committed]
<nacc> do isolation-container autopkgtests inherit the enviornment from the top-level (that is, values like no_proxy?)
<slangasek> sil2100: nowadays the TB has delegated to the SRU team for the SRU exceptions; so what's your sense of whether thunar should be granted an exception?  Do you have confidence that the upstream QA for the microrelease was up to our standards, despite there not being autopkgtests?
<rbasak> xnox: bug 1588330 above - not verification-done?
<ubottu> bug 1588330 in libodb-sqlite (Ubuntu Yakkety) "Incompatible builds of libodb and libodb-mysql" [Undecided,Fix committed] https://launchpad.net/bugs/1588330
<rbasak> slangasek, sil2100: do we (~ubuntu-sru) explicitly grant and document these exceptions currently? For consistency, I feel that we should.
<slangasek> rbasak: if it's intended to be a standing exception, yes
<slangasek> if it's a one-off, the paperwork doesn't pay for itself
<rbasak> Perhaps we should ask uploaders to document in the bug whether it should be a standing or one-off exception (or ~ubuntu-sru could just edit the bug description on approval, etc).
<rbasak> I agree it's not worth anything further for a one-off.
<rbasak> s/edit the bug description/just comment/ even.
<juliank> APT 1.2.20 queue: https://github.com/Debian/apt/compare/1.2.y...julian-klode:1.2.y?expand=1
<juliank> Riddell: ^ might be interested :)
<Riddell> juliank: Debian uses github?
<rbasak> powersj: so I forgot to mention. The next thing that'll happen is a component mismatch, probably leading to an email to ubuntu-release@ saying that those packages are incorrectly in universe. An archive admin will spot this in the component mismatches report, find the approved MIR bug, and override those packages to main. So it's not entirely done, but needs no further action from us as the MIRs are
<rbasak> approved.
<juliank> Riddell: We mirror apt there, and I merge pull requests from there
<juliank> Well, some bot mirrors there, not sure who is really responsible for that
<rbasak> powersj: http://people.canonical.com/~ubuntu-archive/component-mismatches.svg and related files in that directory are the component mismatches reports
<Riddell> juliank: yay for "Only merge acquire items with the same meta key" merge :)
<powersj> rbasak: ok thanks that will save me a few minutes of panic later today :)
<juliank> Riddell: Yeah, now I just need to take a look at some failing tests, and then it should be ready for upload in one to two days.
<juliank> Hmm, nothing troubling actually. Just the sections of some test packages being different
<cult-> rbasak: can you set it to verification-done?
<rbasak> cult-: not without being confident that it was actually verified and what was verified, no.
<rbasak> That's why I asked xnox, because it looks like he knows and that approach is least likely to end badly.
<xnox> rbasak, verified in xenial; did not finish verification in yakkety; i do have container about.
<xnox> for it.
<xnox> cult-, rbasak: the bug has not aged yet. It's only 5 days old, thus will not be released yet.
<cult-> how many days need to be passed?
<cult-> ah damn this is crazy
<rbasak> See https://wiki.ubuntu.com/StableReleaseUpdates for full details.
<rbasak> Taking care to not regress millions of users isn't crazy.
<cult-> i understand it, but the current binaries in universal are unusable
<rbasak> And for 16.04 they've been unusable for 10 months. Two days won't make a difference.
<cult-> so there's not much to break, if its already broken
<cult-> rbasak: ok
<xnox> cult-, you can use binaries from xenial-proposed which are mirrored world-wide
<xnox> you know that, right?!
<cult-> yes
<cult-> :P
<juliank> Riddell: sudo add-apt-repository ppa:deity/apt-1.2 - 1.2.20~rc1 should appear in the next hour or so, it's currently building
<Riddell> that's awfae clever
<nacc> xnox: since you're around, have you looked any further at the libaws/liblog4ada regressions in z-p? I am going to try and talk to the Debian maintainers if they have any suggestions
<xnox> nacc, i ran a test with all-proposed and it did pass and migrate zlib for me
<xnox> (i think libaws test passed)
<nacc> xnox: interesting! thanks for that info!
<xnox> nacc,and I don't care any more =) doko says that these things should be rebuild in order until it's right =/
<xnox> but i'm not sure how to establish that
<nacc> xnox: ack
<toabctl> could somebody sponsor the fix with https://bugs.launchpad.net/ubuntu/+source/zypper/+bug/1638306 please?
<ubottu> Launchpad bug 1638306 in zypper (Ubuntu) "[SRU] zypper binary shipped w/ Ubuntu Xenial requires rebuild (relocation error)" [High,Triaged]
<nacc> toabctl: is it fixed in Y and Z? Your versioning also makes it hard to be sure the sort is correct relative to new versions. Maybe not critical, but e.g., 1.12.4-1ubuntu0.1 would make it clearer that it's an SRU (to me)
<nacc> tbh, i'm also surprised anyone uses zypper on ubuntu, but that's neither here nor there
<sarnold> wow I didn't know we packaged that :)
<toabctl> nacc, you just need an rebuild. there is nothing to fix
<toabctl> nacc, sarnold we need it in the openstack CI which runs on ubuntu but we also want to create suse images there. for that zypper is useful
<nacc> toabctl: i understand, and even my version string above is wrong, since 1.12.4-1ubuntu0.1 would sort ahead of 1.12.4-1build1 (which is what is in y/z)
<toabctl> anyway - this bug is really easy to reproduce (zypper -h) and really easy to fix and test the fix.
<nacc> toabctl: my worry is that '1.12.4-1+b1' is already in use by Debian as a version string (unstable)
<nacc> toabctl: it is wrong (aiui) to use that same string in ubuntu
<sarnold> heh, "Binary-only non-maintainer upload for amd64" considering we don't do binary uploads in ubuntu, there's no maintainers, and you can't easily upload for just one architecture, I think every word in that sentence is a lie :) Also the cake is a lie.
<nacc> toabctl: i fully agree your fix is probably correct, but i'm not comfortable sponsoring it as-is
<Unit193> nacc: I've seen '1.12.4-1~ubuntu0.1'
<nacc> Unit193: yeah i'm thinking the ~ is needed here to sort correctly
<toabctl> doko, what the correct version string for a pkg rebuild?
<Unit193> And I've seen cases like ca-certs that don't add that, thus the version in devel is older. :/
<sarnold> what's the core cause of this fault? it feels unlikely to me that a rebuild alone would be sufficient.
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | 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: mterry
<sarnold> (I mean, sure, a rebuild is likely to -fix- it but what would prevent this from recurring?)
<toabctl> sarnold, I guess a tighter dep on libzypp could help. but this is a bugfix
<sarnold> toabctl: it -does- pass the "minimal effective" test quite well :)
<sarnold> ahhhh, libzypp isn't built from the same source package as zypper; that's surprising.
<toabctl> sarnold, it's a different thing
<smoser> anyone else having issues with vpn ?
<sarnold> smoser: zesty?
<smoser> barry, ? i see you touched network manager recently... /me is unable to connect to a vpn
<smoser> yeah, zesty
<smoser> oh. fun. jgrimm
<nacc> smoser: you need to do a tweak
<smoser> is last-touched on openvpn
<nacc> smoser: https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes#OpenVPN
<nacc> smoser: verify by name exactly in NM's advanced settings, then elid the '/CN:' string in the textbox
<jgrimm> smoser, there's a pending doc update internally to the VPN notes as i understand it too
<smoser> nacc, edit to ? canonical.com ?
<nacc> smoser: the canonical vpn definition in NM
<smoser> nacc, not following. i set " verify by name exactly in NM's advanced settings".
<smoser> but then 'elid' (i assume edit) the '/CN:' string... edit to what ?
<smoser> i currently have /CN=access.is there
<jgrimm> smoser, change to 'access.is'
<barry> yeah i saw some recent changes to the wiki page, but haven't tried connecting to the vpn yet
<smoser> ok. that worked. \o/
<nacc> smoser: sorry, yeah, just remove the '/CN=' part
<smoser> elid is esparanto for delete
<nacc> *elide :/
<infinity> nacc: I tossed some comments on that zypper bug you were looking at.
<sarnold> infinity: what do you mean with "but the packages don't"?
<smoser> for anyone else who sees this..
<smoser>  http://paste.ubuntu.com/24048268/
<sarnold> that's a bit of packaging I never deal with :)
<infinity> sarnold: The binary package name is libzypp, not libzypp1503
<infinity> (Though, in this case, there appears to *also* be an undeclared ABI break happened within the upstream SONAME of 1503, but hard to throw stones at upstream when the packaging is so clearly broken anyway)
<sarnold> interesting, I never noticed just how many lib* packages encode version numbers in the names. it always felt like a minority..
<infinity> sarnold: Any lib* package that's an ELF library with an SONAME should use the SONAME as the package version.
<infinity> s/package version/package name/
<infinity> Brain and finger disagreement.
<sarnold> infinity: thanks for the explanation :)
<infinity> There are some packages so old that they don't conform (zlib1g might be one of the only ones left?), but anything that's had an ABI bump since the glibc transition follows that pattern or is wrong.
<infinity> And with versioned provides, we could finally s/zlib1g/libz1/ if we really wanted to.
<sarnold> and confuse the heck out of everybody??
<infinity> But I kinda like that it's had a stable ABI for so long that it's lived through decades of policy.
<nacc> infinity: thanks
<nacc> infinity: and just to be clear, re: your last comment, no rebuild is needed for zesty; but xenial only
<infinity> nacc: Yeah, yakkety (and thus zesty) got a rebuild for a different transition, which happened to fix this bug in the process. :P
<nacc> infinity: yep :)
<infinity> nacc: My guess is that the Debian maintainer maintains both packages and hand-waves over the glaring packaging bug by not uploading zypper until libzypp is built everywhere.  Which broke in Ubuntu when we mass-synced.
<mterry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | 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:
<nacc> infinity: that makes sense
<toabctl> nacc, thanks for sponsoring. Where can I find the package now? will it popup in proposed?
<nacc> toabctl: https://wiki.ubuntu.com/StableReleaseUpdates
<nacc> toabctl: SRU team needs to handle it once it's built
<toabctl> nacc, ok. thx
<nacc> lamont: hey, just touching base on maas and python-django. Anything I can do to help?
<nacc> slangasek: re: libemperl-perl, I think this is actually a change in behavior in pkg-perl-tools 0.34 (this is when the tests started failing in debian as well). a) they updated autopkgtest to run with PERL_DL_NONLAZY=1 and b) they also added a whitelist functionality for output during a test run, but libembperl-perl doesn't use this for output; and I think it's actually correct for libembperl to emit
<nacc> the redefinition error it does when that environment variable is set
<jackpot51> I have patches for WPA 2 enterprise support in ubiquity - what should I do with them?
<lamont> nacc: I've been working through just how much work it is, and it's not quite trivial
<jackpot51> Patches can be seen here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1107935
<ubottu> Launchpad bug 1107935 in ubiquity (Ubuntu) "Support for WPA Enterprise wireless networks" [Wishlist,Triaged]
<jbicha> jackpot51: it's best to subscribe ~ubuntu-sponsors to a bug when you attach a patch, https://wiki.ubuntu.com/SponsorshipProcess
<jackpot51> ok, cool
<jackpot51> Done
<jackpot51> Here is an additional change for network-manager-applet: https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1667129
<ubottu> Launchpad bug 1667129 in network-manager-applet (Ubuntu) "Python cannot create NMGtkWifiDialog" [Undecided,New]
<nacc> slangasek: in any case, sent to Debian as well, uploaded, and retriggering the tests. I think perl should migrate now
<Unit193> cjwatson: It's safe to presume putty won't be making it into Zesty?
<Unit193> !info libpcsclite1 yakkety
<ubottu> libpcsclite1 (source: pcsc-lite): Middleware to access a smart card using PC/SC (library). In component main, is optional. Version 1.8.14-1ubuntu1.16.10.1 (yakkety), package size 22 kB, installed size 70 kB
<Unit193> !info libpcsclite1 zesty
<ubottu> libpcsclite1 (source: pcsc-lite): Middleware to access a smart card using PC/SC (library). In component main, is optional. Version 1.8.14-1ubuntu1 (zesty), package size 22 kB, installed size 75 kB
<slangasek> nacc: cool!
#ubuntu-devel 2017-02-23
<sarnold> smoser: when you roll out the new cloud-init changes, could you include instructions on how to provide a datasource identifier via qemu commandline or libvirt or both? :)
<cjwatson> Unit193: not 0.68, but Simon's passed me some more limited security patches that are on my to-do list to apply.
<cjwatson> Unit193: at least probably not 0.68.  it seems like a stretch post-FF.
<Unit193> cjwatson: OK, thanks.  I've been using a git snapshot package for the Ed25519 support, was wondering if I could finally get rid of it.  As always, thanks for the info.
<cjwatson> Unit193: I'll think about it :)
<Unit193> :)
<doko> toabctl, nacc, xnox: about zypper: the right thing to do is to have a libzypp transition (which was not done when doing the GCC 5 transitions)
<pitti> Laney: hm, I can't push to autopkgtest-cloud any more; do you mind grabbing http://www.piware.de/tmp/0001-autopkgtest-web-charm-Fix-description-of-github-stat.patch ?
<pitti> Laney: I was looking what it would take to support alternative users for github requests, and spotted that in the meantime
<pitti> (turns out I was confused and we don't actually need this, though)
<Laney> pitti: righto
<Laney> I still haven't looked at that github stuff at all
<cult-> only 1 day left!!
<Laney> pitti: do you have a sec for a quick autopkgtest question?
<Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/armhf/b/bbswitch/20170222_094343_2af9f@/log.gz
<Laney> missing apt update I guess, but how's that meant to happen?
<pitti> Laney: that looks very odd indeed -- I see the partial apt upgrade from --apt-pocket=proposed, but not the one from --apt-upgrade
<pitti> oh, I see -- we usually hide it: apt-get update | tee /proc/self/fd/2
<pitti> ah no, it should appear on stdout for grepping for "Not Found", and also to stderr, so where did that go
<Laney> https://paste.ubuntu.com/24052958/
<Laney> with --debug
<zul> doko: ping...have you had a chance to look at those reviews yet?
<pitti> Laney: whee, where did the --apt-upgrade go to,  it's not there at all
<Laney> pitti: looks like it's meant to be in setup_commands, but isn't
<Laney> no wait, it is
<Laney> but it's after setup-canonical.sh
<Laney> and setup-canonical wants to do apt-get install build-essential on trusty
<pitti> I don't see it in e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/l/lxc/20170221_084939_cab44@/log.gz either
<pitti> Laney: it is? I don't see it in your pastebin at all
<Laney> pitti: https://paste.ubuntu.com/24053024/
<pitti> Laney: oh! so this is from setup-canonical (build-essential) indeed
<pitti> Laney: so yes, seems we need to run --apt-upgrade before setup-canonical then?
<Laney> seems like it
<Laney> maybe just swapping the add_argument() will do it?
<pitti> fun that this never broke before
<pitti> the argv.append() you mean? yeah, the order of --setup-commands is the one you give on the CLI
<pitti> Laney: untested: http://paste.ubuntu.com/24053032/
<pitti> Laney: I'm not completely sure that some of the setup scripts might need to run before upgrading the testbed
<Laney> pitti: meh, I would rather fix autopkgtest so the order you give stuff doesn't matter
<pitti> Laney: well, but it does
<pitti> we can't predict the order in which to run them if the user can't
<pitti> it's not a given whether you need to run some setup before or after upgrading; think firewall rules or other networking setup
<Laney> just make apt-upgrade always happen before setup commands
<Laney> hmm
<Laney> good point
<pitti> setup-testbed for sure needs to run before
<pitti> well, actually not, as long as we use custom images (but we don't for stables)
<pitti> I'd rather rearrange setup-canonical to install build-essential later, or just add an apt-get update right before it
<pitti> (last is easiest, but also costs a few seconds extra)
<Laney> what's this Jenkins testbed comment?
<Laney> is that still relevant?
<pitti> Laney: yes, it is; until around that time we ran stuff on handcrafted VMs which had build-essential pre-installed
<pitti> Laney: later on we fixed tests to declare that as a test dep if they needed to build stuff, but our standard cloud images don't have build-essential
<pitti> so when we moved to the "new" infra, a lot of tests failed due to missing gcc and the like
<pitti> so either we SRU all those to trusty, or (what we opted for back then) we just grandfather this to install build-essential into trusty testbeds
<Laney> pitti: ok, so it's a transitional thing that was later fixed, that makes sense
<Laney> I'm worried about that MTU thing if I put the --apt-upgrade first
<pitti> Laney: yeah; as a quick fix I'd just add an apt update into setup-canonical (for trusty)
<Laney> pitti: Yeah, but then I get worried about dealing with that being flaky
<Laney> Maybe it won't be
<smoser> sarnold, we will have that, yes. how would you use it?
<smoser> are you using the ec2 metadata service?
<pitti> Laney: copy the retry bit from lib/autopkgtest_args.py?
<Laney> right
<pitti> Laney: a simple apt-get update || (sleep 15; apt-get update) should probably do, too
<Laney> I did that for now (well, 10 instead of 15)
<smoser> rbasak, is it approved behavior still for me to run usd import if there is a package missing that i want ?
<smoser> or is there a "proper" way to get it
<smoser> by 'run', i mean run with push
<rbasak> smoser: yeah just run with push
<rbasak> usd import -l racb -v foo # is what I use
<smoser> usd import -v --directory=foo --lp-user=smoser --lp-owner=usd-import-team foo
<smoser> is what my wrapper does
<smoser> i'll drop explicitly adding the --lp-owner
<doko> zul: networking-bagpipe networking-bgpvpn os-faults accepted (wondering who else is doing source reviews ...)
<zul> doko: thanks!
<LocutusOfBorg> pitti, any idea about acct and  https://wiki.ubuntu.com/Teardown ?
<LocutusOfBorg> I would like to drop the merge
<pitti> LocutusOfBorg: https://merges.ubuntu.com/a/acct/acct_6.5.5-2.1ubuntu1.patch is wrong anyway
<pitti> LocutusOfBorg: well, the debian/rules portion is
<LocutusOfBorg> yes, the override in rules file
<pitti> debian/acct.init.d is fine (and the only thing that is relevant)
<LocutusOfBorg> sooooo sync?
<pitti> if you want to go back in sync, it's not the worst thing in the world
<pitti> it should at least be reported in Debian though, and applied there
<LocutusOfBorg> is this thing still an issue with systemd?
<pitti> although in systemd it's completely irrelevant
<pitti> no, if a service is running, it will be stopped regardless of what that LSB header says, it's only a small optimization in Debian under sysvinit
<LocutusOfBorg> so, since we don't support multiple init systems...
<pitti> LocutusOfBorg: so yes, go sync it
<LocutusOfBorg> done thanks
<pitti> dropping deltas is always nice
<LocutusOfBorg> maybe I can commit on debian git
<LocutusOfBorg> done :)
<kierqueen> how id a package made ? after compiling my program using make ?
<kierqueen> what then shall I do , use tar to compress, and archive
<kierqueen>  then where did .deb come in the story
<kierqueen> nacc: hi
<nacc> kierqueen: ok, are you asking how to make a new package?
<kierqueen> nacc yes
<kierqueen> nacc sorry for the late reply hope you don't mind
<nacc> kierqueen: it's fine
<nacc> kierqueen: you don't really need to use bzr, of course
<nacc> kierqueen: http://packaging.ubuntu.com/html/packaging-new-software.html is just a guide
<kierqueen> yeah, the nwhat shall I use ?
<nacc> https://wiki.debian.org/HowToPackageForDebian may also help
<kierqueen> I have a ismple C program I want to package it ?
<nacc> kierqueen: technically your SCM choice is irrelevant
<nacc> kierqueen: if it's a simple application, you may wnat to snap it
<nacc> kierqueen: http://www.snapcraft.io/
<nacc> kierqueen: requires some ramp-up, but a lot less knowledge of debian packaging
<nacc> kierqueen: why do you want to package up your C program as a .deb?
<kierqueen> dude most binaries that you download are in C or C++
<nacc> kierqueen: binaries are not in a language.
<kierqueen> flightgear a large game, and tons of other packages of .deb they are all programs
<kierqueen> binaries are compiled, their source is C or C++ usually or python
<kierqueen> I don't use java
<nacc> kierqueen: i genuinely asked to help -- making your own .deb for a simple program is probably overkill
<nacc> kierqueen: if it's a simple program, snapping will be fastger
<nacc> *faster
<kierqueen> yeah I like ubuntu is always lenient on you. actually I migrated from arch, so that old overkill arch habit
<kierqueen> In arch we use PKGBUILD and make that, if there is no build file for a software
<nacc> kierqueen: i know nothing about arch. If you insist on building your own .deb, read the above guides (and you can use dh_make to frame out your pacakge, potentially)
<kierqueen> nacc: I guess ubuntu is so friendly, that I wont need it at all :)
<kierqueen> and I am not doing a computer related job either
<nacc> kierqueen: i have no idea what you're talking about now
<kierqueen> so I don't need it , i feel
<kierqueen> nacc: ?
<kierqueen> I don't need it ?
<nacc> kierqueen: you don't need what?
<kierqueen> I am not a software developer, to package a thing ?
<nacc> kierqueen: I don't know if you need to package something or not
<kierqueen> to make a pakcge of a source ? why should I?
<nacc> kierqueen: I don't know, you asked the question...
<kierqueen> why should I ? I am not getting paid anyway
<kierqueen> why should anyone else if they are not getting paid, unless they are stupid, and want to kill their time
<viral_mutant> I am building a deb package. I need to include a bunch of service files into the package. I dumped all the files in debian directory
<kierqueen> nacc: there are lots of linux hobbysts out their who want to kill their time
<nacc> kierqueen: ok, i'll assume you're trolling now
<kierqueen> lol
<viral_mutant> but it picks only the one which matches the name exactly
<kierqueen> no I am not
<nacc> viral_mutant: the name of the pacakge?
<kierqueen> nacc I don't have time to waste on trivial pc matters, there are other things in my llife, and ubuntu makes things easier, so no need , unless I get paid, but I don't DO A JOB IN THAT category
<nacc> kierqueen: i have no idea why that's relevant to discussing why you want to package your simple C program. I guess you're saying you don't. Then I don't understand why you asked the question in the first place.
<viral_mutant> I am building openstack-account package. And the service files are named openstack-account.service, openstack-account-auditor.service, -reaper.service etc
<kierqueen> nacc you are right, I don't neeed it , I misjudged
<viral_mutant> it includes only openstack-account.service in openstack-account.deb package
<nacc> viral_mutant: right, by default, dh_systemd will only install services named for the package, maybe?
<kierqueen> was just curious
<nacc> kierqueen: and you were given guides, and several suggestions
<kierqueen> that's all nacc nothing else, no other purpose
<viral_mutant> nacc: but there must be a way to override it
<viral_mutant> like there is for the init files
<nacc> viral_mutant: i think you need to override dh_installinit in your rules and specify to install multiple named services
<nacc> viral_mutant: that's where that default is specified (dh_installinit by default uses the package name)
<viral_mutant> yes, I am trying with that
<viral_mutant> but itâs not picking it. The man page says that âname option works for init files
<viral_mutant> there is no mention of service files
<nacc> viral_mutant: the manpage says it works for all types, what versin of ubuntu are you on?
<viral_mutant> 16.04
<sarnold> smoser: just the usual stuff I think: create user with ssh keys, install different packages based on the 'type' of VM I want to spin up, etc
<nacc> http://manpages.ubuntu.com/manpages/xenial/en/man1/dh_installinit.1.html "associated defaults files, as well as upstart job files, and systemd service files"
<viral_mutant> I am looking at manpage on the net
<nacc> viral_mutant: can you pastebin your d/rules?
<nacc> viral_mutant: and the output from building your package
<smoser> sarnold, where do you do it ?
<smoser> locally with kvm you mean ?
<smoser> i suspect you'll be ok if you're launching things locally, and the intent is to not cause issue on any cloud. but just trying to get more example so i can (if possible) make sure i *dont* break you
<sarnold> smoser: well, I haven't -written- my libvirt NIH yet :)
<sarnold> smoser: I'm still NIHing simplestreams..
<smoser> :)
<sarnold> which btw serde was able to derive implementations piece of cake. Amazing thing.
<smoser> ?
<sarnold> serde is rust's magic serialization / deserialization framework
<smoser> oh ok.
<smoser> sarnold, well, if you use NoCloud (attached disk) it should all just work. if you are planning on using another datasource, then you'll have to "fake" out that datasource.
<sarnold> smoser: thanks for the tip :D
<smoser> if you're able to modify the kernel command line, or put a config in place, then you can do that too
<smoser> kernel command line:
<smoser> ci.ds=Ec2
<smoser> will make you do ec2.
<sarnold> ooooo
<sarnold> that's the magic sauce :)
<viral_mutant> nacc: here is the d/rules file http://pastebin.com/MuiQcP19
<sarnold> thanks smoser :)
<viral_mutant> I am using rules file bundled with Ubuntu swift-account package as reference
<nacc> viral_mutant: did you read the manpage? debian/package.name.init,
<nacc>            debian/package.name.default and debian/package.name.upstart
<nacc> viral_mutant: which to me implies you need to put the .service file in a similar named structure
<juliank> Mmh, apt seems to be tricky today. It failed three times in the download progress test. I know that's an unreliable test, but that's a new low (or rather, a high)...
<juliank> Let's give that one more go. Everyone else did it right, just armhf wants to annoy me
<juliank> Not that it's urgent with beta freeze, but it's still fairly annoying.
<pitti> juliank: wrt. debian bug 855954 -- is there some version of "apt-cache policy pkg" that *only* gives me results for the package pkg?
<ubottu> Debian bug 855954 in autopkgtest "autopkgtest: can't handle packages with a + in its name" [Normal,Open] http://bugs.debian.org/855954
<pitti> juliank: by default it seems to do some kind of substring matching, and enclosing it between ^ and $ then gets confused by '+' in the package name
<pitti> juliank: i. e. some equivalent of apt-get source's --only-source option?
<pitti> I want to know the candidate version of a given package -- perhaps I shouldn't be using apt-cache for that
<juliank> pitti: Not sure, I don't think so. Maybe ask python-apt instead
<pitti> juliank: I can't assume that this is installed
<juliank> pitti: Use apt-cache show <pkg>/candidate
<pitti> juliank: ok, thanks; I just wanted to know whether I'm missing something obvious
<juliank> pitti: But I'm not sure when /candidate was added to show, so please try if you need to run that on old distros :)
<pitti> yeah, it needs to work on precise, will check; thanks!
<pitti> (if it works on trusty, I could kick the code in a few months :) )
<juliank> pitti: Hmm, that probably does matching as well
<juliank> pitti: Maybe just escaping the allowed regex characters, and turn it into an anchored regex is easier
<pitti> yeah, I'm currently trying that; a bit fiddly with posix shell and nested $(), but I'll pour the right amount of escaping into it :)
<pitti> $ dash -c 'pkg=minisat+; apt-cache policy "^$(echo $pkg | sed -r "s/([.+])/\\\\\1/g")\$"'
<pitti> ain't that obvious :)
<juliank> pitti: Whoa, what kind of regex is that?
<pitti> juliank: well, apparently the one that tells apt-cache policy "please give me *THIS* package name *ONLY*" :)
<juliank> pitti: The \  have an uneven number, that's a bit odd
<juliank> with one more \ it works as well
<juliank> or not
<pitti> juliank: yeah, true that
<pitti> (haven't tested, but it sounds plausible)
<juliank> well, it gives me "minisat \+"
<pitti> \\\\ through the two shells becomes \
<juliank> Ah no, input error
<pitti> and \1 is the backref for sed
<juliank> Actually, the number of shells does not matter
<juliank> Just running echo minisat+ | sed ... in the terminal has the same result as putting that inside a dash -c
<juliank> $() has some odd quoting rules
<pitti> juliank: TBH, I kept adding \ until it worked..
<pitti> the sophisticated term for that that hides the fact that you don't understand what you are doing is "Test Driven Development" :)
<acheronuk> barry: gpgme -> release seems to be happening :)
<barry> acheronuk: yep, i believe it was blocked for beta1.  yay
<nacc> whew and it looks like perl will transition too
<juliank> I think I'm about to give up. I tried running the apt tests on armhf 4 times now, but they still fail with one of these test cases that fails from time to time
#ubuntu-devel 2017-02-24
<nacc> jbicha: iirc, imagemagick (and others) are stuck because of emacs25?
<jbicha> yes
<sarnold> are you sure? here I see only 'Pass' and 'Always failed' results http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#imagemagick
<nacc> sarnold: in update_output.txt
<nacc> sarnold: and the new emacs25 is stuck in z-p, which maybe has the fix (not confirmed yet)
<nacc> sarnold: because it failed to build on arm64 :/
<nacc> sarnold: so stuck, but in a different place :)
<juliank> If people here are interested: I'm currently looking add BLAKE2 for use in the repository (Packages and Release files). I posted some results on deity@l.d.o but really only amd64 so far
<sarnold> juliank: nice, thanks
<zul> doko: ping can we get them out of binary new as well?
<sunweaver> hi! Where can I see what packages from Debian are _not_ pulled into Ubuntu on a regular basis. I.e. I am talking about a package that is in Debian, but not at all in Ubuntu.
<jbicha> sunweaver: I don't have an exact answer to that but these packages are prevented from being synced to Ubuntu because either Ubuntu doesn't want them or the packaging differs:
<jbicha> https://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<rbasak> sunweaver: anything that has an Ubuntu delta because of "ubuntu" in the package version string.
<rbasak> (or for some other reason, for example Ubuntu is "upstream" of Debian)
<rbasak> Plus the sync blacklist.
<rbasak> (as jbicha mentions)
<jbicha> this shows some packages that have been deleted from Ubuntu but still present in Debian unstable
<jbicha> https://people.canonical.com/~ubuntu-archive/auto-sync/current.log
<rbasak> That's it. Everything else is auto-synced every cycle AFAIK.
<sunweaver> jbicha: rbasak: thanks.
<sunweaver> funnily, the package was not shown to be in Ubuntu on Debian's DDPO page.
<sunweaver> But a closer look on Launchpad revealed, that the package is actually in zesty.
 * sunweaver wonders if that is a qa.debian.org bug then.
<seb128> wgrant, cjwatson, hey, do you know how are langpack exports enabled? we still don't have any, I think to remember that p_itti said that somebody should set up in the cron on the launchpad side
<wgrant> seb128: I can do the LP side on Monday. Do you know how to do the other bits?
<seb128> wgrant, I should, I went over that with p_itti before holidays, I think I just need to add a crontab line for zesty to the langpack-o-matic instance once the tarball is there
<wgrant> seb128: Sounds plausible. I don't know that side of things well.
<wgrant> I'll let you know when we set up the LP cronjob.
<seb128> wgrant, thanks, I should be able to figure out the client side changes, let me just know the day you pick for the export so I can do the langpack build on the next day (https://dev.launchpad.net/Translations/LanguagePackSchedule suggest that export on tuesday would be good?)
<wgrant> seb128: That sounds ideal, indeed.
<seb128> :-)
<Unit193> sunweaver: You already got answers, but there's also https://launchpad.net/ubuntu/zesty/+missingpackages
<Unit193> bdmurray: Can you provide some context to LP 1667843?
<ubottu> Launchpad bug 1667843 in icecast2 (Ubuntu) "/usr/bin/icecast2:11:source_shutdown:source_main:source_client_thread:source_fallback_file:_start_routine" [Undecided,New] https://launchpad.net/bugs/1667843
<bdmurray> There's a full stacktrace in the Error Tracker for it
<Unit193> Right, but that doesn't help me..
<bdmurray> Unit193: The stacktrace at the error tracker doesn't help you or you don't have access to the error tracker?
<Unit193> Right, sorry.  I don't have access to it, so right now the only useful bit I can see is the title.
<bdmurray> Okay I copied the Stacktrace since there wasn't anything private in it.
<Unit193> Thanks!
<juliank> Do we want to ignore the apt test failure on armhf?
<juliank> Tried 5 times or so, does not seem to start working
<juliank> Stupid timing-dependent test
#ubuntu-devel 2017-02-25
<nacc> slangasek: Was this build cancelled automatically becuase it took too long? https://launchpad.net/ubuntu/+source/mongodb/1:3.4.1-3/+build/12006236
<nacc> slangasek: nm, I don't understand it really at all, it looks to have not been built for i386 at all; and is from experimental. I'll leave it alone
<slangasek> nacc: 'cancelled' usually means someone manually cancelled it
<nacc> slangasek: ok, that's what i wondered, but wasn't sure
<slangasek> nacc: ah - but if I look at the actual log, yes, it says 'killed after inactivity'
<slangasek> so if there's no output in the build log after 150 minutes, the builders assume something got wedged
<nacc> slangasek: got it, thanks!
<thibaultmol> There is a problem with the drivers for the gtx 10 series GPU's from nvidia which makes it so that install ubuntu is a pain in the *ss for new users. I wonder when this is going to be fixed? http://askubuntu.com/questions/795547/ubuntu-16-04-unable-to-boot-with-gtx-1080
<fossfreedom> thibaultmol: is there a bug report?
<cult-> xnox: thanks for your work
<cult-> have a good weekend
#ubuntu-devel 2017-02-26
<cult-> this bug is hauning me ever since 16.04 released
<cult-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1521173
<ubottu> Launchpad bug 1521173 in linux (Ubuntu Xenial) "AER: Corrected error received: id=00e0" [Medium,Triaged]
<cult-> its a very very bad bug
<est31> "I've thought about this problem a bit, but realistically I don't have time to do the fix I'd like to do /.../ Anybody else who is interested should feel free to take a crack at it."
<est31> lol
<Unit193> sarnold: Another benefit to Valid-Until I forgot about, ensuring that whatever mirror you end up with when using 'deb mirror://mirrors.ubuntu.com/mirrors.txt ...' isn't too far behind.
#ubuntu-devel 2018-02-19
<pitti> cjwatson: ack, thanks; it's all good now
<cpaelzer> hmm where can I find the quilt command that dpkg-source uses?
<cpaelzer> if it uses quilt internally at all
<cpaelzer> I have a patch that applied with quilt --fuzz=0
<cpaelzer> but buildpackage complains at dpkg-source to fuzz or be malformed
<cpaelzer> want to hunt down which malform it doesn't like that quilt just accepts as-is
<cpaelzer> ok found "patch -t -F 0 -N -p1 -u -V never -E -b -B"
<mvo> who is the best person nowdays to talk about autopkgtest issues? for snapd on bionic I see 2018-02-19 07:33:41 Executing autopkgtest:ubuntu-18.04-i386:tests/main/interfaces-many (2/261)...\nKilled and no indication why it got killed (that test runs for some time so maybe it hits a timeout?)
<mvo> (full log is https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/i386/s/snapd/20180219_073615_8f705@/log.gz)
<xnox> mvo, you can dump more artefacts to be stored in the artifacts.tar.gz like journal
 * xnox ponders if journal should always be stored in artifacts....
<mvo> xnox: will autopkgtest store in the journal why it did kill a run? if so, that sounds like I need to store that
<xnox> mvo, well, for example if it was OOM killed by the kernel, or a SIGBUS got hit, we would see that in the journal.
<xnox> or seccomp / apparmor / etc...
<xnox> mvo, it might not tell everything....
<mvo> xnox: thank you! I will follow your advise
<xnox> mvo, the systemd autopkgtest store extra things in artefacts; check e.g. debian/tests/upstream. Or there must be other docs where to stash extra artifacts.
<mvo> xnox: thanks again, thats very helpful
<cjwatson> seb128: FYI you can get LP to regenerate an MP diff without having to re-propose the whole thing.  https://launchpad.net/+apidoc/devel.html#branch_merge_proposal-scheduleDiffUpdates (or https://launchpad.net/+apidoc/devel.html#branch-unscan if the whole branch failed to scan)
<xevious> nacc: Are you working today or taking the holiday off?
<rbasak> It's a US public holiday today.
<rbasak> Oh. You might have just said that.
<rbasak> Anyway. I believe he's off.
<xevious> rbasak: That's what I figured. I'm working on the holiday so I can take tomorrow off.
<xevious> (Also, sorry - I though I had sent that like 20 minutes ago, but I apparently didn't hit enter.)
<tsimonq2> (I wonder what public holiday, I still have school...)
<seb128> cjwatson, thanks, that's good to know
<jbicha> cjwatson: any update on LP: #1736618 ?
<ubottu> Launchpad bug 1736618 in debconf (Ubuntu) "debconf: Switch GNOME frontend to gtk3" [Undecided,Confirmed] https://launchpad.net/bugs/1736618
<xevious> nacc: Patch for php-zeta-base... https://bugs.launchpad.net/ubuntu/+source/php-zeta-base/+bug/1750041/comments/5
<ubottu> Launchpad bug 1750041 in php-zeta-console-tools (Ubuntu) "incompatible with PHPUnit 6" [Undecided,New]
<valorie> tsimonq2: it's President's Day!
<valorie> aka Washington's Birthday
<tsimonq2> valorie: ohh
<tsimonq2> ok
<xevious> nacc: Patch for php-zeta-console-tools... https://bugs.launchpad.net/ubuntu/+source/php-zeta-console-tools/+bug/1750041/comments/6
<ubottu> Launchpad bug 1750041 in php-zeta-console-tools (Ubuntu) "incompatible with PHPUnit 6" [Undecided,New]
<xevious> Can someone queue the tests for php-horde-core to be run for the latest version (2.31.1+debian0-1ubuntu1) that's in bionic-proposed? The version listed under php-defaults (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php-defaults) is the one in bionic (2.30.2+debian0-1).
<xevious> You can just queue it for amd64. I'd like to see the result. It passes on my system with proposed enabled.
<xevious> Never mind about rerunning the tests. I found the results for php-horde-core later on the 'excuses...' page.
<nacc> xevious: i will do that tmrw (off today) and retrigger as needed
#ubuntu-devel 2018-02-20
<tsimonq2> tjaalton: About the XDG implementation bug we talked about last week, https://salsa.debian.org/xorg-team/debian/xorg/merge_requests/2
<krytarik> tsimonq2, tjaalton: As opposed to what that MR says it does though, it actually "only" makes sure that '/etc/xdg' is included in the variable if it is already set.
<tsimonq2> krytarik: I wouldn't consider that "only"
<tsimonq2> krytarik: Before this PR, it indiscriminately set it to /etc/xdg/xdg-$DESKTOP_SESSION and /etc/xdg
<tsimonq2> krytarik: Now, if it's empty, sure it still does that, but if it isn't empty, it does that and retains the original content
<doko> Preparing to unpack .../40-python3-sha3_1.0.2-2ubuntu1_amd64.deb ...
<doko> Unpacking python3-sha3 (1.0.2-2ubuntu1) ...
<doko> dpkg: error processing archive /tmp/apt-dpkg-install-SsTVVg/40-python3-sha3_1.0.2-2ubuntu1_amd64.deb (--unpack):
<doko>  trying to overwrite '/usr/lib/python3/dist-packages/sha3.py', which is also in package python3-pysha3 1.0.0-0ubuntu3
<doko> xnox: ^^^
<xnox> doko, i guess i am missing breaks/replaces; had this now as well.
<mvo> another question about autopkgtests - I have a snapd test that is failing on amd64 right now. the failure looks like it is fixed with the latest systemd in bionic-proposed. is it possible that the autopkgtest vm still has an older systemd installed? and if so, how/when is that refreshed?
<seb128> mvo, you can retrigger the test with the systemd proposed version if you want
<seb128> mvo, I think by default it doesn't use all proposed
<seb128> mvo, "The Ubuntu CI system runs packages with only selected packages from -proposed available (the package which caused the test to be run);" is what is written on http://packaging.ubuntu.com/html/auto-pkg-test.html
<seb128> mvo, if you try manually you can -apt-pocket=proposed=src:foo
<seb128> mvo, or you can add &trigger=package/version to the web retry url
<mvo> seb128: let me try that, thank you!
<ddstreet> sil2100 re: lp #1644662, the build for gnome pkgs automatically updates the Uploaders:, how did you build a src pkg without the Uploaders: getting changed?
<ubottu> Launchpad bug 1644662 in gnome-themes-standard (Ubuntu Artful) "Icons missing when appearance setting is "high contrast"" [High,Fix committed] https://launchpad.net/bugs/1644662
<ddstreet> for my future reference, if i have to sponsor a gnome pkg again
<sil2100> ddstreet: I just did a regular rebuild with debuild -S just without touching the debian/control, as it was reverting its contents from what was already in the archive
<ddstreet> sil2100 ok interesting, that's all i did and it did update the Uploaders:
<sil2100> Sometimes it makes sense, but here it got brought back to a very early uploader list which seemed not that nice
<sil2100> hmm
<ddstreet> it does a 'smart' update of Uploaders: using locally-installed gnome files
<ddstreet> yeah, i didn't want to change the field, but if you check the control.in the field is @GNOME_TEAM@ so it has to be auto-populated at pkg build time
<ddstreet> anyway, glad it didn't change it on your system :)
<ddstreet> sil2100 btw, it uses the locally-installed /usr/share/gnome-pkg-tools/1/rules/uploaders.mk file to figure out what the Uploaders: list should be.
<jbicha> the Uploaders field is really irrelevant on Ubuntu so I wouldn't worry about it :)
<mvo> seb128: so &trigger=systemd/latest-in-proposed gave me systemd latest but not the latest snapd, can I can triggers? who is the expert in this these days? sil2100 maybe? (context is autopkgtest and how to ensure that my -proposed snapd runs against the -proposed systemd)
<jbicha> mvo: you can multiple &trigger= to your URL
<seb128> mvo, you need to &trigger= all the packages you want from proposed
<seb128> &trigger=systemd/proposed&trigger=snapd/proposed
<mvo> seb128, jbicha: thank you!
<mvo> \o/
<seb128> mvo, yw!
<caribou> Hello, I'm working on rebuilding gcc7.3 using sbuild which complains that it cannot resolve dependencies to gnat-7 & g++-7 which are native packages of gcc7.3. A=
<caribou> Any reason why this happens and why ?
<caribou> s/why/how to fix it ?
<caribou> hello to everyone btw, long time no see
<nacc> caribou: hi!
<nacc> caribou: can you paste the exact error (presumably from apt)?
<nacc> tjaalton: is it expected for intel-gpu-tools to no longer ship intel-gpu-overlay in bionic?
<nacc> tjaalton: LP: #1750605 (from #ubuntu+1)
<ubottu> Launchpad bug 1750605 in intel-gpu-tools (Ubuntu) "intel-gpu-tools no longer has intel-gpu-overlay application" [Undecided,New] https://launchpad.net/bugs/1750605
<caribou> nacc: the error is from sbuild : https://pastebin.ubuntu.com/p/yY5gnjqQd4/
<caribou> nacc: the gnat-7 & g++-7 dependencies come from the gcc-7 package being built & they're identified as :native in the d/control file
<caribou> nacc: I'm trying to build gcc-7 on Xenial btw
<nacc> caribou: looking if i can see
<nacc> caribou: possibly gcc needs to be bootstrap built?
<nacc> i'd almost assume it does
<caribou> nacc: well, that's something I don't know. But following your question sbeattie answered my query in #ubuntu-hardened so looks like I won't need to rebuild gcc-7 as gcc-5 in xenial-proposed has the retpoline patches
<caribou> which is what I was after
<caribou> I'm still curious to know what a "bootstrap build" is though :)
<tjaalton> nacc: looking
<xevious> Is anyone working on kernel 4.16 for Bionic?
<xevious> Or, are there any plans for it?
<xevious> There are some big improvements for vGPUs coming from Intel.
<tjaalton> no
<tjaalton> bionic will ship with 4.15
<tjaalton> nacc: looks like it needs a new build-dep
<nacc> caribou: i've done it for other tooling, you build a minimal part, and then use that to rebuild itself
<nacc> caribou: if that makes sense
<xevious> xnox: Oops. I forgot to run the php-zeta-base package through adt with proposed enabled.
<xnox> xevious, all i hope is that the messages makes some sense to you, because php is all greek to me.
<xevious> It makes perfect sense: 'object' is now a keyword in PHP 7.2
<tjaalton> nacc: pushed new i-g-t to sid
<nacc> tjaalton: thanks!
<nacc> xevious: you have a fix for that? i can help usher it through
<nacc> xnox: thanks for your help!
<xevious> nacc: Working on it now.
<nacc> xevious: thanks
<xevious> nacc: After I fix this, it's just Horde packages.
<xevious> I'll this php-zeta-base sorted out, then I'm taking the rest of the day off (it's my birthday).
<xevious> s/this/get/
<xevious> Brains.
<nacc> xevious: happy birthday! and thanks for your contribution to Ubuntu!
<nacc> xevious: yeah, i think i can get horde fixed today
<xnox> nacc, i see a bunch of horde uploads.... yet it is still a seas of red. Do we need, like an all-proposed=1 maas-retry of everything?
<xnox> nacc, or do you know what is still outstanding?
<xevious> A bunch of packages need to be updated for PHPUnit 6's namespaced classes.
<nacc> xnox: yeah, it will be that once i'm done uploading
<nacc> i made it up to php-horde-k on friday
<xevious> xnox: In most cases, it's just a search and replace. There are some places where it requires some manual updates, though. (Exception handling completely changed, for instance.)
<xevious> Is it possible to rename a file with quilt?
<nacc> yeah it's a bit slower than normal, since i have to build, test and then possibly test other entanged packages locally before uploading :)
<xnox> xevious, quilt add old new
<xnox> xevious, mv old new
<xnox> xevious, quilt refresh
<xevious> xnox: Thanks
<xevious> nacc: I attached a new patch for php-zeta-base.
<nacc> xevious: thanks
<nacc> xevious: i have a feeling php-horde-sessionhandler is relatively broken
<nacc> https://github.com/horde/SessionHandler/blob/master/lib/Horde/SessionHandler.php#L95
<nacc> emits a warning now
<nacc> https://bugs.php.net/bug.php?id=71038
<ddstreet> nacc are you able to review/sponsor lp #1718568 to bionic for me?
<ubottu> Launchpad bug 1718568 in isc-dhcp (Ubuntu Bionic) "dhclient-script fails to wait for link-local address" [Medium,In progress] https://launchpad.net/bugs/1718568
<ddstreet> i can upload to sru releases once it's in bionic
<nacc> ddstreet: yeah, i'm in the middle of some php stuff, but i can do it this afternoon worst case?
<ddstreet> nacc awesome thnx, no big hurry
<ddstreet> whenever you have time
<nacc> ddstreet: ack
<xevious> nacc: I uploaded a fixed patch for php-zeta-base... https://bugs.launchpad.net/ubuntu/+source/php-sabredav/+bug/1750041/comments/11
<ubottu> Launchpad bug 1750041 in php-zeta-base (Ubuntu) "incompatible with PHPUnit 6" [Undecided,Incomplete]
<nacc> xevious: sponsoring now
<ddstreet> smoser fyi the patch for lp #1718568 is on top of your dhclient.linux script ipv6 dad change, you may want to reivew also
<ubottu> Launchpad bug 1718568 in isc-dhcp (Ubuntu Bionic) "dhclient-script fails to wait for link-local address" [Medium,In progress] https://launchpad.net/bugs/1718568
<nacc> xevious: sponsored
<xevious> Nice.
<nacc> xevious: if you could look at the above php-horde-sessionhandler thing (i also don't use php much) ... imo, i might just need to disable the dep8 tests for now
<xevious> Where does adt store its containers? I'd like to move it onto this VM's enormous ramdisk.
<nacc> xevious: it's just using lxd's config
<nacc> xevious: if i had to guess
<xevious> nacc: "Headers already sent" probably means there was some unintended output before an explicit call to `header()`.
<xevious> (Or, any other method that sends a header...)
<nacc> xevious: sure, but, aiui, this is an intentional upstream change
<nacc> xevious: and it's not clear the php-horde-sessionhandler code is supposed to work
<xevious> They don't officially support PHP7+, though, right?
<xevious> nacc: If they're developing for PHP 5.x, they may be calling something that was valid code on that version of the interpreter, but on PHP7 it generates a warning that produces some output.
<xevious> If that happens before any methods that affect headers, it'll cause a "Headers already sent" error.
<nacc> xevious: not sure, tbh
<nacc> xevious: but, presumably, this passed with 7.0 and 7.1
<xevious> Is this blocking other packages, or could I look at it tomorrow?
<nacc> xevious: go enjoy!
<nacc> xevious: i can keep digging :)
<xevious> nacc: You're going to want to look for unintended output occurring somewhere before any of these lines are executed during that failing test: https://pastebin.com/wsRbzaHV
<nacc> xevious: yeah, i'll nee to run it by hand
<nacc> thanks!
<xevious> If you get frustrated with it, you can leave it for me to look at tomorrow.
<nacc> xevious: thanks, i'll let you know
<xevious> Is something holding up that php-zeta-base?
<nacc> i'm deep in some mock + reflection stuff now (different package)
<xevious> I see it listed as the latest upload, but it's not showing up in proposed. I'm just not sure where I go to monitor the process...
<nacc> xevious: it needs to build, then publish, then it needs to be seen by the dep8 runners
<nacc> xevious: i'll check on it this afternoon
<nacc> xevious: it passed locally for me
<xevious> Yeah, I totally goofed and forgot to test that one with proposed enabled when I first submitted a patch.
<nacc> xevious: fyi, it would appear php-horde-sessionhandler, which in turn affects php-horde-kolab-storage, and php-horde-kronolith all may be entanged due to the php7.2 session handling changes
<nacc> xevious: hey and look at htat php-horde-core is passing iwth all-proposed=1
<nacc> xevious: i think most of horde, but what i mentioned earlier is now passing. i'm uploading one last one and then i'm going to let the publisher settle before retrying php-horde-l* and on
#ubuntu-devel 2018-02-21
<xnox> nacc, go nacc go! =)
<nacc> xnox: heh
<tsimonq2> xnox: Now I have to import your qtbase upload into VCS manually :/
<tsimonq2> xnox: Also, block-proposed still belongs on bug 1749472 because mesa migrating will break Kubuntu and Lubuntu Next completely, so imho "because it's blocked by other things" isn't good enough :/
<ubottu> bug 1749472 in qtbase-opensource-src (Ubuntu Bionic) "mesa 18.0.0 will cause rendering errors in Qt applications" [Undecided,New] https://launchpad.net/bugs/1749472
<xnox> tsimonq2, i was meant to put the tag back in, post qtbase migrating
<xnox> tsimonq2, unfortunately we do not have block-proposed tags that block only some packages =/
<xnox> tsimonq2, thanks for puttin ghte tag back it.
<xnox> *in
<tsimonq2> xnox: I wonder if there's a way for me to implement syntax like block-proposed-qtbase-opensource-src
<tsimonq2> xnox: In fact, I'll look into that now and see if it's as simple as adding a few lines of code
<tsimonq2> xnox: Either way I'd appreciate if you could throw me a PR here merging your upload in: https://salsa.debian.org/qt-kde-team/qt/qtbase/tree/ubuntu+1
<xnox> tsimonq2, well.... one could have two bugs; one bug per source package; with tags and say "blocks bug #" whatever in description......
<xnox> lovely
<xnox> i'm yet to do a PR on salsa /O\
<tsimonq2> xnox: Right but I think that's far from ideal :)
<tsimonq2> xnox: I did my first PR on Salsa yesterday, there should be a fork button somewhere on https://salsa.debian.org/qt-kde-team/qt/qtbase
<tsimonq2> xnox: To be precise: https://salsa.debian.org/qt-kde-team/qt/qtbase/forks/new
<jbicha> xnox: I believe all you have to do is mark a specific package as Fix Released for block-proposed to no longer apply to it
<tsimonq2> jbicha: But it *isn't* Fix Released
<tsimonq2> jbicha: imho that's *super* hacky
<nacc> xnox: xevious: ok, just uploaded the last two php-horde*. I need to be afk tonight, but will retry what i see tmrw morning
<rizonz> xnox: hi! from nacc I understood you are maybe the one buidling the janus package ?
<rizonz> xnox: I have some issues with stopping the service, killing does not work and restarting has pidfile issues and never writes one on bionic
<xnox> rizonz, literarly no idea what janus is
<xnox> rizonz, i did a no change rebuild of it; as part of openssl1.1 transition, but that was 100% automated mechanical bot upload.
<xnox> rizonz, file a bug about it?
<xnox> rizonz, on launchpad, and maybe on Debian BTS too.
<rizonz> xnox: https://launchpad.net/ubuntu/+source/janus/0.2.6-1build1
<rizonz> ah ok!
<xnox> rizonz, as, I said, that was a blind upload. the source package is unmodified from debian.
<rizonz> your name was there
<rizonz> okay!
<rizonz> then I ask them
<rizonz> xnox: sorry to bother you :)
<xnox> no problem
<rizonz> heh, you make me hungry btw, you remind me about unox
<coolfish> Hi, in bug #1749790 a bigger autopkgtest-VM is needed to move the ganeti package from bionic-proposed to release (pass the test). Is there someone willing to set a bigger VM?
<ubottu> bug 1749790 in ganeti (Ubuntu) "ganeti: bionic proposed to release: bigger autopkgtest-VM" [Undecided,Confirmed] https://launchpad.net/bugs/1749790
<Unit193> nmap (7.60-1ubuntu4) bionic; urgency=medium
<Unit193>   * debian/control: Add dependency menu for zenmap. (LP #126331)
<ubottu> Launchpad bug 126331 in Jupiter "Instalation / Upgrade problem" [Undecided,New] https://launchpad.net/bugs/126331
<Unit193> Not exactly ideal..
<sil2100> rbasak: hey! Just so you know, I will be doing and approving some uploads to xenial today as part of preparations for the point-release - just letting you know so that you don't get confused that I'm doing an SRU shift today
<sil2100> I will not get in your way with normal SRUs
<rbasak> sil2100: OK. Thank you for syncing with me!
<rbasak> jamespage: in bug 1724622, shouldn't there be a test output summary attached to the bug?
<ubottu> bug 1724622 in openvswitch (Ubuntu Artful) "[SRU] openvswitch 2.8.1" [High,Fix committed] https://launchpad.net/bugs/1724622
<jamespage> rbasak: uh yes you are quite correct - juggling to many things
<jamespage> lemme dig those out
<rbasak> bdmurray: should ubuntu-release-upgrader in the Xenial SRU queue have a bug reference? Or is it special somehow?
<coolfish> Laney: do you remember me, asking for a bigger autopkgtest-VM for package ganeti? It seems ganeti just got default 1536MB RAM. In the mean time I opened bug #1749790. Could you please have a look at it?
<ubottu> bug 1749790 in ganeti (Ubuntu) "ganeti: bionic proposed to release: bigger autopkgtest-VM" [Undecided,Confirmed] https://launchpad.net/bugs/1749790
<tsimonq2> xnox: Did you get a chance to look at proposing a PR to qtbase on Salsa quite yet?
<xnox> let's do this now.
<tsimonq2> OK
<xnox> tsimonq2, ehhhm that repository is crazy
<xnox> tsimonq2, it appears to be missing 5.9.3+dfsg-0ubuntu1 5.9.3+dfsg-0ubuntu2 5.9.3+dfsg-0ubuntu3 5.9.3+dfsg-0ubuntu4 uploads.
<xnox> tsimonq2, what would you like me to do? rebase the ssl patch against ubuntu+1 branch, aka 5.9.4 tree?
<tsimonq2> Please
<xnox> tsimonq2, but what about other changes? =/
<tsimonq2> Merge those in if possible please
<xnox> tsimonq2, but it's like your upload =/ did you not push latest to salsa?
<xnox> tsimonq2, that repository is very weird usage of git.
<jamespage> rbasak: pasted my test results as you pasted or IRC conversation :-)
<Laney> coolfish: I messed up and didn't put it in one of the required files, fixing now
<xnox> tsimonq2, test building
<rbasak> jamespage: :)
 * rbasak looks
<Laney> coolfish: See if the next lot of tests for 2.16.0~rc2-1 are any better
<acheronuk> xnox: message from tsimonq2 via Telegram. He apologises, but he had to "abruptly leave for class".
<xnox> acheronuk, tsimonq2 - no worries, i should have something proposed on salsa soon.
<xnox> tsimonq2, https://salsa.debian.org/qt-kde-team/qt/qtbase/merge_requests/1
<xnox> no idea if this is right, or wrong.
<xnox> it builds
<mitya57> xnox: tsimonq2 wrote me in Telegram: âPlease pass on to xnox that I had to abruptly leave for classâ
<mitya57> oh, acheronuk already told the same :P
 * mitya57 is slow
<mitya57> I can look at your merge request though
<acheronuk> :)
<tsimonq2> Boy oh boy I want to graduate already
<tsimonq2> xnox, acheronuk, mitya57: Thanks,
<acheronuk> tsimonq2: sadly, won't the 1st time you wish that. high school -> college -> more quals :P
<acheronuk> *last time
 * mitya57 commented on xnox's merge request
 * xnox struggles to find notification of any sort from salsa
 * acheronuk suggests tsimonq2 does a few circuits to relax
<xevious> nacc: Updated the gist a little while ago... https://gist.github.com/iammattcoleman/88013cb5f92105b15a66ee2ada442a16#file-2018-02-19_124034_php-defaults-txt-L171
<xevious> nacc: Whenever you're ready, let's split up the remaining work.
<tsimonq2> grr acheronuk :P
<coolfish> Laney: thanks a lot, I'll watch the autopkgtest status.
<coolfish> Laney: regarding the version: our understanding is, that ubuntu syncs with debain-testing/buster (ganeti-2.15), ganeti-2.16rc2 is in debian-unstable/sid and AFAIK has open regressions.
<bdmurray> rbasak: Its special because the mirror file is just being updated. See https://launchpad.net/ubuntu/+source/python-apt/1.1.0~beta1ubuntu0.16.04.1 Maybe we should document that.
<rbasak> Ah. I had assumed that there's always a tracking bug, but looking at tzdata that isn't always the case.
<rbasak> bdmurray: how should I approach reviewing this?
<rbasak> Just a sanity check and accept?
<rbasak> And does sru-review work as normal?
 * rbasak goes afk for a bit
<bdmurray> rbasak: I'd check with sil2100 since he's leading the 16.04 point release
<sil2100> rbasak: yeah, leave that one for me, I'm not including tracking bugs for releasey things (if it doesn't make sense at least)
<sil2100> rbasak: I checked all the ADT failures and will be taking care of releasing it before the candidates are being created
<sil2100> After some sanity checking
<sil2100> There will be a few other uploads like that
<rbasak> ack
<nacc> xevious: i'm back now
<xevious> nacc: Good morning!
<xevious> nacc: Which packages are you working on? I'll take a handful that you're not currently looking at and add them to LP#1750041.
<xevious> ...and, ya know, work on them.
<xevious> Or, is there one in particular you'd like me to work on?
<nacc> xevious: the ones i don't know how to fix are php-horde-kolab-storage, php-horde-kronolith, php-horde-sessionhandler,
<nacc> xevious: all regressed because of php7.2 changes in how session works, i think
<nacc> xevious: it's the 'headers sent after...' messages
<nacc> xevious: it seems like in php <7.2, it was silently doing nothing
<nacc> now it is noisily warning
<nacc> xevious: i'll retry the others now
<nacc> xevious: would you be able to investigate those? or even a few of them (maybe just sessionhandler to start, as that is the root cause of the regression in kronolith, iirc)
<nacc> xevious: i need to do some MIR work today, but can pivot back to php in a few hours, i think
<nacc> well, that's a new one (running an autopkgtest.u.c retrigger): "A server error occurred.  Please contact the administrator."
<nacc> Laney: --^ would that be you?
<xevious> nacc: Yeah, I'll start with sessionhandler.
<nacc> xevious: thanks!
<nacc> xevious: iirc, the tests actually aren't failing
<nacc> but since php emits a warning, and stderr messages aren't allowed by default, the tests fail
<nacc> so there are two solutions, 1) silence the warnings or 2) fix the warnings :)
<nacc> i'd prefer the latter, but i couldn't figure them out
<nacc> slangasek: would you know who the administrator of autopkgtest.ubuntu.com is?
<slangasek> nacc: present
<slangasek> nacc: (Laney and myself)
<Laney> coolfish: We sync from unstable
<Laney> nacc: link?
<nacc> slangasek: Laney: https://autopkgtest.ubuntu.com/request.cgi?release=bionic&arch=amd64&package=php-horde-serialize&trigger=php-defaults%2F60ubuntu1&all-proposed=1
<nacc> i've not tried any others, since i don't want to just hammer the server with failures :)
<nacc> it was working fine for the first 3 or 4 packages I ran against
<nacc> (i'm working through the php-defaults queue that i fixed last night)
<slangasek> hmph
<slangasek> Laney: I'm on calls right now; do you have time to dig into this?
<Laney> yeah
<Laney> can't connect to the amqp server seems to be the problem
<Laney> :(
<xevious> nacc: Do you already make an LP issue for sessionhandler?
<xevious> *Did
<Laney> nacc: seems to be some maintenance going slightly awry
<nacc> xevious: no, you can just add tasks to the php-defaults bug, i think, if you want
<nacc> Laney: ok, thanks -- I'll hold off on further triggers for now, but others will probably hit it :)
<Laney> nacc: not a lot we can do, and it won't really cause a problem other than irritating you
<Laney> assuming britney is doing something sane like not thinking it has submitted requests ...
<nacc> Laney: ack -- do you have any idea when I should retry again? I know these will all pass once retriggered, just need to through them so we can get php migrated
<Laney> crashing
<Laney> that'll do
<nacc> heh
<Laney> nacc: dunno, I'm watching IS people try to fix it
<nacc> Laney: ah ok :)
<Laney> ah
<Laney> works now I think
<Laney> nacc: just clicked that link for you, feel free to run others
<nacc> Laney: thanks!
<nacc> Laney: yep, working again
<Laney> networking is useful, it turns out
<nacc> Laney: slangasek: thank you to both
<nacc> xevious: fwiw, i was reading other upstream code's changes to deal with the same messages with php7.2
<nacc> xevious: one of them had a commit message like 'do not call ini_set before session_start'
<nacc> Laney: hrm, i submitting a bunch of retriggers now, and none have showed up in http://autopkgtest.ubuntu.com/running .. usually they show up relatively quickly
<nacc> even if in the backlog
<nacc> "a bunch" = 30-40
<Laney> nacc: I can see a handful of tests being run by you there
<Laney> are there some missing? if so, which package/arch?
<Laney> (probably the /running page got a bit confused when its amqp connection went away)
<xevious> Laney: Which AMQP server are you using?
<Laney> rabbitmq
<nacc> Laney: sorry, let me see
<Laney> nacc: I've got https://paste.ubuntu.com/p/srVp6vtxg5/
<nacc> Laney: ok, that looks fine
<nacc> Laney: i think I was just impatient :)
<nacc> bdmurray: can you tell why LP: #1750842 was marked private?
<ubottu> Error: Launchpad bug 1750842 could not be found
<nacc> (the submitting user is asking)
<nacc> xevious: any luck?
<xevious> Still debugging. This is a doozy.
<nacc> xevious: yeah
<nacc> xevious: i got fairly deep into the package code and hte upstream bug reports about this change
<bdmurray> nacc: I can't see it with my lp account. Can you give me some more details?
<nacc> and then decided i really didn't know how to fix it :)
<nacc> bdmurray: i can subscribe you if that would help (the user subscribed me)
<nacc> bdmurray: apport filed it for them
<nacc> bdmurray: but they don't know why it's marked private
<bdmurray> nacc: is it tagged needs-amd64-retrace?
<nacc> bdmurray: it was, but is no longer
<nacc> bdmurray: does that make it private?
<bdmurray> nacc: It starts of as private w/ only the retracer subscribed, then after retracing the retracer leaves it private and subscribes ubuntu-bugcontrol. Its stays private because the Stacktrace might have sensitive information.
<bdmurray> nacc: Or maybe not bugcontrol but some intermediate team.
<bdmurray> nacc: yeah - crash bug triagers for universe or main should be subscribed by apport
<bdmurray> Well its really only one team but still named ubuntu-crashes-universe
<nacc> bdmurray: ah ok
<nacc> bdmurray: thanks for the explanation
<nacc> bdmurray: in this particular case, i don't see any team subscription being added after the retracer tag was removed?
<xevious> nacc: PHPUnit's output is breaking the test. `headers_sent()` returns FALSE before this line and TRUE after it: https://github.com/sebastianbergmann/phpunit/blob/master/src/TextUI/TestRunner.php#L283-L285
<xevious> Still working on a fix, but I at least tracked down the line where we go from working to broken.
<nacc> xevious: weird, but is that really a header send to PHP?
<xevious> As soon as any output occurs, PHP considers the headers sent.
<xevious> ...since you can't change HTTP headers after you start sending the page content.
<nacc> xevious: ah interesting
<nacc> xevious: but PHPUnit has always done this, afaict
<nacc> xevious: or, i guess i would think phpunit would be exec'ing php to run the test, so it'd be a new session?
<nacc> dunno exactly waht i mean, but it's weird to me that the runner's env would affect the runnee's
<xevious> Yeah, I agree. Still trying to figure out *why* that's breaking the test now.
<nacc> xevious: if you are able to get sessionhandler working, i hav ethe kronolith fixes for phpunit6 locallyu, and i can test against your updated version
<bdmurray> nacc: well subscribe me and I'll have alook
<nacc> bdmurray: done
<bdmurray> nacc: Oh, I think there was an LP issue overnight
<nacc> bdmurray: ah ok
<bdmurray> nacc: That doesn't seem to be it though so I'll look into more
<nacc> bdmurray: thanks, i'll let them know
<nacc> xevious: any luck?
<nacc> xevious: i wonder if this is related? https://github.com/yiisoft/yii2/pull/14959
<xevious> I think I found the fix
<xevious> Give me a few...
<nacc> xevious: per the comment there, do we need to add an output buffer?
<nacc> xevious: ok cool!
<nacc> xevious: it seems like a bunch of projects have added freeze/unfreeze logic upstream?
<xevious> nacc: output buffering didn't help. I got it passing but it's still complaining about the headers being sent.
<xevious> All its assertions pass, though.
<xevious> nacc: Which LP issue should I upload the patch to?
<xevious> n/m found it
<xevious> nacc: This issue is about removing packages unused, is there a separate issue about PHP 7.2 compatibility? https://bugs.launchpad.net/ubuntu/+source/php-phpdocumentor-reflection/+bug/1749783
<ubottu> Launchpad bug 1749783 in php-sabre-xml (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,Fix released]
<nacc> xevious: it's about anythiing blocking php-defaults (per the title)
<nacc> xevious: so it's fine to attach there
<xevious> Ok
<xevious> I've built up a strong distaste for Horde users.
<nacc> xevious: :)
<nacc> xevious: fwiw, a bunch of stuff should start migrating from proposed after i retriggered something like 400 tests :)
<xevious> Splendid
<nacc> xevious: and a bunch more are wedged because there are still some horde packages i need to hit
<nacc> i'm d/ling those now
<nacc> xevious: i don't have my mail open right now (having to build 20 or so more horde packages). let me know when you attach the patch and i'll take a look
<xevious> Will do. I got the tests to pass while inside the adt shell after one of the failures. However, when I applied those changes to the package and retested, a new issue cropped up: dealing with it now.
<nacc> xevious: thanks
<xevious> Woops
<xevious> nacc: https://bugs.launchpad.net/ubuntu/+source/php-horde-sessionhandler/+bug/1749783/comments/16
<ubottu> Launchpad bug 1749783 in php-horde-sessionhandler (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,New]
<xevious> nacc: I don't feel great about that patch because I supressed a few warnings to eliminate stderr output, but all of the assertions in the unit tests pass.
<nacc> xevious: do you want to ping the upstream about it? i know it's just in the tests, so the underlying code is unchanged, i just wonder if they would take it
<xevious> A large part of the fix came from them.
<xevious> Hold on though
<xevious> I think I might have figured out how to avoid supressing the warnings.
<xevious> nacc: Here's the majority of the fix: https://github.com/horde/SessionHandler/commit/d1a72d266117894be11f10645486cb13c7b1b40e
<nacc> xevious: oh great!
<nacc> xevious: can you add dep3 headers for that?
<nacc> (cf what `dpkg-source --commit` does)
<xevious> Some of my changes are definitely upstreamed.
<xevious> ..and some of the other changes are upstreamable.
<xevious> Let me try out this change, then we'll circle back to dep3 headers.
<nacc> xevious: thanks! it just lets us track where things come from and such
<xevious> nacc: Ok, I have a better patch that doesn't require supressing warnings.
<xevious> How do I do the dep3 stuff?
<nacc> xevious: so i'm looking for something like
<nacc> http://dep.debian.net/deps/dep3/
<nacc> specifically the Description, Origin, Author fields
<nacc> xevious: you can then use dep3changelog to genrate the changelog entry using that data :)
<nacc> xevious: let me know if you need more
<xevious> I'm splitting it up into two patches: one to pull in the file from upstream, and one with my changes to that file.
<nacc> xevious: ah great, that's a good way of doing it
<xevious> After reading the Debian documentation, it seemed like the right thing to do.
<xevious> Should I put myself or the upstream committer as the author for the first patch?
<nacc> xevious: if it's fully from upstream, i tend to use the upstream commitere/author
<nacc> xevious: is that working ok for you?
<xevious> Yeah, just making the debdiff now
<xevious> My local test has to finish, too.
<nacc> xevious: nice
<xevious> nacc: I've been keeping track of all my changes and plan on at least attempting to upstream them all. Some of the projects specifically say they're a PHP5 library, so I don't know if they'll accept PRs that make them PHP7-only.
<nacc> xevious: yeah, it's worth doing still, even then
<xevious> nacc: Here you go: https://bugs.launchpad.net/ubuntu/+source/php-horde-sessionhandler/+bug/1749783/comments/17
<ubottu> Launchpad bug 1749783 in php-horde-sessionhandler (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,New]
<nacc> xevious: reviewing now
<xevious> Thanks. I've got to head out to dinner soon, but I'd like to make sure it's good before I leave.
<nacc> xevious: yep, pulling it down now the patch looks good, i'll make sure it builds and passes locally
<nacc> and i'll test and push the dependent packages if it does
<nacc> xevious: fixed the LP entry (it needs to be LP:  to be seen)
<xevious> Oops! Thanks for pointing that out.
<nacc> xevious: np
<nacc> xevious: looks good
<nacc> xevious: i'll test the dependent packages and then upload
<xevious> Excellent.
<xevious> I'm heading out for the night. We'll see what's left, if anything, tomorrow.
<nacc> xevious: thanks again for all your help!
<nacc> xevious: ok, that didnt' solve the two related packages (afaict)
<nacc> xevious: definitely kronolith is related
<nacc> https://paste.ubuntu.com/p/CvSQBvRVf6/
<nacc> and for php-horde-kolab-storage with my local changes, i get: https://paste.ubuntu.com/p/ztZpBqrPbW/
<nacc> xevious: i'll update the bug, because it hink sessionhandler itself needs changes in order to work
<nacc> xevious: the reason i think the kolab-storage stuff is related, is that synchronizeList uses the session, i believe
#ubuntu-devel 2018-02-22
<bdmurray> nacc: So something was wrong with the Contents.gz file on the retracer which caused the retrace to fail because it couldn't find the package for the executable.
<nacc> bdmurray: interestin
<nacc> xevious: i'll ping you when i'm in tmrw
<Mirv> mitya57: tsimonq2: looks like Qt LTS for Ubuntu LTS, right? nice to finally have that combination :)
<acheronuk_> Mirv: that is the idea :)
<Mirv> :)
<tsimonq2> Mirv: yep :D
<tsimonq2> Mirv: #ubuntu-qt is a thing btw :D
<seb128> wgrant, cjwatson, do you have any idea why recent bionic uploads for e.g gnome-sudoku or gtk+3.0 don't have their translations getting imported? for example https://translations.launchpad.net/ubuntu/bionic/+source/gtk+3.0/+imports is empty? the build have what looks like valid translations tarball exported, like https://launchpad.net/ubuntu/bionic/+upload/17639672/+files/gtk+3.0_3.22.28-1ubuntu2_amd64_translations.tar.gz
<Mirv> tsimonq2: oh!
<cjwatson> seb128: The job that processes translations uploads seems to have been stuck in some kind of rather sad state since we rebooted our master DB server overnight.  I've got the stuck job killed and we'll see if the next run gets anywhere.  (I'm not sure whether any failures will be retried, though.)
<seb128> cjwatson, ok, thanks. So if it's not sorted out by itself in a few hours I should reupload those? When was the reboot in question (just to know what uploads to check)
<cjwatson> 0400 UTC ish
<seb128> k, thanks
<coreycb> hello release team, please can someone take a look at promoting libapache2-mod-auth-mellon and lasso to main for bug 1610286?
<ubottu> bug 1610286 in libapache2-mod-auth-mellon (Ubuntu) "[MIR] libapache2-mod-auth-mellon, liblasso3" [Medium,Triaged] https://launchpad.net/bugs/1610286
<coreycb> they've already received security team ACK
<jamespage> coreycb: lets seed those packages so they appear on the mismatches reqport
<jamespage> coreycb: have you done that before? (seeding)
<coreycb> jamespage: i think so, let me dig up my notes
<coreycb> jamespage: ok i'll do that, i may ask you for a review later
<jamespage> coreycb: np - I think you'll probably just want to seed libapache2-mod-auth-mellon
<coreycb> jamespage: ok
<seb128> cjwatson, you are sure that job isn't still (or again) stucked? I re-uploaded gnome-sudoku and I still see nothing in the import queue, it could be pending but usually things show up in the queue without too much delay after build
<cjwatson> seb128: there's definitely something stuck, but the way our logging currently is doesn't allow me to tell whether it's just trying to import some huge package or is genuinely stuck :-(
<cjwatson> 2018-02-22 12:55:22 INFO    Running <lp.soyuz.model.packagetranslationsuploadjob.PackageTranslationsUploadJob object at 0x7f02085ef4d0> (ID 41183883) in status Waiting
<cjwatson> ^- shall I compare thee to a chocolate teapot?
<seb128> cjwatson, well I guess let's wait a couple of hours and see if things moved?
<cjwatson> seb128: it's importing libreoffice, apparently that takes eons
<seb128> cjwatson, libreoffice challenging our infras, as always :) thanks for figuring that out!
<cjwatson> seb128: I've just proposed https://code.launchpad.net/~cjwatson/launchpad/ptuj-repr/+merge/338559 which will make this less annoying to diagnose next time
<seb128> cjwatson, great
<coreycb> jamespage: does this look ok? https://bazaar.launchpad.net/~corey.bryant/ubuntu-seeds/platform.bionic/revision/2166
<jalt> Hi, is there a place where I can see daily commits towards the upcoming 16.04.4 point release? Basically, a centralized way to see what went into building the daily ISOs, kinda like https://wiki.ubuntu.com/XenialXerus/ReleaseNotes/ChangeSummary/16.04.4 but daily, and with the detail of https://launchpad.net/ubuntu/+source/ubiquity/+changelog
<cjwatson> https://lists.ubuntu.com/archives/xenial-changes/ isn't commit-level but is probably your best bet
<jalt> thanks cjwatson. sorting that by date basically works for my needs.
<jamespage> coreycb: I'd stick it in the OpenStack section
<jamespage> so its clear its to support that
<coreycb> jamespage: ok i'll do that and push. wasn't sure where to put it.
<coreycb> jamespage: thanks for reviewing
<nacc> xevious: hey
<xevious> Good morning. I'm looking at kronolith now.
<nacc> xevious: thanks -- do you want my debdiff as it is now?
<nacc> xevious: to start from, i mean
<xevious> I got it to the same point already.
<nacc> xevious: ah great
<xevious> nacc: I'm in a meeting now...
<nacc> xevious: np, me too :)
<zyga> there's something weird in grub when booting on an efi system (on 18.04), there's clear double-redering of everything and the rendering's don't quite match
<zyga> like one has larger font than the other
<zyga> the one that is visible in stable state looks like regular grub on efi systems (native panel resolution, etc)
<zyga> the other one looks like it's blurry or lower res
<zyga> I'll try to grab some images but I was curious if this is known
<zyga> the malformed one has black background
<zyga> the non-malformed one has aubergine background
<xevious> nacc: Ok, I'm back on it.
<nacc> xevious: thanks!
<nacc> xevious: kronolith is the one that just need something similar to what you did for the tests but to the constructor itself, right?
<nacc> xevious: i read somewhere else that many folks switched to using a factory
<nacc> but that would change the API, which implies we can't just change it directly
<xevious> It looks like it just needs a `@runInSeparateProcess` annotation on a couple tests.
<xevious> ...however, if the other tests depend on the on that needs to be run in a separate process, then I'll need to make more extensive changes to the tests.
<xevious> s/on that/one that/
<xevious> I really wish IRC supported vim-style corrections. :)
<xevious> If only Quassel supported plugins, I'd make one to allow it.
<zyga> https://twitter.com/zygoon/status/966716431483265024 (for lack of better way to attach movies)
<nacc> xevious: yeah, i can see that
<xevious> nacc: I sure wish someone had answered this: https://github.com/horde/kronolith/commit/d996704daca092d92144f10d9f3d12e04f2b9dcb#r27678172
<nacc> xevious: yeah, i had to do the proper change locally for that part to pass
<nacc> xevious: but it's not clear what upstream wants to do
<xevious> It passes for me if I just move the closing paren to where it's supposed to be.
<nacc> xevious: yeah, that's what i did
<nacc> xevious: rather than their upstream fix, which doesn't work
<nacc> afaict
<xevious> Yikes
<nacc> xevious: yeah, it's weird
<tjaalton> nacc: hi, have you looked at libglvnd MIR yet?
<nacc> tjaalton: was going to today
<xevious> nacc: Found one deprecated line in sessionhandler.
<tjaalton> nacc: ok, thanks
<xevious> ...so far.
<sil2100> smoser: hey! Could you verify the grub2 uploads you made to xenial?
<sil2100> smoser: we'd like to make place for another grub2 SRU
<smoser> ddstreet: yeah... meant to look at taht.
<smoser> sil2100: oh. yeah i can . i''m sorry.
<smoser> sil2100: bug ?
<smoser> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1527727
<ubottu> Launchpad bug 1527727 in grub2-signed (Ubuntu Xenial) "grub-probe for zfs assumes all devices prefix with /dev, ignoring /dev/disk/..." [Medium,Fix committed]
<smoser> thanks. i'll  look to verify
<smoser> rharper: ^
<smoser> how can we easily do that...
<rharper> smoser: I think run our vmtest without the export and as a late_command installed the proposed package
<smoser> but late command woudl be too late
<smoser> no ?
<rharper> actually, install it into the ephemeral, sorry
<rharper> and then the grub install without the env setting will fail to install
<smoser> ? no the target grub is used
<smoser> hm...
<smoser> suck
<tjaalton> dpkg-source failed for xorg-server_1.19.6-1ubuntu2.dsc [return: 2]
<rharper> well, alternative is to post install, remove the env setting file, add proposed package
<tjaalton> what the..
<rharper> and then run install-grub via cloud-init commands
<tjaalton> upload to bionic rejected
<ddstreet> smoser yeah let me know if you have any concerns about lp #1718568
<ubottu> Launchpad bug 1718568 in isc-dhcp (Ubuntu Bionic) "dhclient-script fails to wait for link-local address" [Medium,In progress] https://launchpad.net/bugs/1718568
<xevious> nacc: Another meeting... sorry for the delay!
<nacc> xevious: np! please don't apologize!
<smoser> ddstreet: i did wonder what happens if ipv6 is not enabled
<smoser> like in kernel or something.
<ddstreet> smoser well it should time out in that case
<smoser> i think you'll loop to timeout where as before it would be ok.
<smoser> before it'd quickly exit
<ddstreet> and if someone is trying to set up dhcpv6 when ipv6 is disabled, a timeout shouldn't be unexpected
<smoser> fair point
<smoser> :)
<smoser> is this down a ipv6 dhcp only path ?
<ddstreet> yeah, waiting for dad only makes sense for dhcpv6
<ddstreet> there is no dad in ipv4
<ddstreet> well, dad is ipv6 in general, but as we're talking about dhclient, it would be when it's doing dhcpv6, not dhcpv4
<smoser> right. yeah, so yeah. this gets called in PREINIT6
<smoser> so it is.
<nacc> Laney: how long does it typically take for passes to show up on excuses?
<nacc> Laney: context> i'm clicking through the php regressions currently listed and all seem to have passed from my massive retry yesterday, but only some arches are showing pass
<nacc> slangasek: --^ you might know as well
<slangasek> nacc: if you can see the pass on the autopkgtest web ui, it will also show up in update_excuses in the first full britney run that starts after the website was updated.  So something else is askew and it's not a stale-data issue
<slangasek> nacc: specific example?
<nacc> slangasek: i wonder if it's because some of the triggers (before I tried with all-proposed=1) were still in the retry attempt?
<nacc> slangasek: php-horde-listheaders
<slangasek> nacc: are you looking at http://autopkgtest.ubuntu.com/packages/p/php-horde-listheaders/bionic/armhf for example?
<nacc> slangasek: right
<nacc> is it becuase it didn't do an all-proposed=1 run with the listheaders trigger?
<slangasek> nacc: note that, pathologically, php-horde-listheaders itself is not in the list of triggers, despite it being the correct version being tested
<nacc> maybe these came in after my last retrigger blast
<nacc> slangasek: yeah, i see what happened, i think
<slangasek> so britney fails to credit it to php-horde-listheaders/1.2.5-1ubuntu1 as a "pass", even though the version number listed means it clearly is
<nacc> yeah
<nacc> slangasek: i think it's because some i had manually done that for, and some i hadn't, so when i used retry-autopkgtest-regressions, some had the correct triggers and some didn't
<nacc> slangasek: what's the best way for me to resolve this? retrigger again correctly?
<slangasek> nacc: yeah - if it was just the php-horde-listheaders tests showing as regressions currently, I would offer to just skiptest; but since there are several other packages listed as regressing, better to just work through retries in order to get it into a clean state
<nacc> slangasek: ack, i'll do that now
<xevious> nacc: kronolith is just about done and required updating the patch for sessionhandler.
<xevious> I'm running tests now to compare two potential fixes for sessionhandler.
<nacc> xevious: thanks!
<slangasek> nacc: how close are we to getting php7.2 to migrate?  We need to do a curl migration for openssl1.1, and it'd be nice to have either php7.2 or libunistring out of the way before we start that
<nacc> slangasek: well, php7.2 is through, we're working on php-defaults right now
<nacc> xevious: is working on the last few
<nacc> slangasek: Laney: urgh server error again from request.cgi
<slangasek> nacc: oh, I see; so php7.2 7.2.2-1ubuntu1 doesn't really get caught up in anything.  Any concerns about a re-upload of that package while it's in -proposed?
<nacc> slangasek: if php-defaults goes through, it's just a matter of migrating these retries through
<nacc> slangasek: no, i think that's fine
<xevious> nacc: Did you resolve all the stuck packages?
<nacc> xevious: i think so, i need to retrigger them correctly and they should migrate
<nacc> xevious: well, other than the three you know about in php-defaults
<xevious> Cool
<nacc> xevious: two of which you seem to have a handle on :)
<xevious> Yeah they'll be ready shortly
<xevious> Multi-package ADT runs take soooo long
<nacc> yeah
<nacc> xevious: actually, no, wait, they shoudn't take noticeably longer
<nacc> xevious: oh you need to build them both?
<nacc> xevious: i use sbuild to build locally and then just pass the deb in
<sunweave1> hi! has the sync of new packages between sid and bionic already been frozen?
<sunweave1> I have uploaded x2goserver to sid, bt it does not land in bionc?
<sunweave1> is there still a chance to get it in?
<sarnold> sunweave1: looks like debian import freeze is march 1 https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule
<sarnold> after that syncs have to be made by hand
<sunweave1> that affects packes already in unstable for a while...
<sunweave1> x2goserver ust entered unstable (was in exp before)
<sunweave1> sarnold: is there a difference between pkgs already there and pkgs just entering?
<sarnold> sunweave1: I haven't heard of one, but I'm not too experienced here
<sunweaver> anyone else around who can provide info or even tag X2Go Server for syncing?
<sarnold> sunweaver: sweet, looks like the import already happened: https://launchpad.net/ubuntu/+source/x2goserver
<sarnold> sunweaver: hrm, looks like nxagent is needed but missing http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#x2goserver
<sarnold> I don't know if one uninstallable binary package is sufficient to block the others or not
<sunweaver> nx-libs src:pkg is in unstable, too
<sunweaver> which provides bin:pkg nxagent
<sarnold> curious. launchpad knows about that in debian https://launchpad.net/debian/+source/nx-libs but doesn't have it imported into ubuntu yet
<sunweaver> and that page says it is supposed to go into release(main)
<sunweaver> not universe
<sarnold> I think the /debian/+source/ pages reflect where it lives in debian
<sunweaver> flexiondotorg: ^^^
<sunweaver> xnox: ^^^
<sunweaver> can you shed some light on the above issue?
<sunweaver> sarnold: thanks!
<xevious> nacc: I'm seeing something weird... adt-run gets all the way through kronolith's phpunit tests, then it dies. I'll make a pastebin of the last few lines.
<nacc> xevious: ok
<xevious> nacc: https://paste.ubuntu.com/p/BwZKND8SQZ/
<nacc> xevious: weird, maybe a bug, want to pass me your debdiff and i can tes locally?
<xevious> I'm running adt-run with two `--source` parameters, the first pointing to my sessionhandler .dsc and the second pointing to my kronolith .dsc
<xevious> Yeah, I'll make debdiffs and pop them on the ticket.
<nacc> xevious: that's fine, i hav eyour sessionhandler alreayd built here
<xevious> I had to change it.
<nacc> i guess i need to rebuild, but sure
<nacc> yeah
<nacc> i'm going to walk the dogs, i'll check in when i'm back
<xevious> Sounds good.
<xevious> nacc: Delete the sessionhandler debdiff you've currently got because I changed it: https://bugs.launchpad.net/ubuntu/+source/php-horde-sessionhandler/+bug/1749783/comments/21
<ubottu> Launchpad bug 1749783 in php-horde-sessionhandler (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,New]
<xevious> nacc: Here's the kronolith package debdiff: https://bugs.launchpad.net/ubuntu/+source/php-horde-sessionhandler/+bug/1749783/comments/22
<xevious> I'm gonna go put some food in my face hole.
<nacc> xevious: ack on both
<xevious> I'm back now.
<nacc> xevious: any ideas on the horde-kolab-storage?
<nacc> xevious: i'm building/testing your two now
<xevious> I'll start looking at that now.
<nacc> xevious: thanks
<nacc> xevious: nice, i can confirm both pass now!
<nacc> xevious: uploading
<sil2100> smoser: hey! The grub2 SRU for xenial you made seems to have gotten an automatic verification-failed due to a possible regression found by the bot
<sil2100> smoser: could you look into that?
<sil2100> smoser: LP: #1527727
<ubottu> Launchpad bug 1527727 in grub2-signed (Ubuntu Xenial) "grub-probe for zfs assumes all devices prefix with /dev, ignoring /dev/disk/..." [Medium,Fix committed] https://launchpad.net/bugs/1527727
<nacc> xevious: any luck with kolab-storage?
<nacc> xevious: i just retriggered the php-defaults tests with the two uploaded
<xevious> Had to do a few code reviews. Getting back to it now.
<nacc> xevious: note that even with the dep8 tests working, we'll need to unblock gosa and cakephp from LP: #1749745 I expect
<ubottu> Launchpad bug 1749745 in gosa (Ubuntu) "php7.2 has removed the mcrypt module" [Undecided,Incomplete] https://launchpad.net/bugs/1749745
<nacc> since they will be come uinnstallable
<nacc> luckily both upstreams have issues/trackers for them
<xevious> Will that prevent php-defaults from moving out of proposed?
<nacc> xevious: yeah
<nacc> that's what update_output.txt is (will) show
<nacc> slangasek: --^ do you have an opinion on that (beyond observing the current situation)? I'm tempted to remove gosa*, zoneminder and cakephp
<slangasek> nacc: I have no opinions, I merely identified that there were revdeps not named in your removal request :)
#ubuntu-devel 2018-02-23
<tjaalton> mdeslaur, slangasek: do you have plans to merge pam for bionic?
<slangasek> tjaalton: no plans on my part
<slangasek> tjaalton: well, I should amend that
<slangasek> tjaalton: I do actually have a merge staged in https://git.launchpad.net/~vorlon/ubuntu/+source/pam
<slangasek> tjaalton: which the Server Team asked for some changes to
<tjaalton> slangasek: ok, was just hoping to get the changes from -3.7 in bionic
<slangasek> yeah
<tjaalton> I can finish it
<slangasek> tjaalton: well, the changes requested involve rewriting history, so it may be best if I finish that work
<tjaalton> sure, wfm
<nacc> slangasek: ack
<nacc> tjaalton: do you know when 1.0.0-3 will end up in sid/bionic?
<nacc> tjaalton: re: libglvnd
<tjaalton> nacc: it's not uploaded yet
<tjaalton> waiting for a new upstream bugfix release
<nacc> tjaalton: ack, i just saw that's the upload/future version with the tests enabled
<xevious> Tests: 768, Assertions: 666, Errors: 178, Failures: 26, Skipped: 9, Incomplete: 8, Risky: 18.
<xevious> I dunno about that assertion count...
<nacc> xevious: heh, which pkg is this? kolab-storage?
<xevious> Yeah
<xevious> Obviously something I tried didn't work (Errors: 178)
<tjaalton> nacc: right, I'll upload that if there isn't anything more to add in a week or two
<nacc> xevious: yeah :) i was down to failures 10 .. do you want my debdiff?
<nacc> tjaalton: ack
<nacc> xevious: what were you trying, btw?
<xevious> nacc: I just had a typo in a recursive search and replace. Doh!
<nacc> heh, I've done that a few times now :)
<xevious> Just different ways of building the mock classes.
<nacc> xevious: ah ok
<xevious> To deal with the expectation counts.
<nacc> cyphermox: in the case like above, where tjaalton is going to upload a version with the tests enabled at abuild-time, is it ok to approve the MIR now? or do I wait for that version to be available?
<nacc> xevious: any luck?
<xevious> nacc: Getting there...
<nacc> xevious: cool :)
<cyphermox> nacc: yes
<xevious> nacc: Got it. Just cleaning up the patches...
<xevious> Running tests...
<xevious> I've created 3 patches while working on this quilt package. If I want to make some changes and refresh the second patch, how do I do that?
<sarnold> xevious: probably along the the lines of quilt pop, quilt edit, quilt refresh, quilt push, and quilt refresh if the top-most patch needs it ..
<xevious> I think I `quilt pop`, make changes, `quilt refresh`, then `quilt push -a`. Does that sound right?
<sarnold> that's roughly the same, yes; the 'make changes' step may need the quilt edit if you're changing a file that isn't already in that patch
<xevious> Awesome. Thanks for explaining!
<tsimonq2> xevious: My bookmarked ref is https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
<xevious> Yeah, I've read bits and pieces of that. I really need to read it end-to-end.
<tsimonq2> I'd say DEP-3 is especially important if you haven't read up on it already because imho it's a good, standard way to do patch descriptions, and my sponsors also insisted on it ;)
<nacc> xevious: thanks! i'll look for the debdiff
<nacc> cyphermox: yes to whch one? :)
<nacc> xevious: the most difficult part about quilt, to me, is remembering to tell it which files are about to change :)
<sarnold> I've screwed that up more than once.
<xevious> Yeah, I've forgotten and gotten like 30 files deep into modifications several times.
<xevious> I need to remember to use `quilt edit` instead of `vim`
<sarnold> it's especially easy to do when I use 'gf' to go to a file named under the cursor in vim for making additional changes ..
<cyphermox> nacc: yes to approving it now
<xevious> nacc: FYI, it came down to session-related stuff again.
<nacc> xevious: that's reassuring on some level
<nacc> cyphermox: and thank you
<nacc> xevious: there are some git->quilt tools that make it a bit easier to do, as well
<nacc> guilt, iirc
<xevious> guilt... what an awesome name
<xevious> nacc: https://bugs.launchpad.net/ubuntu/+source/php-horde-kolab-storage/+bug/1749783/comments/24
<ubottu> Launchpad bug 1749783 in php-horde-kolab-storage (Ubuntu) "php-defaults stuck in bionic-proposed" [Undecided,New]
<nacc> xevious: thanks, reviewing it now
<xevious> nacc: Is there anything else to look at that isn't listed under php-defaults on the 'excuses...' page?
<nacc> xevious: not right now, i think we're going to just have to remove cakephp and gosa for now
<nacc> xevious: upstream cakephp +1'd its removal, as they don't want people using that version
<nacc> xevious: and gosa will probably get a fix in debian, and we can sync it back down later
<xevious> Good news
<nacc> xevious: i think all of the horde ones just need retries (I had to upload a few more)
<Unit193> sforshee: Can confirm 1737750 builds and functions.
<nacc> xevious: looks good, uploaded
<xevious> I finally got the LP tag right!
 * xevious is very proud.
<nacc> xevious: nicely done :)
<xevious> brb
<nacc> tjaalton: did you see that libglvnd is stuck in bionic-proposed with regressions in nvidia?
<tjaalton> nacc: it's part of the transition
<tjaalton> nvidia 390 got uploaded, 340 will be after xorg-server is through
<nacc> tjaalton: ack
<xevious> Are armhf, ppc64el, and s390x tests stalled on autopkgtest.ubuntu.com? I see a ton queued, but none running.
<xevious> Yeah... unless they only run between certain hours or something, it looks like something's preventing the armhf, ppc64el, and s390x tests from running on autopkgtest.ubuntu.com.
<sunweaver> why that is, I am currently investigating...
 * sunweaver is gosa maintainer for Debian
<jibel> cpaelzer, Hi, I've bug 1751222 again on bionic
<ubottu> bug 1751222 in virt-manager (Ubuntu) "[regression] virt-manager fails to show virtual console: internal error: unable to execute QEMU command 'getfd': No file descriptor supplied via SCM_RIGHTS" [Undecided,New] https://launchpad.net/bugs/1751222
<cpaelzer> jibel: hmm
<cpaelzer> jibel: we really have this fixed (apparmor wise) both ways now
 * cpaelzer reads the bug details
<jibel> cpaelzer, yes and I verified that the apparmor rules are there
<cpaelzer> jibel: I checked the deny vs the rule but it shoudl match (as it did in the tests)
<cpaelzer> jibel: do you have any extra info that could affect this
<cpaelzer> jibel: maybe - could you tweak the rule in /etc/apparmor.d/usr.sbin.libvirtd until you found the minimal change that is needed?
<cpaelzer> maybe the wildcards, but made no sense working before and it seems good when looking at Deny vs Rule
<jibel> cpaelzer, sure, I'll have a closer look today
<cpaelzer> jibel: I just tried to recreate - but it works for me
<cpaelzer> jibel: sorry, we need to find what is different for you
<seb128> cjwatson, good morning. Do you know if the translations import is still stucked processing libreoffice?
<acheronuk> jbicha: hi. could we maybe get this fix into network manager? https://bugzilla.gnome.org/show_bug.cgi?id=793324
<ubottu> Gnome bug 793324 in general "AddAndActivateConnection loses agent secrets" [Normal,Resolved: fixed]
<acheronuk> for https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1572244
<ubottu> Launchpad bug 1572244 in network-manager (Ubuntu) "Kubuntu requires that the WiFi password be entered twice before WiFi can be used" [Medium,Confirmed]
<cjwatson> seb128: It's been making progress through the queue, but every time it hits a libreoffice import it sits there thinking about it for four hours and then times out
<cjwatson> I wonder if changing that job to download the file from the librarian to a tempfile on disk rather than keeping it in memory would help
<ogra_> sil2100, slangasek, i would appreciate if someone could take a look at bug 1751249
<ubottu> bug 1751249 in ubuntu-image (Ubuntu) "Using âcontent:â in gadget.ymal for a ârole: system-dataâ partition makes it not be system-data anymore " [Undecided,New] https://launchpad.net/bugs/1751249
<sil2100> ogra_: hm, noted
<seb128> cjwatson, k, as long as it doesn't keep retrying the one that timeout and get stucked on it
<cjwatson> seb128: No, it doesn't seem to be doing that
<seb128> cjwatson, k, well let's see, if those packages are still not imported by monday I might ping you again
<seb128> cjwatson, thanks for the help/explanations in any case!
<cjwatson> I pushed https://code.launchpad.net/~cjwatson/launchpad/ptuj-via-disk/+merge/338894 in a slightly speculative attempt to speed it up
<seb128> thx
<ddstreet> smoser hey, i had asked nacc if he could sponsor lp #1718568 but since it's patching code you added it probably makes more sense if you could sponsor it into bionic, you have time for that?  I can sru once it's in bionic
<ubottu> Launchpad bug 1718568 in isc-dhcp (Ubuntu Bionic) "dhclient-script fails to wait for link-local address" [Medium,In progress] https://launchpad.net/bugs/1718568
<ddstreet> unless nacc is already in the middle of sponsoring it, but i think he's been pretty busy lately
<smoser> well, xnox, good news and bad news.
<smoser> good news is that the timeout worked (thanks for 'timeout' i didn't know of that tool)
<smoser> http://autopkgtest.ubuntu.com/packages/o/open-iscsi/bionic/amd64
<smoser> bad news is no new image yet.
<xnox> smoser, well, it would be bad news if the new image failed =) new image will be later on today, i believe.
<xnox> smoser, pipeline starts at about 3:45 PM
<xnox> and it's 1:37PM now.
<nacc> ddstreet: sorry! if smoser can't, i can do it today
<smoser> ddstreet: i can do that right now.
<ddstreet> awesome thnx!
<smoser> ddstreet: /me *really* likes git-ubuntu :)
<smoser> hint for next time
<ddstreet> instead of debdiffs, eh, ok
<ddstreet> been meaning to start using it
<smoser> once you do, you'll never want to do it the other way
<cpaelzer> smoser: xnox: what is the decision on open-iscsi for the time being
<cpaelzer> I saw the timeout change come in and work
<cpaelzer> but the image is still broken
<cpaelzer> do we wait until it is working and retry
<cpaelzer> or do we temporarily mask the test?
<smoser> cpaelzer: xnox sent a Mp to "bad test" it. but the fix should come in an image numbered 20180223
<smoser> so we can bad test or wait hopefully short-number-of-hours
<cpaelzer> thanks for the update smoser
<smoser> cpaelzer: fix is at https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1750851
<ubottu> Launchpad bug 1750851 in ubuntu-meta (Ubuntu) "re-add cloud-initramfs-dyn-netconf to ubuntu-server" [Medium,Fix released]
<smoser> ddstreet: do you mind if i wrap your changelog entries at < 80 ?
<ddstreet> smoser did i go over?  sorry i usually check that
<ddstreet> go for it
<smoser> man that file really needs tabs to spaces consistency
<smoser> tabs interspaced randomly
<ddstreet> smoser do you have a script/tool you use for the various sponsor checks?
<smoser> no
<nacc> ddstreet: smoser: there is sponsor-patch
<ddstreet> i tried that but it seemed rather heavyweight...and does it check stuff like trailing spaces, line lengths...should look at it more tho
<ddstreet> nacc do you use sponsor-patch only for stuff you sponsor?
<nacc> ddstreet: it catches most stuff i care about, tbh, i also do a visual inspection of the debdiff and chekc the build and dep8
<nacc> ddstreet: and yes to the latter
<nacc> ddstreet: well, for some parse of what you wrote. I only use sponsor-patch when sponsoring
<xevious> nacc: You're up early!
<nacc> xevious: sick kid :)
<xevious> Aw, shucks. I'm sorry to hear that.
<nacc> xevious: looks like php-defaults migrated ^5
<xevious> Awww yiss!
<nacc> xevious: thanks :)
<smoser> ddstreet: uploaded
<xevious> You're welcome. Let me know if there's anything else I can help out with.
<nacc> xevious: it will take a bit for it to clear excuses out
<ddstreet> smoser thnx!
<nacc> xevious: speaking of which, I did hit a weird case with php-horde-crypt: https://bugs.horde.org/ticket/14780
<nacc> xevious: i don't think it can possibly work without some relatively invasive cod eupdates
<nacc> xevious: but, i don't want to use up more of your time. I can figure it out eventually :)
<ddstreet> nacc this is the latest doc i could find on git-ubuntu, is there more details anywhere?  https://insights.ubuntu.com/2017/08/09/git-ubuntu-clone/
<nacc> ddstreet: there's a wiki page and manpages
<ddstreet> ok
<nacc> ddstreet: in general `git ubuntu clone <srcpkg>; cd <srcpkg>; do stuff`
<nacc> ddstreet: if that makes sense
<ddstreet> yeah, i was looking more for 'process to created commits for sponsorship'
<ddstreet> using git-ubuntu instead of manual debdiffs
<nacc> ddstreet: right, so you do the normal git stuff
<nacc> like it's a real software proejct :)
<nacc> and then `git ubuntu submit` in theory
<ddstreet> aha ok
<nacc> the latter is still in flux a bit, but i think should work
<xevious> nacc: I just looked at that ticket for php-horde-crypt. That's definitely a significant change.
<bdmurray> juliank: You sponsored the patch in bug 1722411 but I see there have been some updates to it. Do you want to continue with it?
<ubottu> bug 1722411 in gnutls28 (Ubuntu Trusty) "gnutls28 in trusty no longer validates many valid certificate chains, such as google.com" [Medium,In progress] https://launchpad.net/bugs/1722411
<xevious> nacc: The Horde team shouldn't be shelling out to interact with GPG, though. There's a GPG extension, which uses gpgme (which is compatible with both gpg 1 and 2)
<juliank> bdmurray: I guess I should sponsor that 1.3
<juliank> or rather, it might need to be updated with the actual upstream patch, rather than having the different downstream patch
<ddstreet> nacc any plans to include ubuntu-cloud-archive versions in usd-imports (so git-ubuntu has their history as well)?  i assume no...
<rbasak> ddstreet: currently not in our plans.
<rbasak> We could do it in the end I suppose. There's nothing in our design that rules it out.
<nacc> xevious: i agree
<nacc> xevious: but i don't know how to do that on my own and it seems like an invasive change to switch its calling methods
<xevious> Oh yeah, it's totally a "they should do that" situtation.
<nacc> ddstreet: as rbasak said, not curently; but it's relatively easy for us to add a new source of information (curently the Launchpad Debian and Ubuntu publishing information is the only source)
<nacc> ddstreet: it would need a feature request, and presumably would require some knowledge of what branches should exist there
<ddstreet> nacc rbasak thnx, i was just wondering; the cloud guys have their own whole process so probably not really needed anytime soon
<nacc> ddstreet: right
<nacc> ddstreet: in theory, if they are basically doing stuff 'after' the existing publish pockets
<nacc> we can import those publishes easily, if they have a definitive source publication recorde we can look at
<nacc> ddstreet: we just wouldn't necessarily have branches for it
<smoser> slangasek: could you tell me what i did wrong really quick ?
<smoser> https://code.launchpad.net/~smoser/ubuntu/+source/walinuxagent/+git/walinuxagent/+merge/336244
<smoser> installing my package doesnt delete the conf file.
<slangasek> smoser: interesting, your diff looks correct to me
<slangasek> smoser: can you point me at a binary package that I can poke into?
<smoser> slangasek: https://smoser.brickies.net/ubuntu/misc/
<slangasek> smoser: the added line in debian/maintscript should result in some really obvious code being output into preinst,postinst,postrm scripts
<slangasek> smoser: and it does appear to be there
<nacc> isn't the version incorrect?
<slangasek> oh
<nacc> i mean if there is a published version of walinuxagent in bionic with the config file
<slangasek> right, what version are you upgrading *from*?
<nacc> it won't remove it
<nacc> since it's at 2.2.21+really2.2.20-0ubuntu1
<nacc> (at least that's my recollection of the versioning)
<slangasek> smoser: if the version number argument is too low, the migration doesn't trigger when upgrading from a version newer than this
<nacc> i would think you'd want '2.2.21+really2.2.20-0ubuntu2', but i might be wrong
<nacc> err, with a ~ on the end
<slangasek> "prior-version> Defines the latest version of the package whose upgrade should trigger the operation" dpkg-maintscript-helper(1)
<slangasek> yes, I think that's so
<slangasek> or possibly even 2.2.21+really2.2.20-0ubuntu2
<nacc> yeah and since this version was backported to all releases, you'd not see the conffile removal for sure without that change
<nacc> 'this version' = 2.2.21+really2.2.20-0ubuntu1
<slangasek> because it's safer to have it double-trigger when this exact package version is upgraded from, than to miss the removal because someone published a 2.2.21+really2.2.20-0ubuntu2~pre1 that didn't have this code
<nacc> slangasek: yep, good call
<slangasek> (otoh, people shouldn't do that, so YMMV)
<smoser> slangasek, nacc . thank you. MP updated.
<nacc> smoser: yw
<mdeslaur> slangasek: are you working on a python-django merge?
<acheronuk> tjaalton: building against the mesa and libglvnd in -proposed seems to have broken Kubuntu's desktop acceleration. On intel we now only get llvmpipe
<acheronuk> if I purge libglvnd0 and libegl off the system (which are new on our iso we did not have before) we get full desktop hardware opengl back
<nacc> xevious: lol https://github.com/horde/horde/pull/221
<nacc> xevious: "Yes, key generation doesn't work with GnuPG 2 yet, and probably never will."
<tjaalton> acheronuk: transition is in flux
<tjaalton> but if you have issues with upstream mesa then file a bug there
<tjaalton> it shouldn't matter if glvnd is used or not
<tjaalton> debian has had it for six months
<acheronuk> tjaalton: yeah. hopefully it will be ok when it all sits in the same pocket!
<tjaalton> -proposed should work, as does ppa:canonical-x/testing
<acheronuk> at the moment I may have to do a fudge to stop it being pulled in. just until it all sorts itself
<acheronuk> tjaalton: yeah. I have one report from someone who madly uses -proposed, that they have no issue
<nacc> xevious: fwiw, i'm skipping that test, it passes fine with that
<nacc> slangasek: pacemaker ftbfs in artful due to binutils changes there (libqb?). Who from foundations might be able to help? It seems unresolved in Debian (the bugs slashd has found), but it obviously does build in bionic
<acheronuk> tjaalton: probably matters little, but the offending lib is libeg1. the -release version of that being installed breaks it all
<tjaalton> it's too old
<slangasek> mdeslaur: I had not been working on a python-django merge, but it's a trivial delta so I'll knock it out now
<acheronuk> tjaalton: for stuff which was compiled against -proposed then moved to release you mean?
<slangasek> nacc: pacemaker> hmm maybe infinity has some cycles right now to look
<tjaalton> acheronuk: maybe, dunno how you could get that otherwise
<nacc> infinity: that would help me a ton, this is a rabbit hole i've never gone down before
<slangasek> mdeslaur: done
<nacc> infinity: it apparenlty has to do with orphan symbols on certain architectures
<acheronuk> tjaalton: ok. just don't want to do a temp fix, only to have it bite us (kubuntu) harder later. sorry for all the queries
<tjaalton> acheronuk: it should be sorted next week
<acheronuk> cool. thanks
<slangasek> nacc: is there a build log in lp for this pacemaker failure?
<nacc> slangasek: i don't think so, because slashd and i only have it locally while trying to sru a fix back
<slashd> nacc, slangasek, I *think* it was never trigger before because the package has been copied from zesty to artful (probably when artful has been first created) and package never been build again (no other upload nor SRU since then)
<mdeslaur> slangasek: awesome, thanks!
<slangasek> slashd, nacc: ah, which means it shows up on http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-gcc7-artful.html
<nacc> slangasek: sort of
<nacc> slangasek: yes, that's an error, but not hte one i need help with :)
<slashd> nacc, right this one I have found the fix for ^, but once fix the libqb arise
<slashd> slangasek, ^
<nacc> slashd: https://github.com/ClusterLabs/pacemaker/commit/a7476dd96e79197f65acf0f049f75ce8e8f9e801.patch
<nacc> fixes that upstream and is in debian
<nacc> but then it fails due to a symbols change, which slashd narrowed down to libqb
<slangasek> slashd, nacc: ok, so, not only is there not a build failure in lp for this, but the source code you want debugged is also not in lp... where's the pointer for that?
<nacc> LP: #1740892
<ubottu> Launchpad bug 1740892 in pacemaker (Ubuntu Artful) "corosync upgrade on 2018-01-02 caused pacemaker to fail" [High,In progress] https://launchpad.net/bugs/1740892
<nacc> has some info, i believe
<slangasek> surely the server team has a git branch for this WIP that we can pull ;)
<nacc> slangasek: would you rather we did an upload we know would fail? just trying to understand
<nacc> i can put one up for artful, i did for xenial
<slangasek> nacc: I'm asking for enough concrete details for someone (e.g. infinity or myself) to be able to help you efficiently.  Even a pastebin of the toolchain error output?
<slangasek> mdeslaur: ahhh you tricked me into merging a python-django that ftbfs
<slangasek> mdeslaur: the test failure seems unrelated to any debian-ubuntu differences in core packages; I'm stabbing the retry button to see what happens, but if it still ftbfs I'm not following up on it today fwiw
<nacc> slangasek: fair, above patch results in https://paste.ubuntu.com/p/hb68G8rpMw/
<slangasek> oh is that all
<slashd> slangasek, if that can help -> https://launchpadlibrarian.net/357655127/buildlog_ubuntu-artful-amd64.pacemaker_1.1.16-1ubuntu1.2_BUILDING.txt.gz
<slangasek> nacc: those are pretty clearly internal symbols which are not part of the ABI and you should just mark them (optional) instead of doing an architecture-based exclusion list
<slangasek> nacc: there's a new pacemaker version in bionic vs. artful, isn't this what was done there?
<slangasek> and when I say mark them (optional), I mean mark them '(optional)'
<nacc> slangasek: i believe debian just dropped the symbols
<nacc> because the debian bugs are not yet fixed :)
<nacc> but i don't know
<nacc> slangasek: we can do tht in the sru too
<slangasek> nacc: dropping the symbols, or marking them optional, both valid.  (optional) would make the same source package more cleanly backportable to older toolchains
<nacc> slashd: --^
<nacc> slangasek: ok
<slangasek> but a symbol that starts with a __ and isn't listed in the public headers for the library, and especially that doesn't originate in the source of this library, can be assumed safe to drop from .symbols
<nacc> slangasek: thanks that makes sense
<sarnold> flexiondotorg: it's hard to figure out what's going on here, but it vaguely feels like do-release-upgrade isn't happy with something in mate: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1751386
<ubottu> Launchpad bug 1751386 in ubuntu-release-upgrader (Ubuntu) "I have problems with the installation of several application packages." [Undecided,New]
<Unit193> ("The cache has no package named 'ubuntu-mate-core'")  that's odd, but the version numbers for other things are a bit off, ~xenial stuff.
<sarnold> and all those [origin: unknown] messages usually means apt is pretty unhappy
<Unit193> apt-forktracer is an amazing too, fyi.
<sarnold> it feels like the sort of thing where nothing on this computer is going to work quite right, and I don't know what to suggest, but ten minutes with it would probably be enough to sort it out.
 * tsimonq2 takes a wild guess at it being the software boutique and something not being right irt PPAs
<Unit193> I read that email.  Also laughed since it came from the same person that seeded the calc as a snap. :P
<tsimonq2> Unit193: Huh?
<tsimonq2> Martin's the one who seeded the calculator as a snap...
<tsimonq2> :P
<sarnold> Unit193: apt-forktracer is neat. thanks.
<Unit193> tsimonq2: Only half accurate: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.bionic/revision/2632
<Unit193> sarnold: Bases them off 'origin', so Canonical's repo also gets picked up.  But, finds ppas.  apt list | grep ed,loc is interesting too.
<tsimonq2> Unit193: But for 17.10 it was indeed a hack in the cdimage tooling
<sarnold> Unit193: wow, I haven't seen apt list either. handy :D
<Unit193> sarnold: I'm going to presume you know about debsums and deborphan?
<Unit193> ...As well as dpkg -l | awk '/^rc/{print $2}'  and  dpkg-query -W -f='${Conffiles}\n' | grep obso  ?
<sarnold> Unit193: aha! those two I know well :)
<sarnold> Unit193: (debsums, deborphan.. and of course dpkg -l | awk .. I'm sure I've got the dpkg-query thing written down somewhere, but no used often enough to remember :)
<jbicha> sarnold: uh, maybe reassign that bug to LibreOffice, could be a bug in their ppa
#ubuntu-devel 2018-02-24
<jbicha> based on the apt log attachment
<Unit193> That was pretty much my assessment as well.
<sunweaver> cjwatson: I see you put nx-libs-lite on the sync-blacklist.txt in 2012. The package has been removed from Debian recently and has been replaced by nx-libs. Any chance, nx-libs can be synced into Ubuntu from Debian unstable.
<sunweaver> ?
<cjwatson> sunweaver: That sync-blacklist entry isn't what's blocking it.  The question is whether it's OK to override the Ubuntu modifications in the nxproxy source package (because nx-libs builds a binary package that was previously built by nxproxy).  Can you go over the Debian->Ubuntu diff in nxproxy and answer that question?
<sunweaver> cjwatson: oh my god, those nxcomp and nxproxy versions are rotten old. I will inspect those pkgs and give feedback.
<sunweaver> cjwatson: I just checked nxproxy src:pkg and nxcomp:pkg. All Ubuntu specific changes have been in nx-libs for ages. It should be safe, say rather highly recommendable to drop these old nxcomp/nxproxy package mummies and have them replaced by maintained code from nx-libs.
<sunweaver> cjwatson: can you do the required steps for this?
<xnox> smoser, systemd/cryptsetup/et.al. migrated \o/
<infinity> pitti: Looks like you wiped out your home on lillypilly before you left.  Did the britney-indexes* scripts referenced from https://wiki.ubuntu.com/ProposedMigration/LocalSetup survive somewhere else?
#ubuntu-devel 2018-02-25
<sunweaver> cjwatson: (2nd ping) I just checked nxproxy src:pkg and nxcomp:pkg. All Ubuntu specific changes have been in nx-libs for ages. It should be safe, say rather highly recommendable to drop these old nxcomp/nxproxy package mummies and have them replaced by maintained code from nx-libs.
<sunweaver> cjwatson: can you do the required steps for this?
<cjwatson> sunweaver: How about nxcompshad?  That's the other source package being replaced here
<cjwatson> sunweaver: It's pretty old so it's probably all replaceable, but it does need to be checked
<sunweaver> cjwatson: nxcompshad is also part of nx-libs nowadays.
<sunweaver> It is only used for building nxagent (the nx-X11 Xserver optimized for low bandwidth connections)
<sunweaver> no other package should depend or build-depend on it.
<sunweaver> in older times, the developers misunderstood how to build nxagent flawlessly. The only meaningful approach was to ship all NX components in one source project.
<sunweaver> nxproxy is a frontend for nxcomp.
<sunweaver> nxagent is a nested Xserver
<sunweaver> these days, nxagent's X-client nature builds against a special lib(NX_)X11 and against various X-client libs (libXinerama, libXrandr, etc.) from X.org.
<sunweaver> nxagent also build-requires nxcompshad for shadow session support
<sunweaver> the graphical compression is handled by nxcompext which in old times was provided as a shared library (which was complete non-sense).
<sunweaver> in fact, it is an Xserver extension, so it is shipped in the DDX code these days.
<sunweaver> but it seems nxcompext never appeared in Ubuntu.
<sunweaver> the nxcompshad version in Ubuntu is more rotten old, then the nxcomp.
<sunweaver> We, as in nx-libs upstream team, reworked great portions of the code, threw out a lot of stuff and reworked the nx-X11 Xserver code base like hell (3.000.000 lines of code dropped).
<cjwatson> too much information :)
<sunweaver> at the same time, we (upstream nx-libs, esp. people from X2Go project) have provided a clean upgrade path for the packages found in Ubuntu.
<cjwatson> I don't want to know all that, I just needed to check that there were no outstanding Ubuntu patches
<sunweaver> all those Breaks:/Replaces: are in the Debian package nx-libs, as well.
<sunweaver> cjwatson: no Ubuntu patches that haven't been merged upstream.
<cjwatson> that's all I need to know, thanks
<sunweaver> and the upgrade path of the package is also existent.
<sunweaver> thanks to you!
<sunweaver> so you are make nx-libs sync now?
<cjwatson> yes, just done
<sunweaver> cheers!
<cjwatson> checking that it gets from bionic-proposed into bionic is your responsibility though, not mine
<sunweaver> that should be an automatic procedure if no further conflicts / obstructions occur?
<cjwatson> if
<cjwatson> but yes
<sunweaver> what are the criteria for -proposed -> release?
<cjwatson> https://wiki.ubuntu.com/ProposedMigration
<sunweaver> thx
<Unit193> Debian #891296 isn't going to help your other package.
<ubottu> Debian bug 891296 in src:x2goserver "x2goserver binary-all FTBFS: chmod: cannot access 'debian/x2goserver/usr/lib/x2go/*': No such file or directory" [Serious,Open] http://bugs.debian.org/891296
<Unit193> Amusingly seems to be fine in Ubuntu though.
<sunweaver> oh dear...
<sunweaver> Unit193: thanks. Will take a look.
<jdonald> 1) Is there someone here with access to change status on Launchpad bugs? Affected users would like to see this ticket: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337 changed from "Fix Released" back to "Confirmed".
<ubottu> Launchpad bug 1711337 in firefox (Ubuntu) "Firefox crashes at start on armv7L after 55.0.1 update" [Undecided,Fix released]
<mitya57> jdonald: does it still affect Bionic, or only some older release?
<jdonald> Yes, we have confirmed this still affects the Bionic package.
<mitya57> Ok, changed to Confirmed.
<jdonald> Much appreciated.
#ubuntu-devel 2019-02-18
<xnox> teward, sarnold - https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2016-February/016208.html
<xnox> teward, sarnold - we still use the Ogre Onion model from Shrek; however we only make sure that binary packages are a closed set which ever expands as main) restricted) universe) multiverse)
<xnox> things have binary depends on its own layer, and anything to the left of it.
<xnox> and yes we do split publishing a lot, i.e. src:main can produce bin:main bin:restricted bin:universe bin:multiverse from a single build. In practice, producing both bin:main and bin:universe is the most common results of split publishing. Ie. see boost
<sarnold> ogre onion? :)
<andrewsh[m]> hi everyone
<andrewsh[m]> whatâs the procedure to RM obsolete and insecure packages from old releases?
<andrewsh[m]> matrix-synapseâs upstream says theyâre unhappy with bionic and cosmic shipping old releases without security fixes, so Iâm contemplating what can be done about them
<sarnold> https://launchpad.net/ubuntu/+source/bitcoin/+changelog
<andrewsh[m]> if they cannot be bumped them to the latest upstream release, it would be better to actually remove them
<sarnold> https://launchpad.net/ubuntu/+source/owncloud/+changelog
<cjwatson> xnox: It's still slightly onioned even for build-dependencies, just simplified to consider only the freeness axis
<cjwatson> (which I'm sure you know, but it occasionally comes up and is worth being clear)
<RAOF> <andrewsh[m] "matrix-synapseâs upstream says t"> Have they considered providing a snap? ð
<andrewsh[m]> they provide debs, and I tried to convince them to provide a flatpak, but thatâs not the point I was trying to make
 * RAOF would consume such a thing.
<andrewsh[m]> the point is that those releases captured whatever I uploaded to Debian at that time
<andrewsh[m]> and thatâs not necessarily whatâs best for the users
<RAOF> Oh, absolutely. Probably what you want to do is get an empty package SRUed.
<RAOF> I was just being snarky.
<sarnold> well, bitcoin crashed 90% and no one even remembers owncloud any more -- I'm not saying they are correlated to being yanked from our archive .. but .. :)
<mdeslaur> lol
<andrewsh[m]> an empty package SRUed? how exactly does that work?
<mdeslaur> andrewsh[m]: look at the two links sarnold provided for examples
<andrewsh[m]> oh, I hadnât realised it was related to my questions
<RAOF> An empty packaged SRUed is the closest to âremove from the archiveâ we can do.
<andrewsh[m]> right, do I need to prepare the upload myself and then prod someone?
<andrewsh[m]> or do I just need to prod someone to do both? ð
<sarnold> definitely it'll go way faster if you prepare the upload; I can't promies it'll happen, but it'll definitely go smoother if you do a ton of the work :)
<ahasenack> doko: I'm thinking we cannot upgrade pmdk to 1.5 at this time
<ahasenack> doko: 1.4 -> 1.5 is a big change, never mind the minor version bump
<ahasenack> biggest issue I see is this:
<ahasenack> """
<ahasenack> Beyond that, it introduces
<ahasenack>     new APIs, new tools and many other improvements. As a side effect
<ahasenack>     of performance optimizations, the libpmemobj on-media layout had to be
<ahasenack>     changed, which means that old pools have to be converted using pmdk-convert.
<ahasenack> """
<ahasenack> problem is, pmdk-convert is a new source
<ahasenack> it used to be part of the pmdk tools package, in the "pmempool(1)" command
<ahasenack> but in 1.5 the removed it from the pmdk source and made a new project in github: https://github.com/pmem/pmdk-convert
<ahasenack> and debian hasn't packaged that as far as I can see
<ahasenack> so it would be a NEW package in ubuntu
<ahasenack> "    - pmempool: "convert" subcommand is now a wrapper around pmdk-convert
<ahasenack>       (please see https://github.com/pmem/pmdk-convert)
<ahasenack> "
#ubuntu-devel 2019-02-19
<alkisg> vorlon: sorry for the direct ping, re: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1813541 - is it possible that `apt source shim` in 18.04 shows different code than the binary shipped/signed by microsoft?
<ubottu> Launchpad bug 1813541 in shim (Ubuntu) "Shim uses wrong TFTP server IP in proxyDHCP mode" [Medium,Triaged]
<alkisg> Because I'm trying with upstream shimx64.efi and it works, yet 18.04's shim doesn't, even though the patch seems to be in the codebase...
<Wimpress> rbasak: Here you go - https://forum.snapcraft.io/t/installing-snap-on-centos/10020
<Wimpress> Cover RHEL too.
<Wimpress> Linked from https://docs.snapcraft.io/installing-snapd/6735
<vorlon> alkisg: there are lots of ways that apt source might give you different behavior depending on what's in your sources.list, did you check that the versions match?
<alkisg> vorlon: yes, I only have the "normal" sources list, the versions match
<vorlon> alkisg: ok; then that is the source for the binary included in the shim-signed package
<alkisg> vorlon: if the shim binary is signed by ms on every shim package update, then the problem is elsewhere and I'll find it; I just wanted that part from you, if it's signed on every build
<alkisg> Thank you :)
<vorlon> it's not signed on /every/ build, but every shim package version that gets published to the archive is also signed by MS
<alkisg> Right, that's what I meant, my english failed me
<alkisg> (probably another patch was needed which is available upstream, not just the one pointed out by the developers)
<cyphermox> alkisg: what patch?
<cyphermox> alkisg: basically, the source in src:shim should match the binary in source:shim-signed
<cyphermox> well, the other way around, modulo the microsoft signature
<cyphermox> we actually test for that at build-time for shim-signed
<alkisg> cyphermox: yup, that's what I was asking. So, in  https://github.com/rhboot/shim/issues/165, they pointed out commit 5f4fd53 which we do have, but probably b3e4d1f is needed as well; I'll check now if we have that already, e.g. in disco
<alkisg> Ah disco has the same shim version, nevermind
<rbasak> Wimpress: thanks!
<cyphermox> b3e4d1f is just the tip
<cyphermox> is it not?
<alkisg> Let me check...
<cyphermox> nevermind
<cyphermox> it was the tip at which my tree was before I just pulled
<cyphermox> but that's like, 4 commits away from 3beb291; which is what disco is
<alkisg> cyphermox: well, it's possible that the fix for the issue I see is there; I don't mind if Ubuntu gets it sooner or later, as long as we do get it :)
<cyphermox> sure sure
<cyphermox> I do plan on updating shim again very soon, but it's at least two weeks away from now, at the earliest
<alkisg> Oh great, I'll test again then
<alkisg> Thank you cyphermox :)
<cyphermox> none of the commits in between 3beb971 and b3e4d1f are netboot.c relevant
<alkisg> That would leave me with the question... "wth, why is upstream shim working and ubuntu's not..." :)
<jamespage> cpaelzer_: are we stillhaving to blacklist the i386 testing for proposed migrations?
<cpaelzer_> jamespage: my last test was a few weeks ago and still failing
<jamespage> cpaelzer_: ack - raised a review to bump
<jamespage> https://code.launchpad.net/~james-page/britney/ovs-bump/+merge/363351
<infinity> ahasenack: Are you aware of apache2's failing autopkgtests?
<infinity> ahasenack: Why is t/apache/expr_string.t poop?
<ricotz> infinity, the new dpkg doesn't create a Binary field in .changes files
<ricotz> launchpad doesn't like that
<infinity> ricotz: Well that's fun.
<infinity> ricotz: Example?
<ricotz> Rejected:
<ricotz> Unable to find mandatory field 'Binary' in the changes file.
<ricotz> Further error processing not possible because of a critical previous error.
<infinity> ricotz: Is that a source upload or a build?
<ricotz> I would assume this happens with any package, or did I hit some intermediate state?
<ricotz> the source upload
<ricotz> this happened already with the previous try to update to 1.19.4
<infinity> Fun.  doko didn't mention that bit when he asked me to re-do the merge. :P
<infinity> Very much an intentional change:
<infinity>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818618
<ubottu> Debian bug 818618 in dpkg-dev "dpkg-genchanges: Please exclude packages disabled in unstaged builds" [Normal,Fixed]
<ahasenack> infinity: hm, no, I wasn't aware, it wasn't in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#ubuntu-server this morning, but is now
<ahasenack> let me check
<ahasenack> I see it failed the same way once when I uploaded openldap
<ahasenack> and passed after a retry. Still, annoying to have a flaky test
<sarnold> robert_ancell: sigh. I can't recall now where the discussion about mlockall and lightdm was; ~300 M feels like quite a lot to pin into memory. If you can limit it to the password field, and anything derived from it, that'd be better
<robert_ancell> sarnold, I guess that's hard because the password is used in many places.
<robert_ancell> I think just dropping the mlockall entirely is probably the way to go for now and adding in something better in the future if necessary
<sarnold> robert_ancell: hmmm.. what do you think about using MCL_ONFAULT ? it's really new.. (I just learned about it a moment ago :)
<robert_ancell> I have no idea what that is - I'd have to look it up
<sarnold> it locks in pages as they are faulted in; unused parts of libraries etc wouldn't necessarily be faulted in
<doko> infinity: no, I wasn't aware of that one
<robert_ancell> sarnold, is there a way to check how much memory is locked in a process?
<sarnold> robert_ancell: I believe the Locked: lines in /proc/self/smaps would show that
#ubuntu-devel 2019-02-20
<LocutusOfBorg> oSoMoN, hello, https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1667208 and https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1816736 ping :)
<ubottu> Launchpad bug 1667208 in chromium-browser (Ubuntu) "Ubuntu's selenium hardcodes a path that is valid for Debian, but not for Ubuntu" [Undecided,Confirmed]
<ubottu> Launchpad bug 1816736 in thunderbird (Ubuntu) "llvm-toolchain-4.0: Remove from disco" [Undecided,New]
<oSoMoN> LocutusOfBorg, they are on my radar, just not my top priority atm
<LocutusOfBorg> oSoMoN, I can do them if you want :)
<oSoMoN> LocutusOfBorg, bug #1816736 is fixed for firefox in the beta builds, at https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+packages
<ubottu> bug 1816736 in thunderbird (Ubuntu) "llvm-toolchain-4.0: Remove from disco" [Undecided,New] https://launchpad.net/bugs/1816736
<oSoMoN> I'll look at thunderbird shortly
<infinity> sil2100: You have a fresh d-i for xenial in the queue.
<oSoMoN> LocutusOfBorg, and I'm working on a chromium stable update with the fix for bug #1667208
<ubottu> bug 1667208 in chromium-browser (Ubuntu) "Ubuntu's selenium hardcodes a path that is valid for Debian, but not for Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1667208
<LocutusOfBorg> thanks!
<sil2100> infinity: woot, thanks
<sil2100> infinity: ok, looks good, let me accept it, hopefully we'll still be able to fit linux-firmware
<sil2100> Guess we'll know once we build!
<cyphermox> vorlon: grub merge "done", ftbfs due to a mismerge on my part. I expect it will be ready to upload before EOW.
<cyphermox> cjwatson: ^
<cyphermox> it's the linux_params_ptr change for i386, so I know what patch to look at, it did come up as a conflict earlier.
<cjwatson> cyphermox: awesome
<didrocks> https://github.com/ubuntu/ubuntu-report
<sarnold> wow a genoowine Intius Corus processor!
<chiluk> hey arges/rbasak can I get some sru approval love for https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=pulseaudio and  https://launchpad.net/ubuntu/cosmic/+queue?queue_state=1&queue_text=pulseaudio
<chiluk> arges rbasak ^
<seb128> xnox, can you cherrypick https://github.com/systemd/systemd/pull/11697 to disco? it's a regression from system 240 which impacts some of the flavors/sessions
<rbasak> chiluk: sorry, unlikely this week - sprinting
<chiluk> no worries.. I'll get arges to do it, he's already reviewed the upload ..
<vorlon> ogra: do you want to reupload initramfs-tools-devices from cosmic-proposed/new to disco-proposed/new, since it failed to get processed timely last cycle?
<ogra> what is initramfs-tools-devices ?
<ogra> (sure, i can help out here but i cant remember having heard of it)
<vorlon> ogra: so you don't remember having uploaded it and I should just reject it now
<cjwatson> ogra didn't upload it, it just cites him as an author of a script in it
<cjwatson> https://launchpadlibrarian.net/384999453/initramfs-tools-devices_0.1_source.changes
<ogra> aha
<ogra> oh, might be that i helped abeato with it
<ogra> abeato, ^^ see above
<ogra> (i might have signed it back then)
<cjwatson> ah, could be, I didn't check the sig
<vorlon> yeah I was looking at the sig
<ogra> right ... lets wait for him to cmment ... i can surely re-upload if it is still needed
<ogra> *comment
<abeato> vorlon, ogra, cjwatson yes, I would like to have it uploaded
<ogra> ok, lets talk tomorrow then
<abeato> the idea is to split the UC tools in two parts
<abeato> one that is core-only and other that can be used in classic images too
<ogra> i think thats all fine, we just didnt make it in time for release in cosmic
<ogra> (apparently)
<abeato> yeah, it took me a bit until I fixed the linter errors
<abeato> vorlon, cjwatson ogra this is the bug: https://bugs.launchpad.net/ubuntu/+bug/1788601
<ubottu> Launchpad bug 1788601 in Ubuntu "[needs-packaging] It should be possible to use some initramfs-tools-ubuntu-core scripts in classic systems" [Wishlist,In progress]
<abeato> and latest version is in https://launchpad.net/~alfonsosanchezbeato/+archive/ubuntu/initramfs-packages
<cjwatson> untag me please, I was just commenting on the authorship
<abeato> alright
<bdmurray> cpaelzer__: I've heard you are working on the mailman3 mir stuff and was wondering if the server team wanted to subscribe to zope.event.
<vorlon> infinity, xnox: is it possible that we should consider dropping 'nolapic' as an option in the Advanced menu in the installer screen
<infinity> vorlon: Context?
<cpaelzer__> bdmurray: yes, we eventually will subscribe to all of them
<cpaelzer__> bdmurray: we just kicked off the 49 packages that we need to MIR
<cpaelzer__> bdmurray: zope.event will be one of them
<cpaelzer> grr - underscore inflation
#ubuntu-devel 2019-02-21
<jbicha> RAOF: looks like new dpkg broke colord autopkgtests https://ci.debian.net/packages/c/colord/testing/amd64/ I wonder why test 2 went from SKIP to FAIL
<cpaelzer> dannf: FYI - the requested libvirt uploads are now in the SRU unapproved queue
<bdmurray> cpaelzer__: I think zope.event already made it to main hence my question
<RAOF> jbicha: Urgh, thanks. I'll take a look today.
<cyphermox> cpaelzer__: doko: didrocks: for MIRs; would we want to add the Debian Perl Group to the list of official bug subscribers? they seem to be subscribing to the packages, and actually paying attention to the MIR bugs even.
<didrocks> cyphermox: I trust your analyze, so if that fit with your review, that's ok for me
<cyphermox> didrocks: infinity pointed it out; they're very responsive, pay attention to the bugs and all of that. Usually for MIRs we expect some kind of Canonical team, but I don't know that we can't make an exception for highly responsive "upstreams" for stuff that happens to show up a lot for the distro
<cyphermox> ie. devscripts gaining a bunch of depends for various perl magic; lots of it is trivial to review too :)
<cyphermox> I think libhttp-tiny-multipart-perl contained more test code than feature code.
<didrocks> cyphermox: LGTM then, +1
<didrocks> I'll let others give their opinions too :)
<cyphermox> yup
<didrocks> also, well Perl ;)
<cyphermox> jdstrand: ^
<cyphermox> didrocks: Perl <3, my first love.
<didrocks> cyphermox: only on Friday afternoon, before week-end and booze :)
<didrocks> that's my rule :p
<sarnold> cyphermox: part of the team subscriber thing is that if canonical is saying we'll support this package, that someone at canonical will notice bugs..
<sarnold> cyphermox: .. certainly having the debian perl team subscribed would be quite nice, but that's not the same as saying someone at canonical will review issues as they come in
<cyphermox> nah, that's what I was saying earlier, but the exception doesn't feel too bad considering the kind of packages we're looking at in this case; perhaps we should review those case-by-case
<cyphermox> I mean, here, it's for devscripts, which is low-level distro stuff that we definitely use; it's different than reviewing a new package for the desktop for instance
<sarnold> good point
<cyphermox> I guess that means it would have to be case-by-case
<jdstrand> cyphermox: I'm all for adding them, but does that group perform uploads to Ubuntu for bug fixes? if not, then we'll only get fixes for the dev release and not stable releases
<jdstrand> bug fixes in SRUs*
<jdstrand> bug fixes in dev releases is great, but users run stable releases (of course) and if no one is looking after taking care of them, I think I defeats the purpose of requiring a bug subscriber
<infinity> coreycb: Yo.
<infinity> coreycb: chown -R masakari:masakari /var/lib/masakari /etc/masakari
<infinity> coreycb: ^-- explain to me why it should own and have write access to its conffiles.
<RAOF> coreycb: Also, you seem to have two patches - one to disable a failing test on python3.6, and one to fix the test that the other patch disables?
<RAOF> rbalint: You're a bit optimistic that waylandpp will make it through NEW before feature freeze, right? ð
<seb128> RAOF, upload date is what counts for ff, not accepted date
<RAOF> seb128: Yeah, but he should also be uploading the new kodi release that depends on his NEW package, too :)
<doko> ahasenack, cpaelzer_: looked at talloc. looks like both the architecture name and the python version is still encoded ...
<doko> +libpytalloc-util.cpython-37m-x86-64-linux-gnu.so.2 python3-talloc #MINVER#
<doko> + PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.15@PYTALLOC_UTIL.CPYTHON_37M_X86_64_LINUX_GNU_2.1.15 2.1.15-0ubuntu2
<doko> + PYTALLOC_UTIL.PY3_2.1.10@PYTALLOC_UTIL.PY3_2.1.10 2.1.15-0ubuntu2
<doko> + PYTALLOC_UTIL.PY3_2.1.11@PYTALLOC_UTIL.PY3_2.1.11 2.1.15-0ubuntu2
<ahasenack> that I don't know how to change
<doko> looking at my old patches, and then asking upstream ...
<doko> ahasenack: samba-technical talks about a nopython build ...
<cyphermox> jdstrand: best point against it, then; but either way we still need someone on the hook for it in Canonical.
<seb128> RAOF, well, upload, it will depwait and technically it's before ff :)
<infinity> doko: When you remove stuff like https://launchpad.net/ubuntu/+source/libmarc-charset-perl/+publishinghistory "for autopkgtest failures", could we have a bug for reference so we have a clue *what* you removed, and a bit more why?
<infinity> doko: LocutusOfBorg is attempting to reintroduce it (which seems reasonable, cause I can't work out how it was reasonable to remove it), but now I have no idea what else was removed at the same time.
<infinity> Looks like libmarc-xml-perl is the only rdep in unstable.
<doko> infinity: did you look at the removal message. no, I don't remember why
<infinity> doko: Yes.  The removal message that said you removed it "for autopkgtest failures".   Which is a bit of a piss-poor reason to remove a package.  But also, mentions you removed its rdeps, with no mention of what packages those were.
<LocutusOfBorg> doko, autopkgtestsuite failed on arm* probably
<doko> infinity: just this, or together with another package?
<doko> hmm, so you cannot see which packages were removed together?
<infinity> doko: No.
<doko> crap
<infinity> doko: I *think* it was only 2 packages, based on the rdeps in Debian, and those are both back now, but can't say for sure, which is annoying.
<LocutusOfBorg> libmarc-xml-perl libmarc-charset-perl
<infinity> LocutusOfBorg: Those would be the two I'm assuming.
<LocutusOfBorg> and now libcatmandu-marc-perl
<LocutusOfBorg> so we don't keep removal logs?
<infinity> Oh, also libnet-z3950-simple2zoom-perl
<infinity> LocutusOfBorg: Not as batches.
<infinity> LocutusOfBorg: The publishing history of a package gives the removal comment.  If the comment is useless, \o/
<doko> ahasenack: there are no rdeps for python2 samba packages, just python-tdb is recommended by bzr-git
<infinity> Right, copying libnet-z3950-simple2zoom-perl back in too.
<LocutusOfBorg> thanks
<infinity> LocutusOfBorg: You might still get to figure out what's up with the autopkgtest failures that doko deleted for back in bionic, if you want this all to migrate.
<infinity> LocutusOfBorg: But I'll leave that to you.
<LocutusOfBorg> I already had a quick look
<LocutusOfBorg> btw, wasn't "kick out to proposed" enough for the perl migration? I don't understand why they were removed
<infinity> LocutusOfBorg: I'm with you.
<infinity> LocutusOfBorg: Unfortunately, not all AAs agree (and doko isn't alone in his view)
<rbalint> RAOF, patches are even more welcome than snarky comments ;-)
<infinity> rbalint: ?
<RAOF> rbalint: But less easily generated!
<LocutusOfBorg> oh, ok nice to know there are different point of view :)
<infinity> LocutusOfBorg: Yeah, I'm working on turning us into one, homogenous hive-mind, but these people and their opinions keep getting in my way. :P
<doko> we should implement auto-removals like Debian is doing ...
<tdaitx> oSoMoN: hi! how is the libreoffice update in bionic going regarding the openjdk-11 support?
<infinity> jamespage: Yo.  Re, python-os-ken.  While "do stuff | :" will technically do what you want, because true always exits 0 regardless of input, I'm pretty sure you meant "||" (or) not "|" (pipe) :P
<jamespage> infinity: looking
<infinity> jamespage: Not remotely reject-worthy, cause hey, it'll work anyway, just thought I'd mention it.
<jamespage> infinity: thanks indeed you are quite right
 * jamespage commits that fix now
<infinity> jamespage: If you're in a nitpicky mood, try a "lintian -I --pedantic" too.
<jamespage> infinity: looks like I have some updates I need to work into my cookiecutter template
<oSoMoN> tdaitx, not sure I understand your question, is openjdk-11 going to be backported to bionic?
<Lamentin> hello
<tdaitx> oSoMoN: yes, it is, we are working on the transition and libreoffice is one of the packages that fail... the way I was told led me to believe you knew about the transition
<abeato> sil2100, https://bugs.launchpad.net/ubuntu-image/+bug/1817050
<ubottu> Launchpad bug 1817050 in Ubuntu Image "Updating grub-efi breaks classic images" [Undecided,New]
<oSoMoN> tdaitx, I didn't, but that's good news as it should finally address that i386 crash
<oSoMoN> tdaitx, where can IÂ inspect the failed builds?
<tdaitx> oSoMoN: doko did a rebuild with openjdk-11, you can find it @ http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-test-bionic.html
<oSoMoN> tdaitx, that looks like an easy one, we'll need that patch: https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/tree/patches/fix-tests-openjdk11.patch?h=ubuntu-disco-6.1
<oSoMoN> tdaitx, I can prepare a PPA with that patch and building against https://launchpad.net/~openjdk-r/+archive/ubuntu/ppa/+packages, to check whether that's all that's neede
<oSoMoN> needed
<oSoMoN> (after lunch)
<bdmurray> xnox: Could the test case in bug 1813888 be a bit more descriptive?
<ubottu> Error: Could not gather data from Launchpad for bug #1813888 (https://launchpad.net/bugs/1813888). The error has been logged
<xnox> bdmurray, expanded
<oSoMoN> tdaitx, LO building against openjdk-11 in https://launchpad.net/~osomon/+archive/ubuntu/lo-bionic-openjdk11/+packages
<jbicha> xnox: I reported the geary test failures at https://gitlab.gnome.org/GNOME/geary/issues/259 & https://gitlab.gnome.org/GNOME/geary/issues/260
<sil2100> seb128: evolution*, right?
<seb128> sil2100, yes
<LocutusOfBorg> oSoMoN, looks like chromium is having a sad day...
<oSoMoN> LocutusOfBorg, yes, I'm looking at it
<coreycb> infinity: RAOF: thanks for the review. i've updated the chown and uploaded again. RAOF, i double checked the skipped tests and they are not fixed by the other patch so we need to keep both patches for now.
<coreycb> and the reason it's 0ubuntu2 is just because it's easier than reverting tags etc in our git source repo
<infinity> coreycb: chown -R root:masakari /etc/masakari still doesn't make sense unless it's shipped 750 (and has sensitive data in it)
<coreycb> infinity: it's 644 so masakari just gets read access.
<coreycb> let me check again
<coreycb> it should be 640 for the chown i currently have
<infinity> coreycb: Eh?
<coreycb> infinity: ok it's 644 so are you ok with me keeping that chown and adding a chmod 640?
<infinity> coreycb: You have a sqlite DB in /var/lib at 640, you have a log directory at 750.  Neither of those is the config dir in /etc
<coreycb> infinity: i thought we were focused on /etc
<infinity> coreycb: I think you mean 755/750, not 644/640, but sure, if /etc/masakari contains secrets that non-root users shouldn't see.
<infinity> coreycb: If it doesn't contain secrets, then there's zero reason for the chown (nor a chmod).
<coreycb> infinity: probably could just use the defaults. nothing should be executable in /etc/masakari though.
<coreycb> infinity: want me to just switch to no chmod/chown?
<infinity> coreycb: ... nothing is executable?
<infinity> coreycb: We're talking about the permissions of a directory, not a file.
<coreycb> infinity: well it's both. it's a postinst script.
<coreycb> infinity: here's what we currently get out of it: https://paste.ubuntu.com/p/J8kTghGdCz/
<coreycb> infinity: /etc/masakari/masakari.conf will have a db password in it. there may be more sensitive bits.
<coreycb> infinity: definitely open to suggestsions. i'd like to get this right.
<seb128> cyphermox, we would like to get https://github.com/jwrdegoede/grub2/commit/0e6652a6981cf5f9cd4b76fedbf3b68d46b2860a.patch in disco for less-boot-flicker (fedora ships it), any opinion? do you want/can you reiew it? should I just upload?
<acheronuk> doko: why is there an empty llvm-config-patch.diff in clazy? I just left it there in the merge I did this morning as was in a hurry, but thought I better ask in case
<acheronuk> *llvm-config.diff
<doko> acheronuk: just remove
<acheronuk> doko: cheers. I figured as much but had to check. I'll do a ubuntu2 later. thanks
<infinity> coreycb: If it's just one file, that should be 640, root:masakari, if you genuinely don't know what might be in that directory, 750 root:masakari for the dir is fine.
<infinity> coreycb: Right now, it was 755 root:msakari, which makes no sense.
<coreycb> infinity: ok i'll rework it to 750 root:masakari for the dir
<infinity> coreycb: Kay.
<xnox> jbicha, thanks!
<jbicha> xnox: I see you're interested in s390x and geary so you might need to help upstream when you get some time
<xnox> jbicha, not really! i want the new geary to migrate! =)
<xnox> on amd64
<jbicha> well you're more interested in s390x than anyone I know, but I guess not for geary directly
<cyphermox> seb128: I will do it; in the middle of a grub merge right now
<seb128> cyphermox, thx
<coreycb> sil2100: hi, if you have a moment we have a horizon fix in the cosmic unapproved queue that fixes an issue being hit by field engineers upon upgrade from openstack queens to rocky.
<sil2100> coreycb: hey! I think I can take a look
<coreycb> sil2100: thanks :)
<gaughen> thank you bdmurray!
<coreycb> infinity: i've uploaded masakari with the etc changes. thanks for reviewing this btw. i'll make sure our other packages are inline once this gets accepted.
<infinity> coreycb: Accepted.
<cyphermox> seb128: might slip the FF deadline, but I'll do the paperwork if that happens
<coreycb> infinity: thanks again
<seb128> cyphermox, cool, thx
<sil2100> Laney: I have updated the MP for britney SRU stuffy: https://code.launchpad.net/~ubuntu-release/britney/+git/britney2-ubuntu/+merge/355544
<sil2100> Laney: it's good for review although I still need to setup a local britney setup and see how it acts (so no mergy-mergy yet)
<sil2100> But a code review at least would be highly welcome
#ubuntu-devel 2019-02-22
<Laney> sil2100: will look but it'll probably have to be next week (sorry for the delayed reply)
<sil2100> Laney: no worries o/
<Laney> :>
<oSoMoN> tdaitx, LO 6.0.7 built successfully against openjdk-11 in https://launchpad.net/~osomon/+archive/ubuntu/lo-bionic-openjdk11/+packages
<oSoMoN> so it looks like that patch is all that was needed
<oSoMoN> I'll do some smoke testing in a VM to verify that the basic functionality that relies on the JVM works
* Laney changed the topic of #ubuntu-devel to: Archive: FF, DIF | 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:
<bdmurray> rbalint: Here is how gdb is called and the issue I'm seeing - https://pastebin.ubuntu.com/p/Dv5p54XPYt/
<rbalint> bdmurray, seems like this one https://sourceware.org/bugzilla/show_bug.cgi?id=10542
<ubottu> sourceware.org bug 10542 in symtab "'set debug-file-directory' has no effect" [Normal,Unconfirmed]
<rbalint> bdmurray, or it seems to be fixed only partially
<oSoMoN> tdaitx, smoke testing didn't uncover any obvious regressions, and I confirm that the crash on i386 is gone
<oSoMoN> tdaitx, and I've pushed the patch to the libreoffice source package VCS: https://code.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/+git/libreoffice-debian-pkg/+ref/ubuntu-bionic-6.0
<RAOF> jbicha: I have not forgotten colord. I don't know why it's failing, but it fails in a local autopkgtest run and *appears* to be an actual test failure, but I have absolutely no idea what's wrong.
<infinity> RAOF: I suspect what's wrong is that colord is a flaming heap.
<LtWorf> what's ubuntu going to do about iptables nft? Debian basically replaced iptables to use nft and called the normal iptables "iptables-legacy"
<LtWorf> (whichis kinda fucked since it breaks EVERYTHING)
<sarnold> LtWorf: we're apparently getting that when this clears -proposed https://launchpad.net/ubuntu/+source/iptables/1.8.2-3ubuntu1 -- I don't know when that is, but it's coming
<sarnold> LtWorf: ufw can manage with the netfilter backend to the 'new' iptables; libvirt's got an issue (I don't know what) with the 'new' iptables
<sarnold> and here's the excuses page http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#iptables
<LtWorf> ok thanks!
<infinity> Laney: Is it expected for me to no longer have a dock?
<infinity> Laney: Nevermind, seb128 got me sorted out.
<jbicha> RAOF: before this week, the failing colord test was just skipped ð¤·
<RAOF> <freenode_jbi "RAOF: before this week, the fail"> Huh! I wonder what caused it to start not being skipped.
<jbicha> RAOF: it looked like the dpkg update might have triggered the failure but I don't understand whyâ¦
<jbicha> https://ci.debian.net/packages/c/colord/unstable/amd64/ is kind of special: I managed to get colord to pass once (Jan 22)
<infinity> jbicha: Blaming dpkg for colord is surely a red herring.
<jbicha> infinity: perhaps but the evidence does point to dpkg being the trigger https://ci.debian.net/packages/c/colord/testing/amd64/
<seb128> does anyone has an idea what makes libhsqldb1.8.0-java uninstallable in disco builders?
<infinity> jbicha: Oh.  Does it use start-stop-daemon, perchance?
<infinity> jbicha: There's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921557 maybe?
<ubottu> Debian bug 921557 in dpkg "start-stop-daemon: behavior change on "matching only on non-root pidfile /run/exim4/exim.pid is insecure" not fully documented" [Important,Open]
<jbicha> infinity: it doesn't look to me like it uses start-stop-daemon
<oSoMoN> seb128, libhsqldb1.8.0-java depends on libservlet3.1-java, which depends on libjsp-api-java, which doesn't exist
<cjwatson> oSoMoN: I just NEWed it
<oSoMoN> cjwatson, thanks
<seb128> oSoMoN, cjwatson, thx
<cjwatson> (after bootstrapping it, at doko's request)
<seb128> oSoMoN, I tried in a pbuilder and it didn't hit the error unsure why, but good it's fixed, we can retry libreoffice in a bit then
<oSoMoN> yep
<cjwatson> Your pbuilder may just not have had -proposed enabled
<seb128> I did enable proposed, maybe I hit the local proxy or something? or maybe I screwed up... anyway doesn't matter much if it's resolved
<cjwatson> seb128: Oh yeah, the local proxy will very probably ruin your day
<seb128> :)
<cjwatson> At least if you wanted to have a view that does more than pretend to be a little bit current
<seb128> right, that's my bet on why I didn't reproduce the issue
#ubuntu-devel 2019-02-23
<balasankarc> Hi, How often are packages synced from Debian Unstable to Ubuntu?
<jbicha> balasankarc: about 4 times per day except we are now in Debian Import Freeze so autosync has been turned off until the 19.10 cycle begins https://wiki.ubuntu.com/DiscoDingo/ReleaseSchedule
<balasankarc> jbicha, Cool. Thanks.
<mwhudson> huh the glibc autopkgtests don't look toooo bad
 * mwhudson retries a few things in lieu of doing any thinking
<velix> I've just reported a bug for a package of Cosmic. Can anyone please have a look if it's understandable? https://bugs.launchpad.net/ubuntu/+source/fuse3/+bug/1817437
<ubottu> Launchpad bug 1817437 in fuse3 (Ubuntu) "several problems while backporting" [Undecided,New]
<JackFrost> That's an interesting error, as ninja is a newer buildsystem I wonder if something was fixed in debhelper.
<JackFrost> velix: Amusingly, if you use meson from disco, it builds fine fwiw.
<velix> JackFrost: Oh, I already thought that the building dependencies have the wrong version number.
<velix> JackFrost: let me backport meson.
<velix> Oh my... building meson is like ... dumping 1 GB of stuff on my disk ... literall.
<JackFrost> Yeah I was in a chroot, so just to test I simply pulled Disco's, not great at all but decent test.
<velix> JackFrost: you're right.
<velix> Just ran through.
<velix> but tests still fail
<JackFrost> In my build all 39 tests were skipped, yeah.
<velix> here they directly broke with the error described :/
<velix> But when running it manuall, nearly all tests are completed.
<velix> damn, what a BAD english today.
#ubuntu-devel 2020-02-17
<gbit86__> Anyone know if there is a direct and single keycode I can use to simulate a Control+Left arrow key input that will move a cursor by word in a GUI app?
<gbit86__> I've got a conflict on my remapping that I think can only be solved by skipping any mention of Control+Left.. because I am also remapping Control+Left to another duty.. Alt+Left as odd as that may seem..
<gbit86__> and I need Alt+Left to actually do Control+Left.. but.. so that is my world atm.
<gbit86__> The big issue is that chrome uses Alt+Left as a back button.. not easy to fix. I want it to ignore Alt+Left altogether and use Ctrl+[
<gbit86__> that's really what's screwing me over.
<cpaelzer> cjwatson: hiho - is openssh 8.2 soemthing you'd look at getting into focal https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1863447 ?
<ubottu> Launchpad bug 1863447 in openssh (Ubuntu) "openssh outdated by 8.2" [Undecided,New]
<cpaelzer> rbasak: ^^ since you asked about 8.2 as well
<cjwatson> cpaelzer: already working on it
<cjwatson> but also not at work today
<cpaelzer> thanks cjwatson I just wanted to check if it is known/under-control and that it is
<cpaelzer> enjoy your day
<ahasenack> rbasak: hi, I'm done with the my_bool ftbfs in my ppa: https://trello.com/c/SnUYinhZ https://launchpad.net/~ahasenack/+archive/ubuntu/mysql8-my-bool-removal/+packages
<ahasenack> rbasak: the remaining ones are "normal" ftbfs, which, once resolved, could still require the my_bool typedef
<ahasenack> rbasak: https://pastebin.ubuntu.com/p/PPgKpbQyrz/ standard d/changelog and dep3 patch I'm using
<ahasenack> hm, just realized I should remove the pkg name from the bug url
<ahasenack> so it can really be re-used
<ahasenack> should I start with the actual uploads? What should we do about reviews?
<ahasenack> or fix the remaining "normal" ftbfs first?
<rbasak> ahasenack: nice job!
<ahasenack> rbasak: thx! The usual pattern for the patch is as we discussed:
<ahasenack>  #include <mysql.h>
<ahasenack> +typedef bool my_bool;
<rbasak> ahasenack: I'm happy for you to start uploads in the archive immediately. But we'll need to cover those FTBFS immediately and I don't see any big benefit to starting sooner
<rbasak> But we'll need to cover those FTBFS _anyway ad I don't...
<ahasenack> FF is my concern
<rbasak> Skuggen: FYI ^
<rbasak> ahasenack: OK, go ahead then I guess. It seems unlikely that we'll get hung up on fixing any of the remaining FTBFS as a result of this change, anywa
<rbasak> y
<rbasak> ahasenack: MySQL packaging is maintained in Salsa
<ahasenack> rbasak: I was just going to "nmu" it
<ahasenack> but the mysql one I can do properly
<ahasenack> rbasak: so no git-ubuntu for mysql-8?
<ahasenack> how do you keep the g-u tree in sync with salsa?
<rbasak> I don't use the g-u tree - so I don't use upload tags and generally ignore it
<rbasak> To catch up Salsa against "NMU"s I "borrow" the git ubuntu imported tree objects
<rbasak> But make up the commits myself
<rbasak> (same as a gbp workflow I guess)
<ahasenack> how about I just use g-u for ubuntu's mysql, and then you later at some point fixup the salsa branch?
<rbasak> ahasenack: if I catch the salsa branch up quickly for you now, would it cause any difficulty to you to use it directly instead?
<ahasenack> url? Let me take a look
<rbasak> https://salsa.debian.org/mariadb-team/mysql/tree/mysql-8.0/ubuntu/devel
<ahasenack> what would I do, create a MR against it?
<rbasak> Yes please, or I can add you to the project.
<rbasak> I'm asking because I'd like the workflow settled, rather than me always playing catchup with "NMU"s from our own team.
<ahasenack> ok
<rbasak> But if you feel that you've got enough else to do already to take that on, then sure, do it how you prefer for now, but we should resolve this question later. I don't mind if you want to defer it.
<ahasenack> let me know when the tree is up-to-date
<rbasak> OK I'll update it now thanks
<ahasenack> today I suppose?
<rbasak> Next ten minutes I'm hoping
<ahasenack> ok
<tarzeau> how can i get back /usr/bin/python ?
<rbasak> ahasenack: done. Note it's the mysql-8.0/ubuntu/devel branch there - that's not the default HEAD.
<ahasenack> ok
<rbasak> ahasenack: want to give me one of the FTBFS to investigate?
<ahasenack> rbasak: icinga2 if you would
<rbasak> Sure
<ahasenack> it misdetects the boost version for some reason
<ahasenack> rbasak: ugh, another kernel source to blacklist:
<ahasenack> 18837 ?        S      0:02      |           \_ /usr/bin/perl /snap/git-ubuntu/464/usr/bin/dpkg-source -x /tmp/tmpiiuj19zk/.git/git-ubuntu-cache/linux-gcp_5.3.0-1008.9.dsc /tmp/tmp3ebzs916/x
<ahasenack> I was just checking why haproxy hasn't been imported yet
<ahasenack> that thing is probably holding the whole importer up
<ahasenack> rbasak: +1? https://pastebin.ubuntu.com/p/ryChqz8B6p/
<rbasak> ahasenack: +1
<rbasak> No need to ask IMHO :)
<ahasenack> I could have typoed it :)
<rbasak> /usr/bin/ld: cannot find -lpthreads
<rbasak> Shouldn't that be pthread (not plural) or is pthreads something different?
<rbasak> Oh apparently it's a boost thing?
<ahasenack> don't know
<ahasenack> that could just be a ./configure check, normal
<xnox> with cmake, look for "./debian/rules build" then look for the _first_ error from cmake, not the last one.
<xnox> cause it tries all the pthreads things, and there is always error about not able to find one of the alternative ptreahd names
<ahasenack> that will be the boost version check I mentioned
<rbasak> Ah
 * rafaeldtinoco uploaded pacemaker again (trying to fix up i386 issues blocking migration)
<rbasak> Thanks xnox, that helps!
<ahasenack> it wants boost 1.34, and fails to see 1.7x is higher
<xnox> lovely
<xnox> i think there must be a Boost_Version check too? cause it changed format from 1000000 to 1.00
<ahasenack> that's it then
<ahasenack> it was comparing a long number with no decimal points to "1.34"
<ahasenack> I actually filed a bug about it, sorry I forgot to mention it: https://bugs.launchpad.net/ubuntu/+source/icinga2/+bug/1863371
<ubottu> Launchpad bug 1863371 in icinga2 (Ubuntu) "FTBFS with boost 1.71" [High,New]
<ahasenack> rbasak: ^
<rbasak> Thanks
<rbasak> https://github.com/Icinga/icinga2/commit/b0b34f472ed6344d0822e9dc9e940dcc27a0751c "Fix building with Boost 1.71"
<rbasak> Upstream just removes the check.
<rbasak> I'll cherry-pick that
<ahasenack> rbasak: https://salsa.debian.org/mariadb-team/mysql/merge_requests/31 ?
<rbasak> looking
<rbasak> ahasenack: merged, thanks!
<rbasak> (the CI pipeline is broken and always fails currently)
<ahasenack> what now?
<rbasak> ahasenack: commit a changelog change, tag and upload?
<ahasenack> tag?
<ahasenack> oh, you mean do it again in g-u?
<rbasak> No
<rbasak> Just in git
<rbasak> The tag is only informative, not used for anything else
<ahasenack> what is the format?
<rbasak> I just follow the previous pattern
<ahasenack> I have too many remotes
<ahasenack> mysql-8.0/ubuntu/8.0.19-0ubuntu2
<ahasenack> ok, that format
<rbasak> Right
<ahasenack> oh, I didn't push the changelog commit, sorry
<rbasak> Also there's https://salsa.debian.org/mariadb-team/mysql/blob/mysql-8.0/ubuntu/devel/debian/README.source that explains the git namespace
<ahasenack> rbasak: will you cherry-pick this? https://salsa.debian.org/andreas-guest/mysql/commit/70eff4192548b52a02adcb0e004b572489066369
<ahasenack> and I can't push the tag to your repo
<rbasak> Let me add you to the project
<rbasak> ahasenack: done
<ahasenack> thx
<rbasak> (added you)
<rbasak> Do you still want me to cherry-pick?
<rbasak> ahasenack: also, icinga2 patch ready: https://paste.ubuntu.com/p/G2NF3YyGX8/ - that works for me locally against your PPA.
<rbasak> How do you want to handle these?
<rbasak> And would you like to give me another
<ahasenack> rbasak: get me a branch and I'll upload to that ppa
<rbasak> ahasenack: in git-ubuntu? Do we have all those relevant universe packages imported?
<ahasenack> rbasak: libdbi-drivers is one I didn't investigate
<ahasenack> rbasak: no, not impored, you are right. I have local branches just
<ahasenack> rbasak: I'll get your pastebin
<ahasenack> thx
<rbasak> Thanks
<rbasak> I'll take libdbi-drivers next then
<ahasenack> all I know about that one is that a unit test failed (run during pkg build)
<ahasenack> could be flaky, could be a can of worms. N oidea
<ahasenack> you can check the ppa build logs
<rbasak> ack
<ahasenack> https://launchpad.net/~ahasenack/+archive/ubuntu/mysql8-my-bool-removal/+build/18694052
<ahasenack> rbasak: ^
<ahasenack> rbasak: wrt mysql, let me exercise my new privileges, carefully
<LocutusOfBorg> mitya57, so with libserial fixed I guess we are waiting for you to upload this? https://salsa.debian.org/python-team/modules/qscintilla2/commit/cdf70449b3dae5a7429c3f3f3c55db3d058d3da0
<rbasak> I set a local build off to compare
 * rbasak will be back in 20
<seb128> vorlon, the colord/i386 hint force-badtest needs to be updated. Shouldn't that one just flagged as bad and not for a specific version? As the comment hints, it requires gnome-session&co
<rbasak> Looks like a minor floating point mismatch
<ahasenack> rbasak: ok, ready to upload to ubuntu
<ahasenack> got this during source package build: dpkg-source: warning: ignoring deletion of directory source_downloads
<ahasenack> due to the git empty directory issue, right?
<ahasenack> I got a warning about that dir when checking this out/cloning
<rbasak> That's normal. I did mention it to Skuggen - it's a useless empty directory in the orig tarball, yes.
<ahasenack> ok
<ahasenack> rbasak: uploaded, the race to fix things is on (as soon as it builds)
<rbasak> \o/
<rbasak> Thank you for doing this
<seb128> vorlon, openjpeg2 is blocked in proposed due Unsatisfiable depends: spawn-fcgi (>= 1.6.1): i386 ... are you looking at that? (I see you did the previous upload to ignore some debs on i386)
<ahasenack> rbasak: thx for helping
<rbasak> ahasenack: quick sync on an acceptable fix for libdbi-drivers please
<rbasak> The problem seems to be that the FLOAT4 type seems to have gotten more accurate between MySQL 8.0.16 and MySQL 8.0.19 somehow
<rbasak> test_dbi.c:3823: unit test failure: pgsql -> libdbi connection -> Retrieving fields as -> test_dbi_result_get_as_string -> [3.402823e+38] should match [3.402820e+38] at [test_dbi.c] line [3823]
<rbasak> The test is inserting 3.402823466E+38
<rbasak> I don't see anything in the release notes specifically for that, but there have been some other changes in relation to float accuracy that don't specify this change.
<ahasenack> did you find an upstream fix?
<rbasak> No. Nothing upstream.
<ahasenack> I remember glibc getting more accurate a while back
<ahasenack> but that was on year ago or more
<rbasak> Maybe it's that?
<rbasak> 2019-10-18 was the last successful build date
<rbasak> Anyway, I assume (not tested) that patching the test will work. Would you consider that acceptable?
<rbasak> I can send a report upstream of course.
<rbasak> (patching the test for the value we actually get)
<ahasenack> can you check if there is a history of such patching?
<ahasenack> in these tests
<ahasenack> but sounds good with an upstream report linked to the patch
<rbasak> The test code upstream doesn't seem to have been touched since  2017-10-27
<rbasak> I see the occasional touch of adjustment presumably for database changes, but not many
<ahasenack> rbasak: when was the last time it passed for us?
<ahasenack> and what was that numeric output then?
<rbasak> 2019-10-18
<rbasak> The output matched then presumably - 3.402820e+38
<rbasak> (since the same test passed then)
<ahasenack> and that was mysql 5.7?
<rbasak> The output is now 3.402823e+38
<rbasak> No that was 8.0.16.
<ahasenack> oh
<ahasenack> Skuggen: have you seen something like that before, changing? ^
<ahasenack> in terms of mysql releases/changes
<rbasak> Interestingly, the expected Postgres output in the test is also the less accurate 3.402820e+38
<rbasak> But there was only one test failure. Let me patch it and see.
<rbasak> The Postgres test is also affected. I had to patch both. Got a successful build now.
<ahasenack> rbasak: I'm gonna head out for lunch, thanks so far
<rafaeldtinoco> can anyone check if /etc/modules (there is a symlink inside /etc/modules-load.d/modules.conf -> /etc/modules) still works in Focal ? My understanding is that /lib/systemd/systemd-modules-load will load modules described in /etc/modules. That is not ocurring for me, just want to confirm.
<rafaeldtinoco> Oh, nm, its a watchdog module.. I think its blacklisted by default
<rafaeldtinoco>  /lib/modprobe.d/blacklist_linux-5.4_5.4.0-14-generic.conf
<rafaeldtinoco> yep it is. sorry for the noise
<ahasenack> rbasak: https://debconf19.debconf.org/talks/63-how-mariadb-packaging-uses-salsa-ci-to-ensure-smooth-upgrades-and-avoid-regressions/
<ahasenack> rbasak: the slides are probably in salsa somewhere
<ahasenack> rbasak: these are the notes I took when the "workarounds" topic came up: https://pastebin.ubuntu.com/p/trGmBy9n8f/
<rbasak> ahasenack: here's the libdbi-drivers fix: https://paste.ubuntu.com/p/NpkMY7HMfh/ - turns out only the Postgres test needed tweaking. Patching the MySQL test seems to make no difference, so I didn't.
<ahasenack> rbasak: thanks!
<ahasenack> rbasak: and icinga2 rebuilt just fine in the ppa
<rbasak> ahasenack: next?
<ahasenack> rbasak: zoneminder is harder (https://bugs.launchpad.net/ubuntu/+source/zoneminder/+bug/1859295)
<ubottu> Launchpad bug 1859295 in zoneminder (Ubuntu) "zoneminder 1.32.3-2build1 does not work with MySQL 8" [Undecided,New]
<ahasenack> rbasak: apr-util is just a matter of s/python/python2/ I believe
<ahasenack> unless we want to move to py3, then some patches from upstream have to be cherry-picked
<rbasak> Let me look at apr-util first then, as I don't have much of my day left
<ahasenack> "apr-util: Depends: python:any but it is not installable"
<rbasak> src:apr has the same issue
<rbasak> And if I fix apr-util, then the build still fails because a file provided by src:apr has a python (not python2) shebang
<vorlon> seb128: ok, I'll follow up on openjpeg2, apparently my removal of libopenjpip-server on i386 didn't actually take
 * rbasak continues digging
<rbasak> ahasenack: OK so to fix apr-util we need to patch both apr and apr-util. Here are the unpolished patches. Is the general approach the one we want: apr: https://paste.ubuntu.com/p/Kn9GHT2HpY/ apr-util: https://paste.ubuntu.com/p/kMJjRmJh8Y/
<rbasak> ahasenack: I'm going to finish for the day soon. Feel free to pass me more to do for my morning. I haven't looked at zoneminder at all yet - I can look at that tomorrow if you like.
<rbasak> And any coordination needed with Foundations and/or doko for Python related fixes?
<ahasenack> rbasak: not that I know of, since python3-defaults migrated
<ahasenack> rbasak: thanks for your help!
<mitya57> LocutusOfBorg: well, I also need to upload pyqt5 :) I will do that when python-cogent becomes a candidate for migration to testing.
<mitya57> I didn't mean fixing libserial is urgent, sorry if you understood me wrongly. But python-sip will be removed in 2-3 weeks at most.
<gbit86__> Is there a faster way to change symbols of an existing loaded xkb keymap?
<cpaelzer> Thanks kanashiro for spotting - nbdkit is odd, it seems since xenial we didn't re-build x86 binaries for dependency issues.
<cpaelzer> Just look at the builds in https://launchpad.net/ubuntu/+source/nbdkit
<cpaelzer> There is a bad kernel dependency to linux-image-amd64 not existing for us, but think we drop it - then how to resolve the circular dependency that is:
<cpaelzer> CIRCLE: src:nbdkit build-depends on binaries of src:libnbd build-depends on binaries of src:nbdkit.
<cpaelzer> If anyone here has a good recommendation how to resolve these in Focal let me and kanashiro now please.
<cpaelzer> doko: FYI the last nbdkit upload is by you, in case you rely on it to build fine ^^
<cpaelzer> kanashiro: libnbd needs nbdkit deps only for tests, so you could maybe do it in this order
<cpaelzer> 1. upload a libnbd that has all test-deps dropped and the tests disabled
<cpaelzer> 2. upload a nbdkit (-linux-* deps) that can now build finding libnbd-*
<cpaelzer> 3. upload a libnbd that has the test deps added back (now available)
<cpaelzer> kanashiro: you should be able to play through that in a PPA before doing the same in the archive
<cpaelzer> also if others have better recommendations use those, I'm guessing based on what I see
<gbit86__> ended up solving it with just using xkbcomp and skipping the setxkbmap command I was using to reset before running xkbcomp. I think xkbcomp runs a lot faster without blanking out my config first.
<gbit86__> I just like blanking it first in the past to avoid any cache issues, but I think when changing btwn 2 very similar configs it isn't much problem (only symbols change slightly, but the type and modifier levels don't).
<gbit86__> At least this seems to fix and avoid a looping keybinding issue I was running into.
<kanashiro> cpaelzer, thanks, I'll try to follow what you suggested in my ppa
<LocutusOfBorg> mitya57, I would have done that months ago, if I had noticed the switch from sourceforge to github :)
<blaze> LocutusOfBorg: is there a reason for qtcreator not migrating from llvm8?
<mwhudson> does anyone happen to know where in the maze of initramfs code udevd actually gets started?
<mwhudson> oh the udev package ships hooks/scripts
#ubuntu-devel 2020-02-18
<rbasak> cpaelzer, kanashiro: yeah - figure out a way to break the cycle temporarily. I've been asked to avoid doing that live in the archive. An archive admin will be able to advise.
<gbit86__> If anyone would look to take a stab at this problem I just posted.. then please do! https://stackoverflow.com/questions/60272229/detect-status-of-an-input-caret-under-any-or-most-linux-des
<gbit86__> like* to take a stab
<krytarik> gbit86__: I'm not sure why you still pound the development channel with that.
<gbit86__> lol.. because I am relentless in wanting to find an answer. Pretty sure it is the last thing I need to solve to button this project up.
<gbit86__> I was hitting the regular ubuntu channel but was directed to go here.
<gbit86__> And someone in the ubuntu channel was actually very helpful, pointed me to look at ibus, which did and does work on ubuntu 19.10, but not all ubuntu/debian based systems though.
<gbit86__> I tried installing ibus after the fact.. but that does not seem to be enough.
<rbasak> mwhudson: systemd is not present in docker containers> well yes, but that's not soemthing that Debian/Ubuntu developers have ever formally considered a use case that they have to maintain. We may have to change that now, but until now Docker's use has effectively been an unsupported hack from our perspective.
<rbasak> That's what I meant by "not buggy"
<rbasak> I accept that we should do what we can for DOcker users and find a solution here
<rbasak> BUt to me it's Wishlist, not a bug.
<mwhudson> rbasak: if you depend on a feature from a package that you don't depend on and that package that's not essential, it's a bug per debian policy
<rbasak> Though one that deserves some effort
<mwhudson> but this is splitting hairs
<rbasak> Only for Debian
<rbasak> Anyway, sure. I was just trying to explain what I meant.
<rbasak> I don't care how we choose to state the problem :)
<mwhudson> right, i don't think we actually disagree :)
<rbasak> mwhudson: nothing will process the tmpfiles fragments when the container starts> any chance of getting Docker upstream to provide a mechanism for that?
<rbasak> If we had a common language to tell Docker what it needs, and Docker understood that language, then that might be a clean way of making it all work end-to-end
<mwhudson> rbasak: i doubt it, but apparently the fact that /run and /tmp are not tmpfs in containers is sort of intended to make this sort of thing work
<rbasak> So we could provide an opt-in mechanism for Docker image builders?
<mwhudson> the opt in mechanism is having postinst create the directories, no?
<rbasak> Maybe. It doesn't feel generic enough to me.
<mwhudson> well the dockerish answer is "RUN mkdir /run/wibble" in your Dockerfile
<rbasak> I'm not sure there's a guarantee that in every case it's appropriate for the postinst to create all tmpfiles immediately, even if that's the default behaviour.
<rbasak> Yeah sure, but what I'm suggesting is "RUN mk-tmpfiles.d" rather than the image builder having to know specifics of each package
<rbasak> Or something even more generic and not specific to systemd
<rbasak> Then our general recommendation could be "if FROM ubuntu, then do that"
<rbasak> (or Debian even)
<rbasak> That should work today without even needing debhelper mods I think?
<rbasak> (if the mechanism is implemented, of course)
<mwhudson> rbasak: i have to run, but the idea of a solution that requires people writing dockerfiles to remember to do some extra thing to have things happen that happen automatically on installation on normal systems doesn't really appeal
 * mwhudson --> big blue (or rather dark grey today) room
<rbasak> mwhudson: sure, hence my talk of getting Docker upstream to help with that part
<rbasak> mwhudson: enjoy!
<xnox> mwhudson: I thought there was syntax to inject commands into whoever does FROM yourself.
<xnox> mwhudson: Something like: ONBUILD echo after package installation your docker file must specify RUN systemd-tmfiles --create
<xnox> I do wonder if we should drop the /run/systemd/systemd guard, or like make systemd-tmpfiles allow to fail when not booted. And make debhelper to start generating depends on tmpfiles.d (== 210) depending on which directives where added when.
<xnox> And we probably should install systemd-tmpfiles in the docker container.
<rbasak> Nice. Sounds like that could make it all magically work?
<rbasak> Without any in-distribution changes and only in our official Docker images?
<rbasak> only -> the only changes required being in, I mean
<LocutusOfBorg> blaze[m], not sure, better ask tsimonq2
<LocutusOfBorg> tsimonq2, http://debomatic-amd64.debian.net/distribution#unstable/qtcreator/4.11.0-2.1/buildlog
<mwhudson> xnox: turns out systemd-tmpfiles is linked to libsystem-shared.so which is linked to THE ENTIRE UNIVERSE but that's a solvable problem i guess
<mwhudson> /usr/bin/ld: cannot find -lpthreads
<mwhudson> how did that happen
<doko> seb128: the libxslt sync from experimental drops the xslt-config binary, causing a lot of ftbfs
<seb128> doko, I guess those need to be fixed then
<doko> or you re-add that binary
<seb128> or that
<seb128> feel free to open a bug about that, might be easier to discuss the options
<doko> I don't want to discuss, I want to have it fixed ;p, just seeing the new ftbfs working on icu
<Skuggen> ahasenack: I think we've seen floating accuracy test failures before (but IIRC it was because of different maths library on PPC), yeah
<Skuggen> Let me see if I can dig out some of those tests in MySQL itself, and I can see if they've changed recently
<Skuggen> mdeslaur dropped that patch from mysql-8.0 when importing 8.0.18
<Skuggen> Actually, that looks like it might have been an urelated change making the same edits to our upstream tests
<Skuggen> 8.0.18 does have a floating point precision-related fix, though
<ahasenack> rbasak: icinga2, the one with the boost fix, failed to build on s390x only
<rbasak> :(
<ahasenack> xnox: have you seen these before?
<ahasenack>  /usr/bin/ld: /usr/lib/s390x-linux-gnu/libboost_coroutine.so.1.71.0: undefined reference to `jump_fcontext'
<ahasenack>  /usr/bin/ld: /usr/lib/s390x-linux-gnu/libboost_coroutine.so.1.71.0: undefined reference to `make_fcontext'
<ahasenack> rbasak: the mysql8 tests seem to take longer than the allotted timeout on arm*, do you remember how this was handled in the past? There is no existing hint for mysql-8
<ahasenack> http://autopkgtest.ubuntu.com/packages/m/mysql-8.0/focal/arm64
<ahasenack> or is it hanging in that test, hmm
<rbasak> I don't recall seeing it time out
<ahasenack> the test runner times out, I mean
<ahasenack> tinoco had to retry once in the previous upload
<ahasenack> and it passed after 4h23min
<ahasenack> well, better start early
<rafaeldtinoco> yep i retried that one
<rafaeldtinoco> we should add "quilt poop" command
<rafaeldtinoco> when we are merging and we do wrong things
<ahasenack> arm64 takes twice as long as amd64
<rafaeldtinoco> yep, that is what christian has also found
<rafaeldtinoco> when building qemu
<rafaeldtinoco> at least for our build servers
<ahasenack> wow, there are libreoffice dep8 runs taking 7h+ on arm64
<rbasak> LocutusOfBorg: fancy merging lighttpd please? It's only on my list because of a no change rebuild :-/
 * rbasak doesn't understand why it must have such an extensive delta
<xnox> ahasenack:  so, coroutine is new in 1.71 on s390x. and I have seen a couple of places like that. I somehow think, I have miss-cherrypicked boost patches for boost on s390x hence it doesn't work for neither ceph nor icinga
<ahasenack> xnox: ceph is also failing to build on s390x with a similar error?
<xnox> ahasenack:  yes, when it tried to use coroutine; it doesn't use coroutine on s390x anymore.
<ahasenack> xnox: is this something you can fix for icinga2/boost?
<xnox> yes, it's on my hit list for icu & boost transitions => is it blocking you somewhere else too?
<xnox> cause then i can look into it earlier.
<ahasenack> I'm using https://bugs.launchpad.net/bugs/1863371 for icinga2
<ubottu> Launchpad bug 1863371 in icinga2 (Ubuntu) "FTBFS with boost 1.71" [High,In progress]
<ahasenack> xnox: yes, it's the only build failure in my upload
<xnox> ack
<ahasenack> thanks!
<ahasenack> rbasak: those linux-* packages I blacklisted yesterday are blocking the importer runs from importing anything else
<ahasenack> rbasak: should we build a new snap with that config and deploy?
<rbasak> ahasenack: if you kill and restart, it shouldn't reattempt unless another upload to that package is made
<ahasenack> ah, I'll do that then
<rbasak> But yes, happy for us to do another release if necessary
<ahasenack> I never find the snap service name
<rbasak> There's also a command line option to override the blacklist locally, but I'd prefer to avoid that if possible to avoid it getting out of sync
<rbasak> systemctl status --user
<ahasenack> ah, it's a user service
<Mirv> can someone point me to (if exists) some explanation why daily-live 'current' points to 4 week old focal image? it seems a bit weird starting point for testing.
<ahasenack> Mirv: the current pending image is probably failing some test which is preventing it from being promoted to "daily"
<ahasenack> it does look troublesome, though, if it has been failing checks for 4 weeks
<Mirv> right, mainly the 4 weeks sounds a bit troublesome given release in 2 months
<xnox> - default architecture     : none aha
<ahasenack> xnox: what was that?
<xnox> probably incomplete boost port to s390x!
<ahasenack> yay
<LocutusOfBorg> rbasak, .
<xnox> ahasenack:  uploaded new boost1.71 into the archive, once that builds & publishes, it might be better on s390x, and then just a retry on icinga might fix it
<xnox> if that new boost builds
<ahasenack> xnox: nice, thanks a lot, will watch it
<ahasenack> xnox: 6ubuntu3?
<ahasenack> yep
<rbasak> LocutusOfBorg: thank you!
<ahasenack> rbasak: restart didn't work as expected, it's trying again (linux-gke, linux-kvm, linux-gcp)
<ahasenack> I'll ask bryce to do a new edge release and have that deployed
<mdeslaur> is anyone working on a samba merge? ahasenack?
<ahasenack> mdeslaur: yes, I have one up for review for 4.11.5
<mdeslaur> ahasenack: awsome, thanks
<ahasenack> I pinged debian for 4.11.6, even proposed a pristine-tar branch to them so we at least get the same tarball
<ahasenack> mdeslaur: https://code.launchpad.net/~ahasenack/ubuntu/+source/samba/+git/samba/+merge/379350
<ahasenack> https://salsa.debian.org/samba-team/samba/merge_requests/45 for 4.11.6
<rbasak> ahasenack: I'm gong to attempt a second restart
<ahasenack> rbasak: why wouldn't it try again if the previous import didn't finish?
<rbasak> It gets marked as errored
<rbasak> And deliberately isn't retried
<rbasak> Until the next time a publication is made
<rbasak> Restarted
<rbasak> There were a bunch of uploads to different releases of those packages today
<rbasak> (not -gke, I'm confused why you saw that, but the others)
<rbasak> So it's possible that the future uploads kicked off new import runs even though the previous ones were errored
<rbasak> Hence my second restart
<rbasak> We'll see
<xnox> ahasenack:  so the new boost build looks a lot better; now just need to wait for it to publish, and then retry icinga
<ahasenack> xnox: ack
<ahasenack> ppc64el hasn't even started yet
<rbasak> ahasenack: restarted the importer and it doesn't appear to be stuck on any of the kernel packages yet
<rbasak> And none of them are marked 'needed' so I think we're good.
<rbasak> Maybe we need a different mechanism
<rbasak> Just blacklisting packages doesn't seem good enough if new oversized source packages keep being added like this
<ahasenack> yep
<rbasak> So what's the story with the /usr/bin/python name?
<rbasak> From doko's email we shouldn't be using it
<rbasak> But how do I explain this to upstreams? Is this in preparation for a future pointer to Python 3, or are we doing that immediately in Focal?
<ahasenack> IIRC there would be a default python late in the cycle, pointing at py3
<ahasenack> focal still
<ahasenack> but doko would know for sure
<doko> rbasak: we will have two packages, one linking to 2, one to 3, but none must be used in the archive
<doko> I have to follow-up again on this
<rbasak> doko: what can users expect to see?
<rbasak> Because if we have something by default, they'll inevitably start using that in upstream shebangs, so we'll have be be permanently patching
<doko> python-is-python2-but-deprecated and python-is-python3
<rbasak> I can point upstreams to https://www.python.org/dev/peps/pep-0394/#for-python-script-publishers I guess
<rbasak> ahasenack: do you have a current temlate for your regular typedef patch please?
<ahasenack> rbasak: just the dep3 headers
<ahasenack> rbasak: I grep for my_bool, then check if the same file includes mysql.h, and add the typedef beneath that
<ahasenack> if mysql.h is not included there, I grep to see which other file includes it, and change that one
<rbasak> I was just after your standard dep3 headers and changelog text :)
<ahasenack> just a sec
<ahasenack> rbasak: https://pastebin.ubuntu.com/p/7XqPzbGSGj/ with a helper hack/script
<rbasak> Thank you!
<rbasak> I suppose I should replace the author?
<ahasenack> sure
<rbasak> ahasenack: uploads ready for apr and apr-util: https://paste.ubuntu.com/p/SxNYxRTPbD/ and https://paste.ubuntu.com/p/NYphZ9yshg/
<ahasenack> rbasak: oh, I had those ready already, but cool :)
<rbasak> Oh
<rbasak> I did file an upstream bug
<ahasenack> in my ppa, I did a test build yesterday
<rbasak> And for apr
<rbasak> (in dep3 also)
<rbasak> How do you want to proceed?
<ahasenack> you go ahead
<ahasenack> just drop the ~dev1
<ahasenack> rbasak: I uploaded a few packages with the mybool patch, but I really would prefer for mysql8 to mgirate first
<rbasak> To be clear, to upload to the archive now, with these latest pastebins, dropping the ~dev1?
<ahasenack> but that will take a while, given the libreoffice tests take hours and hours
<ahasenack> rbasak: yes, let me just check the second one quickly
<ahasenack> rbasak: yeah, +1 to both
<rbasak> Thanks!
<ahasenack> with the !~dev1 drop
<rbasak> Yep
<rbasak> apr uploaded
<rbasak> apr-util will have to wait until apr is built and published, or else it will FTBFS
<ahasenack> yes
<ahasenack> been there, done that :)
<ahasenack> boost is built
 * ahasenack checks if it's published
<ahasenack> looks like it
 * ahasenack rebuilds icinga2
<ahasenack> and that was done already
 * ahasenack watches it
<rbasak> I'll look at zoneminder next shall I?
<xnox> ahasenack:  icinga has now built
<xnox> (there is buildlog, meaning that it is uploading now)
<coreycb> infinity: do you know if 20.10 final release would be oct 15 or oct 22?
<ahasenack> xnox: awesome, thanks again
<knocte> can a maintainer help here? https://bugs.launchpad.net/ubuntu/+source/mono/+bug/1520033 we need to drop an arch (s390x) so that mono can get a hotfix that will make nuget work
<ubottu> Launchpad bug 1520033 in mono (Ubuntu) "ftbfs on s390x" [Undecided,Confirmed]
<knocte> otherwise nuget (the .NET package manager) will crash when running with the mono version shipped by the upcoming LTS
<knocte> I understand that s390x is not a critical arch for ubuntu anyway
<xnox> knocte:  s390x is an official ubuntu architecture with support on-par with ppc64el amd64 arm64
<xnox> knocte:  mono itself is in universe, and not supported as much as other packages in ubuntu are.
<xnox> knocte:  however current mono in ubuntu does not ftbfs.
<xnox> knocte:  so what is your question ? about which package / version and in which release?
<xnox> updated that bug report to be marked as fix released
<knocte> fix released? what?
<xnox> knocte:  Click https://launchpad.net/ubuntu/+source/mono/5.18.0.240+dfsg-3 look at the builds portion of the page: note how it is built correctly on all 6 architectures including s390x
<xnox> is there soemthing wrong with https://launchpad.net/ubuntu/+source/mono/5.18.0.240+dfsg-3/+build/17185141 ?
<xnox> i see there is -5 version in unstable, not yet in ubuntu.
<xnox> bug report and its status was out of date, w.r.t. reality. Do you have any other concerns around mono or nuget in Ubuntu?
<knocte> we need 7ac7d35 in ubuntu, otherwise upcoming LTS will crash with nuget
<knocte> (that git commit I mentioned above is taken from https://code.launchpad.net/~usd-import-team/ubuntu/+source/mono/+git/mono/+ref/ubuntu/eoan-proposed )
<xnox> knocte:  i see
<knocte> (it comes from upstream's "* [d8d5d6b] Fixes __MonoCS__ handling of value types")
<xnox> knocte:  indeed something odd is happening
<Laney> -5 got removed from eoan-proposed because of s390x build failures
<Laney> you can see that on https://launchpad.net/ubuntu/+source/mono/+publishinghistory
<xnox> vorlon:  infinity: looking at https://launchpad.net/ubuntu/+source/mono/+publishinghistory it seems like at archive opening we have dropped -5 upload from eoan-proposed, but did not publish it into focal-proposed
<xnox> i would have expected it to roll over
 * xnox syncs it again
<knocte> well, both mono-packaging maintainers have agreed that the -5 fix is more important than the s390x arch
<xnox> knocte:  sure, i understand the issue now. It seems that we have dropped -4 and -5 uploads of mono on the floor.
<xnox> which is a process / archive administration issue.
<xnox> knocte:  i'm now trying to get up to date mono upload into ubuntu. thank you for raising this.
<knocte> thanks for your help xnox
<xnox> Laney:  actually i guess i need to do a binary copy from eoan-proposed, or a no change rebuild.
<vorlon> xnox: -5 was removed from eoan-proposed manually by infinity as 'FTBFS'
<Laney> if it does fail to build on s390x then you'll have problems @ proposed-migration
<xnox> right
 * xnox uploads a no change rebuild to see what happens
<xnox> we have now raised to z13 which might do better
<doko> coreycb, jamespage: please could you add a lasso merge on openstack's list? needed for python3
<coreycb> doko: yes will do
<doko> ta
<rbasak> ahasenack: here's the fix for zoneminder: https://pastebin.ubuntu.com/p/GcRKP5Yyt5/
<rbasak> I've sent a patch to Debian BTS, just waiting on the bug number
<rbasak> How do you want to integrate it? Is the paste sufficient?
<rbasak> Probably worth testing that in your PPA
<rbasak> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951600
<ubottu> Debian bug 951600 in src:zoneminder ""debian/rules build" fails to call defined build-indep target, causing FTBFS" [Serious,Open]
<ahasenack> rbasak: you rock
<ahasenack> rbasak: the paste is sufficient
<ahasenack> rbasak: I'll upload to my ppa
<rbasak> Thanks!
<rbasak> I do like the interesting fixes :)
<doko> rbasak: sent the python2 removal update
<rbasak> Thank you!
<ahasenack> rbasak: apr has built, will you upload apr-util now?
<rbasak> ahasenack: sure
<rbasak> Sorry I'd forgotten about that
<ahasenack> np, thanks!
<rbasak> Done
<seb128> doko, does the patch on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951101 looks fine? your cracklib2 upload failed to build...
<ubottu> Debian bug 951101 in src:cracklib2 "cracklib2 FTBFS: debian/rules:6: /usr/share/python/python.mk: No such file or directory" [Serious,Open]
<seb128> | debian/rules:6: /usr/share/python/python.mk: No such file or directory
<mwhudson> morning
#ubuntu-devel 2020-02-19
<knocte> xnox: any luck with z13?
<knocte> (my buffer is not long enough so I'm not sure there was any follow-up about this)
<seb128> doko, http://autopkgtest.ubuntu.com/packages/g/gnustep-base/focal/amd64 seems unhappy with the new libxml2 you uploaded because xml-config2 has e.g -llzma but the package doesn't depends on it (unsure how it worked before but the depends was not there either)
<Saviq> juliank: hey, when you have some time, I'd like to retrace my steps and try and see what got broke for me re: MOK last week
<juliank> Saviq: Not sure when I'll have time, also shim in focal seems broken, it can't load fwupd anymore so yeah, lot of brokenness
<LocutusOfBorg> kirkland, hello, what is the reason to have byobu not in sync with debian?
<juliank> Saviq: Were you on focal?
<LocutusOfBorg> the diff is just changelog, I propose to syncpackage it and remove it from MoM page
<Saviq> juliank: yes
<juliank> ok
<Saviq> juliank: mine's not critical, but maybe it will lead to some improvements
<ahasenack> can anybody shed some light on why the maas deb2snap upload triggered a dep8 test of "ikiwiki-hosting"? https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#maas
<ahasenack> I say deb2snap loosely, it's a deb that's obsoleting the deb and installing the snap, just like lxd did
<ackk> FTR, the autopkgtests page shows: ikiwiki-hosting {"triggers": ["maas/1:0.1"], "submit-time": "2020-02-18 20:02:32"}
<juliank> tjaalton: ooh, I just upgraded to that mesa rc in proposed. I think that defaults to iris now? Also I saw a bunch of more kernel crash fixes for i915, I should probably collect them and open a bug with them to get them cherry-picked.
<juliank> Yes I know I'm doing "scary" stuff w/ my system
<juliank> I think there are 4 patches missing in our kernel
<tjaalton> juliank: yeah a final release should arrive this week, wanted to see if the fixes in rc helps openscad
<juliank> But I can't find the gitlab issue anymore
<juliank> drm/i915/execlists: Always force a context reload when rewinding RING_TAIL
<juliank> for https://gitlab.freedesktop.org/drm/intel/issues/1164
<juliank> 76f9764cc3d5 ("drm/i915: Introduce a vma.kref")
<juliank> bbca083de291 ("drm/i915: Serialise i915_active_acquire() with __active_retire()")
<juliank> from https://gitlab.freedesktop.org/drm/intel/issues/1201
<juliank> let's track that in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1863898
<ubottu> Launchpad bug 1863898 in linux (Ubuntu) "More i915 fixes to cherry-pick" [Undecided,New]
<coreycb> jamespage: infinity: fyi current release schedule proposal for openstack victoria (maps to 20.10) https://review.opendev.org/#/c/708471/. they were nice enough to bump it back to 10/14 final release from 10/21. I'm hoping that 20.10 final release will be 10/22.
<ahasenack> ackk: maybe send that question to ubuntu-devel-discuss@ then
<ahasenack> I see the dep8 test is still in some queue
<ahasenack> "in progress"
<ahasenack> that area is one of the "black boxes"
<tjaalton> juliank: can you send them to the list?
<juliank> tjaalton: I haven't looked how well they are cherry-pickable, so I don't have patches to send. I just forwarded my stalking of upstream bugs :)
<juliank> Oh, but at least cloning a kernel should be decently fast on my internet connection these days
<directhex> I can't repro an issue from Focal on Debian Sid. are there anything resembling porterboxes for Ubuntu port fixing?
<tumbleweed> chroots?
<tumbleweed> but no, no porterboxes
<pyusr> hi, there is a major issue in python 2 EOL and ubuntu 16.04, any chance to fix it ?
<cjwatson> You'll probably have more chance of an answer if you say what it is, preferably in the form of a bug report
<pyusr> the quesiton is to open it on pypa or here
<pyusr> i'll gist it, and past eit
<cjwatson> If it's a bug you want fixing in Ubuntu then you'll need to open a bug report on Launchpad about it
<cjwatson> ubuntu-bug <name of package>
<cjwatson> (I don't maintain Ubuntu's Python - this is just a general point-in-the-right-direction comment)
<ahasenack> is there something up with the arm dep8 runners? The queue is huge
<ahasenack> but empty in the other arches
<ahasenack> or are the other arches bad, and arm is the only one running? :)
<pyusr> this is the issue with ubuntu 16.04 and system python-virtualenv: https://github.com/pypa/packaging-problems/issues/325
<teward> mitya57: correct, we can't sync as is (for #1863528)  Hope you don't mind me poking and testing in the few hours of boredom I had here :P
<genii> If I see some "fakesync" version of a package available with apt-cache policy, what does this signify?
<genii> ..for instance https://paste.ubuntu.com/p/4zGkNrcsrx/
<mitya57> teward: sure, thanks for your help with testing it!
<rafaeldtinoco> ahasenack: samba merge +1ed if you want to upload today before eod.
<ahasenack> rafaeldtinoco: thanks!
<rafaeldtinoco> i left a quick note about masked service and systemd helper
<ahasenack> that has been there forever
<ahasenack> it was added to *fix* a bug :)
<teward> mitya57: you're welcome.  I figured testing a sync in a PPA for building was easy :P
<teward> boy was I wrong (had to spin a Focal VM just to get pbuilder/sbuild to work right for local building/testing)
<teward> but glad i could assist :)
<teward> (evidence easy that FTBFS was still present, odd it's only in amd64 though and completely as syntax errors...)
<juliank> genii: someone had to sync the package locally because the tarball in debian was different
<juliank> or other similar stuff
<genii> juliank: Thanks for the explanation
<bryce> is there information at hand about the icu transition, that someone could point me to?  I'm trying to understand how it's blocking dovecot and php7.4.
<LocutusOfBorg> bryce, https://people.canonical.com/~ubuntu-archive/transitions/html/html/auto-icu.html
<LocutusOfBorg> they link icu?
<bryce> LocutusOfBorg, yes, dovecot has an unversioned b-d on libicu-dev
<LocutusOfBorg> bryce, so you have the answer, it will migrate with icu
#ubuntu-devel 2020-02-20
<seb128> juliank, Laney, do you know what's going on with autopkgtests/arm64?
<Laney> can you be more specific?
<seb128> Laney, https://autopkgtest.ubuntu.com/running has a focal/arm64 queue of 465 ... is that normal business, just busy and need time
<seb128> or do we have a capacity problem?
<Laney> both of those things are true at the same time
<seb128> k, let me rephrase
<Laney> it's normal, arm64 is always the slowest arch
<Laney> and more faster hardware would help with that
<seb128> do we just wait or is there a problem that needs to be handled (maybe with #is)?
<Laney> but it looks to be proceeding
<seb128> k, so normal business, we just DoSed the infra by number of uploads?
<seb128> I was wondering if there was a problem,it has been a long time since we had > 1 day for items to get picked so it looked like maybe there was some problem
<seb128> if not all good, I'm just going to wait :)
<Laney> we need moar arms
<Laney> there was a glibc upload and some other big ones
<doko> seb128: cracklib, yes use the python3 path
<seb128> doko, thx
<doko> xml2-config: I tried to restore the original behavior, however Debian's plan is not to ship that at all, that will be the long term solution
<doko> use pkg-config instead
<seb128> doko, right, I saw your follow up upload you just did, sounds it should fix the regression, thx
<doko> rbasak: https://launchpadlibrarian.net/465508087/buildlog_ubuntu-focal-amd64.python-sniffio_1.0.0-1build1_BUILDING.txt.gz could you fix that and maybe update to the new upstream in debian?
<doko> xnox: https://launchpadlibrarian.net/465504895/buildlog_ubuntu-focal-amd64.m2crypto_0.31.0-9build1_BUILDING.txt.gz fails with a SSL error, could you have a look?
<xnox> doko:  it's trying to test that tls1 connection is refused by configuring server without tls1 => that won't work any more, as tls1 is disabled on the client too. It already skips the test in fips mode, and it should skip it forever now. Because just like fips, we don't allow tls1 anymore.
<alkisg> Hi, the latest cups sync from debian in focal broke cups, now e.g. `cupsctl` sprouts HTML instead of just var=value output; and any settings change writes html to /etc/cups/cupsd.conf, completely breaking cups
<alkisg> Would I file a bug in debian for this, or in ubuntu?
<seb128> tkamppeter, ^
<alkisg> Working: 2.3.1-4, broken: 2.3.1-7
<seb128> alkisg, seems worth reporting to Debian in any case
<alkisg> Thank you seb128; I'll stick around in case launchpad is also desired
<seb128> alkisg, thx
<Laney> interesting
<Laney> alkisg: I've got -4 still on two systems and I see that on one of them but not the other
 * alkisg updates his bullseye VM to test/report there...
<alkisg> Laney: hrm
<Laney> https://paste.ubuntu.com/p/YdhZtpRYMk/
<alkisg> Laney: also keep a backup of /etc/cups/cupsd.conf, as e.g. `cupsctl _share_printers=1` will overwrite it with broken html
<Laney> good hint
<cjwatson> etckeeper ftw
<alkisg> Meh, it doesn't happen on debian with 2.3.1-7
<alkisg> It might be an upgrade path, missing or additional packages etc
<tarzeau> is there a way to get https://bugs.launchpad.net/ubuntu/+source/libbinio/+bug/1839038 fixed for 20.04 LTS?
<ubottu> Launchpad bug 1839038 in ocp (Ubuntu) "adplug+libbinio+memory mapped = crash on some files" [Undecided,Confirmed]
<tarzeau> i actually have a fix (for libbinio+ocp) but there's no time left for it happen before freeze
<tkamppeter> seb128, thanks for telling me. Seems that some Debian change has totally broken CUPS, as the upstream versions are the same.
<tarzeau> and does canonical want to have fwupd.org thing in 20.04 LTS?
<tkamppeter> seb128, so a report to Debian would make sense here.
<xnox> tarzeau:  fwupd.org => do you mean fwupdates which are integrated for years now into software-updater and are applied on all UEFI machines for which there are firmware updates already? (e.g. Dell laptops)
<tarzeau> i have no idea of it, i just maintain flashrom (and coreboot)
<tarzeau> but someone maintaining fw* asked me to build libflashrom1 + libflashrom-dev (which i do with flashrom 1.2-2 in new queue debian)
<alkisg> tkamppeter: I would report it to debian, but I can't reproduce it there; it only happens in my focal VM, not in my bullseye VM
<alkisg> The cups-filters package version is different though
<alkisg> Dunno if that would justify the difference
<tkamppeter> alkisg, cups-filters should not influence the output of cupsctl, as cupsctl only shows some common configuration options of the cups daemon, this should not change by the presence of certain filters or cups-browsed.
<tkamppeter> I get the messy cupsctl output with cups-browsed not running.
<alkisg> tkamppeter: then the versions are the same; yet I only see the issue in ubuntu :/
<alkisg> Debian is gnome, Ubuntu is mate, but I don't think that makes a difference either
<tkamppeter> So perhaps there are some environment variables set in Ubuntu which are not set in Debian, and here we perhaps had a change in recent days.
<Laney> tkamppeter: and I have two Ubuntu machines: same cups versions, one with the issue, one without
<alkisg> Laney: similar uptimes? Or maybe the one wasn't rebooted for days/updates?
<Laney> so I suppose something that happened on one of them made the bug appear ... but what?
<Laney> 5 days on the affected machine, 12 the other
<tkamppeter> Laney, and the Ubuntu environments, how do they differ? Different releases?
<Laney> no, they are both focal
<Laney> I mean I'm sure there are differences in what's happened to each of them, but that's figuring out the bug isn't it :-)
<alkisg> Laney: I think it doesn't happen if I `su`... can you verify that?
<tkamppeter> Laney, could you get a full list of the env variables from the terminals out of which cupsctl got started?
<alkisg> I used su - on debian, and just cupsctl on ubuntu
<Laney> alkisg: yes, can confirm that
<Laney> tkamppeter: It happens even when I run "env -i /usr/sbin/cupsctl"
<tkamppeter> So does it mean that from root and normal user only one environment shows the problem?
<Laney> https://paste.ubuntu.com/p/cHTPG8tpSD/
<tkamppeter> For me as root the output is OK and as user it is messy.
<alkisg> In Debian, as the user, /usr/sbin/cupsctl => doesn't produce the issue
<alkisg> So it's not a matter of uid, but of environment variables or something, testing more...
<Laney> messy -> you see the bug?
<tkamppeter> Laney, yes.
<tkamppeter> Independent whether with or without "env -i" as user it is broken and as root (with sudo) it is correct.
<Laney> whoops, I ran cupsctl --debug-logging and it made the daemon exit, and now cupsctl just prints "Bad file descriptor"
<Laney> tkamppeter: right, good, then you see the same as me
<tkamppeter> My user account is in the "lpadmin" group, by the way.
<Laney> ah, I guess doing that corrupted my cupsd.conf
<Laney> and restoring that has made the bug stop happening, so be careful when restarting things
<alkisg> tkamppeter, Laney, setting WebInterface No in cupsd.conf and restarting cups works around the issue
<alkisg> Somehow, the web server is contacted by cupsctl
<tkamppeter> I am looking through the source of cupsctl.
<tkamppeter> cupsctl calls a linbrary function cupsAdminGetServerSettings which returns an aplphabetically sorted list of key-value pairs. Somehow, when runniung as user, there get two garbage pairs, both with grabage as key and empty value into the list.
<tkamppeter> The first one starts with & and therefore gets to the beginning, and the second one starts with a letter and it falls to the end.
<tkamppeter> The five main options start with _ and in the messy case other options which start with a letter do not appear.
<tkamppeter> cupsctl reads cupsd.conf, but not directly as a file as it is only readable for root. It uses a function to poll the config file from the CUPS daemon.
<tkamppeter> That all happens in the cupsAdminGetServerSettings() in cups/adminutil.c of the CUPS library.
<rbasak> doko: thank you for the ping. I'm hoping to catch the trio stack up in Debian before Monday. In personal time - I'm off until then.
<tkamppeter> Following cupsd's opinion, my cupsd.conf lokks like this: https://pastebin.ubuntu.com/p/gpyrnBTrP6/
<xevious> This article mentions environment variables you can set to to tune the kernel build process: https://help.ubuntu.com/community/Kernel/Compile#Build_Method_A:_Build_the_kernel_.28when_source_is_from_git_repository.2C_or_from_apt-get_source.29
<xevious> Is there an environment variable I can set to customize the kernel version string?
<tkamppeter> But if I trust my own eyes, my cupsd.conf looks like this: https://pastebin.ubuntu.com/p/VctGgxP5BP/
<tkamppeter> alkisg, Laney, ^^
<tkamppeter> Laney, alkisg, sorry, CUPS' interpretation of my cupsd.conf is https://pastebin.ubuntu.com/p/nCpSdxntBm/
<tkamppeter> For me it loks like what the web interface displays if you select do modify the server settings.
<tkamppeter> Laney, alkisg, I am already coming closer, on a Focal machine and on a Bionic machine, take a browser and go to http://localhost:631/admin/conf/cupsd.conf When asked for user name enter your user name and password.
<tkamppeter> Bionic shows cupsd.conf as expected, Focal shows the min page for we admin
<tkamppeter> Needs WebInterface=Yes, naturally.
<alkisg> tkamppeter: indeed; yet, on bullseye, it shows the admin interface, but the problem doesn't appear there
<alkisg> Btw on bionic I'm not getting a security warning for the localhost:631 certificate, while I am on focal; dunno if it's at all related
<alkisg> Oh never mind that, my mistake, I had already accepted the certificate on bionic
<doko> OverflowError: timestamp out of range for platform time_t
<doko> is it already 2038?
<Laney> tkamppeter: Don't think I can help much any more since it stopped happening after the file got corrupted
<Laney> unless we figure out how to trigger it again
<Tuxist> pipewire 0.3 released : https://gitlab.freedesktop.org/pipewire/pipewire my ppa build: https://launchpad.net/~jan-koester/+archive/ubuntu/pipewiremaster
<tkamppeter> doko, jbicha, could you update Avahi to the new upstream version 0.8 for Focal?
<doko> tkamppeter: no, please go ahead yourself
<tkamppeter> doko, I cannot upload by myself, I am not core-dev.
<tkamppeter> doko, therefore I am asking.
<doko> tkamppeter: prepare the package in a PPA, and then ask for a sponsor
<doko> coreycb, jamespage: python-vitrageclient probably needs a MIR (pulled in by heat), and vitrage ftbfs in focal
<coreycb> doko: ok thanks I'll take care of those
<tkamppeter> Laney, alkisg, I have found a fix for CUPS. Mike Sweet had messed it up between 2.3.0 and 2.3.1.
<Laney> nice one
<tkamppeter> Laney, alkisg: https://github.com/apple/cups/issues/5744
<tkamppeter> Patch attached.
<alkisg> tkamppeter: thanks, reading...
<kyrofa> Can someone confirm for me that Focal will stick with Python 3.7, not move to 3.8?
<tumbleweed> it's 3.8 only
<kyrofa> Oh wow, I swear I looked a week or two ago, did that change recently?
<kyrofa> Maybe I was looking at eoan
<tumbleweed> 3.8 by default migrated to focal a weeek ago
<sarnold> it was atleast partially announced a month ago or so https://lists.ubuntu.com/archives/ubuntu-devel/2020-January/040882.html
<sarnold> and the transition looks like it's pretty far along, 96% on https://people.canonical.com/~ubuntu-archive/transitions/
<kyrofa> sarnold, does that represent the transition from 3.7 to 3.8 though, or the removal of python<no version>?
<kyrofa> I thought it was the latter
<sarnold> kyrofa: I'm no expert on the syntax at the top of the page but I *think* the 3.8 transition is about dropping dependencies on python 3.7 things
<tumbleweed> yes
<tumbleweed> the previous one was switching defauts
<kyrofa> Ah okay
<kyrofa> Thank you both! Very pleased to see 3.8 come in
<Odd_Bloke> I'm SSH'd into a desktop and I'm trying to build and, crucially, sign a package using a GPG key with a passphrase.  I'm not being prompted in the console for my passphrase, instead seeing a hang (presumably because a graphical prompt is configured).  How can I get GPG to prompt me in the terminal?
<powersj> Odd_Bloke, have you tried ssh -X to pass the X11 forwarding?
<Odd_Bloke> powersj: I have.
<tumbleweed> unset SSH_AUTH_SOCK
<tumbleweed> actually, you probably need to get it to use the console pin entry
<JackFrost> I tend to just unset DISPLAY. :P
<Odd_Bloke> tumbleweed: Thanks!  That hint got me to https://superuser.com/questions/520980/how-to-force-gpg-to-use-console-mode-pinentry-to-prompt-for-passwords which has worked.
#ubuntu-devel 2020-02-21
<ahasenack> doko: hi, are you a debian ftpmaster by any chance?
<doko> ahasenack: no
<ahasenack> k
<ahasenack> LocutusOfBorg: that ocaml/findlib linux-image-generic dep8 error, we need a trigger with the kernel from proposed?
<ahasenack> I did a run with all-proposed=1, same error
<ahasenack>  linux-generic : Depends: linux-image-generic (= 5.4.0.15.18) but 5.4.0.14.17 is to be installed
<mapreri> sarnold: probably one way to express those concerns is to follow up in the debian bug, since that's also the same entity that wrote the profiles in github.  (re: hexchat's apparmor profiles)
<LocutusOfBorg> ahasenack, I didn't check logs yet
<zyga> hello
<zyga> who can I talk about the focal server ISO and snapd seed present there?
<zyga> The context is https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1864113
<ubottu> Launchpad bug 1864113 in snapd (Ubuntu) "snapd.seeded.service never starts" [Undecided,Confirmed]
<zyga> the snapd team believes that the seed on the image is constructed incorrectly
<ahasenack> zyga: rcj?
<zyga> ahasenack: we're chatting in another channel now
<ahasenack> cool
<ahasenack> lamont: hey, hope you are doing fine! Do you remember why neither debian or ubuntu ever built the bind9 dlz modules?
<LocutusOfBorg> ahasenack, seems good now
<LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/c/camlpdf/focal/amd64
<ahasenack> oh?
<LocutusOfBorg> something in the proposed kernel makes it non-installable
<ahasenack> maybe the kernel calmed down
<LocutusOfBorg> actually I don't need --all-proposed
<ahasenack> that's a lot of retriggers that have to happen now
<ahasenack> yeah, just ocaml?
<ahasenack> ocaml and findlib need to be together afaik
<LocutusOfBorg> the uninstallability is picking proposed packages automatically
<LocutusOfBorg> it should auto-heal
<ahasenack> ok, will leave it alone for today
<LocutusOfBorg> I retried without all proposed
<LocutusOfBorg> it should go green for lots of places
<sarnold> mapreri: oh nice, I hadn't noticed that it was the author of the profiles :)
#ubuntu-devel 2020-02-22
<doko> php7.x almost autopkg test clean ...
<doko> autopkgtest for acorn/6.2.1+ds+~0.4.0+~4.0.0+really4.0.0+~1.0.0+~5.0.1+ds+~1.7.0+ds+~0.1.1+~0.3.1+~0.2.0+~0.1.0+~0.3.0+~0.3.0-13 ...
<JackFrost> Yes, the acorn version string is insane.
#ubuntu-devel 2020-02-23
<caylorme> join #godot
<xnox> doko:  thanks for supercollider upload
<xnox> doko:  about zimlib I thought it needs library package rename. But i also wonder if the reverse-deps use symbols from zimlib or not, cause they were already rebuilt against icu65
<xnox> somehow this:
<xnox>  ldd /usr/bin/zimwriterfs | grep icuuc
<xnox> 	libicuuc.so.65 => /usr/lib/x86_64-linux-gnu/libicuuc.so.65 (0x00007f73bf29a000)
<xnox> 	libicuuc.so.63 => /usr/lib/x86_64-linux-gnu/libicuuc.so.63 (0x00007f73be701000)
<xnox> does not crash
<xnox> doko:  but i am confused about your mozjs60 upload
<xnox> -	VERBOSE=1 python2 intl/icu_sources_data.py "$(CURDIR)"
<xnox> +	VERBOSE=1 python intl/icu_sources_data.py "$(CURDIR)"
<doko> fixed, and just uploaded the two zimlib rdeps
<ahasenack> doko: just in case there is some excitement tomorrow before my start of day, https://code.launchpad.net/~ahasenack/ubuntu/+source/bind9/+git/bind9/+merge/379699 is the bind9 9.16.0 merge
