#ubuntu-devel 2005-01-24
<lamont> momentarily
<lamont> given back
<seb128> thanks
* mdz beats dpkg-reconfigure into submission
<seb128> Setting up cupsys (1.1.23-1ubuntu2) ...
<seb128> /var/lib/dpkg/info/cupsys.postinst: line 31: ps: command not found
<seb128> /var/lib/dpkg/info/cupsys.postinst: line 39: ps: command not found
<seb128> chown: cannot access `/usr/bin/lppasswd': No such file or directory
<seb128> lamont: evolution-webcal build :(
<Kamion> mdz: here now
<Kamion> mdz: giving you X_SETBACKTITLE love in cdebconf
<Kamion> although using it is a bit fiddly because you have to call it after the main menu starts up but before localechooser appears *shrug*
<sivang> mdz: just noticed my resync failed when I fire it up (I didn't notice so no download) @ERROR: Unknown module 'daily-live'
<lamont> seb128: there's already a bug in the bts about that
<Kamion> sivang: put cdimage/ before daily-live/
<mako> i think this just changed my life: http://conkeror.mozdev.org/
<lamont> seb128: hrm.. then again, I think that could be my upload...
<Kamion> sivang: rsync is laid out slightly differently because rsync doesn't do virtual hosting, unlike http
<sivang> Kamion,mdz : noted, thanks :)
* sivang downlaoding 
<Kamion> mako: I love the bottom item on their features list
<Kamion> sivang: note rsync isn't all that useful for the live CD yet
<sivang> Kamion: I know, I just use it as means of letting me continue a broken download, should I loose power or net acess.
<sivang> mako: there's a package in universe or something?
<mako> sivang: it's an XPI for mozilla so you can just click a link and install it
<sivang> mako: ah nice
<mako> Kamion: i don't have a mouse either! this guy ROCKS
<mako> it's slightly a mindfuck but i think i'm loving it
<Keybuk> "This means all the keybindings and to-die-for features of Emacs that can be imitated by a javascript/XUL web browser Just Work."
<Keybuk> it does nxml-mode and psychoanalyze-pinhead? :p
<sivang> Keybuk: hehe
<mako> there are 2-3 mouseless mozilla projects
<mako> this one seems great but kind of buggy maybe
<lamont> evening elmo
<elmo> hey
<mdz> Kamion: so I was working on the debconf/cdebconf situation today
<mdz> Kamion: and the cleanest solution I came up with was to modify dpkg-reconfigure to allow it to use an existing frontend
<mdz> Kamion: and then run it in a chroot before pivoting
<mdz> Kamion: does this sound sane to you?
* lamont notes idly that the phrase "does that sound sane" generally indicates a lack of belief on the part of the speaker...
<mdz> Kamion: I tried to get joeyh's opinion, but he didn't seem to be around
<mdz> Kamion: I did a proof of concept using the current live CD, and this method works
<Kamion> mdz: what does the modification look like
<Kamion> ?
<Kamion> mdz: joeyh is around now, he was speaking on #debian-boot just a minute ago
<mdz> Kamion: it basically just conditionalizes a bunch of code in dpkg-reconfigure
<Kamion> IME he doesn't tend to read scrollback much
<Kamion> I mean is it optional?
<mdz> emailed you a copy of the patch
<Kamion> there's some stuff in base-config I think you might need to be careful about not breaking
<mdz> Kamion: it automatically changes behaviour if DEBIAN_HAS_FRONTEND is set
<Kamion> ugh
<Kamion> think I'd prefer it to be explicit, but ...
<Kamion> dunno
<mdz> well, the current behaviour just crashes and burns if there's a frontend running
<mdz> so I didn't see a reason to preserve that
<Kamion> hm
<mdz> but it's simple enough to make a flag for it
<mdz> maisde you a copy of the diff
<mdz> mailed, even
<Kamion> mdz: he said he didn't catch your earlier question
<Kamion> mdz: presumably you have to load the templates into cdebconf, as we discussed?
<mdz> Kamion: yeah, did that
<Kamion> ok
<Kamion> cool
<mdz>     debconf-loadtemplate d-i /target/var/lib/dpkg/info/xserver-xorg.templates
<mdz>     XORGFORCEPROBE=yes chroot /target dpkg-reconfigure xserver-xorg
<mdz> that's it, with the patch
<mdz> Kamion: this could be useful for rescue mode as well
<Kamion> how so?
<mdz> guided repairs
<Kamion> rescue mode tends to assume that any installed system that might exist is arbitrarily broken
<Kamion> hoping that debconf miraculously works in the target is too ambitious, usually
* lamont grumbles at his machine
<mdz> Kamion: it's not the sort of thing I would do unconditionally, but it seems like an interesting idea to be able to have menu items which could talk to debconf in the target to do reconfigure/reinstall type things
<Kamion> yes
<Kamion> though I think it's slightly more useful in the Debian context, to allow debootstrap-installed packages to ask questions at lower priorities
<Nafallo> /sleep
* Kamion -> bed
<lamont> so, -4 is busted, yes?
<lamont> linux-image-2.6.10, that is
<mdz> lamont: yes
<lamont> then I won't upgrade from that snapshot of the archive
<elmo> Mithrandir: ?
<lamont> Setting up mozilla-firefox (1.0-2ubuntu3) ...
<lamont> Updating mozilla-firefox chrome registry...E: Registration process existed with status: 1
<lamont> E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still present. Registration might have gone wrong.
<lamont> mv: cannot stat `/usr/lib/mozilla-firefox/defaults.ini': No such file or directory
<lamont> hrm... that's not right
<lamont> thom???
<lamont> yeah, I know. sleeping
<jdub> hrm, i didn't get that on my upgrade
<lamont> jdub: it could be that rebuilding the chroot might help
<lamont> things have been installed/removed over and over and over and over in that chroot
* lamont heads off to class
<lamont> jdub: you have a current gnome install?
<lamont> panel -> properties -> autohide... does it?
<lamont> (doesn't here, but not 100% current...)
* lamont really heads to class. back in 3.5-4 hours.
<daniels> mdz: ...
<daniels> lamont: gnome-session -> libxau-dev
* sivang burns the live iso
<sivang> nice to see that nautilus showing the content of the RW cd doesn't block the burner from working.
<mdz> daniels: how is the X configuration stuff coming?
<daniels> mdz: good thanks, it seems to be pretty solid at the moment; the bandwidth is a bit flogged, so live CD hasn't come through yet, but I think this X upload is pretty much ready to go, and I've also dealt with two merges (one of them being glibc)
<daniels> mdz: if I gave you new debs, would that be useful?
<daniels> brr
<mdz> daniels: yes
<mdz> well
<mdz> me, or the archive?
<mdz> me -> no, archive -> yes
<daniels> mdz: k
<mdz> daniels: how does it stand?
<mdz> did you implement the bit to ignore the previous values if a probe is forced?
<daniels> mdz: yeah
<daniels> XORG_FORCE_PROBE now throws away everything it's got earlier and does a reprobe
<daniels> note the change in variable name
<daniels> as well as fairly large backports of i8xx and via drivers, disabling horizontal scrolling per default, fixing the altgr-on-macs bug, dpkg-architecture, fixing the original-imacs-won't-show-anything bug, a couple of xkb stuff, this change, and a semi-related script cleanup
<lifeless> rock
<mdz> Kamion: around? could use some cdebconf enlightenment
<mjg59> daniels: Thom sees the same problem with suspend/resume after playing with vbetool
<mjg59> Have you got nifty keen DRI save/restore functionality yet?
<daniels> mjg59: wack; not yet, no
<daniels> mjg59: i'm dragging back mesa 6.2 for my next xorg revision
<lifeless> mdz: we should sync tla 1.3 if we haven't already
<lifeless> is amaya supported or unsupported ?
<lifeless> Cause its fucked, and does anyone care ?
<daniels> use apt-cache show to see whether it's in main or universe
<lifeless> ah universe
<lifeless> ok, so does anyone care;)
<daniels> if you want to fix it ...
<daniels> holy shit, 60.5%
<daniels> the rsync may actually finish this week
<lifeless> :)
<mdz> lifeless: patches gratefully received
<lifeless> mdz: for amaya or tla 1.3? 
<mdz> lifeless: amaya
<lifeless> I may have a peek if I get some time.
<mdz> tla 1.3, we're in freeze now
<lifeless> mdz: it was released before christmas, but asuffield sucked.
<lifeless> mdz: its quite important to have tla 1.3, because its got the same revlib format as baz, which tla 1.2 doesn't.
<lifeless> mdz: the muppet who did the patch originally didn't do it backwards compatibly.
<mdz> Exceptions requiring confirmation:
<mdz>     *      Packages in or relating to FeatureGoals?
<mdz>     *      Minor fixes, if the upstream change is a micro-increment (or equivalent)
<mdz>     *      Major fixes, particularly blockers, if the upstream change is a minor-increment (or equivalent)
<mdz>     *      Exceptional circumstances
* lifeless claims exceptional circumstances for tla 1.3 and baz 1.1
<mdz> baz 1.1 is an internal project, so I think it deserves it
<mdz> but why should we track tla releases through the freeze?
<mdz> it sounds like they're actively doing feature development
<lifeless> because having tla 1.2 there will make it harder for users to use baz.
<lifeless> we don't need to go for tla 1.4, only 1.3
<Keybuk> bazaar 1.1 didn't make the upstream freeze either, did it?
<lifeless> no, but that was pre-discussed
<stub> Thanks to vbetool, I've now got this Dell8600 laptop suspending to RAM, except that when it wakes the external USB mouse is no longer working. Can someone point me to a tool that might let me reset that stuff?
<lifeless> stub: try unloaded and reloaing the usb)uhci or whatever driver
<fabbione> morning
<lamont> morning fabbione 
<fabbione> hey lamont 
* lamont cries
<lamont> I fear my mirror will never catch up
<fabbione> what's up?
<fabbione> ahhaha
<fabbione> i still have to upload -6
<fabbione> ain't my fault...
<fabbione> not this time at least
<lamont> nah -evo data server and mozilla-* are .
<lamont> but before they get there, you will be
<lamont> mdz: wvstreams uploaded.
* lamont plays with a new keyboard.
<fabbione> lamont: f11 still has I/O problems
<fabbione> i did try to make some working configs but it takes just too much time... sorry
<lamont> np.  does -6 have where you're at then?
<fabbione> lamont: -6 has -pa10 but not valid configs
<lamont> ok.
<lamont> I'll work with it over the weekend or something
<jdub> fabbione: do you want latest inotify patches?
<lamont> right now is sleep time, thouhg
<fabbione> lamont: so basically what you have to do manually is to dpkg-buildpackage and while it steps in the configs try to answer in the appropriate way until it builds ;)
<jdub> fabbione: http://lwn.net/Articles/118107/
<lamont> fabbione: and capture the config.
<jdub> fabbione: just checking to see if that's the very latest
<fabbione> lamont: than copy them from debian/build/build-$flavour/.config to debian/config/hppa/$flavour
<fabbione> lamont: and send them to me
<fabbione> jdub: hold on...
<fabbione> jdub: it'a all documented in the source btw.. you can check yourself...
<lamont> fabbione: ok.  g'night then
<fabbione> debian/external-drivers
<fabbione> lamont: g'night
<jdub> fabbione: our kernel source won't tell us if you've used the latest patch aailable :)
<fabbione> jdub: yes it does
<jdub> fabbione: it can't, you need extra information, ie. what the latest inotify patch is :-)
<fabbione> jdub: apt-get source linux-source-2.6.10 and read debian/external-drivers
<fabbione> jdub: that one will tell you what version is in
<fabbione> and you can compare with what is available
<jdub> fabbione: yes, that will tell me the version in the kernel, not which versions are available
<jdub> meanwhile, i'm not downloading the kernel source
<fabbione> jdub: you are just lazy and i am still waiting info on your DVB bug report
<jdub> fabbione: bandwidth issues
<jdub> i have to get the card back to find out
<jdub> fabbione: which version of inotify is in our kernel?
<jdub> i'm checking what the latest 'stable' version is atm
<fabbione> inotify            | 0.17-wip-rml-2.6.10-rc2-12 | ok     | 15/12/2004   | http://www.kernel.org/pub/linux/kernel/people/rml/inotify/v2.6/
<jdub> ok
<jdub> http://www.kernel.org/pub/linux/kernel/people/rml/inotify/v2.6/0.18/inotify-0.18-rml-2.6.10-4.patch
<jdub> so that's a start
<fabbione> jdub: i have other things to deal with right now.. like a few tons of security patches
<fabbione> also we are in UVF
<fabbione> that's a new upstream version
<jdub> as yet, we have no policy about kernel patch relationship with UVF
<jdub> i will file a bug for you
<fabbione> dude..
<fabbione> read the changelog
<fabbione> The primary change since the last post is a reworking of the locking and
<fabbione> refcounting.  A bit more such reworking is expected.
<fabbione> meanign that the new version is not completed
<jdub> i know
<mdz> is inotify fucked?
<fabbione> mdz: no. jdub is asking for a new upstream version of it
<mdz> but I have heard talk about it being buggy
<jdub> mdz: you'll get bug cc in a moment
<jdub> mdz: i believe that's mostly gamin's support of inotify, which i am considering disabling
<fabbione> and so what is the point of having inotify if there are only 2 thing that actually uses it?
<jdub> fabbione: because everything in gnome uses gamin (via the fam abi)
<jdub> fabbione: so if you're using inotify for monitoring, you don't block disks from unmounting and so on
<jdub> which is preferable to dnotify
<fabbione> <jdub> mdz: i believe that's mostly gamin's support of inotify, which i am
<fabbione>           considering disabling
<fabbione> than i miss something
<fabbione> you need inotify for gamin
<mdz> is gamin not going to be fixed for hoary?
<fabbione> and you want to disable inotify support for gamin
<mdz> jdub: bah, LWN went and published that hack-of-the-day live CD rather than the subsequent (much nicer) daily builds
<mdz> I deliberately sent that to -devel and not to -announce because it wasn't ready for that kind of publicity
<jdub> fabbione: gamin supports inotify as well as dnotify, but its support for inotify is not great
<jdub> it seems
<jdub> mdz: not sure if gamin/inotify will be fixed, thus considering disabling the inotify support
<jdub> mdz: i will track it beyond UVF to see if there are related bugfixes
<mdz> jdub: have you tried the latest round of hoary live CDs?
<jdub> no, haven't committed to downloading them yet ;)
<mdz> 3 architectures, fewer calories, better tasting
<jdub> dc-built?
<mdz> daily
<mdz> fresh and hot
<jdub> cool
<jdub> i'll pull one down during off-peak tonight
<mdz> no X yet, but daniels is working on it AHEM
<jdub> i've been watching the casper changes with interest :)
<jdub> it's such a good idea
<mdz> I must admit, it is
<jdub> :)
<mdz> casper is like 100 lines of shell on top of one fucking good idea
<jdub> proven by beauty? :)
<daniels> mdz: how do I mount the cloop image from the live CD?
<daniels> mdz: or otherwise test X
<mdz> daniels: boot it?
<daniels> mdz: lwn love us to omuch
<daniels> mdz: and, heh, yeah, they do love us
* daniels stares at mdz.
<mdz> modprobe cloop && losetup /dev/cloop0 /path/to/filesystem.cloop && mount /dev/cloop0 /mnt
<daniels> mdz: can I netboot the live CD?
<mdz> daniels: dude, yes you can ;-)
<jdub> tftp get filesystem.cloop
<jdub> ...
<jdub> ;-)
<mdz> jdub: d-i netinst + NFS mount
<daniels> heh, nice
<daniels> my laptop sort of lacks a cd-rom
<daniels> ls
<mdz> it should work with zero or few changes
<mdz> daniels: no docking station or USB?
<jdub> mdz: yum (such a good idea)
<daniels> mdz: i have usb
<daniels> but no docking station yet
<daniels> agh, hm
<mdz> daniels: I use a USB drive for this stuff pretty much exclusively; it's great
<jdub> surely you could copy the cloop to your hard drive?
<mdz> ran me about USD 100 for DVD+/-/RW/RAM and USB enclosure
<mdz> daniels: I don't really see how the cloop image is necessary for testing, tbh
<mdz> but you can chroot into it easily enough
<daniels> mdz: yeah, I should probably grab one
<daniels> mdz: well, failing being able to boot the thing ... but yeah, I'll see if I can't go grab one
<mdz> daniels: you can also boot it in qemu
<mdz> sluggish, but works
<mdz> qemu -cdrom hoary-i386-live.iso
<jdub> i should try the powerpc one under pearpc :)
<mdz> er
<jdub> s/^i/someone with more bandwidth/
<mdz> someone just renamed the UserPages page in the wiki to their personal page
<jdub> haha
<mdz> ??changed:
<mdz> -{{{This is a list of all userpages}}}
<mdz> -
<mdz> Una bienvenida desde el Peru
<mdz> yay wiki
<jdub> that's it, i'm switching to the other theme
<jdub> my login is never remembered :|
<mdz> you can login??
<jdub> with https, yeah
<jdub> oh, the zwiki theme doesn't have a recent changes link
<jdub> boh
<jdub> oh man
<jdub> someone sent a 16K please unsubscribe me repluy
<mdz> yeah
<mdz> imminent death of usenet predicted
* jdub replies off-list
* mdz changes the live CD to _not_ change the hardware clock
<fabbione> mdz: 5472.. do you want to comment on it? it can still make it for -6 but i want to know before (possibly) breaking the ABI again
<mdz> if it will fix some of the problems with inotify, great
<mdz> if not, I'm not sure it's worthwhile
<fabbione> jdub: ?
<daniels> mdz: hm
<jdub> leave it for now
<daniels> mdz: is there an easy way to transfer files from the host OS to the live CD?
<jdub> rml's next release will be more useful it seems, and it won't fix the gamin/inotify stuff
<mdz> daniels: yeah, boot it :-P
<daniels> heh
<daniels> not that I have a working CD burner right now, anyway
<fabbione> jdub: ok
<mdz> daniels: that's a problem
<fabbione> mdz: what was the rationale to use the e100 driver in place of the eepro100 ?
<fabbione> if there is any...
<daniels> mdz: yeah, I have two dual-layer DVD burners on order
<daniels> mdz: i'll be in much better shape when my shiny amd64 turns up
<daniels> right now, all I have is the motherboard
<mdz> fabbione: herbert said eepro100 was deprecated
<mdz> iirc
<fabbione> ah
<mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=2156
<mdz> for reference
<fabbione> because both Debian and us are having problems with the e100 but not with the eepro100
<mdz> maybe ask dilinger or someone, get a second opinion
<fabbione> T-Bone is alive ;)
<fabbione> we already discussed it
<mdz> fabbione: I meant ask about e100 vs. eepro100
<mdz> daniels: I bought my single-layer *just* before the dual-layers came out for the same price
<mdz> it can apparently read (but not write) them with a firmware update
<daniels> mdz: i bought my x40 about 5 days before they brought out faster models and dropped all the prices
<fabbione> mdz: yeps... that's what we discussed about
<daniels> mdz: whoohoo!
<abelli> smurfix: ping
<abelli> hi everybody
<jdub> hi abelli 
<jdub> was it you asking for the it-devel list?
<abelli> jdub: yes
<abelli> jdub: but its ok now...
<sid77> hi
<jdub> abelli: i spoke to mako about it; it would be more appropriate to keep all devel discussion on one list
<jdub> abelli: and country-team oriented stuff on one list (ubuntu-it)
<abelli> jdub: i agree with that, but since we are dealing with some teachers [for projects about Ubuntu in the Italian School System] , and 
<abelli> many of them do not speak english, i needed an italian mailing list.
<jdub> sounds like a good project for ubuntu-it
<abelli> so now we have ubuntu-it@lists.ubuntu.com, EXCLUSIVELY for SUPPORT
<abelli> and sviluppo@ubuntuitalia.org for administrating our projects
<abelli> jdub: you can find some of them here... http://www.ubuntulinux.org/wiki/AndreaAbelli
<daniels> mdz: I AM THE SHIZZLE
<Treenaks> Word!
* Treenaks pokes SuSE into accepting his jhbuild-built gnome CVS HEAD goodness
<daniels> mdz: ok, I have something that works and generates an entirely new configuration with XORG_FORCE_PROBE=yes dpkg-reconfigure -phigh xserver-xorg
<mdz> daniels: awesome, upload it in time for me to use it for live CD testing tomorrow?
<abelli> i was actually looking for smurfix: during the CC he said he had told us to get to the meeting... but i can't remember/find his advices /in the logs .. and i dont want to appear a deserter
<daniels> mdz: fo'sho
<daniels> mdz: number of hours I have to upload?
<daniels> mdz: i'd like to do the usual laps-of-the-data-centre thing with test builds on every architecture
<abelli> jdub: what about ubuntu-it's rootly powers? i receive a cc: by mako about this.
<fabbione> daniels: does the change require to ship new files?
<jdub> abelli: that was waiting on appointment of loco team leaders
<jdub> abelli: has that happened?
<daniels> fabbione: i don't think we've touched the manifests ... but I did fix an ia64 FTBFS that lamont didn't notice :)
<jdub> CC meeting is too late for me to sanely get to
<fabbione> daniels: ehe ok
<mdz> daniels: I'll be awake again at about 1800 UTC probably
<daniels> fabbione: even so, there are some fairly significant code changes (i8xx from HEAD to get rid of all the horrid widescreen panel video BIOS changes, via from unichrome.sf.net), so I'd feel a lot safer :)
<daniels> mdz: when does the daily build run?
<mdz> daniels: now
<mdz> (0800 I think)
<mdz> I can run a build by hand in the morning, though, if X is ready
<fabbione> daniels: last time we checked the unichrome was utterly broken...
<fabbione> daniels: did they fix stuff around?
<daniels> fabbione: yeah, and it should finally run on the craptop
<daniels> mdz: ok, so let's assume 'now' is a missed target ...
<daniels> mdz: i'll upload after my test builds are done
<fabbione> daniels: last time Treenaks was complaining about tvout being broken
<daniels> mdz: say ... upload by 1000 UTC?
<abelli> jdub: sorry it was batty time...yes
<mdz> daniels: don't they take 4 hours to build or something?
<daniels> fabbione: hm.  well, the unichrome guys claim it will give us basic 2D functionality on everything they know of, so that's a huge win over what we have already.
<mdz> I want to get X working in the live CD by end of day tomorrow if possible
<daniels> mdz: 32min on amd64, 74min on powerpc, ~90 on i386.
<Treenaks> fabbione: that was a long time ago
<Treenaks> fabbione: if you have sid-installable xorg packages I can try again..
<daniels> mdz: so our worst case has it being in the archive by about 1400
<daniels> mdz: at which time you're still asleep
<daniels> brb
<mdz> that's fine
<mdz> daniels: I thought you meant the 1000 UTC after that one
<Treenaks> fabbione: people have been tweaking tvout on unichrome.sf.net afaik
<mdz> you and your international date line
<daniels> mdz: nope, the 1000 UTC in ~2h
<daniels> mdz: er, it's 0800 UTC now
<daniels> i'm not talking about my timezone
<daniels> anyway, back in a bit
<jdub> mdz: http://www.novell.com/documentation/suse91/suselinux-adminguide/html/apas02.html
<jdub> mdz: published by novell (haw haw)
<mdz> jdub: let me guess: they like reiser
<jdub> nup
<jdub> it's very balanced (ie. ext3 naturally comes out as safest)
<mdz> hmm
<mdz> it doesn't talk about weaknesses of any of them
<jdub> yeah
<jdub> probably don't want to get sued
<jdub> ;-)
<Treenaks> jdub: by Hans Reiser? 
<mdz> it's sort of a puff piece
<jdub> by anyone
<amu> moin moin   
<jdub> hey amu
<amu> huhu jdub 
<jdub> haggai: ping
<jdub> probably too early
<elmo> Mithrandir: ?
<jdub> elmo: do we have sync-from-debian mails to changes?
* fabbione gives a true spin to concordia
<pitti> Morning everybody
<fabbione> hey pitti
<elmo> jdub: no, sorry kernel security holes and nagios have fucked over my time tables
<fabbione> elmo: AND MORE TO COME ;)
<jdub> elmo: ok
<daniels> fabbione: asdfl;jasl;kje34l;'52342q34
<fabbione> top - 08:36:45 up 4 days, 19:50,  2 users,  load average: 71.08, 27.54, 10.85
<fabbione> and still highly responsive
<fabbione> not too bad
<fabbione> 88
<fabbione> 92
<fabbione> 97
<fabbione> impressive what you can do setting an evn var ;)
<fabbione> env even
<fabbione> 103
<fabbione> elmo: concordia is keeping up ;)
<fabbione> 105
<fabbione> YEAH CLIMB! 108
<Kamion> mdz: morning. still need cdebconf help?
<daniels> fabbione: what are you doing to it?
<fabbione> Kamion: i think he falled asleep on his chair
<fabbione> daniels: compiling the kernel
<daniels> insanity
<fabbione> nahh
* daniels wanders off for a bit while X builds.
<fabbione> just export CONCURRENCY_LEVEL=100
<jdub> Kamion: when's that OQO turning up at your place? :)
<pitti> Hi carlos!
<carlos> pitti: hi
<mdz> Kamion: no, got that bit going actually
<mdz> Kamion: I have a patch which implements DATA
<mdz> but then I discovered that the protocol that passthrough actually speaks is not in fact "standard debconf + DATA", but something weird and incompatible
<mdz> but joeyh says it's OK to break it to make it consistent and compatible
<mdz> Kamion: I'll mail you my cdebconf patch, would appreciate the eyeballs
<Kamion> ok, thanks, catching up on the morning's spam^Wmail currently
<fabbione> pitti there is an updated patch for CAN-2004-1235 (2.6) that has been committed yesterday to bk
<pitti> fabbione: any critical changes?
<pitti> fabbione: Herbert still did not upload the Warty kernel, so maybe you can send him the patch?
<fabbione> it is a merge between the Marcello and Linus one
<pitti> fabbione: I thought these two patches fix the same thing in a completely different way?
<pitti> how can they be merged?
<fabbione> apparently no
<fabbione> pitti: ask Linus and Marcello
<fabbione> i really have no idea
<pitti> fabbione: okay, thanks. Can you forward it to Herbert?
<davyd> good morning Gentlemen (and any ladies)
<pitti> Hi davyd 
<davyd> what is the Ubuntu XInputManager of choice? SCIM?
<fabbione> pitti: sure.. in a sec
<davyd> or has there been no focus on input managers?
<Kamion> I'm not convinced we have an input method of choice
<davyd> Kamion: also possible
<Kamion> there's been some talk about them, mako's as close to a local expert as we have
<davyd> It's certainly not something that appears to be shipping by default
<davyd> I mean, in my opinion, it should integrate with gswitchit anyway
<davyd> since you already use that to select keyboard layouts
<davyd> but that sounds hard
<mdz> night all
<ogra> night
<Treenaks> morning ogra :)
<Treenaks> mdz: night :)
<ogra> morning :)
<pitti> Night mdz
<pitti> Hi ogra
<ogra> ogra@honk:~ $ uname -a
<ogra> Linux honk 2.6.8.1-4-amd64-k8 #1 Sat Jan 8 19:34:42 UTC 2005 x86_64 GNU/Linux
<fabbione> night mdz
<ogra> i'm about to join Mithrandirs realm :)
<Treenaks> ogra: "Linux linux 2.6.5-7.111.19-default #1 Fri Dec 10 15:10:58 UTC 2004 i686 i686 i386 GNU/Linux" here :(
<ogra> 2.6.5 ???
<ogra> why that ?
<Treenaks> suse default kernel
* ogra shivers
<ogra> suse
<ogra> brr
* Treenaks points at his boss
<ogra> heh
<Mithrandir> elmo: pong
<fabbione> elmo: uploading the new kernel for hoary now.. it will need some NEW love for the binaries
<davyd> fabbione: did you end up merging the orinoco 0.15 drivers?
<davyd> http://www.nongnu.org/orinoco/
<haggai> jdub: pong!
<elmo> Mithrandir: dude, your blog disappeared
<Mithrandir> it disappeared?
<fabbione> davyd: no.
<Mithrandir> weird, I'll check it out
<davyd> fabbione: ok, just letting you know about them then ;)
<fabbione> davyd: since it is an upstream driver, when it will be merged, it will be updated
<davyd> since they fix up things, like scanning for APs
<jdub> haggai: hey hey
<jdub> haggai: what's up with OOo 2.0 atm?
<davyd> allowing you use `iwlist scan` and netapplet
<jdub> haggai: also, were you at akademy?
<fabbione> we can't track all possible external drivers by ourself
<davyd> fabbione: I fully respect that
<fabbione> it's just a question of resources
<Mithrandir> elmo: dying hard drive. :/
<davyd> the only reason I was letting you know about these ones, is that there are a lot of people with orinoco cards, and people are talking about things like netapplet
<fabbione> if you can give me the patches and test them before and keep taking care of it, i will not mind adding it
<davyd> so it would lessen that sort of pain
<fabbione> and also.. we are in "upstream version freeze"
<fabbione> that means no new upstream versions if not for very specific reasons
<davyd> fabbione: hmm... ok
<davyd> I mean, it doesn't personally bother me
<jdub> fabbione: although we haven't determined that UVF strictly applies to kernel patches yet :)
<davyd> it just might be useful in general
<davyd> unfortunately I don't really have the time to maintain a kernel patch at the moment :(
<davyd> plus, as it's been proven in the last, I'm not very good at it
<fabbione> jdub: kernel is not different in that respect...
<fabbione> jdub: otherwise i could bring 2.6.10 to 2.6.11-rcX via patches ;)
<fabbione> davyd: i understand.. we will see what to do at the proper time
<davyd> fabbione: sure
* fabbione tries to update his workstation
<fabbione> brb
<haggai> jdub: it's packaged.  It's running on Debian but Ubuntu's evo is causing problems atm, and the menu icons aren't there yet
* haggai is hoping for an upload today
<Kamion> hm, I wonder if today's daily ISO is releasable
<pitti> Kamion: does it fix the apt authentication?
<Kamion> "fix"?
<pitti> Kamion: the last daily I tried did not install any packages, I had to force this
<Kamion> still haven't seen it be broken, but I haven't gone that far with an install CD in a while ...
<pitti> Kamion: I found myself in a minimal system on a command line prompt
<Kamion> understood, but I'll have to see it before knowing what's wrong I think
<haggai> jdub: oh, no I wasn't at akademy
<jdub> haggai: aha (re OOo), excellent :)
<pitti> Kamion: it's not a problem for me, but it should work on array cds which are tested by less experienced users...
<jdub> haggai: package names have 2.0 in them or whatever?
<Kamion> pitti: it's obviously a bug if that's happening, I don't need to be persuaded of that
<haggai> jdub: yes, 1.9 since that's how upstream is doing the versioning
<Kamion> ah, the OQO's coming tomorrow, they tried to deliver yesterday but I was away/dead/something
<jdub> haggai: hrm, then we have to futz around with package names changing :)
<jdub> Kamion: cool :-)
<jdub> Kamion: let me know how it goes, i want to pimp success all over the place when it happens :)
<haggai> jdub: what would you say is better?  2.0 or openoffice.org?
<jdub> haggai: how do you mean?
<haggai> jdub: I didn't understand what you mean about futzing around
<Kamion> jdub: like I said to silbs, I expect to pass it over to daniels fairly soon for X love :)
<jdub> rawk
<haggai> jdub: are you saying 1.9 is reasonable and everyone has to futz or you think we should use somthing else?
<jdub> haggai: hrm, i should give you more context because it is all in my brain
<jdub> haggai: first question meant "will the version number be in the actual package name when you upload it?"
<jdub> haggai: you mentioned 1.9, which i don't think is worth putting in the package name
<jdub> but you may have been answering my question differently to how i was asking it (based on lack of context)
<haggai> ok, well if it isn't going to replace 1.1 (which I don't think it should quite yet), it needs another name, right?
<jdub> as an example, i think it would make sense to have openoffice.org2.0 version 1.9
<haggai> ok, right I did understand you then
<jdub> or something like that
<jdub> oh, ok
<jdub> good
<jdub> PAGE FOUND
<haggai> ROCK :)
<jdub> ALL DEVELOPERS PLEASE CONGREGATE ON THE SAME PAGE
<haggai> er I'd have a problem fitting all your thoughts on such a small page..
* haggai starts looking for page compression algorithms just in case
<jdub> it definitely wouldn't be RTL, if the mess in my brain atm is anything to go by
<pitti> thom: here?
<thom> pitti: wordup
<haggai> maybe openoffice2 instead of openoffice2.0?
<pitti> thom: in php4 4:4.3.9-1ubuntu1 you removed caudium-php4 and php4-imap
<jdub> yeah, that's nicer
<thom> pitti: indeed
<pitti> thom: what was the reason for this?
<daniels> haggai: really?  i could do it in one word
<thom> pitti: mdz told me to
<haggai> daniels: now now :)
<thom> pitti: basically, we don't want c-client or caudium in main
<daniels> pitti: er, because we don't support caudium or the uw abomination; presumably that would involve dragging those two into main
<daniels> haggai: 'pants'
<haggai> lol
<pitti> thom: I want to merge the Debian pacakge from scratch since the current merge is too dirty
<jdub> daniels: so this is weird
<jdub> i'm weirding holden special vehicles boxer shorts
<jdub> um
<pitti> daniels, thom: makes sense, thansk
<pitti> thanks, even
<jdub> s/weirding/wearing/
<haggai> jdub: nah, weirding was better
<thom> jdub: TMI
<daniels> jdub: are you still in yass?
<jdub> no way dude
<jdub> then i'd be nice and cool
<jdub> pipka's dad is a refrigeration engineer :)
<tuo2> jdub: sydney heat sucks
<jdub> (air conditioners are refrigerators)
<jdub> fridge
<jdub> bong
<daniels> so, where did you happen upon hsv boxer shorts?
<daniels> it seems like your inner redferner is busting out :)
<Treenaks> redferner?
<daniels> Treenaks: jdub lives in a rather, er, down-at-heel suburb
<daniels> (except he doesn't, really)
<Treenaks> daniels: ah, he only grew up there :)
<fabbione> daniels: 2.6.10-6 is up. you will need to update l-r-m
<daniels> fabbione: blah, we're at .10-2 now?
<fabbione> no idea... -3 i think
<Kamion> -2
<daniels> ok, thanks for the warning
<fabbione> Kamion: same goes for d-i :(
<daniels> this is going to be a pain :\
* daniels kicks ATI.
<fabbione> daniels: i need to wait for you to update linux-meta
<Kamion> fabbione: yeah, noted
<Kamion> let's try and get this out of the way today if possible so that we can keep CDs working
<fabbione> Kamion: i hope so too
<fabbione> Kamion: i am afraid this is going to be a pain
<fabbione> amd64 failed::
<fabbione> Errors were encountered while processing:
<fabbione>  cupsys
<fabbione> E: Sub-process /usr/bin/dpkg returned an error code (1)
<fabbione> apt-get failed.
<fabbione> Package installation failed
<fabbione> I SWEAR IT'S NOT MY FAULT!
<pitti> fabbione: what failed with cupsys?
<fabbione> thom: you around?
<fabbione> pitti: http://people.ubuntulinux.org/~lamont/buildLogs/l/linux-source-2.6.10/2.6.10-6/
<fabbione> etting up cupsys (1.1.23-1ubuntu2) ...
<fabbione>  /var/lib/dpkg/info/cupsys.postinst: line 31: ps: command not found
<fabbione>  chown: cannot access `/usr/bin/lppasswd': No such file or directory
<pitti> fabbione: why the kernel needs cupsys?
<pitti> hmm
<fabbione> it gets pulled in by some indirect build-deps.. 
<thom> fabbione: yes
<pitti> fabbione: I fixed the lppasswd error yesterday
<pitti> fabbione: in 1.1.23-1ubuntu2
<pitti> fabbione: however, the ps eror is new (and not Ubuntu specific)
<fabbione> thom: sorry.. 2 questions on the fly.. i need to bootstrap mono on sparc.. lamont told me that you had some kind of way to do that...
<fabbione> thom: and if you have any plan to update eingmail for thunderbird 1.0
<thom> fabbione: thunderbird is Mithrandir territory now
<pitti> fabbione: hmm, ps is shipped in procps, which is required
<pitti> fabbione: ... but not essential
<fabbione> thom: oh true.. sorry
<fabbione> Mithrandir: ?
<fabbione> pitti: buildd chroots are minimal
<thom> fabbione: http://pkg-mono.alioth.debian.org/BUILD_MONO_FROM_SCRATCH_HOWTO is basicallywhat you need
<fabbione> thom: ok
<fabbione> thanks
<pitti> fabbione: I will upload a fixed cupsys ASAP
<fabbione> pitti: thanks
<thom> it's not too fun
<fabbione> given that is portable to arch foo
<daniels> fabbione: lrm uploaded
<Mithrandir> fabbione: yes?
<fabbione> daniels: did you remember to bump the kernel ABI?
<fabbione> Mithrandir: do you have any plan to update enigmail for thunderbird 1.0?
<elmo> lol, Mithrandir dcut won't work
<Mithrandir> fabbione: yes, but I have a hard drive dying which I need to tend to first.
<Mithrandir> elmo: it should! :P
<elmo> yeah, I know
<fabbione> Mithrandir: sure.. no rush.. i was just curious
<daniels> fabbione: yep
<daniels> fabbione: including for d-i
<pitti> fabbione: cupsys_1.1.23-1ubuntu3 is uploaded and fixes both issues
<Kamion> fixed d-i prepared, waiting for binaries to test against
<fabbione> daniels: cool
<fabbione> pitti: thanks
<fabbione> Kamion: that might take a couple of hours at least
<Kamion> understood
<fabbione> ppc and amd64 are fail
<Kamion> hm?
<fabbione> waiting for the i386 and ia64 :)
<fabbione> Kamion: cupsys is broken
<Kamion> dude, don't do this to me :(
<Kamion> ah
<fabbione> and it fails to install in the chroot
<fabbione> <fabbione> I SWEAR IT'S NOT MY FAULT!
<Kamion> go cupsys
<fabbione> Kamion: i am sure 100% that i386/ppc/amd64 can build
<fabbione> i did test them on the porting boxes
<pitti> cupsys_1.1.23-1ubuntu3_source.changes ACCEPTED
<pitti> Kamion: ^ this should make it work again :-)
<Kamion> elmo: planning to upload this debian-installer with raw-installer rather than byhand; that still ok?
<Kamion> and will it delay it for $LONGTIME?
<pitti> mvo_: I just tried update-notifier again
<pitti> mvo_: it still fails
<pitti> mvo_: I start it, the symbol appears, I click on it, enter my password
<mvo_> pitti: right click on it and see what options are available
<pitti> mvo_: then I get the console string "sudo: /usr/bin/usudo:
<pitti> "
<mvo_> /usr/bin/usudo?
<pitti> mvo_: and an errir dialog saying that "Failed to run /usr/bin/update-manager as user root:
<pitti>  Unterprozess endete mit dem Status 215"
<pitti> mvo_: I think the "/usr/bin/update-manager" string gets overwritten by another message
<pitti> mvo_: what it is _supposed_ to do when I click on it?
<mvo_> pitti: can you start "/usr/bin/update-manager" by hand
<pitti> mvo_: run apt-get dist-upgrade in the background?
<pitti> mvo_: I did start it by hand in a foreground console
<mvo_> pitti: no, just start a application that shows you what updates are available (or start the package-manager)
<davyd> hmm, libebook transitions again...
<mvo_> pitti: what happens if you run "sudo /usr/bin/update-manager"?
<pitti> $ sudo /usr/bin/update-manager
<pitti> sudo: /usr/bin/update-manager: command not found
<pitti> huh?
<pitti> ah, indeed
<pitti> update-notifier != update-manager
<pitti> mvo_: a missing dependency then?
<elmo> kamion: it might reject one, sec let me sync my katie changes
<mvo_> pitti: I think I need to tighten the dependencies here a bit. it's recommended right now, not depends
<pitti> mvo_: I install it manually now
<mvo_> pitti: if you right click on the icon, you have more choices (like starting the package-manager)
<pitti> mvo_: uh, "show updates" requires root privileges?
<mvo_> pitti: technically no, but there is a bug in gksu that makes the acquire of root later a bit messy. this will eventually be fixed
<pitti> mvo_: ah, now it seems to work
<pitti> mvo_: please update the dependency then
* fabbione starts the mono bootstrapping dance on sparc
<Kamion> elmo: machine with the candidate upload's doing a test installation anyway
<pitti> mvo_: uh, bad
<pitti> mvo_: I click on the icon, the dialog with the list of updated packages appears
<pitti> mvo_: I click on any item in the list and the dialog instantly disappears
<mvo_> pitti: python-gtk bug, seb128 fixed it yesterday
<pitti> mvo_: I actually wanted to see the changes
<pitti> mvo_: okay, thanks
<elmo> Kamion: done
<mvo_> pitti: or will it crash if you click on the "description" as well?
<pitti> mvo_: both, I can click on the checkbox or on the text
<Kamion> elmo: cool, thanks. is that it totally automated now or is it still an alias for byhand?
<pitti> mvo_: I do a dist-upgrade now and complain again after this :-)
<elmo> Kamion: haha, the latter, sorry
<mvo_> pitti: ok :) thanks for testing
<Kamion> elmo: thought so :)
<trukulo> hi
<Mithrandir> elmo: the problem with my blog was a friend of mine misconfiguring apache, but thanks anyhow, since I then noticed a load of DMA errors in the dmesg. :P
<lifeless> Mithrandir: ow
<Mithrandir> it might be the mainboard, I'm not sure.  Just rebooting to check first, after I've done a couple of extra backups.
<pitti> http://people.no-name-yet.com/~lamont/buildLogs/c/cupsys/1.1.23-1ubuntu3/cupsys_1.1.23-1ubuntu3_20050113-1036-amd64-failed
<Mithrandir> trukulo: what's up with the _big .avis?
<pitti> D'oh
<pitti> fabbione: see build log above
<pitti> fabbione: it seems that cupsys build-depends on itself
<fabbione> amen
<pitti> fabbione: so the cupsys version which fixes the procps/lppasswd issue can't be built because the older version does not install
<pitti> grrrrr
<pitti> lamooooooooooooooooont
<fabbione> pitti: we can problably workaround it
<carlos> pitti: could we meet in about 30 minutes?
<pitti> carlos: sure
<fabbione> what pulls in cupsys that is required to build cupsys?
<pitti> fabbione: I try to find that out
<carlos> pitti: ok, 11:40 UTC?
<pitti> fabbione: it seems that some common -dev package depends on cupsys now
<pitti> fabbione: that seems to be *stupid*
<pitti> carlos: ACK
<fabbione> pitti: we could theoretically upload a minimal version of cupsys that doesn't build-dep on itself to unfuck the buildd
<carlos> perfect, thanks
<fabbione> and reupload the full version immediatly after
<pitti> fabbione: or lamont just installs an older cupsys temporarily
<pitti> fabbione: the build worked on ia64 and powerpc
<Kamion> pitti: did you ask base-config to update from the net, or not?
<pitti> Kamion: hmm, I think I should have said yes
<Kamion> pitti: there's a separate base-config bug killing all installs at the moment, fixing that in a second - it has nothing to do with apt authentication though ...
<pitti> Kamion: usually I say yes
<fabbione> food
<fabbione> later
<Kamion> pitti: if you saw "~tubuntu-desktop: command not found", then I know the fix
<pitti> Kamion: I'm not sure
<pitti> Kamion: I was away during the installation
<Kamion> ok, I'll fix the bug I know about and then worry about the ones I don't know about :-)
<pitti> Kamion: when I returned I just saw a normal login prompt
<pitti> Kamion: let's hope that this was the reason :-)
<Kamion> ok
<pitti> AAAARGH
<pitti> php4 build failed
<pitti> because cupsys failed
<Treenaks> php depends on CUPS?
<pitti> why does half of our archive depend on a printer server?
<pitti> Treenaks: some common -dev package depends on cupsys, as it seems
* davyd laughs
<jdub> DOLPHIN KILLERS!
<davyd> this is almost as funny as battstat 2.9.4 eating all your Xserver memory
<davyd> almost...
<Keybuk> pitti: which one?
<pitti> Keybuk: gimme a minute, I just have to finish something else
<seb128> pitti: evolution-webcal fails because of cupsys too :p
* Kamion wonders if base-config will build before l-s-2.6.10, so that he'll have a chance to build more working CDs
<pitti> cupsys, THE central essential development package for kernel, evolution, php, and just about anything
<pitti> stunning
<seb128> :)
<trukulo> Mithrandir: uploading?
<Mithrandir> trukulo: are you sure?
<trukulo> Mithrandir: working on it now
<trukulo> they were'nt
<trukulo> ok, uploading now
<trukulo> but it's VERY slow
<Mithrandir> yeah, I've noticed that. :P
<trukulo> umm, seems stuck
<trukulo> no, it's uploading
<trukulo> but very, very slow
<trukulo> 3.3kbs
<Mithrandir> you might have more luck with rsync --partial  (and possibly -av --progress) since the connection seemed to drop once in a while.
<trukulo> Mithrandir: it's not my computer, he hasn't got rsync installed
<trukulo> :P
<Mithrandir> trukulo: ask him to install it? :)
<trukulo> i'm working on very bad conditions to upload the files
<Mithrandir> yeah, I can understand that -- just trying to be helpful. :)
<trukulo> Mithrandir: resume doesn't work with your ssh account?
<trukulo> :) i know, Mithrandir , thanks a lot
<Mithrandir> trukulo: does sftp support resume?
<trukulo> ummm , now i can't say
<trukulo> yes, it does
<trukulo> Includes the following fixes: SSH/SFTP file listing limit. SSH/SFTP resume upload fixes.
<trukulo> from a changelog of a sftp client
<Mithrandir> ok, fun.
<fabbione> pitti: dude.. everything is failing for that reason
<pitti> fabbione: hey, the missing procps dependendy was not my fault
<fabbione> i am not blaming you
<pitti> fabbione: I currently try to find the package that depends on cupsys
<fabbione> it's always GTK fault!
<Treenaks> fabbione: "seb!!!"
<fabbione> you will find some libgtk* depends on it
<fabbione> ;)
<fabbione> hell this is cool
<fabbione> mono tryihng to execute some win32 commands on sparc
<Mithrandir> pitti: gal depends on libgnomeprint depends on libcupsys2-gnutls10 depends on cupsys-client depends on cupsys
<Kamion> AIUI openssh sftp doesn't do resume
<Kamion> (yet, anyway)
<thom> fabbione: has mono been ported to sparc?
<Kamion> psftp does resume
<fabbione> thom: ENOCLUE
<thom> you might want to check before you try bootstrapping it? ;-)
<fabbione> that's almost an idea :-)
<pitti> Mithrandir: did you find out why cupsys b-d on itself?
<pitti> Mithrandir: I'm currently tracking that
<pitti> ... but I just cannot find it
<pitti> we need a recursive dependency display tool
<Mithrandir> apt-cache dotty | graphviz?
<Kamion> germinate?
<Kamion> http://people.ubuntu.com/~cjwatson/germinate-hoary-output/rdepends/cupsys/
<fabbione> Mono today ships with a Just-in-Time compiler for x86, PowerPC, S390 and SPARC-based systems.
<fabbione> but i think they mean solaris
<pitti> Kamion: this is the same as apt-cache rdepends
<pitti> right
<pitti> ?
<Kamion> no, it's recursive; although it doesn't list cupsys-client dep cupsys for some reason
<Kamion> may not be complete, can't remember exactly how that bit works
<pitti> oh right
<pitti> cupsys depends on cupsys
<pitti> but through which packages?
<Mithrandir> pitti: no, it doesn't.
<Mithrandir> debootstrap a hoary chroot, run apt-get build-dep cupsys
<Mithrandir> so I think sbuild would just be confused, or dpkg might be, due to unclean chroot.
<daniels> mdz:  649     Jan 13 Ubuntu Installe (  11) xorg_6.8.1-1ubuntu10_source.changes ACCEPTED
<fabbione> that mostlikely will ftbfs
<fabbione> due to cupsys being b0rk3d
<daniels> fabbione: WHOOHOO
<fabbione> Kamion: i think at least i386 picked up the kernel
<fabbione> so that means that everything will go banana
<fabbione> because not in sync
<Kamion> fabbione: no build log yet
<Kamion> fabbione: all I need is for base-config to beat the kernel by half an hour :)
<fabbione> Kamion: yeah.. this version will invalidate all the ccache so it will take ages to build
<daniels> https://xorg.freedesktop.org/~gisburn/X11R682/download/X11R682RC2/xorg-x11-6.8.1.902.tar.bz2
<fabbione> that's why i am afraid i386 is building the kernel
* daniels giggles maniacally.
<daniels> another blow struck for sensibility -- sane tarball names
<daniels> hot on the heels of a non-stupid config file name
<davyd> I have come up with a new idea
<davyd> when there are multiple network cards in a system
<davyd> d-i should show you which ones have media in them
<Kamion> d-i already selects the first one with media by default
<davyd> Kamion: seeing as I didn't know that, perhaps some visual indication would be useful?
<Kamion> netcfg patches welcome, though; it's scary localisation hell around there :-/
<fabbione> (given that the driver for that card or the card itself support mii)
<Kamion> davyd: agree it would be useful
<davyd> mmm, better mii support all round would be a nice thing
<davyd> so that my ethernet port only goes live if it knows there is media on there
<fabbione> davyd: that's not only a driver problem
<fabbione> some hardware simply doesn't know...
<davyd> fabbione: indeed
<davyd> I've played with it a bit in the past
<Kamion> davyd: can you file a netcfg enhancement request in bugzilla so I remember?
<davyd> Kamion: if I remember my password ;)
<davyd> fabbione: I did see a white/black list at some point
<Kamion> can't promise to do it for hoary though, I still don't really understand the weirder bits of debconf localisation
<davyd> for cards that were known good and known bad
<davyd> Kamion: I just thought it might be useful, no rush ;)
<davyd> I'm sure it will still make it for Sarge
<davyd> ;)
<Kamion> sarge d-i is not getting that sort of new feature :)
<davyd> or ever getting released?
<Kamion> ball's still in ftpmaster's court
<Kamion> but moving, at least
* davyd continues to work on g-applets 2.9.4.1
<davyd> stupid memory leaks
* davyd mumbles
<Mithrandir> davyd: when you get bored, you can fix the leaks in e-d-s :)
<davyd> Mithrandir: they don't leak 500megs into the X server
<Mithrandir> davyd: they don't?  I tend to get a process which is around 300MB after 24 hours.
<davyd> Mithrandir: yeah, I think that's all your crap in it's 'cache'
<Mithrandir> davyd: hm, how so?
<davyd> still, leaking into the X server is a pain, I haven't got it back yet
<mjg59> daniels: What version of xorg has your crack?
<daniels> mjg59: ubuntu10
<daniels> davyd: xrestop is yum
<mjg59> Rock-on
<mjg59> thom: Have you pushed that acpi-support stuff at all?
<davyd> daniels: I have now learnt about it ;)
<thom> no, firefox took too long last night
<fabbione> thom: btw you got all your readahead crack in -6 :-)
<thom> it's next on my list
<thom> fabbione: cool
<mjg59> Excellent
<daniels> davyd: heh
<davyd> daniels: I was wondering why my machine was sucking
<davyd> especially window repains
<davyd> *repaints
<daniels> i wonder if I can upload glibc without my machine bloody freezing this time
<daniels> (attempt #5 ...)
<fabbione> eh????
<Keybuk> yay, the peril-sensitive-ftp-client is working
<fabbione> uploading glibc?
<daniels> yeah
<daniels> i'm maintaining it now
<daniels> and i put in some patches i think will really speed it up a lot
<daniels> found 'em on the gentoo forums
<Kamion> damnit, I broke prebaseconfig
<Keybuk> o...k...  uh, *hunts for the hold key*
<fabbione> daniels: are you talkign about libc6?
* thom hits the EMERGENCY HOLD EVERYTHING button
<fabbione> daniels: because you know that soon someone will take care of it? don't you?
<Kamion> argh, please save me. I nearly uploaded "prebaseconfig_1.06ubuntu3_s0urce.changes"
<daniels> (in all seriousness, it's just a sync)
<daniels> and, hm
* fabbione stops rsyncing 
<daniels> Kamion: heh :)
<thom> Kamion: rofl
<daniels> fabbione: acx is quite badly broken :\
<daniels> if I do a large transfer, I can see my machine slooooooooowly come down to its knees
<fabbione> Kamion: ehehhe
<daniels> until it's utterly useless
<fabbione> daniels: there is no rush to upload libc6 really...
<fabbione> just wait until next monday
<daniels> fabbione: today is the last day for syncs
<daniels> fabbione: and it's meant to be done today
<daniels> or so says mdz
<Kamion> yesterday was the last day for syncs :-)
<fabbione> wan't it yesterday?
<daniels> Kamion: it's still the 13th
<Keybuk> today :)
<Kamion> the deadline was 12th I thought
<fabbione> ok
<fabbione> yeah so did i
<Keybuk> mdz's post was temporarly fuzzy
<fabbione> at least that's what mdz written in my bugs
<daniels> maybe he compensated for the $TZ difference :)
<fabbione> no i think he gave one day more to slow developers :P
* fabbione run away
<daniels> hm
* daniels coughs.
<daniels> ok, let's see if I don't kill nanasawa again
<fabbione> daniels: where is the acx patch you promised me?
<daniels> fabbione: been doing other stuff instead
<fabbione> wanker ;)
<daniels> hm, hasn't died yet.  progress!
<daniels> fabbione: !
<ogra> tststs
<thom> mjg59: basically, gonna upload what you gave me as 0.10, then do the rest of the hotkeys as 0.11
<fabbione> ogra: bug 5193
<fabbione> mjg59: 5232.. do you have the patch handy for it?
<ogra> fabbionne: i thought mvo said hae wants to....if he doesnt, i will
<fabbione> well until someone will do it
<mjg59> fabbione: StR is waiting for a 2.6.10 from benh
<ogra> i will ask him
<fabbione> mjg59: so am I :-)
<fabbione> mjg59: benh is in holidays afaik
<mjg59> StD is more of a problem - the guy working on it insists on targetting his code against bleeding edge swsusp crack
<fabbione> and didn't port his crack to 2.6.10 yet
<mjg59> I have no Mac hardware, so can't really test this stuff
<thom> mjg59: oh, can you give me the list of hotkeys again? 
<fabbione> mjg59: there is not much left of benh patch for 2.6.10
<thom> link me, rather
<fabbione> most of it is already upstream
<daniels> agh, wtf
<daniels> Jan 13 23:37:01 nanasawa kernel: VFS: file-max limit 50503 reached
<mjg59> thom: www.codon.org.uk/~mjg59/tmp/hotkeys.list
<fabbione> daniels: tune via /proc
<Kamion> anyone know what's up with, er, well, gnome* installability at the moment?
<daniels> fabbione: the question is: why, when I start a large transfer via scp, do I start consuming 50,000 file handles?
<thom> grazi
<fabbione> daniels: echo 100000000 > /proc/sys/fs/file-max
<fabbione> daniels: that's on the whole system.. not just your transfer
<fabbione> but remember that thingy sucks memory
<fabbione> and it is tuned at boot according to RAM
<daniels> fabbione: i know dude
<daniels> but acx_pci should not somehow be chewing 50,000 file handles
<fabbione> it was just to avoid you killing a remote server for a misunderstanding kid
<daniels> ahr, yeah :)
* daniels blushes.
<daniels> *cough*nevermind
<fabbione> daniels: do you want to send me the interdiff?
<fabbione> i can do the upload for you
<daniels> it's ok
<thom> daniels: what had you broken?
<daniels> i clued on when I looked in /proc and saw several thousand processes
<daniels> i used to be behind a fascist firewall where I had to SSH proxy
<fabbione> ahahaha
<daniels> so I deleted chinstrap's ProxyCommand line
<thom> oops
<daniels> cue ssh forkbombing my system into theg round
<fabbione> tsk
<fabbione> and you were ranting about the kernel
<fabbione> PEBCAK
<Keybuk> Kamion: e-d-s
<daniels> yeah, well the kernel's crap anyway
<thom> mjg59: 00000052 -> Lightning bulb (?) !!
<mjg59> thom: Yeah, no idea
<mjg59> That's just how I found it described
<mjg59> Possibly it's supposed to be lightning bolt, or something
<Keybuk> I thought lightning was U+2607 :p
<Keybuk> 
<jordi> hey
<jordi> sto and I were wondering if you plan to handle this case with the language packs for Hoary
<jordi> What do you do if a language-pack adds new languages?
<jordi> just adding the mo files will handle most of the stuff (app interface translation), but quite a few things will have problems still
<pitti> jordi: we have one source/Binary package per language
<jordi> one of the most visible is the vfolders and .desktop descriptions. Do you have an idea of how to handle that?
<pitti> jordi: so if a new language comes up, we just supply a new set of base/update/support package
<pitti> jordi: no, currently we just handle /usr/share/locale translations
<jordi> nod
* Kamion ponders a gross and unpleasant debconf hack
<sto> pitti: we were thinking about adding support for .desktop.language files
<sto> pitti: seems reasonable?
<pitti> sure
<jordi> sto thought that maybe patching gnome-vfs to look for translation overrides in some extra files could work.
<pitti> sto: these can be put into the language packs
<pitti> sto: if gnome supports reading these files
<sto> pitti: that's the idea ;)
<pitti> sto: however, that does not work using gettext I assume?
<jordi> it doesn't, currently. A few things would need to be patched.
<pitti> sto: I think the best would be to stuff some mo files somewhere and make desktop files work with mo files
<pitti> sto: I think that is better than having .desktop.lang
<pitti> (mo files = use gettext)
<jordi> pitti: yeah, GNOME is full of generated files similar to the .desktop case.
<sto> pitti: sure, the .desktop.lang suggestion is a quick hack
<sto> pitti: but seems easier to add
<pitti> otherwise you have to reinvent the wheel for rosetta
<pitti> sto: it might be easier to add
<pitti> sto: but in the long run you shoot yourself in the foot
<jordi> off the top of my head, .vfolders (or something similar related to gnome-vfs), .desktop, .schemas and something else I forget.
<pitti> sto: because it requires a completely new infrastructure for translation
<jordi> yeah.
<jordi> you'd have to write something to automatically generate these files
<pitti> sto: as I said: converting the language packs to ship other files is not that problematic
<pitti> sto: but I would not really like that approach
<sto> pitti: sure, the idea is a temporary solution for our own distribution, for the long term is better to use gettext
<carlos> pitti: the problem with .desktop files is that it's not easy to use gettext with them because it's not the application which ships it the one that looks for the translations but nautilus, konqueror, gnome-panel, kpanel, etc... and it makes no sense to have a .mo per .desktop file and language only for three strings...
<pitti> carlos: sure
<pitti> carlos: well, if you can extend Rosetta to support in-line translations as well
<sto> carlos: and what do you think about the .desktop.lang?
<pitti> carlos: but then it makes no sense to put them into a language pack
<pitti> carlos: I mean the current form of desktop files 
<pitti> carlos: with .desktop.lang we _can_ put them into a langpack
<carlos> sto: we could add support to gettext to those kind of files
<carlos> gettext produces .mo files and other formats
<carlos> like the Java one
<carlos> from .po sources
<pitti> hey, good idea
<carlos> so that should work
<carlos> but it's not a change we could do _now_
<carlos> you need to add support to gettext and ask for an update to the freedesktop standard about .desktop files
<carlos> In fact, intltool should be killed and moved inside gettext so it generates directly .xml files and other formats like gettext does
<thom> hrm, why is mmv not in desktop
<carlos> sorry, like intltool does
<lamont> moo
<lamont> cupsys/amd64, or everywhere, I wonder?
<Kamion> lamont: pitti's fixed it
<Kamion> if you mean the build failures
<thom> lamont: seems you didn't have any great joy with mono
<thom> ?
<pitti> Hi lamont
<fabbione> lamont: all arches
<pitti> lamont: cupsys does not build on i386 and amd64, but works on ppc and ia64
<lamont> Kamion/pitti: cool - tell me if I need to do anything there
<pitti> lamont: it build-deps on it self
<lamont> thom: haven't done squat.  inplan for today
<pitti> lamont: so the new version (that fixes the issues) can't be build because it depends on the old version, which doesn't install
<lamont> pitti: so I need to nudge it through on i386/ia64?
<pitti> lamont: is it possible to temporarily install an older cupsys version in the i386/amd64 buildds?
<thom> ah
<pitti> lamont: some other packages were uploaded today, whose build failed as well (because they build-dep on cupsys)
<pitti> lamont: it's a mess
<Kamion> WOW. evil debconf hack (almost) works
<Kamion> just need to recode templates and sort out $LANG ...
<Treenaks> talk about redundancy.. the evolution-data-server build here includes "-I. -I. -I.. -I.. -I./.." on all GCC invocations
<Kamion> Treenaks: just to make sure
<thom> coo, one of my firefox bugs appears to have magically fixed itself
<thom> sweet!
<sivang> thom: hehe
<sivang> hi all , btw :)
<Kamion> lamont: (not just because they build-dep on cupsys, but because the chroot was hosed - c.f. prebaseconfig)
<cartman> [OT]  GraphViz is now free software. http://www.graphviz.org/News.php Time to take it to main? :)
<Keybuk> mako: work now, play later.
<Treenaks> sivang: how did you solve the 'po-file not in rosetta' stuff?
<Treenaks> sivang: (for existing translations)
<thom> uh.
<thom> 15:02 ~/work/packages% sudo swapon -a
<thom> swapon: /dev/hda6: Invalid argument
<thom> HUH?
<zul> partition table messed up?
<Kamion> Keybuk: hmm?
<tseng> mayhaps a bad swsusp broke your swap?
<tseng> it does that.
<Keybuk> Kamion: picking packages that you knew would break my code
<Kamion> did I?
<Kamion> which one breaks?
<thom> tseng: ah, that might be it
<tseng> thom: mkswap on it again
<tseng> if thats the issue.
<Kamion> Keybuk: they're not set in stone, I'm willing to pick other ones
<thom> tseng: yeah, that was the issue
<Keybuk> Kamion: fixed the bugs now
<metalikop> Eek, evoluton-exchange is broke.
<Keybuk> Rejected: md5sum and/or size mismatch on existing copy of glibc_2.3.2.ds1-20ubuntu1.dsc.
<Keybuk> Rejected: md5sum and/or size mismatch on existing copy of glibc_2.3.2.ds1-20ubuntu1.diff.gz.
<Keybuk> Rejected: glibc_2.3.2.ds1-20ubuntu1.dsc: old version (2.3.2.ds1-20ubuntu1) in hoary >= new version (2.3.2.ds1-20ubuntu1) targeted at hoary.
<Keybuk> Rejected: can not overwrite existing copy of 'glibc_2.3.2.ds1-20ubuntu1.diff.gz' already in the archive.
<Keybuk> &&
<Keybuk> Rejected: mdadm_1.8.1-1ubuntu1.dsc refers to mdadm_1.8.1.orig.tar.gz, but I can't find it in the queue or in the pool.
<Keybuk> -- 
<daniels> Keybuk: -20ubuntu1 already in hoary? wtf?
<Keybuk> you don't just suck, dude; you used teeth
<elmo> upload 01/09 by doko
<daniels> gnar
<pitti> lamont: here?
<lamont> pitti: yeah - just finished with the massive give-back, most of main should get started quickly
<lamont> thom: mass give-back on the buildd's, once they get semi-quiet, I'll go deal with mono
<thom> k
<Riddell> elmo: am I able to upload to universe yet?
<elmo> Riddell: not yet, sorry, today hopefully, the kernel security hole has delayed me
<Riddell> elmo: right, thanks
<pitti> Hi sjoerd!
<opi> Hi there, Ubuntu Developers :-)
<daniels> mdz: so does warty gain a new l-r-m to go with the kernel abi bump?
<mjg59> thom: I think I've solved the video issue
<mjg59> thom: Can you remove the vbestate stuff from prepare.sh and add a script in rcS.d that does vbetool vbestate save >/var/run/vbestate and then modify resume.sh to read the state from there?
<mjg59> Using boottime video state seems to work better
<fabbione> lamont: i think the ia64 chroot is kinda broken
<lamont> fabbione: what machine name at the top of things?
<fabbione> Automatic build of linux-source-2.6.10_2.6.10-6 on weddell by sbuild/ia64 1.170.5
<fabbione> http://people.ubuntulinux.org/~lamont/buildLogs/l/linux-source-2.6.10/2.6.10-6/linux-source-2.6.10_2.6.10-6_20050113-1500-ia64-given-back
<thom> mjg59: ok, will try that in a second
* lamont bets on 'weddell'
* lamont back in a few minutes
<fabbione> jamesh: make-kpkg: command not found DOH!
<fabbione> ops
<fabbione> that was for lamont
<mjg59> daniels: Does the i810 3D after resume thing need updated DRM as well as updated X?
<mjg59> thom: Doing that seems to work perfectly here
* mjg59 goes out
<daniels> mjg59: it touches DRM, DRI (Mesa) and X
<mjg59> daniels: Right, I need to pull in more stuff then
<daniels> mjg59: hence, non-trivial
<daniels> mjg59: right
<fabbione> daniels: l-r-m did build on i386.. looks good
<daniels> fabbione: sweet
<mjg59> Could you produce a patch for the 2.6.10 kernel?
<daniels> mjg59: not before I go to bed, no
* daniels notes the time.
<daniels> mjg59: tomorrow's tasks include backporting mesa 6.2.x branch (which has the i915 shizzle plus i8xx dri resume), and i'll produce a 2.6.10 patch as part of that
<daniels> mjg59: then fabbione can be your bitch
* daniels -> pillow
<fabbione> patch for the kernel to do what?=
<fabbione> there is a bunch of stuff in bk to update DRM but it is really big
<fabbione> and buggy
<opi> mdz: could you remind me, who is going to get PegasosPPC board and work on Ubuntu port?
<fabbione> (considering the 200 commits after the main pull)
<Kamion> mmm, shiny evil
<Kamion> +version="$(chroot /target dpkg --status passwd | grep ^Version: | \
<Kamion> +          sed 's/^Version: //')"
<Kamion> +RET=0
<Kamion> +DEBCONF_RECONFIGURE=1 chroot /target \
<Kamion> +       /var/lib/dpkg/info/passwd.config reconfigure "$version" || RET="$?"
<Kamion> [etc.] 
<Kamion> opi: I've got a Pegasos, been meaning to get Ubuntu up and running on it
<lamont> Kamion: sed -n '/^Version:/s/^Version: //p' instead of the grep | sed??
<opi> Kamion: I'm going to get one in a week
<opi> Kamion: maybe we should join forces? :)
<Kamion> lamont: too late for the upload, but yeah, I just couldn't remember the sed rune for that
<Kamion> grep | sed seemed safer pending me checking busybox sed for whether that would work
<lamont> Kamion: well, I'm sure there's a perl rune, too... :-)
<Kamion> lamont: ENOPERL
<lamont> ah, that'd be a challenge for you alright.  I bet ENOPYTHON-MINIMAL too.
<Kamion> correct
<Kamion> either would be a good deal of overkill though :)
#ubuntu-devel 2005-01-26
<mdz> sladen: we're using create_compressed_fs, which is actually advfs installed with a different name
<fabbione> morning guys
<fabbione> lamont: still around?
<mdz> fabbione: morning
<fabbione> hey mdz
<jdub> hey, who sang that song, "it'll all be better if we slept together"?
<fabbione> jdub: you are begging us to say you mom (part 2)
<jdub> :-)
<fabbione> sorry.. couldn't resist
<mdz> the name of my new band is Jeff's Mum
<mdz> perl: I HATE YOU
<jdub> dude, you so want to *be* my mum
<fabbione> who is the owner of this boglot?
<fabbione> ~logbot@
<fabbione> i don't mind it.. just curious
* fabbione enables pkgstriptranslations on sparc buildd
<jdub> 19:58 < Greves> i may have to try this so-called "ubuntu"
<jdub> we're lying, it's actually called "smillysloffilyploff"
<fabbione> bah time to start sandpapering another room
<fabbione> later fellas
<Mithrandir> fabbione: have fun
<Keybuk> Kamion: #5517, want to look?
<thom> mornin
<Keybuk> hey dude
<mdz> Kamion: around?
<mdz> after all my wrangling, it's starting to look like the initrd doesn't have the new cdebconf
<mdz> $1 says I need to specify your magic flag to use the daily d-i build
<mdz> ah, found it, DI_TYPE
<amu> moin 
<mdz> LAMONT
<mdz> http://king.warthogs.hbd.com/%7Ebuildd/livecd/livecd-current.cloop:
<mdz> 09:53:50 ERROR 404: Not Found.
<thom> mdz: there's a livecd.cloop which is a symlink to 20050115/livecd.cloop
<mdz> thom: can you make it point to something which actually exists?
<mdz> fuckit, i'll try swapping in a new initrd on my iso
<thom> mdz: livecd-current.cloop should work now
<thom> as should livecd.cloop
<mdz> thanks
<elmo> mdz: dude, tell me you're not still up?
<mdz> oh, but I am
<mdz> and I can almost taste it
<elmo> do we use cfq by default in our kernels?
<mdz> /boot/config-2.6.10-2-k7:CONFIG_IOSCHED_CFQ=y
<elmo> yeah, but IIRC AS is the default
<elmo> I'd check, but well, I don't have any non-custom kernels handy ;)
<elmo> Using anticipatory io scheduler <-- from mine
<mdz> ROCK ON
<mdz> X autoconfiguration in the live CD
<jdub> sweet!
<thom> woot
<Kamion> mdz: morning
<mdz> Kamion: just in time
<Kamion> mdz: did you tweak CONF.sh? I was reading the backlog thinking "shit, forgot to change that over so that he wouldn't have to know
<Kamion> mdz: that main->universe symlink stuff was in order that warty CD builds remain possible
<Kamion> if somebody trimmed the broken symlinks, they broke that again :)
<thom> elmo: yeah, anticipatory is the default
<elmo> Kamion: I think you'll have to only use --copy-links for pool
<Kamion> elmo: ah, ok
<jdub> mdz: how scary is the livecd image-building foo?
<Kamion> I saw the anonftpsync change, will review/commit
<elmo> Kamion: k, sorry for using your account like that
<Kamion> not a problem
<mdz> jdub: there's the d-i building bit, the live image building bit, and the CD image building bit
<thom> elmo: and yeah, we probably ought to default to CFQ IMO
<jdub> mdz: yeah, the live image
<Kamion> how come it needed my account in particular? was there stuff non-group-writable?
<Kamion> 'cos if so that's a bug I'd like to fix, so mdz can do this stuff
<elmo> Kamion: I dunno, matt asked me to sort it, and I'm not in the group - i didn't want to use sudo in case I left broken permissions around
<mdz> jdub: shouldn't be particularly scary, but then, no one has seen it except lamont ;-)
<Kamion> ok, no problem, I was away and he needed to get stuff done
<jdub> mdz: ... ah.
<Kamion> mdz: I've set DI_TYPE to daily-installer, next daily build will use the new d-i build
<mdz> Kamion: once casper 0.14 builds, a new set of CDs would be great
<Kamion> mdz: I rsynced a full live CD last night, and tried to rsync a new one today; it is not rsyncing usefully
<mdz> Kamion: yeah, lamont discovered this as well
<mdz> it's worth some investigation to find out why; intuitively it seems like we should be winning
<opi> morning
<mdz> jdub: it was rad, I just booted up this hoary live CD straight into GNOME, and the desktop looks newer than the one on my workstation ;-)
<mdz> fresh crack
<jdub> mdz: SASS
<mvo_> when I booted it and did a apt-get update, some seconds later update-notifier showed some updates :) funny 
<jdub> mvo_: last night, mine showed 156 updates ;)
<jdub> COW is going to *love* that ;)
<mvo_> hehe :)
<Riddell> any ideas why my upload of kdelibs to warty-security hasn't built over night?
<mdz> thom: I saw something strange with readahead
<mdz> on powerpc and/or amd64, it was segfaulting
<mdz> and on _shutdown_
<mdz> no idea how
<mdz> since it doesn't even seem to run at shutdown
<Kamion> mdz: apt 0.5.27.2's fine for sarge, isn't it?
<Kamion> er, </offtopic>
<mdz> Kamion: yeah, that was absolutely its intended target
<jdub> mdz: readahead does the sort-readahead-file-by-disk-order on shutdown, doesn't it?
<mdz> jdub: the 'stop' section in /etc/init.d/readahead is empty
<mdz> and it doesn't have a link in rc/06] .d, either
<mdz> so clearly I'm insane
<mdz> maybe it segfaulted at boot
<Kamion> mdz: the changelog message in 0.5.27.2 is not backed up by any actual diff to the source though
<Kamion> I see the stuff in 0.5.27.1, but I don't see the diff for this setlocale() stuff
<mdz> really? hmm
<mdz> the setlocale() stuff was icing
<mdz> the 0.5.27.1 bits are what is needed for sarge
<Kamion> the diff is like a single page, it's very clear
<Kamion> ok
<mdz> weird
<Kamion> go arch!
<mdz> a single page? the translation updates are missing as well?
<Kamion> yes
<mdz> wtf
<thom> mdz: there's K76fileordering
<Kamion> it has MaxArgs and MaxArgsBytes changes, configure/configure.in versioning, changelog, and nothing else
<thom> which does the sort on shutdown
<thom> it ought to move to the same init script
<thom> but... :-)
<Kamion> mdz: approved 0.5.27.2, if you could leave a fix for these issues 'til after the next dinstall I'd appreciate it
<thom> mdz: so both readahead *and* fileordering were segfaulting?
<mdz> thom: just checked to confirm
<mdz> K76fileordering segfaults
<mdz> S39readahead does not
<mdz> this was powerpc just now
<thom> right, hrm
<thom> my amd64 is still in a box, does it happen there too?
<mdz> will check
<thom> thanks
<mdz> no problem on amd64
<thom> right, it could be the funky inode code. could you possibly file a bug and i'll talk to daniel silverstone (since it's his code) on monday
<mdz> Kamion: so, I think I'm going to crash, but a new set of CDs based on daily-installer and containing casper-udeb 0.14 would be great
<mdz> thom: how much of the faster-boot experimentation ended up making it into hoary?
<thom> we don't have caching of /dev nor the faster gdm artwork yet
<thom> most everything bar that should be in
<elmo> gdm's artwork is slow?
<Kamion> mdz: ok, will build in twenty minutes or so when casper 0.14 shows up
<thom> elmo: resizing it is, yes
<mdz> I'll queue an rsync for +1 hour or so
<elmo> boggle
<thom> elmo: (it's a png, not svg, so gdm has to do some hard work)
<Kamion> mdz: ok
<mdz> thom: I've added an entry to the HoaryGoals page for it; please create a wiki page to record which bits went in, and also the future stuff that we could do
<mdz> so we can brag about it in the release notes, etc.
<jdub> elmo: seems gdk-pixbuf is crap at scaling images
<thom> mdz: sure
<jdub> thom: turns out an svg version of current gdm glow is 'hard'
<Kamion> elmo: could you update germinate on jackass? I added support for per-arch seed entries, would like to start using them soonish
<jdub> thom: it's not just one gradient ;)
<thom> jdub: ah.
<jdub> thom: so we'll probably have something new and special
<mdz> thanks
<mdz> night all
<thom> so we're racing to gdm, and then sitting around and twiddling our thumbs for an image to load :-)
<jdub> not elmo special, proper special
<mvo_> night mdz
<thom> night dude
<jdub>    * Enable X autoconfiguration(!)
<jdub> :-)
<amu> n8 mdz 
<Kamion> elmo: will anastacia (or whichever one it is) be able to deal with germinate giving different answers for main-ness/universe-ness on different architectures?
<Kamion> (doesn't really matter if it can't and I guess overrides probably don't get to be per-arch like that, would just be interesting)
<jdub> elmo: ping
<daniels> mdz: g'night
<Kamion> also, either elilo needs to be removed from i386 or efibootmgr needs to be built on i386, one or the other
<Kamion> I think probably the latter given that elilo explicitly claims that it's useful on some i386 systems
<Kamion> hm, do Intel x86_64 systems use EFI?
<Kamion> and/or elilo ...
<elmo> Kamion: nope, it almagates all the architectures, so if you're in main for one, you're in for all
<Kamion> fair enough
<sladen> Kamion: I don't believe so---remember those machines are still coming up as 16-bit 286's
<Kamion> still, it will help out (a) CD images and (b) debootstrap, and you'll need to understand the new syntax
<elmo> btw, the gdm image stuff couldn't you just resize permanently?  most people don't change res often?  combined with a mini-rainbow of common sizes being generated by cron after install or something?
<Kamion> sladen: so are i386en and apparently they can use EFI
<elmo> Kamion: ok, will do when I get to the DC..
<Kamion> sladen: it's a matter of boot firmware rather than 64-bitness AIUI
<elmo> Kamion: I don't think they do use EFI no
<elmo> HP DL3x0's G4's are em64_t, but AFAIK they have a normal bios, I'll ask taggart
<Kamion> hm, ok
<azeem> is there an eaysy way to get laptop-mode not to mount partitions with noatime?
<azeem> eh, in warty
<Kamion> http://adare.warthogs.hbd.com/%7Ebuildd/livecd/livecd-current.cloop:
<Kamion> 11:11:01 ERROR 404: Not Found.
<Kamion> can someone fix that?
<Kamion> amd64 and i386 were fine
<elmo> how would it be fixed?
<Kamion> livecd-current.cloop-1024:65536 exists ...
<thom> Kamion: doing so now
<elmo> azeem: you actually have a use for atime?  on a laptop?
<elmo> thom: by manually adding the CD ?
<elmo> err, link?
<azeem> elmo: it breaks mutt
<elmo> if so, please be sure to tell lamont so he can actually fix it
<elmo> azeem: boggle
<thom> elmo: yes
<thom> and yes
<Kamion> I think the -4096:4096 build failed and that was what was supposed to be linked to the plain name
<thom> Kamion: done
<Kamion> judging from terranova
<Kamion> thom: thanks
<thom> same happened on amd64, fwiw
* Kamion babysits
<bob2> azeem: how does it break mutt?
<azeem> bob2: mutt sometimes thinks there's new mail in mailboxes all the time 
<azeem> aha
<azeem> "If you use mutt and experience this, you must disable the noatime remounting in the control script by setting DO_REMOUNT_NOATIME=0."
<azeem> control script == /usr/sbin/laptop-mode
<azeem> took me a while to figure that out :)
<thom> it sources /etc/default/laptop-mode, no?
<Kamion> mdz: new live CD up, seems sane
<sladen> thom: I think the laptop-mode in Hoary/Debian is out of date;  there's new ones I've seen that have about 20 options in the config file
<thom> sladen: quite likely
<azeem> there are options in the Debian one, yes
<sladen> Kamion: just Googling, I've found one press release mentioning plans to produce an amd64/efi system
<azeem> thom: yeah, that works as well, thanks
<thom> np
* thom rips the script out of the current kernel and tests
<sladen> Kamion: but I suspect you can ignore it until that actually happens
<doko> kamion: can we close #1232?
<Kamion> doko: just looking at the last couple of entries
<jdub> sladen: "coloured prompt!"
<jdub> sladen: "no, what do you want from the boot process?"
<jdub> sladen: "optimised packages!"
<sladen> jdub: "use flags!"
<Kamion> do users want a boot process that can be inserted nasally?
<jdub> right into the main vein
<sladen> we need a focus group.  This is like extracting water from a stone
<jdub> Kamion: have you done mini.iso installs?
<Kamion> jdub: which mini.iso?
<jdub> Kamion: warty's
<Kamion> jdub: no, *which* mini.iso? netboot, monolithic, ...?
<Kamion> mini.iso is just a way of putting the bits together, it doesn't specify which bits
<Kamion> people have done netboot installs, I haven't done one with final warty and I know there were a couple of bugs
<Kamion> I did a hoary netboot install yesterday, was basically ok
<jdub> Kamion: oh, netboot i guess, couldn't see any others
<Kamion> probably depends on the arch
<jdub> yeah, some dude did a warty install and it was incomplete
<jdub> i386
<Kamion> hm, how so?
<Kamion> I can give it a try later ...
<jdub> didn't have ubuntu-desktop
<jdub> and a bunch of other stuff
<Kamion> boggle
<Kamion> that's a function of the archive not the boot method
<jdub> he may have done something wacky
<Kamion> was he trying to use the CD as a "mirror"?
<jdub> no
<jdub> full net install
<Kamion> ok
<jdub> it was greves on #ubuntu if you want to ask for more details
<Kamion> I'll check it out next opportunity, then
<Kamion> I have to go in twenty minutes unfortunately, maybe later
<Kamion> thanks for passing that on
<sladen> one thing that was strange with the net-install is that it only offered 'Great Britain' as a mirror option.  Eventually figured that was because that's where the Canonical machines are.  Is it worth adding an automatic skip in the case of only one choice?
<Kamion> sladen: theoretically, but I'd rather add more mirrors
<two-face> Hi.
<jdub> elmo, lamont: ping
<jdub> oh, hi elmo 
<elmo> ?
<jdub> elmo: so Riddell did a warty-security upload - do you still have to confirm it?
<jdub> elmo: are security build logs ever published?
<elmo> jdub: warty-security is setup to require confirmation from the security team yes
<elmo> and no
<jdub> cool, ta
<elmo> (security team meaning pitti)
<jdub> oh right
<elmo> kdelibs got built fine, it's just sitting in queue/accepted
<jdub> great
<jdub> just answering Riddell's mail on u-d
<Riddell> elmo: why are the logs not published?
<elmo> I've no idea how we want to handle warty-security, i.e. whether or not we require confirmation
<elmo> Riddell: because security uploads are often embargoed
<jdub> heh
<Riddell> what does embargoed mean?
<elmo> err, handle warty-security +"for universe"
<jdub> Riddell: answering your mail atm, with that precise phrase in it :)
<elmo> Riddell: not to be released until a certain agreed date
<Riddell> elmo: ah, that makes sense
<Riddell> hmm, if I'm an approved ubuntu person does that mean I get on planet.ubuntu :)
<jdub> Riddell: planet ubuntu will actually be for members soon, not just developers :)
<Riddell> is the website team aware of just how heavily ubuntulinux.org uses text-shadow?  it gets quite annoying after a bit
<jdub> Riddell: whereabouts?
<elmo> Kamion: so, what's going to change when I update  germinate?
<Kamion> elmo: with the current seeds, nothing
<Kamion> elmo: well, depends what your current version is I guess ;)
<Kamion> elmo: once seeds get updated, there'll be stuff like "elilo [ia64] ", so elilo will only be considered part of the base seed if you're germinating for ia64
<Kamion> it won't be actively excluded on other architectures though - i.e. if something on i386 depends on elilo it'll still be included
<Kamion> just not seeded
<elmo> ok, so that won't matter to me
<elmo> hmm, which doesn't really help does it?
<Kamion> elmo: it helps with the CD images and my auto-debootstrap-updater - the only reason I want you to update is that the syntax for arch-specific seeds would be invalid in old germinate, I think
<elmo> presumably the point of that was to not pull things in that can't be dep-satisfied? 
<elmo> ok
<Kamion> no, the point is not to have to pull stuff into base on one arch just because it's base in another
<Kamion> or similar
<Kamion> it doesn't matter for main/universe-ness, it matters for which bit of main/universe it's in
<Kamion> which bit of main, I mean
<elmo> ok
<Riddell> jdub: all the headers http://muse.19inch.net/~jr/tmp/ubuntu-text-shadow.png  it would be fine if it was toned down a bit
<elmo> I thought it might be trying to address oo.o on ia64 for example
<Kamion> up to now I've had a system of overrides in debootstrap to cope, but that's a bit informal and really ought to die
<elmo> ok, I'm up to colin.watson@canonical.com--2004/germinate--mainline--0--patch-29
<Kamion> elmo: lamont mentioned that, but I'm not convinced that'll work; otoh we might be able to take it out of desktop on ia64, I think, which might help
<Kamion> it'll still be a build failure then but wouldn't block livefs builds
<Kamion> elmo: that's currnt
<Kamion> +e
<elmo> kamion: it won't work
<elmo> the archive can't do per-arch components for a given binary package
<elmo> hmm, anasatacia got very upset
<Kamion> elmo: like I say, I don't care whether it's still in main or not
<jdub> Riddell: holy crap
<elmo> Kamion: yes, but to solve oo.o, you'd have to
<Kamion> elmo: if it's still in main that's fine, but we could make ubuntu-desktop stop depending on it
<jdub> Riddell: i guess gecko doesn't implement that
<elmo> well sure, but we'd still have uninstallable packages in main, which sucks
<Kamion> elmo: don't see why? if it's not depended-upon it won't be included
<jdub> Riddell: that looks completely crap - can you file a bug?
<Kamion> oh, yeah, it's not a full solution, but it would stop being a live-CD blocker
<elmo> sure
<Kamion> what broke anastacia?
<elmo> anyway, this doesn't seem to have worked too well, linux-source is getting no love for !i386.. checking
<Kamion> huh, odd
<fabbione> uh?
<Kamion> the last change really ought to be a no-op with current seeds
<elmo> kamion: I was quite out of date
<elmo> I jumped 15 odd patches
<Kamion> hm, the multi-component/multi-dist stuff would be the prime candidate for something going wrong
<Kamion> it was all fine for me on cdimage though
<Kamion> elmo: anyway unfortunately I really have to go, late already; if it's a blocker feel free to revert and I'll sort it out later
<elmo> do you care if Desktop goes screwy?
<elmo> other than it's not a blocker
<Kamion> yeah, kinda
<Kamion> cdimage cares anyway
<Kamion> if you could mail me the germinate invocation you're using that would be goodd
<elmo> cares before you get back? :)
<Kamion> mmm, probably not
<Kamion> I'll be away most of the afternoon/early-evening though
<elmo> ok then, i'll leave it, i'm not even sure how I'd revert.. I'll poke at it and mail you details including how to reproduce
<Kamion> baz update <whatever-revision-you-were-last-at>
<elmo> yeah the problem is the last part
<Kamion> oh, don't have the output from the update around any more?
<elmo> oh, yeah I do, blah.. too tired
<elmo> or rather, I have a backup copy of the entire dir, I'll revert to that for now
<Kamion> anyhow ... gone
<Riddell> jdub: what is the difference between a developer and a maintainer?
<jdub> Riddell: developer covers committers, maintainers, etc.
<jdub> Riddell: so it's just a more general term
<Riddell> jdub: you said planet would be for "maintainers not just developers"
<jdub> Riddell: members not just developers
<Riddell> jdub: so who's allowed on the planet at the moment (not because I want on it, I'm trying to understand the terminology)
<jdub> Riddell: atm, it's an unupdatable blob ;)
<jdub> Riddell: i'm fixing things up atm, so that when it will be maintained from an arch branch
<jdub> at which point, it will be for any member
<Riddell> ok, richt
<jdub> i'll put your blog on straight away :)
<jdub> do you have an ubuntu or tech category?
<jdub> elmo: btw, could you send the index.html.tmpl from the planet install? i didn't realise you just sent the config last time :-)
<sladen> jdub: you need to put a flowchart diagram up that goes   member -> committer -> maintainer   or something
<jdub> yeah
<Riddell> jdub: http://www.kdedevelopers.org/blog/feed/57
<jdub> hrm
<elmo> jdub: I thought I tarred up config-ubuntu for oyu.. but ok
<jdub> drupal does such poo rss ;)
<jdub> at least it has dates now
<jdub> elmo: hrm, wait a sec
<jdub> i'll check personal mail
<jdub> nup
<elmo> jdub: sent
<jdub> thanks
<jdub> now to deplone it
<elmo> doko: I just passed you a pyopengl b-d bug
<elmo> doko: do  you know off hand whath appened to python2.3-dictdlib?  dict-moby-thesaurus still b-d's on it
<doko> python2.3-dictdlib is nowpython2.4-dictdlib, will update dict-moby-thesaurus
<elmo> doko: ah, well it must have FTBFS
<elmo> 'cos python2.4-dictdlib doesn't exist yet in the archive :)
<elmo> could you chase that down too?
<doko> pyopengl b-d, I should pass that on to daniels, see http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=xvfb
<doko> elmo: ok, btw, what any news about the powerpc64 chroot on davis?
<Riddell> jdub: should I turn up at at the next technical board meeting and ask to be made a maintainer so I can work on kde packages in main (and does haggai need to do the same)?
<elmo> doko: err, what would I build it with?  I thought you were just asking if I would do it, not for me to do it
<jdub> Riddell: haggai has been approved already
<elmo> doko: can you make the pyopengl bug say 'blocks on <n>' (whatever <n> is for our BTS)
<doko> elmo: will do
<jdub> Riddell: you should put your name on the maintainer proposals page, and CC and TB agenda
<elmo> doko: [ppc64]  will a powerpc chroot do to start with?
<Riddell> jdub: ok. why the CC agenda?
<doko> elmo: chroot: yes, then install the things I wrote you in an email.
<elmo> Riddell: CC and TB approve maintainers
<elmo> doko: I don't seem to be getting email from you
<elmo> doko: where/when/to-who did you send it, and what's the message  ID?
<jdub> Riddell: gotta get the love from everyone ;)
<Riddell> elmo, jdub: so CC approves members, TB approves committers and both CC and TB approve maintainers?
<Riddell> sladen: the flow is fairly obvious, it's the details that arn't clear
<ogra> Riddell, wasnt there a propsal from mark that you get both stati in one step to speed up the MOTU process
<ogra> Riddell, thats how i understood it at least
<jdub> Riddell: the bar for being a universe maintainer is quite a bit lower than for being a main maintainer
<doko> elmo: sent again. you did get my email about the mailman sync from unstable?
<jdub> Riddell: haggai was approved quickly because he's an experienced debian maintainer, and has a saucy and convincing british accent
<ogra> hehe
<jdub> ogra: do you have a blog?
<ogra> yup
<jdub> ogra: with an ubuntu or tech category in it?
<ogra> nope, do i need one ?
<jdub> not necessarily
<jdub> your call which you'd prefer
<jdub> would you like to be aggregated on planet.ubuntu?
<jdub> if so, rss url please :)
<ogra> since all i blog will mostly be ubuntu related i dont think i need a category: http://www.grawert.net/weblog.cgi/index.rss
<ogra> :)
<jdub> cool
<ogra> thanks
<ogra> jdub: btw, remember our graveman discussion about setting the g-v-m burner key in postinst.... ?
<jdub> yeah
<jdub> the one where i cried and begged you not to? ;)
<ogra> jdub: if i leave nautilus in there, but want to burn with graveman, how do i avoid nautilus from popping up if a cd is inserted ?
<jdub> ogra: you can't, the best thing is to change the setting
<ogra> except by setting/unsetting the key dynamically if the app is started
<jdub> ogra: in future, g-v-m will have a list box of choices instead of command lines
<ogra> yup, thats what i thought...
<ogra> ah, thats nicer :)
<jdub> in which case you'll be able to provide a choice for it in the package, and the user can choose it
<jdub> elmo: haven't got your mail yet...
<elmo> oh GAR
<elmo> jdub: really sent - sorry, sending mail to canonical.com from within the DC, is, err interesting
<jdub> heh
<fabbione> hey seb128
<sivang> hi seb128_ 
<seb128_> hello
<fabbione> hmmmmmm
<fabbione> we have an ioctl problem with the new emu10k1 driver
<fabbione> now.. how many applications do we need to update?
<fabbione> all the mixers segfaults doing some very specific operations
<fabbione> cool
<fabbione> now i have the THX tuned again!
<elmo> fabbione: hmm - I thought you added the pb sleep patch?
<fabbione> pb?
<fabbione> powerbook?
<elmo> yeah
<fabbione> it's no go on 2.6.10
<fabbione> i am waiting for benh to port it
<fabbione> and i will add it
<elmo> oh, meh, ok
<fabbione> i did try to merge it myself but it was no go
<elmo> it's in the source package which confused me
<elmo> the source source package, I mean
<fabbione> too many bits have been merged upstream and others need to be reviewed
<fabbione> yeah my fault
<fabbione> i forgot to take it away
<fabbione> but it's not applied
<elmo> yeah, ok, no prob
<fabbione> it works on 2.6.9
<elmo> yep, using it on there now.. I'll go back to that +security patches
<fabbione> elmo: if it is only for your laptop and it is not multiuser, you only need the igmp patch
<fabbione> that was the only remote DoS
<fabbione> otherwise skip the others
<fabbione> i doubt you give accounts to people on your laptop
<fabbione> iirc that one made it in 2.6.9 before we switched to 2.6.10
<fabbione> note for my self: stop playing around servers powerswitched when passing new cables
<fabbione> (machines can casually turn off)
* Riddell high fives JakubS 
<JakubS> :-)
<JakubS> jdub: i'm the guy who filed debian bug against mdnsresponder's license
<JakubS> why you install copy of BSD instead of APSL-2 ?
<lamont> Kamion: you around?
<JakubS> into /usr/share/doc/mdnresponder/copyright?
<jdub> JakubS: it's a bug
<jdub> JakubS: just needs to be clarified
<jdub> JakubS: the library interface is BSD (thus the confusion)
<JakubS> ah ok, i just wanted your comment on that 
<JakubS> library sure is but daemon not
<jdub> that's right
<jdub> i'm aware of the problem :)
<lamont> fabbione: so is -8 still the current one, I wonder?
<fabbione> lamont: he left sometime ago
<fabbione> lamont: yes :-)
<fabbione> i am not working today
<lamont> woot!  I finally have the current kernel source in  my mirror!!! :-)
<fabbione> i need to unmelt my brain
<fabbione> AHAH
* fabbione uploads -9
<crimsun> ogra: if you'd like and have the time, please consider triggering a simple rebuild of 'nicotine' against python2.4 (all that's needed is a recompile).
<lamont> fabbione: you;re the one who wants me to work on it...
* haggai says something unintelligible to jdub in a saucy british accent
<jdub> riowr!
<fabbione> lamont: i would like to get the kernel at "state of the art" on 6 arches :-)
<fabbione> lamont: that would be an achievement
<Riddell> haggai: awa wi ye sassenach
<lamont> I will work on it this weekend.  which happens to include mondyua
<lamont> which is fortunate, since today is 'fix the frozen pipes and figure out what else got ruined' day
<lamont> thom?
<doko> fabbione: lrm again. adding the avm isdn modules including the firmware will increase the size of each l-r-m binary on ix86 by a factor of 4, ending up at 6mb. upload it as is, or split it in it's own binaries lrm-avm-2.6.xx ?
* ogra reads dupload doc...
<Treenaks> ogra: not dput?
<ogra> Treenaks: are there advantages ? 
<Treenaks> ogra: it's a shorter name ;)
<ogra> heh
<ogra> ok
<lamont> Setting up fontconfig (2.2.3-2ubuntu1) ...
<lamont> /usr/sbin/laptop-detect: line 14: dmidecode: command not found
<lamont> grumble
<Treenaks> yay for non-x86!
<Treenaks> (I guess)_
<lamont> yeah
* lamont makes a note to file a bug later today
<fabbione> doko: dude.. until everything is in the same source it's ok
<fabbione> doko: it doesn't really matter how many binaries will spit out, but again you need to discuss this with mdz since he expect max 2 sources with kernel stuff.. kernel and lrm
<Treenaks> grrgghgggrrrrrrh...
* Treenaks pokes via-rhine in 2.6.10
<Treenaks> fabbione: (not your uber-patched 2.6.10)
<fabbione> ARGH!
<fabbione> xine-libs are borked!
* fabbione fixes
<doko> fabbione: he delegated the decision to you/us :)
<doko> doko: so I propose to put it in the same module until somebody cries about the size.
* sladen cries about the size
<fabbione> doko: so go ahead and decide.. for me any solution is the same
<doko> fabbione: ok
<ogra> crimsun: uploaded... lets see if i did it right ;)
<crimsun> ogra: many thanks
<ogra> thanks for pointing me at it ;)
<crimsun> np :)
<robertj> has anyone in here running hoary done a dist-upgrade to find that only 640x480 & 800x600 were still working on their i810 hardware?
<robertj> and also, that there was no menu text on the panels or right-click menus?
<robertj> It's been noted a few times on the forums
<sladen> robertj: 1024x768 still works.  but I've seen the  no-panels  bug many times
<sladen> robertj: it's a race that needs tracking down.  Workaround:    pkill -u $USER
<sladen> and log back in
<robertj> sladen: there are napenls
<robertj> they are void of text
<robertj> I've got the gnome foot and the sound icon up top but no menu text
<robertj> at the bottom I have lal my launcher icons and stuff, but no text on the task list
<sladen> is this funny-crashed-xserver type thing
<robertj> if I click the foot I get all the images in a little micro-menu with no text, is that what you have seen?
<sladen> nope.  not seen that one.  As though all the text is suddenly zero-width?
<robertj> and once it was just very very tiny
<robertj> like a little line going across the screen, with several pages taking up only a few hundred pixels
<robertj> sladen: getting Bad V_BIOS checksum
<robertj> should that worry me?
<trukulo> Mithrandir, r u there?
<fabbione> daniels: ping
<trukulo> fabbione, have you seen your video?
<fabbione> trukulo: no. i was waiting to know if it was all up
<trukulo> small one is all up
<trukulo> well, small ones, i mean
<fabbione> nah i was waiting for the big one
<trukulo> ok
<ogra> why is gnome-btdownload still excluded from universe ?
<trukulo> ogra, i have package for 20050112 graveman
<trukulo> if you want sources..
<ogra> oh, there is a new upstream ?
<trukulo> more than one
<trukulo> 3 i think
<trukulo> with new dependencies
<trukulo> build time too
<trukulo> http://mercurio.homeip.net/debian/
<trukulo> there you have mine , if you want to look at it
<fabbione> i wonder why you two don't share a common arch repo
<fabbione> and create an ubuntu and a debian branch
<fabbione> keeping the common stuff
<fabbione> in "common"
<trukulo> because i'm very bad doing this
<trukulo> i don't understand well things related to package development, yet
<ogra> fabbione:  because i dont want to _develop_ graveman.... if there will be a debian package it will go into universe anyway....
<ogra> and it seems trukulo plans to get his included into sid if i understood it correctly....
<fabbione> ok
<fabbione> but i would still share the efford with a simple RCS
<fabbione> and you would both benefits in learning :-)
<trukulo> ogra, i want to, i have to speak with a friend that is debian delevoper
<ogra> fabbione: i'm setting up bazaar anyway....
<trukulo> perhaps he can be my "bitch-uploader"
<fabbione> ogra: baz is fine :-)
<fabbione> baz is based on the arch protocol
<ogra> trukulo: nah, come on.....get a dev yourself....you are already on your way....
<ogra> fabbione: i know ;) i had a lot of cigarettes with jblack in mataro ....
<trukulo> ogra, time problem here :)
<ogra> trukulo: universe urgently needs new maintainers ....
<sivang> ogra: the reason for using those is that they are cheaper right? ;-)
<trukulo> i have my own enterprise, and not very much time
<ogra> sivang: those ?
<trukulo> so being a developer it's not on my plains
<trulux> woo
<trulux> mdz: ping
<sivang> ogra: woops, I though jblack was the cigarettes's filling.
<ogra> heh
<ogra> sivang: lol, jblack is james blackwell from the arch team ;)
<sivang> ogra: hhm, I hope he doesn't read this somehwere :)
<trukulo> Mithrandir, you awake? tell what video to upload next
<jdub> trukulo: i listened to the video of me yesterday - obviously i need help with spanish humour, badopi dudes were not laughing loud enough :-)
<trukulo> lol
<trukulo> if you want to take classes, tell me
<trukulo> you know what happens?
<trukulo> they don't understand very well english
<trukulo> so they need to do a lot of work listening, and that is no good for humor
<jdub> yeah
<trukulo> anyway, yes, you need to improve your humor
<trukulo> heheheh
<jdub> i hope they watch the video again and realise how FUNNY it was :-)
* jdub spanks trukulo 
<trukulo> you need to be very ugly to be funny
<trukulo> as mako
<trukulo> xD
<jdub> heh
<fabbione> jdub: what time is it in .au?
<fabbione> or better.. where daniels lives
<jdub> 0300
<fabbione> jdub: isn't time to wake him up and tell him that xine-lib is borked?
* sivang notes some lighting help and projector -->laptop integration would help, too. :)
<fabbione> daf: nevermind... i always forget that i tend to put all the logs > /dev/null on my sensible systems
<fabbione> ops
<fabbione> ECHAN
<elmo> okay, the buildds are going down for a while - shout now if this is particularly inconvenient for you
<elmo> (while ==> hours)
<fabbione> go for me
<sladen> robertj: mention  Bad V_BIOS  to daniels (I'd assume vesa-bios or something without lookingit up
<robertj> sladen: using a custom xorg.conf got me going again
<robertj> menus still lack text though
<robertj> maybe somewhere pango is barfing?
<sladen> robertj: what did you have to change in the xorg.conf?
<Riddell> I'm getting a "/usr/bin/ld: cannot find -lXinerama" compile error because there is a libXinerama.so.1 but no libXinerama.so  Any ideas how to get round that?
<robertj> sladen: not sure, I just created a real basic xorg.conf and got it going
<crimsun> Riddell: is libxinerama-dev installed?
<fabbione> Riddell: as crimsun sais...
<Riddell> crimsun: you are a genius
<crimsun> nah, I've just been bitten by it before
<crimsun> .so symlinks are in -dev packages
<Riddell> if I have a package from CVS how should I version it?  cvs20050115-ubuntu1  or cvs20050115-1ubuntu1 ?
<fabbione> Riddell: i suggest <oldversion>+cvs<date>-0ubuntu1
<fabbione> or something like that
<trukulo> or better : package-cvs<date>-randomnumber-willfuckyoursystemifyoudontwatchit-ubuntu1
<mako> trukulo: I HEARD THAT
<mako> trukulo: be carefully buddy.. i know where you live :)
<trukulo> mako, You talking to me? You talking to me? You talking to me? Then who the hell else are you talking to? You talking to me? Well, I'm the only one here.
<Treenaks> trukulo: could you seed fabio_big or jeff_big? :) (you were the seed right?)
<fabbione> ahah i found the perfect weapon to give to our users to kill all the bugs themselves
<fabbione> http://twerked.com/~splice/pics/p_debates.jpg
<bob2> hahaha
<bob2> html files with .jpg extenions are wrong and against nature
<trukulo> sure
<Treenaks> bob2: as long as the MIME type is OK...
<Treenaks> bob2: IE won't understand though :)
<lupus_> nice :)
<trukulo> Treenaks, fabio uploading
<fabbione> trukulo: uploading what?
<Treenaks> fabbione: video from mataro
<fabbione> ah ok
<trukulo> big one
<fabbione> ok
<trukulo> mirak, fabio big uploading
<trukulo> ups
<trukulo> Mithrandir, i mean
<Treenaks> trukulo: I can't see a seed on fabio_big ?
<Mithrandir> trukulo: great
<trukulo> Treenaks, i'm doing right now
<trukulo> Mithrandir, can you confirm seed of fabio?
<Mithrandir> Treenaks: I'm seeing it
<Mithrandir> yeah
<Treenaks> hmmm
<Treenaks> oh hey it works now
<trukulo> :)
<seb128> is there a problem with the archive ?
<amu> 3 problems with the livecd, ipw2200 is not detected, X with my nvidia and after login out, and relogin with gdm, gdm ask for a user + pass       
<seb128> nm
<mdz> amu: tried the new live CDs? :-)
<jdub> mdz: how's the rsyncability?
<mdz> jdub: crap
<jdub> bummer
<amu> mdz: yep ;) 
<amu> mdz: *dammed* you sleep less than me 
<mdz> amu: did X come up for you?
<jdub> sleep is for the week
<bob2> haha
<amu> mdz: no, driver was correct, nv, resolution was also fine, i changed it to vesa and it runs  
<mdz> amu: oh, does your card not work with nv?
<mdz> amu: the login/logout thing is apparently a feature in gdm, but maybe we can change it...jdub, seb128?
<amu> mdz: no, with 1600*1080 only nvidia works D 
<mdz> amu: is there some way to detect it so that we can choose vesa for that card instead of nv?
<jdub> mdz: missed the context
<mdz> amu: have you talked to daniels?
<mdz> jdub: gdm autologin only autologins when it first starts up
<jdub> oh right
<mdz> jdub: if you log out, it leaves you at a login prompt
<mdz> I assume this is by design
<mdz> to prevent endless looping and that sort of thing
<jdub> yeah, totally
<jdub> can we just turn off logging out? :)
<amu> mdz: nv it works with smaller ex 1400*9xx resolutions, but Xorg  detects full 1600*1080 
<mdz> dunno, can we?
<jdub> i assume gdm with autologin if you ctrl-alt-backspace
<jdub> we might be able to
<mdz> at least remove it from the menu anyway
<mdz> though
<jdub> so the logout box will only have restart and shutdown
<mdz> I sort of like the idea of being able ot test drive gdm
<amu> mdz: nope i guess he's still sleeping idle for 6h 
<mdz> if they want to
<jdub> mdz: true
<jdub> mdz: maybe add to the livecd gdm artwork "login with ..."
<mdz> jdub: or pre-fill it
<mdz> with the autologin username
<jdub> don't think we can do that
<jdub> without code changes, at least
<mdz> yeah, but easy ones
<jdub> hrm
<jdub> i think there's a 'remember last user' option
<mdz> jdub: in 'expert' mode, maybe it would disable autologin entirely
<mdz> and only seed the username
<mdz> so the user could select their session or whatever
<jdub> mmm
<jdub> not that there are very useful alternative sessions ;)
<mdz> no...
<amu> jdub: isnt it possible to define a default user with no login? ex. with kdm you can define such a thing *ducks* 
<jdub> #DisplayLastLogin=false
<mdz> amu: that's autologin, which is what we already do
<jdub> we can turn that on, at least
<jdub> mdz: i think he means default user but without actually doing the login (ie. seeding it)
<mdz> oh, so the same thing I suggested
<amu> jdub: ack
<mdz> only cheeky ;-)
<jdub> heg
<amu> bleh 
<amu> hal-device-manager" has quit unexpectedly.
* amu resets and continue writing test-cases ;) 
<elmo> Riddell: ?
<Riddell> elmo: hi
<elmo> Riddell: your amarok upload is really broken in some way, it completely killed the archive scripts
<elmo> Riddell: unfortunately I have to run right now.. I've moved it out of the way, but could you not reupload it and hold off on anymore uploads till I have a chance to figure out why?
<elmo> [Offhand, I think the version number you used is illegal, but I'm surprised it caused that much chaos if that's all that's wrong] 
<chrisa> That's quite a feat
<jdub> armed and dangerous
<Riddell> 1.2_beta3-ubuntu1  the underscore should be a dash?
<bob2> it should be nothing
<bob2> assuming the upstream version is 1.2beta3
<bob2> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
<Riddell> bob2: previous versions were 1.2-beta2  but then debuild complains that the version format it wrong so I changed it to an underscore
<Riddell> I'm so naieve
<bob2> wow
<bob2> who packaged it originally?
<Riddell> bob2: amu 
<jdub> *bob2 backpedals*
<bob2> amu: your version numbering wais crackful :-)
<amu> bob2: letme check :-() 
<amu> bob2: uptream version is 1.2-beta2+cvs20041228
<amu> my version was 1.2-beta2+cvs20041228-1ubuntu1 
<amu> bob2: please explain me what's wrong with my version numbering, execpt to package a cvs version   
<mdz>           The <upstream_version> may contain only alphanumerics[1]  and the
<mdz>           characters `.'  `+' `-' `:' (full stop, plus, hyphen, colon) and
<mdz>           should start with a digit.
<mdz> [1]   Alphanumerics are `A-Za-z0-9' only.
<mdz> amu: ^^
<T-Bone> hi
<bob2> amu: it's ok but confusing to have multiple -'s
<amu> bob2: err not :) "characC[C[C[C[C[C[Cters . + - : (full stop, plus, hyphen, colon) and should start with a digit" 
<bob2> oh, and not starting with a number
<bob2>  * Starting Postfix Mail Transport Agent...
<bob2> eval: invalid option -- c
<bob2> postfix/postfix-script: warning: unable to create missing queue directories
<bob2>  *stfix/postfix-script: fatal: Postfix integrity check failed!           [fail] 
<bob2> invoke-rc.d: initscript postfix, action "start" failed.
<ogra> elmo ?
<T-Bone> Kamion: ping?
<Riddell> does anyone have an amd64 machine we could use to test a compile on?
<amu> Riddell: me  
<Riddell> amu: you do?  well how about testing that libtunepimp change on it?
<amu> Riddell: hold on i'll add you an account 
<mxpxpod> what's up with the gpg signatures?
<mxpxpod> on the archives
* T-Bone curses hotplug
<doko_> mdz: hmm, fabbione didn't want to add an "artifical" version number, did talk with him about it.
<fabbione> doko_: ????
<T-Bone> fabbione: i'm debugging ia64 linux atm, fyi
<fabbione> T-Bone: cool
<T-Bone> s/linux/ubuntu/
<fabbione> yeah
<fabbione> my bitching put you on the right direction :-)
<T-Bone> ran through some very nice issues, the first one being that the kernel package aren't on the daily hoary iso
<fabbione> DOH
<T-Bone> indeed
<T-Bone> and that's the least of the pains
<mdz> fabbione: linux-restricted-modules-2.6.10.1
<fabbione> ah yeah.. 
<doko_> fabbione: we did talk about adding the avm drivers as an uuencoded tarball, or upload them with a new lrm source, with an 2.6.10.1 version number. IIRC you wanted to have them uuencoded
<T-Bone> i'm up to the point where i can boot the box standalone, but now i'm running into some issues i've already met on my ppc box, namely hotplug screwing up
<fabbione> i suggested..
<fabbione> T-Bone: interesting...
<T-Bone> fabbione: which led me to curse the default kernel configuration for not having builtin support for USB keyboards
<fabbione> doko_: don't get me wrong.. but i only suggested..
<doko_> fabbione: ok, another upload ...
<fabbione> for the reason that changing number might require other packages too change to
<fabbione> T-Bone: that bounce back to you for not giving me a kernel config :-)
<fabbione> doko_: go ahead.. * is fine for me :-)
<T-Bone> fabbione: yeah, but unfortunately that's a common problem: had the same on my ppc box
<T-Bone> i ended up completely disabling hardware auto detection and hardcoding mandatory modules through /etc/modules
<fabbione> T-Bone: i am pretty sure we have usb keyboard support for PPC
<T-Bone> that's exactly what i'm doing on ia64 now
<T-Bone> fabbione: on warty, usb was support was a module
<T-Bone> hence you didn't get a keyboard control until _after_ hotplug did its job. And when it didn't... you were screwd (as i am on ia64 ;)
<fabbione> # USB Input Devices
<fabbione> CONFIG_USB_HID=m
<fabbione> CONFIG_USB_HIDINPUT=y
<fabbione> CONFIG_USB_HIDDEV=y
<fabbione> # USB HID Boot Protocol drivers
<fabbione> CONFIG_USB_KBD=m
<fabbione> CONFIG_USB_MOUSE=m
* T-Bone gives the boot one more time
<fabbione> it's there
<T-Bone> fabbione: 'm'
<fabbione> do you need it 'y'?
<T-Bone> until the module gets loaded, you don't have a keyboard
<T-Bone> fabbione: i do when hotplug screws: you can't interract with the init process until _after_ hotplug loads the module
<fabbione> tough luck
<fabbione> :P
<T-Bone> it's the 5th time i'm booting on the cd, mounting the fs (rescue udeb doesn't seem to work btw) and editing a few files to get the box to boot
<fabbione> sec.. i am on the phone
<T-Bone> i'm in known country since i ran through the same havock on ppc
<T-Bone> YAY! Box booted!
<T-Bone> damn. that was a struggle
<T-Bone> oh, while i'm at it: i gave warty a try on my 64bit g5 box. can't boot any power4 kernel
<fabbione> re
<fabbione> T-Bone: now.. upgrade the box... get linux-source-2.6.10 (-8)
<fabbione> update the config in a decent way
<fabbione> and send them back to me asap
<T-Bone> fabbione: heheh, hold on buddy
<T-Bone> the box is not in good shape
<fabbione> you don't need to compile
<fabbione> it's enough you send me the config
<T-Bone> i had several failures with base install and had to tweak a lot the install process
<T-Bone> ok
<fabbione> i can do test builds for you
<fabbione> and send you the logs back
<T-Bone> fabbione: btw, the elilo package doesn't look good to me
<T-Bone> it installs EFI cruft in /EFI/debian
<fabbione> T-Bone: eheh this isn't my port dude :-)
<T-Bone> lol
<fabbione> somebody with ia64 needs to debug and fix
<fabbione> i only have access to a remote machine where i can compile
<fabbione> no console access, no root access
<fabbione> so that's all i can offer
<T-Bone> sure, but i don't have an overwhelming knowledge of all packages, nor all ia64-specific packages
<fabbione> T-Bone: that's something we can coordinate in here
<fabbione> also most of the basic ia64 stuff is simply dragged from debian
<fabbione> s/basic/specific
<T-Bone> i'll ask Bdale about elilo next time i see him online
<fabbione> so it mostlikely needs love
<T-Bone> yeah i figured that out
* T-Bone notes that apt-get source works better with a deb-src line :P
<fabbione> and i am back to watch movies :-)
<T-Bone> lol
* T-Bone will get some dinner too in a short while
<T-Bone> fabbione: see what we're discussing with jbailey on #d-kernel. That might actually be the Right Thing to do, and thus keep kernel config consistent with Debian
<fabbione> T-Bone: these configs are debian based but they are not the same and can't be
<fabbione> we have different hardware support, more drivers
<fabbione> etc.
<T-Bone> good point
<T-Bone> anyway please look at what was said on #d-k
<daniels> Kamion: someone raised an interesting point -- is it worth having separate desktop and server install CDs?
<daniels> Kamion: e.g. ooo out, a2/php4/postgres in
<daniels> Kamion: since data centres in romania often have terrible bandwidth
<lamont> bob2: what did you do to postfix??
<T-Bone> lamont: i did go past the anna problem you told me about, but ran into quite a lot of issues
<bob2> lamont: I have no idea
<bob2> lamont: just sudo invoke-rc.d postfix stop
<lamont> T-Bone: what was the anna issue?
<T-Bone> lamont: no clue, wasn't hit. I used the expert mode and carefully selected the modules i needed, for i do not trust hw detection on anything else than x86
<T-Bone> lamont: hw autodetect did fail shamelessly on my ppc box
<bob2> lamont: is it fixable?
<lamont> bob2: will have to check
<lamont> mdz about?
* lamont has mono questions for mdz
<bob2> hrm, maybe my filesystem is fux0red
<T-Bone> lamont: i took a few notes about what went wrong, guess i'll mail kamion and you. d-i needs some changes afaict
<T-Bone> oh
<T-Bone> and daily ia64 isos need linux-images
<T-Bone> ;)
<lamont> those should be there, I thought...
<lifeless> daniels: datacentre, romania, two words I didn't expect to hear in the same breath.
<T-Bone> lamont: tried today's iso, weren't. Got the nice 'no installable kernels were found' fatal error
<lamont> T-Bone: awesome.
<lamont> that's a kamion thing
<T-Bone> lamont: what?
<lamont> T-Bone: getting kernels on the cd
<T-Bone> ah ok
<T-Bone> i'll send you a brief report of the couple of hours i spent on my zx2000 trying to get the damn thing to boot (which i eventually did after quite a lot of pain)
<T-Bone> :)
<lamont> actually, that's pretty much anyone... we just need to add them to the right seed....  mdz/jdub OK with that?
<T-Bone> lamont: there's another problem with libunwind7: tho it's on the cd, for a reason i can't figure out, it doesn't get (properly?) installed and thus screws a few dependancies later on. Installing it by hand solves the issue
<doko> T-Bone: which libunwind7 version do you try to install?
<lamont> that should just be a debootstrap change
<lamont> doko: today's daily-build install
* T-Bone goes off
<T-Bone> i'm starving
<T-Bone> bbl
<daniels> mdz: when I do l-r-m/l-m for warty, does that go to -security, or -updates?
<mdz> lamont: here
<mdz> daniels: when you do a security update for it, that's -security.  when you fix a critical dataloss bug, that's -updates
<lamont> looks like we may need to add the ia64 kernels to the seeds?
<lamont> mdz^^
<mdz> lamont: sounds likely
<lamont> and mono...
<lamont> did we decide to pull that from main until it can build itself?  and do we want to upload the 1.0.4 abomination?
<mdz> I thought we decided that mono wasn't ready for horay
<mdz> hoary
<lamont> 1.0.4 in universe, then?  or not even that until it can build itself?
<daniels> mdz: and when l-i changes and makes l-r-m uninstallable, that's ...
<daniels> mdz: the only change is to get it back in step with a -security update
<daniels> mdz: (since the latest update took it to .8.1-4)
<mdz> daniels: X autoconfig fails on my amd64
<mdz> it ends up with UseFBDev "true"; "false" works
<mdz> the vga16 fb module is loaded, because we came from d-i (live CD)
<mdz> daniels: er
<mdz> daniels: kernel security updates should include a new l-r-m if the ABI changes
<mdz> fabbione, pitti: ?
<mdz> s/should/MUST/
<daniels> mdz: errr ... wack
<mdz> lamont: universe, sure
<daniels> mdz: ok, so that (l-r-m)'s -security, then?
<amu> daniels: X autoconfig fails on my amd64, changing from autodetected nv to vesa, works  
<mdz> daniels: yes, it would be, if in fact pitti/fabbione did not update it
<daniels> good god
<lamont> ok.  once I see the source back in universe, I'll deal with the upload.
<daniels> mdz: currently, if we have a usable framebuffer, and it's not offb/vesa, we attempt to use it
<amu> daniels: +i386 ... ppc with ati on testqueue :)  
<daniels> mdz: ok
<mdz> daniels: maybe vga16 should be added to that list of exclusions?
<mdz> dunno what the problem is
<mdz> can get you a log
<daniels> mdz: fixing the usefbdev mess will be a total shit, but i'll have a look at it
<daniels> mdz: /proc/fb would be useful
<daniels> amu: heh
<mdz> ok, next boot
<daniels> i'm very much tempted to whitelist UseFBDev, the same way I've whitelisted HorizSync/VertRefresh
<daniels> iirc the only one that really needs it is nv/powerpc
<amu> daniels: i think pitti has those combination
<daniels> amu: yeah, a few dyo
<daniels> the nv driver is complete crap, it does about the rough equivalent of drooling on the keyboard and hoping it'll work
<daniels> needs all the assistance it can get to program modes
<amu> daniels: unfortunately, i guess 30-35% of all new laptops/desktops comes with nvidia, i have too much trouble before with nv and gnoppix  
<daniels> amu: mercifully, most i386 laptops are i8xx, which we can do fine now
<tritium> Is useradd or adduser preferred?
<Treenaks> adduser I think
<Treenaks> useradd is more "low-level"
<mdz> Kamion: hmm, current powerpc live CD doesn't boot for me
<mdz> and is suspiciously small
<tritium> Treenaks, thanks.
<amu> daniels: proc/fb 0 VGA16 VGA ( it's a GeForce FX Go 5200 )
<mdz> daniels: ^^ that's what mine looked like, too
* lamont wanders off for a while
<mdz> lamont: amd64 cloop image contains the wrong kernel modules
<mdz> lamont: needs to be updated to 2.6.10-2
<mdz> Kamion: re-burning fixed it, nm
<mdz> though it is strange that it is smaller than i386
<mdz> powerpc live CD++
<amu> mdz: a ugly workaround for this nv problem is booting with linux debian-installer/framebuffer=false
<mdz> daniels, amu: this was going to become a problem with usplash anyway, so may as well fix it now
<fabbione> mdz: ?
<T-Bone> fabbione: is that fabbione@c.c ?
<fabbione> yea
<T-Bone> k
<fabbione> <mdz> fabbione, pitti: ?
<mdz> fabbione: did you guys upload linux 2.6.8.1-4 without updating linux-restricted-modules?
<fabbione> mdz: no idea.. it's herbert/pitti that do warty
<fabbione> was -4 the one that changed the ABI?
<mdz> yes
<fabbione> i remember i was in CC because i was doing hoary and you, pitti and herbert were discussing the problem
<fabbione> but i didn't check if l-r-m was upload after that
<mdz> I just finished (finally) converting my mythtv box to ubuntu
<mdz> total 6 in the house now :-)
<fabbione> mdz: still one less than me :-)
<fabbione> i am up to 7 ubuntu and one debian
<fabbione> :P
<fabbione> and when i will be back from my honeymoon i will need to clean that up too :-)
<mdz> fabbione: I could put ubuntu on the zaurus to catch up
<fabbione> yeah but i run the only l33t hoary sparc in the world :-)
<fabbione> spaaaarc.... elmo are you around?
<mdz> fabbione: Jan 15 10:21:33 <elmo>  Riddell: unfortunately I have to run right now
<mdz> (4 hours ago)
<fabbione> mdz: ok thanks :-)
#ubuntu-devel 2005-01-27
<ogra> no luck for me with the daily livecd on amd64 :`(
<calc> anyone here happen to use SOAPpy?
<calc> (python-soappy) seems not to work when return type is float, even the examples given on its homepage don't work :\
* calc wonders if he is doing something wrong with it
<mdz> calc: I haven't, no
* mdz nags calc about libogg ;-)
<jdub> http://people.ubuntu.com/~jdub/planet/
<jdub> el commento scorchio?
<Riddell> jdub: why the white background?
<jdub> so it doesn't look like someone weed on it
<jdub> also, it generally looks better (people kinda assume)
<Riddell> jdub: it might look better but it's inconsistent with all the other ubuntu/canonical websites
<jdub> yep
<jdub> i've left the rest of the chrome in the same colour
<daniels> jdub: scorchio!
<jdub> it's a simple change if people really deliriously object
<daniels> jdub: not such a fan of the yellow up top, but shit, it's come a long way
<jdub> website redesign contest announce going out soon ;)
<mdz> jdub: what is up with the scaling in the multiload applet?
<daniels> WORD
<jdub> mdz: scaling?
<mdz> what it appears to be doing is considering the highest sample in the current period to be the maximum
<mdz> and scaling the graph relative to that
<jdub> haha
<mdz> which means that if there is any activity at all, it looks like it is maxed
<jdub> for which graph?
<mdz> all of them
<jdub> doesn't seem to do that for cpu
<jdub> arch?
<mdz> maybe not for cpu, dunno
<mdz> looking at network and I/O
<mdz> i386
<mdz> right now I am downloading a file at about 150kbyte/sec
<mdz> over 100mbit ethernet
<mdz> and the network graph is full
<mdz> I think a smarter idea would be to remember the highest value ever seen
<jdub> mdz: it has detected that you're using low quality cabling
<mdz> and treat that as max, where no authoritative value is available
<jdub> yeah
<jdub> pinging davyd, who is probably not awake
<jdub> http://weblog.zerokspot.com/posts/164/
<robertj> are the autobuilders up yet?
<lamont> robertj: up is such a relative term.
<lamont> 3 of them were actually up and running (out of 12)...  I'm rebuilding chroots on all of them right now, spring cleaning and all that
<robertj> ahh, do you know if there is anything in the que for xorg and friends
<robertj> although I'm not unsure it's not pangos fault, I need to check on that
<robertj> great results though, like every font in every gtk app was like 1 point  ;)
<lamont> haven't looked - see people.ubuntu.com/~lamont/buildLogs/Lists/hoary.all.{i386,amd64,powerpc,ia64}
<lamont> if it says 'Needs-Build', then it's queued
* T-Bone calls it a night, bye all
<robertj> wow, that's quite a list
<lamont> hrm.. wonder if thom is awake
<jdub> o/~ all this time in litigation, so much for darl's happy ending o/!
<mjg59> Is the canonical conference before or after LCA?
<lamont> mjg59: I expect after, dunno
<lamont> it's certainly after the release
<jdub> after
<jdub> mjg59: dates will be announced next week
<jdub> mjg59: it'll basically be 25th-30th
<mjg59> Hm. I might actually be able to make that, possibly.
<mjg59> jdub: When are you getting married, then? :)
<jdub> 17th
<jdub> 17 18 19 20 21 22 23
<jdub> 24 25 26 27 28 29 30
<jdub> 17 == married
<mjg59> Haha
<jdub> 18-23 == linux.conf.au
<jdub> 25-30 == ubuntudownunder
<mjg59> I have to teach on the 2nd May
<jdub> 1 == FUCK OFF
<lamont> jdub: pia is gonna kill you, you know...
<mjg59> But from the end of March until then, I'm free
<jdub> lamont: i prepped her for it a long while back :)
<mjg59> So I may actually be able to join you guys
<jdub> that'd be rad
<jdub> would love to see you at desktop.conf.au too :)
* jdub is renaming gnome.conf.au
<sladen> mjg59: you asking aswell?
<mjg59> sladen: Mm?
<mjg59> jdub: Well, when there's some better idea as to what's going on, I'll let you know what's possible
<sladen> mjg59: same question I asked jdub, only a couple of hours ago :)
<mjg59> sladen: Pff. You expect me to analyse history?
<sivang> jdub: there are 2 gnome confs a year? the one in germany and the one in .au? and so close by date.. :)
<jdub> sivang: there are many
<jdub> there's GUADEC (which roams around europe, and is the biggest)
<jdub> there's the summit, which is based in boston
<jdub> there's a spanish one
<jdub> there's gnome.conf.au
<jdub> there's one in chile
<sivang> jdub: which one is the best to attend ? :-) (I think I can predict the answer from you)
<sladen> mjg59: it was a /privmsg to be fare 
<mjg59> Guadec is probably the single most important
<jdub> if ubuntu doesn't have more mini-confs than gnome within a year, i'm going to buy a jet and do them myself :)
<jdub> sivang: guadec
<sladen> GUADEC is 28th-30th May in Stuttgard
<jdub> pretty much everyone goes to guadec
<mjg59> The summit probably gets more done, but guadec shapes what's going to be done significantly more
<jdub> and there's more fanboys
<mjg59> Yeah, you get to meet and fanboy rml
<sivang> mjg59: fanboy rml?
<sladen> mjg59: and everyone gets to meet and fanboy you
<sladen> sivang: you can rob him of his love
<mjg59> sivang: rml deserves mad fanboying
<sivang> who is rml? :-) 
<jdub> rob love, kernel hackeur
<kent> hmm,  is there some way of getting intouch with some one from Stuttgart who are going to GUADEC and could perhaps let some other, like me for example, live at his/her's place over the event? I have never been at such an event, but i think it would be fun..
<sladen> kent: you have similar plans to me, but this is a good 4 months away yet...
<sivang> jdub: ah yeah, just read about him in the speakers list :-) quite a guy
<kent> sladen, yeah.. and i'm very good at making plans in the middle of the night, which i forget the next day. But i think i will write this down. I looked at the internet, and if i only have to pay for the tickets to get there, and some for the food, then i think i can afford it.
<jdub> kent: jump on guadec-list and ask
<Riddell> I like how this year's guadec is in much the same place as akademy was last year
<sladen> Riddell: wouldn't want to risk holding a major conference somewhere without letting some minor, dispenable conference test the waters first
<Riddell> sladen: you know that tone of voice in #ubuntu would get you a telling off from jdub  :)
<jdub> akademy was bloody huge dude
<jdub> and very long
<Riddell> yes, too long one conference would have been enough, but good fun
<Riddell> guadec misses a hacking session though which surprises me, you can't do that much in a weekend
<sivang> is everything ok with bugzilla? won't let me in....
<sivang> eh ok, cache refreshment did it.
<sladen> sivang: that  /ubunturocks  spells  ubuntu  ubutu
<sladen> sivang: might also be worth saying  ''This is what Ars said:'' as somebody has mentioned elsewhere as it could be seen as Ubuntu slagging off Debian by appearing to agree  ...which would be unlike Ubuntu
<sladen> jdub: can I patch 'passwd root'  to say:   ''I'm sorry Dave...  I can't let you do that.  It's for your own safety you know''
<jdub> :-)
<mdz> jdub: is anyone working on adding the capabilty to configure which sound device should be primary in the desktop?
<mdz> i.e., which one esd/polyp/etc. will use?
<amu> hmmm is there's something wrong with katie? 
<jdub> mdz: not atm
<mdz> sladen: is the --rsyncable stuff really that simple?
<jdub> amu: elmo said it was b0rked up a bit earlier
<mdz> sladen: I looked at the code once, and it wasn't immediately obvious what it was doing
<sladen> mdz:  uh huh
<mdz> sladen: on what did you base the 0.07% penalty estimate?
<sladen> mdz: the main bit is a counter that counts down to the next sync point and ensures and any string that is created in the output is capped at the next sync point and a new string started again
<amu> jdub: yeah i thought it was fixed a bit later, looks not ... thx
<sladen> mdz: somebody from Debian quotes somehwere that it works out as 0.7% on most packages and 1.2% on ''some of our core packages''
<sladen> mdz: on the live CD, the sync point could be set every 1MB and it'd still probably make a major difference
<mdz> sladen: hard to say, because the filesystem inside might allocate things differently from one run to the next
<mdz> what I was thinking was that it could sync every block
<sladen> mdz: I chatted to broonie earlier about what might get upstream and how to allow variable sync windows
<mdz> since it's compressing blockwise anyway
<mdz> and if we set fs block size = compression block size, and sync at every block, we should do very well
<sladen> yup.  The other thing I forgot to mention, is running touch over the whole FS to force  ctime/atime to a known value
<sladen> since those will change with each unpack/build
<mdz> hmm
<mdz> the entire inode would need to be identical for it to be a win
<mdz> size, atime, ctime, mtime, permissions and ownership...
<mdz> could be other filesystem-specific data in that block as well
<mdz> reiser at least will pack the data for tiny files in the same block with the inode
<mdz> though I don't think ext2 does anything like that
<elmo> it doesn't
<mdz> I think that's worthwhile to try, though
<mdz> having an entire filesystem with the same inode times will look a bit weird, but I don't imagine it would break anything
<mdz> elmo: did you find Riddell's bug?
<elmo> actually, there's no bug in katie, the reject message is very scary, but all accurate.. 
<jdub> elmo: calc mentioned the archive md5sums were wrong
<elmo> jdub: err, seems unlikely?
<jdub> dunno
<elmo> got any details, I don't have a client logging at home anymore
<jdub> calc: ping
<calc> jdub: pong
<calc> yea i ran apt-get update and it was failing
<calc> it works now
<calc> so not sure what changed, unless someone recently fixed it
<calc> btw anyone know how to tell a python module to install under /usr/local ?
<elmo> what's "failing", and where are your sources.list's pointing?
<calc> it was hoary universe that had bad md5sum, but it works fine now
<calc>  deb http://archive.ubuntu.com/ubuntu/ hoary universe
<calc> that one afaik
<elmo> well, please capture the error message next time - but nothing's changed on a.u.c, so I'm guessing it was a transient network thing
<elmo> bah, silly fascist hotel starts dropping NEW ports if you don't make port 80 requests every so often
<calc> ok
<elmo> night all
<calc> cool i found out why SOAPpy doesn't work for me
<calc> its too darn old and needs to be updated
<calc> 0.11.3 is in hoary and doesn't work but 0.11.6 works fine
<robertj> I'm dangerously close to building my first .deb, kinda scary really
<calc> robertj: read all the docs already? :)
<tritium> robertj, awesome :)
<robertj> calc: yeah
<robertj> ignoring most of the stuff for now though ;)
<tritium> robertj, new maintainer, I presume?  How long did the process take?
<robertj> trit: nahh, just on my own
<tritium> robertj, cool
<robertj> pre and postinst dont seem to be firing yet though
* lamont sleeps
<lamont> Kamion: let me know if there were any issues with livecd/di (other than you needing to change the name of the host you fetch from...)
<robertj> is there anything special that needs doing to get the scripts to run? Running by hand yields the expected results
<robertj> set -e
<robertj> gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules
<robertj> exit 0
<robertj> that's the extent of it, but nothing hapening unless I run them by hand for preinst and postinst
<thully_> Is there currently a recommended snapshot CD to be used for installing Hoary?
<thully> I lost my connection - but I was just wondering if anyone knows a good Ubuntu Hoary snapshot to use for installation
<bob2> Setting up debsums (2.0.13) ...
<bob2> /var/lib/dpkg/info/debsums.config:5: local: not found
* bob2 blames lamont 
<bob2> HAH
<bob2> it *is* lamont's fault
<bob2> I changed /bin/sh to be posh
<bob2> and setting it back to bash fixes it
<thully> hi - is Ubuntu going to handle the Mozilla trademark issue in the same way Debian eventually does?
<froud> hi, does ubuntu support Ipv6?
<bob2> yes
<froud> thanks
<bob2> hah, nevow is in supported
<froud> bob2, ? what
<bob2> is someone in charge of making the mono toolchain work on ubuntu atm?
<fabbione> mornign
<fabbione> lamont: ping
<bob2> lamont: is it bad if I'm getting a ton of these: postdrop: warning: mail_queue_enter: create file maildrop/173496.8172: Permission denied
<jdub> thom: ping
<bob2> lamont: I found http://lists.debian.org/debian-user/2000/12/msg03524.html, but it doesn't seem to be the problem in this case
<froud> is anyone maintaining a list of Release Notes for Hoary or knows where I can fin dinformation to compiled Release Notes?
<bob2> lamont: erk, it seems was filesystem was slightly fucked
<mdz> night
<Kosai> Hrr.  Is it safe to remove esd?
<T-None> Kamion: i'll have trouble giving you the content of /proc/cpuinfo if i'm unable to load a kernel ;)
<T-Bone> Kamion: I can give you more detailed info about ia64, i have a scratch box, and ppc64 (same), but for the G4 it's gonna be more tricky: I'm not very inclined to wipe out the install I made :P
<T-Bone> Kamion: i'll give a shot at elilo/efibootmgr package too.
<Kamion> T-Bone: you can run through the install up to the beginning of the partitioning step; that does all the hardware detection but doesn't touch the box
<T-Bone> good point, but the hotplug bug shows _after_ install
<Kamion> T-Bone: also a tarball of /proc/device-tree on the G4 might be useful, along with what you needed to put in /etc/modules by hand
<Kamion> T-Bone: even in hoary?
<T-Bone> Kamion: i wouldn't have much to report tho: it's basically hanging
<Kamion> hoary's installer uses hotplug
<Kamion> warty's does not
<T-Bone> Kamion: it doesn't happen during the install
<T-Bone> it's after rebooting
<Kamion> bizarre
* Kamion would try running the hotplug scripts with 'set -x'
<T-Bone> i see "starting hotplug..." then the cursor moves 1 1/2 screen and then it hangs
<Kamion> ok, now let's see what lamont did to debootstrap ... :)
<T-Bone> hehe
<T-Bone> Kamion: i'm off for breakfast, bbiab for more debug :)
<Kamion> mdz: Argh. How do I convince apt that packages in /var/cache/apt/archives have already been authenticated?
<daniels> Kamion: apt-ftparchive and gpg ;)
<Kamion> daniels: ... uh-huh
<Kamion> gpg with what key, exactly? one I just made up? I bet that'll be in ubuntu-keyring ;)
<T-Bone> Kamion: oh and of course, it was daily from 20050115
<ogra> hmm, daniels i got a new laptop with 1280x800 .... there seems to be no chance to convice xorg to do this res. except by specifying a modeline....
<T-Bone> must have been on crack when writing the date
<T-Bone> first bad new: I don't have /var/log/debian-installer
<Kamion> lamont: uh, why does ia64 need libunwind7*-dev* in base?
<Kamion> T-Bone: that's only there after the installation is complete
<Kamion> during installation, it's /var/log/syslog
<T-Bone> Kamion: i reiterate: there is no linux-image-* in /cdrom/pool/main/l/
<Kamion> T-Bone: good.
<Kamion> T-Bone: it's in linux-meta
<Kamion> probably restricted
<Kamion> find /cdrom -name linux\*
<T-Bone> right, my bad
<T-Bone> it's there ;)
<Kamion> I reiterate, send me /var/log/syslog :)
<Kamion> after base-installer has run and failed
<T-Bone> Kamion: 'after installation' means after a successful installation, i suppose
<Kamion> it means post-reboot after prebaseconfig has run
<T-Bone> since it hasn't... ;)
<Kamion> so it would probably have to be successful to some degree, yeah
<T-Bone> ok, i'll scratch the box again and grab the files
<Kamion> you have nc in the installer, so you can get files out
<T-Bone> netcat, yummy ;)
<Kamion> there's openssh-client-udeb too, but I don't want to exacerbate the anna problems ...
<T-Bone> heh
<daniels> Kamion: so, usefbdev on powerpc ... speak to me.
<Kamion> daniels: I don't know what the generic answer is
* T-Bone needs to recall his limited netcat-fu
<daniels> Kamion: ok.  let's see how pinging overfiend goes :)
<T-Bone> Kamion: i'll try the G5 with daily hoary too
<Kamion> daniels: try Michel Daenzer
<daniels> Kamion: good point
<Kosai> Kamion: How's the Oqo doing?  :)
<Kamion> T-Bone: yeah, will probably stand a better chance there; I think PPC970FX CPU support went in post-warty
<Kamion> Kosai: installing today's daily, seeing how the new kernel goes
<Kamion> I need support for my USB wireless thingy in order to develop on it sanely
<T-Bone> Kamion: ok. FYI it's the top end G5 model. Dual 2.5GHz watercooled
<T-Bone> (talk about a fine beast :)
<Kosai> Kamion: Cool.
<T-Bone> Kamion: before scratching the box i'll patch elilo and efibootmgr to the best of my abilities so that you can integrate it in next snapshots
<lupus_> nick lupusBE
<lupus_> crap :s sorry 
<Kamion> T-Bone: ok, send me/lamont the patches
<T-Bone> sure
<Kamion> there's a documentation fix in the d-i manual needed as well, but I'll handle that
<Kamion> brb, shuffling houses
<daniels> rburton: hey dude :)
<rburton> hi daniels 
<trukulo> Mithrandir, u there?
<Treenaks> trukulo: time for jeff_big ! :P
<trukulo> :) ok
<Mithrandir> trukulo: yes.
<trukulo> so going to seed it
<trukulo> it's the last one, isn't it?
<Treenaks> yes
<Mithrandir> blah, my bittorrent client had segfaulted. :/
<trukulo> put it again before i seed it
<Mithrandir> yeah, it's checking the files on disk now
<trukulo> ok
<Mithrandir> ok, just start seeding
<trukulo> seeding
<trukulo> it's checking
<trukulo> seeding now
<Mithrandir> yup, ETA 18-ish hours
<ajmitch> ext2resize in hoary looks like quite an old version (same as sid) - I've got a locally updated version here that is meant to work with 2.6.9+ for online resizing
<trukulo> perfect
<trukulo> last one, cool
<Mithrandir> yup, great.
* daniels stares at X.Org's drivers/ati/Imakefile.
<daniels> THIS DOES NOT MAKE SENSE
<daniels> die monolithic tree, die
<Kamion> back
<daniels> Kamion: represent
<trulux> mdz: arpund?
<trulux> around?
<T-Bone> Kamion: who's gonna handle maintainership of Ubuntu-modified ia64 package? :)
<bob2> it's cool when your ISP combines shaping of non-local traffic with an ubuntu mirror
<bob2> er, "broken ubuntu mirror"
<daniels> bob2: d'oh
* T-Bone has a working Ubuntu-branded elilo
<T-Bone> Kamion: ok, on ia64, hotplug dies on /etc/hotplug/prc.rc start
<T-Bone> Kamion: anything you want me try before wiping out the system and reinstalling from scratch?
<jdub> hrm
<jdub> the version of dovecot in warty is a bit pants
<amu> daniels: you handle dbus, right?  
<daniels> amu: yah
<T-Bone> weeee! kernel panic during boot
<amu> daniels: i need dbus-qt enabled :) could i send you a diff, or this is a problem cause qt isnt in main?  
<T-Bone> in ext3
<daniels> amu: problem 'cause qt isn't in main, but if we need to, i could do something similar to what i did for dbus-mono
<daniels> amu: how urgently do you need it?  i can do it around wednesday if you like
<mjg59> daniels: How's the crack?
<Kamion> T-Bone: usually not necessary to change Maintainer:
<Kamion> T-Bone: but, we hope, the ia64 port team ... i.e. you and others ... :)
<T-Bone> lol
<T-Bone> i can handle elilo i guess ;)
<amu> daniels: that's fine for me, even better if you do it yourself ;) i started packaging kde3.4, and i really want this the dbus things enabled   
<Kamion> T-Bone: try 'sh -x /etc/hotplug/pci.rc start'
<bob2> daniels: how was dbus-mono handled without bringing mono into main?
<Kamion> amu: Qt is in main
<Kamion> libqt3-dev | 3:3.3.3-7ubuntu1 |    hoary/main | amd64, i386, ia64, powerpc
<bob2> main = supported, right?
* T-Bone needs to document about package management in ubuntu, now that he's a maintainer :P
<daniels> mjg59: it's crackful
<T-Bone> Kamion: sure, if i can get that box to boot again i'll try :)
<Kamion> bob2: yes, everything in main's supported
<daniels> mjg59: (but it's also Sunday evening)
<sladen> amu: riddell/haggai have been busy porting stuff.  KDE 3.4 should already be in there
<daniels> bob2: separate source package
<bob2> oh, that's crack
<amu> Kamion: nice  
<daniels> Kamion: oh, it's in main these days?  nice
<daniels> bob2: yes, doubly so given it sets 'DESTDIR='
<Kamion> daniels: libqt3-dev | 3:3.2.3-4ubuntu1 |    warty/main | amd64, i386, powerpc
<daniels> which was omgwtfbbq
<Kamion> was always in main
<daniels> Kamion: yah
<daniels> Kamion: really?
<Kamion> yep
* jdub is reading old, old emails from when he first met thomarse
<daniels> heh
<daniels> jdub: was he rabbiting on about cargo bar? :)
<Kamion> due to doxygen IIRC
<amu> sladen: aeh?
<bob2> hahaha
<bob2> daniels: and scubar
<daniels> bob2: apparently they have a machine with the getaway there, and there's a *massive* line of skanky english backpackers
<bob2> oh man
<bob2> that's doubly scary since some of my friends want to go there on saturday
<bob2> mm, 308MB dist-upgrade
<amu> is there someone alive, who could restart a sbuild on kdemultimedia-amd64 , it's a blocker, it's depends are just fixed 
* Kamion hopes that's kdemultimedia/amd64 rather than a separate source package called kdemultimedia-amd64
<daniels> Kamion: at least no-one's had the stupid idea of openoffice.org-amd64; that would be a horror
<daniels> (phew!)
<daniels> amu: did you just upload to fix its build-depends, or did it depend on broken stuff that's now been fixed?
<Kamion> the auto-depwaiter often deals with the latter ...
<daniels> and the former is done automatically
<amu> daniels: it depended on broken stuff and now it is fixed, uploaded yesterday   
<daniels> amu: so the stuff it depends on has been fixed?
<amu> daniels: ack
<daniels> ok, you may need to kick lamont, else it should just be taken care of
<daniels> `kde_42-4.10ubp1_all.deb' -> `/var/apt/ubuntu/dists/warty-backports-staging/universe/binary-i386/kde_42-4.10ubp1_all.deb'
<daniels> what sort of version is that?
<daniels> what the hell?
<amu> daniels: thx, dbus-qt is scheduled?  
<daniels> _42?
<daniels> amu: wednesday, if you don't need it earlier
<amu> daniels: that's fine for me 
<amu> daniels: guess this package never got some love ;) 
<daniels> heh, not really
<daniels> it was broken for *ages*
<T-Bone> Kamion: side note. i don't think any ia64 system ships with PCMCIA (to be confirmed tho), so maybe PCMCIA isn't necessary in d-i
<Kamion> just take out pcmcia-cs-udeb then
<Kamion> it shouldn't be very important to take it out though?
<amu> daniels: hehe
<T-Bone> nah. It just asks a (imho) bogus question
<daniels> (upstream)
<Kamion> T-Bone: only in expert mode, which is itself bogus
<Kamion> we must not ship a system that requires expert mode in order to install correctly :)
<T-Bone> heh
<T-Bone> Kamion: as lamont pointed, I suspect that one of the IDE modules is killing anna. I'll investigate that later, once I'll have answered all others points in your email :)
<T-Bone> Kamion: i wonder why you need to pass the kernel boot arg to have rescue working. Selecting its udeb in the list doesn't seem to work
<Kamion> T-Bone: long story
<T-Bone> heh ok ;)
<T-Bone> huh, interesting
<T-Bone> i started in non expert mode by mistake, it's working just fine, the CDrom gets detected
<T-Bone> it just red-screen on 'error while running 'modprobe -v amd74xx''
<Kamion> T-Bone: I suppose I could db_input rescue/check in rescue mode, but I'm not sure I want to; the correct approach is to add bootloader config to have a separate rescue mode
<Kamion> that's expert mode for you
<T-Bone> Kamion: the anna issue hasn't been fixed, has it?
<mjg59> Hm. There's definitely problems with swsusp and interrupt routing after resume at the moment.
<Kamion> T-Bone: no
<mjg59> Other than that, https://www.ubuntulinux.org/wiki/HoaryPMResults looks pretty promising
<T-Bone> Kamion: then it doesn't affect my configuration
<T-Bone> i bet that's a SCSI problem
<T-Bone> i'll try on zx6000 in a while
<Kamion> T-Bone: somebody needs to build a debugging version of anna, probably with extra printf() statements to figure out where it's segfaulting, put that debugging anna in an initrd, and iterate
<Kamion> T-Bone: anna segfaulting is not a SCSI problem :-)
<T-Bone> hmm
<Kamion> something in anna or libdebian-installer is bogus, but the curious thing is why it doesn't affect Debian
<T-Bone> Kamion: it's obviously hardware-dependent though
<Kamion> or any of our other architectures
<Kamion> T-Bone: yes but the set of udebs anna wants to install might be hardware-dependent
<T-Bone> i wonder if i had that anna problem on my g4. I had so many problems I just can't recall what they were
<Kamion> unlikely
<Kamion> I've never ever seen that or heard of that on powerpc
<Kamion> you were probably just missing a chunk in discover-mac-io
<T-Bone> right
<Kamion> if anna segfaulted, you'd know about it.
<T-Bone> heh
<T-Bone> ok so i finish debugging that hotplug issue and then get the syslogs, and then reply to your mail with a nice elilo patch
<Kamion> some other ia64 people mentioned the kernel issue BTW
<Kamion> unfortunately I don't quite have the base-installer tests working on Ubuntu yet
<T-Bone> Kamion: does 'Ubuntu GNU/Linux' sounds like a good naming (I basically changed all '[Dd] ebian' strings with '[Uu] buntu')
<Keybuk> should be just "Ubuntu"
<rburton> risking the wrath of stallman?
<Mithrandir> avoiding the issue altogether
<rburton> true
<T-Bone> Keybuk: 'Ubuntu Linux' at least, no?
<Mithrandir> T-Bone: no, just Ubuntu
<Keybuk> T-Bone: no, just Ubuntu
<T-Bone> well then, so be it
<Kamion> agreed, just Ubuntu
<T-Bone> Mithrandir, Keybuk: same for the manpages, i suppose?
<Kamion> T-Bone: all the rest of d-i is branded this way
<T-Bone> Kamion: fyi, hoary iso signs itself as 'Debian Inst' in EFI
<Kamion> T-Bone: yes, bug
<Mithrandir> T-Bone: avoiding "Linux" means you don't get into the "Linux" vs "GNU/Linux" argument at all.
<T-Bone> Mithrandir: ah ok
<T-Bone> wasn't aware
<Kamion> hm, although I can't find that "Debian Inst" string
<Kamion> oh, there it is, whoops
<T-Bone> Kamion: i guess that's some mkisofs configuration
<Kamion> no, it's a mkfs.msdos parameter in debian-installer
<T-Bone> ah ok
<Kamion> T-Bone: fixed in my local tree, thanks
<T-Bone> np
<bob2> mjg59: where do all those variables ($SAVE_VBE_STATE, e.g.) get set for acpi/resume.sh?
<mjg59> bob2: /etc/default/acpi-support
<bob2> mjg59: it doesn't seem to source it
<mjg59> bob2: Uh. sleep.sh and hibernate.sh source it.
<mjg59> They source the other scripts.
<bob2> ahhh, right, sorry
<T-Bone> looks like that ext3 bug screwed my system, /etc/modules doesn't seem to be acknowledged
<T-Bone> gonna reinstall and then debug hotplug
<sladen> oooh.  SPCR ACPI table---serial port console redirection
<T-Bone> Kamion: ok my bugreport about kernel package was incomplete
<T-Bone> d-i looks for "kernel-image"
<T-Bone> hence the bug
<T-Bone> it says: "The current default kernel package is 'kernel-image'." Obviously remnant of Debian origins ;)
<Kamion> that's only a fallback
<Kamion> it shouldn't actually be a problem
<Kamion> it's not a problem on other architectures, they all default to kernel-image too; and "kernel-image" without suffix generally doesn't exist on either Debian or Ubuntu anyway
<T-Bone> true enough
<Kamion> as I say, all the information I need to debug this is in syslog. :)
<T-Bone> i'll send you the logs in a short while
<Kamion> ok, thanks
<T-Bone> heh, you'll get them :)
<Kamion> I might need to get /proc/cpuinfo from you as well actually
<Kamion> hm, I need new base-installer for PPC970FX support
<T-Bone> hopefully dpkg is statically linked. Missing libunwind7 kills apt
<T-Bone> Kamion: i'll send that as well
<T-Bone> Kamion: oh, so basically i just downloaded 650M of worthless data? :^)
<Mithrandir> T-Bone: no, dpkg is not statically linked.
<T-Bone> Mithrandir: my bad, i meant it wasn't using libunwind
<T-Bone> Kamion: i see that all kernel flavours available on the cd are smp ones. Could that be part of the problem? (I'm on a UP box)
<Kamion> T-Bone: no, you may just need to pick the kernel by hand
<Kamion> T-Bone: I was under the impression that SMP was fine on UP boxes; we can't afford space for all kernel flavours on the CD
<Kamion> so if it'll work but is maybe a bit suboptimal, we include that and don't worry about the optimal ones
<T-Bone> well iirc debian policy is the exact opposite: install up by default, right?
<Kosai> Kamion: I've seen SMP/apic problems on UP, but they're rare.  It should be fine, AFAIK.
<Kamion> mckinley's an exception because apparently itanium's really bad on mckinley boxes
<Kamion> T-Bone: nope
<Kamion> T-Bone: I'm most of the base-installer maintainer in Debian too ...
<T-Bone> Kamion: yeah i know, but it's been a while since i've last tested Debian d-i ;)
<Kamion> there isn't a consistent policy across architectures on this
<T-Bone> Kamion: i'm used to a conservative approach WRT SMP, given the numerous bugs i've experienced on hppa and ia64 SMP boxes
<T-Bone> (and recent kernels)
* T-Bone installs SMP kernel anyway
<T-Bone> ah
<Kamion> if real problems are demonstrated, we'll revisit it
<T-Bone> another bug
<T-Bone> if you do 'apt-get install linux-image-mckinley-smp', and then say 'n' to the "go further" question, you're left in an unstable state
<Kamion> but the kernels are one of the few places where CD space is arch-dependent; if we blow out ia64 with kernels, then we have to reduce arch-independent stuff
<T-Bone> apt wants you to run apt-get -f install
<Kamion> sounds about right
<Kamion> the preinst failed ...
<T-Bone> no
<T-Bone> the user answered 'no' to a given question
<T-Bone> that's not a failure
<T-Bone> imho
<T-Bone> (i'm speaking from a user PoV)
<T-Bone> it should cleanly abort the installation, and not require subsequent call to apt-get -f install or apt-get remove to be able to install any other package
<Kamion> oh sure, just nobody's figured out how to do that. :)
<T-Bone> lol
<Kamion> I can't think of an interface in dpkg to abort a package installation and leave the package cleanly uninstalled
<T-Bone> Kamion: simply silently run 'apt-get remove <package>' ?
<Kamion> can't do that within a preinst
<Kamion> dpkg is not reantrant
<Kamion> er, reentrant
<Kamion> (and besides you might not be using apt-get)
<T-Bone> yeah sure, that's the general idea i was considering
<Kamion> it basically only affects kernels; very few other packages have that initial "did you really want to install this?" question, and assume more sensibly that if you installed it then you meant to do so
<T-Bone> yeah
<bob2> 308MB dist-upgrade and not a single error
<bob2> good work dudes
<T-Bone> that usbkbd mess is a real pain :P
<Mithrandir> bob2: yeah, we rock. :)
<bob2> Unpacking replacement libwxgtk2.4-python ...
<bob2> dpkg: error processing /var/cache/apt/archives/libwxgtk2.4-python_2.4.2.6ubuntu1_i386.deb (--unpack):
<bob2>  trying to overwrite `/usr/bin/helpviewer', which is also in package wxpython2.5.3
* bob2 takes it all back!
<Riddell> sladen: amu is doing KDE ubuntu as well
<sladen> Riddell: ahhh
<Kamion> ok, I think I've fixed the base-installer tests so that they can be used for Ubuntu in future
<T-Bone> shit! That bastard didn't copied the logs when i asked to
<Kamion> mdz: I'd like to merge base-installer 1.15 from experimental to fix a couple of issues with recent powerpc machines and to allow the kernel selection tests to be used on Ubuntu. Is that OK?
<T-Bone> hmmm
<T-Bone> i wonder if the kernel on the CD has all needed driver. Panic'd on VFS unable to mount root device 'hdb3'
* T-Bone installs archive.u.c up kernel
<Kamion> sounds more like a broken initrd
<T-Bone> yup
<T-Bone> kay i have the logs, the modified elilo. Need to test hotplug pci and then will mail you
<Kamion> if the kernel on the CD didn't have that driver then you wouldn't have been able to create that partition or install to it in the first place
<Kamion> thanks
<Kamion> have to go to a concert now, later
<T-Bone> Kamion: yeah sure, i misexpressed myself ;)
<Kamion> ok
<T-Bone> heh
<T-Bone> have a nice day
<T-Bone> bummer i didn't have the initrd line in my elilo.conf.
* Keybuk declares victory against the GNOME Applets tyranny
<Keybuk> ripped the old wireless applet code and turned it into its own package
<Keybuk> muahahahahaha
<T-Bone> YAY! Getting there! The box boots
<bob2> Keybuk: it's all about netapplet now anyway
<Keybuk> bob2: yes, but netapplet depends on thom doing some work :p
<bob2> haha
<Treenaks> gm, no pitti
<lamont> Kamion: because it's a poorly named package
<lamont> Kamion: maybe it's just my memory that's faulty, but ISTR it got really mad at just libunwind7
* lamont bbia 4hours
<bob2> lamont: found the postfix problem, it's because the scripts say they need /bin/sh but actually want bash
<lamont> bob2: ah, and posh / dash doesn'
<lamont> t like it, eh?
<bob2> yeah, very much so
<bob2> it fails in quite bizarre ways
<lamont> will fix - please file a bug
<bob2> debian or ubuntu?
<lamont> (it's supposed to work with bin/sh)
<lamont> I expect debian - go ahead and file it there
<bob2> sure, thanks.
<lamont> sev serious
* lamont runs before the wife hurts him
<bob2> hehe, cya :)
<Riddell> elmo: can I try uploading a new amarok package with a fixed version number?
<ogra> elmo ?
* T-Bone waves
<Simira> any Rosetta-people here?
<HostingGeek> xorg i810 driver is broken or something
<HostingGeek> i just --purge remove EVERYTHING including xorg
<HostingGeek> and apt-get it all again and still am having the problem of the max pixel i can use is 800x600
<crimsun> HostingGeek: let's take this back to #ubuntu.
<HostingGeek> crimsun: lets unban me from #ubuntu first
<tseng> maybe you could follow some simple rules
<HostingGeek> thanks for unbanning me
<tseng> like not proclaiming to developers that their system is broken, when you have no clue
<T-Bone> HostingGeek: if you're not willing to RTFM and keep asking offtopic questions to everyone you're gonna be banned again
<Keybuk> thank god, will that kid ever learn? :-/
* Keybuk adjusts his /ignore settings
<Treenaks> oh wait
* Treenaks was wondering who you were talking about.. nm
<elmo> Riddell: yes
<elmo> ogra: ?
<ogra> my uploads seem to dissapear silently, is my key not in the ring yet ?
<ogra> elmo ^^
* T-Bone notices ubuntu use source-only uploads, good to know
<T-Bone> geez, hoary install went fine, but i can't reboot my G5: open firmware freaks out when loading the kernel :P
<Keybuk> T-Bone: yeah, it means that it doesn't matter exactly what we run or how we fuck up our own boxes
<Keybuk> just how much LaMont fucks up the buildds :p
<T-Bone> hehe
<T-Bone> can't it lead to unbuildable package uploads?
<Keybuk> yeah
<Keybuk> that's the disadvantage
* T-Bone goes off for a bit - reading some 'bande dessinee' ;)
<robertj> i'm working on my first .deb (just messing around), but I can't get the postinst and prerm to run
<robertj> running by hand produces the desired result, any suggestions?
<Keybuk> dpkg-deb -I blah...deb
<Keybuk> does that show postinst in it?
<robertj> one sec
<Keybuk> it'll be in the list at the top with control (and probably md5sums)
<robertj> no
<Keybuk> then the reason your postinst and prerm aren't being run, is because they're not actually being put in the package
<Keybuk> are you using debhelper?
<robertj> yeah
<Keybuk> and you're running dh_installdeb ?
<robertj> hrmm, no
<Keybuk> heh, that's quite a critical one
<Keybuk> it copies files from debian/ into DEBIAN/ (which dpkg-deb --build turns into control.tar.gz)
<robertj> thanks
<robertj> building now
<robertj> it's amazing the build difference between a 2.8 ghz celeron and a 1ghz duron
<robertj> (whole machine was $350 from Dell)
<robertj> I ran dh_installdeb and nothing changed after I built the package
<robertj> do I need to create DEBIAN by hand?
<Keybuk> no
<Keybuk> try running "dh_installdeb -v" by hand
<Keybuk> what does it do?
<robertj> nothing
<Keybuk> in debian/ you have a package.postinst file?
<robertj> no, I have a postinst.ex
<robertj> I guess that's probably it eh?
<robertj> rename to mypackagename.postinst?
<Keybuk> ah, rename that to <package>.postinst  (where <package> is the name of the package that should have it)
<Keybuk> yup
<robertj> btw, dh_installdeb must be automagic
<Keybuk> why?
<robertj> the files showed up without it
<tritium> I have suspend to RAM mostly working, except for wireless lan card problems
<robertj> well it's not working
<robertj> hrmm
<robertj> let me see if dh_installdeb is called from the control file
<robertj> or rules
<robertj> yeah
<robertj> rules runs dh_installdeb
<robertj>      991 bytes,    43 lines   *  postinst             #!/bin/sh
<robertj>     1023 bytes,    41 lines   *  prerm                #!/bin/sh
<Keybuk> there you go
<robertj> the scripts still aren't working though, is there a way I can run them more verbosely?
<robertj> set -e
<robertj> gtk-query-immodules-2.0 > /etc/gtk-2.0/gtk.immodules
<robertj> exit 0
<robertj> that's the entirity of the script sans blank lines and comments
<Keybuk> that's a dangerously incomplete script
<robertj> yeah, but I figured it was best to get something working first
<Keybuk> stick "set -x" in there? :)
<Keybuk> (to complete it, add something like this to the top): [ "$1" = "configure" ]  || exit 0
<robertj> I don't see why you wouldn't want it to run again
<robertj> btw +x shows that  gtk-query-immodules-2.0 gets run but doesn't mention the > /etc/gtk-2.0/gtk.immodules bit
* robertj decides to look at the postinst from another gkt input module
<Keybuk> run it again?
<robertj> yeah, all it does is check the locations in it's path and put them in the file
<robertj> err all the modules it finds there
<Keybuk> you're aware of all the situations that postinst can be run?
<robertj> guess not
<robertj> i thought only after a package was installed
<robertj> or reconfigured 
<Keybuk> no, it's also run if an upgrade to a newer version fails
<robertj> oh
<tritium> Does anybody know the difference between "platform" and "shutdown" for the hibernate_mode (caps) variable in acpi-support?
<tritium> /etc/default/acpi-support says to use "platform" if you want acpi to shutdown, which seems backwards
<robertj> Keybum: imhangul seems to run it in every case
<robertj> whee
<robertj> but now it's working
<robertj> Keybuk: thinks for your help, I have alot of reading to do
<Riddell> elmo: what is the status of my new unsermake package?
* robertj washes his cat intently clean the soup bowl beside his computer
<T-Bone> i'm not sure washing a cat is a good idea if you care about your clothes and skin ;)
* T-Bone ducks
<T-Bone> sweet, after a fresh hoary install on ppc, the default user isn't in the sudoers
<robertj> %s/washes/watches/g
<robertj> T-Bone: can't trust those mac-using tards anyway ;)
<T-Bone> lol
* robertj supports ~ 125 mac users
<robertj> does your machine count include scanners that people carry to meetings thinking they are laptops?
<T-Bone> btw, i was wondering what happens if the system falls back to single user mode at boot time... (maybe that's an already answered question tho)
<mjg59> T-Bone: Straight to root shell
<T-Bone> ?
<T-Bone> ah ok
<Keybuk> asking for a password is somewhat silly :)  given if they can type it, they can also boot with (e.g.) init=/bin/sh
<T-Bone> wow nice work my bluetooth keyboard is supported, but not my mouse, afaict
<T-Bone> Keybuk: damn true :)
<T-Bone> ah yes, the mouse came back. Bluetooth neg lag i suppose
<abelli> Kamion: ding
<trulux> doko: hey
<trulux> doko: more people interested in the meeting
<trulux> i think we need to spread the word for all Ubuntu folks
<thully> anybody know Ubuntu's position on the Mozilla trademark issues?
<mjg59> fabbione: Hm, what happened to the patch that fixed interrupt handling after swsusp?
<mjg59> fabbione: #5567 - I've attached a patch
<no0tic> hi all! what's the acer's laptop support in hoary nowadays?
<mdz> Kamion: apt doesn't authenticate packages; it doesn't even check the md5sum on packages in the cache (it's trusted)
<mdz> Kamion: base-installer merge is fine with me
<mjg59> no0tic: In what way?
<no0tic> mjg59: suspend-to-disk, suspend to ram, acpi
<mjg59> no0tic: On Hoary, you ought to get working suspend/resume
<mjg59> suspend-to-disk is currently broken, but will be fixed in the next kernel upload
<thully> mjg59: when will that be
<thully> I need suspend-to-disk, and was about to try a Hoary install
<mjg59> thully: Whenever fabbione builds it
<mjg59> Ought to be tomorrow
<no0tic> mjg59: ah, ok
<mjg59> suspend and resume will work, but if you want PCI devices to work afterwards you need to pass the pci=routeirq parameter
<mjg59> The new kernel will fix that so you don't need the parameter
<thully> (i need this because my laptop uses 10% of it's power per hour in suspend-to-ram)
<thully> however, apm suspend-to-ram works fine - weird - unfortunately speedstep doesn't work in APM :(
<no0tic> mjg59: now in warty I have to close the lid after shutdown command to actually shutdown, otherwise it reboot... it's fixed?
<mjg59> no0tic: Should be fixed
<no0tic> mjg59: I often heard that ati fglrx drivers brake in some way suspend...
<mjg59> no0tic: Yes, you may well have to use the stock ATI drivers
<no0tic> mjg59: sorry, I didn't understand.. :)
<mjg59> no0tic: the fglrx drivers don't support suspend and resume. You might be lucky and find that they work anyway, but otherwise you'll have to use x.org's radeon driver
<mjg59> sladen: Around?
<no0tic> mjg59: ok :(
<mjg59> no0tic: Give it a try, anyway. If it doesn't work, contact ATI and ask them to support suspend and resume
<no0tic> mjg59: I hope tomorrow ati's drivers release, will fix it, with the support at x.org 6.8.1
<mjg59> no0tic: I haven't heard that they've improved that, but if they have done, that'd be good
<mjg59> thully: But yeah, suspend to disk will work fine as long as you use the pci=routeirq thing
<no0tic> ok, thanks for now!
<thully> Oh, OK - I'll do that for now
<sladen> mjg59: yup
<mjg59> sladen: Know anything about apm?
<mjg59> sladen: I've been thinking that we could possibly reverse engineer the T-series apm BIOS, which would give some indication as to what it's doing on apm suspend that isn't being done on acpi suspend
<abelli> mjg59: ...
<mjg59> abelli: Mm?
<abelli> mjg59: im interested..
<abelli> mjg59: please go on...
<abelli> :)
<thully> so is there a reasonably functional hoary live CD yet?  if so, what release?  is Gnoppix the same as hoary's live CD?
<mjg59> Several Thinkpads use far too much power when in ACPI suspend, and so far we haven't been able to work out why
<mjg59> So checking to see what the BIOS does in APM ought to give some indication
<sladen> mjg59: yup.  the magic code is all in the 64Kb of SMM code.  This is outside of the normal 64GB of memory space but has to code from somewhere, so may be possible to pull it out of the BIOS image if you can get it out
<mjg59> Right, so we need a full BIOS image?
<mjg59> Did we ever work out the compression scheme IBM used?
<abelli> i think so
<sladen> mjg59: communication (same as ACPI) is normally through port 0xb1/0xb2 which aswell as taking the value given, cause SMI to be asserted  (From memory)
<mjg59> sladen: Ok. So we need to find a full T-series BIOS image.
<abelli> mjg59, sladen : i like it... how much is a Thinkpad that has the features youre working on?
<mjg59> Oh. Unless it would be in the EC firmware?
<sladen> mjg59: no, but some guy found me and was bugging me out it (yesterday of all coincidences).  flash2 is doing the ibm-specific decompression, patching in the system ID, bios version etc, producing  bios.wph  and then calling phlash16 which is the bog-standard Phoenix utility
<thully> Can I extract it from my laptop somehow?
<thully> I have a t42
<mjg59> thully: With some difficulty
<mjg59> sladen: Is this likely to be BIOS code or EC firmware code?
<abelli> mjg59: is it, the bios, in the controller, or on a separate rom?
<thully> if it involves doing anything hardware-based, I can't do it
<sladen> mjg59: x86 code, it's run on the normal CPU, 
<mjg59> abelli: That's what I'm trying to find out :)
<mjg59> sladen: IBM provide separate EC and BIOS flashes
<thully> meaning - I don't want to void my warranty and pull out some chip, etc.
<abelli> because a teacher of mine, at the university.. helped me doing the same thing on the xbox..
<thully> mjg59:  do the BIOS updates on IBM's site help you at all?
<abelli> i think he could help us
<mjg59> thully: They're compressed in an irritating format
<mjg59> sladen: Ooh. Do you think we can get the flash2 stuff to work under dosemu?
<Kamion> mdz: a current hoary install seems to refuse to install packages in the cache without turning on allowunauthenticated
<Kamion> mdz: namely laptop-detect, mdetect, xresprobe
<Kamion> abelli: pong
<abelli> Kamion: resolved thank you.
<abelli> Kamion: was about d-i.
<mdz> Kamion: that means it can't authenticate the Packages file that it guesses they came from
<T-Bone> Kamion: the default config for ppc kernel seems to lack a few things, while having worthless options enabled
<sladen> mjg59: maybe, but it's that program (flash2) that is doing the checks ''do you have a thinkpad'', ''is it the right version'', ''do you have AC and battery plugged in and the battery is fully charged''
<doko> Kamion: what is wrong with the libunwind library, anything I can test?
<Kamion> T-Bone: I'm not the kernel maintainer; please file a bug with details
<Kamion> doko: not AFAIK? I was just asking why lamont had put libunwind7-dev in base
<doko> ahh, libgcc1 depends on it.
<Kamion> lamont: if debootstrap works with libunwind7-dev removed from base, that would be far preferable, since then it will actually work when autogenerated from the seeds (it currently doesn't match what germinate says)
<Kamion> doko: on libunwind7-dev? really?
<doko> kamion: no, not the -dev.
<Kamion> ok, good
<mjg59> sladen: Yeah. I'm wondering whether there's a command-line switch to disable that stuff.
<T-Bone> Kamion: is reportbug to be used for that kind of bugs or should i use the bugzilla web interface instead?
<mjg59> Under dosemu, the checks thing returns 21
<Kamion> T-Bone: bugzilla please
<T-Bone> gah :(
<Kamion> reportbug just mails -users
<Kamion> cheesy hack until launchpad works properly :-/
<T-Bone> yummy
<lamont> Kamion: I'm happy to be found 100% wrong about libunwind7-dev
<T-Bone> i just don't like bugzilla
<Kamion> T-Bone: nor do I
<Kamion> lamont: ok, so you won't be too annoyed if I do another debootstrap upload that matches the seeds? :) I need to do one soon for authentication support
<T-Bone> heh
<T-Bone> Kamion: could you get something useful of my few mails?
<mjg59> sladen: Ok, there's no command line option. Ought to be a simple hack though, right?
<Kamion> T-Bone: I only have your initial mail plus the followup about anna/zx2000/etc.
<Kamion> if there was more it hasn't reached me
<lamont> Kamion: way cool with me.
<lamont> Kamion: and I believe that the ln -s vs sf bug is already in the debian bts
<lamont> with me as the submitter
<sladen> mjg59: there is a /batt or something which I guess tells it to ignore the battery state
<crimsun> could someone please do a simple recompile of python-ecasound in hoary (it just needs to be updated for python2.4)
<T-Bone> Kamion: i sent you a reply to the mail you sent me with attachements, and some followups about the G5 install
<Kamion> T-Bone: oops, it got caught as spam. d'oh
<thom> lamont: you were looking for me?
<Kamion> my rules are a bit overenthusiastic about killing attachments sometimes
<mjg59> sladen: it looks like the only times it prints anything on screen are when it's doing the checks, which ought to make it easy enough to drag out
<sladen> mjg59: strings on it was somewhat interesting;  I'm puzzled by updtflsh*  the bigger one (39kB) apperas to contain very similar code to flash2---and the some block of parameters to pass to phlash
* Kamion rescues the mails
<mjg59> Is the only way to print stuff in DOS to do bios interrupts?
<ogra> crimsun: i would love to, but obviously elmo hasnt given me access yet....(dunno if i miss anything required thiugh)
<lamont> thom: uh... not still looking, at any rate
<sladen> mjg59: it's the only way they're probably using.
<crimsun> ogra: aye, I understand.
<thom> oh well
<lamont> Kamion: I figured I was missing a step or 3 in my debootstrap upload... sorry about that
<T-Bone> Kamion: the G5-related mail had attachements as well (it's stated in both mails anyway)
<mjg59> sladen: uptdflsh is a menu-driven thing
<mjg59> It seems to do the same otherwise
<Kamion> T-Bone: yup, got both
<mjg59> sladen: So we find out which code prints stuff to screen and then work back from there?
<Kamion> lamont: no, it's ok, the auto-germinator bit isn't in the debootstrap source package yet :(
<Kamion> Jan 16 14:59:57 base-installer: warning: apt update failed: 127
<Kamion> that would explain why it can't find any kernels ...
<sladen> mjg59: I think int 0x15 is the BIOS video stuff.  There's also a DOS (0x21) call that many people used which I think copes with redirection, 
<Kamion> is VERY confused
<T-Bone> heh
<mjg59> sladen: Ok, there's a stack of both of them
* T-Bone bbiab, dinner time
<sladen> mjg59: other thing is just to disassemble and grep for a shortish loop (<100-200 instructions) with a right  lodsb/stosb combination.  The compression is LZ-something based (you can see the original ASCII strings in the file), so it's a copy/marker setup
<sladen> s/right/tight
<mjg59> sladen: Heh. Easier to skip the checks if possible, I think.
<sladen> mjg59: the BIOS this guy gave me yesterday was 1UET63WW 
<mjg59> I'm not really in the mood to rip out and reimplement someone's compression algorithm :)
<mjg59> What model's that from?
<sladen> mjg59: dunno
* mjg59 finds code calling IBM private interfaces and APM code
<mjg59> Ah! This is the section that shuts it down.
<sladen> mjg59: I also got a mail from the ibm-acpi guy today saying he's done a -10 with my changes in it, but he doesn't seem too keen on stick the tpb nvram stuff into the driver
<sladen> mjg59: where did you find the code?
<mjg59> sladen: I'm just doing ndisasm over flash2
<thully> This is very interesting - you're reverse engineering the IBM T-series BIOS
<thully> I hope it leads to a fix to this issue
<mjg59> thully: At the moment, I'm reverse engineering the code that decompresses the T-series BIOS
<mjg59> The BIOS itself is going to be harder :)
<thully> ah
<sladen> thully: not the first time http://www.paul.sladen.org/thinkpad-r31/x40-bios-dis.txt ; and I was trying to get LinuxBIOS on my R31 too
<Kamion> T-Gone: ah-ha! the entire kernel thing is due to libunwind7 not being there
<Kamion> apt-get: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory
<Kamion> that's what happens when base-installer tries to call apt-get update
<Kamion> so it can't find any kernels
<sladen> mjg59: if I had a copy of the same file, both compressed and uncompressed.  Do you still have that for your machine back from the minipci patching?
<T-Gone> Kamion: i suspected that yeap
<mjg59> sladen: Ought to, yes
<mjg59> Hang on...
<Kamion> T-Bone: fixing your powerpc kernel issue now by means of a merge from Debian
<T-Bone> the 'wrong kernel gets installed' one?
* T-Bone needs to learn to use libata, his home brewd kernel panics unable to open root device
<mjg59> sladen: Hrm. I have an uncompressed one, but can't find the compressed one to go with it
<mjg59> Oh, I'm looking on the wrong machine. Duh.
<Kamion> T-Bone: yes, it'll install linux-power4 now
<Kamion> (uploaded)
<T-Bone> cool
<T-Bone> Kamion: i've tested modified elilo as much as i could, it seems to behave as we'd like
<Kamion> ok, will look tomorrow, not going to be around much more this evening
<sladen> mjg59: if you have the image, can probably grep the 1UET63WW style identifer from it and find the install dis
<mjg59> sladen: http://www.codon.org.uk/~mjg59/bios/
<mjg59> I believe those are both the same BIOS
<mdz> Kamion: has apt-get update been run by that point?
<sladen> mjg59: interesting coincidence, that is the same (md5sum) one I was playing with yesterday.  
<Kamion> mdz: I think it should have been run by apt-setup, yes
<mdz> Kamion: are there .gpg files in /var/lib/apt/lists?
<mdz> those are apt's "I authenticated this" markers
<Kamion> mdz: I can check later; my test install is on the OQO and non-networked
<Kamion> I'm away from home at the moment
<mdz> ah
<mdz> oh, we have source CDs now
<mdz> ...he said as his disk filled overnight
<Kamion> :-)
<jdub> haha
<jdub> morning all!
<sivang> morning jdub 
<jdub> where's this elmo character i hear about?
<jdub> probably at church, being such a baby jesus fearing young man
* thom falls off his chair laughing
<thom> morning duder
<jdub> dude
<jdub> i had a funny night last night
<jdub> was setting up my server, testing new imap setup for pipka
<jdub> decided to try imapping on my extensive mail archives
<thom> uhuh
<jdub> and found all sorts of funny stuff
<jdub> excie :-)
<thom> old table/slug stuff?
<thom> hehe!
<thom> gods thats old school
<jdub> i think i have the first "meet you on irc" mail too
<thom> heh
<sladen> jdub: this is #gagging-for-it ?
<thom> i think all my mail from that long ago is dead
* Keybuk has a few years
<jdub> it is very weird reading old mail
<jdub> but i can't believe how much has been packed into the last four years
<Keybuk> ever tried reading old blog posts?
<jdub> some of my advogato ones would be amusing, i'm sure
<rburton> jdub: "decided to help out with the gnome 2 release. should be over shortly"
<jdub> rburton: yeah, those are funny
<jdub> rburton: garnome complaints from a young ross burton were funny too ;)
<rburton> doh
<sivang> rburton: hehe
* rburton stops reading jdub logs dated 15 apr 2000
<jdub> 15 april 2002 might be interesting though
<sivang> ehrm people, don't want to sound like a #users issue, but how do i get my gnome back running after the upgrade? :)
<sivang> (this is first time nothing I do helps)
<jdub> you have blank panels?
<sivang> none
<sivang> I have X.
<sivang> period
<sivang> :)
<sivang> oh, and gdm that fires up the gnome-session.
<jdub> what happens after this so called... "period"?
<sivang> hmmmm....nothing? :)
<sivang> I just get the X screen and that's it.
<tseng> just brown?
<sivang> tseng: now, plain X offwhite texture, like when running X without parameters or a client app.
<sivang> *no
<tseng> the checker patter thingy?
<jdub> that's bong
<tseng> nasty++
<mjg59> sladen: Are you /sure/ it writes a bios.wph file?
<sivang> tseng: exactly.
<sivang> ergghgh
<sivang> suddenly came back
<sivang> I don't get it..
<sivang> I just apt-get up/upg again, nothing was changed, startxed and it works.
<sivang> garrr
<tseng> well that pattern is patched out in gdm.conf, its supposed to set it to a slightly nicer brown
<tseng> so something is pretty well off.
<sivang> weird
<sivang> hmm, fonts are smaller....well, could have been worse..
<sivang> like all went non-bold
<thom> hurrah, my desktop has tomboy love again. life is complete
<sivang> thom: you reintalled your desktop?
* thom goes to bed
<thom> sivang: no?
<thom> sivang: just reinstalled mono
<sivang> oh
<sivang> thom: anyway, night :)
<thom> night
<sladen> mjg59: now that I've looked, I'm puzzled.  It might not be
<sladen> mjg59: I suspect .wph == win phlash
<sladen> mjg59: I'm also wondering whether ''flash over LAN'' actually means ''PXE load a floppy image and execute it''
<mjg59> sladen: I thought I'd flashed a compressed image with phlash.exe
<mjg59> On floppy, there's no room to write an uncompressed file anywhere, which makes me suspect that it's phlash that does the decompression
<sladen> mjg59: didn't you get it unpacked the previous time by using the windowsy bios-editor tools?
<sladen> mjg59: the supposed "demo" version;  however the guy yesterday claims that he used that and succesfully claimed the BIOS boot image in his vmware session (?)
<sladen> mjg59: grep 'FL' *.EXE -> PHLASH16.EXE  I think you win
<mjg59> sladen: I don't /think/ I could open the compressed ones there
<mjg59> Are old ubuntu debs available from anywhere?
<mjg59> sladen: I unpacked it last time by flashing it and making a backup copy...
<Riddell> are the buildd's down?
<azeem> elmo said something about that, yes
<azeem> dunno if that is still the case, it has been a while
* mjg59 fixes swsusp, and goes on to try to work out why it generates a load of 2
<mjg59> Hurrah. It's freeze_processes()'s fault.
<buga> Riddell: I'm also waiting for your new amarok binary packages. :)
<mjg59> Hurrah. Got it, I think.
<kent> Just a little notice. Using Hoary, if i start Program -> system tools -> ubuntu update manager.  Then press the "settings" button, i get a window called "software preferences" where it says that Hoary is officially supported. But, is this true? I mean, since its a development-version..?
<mjg59> Woo!
* mjg59 wins
* ogra applauds
<sladen> kent: I think that's saying the packages are produced by Ubuntu, rather than say 'random' mariallet archives
<sladen> mjg59: news?
<Kamion> mjg59: morgue.ubuntu.com
<Kamion> kent: sounds like the sort of thing where if it matters to the code whether it's "officially supported" or not, then it's better to have that in well before release so that we can test it
<mjg59> sladen: With a swsusp bug, not the BIOS (sadly)
<mjg59> Kamion: Ah, thanks
<mjg59> bugzilla is very, *very* slow
<Kamion> go bugzilla
<Kamion> we love you with rapturous flaming death
<sladen> ''oooh, it's Canonical-sponsored international snail racing with Wiki on the Right and Bugzilla on the left.  
* mjg59 fixes all the known swsusp issues
<mjg59> I fucking rock
<Kamion> mjg59: you can have my installer bug list if you like
<mjg59> Kamion: Only when I start being given your salary as well
<Kamion> heh
<Kamion> a fair point :-)
* T-Bone calls it a night, see ya
#ubuntu-devel 2005-01-28
<mdz> sladen: they're _racing_ snails
<Mithrandir> Kamion: why does pterm set TERM = xterm?
<thully> Hi - has anyone tried the live CD lately
<thully> It appears that the latest daily works - in fact, I'm typing from it right now
<thully> There are a few issues I've noticed, though - specific to the Live CD.
<mdz> thully: if they were not already mentioned in my email as known problems, they should be reported to Bugzilla
<thully> I
<thully> 'm not using the old alpha version
<thully> is this a more recent e-mail
<mdz> I sent an email yesterday
<thully> what's the title of said e-mail - I had to unsubscribe from ubuntu-devel for a while under a deluge of e-mail
<mdz> something something live CD something
<thully> live cd x configuration?
<thully> autoconfiguration
<mdz> that's it
<thully> OK - one of the issues I'm having was reported way back in the days of the warty CD image - and is not fixed in hoary
<thully> My ipw2200 wireless only works from live boot if I modprobe -r ipw2200;modprobe ipw2200
<thully> actually, it didn't work at all on warty
<thully> live cd
<azeem> it couldn't find the firmware on warty I think
<thully> no - it was there - it gave me some weird semaphore message
<mdz> Kamion: have you thought about using passthrough for the ask-questions-before-reboot work?
<mdz> thully: file a bug with dmesg output
<mdz> thully: component: 'linux'
<thully> Also, is there plans to simplify the boot process on the hoary live cd?  it seems very convoluted, as you practically have to go through the whole install process, just not copying any files
<mdz> in my tests, it asks 4 questions
<mdz> language, location and keyboard layout (which are essentially unavoidable)
<mdz> and then hostname
<mdz> which will be suppressed
<mdz> but honestly, things like that are not important at this point in development; this live CD only came into existence last week, and polish is not our focus yet
<thully> well, you could have a few common languages/keyboard layouts on the grub boot screen and offer a "custom" option
<mdz> you may have noticed that there is no grub boot screen
<thully> Well, so far it's better than warty's - it can have software installed on it and it works with wi-fi
<thully> there was some type of boot screen - just like the install cd
<mdz> yes, isolinux.  it doesn't provide the fancy menus and such that are possible with grub
<thully> OK
<mdz> but it boots correctly on more machines
<jdub> mdz: some of the 'convolution' feeling comes from rapidly switching progress bar action
<jdub> which is hard to avoid atm
<thully> didn't pay that much attention to what happened at boot
<thully> also, it takes a long time to boot compared to knoppix and the like
<mdz> it boots faster than the warty live CD for me
<mdz> probably your CD-ROM doesn't have DMA enabled
<mdz> the hoary live CD doesn't try to enable it if it's disabled by default, while knoppix and the like do
<jdub> mdz: can we avoid loading a bunch of the nichey udebs if the kernel modules are on the live image?
<thully> well - I have a laptop, so maybe some weird quirks are causing this
<thully> Other issues I've had include - autohinter isn't enabled by default on fonts, and configuring wi-fi in GNOME control panel doesn't work (even after ipw2200 is reloaded - I ended up invoking dhcp from command line)
<jdub> the autohinter thing isn't livecd-specific
<thully> did they turn it off by default in standard hoary?  last I checked hoary turned it on by default
<thully> warty did not
<thully> This makes all fonts look much better - so it should default to on
<mdz> hmm, ipw2200 doesn't work for me either on the live CD, now that I look
<mdz> it's because it's failing to load the firmware
<mdz> that means the firmware must be missing from the udebs
<mdz> that's why reloading it works
<mdz> Kamion: ^^^^
<thully> so, what's Ubuntu going to do about the thunderbird/firefox trademark situation?
<jdub> we've been talking to the mozilla folks
<jdub> it's an open issue
<mdz> jdub: oh, autohinter changes, is that why hoary fonts look different?
<thully> will you do what debian does, or may Ubuntu stick with "firefox/thunderbird" while Debian goes iceweasel?
<mdz> looks better on my laptop, slightly less so on my desktop
<jdub> mdz: mmm
<jdub> mdz: which fonts do you use? bitstream vera or others?
<mdz> jdub: I use whatever the defaults are
<jdub> thully: it's an open question
<thully> mdz: the hoary installer used laptop-detect and used subpixel/autohinter (both) on my laptop
<thully> I believe it would use just autohinter (no subpixel) on desktops
<mdz> jdub: I really don't have a handle on our font setup
<thully> laptop-detect with one set of settings for desktop and one for laptop would seem to be the ideal solution
<thully> for both live cd and non-live install
<jdub> mdz: fontconfig.config
<jdub> mdz: i don't think it should be autoconfiguring subpixel myself
<jdub> mdz: that's probably best left to a gnome postinst gconf defaults change, such as we do with the default panel applets
<thully> It should pick the optimal look for the hardware
<thully> I've got to go - first a quick question - how do you restart X on the live CD without causing it to shutdown?
<thully> don't bother - I figured how to test autohinter another way.
<mdz> jdub: so essentially everything in the desktop is doing client-side fonts?
<thully> bye
<jdub> mdz: yeah, totally
<jdub> mdz: that's the new world order
<mdz> jdub: is there even any point in installing the X fonts, then?
<jdub> not hugeyl
<mdz> all 20 megs of them or whatever
<jdub> yeah, that's a good point
<mdz> I suppose people might expect to be able to run xterm and such
<mdz> but surely we can trim it down a bit
<thully> Hi - just booted the liveCD again - my system really took a long time at the network configuration stages
<jdub> amu: ping
<jdub> hrm, probably a bit late
<amu> jdub: hurry up, i'm on the way to bed 
<jdub> hey hey :)
<jdub> amu: arts depends on libjack which depends on jackd - yikes!
<jdub> installing kde-core
<jdub> some of the depends are... odd
<jdub> amu: do you have a seed list for kubuntu yet?
* jdub wonders why arts package hasn't been split into backend packages
<amu> jdub: next on my todo, well those meta things are all broken :( 
<jdub> pretty wacky :)
<jdub> what packages do you recommend installing for a good kde desktop, ala kubuntu?
<amu> jdub: i spend the hole WE on the Kstuff, finally everything is uploaded
<jdub> if you have a list handy
<amu> apt-get install kde is the best of the worsest cases   
<jdub> dude, that was *insane*
<jdub> you couldn't possibly fit all that stuff on one cd ;)
<Riddell> jdub: kdelibs, kdebase, libarts1-mpeglib, juk, kdm, gwenview, kontact  off the top of my head
<amu> jdub: hehe 
<amu> jdub: the problem is not the big kde packages, the prob are the small CD's *duck* 
<jdub> the non-kde depends for 'kde' are pretty crazy though
<amu> jdub: ;) i'm sure we find a cool solution, not every k package is needed for a cool desktop     
<amu> jdub: but you're too fast for me, i'm not fulltime working on it 
<amu> jdub: but good to know, you're my betatester no.1 with 3.4
<jdub> amu: it'll be easier now that we're in UVF :)
<kent> Cant you make a dvd-version of Ubuntu, with more stuff on it than the usual cd, i mean.. if you still want to limit it to one disc?
<eruin> ?UVF
<jdub> kent: it's highly likely that there'll be a dvd image with all of supported on it, plus the normal live image
<jdub> eruin: upstream version freeze, when we stop syncing with sid
<jdub> amu: running a big install now :)
<eruin> that explains the lack of daily en-masse-updates
<eruin> ;)
<ajmitch> jdub: what's the general criteria for being naughty & breaking the freeze?
<jdub> ajmitch: for main, we only sync if there are fixes we need, or if debian's merged ours
<jdub> ajmitch: and exceptional other circumstances
<ajmitch> and universe?
<jdub> ajmitch: see the release schedule for all the freeze definitions
<jdub> universe is slightly more flexible, or has been in the pasts
<jdub> past
<ajmitch> ok
<jdub> ie. if someone's said it works and it's valuable for xyz reasons, we'll generally sync
* ajmitch is just thinking of his own packages here 
<jdub> and it doesn't have potentially obvious side-effects
<jdub> ajmitch: thought so ;)
<jdub> ajmitch: i have the suspicion that within a few releases, we'll start seeing debian uploads to sid specifically in time for UVF :)
<ajmitch> it's not like anyone else will care about them ;)
<ajmitch> oh most likely :)
<ajmitch> at least people won't be uploading semi-stable packages, just bugfixes for that time
<amu> jdub: hehehe, next time we meet, i want see you installation :) 
<jdub> amu: this is on my desktop testing box - it also has windows xp on it ;)
<ajmitch> I ought to wait a few days before doing this warty->hoary upgrade
<ajmitch> supposedly I'm moving to 256Kbps DSL soon :)
<jbailey> ajmitch: Ouch.  I've been wrestling with whether to upgrade from 3M to 5M. =)
<eruin> I was about to say you poor thing, too
<jbailey> Mostly because I then go from 384k up 768k up.
<ajmitch> I'll probably be able to get 2M by march or so
<ajmitch> still only 128k up
<ajmitch> but I'll at least be able to do a little bit of hacking by then :)
<mjg59> daniels: Sweet crack today?
<robertj> deep thought: If Debian really does time-based releases, will Ubuntu sync up somehow?
<eruin> ajmitch: you'll need more than 128up for that 2mbit down to be of any real use ;>
<ajmitch> eruin: blame the NZ government for that ;)
<eruin> mmm, nz
<eruin> reminds me of home ;)
<daniels> mjg59: hopefully, yah
<daniels> Kamion: ping
<daniels> mdz: ping
<mjg59> mdz: Working hibernate key requires us to ship an ibm-acpi modprobe.d fragment. ipw2200 should work after swsusp if you either (a) provide pci=routeirq on the kernel command line, or (b) wait for fabbione to apply the patch I sent him today
<mjg59> daniels: Rocking
<mjg59> Ass. #5576 is very irritating.
<sladen> mjg59: why is being run at that point?
<ajmitch> excellent, recent ext2online works on lvm
<mjg59> sladen: As opposed to?
<mjg59> I guess doing it in multiuser might work as well, but it has to be done before X is started
<daniels> mjg59: S12
<mjg59> Anyway, I blame thom :P
<sladen> mjg59: oh, why is vbestate being run?
<mjg59> sladen: To save the video state before X is started
<mjg59> We need something to restore after resume, and saving on suspend doesn't seem to work very well
<sivang> jdub: do you know if the plans to move menu representation to GtkUIManager are in place for 2.10 ?
<sivang> jdub: (e.g. using xml for all menu reps. instead of acutal packing calls in code etc)
<sladen> mjg59: I think I asked somebody to file a bug about that earlier today  (NTP hanging under Hoary)
<jdub> sivang: which menus?
<mjg59> daniels: In the case of DDC only providing mode names and not sync ranges, shouldn't it be possible to calculate ranges?
<sivang> jdub: I was referring to the way an app
<sivang>                specifies it's menus for the UI.
<jdub> depends on the app
<sivang> jdub: that is , I understood that there is an intent to move have apps use GtkUIManager which uses XML specs for creating menus. And Nautilus is already using it.
<jdub> you can use gtkuimanager manually too
<jdub> it's up to the author
<daniels> mjg59: i have 3 vim sessions dedicated to this very task right now
<mjg59> Rock
<daniels> mjg59: the problem is that we only decided whether or not to write the sync ranges in dexconf, which is far too late
<daniels> mjg59: so i'm moving all that over to .config.in, which can work out whether or not we got everything
<mjg59> Ah, ok
<sivang> jdub: ok, so a streamlined way to add the launchpad integration entries should not be (at least in theory) be affected by this right?
<daniels> so the 'special' logic is all there, and i'm writing crt-with-list-of-resolutions-but-no-sync-ranges logic now
<jdub> sivang: i believe libgnome(ui) may be useful here
<jdub> sivang: i recall something about adding common help items
<jdub> mjg59: know anything about that?
<sivang> jdub: and about items also?
<jdub> i'm talking about help menus
<sivang> jdub: ah ok, you have a thread link?
<jdub> thread of what?
<sivang> jdub: nm.
* daniels stares at his Radeon.
<daniels> either this monitor is a ghost monitor, or it's caching DDC
<daniels> (i have a benq lcd and a dell crt, and when the dell crt was turned off and unplugged from power, it was returning ddc results from there)
<jdub> oof, lots of crap in u-u moderation
<jdub> prepare for gibs
<sivang> jdub: what's gibs?
<tseng> sivang: ever hack someone to pieces with the crowbar in halflife?
<mjg59> daniels: I think I've seen hardware that cached stuff if there wasn't a response
<sivang> tseng: hmm, done something similar to this in HeavyMetalII 
<tseng> sivang: the little bits left over are gibs
<sivang> tseng: ah ok, thanks ;)
<daniels> mjg59: it's a good idea, so you don't have to tie up the lines waiting for ddc, but bleh
<mjg59> Bastard protocol from hell
<daniels> mjg59: i've just had an epiphany
<daniels> mjg59: you know how if we take the state from just before suspend, and restore it after resume, the rendering is totally wack?
<daniels> mjg59: and you know how dri is enabled before suspend, but not after resume?
<daniels> mjg59: ... connect the dots
<sladen> oooh, oooh.  I think it might be possible to do ppc, x86, amd64 *and* ia-64 on the same bootable ISO
<sladen> daniels: I suspect the ddc electronics are hot the whole time the VGA cable is plugged on so that you can detect it and turn it off and on ?
<daniels> sladen: well, you can detect the rpesence of a crt or otherwise, so it probably caches it for the lifetime of the connection
<fabbione> morning
<daniels> fabbione: dude, you so need to sleep in
<sladen> fabbione: morning.  ibm-acpi 0.10 is out  :-)
<fabbione> daniels: i know...
<fabbione> sladen: and the dpatch for the kernel?
<fabbione> + i have a patch for ibm-acpi from mjg59 to fix some stuff
<sladen> fabbione: no delta patch that I can see
<fabbione> sladen: give me a dpatch :-)
<sladen> fabbione: but you /know/ how much /hassle/ that is :)
* daniels looks at HostingGeek.
<HostingGeek> there is a huge bug in shorewall 2.0.13 and debian has upgraded to not only 2.0.14 but 2.0.15.1 can we see another merge
* HostingGeek looks at the exit
<HostingGeek> thx cya
<fabbione> daniels: can you gimme op access level in here please?
<fabbione> (level 10 is the minimum according to chanserv config)
<daniels> fabbione: i don't have it in #u-d
<bob2> fabbione: only thombot has it in here
<fabbione> ok
<thully> hi - can someone answer some questions on how the settings for subpixel rendering are decided?
<thully> does Ubuntu choose a different type of subpixel rendering (rgb, bgr, vertical rgb, vertical bgr) based on the configuration?
<thully> does X.org handle this any differently than XFree86?
<daniels> you're better off asking in #ubuntu, but no, we don't pick the subpixel order at present.  and the important thing isn't xfree86 vs xorg, it's the versions of fontconfig and freetype you have installed.
<fabbione> thully: these stuff is offtopic here
<thully> OK - just thought this to be a bit technical for #ubuntu
<fabbione> daniels: if i will give you an acx100 driver can you test it for me? to fix the firmware load path?
<fabbione> daniels: also.. what flavour do i need to build for you? 686?
<daniels> fabb	sure
<daniels> fabbione: k7 pls
<thully> I do know that the ubuntu-devel mailing list is for development and very technical questions - is this different?
<fabbione> daniels 
<fabbione> daniels: sure.. thanks
<fabbione> thully: a lot of people on #ubuntu has very high tech skils
<fabbione> skills even
<daniels> fabbione: cheers dude
<fabbione> this chan is very specific to development
<thully> OK - I guess I kind of thought it was like the ubuntu-devel mailing list which said it was for highly technical discussions and development
<fabbione> daniels: what package does actually ship the acx100 firmware?
<daniels> fabbione: lrm-ver-subarch
<fabbione> ok
<fabbione> daniels: just to make the first test easier.. what firmware do you load?
<fabbione> or better.. that chipset do you have?
<fabbione> the ACX111 or the pure ACX100?
<daniels> 111
<fabbione> i knew that your hardware sucks :-)
<fabbione> clearly is the most complicated one
<fabbione> ahahah
<daniels> i need TIACX111.BIN
<daniels> heh :)
<daniels> dh_install --sourcedir=debian/tmp
<daniels> cp: cannot create regular file `debian/libxdamage-dev//usr/X11R6/lib/pkgconfig/xdamage.pc': Permission denied
<daniels> ...
<daniels> ah, I see
<fabbione> daniels: it will take me a little while to build
<daniels> fabbione: sure, that's fine
<fabbione> i don't think i have k7 in ccache
<daniels> heh :)
<fabbione> well i still have my -j15 to build :-)
<fabbione> ccache+distcc = teh r0ck
<jdub> if a shared library is considered private, is it okay to put it in the same package as a normal executable?
<jdub> they don't really need to be split if that's kosher
<bob2> is it in /usr/lib/packagename/?
<daniels> (also, don't ship a .so at all)
<daniels> and yes
<jdub> it's not in /usr/lib/packagename/
<fabbione> jdub: i would do that only if 100% sure that nothing in future will use that lib
<fabbione> otherwise just split it and it's done...
<fabbione> once and forever
<fabbione> and you don't need to rethink it in 2 months from now
* fabbione hugs his THX
<fabbione> daniels: building now
<jdub> heh, morning mpt
<jdub> wondered how long it would take :)
<daniels> fabbione: cool, thanks
<jdub> mdz: can i move dbus-1 from the base to desktop?
<jdub> mdz: i have *no* idea why it's in base
<daniels> sure nothing else in base depends on it?
<jdub> 100%
<jdub> otherwise it would depend on it
<daniels> wacky
<Keybuk> if something in base depended on it, he couldn't move it
<Keybuk> germinate would be sarcastic and leave it where it was
<jdub> i want to see aforementioned sarcasm
<Keybuk> http://people.ubuntu.com/~cjwatson/germinate-hoary-output/_germinate_output ? :p
<Keybuk> ! Promoted debhelper from supported to desktop to satisfy alien
<Keybuk> that kind of thing
<mpt> jdub: And what's that supposed to imply? :-)
<jdub> mpt: that you're a sucker for punishment, and we've piqued your interest. :-)
<jdub> Keybuk: i want to see sarcasm, dude!
<Keybuk> jdub: I swear it was more sarcastic when I maintained it :p
<mpt> jdub: Something like that
<mpt> jdub: I see there's a graphical installer that needs designing ...
<mpt> (or so it says on the wiki)
<jdub> Keybuk: colin made it polite
<jdub> Keybuk: perhaps we should maintain a marvin branch
<jdub> Keybuk: "oh, sigh, these humans don't know how to satisfy alien"
<Keybuk> easy, oo-mox
<jdub> hrm, wish rince ran postfix
<fabbione> daniels: did you see that xine* bug i did assign to you?
<fabbione> daniels: do you think you can manage to fix it?
<fabbione> otherwise in fullscreen it is real crap
<daniels> fabbione: yeah, I'll do that tonight
<fabbione> daniels: acx_pci.ko, right?
<fabbione> daniels: it's on people...
<fabbione> just grab that one and be sure you don't have any symlink or firmware around
<fabbione> modprobe it 
<fabbione> and it should print some extra crap in the dmesg
<fabbione> like FABBIONE: <blabla>
<fabbione> that will tell you if it found the right file or not
<daniels> fabbione: ah cool
<daniels> hold on a sec
<daniels> was just eating, sorry
<fabbione> np
<daniels> heh
<daniels> i forgot i was back on -1
<daniels> so i've installed -2, in the meantime my wireless card has died in the arse and won't come back up
<daniels> so i'm just waiting for this xorg build to finish before i reboot
<daniels> just in dh_strip now
<fabbione> sure
<fabbione> no problem
<fabbione> just replace the driver from people before rebootinh
<fabbione> and check the dmesg
<fabbione> so you don't need to unload/load
<fabbione> but be sure that you don't have spurious firmwares around
<fabbione> brb
<daniels> yeah
<fabbione> -               sprintf(filename,"%s/TIACX111.BIN", firmware_dir); /* combined firmware */
<fabbione> +               sprintf(filename,"%s/TIACX111.BIN-%s", firmware_dir, UTS_RELEASE);
<fabbione> +               if (OK != acx_check_file(filename)) {
<fabbione> +                       acxlog(L_INIT, "FABBIONE Firmware: '%s' not found. Trying alternative firmware.\n", filename);
<fabbione> +                       sprintf(filename,"%s/TIACX111.BIN", firmware_dir); /* combined firmware */
<fabbione> +               }
<fabbione> the patch is easy
<fabbione> but basically i need to see if UTS_RELEASE is what we really need :-)
<daniels> cool :)
<fabbione> if that works i need to propagate the change to the lower firmware loader
<daniels> i'll tell you :)
<daniels> rebooting now
<fabbione> ok
<daniels> fabbione: scoooooooooooore
<daniels> fabbione: thanks mate :)
<fabbione> daniels: cool
<sivang> Morning all
<fabbione> this code is SO hugly!
<Treenaks> morning sivang
<fabbione> hi sivang 
<fabbione> hi Treenaks 
<sivang> fabbione: did you sacrafice your daily chunk of gpg keys?
<Treenaks> hi fabbione
<fabbione> sivang: ?
<Treenaks> fabbione: I tried the VIA driver from the unichrome.sf.net site (on sid, with XFree86 4.3.0)
<Treenaks> fabbione: it works fine now
<daniels> Treenaks: you know hoary has the via driver from unichrome now? :)
<Treenaks> fabbione: (though there's one patch not integrated yet.. )
<Treenaks> daniels: yeah, I read that
<sivang> fabbione: the gpg keys scarafice , surely you emember one frustrating day with the kernel? ;-)
<fabbione> Treenaks: open a wishlist bug on debian for it, but i don't promise to get it in.
<Treenaks> daniels: but my machine is running sid, and I don't like reinstalling ;)
<fabbione> sivang: ehehe
<sivang> fabbione: buena serra btw :)
<Treenaks> fabbione: I'll stick with the unofficial xserver packages I found
<fabbione> Treenaks: Branden and I are being pretty conservative at this point of the release to mess around too much with drivers and such
<fabbione> sivang: :-)
<sivang> fabbione: (I hope I said good morning in italian)
<sivang> Treenaks: morning!
<Treenaks> fabbione: yeah, I understand
<Treenaks> fabbione: that's why I'm using the unofficial deb ;)
<daniels> heh, cool :)
<daniels> xresprobe now tells you whether the display is crt, lcd/lvds, or lcd/tmds
<fabbione> sorry i am fighting with teh HUGLYNESS right now
<fabbione> daniels: that driver needs a full rewrite
<daniels> fabbione: what, via?
<fabbione> it's so much crap that it doesn't deserve to live in my kernel
<fabbione> acx100
<Treenaks> daniels: the via kernel driver (drm) is undergoing a rewrite already :)
<fabbione> they don't even know how to write C
<Treenaks> daniels: ("That's the largest function I've ever seen in a C program" - some dri coder)
<fabbione> daniels: afaics we don't ship the USB version, right?
<daniels> Treenaks: yeah, I've seen alanh going through and rewriting a whole bunch of stuff
<daniels> fabbione: oh yeah, acx, it's a horror
<daniels> fabbione: i don't think they even have the usb stuff working
<fabbione> ok
<fabbione> daniels: can you do me a favour? on 5329 can you just add a foobar comment?  i need to see if my new mail filters are working :-)
<fabbione> hey pitti
<pitti> Hi fabbione 
<pitti> hi everybody
<fabbione> pitti: gimme some bad news.. just to start the week :)
<fabbione> pitti: can you please add a simple foobar comment to 5329?
<fabbione> i need to test my spam^Wbug mail filters?
<pitti> fabbione: hmm, I don't think that I can add anything qualified to this bug
<fabbione> just foobar
<fabbione> i don't need anything useful in it
<pitti> fabbione: bad news> wait, I just opened my mailbox :-)
<fabbione> but i cannot do it myseld
<pitti> okay
<bob2> done
<fabbione> thanks
<fabbione> perfect
<pitti> fabbione: mid-air collision...
<pitti> bob2 was faster
<fabbione> pitti: bob2 did.. thanks
<pitti> elmo: can you please sync mailman?
<HostingGeek> can we have more games in ubuntu which are offical support (right channel?)
<daniels> HostingGeek: wrong channel.
<fabbione> pitti: i need to go and pick up the new passport
<fabbione> pitti: please mail me if there is any bad news
<pitti> fabbione: sure
<fabbione> i plan another upload today or tomorrow
<opi> morning
<pitti> fabbione: I ordered mine last week, but our country needs 6 weeks to create a passport :-(
<fabbione> pitti: i am waiting since november :-)
<opi> pitti: here you need 8 and a bribe ;-))
<fabbione> pitti: because i live in dk and the embassy needs permissions and papers from italy
<pitti> hmm, okay, maybe .de is not _that_ bad :-)
<pitti> fabbione: ah, right
<opi> well, shouldn't we drop passports in UE? :)
<fabbione> opi: you still need it to travel outside EU :(
<opi> fabbione: that's true
<sivang> pitti: morning !
<fabbione> later
<pitti> Hi sivang!
<Treenaks> fabbione: no, we just extend it further
<sivang> pitti: what's up? 
<bob2> hah
<fabbione> Treenaks: for .it extending = make a new one
<Treenaks> fabbione: starting with (of course) the middle-east and Africa :)
* fabbione sighs
<fabbione> i am off for real now
<sivang> pitti: if you have time today, I'd like to try close the pending g-s-t issues wrt the stock profiles we should provide.
<pitti> sivang: sure!
<sivang> pitti: cool :-)
<pitti> amu: hi!
<pitti> amu: did you already fix CAN-2004-1145 in Warty?
<mdz> jdub: wtf is it doing in base?
<mdz> jdub: (yes)
<mdz> daniels: pong
<mdz> mjg59: is the ibm-acpi modprobe.d fragment documented somewhere?
<daniels> mdz: is the only framebuffer for the livecd goign to be vga16?
<mdz> daniels: I believe it tries vesafb, and if that doesn't work, falls back to vga16
<daniels> cool
<daniels> well, I've blacklisted vga16 itmt
<daniels> (which is enough for the livecd)
<opi> btw: I've filled a ,,bug'', but it should be easy to fix, so maybe I'll mention it here
<opi> I've noticed that ubuntu-desktop don't depend on sudo, and while we use sudo for everything, shouldn't it be there?
<opi> you can apt-get remove sudo, and render some desktop parts unusable
<HostingGeek> RE: the nvu source package
<HostingGeek> i still have got to reply
<HostingGeek> when is the dead line for me to get it fixed so it can be included in universe ?
<daniels> like last week
<daniels> or two weeks ago
<HostingGeek> daniels: can we make one acception 
<HostingGeek> daniels: we are talking about nvu
<daniels> in 'exceptional circumstances', uvf can be broken.  what's so exceptional about nvu? (i don't even know what's broken, so you'll have to explain)
<HostingGeek> daniels: the nvu  sourece package i found md5sum mismatch
<HostingGeek> so people here screemed it being unsafe
<daniels> er, that pretty much can't actually happen
<daniels> since katie looks at what's in the archive, takes an md5sum of that, and then uses that for Sources.gz
<HostingGeek> daniels: well thats what happened so i think Kamion or Keybuk said the rep probbly has been hacked
<thom> daniels: it's not in our repo at all, afaik
<thom> this was a different repo
<thom> mjg59: *what* is all my fault this time? :P
<HostingGeek> daniels: i guess you don't remeber the convo here....
<daniels> thom: oh, sensible
<daniels> HostingGeek: dude, if the ubuntu repository's been cracked, we won't be fixing some random package in universe
<thom> heh
<daniels> there's sort of a more serious problem that we might want to fix
<HostingGeek> daniels: this is another rep.... which has a source package for nvu that ubuntu can use
<daniels> ... so why are you asking here?
<thom> because he wants to get it in universe
<thom> keep up
<daniels> ah, well in that case, upstream version freeze has passed
<daniels> thom: dude, i can keep up with the coherent
<daniels> thom: in any case, i8xx dri suspend/resume is on the way -- shazam
<HostingGeek> daniels: ok so we can work on making it for grumpy?!?
<daniels> HostingGeek: when the time comes
<HostingGeek> daniels: no it need a lot of work
<daniels> so do the work beforehand
* thom smites people that can't read email messages
<HostingGeek> nvu provides firefox now
<daniels> host	it what?
<HostingGeek> so can't we just make a simple build that replaces firefox
<thom> um, no
<daniels> no
<thom> that's utter, total crack
<HostingGeek> rather than do a huge code edit
<HostingGeek> me?
<daniels> yes
<HostingGeek> changing servers if anyone said anything to me resay i am missing 50% of stuff said in this channel from this server
<daniels> it's a really bad idea
<HostingGeek> why?
<HostingGeek> brb
<HostingGeek> ok back
<HostingGeek> daniels: why is it a bad idea , it better than having nvu+firefox installed and firefox
<thom> nvu should just use the installed firefox
<Treenaks> nvu should use the x-www-browser!
<HostingGeek> daniels: there is one problem with freezing now, firefox 1.1 will be out before hoary become stable and open office 2 and #ubuntu will be full of "why didn't ubuntu ship with firefox 1.1 and open office 2?"
<HostingGeek> Treenaks: thats a bigger hack than thom idea
<trukulo> Mithrandir: u awak?
<trukulo> sorry, are you awake?
<HostingGeek> thom: so many distro tried making a hack for nvu but it pritty much then a rewrite
<HostingGeek> daniels: can you give me a server that does give lag for 3 min?
<Mithrandir> trukulo: yes
* thom giggles at Treenaks belatedly
<trukulo> Mithrandir: is last video full uploaded?
<thom> HostingGeek: then until nvu is fixed to use the installed firefox i dont believe its suitable for inclusion
<Mithrandir> trukulo: yes, absolutely.
<Mithrandir> trukulo: I'm uploading at 1Mbyte/sec ATM. :)
<trukulo> Mithrandir: cool ! so i close torrent seed
<Mithrandir> great
<trukulo> and now, we have full videos uploaded :)
<Mithrandir> yup
<Mithrandir> I'm going to blog it on planet.ubuntu
<Mithrandir> but not right now, since I'm in a meeting.
<HostingGeek> thom: yes and its no where in the road map thats why it should provide firefox
<thom> no, that's totally friggin' backwards
<HostingGeek> thom: well the nvu team have no where in there road map to do this
<thom> HostingGeek: well, tell them to do so
<HostingGeek> thom: and many have tried to do this but still got no where
<thom> HostingGeek: you won't find any distros bar linspire being at all thrilled by the idea of using firefox from some random tarball
<HostingGeek> thom: ummm so many distro have requested this
<HostingGeek> thom: then merge it back to our build of firefox
<Treenaks> HostingGeek: uh... you're seeing it backwards.
<HostingGeek> Dependce problem
<Treenaks> HostingGeek: nvu should use the existing firefox. firefox should not be "patched" so NVU works with it (I ope)
<trukulo> pefect
<HostingGeek> libsdl-sound1.2 depends on linflac4
<HostingGeek> and there is no libflac4 in universe
<Treenaks> urgh.. the flac4/flac6 thing
<HostingGeek> daniels: any chance on letting in one more file
<HostingGeek> Treenaks: libflac4 should then be a dummy package
<thom> no, libsdl-sound should be rebuilt
<HostingGeek> Treenaks: a lot of games do need libsdl-sound1.2
<HostingGeek> Treenaks: RE: nvu; yes it should someone should tell that to the nvu devels but as they will not do it, and it to hard for anyone else to do as its rewrite too much, its the only way
<Treenaks> HostingGeek: you're talking to them, as a packager, aren't you?
<Treenaks> HostingGeek: so you should ask them, or write it yourself
<elmo> pitti: done
<pitti> thanks
<HostingGeek> Treenaks: so far, debian, gentoo, mandrake, suse.... have asked this of them
<Treenaks> HostingGeek: well, if you ask, ubuntu asked as well
<HostingGeek> not sure if fedora did
<Mithrandir> elmo: care to sync mailman from unstable, please?
<Treenaks> HostingGeek: the more people ask, the more likely they'll do it
<HostingGeek> Treenaks: well as i can't speel want to proof read my email
<elmo> Mithrandir: that was the 'done'
<Mithrandir> elmo: ah, ok, thanks then  :)
<Treenaks> HostingGeek: evolution has a spell checker built in.
<Treenaks> HostingGeek: and maybe you should learn to spell then?
<ogra> morning
<Treenaks> hey ogra
<ogra> hi
<HostingGeek> Treenaks: yes and it can't tell 50% of my words
<ogra> elmo: so now please tell me what am i missing to get my uploads functional....
<HostingGeek> Treenaks: and anyway my gammar
<Treenaks> HostingGeek: well, learning is a good thing
<Treenaks> HostingGeek: and if you want to do stuff for free software, you might as well learn that as well :)
<HostingGeek> heh
<elmo> ogra: one sec
<ogra> yup :)
<trukulo> hi ogra
<ogra> hi :)
<HostingGeek> hmm can i make a ubuntu-games package that depends on all the working and cool games to be included in ubuntu?
<trukulo> HostingGeek: please, don't
<HostingGeek> trukulo: ok lol
<trukulo> :)
<HostingGeek> why doesn't ubuntu offical suppport a free open source java vm? so it can ship with java preinstalled
<HostingGeek> *offically
<Treenaks> HostingGeek: because there is no free java vm that's good enough ?
<HostingGeek> Treenaks: you see thats why i need you to read my email before i send it
<HostingGeek> Treenaks: blackdown is
<Treenaks> HostingGeek: blackdown is not free
<Treenaks> http://www.debian.org/social_contract -> look at the "DFSG", read the blackdown license and compare
<HostingGeek> Treenaks: hmmm #ubuntu told me it is free
<Treenaks> HostingGeek: yes. free as in beer. not free as in freedom.
<HostingGeek> Treenaks: i remeber reading in debian news letter something about debian supporting one
<Treenaks> HostingGeek: you should really read a bit more on what "free" in "free software" means
<HostingGeek> i know what it mean
<Treenaks> apparently noyt
<Treenaks> not
<HostingGeek> but i thought he ment as freedom
<Treenaks> HostingGeek: don't think if you don't have all the facts
<HostingGeek> ok out of all the free vms now can't ubuntu ship with the best one (which one is the best one?)
<Treenaks> HostingGeek: because nobody has stepped up and implemented it?
<Treenaks> HostingGeek: in a Good way?
<HostingGeek> Treenaks: debian has i remeber reading in a news letter a few weeks ago about it
<trukulo> HostingGeek: read it again, please
<trukulo> that java vm's are not "production ready"
<HostingGeek> but something is better than nothing
<Treenaks> HostingGeek: a broken java is worse than no java at all
<azeem> I wonder whether java-package has been fixed to work with Sun's jre-1.5 final
<daniels> i always feared the development channel would become cluttered with useless crap so it would become hopeless as a development chanenl
<ogra> azeem: not yet, but we have percompiled binarys....on a community repo for 1.5
<HostingGeek> azeem: it has
<HostingGeek> Treenaks: JamVM clames to support upto java 1.2, so it 3 versions old
<azeem> yeah
<azeem> using java-package is quite easy even for non tech-savy people
<pitti> Riddell: ping
<HostingGeek> pitti: 9.2 seconds 0_0
<ogra> azeem: adding a repo is even easier :)
<HostingGeek> ogra: and having a free LGPL vm support up to 1.5 is even easier
<azeem> ogra: what are the legal implications of advertising a java repo on the wiki? If you can put the .debs up, they could just as well go into multiverse, no?
<fabbione> re
<ogra> azeem: i think this should be as possible as mplayer is :)
<azeem> ogra: eh, mplayer is GPL
<azeem> in theory, at least
<ogra> ahh, true...decss isnt....
<azeem> decss is in multiverse?
<ogra> nope
<jdub> no
<azeem> pfew, you scared me for a second
<jdub> libdvdcss is freely licensed, it's just unshippable :)
<azeem> there's a reason the blackdown .debs aren't in Debian's non-free I guess, besides 'nobody cares'
<ogra> azeem: so we ave to keep java external too i guess
<toresbe> hey, that launchpad thing
<toresbe> how do I get an account?
<lupus_> patent issues :)
<toresbe> bob2: hey :)
<ogra> toresbe: create one for the wiki, the apply everywhere i think
<bob2> toresbe: sign up on ubuntu.com
<ogra> they even
<toresbe> yay. Thanks :)
<toresbe> eek, need food first
<fabbione> mdz: you still around?
<azeem> how about you scratch methods 1, 3, 4 and 5 from the 'get Java' wiki page? Having five alternatives to choose from looks pretty confusing
<ogra> azeem: people may get upset if you simply scratch their stuff :) but i fully agree....(it is grown over time...)
<HostingGeek> what blackdown called in ubuntu
<Treenaks> ogra: it's a wiki. you shuold expect your stuff to vanish
<ogra> yup...
<bob2> HostingGeek: it's not in ubuntu, read the wiki.
<azeem> method 0 has about three or four different ways as well
* ogra would rather see gcj in main to have eclipse supported....
* azeem wonders whether somebody will invent 'Method -1', just to be on top
<ogra> hehe
<ogra> the 0 was my suggestion
<bob2> Riddell: what's with the epoch on kynaptic in it's first upload?
<azeem> OMG, who decides on those names?
<azeem> kynaptic sounds ugh
<Treenaks> azeem: it's a KDE app... the name HAS to start with a K
<ogra> like something used by a surgeon
<mvo_> azeem: has it hit the archive?
<bob2> mvo_: yes
<azeem> mvo_: is it the same codebase?
<mvo_> the backend yes
<azeem> eh, is it in the same codebase, or did they fork, I mean
<Kamion> Mithrandir: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=167629#msg8
<mvo_> there is no there currently :) we keep it compiling but there is not a lot of work on it right now 
<azeem> mvo_: IMHO, everything shared between synaptic and kynaptic should go into APT or another library on top of APT
<azeem> but I told you already :)
<mvo_> azeem: and I agreed already I think :)
<azeem> same for stuff shared with aptitude
<mvo_> azeem: +1
<azeem> mvo_: do you know whether the APT dudes support this?
<azeem> i.e. adding convenience stuff done by aptitude/synaptic into it
<mvo_> azeem: I think so, but changes need to be in small pieces. people get nervous when there package manager changes to rapidly
<azeem> yeah, sure
<HostingGeek> Treenaks: yes and it must not have its 2nd letter as a s
<HostingGeek> i got a game for ubuntu http://www.ysagoon.com/glob2/index.php/game/welcome?lang=en&frame=no someone remeber it to be included in 2 months the debs are the so are the source packages....
<bob2> HostingGeek: maybe you could do some work instead of ordering people around?
<bob2> HostingGeek: like even download it and see if the source package is actually complete and builds?
<HostingGeek> bob2: i am not ordering anyone
<HostingGeek> bob2: it is
<bob2> HostingGeek: see, you said something similar about nvu
<HostingGeek> bob2: yes the nvu package only had a hacker problem....
<bob2> HostingGeek: 'hacker problem'?
<HostingGeek> bob2: some changed the source package so it has a md5 mismatch i have emailed linex.org
<ogra> Kamion: is it ok, if i start to point people with floppy probs to #5060 ? i would like to have a place to collect the info (i'm also willing to solve it if i have a clue whats wrong but youre the bugowner)
<Kamion> ogra: sure, please ask them to dd out the contents of the floppy and put the result somewhere so that we can actually fix the bug
<Kamion> ogra: didn't you say you had some affected floppies?
<ogra> i had....but i have my floppy drive not here since mataro.....i'll get it back in some days ;)
<Treenaks> ogra: you left your floppy drive  in Matar?
<ogra> hehe
<ogra> nope...i gave the laptop with the drive away before mataro 
<Kamion> Keybuk: I did not make germinate more polite, it was like that when you gave it to me :)
<Keybuk> maybe I did then
<Kamion> mdz: yeah, planning to switch to passthrough, just haven't done any more first-stage-questions work since you implemented it :)
<trukulo> ogra: new graveman version
<ogra> trukulo: i'll look at it toay ;) thanks
<ogra> today
<Kamion> mdz: the ipw2200 firmware is in the udebs, although its name has changed
<trukulo> :) as always, you have packages for sid in my web if you wanna look at it
<ogra> trukulo: i will :)
<abelli> hi everybody
<abelli> ogra: ciao
<ogra> hi abelli
<ogra> has anybody seen this: http://www.ubuntu.org/ ?
<Kamion> ogra: yes, we knew about that when the name was originally picked
<ogra> ah, ok
<no0tic> In what daily isos differ from weekly-dvd?
<no0tic> Apart from size and number of packs..
<Kamion> the daily is a CD including only base, the standard desktop, and a few extra bits
<Kamion> the weekly DVD is, well, a DVD including all of main
<Kamion> if you say "apart from size and number of packages", then the answer is "nothing", because the differences are size and number of packages. :-)
<Kamion> the DVD will probably become an install+live image in the future
<no0tic> :)
<no0tic> there are also differences in stability?
<HostingGeek> phpbb2 package should be removed from universe
<Treenaks> HostingGeek: why?
<HostingGeek> there possible legal issue with themes right now
<Kamion> no0tic: why would there be?
<Treenaks> HostingGeek: so just replace the theme
<no0tic> Kamion: I don't know :), thank anyway!
<Kamion> no0tic: you may see bugs in one that you don't see in the other simply because the weekly DVD is only generated weekly and therefore doesn't have more recent changes
<Kamion> I wouldn't characterise that as a difference in stability though
<ogra> heh, someone reported a bug about reportbug not working.... with reportbug ...lol
<no0tic> Kamion: thanks again
<no0tic> :)
<HostingGeek> Treenaks: the defualt theme subSilver is under GPL and there are to many themes based on it that have changed the license from GPL to a non-free license this could mean 1000s of people can be sued so untill subsilver changed its license to LGPL or BSD it should be removed
<Treenaks> HostingGeek: that's not a problem for phpbb-- if phpbb is GPL
<Treenaks> HostingGeek: the copyright holders of subsilver should start sending mail to the infringers
<HostingGeek> Treenaks: oops your right
<trukulo> Treenaks: do you want a blade?
<Treenaks> trukulo: blade?
<mjg59> mdz: I'm keen on shipping the appropriate fragment
<ogra> Treenaks: one end of a sword ;)
<trukulo> Treenaks: for your veins
<mjg59> mdz: But the current ibm-acpi that we ship has broken module parameter parsing
<trukulo> ogra: umm, i think then i mean a razor
<Treenaks> trukulo: I'm not suicidal, thanks
<Treenaks> not yet, at least
<ogra> heh
<fabbione> mjg59: i have your patch applied for -9
<fabbione> patches even
<fabbione> i forgot that i need to go to the dentist
<fabbione> i will upload later today
<mjg59> fabbione: Have you applied the swsusp fix from Bugzilla?
<fabbione> yes
<mjg59> Rock
<fabbione> mjg59: can you take a look at -8 and see if any of the acpi patches need to be either updated or dropped?
<fabbione> i keep forwarding some stuff you gave me for 2.6.9 but didn't get any update from you
<fabbione> just to be sure i didn't miss anything
* thom beats mjg59 with the "test uses a single = for string equality tests" stick
<Treenaks> that's one specialized stick...
<thom> it's large and spikey
<Treenaks> and rusty?
<mjg59> fabbione: I don't think there's anything I sent you that needs to be dropped yet
<mjg59> thom: Oops
<fabbione> mjg59: cool
<thom> mjg59: only 11 instances in acpi-support ;-)
<Keybuk> it's amazing how many people get that one wrong
* Keybuk blames GNU test for supporting it
<Keybuk> actually, I think GNU test doesn't and bash does?
<Treenaks> it should output a warning, like perl does
<Keybuk> descent scott% /usr/bin/test "foo" == "bar"
<Keybuk> /usr/bin/test: ==: binary operator expected
<thom> it's bash, yes
<Keybuk> bash is the First Evil.
<Treenaks> Keybuk: tied with zsh
<mjg59> bash supports it
<Keybuk> Treenaks: yeah, but zsh doesn't even *claim* POSIX compliance
<mjg59> And all the acpi-support stuff is /bin/bash 
<Kamion> does it need to be /bin/bash for any other reasons?
<mjg59> Kamion: Nope
<Keybuk> mjg59: gah, you're worse than Colin "I want to write essential things in Perl" Watson
<mjg59> Haha
<thom> mjg59: ... except the bits that aren't :-)
* Keybuk wonders why dpkg doesn't pre-depend on bash
<mjg59> thom: Pff. All the affected ones are.
<azeem> packages from contrib are not getting automatically built for multiverse, right?
<seb128> elmo: drivel sync please
<Treenaks> seb128: any reason why evolution isn't built with --enable-plugins=all (instead of just --enable-plugins, which means --enable-plugins=base)?
<seb128> Treenaks: gni ?
<seb128> Treenaks: you could at least look on the build before asking, --enable-plugins means all
<seb128> http://people.ubuntu.com/~lamont/buildLogs/e/evolution/2.1.3.2-0ubuntu1/evolution_2.1.3.2-0ubuntu1_20050113-1353-i386-successful
<seb128> 	Plugins:	  yes (all)
<mvo_> Mithrandir: update-notifier with upgrade-hook support is uploaded
<ogra> hmm, ubuntulinux.org seems down
<seb128> mvo_: have you get the new backtrace for the update-notifier crash ?
<mvo_> seb128: yes
<mvo_> thanks
<seb128> mvo_: any idea on the bug ?
<seb128> np
<seb128> let me know if I should add debugging stuff in the code or something
<mvo_> seb128: can you reproduce it? 
<seb128> no
<seb128> it happens sometime that's all
<seb128> no clue on how to force it ...
<thom> ogra: looks ok here
<mvo_> same for me. I added even more saveguards and I implemented a "destroy" callback so that when the panel is restarted, update-notifier kills itself and comes up clean again
<ogra> thom: hmm, strange....maybe a routing prob of my provider...everything else works....
<ogra> hmm....10  vlan202.rsm-r-1.lon2.mnet.net.uk (62.140.218.35)  75.205 ms  76.512 ms  78.205 ms
<ogra> 11  * * *
<Treenaks> seb128: hm... it does not mean all when I build from source... I'll look again
<ogra> btw...even windows ships traceroute by default....
<seb128> Treenaks: sure, the package doesn't build from sources
<ogra> should really be in main for failure tracking
<seb128> :p
<thom> ogra: we ship mtr by default, *shrug*
<ogra> ho, ok.....(so i'm to "old school") *g*
<seb128> Treenaks: why not using the package ?
<Kamion> base: * iputils-tracepath  # more secure sort of traceroute, will put compatibility symblink in for traceroute users
<Kamion> maybe the symlink got forgotten about
<ogra> yup, looks like
<Treenaks> seb128: nevermind
<Kamion> supported: * traceroute             # we have iputils-tracepath in base, this is only for real traceroute lovers
<seb128> Treenaks: let me know if there is something to fix in the package so it can be fixed for everybody ...
* ogra thinks he should read more of the docs :)
<thom> hey jeff! welcome to the madhouse :-)
<Kamion> jbailey: welcome :-)
<jbailey> thom: Thanks. =)
<jbailey> Kamion: Heya, thanks. =)
<seb128> hey jbailey !!
<jbailey> M. sb! =)
<mvo_> hi jbailey! welcome :)
<jordi> jeeeeff :)
<jbailey> 'lo mvo. =)  Jordi!
<Treenaks> seb128: well.. I was trying to figure out why the new-mail-notify plugin isn't included in the binary (while it is available in the source)..
<seb128> Treenaks: warning: dbus-glib-1 was not found, new-mail-notify plugin will not be built.
<seb128> that's it
<seb128> (search "inotify" in the build log :p)
<Treenaks> seb128: shall I file a bug on that missing build-dep? :)
<seb128> if you want
<Treenaks> OK
<seb128> I'll probably fix it today but still useful to have a reminder
<seb128> Treenaks: thanks for noticing
<Treenaks> seb128: #5587
<seb128> ok
<Treenaks> seb128: I noticed because I'm jhbuilding my own stuff on suse here -- and the list of plugins was different
<seb128> is there other differences ?
<Treenaks> well, audio-inline, but that's in the bug report as well
<Treenaks> but otherwise it "feels" mostly the same now :)
<seb128> this one need gstreamer yep
<pitti> sivang: I'm back, btw
<pitti> sivang: trouble with my net connection
<pitti> seb128_: sivang wants to work on g-s-t a bit
<pitti> seb128_: since I want to teach him some patch'n'package, would you mind if I upload the next version?
<seb128_> pitti: ?
<pitti> seb128_: profile support needs to be tweaked a bit
<pitti> seb128_: he shall prepare the package under my supervision and if everything works, you or me would upload it
<seb128_> pitti: feel free to upload and change whatever you want, I've nothing like "that *MY* package" :p
<pitti> seb128_: would that be fine for you?
<thom> seb128_: so we can't call you marillat? damn.
<seb128_> ah ah
<pitti> seb128_: it's gnome, and if it breaks, the folks will blame YOU :-))
* thom runs away
<seb128_> pitti: I'll get back to you in this case, don't worry :)
<fabbione> Mithrandir: ping
<fabbione> Kamion: i think that the problem on booting on that powermac7,3 is as benh said a "ppc64 kernel problem"
<Kamion> fabbione: the reporter says that it works on Debian now, and Debian does not use ppc64
<Kamion> therefore I'm simply asking if we're up to date on patches
<fabbione> yes but i am uptodated with ppc patches
<Kamion> if so, the bug can be closed
<fabbione> yeah but i wonder why it doesn...
<Kamion> it hasn't been reported on recent hoary, it was a warty report
<Kamion> warty was definitely out of date with regard to some required patches
<amu> someone could review hotplug fix? http://amu.debian.net/tmp/hotplug.diff
<fabbione> Kamion: ok... i will close it
<fabbione> is anybody working on OOo?
<fabbione> i need to do a port upload....
<amu> fabbione: haggai i guess ;)  
<fabbione> amu: i mean.. right now to do an ubuntu upload :-)
<robertj> sweetness
<robertj> Tor Lillquest got hired by NDS to hack on win32 stuff
<robertj> dbus porting then evolution
<haggai> fabbione: no I'm working on oo2
<fabbione> haggai: ok.
<fabbione> haggai: i only need to fix a MANIFEST file.. so it shouldn't be too complicate :-)
<robertj> haggai: is that the official abbreviation ;)
<haggai> fabbione: ah, k.  I dropped those for ver 2 because I rewrote the packaging scripts to use the upstream maintained filelists
<haggai> robertj: I don't think there is an official one
<robertj> I need to check out the win32 builds again
<robertj> last time I checked database had just gone in
* Kamion wonders exactly what amu's hotplug fix is fixing
<Kamion> none of that should be needed with a POSIX shell
<fabbione> mjg59: 5591 :-)
<mjg59> fabbione: His DSDT is fucked
<fabbione> mjg59: do you want to explain that to him? ;)
<mjg59> Keybuk: Can you take a look at the video options in /etc/default/acpi-support, switch them all off and then try swsusp again?
<sladen> fabbione: already have
<Keybuk> I tried them all
<mjg59> Keybuk: And still the crash on vt switch?
<Keybuk> yeah
<mjg59> Wow. Your machine is less functional than the craptop.
<Keybuk> it *looks* like it's X.org bailing out
<mjg59> Does it work if you suspend from the console?
<Keybuk> your scripts don't even suspend if I do it from the console
<Keybuk> they tear down dhcp, and then don't do anything else
<mjg59> Make very sure that you're using the acpi-support from horay and not my one
<Keybuk> I am, 0.13
<mjg59> thom: Can we shift the vbesave script to the beginning of multiuser?
<thom> certainly
<thom> ... why? :-)
<mjg59> thom: That way, when it breaks someone's computer, we can get them to boot in single user mode...
<thom> ah, true
* Keybuk smiles at fabbione
<fabbione> Keybuk: ?
<Keybuk> oh, just running apache through hct
<fabbione> ah cool
<Keybuk> have been for half an hour or so now
* Keybuk watches the progress log messages scroll past
<ogra> does anybody know how long a typical "elmo second" is ?
<ogra> he said "wait a sec" ......
<Keybuk> ogra: about two to three centuries, why?
<smurfix> ogra: There is no such thing IME
<ogra> ....four hours ago
<smurfix> ogra: he didn't say he'd be done afterwards, now did he?
<ogra> smurfix: nope :)
<Keybuk> I appear to have lied when I said it imports ok though, because the version in hoary tickles a little bug that I just fixed
<ogra> Keybuk: because i have a bunch of universe packages that need rebuild and would like to upload then
<ogra> them
<Keybuk> I always feel happier about code once I've found and fixed some bugs in it
<fabbione> it was rejected...
<fabbione> ops
<Keybuk> fotfl ... apache--suexec-of-death--1.3.33
<Keybuk> you know there's a bunch of patches in here that don't apply?
<thom> the apache* packages have some wonderful patch names
<fabbione> all of them do
<Keybuk> 010_dbm_part_2_the_revenge
<fabbione> if applied in proper order
<Keybuk> ah, you see, we can't represent that in Arch
<fabbione> DOH!
<Keybuk> we can represent patch 2 depends on patch 1 which depends on base
<Keybuk> all the way up to arbitrary patch N
<Keybuk> what we can't represent is patch 3 depends on patch 2 and patch 1, but patch 2 *does not* depend on patch 1
<Keybuk> because that would require branches with multiple parents
<Keybuk> and lifeless goes interesting colours if you say things like that
<elmo> giggle
<fabbione> happyness
<Keybuk> debian/patches/ssl/004_eapi.patch.patch/pkg.eapi/eapi.patch
<fabbione> ok.. skip apache 
<Keybuk> meh, why is there a patch whose whole purpose in life is to add another patch to the tree? :p
<fabbione> if arch can't handle i will
<fabbione> becasue it is required? ;)
<Keybuk> couldn't you just, oh, I don't know, put the patch in the tree, instead of patching it into the tree? <g>
* Keybuk awards fabbione and the Apache maintainers the "Martin Pitt Award" for strange source-package practices
<elmo> Keybuk: dude, can I ask for a couple of packages?
<Keybuk> elmo: if you like
<robertj> anyone know how the A05 Bios does these days?
<fabbione> elmo: i think my OOo upload was lost... at least no emails back
<sivang> Keybuk: Martin Pitt award? Does he have strange practices for source packages? :-) How strange?
<Keybuk> WARNING:Inventory.1.Inventory.11:Couldn't inspect 'debian/scripts/fix.source.patch'
<Keybuk> I'm going to guess that's not really a patch file :p
<robertj> I guess I'll find out
<elmo> fabbione: someone finally made me deal with sparc, so jennifer's cron job is disabled ATM ;-)
<elmo> ogra: and sorry, I got sidetracked by some other stuff, I will try and do it RSN.. well basically once the archive comes back
<Keybuk> sivang: just twisted, things patching things that don't deserve to be
<elmo> Keybuk: one of them is binutils tho - is that too big?
<fabbione> elmo: AHAHA COOL!
<Keybuk> elmo: I thought binutils was relatively tiny?
<ogra> elmo: great, thanks....ever thought about a secretary ? ;)
* thom is resisting asking for firefox
<thom> since there's no way the cvs import will happen in my lifetime
<Keybuk> thom: well, that applies to Apache too
<Keybuk> but I can never resist the opportunity to laugh at a Modernist source package
<elmo> Keybuk: hmm, 86Mb unpacked source... the CVS tree is, err... interesting, it has a daily auto-commit, which I suspect fucks with someone's head, but I don't know if HCT cares
<thom> i should check if they're importing cvs or svn
<elmo> and it's had public CVS for like 7-8 years too
<Keybuk> elmo: heh, HCT won't care ... importd might explode into little pieces
<elmo> ogra: I asked for one the other day, but was DENIED
<Keybuk> size for HCT is number of tarballs multiplied by number of patches
<ogra> elmo: bah.....
<ogra> elmo: i would vote for getting you one :)
<elmo> Keybuk: okay, I have 17 patches, but only one tar ball
<elmo> and they're very simple patches, no ordering to them
<Keybuk> WARNING:Inventory.69.Inventory.70:Couldn't inspect 'patches/apply_demangler'
<Keybuk> *snigger* ... that's not a patch, eh? :p
<sivang> does anybody mind if I ask who/what is HCT?
<sivang> :)
<mjg59> fabbione: Did you say you'd uploaded -9?
<Keybuk> sivang: weren't you awake the morning I demo'd it?
<ogra> Keybuk: the BOF where everybody was asleep ?
<sivang> Keybuk: I don't think so, was in on the first/second week?
<Keybuk> second week
* ogra hides behind some serious furniture
<sivang> Keybuk: wasn't there on second week :-/
<Keybuk> ah, is basically a tool for managing source packages in tla/baz/bzr
<sivang> Keybuk: bzr = ?
<lamont> seb128: is it safe to dist-upgrade this morning?
<Keybuk> sivang: bazaar
<seb128> lamont: should be, yep
<lamont> 332 upgraded, 17 newly installed, 4 to remove and 0 not upgraded.
<lamont> hrm
<sivang> Keybuk: and baz is like the web frontned?
<Kamion> $ type -p baz
<Kamion> /usr/bin/baz
<Kamion> lamont: any idea what's taking ubuntu-meta so long to build on i386/ia64?
<lamont> sivang: baz is a replacement for tla, hct makes baz do the right thing.
<lamont> Kamion: checking
<elmo> hmm, fabbione you made jennifer cry
<elmo> ogra: okay, first of all - what email did you ask me to whitelist?
<fabbione> elmo: why?
<elmo> I think I asked you when you weren't around, and then you replied when I wasn't around
<ogra> hostmaster@grawert.net
<jordi> fabbione must have a big one!
<elmo> fabbione: dunno, your oo.o is ERROR.. checking now whic
<fabbione> AH
<lamont> elmo.  floe. not. happy.
<elmo> err, not happy how?
* lamont goes to the other room
<lamont> email
<fabbione> elmo: i did the usual upload procedure.. are you sure it didn't fail on the gpg check? (since i used the new key and so on)
<ogra> elmo: i sent it to upload@ubuntulinux.org (hostmaster@grawert.net)
<elmo> ah
<elmo> fabbione: nah, it was err, PEBKAC
<elmo> I broke it with the MOTU changes
<sivang> Keybuk: so tla must have hct to do the right thing? s/tla/baz. so hct is a backend?
<ogra> elmo: ahh, ok
<thom> hct is a specialised frontend
<elmo> hmm, who was the other MOTU/universe uploader who got approved recently?
<ogra> Riddel
<ogra> +l
<elmo> yep, got him, and haggai and smurfix (tho the latter two are full maintainers)
<Kamion> sivang: you're taking too much from Keybuk's "right thing" - tla/baz work on their own, but hct is a wrapper around them to make the system easier/saner to use for package management
<sivang> Kamion: ok, thanks for your clarifications. 
<ogra> elmo: i think i'm the only one sticking with universe for the start...even riddell will get access to main tomorrow (i wanna practise a bit before breaking main ;))
<elmo> ogra: okay, whitelisted.  next question, what did you upload?
<ogra> elmo: i tried nicotine 
<elmo> ogra: that got rejected because you didn't make the distribution 'hoary'
<ogra> elmo: just a dependency change to python2.4 shouldnt break anything
<elmo> ogra: you've seen the wiki page on uploads, right?
<ogra> ah, ok...
<ogra> yup
<elmo> ok
<Kamion> lamont: #4940> hm, interesting ... does it work for you too?
<ogra> anything i missed ?
<elmo> ogra: in the changelog, you need to say 'hoary' not 'unstable'
<elmo> gnupg (1.4.0-1) unstable; urgency=low
<ogra> elmo: yup, understood
<elmo>                    ^--- thereish
<fabbione> elmo: do you want me to upload again or will you fix it manually?
<fabbione> elmo: both works for me
<elmo> fabbione: oo.o?  no, don't worry, ERROR stuff doesn't get rejected, it just hate mails me and stays in queue/unchecked
<elmo> ogra: okay, try reuploading then..
<fabbione> elmo: ok
<ogra> elmo: done :)
<robertj> has there been any more talk about whether mono can/will go into base if f-spot & beagle catch on?
<Keybuk> s/base/desktop/ :)
<robertj> err yeah
<Kamion> well, jdub asked for mono to be taken back out of desktop until beagle was there ...
<sladen> fabbione: what hotplug/usb is likely to be different between a stock kernel.org kernel and the Ubuntu patchset.  Somebody here has decided to roll his own k.org one and is wondering why nothing automounts
<robertj> Kamion: is there an ETA on beagle 1.0?
<thom> it's not even a case of 1.0, just sufficiently supportable
<tseng> alot of mono sutff lags behind upstream by alot in debian proper, unfortunately
<robertj> I'm just got this fear that it will remain Linux's most envied theoretical study of data indexing
<tseng> not least mono itself
<fabbione> sladen: i don't follow you...... what do you mean?
* fabbione claps his hands to ogra for his first Ubuntu upload
<ogra> YEAH !
<ogra> finally
<fabbione> Accepted nicotine 1.0.8rc1-1.1 (source)
* sivang congretulates ogra for his first upload.
<fabbione> :)
<Keybuk> that just begs for a niquitin-cq upload :p
<Kamion> robertj: I have no idea
<ogra> sivang: you will be next, wont you ?
<Keybuk> Provides: nicotine
<thom> heh
<sivang> ogra:I hope so ;-)
<Keybuk> Depends: will-power
<Keybuk> Suggests: advice-from-your-gp
<ogra> Keybuk: nicotine-cq ?
<sivang> -gp ?
<Keybuk> ogra: niquitin-cq is a popular brand of quit-smoking nicotine patch things in the UK
<ogra> lol
<lamont> Kamion: 4940,etc - fixing the ubuntu-meta meta-problem, then I'll lookl
<Kamion> sivang: abbreviation for "General Practitioner", i.e. doctor who treats general problems in their own practice rather than working in a hospital
<Kamion> lamont: fundamental buildd problem?
<sivang> Kamion: I'm always in for some more english abbrivations knowlegede :-)
<Kamion> ogra: you don't need to say NMU for Ubuntu uploads by the way; we don't really have such a thing
<Kamion> ogra: erk, you uploaded -1.1 to Ubuntu based on a Debian -1?
<ogra> Kamion: i suspected that, but wanted my frst one without lintian warnings ;)
<Kamion> that's a bogus lintian warning for Ubuntu
<ogra> now i know ....
<Kamion> ogra: Ubuntu uploads like that should be -1ubuntu1
<ogra> even universe ? 
<Kamion> ogra: otherwise if somebody uploads -1.1 to Debian then they'll clash
<Kamion> ogra: yes
<ogra> i thought this suffix was for main only
<Kamion> it's a function of where the changes are made rather than of whether the package is supported
<Kamion> nah, it's a version namespacing thing
<ogra> ok...i'll make it -1ubuntu1 then :)
<Kamion> too late now, but you'll know for the next package
<ogra> hmm isnt -1ubuntu1 > 1.1 ?
<Kamion> $ dpkg --compare-versions 1.0.8rc1-1.1 lt 1.0.8rc1-1ubuntu1; echo $?
<Kamion> 1
<Kamion> no, it's not
<ogra> ah, ok, i see
<Kamion> that's the reason we settled on that version numbering scheme: it means that Debian uploads always jump past ours in version numbers
* Kamion goes off to explain that in wiki/Uploads
<Keybuk> '.' > [a-z]  in dpkg terms
<ogra> hmm, and on sync from sid the packages go in 1:1 ? (i.e. i had to change from unstable to hoary) 
<Keybuk> it doesn't use ASCII, remember
<ogra> Keybuk: trying to keep that in mind :)
<ogra> hmm .... so MOTU has to touch _all_ 15000 packages to become hoary ?
<zul> fabbione: is the kernel team wiki page up yet?
<fabbione> zul: no sorry. i have been really busy
<fabbione> zul: max tomorrow it will be up
<zul> fabbione: ok no probs
<Kamion> ogra: no, if local changes haven't been made to them in Ubuntu then they will be synced automatically
<Kamion> it's only merges that you lot have to take care of
<fabbione> and talking about kernel.. let's upload -9 with another 3 bug fixed
<ogra> ah, i already was doubting the system....
<lamont> Kamion: not so fundamental as thurough. :-(
<lamont> Kamion: I didn't break it, but then I didn't fix it completely like I said I would either.
<Keybuk> heh, pitti shut down his box
* Keybuk wonders whether he should tell pitti about the half-a-dozen or so remote exploits in dircproxy ...
<Keybuk> naaaaaah
<ogra> heh
<thom> i blame the original developer
<Keybuk> thom: as do I
<lamont> Kamion: I expect it's the scsi vs ide issue...
<Kamion> lamont: that messes with my head
<Keybuk> I fear our Security Team lead using unmaintained software
<lamont> Kamion: if I _must_, I can reboot the local mirror/squid/web/whatever proxy to verify that things work on my ide i2k.
<lamont> the zx2000 is scsi, iirc.
<Kamion> lamont: nah, don't worry
<lamont> Kamion: k
<lamont> brb
<Keybuk> thom: the best ones are Keybuk forgetting to escape \n when writing log files, so you can insert arbitrary lines into the log which dircproxy doesn't expect and exploit them when the client connects :p
<seb128> elmo: drivel and planner sync please
<elmo> seb128: done
<seb128> thanks
<jordi> mvo_: ping2!
<thom> Keybuk: heh!
<mvo_> jordi: pong
<Keybuk> I'm actually quite amazed it's stood up this long though, you'd think given it's prevelance it would be subject to massive attack by now
<jordi> mvo_: hmm, I merged ca.po I sent with synaptic.pot, and I got a zillion things to update.
<jordi> hadn't you merged the files already?
<mvo_> jordi: I didn't commited a "make update-po" yet I guess
<jordi> mvo_: included in the fuzzy strings, there are some that contain tabs. It is recommended not to do that if possible.
<elmo> Keybuk: dude, why is it in debian?
<jordi> mvo_: aha. well, I'm updating.
<jordi> msgid "\t%s %s but %s is to be installed"
<jordi> stuff like this needs a translator comment to explain what the phrase might look like
<Keybuk> elmo: *shrug* I don't care about it anymore, and I don't know how to write l33t exploits to find out whether the silly bugs were actually exploitable
<Keybuk> I don't even remember what most of them are anymore, it's been that long since I touched it
<Keybuk> so it would be a "remove foo, because I wrote it when I was a kid and couldn't code worth a monkey" :p
<thom> how much is a monkey worth </curious>
<mvo_> jordi: most of them should have one already, let me check
<Keybuk> thom: 500, you should know that
<thom> ah
<thom> uh, holy crap map.search.ch is cool
<jordi> mvo_: I don't see them
<Treenaks> thom: HOLY CRAP
<mvo_> jordi: you got me ... this particular code-path has no translator comments :(
<Treenaks> thom: coolness
<Riddell> bob2: there was a previous upload of kynaptic (that didn't compile) using a different number scheme
<Keybuk> oh, one of the really silly bugs is that dircproxy holds proxied dcc files in memory -- so if you can send a really big file fast enough, their OOM killer takes out most of their machine :p
<mvo_> jordi: I'll have a look next
<mvo_> jordi: just leave them out for now
<thom> keybuk: swwwweeeet!
<jordi> mvo_: okie
<chrisa> Keybuk: This program sounds amazing
<robertj> whee
<haggai> elmo: is there some sort of limit on the upload queue?  I keep getting disconnected while uploading the OOo2 tarball
* lamont pokes Mithrandir about libsdl1.2/amd64
<robertj> power management is happy on my laptop at last
<lamont> Mithrandir: and linux86
<elmo> haggai: what are you using to upload?
<haggai> elmo: I started off using dput and now I tried with lftp
<elmo> hmm, are you uploading just the .tar.gz or the .dsc and .diff.gz too?
<haggai> well, trying all of them
<haggai> dput uploaded the dsc and then the tar.gz
<haggai> with lftp I had the .diff first, then the .dsc and then the .tar
<jordi> mvo_: #: gtk/window_find.glade.h:9
<jordi> msgid "Origion"
* lamont hangs his head in shame, uploads mcs 1.0.4-1 to universe
<lamont> thom: hope you're happy, now. :-)
<mvo_> jordi: thanks! I ran make update-po and commited, can you please update?
<elmo> haggai: hmm, this may be a (bad) bug in poppy
<elmo> please try just the orig.tar.gz
<thom> lamont: cool
<haggai> elmo: ok
<lamont> thom: I feel so dirty, though.
<lamont> elmo: they made me do it.
<lamont> do we have a bz for universe yet?
<lamont> hrm.. actually, I could just file this one against debian.
<elmo> do what?
<lamont> elmo: upload mcs to universe
<lamont> it's ftbfs
<lamont> see also the whole discussion about mcs moving back to universe, etc.
<lamont> heh.  already filed.  #290234
<Kamion> fabbione: um, what's happened to the Packages file in your archive?
<fabbione> Kamion: i removed them because i am fixing the signs on the changes and upload to jackass
<fabbione> elmo did his big black magic
<fabbione> :-)
<Kamion> ah
<fabbione> Kamion: if you want i can regenerate them.. but i already uploaded and removed one package
<Kamion> it's ok, I'll figure out how not to disappear them from debootstrap
<fabbione> ops.. hold on...
<fabbione> i will remake them in a sec
<fabbione> it doesn't take more than an ssh ;)
<haggai> elmo: it restarted again :(
<fabbione> 45% of .changes are (re)signed
<fabbione> Kamion: done
<Kamion> thanks
<Kamion> let me know when it's in the archive proper and I can start using that :)
<fabbione> Kamion: it will take sometime before it's in the archive....
<elmo> haggai: gar
<elmo> haggai: is there somewhere I can download this to test myself?
<haggai> elmo: I'm just uploading to a machine with a better net connection
<elmo> there's definitely no upload limits, which I guess means zope's ftpd is timing you out or something.. or your end is timing out
<fabbione> elmo: 51% ;)
<jordi> msgid "The following problems where found on your system:"
<jordi> mvo_: that too
<mvo_> jordi: this one is the header of a new generic message box that is popt up when apt complains about problems. it usually is a error that a server is not reachable or that a packages list file is missing. it can also contain errors that happend during installing (like when a packages tries to override a file owned by another one). I found hard to find a good generic header for this dialog
<Kamion> mvo_: "were" is misspelt as "where"
<mvo_> Kamion: ups :) thanks
<mvo_> jordi: fixed
<pitti> lamont: here?
<lamont> pitti: yo
<pitti> lamont: http://people.ubuntu.com/~pitti/langpack/
<pitti> lamont: the complete set is now there
<pitti> lamont: that means
<pitti> TIME FOR THE STRIPTEASE
<lamont> lol
<pitti> lamont: so can you enable pkgstriptranslations on the buildds now?
* lamont will finish packaging the latest sbuild and roll 12 buildd's thn
<lamont> then
<pitti> cool, thanks!
<lamont> wanna make mdz say 'go'
<lamont> ?
<lamont> or just do it?
<lamont> brb 
<pitti> mdz: please say "go"
<mdz_> pitti: your mum
<pitti> fake_mdz, aka elmo: why my mum?
<elmo> hmm, you clearly didn't get enough jdub exposure in mataro
<pitti> elmo: well, at least I did not understand all of his jokes
<pitti> lamont: nah, that's okay. mdz already said to me "say go whenever you feel like" :-)
<Kamion> is atmel-firmware too proprietary for restricted?
<lamont> pitti: is your stuff bound for the archive?
<pitti> lamont: "bound"?
<Kamion> its licence basically seems to be "only distribute in object code format as .h or binary image" + standard BSD conditions + no endorsement
<Kamion> which I thought was ok for restricted
<lamont> pitti: due to be uploaded/been uploaded
<pitti> lamont: It shall be on people.ubuntu.com for a while for testing
<pitti> lamont: I think I will upload it in a week or so
<lamont> ok.  If I snatch it and we use it, then your upload has to be a higher version...
<pitti> lamont: no problem, I will regenerated it from scratch anyway
<pitti> lamont: (to get up-to-date base packages)
<pitti> lamont: s/regenerate from scratch/update/ , probably
<lamont> ok
<lamont> btw, arch-all, yes?
<elmo> btw, anyone used dar, or any of the other newish (i.e. not amanda era) backup programs?
<Kamion> elmo: can you regenerate the Task: ubuntu-desktop headers please?
<Kamion> they need to include dbus-1 now ...
<trukulo> Kamion, i use atmel project from berlios, that is gpl
<pitti> lamont: yes, Arch: all
<elmo> Kamion: more urgently than the daily cron job?
<Kamion> trukulo: link? (note this is for an end-user friend, not for myself; and nevertheless my question still stands)
<lamont> pitti: _which_ package do I want from that pile?
<sabdfl> Kamion: is the db-h dirname for open deb bugs standard?
<Kamion> elmo: oh, couldn't remember if that's daily or not
<sabdfl> what's the equivalent for the archive?
<trukulo> kamion: http://at76c503a.berlios.de/
<Kamion> trukulo: that's USB, the card in question is PCI
<elmo> Kamion: yeah, 'tis
<elmo> tho I still need to update germinate. meh.
<pitti> lamont: I write the announcement mail now
<lamont> pitti: let me rephrase that - which package do I need to install in the chroots, etc.
<Kamion> sabdfl: db-h and archive are what debbugs CVS has
<sabdfl> ok thanks Kamion
<pitti> lamont: not the language packs
<trukulo> Kamion, ah, ok
<pitti> lamont: pkgstriptranslations only
<Kamion> sabdfl: I'm not sure I'd call it standard given that I think Debian's the only project to export its debbugs spool by rsync :-)
<lamont> pitti: that's what I thought you were pointing me at... :-)
<pitti> lamont: pkgstriptranslations is already in main
<lamont> pkgstriptranslations is current in the archive?
<pitti> lamont: no, sorry
<pitti> lamont: that was just to show that the language packs are now ready
<sabdfl> Kamion: best kind of standard there is ;-)
<Kamion> trukulo: (er, cardbus, that is)
<pitti> lamont: yes, pkgstriptranslations is already in main
<lamont> ok
<trukulo> Kamion, so, don't know, my wireless is usb
<lamont> Kamion: next pass at debootstrap, could you add pkgstriptranslations to hoary.buildd?
<Kamion> lamont: sure
<trukulo> and it's _very_ bad
<lamont> thanks
<pitti> lamont: the conffile got a bit bigger, but still the only necessary change should be to actually enable it
<pitti> lamont: however, you can also change the tarball suffix if you want
* pitti gets his asbesto pants now, since he is going to break the buildds
<sabdfl> in python, how do I print a '.' without a newline? to create that "i'm doing something still" effect?
<lamont> file.write(".")
<sabdfl> lamont: thanks
<lamont> where file might be sys.__stdout__... :-)
<Kamion> sabdfl: or 'print ".",'
<Kamion> (with the trailing comma)
<sabdfl> Kamion: cool, thanks
<Kamion> I don't know what the buffering implications are though
<lamont> Kamion: I like your's better.. :-)  mine always felt wrong somehow.
<lamont> probably the same buffering issues, I expect.
<Kamion> hm, damnit, 'print ".",' still leaves a trailing space
<Treenaks> I saw the solution in the nutshell book
<Treenaks> *looking*
<Kamion> looks like sys.stdout.write(".") is easier after all, silly python
<Treenaks> Kamion: the comma trick should not print a space
<Treenaks> Kamion: according to this book
<elmo> doesn't here?
<Kamion> Treenaks: try it twice
<Kamion> Treenaks: also see http://docs.python.org/ref/print.html
<Kamion> "A space is written before each object is (converted and) written, unless the output system believes it is positioned at the beginning of a line."
<Treenaks> Kamion: so the write-option is the best..
<Treenaks> hmm
<pitti> mdz: here?
* sladen uses   sys.stdout.write(...)
<elmo> Kamion: boggle, that's bad crack
<Kamion> s'pose it's totally unchangeable now because a billion programs rely on it
<haggai> elmo: finally,it's up: http://www.credativ.com/~cha/openoffice.org2_1.9.66.orig.tar.gz
<fabbione> that looks scary
<fabbione> elmo: less than 90 .changes left for signing :-)
<T-Bone> hey fabbione!
<fabbione> hey T-Bone 
<lamont> fabbione: how soon do we package 2.6.11-rc*?
<fabbione> lamont: we won't i am afraid... UVF
<T-Bone> fabbione: so, did you find bitchslapping me was productive? :^)
<lamont> fabbione: doh
<fabbione> only if there is a big request for it
* fabbione spanks T-Bone  a bit more
<T-Bone> lol
<fabbione> lamont: well i already backported a lot of bugfixes from -bk
<lamont> <lamont> patofiero: I've only tried on 2.6.8 - will try 2.6.10 this week
<lamont> <willy> lamont: nono, try 2.6.11-rc1, it's all hoopy & froody & stuff.
<lamont> * willy nods emphatically
<lamont> teehee
<fabbione> willy lies :P
<fabbione> get 2.6.10 up first
<fabbione> and we will see if something else needs to be backported
<fabbione> i heard some rumors about some good stuff going in
<fabbione> if it's worth we will grab it
<fabbione> i am kinda afraid to push 2.6.11-rc as is because some arches still have to catch up on some major changes
<lamont> fabbione: I think he was being a shade parisc-centric
<fabbione> eheh
<fabbione> he still has to fix those I/O problems on f11
<fabbione> that's the only reason why i didn
<fabbione> 't build the kernels myself
<T-Bone> heh
<fabbione> Kamion: can i kill the Packages files on people?
* lamont tries to remember if today's a holiday or not.
<thom> lamont: i think mako said it was
<T-Bone> if so, i wasn't aware ;)
<lamont> T-Bone: us holiday
<lamont> some dead civil rights leader or something
<mako> lamont: dude, totally
<T-Bone> huh
<lamont> mako: my kids have school today
<fabbione> elmo: ready to get 4GB of transfer?
<mako> lamont: today is MLK jr day
<lamont> but the banks are closed
<mako> lamont: if your kids went to school at a federal bank, they wouldn't have
<lamont> mako: the rest of the district has the school off...
<mako> lamont: maybe the principle is anti-mlk
<mako> several states refused to celebrate mlk day at all until the 90s
<mako> "celebrate" meaning we don't work
<lamont> mako: conservative school in colorado - they just plain don't like them thar liberals
<mako> in any case, i forgot too so i'm gonna take off another day this week
<lamont> mako: too much to do today, I think I'll pretend it's tuesday
* mako will too
<haggai> mako: did you get my mail re MOTU?
<elmo> fabbione: sure
<fabbione> elmo: i am going to upload "less" for testing
<fabbione> and than i will flood jackass
<elmo> haggai: nice link credative have there
<fabbione> just to be 1000% sure that the .changes are correct
<fabbione> elmo: do you want to stop cron while i am flushing the 4G and run manually?
<elmo> nah
<fabbione> i am not sure we can process that much data in 5 minutes
<mako> haggai: probably.. i have only 104 more canonical mails in my inbox to get through :)
<haggai> elmo: was that sarcastic? (I've no idea how fast it is)
<haggai> mako: ah :)
<fabbione> elmo: less is up
<elmo> haggai: I was getting 3Mb/s at one point - I suspect if both ends had the right tcp windows settings it could sane that and/or do better
<elmo> s/sane/sustain/
* fabbione waits for an email
<haggai> elmo: uh, wow
<elmo> still, doesn't quite compare to the 42Mb/s I got transferring it on the LAN ;-)
<elmo> haggai: okay, it works locally.. so I'm guessing it didn't like the 30min+transfer for some reason.  sucks.
<haggai> elmo: oh, odd
<fabbione> elmo: less_382-2_sparc.changes ACCEPTED
<fabbione> i am flooding now
<haggai> elmo: so is the file in the upload directory now?
<fabbione> on the way :-)
<elmo> haggai: yeah - do you want to transfer everything but the orig.tar.gz?
<haggai> elmo: will do, cheers
<elmo> as a work around, I suggest you upload from that www.creadtiv box, if you can
<elmo> for 100MB +orig.tar.gz's anyway
* fabbione -> food
<haggai> ok.  I think I'll actually create the file remotely and just download it to my box in future, like I do for the main version
<elmo> oh christ
<elmo> I bet fabbione's doing all 4Gb in one upload.. this'll be an interesting test of poppy
<T-Bone> heh
* thom waits for the nagios messages from jackass falling over
<Riddell> elmo: any idea why my kynaptic -0ubuntu2 package hasn't been built?
<elmo> Riddell: checked the build logs?
<elmo> drwxr-sr-x    2 poppy    poppy      253952 Jan 17 19:41 upload-000295
<elmo> go sparc, it's your freaking b'day
<Riddell> elmo: there's no build log for it, but there is an accepted message on hoary-changes
<elmo> okay, it's dep-wait on unsermake
<Riddell> elmo: -0ubuntu1 wrongly had a build-dep on unsermake so I uploaded -0ubuntu2 which removed that build-dep
<elmo> which I'll go process if jackass survives fabbione-assualt
<elmo> Riddell: ah, okay, our buildds can't handle that; I'll give it back in that case
<Mithrandir> lamont: sorry, I've been away today; had a meeting in Oslo.
<lamont> Mithrandir: np
<Mithrandir> lamont: libsdl1.2, linux86 and what was the last one?
* lamont goes looking
* lamont kicks evo-data-server 0ubuntu6
<seb128> what ?
<seb128> lamont: there is a 0ubuntu7
<seb128> lamont: built everywhere
* ajmitch watches his hoary upgrade break into several pieces
<fabbione> elmo: it's all in
<fabbione> 4108001884 bytes transferred in 886 seconds (4.42M/s)                          
<fabbione> Total 7599 files transferred
<kent> ajmitch, its not adviced to upgrade now, or?
<elmo> fabbione: yep, it'[s processing now
<elmo> oh crap
<elmo> you killedit
<lamont> seb128: yeah
<fabbione> elmo: i am getting the emails
<lamont> sorry -fast fingers
* lamont hates perl
<ajmitch> kent: dunno, I'm putting the pieces back together now :)
<fabbione> elmo: i am so damn excited :-)
<T-Bone> lamont: how much? ;)
<kent> ajmitch, i upgraded right now, and didn't have so much to install. I didn't get any problems, perhaps if i reboot..
<ajmitch> kent: well I'm doing a warty->hoary upgrade
<kent> ajmitch, oh.. that might get you in trouble initially..  I have run hoary some time now, 
<Kamion> fabbione: go ahead and kill that Packages file
<ajmitch> kent: nothing that can't be easily fixed, I'm sure
<kent> btw,  beep media player have not worked for a long time. it seg faults..  but since its in Universe, perhaps you dont mind?
<lamont> T-Bone: don't ask.
<T-Bone> lamont: heh. I bet that's not enough ;^)
* ajmitch will bbl
* Kamion goes to training, back in 1.5 hours or so
<fabbione> Kamion: i did a while ago :-)
<fabbione> Kamion: i think pretty soon you will be able to use the archive
<Kamion> good
<fabbione> i am getting mails from d*
<Mithrandir> fabbione: sparc?
<fabbione> Mithrandir: yeps
<haggai> elmo: please can you allow openoffice2 in?
<haggai> openoffice.org2, I mean
<fabbione> i think we lost debian-installer...
<Mithrandir> fabbione: rock! :)
<fabbione> none of the versions have been accepted
<Mithrandir> (about sparc, not d-i)
<fabbione> Mithrandir: <fabbione> elmo: i am so damn excited :-)
<fabbione> Mithrandir: that was d-i for sparc :-)
<fabbione> i think the easiest way to spot if something is wrong will be to compare the 2 package files from what is in the dc and what is at home
<fabbione> i think either my spam filter is skipping
<fabbione> anyway the packages are all there
<fabbione> elmo: sorry.. one question: debian-installer_20041227ubuntu5
<fabbione> i didn't get any email that has been processed.. did i lost it or is it still in the queue?
<fabbione> just to be sure i don't start to be anal on missing emails
<elmo> debian-installer is BYHAND
<fabbione> ah ok
<elmo> neither maintainer nor buildd get mail about that till it's processed
<fabbione> so i will never see an ACCEPT
<elmo> you will when I process it
<fabbione> roger
<elmo> and I just fixed the REJECT fd leak, so the rest should go through now
<fabbione> i am getting email from g*
<fabbione> processed more than 30 minutes ago :-)
<Mithrandir> elmo: what's the easiest way to get old packages out of the morgue?
<elmo> Mithrandir: morgue.ubuntu.com ?
<elmo> it needs an index, but other than that..
<lamont> fabbione: Use of uninitialized value in pattern match (m//) at /usr/share/kernel-wedge/commands/gen-control line 161.
<lamont> ??
<Mithrandir> great, thanks.
<fabbione> lamont: kernel-wedge - harmless
<lamont> kewlnews
<elmo> Mithrandir: it's on rookery if you want find(1)/locate(1) ability
<lamont> s/ws/ss/
<fabbione> ARGH
<fabbione> openoffice.org failed on i386!
<fabbione> and i did change MANIFEST.sparc?
* lamont notices -9, cries.
<fabbione> lamont: no.. no need to
<lamont> my aching bandwidth-straw
<fabbione> you can build with -8
<fabbione> there are no config changes
<lamont> yeah - but it's gonna take the poor mirror another week or two to catch up again
<lamont> esp if oo.o is heading down the pipe at it
<fabbione> lamont: exclude linux-source for now
<fabbione> i will tell you when enable it again
* Mithrandir tries the patch in a debian bug report for fixing libsdl1.2
<lamont> fabbione: it's not so trivial...
<lamont> since excluding it will cause me to morgue-ify all the existing copies as well.. :-(
<fabbione> lamont: god.. downloading 12Mb of buildlog is the pain
<lamont> feh - that's nothging in light of the 233 MB burp that you cause me in linux-source
<lamont> (and that's just i386/ia64)
<lamont> and source
<fabbione> ERROR: Error 65280 occurred while making /build/buildd/openoffice.org-1.1.3/connectivity/source/drivers/evoab1.5
<fabbione> AHHHH
<fabbione> of course the error is sooooo clear!
* elmo locks haggai in a room and hands fabbione the key
<fabbione> NOTICE.. i did only change debian/MANIFEST.sparc
<lamont> hex(65280)
<lamont> '0xff00'
* fabbione offers a couple of beers to elmo to get THAT key
<fabbione> haggai: ?
<fabbione> lamont: meh.. what does that mean?
<elmo> ARGH
<elmo> why is figlet non-free?
<elmo> I so need to MEGA-FIGLET-OF-DEATH lamont right now
<fabbione>  _   _    _    ____  ____    _    ___ _ 
<fabbione> | | | |  / \  / ___|/ ___|  / \  |_ _| |
<fabbione> | |_| | / _ \| |  _| |  _  / _ \  | || |
<fabbione> |  _  |/ ___ \ |_| | |_| |/ ___ \ | ||_|
<fabbione> |_| |_/_/   \_\____|\____/_/   \_\___(_)
<fabbione> 
<Mithrandir> because of some font shit or something and the debian maintainer was silly and uploaded the new version to non-free rather than just keeping the old, free version in main.
<jordi> doh
<lamont> fabbione: does it put it's output somewhere other than stdout?  (kernel, that is)
<fabbione> Mithrandir: do you have any idea of what could have caused that error in OOo?
<fabbione> lamont: nope..
<fabbione> standard build
<Mithrandir> fabbione: sorry, I'm not drunk enough yet.
<fabbione> if you want to see all the gcc normal compilation stuff you need to define VERBOSE=1 or something like that
<fabbione> it's in the top Makefile
<fabbione>   KBUILD_VERBOSE = 0
<fabbione> this one
<Mithrandir> they're using kbuild?
<fabbione> Mithrandir: no no.. that's the kernel
<fabbione> <lamont> fabbione: does it put it's output somewhere other than stdout? 
<Mithrandir> fabbione: ah, ok.
<fabbione> lamont: can you just try to give back ooo on i386?
<fabbione> lamont: i really don't see why it should fail
<fabbione> either some build-dep are fucked
<fabbione> because i didn't touch anything
<fabbione> but "you touched last" rule is still valid... i guess
<pitti> lamont: I did not catch mdz up to now; if you do, can you please ask him about the stripping?
<lamont> pitti: will do - I expect he's actually taking the US holiday today, instead of tomorrow like some of us... :-)
<pitti> oh, ok
<Mithrandir> lamont: did you find out what other package was problematic?
<pitti> see you, guys
<lamont> Mithrandir: no
<lamont> Mithrandir: libglademm2.0, libsdl1.2, linux86
<lamont> are the 3 possibly amd64-specific failures I have now
<Mithrandir> ah, it was the first one, then.
<Mithrandir> libsdl1.2 was just uploaded.
<jordi> mvo_: another
<jordi> "Prefer package versions from the selected distribution when upgrading "
<jordi> "packages. If you manually force a verison from a different distribution, the "
<jordi> "verison"
<mvo_> jordi: thanks
<mvo_> jordi: fixed in r1478
<jordi> getting nitpicky:
<jordi> "Reload the package information to become informed about new, removed or "
<jordi> "upgraded  software packages."
<jordi> extra space :)
<seb128> Mithrandir: is #3029 still true ? I've it assigned to me but no idea on the issue in fact ...
<Mithrandir> seb128: it's my bug, it's my glorious hack which solves that one
<mvo_> jordi: thanks, fixed (also I shouldn't encourage your nitpicking ;)
<seb128> Mithrandir: ok, so just take it, thanks :)
<jordi> mvo_: you can't avoid that :)
<jordi> mvo_: wait before I report all the missing full stops at the end of some long warnings and notice dialogs :)
<ajmitch> hey jordi  
<jordi> hi andrew!
<mvo_> jordi: aggg ... glad that I haven't announced a string-freeze yet :)
<jordi> hehe
<Mithrandir> mvo_: what's the status of IUH?
<jordi> msgid "%s: %s but it is not going to be installed"
<mvo_> Mithrandir: basic stuff ready and uploaded
<jordi> ok, so what was I supossed to do with these?
<Mithrandir> mvo_: ok, coolie.  I'll go ahead and hack at U8MT, then
<mvo_> Mithrandir: no i18n support yet (but not too hard to do)
<mvo_> Mithrandir: play a bit with it, see the example on the wiki
<Mithrandir> ok, but I don't i18n yet, so that's not a problem.  (Yet. :)
<mvo_> jordi: haven't had time yet to look, was dragged away
<jordi> ok
<jordi> that's the only thing I'm missing.
<jordi> mvo_: is there no upstream changelog for synaptic?
<mvo_> jordi: the changelog of the svn is the best we have
<jordi> mvo_: urgh
<jordi> food time
<mvo_> jordi: what are you looking for exactly? 
<mvo_> I may be able to help you :)
<jordi> mvo_: just having a look :)
<jordi> NEWS was interesting enough
<fabbione> jackass is slowing down :-)
<fabbione> 1 hour delay on the emails
<mjg59> fabbione: You missed one of hte bugzilla patches
<thom> weedy load average though
<mdz> pitti: here now
<mjg59> fabbione: 5548
<fabbione> mjg59: i was just reading on #ubuntu
<fabbione> i missed the patch.. no problem.. it will be in -10
<mdz> pitti, lamont: if this is regarding confirmation to enable .mo stripping in the archive, if pitti is ready then I am ready
<mvo_> jordi: I'm looking over the strings now
<mjg59> fabbione: Thanks!
<fabbione> mjg59: no problem.. sorry again, but i started from the bottom of the list and after a few hours i stopped
<mjg59> Haha
<mjg59> No problem
<fabbione> and i rather keep going for upload small changes / upload often
<mdz> jbailey: around?
<fabbione> than 20938298392839823 fixes and one upload
<mjg59> Is jbailey one of you guys now?
<fabbione> he has been assimilated
<jbailey> mdz: Yup
<mjg59> mdz: Can I chat to you about power management integration quickly?
<mdz> mjg59: sure
<mdz> elmo: wanted to talk about translation stripping?
<mjg59> mdz: Ideally, we'd have a package that provided a consistent interface for suspending to different states
<mdz> mjg59: yes, thom and I talked about this a bit
<lamont> svgalib is like totally universe now, right?
<mdz> jbailey: welcome officially :-)
<mdz> lamont: totally dude
<lamont> jbailey: yeah - welcome abored
<mjg59> This would also be a good place to add hooks like the initrd/dsdt stuff
<lamont> aboard, even
<jbailey> mdz: Thanks, Matt. =)
<lamont> mdz: then I guess I should really fix lirc.
<Mithrandir> lamont: ok, linux86, libglademm2.0, libsdl1.2 all fixed.
<jbailey> lamont: Duuude. ;)
<lamont> Mithrandir: rock!~
<mjg59> mdz: So can we add something to main that does this? That way it makes it easier to hook in the UI stuff
<lamont> dh_install -s --sourcedir=debian/tmp --list-missing
<lamont> cp: cannot stat `debian/tmp/usr/bin/smode2': No such file or directory
<lamont> how do I tell dh_install that smode2 is optional?
<lamont> I suppose I could just terminate it with prejudice, but that seems kinda mean.. :-)
<Mithrandir> lamont: currently, you can use a wildcard, but that's going to go away once joeyh fixes said bug. :)
<lamont> I fixed it by removing the package that shouldn't be there anyway
<mdz> lamont: what about lirc?
<mdz> lamont: oh, does it build-dep on svgalib?
<mdz> lamont: fwiw, the easiest way would probably be to add an extra dh_install invocation and do it on the command line
* Mithrandir hugs elmo
<lamont> mdz: only on i386. :-(
<lamont> lirc-svga package kissed goodbye.
<lamont> since smode2 was the only thing in it...
<ajmitch> hmm, need another CONFIG option turned on in the kernel for selinux to work properly
<fabbione> ajmitch: ?
<ajmitch> fabbione: CONFIG_AUDIT, otherwise you don't get any messages
<ajmitch> want me to file a bug now?
<seb128> lamont: do you know why gnome-doc-utils is not in the build logs ?
<fabbione> ajmitch: hold on
<lamont> seb128: short answer: yes.\
<lamont> let me go find it.
<lamont> seb128: it's  d-w libxml2-dev (>= 2.6.12)
<lamont> and only success logs are there for the past little bit... I'll do a massive giveback sometime soon to catch all the failures.
<fabbione> ajmitch: what is the reason of having such option enabled?
<lamont> bad gaim
<lamont> seb128: missing build-dep on libcamel1.2-dev, somehow.
<seb128> lamont: hum ok. In fact libxml2 is probably stucked in a NEW somewhere, a binary package has changed its name
<lamont> that could do it
<seb128> lamont: ok, fixing gaim now
<ajmitch> fabbione: selinux uses the auditing framework to report avc messages now, iirc
<ajmitch> same problem has been seen in sid
<fabbione> ajmitch: and why these avc messages are important?
<fabbione> sid, but what arch?
<ajmitch> fabbione: avc messages are all the security messages that selinux reports
<ajmitch> last I checked (2.6.9) it was sid, all arches
<ajmitch> since selinux was only enabled by default in that version
<fabbione> ajmitch: i will think abou tit
<ajmitch> ok
<fabbione> i am off
<fabbione> cya tomorrow
<ajmitch> bye
<ogra> ciao fabbione
<crimsun> ogra: thanks for nicotine :-)
<ogra> :)
<mvo_> jordi: translator examples are added to r1480
<ogra> crimsun: fits perfectly for a first upload for me (i'm Mr. smoketomuch) ...
<crimsun> ogra: ;-)
<ogra> crimsun: ecsound is also done...
<ogra> crimsun: eca even
<Nafallo> still no new mozilla-thunderbird-enigmail package :-P...
<crimsun> ogra: excellent!
<ogra> :)
* ogra is currently looking at nautilus-media....but it looks quite bad....
<ogra> seb128: will this survive gnome 2.10 ? there seems to be no replacement for nautilus-view.h in libnautilus-extensinon 
<jordi> mvo_: thanks
<seb128> ogra: define "this" 
<seb128> oh, nautilus-media
<ogra> seb128: look a line above ;)
<seb128> dunno, there is no real point to keep it
<ogra> seb128: thats what i thought....
<seb128> totem has most of the features
<ogra> seb128: audio preview works without n-m right ?
<seb128> "preview" ?
<ogra> pre-listen
<seb128> oh, right, that's a nautilus' feature
<ogra> so we should drop it from universe, since it has no use anymore and wont work.....
<seb128> "we" ?
<seb128> I don't drop any package, feel free to do it :p
<ogra> <- MOTU
<ogra> i will :)
<seb128> ogra: https://bugzilla.ubuntu.com/show_bug.cgi?id=3837, comment #2/#3
<ogra> seb128: wow, thanks :)
<seb128> np
<Riddell> elmo: amarok 1.2beta3 seems to be in hoary but I can't see a build log
<jordi> mvo_: the \t thing remains.
<jordi> mvo_: soem of the "FIXME" strings in ca.po still apply, too.
<elmo> Riddell: please ask lamont as first point of contact about buildd related things
<opi> hi
<mvo_> jordi: FIXME strings? I should have another look over them tomorrow I guess 
<Kamion> amu: did you apply the hotplug patch you were mentioning earlier? it was wrong
<mvo_> jordi: what needs to be added for the \t?
<Kamion> amu: it changed a bunch of things which were already correct, and didn't fix at least one bashism that was visible in context ...
<Riddell> elmo: ok, sure
<T-Gone> Kamion: have you been able to merge all changes (debootstrap, libunwind, elilo) in the daily ISO for ia64 lately?
<T-Gone> if so i'll give a new shot asap
<Kamion> T-Gone: debootstrap/libunwind should be there in tomorrow's ISO, not elilo though
<Riddell> lamont: any idea? (why amarok 1.2beta3 seems to be in hoary but there's no build log)
<lamont> Riddell: pretty good idea... :-(
* lamont goes to find it - I assume you mena i386, since nothing else built...
<T-Gone> Kamion: i'll wait for elilo to be in, I'll test everything at once. I'll try to find some time to boot my zx6000 monster to check what's wrong on SCSI boxes
<mvo_> jordi: only 4 FIXMEs left in ca.po :)
<jordi> mvo_: http://developer.gnome.org/doc/tutorials/gnome-i18n/developer.html
<jordi> mvo_: that's an excellent document 
<jordi> searching for tabs should reveal stuff
<jordi> Why do you use tabs in those messages anyway?
<mdz> jordi: hey
* T-Gone is exhausted, calling it a night. See yall.
<Kamion> T-Gone: ok, I'll take care of it tomorrow
<amu> Kamion: i applied the patch, tested it local and it works   
<jordi> hi mdz 
<T-Gone> Kamion: thx! See ya.
<Kamion> amu: really, it does not fix it. no current shell cares about "$VERBOSE" == no versus "x$VERBOSE" == "xno"
<jordi> mdz: when I was going to work on the apt po update, I saw you had uploaded already :)
<Kamion> amu: please revert that and simply replace the == with =
<Kamion> that's the bashism that was reported
<Kamion> your patched package will work, but no better and no worse than the original
<lamont> Riddell: give it about 5-10 minutews
<mvo_> jordi: this is the dependency problem error message. it can be very long
<lamont> Riddell: I had an idea, but it was wrong...
<Riddell> lamont: ok, good luck
<lamont> Riddell: nah - stale lock file was preventing mirroring, it turned out.
<jordi> mvo_: hmmm, but you don't answer why it needs tabs
* lamont adds an @reboot crontab entry to remove it.
* lamont scratches his head.  That's already there.
<jordi> mvo_: sent update
<jdub> thom, lamont: ooh, mono was de-b0rked?
<thom> yeah, and shoved back to universe
<lamont> jdub: evil was committed
<lamont> and mdz would approve universe
<thom> we might want to work on 1.1 at some point, i think it's gonna be the better option
<lamont> mcs_1.0.4-1 must never go into main
<elmo> the fact that it's in universe is no excuse, we should not be hand uploading stuff that doesn't build.  period.
<lamont> thom: regardless of the version picked, it must be able to build from just the sources in the archive.  At any time.
<thom> yes
<thom> agreed 100%
<jdub> ooh, evil enough to rile the walking evil Himself :-)
<lamont> elmo: mcs_1.0.4-1 is the first package that has been so treated, and only after discussing it with mdz.  /me is not happy with it at all
<thom> (it doesn't build in debian, either, btw)
<ajmitch> lamont: is it truly that evil?
<lamont> ajmitch: if I can't build it tomorrow, it doesn't go in the archive today.  period.
<mdz> jordi: I can do another Debian upload for new translations, vorlon said it would be OK
<mvo_> jordi: ups, sorry. it displays a dialog (dialog_unmet) that has a message "Could not mark all packages for install or update". it then has a textview that shows: "$packagename: \n Depends: apt 0.5.4 but 0.5.3 is installed or\n aptitude 0.2.17 but it is not installable"
<lamont> ajmitch: as it was, building it required scrounging the morgues of both debian and ununtu
<ajmitch> hmm, so there'd only be one .net-compatible runtime
<lamont> ajmitch: not at all.
<lamont> the issue with mono 1.0.4-1 is that you must install 1.0.2-1 on the machine in order to build it.
<ajmitch> lamont: not pnet?
<jordi> mdz: oh
<jordi> mdz: hmm, but you already did it, didn't you?
<lamont> if pnet can build itself, I'll be happy to bootstrap it in
<ajmitch> lamont: it's in universe
<thom> i didn't think dotGNU was even close to useful yet
<lamont> ajmitch: the process goes: 1) build it once using whatever it takes.  (2) build it again using only source/binaries in the archive, and the binaries that you built in (1)
<ajmitch> thom: it's not as useful as mono, but still runs a bit of stuff well
<ajmitch> I need to hack the package a little to tell it to use the correct paths for gtk#, etc
* lamont giggles and points at gnus
<lamont> hrm.. looks like a debian bug, to boot.
* lamont just shipped a handful of warty cd's to chicago via courier
<lamont> well, ok.  a buddy just grabbed abunch on his way to the airport, with promises to find them good homes
<mdz> jordi: 
<mdz> jordi: I have made two uploads, and I am not afraid to make two more if necessary ;-)
<mdz> I have a sarge branch set up now
* mvo_ goes to bed now
<ogra> mvo_: n8
* haggai looks in and finds himself locked in a room with a key belonging to fabbione
<haggai> fabbione: the error message is way above the line you posted
<jdub> thom: 
<jdub> dpkg: error processing /var/cache/apt/archives/mono-assemblies-base_1.0.4-1_all.deb (--unpack):
<jdub>  trying to overwrite `/usr/lib/mono', which is also in package libdbus-cil
<jdub> 
<jdub> known?
#ubuntu-devel 2005-01-29
<thom> that's a bug in libdbus-cil; i've not seen it before tho
<haggai> fabbione: Checking DLL ../../../unxlngi4.pro/lib/check_libevoab2.so ...: ERROR: /usr/lib/libsoftokn3.so: undefined symbol: PR_GetLibraryFilePathname
<haggai> dmake:  Error code 1, while making '../../../unxlngi4.pro/lib/libevoab2.so'
<haggai> looks like evo has changed
* haggai glares at seb128
<seb128> why me ?
<haggai> seb128: evo :)
<haggai> fabbione: I'll set a build running and have a look at it in the morning
<seb128> haggai: what's wrong with it this time ?
<haggai> seb128: dunno yet, the evo address book module has failed to compile
<seb128> ftbfs from evo ?
<seb128> no, the build logs are fine
<seb128> which module is that ?
<seb128> oh, openoffice
<haggai> OOo has been broken by an evo source change
<seb128> the change is the krb4/5 support 
<seb128> it was off before and is on now
<haggai> CFLAGS+=`pkg-config --cflags libebook-1.0`
<haggai> libebook-1.0 is no more
<seb128> no
<seb128> but that's not new
<seb128> -1.2 for eds 1.2 in hoary
<haggai> yes, and that change broke OOo
<seb128> time to update it so :)
<haggai> indeed
<haggai> I'm allowed to glare at you because of it though :)
<jdub> thom: yeah, tberman recommends we ship 1.1, which is less buggy than 1.0 even though the 1.2 process has lagged for so long
<thom> i knew he would ;-)
<jdub> haggai: at least it's not a gtk bug :)
* jdub makes muffled kitten noises in elmo's direction
<jdub> haggai: do you have a blog?
<jdub> haggai: i want to read your adolescent poetry
<seb128> jdub: 
<seb128> <taaz> seb128: i've finally got a ffmpeg package to upload ;)
<seb128> gst-ffmpeg that's it
<azeem> haggai: yeah, where is your blog?
<azeem> you promised me one
<jdub> seb128: heh, rad
<haggai> jdub: oh I'll make sure you can't read it by filling it with britishisms then :)
<jdub> haggai: dude, i'm .au. we grok.
<jdub> weeeeeell, mostly anyway
<daniels> jdub: 'packaged openoffice today, innit'
<jdub> haha
<lamont> jdub: any final objection to cupsys-driver-gimpprint going into desktop?  ( #2113)
<haggai> you'll have a job to erwig me
<haggai> earwig
<haggai> time to get some bo
<jdub> lamont: go for it
<jdub> haggai: so what's the go with OOo2.0? (rhyme! yeah!)
<lamont> jdub/mdz: committed
<lamont> with some whitespace cleanup, sadly
<Mithrandir> jdub, you mean this?
<Mithrandir> 21:14 < haggai> elmo: please can you allow openoffice2 in?
<Mithrandir> 21:14 < haggai> openoffice.org2, I mean
<jdub> pitti: WOOOOO!
<jdub> Mithrandir: rad :)
<lamont> jdub: thoughts on just syncing a new gnus from debian?  http://packages.debian.org/changelogs/pool/main/g/gnus/gnus_5.10.6-0.CVS.20050104-1/changelog
<lamont> we need the first bug fix listed
<lamont> not sure what else is changed...
<lamont> alternatively, I could backport the fix - it's not particluarly painful
<jdub> okay by me
<lamont> jdub: is that sufficient process, or is there more?
<jordi> mdz: so do you upload to tpu, or straight to unstable?
<lamont> guess I should at least file a bug first, eh?
<mdz> jordi: unstable
<jordi> mdz: ok, AIUI, you already grabbed all the updates from CVS, right?
<mdz> jordi: yes
<jordi> ok
<mdz> jordi: bubulle is doing some work organizing translations into arch
<jordi> I know there are some typos still in apt :)
<mdz> jordi: it would be ideal if I could receive translation updates via arch
<jordi> mdz: great
<jordi> nod
<lamont> grumble... no gnus package in bz
<jdub> lamont: strictly speaking, there should be a bugzilla bug to confirm
<jdub> heh
<lamont> 5605 would be that bug
* lamont must go fetch a child.  bbiab
<lamont> like 60-90 minutes
<lamont> jdub: feel free to confirm and poke elmo.  thanks.
<mdz> daniels: what's the story with that framebuffer autodetection bug?
<daniels> mdz: fixed locally, will upload with the rest of xorg later today
<mdz> daniels: fabulous, thanks
<daniels> mdz: no worries
<jdub> mdz, elmo: xen is a bendy goal, right?
<mdz> jdub: haven't thought about it much
<mdz> hoary hoary hoary
<elmo> I think it should be, esp. if we come to rely on it
<jdub> elmo: hoary or bendy?
<elmo> (of course talk is cheap and all that)
<jdub> i'm writing about FC4 plans to udevel
<thom> if we wind up needing it for automated testing, we're gonna need it for hoary, right?
<jdub> thom: it has been downgraded
<thom> "it"? automated testing?
<jdub> yeah
<elmo> jdub: if we're not doing auto-testing for hoary then bendy's fine.. hoary would be lovely, but I'm certainly not volunteering :(
<thom> yay, one less feature goal!
<jdub> haggai: so anyway, do you have a blog?
<elmo> fabbione: ?
<Mithrandir> elmo: he went to bed two hours ago
<elmo> meh, fabbione's such a wimp - anyone would think he got up at 7 or something
<Riddell> jdub: someone made this avater for my planet entries, it was refused on planetkde for some reason http://muse.19inch.net/~jr/tmp/jriddell.png
<jdub> Riddell: because it's not a hackergotchi!
<Riddell> :)
<robertj> it's obvious that there needs to be an amihackergotchiornot
<mdz> elmo: is oo.o2 waiting on you?
<mdz> elmo: or me?
<elmo> mostly waiting on you to not ignore me
<elmo> ;-p
<elmo> I was trying to ask you about the policy for NEW packages and UVF in general on universe?
<mdz> elmo: when did you ask that?
<elmo> I pinged you on jabber a while ago
<mdz> fucking hell
<mdz> my jabber window keeps opening minimized
<mdz> elmo: new versions in universe are fine by me until at least feature freeze
<elmo> and new-altogether packages?
<mdz> likewise
<elmo> ok
<elmo> do you want me to do anything different WRT seed syncage?  or can I assume anything committed to the seeds is approved for actioning?
<mdz> elmo: within reason, yes
<mdz> if you find that something stupid is getting pulled into main, of course scream
<elmo> ok
<mdz> Kamion: here?
<elmo> he said he was going to bed an hour or so again
<elmo> s/again/ago/
<mdz> ah
<mdz> elmo: for the stuff you imported from !debian, did you automatically sync new versions prior to UVF?
<elmo> err, no
<elmo> should I have?
<elmo> I was never automatically syncing !main - I thought that was known
<mdz> !
<mdz> no, it wasn't known
<mdz> you weren't synching universe?
<elmo> sorry
<elmo> I was never automatically syncing !Debian-main
<mdz> ah
<mdz> in that case, we should probably have done it at least once prior to UVF
<elmo> do you want me to do it now?  it's all universe or lower
<mdz> yeah
<mdz> just freshen it up
<elmo> ok
<mdz> thanks
<tseng> holy crap mono built
<jdub> freshen up multiverse? through the nose!
<jdub> mdz: so we roughly agreed on xen being maintained in our standard kernel packages, right?
<mdz> jdub: from the sound of it (their incremental diffs and such), I think that's workable, yeah, but I haven't actually looked
<daniels> elmo: please install l-h-2.6.10-2-* on concordia and davis
<mdz> if it's crack and falls behind upstream, we shouldn't do it that way
<jdub> might be able to get buy-in from the xen folks
<jdub> so, this might be an off-colour suggestion
<jdub> how about importing NEW packages from experimental into universe automagically?
<jdub> ie. not new versions of existing packages
<daniels> we don't have access to packages in the NEW queue
<jdub> NEW for us
<daniels> oh, I see
<jdub> it has a whiff of insanity
<jdub> but might be kinda cool
<ajmitch> why only the first version?
<jdub> ah, not just the first version
<jdub> but anything that isn't a new version of something that already exists in universe
<robertj> just err, new, packages ;)
<elmo> jdub: one possible (if unlikely problem is), foo_2.0 introduced to experimental -> universe, foo_1.0 uploaded to unstable.. we're stuck with 2.0
<robertj> evolution has a really irritating bug in it right now where it doubles the host name portion in webcal uris
* thom sleeps
<jdub> elmo: aha. subtle.
<jdub> dear elmo, please sync pure bullets of planet ubuntu love. love, jdub.
<elmo> daniels: chroots freshened
<daniels> elmo: cheers
<daniels> elmo: i'm sitting here wearing my represent t-shirt just for you
<arc_> hi all
<arc_> iBooks are unable to suspend, and I found the problem, hald and pmud can't be up at the same time
<daniels> elmo: er, davis too?
<arc_> just stopped down all the service and noticed that my ibook now can suspend
<daniels> arc_: yah, this was reported in the bug somewhere
<jdub> mdz: would be good to have python-gnome2-extras python2.4-gnome2-extras in the desktop seed
<arc_> and then, starting up all the services, suspend crashed when I finally start up dbus/hald
<daniels> iirc it's holding the cd device open
<elmo> daniels: did that too?
<elmo> damn I need to order from all those cafepress shops
<daniels> elmo: afaict none of l-h-2.6.10-2-* is installed in the hoary chroot in davis
<elmo> meh
<azeem> "I carry the weight of Debian"
<daniels> azeem: oddly appropriate
<daniels> http://linux.slashdot.org/article.pl?sid=05/01/17/2341219&tid=163&tid=90
<jdub> what on earth is going on here?
<jdub> dpkg: error processing /var/cache/apt/archives/mono-assemblies-base_1.0.4-1_all.deb (--unpack):
<jdub>  trying to overwrite `/usr/lib/mono', which is also in package libdbus-cil
<jdub> 
<jdub> daniels: aha, lugradio got slashdotted :)
<jdub> excellent
<daniels> jdub: looks like it turned from a symlink into a directory, or vice-versa
<daniels> so dbus needs to be updated, and bleh
<elmo> daniels: done now
<jdub> daniels: ok, can fix here
<daniels> elmo: cheers
<daniels> jdub: libdbus-cil is the flaming bag of shit on my doorstep, so i'll deal with it later
<jdub> ok
<mjg59> daniels: BTW, there are various hacks to make the nvidia drivers more suspend-friendly
<mjg59> What license are the bits with source under?
<robertj> it's exciting to hear that dbus is on it's way to windows
<daniels> mjg59: errrr
<daniels> mjg59: nv is under a shit licence, nvidia is under a worse licence
<daniels> hm
<mjg59> daniels: This is the kernel-level stuff
<daniels> 'Users and possessors of this source code are hereby granted a nonexclusive, royalty-free copyright and design patent license to use this code in individual and commercial software.'
<daniels> there's nothing in the nvidia licence that allows us to modify the nv driver afaics
<daniels> mjg59: that's under GPL, I believe
<daniels> i'll let you know fo'sho after lunch
<daniels> since I'm starving
<mjg59> Yeah, I /think/ it's the kernel code
<mjg59> No problem
<mjg59> http://www.ati.com/support/infobase/4746.html
<mjg59> Haha
<mjg59> How shit
<daniels> yeah, woo woo ati
<daniels> oh well, l-r-m 2.6.10.2-1 uploaded
<daniels> the ravenous hordes can dissect it and kill it in every imaginable way
<jdub> daniels: oh, it has ati love?
<daniels> jdub: xorg + amd64
<jdub> cool
<jdub> no ppc?
<jdub> does nvidia do ppc?
<mjg59> No
<daniels> nope
<daniels> no-one does ppc
<mjg59> int agp_generic_suspend(void)
<mjg59> {
<mjg59>     return 0;
<mjg59> }
<mjg59> WAY TO GO ATI
<daniels> (probably because of the spectre of apple)
<daniels> mjg59: you're shitting me
<daniels> but yeah, if apple said 'you do linux/ppc and we go to $othervendor for our next systems', you wouldn't
<daniels> not that there's the userbase anyway
<mjg59> There's actually hardware specific code for some bridges
<mjg59> But it looks like ATI's AGP code is heavily ripped off from other places
<daniels> having drivers for peons is a pleasant side effect of having it for dreamworks
<daniels> mjg59: christing fuck
<mjg59> They don't seem to have any suspend/resume for the card itself
<daniels> mjg59: so I'm tipping UseInternalAGPGART no -> S3 death
<mjg59> Why do all these people want their own AGP code?
<mjg59> Did the kernel's AGP code molest them as children, or something?
<arc_> daniels: I don't think that apple is happy with people using linux on their boxes
<daniels> i really don't know; nvidia do the same thing, though
<daniels> arc_: as I said
<daniels> maybe agpgart worked too well
<mjg59> There's no symbols in the fglrx code itself that look like they're related to suspend/resume
<mjg59> Utter cocks
<robertj> arc: why not?
<robertj> arc; their hardware margins are huge
<robertj> pushing 30%
<arc_> anyway, I don't think that they're being worried about linux/ppc users
<robertj> oh, certainly not, but still ;)
* lamont returns
* lamont wonders if someone already has plans to play with ubuntu-meta any time soon (kamion)?
* mjg59 notes that the Nvidia release notes claim that they don't support ACPI, and then go on to say that ACPI S3 is supported but suspend to disk isn't
<daniels> s3 probably works by accident
<ogra> jdub: finally i need a hackergotchi :)
<jdub> ogra: yep :)
<ogra> jdub: btw, since im upload capable now....how about uploading packages to universe that are not in debian do they need approval or is this fully in MOTUs hands
<jdub> ogra: that's a slightly controversial issue
<jdub> ogra: probably best to discuss with mdz, elmo, person who is roughly resposible for the concept area the package fits into, etc.
<ogra> so we should add it to the agenda tmorrow ?
<jdub> that's a good start
<ogra> fine :)
<jdub> but we probably don't have to deal with those super-officially in general
<jdub> but perhaps a policy will come up as part of that discussion
<jdub> you might want to suggest general policy discussion as well as the specifics :)
<elmo> oh, crap t-b meeting of doom tomorrow
<ogra> that would be enough....there should be limitations though
<jdub> haggai: GO GO GO!
<jdub> elmo: what's doomy?
<lamont> jdub: same meta rules as mao?
<jdub> lamont: ;)
<elmo> jdub: they just always seem to go on for hours
<jdub> oh
<mjg59> daniels: Ok, the file that needs modifying to alter PM behaviour is under a You're not even allowed to look at this license
<daniels> mjg59: fglrx?
<mjg59> Nvidia
<mjg59> fglrx seems to have no hope
<mjg59> ARGH MY EYES
<mjg59> They have separate APM and ACPI suspend routines
<daniels> nvidia?
<mjg59> Yes
<mjg59> Oh. ungh.
<mjg59> They register the APM one with the legacy PM support, and the ACPI one with the device model PM support.
<daniels> WHOOHOO
<daniels> give it up for nvidiaaaaaa
<mjg59> And this is all based on compile time configuration
<mjg59> Jesus
<mjg59> That's about the worst thing I've seen all day
<daniels> what the fuck?
<daniels> sonicblue stole agpgart from the kernel and made their own hacks afaict
<daniels> synced with code in 2.4.16 and 2.4.8-ac7, that's great
<mjg59> Hahaha
<ogra> jdub: i would also like to see a policy for package removal for obsolete things like nautilus-media (which will never build with the new libs)....
<mjg59> WE ARE BIG CORPORATIONS. WE DON'T NEED TO FOLLOW YOUR CODING GUIDELINES OR COPYRIGHT.
<mjg59> Dave Jones got fairly pissed off with ATI at one point
<daniels> to be fair, sonicblue didn't assert copyright
<mjg59> Is the file GPLed?
<jdub> ogra: note that n-m has always been in universe
<daniels> (sonicblue being the dudes who wrote most of fglrx originally)
<daniels> mjg59: yah
<mjg59> Does it credit the original authors?
<daniels> there's jeff hartmann/precision/xig copyrights with gpl, plus davej ... no, not gpl
<daniels> the entire file is ... i think that's mit/x11
<daniels> yeah, full credit
<mjg59> Hahaha
* lamont files a bug against laptop-detect so he can fix it.
<ogra> jdub: its unusable and uninstallable...i looked at it this afternoon....its unlikely to build with libnautilus-extension-dev (the whole bonobo stuff is gone)
<daniels> hm, and further below, they assert copyright, but fail to licence it
<daniels> *slaps forehead*
<daniels> dear arseclowns
<jdub> ogra: yeah, i know (from upstream)
<daniels> you are a bunch of arseclowns
<daniels> please desist
<daniels> cheers,
<jdub> ogra: i am glad :)
<daniels> daniel
<ogra> jdub: so lets just drop it to not confuse the users ;)
* lamont decides to let thom fix the bug :-)
<lamont> somone who loves universe should help out 3518 (scim)
<lamont> it has stuff dep-waiting on it
<daniels> haggai: nice work :)
<elmo> uh
<jdub> okay dudes
<jdub> with thanks to our overworked and underincentivised sysadmin team
<jdub> we have a new planet.ubuntu.com
<jdub> which is sexier and more useful than every
<jdub> ever
<jdub> the news feed aggregates a bunch of different news things into one place
<lamont> jdub: does this mean that sometime soon someone will hold my hand through setting up a blog somewhere?
<jdub> so it's more useful than the one on the website ;)
<jdub> lamont: advogato.org :)
* lamont makes a note
<jdub> also, it's now for members and developers
<jdub> lamont: advo is very basic, but it's good
<jdub> lamont: depends on whether you want to run your own or not, whether you want to upload pictures, etc., etc.
<lamont> pics would be nice, don't mind running my own (providing it's not much load, etc)
<bob2> jdub: those bullets are kinda arse
<jdub> we should order dial-a-call-girl for the sysadmin team every now and then
<jdub> bob2: in the subs list?
<bob2> yeah
<jdub> oh, everywhere
<bob2> or is that plonedamage?
<jdub> yeah
<jdub> plonedamage
<jdub> i fixed some plonedamage
<jdub> but only absolute brokenness
<bob2> nice work covering up most of the salmonness
<jdub> makes blogs easier to read
<jdub> the worst plone damage is the fonts
* ogra goes to bed
<bob2> yeah
* jdub will actually visit planet ubuntu more often now ;)
<jdub> really have to get opml support in :|
<jdub> mdz: hmm, is grub purposefully not in ubuntu-base?
<mdz> jdub: sort of
<mdz> jdub: ubuntu-base is (base seed & debootstrap)
<mdz> and grub is purposefully not in debootstrap
<jdub> aha
<jdub> handy if you need to switch to lilo
<mdz> jdub: so where's my planet?
<jdub> you have a blog?
<mdz> no, exactly the point
<jdub> oh right
<mdz> jdub: holy shit re: xen, just saw http://linux.slashdot.org/linux/05/01/17/1212241.shtml?tid=136&tid=156&tid=172&tid=106
<jdub> sign up with blogger or advogato or something if you don't want to run your own
<jdub> mdz: whooooa
<jdub> mdz: and linus has mentioned adding it to 2.6
<mdz> jdub: maybe we should push that along
<jdub> hmm
<jdub> for hoary?
<mdz> know anyone who could do xen for us between now and feature freeze?
<jdub> hmm
<mdz> dilinger was at least knowledgeable about it
<chrisa> I remember there being some guy in #alioth that never stopped talking about xen
<mdz> chrisa: probably doogie, but he's easily distracted
<chrisa> I know it wasn't doogie, it was some guy knew to packaging
<chrisa> .... s/knew/new/
<mdz> ah
<mdz> aww, oo.o2 ftbfs
<mdz> haggai: :'-(
<Riddell> why would my package (unsermake) have a build log for i386 but not for other platforms?  maybe I'm just being impatient
<Riddell> "/bin/sh: ../ooo-build/configure: Permission denied" glad to see it's not just me who fell for that :)
* lamont looks
<lamont> Riddell: because it's arch: all
<lamont> that gets built on i386, but not the others
<lamont> although the log file should have showed up, ithink
<lamont> Riddell: logs that say ': (amd64|hppa|ia64|powerpc|sparc) not in arch list: all -- skipping' are filed in /dev/null
<Riddell> lamont: great news, thanks
<lamont> mdz: what's the plan on the 17 outstanding universe merges?  MOTU?
<mdz> lamont: MOTU
* mdz contemplates downloading oo.o2 just to upload the one-line fix
* jdub rapidly considered and threw out that idea ;)
<eruin> don't be lazy now!
<jdub> more that i can measure that fix in legal tender :)
<eruin> :o
<daniels> Riddell: (you want arch: any, not arch: all)
<Riddell> daniels: oh fooey, what is arch any for then?
<lamont> mdz: so when I fix postfix bugs (found in 2.1.5-4ubuntuN) in postfix-2.1.5-5 in debian, and that's all I've done, am I free to upload that as 2.1.5-5ubuntu1?  or do I need to call it 2.1.5-4ubuntuN+1?  (otherwise identical code...)
<mdz> jdub: ETA 12m
<jdub> mdz: OOo2?
<mdz> Riddell: think of arch: any as "each", and arch: all as "every"
<mdz> Riddell: arch any means build once per architecture, arch all means build once for all architectures
<mdz> jdub: yes
<mdz> lamont: call it whatever you like, as long as you're careful
<lamont> right
<mdz> lamont: 2.1.5-5ubuntu1 should really be based on -5, rather than -5
<mdz> rather than -4
<mdz> (should have the changelog entries, etc.)
<daniels> Riddell: arch any is 'this can build on any architecture'
<mdz> lamont: Keybuk should have it set up so that you can use MoM to do this
<daniels> Riddell: arch all is 'this can build on any architecture, but is machine-independent, so only needs to be built once'
<daniels> Riddell: come to think of it, unsermake is python, so can be arch all
<daniels> nevermind
<jdub> mdz: sweet :)
<lamont> mdz: truth is that it's checked into a cvs branch
<lamont> mdz: right 5ubuntu1 would be a 'resync with -5' entry, while -4ubuntuN+1 would be 'backport fixes from -5' kind of entries.
<jdub> elmo: ping
<jdub> mdz: thanks, subbing to the wiki works *much* better
* jdub converges on sanity.
<daniels> elmo: is mail for d.s@u.c getting lost somewhere?
<lamont> mdz: postfix is a package that I really want to get into hct, but it's also one that I want to be familiar with a happy hct before I use it there...
<jdub> oh man
<jdub> you can't put html in the news leadin bit
<jdub> that is so bong
<Safari_Al> How are things, jdub?  Did you get the email that I sent to you last week?
<fabbione> morning
<fabbione> lamont: are you still around?
<mdz> good morning, fabbione
<fabbione> hey mdz
<fabbione> lamont: can you please give back ooo on i386?
<fabbione> ppc builded fine
<lamont> fabbione: ISTR mdz was gonna upload a 1-line fix, or are you talking about ooo1?
<fabbione> ooo1
<mdz> lamont: he's talking about v1, I assume
<mdz> and the 1-line fix has turned into 3 missing build-deps so far
<fabbione> yes the one i uploaded yesterday
<fabbione> mdz: btw we got sparc in the archive :-)
<fabbione> i own elmo a few beers
<fabbione> yesterday he really managed to get my dick VERY hard
* chrisa quotefiles
<mdz> fabbione: shouldn't the beers come first, before the erection?
<fabbione> when you are drunk it's difficult to get a hard dick :P
<daniels> ...
<zenrox> lol
<mdz> fabbione: I wasn't CCed on #1293, so I didn't see your comment until now
<mdz> fabbione: you did the right thing anyway
<fabbione> mdz: thanks. i decide to uplaod after he confirmed that there is no need to serialize the uploads...
<fabbione> i need to wake up my gf
<fabbione> mdz: can you show me the dmesg output for 5234?
<fabbione> mdz: i think i have some kind of an idea on how to fix it easily
<mdz> fabbione: with or without the option enabled?
<fabbione> without
<fabbione> just plain boot
<fabbione> at the beginning of the boot there is some ACPI stuff
<fabbione> and there is also a neat line that i want to see if it is there for your machine
* lamont sleeps
<fabbione> night lamont
<lamont> fabbione: and (doh) given-back.
<fabbione> thanks :-)
<mdz> fabbione: emailed
<fabbione> mdz: thanks
<fabbione> mz: you booted with irqpoll
<fabbione> Misrouted IRQ fixup and polling support enabled.
<fabbione> i need without it :-)
<mdz> I can't reboot right now
<fabbione> ok
<fabbione> than when you can do this:
<mdz> let me see if I can get one from kern.log
<fabbione> boot without irqpool
<fabbione> nah don't worry
<fabbione> and check if the ACPI stuff says something like:
<fabbione> ** NOTE IRQ will not be routed automatically **
<fabbione> if it does it should also tell you which option to use to revert to 2.6.9 behaviour
<fabbione> and if you can test that one
<fabbione> i don't mind to revert the default to 2.6.9 for hoary
<fabbione> and see how it works for hoary+1
<mdz> sent
<mdz> I don't se a message like that
<mdz> I do see this: /var/log/kern.log.0:Jan 15 16:02:17 localhost kernel: Misrouted IRQ fixup and polling support enabled.
<fabbione> Jan  7 16:57:49 localhost kernel: ** PCI interrupts are no longer routed automatically.  If this
<fabbione> there it is
<fabbione> Jan  7 16:57:49 localhost kernel: ** workaround, the "pci=routeirq" argument restores the old
<fabbione> next time.. can you boot only with that option?
<mdz> pci=routeirq ?
<fabbione> instead of irqpoll?
<fabbione> yup
<mdz> grub updated
<mdz> what does it mean?
<fabbione> it's all explained in the dmesg
<mdz> ah, I see
<fabbione> basically they are moving the irq routing from a central thingy to the driver
<mdz> should I send my lspci output to bugzilla, then?
<fabbione> there is an email address where to send these info
<fabbione> perhaps just update our bugzilla and send him the link to it :-)
<bob2> mjg59: why does any acpi code run when the lid is closed at all?
<mdz> fabbione: can you find out if it's updated in bk already, before I mail him?
<mdz> 0000:00:07.5 Multimedia audio controller: VIA Technologies, Inc. VT82C686 AC97 Audio Controller (rev 50)
<mdz> (snd_via82xx)
<fabbione> mdz: yes. there was a huge alsa update from 1.0.7 to 1.0.8rcX
<fabbione> but no idea what has been fixed there
<davyd> anyone know how I would get a hold of bdale?
<davyd> does he answer his email?
<fabbione> did you try to contact him either on irc or via email?
<davyd> not yet
<davyd> I considered IRC, where does he hang out?
<fabbione> well try first then ask :-)
<davyd> fabbione: I figured I would ask so that I could use his preferred medium
<fabbione> #debian-devel #debian-kernel probably more
<davyd> on this server?
<fabbione> yes
<davyd> cool, thanks
<fabbione>  /whois bdale is your friend before flooding chans with pings
<fabbione> he is idling since a few hours
<fabbione> possibly asleep...
<davyd> yeah, I noticed that
<davyd> however lots of Americans seem awake
<davyd> so I don't know
<davyd> I'm not even sure which coast he's on
<mdz> night
<fabbione> night mdz
<fabbione> cya later for the meeting
<fabbione> btw.. at what time is that?
<fabbione> usual 16:00 UTC?
<daniels> which meeting, TB?
<crimsun> yes.
<crimsun> (there's no time in the topic of #ubuntu-meeting for it)
<daniels> Suggested packages:
<daniels>   bazaar-doc
<daniels> The following NEW packages will be installed:
<daniels>   bazaar
<daniels> that's a joke, right?  documentation?
<jdub> haha
<daniels> haggai: you are not kind
<daniels> pool/universe/o/openoffice.org2/openoffice.org2_1.9.66.orig.tar.gz
<daniels>       967566   0%   58.92kB/s    0:45:33
<bob2> hah
* bob2 enjoyes --nosource
<Keybuk> you're just jealous that haggai's got a bigger package than you
<daniels> not really -- he can have the bloody thing
<daniels> but my DSL wants to beat him
<daniels> savagely
<toresbe> What state is ooo2 in now?
<sivang> morning all
<Treenaks> hi sivang
<jdub> anyone got mail in their ubuntu-announce box?
* sivang checks
<sivang> morning Treenaks 
<fabbione> jdub: yup
<Treenaks> apparently, I'm only subscribed to -security-announce... let's fix that
<jdub> aha! finally got it
<jdub> thanks fabbione too :)
<fabbione> jdub: i just added universe to the sparc buildd :-)
<sivang> jdub: what was the announcment about?
<jdub> sivang: website look'n'feel context
<jdub> contest
<jdub> fabbione: whoa! sweet :)
<jdub> fabbione: what is your buildd?
<fabbione> jdub: netra t1 466Mhz + 512Mb
<jdub> heh :)
<fabbione> jdub: main hitted the archive yesterday
<jdub> i-think-i-can-i-think-i-can ;)
<jdub> oh, seriously? that's rad!
<fabbione> or better.. jackass
<jdub> when will there be netboot images? :)
<fabbione> jdub: yes. we only need elmo to finish to setup sparc.u.c
<fabbione> jdub: there are already
<fabbione> we need to get everything in the proper position in the pool and so on
<fabbione> and i need to build/upload a few packages still before you will be able to install
<fabbione> unfortunatly katie rejected the kernel because sparc did build -8
<jdub> cool
<fabbione> but i uploaded -9 in the morning
<fabbione> so basically she refused (correctly) to get an older binary than the source
<fabbione> but it's building now
* Treenaks proposes m68k ubuntu
<fabbione> Treenaks: don't tempt me
<fabbione> i have 2 m68k idling at a colo :-)
<fabbione> Total 4935 package(s)
<fabbione> to build from universe :(
<Treenaks> fabbione: *shudder*
<fabbione> ah damn
<fabbione> OOo still fails on i386!
<fabbione> haggai: where are you?
<sivang> morning seb128 
<seb128> hi
<pitti> Morning everybody
<seb128> hey pitti 
<daniels> sup pitti
<pitti> seb128: already tried language-support-fr? :-)
<seb128> not yet :)
<pitti> D'oh, so many new vulnerabilities today...
<daniels> pitti: at least libXpm managed to survive so far
<pitti> brb
<sivang> morning pitti
<Keybuk> pitti: why do you keep killing your box? :)
* Treenaks suspects vulnerabilities
<pitti> Keybuk: my ISP blocked the IRC ports yesterday , grrr
<pitti> Keybuk: so I installed a proxy, but I had to restart it :-)
<Keybuk> yeah, you might want to audit the dircproxy code a little
<Keybuk> from what I recall, there's some very silly bugs in it
<pitti> Keybuk: no, my neighbor needed a proxy, too, so I thought he could reuse mine
<pitti> Keybuk: but it doesn't work, so I just give him his own proxy, I think
<sivang> can anybody share his oppinion wheather simple-cdd is the right way to go customize an installer cd ? or does ubuntu has something better that's being worked on?
<sivang> pitti: could you reopen the bug I CC'd you with g-s-t? so I would be able to close when I have the 2 ubuntu stock profile templates done? :)
<pitti> sivang: you can't reopen it yourself?
<sivang> pitti: I tried to find it, but no matter how hard I tried couldn't. It's like gone to the null bit bucket.
<sivang> pitti: researching now.
<pitti> sivang: bug #?
<sivang> pitti: I wish I recalled, this is what I get when I search for users-admin ==> https://bugzilla.ubuntu.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=UPSTREAM&bug_status=PENDINGUPLOAD&field0-0-0=product&type0-0-0=substring&value0-0-0=users-admin&field0-0-1=component&type0-0-1=substring&value0-0-1=users-admin&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=users-adm
<sivang> erggh
* sivang didn't notice this was SUCH along URL. Apologies.
<sivang> pitti: I seem to fail find it also when attempting a g-s-t wide search.
<fabbione> hey pitti
<pitti> Hi my dear fabbione 
<fabbione> pitti: the use of work "dear" gives the idea that you are going to tell me that something is badly wrong
<fabbione> s/work/word
<pitti> fabbione: no, this time it really was meant like that :.-)
<fabbione> eehhe
<pitti> argh, my poor smiley...
<sivang> fabbione: you made him cry! :)
<Keybuk> oh fabbione, dear fabbione
<fabbione> hey Keybuk 
<seb128> jdub: here ?
<jdub> yo seb128 
<seb128> do you have some time to comment on #163501 (GNOME) ? UI freeze is monday and Vincent would like to get some advice on this before doing something ...
<seb128> BTW hey :)
<jdub> main menu?
<seb128> yep
<jdub> got a tab open for it ;)
<seb128> if you have any idea on what to do with it ...
<seb128> cool
<jdub> python2.4-samba is 4MB
<jdub> seb128: do you mind if i mention you in an open email, in relation to your ubuntu packaging?
<seb128> no
<jdub> thom: ping
<jdub> seb128: thanks :)
<jdub> seb128: um, it's positive, btw ;)
<ogra> morning...
<jdub> morning ogra
<jdub> ogra: how's that xscreensaver patch?
<seb128> jdub: I hope so, or I'll track you down :p
<ogra> pitti....dont you use a wlan usb stick for your ibook ?
<pitti> ogra: no
<pitti> ogra: i. e., I use one :-)
<ogra> jdub: i think i'll drop the aim for utf 8, else i only need to rewrite all the destroy functions....you'll have it at the weekend if thats enough
<ogra> pitti: what model/brand, we have a guy in ubuntu-users that needs a quick advice for one before a surgery...
<pitti> ogra: Netgear MA111
<jdub> ogra: i'd be totally happy for just chrome improvements.
<ogra> pitti: great....you've done our volvoguy a big favor i think
<jdub> seb128: "Debian or Ubuntu package maintenance is significantly more involved than GARNOME or jhbuild module definitions, but Seb drives through it like a chainsaw through creme brule."
<jdub> seb128: should that be 'crme'?
<seb128> crme
<jdub> aha
<jdub> thanks
<seb128> :)
<seb128> np
<Treenaks> jdub: writing the hoary release announcement already?
<jdub> Treenaks: haha, no
<jdub> Treenaks: i'll post a link when i've finished
<jdub> this is a bit different ;)
<jdub> seb128: how does an e with a grave sound?
<jdub> same as the e in seb?
<seb128> no
<seb128> grave = 
<Keybuk> isn't it that  goes down and  goes up ?
<seb128> aigu =  like in Sb
<seb128> circonflexe = 
<jdub> seb128: yeah, but what does it sound like? :)
<d3vic3> 0.o
<Kamion> jdub: circumflex over the u in brulee IIRC
<Kamion> crme brle
<seb128> correct
<jdub> aha, thanks
<jdub> oh, and first e?
<seb128> jdub: not really easy to explain how it sounds :p
<seb128> yeah
<Treenaks> seb128: so, the "" in crme brle is pronounced as the "e" in "seb" or "bed"
<Treenaks> seb128: sight?
<Treenaks> right?
<seb128> correct
<Treenaks> uh the 
<Treenaks> 
<Keybuk> seb128: simple, .mp3
<jdub> Keybuk: DOLPHIN KILLER
<Keybuk> do one with saying crme, one saying crme and one saying creme -- so we can tell the difference
<Keybuk> jdub: BABY iWHALE KILLER
<Treenaks> iWHALE? the new Apple product?
<seb128> elmo: gnome-pilot and gnome-pilot-conduits syncs please
<Keybuk> Treenaks: baby whales = pod, iWHALE, BABY iWHALE, iPod ... it made sense to me
<Treenaks> Keybuk: ah!
<Keybuk> not that I *own* an iPod, too much of my music is in .ogg for that, but still
<Treenaks> Keybuk: I missed the "pod" definition :)
<ogra> seb128: pronounce lix *g*
<Kamion> that well-known French character, 
<ogra> heh
<Treenaks> ogra: f?
<ogra> lol
<Keybuk> Llinwcs!
<Treenaks> fun with compose maps... sigh
<haggai> fabbione: should I fix OOo?
* ogra cant belive the discuss a backport of ooo2 in the -devel ML
<ogra> they even
<thom> jdub: ack
<thom> morning folks
<sivang> morning thom
<ogra> hi thom
<pitti> Hey thom
<seb128> hey thom 
<Treenaks> hey thom
<haggai> ogra: they won't need a backport
<ogra> i know, they are crazy.....
<Treenaks> ogra: ex-gentoo?
<ogra> heh
<ogra> maybe....
<trukulo> ogra: i know about netgear usb wlan
<trukulo> i own one
<ogra> great, do you read ubuntu-users ?
<trukulo> uses atmel driver, http://at76c503a.berlios.de/
<trukulo> no, i only read ubuntu-devel
<trukulo> but as i know, doesn't work on ibook
<trukulo> only i386
<ogra> there is a guy that has a spinal surgery this week and wants a quick advice how to use his ibook wireless
<trukulo> as i know, netgear usb doesn't work on ppc
<Treenaks> ogra: you already helped him, right?
<trukulo> friends of mine bought one, and they have to return
<ogra> trukulo: pitti said he uses one
<jdub> thom: so man
<jdub> thom: netapplet sucks so bad
<ogra> Treenaks: but details can always help 
<trukulo> ogra: on ibook? so my friends are wrong, or very inepts
<jdub> thom: what do you think about hacking the netapplet menu and switcher into netstatus?
<jdub> thom: it's way nicer
<trukulo> i use one on i386
<azeem> ls
<azeem> eh, sorry
<jdub> pr0n.png ben-affleck-nude.kpg
<Keybuk> jdub: provided you get rid of the blinkenlights from netstatus
<sivang> morning mdz 
<azeem> .kpg?
<jdub> Keybuk: stfu. (i find them irritating too.)
<ogra> trukulo: btw, i have put the inclusion of foreign packages on the TB agenda today....with luck i'll get your graveman pkgs in universe this week
<jdub> azeem: you name your files stupidly
<Keybuk> jdub: so do something about it then! :p
<jdub> mdz: okay with me putting libnss-ldap and libpam-ldap in supported?
<trukulo> :) cool
<azeem> I can paste the content of ~ to prove you are wrong, if you want :P
<azeem> then I get banned for flooding and will die a martyrer death
<jdub> clean up your home directory
<thom> jdub: we'd still need all the (dubious) netdaemon connection stuff, but it might work out better
<jdub> then you won't get banned for flooding
<jdub> thom: yeah.
<jdub> thom: i figure it's more productive to go that way than to sass up netapplet
<jdub> hrm
<jdub> maybe not
<jdub> saves porting netapplet to being a real applet though ;)
<thom> it's a fairly chunky rewrite to "fix" netapplet
<thom> yeah
<trukulo> ogra: if you want liferea one, tell me
<trukulo> i can make a package of liferea this morning
<ogra> trukulo: i think thats already in from sid ?
<trukulo> sorry, i mean leafpad
<ogra> ah, ok
<trukulo> do you want me to do it?
<ogra> lets see what the meeting turns out in case of ploicy....(there currently is none)
<ogra> policy
<seb128> jdub: we can upload new packages in hoary at this point, or we are supposed to have freezed that ? /me considers packaging nautilus-sendto 
<trukulo> ok
<ogra> seb128: yay
<ogra> seb128: i've put this topic on tonights agenda (inclusion of new universe pkgs)
<seb128> you have some packages to upload ?
<ogra> seb128: graveman
<ogra> for instance
<jdub> seb128: universe is pretty loose - ask mdz and i (i approve)
<seb128> why do you need an agenda topic for that ?
<trukulo> wait, ogra, there's a debian package already for leafpad
<trukulo> it's in allioth
<seb128> jdub: ok, sending a mail right now
<jdub> seb128: ogra's would be ubuntu-only, which is slightly more controversial :)
<trukulo> http://chinese.alioth.debian.org/leafpad/
<ogra> seb128: because i'd like to have a written policy that doenst need to involve mdz and jdub
<jdub> ogra: it'll probably involve us anywya ;)
<ogra> jdub: i think it would only be for the time unzil pkgs go in debian anyway
<trukulo> jdub: me wants lion wallpaper in hoary by default :P
<seb128> yeah, just hijack jdub :p
<sivang> trukulo: me too
<sivang> :)
<trukulo> :)
<trukulo> votes for lion?
<trukulo> (leonardo)
<ogra> jdub: i.e. graveman will get packaged for debian once...as most of the other things will..
<jdub> trukulo: oh, did you do the lion?
<trukulo> jdub: no, it's from disney
<trukulo> heheheheh
<jdub> ogra: it's different for you though, as you can't upload to both
<jdub> ogra: that's the controversial bit
<ogra> ah, ok
<trukulo> jdub: but if you want, i can make one
<fabbione> Kamion: are you still in the position to test 5162?
<fabbione> Kamion: i think i have a fix :-)
<Kamion> fabbione: might take a bit of fiddling, but I think so, yeah
<fabbione> ok
<fabbione> i will upload the possible fix with the next kernel..
<fabbione> it's one line from upstream exactly in the point we need it :-)
<fabbione> and it is pretty clear how the code has been changing from 2.6.8/9/10
<ogra> fabbione: it would also be nice if my laptop could work with a load below 3.5 with the next upload ;)
<fabbione> ogra: it will
<fabbione> patch is already applied
<ogra> fabbione: great, thanks :)
<haggai> fabbione: did you do anything to ooo?
<ogra> fabbione: btw, i'm missing pinhead on the new planet 
<seb128> somebody able to reproduce the panel/nautilus/vfs lock here ?
<Kamion> is anyone working on fixing libxslt1-python2.4?
<seb128> I've put patched packages that might fix the issue: http://people.ubuntu.com/~seb128/vfs/ ... any feedback would be welcome
<fabbione> Kamion: i confirm that that one IS the fix :-)
<Kamion> ok, good, my shadow fix worked
<fabbione> there...
<jdub> seb128: ah yes, it happens on this machine
<seb128> jdub: go go go
<ogra> seb128: is there a bug # ? (doesnt happen here it seems (amd64))
<seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=4794
<ogra> thanks :)
<seb128> np
<elmo> seb128: done
<seb128> thanks
<jdub> elmo: ping :-)
<jdub> elmo: could you update p.u.c?
<elmo> k
<Mithrandir> ogra: you're on an amd64 now?  would you care to install openoffice.org-gtk-gnome and see if it works correctly for you?
<ogra> Mithrandir: already did it tonight :)
<fabbione> elmo: can you remove gtk2-engines_2.2.0-3_sparc from the incoming queue?
<fabbione> elmo: for some reason it was in hoary and then downgraded?
<elmo> fabbione: yeah, I just did, sorry about that
<fabbione> because that would be the only thing that could explain the message i get
<ogra> Mithrandir: seems to work great as far as i can tell (i didnt write exhauting texts or such though)
<elmo> I'll figure out why when I'm a little more awake
<fabbione> no problem dude..
<fabbione> i was just worried that i did something wrong, but i am 100% sure i didn't build anything outside hoary
<Mithrandir> ogra: rock, I'll close the bug, then.  Thanks
<elmo> jdub: done
<jdub> elmo: thanks :)
<jdub> elmo: did you run it too? ;)
<elmo> fabbione: an UNACCEPT is always a katie problem of some sort
<elmo> the message should make that clearer
<elmo> jdub: yeah
<jdub> thanks
<ogra> Mithrandir: are the buttons supposed to be themed ? they only have the right color, but stiull very rough edges
<jdub> ah stupid plone
<jdub> elmo: http://planet.ubuntu.com/news/
<jdub> elmo: need html as a directoryindex too :)
<Mithrandir> ogra: what do you mean -- rough edges?
<ogra> Mithrandir: they look like win98
<ogra> Mithrandir: not like industrial themed
<Mithrandir> ogra: hm, true.  Not sure what's up with that.. I'll have to look at it on i386 to see what it should look like. :)
<elmo> oh, meh, ok
<ogra> Mithrandir: its not too important though..... just the font and color improvement is already a lot....
<elmo> jdub: fixed
<jdub> elmo: thanks!
<elmo> argh, but now it's killed index.shtml
<jdub> haha
<jdub> DirectoryIndex index.shtml index.html
<elmo> that's exactly what I've done dude
<jdub> that is surprising
<elmo> I'm not stupid, apache is just a complete piece of arse when it comes to configuration
<Mithrandir> ogra: it uses the gnome file selector for instance here, but the buttons aren't properly themed, you're right.
<thom> pffft
<jdub> elmo: if i ever think you're stupid, i won't waste time implying it. ;-)
<ogra> Mithrandir: yup....and it seems the app icon is missing (i got the default icon in the tasklist)
<elmo> boggle, it seems to randomly pick .shtml or .html
<elmo> go apache.
<fabbione> elmo: you can bitch thombot :-)
<Mithrandir> ogra: I think we'd need to make ia32-libs-theme-industrial or something.. and I don't want to do that, for obvious reasons.
<Riddell> how do I tell dput to upload the .orig.tar.gz ?
<ogra> i think its ok as it is.....the fonts were the worst part and that is done :)
<Mithrandir> Riddell:build with debuild -S -sa
<mjg59> thom: We need some sort of power-base package that provides a consistent interface to suspend stuff
<mvo_> is it a known problem that xsltproc segfaults after todays upgrade? 
<azeem> didn't somebody talk about something like power-base on debian-devel some time ago?
<Kamion> powermgmt-base exists
<Kamion> extra bits should probably go in there
<mjg59> Kamion: Mm. True.
* Kamion is a bit worried by these "File descriptor 3 left open" (for 3..6) on /var/log/messages in recent installs
<thom> mjg59: yes
<thom> elmo: that's definitely a bug, it should be in order
<thom> mjg59: best yet, pbbuttonsd *almost* has a useful codebase for combining power management systems
<mjg59> thom: So something that can check whether it's an ACPI, APM or Pmac system and call the appropriate stuff on UI events
<thom> yah. 
<jdub> mjg59, thom: have you seen the PowerManager stuff on the gnome wiki?
<mjg59> Yeah
<thom> jdub: yeah
<mjg59> In the long run, that's the way to go
<thom> and i've been following the discussions on the hal list, too
<jdub> yeah
<thom> but definitely long term
<mvo_> seb128: any known problem with the libxml2 from yesterday? I have a crash in xsltproc that seems to be libxml2 releated
<fabbione> daniels: ping
<jdub> pitti: idea on u-d to have fonts as depends on language packages - i heartily endorse this idea
<pitti> jdub: I think it's a good idea too
<pitti> jdub: mako said that he has a list 
<pitti> jdub: I explained him the arch repo, so he just can commit that stuff :-)
<pitti> jdub: if you have an idea what to add, just tell me
<seb128> mvo_: not afaik
<seb128> jdub: #982 
<sivang> pitti: ok, culmus for hebrew language pack can be a start :)
<pitti> sivang: yes, send me a list of appropriate dependencies for language-support-il, and I will add them
<sivang> pitti: cool!
<abelli_> pitti: what if: 
<abelli_> unable to open /proc/net/dev: permission denied..
<sivang> pitti: also, is it a good idea to have pakcage for preconfiguring gnome kbd layout chooser to be automatically set up in the right language and maybe even the menu lang as part of this and the language-support-XX dependency?
<abelli_> is it normal with your kernel?
* sivang dreams of localized distros by an install of the language pack.
<pitti> abelli_: yes, it is; you have some /proc restrictions as normal user
<abelli_> ok thank you
<pitti> sivang: it shuold be the other way round
<pitti> sivang: the installer asks for language and so on, installs the correct language pack and passes the language to the X installer
<sivang> pitti: ok, and this is alos in the works?
<pitti> sivang: the only missing thing so far is the installation of l-p-<lang> by d-i
<elmo> jdub: right, fixed.. apache was actually fine, it was firefox that was broken
<pitti> sivang: but as long as the langpacks are not in the official archive, this can't yet happen
<no0tic> ati has released new drivers. They are compatible with xorg 6.8, and there are for 64bit too, they will be present in hoary stable?
<mjg59> no0tic: They will be in Hoary, yes
<no0tic> tnx
<jdub> elmo: sweet, ta
<Kamion> so what packages do I need to make the installer install?
<jdub> no0tic: they've already been uploaded.
<jdub> elmo: how much of a hassle is it for you to do p.u.c merges?
<Kamion> er, that was a bit general - I mean for language packs
<no0tic> jdub: cool
<jdub> elmo: want to figure out the optimal granularity of my requests :)
<sivang> pitti: ok, are you planning to add the auto input lang setup support as part of it? so when they will be in the official archive (and also auto synced from rosetta) we would have rocking local support? :)
<pitti> sivang: no, the input lang setup is done by d-i
<pitti> sivang: l-s-<lang> only provides gettext data and dependencies
<pitti> sivang: brb, food
<elmo> jdub: not much, but if it gets to be like one an hour, I'm going to cry
<jdub> ok
<jdub> lucky last one for a while coming in a minute
<seb128> elmo: glib2.0 sync please
<elmo> seb128: done
<fabbione> elmo: sparc.u.c sync please :P
* fabbione hides
<fabbione> elmo: thanks again for yesterday
<seb128> thanks
<fabbione> it was cool
<jdub> elmo: fabbione said you made him hard.
<trukulo> ogra_: oh, my god, new graveman, that man doesn't rest or what?
<ogra> heh
<ogra> great
<elmo> fabbione: if there was only a command to create sparc.u.c like there is for syncs.. 
<ogra> hoplefully he sorts out the crappy detection stuff
<elmo> jdub: yeah, I'm working on blocking that out of my mind thanks :-P
<trukulo> yes
<trukulo> Fixed ATA and ATAPI devices detection, 2 !
<jdub> elmo: he means an erection
<jdub> elmo: i don't know if he knows how to say erection
<jdub> elmo: but that's what he means
<ogra> trukulo: ah, ok.....but i guess he still unses cdrecord --scanbus for that :(
<elmo> jesus christ, it's snowing
<Kamion> clear skies a mere couple of hundred miles south
<thom> yeah, it bloody ain't snowing here
<ogra> elmo: not here, youre probably in the wrong part of the world
<trukulo> ogra: could be
<ogra> trukulo: sad
<trukulo> ogra: but now he changes version number ! YEAH !
<trukulo> it's 0.3
<trukulo> and no more dates
<ogra> trukulo: after hoary preview i will see if n-c-b is injectable there
<ogra> trukulo: at least the detection code
<elmo> "Feels like: -5.6C"
<trukulo> ogra: that could be cool
<ogra> trukulo: way cooler would be to use dbus for IPC with cdrecord ;)
<ogra> trukulo: but then i could rewrite the whole thing....
<trukulo> ogra: so do it
<trukulo> hehehe
<fabbione> hmmm
<fabbione> dput barfed
<ogra> trukulo: matter of time :(
<fabbione> elmo: can you please remove linux-sources from uploaddir?
<ogra> trukulo: since i still have to pay my rent :/
<fabbione> Uploading via ftp linux-image-2.6.10-2-sparc64_2.6.10-9_sparc.deb: Error '(32, 'Broken pipe')' during ftp transfer of linux-image-2.6.10-2-sparc64_2.6.10-9_sparc.deb
<fabbione> ^^first time i see something like this
<ogra> fabbione: haggai had something similar with ooo yesterday
<fabbione> ogra: i am building locally to see if it is somekind of buildd problem or a missing build-dep
<fabbione> but it is i386 specific
<fabbione> that's for sure
<trukulo> ogra: yeah, i have to pay the rent too, bad thing the rent
<ogra> weird
<ogra> trukulo: yup....ad the food and the cars....
<ogra> and even
<elmo> fabbione: fabbione boggle
<trukulo> and the wife ?
<elmo> fabbione: it's 'cos I just cleared it out of new
<fabbione> elmo: ah
<ogra> trukulo: i'm not fabbionne......(only a GF ...)
<trukulo> heheheh
<fabbione> elmo: do i need to reupload i guess
<trukulo> fabbione: are you sure about your wedding?
<elmo> fabbione: yeah, please retry now
<fabbione> elmo: sure
<trukulo> think you wouldn't wank anymore
<sivang> trukulo: what;s wank?
<ogra> trukulo: but i have to pay her life too ;)
<fabbione> trukulo: in life there is only one sure thing that is DEATH!
<sivang> fabbione: ahahah
<sivang> fabbione: and taxes
<fabbione> sivang: no if you live in the middle of italy ;)
<trukulo> sivang: "touch yourself"
<sivang> trukulo: ah :)
<trukulo> ogra: same here with mi gf
<sivang> fabbione: I see.
<fabbione> ok
<fabbione> i can reproduce the ooo build error..
<fabbione> that's all i know :)
<trukulo> ogra: here you have new packages: http://mercurio.homeip.net/debian/
<ogra> trukulo: ok, lets see what turns out in the meeting tonight....#
<trukulo> ok
<trukulo> tell me tomorrow
<ogra> trukulo: is your .desktop file translatable ?
<trukulo> ogra: i use graveman's one
<trukulo> upstream .desktop file
<ogra> trukulo: it has one ? since which vers ?
<ogra> trukulo: i'm still two weeks behind with my package
<trukulo> don't remember, 20050110 could be
<ogra> ah, ok
<ogra> trukulo: so its a better decision to take yours for universe....will you keep it up to date ?
<trukulo> yes, as i want to upload it into sid too
<ogra> great :)
<trukulo> i'm talking with debian-devel-spanish
<trukulo> not to be a debian developer, but one of them could be my "bitch-uploader"
<trukulo> :)
<ogra> trukulo: as i will be for ubuntu ;)
* fabbione is crashing
<trukulo> sure
<trukulo> :)
<trukulo> ogra: sylvain now emails me when he has new versions :)
<trukulo> that's good
<ogra> yay
<ogra> tell him that we work together.....i also mailed him in the beginning of the year
<HostingGeek> why no unrar-nonfree in ubuntu?
<HostingGeek> unrar 1 can hardle open any rar files these days
<ogra> ogra@honk:~ $ apt-cache show unrar-nonfree
<ogra> Package: unrar-nonfree
<ogra> Priority: optional
<ogra> Section: multiverse/utils
<trukulo> ok, so i send him an email telling that our package is the same ?
<HostingGeek> hmmmmm
<ogra> trukulo: yup, that would be nice :)
* HostingGeek is blind
<HostingGeek> sry
<trukulo> so i'll do
<fabbione> Treenaks: can you add a dmesg output when the cs4236 module is loaded please?
<fabbione> i am looking at the device ID table and clearly your is missing... 
<fabbione> but it's not really *clear* how to add one
<fabbione> Treenaks: or very verbose lspnp
<Treenaks> fabbione: there's no pnp code in the driver I load... only in the /other/ cs423x driver
<Treenaks> afaik
<Treenaks> (what's the bug # again)
<trukulo> ogra: mail sent
<fabbione> 4787
<ogra> yay, thnak you :)
<fabbione> Treenaks: and what do you load?
<Treenaks> snd-cs4231
<Treenaks> not snd-cs4236
<ogra> fabbione, Treenaks: you should really involve crimsun.....he is a great alsa guy ;)
<fabbione> Treenaks: it looks like that portion of the code is somehow shared
<fabbione> but it would still lack the CSC0011
<Treenaks> fabbione: ah ok.. well, the lspnp -v output is there
<fabbione> that is the mixer/dsp one
<Treenaks> fabbione: I can't connect to the machine (xircom + ipv6 when not in promisc mode.. argh)
<fabbione> tsk :P
<fabbione> ok this even is fine
<Kamion> damn, anna's surprisingly complex considering its size
<trukulo> ogra: new version, i made a mistake in the last one
<ogra> trukulo: i wont sync before a decision tonight, take your time
<trukulo> ok
<HostingGeek> can we have java-package upgrade
<HostingGeek> i remember just after the hoary merge there was a new version that was fixed to work with sun 5
<HostingGeek> the current one doesn't work
<HostingGeek> unless you edit the script a bit
<HostingGeek> which is what the upgrade is
<ogra> HostingGeek: there is a prepackaged java1.4 and 1.5 in the tower net repo....no need for building it yourself, see the Java wiki page
<HostingGeek> ogra: i know
<HostingGeek> ogra: but people still will want to build there own
<HostingGeek> for what ever reason
<HostingGeek> and anyway java-package *IS* in the ubuntu rep
<jdub> elmo: http://ninjapants.org/files/chart.jpg
<fabbione> ahaha
<fabbione> jdub: "meh" is missing ;)
<jdub> heh
<fabbione> elmo:
<fabbione> Uploading via ftp linux-image-2.6.10-2-sparc64_2.6.10-9_sparc.deb: Error '(32, 'Broken pipe')' during ftp transfer of linux-image-2.6.10-2-sparc64_2.6.10-9_sparc.deb
<fabbione> i got the same error again..
<fabbione> it smells of timeout or something like that
<fabbione> let me try with a couple of small packages
<fabbione> elmo: it is some kind of timeout problem on ftp
<elmo> fabbione: where are you uploading from?
<fabbione> because small file transfers are ok
<fabbione> from hom
<fabbione> home
<thom> pitti: what you wanna do about #5606?
<HostingGeek> so java-package will not be upgraded?!?
<fabbione> HostingGeek: i told you already a couple of days ago that these issues must be discussed on the mailing list
<fabbione> not everybody is here now to be able to do a proper evaluation & so on.
<azeem> fwiw, the debia release managers requested a major overhaul of java-package before approval into sarge
<azeem> killing of those *debian packages, namely
<pitti> thom: apache-utils ships check-forensic
<HostingGeek> fabbione: 0_o you did
<pitti> thom: so yes, we need a security update
<thom> pitti: (i mean for apache2, i know we need one for apache)
<pitti> thom: nice, Javier finds all kinds of tempfile vulns
<pitti> thom: I'm just at fixing mysql (with the same bug)
<thom> yeah
<pitti> thom: ah, right
<pitti> thom: then please disregard my last comment to the bug
<pitti> thom: apache is in universe
<elmo> fabbione: as a work around, you could upload the large files by someother method to chinstrap/rookery/whatever and dput from there
<HostingGeek> pitti: by apache you do mean apache 1 right?
<elmo> fabbione: but, I could do with your help in testing/debugging the problem later, if I can't reproduce it on my connection
<pitti> thom: if you upload a new sid package and you have validated patches, can you fix hoary as well?
<pitti> HostingGeek: right
<thom> pitti: yeah
<thom> if you want to do an apache2 release i can give you a patch now
<pitti> thom: I would like to fix Warty too, but it is not high-priority
<thom> yeah
<fabbione> elmo: i can wait to upload the kernel.
<pitti> thom: the fix is easy, so if it is not too much effort, a warty update would be nice
<jdub> elmo: so dude
<jdub> elmo: https://www.ubuntu.com/
<ogra> jdub: i've see you plan a mips port ?
<jdub> elmo: this makes pointing people to www.ubuntu.com as the primary host... hard ;)
<jdub> ogra: i'm roughly interested in playing with the idea. </non-committal>
<ogra> jdub: fine, i got a dusty indigo2 hanging around....
<pitti> thom: the only problem with this is that people have to update apache2 for no apparent change
<elmo> jdub: fixed
<ogra> jdub: unfortunately with extreme graphics, so not desktop fun, but i would offer it....
<thom> pitti: yeah, i don't think it's worth it tbh
<jdub> elmo: awesome, thanks
<jdub> ogra: i have a build farm ;)
<jdub> ogra: two cobalt cubes and a linksys wifi router.
<ogra> yay
<pitti> thom: hmm. Do you think there are many folks recompiling the source package and using scripts out of it?
<pitti> thom: I don't, tbh
<ogra> hmmm, cubes :)
<thom> pitti: no, i don't think so either
<pitti> thom: hmm, right. Let's forget about this
<pitti> thom: I just saw the apache2 update on hoary-changes
<thom> yeah, that was just to get it out the way trivially
<Kamion> elmo: could you bump archive-copier's priority up to standard? I need this (for convoluted reasons) to stop the live CD using partman
<Riddell> I broke something again :(  I uploaded a package without a .orig file so I did debuild -S -sa and reuploaded but I havn't had an accept or reject notice in over 2 hours
<Kamion> archive-copier already has code in its postinst to exit early if it doesn't have a CD
<elmo> Kamion: done
<elmo> Riddell: what package?
<Riddell> elmo: kipi-plugins (and also gwenview I didn't upload the .orig with)
<elmo> Riddell: I don't think you reuploaded it to ubuntu...
<Riddell> oh no, not again...how do I set the default upload target in dput darnit
<fabbione> Riddell: just specify it in the command line all the time
<fabbione> it is a good practise
<ogra> Riddell: or drop all the other targets ;)
<ogra> Riddell: ...from your config
<pitti> Riddell: may it be that dput did nothing because you forgot to delete the .upload file?
<fabbione> pitti: good point
<Kamion> elmo: thanks
<ogra> pitti: doesnt it complain like dupload does ?
<pitti> ogra: it does
<Riddell> pitti: nope, .upload says it went to debian, that's very incompetant of me
<pitti> ogra: I don't know about you, but I never pay particular interest to the dput output
<pitti> ogra: I just do "uup foo.changes" and forget about it...
<ogra> pitti: snce i only have uploaded my first two packages yesterday i payed a lot attention to it ;)
<ogra> if i'm used to it i will probably ignore it too :)
<thom> hrm, i guess mithrandir has broken vawad then
* lamont heads off to enjoy MLKJ+1 day. :-)  will be back on in a few hours, I expect.
<pitti> lamont-away: still here?
<pitti> lamont-away: I NEED YOU
<Riddell> it would be good if an e-mail way sent out saying if a package you had uploaded had compiled sucessfully or no
<lamont-away> pitti: yo
<lamont-away> I shouldn't be here 
<lamont-away> elmo about?
<pitti> lamont-away: the warty-security buildds don't build ...
<lamont-away> pitti: GAH!
<pitti> lamont-away: he said to bother you
<pitti> lamont-away: well, it should have time until tomorrow...
<pitti> lamont-away: if you are in a hurry, just go
<lamont-away> pitti: nah - I must run the kids to town, but I'll go hop online and deal with it after that.
<pitti> lamont-away: sure, thanks!
<lamont-away> should take about 45-60 min before you see lamont_r on
<elmo> lamont-away: w-b can see them, I didn't investigate further than that yet
<lamont-away> elmo: cool.
<thom> mjg59: 5619 for your enjoyment
<fabbione> duplicate of another one that is pending upload
<mjg59> fabbione: No, it's a completely different one (sadly)
<fabbione> mjg59: the submitter admitted it...
<fabbione> it's the same...
<fabbione> otherwise just unmerge them :-.)
<mjg59> fabbione: No, it's entirely different
<fabbione> ok
<fabbione> have fun
<fabbione> ;)
<fabbione> i am off for a while
<zul> hey
<thom> pitti: 1.3.31-6ubuntu0.3 uploaded
<pitti> thom: thanks
<tseng> whats the policy on filing bugs against universe?
<tseng> oh there it is, appologies
<Keybuk> Bug#249182: universe: rules aren't consistent when viewed close-up.
* thom wonders what Mithrandir is doing to those disks, moving them byte-by-byte with a magnet?
<elmo> good god
<tseng> Keybuk: libfaad2-dev is uninstallable, but the notice says it only gets fixed when synced from sid
<elmo> sparc by itself, 1.2Gb.  sparc +all, 8.8Gb
<zul> mmmm....magnet
<ogra> tseng: hmm, i cant find a libfaad in debian....
<Treenaks> libfaad?
<tseng> hang on a sec, it might be me
<tseng> because the source package is sane
<tseng> nope, i only have hoary archives listed.. thought maybe in marillat
<Treenaks> ogra: libfaad2-0
<ogra> hmm, looks like marillat....
<Treenaks> ogra: in marillat. yes
<tseng> its in multiverse.
<tseng> building from source results in working packages, i must have something messed locally
<shaya> jdub: you here?
<jdub> i am
<shaya> so, gonna fix planet.gnome.org's xml :)
<lamont_r> pitti: fixed
<pitti> lamont_r: thanks
<lamont_r> pitti: and I have NFC how long ago I introduced that bug, or how it lived this long...
<pitti> lamont_r: it still worked three days ago
<ogra> sivang ... around ?
<lamont_r> I rebuilt the chroots, and the bug has been in the script for building chroots for as long as I can see...
<lamont_r> (it helps if you have a deb-src line pointing at warty-security in addition to warty... :-)
<lamont_r> pitti: which is to say, those chroots haven't been rebuilt since I built them by hand ages ago
<pitti> lamont_r: so all uploaded packages dep-waited on some security update?
<shaya> ijdub: so that's a no? :(
<jdub> shaya: oh, haven't got to it yet
<elmo> fabbione: sparc.u.c's up
<lamont_r> anybody got anything else before I disappear for a few hours?
<lamont_r> pitti: do you care if it takes a while to retry your packages?
<pitti> lamont_r: what is "a while"?
<pitti> lamont_r: hours are no problem; days might become a problem :-)
<pitti> lamont_r: btw, I just upload the next security update
<pitti> lamont_r: if you need something to play with :-)
<no0tic> hi all
<no0tic> I have finished installing hoary from array2 and I noticed many problems
<no0tic> it doesn't install xorg & gnome automatically, for example
<no0tic> it recognized synaptic touchpad but not installed the proper drivers
<lamont_r> pitti: fwiw, warty-{security,updates} are fixed everywhere, hoary-{security,updates} aren't yet, but should't matter
<pitti> lamont_r: right, I don't use hoary-security yet
<lamont_r> right
<lamont_r> I've fixed the script, and will fix hoary later today, I expct
<elmo> why the hell is bazaar-doc in universe?
<lamont_r> elmo: because it's not seeded, of course.
* lamont_r ducks
* lamont_r can't think of any better/other reason
<pitti> thom: btw, did you upload apache for hoary as well?
<thom> not yet
<thom> gonna do an upload to unstable and get it synced
<pitti> that's even better
<pitti> I just want to keep track :-)
<jdub> i can't stay awake for CC
<ogra> :(
<Keybuk> it's TB today
<ogra> jdub: you really sleep too much :p
<jdub> oh yeah
<jdub> oh, my evo is wrong
<pitti> sivang: you want the culmus package with the langpacks, right?
<pitti> sivang: since this is in universe right now, can you please talk about this package in today's TB?
<ogra> pitti: regarding the ML it should move into main soon
<pitti> ogra: on which ML?
<ogra> -devel i think....someone wrote that culmus is quite necessary for hebrew
<pitti> ogra: yes, right. and I answered that I would add it as soon as it is in main
<pitti> ogra: that's why I want to propose that in the TB
<ogra> argh....blind me
<pitti> ogra: because strictly speaking it is far too late to change the seeds 
<ogra>  just saw it
<seb128> elmo: here ?
* lamont_r prepares to run away for a whiel
<ogra> lamont_r: TB meeting in 30....
* lamont_r ponders
<lamont_r> mdz about>
<lamont_r> ?
<Kamion> lamont_r: supported: * bazaar-doc            # docs for bazaar
* lamont_r looks at the agenda
<lamont_r> Kamion: works for me...
<Kamion> lamont_r: it's been there for a while
<lamont_r> wonder if that just got committed?
<lamont_r> hrm.
<Kamion> so I blame elmo ;)
<lamont_r> yep.  muppet-error
<Kamion> 2004-12-07 11:32:08 GMT James Troup <james.troup@canonical.com> patch-48
<Kamion>     Summary:
<Kamion>       Add bazaar-doc.
<lamont_r> maybe that's why he noticed?
<lamont_r> LOL
<lamont_r> LOL
* lamont_r wipes the spit off his laptop.
<lamont_r> damn you Kamion 
<lamont_r> dammit.  need to be at tb
* lamont_r tends to agree with removing postfix from ubuntu-base - lets me ask questions intelligently at install time :-)
<Kamion> hell yeah
<lamont_r> Kamion: hell yeah remove it , or hell yeah I need to be at tb?
<Kamion> removing it, once the alternative is in place
<lamont_r> Kamion: or even without the alternative?
<Kamion> not so convinced about that
<lamont_r> yeah - we'd have to make exim4 a virtual package, or change a bunch of Depends. :-)
<mdz> morning
<mdz> lamont_r: am now
<lamont_r> mdz: I was debating the virtues of MLKJ+1 day vs the t-b meeting, then I read the agenda, and the question was solved.
<lamont_r> mdz: although if we could do mail first, then I can run off for the hour or 2 that I really want to run off for, and celebrate MLKJ+2 day instead. :-)
<pitti> Hi mdz
<mdz> hello
<mdz> tech board meeting in ~6 minutes in #ubuntu-meeting
<fabbione> hey mdz
<pitti> sivang: ping
<mdz> hmm, oo.o2 still not building
<mdz> and the latest version isn't in the archive, though I think I know how to fix the most recent build failure
<fabbione> neither oo1 for i386
<fabbione> haggai: ping
<thom> seb128: you bribed someone to fix find in epiphany?
<elmo> seb128: ?
<elmo> kamion: germinate.output:? Unknown supported package: bazaar-doc
<elmo> am I being particularly dense or something?
<seb128> thom: find extension working, I'm testing right now and will upload a cvs snapshot in a few min
<seb128> chpe did it
<Kamion> elmo: is that germinate run including universe?
<fabbione> elmo: do you want me try to upload again and see if timeouts?
<seb128> elmo: python2.4-libxml2 is in universe ... I changed the desktop seed before uploading it, that's not enough to get it into main ?
<thom> seb128: SWEEET!
<elmo> Kamion: yeah
<elmo> fabbione: no, not yet, I haven't added debug code
<fabbione> elmo: ok
<seb128> elmo: python2.4-libxslt1 will probably be in the same case we python2.4-libxml2 is here to build libxslt1
<Kamion> elmo: just trying it for myself now
<seb128> haggai: you need a pbuilder (and a fast box) to test your build-deps :p
<lamont_r> seb128: or even better, an sbuild setup
<lamont_r> since pbuilder and sbuild use different logic to pick the build-deps to install..
<elmo> seb128: caught up, sorry
<lamont_r> that is, assuming that you have any | build-deps...
<seb128> elmo: np
<seb128> lamont_r: yeah, that's probably OO.o's case
<Kamion> mdz: in case you haven't seen it, I made a casper change earlier to take advantage of the extra tweak I added to anna; behind the scenes I also removed archive-copier from udeb_include, which should further stop anna trying to pull in partman via dependencies
<lamont_r> seb128: almost certainly - without even looking... :-)
<mdz> Kamion: I haven't done mail yet
<Kamion> live CD will need retesting after that
<Kamion> I didn't test the live CD, but I did test an identical change to rescue
<Kamion> elmo: haha
<Kamion> elmo: germinate doesn't like the tabs following bazaar-doc
<elmo> boggle
* Kamion wallops Keybuk
<elmo> it doesn't .strip()?
<Kamion>             if pkg.find(" ") != -1:
<Kamion>                 pkg = pkg[:pkg.find(" ")] 
<Kamion> let me just check that that isn't my fault ...
<Keybuk> Kamion: ?
<elmo> BOGGLE
<seb128> who is taking care of samba around ?
<Kamion> yep, it's in Keybuk's last version :)
<Kamion> ok, willfix
<Keybuk> what's that doing?
<haggai> seb128: yeah, it's quicker to reupload than to rebuild...
<Keybuk> you can't insert literal tabs into Moin, can you ?!
<elmo> Keybuk: we stopped using moin for the seeds, they're in tla as text files now
<Kamion> like ages ago
<Kamion> pkg = pkg.split()[0]  seems simpler and saner
<elmo> umm?
<Keybuk> I don't think I knew about pkg.split() then :p
<seb128> grumpf, forgotten the TB again
<elmo> Kamion: [1]  surely?
<elmo> [0]  will be the *
<elmo> tho I'm assuming pkg is the whole line
<Kamion> elmo: " * " has already been stripped by that point, it's not the whole line any more
<elmo> ah, ok, sorry
<Kamion> ok, seems to work, let me test a bit more
<Kamion> elmo: can I have the debugging bits from that failed germinate upgrade?
<elmo> Kamion: ah, fair point
<elmo> I'll try again
<thom> seb128: < thaytan> xsltproc is suddenly crashing here building gstreamer docs
<seb128> thom: known issue, need new libxslt 1.12 which has been uploaded ~1 hour ago
<elmo> Kamion: meh, never mind
<elmo> you changed the name of the input files, that's what broke me
<Kamion> elmo: I did?
<Kamion> elmo: oh, I changed Packages to hoary_main_Packages, sorry ...
<Kamion> elmo: TBH I'd recommend you start using the multi-component support, then you don't have to deal with those filenames at all
<fabbione> mvo__: ping
<Kamion> elmo: I fixed germinate to stop trashing any file: mirror you point it at, too
<elmo> I dealt with multi-component by catting them together, it works well enough ;P
<mvo__> fabbione: pong
<fabbione> mvo__: the last aptitude ubuntu7 bombs on sparc
<fabbione> xsltproc -o output-html/ ./../aptitude-html.xsl ./aptitude.xml
<fabbione> make[5] : *** [doc-html-stamp]  Bus error
<fabbione> (FTBFS)
<fabbione> i have never seen this error on all the other versions
<mvo__> fabbione: a bad libxml2
<elmo> fabbione: see scroll back
<Kamion> elmo: sorry, I'd forgotten that you were depending on those names, I'd been considering them internal
<thom> fabbione: see what i said to seb a few minutes ago
<elmo> kamion: "Packages" ?? 
<mvo__> fabbione: or rather, a bad libxml2 + libxslt combination
<fabbione> ah ok
<elmo> anyway no prob now I know
<Kamion> elmo: well, germinate downloads to them :-)
<mvo__> a new upload is on the way
<fabbione> thanks
<fabbione> mvo__: yes i saw ubuntu8 already
<mvo__> fabbione: it will work again when libxslt_1.1.12 has entered the archive
<fabbione> mvo__: ok thanks. i will keep an eye on it
<mvo__> np. and cheers to seb128 because he did the new libxslt upload :)
<haggai> fabbione: oo1 - seems the moz libs have changed which breaks OOo's internal moz libs
<fabbione> haggai: ah
<fabbione> how to fix it?
<fabbione> because it fails only on i386
<haggai> ah, yeah that will be the only arch that actually uses the moz stuff, it's disabled on all the rest
* fabbione shrugs
<haggai> we could disable it on i386 too
<seb128> lamont_r: can you kick the libxslt build ?
<fabbione> haggai: ok.. do you have a fix for it?
<lamont_r> how's it blocked?
<haggai> fabbione: I'll have to look, as with all things OOo it'll take a while to sort out
<fabbione> haggai: ok. does OOo forks its build? aka make -j X ?
<seb128> lamont_r: probably waiting for python2.4-libxml2 which was in universe due to a name change
<seb128> lamont_r: elmo has moved it to main
<fabbione> haggai: if so i have a pretty fast build cluster over here
<Kamion> elmo: fix committed, patch-31
<lamont_r> if it's dep-wait for somthing that now exists, all is well, and will kick sortly. If it's dep-wait on a package name that will never exist, then I need to fix it... whch is it?
<seb128> lamont_r: first
<haggai> fabbione: it can fork but it isn't reliable
<fabbione> amen
<seb128> lamont_r: and it creates probably a lot of ftbfs since doc build segfault with the old libxslt
<seb128> lamont_r: so better to build it asap
<haggai> fabbione: strangely enough, OOo2 has now failed on the buildd too for exactly the same reason, even though it didn't on my system.  Maybe I can build-conflicts with something
<fabbione> haggai: interesting....
<fabbione> haggai: let me know what you figure out. i need to put oo1 back asap
<haggai> fabbione: I can take over
<elmo> Kamion: seems a lot happier now
<elmo> (not patch-31, just the new germinate in general)
<fabbione> haggai: i don't think you can upload to main, can you?
<fabbione> haggai: if so just go ahead.. it's fine for me
<haggai> fabbione: sure I can
<fabbione> perfect
<fabbione> thanks a lot!
<haggai> no probs
* haggai glares at seb128 again
<haggai> seems the latest evo made the change
<seb128> what change ?
<haggai> that pulls in the extra symbol via moz somehow
<haggai> my build env didn't have newest evo
<seb128> oh
<fabbione> i knew..
<elmo> and bazaar-doc comes into main with patch-31
<fabbione> it's always GTK at fault :P
<seb128> evolution-data-server probably
<seb128> which symbole ?
<haggai> seb128: yup, that project is linking against libebook
<haggai> Checking DLL ../../../unxlngi4.pro/lib/check_libevoab2.so ...: ERROR: /usr/lib/libsoftokn3.so: undefined symbol: PR_GetLibraryFilePathname
<haggai> libnspr4.so contains the new sym
<haggai> it wouldn't be such a problem if OOo's moz stuff wasn't so b0rken
<seb128> haggai: I'll fix eds in a min
<sivang> pitti: pong
<fabbione> lamont_r: adding universe to the buildd... i noticed that the output of quinn-diff adds universe/ to the list
<fabbione> now. in my wanna-build i added qw(main universe)
<lamont_r> yes
<fabbione> will that preserve the priority of building main before universe?
<lamont_r> huh?
<fabbione> or do i need to do some more magic?
<elmo> no, you need to patch it
<fabbione> well i want to prioritize packages from main
<lamont_r> fabbione: I think the w-b in the admin archive has elmo's patch in it.
<elmo> fabbione: check out chinstrap:~james/wanna-build
<elmo> oh, ok
<lamont_r> and I'll double check that today
<fabbione> yes i am using the one from db.d.o
<fabbione> or admin.. or whatever
<fabbione> elmo: is that sufficient to your knowledge?
<elmo> fabbione: dunno, diff the one you have with the one I put on chinstrap
<elmo>                 $sectval{"universe/$i"} = $sectval{$i}+80;
<fabbione> elmo: ok thanks
<elmo>                 $componentval{"universe/$i"} = 1;
<elmo> and that are the two key lines
<fabbione> checking..
<lamont_r> elmo: it's there
<lamont_r> fabbione: the admin archive in the data center, not debian's.
<lamont_r> you'll need that for package translation stripping as well..
<fabbione> lamont_r: no i have the one from debian...
<fabbione> replacing it now ;)
<haggai> seb128: do you think there's something fixable?  I think it's probably OOo's fault
<seb128> <seb128> haggai: I'll fix eds in a min
<haggai> seb128: I wasn't expecting you to fix anything
<seb128> libebook1.2-dev need to depends on libnspr-dev
<seb128> that's an eds bug
<seb128> since libebook is linked with it
<haggai> oh, right.  Another problem, then.
<haggai> It won't actually fix my OOo problem because OOo has an internal copy of the moz lib
<seb128> you said that's due to eds
<seb128> (just a quick question out of this, a friend is pinging me, OO.o crash in debian for his user with that:
<seb128> sh: crash_report: command not found
<seb128> Fatal exception: Signal 11
<seb128> and works as root .. any idea on what could be wrong ?)
<fabbione> elmo: do i also need the /C/ switch?
<haggai> no.  people sometimes report such a problem, but it can be several problems
<elmo> fabbione: oh, yeah
<elmo> I think
<haggai> seb128: it could be an unreadable font, or unreadable files in his home directory.  Get him to try moving ~/.sversionrc and ~/.openoffice away and try again
<fabbione> elmo: ok thanks
<seb128> haggai: ok thanks. He says that oo.o was working fine with wmaker and crashes since he switched to GNOME .... noooooo, not a new GNOME bug :p
<haggai> seb128: yuk
<elmo> lol
<elmo> iz always gtk bug
<haggai> and almost always has something to do with evo.. 
* haggai hides
<haggai> seb128: I already have that moz lib installed on my hoary chroot and oo1 still isn't building on it
<haggai> so I have to fix OOo :(
<seb128> haggai: libnspr-dev ?
<haggai> seb128: yes
<elmo> Riddell: ?
<elmo>    * Build fixes
<elmo> please document what you actually changed in changelogs
<Riddell> elmo: fair point
<Riddell> elmo: will you delete that one and get me to reload or let it pass?
<elmo> it's already gone in, I'm just asking for future ref
<lamont_r> Riddell: I save comments like 'stupid typo' for arch logs. :-)
<lamont_r> the changelog gets 'stupid typo in postinst was causing dpkg-divert to fail' or some such.
* lamont_r wanders off for a few hours
<lamont_r> seb128: libxslt is uploaded on at least one architecture now...
<seb128> lamont-away: cool, thanks
<Mithrandir> argh, my x40 fan has started making annoying noises.
<Kamion> Mithrandir: that's your fault for buying an x40
<Mithrandir> bah, I'll just call IBM and get them to fix it.
<sabdfl> Kamion: j-e-a-l-o-u-s-y ;-)
<Kamion> :-)
<elmo> that seems to be a feature of IBM laptop's, Marianne's is MIGRANE-INDUCINGLY loud
<thom> mine is silent unless i'm building firefux
<Mithrandir> mine used to be silent until this morning
<daniels> fabbione: pong
<fabbione> daniels: too late.. i can't remember what i had to ask..
<mdz> haggai: build-depends: bzip2 :-)
<daniels> fabbione: TOO LATE OH WELL
<fabbione> i just can't remember
<haggai> mdz: for OOo? gah, thx
<mdz> Unpacking OO.o build tree - [ go make some tea ]  ...
<mdz> tar: bzip2: Cannot exec: No such file or directory
<mdz> tar: Error is not recoverable: exiting now
<mdz> ajmitch: the universe-only process is a simplified way for people to get upload privileges to universe
<doko> mdz: Charles asked me about Python module packages that need to be updated for 2.4. these from universe?
<mdz> ajmitch: sabdfl will be documenting it shortly
<mdz> doko: universe, yes
<elmo> gar source-only uploads SUCK for checking packages
<T-Bone> heh
<Kamion> private buildd farm just for NEW, whose output gets thrown away on ACCEPT? :)
<Kamion> (yes, crack, I know)
<haggai> elmo: yeah, now if the ftpmasters documented and packaged their buildds properly I would have solved that ;)  as it is I'm still working on it
<T-Bone> Kamion: heh ;) btw, got my mail?
<elmo> haggai: huh?  I'm talking about NEW
<elmo> Kamion: seriously, that's been on our TODO list for sometime, it's a relaly good idea
<haggai> elmo: ah I thought you were complaining bitterly about all my OOo2 br0ken source uploads..
<elmo> as it is, I'm abusing BATTLESTAR concordia to do the same thing in a more manual fashion
<elmo> Take that Cylon scum!
<Kamion> elmo: doesn't it mean building not-even-slightly-vetted stuff though? that's why I thought it'd be crack
<Kamion> T-Bone: yeah, just buried in main-menu at the moment
<Kamion> (it's grubby in here)
<T-Bone> Kamion: k np. I suppose it'll be in tomorrow's snapshot?
<elmo> Kamion: well, it's come from a known person - better it breaks in the known-to-be-dangerous buildd enviornment than for 11 architectures
<Kamion> T-Bone: hope so, I'm not doing much else tonight
<Kamion> elmo: oh I guess it's been gpg-checked by that point, duh
<T-Bone> Kamion: sure, lemme know when you have more time. No hurry on my side ;)
<Kamion> T-Bone: what I meant was "yes, will do tonight" :-)
<ogra> so who is able to edit the CoC webpage.... ?
<ogra> elmo ?
<T-Bone> Kamion: ;o)
<elmo> ogra: why?
<Kamion> I don't think we need to go back and forth by e-mail any more, so I just need to apply the patch and tweak
<elmo> [I don't think I am tho] 
<Kamion> I can but would rather not; try mako?
<ogra> elmo: for adding a link to a txt version of the CoC
<T-Bone> Kamion: k. If you have hints for me wrt my specific questions, that'd be cool ;)
<ogra> elmo: to make signing easier
<Kamion> T-Bone: yeah, will reply to those
<T-Bone> thx a lot
<ogra> elmo: sabdfl just assigned it to me
<ogra> elmo: are you the guy ?
<elmo> ogra: hmm, *shrug* I can edit it, so yeah, I guess
<ogra> hmm, so who is the one ? mako ?
<elmo> blah.  kde.  makes even concordia slow and boring
<ogra> elmo: great :)
<ogra> elmo: fine :) http://www.grawert.net/CoC.txt
<elmo> hmm, can you get the text version on the website?
<Riddell> elmo: if you said that in #ubuntu jdub would tell you off
<mako> i'm happy to edit the coc webpage
<T-Bone> hi mako!
<mako> T-Bone: hola
<elmo> Riddell: jdub tells me off all the time anyway
<ogra> yay mako
<ogra> mako: could you add my text doc to download to the site please ?
<ogra> mako: http://www.grawert.net/CoC.txt
<T-Bone> Kamion: side note: Thierry tested 20050117 on a SCSI zx2000 without trouble, afaict. Will check on my zx6000 anyway tomorrow's image
<ogra> mako: and porbaly re-read it before putting it up ... just in case ;)
* mako nods to ogra 
<ogra> thaks :)
<elmo> does KDE install it's docs as .docbook files in the .deb?
<crimsun> yes, at least looking at kdebase-bin
<elmo> boggle.. ok
<Riddell> elmo: no, .html is generated at compile time
<crimsun> Riddell: what of the .docbooks?
<mdz> Kamion: did you test casper with the new anna stuff?
<elmo> Riddell: they don't seem to be in kipi-plugins?
<mdz> Kamion: it seems likely that it's missing some dependencies
<mdz> (e.g., hw-detect-full)
<ogra> trukulo
<trukulo> ogra, tell me
<ogra> i'll prepare it tonight ;)
<trukulo> ogra, tomorrow i'll update a better package
<trukulo> corrected by DD
<ogra> great !
<trukulo> and i'll make a ITP
<ogra> so i'll wait a day
<mako> ogra: i am going to run to the store quickly... i'm add it when i get back :)
<ogra> mako: will be enough i think :)
<Riddell> elmo: kipi-plugins has no docs that I've seen
<trukulo> ok
<Kamion> mdz: I tested rescue, which has equivalent disk detection requirements; it's fine
<elmo> -rw-r--r-- root/root      1517 2004-12-12 09:33:35 ./usr/share/doc/kde/HTML/en/kipi-plugins/borderimages.docbook
<elmo> -rw-r--r-- root/root       813 2004-12-12 09:33:35 ./usr/share/doc/kde/HTML/en/kipi-plugins/findduplicateimages.docbook
<elmo> -rw-r--r-- root/root      1087 2004-12-12 09:33:35 ./usr/share/doc/kde/HTML/en/kipi-plugins/acquireimages.docbook
<elmo> Riddell: ^---
* T-Bone had a few occasion to test rescue on ia64 and ppc too
<Kamion> mdz: oh, but rescue-mode depends on harddrive-detection; I think you should do the same in casper
<Kamion> (hw-detect-full provides harddrive-detection)
<Kamion> I didn't realise you weren't depending on that explicitly
<Kamion> mdz: to be pedantically correct you should also depend on casper-check, since you db_get a template defined there
<Riddell> elmo: ok I'm wrong, some packages generate the HTML at compile time and some at build time
<Riddell> s/build time/doc reading time/
<elmo> ok
<elmo> well ignore the third item in my REJECT mail then :)
<Riddell> righty
<no0tic> it's useful if I describe my experience with hoary array 2 installation?
<Kamion> yes, but a mailing list might be a better place than IRC
<Kamion> or bug reports for specific issues
<Kamion> if you're not sure where bug reports should go, a general installation report is fine too
<elmo> hmm, I should probably schedule some time to try hoary installs on all our servers types
<Kamion> that would be nice, esp. for hotpluggish hardware detection
<no0tic> I would like to know if my problems are normal problems or there something strange
<Kamion> damn, my reduced libc doesn't have scandir; wonder if it's easier to reimplement in opendir/readdir/closedir or to rebuild the initrd ...
<Kamion> no0tic: what was the first thing that went wrong?
<no0tic> Kamion: after the installation the system rebooted and xorg didn't come up because it found synaptics touchpad but not installed the drivers
<Kamion> oh, not stuff I know about then
<Kamion> mail the list :-)
<no0tic> Kamion: then I had to install gdm manually but it didn't start because of a font problem
<no0tic> Kamion: where can I find it?
<Kamion> did you choose to install software from the network?
<Kamion> if so, try the other way: answer "no" to that question, and you won't be vulnerable to recent archive changes
<Kamion> ubuntu-users@lists.ubuntu.com
<no0tic> Kamion: I installed from cd
<Kamion> yes, I know, but it asks you whether you want to install updates from the network
<no0tic> ah, ok, I thought it installed it from cd and then tried to update packages from the net with no avail
<no0tic> then it's clear
<Kamion> it tries, but tolerates some kinds of failure, like the network not being there
<mdz> Kamion: ok, will add a dep on harddrive-detection in my next upload
<mdz> Kamion: and casper-check
<Kamion> ok, cool
<mdz> Kamion: I've been working out how to debconfize the hardcoded stuff in casper
<Kamion> mdz: note you'll need a new rebuild from little before partman disappears
<mdz> Kamion: how evil would it be for me to use debconf to pass data from one casper hook to another?
<Kamion> in what way?
<Kamion> setting questions as a means of communication is fairly non-evil in d-i
<Kamion> if that's what you mean
<mdz> e.g., 15swap does db_input casper/swap/devices, and then a later script db_gets that to write it into fstab
<Mithrandir> mdz: do you want UVF exception request by mail rather than by IRC?
<Kamion> really db_input? as in ask the user?
<mdz> priority low
<Kamion> ok
<mdz> defaulting to "auto"
<Kamion> yeah, that sort of thing's fine IMHO as long as the ordering's defined
<mdz> in which case it finds one and db_sets it
<Kamion> partman's no different really
<mdz> ok
<mdz> Mithrandir: yes, email elmo, CC me+jdub
<Kamion> in d-i, debconf is allowed to be a registry ;-)
<ajmitch> is the mono packaging for ubuntu just based off the debian packaging?
<mdz> that was the essence of my question :-)
<Mithrandir> mdz: ok
<thom> ajmitch: it *is* the debian packaging
<ajmitch> thom: right, so I should bug them
<mdz> Kamion: what do you think about moving those symlinks from casper-udeb to localechooser, hw-detect, netcfg, etc.?
<ajmitch> about 1.0.5 being released for a month or so
<Kamion> (in death, a member of Project Mayhem has a name.)
<crimsun> ajmitch: meebey and zomb will just smite you.
<Kamion> mdz: I'm inclined to think it's cleaner than dangling symlinks in casper-udeb ...
<ajmitch> crimsun: I'm sure :)
<mdz> Kamion: I agree, but as far as actually getting the changes in
<mdz> Kamion: should I upload them, or will you?
<crimsun> ajmitch: the decision to use 1.0.4 instead of 1.0.5 was based on the latter consisting mainly of documentation updates.
<ajmitch> crimsun: but I can help them out
<Kamion> either's fine, I can do it tonight if you like
<mdz> iirc, the udeb process doesn't really care about file overlaps, so we don't really need to synchronize
<ajmitch> I see
<Kamion> the last udeb in lexicographical order wins, as far as stuff in the initrd goes
<Kamion> TBH I can't remember what happens with stuff installed by udpkg at run-time
<Kamion> mm, yeah, it doesn't care either
<mdz> Kamion: they'll be identical anyway
* Kamion nods
<mdz> since you're probably going to upload some of those as time goes on anyway, I think it makes sense for you to do it
<mdz> no particular hurry
<Kamion> I'll just blitz them :)
<Kamion> it'll need an initrd rebuild before it takes effect though
<mdz> Kamion: did you see that report on ubuntu-devel of vga16fb apparently using 80x30 characters on an 80x24 screen?
<Kamion> mdz: yes; unfortunately the same applies the other way round on some hardware
<mdz> has that ever been reported before?
<Kamion> yeah, it happens from time to time
<Kamion> some people have to use vga=<blah>
<Kamion> but if you try vga=791 (or whatever) on other hardware you get the same bug
<Kamion> I haven't seen a single sane solution that works everywhere
<mdz> 80x24 on 80x30 seems better than 80x30 on 80x24 ;-)
<Kamion> no, not that way
<Kamion> I have systems that overflow the screen on vga=791
<Kamion> whichever one you pick you lose similarly
<Kamion> it's documented on one of the isolinux help screens
<Kamion> I'd like to see a better solution, but I fear that it has to be a (vga16|vesa)fb fix in the kernel rather than a configuration change
<mdz> haggai: weird, when I uudecode src/images_kde-m62-1.zip.uu, I get a .zip archive that unzip can't extract
<mdz> (corrupt?)
<haggai> mdz: that's not normal
<mdz> Archive:  src/images_kde-m62-1.zip
<mdz>   End-of-central-directory signature not found.  Either this file is not
<mdz> haggai: well, so long as it builds on the buildds...
<elmo> ogra: 
<ogra> yup
<elmo> ogra: you're missing a build-depend on debmake
<ogra> ouch
<ogra> sorry
<Mithrandir> oh no! not debmake.
<Kamion> *debmake*?
<Mithrandir> please, not debmake.
<elmo> and debmake is REALLY old and crap, if at all possible you should fix the package to use something a little less 70's
<ogra> ok
<Mithrandir> gcc should conflict with debmake or something.
<elmo> ogra: also, you need to put the actual license into the debian/copyright file
<elmo> not just who has copyright on it
<ogra> i'll do, sorry to make fuss
<elmo> it's no prob
<ogra> :)
* thom kicks the bts scripts
<Kamion> thom: hm?
<thom> they appear to be ignoring DEB{FULLNAME,EMAIL}
<Kamion> oh you mean /usr/bin/bts
<thom> yes
<Kamion> it does honour DEBEMAIL
<Kamion> er, and apparently DEBFULLNAME too ...
<Kamion> strange, should work
<thom> ber, wonder why it sent from thom@localhost.localdomain then
<thom> oh well
<Riddell> are the buildd's running?  my gwenview package hasn't compiled in several hours
<mdz> Kamion: what do you want to do about getting the proper language pack installed initially?
<mdz> Riddell: was it accepted?
<Riddell> yep gwenview_1.1.8-1ubuntu3_source.changes ACCEPTED
<elmo> have you checked for build logs?
<Kamion> mdz: I'll just hack it in base-config, but nobody answered me when I asked earlier what packages I was supposed to install
<mdz> Riddell: http://people.ubuntulinux.org/~lamont/buildLogs/g/gwenview/1.1.8-1ubuntu2/
<elmo> generally speaking the buildds are always running, the downtime over the weekend was exceptional
<mdz> failed on all architectures
<mdz> silly me, I assumed he meant that no builds had been _attempted_ :-P
<elmo> so your first thing to do when asking "where's my package" is to check the build logs and/or state
<ogra> http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
<mdz> Riddell: that and other gems are on http://www.ubuntu.com/wiki/DeveloperResources
<Riddell> mdz: it was ubuntu3 I was asking about, not ubuntu2
<mdz> Riddell: what's the date on the ACCEPTED email?
<Riddell> mdz: ue, 18 Jan 2005 16:40:03 +0000
<Riddell> mdz: Tue, 18 Jan 2005 16:40:03 +0000
<elmo> meh, crap cron.daily broke due to germinate
<elmo> fixed
<Riddell> germinate?
<Kamion> elmo: oops
<Kamion> Riddell: have you heard of "seeds"?
<Kamion> like the base seed and the desktop seed
<Riddell> Kamion: yes
<mdz> Riddell: http://www.ubuntu.com/wiki/SeedManagement
<Kamion> Riddell: ok, germinate is the program that expands the list of seeds (which is in fairly minimal form, basically "these are the packages we're interested in") and expands out their dependencies so that they can be fed to things like the archive management scripts and the CD-building scripts
<sivang> could everybody who are Ubuntu Members add theirselves here : https://www.ubuntulinux.org/wiki/UbuntuMembers
<sivang> ?
* sivang only had a couple of names out of memory, please feel free to fix.
<Riddell> Kamion: I see
<mdz> sivang: they should all be in the community council transcripts
<Kamion> probably not all the Canonical staff though
<Kamion> they should probably either be in order of joining or in alphabetical order
<Kamion> (by surname, I'd recommend)
<sivang> mdz,Kamion : note take, however I think it would me more efficient to let people add themselves?
* Riddell is beginning to dislike lintian
<Riddell> why should a description synopsis not start with a capital letter darnit
<sivang> Riddell: hehe
<mdz> Riddell: lintian -i
<Kamion> Riddell: that's a recent stupidity in lintian
<sivang> mdz: I will add people whom I find approved int he CC transcripts though as a starting ground.
<Kamion> Riddell: it's been dropped in Subversion trunk of lintian
<Riddell> Kamion: I'm pleased to hear it :)
<Riddell> I hope the silly desktop-file-in-wrong-dir test gets fixed too
<Kamion> occasionally lintian gets slightly more overrun by pedantry than it should
<Kamion> not familiar with that test
<Kamion> I doubt many of the other lintian maintainers are either; it probably needs somebody to go and explain all the issues
<Riddell> should I report it as a beastie to debian or ubuntu?
<jvw> as a lintian maintainer, yes, that was a fuckup
<Riddell> jvw: the desktop one?
<jvw> we failed to do enough QA on the upload, due to rushing out the security thingy
<jvw> Riddell: amongst others
<Kamion> Riddell: see #289773
<jvw> the desktop was too strict, the capitilization too
<jvw> both have been removed
<Riddell> groovy
<jvw> I've removed the warnings about hardlinks too for hardlinks within the same dir
<jvw> and somebody else removed the waring about starting with an article
<jvw> (in the short description)
<ogra> Treenaks....you need a wiki page to become a memeber.....(just a reminder)
<Treenaks> ogra: I have a wikipage.. it's just that my name is "strange"
<Treenaks> ogra: (and it's not completely filled in yet)
<ogra> https://www.ubuntulinux.org/wiki/UbuntuMembers ?
<sivang> does anybody know if we have a "make yourself a local ubuntu archive" howto?
<Treenaks> ogra: it's linked from DutchTeam
<sivang> and the link to it, if I may ask.
<ogra> ah
<Treenaks> ogra: it's "Martijn"
<Treenaks> ogra: not "Martin"
* ogra edits
<ogra> corrected
<Treenaks> ogra: thanks!
<Kamion> mdz: ok, all the symlink changes uploaded
<mdz> Kamion: doh, just uploaded casper
<mdz> I'll remove them in the next one
<mdz> thanks
<Kamion> as I say it needs an initrd rebuild anyway
<Kamion> mdz: hm, do you feel like adding a backdrop title to casper?
<Kamion> saying "Ubuntu Live CD" in the top left-hand corner of the screen
<Kamion> or just "Ubuntu Live" or whatever
<mdz> Kamion: hah, I was just switching back to this window to ask you that
<mdz> after reading hoary-changes
<mdz> how do I do it?
<Kamion> add a template with the text of the backdrop title and 'Type: title'
<Kamion> add /lib/main-menu.d/10casper reading:
<Kamion> #! /bin/sh
<Kamion> . /usr/share/debconf/confmodule
<Kamion> db_x_setbacktitle casper/backtitle
<Kamion> d'oh, guard that with db_get casper/enable and a check that $RET is true
<mdz> do I need to wait for an initrd with the new cdebconf?
<mdz> Kamion: also, is there an existing debconf template I can borrow in place of casper-udeb/adduser/username ?
<Kamion> no, but you do need an initrd with the new main-menu
<mojo_> Unusre of group ettiquite, but can I ask about audio config in Ubuntu here?  My sound works, but I want to re-order my sound cards.  Also, I need to do a post-install to echo a midi string (so my Audigy2 remote will work).  Thanks
<Kamion> #! /bin/sh
<Kamion> . /usr/share/debconf/confmodule
<Kamion> db_get rescue/enable
<Kamion> if [ "$RET" = true ] ; then
<Kamion>         db_x_setbacktitle rescue/backtitle
<Kamion> fi
<Kamion> ^-- fixed main-menu.d script for rescue
<Kamion> mdz: perhaps you could just depend on initial-passwd-udeb instead?
<mdz> Kamion: I assume that expects /target to be mounted
<mdz> which isn't true before casper runs
<Kamion> that depends on base-installer, but I could tweak that
<Kamion> yes, it does
<Kamion> when does post.d run?
<mdz> after pivot_root
<mdz> which is when the adduser stuff currently happens
<Kamion> you could just 'dpkg-reconfigure passwd', then, with suitable passthrough magic
<mdz> Kamion: initial-passwd-udeb.postinst looks much like casper's X config script did before I did the passthrough stuff
<mdz> in fact yours is more evil ;-)
<Kamion> hey, I like mine :-) ... but yeah
<mdz> I called prerm and postinst too
<mdz> Kamion: dpkg-query -W --showformat='${Version}' passwd
<Kamion> I was cloning-and-hacking dpkg-reconfigure moderately literally there
<Kamion>         $_=`dpkg --status $pkg`;
<Kamion> point taken, but I was planning to kill that code
<Kamion> mdz: passwd/username is the template in question, anyway
<mdz> Kamion: does it have a default?
<Kamion> no
<mdz> hmm, i can't use that template unless initial-passwd-udeb is there, anyway
<mdz> we should find some way to share it though
<Kamion> I could split initial-passwd-udeb up, but that seems a bit evil
<Kamion> you can't just copy from debconf's templates database, because cdebconf requires UTF-8 templates
<mdz> what's the menu order for initial-passwd-udeb?
<mdz> if it's after casper, that should work
<Kamion> 72, but dependencies override menu-item order
<Kamion> if you depend on initial-passwd-udeb it will be configured before you regardless
<mdz> ah, darn
<Kamion> hey, doesn't this passthrough stuff pass the template data through?
<Kamion> so why would you need the template data in cdebconf?
<mdz> yes, that's much of the point
<mdz> oh, right, the template is in passwd, not in the udeb
<Kamion> so you can just 'dpkg-reconfigure passwd' after pivoting
<Kamion> yes
<mdz> I love it when a plan comes together
<Kamion> :-)
<mdz> can I let passwd.postinst create the user, too?
<elmo> grr, fsh broke
<Kamion> mdz: passwd.config already does that
<mdz> Kamion: .config creates the user??
<Kamion> yep
<mdz> my word, it does
<Kamion> I try not to look at it too hard
<mdz> isn't that evil?
<Kamion> mdz: it's probably better than storing the password until .postinst gets round to running
<mdz> Kamion: it's no worse than storing it in shadow
<Kamion> it's moderately evil, but works :) It does check whether adduser is there first.
<mdz> assuming it could store the hash...
<mdz> chpasswd certainly allows for that
* Kamion is not inclined to mess with it. :-)
<mdz> hmm, one problem
<mdz> I need for the username question to be asked at below-default priority
<mdz> while passwd.config will ask it at default-or-above priority
<eruin> seb128: your gnome-vfs packages seem to do the trick
<Kamion> hm, this sort of calls for the ability to preseed priorities (which doesn't exist, but we've talked about it)
<Kamion> mdz: hack: look at debconf/priority, and if it's high or critical then set a default value
<Kamion> (you may vomit now)
<eruin> seb128: I've only restarted nine times, but so far so good
<mdz> Kamion: how about I just db_set it for now
<Kamion> that works
<mdz> (passwd/username)
<seb128> eruin: cool
<seb128> eruin: thanks
<Kamion> what about the password?
<mdz> the "let me specify a custom username" feature can wait
<mdz> I don't set one, currently
<seb128> eruin: "only" ? :) nine is quite a lot
<eruin> seb128: not where I'm coming from ;-)
<mdz> dunno what passwd.config would do with that
<Kamion> I don't know if you'll need to tweak passwd.config to support that
<Kamion> you will
<Kamion> it strikes me as a dangerous thing to support in the general case
<jdub> goooooood morning freedom lovers!
<Kamion> I'd almost be inclined to temporarily set a dummy password and then clear the password field in shadow afterwards
<ogra> morning jdub :)
<mdz> not an entirely silly idea
<elmo> any reason why fsh didn't make the cut for main?
<mdz>                                 case "$RET" in
<mdz>                                     "Martin Michlmayr")
<mdz>                                         userdefault="tbm"
<mdz> can I get one of those too? :-P
<elmo> I don't recall any objections to it in mataro
<mdz> elmo: with pitti's review, it's ok with me
<elmo> mdz: with == if?
<mdz> elmo: with == with
<mdz> or with == "if it passes"
<elmo> uh, I'm confused. I mean has there been one
<elmo> ok
<mdz> I wonder if there's a kernel tunable
<elmo> authbind which is suid managed to get in, but, hey, I'll not mention little details like that ;P
<mdz> to say "my disk is ridiculously slow"
<mdz> "aggressively swap stuff out to make room for cache"
<mdz> would be nice for casper
<mdz> elmo: "managed to get in"?
<elmo>   authbind | 1.1.5.2-0.1 |         hoary | source, amd64, i386, ia64, powerpc, sparc
<mdz> elmo: am I mistaken in believing that stuff doesn't get in without your making it so?
<elmo> mdz: no?
<mdz> or is it only that it didn't get a security review?
<elmo> yeah, I'm just saying it didn't have a security review
<mdz> meaning that I said "yes", rather than "yes, pending review"?
<mdz> if so, please retroactively send it to pitti for review
<elmo> all of thom's changes went in en-masse.  I asked you about them on irc.. mailed you and jdub, and eventually assumed consent and added them
<elmo> ok
<jdub> assumed consent
<mdz> elmo: was it seeded, or a dependency?
<elmo> mdz: it was seeded
* jdub will remember that one at 3am during the next ubuntu conference.
<mdz> elmo: when we reviewed these in Mataro, we specified which ones needed review
<mdz> they should be in thom's or whoever's notes
<mdz> thom: ?
<mdz> elmo: date or subject of the mail?
<elmo> I'm not quite sure why I'm meant to be gatekeeper to the seeds like this?  they are commited to a public tla repo and it's not as if I didn't ask you
<mdz> elmo: I believe you that you asked, but I wanted to dig up the list for reference
<thom> if i had "needs security review" in my notes, that went into the seed as a comment
<mdz> the intent was that they got review before being added to the seed
<elmo> mdz: people.ubuntu.com/~james/to_sync.txt is the URL I sent you
<elmo> still looking for the mail
<mdz> that's sufficient, thanks
<mdz> lintian wasn't already there?  I could have sworn
<elmo> I gues the mail would have been the same date as that file ~7 Jan
<thom> no, we only had linda seeded due to the whole being python thing
<Kamion> mdz: Christian Perrier seems to be the one determined to hand those out ;)
<mdz> thom: I thought we gave up and did both because they were complementary
<mdz> Kamion: hand what out?
<Kamion> mdz: userdefault, above
<thom> mdz: yeah, at mataro
<mdz> ah
<Mithrandir> did we decide on what ipsec implementation to go with?
<Kamion> (mostly) gone for the evening, night all
<mdz> Kamion: db_set seems to set the value, but the question is still asked
<mdz> Kamion: joeyh mentioned something about the seen flag being ignored
<mdz> Kamion: how does preseed make this work?
<mdz> doh, missed him
<fabbione> mdz: is it powernowd that loads all the cpu freq scaling modules?
<thom> yes
<fabbione> thom: you maintain it, right?
<thom> yeah
<jdub> thom: (start backing away now.)
<fabbione> you win 5103
<jdub> this is one of those question... question... BULLET IN HEAD things
<fabbione> daniels: ah now i remember... 5117
<jdub> oh man, people are talking about xpde on #ubuntu
<thom> fabbione: gee, thanks
<fabbione> thom: welcome :-)
<thom> evince is pretty sweet, btw
<fabbione> at least it's easy
* ogra thinks crimsun deserves the medal of patiency for supporting xpde installs.....
<jdub> thom: yeah, it's rad
<thom> i guess we give up on gpdf for bendy and pin on this
<thom> jdub: have you read dcbw's mail? NM is looking a lot saner, suddenly
<sivang> thom: gpdf allows for easier and through gnome cups printing, is xpde also?
<sivang> (in my experience)
<thom> sivang: we're talking about evince
<ogra> sivang: xpde is a win XP desktop clone for linux
<ogra> (the try of a clone though)
<sivang> oops, I was referring to the differences between xpdf and gpdf.
<jdub> thom: i got the colina followup ;)
<thom> sivang: yeah, that's evince
<thom> jdub: heh
<thom> jdub: and the original? :P
<sivang> thom: do we have a package for xpde?
<jdub> thom: lwresd and nss_lwres sound good
<jdub> thom: we should get them into universe :)
<thom> sivang: dude, i have no idea. like i said, i was talking about evince
<ogra> sivang: do you want to package it *g*
<sivang> thom: ah ok, sorry....ergh I read too much gtk internal code today..maybe time for a break :)
<thom> jdub: yes
<sivang> ogra: could be, yeah, my cousing would double his ubuntu systems in NYC if I get him a decent Xp desktop clone, he has already started moving some quite number of mahcines to ubuntu, and he was an MSDN subscriber..:)
<Nafallo> Mithrandir: ping?
<jdub> thom: replied
<jdub> thom: congratulating colin for his sex change, too
<thom> jdub: cool cool, i was leaving it till morning; i've been exhausted for no good reason today
<jdub> 08:21 < gjc> this is interesting, my xserver is keeping the state of capslock
<elmo> god mysqldump has such fucked-in-the-head option parsing
<jdub>              bound to the application currently with focus
<jdub> 08:22 < gjc> so if I turn capslock on then give focus to another window, it
<jdub>              turns itself off
<jdub> it's very cool
<jdub> 
<jdub> but i don't think most users would like it
<jdub> i'm reproducing that in hoary atm
<thom> capslock is crack
<sivang> evince looks nice, I wonder if it's better then gpdf, it has more top menu items that's for sure.
<jdub> it is already better than gpdf in terms of pdf support
<elmo> ogra: ?
<ogra> yup
<ogra> still errors ?
<elmo> ogra: mind some more comments on gcursor?
<ogra> go on :)
<elmo>  Description: the program gcursor is a cursor theme managing software
<elmo>   a little gtk program to change youre Xcursor with anitmated preview.
<elmo> animated and your
<ogra> ah, i see
<ogra> article....
<elmo> and the first line should be something more like "a cursor theme managing software", without the leading preamble
<sivang> jdub: has the emacs nifty incremental seach also, cooool
<elmo> second of all, you need to use lintian 
<ogra> i use debuild-pbuilder
<ogra> dpkg-buildpackage: source only upload (original source is included)
<ogra> Now running lintian...
<ogra> Finished running lintian.
<ogra> Now signing changes and any dsc files...
<ogra> seemed to go fine
<jvw> elmo: if you're talking about the ^the... vorlon kicked that test out
<elmo> ogra: third, sorry, I wasn't clear, the GPL is a special case, you don't include the full thing in the copyright file because it's already in base-files, so you put a pointer to it in the copyright file, see any GPL package (e.g. dpkg) for an example
<elmo> jvw: I think "the program gcursor is" is redudant personally
<elmo> ogra: do you have lintian installed?  'cos it certainly comes up with a lot of output
<ogra> ah, ok .... i already found the redundancy a bit bad....
<ogra> elmo: sure i have.... pbuilder ran it
<elmo> well something's broken then
<elmo> I mean see for yourself, run 'lintian gcursor*.deb'
<ogra> i just ran it on the dsc
<elmo> nah, you need to run it on the .changes or .deb
<elmo> jvw: is that lintian bug fixed in debian btw?
<elmo> the desktop one
<elmo> 'cos if it is, we should probably sync it
<ogra> nope, nothing on .changes .... i'll build a deb, wait a sec
<jvw> elmo: only in trunk
<jvw> elmo: this time, I *do* plan to do some QA before uploading :)
<elmo> ogra: dude, you did build a deb and test this before uploading, right? :p
<jvw> (the security issue over-rushed the upload)
<ogra> elmo: argh, sorry i did build several debs of it ....but before the changes...sorry
<ogra> ok...now i got all the errors...gah, dumb me
<elmo> jvw: ok, no prob, just checking
<jvw> elmo: the three most obnoxious checks introduced have been backed out in trunk
<jvw> are at least, made less easy to be triggered
<elmo> ogra: oh, one last thing, please document what you actually change in the changelog
<elmo> I think that was it
<sivang> mdz: do you think simple-cdd is something good to use as a installer cd customization for ubuntu's d-i? can I use it completely unchanged in ubunut?
<ogra> ok, i'll upload a new one in 10 mins....lets see then .... thanks for the effort :)
<mdz> sivang: I don't know what simple-cdd is, so I cannot answer that
<sivang> mdz: it's a custom debian distribution subproject I think, that allows you with some very few instruction and modifications to create a custome preseeded installer cd.
<Mithrandir> Nafallo: yes?
<Nafallo> Mithrandir: see #debian-amd64 :-)
<mxpxpod> this may be a really dumb question, but is beagle going to be included on hoary?
<mxpxpod> s/on/in/
<thom> mxpxpod: not too likely at this point
<mxpxpod> thom: ok
<mxpxpod> thom: is there any way to get it working on hoary? or do you have to install loads of cvs stuff?
<thom> it's pretty easy actually, the nastiest bit is gmime
<mxpxpod> thom: is there a guide somewhere?
<lamont> thom: out of curiosity - would you rather I had uploaded the fix for laptop-detect?
<sladen> mjg59: a thought, is vberestore 0x4f04 being called before PMinitialize to initialize the VideoBIOS state.
<kent> since no one could answere in #ubuntu, I'l try here. I saw the article from Davyd about gnome 2.10. It looked like the Hoary menu-design would be in Gnome 2.10, is that true? that would be very cool.
<thom> lamont: oh,eh. totally forgot
<lamont> thom: wasn't particularly meaning to prod you - was more curious in the general case
<sladen> mjg59: eg, when coming out S3, or on boot without vesafb loaded
<thom> lamont: i'm a bit concerned that it only just broke, what changed?
<jdub> kent: yes
<sladen> mjg59: it won't have been called by that time since the the Vesa Address grepping is done in 16-bit code
<thom> ah
<thom> lamont: ahr, guess you're seeing this on ia64?
<lamont> thom: uh, actually hppa. 
<lamont> and ppc, and ...
<thom> well, ppc survived all of ppc
<thom> all of warty, i mean
<mxpxpod> thom: how do I get thte dbus bindings for mono?
<mxpxpod> or the mono bindings for dbus :)
<lamont> thom: yeah, well. :-)
<lamont> I finally got observant.
<sjoerd> mxpxpod: libdbus-cil is in hoary's universe afaik
<mxpxpod> sjoerd: for ppc?
<sjoerd> dunno, should be
<thom> it probably needs to be given back
<jdub> you get bzip in, and people ask for 7zip
<jdub> daniels needs to fix libdbus-cil though
<mxpxpod> jdub: thanks
<lamont> mvo around?
<lamont> nm
<ogra> elmo ?
<elmo> ogra: yeah, I just rejected the old 3 from NEW, you can reupload it if you like
<ogra> elmo ah great....i was fearing i had to raise the version number and was wondering why :)
<ogra> so next turn then....
<elmo> ogra: 'animated' still in the long description.. trivial tho, not worth an upload just for that
<elmo> other than that it looks good
<Nafallo> ubuntu-bugzilla is here to stay or could we expect a replacement? :-P
<ogra> wow, finally.....fixing broken universe pkgs is quite easier
<elmo> Nafallo: there's working being done on a replacement bug tracking system
<elmo> gar sf mail archives are satanic
<elmo> do thhey have a "download an mbox" type facility, does anyone know?
<Nafallo> elmo: good :-). it's a bit awkward to sign bugs against UNKNOWN when you know EXACTLY what package that need the change ;-).
<ogra> Nafallo: preview: https://launchpad.ubuntu.com/malone
<kent> ogra, so ubuntu is not going to use bugzille later on?
<thom> jdub: did you cc me on your response, or just to the list?
<ogra> i dont think so
<jdub> just the list
<sivang> kent: take a look at malone launchpad.ubuntu.com/malone
<Nafallo> ogra: I think I'm in love :-).
<ogra> heh
<ogra> Nafallo: take a look at rosetta too....its quite cool
<Nafallo> ogra: going :-)
<sivang> Nafallo: with Ubuntu?
<Nafallo> sivang: malone + rosetta :-)
<Nafallo> sivang: ubuntu on the other hand, I'm not sure about. drains my batterylife at 200% compared to deb :-P.
<Nafallo> if not more...
<sivang> Nafallo: this is being worked on, should be no problem at future IIRC.
<Nafallo> sivang: yepp, and til sarge is released this is the choice for amd64 :-).
<ogra> Nafallo: youre on amd64 ?
<Nafallo> ogra: yepp. 1.6GHz, 1024MB RAM and still lappy ;-).
<sivang> Nafallo: rosetta and malone are way cool, yes.
<Nafallo> sivang: they might be a reason to follow Ubuntu even longer :-).
<ogra> Nafallo: 2.0 512MB lappie too ..... (and i wont give it away anymore)
<Nafallo> sivang: I COULD run fluxbox without security updates I guess ;-).
<Nafallo> ogra: no, why would you want to do that? :-)
<ogra> heh
<thom> Nafallo: 200% comparing with the same software load and the same workload
<sivang> Nafallo: you can, but well, you'd miss the good love of gnome :-) ah well, I guess it's lighter and drains less cpu cycles thus less battery :)
<ogra> elmo....looking at the build logs....is it true that all dependencys are installed and removed for every single build ?
<thom> ogra: that's the idea, yes
<Nafallo> thom: I try not to run unsupported things, but then again, I COULD ditch ubuntu-desktop if I wanted to ;-).
<ogra> why that ? that slows down the process a lot i imagine.....
<thom> Nafallo: that really wasn't what i asked
<thom> Nafallo: are you comparing like for like?
<Nafallo> thom: then, the simple answer would be no.
<elmo> ogra: to ensure things are only compiled with what they asked for
<ogra> but wouldnt it be faster to leave everything in place and just update missing bits and pieces ?
<elmo> yes, but buildds aren't short of time
<sivang> elmo: hmm, that can point some really nasty missing dependecies which would never appear on a regular preinstalled build system. This is also the case for debian?
<ogra> ah, ok....
<sivang> ogra: or be elusive of the update bits scrips IMHO
<sivang> :)
<elmo> the expensive things for buildds is the human time needed to fix build failures, not the time needed for successful builds 
<sivang> elmo: two of them are POWER machines right?
<Nafallo> thom: ubuntu will however grew and universe could be more or less community supported. that's the plan right? to, at some time, pull in security support for universe?
<jdub> yeah
<elmo> sivang: debian doesn't do source only uploads, so one architecture is usually built in a messy environment, but basically yeah
<jdub> either moving stuff to main, or doing community security for universe
<jdub> s/either/both/
<elmo> sivang: hmm?  there's 3 buildds of each architecture (i386, amd64, powerpc, ia64), the powerpc ones are Apple G5's
<Nafallo> jdub: in other words, I should probably stay with ubuntu on lappy instead of moving to etch :-). (rosetta and malone convinced me ;-)).
<sivang> Nafallo: ubuntu does so much good in catering for kernel updates, and laptop support already, that you would be better staying with it even without rosetta and malone :) I happen to have enjoyed the fact I don't need to recompile my kernel on the lappie everytime nvidia udpates their driver :) 
<Nafallo> sivang: seems easier to contribute here than in debian to :-).
<sivang> Nafallo: you wouldn't even imagine how much ...:) my test case is a good example I think.
<ogra> Nafallo: wanna become a MOTU ?
<Nafallo> ogra: if you explain the last word(s) maybe ;-).
* T-Bone gets that Queen song running in his head everytime he sees something about 'MOTU' ;)
<ogra> Master of the universe :)
<ogra> ...universe maintainer.....
<thom> yes, hence the queen song :-)
<Nafallo> ogra: I'll have to learn packaging first I believe? just have to find time to study that :-/.
* Nafallo HATES that damn favicon on launchpad :-P *
<elmo> queen song?  dude, it's all about He-Man
<jdub> I HAVE THE POWER!
<ogra> Nafallo: its quite easy to learn, just start with a program you like and package it for yourself for a while :),,,,there are a lot of helper tools that ease the work....
<T-Bone> elmo: heh. Can't help it. I'm a Queen fan no matter what. And if you've seen Highlander, it's even worse :^)
<Nafallo> ogra: the problem is I want to learn from scratch and have an auto-ditch on helper-tools ;-).
<Nafallo> ogre: I've already signed some ITPs for my WLAN-driver in debian though :-).
<ogra> Nafallo: hmm, setting up a debian directory in a source tree can become a pain i imagine :)
<Kamion> mdz: easy, db_fset <question> seen true
<Nafallo> ogra: from what I've seen it's not THAT hard :-).
<Kamion> mdz: that's exactly what preseed does
<mdz> Kamion: ok, thanks
<mdz> I was confused by this:
<mdz> Jan 13 16:09:11 <joeyh> that wouldn't happen in d-i since we ignore seen flags
<Nafallo> ogra: just need time to read through everything ;-).
<ogra> Nafallo: thats what i thought....until i uploaded my first _own_ package today....
<Nafallo> ogra: congrats! :-D
<Kamion> mdz: well actually it's not quite what preseed does, it calls debconf-set-selections, but same difference
<thom> 2.6.10 seems to do less well under load that previous kernels here, anyone else care to corroborate?
<ogra> Nafallo: thanks :)
<Kamion> mdz: I think joeyh must have been referring to something subtly different, I'm slightly confused by what he meant by that
#ubuntu-devel 2005-01-30
<Kamion> <cjwatson@cittagazze ~/src/debian/debian-installer/trunk/debian-installer/packag
<Kamion> es/debian-installer-utils>$ grep fset debconf-set-selections
<Kamion>         db_fset "$var" seen true
<mdz> Kamion: how big a job would it be to add an overall progress meter to d-i?
<elmo> that'd rock
<jdub> rawk
<elmo> that too
<jdub> ogra: see ubuntu-devel list :)
<Kamion> mdz: requires fixing the cdebconf progress protocol to allow multiple simultaneous progress meters
<Kamion> I've thought about it in the past; I think the advantage will be much greater with the gtk frontend than with newt though
<ogra> jdub: yay, thanks :-D
<mdz> thom: CPU or I/O?
<jdub> ogra: but now i'm going to file bugs
<ogra> jdub: go on :)
<Kamion> also requires working out where the hell you actually are - before you've retrieved udebs, you don't actually know
<mdz> Kamion: it would do very good things for the user experience, even in newt I think
<mdz> good point
<jdub> ogra: kidding ;)
<thom> mdz: cpu
<mdz> that's a relatively short way into the process, at least with cdrom
<Kamion> I suspect some kind of waypoint system like in base-installer would be useful
<mdz> and we could fake it
<Kamion> mdz: would like not to be completely wrong with monolithic though :-)
<ogra> jdub: :)
<Kamion> I'll have a look if you think it's really nice-to-have, can't bump away feature goals at the moment though
<Kamion> mdz: (hey! could abuse menu-item numbers ...)
<mdz> Kamion: the path to the cloop image is now a debconf variable
<mdz> Kamion: do you think we should set it in debian-cd land rather than using the hardcoded default?
<Kamion> I was just about to ask that
<mdz> since debian-cd decides where to put it
<Kamion> yes, I think that would be a good idea; file a bug on debian-cd please?
<Kamion> I'll do that tomorrow
<mdz> will do
<elmo> mdz: how do you normally pass a password to mysqldump?
<mdz> Kamion: hmm, it has /cdrom in it
<mdz> elmo: interactively, I use -p (no arg)
<mdz> non-interactively, I use this awful shell/perl construct
<sladen> echo password | mysqldump -p
<elmo> sladen: doesn't work
<sladen> or mysqldump -p=password  if you don't mind it being in the shell history
<elmo> sladen: and more to the point, in ps output while it's running
<elmo> which for non-trivial databases is a reasonable amount of time
<elmo> mdz: wah
<elmo> I can feel a case of expect coming on
<mdz> elmo: you want my monstrosity?
<Nafallo> bbl
<Nafallo> night
<sladen> I haven't needed it before
<sivang> jdub: ping
<mdz> elmo: oh, wait
<mdz> elmo: you said mysqldump
<mdz> elmo: this is for unattended backups, and not for a maintainer script
<mdz> ?
<elmo> yes
<mdz> elmo: you can stash the password in a file
<elmo> I tried that?
<mdz> ~/.my.cnf by default
<mdz> section [mysqldump] 
<elmo> oh, MAH
<elmo> defeated by cut'n'waste
<elmo> hmm, or not
<elmo> mdz: mmk
<mdz> what's the least horrific shell idiom for "iterate over the files matching this glob, but if the glob doesn't match anything, do nothing"?
<sivang> jdub: just saw the thread from shlomil regarding the language pack dependecies, I already talked about this with pitti and you in MAtaro, what needs to be done for the culmus pakcage to get into main so pitti could depend on it in the language pack package?
<jdub> approval from mdz/myself
<jdub> i've already given mine
<sivang> mdz : are you ok with jdub approving or would you like a TB meeting for this?
<sivang> jdub: coool
<jdub> oof, this stuff doesn't need TB meeting bureaucracy
<mdz> sivang: it needs to meet the criteria in the wiki
<jdub> TB/CC are meant to be last resorts
<mdz> http://www.ubuntulinux.org/wiki/SeedManagement
<mdz> under Supported
<sivang> main/supported right?
<mdz> "Supported" is the section heading
<elmo> mdz: hmm, sorry how does the mysqldump thing in my.cnf help?  and is there a man page for that file?
<mdz> elmo: each tool looks up its config in a section named after it
<mdz> so you can specify different parameters for different programs in the one file
<mdz> /etc/mysql/my.cnf is an illustrative example
<mdz> it's documented in the mysql manual, iirc
<mdz> [mysqldump] 
<mdz> password = XXXXX
<mdz> doesn't work?
<mdz> (it did for me under woody, where I did this in production)
<mdz> note that you don't specify the -p option if you do that
<elmo> uh, where XXX is the password?
<mdz> yes
<elmo> it's a 644 file dude
<mdz> ??
<mdz> then make it 600
<elmo> it's 644 by default
<elmo> should we fix that?
<mdz> oh, you're talking about /etc/mysql/my.cnf? don't put it there
<elmo> oh GOD
<mdz> Default options are read from the following files in the given order:
<mdz> /etc/mysql/my.cnf /var/lib/mysql/my.cnf ~/.my.cnf
<elmo> sorry, I get it now.  I neeed more tea
<mdz> or use --defaults-extra-file=<path>
<sivang> mdz: it already meets (1) , (2) I can try and check , am willing to port it to arch if this is a must, and I think it would pass asecurity review because basically it copies files from the debian package to some place on the host system, what else?
<sivang> mdz: merely a repository of fonts..
<mdz> Kamion: sshd won't let users login remotely with blank passwords by default, right?
<mdz> Kamion: do you think it's necessary to set a password on the live CD?
<T-Bone> mdz: need to usermod -U
<elmo> mdz: score - working now, thanks.
<mdz> sivang: if it's just data (no programs), then (2) should be easy
<mdz> sivang: and fonts don't generally need porting, either
<sivang> mdz: yes very much, the rules files is even pretty standard and doesn't do nothing but a couple of dh_install stuff
<sivang> mdz: true, it has one target for all archs.
<kent> I just installed gcursor mentioned here before.  Why have the theme-manager not support for changing cursor-theme?
<jdub> kent: because no one's written it yet
<mdz> mjg59: here?
<sivang> mdz: only one issue, is if you want the files to reside in some other place then the current, oh and it does install to some of the X11 fonts dirs.
<mdz> daniels: alive?
<mdz> sivang: fine with me, then
<ogra> has anybody else weird font probs in evo (looks like gtkhtmls font rendering cant decide on the right fontsize)
<sivang> mdz: ok, coool. btw, does it need a maintainer to go with? :) although I'm pretty sure it could go by itself, and if there's a problem with it I don't mind to be the address for that.
* T-Bone calls it a nite. bye all
<mdz> sivang: is this a package you made, or did someone else make it?
<Kamion> mdz: don't see a problem with /cdrom, enough of d-i assumes it that I think debian-cd can get away with doing so too
<mdz> Kamion: should I prepend /cdrom in casper, and expect a relative path in debconf?
<mdz> or is it ok for the full path to be in debian-cd?
<Kamion> mdz: PermitEmptyPasswords is off by default, yes, although I'd test carefully if I were you
<Kamion> mdz: no, I think it's better for the full path to be in debian-cd in order that you can change it to be off an NFS mount or whatever
<mdz> Kamion: good call
<Kamion> mdz: apt 0.5.28.1 is supposed to be OK for sarge?
<Kamion> seems ok
* Kamion contemplates switching the weekly DVD to be install+live
<Kamion> ... maybe not today
<mdz> Kamion: yes
<mdz> Kamion: did you look into that issue with the ipw2200 firmware?
<Kamion> not yet
<Kamion> mdz: I did mention that the firmware is there but with a different name than it used to have, didn't I?
<Kamion> my money's on something looking for the old name
<sivang> mdz: it made by baruch even, a DD
<mdz> Kamion: oh, so you think it's a kernel problem?
<Kamion> well it's certainly in the udeb ...
<mdz> looking at it now
<Kamion> unless that's not being installed for some reason
<mdz> it's trying to loadipw-2.2-boot.fw
<mdz> /lib/hotplug/firmware/ipw-2.2-boot.fw-<version> exists
<Kamion> -rw-r--r-- root/root      6472 2005-01-17 18:04:55 ./lib/hotplug/firmware/ipw-2.2-boot.fw-2.6.10-2-386
<mdz> maybe this is the timeout problem keybuk talked about
<Kamion> what problem was that?
<mdz> he said that the driver didn't wait long enough for the firmware to be loaded by hotplug
<mdz> and that this would become a problem when we switched to udevsend
<mdz> odd
<mdz> I just added some logging to firmware.agent and it doesn't show up
<mdz> it clearly works in the installed system (including the live CD), though
<Kamion> any reason why the firmware agent might not be called?
* Kamion hopes nothing's hardcoding /sbin/hotplug or something
<mdz> I don't see how it could
<mdz> the kernel invokes the hotplug helper
<mdz> and it's set to /sbin/udevsend
<Kamion> I meant in the kernel :)
<mdz> ah
<Kamion> any easy way to get udevsend to log everything it gets?
<sladen> Kamion: it's hard-coded in the kernel but you can set it by echo/cat'ing /proc/sys/kernel/hotplug
<mdz> +       rc = request_firmware(fw, name, &priv->pci_dev->dev);
<mdz> the driver doesn't seem to do anything weird
<mdz> most likely all firmware loading is busted
<mjg59> sladen: Uh. PMInitialize?
<mjg59> mdz: Hi
<mdz> mjg59: I wanted to know how to determine whether a swap device was holding swsusp data
<mdz> mjg59: so that the live CD would not touch it
<mjg59> mdz: Ah, right. There's a header right at the start - the struct is defined in kernel/power/swsusp.c (IIRC)
<mjg59> swapon -a will refuse to mount it
<sladen> mjg59: Protected-Mode Initialize ;  you're supposed to call that to initial the Video BIOS before you make any 32-bit VBE calls.  Is there a chance that when coming out of S3, or on bootup (that hang issue you had), that isn't happening?
<mdz> oh
<mdz> yeah
<mdz> it seems to overwrite the swap space signature
<mdz> so that's perfect
<mdz> and the bug won't exist in the first place
<mjg59> sladen: We don't make any 32 bit VBE calls
<sladen> mjg59: how the nack are you doing vbesave ?
<mjg59> 32 bit entry to VBE is optional - AFAIK, lots of cards don't do it
<mjg59> Real mode
<mjg59> lrmi does vm86 real-mode emulation
<jdub> mdz: hrm, when's the next livecd build? lots of nice uploads i see ;)
<jdub> tseng: ping
<Kamion> sladen: hotplug> yeah, that's what I understood certainly and d-i sets that sysctl, was just wondering if there could be a bug somewhere
<Kamion> jdub: 1 8 * * *       /srv/cdimage.no-name-yet.com/bin/cron.daily-live
<mjg59> sladen: To the best of my knowledge, neiter vbetool nor the kernel ever makes any 32-bit VBE calls
<Kamion> although many of today's uploads require the debian-installer I uploaded tonight to become active, which requires elmo's byhand
<Kamion> ... which he's already done. rocks.
<Kamion> rock.
<mdz> jdub: it's mostly under-the-hood stuff, though
<mdz> jdub: much cleaner, but if I've done it right you won't notice any difference
<mdz> Kamion: I haven't been able to test the passwd stuff properly, since it needs a new cloop image, but I think it should work
<mdz> it creates the user OK, but the group and sudo stuff is missing, since that isn't in the old version
<mdz> I need to find a clever way to unmount the root filesystem and eject the CD
<Kamion> the udeb retrieval stage should be shorter now, jdub was asking about that recently I think
<mdz> s/asking/bitching/ :-P
<mdz> jdub: *hug*
<Kamion> mdz++
<lamont> mdz: doesn't 
<lamont> eject work?
<mdz> lamont: I bet it would
<mdz> lamont: but it's hard to get to after unmounting root
<lamont> works on the warty livecd, albeit fatally, and only as root...
<mdz> the closest I can think of so far is to create a min-chroot and pivot into it
<mdz> or modify init; amu pointed out that knoppix takes that approach
<Kamion> haha, WinXP fails to deal with my amd64's SATA drive
<mdz> probably the easiest way would be to simply _not_ unmount the d-i initrd
<mdz> and then pivot back into it
<mdz> but it's huge and occupies a lot of memory just for that
<lamont> ew!
<lamont> remount root as readonly, then eject
<mdz> I don't think that remounting r/o will release the device
<mdz> nor should it?
<mdz> is there an eject --i-really-mean-it
<lamont> eject hasn't been seen to care if the device is in use or not, at least not by me....
* lamont tests
<mdz> lamont: eject tries to unmount if it's mounted
<mdz> otherwise it will fail
<jdub> mdz: didn't mean to be bitching
<mdz> jdub: just teasing
<lamont> yeah - shows busy
<lamont> bummer
<mdz> jdub: your live CD feedback is R0X0R
<jdub> so how many udebs were optimised out (roughly)?
<jdub> were we able to skip much of the kernel module ones, if the kernel is in the main image?
<mdz> we didn't try that
<mdz> it would require some significant changes
<mdz> there's no way to get to the image until casper is unpacked
<Kamion> jdub: deliberately didn't attempt to skip the kernel modules
<mdz> and casper is unpacked at the same time as everything else
<Kamion> took out the ones that are there to be menu items, so base-installer, archive-copier, prebaseconfig, {grub,lilo,yaboot,...}-installer, all of partman
<mdz> thom: you stole my stopwatch, you bastard
<jdub> ahr
<mdz> thom: you'd better bring it to sydney
<Kamion> maybe a dozen or so at a rough guess, although I didn't count
<jdub> Kamion: elite
<mdz> tomorrow's live CD improvements are all behind the scenes ;-)
<mdz> if it works, we win
<Kamion> jdub: I tried skipping all standard udebs including kernel modules; didn't work, network configuration failed because it didn't have nic-*
<mdz> Kamion: why is it that all of /etc/hotplug is world-writable under d-i?
<daniels> Kamion: yah
<mdz> does udpkg do that deliberately or something?
<daniels> er
<daniels> mdz: yah
<Kamion> mdz: uh, shouldn't
<mdz> daniels: I think I was looking for an informed opinion on sivang's X fonts package
<mdz> Kamion: is it just me?
<mdz> Kamion: oh, that's on the initrd
<mdz> maybe genext2fs is stupid about permissions?
<mdz> /bin/busybox is 777 too
<Kamion> yes, apparently so
<Kamion> it's like that in warty too
<Kamion> (just happened to be booting a rescue CD^W^Wwarty amd64 CD)
<daniels> mdz: oh
<daniels> mdz: server-side fonts are pretty hard to get wrong
<mjg59> fabbione: There's a possibly important fix in the current ACPI patch - I'll get more details to you tomorrow
<mjg59> daniels: CRACK?
<daniels> mjg59: uploaded
<elmo> crap, it'd probably help if I actually filter @ubuntu.com somewhere other than spam wouldn't it
<mjg59> daniels: I would offer to fellate you, but I feel you might turn me down
<tseng> jdub: hiya
<jdub> tseng: dude, three people have already asked me about tomboy 0.3, and it was only released today ;)
<jdub> tseng: you got yourself a popular package ;)
<tseng> hah :P
<jdub> tseng: perhaps it could be your first universe upload? :)
<mdz> Kamion: not even /etc/hotplug.d/default/default.hotplug is called when the firmware is requested
<Kamion> mdz: that's a bit depressingly bad
<mjg59> Haha
<tseng> jdub: sure, i can check out the update here in a few, having some dinner
<mjg59> I've shocked daniel into silence
<jdub> tseng: rawk :_)
<jdub> tseng: and mono is fixed too!
<tseng> hell yes it is
<mjg59> fabbione: We need ACPI CA 20050114
<Kamion> mdz: nothing seems to be obviously missing from hotplug-udeb
<Kamion> my money remains on the kernel
<sivang> ubuntu.com now replaces canonical.com for employee distro people?
<Kamion> yes
<sivang> oh
<mdz> request_firmware is returning -ENOENT
<Kamion> sivang: partly to try to help erase the distinction between Canonical and non-Canonical distro hackers
<daniels> mjg59: it's entirely possible
<mdz> the configured hotplug handler is getting called
<mdz> with a firmware add event
<mdz> and reasonable arguments
* mdz yearns for strace
<Kamion> do you have libc6-udeb installed yet?
<mdz> I'm at netcfg
<Kamion> if so, udpkg -i /cdrom/pool/main/s/strace/strace_*.deb
<mdz> is libc6-udeb something that gets installed automagically?
<Kamion> might need to udpkg -i /cdrom/pool/main/g/glibc/libc6-udeb_*.udeb too
<Kamion> mdz: yes
<sivang> Kamion: that's what I though, ok.
<mdz> strace isn't on the live CD, but I could copy a deb I suppose
<Kamion> it's depended upon by various bits that get pulled in by anna
<Kamion> USB storage?
<mdz> yay
<mdz> (I have wired network as well)
<sivang> mdz: wired network is the best :)
<daniels> woo, more video cards :)
<mdz> GAH
<mdz> busybox tar doesn't support creating tar files??/
<Kamion> nope
<mdz> Kamion: found it
<mdz> /etc/hotplug.d/default/default.hotplug is #!/bin/bash
<mdz> %^@#$%@#$
<Kamion> haha
<Kamion> silly hotplug people
<Kamion>     if [ -t ] ; then
<Kamion> wonder what that's meant to mean
<mdz> probably tests if stdout is a terminal
<mdz> Kamion: changing it to #!/bin/sh worked perfectly
<mdz> a quick read didn't reveal any obvious bashisms
<Kamion> mdz: -t is only documented to take a file descriptor; none of SUSv3, bash(1), test(1) document what it might do when given no arguments
<mdz> it comes as #!/bin/bash from upstream
<Kamion> mdz: yeah, I checked too, there are a few bits of test -a/-o junk in hotplug.functions but that's fine in busybox sh anyway
<mdz> Kamion: if you're satisfied, I plan to patch it immediately
<Kamion> satisfied
<elmo> mdz: I don't understand this mail about kdelibs - are you saying it's depending on something that should be pulled into main?
<elmo> 'cos anastacia disagrees
<elmo> in fact kdelibs isn't even in main, I'm entirely confused
<mdz> elmo: I sent you mail about kdelibs?
<elmo>  . [  24: Matt Zimmerman      ]  Re: oo.o2 FTBFS
<daniels> blegh
<mdz> elmo: oh, I was probably thinking oo.o2 was going into main
<mdz> which it probably ought
<elmo> for HOARY?
<mdz> that's the plan
<sivang> mdz: did you approve the fonts package then? (I think I saw you say you're reviewing it)
* elmo runs away screaming
* sivang notes it has some rocking hebrew support. woudl be cool to see it in hoary. nearly zero effort hebrew ena/loc distro :)
<daniels> elmo: the old fglrx-driver diverts away libGL.so.1, but I'm moving that diversion into xorg-driver-fglrx.  moving the diversion removal as an unconditional in postinst doesn't help, because fglrx-driver is unpacked but not configured before xorg-driver-fglrx, despite the conflcits.  is there a pre-depends, only for conflicts?
<mdz> elmo: it doesn't replace v1, so we can take our pick when we're ready
<daniels> elmo: i.e. have xorg-driver-fglrx declare that it can't unpack while fglrx-driver << 8.8.25-0ubuntu2 is configured
<mdz> daniels: that's "Conflicts"
<elmo> only unversioned I think
<daniels> mdz: can't
<Kamion> if you conflict with something then you can't exist on the system at all at the same time as it
<mdz> hm?  a versioned conflict would force the new fglrx-driver to be unpacked before xorg-driver-fglrx
<daniels> mdz: i conflict fglrx-driver << 8.8.25-0ubuntu2 already, but it only gets *unpacked*, not configured
<daniels> mdz: yeah ...
<mdz> daniels: you should be removing the diversion in preinst
<daniels> mdz: and that will dtrt?
<mdz> daniels: preinst is called before unpacking
<mdz> so it would go: fglrx new-preinst, fglrx unpack, xorg unpack
<daniels> mdz: mmm, but if you're upgrading, wouldn't that arse around with diversions?
<mdz> daniels: isn't that the point?
<daniels> mdz: fglrx new-preinst removes diversion, fglrx new-unpack removes libGL.so.1, so your xlibmesa-gl copy of libGL.so.1 is gone ...
<mdz> the diversion is gone in the new fglrx
<mdz> so on upgrade it should be removed
<daniels> correct
<daniels> given fglrx-driver no longer ships libGL.so.1
<mdz> I don't see the upgrading/arse problem
<bob2> the new acpi-support disables suspend-to-ram by default
<bob2> that seems slightly silly
<daniels> ok, I'll try to explain what I fear may happen
<daniels> original: old fglrx-driver unpacked; scenario: dist-upgrade
<daniels> first, new fglrx-driver preinst runs, since the old one had no pre* scripts, right
<daniels> and removes the libGL diversion, so /usr/X11R6/libGL.so.1 is now xlibmesa-gl's
<daniels> then new fglrx-driver gets unpacked, and as it's no longer providing libGL.so.1, libGL.so.1 gets removed
<daniels> so xlibmesa-gl's copy is gone until you unpack that again
<mdz> that doesn't happen
<mdz> dpkg knows which package the file belongs to
<mdz> it won't remove xlibmesa-gl's file just because it's not in fglrx-driver
<daniels> ok
<daniels> so no adverse affects from removing the diversion in preinst?
<mjg59> bob2: We'll probably switch to enabled by default, but it's known broken on some percentage of hardware
<mdz> that is the correct way to handle this situation
<mdz> if I understand correctly
<daniels> mdz: if it's not, I'll beat Keybuk up *shrug*
<mdz> neither xorg-driver-fglrx nor fglrx-driver contains the file, right?
<mdz> they just both divert it
<mdz> or do they divert it and also contain the file in the .deb?
<mdz> if they contain it in the .deb, you need to be doing the diversion stuff in preinst anyway
<bob2> mjg59: yeah, it's just that it was enabled until I upgraded to acpi-support 0.12
<bob2> so I was kinda confused when it stopped working ;)
<lamont> mdz: would it be a bad thing if I added hppa to linux-meta?
<mdz> lamont: bad? no.  silly? maybe
<mdz> as long as it doesn't break it on real architectures...
<lamont> it's just the meta packages
<daniels> mdz: divert and also contain
<lamont> shouldn't break anything
<lamont> (hppa has 783 of 822 packages in main built)
<jdub> lamont: wooo
<tseng> jdub: have a package here for latest and greatest tomboy
<tseng> i hopefully fixed alot of retardation i caused on my first attempt at packaging it
<jdub> that'll slow down the heat death of the universe :)
<sivang> tseng: yay!
<Kamion> jdub: given the amount of heat an hppa puts out? :)
* sivang LOLs
<daniels> mdz: my system is now very, very, very confused
<jdub> Kamion: cheques and balances ;)
<daniels> mdz: Removing `diversion of /usr/X11R6/lib/libGL.so.1.2 to /usr/share/fglrx/diversions/libGL.so.1.2 by fglrx-driver'
<elmo> hppa's aren't that bad
<daniels> dpkg-divert: rename involves overwriting `/usr/X11R6/lib/libGL.so.1.2' with
<daniels>   different file `/usr/share/fglrx/diversions/libGL.so.1.2', not allowed
<lamont> jdub: ia64 is much hotter than hppa
<jdub> wow-wow-wacka-wacka
<mdz> daniels: that looks like "you told me to undivert the file, but there's a file in the way
<mdz> daniels: that's on dpkg-divert --remove?
<mdz> I suppose that's a reasonable complaint
<Kamion> last hppa I was anywhere near sounded like nothing else than an aeroplane taking off when booting
<jdub> mine is hot and noisy
<jdub> and not hugely useful
<jdub> and HPUX is horrific
<mdz> sounds like a typical hppa machine
<daniels> mdz: that's on --remove, yes
<lamont> jdub: the one I care about is my firewall
<daniels> mdz: that's fglrx-driver trying to remove its own diversion in the new preinst
<mdz> daniels: while its file is still in the way
<lamont> b180's aren't very noisy.  The rack-mount machines are kinda bad though
<daniels> mdz: any other suggestions?
<mdz> daniels: rm -f ? :-P
<lamont> hrm.. do we care that the version of linux-meta won't match the api version of the kernel any more if I do this upload?
<mdz> daniels: if this is all for the sake of renaming the package, there will be trouble
<daniels> mdz: not just renaming, splitting
<daniels> mdz: xfree86 and xorg
<lamont> hasn't before, so it shouldn't matter
<daniels> mdz: (but it was a really stupid name anyway)
* lamont uploads, goes to fire training
<mdz> daniels: can't you get rid of fglrx-driver entirely?
<Kamion> linux-restricted-modules-2.6.9 produces a load of uninstallable binaries according to britney; should we just kill it?
<mdz> daniels: and just conflict with it (all versions)?
<daniels> Kamion: uninstallable how?
<daniels> mdz: mmm, probably
<mdz> Kamion: yes
<mdz> Kamion: and the corresponding linux-source too
<Kamion> the corresponding linux-source is already gone
<daniels> mdz: will apt dtrt and remove fglrx-driver if xorg-driver-fglrx/xfree86-driver-fglrx crp it?
<Kamion> which probably explains why that l-r-m no worky
* daniels reads u-d and stares at sladen.
<daniels> sladen: ... so much pain
<mdz> daniels: you just need to conflict
<mdz> daniels: though rp is good documentation
<daniels> mdz: 'kay, thanks
<Kamion> elmo: could you kill linux-restricted-modules-2.6.9 and everything in it from main, please?
<Kamion> germinate doesn't seem to want it there any more
<Kamion> lamont: any idea why i386 hasn't tried to build efibootmgr?
* lamont looks
<lamont> wanna-build -bi386/build-db -dhoary --info efibootmgr
<lamont> efibootmgr: not registered
<lamont> PaSA
<Kamion> odd, Debian has it for i386+ia64
<lamont> efibootmgr: ia64                                                      # ia64 specific
<Kamion> elilo: ia64                                                           # ia64 specific boot-loader
<Kamion> so why do we have elilo/i386?
* lamont shrugs
<Kamion> either we should have both elilo/i386 and efibootmgr/i386, or neither
<Kamion> having the first but not the second is broken. :)
<lamont> does elio have any arch: all components?
<Kamion> no
<Kamion> it does list i386 in Architecture:
<lamont> elilo: i386 ia64                                                      # ia64 specific boot-loader
<Kamion> as does efibootmgr, mind
<lamont> in any case, fixing hoary is an elmo edit
<lamont> fixing debian I could do, if you tell me what you want it to say...
<lamont> but I'm supposed to be at fire training in < 1 minute, must really run
<Kamion> lamont: bdale added i386 to the list of supported architectures in elilo 3.4-4; I assume he knew what he was doing, so I figure i386 ought to be added to both elilo and efibootmgr
<Kamion> and efibootmgr 0.4.2-2
<sladen> there's an i386 floppy disk with EFI on it that you can download and play with
<tseng> jdub: ping
<mdz> sladen: if you're feeling nostalgic about MS-DOS?
<sladen> :)
<eruin> any chance we'll see beagle in universe/multiverse?
<mdz> someone asked that about an hour ago
<eruin> lol
<mdz> is it beagle day?
<eruin> sorry
<sivang> mdz: beagle love day :)
<eruin> it's mentioned on slashdot
<tseng> eruin: probably not until it stops deping on cvs packages
<eruin> + planetgnome
<mdz> ah
<eruin> plus they have a pretty, pretty screenshot
<eruin> which always helps grab attention :P
<robertj> is the bootsplash still planned for hoary
* sladen whistles and looks at ceiling
<ogra> lol
<eruin> anyone here in the know about gnomevfs packages?
<sladen> robertj: it's unlikely that the 'bootsplash' package with ever make it into Ubuntu.  It's too evil.
<robertj> err not bootsplash
<robertj> usersplash
<sladen> robertj: hopefully
<robertj> are there experimental packages being built somewhere for hoary usersplash?
<robertj> I know it was supposed to come in along super phat laptop support
<Nafallo> hi again. where can I read about a MOTU's dutys? :-)
<kent> usersplash sure sounds promising.  :)
<eruin> or just plain sexy
<sladen> robertj: there should be a separate usplash respositary for people to test in the next week or two
<sladen> robertj: with the various packages to enable it
<robertj> that will be good
<robertj> I noticed the other day I closed my laptop lid and opened it and it was very boring
<robertj> even XP acts very interesting when I do tha
<tritium> sladen, where will the usplash repo be announced?
<robertj> so all in all a good sign
<sladen> robertj: what sort of interesting thing?
<sladen> tritium: on the mailing lits
<robertj> sladen: well it locks up or sits there with no mouse input
<robertj> but with hoary it just opens
* Nafallo starts to wonder who he should ping ;-) *
<sladen> robertj: is that just the lid turning the screen off, or is it actually going to S3?
<robertj> I think it's actually sleeping
<sladen> robertj: mjg59 is the person to thank for that
<robertj> i need to probe around the logs
<tritium> strange things happen when I suspend and the close the lid
<sladen> tritium: try updating, there was a kernel rev last night and some more stuff went in which may fix the Interrupt routeing and non-waking
<tritium> sladen, okay, will do.  Thanks.
<sladen> robertj: back to the question.  What kind of ''interesting thing'' does XP do---just that it close and when re-opened it still works?
<robertj> not it stops working in interesting ways
<robertj> wifi stops working or pancs
<robertj> sometimes no input is handled ,etc
<robertj> how can I tell for sure if it's properly asleep
<robertj> I close the lid, open it and get a black terminal for a second before the screensaver is activated
<tseng> its not quite like that, its more like it stored the state from X before the lid close
<tseng> and then updates to the current, which has a locked screen
<tseng> youll notice the first image you see is way behind if something on the screen is updating, like your irc client
<robertj> dunno, it happens pretty quick, maybe it aint
<robertj> what should I be looking for
<tseng> you could sleep 10 and echo something i guess
<tseng> close the lid, wait 10, open
<ogra> if it really sleeps you wont be able to ping it
<tseng> the first thing you see should have no echo yet
<robertj> doh
<robertj> it's pinging
<tritium> I can ditch this grub splash image I made once usplash is available: http://mip-lab4.ecn.purdue.edu/~rimbert/ubuntu-splash.xpm
<robertj> i'm still feeling so-so about the default colorscheme
<tritium> it has grown on me.  I used to be a big fan of debblue
<robertj> ThinGeramik with Crux & Gartoon are great
<robertj> clean but fun
<robertj> I think ThinGeramik is hands down the best widget set though
<eruin> I like the ClearLooks / Industrial / Human combination
<eruin> http://appelsinjuice.org/Skjermdump.jpg
<sladen> robertj: is this is XP, or Warty, or Hoary?
<tritium> What's that icon that looks like 3 shirts stacked on each other, slightly offset?
<eruin> oh, it's the theme manager thing
<tseng> thats the icon for theme-manager
<tritium> oh, okay
<sladen> tritium: usplash is more of an 'engine'.  It still needs something to display and if you're got some funky ideas for you'd like to see or some out of this world-ideas that nobody has seen before, I'd love to hear them!
<tritium> sladen, Okay, thanks for asking.  If I have ideas, I'll let you know.
<kent> eruin, that gdesklet-thing to the right, what is it called? 
<sladen> tritium: that image might useful in the case of a 16-colour framebuffer
<tritium> sladen, Okay, I'll definitely share it.  I was planning on doing so anyway.  I still need to set up my wiki page, etc.
<eruin> kent: CornerRhythmlet-bottomright.display
<eruin> it's in media/control if you install the gdesklets-data package
<tritium> sladen, how should I get involved?
<tritium> I'm definitely no artist, by the way.  I'm not that creative.
<eruin> whoooa
<jdub> tseng: pong
<tseng> jdub: oh.. hi
<tseng> jdub: the tomboy package i noticed is fairly botched, not sure how to best fix it
<tseng> jdub: look at diff.gz, there is a bunch of stuff that doesnt seem to belong
<jdub> sounds like you've built the package after building it before
<jdub> and it didn't properly clean up after itself the first time
<tseng> quite possibly, but its in the source package already.
<jdub> yeah, so
<jdub> untar tomboy
<jdub> copy over your debian directory
<jdub> then do the source-only build
<tseng> yay
<jdub> then do fakeroot debian/rules binary
<jdub> to make sure the binary is ok
<jdub> that won't futz with your source packages though
<jdub> mdz: was intending to do a sweep of artwork pages tonight, just watching your changes
<jdub> mdz: if you can hook up cliff and i soon, that would be very helpful
<mdz> jdub: would appreciate any clarifications that you can make on the pages
<mdz> jdub: I don't know jack about themes
<mdz> jdub: I sent cliff email tonight; going to set up a time to meet and talk
<jdub> ok
<mdz> jdub: will probably be in the evening local time
<mdz> any times you're not available this week?
<jdub> not really
<fabbione> morning guys
<fabbione> jdub: http://sparc.ubuntu.com/ :-)
<fabbione> we still cannot bootstrap from it
<fabbione> but almost
<fabbione> still missing a few NEW love from elmo
<fabbione> like the kernel ;)
<AndyFitz> anyone know whats happening to hoary repositories right now ?
<sladen> AndyFitz: how do you mean?
<AndyFitz> fglrx  has broken and now cant be fixed/removed etc.  also  the security repo doesnt authenticate all the time 
<lamont> fabbione: good point - my linux-meta upload is gonna be stuck in NEW too.
<lamont> fabbione: how soon do you plan to upload -10, btw?
<fabbione> lamont: later today or tomorrow morning
<lamont> ok.
<fabbione> i got flooded by bugs during the night
<lamont> playing with -9lamont1 here. :-)
<fabbione> cool :-)
<fabbione> does it boot?
<lamont> dunno yet, trying to actually build the source package... just learned about 00list-<revision> :-(
<fabbione> argh
<fabbione> and 00list-<revision>.hppa :-)
<lamont> yeah - saw that one
* lamont wonders if he should beat up daniels about xresprobe 
<fabbione> you probably need to add the stub for hppa
<fabbione> like we did for sparc and the others
<lamont> fabbione: nah - it has horribly b0rked #ifdef cruft in it
<fabbione> ah ok
<daniels> lamont: which #ifdef cruft?
<lamont> Installing new version of config file /etc/mozilla-firefox/pref/firefox.js ...
<lamont> Updating mozilla-firefox chrome registry...E: Registration process existed with status: 1
<lamont> E: /usr/lib/mozilla-firefox/extensions/installed-extensions.txt still present.
<lamont> +Registration might have gone wrong.
<daniels> (i assume you mean ddcprobe)
<lamont> hrm.. there's an english error there, and I wonder if I can reproduce that on i386...
<lamont> daniels: xresprobe source package.  ddcprobe sounds about right
<fabbione> lamont: i think today (later) we can give back ooo1 on i386
<fabbione> the problem is e-d-s
<fabbione> that exported an extra symbol
<fabbione> it wasn't my fault at the end ;)
<fabbione> but i am not sure seb already fixed it with yesterday upload
<lamont> just say when..
<fabbione> lamont: sure
<fabbione> lamont: what's the situation with hppa in general?
<fabbione> (just curios)
<lamont> 799 installed
<fabbione> sounds good :-)
* lamont runs the script to slurp in uploads again.
<lamont> mirror freshened around around 0130UTC, stage2 is pretty much current
<daniels> pool/universe/z/zsh-beta/zsh-beta_4.2.0-dev-1+20040622-1_powerpc.deb
<daniels>      1930298 100%   51.18kB/s    0:00:36  (3429, 99.9% of 91862)
<daniels> whoooooooooo
<daniels> come on, fortnight-long rsync
<daniels> you can do it
<fabbione> ehhe
<fabbione> i am rsyncing sparc now :-)
<fabbione> so i can finally change some buildd setup to something sane
<daniels> heh, nice
<fabbione> yup
<daniels> i'm just uploading xine now btw
<fabbione> i think either today or tomorrow it will be possible to bootstrap from it
<fabbione> daniels: thanks
<daniels> no worries
<daniels> oh, nice!
<daniels> so when will I be able to install my u5? :)
<fabbione> daniels: i am waiting elmo to bless the kernel (NEW)
<fabbione> and i think we will need ubuntu-meta seeded properly
<fabbione> + i need to check if all the uploads have been munged properly
<fabbione> (just run a quinn-diff on the archive)
<fabbione> because hounestly i didn't bother to read 1553 mails of REJECT/ACCEPTED
<fabbione> + i started building universe
<daniels> oh my god, xine has a toolkit of its own
<daniels> based on xt
<fabbione> main is pretty much in sync other than OOO
<daniels> head -> desk
<daniels> wow, that's awesome dude :) nice work
<fabbione> daniels: thanks :-)
<fabbione> on the otherside there is a bug (at least on my sparc)
<fabbione> that needs fixing
<fabbione> that is mostlikely related to the fact that i am headless
<lamont> Total 9 package(s) in state Dep-Wait-Removed.
<lamont> Total 8 package(s) in state Failed-Removed.
<lamont> Total 799 package(s) in state Installed.
<lamont> Total 816 package(s)
* lamont smiles
<fabbione> and on serial console all the lsb crack manage to hang the console badly
<fabbione> but the machine is alive
<lamont> hrm.. not sure that gdb and evolution should be 'removed' though...
<daniels> RSYNC COMPLETED
<lamont> grumble
<fabbione> daniels: did you also check the Xmvc in xine-lib?
<fabbione> because adding the b-d isn't enough
<fabbione> (+ you can close the bug)
<fabbione> ;)
<lamont> Kamion: livecd rootfs seems to have an issue or 2 for me to fix, but sleep needs to happen first, so I can think straight.
<fabbione> good night lamont
* lamont goes to fall over
<daniels> fabbione: hmm?
<daniels> fabbione: i installed xine, it started, that was good enough for me
<fabbione> daniels: i did open a bug for the xine-lib stuff
<fabbione> with all the details
<daniels> ok
<fabbione> and it is assigned to you
<fabbione> starting is not enough.. it was starting before too
<fabbione> but fullscreen wasn't working
<fabbione> not with xinerama enabled and other stuff
<fabbione> but there is the Xmvc bits that need some autocrap love that i am not able to do
<fabbione> that's why i assigned the bug to you :)
<daniels> blegh
<daniels> 'k
<fabbione> jdub: i think we can get gfs in for hoary :-)
<jdub> fabbione: ... !
<fabbione> jdub: do you have a url for the patch?
<fabbione> it's a feature and we are not in feature freeze ;)
<jdub> elvis.redhat.com?
<jdub> might be there
<jdub> haha
<fabbione> can you please dig it for me?
<jdub> you've changed your tune ;)
<jdub> yep, will do
<fabbione> i am test-building the new inofoty patch
<fabbione> inotify even
<jdub> don't spend too much time on it if it sucks
<fabbione> i am not...
<fabbione> just test-building
<fabbione> updating patches is easy now
<fabbione> but i need to know if it builds at least
<fabbione> it might as well fix another bug
<fabbione> 5431
<jdub> fabbione: not the page you need, but check this out: http://www.redhat.com/software/rha/gfs/
<jdub> fabbione: http://sources.redhat.com/cluster/gfs/
<fabbione> yeah i know what it is :-)
<fabbione> i planned to use it on my file server :-)
<d3vic3> daniels, ping
<jdub> http://people.redhat.com/cfeist/cluster/tgz/
<jdub> fabbione: the, um, price is what you should check out ;)
<fabbione> jdub: yes i know...
<fabbione> is the code GPL btw?
<jdub> yes
<fabbione> can we actually include it?
<fabbione> ok
<d3vic3> fabbione 
<d3vic3> morning 
<fabbione> hi d3vic3 
<d3vic3> my distro broke, need help 
<jdub> fabbione: golly, they're maintaining patches in cvs
<d3vic3> when I run `apt-get dist-upgrade` I get errors about dependencies 
<d3vic3> and gnome will not start 
<fabbione> jdub: i can see that there a bunch of patches that needs to be integrated...
<d3vic3> ubuntu-desktop fails to load 
<jdub> fabbione: lots of stuff
<fabbione> jdub: and they are up to 2.6.9.. so we might need a cvs checkout
<jdub> fabbione: might be a bit hairy for the supported kernel
<fabbione> + userland tools
<daniels> d3v	yo
<daniels> er
<jdub> fabbione: there's 2.6.10 in the patches area
<daniels> d3vic3: yo
<fabbione> jdub: yes.. i agree.. specially because we don't have experience on it and not enough time to test it properly
<jdub> punt!
<fabbione> i tought it was a bit smaller than that
<d3vic3> daniels, ubuntu-desktop wont install 
<jdub> maybe we can make an unofficial module package ;)
<fabbione> jdub: that's an option.. good luck and thanks for offering volunteer
<fabbione> :)
<d3vic3> wich kernel is hoary using ? 
<jdub> :)
<fabbione> d3vic3: calm down.. one thing at a time
<fabbione> first of all... what error do you get?
<d3vic3> I'm calm 
<daniels> hm, u-d should be fine, i thought we fixed that the other day
<d3vic3> dist-upgrade gives me errors about dependencies 
<d3vic3> lots of them 
<fabbione> d3vic3: start with an apt-get update
<d3vic3> I did 
<fabbione> then apt-get dist-upgrade
<fabbione> and see what it says
<d3vic3> I did that 
<d3vic3> same things, dependencies 
<fabbione> ok.. let's check your sources.list
<d3vic3> poinst to hoary 
<fabbione> please paste it
<fabbione> either in pvt or to pastebin
<fabbione> not in the chan
<zenrox> ya defentaly not in chanel
<fabbione> ok
<fabbione> ok.. start removing hoary-security
<d3vic3> ok
<d3vic3> and ? 
<fabbione> now do again the dance of apt-get update && apt-get dist-upgrade
<d3vic3> gives same errors 
<fabbione> ok
<fabbione> can you paste (as before) a few of these errors?
<fabbione> d3vic3: it says in the beginning what you have to do
<fabbione> apt-get -f install
<d3vic3> wont -f skip the dependencies ? 
<fabbione> apparently one upgrade didn't succeed properly
<fabbione> d3vic3: no.. there is an inconsistency on your system that needs to be fixed
<fabbione> and that command will do if it can
<fabbione> i need to go for 20 minutes or so
<fabbione> bbl
<d3vic3> ok
* Mithrandir grumbles at new postgresql-dev requiring kerberos4 libraries.
<fabbione> re
<Treenaks> wb
<d3vic3> fabbione, ping 
<fabbione> d3vic3: yes i am here
<d3vic3> managed to fix lots 
<d3vic3> but now I get a diff error 
<d3vic3> not about deps anymore
<fabbione> ok such as?
<d3vic3> pasted ptv 
<d3vic3> s/ptv/pvt /
<fabbione> d3vic3: that's a bug in kdelibs-data
<d3vic3> issit 
<d3vic3> is it filed ?
<d3vic3> fabbione, whats that command for reconfiguring X ? 
<crimsun> dpkg-reconfigure xserver-xorg  <-- hoary
<crimsun> dpkg-reconfigure xserver-xfree86  <-- warty
<d3vic3> ty
<d3vic3> anyone fixing the kdelibs-data bug, coz now I can install X
<daniels> SEB!!!
<fabbione> d3vic3: in general.. just ask
<fabbione> don't point to one person.. everybody in here is able to help you
<crimsun> should we direct this back to #ubuntu?
<fabbione> as well
<daniels> the panel is broken to hell at the moment
* daniels files a bug on GTK.
<Treenaks> daniels: it doesn't load when you login?
<Treenaks> daniels: or it looks like it "hangs"?
<daniels> Treenaks: nah, it seems to have gained xinerama support, so I don't have it spanning my MergedFB now
<daniels> Treenaks: and adding more seems to be broken
<Treenaks> next ubuntu conference and LCA were "almost at the same time", right?
<Treenaks> or is that not final yet?
<lifeless> its definate
<Treenaks> lifeless: ok.. then I need help with intra-Australia travel ;) flights to Sydney/Melbourne are 200 euros cheaper than direct flights to Canberra
<daniels> Treenaks: www.virginblue.com.au
<daniels> Treenaks: get a direct to sydney, and connect later on in the day to canberra for around $au120 return (~EUR60)
<daniels> Treenaks: or quantas for possibly the same rate
<daniels> but Ubuntu Down Under might be in Sydney, not canberra
<Treenaks> daniels: hmm..
<fabbione> daniels: 5117 <-
<Treenaks> daniels: when will the final decision on that be made?
<daniels> Treenaks: dunno, sorry
<Treenaks> daniels: WILL it be made? :P
<daniels> Treenaks: i hope so :)
<daniels> fabbione: bugger.
<pitti> Morning folks!
<crimsun> moin pitti 
<Keybuk> it almost certainly is in Sydney, from what I understand?
<pitti> Hi crimsun 
<daniels> Keybuk: yeah
<sabdfl> morning all
<Treenaks> hi sabdfl 
<sabdfl> Kamion: in debbugs, some of the messages are presented as control messages. are the rules to identify them and present them documented anywhere other than the code?
<Treenaks> sabdfl: I was just asking people.. anything certain about Ubuntu Down Under yet (except for "it will happen") ?
<sabdfl> yes, dates are set
<Treenaks> locations too?
<sabdfl> april 25-30
<sabdfl> sydney
<sabdfl> many of us will go to LCA in Canberra the week before, then UDU in Sydney
<Treenaks> I'm trying to figure out if I'm going, and if so, how BEFORE early bird registration for lca ends :)
<tuo2> Sweet.
<sladen> Treenaks: what's the loose/gain risk for booking LCA just in case?
<sabdfl> i'm looking forward to LCA
<daniels> sabdfl: me too ... but I'm also conscious of the fact I have to decide what it is that I'm talking about *and* write an abstract in the next week or two ;)
<Treenaks> sladen: not much, really..
<tuo2> Treenaks: Earlybird finishes 1st Feb
<Treenaks> tuo2: that's <2 weeks from now
<tuo2> yup.
<tuo2> Oh, sorry. I though you were asking *when* it ended
<Treenaks> well, I should probably have a flight to sydney, and get on the plane to Canberra from there..
<ogra> morning
<Treenaks> hi ogra 
<ogra> sabdfl: only 5 days :-O
<tuo2> Treenaks: you could also do the train from SYD->CAN
<Treenaks> tuo2: how long does that take?
<tuo2> 4 hours...
<Treenaks> oh that's doable
<Mabus> justdave: ping ?
<tuo2> it's quite pretty as well.
<justdave> Mabus: pong
<Mabus> justdave: do you have any control of the build machines ?
<tuo2> I though there was some talk about doing a big train ride down with slug
<justdave> nope
<Mabus> justdave: it seems the openoffice.org2 build is failing solely because the machine is missing bzip2: http://people.no-name-yet.com/~lamont/buildLogs/o/openoffice.org2/1.9.66-0ubuntu5/openoffice.org2_1.9.66-0ubuntu5_20050118-1612-i386-failed
<Mabus> oh
<Treenaks> tuo2: thanks for the info :)
<Mabus> justdave: know who I should poke? :)
<justdave> lamont probably
<tuo2> Treenaks: np. Good to see people coming to lca! :)
<Mabus> thanks
<ogra> Treenaks: is it sure that you fly ?
<ogra> hehe...ooo2 becomes really british it seems: Unpacking OO.o build tree - [ go make some tea ]  ...
<Treenaks> ogra: I'm not going to walk to australia :P
<ogra> Treenaks: g*
<ogra> Treenaks: i'm still not sure if i can pay the flight.....have to finish some extra work before :(
<Treenaks> ogra: same for me
<Treenaks> ogra: but it's not april yet! :P
<ogra> Treenaks: nope, and its to important to miss :) 
<ogra> only 5 days looks a bit dissapointing though
<Treenaks> ogra: it's followed by Ubuntu Down Under in Sydney
<ogra> err, 25-30 isnt the ubuntu conference ?
<Treenaks> ogra: 25-30 is, but 18-23 is lca
<ogra> ah, ok.....so its probably clever to hit them both :)
<Treenaks> I would
<ogra> since i never was in au before (and probably will never ever go there) i think i'll too
<pitti> ogra: Hi! Congrats to your first package
<pitti> ogra: however, the version number (0.061-ubuntu3) looks a bit odd
<ogra> pitti: i will fix it in the next upload.... (elmo had no objections....but was probably tired to point out even more errors) ;)
<ogra> pitti: thanks
<ogra> pitti: the original package was build with debmake....so i had to changea _lot_ ....that one just slipped through
<ogra> i promise i'll do better in the future :)
<pitti> ogra: no problem :-)
<pitti> ogra: it's not a big deal, I just wanted to point out this 
<pitti> ogra: nice to see you in the boat now :-)
<ogra> pitti: i'm going for main.....there such errors are not acceptable i think :)
<Riddell> fabbione: do you know what d3vic3's problem with kdelibs-data was?
<ogra> thanks :) i'm on my way :-D
<pitti> ogra: everybody makes such silly errors from time to time, I think
<fabbione> Riddell: provides file from another package
<d3vic3> Riddell, bug #5354 
<Riddell> d3vic3: didn't see you there
<Riddell> d3vic3: it's supposed to be fixed but I don't think it worked
<d3vic3> i see 
<sabdfl> https://wiki.launchpad.canonical.com/RoadMap
<sabdfl> oww
<fabbione> morning sabdfl 
<sabdfl> hi all
<sabdfl> connection is very up and down today
<fabbione> sabdfl: we are almost ready to launch sparc :-)
<sabdfl> whoot!
<fabbione> sparc.u.c is there
<fabbione> missing only a few details and a bit of testing my side
<fabbione> sabdfl: elmo has done a great job :-)
<decko> Hi people
<sabdfl> thanks elmo, fabbione, can't wait to have it out there
<fabbione> sabdfl: soon.. soon.. i am burning for it
<fabbione> :)
<Kamion> sabdfl: I don't believe any of debbugs' internal log message representation is documented anywhere other than the code; I'm assuming you've already read the documentation in Debbugs::Log, but that doesn't really deal with control messages
<mjg59> fabbione: I'll whip you up a patch to get useful debug output out of swsusp
<Kamion> sabdfl: in general a control message is represented as an html record with a description of the action (which was a terrible design decision - it'd be nice to transform all such records into something properly machine-readable some day) and an incoming-recv record with the text of the mail that did it
<Kamion> sabdfl: nothing in debbugs right now ever needs to parse the html, only display it, because it applies the necessary changes to .summary at the same time as writing .log
<trukulo> ogra_: when you awake tell me, i have graveman package for universe
<fabbione> mjg59: cool thanks
<trukulo> fabbione: did i tell you that all the videos are up?
<fabbione> trukulo: no you didn't or i didn't read :-)
<fabbione> what was the URL again?
<trukulo> so all of them are up
<trukulo> badopi.org/videos
<fabbione> thanks :-)
<trukulo> sabdfl: yours too
<sladen> anyone know the deal with firewire automounting?  I was expecting it to work like USB, but this user doesn't seem to be having that with his iPod
<sabdfl> Kamion: ok, thanks
<pitti> sladen: does manual mount with pmount /dev/sda2 (or whatever) work?
<Kamion> heh, review of d-i in Wil Wheaton's blog, and mention of Ubuntu in the comments: http://www.wilwheaton.net/mt/archives/001771.php#001771
<sladen> pitti: do you have to modprobe anything first?
<pitti> sladen: actually not
<thom> mdz: don't worry, i can't work out how to stop the stupid thing beeping, you'll get it back asap
<pitti> elmo: imagemagick sync, please
<fabbione> elmo: when you have time can you bless the sparc kernel please?
<sladen> lamont: you should really give  klogd's dd a bs=128  ---it's very good at buffering messages otherwise.  So good that it makes debugging a pain
<pitti> thom: here?
<Nafallo> so... where can I read about MOTU's dutys? :-)
<Nafallo> *reading logs*
<Mithrandir> what's the plan surrounding ooo2?  Is it going to be the OOo for hoary (which means I have to go around and be bloody bothered about it wrt amd64) or can I ignore it?
<Kamion> AIUI it may be the OOo for hoary if it seems to work well
<mjg59> fabbione: Has daniels sent you updated DRM stuff yet?
<fabbione> mjg59: no, but i want to grab it in full from bk
<mjg59> Ok, cool
<mjg59> The DRI tree is on bk now?
<mjg59> Or have they already submitted the DRM code to Linus?
<fabbione> it has been merged a lot between 2.6.10 and 11-rc1
<mjg59> Ah, ok
<fabbione> and i don't want any fancy code that hasn't been merged yet
<mjg59> There's been some extra code added to support DRI over suspend/resume on i810, so it'd be good to get that in
<fabbione> mjg59: do you prefer to send me a patch?
<fabbione> that would save me extra work
<mjg59> fabbione: I'll wait to talk to daniels about it
<fabbione> ok
<thom> pitti: hrm?
<fabbione> thom: when pitti hunts people, it's better to hide
<thom> heh
<fabbione> it's usually the start of a endless series of security bugs :-
<fabbione> )
<mjg59> Hrm. Why are people getting the autohinter switched on if they have sub-pixel anti-aliasing?
<Kamion> elmo: could you refresh Task: ubuntu-desktop? It's broken at the moment; I just uploaded ubuntu-meta to fix it.
<Kamion> the fixed binaries are in the archive now
<mjg59> daniels: xlibmesa-dri needs to define a tighter depends on xlibmesa-gl
<mjg59> Hrm, no, that's not it.
<Mithrandir> shouldn't g-v-m try to mount thumbdrives and such which are inserted prior to login?
<mjg59> Grah.
<mjg59> daniels: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg21142.html - I'm seeing the same
<daniels> mjg59: yeah.  i had stuff to do tonight, but before I started doing stuff, I did this:
<daniels>   * Resync Imakefiles for Mesa, so t_vb_cull gets built, and i915_dri is
<daniels>     loadable.
<daniels>   * Add extra guarding to xserver-xorg.postinst, so it will silently assume a
<daniels>     CRT if xresprobe doesn't feed us a display type (closes: Ubuntu#5639).
<daniels> mjg59: and that was before I saw dri-devel.  I AM A GOD AMONG MEN.
<fabbione> daniels: tsk... i am your god...
<daniels> fabbione: dude, mesa is hardcaw
* daniels flashes gang signs at fabbione.
<mjg59> daniels: You are, truly, a god
<mjg59> Is that uploaded?
<fabbione> god: a comment on 5117 please
<daniels> mjg59: not yet
<daniels> but it built on i386
<daniels> fabbione: if that's trackpoint, throw it away
<daniels> did I mention that I HATE PS/2 MICE?
<fabbione> daniels: and what about the wishlist for getting it in?
<fabbione> is there any new patch out?
<daniels> fabbione: i haven't been able to find any new patch
<fabbione> ok
<daniels> mjg59: because I am so goddamn good and did what you wanted before you asked, you must solve this bug -- https://bugzilla.ubuntu.com/show_bug.cgi?id=5466
<daniels> fabbione: i have lots of cool cards now :) got an imstt, bidding on an ark, a firegl on the way, lots of random cards too
<fabbione> ahhaha
<fabbione> daniels: you are always my little punk :P
<Kamion> anyone have a clue what on earth #5637 is about?
<fabbione> GTK?
<Kamion> if nobody knows I'll just punt to the kernel :P
<mjg59> HA. HA. HA.
<mjg59> daniels: Choke on my fuck
<fabbione> Kamion: we should ask him to buy serious hardware
<mjg59> daniels: For what it's worth, my Sid system doesn't link against them
<fabbione> Kamion: but that's USB.. so guess what? GTK!
<Kamion> haha, unlucky, kernel bug it is
* fabbione isn't suprised
<Kamion> oh, you beat me to it
<fabbione> ehehe
<Kamion> grah, dude, you don't get to change the package to linux and leave it assigned to me. I am not joining the kernel team :P
<fabbione> I did push the radio to ressign to QA or owner
<Kamion> weird
* fabbione hits bugzilla with a washing machine
* Keybuk wonders whether daniels was being lazy, or really can't save to launchpad :P
<daniels> Keybuk: can't seem to log in
<daniels> fabbione: haha :)
<Keybuk> daniels: me neither
<daniels> fabbione: it's probably getting detected as a Synaptics touchpad
<Keybuk> ho-hum
<daniels> Keybuk: awesome
<daniels> mdz: i'd like permission to defer 1421 until after the feature freeze -- letting vbetool subsume ddcprobe
<daniels> mdz: i've got a kick-arse amd64 motherboard at the moment, but no cpu/ram/case/psu yet
<daniels> (and my video card will probably take a while; given it's a pcie+pci board, i'll probably have to run a shitty pci video card for a while, in an sli-capable pcie motherboard.  life's little ironies.)
* Mithrandir pats daniels on the head.
<thom> what is sli, btw?
<mjg59> single line interlace (IIRC)
<Mithrandir> thom: you remember voodoo 2, where you could use two video cards to drive one screen?
<Mithrandir> same stuff.
<thom> righto
<thom> cool
<Mithrandir> they render every second line and you can shoot double the number of badassess.
<daniels> but only nvidia do it
<Mithrandir> or something.
<thom> i did wonder, i had a dual voodoo2s 
<daniels> apparently two 6800gts in sli is pimpfast
<daniels> but the best single card is still x800 xt pe/x850
<daniels> especially as in single mode you get pcie 16x
<Mithrandir> daniels: what happens if you put two ATI boards in a SLI board?  Can you drive them independently?
<daniels> which is like, your entire game's worth of textures in a nanosecond
<daniels> Mithrandir: i'm not sure tbh
<kent> my tnt2 works great with gnome ;)
<daniels> Mithrandir: but ati did actually make an sli card
<daniels> the rage fury maxx
<daniels> one board, two gpus
<daniels> essentially working in sli
<Mithrandir> daniels: it'd be a cheap way to get dual DVI.
<thom> daniels: you're making my 9800pro feel inadequate, stop it :P
<daniels> except without having to run some horrific cable between the two cards
<daniels> Mithrandir: er, screw that
<daniels> Mithrandir: basically every r4xx ever has dual DVI
<Mithrandir> daniels: r4xx is what?
<daniels> Mithrandir: aiui, x700 is r400, and x800 is r423
<daniels> r400 being agp, r423 being pcie
<daniels> but r4xx-class cards are all natively pcie
<daniels> so the r400 is actually a pcie chip with an agp bridge :)
<daniels> as opposed to the reverse, which is crap
<daniels> a pcie firegl would be frightening; those things have astounding amounts of memory
<mjg59> daniels: Uh, the rage fury maxx wasn't really sli
<mjg59> They interleaved frames, not lines
<daniels> being able to fill that over 16x pcie would be stunning
<daniels> mjg59: oh, right
<mjg59> Which was crack-tastic
<mjg59> (for decent performance, you needed at least a frame of buffering)
<daniels> right
<Mithrandir> daniels: actually, it seems like the price of dual-dvi 6600's has dropped significantly
<daniels> apparently there were two of them made
<mjg59> daniels: Xorg says I have version 1.2 of the 915 DRM, and then says that suspend won't work with <1.2
<mjg59> I think it means <=1.2
<daniels> ajax has been trying to get docs off ati with no success
<daniels> mjg59: probably
<Mithrandir> hiya Simira 
<Simira> mornin
<daniels> /home/daniels/x/xorg/remote/xc/extras/drm/shared/i915.h: * 1.1: Original.
<daniels> /home/daniels/x/xorg/remote/xc/extras/drm/shared/i915.h: * 1.2: Add Power Management
<daniels> go figure
<fabbione> hey Simira 
<Simira> hi fabbione
<daniels> mjg59: yeah, X.Org HEAD has 1.2
<daniels> fabbione: have you really integrated new DRM crack recently?
<no0tic> hwo can I test standby and hybernate hoary features?
<fabbione> daniels: read above my chat with mjg59 
<daniels> thom: you should get an x800 xt 2dhtv, i hear they're awesome :)
<daniels> fabbione: ah ok, so not merged yet?
<thom> i'll need a PCIe mobo first :P
<Simira> hm, n silbs
<Simira> n/no
<daniels> thom: you should get one of those, I hear they're cool
<daniels> although they went a little bit overboard
<thom> heh
<daniels> there are 8 SATA cables
<thom> fuck
<thom> that's quite a bit :-)
<daniels> as well as an external plate with 2 SATA connectors (and power)
<daniels> and multiple IDE/floppy cables, etc, etc
<daniels> there's a staggering collection of shit in there
<Mithrandir> daniels: uhm, on a what kind of mobo?
<daniels> (the motherboard requires the 24-pin ATX plug, the 4-pin 'P4 power' plug, and a single Molex connector)
<daniels> Mithrandir: k8n-sli or whatever
<daniels> nforce4 + pcie + sli
<Mithrandir> asus?
<daniels> oh my god, that's frightening
<daniels> 'DFI LANPARTY NF4SLI-D Socket 939, 2000MT/s, PCI Express (SLI mode), DDR400, SATAII, RAID, Dual Gigabit LAN, UV Reactive Slots & Cables'
<daniels> yeah, asus
<Mithrandir> daniels: dfi's lanparty stuff _is_ overboard, yes.
<daniels> uv reactive slots and cables?!?
<daniels> Mithrandir: this is mine -- http://www.asus.com/products/mb/socket939/a8nsli-d/overview.htm
<daniels> it's a *very* nice motherboard
<daniels> and I'll never run out of SATA
<Mithrandir> I have six sata thingies on mine.. quite enough.
<daniels> mjg59: 
<daniels> daniels@nanasawa:~xap/debian/xlibmesa-dri/usr/X11R6/lib/modules/dri% objdump -x i915_dri.so | grep _tnl_vertex_cull_stage
<daniels> 0019bbc0 l     O .data  0000002c              _tnl_vertex_cull_stage
<Mithrandir> daniels: shame there's a mobo fan on it.
<daniels> Mithrandir: *shrug*
<Kamion> is there a way to figure out from /sys which kernel driver owns a given network device?
<Kamion> s/device/interface/
<daniels> mjg59: so what was the conclusion for nvidia+acpi?
<fabbione> seb128: did you fix that e-d-s symbol problem?
<Kamion> the only way I can see to do it is by looking at the target of the /sys/class/net/*/driver symlink, which is arse
<Mithrandir> daniels: and small fans like that are often noisy.  I want my machine to be silent.
<`anthony> mjg59: re daniels' message - on this laptop, suspend/resume works, except that on resume, the screen never gets powered back on.
<seb128> fabbione: yep
<fabbione> seb128: did you tell lamont to give-back ooo1 on i386?
<seb128> nop
<fabbione> ok
<fabbione> i will do it later :-)
<fabbione> thanks
<mjg59> daniels: Yeah, I just rebuilt mesa with the one-line fix
<daniels> mjg59: sweet
<mjg59> daniels: We /could/ fix it, except, uh, we have no rights to modify nv.c
<daniels> mjg59: d'oh
<mjg59> So fuck them
<`anthony> mjg59: Do you have a capsule description of the problem? I'm happy to send them "as a pissed off owner of one of your cards, please fucking fix this" emails
<Kamion> anyone here have an ipw2[12] 00?
<thom> Kamion: yeah, ipw2100
<maswan> Kamion: yeah, as thom
<Mithrandir> Kamion: ipw2200, why?
<Kamion> does /sys/class/net/<ethwhatever>/device/rf_kill exist?
<mjg59> `anthony: Their power management code doesn't integrate with the kernel correctly
<thom> Kamion: yes
<maswan> Kamion: not what I can see (warty kernel)
<Kamion> thom: good, I've got the path right then
<`anthony> mjg59: suprise! stupid fucking half-open-source piece of crap driver.
<Kamion> maswan: odd that it doesn't exist for you, but ...
<thom> (this is with hoary)
<Treenaks> maswan: do you have a "hardware" rf switch/
<Kamion> maswan: try 'find -follow /sys/class/net/<ethwhatever> -name rf_kill'?
<maswan> I might just be weird then. :)
<maswan> Kamion: I just did that, no result
<Kamion> ok, no worries
<Mithrandir> Kamion: same with hoary + ipw2200 here.
<mjg59> daniels: Where can I get recent enough DRM to do i915 suspend/resume?
<daniels> mjg59: err ... err ...
<daniels> mjg59: i assume you're using -686?
<daniels> if so, i can build you xorg head's i915
<mjg59> daniels: Yeah
<Kamion> Mithrandir: same as thom?
<mjg59> Rock
<Mithrandir> Kamion: same as thom, yes.
<mjg59> daniels: Is that in the code that's been pushed to the kernel, or do we need another patch?
<Kamion> thom, Mithrandir: oh, could you also tell me what /sys/class/net/<ethwhatever>/driver points to?
<mjg59> fabbione was going to pull the stuff from 2.6.11
<daniels> mjg59: dunno
<fabbione> guys either way is ok for me
<daniels> mjg59: in any case, http://amnesiac.heapspace.net/~daniel/i{8[13] 0,915}.ko
<thom> Kamion: lrwxrwxrwx  1 root root 0 2005-01-19 13:16 /sys/class/net/eth1//device -> ../../../devices/pci0000:00/0000:00:1e.0/0000:02:02.0
<fabbione> but it would be better if we can run a test on it before uplaoding
<daniels> fabbione: i'm almost certain the stuff that got pushed is what's in xorg head now
<Kamion> thom: driver rather than device
<thom> oh, sorry
<Mithrandir> lrwxrwxrwx  1 root root 0 2005-01-19 14:17 /sys/class/net/eth1/driver -> ../../../bus/pci/drivers/ipw2200/
<thom> Kamion: ../../../bus/pci/drivers/ipw2100
<Kamion> thanks
<Kamion> I wonder why Mithrandir's has the trailing /
<Mithrandir> because I've aliased ls. :P
<Kamion> oh :-)
<Mithrandir> goes away if I call /bin/ls instead of the alias
<Kamion> just a shame I have to use readlink(2), since that syscall officially sucks
<Mithrandir> oh, why?
<Kamion> you have to guess how long the symlink text is and repeat if you were wrong
* Kamion cheats
<Kamion> oh, and it doesn't append NUL
<Mithrandir> yeah, looks like suckage.
<fabbione> argh...another libc6 upload
<Kamion> sorry :P
<Mithrandir> Kamion: just use PATH_MAX? :)
<Mithrandir> hi jeff
<Kamion> Mithrandir: Jeff would kill me ;)
<Kamion> [context: readlink(2) sucks] 
<Mithrandir> Kamion: heh, true. :)
<jbailey> *lol*
<jbailey> What have I walked into now? =)
<mjg59> daniels: Rock, working 3D across suspend/resume
<mjg59> But I get:
<mjg59> libGL warning: 3D driver claims to not support visual 0x22
<mjg59> libGL warning: 3D driver claims to not support visual 0x23
<mjg59> libGL warning: 3D driver claims to not support visual 0x26
<mjg59> libGL warning: 3D driver claims to not support visual 0x27
<daniels> mjg59: errrrr
<jbailey> daniels: Yay!  Most recent X update fixes my hang-on-start on ppc. =)
<elmo> pitti: done
<elmo> Kamion: done
<pitti> thanks
<Kamion> elmo: thanks
<no0tic> mjg59: how can I test suspend/resume?
<daniels> jbailey: really? sweet deal.
<daniels> jbailey: let me guess -- you're using an r128
<mjg59> no0tic: http://www.ubuntu.com/wiki/HoaryPM
<no0tic> mjg59: thanks
<jbailey> daniels: Radeon 9200SE
<pitti> jbailey: thanks for that hint, so I won't upgrade my iBook for now :-)
<fabbione> daniels, mjg59: would it be ok drm in -11?
<daniels> jbailey: oh well, close enough ;)
<daniels> fabbione: yeah, that's fine for me
<fabbione> ok
<no0tic> mjg59: I have two swap partitions, can I use both in some way to resume?
<elmo> fabbione: done
<seb128> thom: around ?
<mjg59> fabbione: Sure
<mjg59> no0tic: Not currently, nope
<mjg59> Just choose the biggest
<no0tic> mjg59: hibernating will copy ram contents to it?
<no0tic> mjg59: or also something else?
<thom> seb128: kinda head down in firefox, but sup?
<seb128> thom: http://bugzilla.gnome.org/show_bug.cgi?id=157435
<seb128> thom: could be interesting
<thom> i'll apply it and see
<mjg59> Mostly RAM contents
<seb128> thom: BTW firefox build-dep on libkrb5-dev ... is there any way to use heimdal-dev instead ? Just wondering because evolution and friends build-dep on heimdal-dev which conflitcs with libkrb5-dev
<no0tic> mjg59: ok thanks
<thom> seb128: ugh
<seb128> grrrrr
<lexhider> seb128: I think #5632 may still be a problem.
<seb128>   File "/usr/share/dput/ftp.py", line 59, in upload
<seb128>     if e.args and e.args[0] [:1] =='5':
<seb128> TypeError: unsubscriptable object
<seb128> second type that dput crashes in the middle of a gnumeric upload
<seb128> that sucks
<seb128> lexhider: I've read the comment yep and get the bug here
<seb128> mvo_: ping ?
<daniels> hm
<lexhider> seb128: cool, just checking if it was just my end, bye.
<elmo> seb128: hmm, one sec
<daniels> so, ATI are all set up for lib/lib64, not lib32/lib
<elmo> seb128: try it again?
<daniels> so its 32-bit (binary-only) libGL.so.1.2 tries to load /usr/X11R6/lib/modules/dri/%s_dri.so, not /usr/X11R6/lib32/modules/dri/%s_dri.so
<seb128> elmo: the upload ? sure, just a 20min job with my sucking upload link :p
<daniels> would patching it with a vi script at l-r-m build time be wrong?
<Mithrandir> ** (gnome-cups-manager:10738): WARNING **: FOOBAR
<Mithrandir> how _useful_
<daniels> Mithrandir: when I was looking at synaptic source ~2 years ago, it had cerr << _("OMG DUNNO WTF IS GOING ON?!?\n");
<daniels> (it got translated into most languages)
<fabbione> elmo: thanks
<elmo> seb128: ouch
<Mithrandir> daniels: *chuckle*
<daniels> seb128: tell me about it ... uploading l-r-m orig is 45min
<Treenaks> daniels: coolness
<daniels> seb128: while you have TEN THOUSAND message windows with 'HEY DUDE DID YOU SEE ATI RELEASED FGLRX?!? DUDE! FGLRX! AMD64? XORG? DID YOU SEE?'
<Treenaks> daniels: well, did you?
<daniels> Treenaks: did I see?
* Treenaks hides
<Treenaks> daniels: yes
<Mithrandir> daniels: well, they're not in the archive yet, so you can't have noticed.
<daniels> Mithrandir: ?!?
<elmo> giggle
<seb128> daniels: ah ah
<daniels> Mithrandir: http://archive.ubuntu.com/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.10/xorg-driver-fglrx_6.8.0-8.8.25-0ubuntu2_amd64.deb
<fabbione> bleah
<Mithrandir> daniels: bah, ok, then. :P
<daniels> Mithrandir: if thom wasn't such a fascist, I'd figlet kthxbye at you
<fabbione> Kamion: i think you should be able to start seeding from sparc.u.c
<fabbione> we still don't have a real sparc ubuntu-meta
<fabbione> even if it builds. it's empty
<thom> daniels: --->  Installing 'figlet-2.2.1' from a port (misc/figlet)
<thom> --->  Building '/usr/ports/misc/figlet'
<`anthony> mjg59: fwiw, if I can stomach it, my plan is to try and figure out why the nvidia driver is busted, fix it, and post an ed-format diff somewhere. nvidia can go fuck themselves if they want to complain about that, since it contains none of their code.
<ogra> seb128: cool, you packaged nautilus-sendto :) 
<silbs> Simira: you were looking for me?
<seb128> ogra: yep, that was the plan :p
<daniels> thom: thanks
<ogra> will this go into main ?
<lamont> fabbione: ooo1 is ready to give back then?
<fabbione> lamont: good morning.. and yes
<Kamion> fabbione: ok. ubuntu-meta will need its source changed to look at sparc.ubuntu.com; best ask mdz if that's ok
<fabbione> Kamion: sure...
<fabbione> i will ask him later
<lamont> fabbione: done
<pitti> lamont: hi!
<pitti> lamont: MLKJ+2 today?
<lamont> nah - I got enough vacation in yesterday - although I my go back to bed for a couple hours this morning - bed happened late last night.
<Mithrandir> fabbione: that's just a give-back on sparc?
<Kamion> fabbione: ugh, germinate doesn't support working off sparc.ubuntu.com yet; no Sources file ...
<pitti> lamont: so I can tell you that apache security update does not build?
<Kamion> it'd need to be extended to allow getting Sources from a different place from Packages
<pitti> lamont: I didn't get a failed build log either
<lamont> pitti: either way, I'm going to reboot my machine in about 20 seconds... 
<lamont> brb
<Kamion> so I'll still have to do slightly scary hacks
<fabbione> Mithrandir: nah sparc will build fine and it is building right now. the problem was i386 specific
<fabbione> Kamion: there are no sources on sparc.u.c. It needs to use the same from archive.
<fabbione> Kamion: sparc has only the binaries. there is very litte point in mirroring them twice
<Kamion> yes, I know
<Mithrandir> fabbione: ok, so it'll be given-back on i386.  That's fine.  I just bloody don't want anybody to upload a new OOo unless they have to.  It's painful for me.
<Kamion> it still needs a germinate extension to support that. :)
<fabbione> Mithrandir: it has been done already.
<fabbione> lamont: what's the status with the hppa kernel?
<lamont> fabbione: did you get the files I tossed you?
<fabbione> lamont: via email?
<fabbione> i don't have irc scrollback or log
<lamont> actually, I think it was a URL in /msg
<fabbione> so if you pasted here no
<fabbione> argh...
<lamont> let me find it.
<fabbione> sorry no..
<fabbione> thanks
<lamont> people.ubuntu.com/~lamont/fabbione.pa.tar.gz
<mjg59> daniels: Hrm. Is the nvidia driver patched in linux-restricted-modules?
<lamont> has modified control and control.stub, debian/config/hppa, and a modified pa_patch
<fabbione> lamont: ok. perfect
<lamont> you'll want to migrate the build-depends from control*, since it's relative to -8
<fabbione> it will be in my tree in a few minutes :-)
<lamont> but the others just drop in.
<daniels> mjg59: how do you run vbetool to post?  vbetool post?
<fabbione> lamont: sure.. don't worry
<daniels> mjg59: yeah, needs to be patched for .10.  why?
<lamont> pitti: checking on your build
* fabbione -> coffee
<mjg59> daniels: There's no permission to do so
<mjg59> daniels: Yeah
<mjg59> daniels: Check the copyright headers on nv.h and nv.c
<sivang> morning all
<seb128> thom: http://live.gnome.org/Epiphany_2fMozillaPatches
* lamont wonders WTH is sound went...
<lamont> at full volume, I get popping
<seb128> GRRRRR
<seb128> Uploading via ftp gnumeric_1.4.2.orig.tar.gz: Error '(32, 'Broken pipe')' during ftp transfer of gnumeric_1.4.2.orig.tar.gz
<seb128> HATE dput
* seb128 scp the files on chinstrap this time
<elmo> seb128: dude, it's not dput
<elmo> sorry, I didn't realise it was dieing on the orig.tar.gz
<elmo> our new upload daemon has timeout issues - stevea is working on it, but in the meantime, if you have a large orig.tar.gz, like gnumeric, on a slow link, 'rsync -e ssh' it to chinstrap first
<seb128> elmo: 
<seb128>   File "/usr/bin/dput", line 857, in main
<seb128>     progress=config.getint(host,'progress_indicator'))
<seb128>   File "/usr/share/dput/ftp.py", line 59, in upload
<seb128>     if e.args and e.args[0] [:1] =='5':
<seb128> elmo: oh ok ... thanks
<elmo> I'm really surprised we haven't had this problem before now.. and now 3 people in as many days have hit it..
<Mithrandir> elmo: I've had it for a while, but I usually get by by uploading to something which does a few MB/sec.
<lamont> elmo: it's timing out because of lack of activity on the control socket??
<elmo> lamont: nah, the code's buggy.. it's timing out because the timer's not being updated ;-)
<elmo> Mithrandir: thanks for telling me dude ;-P
<Mithrandir> elmo: I didn't know if it was my end or dput being dodgy or not.
<Mithrandir> elmo: and I don't like to complain if I can work around issues relativetly easy and I don't know where the problem is
<Kamion> lamont: ia64's still building glibc, I take it?
<elmo> ok, new upload daemon in place.. if this doesn't work, we get to tar'n'feathe the entire zope3 upstream ;-)
<lamont> seb128: why doesn't shift-insert paste what I just button-3-cut?
<thom> seb128: nice! i'll look at and review
<seb128> lamont: that's a xfree's question for daniels probably
<seb128> thom: yep, thanks :)
<Kamion> shift-insert is an application thing not an X thing surely
<seb128> in which app so ? :)
<lamont> Kamion: make[3] : Leaving directory `/build/buildd/glibc-2.3.2.ds1/build-tree/glibc-2.3.2/login'
<lamont> xterm, of course
<daniels> elmo: ... so, if I were to tell you that we can't actually distribute l-r-m at all, and we were technically violating the licence of one of the modules in there ...
<Kamion> ah, so it is an xorg question then ;)
<seb128> lamont: works for me (tm) ...
<daniels> lamont: button-3-cut is the PRIMARY selection, shift-insert is CLIPBOARD
<daniels> (that's how most apps implement it -- gtk bug)
<Kamion> elmo: (speaking of, can you demote l-r-m-2.6.9 to universe?)
<azeem> daniels: wasn't that clear from the day you included the ipw2100 firmware? Or do you have a special license for that?
<daniels> (there's PRIMARY, SECONDARY, and CLIPBOARD)
<seb128> lamont: see, daniels knows about this :)
<lamont> seb128: ok.
<daniels> azeem: there's no ipw2100 firmware in lrm
<seb128> (even if the evil guy blames gtk *again*)
<azeem> oh :)
<azeem> I wonder how my WLAN works then
<lamont> daniels: so how do I copy into the clipboard?
<daniels> lamont: edit->copy or whatever
* netjoined: irc.freenode.net -> benford.freenode.net
<daniels> you don't want CLIPBOARD; try to use PRIMARY (which is usually just selecting with the mouse) whereever you can
<Kamion> azeem: it's in linux-source, not l-r-m
<lamont> I WANT MY SOUND BACK!
<azeem> ah
<fabbione> lamont: eh?
<fabbione> are the modules loaded?
<lamont> fabbione: _I_ didn't change anything (other than an  upgrade of the system :-)
<fabbione> lamont: i didn't say you did change something...
<fabbione> lsmod |grep snd
<elmo> kamion: boggle, no?
<lamont> echo $(lsmod | awk '/snd/ { print $1}' )
<lamont> snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc
<elmo> Kamion: multiverse maybe, or just remove it
<elmo> but not universe
<fabbione> lamont: check the mixer
<Kamion> elmo: er, sorry, multiverse is what I meant
<fabbione> lamont: probably you hitted one of these alsa "i kill your mixer settings" obscure bugs
<Kamion> elmo: linux-source-2.6.9's in universe at the moment so it would make sense to match
<lamont> fabbione: and the recovery would be?
* netjoined: irc.freenode.net -> benford.freenode.net
<Kamion> pitti: yes, having the langpack base package depend on the update packages seems sensible to me
<pitti> Kamion: would the current structure work reasonably easy with the installer?
<wasabi> i hate how synaptic doesn't use my gtk theme. =/
<pitti> Kamion: i. e. do you already have the language code in d-i?
<Kamion> pitti: yes, I have the language code
<pitti> Kamion: okay, so actually there is now nothing left to decide any more
<Kamion> just give me a set of rules for (language/country => package names) basically and I'll implement them
<Kamion> or locale => package names, either works
<pitti> Kamion: basically, it's just "install language-support-<LANG> and language-pack-<LANG>" for language code <LANG>
<Kamion> what about things like pt_BR?
<Kamion> does -pt get both?
<pitti> Kamion: it was decided to merge all countries in a single per-language pack
<tseng> jdub: hey. this new tomboy is using dbus mono bindings, i have them locally (source in hoary dbus-mono) but there is no bin in hoary yet.. no go for now
<Kamion> ok
<pitti> Kamion: otherwise you get crazy with e. g. de-at and de-de
<no0tic> libc6 new update works?
<Kamion> pitti: there are obviously different cases; I think that should have been decided case by case
<Kamion> no0tic: was a one-line change
<pitti> Kamion: we discussed a little about zh_CN and zh_tw
<Kamion> pt_BR is a totally different situation from de_AT
<pitti> Kamion: but in the end there was an agreement to have only per-language
<pitti> Kamion: this also saves us some 150 packages
<no0tic> Kamion: that messed up all ;)
<Kamion> no0tic: huh?
<no0tic> Kamion: one-line change... (a joke) 
<Kamion> no0tic: if you have problems, please give details.
* Treenaks reads the description of daniels on http://lca2005.linux.org.au/speakers.php and LOLs
<no0tic> Kamion: no, it was a joke, np
<lamont> fabbione: someone decided to switch things to the oss mixer...
<fabbione> lamont: no recovery.. :( just set the mixer back again
<lamont> (fixed)
<fabbione> eh? oss?
<fabbione> that's not me
<fabbione> lamont: gtk!
<fabbione> remember.. it's always gtk
<lamont> fabbione: nah - let's just blame seb128 directly
<lamont> :-)
<fabbione> haha
<seb128> grrr :p
* lamont makes a note to buy seb128 a beer in .au, before he goes postal or something
<Mithrandir> lamont: I would recommend some morphine or similar substances.
<lamont> Mithrandir: some opiate, eh?
* netjoined: irc.freenode.net -> benford.freenode.net
<fabbione> lamont: can i upload 2.6.10-10 ?
<fabbione> or that would kill your mirror?
<Mithrandir> yeah
<lamont> fabbione: whatever.
* fabbione feels a tone of desperation in "whatever"
<lamont> nah
* lamont has other issues with his mirror atm
<fabbione> oh ok
<jbailey> wasabi: There?
<wasabi> yes
<jbailey> wasabi: When you're running eclipse in the various JVMs, are you including the standard gcj in that set?  I had thought that eclipse3 needed gcc4's bits to make it work.
<wasabi> No.
<wasabi> Kaffe only at this point.
<wasabi> ANd Kaffe just barely
<jbailey> 'kay.  I thought I saw a success on #classpath for it with jamvm and CVS classpath.
<wasabi> Might be. It all falls to classpath at this point.
<wasabi> All the VMs are fairly good. Sable, Kaffe, GCJ, whatever, etc.
<jbailey> I haven't tried it yet, though.  I usually have either blackdown or sun's jvm installed.
<wasabi> But they all use classpath.
<wasabi> And classpath is a bit lacking in sid currently.
<wasabi> My packages work flawlessly on sun's. ;)
<lamont> fabbione: so more dispair or apathy than desparation
<wasabi> Either way, it runs Good Enough on Kaffe for main.
<wasabi> In sid at least.
<wasabi> Seeing as our current packages are 1.5 years out of date and only work on Sun's period. ANything is an improvement. ;)
<jbailey> No kiddin'.
<jbailey> Did you wind up disabling all of the auto update features?
<wasabi> Nope.
<wasabi> It's off by default.
<fabbione> lamont: ehe don't worry.. i will probably release later today or tomorrow
<jbailey> Oh?  Cool.
<wasabi> You have to specifically update it yourself... and to do so you have to update it into a second update site.
<fabbione> lamont: i need to check that the changes will not break anything
<wasabi> SUch as /usr/local/share/eclipse or ~/.eclipse
<fabbione> lamont: like the binary compatibility
<wasabi> And if a user choose to go through all that, let em.
<fabbione> pitti: ping?
<jbailey> wasabi: Yeah.
<pitti> fabbione: pong
<wasabi> I'm pretty confident all the free VMs will run Eclipse.
<wasabi> Depending on how close to classpath CVS they are.
<wasabi> Eclipse gives us a free compiler in main too, a perfect compiler. ;0 THe Eclipse JDT.
<jbailey> Hmm, I'll give your packages a try.  I usually use jamvm just because it uses cp directly.  But the package hasn't been updated yet.
<wasabi> please do. I want any and all info/testing regarding them. ;)
<jbailey> How does the Eclipse JDT do vs. jikes?
<wasabi> Jikes is barely competitent.
<wasabi> I would never it near production code.
<wasabi> It can't handle inner classes at all. IT's import parsing orders are all out of wack.
<wasabi> Eclipse JDT is *perfect*. And I mean it.
<wasabi> IBM would not be able to sell WebSphere if it wasn't.
<wasabi> So... yeah. =)
<wasabi> It's CPL though.
<wasabi> It's good enough to compile stuff, but not GPL compatible.
<Kamion> is that a problem for a compiler?
<wasabi> Dpeending on your interpretation of the GPL.
<wasabi> heh
<fabbione> seb128: the e-d-s symbol is not fixed...
<fabbione> seb128: ooo1 failed again
<fabbione> and judging from the log size, exactly at the same point
<Kamion> wasabi: rather, depending on whether it claims that object code it produces is also CPL
<wasabi> It does not claim that.
<jbailey> Kamion: As long as there's an exemption allowing the code output to be whatever license you'd like, it ought to be fine.
<Kamion> if it doesn't then I don't think one's interpretation of the GPL matters
<fabbione> seb128: what version of e-d-s should fix that?
<Kamion> jbailey: indeed
<wasabi> There is a big ass d-l thread regarding Java compilers + GPL.
<wasabi> I can see both sides of it.
<Kamion> -legal ... *shrug*
<seb128> fabbione: 1.1.3-0ubuntu8
<seb128> fabbione: but haggai said there was an OO.o issue too, are you sure that's fixed ?
<fabbione> seb128: that's what i understood from you
<jbailey> wasabi: Do you know if it's possible to drop their compiler into a separate package and invoke it as javac?
<wasabi> The package name is eclipse-javac
<wasabi> I made a wrapper script for it.
<jbailey> Nice. =)
<wasabi> THere is also an ant plugin
<seb128> fabbione: are heimdal-dev and libnspr-dev installed for the build ?
<wasabi> In fact... I'm building Eclipse with it. The eclipse packages are two stage... use Kaffe to build the JDT... then use the JDT to rebuild everything.
<wasabi> kjc isn't good enough to compile ALL of eclipse without modifications.
<thom> fabbione: i should've taken your advice and run away
<pitti> thom: at some day I had caught you anyway
<pitti> MUHAHAHAHA
<fabbione> seb128: sorry i need to.. you can check in the log :-)
<fabbione> thom: ahhaha
<fabbione> i have a meeting with the kitchen company now
<thom> but you would have had to do this firefox release
<fabbione> bbl
<pitti> sorry, thom! :-)
<thom> that patch is a SCREAMING NIGHTMARE
<pitti> thom: the injection? right
<pitti> thom: if it does not work, and you don't have the feeling that this is wartyable, let's forget about it
<pitti> thom: there are enough other issues :-)
<thom> i don't see it being wartyable
<thom> it's blowing the ABI and API into tiny little shreds and stomping on them
<pitti> thom: then I rather write a stanza about it in the USN
<thom> go mozilla, it's your birthday. one of the hunks is 400 lines of mixed style change and code change
<mjg59> I vote that security advisories give a rating out of 10 for quality of vendor provided patch
* pitti tries to escape thom's axe
<pitti> mjg59: this window injection thingy is not really a patch; it's a complete rewrite
<pitti> thom: what about hoary?
<Mithrandir> what's the way to make baz shut up about it not knowing what kind of archive an archive is?
<enrico> Hello.  Someone in the docteam is taking care of making nice release notes for Hoary, and could use some details about it (where it will be published, how long it should be, what level of detail...).  Who can I refer him to?
<thom> Mithrandir: beat lifeless until he shuts it the hell up
<thom> pitti: i'm still applying the patch for hoary, will see how it goes
<pitti> thom: since the bug is fixed, is it already contained in a new upstream release?
<pitti> thom: might be easier to package that
<`anthony> mjg59: You are an a-grade legend. Your vbetool was the magic bit I needed to make this laptop unsuspend right
<`anthony> Thankyouthankyouthankyouthankyou.
<mjg59> `anthony: Rocking
<`anthony> mjg59: Well, that, and making sure i rmmod'd uhci_hcd first.
<mjg59> `anthony: The scripts in Hoary ought to do that
<`anthony> the wacky dell usb-to-ps/2 replication stuff plays, well, very very badly, with suspend.
<thom> pitti: nope - there's not been a firefox release since 1.0
<pitti> bad
<pitti> they should
<thom> yep
<pitti> mozilla?
<`anthony> mjg59: That would be awesome if it automatically did this. It doesn't _always_ work. One time in about 5, the video driver goes utterly batshit and you get a gray screen fading in from the sides, but that could've been something else I was fucking about with causing that.
<thom> they want to go straight for 1.1 i think, which means merging trunk on to the firefox branch
<thom> pitti: 1.8 is still alpha
<thom> 1.7 won't get the fix since it's too intrusive
<pitti> hahaha
<mjg59> `anthony: In Hoary, the default is to rmmod all the USB stuff and do vbe stuff on suspend/resume
<thom> pitti: (they say the same for a 1.0.1 of firefox if it was considered)
<`anthony> mjg59: Also, kill orinoco
<pitti> thom: okay, so WONTFIX for warty
<thom> definitely
<`anthony> s/kill/rmmod
<mjg59> `anthony: We call cardctl eject, which ought to be enough for that
<thom> oh man, i so loathe C++
<`anthony> mjg59: I needed to do vbetool post - vbetool vbestate save/restore didn't do the job.
<mjg59> `anthony: Hm. That's a shame.
<mjg59> vbetool post kills some machines :)
<`anthony> Yay!
<no0tic> it's useful for you to know my experiences with standby & hibernate?
<mjg59> no0tic: Yup, but I have to go out for a few minutes
<mjg59> Can you add them to www.ubuntu.org/wiki/HoaryPMResults ?
<no0tic> yes
<`anthony> mjg59: I can add stuff, although this box is still running FC until Hoary is out.
<no0tic> mjg59: how can I edit the wiki, once logged in?
<Kamion> there's an "Edit" tab around the top left
<thom> pitti: i'm bailing on this patch for hoary, too
<thom> pitti: i don't think it's reasonable or supportable
<thom> c
<thom> uh, this isn't mutt
* thom trys that on the correct desktop
<ogra> :(
<daniels> Kamion: i assume /etc/profile is the best way to set global environment variables?
<Kamion> daniels: the whole notion of global environment variables is a horror show
<daniels> Kamion: no shit
<Kamion> /etc/profile is global to all interactive login shells
* netjoined: irc.freenode.net -> benford.freenode.net
<wasabi_> oooh.
<wasabi_> jbailey: rumers about a free jvm by ibm or something. ;)
<thom> yeah, they happen every 6 months
<jbailey> wasabi_: I've read those rumours for a while, but haven't been able to track one down.
<jbailey> Frankly I think the best bets are going to be the funding from Brazil for classpath hackers.
<wasabi_> ross burton has something on his blog
<jbailey> He's on planet.gnome, right?
<wasabi_> yeah
<jbailey> Feh.  Quoting esr.  Must be vapourware.
<wasabi_> haha
<jbailey> I've been looking at the jpackage stuff the last couple days trying to figure out how I feel about it.  It looks so handy, but it's so... rpm based. =)
<wasabi_> I had originally used the jpackages for Eclipse as a base for the .debs
<wasabi_> But, they are horrid.
<wasabi_> Unreadable spec files.
<wasabi_> tons of pushd and popd, in no particular order.
<wasabi_> So, I just looked at them and figured out what they did.
<wasabi_> I am not excited about JPackage at all.
<Kamion> scripts that use pushd and popd generally need to be thrown away
<wasabi_> It's a good resource for learning what needs to be done to make .debs. ;)
<Kamion> (as opposed to subshell, cd, exit subshell)
<jbailey> wasabi_: mjw pointed me at it as a way to consider doing things.
<mdz> morning
<mdz> lamont: ping?
<lamont> morning
<pitti> Hi mdz!
* lamont bets mdz is after livecd answer
<lamont> s
<mdz> lamont: curious about the rsyncable experiment
<Kamion> elmo: any idea why libxml2-python2.4 fell out of ubuntu-desktop? python2.4-libxslt1 still claims to need it ...
<lamont> uh, huh?
<Kamion> seb128: can I change libxslt1 to make the python bit depend on the new python2.4-libxml2 package name?
<pepesan_> hi all
<mdz> lamont: sladen said you were going to take a shot at getting advfs to use the gzip --rsyncable stuff
<seb128> Kamion: sure
<pitti> mdz: I changed the langpacks so that l-support does not depend on l-pack any more
<lamont> mdz: news to me
<pitti> mdz: so you can install auxilliary packages and gettext data independently
<mdz> but now I see that the most recent live CD build is 20050115, in which case I'm more interested in that
<Kamion> is germinate bug, I bet ...
<pitti> mdz: as proposed on the ML
<mdz> Kamion, lamont: what happened with today's build?
<lamont> mdz: I know that there was some discussion about doing that
<lamont> mdz: looking into what happened
<mdz> pitti: sounds good
<lamont> rootfs build barfed, at the very least
* lamont disappears to the other workspace to figure things out
<Kamion> make: *** [/srv/cdimage.no-name-yet.com/scratch/tmp/hoary-amd64/packages-stamp] 
<pitti> mdz: I built another round of pristine source and binary packages now, I can upload afterwards if you are fine with that :-)
<Kamion> Error 1
<Kamion> ERROR WHILE BUILDING OFFICIAL IMAGES !!
<Kamion> whatever that means
<mdz> pitti: I am fine with that
<Kamion> sheesh, it's been doing that for days. sorry I didn't notice
<Kamion> lamont: king.warthogs.hbd.com is not answering HTTP queries
<Kamion> please fix, kthxbye
<lamont> Kamion: it's part of the whole 'deal with the datacenter changes' cruft
<lamont> I think it's fixed, testing now
<Kamion> cjwatson@little:~$ ping king.warthogs.hbd.com
<Kamion> PING king.warthogs.hbd.com (82.211.81.150) 56(84) bytes of data.
<Kamion> From little.warthogs.hbd.com (82.211.81.136) icmp_seq=1 Destination Host Unreachable
<lamont> Kamion: btw, the name is 'king.buildd'.
<Kamion> same for all the other buildds
<Kamion> oh, I didn't know it had been changed
<lamont> yeah - this past saturday
<lamont> the fact that I broke the livecd rootfs build at the same time is, um, interesting
<Kamion> lamont: they answer from chinstrap, but not from little
<lamont> see routing on chinstrap vs on little, then
<lamont> and pester elmo
<Kamion> would also be nice if somebody would turn off the old names so that I got proper errors
<lamont> there is some lagtime in making dns changes to w.h.c :-(
<Kamion> elmo: could you teach little how to route to the buildds so I can fetch live rootfs builds, please?
<Kamion> I've fixed debian-cd for the new names
<lamont> actually, I didn't break the livecd rootfs until after the build on the 17th
<lamont> Kamion: did you upload a new debootstrap with the libunwind7-dev fix
<lamont> ?
<lamont> in scripts/hoary?
<mdz> lamont: is it fixed now?
<mdz> (live images, not ia64)
<Kamion> lamont: I took libunwind7-dev out, yes
<lamont> rootfs build appears to be fixed
<Kamion> debootstrap would have failed since libc6.1-dev isn't in required (nor should it be)
<mdz> lamont, Kamion: please do a fresh build so that I can test yesterday's casper changes
<lamont> Kamion: yeah - that's what I just ran into...
<Kamion> mdz: will do once I have routing
<lamont> mdz: he needs routing
<mdz> elmo?
<Kamion> it seems to have been broken since 20041115 :(
<lamont> Kamion: yeah, that'd be right
<mdz> lamont: but once he has routing, there are three new cloops waiting?
<mvo_> elmo: can you please sync dpkg-1.10.26?
<lamont> well, in about 20 minutes or so
<mdz> ok, thanks
* Kamion is also trying to get a new Array CD done today, ideally ...
<lamont> mdz: so that could be a 'yes' :-)
<mdz> 10.211.37.0/24 via 82.211.81.157 dev eth0
<lamont> Kamion: I know I told elmo that the move required changes on the cd build side... should have told you then, too.. sorry
<mdz> looks like what you need
<mdz> thom: here?
<thom> mdz: yes
<mdz> thom: can you do a quick fix for us on little until elmo returns?
<thom> just to fix the buildd routing?
<thom> sure
<mdz> yeah
<lamont> Kamion: I'll tell you when the rootfs's are ready
<mdz> and someone email elmo so that he can fix it permanently
<lamont> Kamion: you want that, or shall I?
<Kamion> I'll do it
<lamont> rt@rt...?
<Kamion> yup
<thom> mdz: done
<mdz> thom: thanks
<Kamion> mail sent
* mdz mumbles about iproute not being installed
<mdz> --- king.buildd ping statistics ---
<mdz> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
<Kamion> thanks, seems better
* thom goes home to see how his brother is
<thom> had arthroscopy (however you spell it) yesterday
<lamont> Kamion: images current on all 3./
* lamont still wants to know what we're gonna do about ooo/ia64
<Kamion> mdz: how about making openoffice.org stuff be [amd64 i386 powerpc sparc] ?
<lamont> how big are those _all.deb's I wonder... /me checks
<Kamion> new daily-live build running
<mdz> Kamion: fine with me
<mdz> lamont: thanks
<Kamion> at least the stuff in desktop
<lamont> Kamion: that bloats the archive by about 54 MB currently
<Kamion> what does?
<lamont> how about making openoffice.org stuff be [amd64 i386 powerpc sparc] ?
<lamont> that
<Kamion> doing that wouldn't kick them out of main
<Kamion> it would merely kick them out of ubuntu-desktop
<lamont> ??
<lamont> why would it kick them out?
<Kamion> of which?
<Kamion> we're talking at cross-purposes, I feel ...
<lamont> oh -wait - where are you suggesting to change../
<Kamion> lamont: I'm suggesting adding [amd64 i386 powerpc sparc]  to all the seed entries in desktop for openoffice.org
<lamont> Kamion: woot.  agree
<Kamion> lamont: oh, you thought I meant make the actual .debs arch-specific? no, not that
<lamont> right
<lamont> same syntax and all that
<Kamion> done
<Kamion> next ubuntu-meta upload should take care of it
<mdz> mvo_: did you receive my email about apt 0.6.30?
<mvo_> mdz: yes, I would like to do it all in one go and was asking about dpkg first
<mvo_> Keybuk gave me his ok to upload a patched dpkg as well, he just asked me to wait for the dpkg-1.10.26 sync
<Kamion> mdz: daily-live build up, seems to work this time
<mdz> excellent
<mdz> thanks, Kamion and lamont
<mdz> and thom
<Keybuk> did you ask for the sync?
<mvo_> Keybuk: yes
<Keybuk> coolios
<mvo_> but only a couple of minutes ago :)
<elmo> mvo_: done
<mvo_> elmo: great, thanks!
<seb128> mvo_: about #5632 ... your patch was not supposed to fix that ?
<mvo_> seb128: that was what it intended, let me check
<mvo_> seb128: the problem seems to be in gnome-system-tools 
<mvo_> modem-applet calls g-s-t
<mvo_> seb128: just assign the bug to me, I'll take care of it
<seb128> mvo_: gni ? network-admin ask for the root password if it's not runned by root ... that's why we have "gksudo network-admin" as a menu entry :p
<seb128> mvo_: there is a bug open about "gst should use sudo instead of su internaly" ... is that a dup ?
<seb128> ie: do you want to fix gst or to workaround the applet ?
<mvo_> seb128: probably
<mvo_> seb128: probably a dup
<seb128> ok
<elmo> mdz: ok with supressing $distro-changes mails for language  packs?
<pepesan_> hi all!!!!!!
<pepesan_> im lookin for someone what is developin the ppc port
<sivang> mvo_: it is already using it IIRC?
<seb128> sivang: speaking about gst ?
<sivang> seb128: yes
<seb128> sivang: it uses su
<sivang> seb128: ergh, I thought that was already patched...
<seb128> sivang: we workaround by using "gksudo <...-admin>" in the menu entries
<Kamion> pepesan_: you're more likely to get an answer if you say what you want ... :)
<sivang> seb128: oh, ok, so mvo is going to make it use libgksudo ?
<seb128> sivang: you are in the cc of the bug, I've just commented on it
<pepesan_> Kamion: Hi, i wanna help to the ppc port and help to the live ppc port
<seb128> sivang: dunno ask him for the details. The bug has a patch to use sudo instead of su but doesn't build here, the idea is here BTW
<Kamion> pepesan_: download, send patches :)
<Kamion> pepesan_: bear in mind we try to minimise the amount of stuff that's architecture-specific; the new live powerpc CD deliberately uses pre-existing code almost all the way, so it took almost no explicit porting effort
<pepesan_> Kamion: i represent a part of a spanish region waht develop a distro for educational pourpuses
<Kamion> if you want to work on the live powerpc CD, you might as well just work on the live CD in general, for most purposes
<pepesan_> Kamion: we want to help the betatesting and development of the live ppc and ppc distro 
<Kamion> what do you need to know?
<pepesan_> there are many mac in the institutes of this region
<pepesan_> Kamion:  who help in the port
<pepesan_> sorry
<pepesan_> how help in the port
* T-Bone sees cdimage.u.c throughput sucking: 180ko/s ;^P
<Kamion> pepesan_: find something you need to fix, fix it, repeat :-)
<T-Bone> Kamion: gonna try last ia64 hoary. Seems that there are still issues with it
<pepesan_> Kamion: we want to port many packages to ubuntu
<Kamion> pepesan_: seriously it's hard to give better advice than that ...
<pepesan_> Kamion: i know
<pepesan_> Kamion: there is a list of development of the ppc port?
<lamont> pepesan_: once you add universe, ppc is pretty close to i386 in terms of package count
<Kamion> no, we don't have port lists
<Kamion> development is on ubuntu-devel@ until it accumulates enough traffic to annoy other developers enough to want it split off :)
<Kamion> the Mac-specific development that needs work is along the lines of support for very new hardware like the G5, support for power management, and figuring out how to make the installer work on oldworld powermacs
<Kamion> package builds take care of themselves in the vast majority of cases, under the able stewardship of our build daemon maintainer
<pepesan_> yep
<pepesan_> the prinpicipal problem is the way to manage pointers
<pepesan_> bigendian a nd litle endian
<Kamion> ?
<pepesan_> and the hardware support
<Kamion> that's only a problem with a tiny minority of very broken packages
<Kamion> most of those got fixed in Debian years ago, since powerpc is a mature port
<pepesan_> beleave me there are many new packages that doesnt support that
<pepesan_> especialy that kind of packs
<Kamion> not IME
<pepesan_> there are very espeficic
<Kamion> occasionally you have to fix an endianness bug or an assumption of unsigned char, but it's relatively rare nowadays
<pepesan_> ok
<Kamion> s/unsigned/signed/
<pepesan_> i beleave u :)
<Kamion> support for very old or very new hardware is more interesting and much harder
<pepesan_> there are any road map for the ppc lice distro?
<Kamion> once again, the plans aren't powerpc-specific
<pepesan_> ahh
<pepesan_> ok
<Kamion> the live CD plans are at http://www.ubuntulinux.org/wiki/LiveCD, under "Ongoing development"
<lamont> Kamion: did you upload a new ubuntu-meta to go with your seed changes?
<Kamion> lamont: no, not yet
<Kamion> shall I do so?
<T-Bone> Kamion: does today's ia64 ISO contain all the fixes for the various problem we've been tracking down?
<lamont> we might get an ia64 livecd if we do...
<T-Bone> lamont: I was just thinking about that, not daring to suggest it ;^)
<Kamion> T-Bone: it's got the elilo fix and the others from earlier
<T-Bone> Kamion: ok fine
<Kamion> should be ok
<Kamion> updating ubuntu-meta now
<lamont> T-Bone: there are a couple of other uninstallables on ia64, but those should be cleaned up by the time we get u-m inb
<T-Bone> lamont: heh ok
<T-Bone> are there mirror for the daily ISO snapshots?
<Kamion> pepesan_: testing and bug-fixes for the powerpc live CD would be very welcome, though
<lamont> Kamion: how hard would it be to put up an (unusable) iso of the livecd that was missing the cloop fs?
<lamont> that would be a less painful rsync, and then we could just rsync the fsimage, or something...
<seb128> lamont: please kick nautilus-sendto build
<Kamion> lamont: probably tolerable, but I don't see how it would make life any easier; rsyncing the ISO should be about as hard as rsyncing the filesystem image
<Kamion> since it's basically just a few bytes around the image
<pitti> fabbione, lamont: Accepted pkgstriptranslations 4 (source)
<pitti> fabbione, lamont: believe me, you _want_ this version on your buildds
<pitti> *cough*
<sivang> pitti: do you know if the culmus package got into main finally? I talked with mdz about it last night, don't know the outcome.
<lamont> seb128: done
<no0tic> the system doesn't recognize correctly my cpu freq
<seb128> lamont: thanks
<no0tic> what can I do?
<lamont> Kamion: I meant the filesystem, not the image.
<lamont> pitti: yeah, and the new sbuild and buildd-config, and....
<pitti> sivang: me neither, I had to leave after the meeting
<sivang> pitti: ah ok.
<Kamion> lamont: oh, I see
<lamont> Kamion: that one's highly rsyncable...
<Kamion> lamont: hm, yeah, could do
<crimsun> sivang: from an update a few minutes ago, it looks like it's still in 'universe', though I don't have access to the machines themselves to check.
<sivang> crimsun: ok, then I have to talk to mdz then :)
<Kamion>     culmus |     0.93-1 | warty/universe | all, source
<Kamion>     culmus |    0.101-1 | hoary/universe | all, source
<crimsun> thanks, Kamion.
<lamont> seb128: you know nautilus-sendto is universe, yes?
<Kamion> it certainly hasn't been seeded, which would be a requirement
<sivang> Kamion: k
<Kamion> pitti: *grin*
<seb128> lamont: yep
<pitti> Kamion: Yes, I know, that was dumb...
<Kamion> hey, it happens
<ogra> who stole my sound ?
<Kamion> I managed to kill all the logic to add the initial user to groups, sudoers, and aliases the other day
<lamont> ogra: open volume control, change it to the alsa mixer
<lamont> and file a bug about it so seb128 will fix it. :-)
<seb128> DOH
<ogra> hmm, i got no alsa mixer....damned....
<no0tic> ogra: I had the same problem
<ogra> ah, nm, fount the hidden option
<ogra> ooohh.....suddenly i got 4 volume controls in the panel *g*
<pepesan_> Kamion: ok i have a ibook g4 for testing and the region admin have a lot of g5
<ogra> thanks lamont
<ogra> seb128: need a bug as reminder ?
<lamont> seb128: is that really in your arena, or where is it coming from?
<ogra> havoc pennington ?
<seb128> lamont: I have no idea on this bug, first time I heard about it
<seb128> need details
<seb128> ogra: reminder of what ?
<lamont> seb128: somewhere in the last couple of weeks or so, upgrading hoary causes things to switch to the oss mixer, and sound goes *poof*
<lamont> seb128: ogra's talking about the same bug
<seb128> hum
<ogra> seb128: to fix it if its your domain
<seb128> no idea of that's due to the system or GNOME, fill a bug
<ogra> seb128: looks like an upstream chane
<ogra> change
<ogra> seb128
<seb128> ogra: GNOME side ? do you know how to get it from scratch ? could you try to downgrade ?
<lamont> ogra: mostly I was trolling seb128, but it might actually be his to fix (gnome)
* lamont has no clue where the bug actually lives.
<ogra> seb128: it could also be alsa in todays kernel upgrade
<trulux> pitti: ping
<seb128> ogra: right, that's why I need details on when it happened (just after a GNOME update ?) etc
* ogra looks which upgrades came during the day....
<trulux> pitti: ping
<pitti> trulux: pong
<trulux> :)
<Kamion> lamont: ubuntu-meta uploaded, with any luck ubuntu-desktop should be installable on ia64 now
<pitti> trulux: pong png
<seb128> ogra: no GNOME change today if you upgrade every day
<trulux> pitti: ok, time to do the gcc packages
<Kamion> if it isn't, the problem is not OOo ... :)
<trulux> pitti: so, finally what you take is gcc-ssp
<ogra> seb128: i do, so it might be a kernel issue
<trulux> right?
<lamont> Kamion: yeah, checking on the other languishing children now.
<trulux> or gcc-hardened?
<Kamion> lamont: contact-lookup-applet probably still a problem
<Kamion> oh, which just built
<lamont> Kamion: ssshhhh!
<pitti> trulux: -ssp
<ogra> seb128: must have happened during the day....i rebooted this morning and it worked.....i rebooted 1/2h ago and it changed...
<lamont> ia64 had a few give-back's land on the floor
<trulux> pitti: ok
<trulux> pitti: is that the final decision?
<seb128> ogra: ok, not GNOME so
<ogra> nope
<seb128> ogra: what did you update ?
<ogra> i run update-manager .... everything that came since tonight.....
<ogra> so it could also be hotplug which got updated ....
<seb128> ogra: ok, good luck :p
<seb128> I've to go for dinner
<ogra> heh
<seb128> later
<pappy-> good morning
<trulux> pappy-: hey
<trulux> pappy-: pitti is the guy who is working together with us in the deployment of a hardened toolchain
<ajmitch> hi trulux, pappy- 
<trulux> hey ajmitch
<Hwolf> Hi. Sebastian told me to come here since after the recent upgrades I've got issue's with oss/alsa.
<pappy-> pitti: nice to meet you, Sir.
<trulux> pitti: me and ajmitch are working on SELinux stuff, we are trying to form a work team
<lamont> woot.  jabber came back
<trulux> pitti: pappy- is the man who you should ask for toolchain (gcc and glibc) issues
<trulux> pitti: he is one of the best guys that can help you with the work
<trulux> pitti: I will take the kernel work, so, ask me all about kernel-related issues
<trulux> i will start filling the bugzilla with my junk ;)
<Kamion> lamont: ok, in that case I think you'll be good to go in an hour or so
<Hwolf> Is there anyone here knowledgeable about alsa/oss?
* Kamion wonders how many people will actually *use* an ia64 live CD ...
<pappy-> lamont: hi
<crimsun> Hwolf: what do you need?
<T-Bone> Kamion: 1: lamont :)
<ogra> Kamion: give me the HW, then i'll use it ;p
<Kamion> T-Bone: true :)
<T-Bone> hehe
<lamont> T-Bone: you better use it too...
<T-Bone> lamont: gaah. Nah. I do install my boxes you know. Especially when they are _poweful_ ones ;)
<lamont> actually, once the livecd works, I plan to drop a handful of them on the linux gang in hp ftc
<Hwolf> crimsun, After the recent updates my audigy card doesn't show up in applications / sound & video / Volume control anymore. However, it does work. 
* Kamion goes for dinner with parents
<Hwolf> crimsun: I think it is using oss rather than alsa
<T-Bone> lamont: actually i think that a 'server-oriented' ia64 liveCD would prove useful
<crimsun> Hwolf: the contents of /proc/asound/cards should list your audigy
<T-Bone> (from a technical and 'marketing' PoV, that is)
<ogra> Hwolf: look in File->Change Device (german here, might be called different)
<crimsun> Hwolf: next, check lsof /dev/dsp* ; lsof /dev/snd/*
<ogra> Hwolf: in the volume control....
<lamont> T-Bone: yeah - in it's raw form, I don't expect many to use it.  But as a proof of concept for what you can do with ia64 and a bootable CD, ....
<pappy-> pitti: have a time?
<T-Bone> lamont: yeah, exactly
<Hwolf> crimsun: root@system:/home/hidde # lsof /dev/dsp
<Hwolf> COMMAND  PID  USER   FD   TYPE DEVICE SIZE NODE NAME
<Hwolf> esd     9488 hidde    5w   CHR   14,3      7474 /dev/dsp
<lamont> and it's a good thing to have when all you can find are hp-ux ia64 boxen...
<crimsun> Hwolf: that seems fine. Followed ogra's tip?
<T-Bone> lamont: heh ;)
<trulux> pitti: hey, are you there?
* lamont will go into town tomorrow and download a couple of livecd's.
<pitti> pappy-: nice to meet you; trulux, thanks for the introduction
<T-Bone> lamont: as a matter of fact, I wouldn't have many friends owners of ia64 to make switch to Ubuntu :)
<ogra> crimsun: there is a bug in the selection of the default mixer it seems, i just try to find out which package it introduced in todays update...
<lamont> T-Bone: do we know anything about scsi vs ide?
<T-Bone> lamont: not really. Thierry installed hoary on his zx2000 SCSI box
<trulux> pappy-: no problemo, now it's your time, sure pappy will help all of us to make this going in the right way (tm)
<T-Bone> and didn't hit the anna issue either
<ajmitch> hi pitti 
<T-Bone> lamont: i have to test it on my zx6000. Will do that quickly in a few minutes
<T-Bone> (burning the cd atm)
<Hwolf> crimsun: it shows up now
<lamont> T-Bone: kewl
<pappy-> t-bone, lamont
<pappy-> this sounds like a debian-hppa reunion here
<T-Bone> pappy-: heh, always the same faces everywhere ;)
<crimsun> Hwolf: right, then we need to pinpoint which gnome package introduced it. I'll check aptitude logs in a sec.
<Hwolf> crimsun: There is something quite wrong with that.
<lamont> pappy:
<lamont>  tail -2 quinn-diff/list.stage2.hppa 
<lamont> Total 779 package(s) in state Installed.
<lamont> Total 828 package(s)
<ogra> crimsun: no gnome update today....
* T-Bone curses lamont for doing all the stuff by himself ;)
<Hwolf> I was running rythmbox / audigy / alsa, opened gnome volume-manager and now I've got no sound
<ogra> crimsun: i suspect linux-image or hotplug
<pappy-> lamont: :-)
<elmo> Kamion: you still wondering about that xslt thing you asked about earlier?
<lamont> T-Bone: was christmas break, and you were walk-about or some such...
<pappy-> you guys rock
<T-Bone> lamont: fair enough. But I had warty ready before that, remember ? :)
<lamont> pappy: apt-get source linux-meta
<lamont> T-Bone: yeah, well..
<pitti> trulux: sure, I'm here. Just a bit busy...
<lamont> and 2.6.10-10 kernel has hppa in it as well.
* lamont is saving d-i for t-bone
<T-Bone> lamont: lol, damn you! ;)
* T-Bone is always doing the dirty parts, and only gets a rice-bowl a day for it ;)
<lamont> T-Bone: just don't try to use a gscps2 mouse with that kernel, apparently
<lamont> T-Bone: but it's good sticky rice, not that bara-bara crap.
<T-Bone> lamont: doh? A kernel bug? Have to fix that :P
<lamont> T-Bone: fixed in cvs
<T-Bone> lamont: lol true ;)
<T-Bone> lamont: ah ok
<Hwolf> crimsun: opening volume control for me stops rythmbox from playing. I need to switch volume-control to audigy before it starts playing
<lamont> in 2.6.11-rc1, which is why we don't have it...
<T-Bone> roger that
<pitti> ajmitch: Hi!
<Hwolf> crimsun: I can't get my line-in working (from tv-card to audigy) But tv-card is happily outputting the sound to my line-out, and audigy line-in is open
<T-Bone> geez these 4X RW are slow shit
<trulux> pitti: why hoary uses PAM 0.76?
<crimsun> Hwolf: so you have two cards?
<pappy-> pitti: do you employ the default-disabled SSP patch in your default gcc packages
<Hwolf> crimsun: tv-card and sb-audigy
<pappy-> pitti: afaik it has no negative side impacts i know of.
<crimsun> Hwolf: both of which use alsa modules according to /proc/asound/cards?
<crimsun> Hwolf: we should remove this to #ubuntu
<pappy-> (other than that it does not work on -hppa that is)
<pitti> mdz: ping
<pitti> trulux: hmm, what else?
<trulux> pitti: sid and Hoary are using PAM 0.76
<trulux> should use at least 0.77
<pitti> pappy-: it's in the source package, but not activated
* decko is going home...
<pappy-> pitti: that did not answer my question.
<mdz> pitti: pong
<pappy-> pitti: when i apt-get install gcc, can i do gcc -fstack-protector-all, yes or no?
<pappy-> as a user?
<pitti> pappy-: <pitti> pappy-: it's in the source package, but not activated
<sivang> mdz: culmus is still in universe, did you approve moving it to main and it awaits seeding?
<pitti> pappy-: -> no
<pappy-> pitti: aha.
<pitti> pappy-: it is not built
<pappy-> pitti: same as Debian then.
<mdz> sivang: yes
<pappy-> pitti: intention to change it?
<sivang> mdz: ok, thank you!
<mdz> sivang: I'll add it now
<pitti> pappy-: that's the reason why we want completely separated source packages in universe
<trulux> pappy-: my patches are the one included
<pappy-> pitti: sorry for misunderstanding you, but with "activated" i refer to "on by default building SSP"
<trulux> we have still the ability f changing the ssp code by the libssp
<pappy-> trulux: your libssp patches?
<pitti> mdz: we are ready to upload, we only need a final ack about suppressing "Accepted" mails to *-changes for language-packs
<pitti> pappy-: no, I meant that the patch is not applied; sorry
<pitti> elmo: mdz is here, final ack :-)
<pappy-> pitti: okay, thanks anyway for making it clear to me.
<pitti> pappy-: the problem is that we cannot just enable it and use it
<trulux> pappy-: the libssp support patches
<pappy-> pitti: i do can.
<pitti> pappy-: if it breaks anything, our release would be screwed
<pappy-> pitti: yes, i understand
<pitti> pappy-: so we want some independent test packages in universe to play around with
<pappy-> pitti: Debian Hardened that is.
<pappy-> pitti: we will try to steal as much hoary as we can and test-drive our work on your stuff, if you like.
<pitti> pappy-: theoretically it would even possible to automatically build a parallel ubuntu-ssp archive
<tseng> heh, pappy-.
<pappy-> ha tseng 
<pappy-> pitti: yes.
<ajmitch> pitti: If this stuff went into main, it'd be for the release post-hoary?
<pappy-> pitti: trulux will coordinate that.
<pitti> elmo: I meant, "to give final ack", not "he gave"
<trulux> pappy- is right
<pitti> ajmitch: yes, post-hoary in any case
<trulux> :)
<pitti> ajmitch: but it is important to get it working in the hoary timeframe
<pitti> ajmitch: so that activating ssp would be one of the very first things we do
<ajmitch> ok
<pitti> ajmitch: (for hoary+1)
<ajmitch> since the release process for hoary+1 will start straight away, and you'd need to recompile everything with the -ssp compiler
<ajmitch> true?
<pappy-> pitti: Debian Hardened will build default PIE and SSP at as much packages as possible, being independent from RSBAC (which distinguishes it from Adamantix at the moment)
<pitti> ajmitch: yes
<pappy-> pitti: i think you know the tricks i am playing on toolchains since some years.
<pitti> ajmitch: but primarily to follow the "early breakage" principle
<trulux> pitti: I'm doing SELinux work for Hoary, so, it could be added in the first release
<trulux> just packages updates and fixes
* ajmitch checks... I think libselinux is in main already
<trulux> pitti: would you propose me for being an official Ubuntu dev? ;D
<trulux> ajmitch: yes, but not the last revision
<T-Bone> lamont: booting the zx6000
<ajmitch> trulux: that doesn't matter, getting it in there in the first place is what's needed :)
<pitti> trulux: if you prepare and maintain packages, yes, why not
<pitti> trulux, ajmitch: I'm off for a bit (about an hour)
<trulux> pitti: ok, i'm going to make my first "stable" ones for Hoary :)
<ajmitch> ok pitti, see you later
<T-Bone> Kamion: something is screwed with the dating script. The iso claims to be "built on 20041227ubuntu6"
* ajmitch should ask for inclusion as well soon :)
<mdz> pitti: suppressing emails?
<mdz> pitti: if you think it is appropriate, I don't see a problem
<mdz> do you plan to update the packs every day?
<trulux> ajmitch: have you sent the bug to the bugzilla?
<ajmitch> trulux: nope, only just installed latest kernel to check 
<T-Bone> lamont: i'm up to partitionning HD, no anna-bug
<T-Bone> lamont: but the internal SCSI controller isn't detected, it can't find any disk
<pitti> mdz: well, would you like to get 246 accepted emails initially and then a bunch of them every day?
<pitti> mdz: daily update is not really possible right now
<pitti> mdz: since Rosetta does not yet support this
<pitti> mdz: but eventually yes
<pitti> mdz: I still get REJECTED and NEW messages, so I know about problems
<mdz> Kamion: gah, casper is missing a depnedency on md-modules
<mdz> pitti: whatever you and elmo agree on is fine with me; don't let me be a bottleneck
* T-Bone lacks lspci on the installer to find out which driver to use ;P
<ajmitch> trulux: bug filed
<mdz> T-Bone: /proc/bus/pci?
<T-Bone> mdz: i walking through, but it's far less practical
<ajmitch> ugh I dislike bugzilla :)
<mdz> I thought there was a udeb with it now
<fabbione> hey mdz
<trulux> ajmitch: great
* T-Bone can't find relevant info in /proc/bus/pci, looks in /sys
* ogra wonders if either todays hotplug or the linux-source upgrade killed his sound setup
<trulux> ajmitch: bug number?
<ajmitch> trulux: almost filed, I should say..
<mdz> fabbione: good morning
<ajmitch> it complained, I have to go back
<trulux> ajmitch: okay dockey
<trulux> fabbione: hey
<fabbione> mdz: if you have time could you take a look at ubuntu-meta for sparc? i know several bits need modification
<fabbione> hey trulux 
<fabbione> T-Bone: i fixed that USB keyboard config thingy on ia64
<ajmitch> hi fabbione 
<fabbione> mdz: the repo is at sparc.u.c
* fabbione waves 
<mdz> fabbione: you have a patch that you want me to review, or you need me to do the changes?
<mdz> fabbione: the former is much faster ;-)
<fabbione> mdz: sorry i don't have a patch
<fabbione> but Kamion was talking about germinate/seeds ubuntu-meta
<T-Bone> fabbione: has it been integrated into todays iso?
<fabbione> T-Bone: no. it is in 2.6.10-10 that i uploaded a few hours ago
<T-Bone> mdz: there's no way I can't find what PCI device i have, and i can't even look into 'load installer component from the CD', because d-i won't let me load anything, though the failing step comes _after_ loading components
<fabbione> so i believe it will be in tomorrows cd
<T-Bone> fabbione: ok
<pitti> mdz: that was actually the last outstanding question. Now I'm ready to upload :-)
<T-Bone> s/I can't/I can/
<mdz> pitti: fantastic
<Hwolf> Can anyone here help me find out why I since a recent upgrade I can't use my line-in anymore?
<fabbione> ok.. i really need a shower and cook some dinner
<fabbione> only 3 hours to pain the living room is a record :)
<fabbione> mdz: anyway there is NO rush for it
<fabbione> mdz: i still lack a few packages in main (outdated) to be 100% synced
* fabbione &
<ogra> fabbione, mdz: who of you broke my sound  ?
<fabbione> not me
<mdz> I don't break things
<ogra> there were only two sound related updates today for me....
<fabbione> ogra: talk with seb128 :-)
<ogra> hotplug and linux-image
<fabbione> ogra: blame hotplug
<ogra> heh, fabbione i already did
<fabbione> lamont was talkign about a similar problem
<ogra> isnt it policy that he is always the first to bug ?
<fabbione> that for some reason the default in the mixer was changes to oss
<ogra> yup, i know
<fabbione> ok
<fabbione> ogra: you can blame everything other than the kernel...
<fabbione> and before the kernel your crappy hardware
<fabbione> ;)
<fabbione> ok i need to go really
<fabbione> i am starving
<elmo> mdz: are these okay for main?
<ogra> i think thats ok....but the oss mixer doesnt affect anything anymore, so it also could be a module thing
<T-Bone> fabbione: missing driver in ia64 conf, as it seems
<fabbione> cya tomorrow guys
<crimsun> ogra: do you have 2 cards?
<T-Bone> fabbione: you're gonna have to roll up new kernels again ;)
<mdz> elmo: language packs? yes
<fabbione> T-Bone: send me updated configs
<mdz> pitti: please seed them
<T-Bone> fabbione: will do
<ogra> crimsun: nope
<fabbione> T-Bone: cool
<fabbione> byr
<ogra> crimsun: laptop with via chip
<crimsun> ciao fabbione 
<ajmitch> fabbione: filed bug for the selinux & audit stuff for you
<mdz> elmo: speaking of main, #4750
<mdz> elmo: only the metapackages are seeded, so I think you just need to sync with germinate
<ogra> crimsun: it seems like the oss mixer stuff stopped working completely
<seb128> lamont: could you retry nautilus-sendto again on ppc/ia64 ? It didn't pick libebook1.2-dev 1.1.3-0ubuntu9 previous time
<pitti> mdz: oh, before uploading them? or after? does it matter?
<mdz> pitti: before elmo processes them
<Hwolf> crimsun: I've got my system working, however if I open gnome-volume-control the playing audio stops
<pitti> mdz: ok
<mdz> Kamion: why is there no 'british english' layout on powerpc or amd64 in d-i?
<mdz> Kamion: it breaks my finger macros
<mdz> (at least, if it's there, it isn't at the same point in the list)
<crimsun> ogra: does linux-image-$(uname -r) 2.6.10-8 work correctly?
<pitti> mdz: seed to supported for now? (and ship later, depending on how many languages we support?)
* T-Bone test-installs zx2000 now
<ogra> crimsun: hmm, let me try, i have only -5 installed ...
<crimsun> ack
<lamont> seb128: done
<crimsun> I assumed he was running -9
<seb128> lamont: thanks
<mdz> pitti: yes
<sivang> pitti: will it be possible to include another package as a depend of the language pack pacage, pulling in conffiles for GNOME kbd chooser to be already configured with the respective pack's language?
<T-Bone> lamont, Kamion: more breakage: unable to initrd-tools
<T-Bone> because of libunwind7
<mdz> elmo: please rm -rf ~mdz/public_html/ubuntu-live on little (it has some files owned by alex)
<T-Bone> it's trying to install libunwind7-dev which depends on libc6.1-dev
<mdz> Kamion fixed that
<lamont> after today's cd image?
<mdz> Jan 19 08:55:22 <Kamion>        lamont: I took libunwind7-dev out, yes
<mdz> Jan 19 08:55:40 <Kamion>        debootstrap would have failed since libc6.1-dev
<mdz> isn't in required (nor should it be)
<mdz> looks like it, yes
<T-Bone> lamont: yup
<T-Bone> lamont: or so i hope. It's labelled 'built on 20041227ubuntu6'
* lamont thinks he was confused by the fact that he was messing with hoary.buildd, which does require libunwind7-dev (since it's essential + build-essential)
<T-Bone> lamont: same player shot again, heh ;)
<crimsun> ogra: sorry, I presumed you were using -9
<ogra> hmm...its not the kernel
<elmo> mdz: done
<crimsun> ogra: needed you to back up to -8 if you were using -9. Are you using snd-via82xx?
<ogra> crimsun: i have only -5 for testing
<T-Bone> lamont: to make things better, the kernel in panicing on halt
<ogra> yup
<ogra> crimsun: my currently running kernel is -9 ...
<lamont> T-Bone: it halted. :-)
<T-Bone> lamont: no
<T-Bone> had to unplug
<lamont> 0 upgraded, 611 newly installed, 0 to remove and 0 not upgraded.
<lamont> Need to get 430MB of archives.
<lamont> that's a "go" for ubuntu-desktop/ubuntu-base installability on ia64.
<lamont> thanks Kamion 
<T-Bone> lamont: oh btw, don't make ubuntu-dekstop depend on ooffice on ia64, or else it will never install
<lamont> T-Bone: that was what Kamion  fixed.
<crimsun> ogra: so volume control only now began defaulting to oss?
<mdz> lamont: how long before I can expect casper 0.19 binaries (arch all) in the archive so that I can do a new live CD build?
<lamont> and ooo2 should fix that the other way
<T-Bone> lamont: ah ok cool
<lamont> mdz: when did you upload?
<mdz> -rw-rw----  1 mdz mdz  302 2005-01-19 11:24 casper_0.19_source.upload
<mdz> PST
<mdz> ~35 minutes ago
<ogra> crimsun: no, it keeps the setting you select....my defaut mixer was oss al the time, since i didnt touch the mixer since the warty upgrade of this lappie
<lamont> so the sources should have snapped at 11:33, and binaries should be there at 12:03
<mdz> sources aren't there (on archive.u.c anyway)
<ogra> crimsun: so it looks like the oss mixer doesnt work anymore but the unselected alsa works fine....
<lamont> mdz: and it's uploaded, so it built just fine for you
<mdz> lamont: ok, thanks
<ogra> crimsun: i'll downgrade hotplug for a test....
<mdz> lamont: can you document the time schedule on a wiki page and link it from DeveloperResources?
<mdz> lamont: also I think the build logs byDate view (and any others you might have besides the raw index view) should probably be documented there
<lamont> mdz: we'll do
<lamont> right - BuildDaemonInfo or some such, eh?
<Hwolf> Is there any reason for synaptic holding off on upgrading libslt1-python2.4?
<mdz> lamont: or ArchiveProcessingSchedule?
<Hwolf> libxslt1-python2.4?
<lamont> mdz: that doesn't quite describe the byDate stuff though...
<mvo_> Hwolf: might be because it was renamed to python2.4-libxslt1
<mdz> lamont: whatever you think is best, then
<Hwolf> mvo_ Can I safely replace it with the new version?
* T-Bone is exhausted, gives up for tonight
<T-Bone> see yall
<mvo_> Hwolf: see the description of the libxslt1-python2.4 package :) 
<Hwolf> Hm. There is openoffice2-debian in universe, but openoffice2 itself isn't
<crimsun> Hwolf: I can't reproduce the sound halt while opening gnome-volume-control.
<Hwolf> crimsun: Anything I can do?
<crimsun> Hwolf: which device is gnome-volume-control set to manipulate by default (when you open it)?
<Hwolf> Audigy-alsa
<Hwolf> I get a soundhalt. Closing the program and opening it again causes sound to resume.
<Hwolf> -2
<Hwolf> 2.6.10-2 is the latest I can see
<Hwolf> kernel 2.6.10-2-386
<crimsun> Hwolf: alsa-base is 1.0.8-1, and the latest for 386 is 2.6.10-9
<Hwolf> crimsun: not according to my hoary :-S
<Hwolf> Just ran an upgrade
<crimsun> did you update first?
<Hwolf> Ofcourse
<Hwolf> Got it from my grub menu, so I'm running -2
<crimsun> are you using apt-proxy?
<Hwolf> No
<crimsun> paste me `apt-cache policy linux-image-2.6.10-2-386'
<Hwolf> hidde@system:~ $ apt-cache policy linux-image-2.6.10-2-386
<Hwolf> linux-image-2.6.10-2-386:
<Hwolf>   Installed: 2.6.10-9
<Hwolf>   Candidate: 2.6.10-9
<Hwolf>   Version Table:
<Hwolf>  *** 2.6.10-9 0
<Hwolf>         500 http://archive.ubuntu.com hoary/main Packages
<Hwolf>         100 /var/lib/dpkg/status
<Hwolf> hidde@system:~ $
<crimsun> Hwolf: well, that was supposed to go to me in query, since this isn't directly related to ubuntu development.
<Hwolf> excusez-moi
<mdz> lamont: hmm, :18 now and still no casper
<ogra> crimsun, nothing... no idea what it is (
<crimsun> ogra: troubleshooting w/ Hwolf, too
<lifeless> daniels: erm....
<lifeless>  8879 root       5 -10  836m 583m 6056 S  0.3 57.6  20:04.41 Xorg
<mdz> lifeless: there's a Debian bug about X sucking up huge amounts of memory
<mdz> lifeless: what sort of apps are you running?
<lifeless> overnight, 2* gvim, evo 2.2, 1 uxterm running screen, and xscreensaver was running the lightning screen saver
* lamont points mdz at the other window
<lifeless> mdz: it was ok before I went to bed.
<mvo__> lifeless: it would be nice if you could confirm that #5412 (aptitude wants to remove the kernel) is solved with my latest aptitude upload (if possible)
<seb128> haggai: here ?
<lifeless> mvo__: erm, next kernel upgrade, sure.
<mdz> Kamion: little mirrors from mirnyy, right?  and updates its mirror as part of the CD build process?
<mdz> lamont: ran anonftpsync on little, it's there now
<crimsun> ogra: I'll need to continue in 4-5 hours, meeting now. I'll forward you anything I uncover.
<ogra> thanks :)
<lifeless> mdz: anything else you need before I nuke this sucker ?
<elmo> err, if I drag a folder  into CD/DVD creator it is _copying_ it right?
<elmo> and not symlinking it or something equally retarded
<ogra> elmo: i think its something like symlinking until it runs the mkisofs in the background....copying would consume a lot of diskspace
<mdz> lifeless: daniels is the one to talk to about it
<mdz> elmo: I think it's just remembering the name
<ogra> elmo:(and probably a lot of time too if you copy big files between partitions)
<mdz> elmo: there's a feature request to have it optionally copy, e.g. to enable copying CDs with a single drive simply
* lamont realizes that he needs to run to town for a bit... back in a while
<trulux> pitti: libselinux 1.20 for Ubuntu is almost ready
<trulux> ajmitch: ping
* smurfix grumbles. Bad power supply, keeps shutting off :-(
<kent> smurfix, have you checked the temperature of the cpu/motherboard?  my amd system shuts of time to time due to heat :(  Bad cpu-fan i guess..
<ajmitch> trulux: back
<mdz> Kamion: can I remove any of the casper symlinks yet?
<ajmitch> trulux: what changes did you have to make from the sid version? I just recompiled 1.20..
<Kamion> elmo: I'm still curious as to why it broke, but I think it's some complicated germinate bug to do with versioned dependencies on virtual packages
<Kamion> elmo: I just uploaded libxslt to avoid the problem, since I needed it to work fairly urgently
<mdz> Kamion: I need to do another upload anyway
<trulux> ajmitch: me too, added extra .ubunut banner to version
<Kamion> mdz: yes, go ahead
<ajmitch> trulux: hmm, why? :)
<trulux> we would need to add our specifical dependencies on it
<ajmitch> ok
<Kamion> mdz: little mirrors from mirnyy, yes, and anonftpsync is the first thing it does
<trulux> ajmitch: to follow standard Ubuntu versioning style
<mdz> excellent, thanks
<azeem> trulux: it's not .ubuntu though, but ubuntu, AFAIK
<ajmitch> check with others here - I thought ubuntu tags on versions was when stuff was patched, not just recompiled
<Kamion> mdz: I always use British English keyboard layouts, it's there
<ajmitch> hey azeem 
<azeem> ajmitch: dude
<trulux> azeem: ok, rebuilding
<mdz> Kamion: on i386 for me, it goes us, british, dvorak
<mdz> Kamion: but on amd64 at least it's us, dvorak
<Kamion> weirdness, I'd certainly notice immediately if it were missing
<azeem> trulux: uhm, I'm no pro on this. That was just a suggestion to check back with the doku
<Kamion> might be something to do with keyboard type
<Kamion> (at/usb/etc. differ)
<trulux> azeem: NP, this doesn't take a life to rebuild
<Kamion> there's only one keyboard type on powerpc though, it's all considered to be usb
* ajmitch wonders if he should leave a stack of ubuntu cds in the CS lab at uni
<amu> mdz: hmm probably late 20050119.1 casper cant load ext2, dm_mod
<trulux> ajmitch: :)
<ajmitch> yeah, it takes about 30 seconds..
<Kamion> ajmitch: when we make a source modification to 1.0-1, it becomes 1.0-1ubuntu1
<mdz> Kamion: I bet it's only missing when you select location 'united states'
<ajmitch> Kamion: great, that's what I thought
<ajmitch> trulux: so it should be safe to leave it at 1.20-1
<Kamion> ajmitch: you never just recompile without changing the version number (ahem, *shush* those who remember the great archive flush), so it'd have to be something like that
<mdz> Kamion: which, come to think of it, it should do consistently on all architectures
<Kamion> ajmitch: NOOOOO
<ajmitch> Kamion: hmmph
<Kamion> mdz: I find that implausible, knowing the kbd-chooser code
<ogra> ajmitch: dont make the same error i did ;)
<ajmitch> Kamion: source change, or recompile, which is it? :)
<mdz> Kamion: I have an i386 to my left, and an amd64 to my right, and the keyboard chooser menu is different
<mdz> Kamion: I can take a photo if you like :-)
<Kamion> ajmitch: you must not just recompile and leave the version number as it is. It will confuse the world.
<ogra> ajmitch: change is it
<Kamion> mdz: that might be useful actually
<ajmitch> ogra: don't worry, I don't have any upload rights yet :)
<mdz> ok, coming up
<Kamion> ajmitch: shouldn't you be changing build-dependencies anyway? that's a source modification
<ogra> ajmitch: this might be interesting: http://www.ubuntulinux.org/wiki/Uploads/
<ogra> ajmitch: i'm only three in advance of you ;)
<ajmitch> Kamion: it has no build-depends, really..
<Kamion> ajmitch: also for the real archive I don't think we should do a big rebuild effort; instead, just change the buildds and let things gradually get recompiled as they're moved over anyway
<ajmitch> apart from the usual build-essential
<Kamion> ajmitch: oh, you mean this is a Debian->Ubuntu port?
<mdz> gah
<ajmitch> yes
<mdz> passwd is asking all the questions
<Kamion> ajmitch: does it build from scratch in Ubuntu with no modifications?
<ajmitch> of a package that we would love to have in base
<mdz> full name, username, password, password-again at least
<ajmitch> yes, 1.18 is in ubuntu
<ajmitch> 1.20 is in sid
<Kamion> ajmitch: so why not just request a sync?
<ajmitch> that would be easiest, we're still waiting for manoj's new version to get into sid, iirc
<Kamion> ajmitch: from Debian->Ubuntu that's two separate archives so you're allowed to recompile without changing the version number; I thought you were talking about recompiling a package already in the Ubuntu archive
<mdz> daniels: ping
<ajmitch> we've got a few that will definitely  need version number changes
<ajmitch> since they'll need patches, which possibly won't be in hoary
<ajmitch> depends on how much of a window to get the userland patches for selinux in
<Kamion> you'd want to ask mdz/jdub/some-master-of-the-universe for permission to sync newer versions
<ajmitch> and for packages that are in main?
<Kamion> we're in upstream version freeze so that would be on a case-by-case basis and had better have a good reason
<ogra> ajmitch: UVF ..... you will need a real good reason
<ajmitch> that's what I thought..
<Kamion> not to say that exceptions can't be made if there is a good reason, but that isn't my call
<ajmitch> most of the packages we have to patch are in main, so we'll probably work on a separate archive of patched/upgraded packages until post-hoary
<ajmitch> trulux: what do you think?
<trulux> ajmitch: I think we could keep ubuntu banner on version strings, as it doesn't harm and it allows you to track the package
<pappy-> not for network daemons
<pappy-> that hurts security issues
<ajmitch> trulux: I mean having a separate apt repository for now
<trulux> pappy-: right
<pappy-> have it looking as vanilla as it can be
<pappy-> prevents information leaking through the network sockets
<pappy-> makes it harder for attacks
<azeem> ajmitch: what are you working on?
<pappy-> locally i don't care personally
<trulux> ajmitch: Hardened Debian separates reps, we have one for sid, sarge, woody and hoary
<ajmitch> pappy-: I think trulux means just the debian revision, right?
<pappy-> because i can do fingerprinting on all of your binaries when i am a user on a local machina.
<pappy-> ajmitch: i hope so.
<trulux> right
<ajmitch> azeem: selinux integration with trulux & others :)
* pappy- is talking about network service identification.
<azeem> ah
<trulux> yep
<trulux> pappy- is completely right, we can't call hardened daemons "-hardened": Oh, this is running apache-1.3.26-hardened
<Kamion> pappy-: I'm totally unconvinced by that argument, always have been
<trulux> best to leave the kids playing around and breaking their heads before they suddenly discover that it's a hardened package
<azeem> "OMG, they run -hardened, off to the next IP"
<pappy-> Kamion: i don't care if you are unconvinced.
<trulux> azeem: right
<Kamion> pappy-: in practice people just scatterbomb attacks without bothering to check the version strings first, and including version strings allows network admins to do auditing of machines
<Kamion> pappy-: that's nice of you
<ajmitch> azeem: what are you up to?
<azeem> ajmitch: lurking
<ajmitch> :)
* ajmitch is good at that
<pappy-> Kamion: so you know about "practice" and "scatterbombing"
<azeem> hehe
<pappy-> Kamion: show me figures.
<pappy-> and show me best before dates of zeroday exploits.
<pappy-> which make it through the internet "scatterbombing"
* ajmitch can see this discussion going nowhere
<azeem> Kamion: show me the money
<Kamion> show me a case where people bothered to check the version strings? come on
* trulux too
<Kamion> script kiddies never do
* pappy- gives in to your superior train of argumentation
<trulux> Kamion: but their tools do
<Kamion> I don't think yours is any better
<mdz> Kamion: aha, in the process of taking the photos I noticed the _other_ difference :-)
<mdz> Kamion: i386 is using a PS/2 keyboard, amd64 and powerpc are using USB
<pappy-> Kamion: i could care less.  i just leave it up to my users to decide.
<mdz> so no british english layout for USB?
<trulux> Kamion: i was a script kiddie many time ago, so, maybe i could get some fresh information on this thread
<ajmitch> trulux: ok, so can we upload some of this modified stuff to the hoary repository on debian-hardened then? :)
* trulux reveals his obscure past
<twisted_steel> quick hoary question: am I the only one who can't enter text in the address book applet?
<trulux> ajmitch: right
<pappy-> trulux: l33t!
<Kamion> face it, if you have a network service with a security hole, it'll get exploited whether the version number exposes the fact or not
<trulux> pappy-: w00t!
<ajmitch> trulux: can I get access? :)
<pappy-> Kamion: we are talking about exposing -hardened being a feature on the machine or not.
<pappy-> Kamion: it is silly to "show off" with it.
<pappy-> Kamion: maybe i don't get it though.
<Kamion> mdz: sounds possible if strange; that would certainly be a more relevant distinction
<trulux> ajmitch: It's not my box, but i could try to open access for you
<pappy-> Kamion: maybe i am too stupid.
* pappy- baits Kamion 
<ajmitch> ok
<pappy-> *g*
<trulux> ajmitch: we need to get mcp for install decent repositories
<trulux> because I'm using the boxes where I'm a sysadmin to host some stuff
<trulux> they are all using hardened debian stuff
<Kamion> pappy-: here's a use case: the network admins at the university I used to attend routinely do friendly probing of services throughout the network. Being able to detect vulnerable machines by banner probing allows them to notify local admins of problems often before the kiddies get around to it, which reduces the exposure of the network as a hole.
<Kamion> er, whole.
<ogra> guys did you consider using -honeypot instead of -hardened (i think it has the same effect)
<pappy-> Kamion: i agree with you
<trulux> ogra: good point
<pappy-> Kamion: but we were up to discussing "showing off l33t security improvements" via changing banners here.
<ajmitch> ogra: -rootable sounds better
<Kamion> so, if your version string lies about what the binary is, this compromises that goal.
<ogra> heh
<pappy-> Kamion: i often also deliberately change my banners to weak strings for honeypots
<pappy-> Kamion: compromising the goals of lazy admins is what i like.  instead of doing it properly.
<pappy-> centralized revision control on the servers.
<Kamion> personally I'm all up for having complete package version strings in the banners, but I'm sure I lost that argument a while back
<Kamion> openssh does this though, and it's useful
<pappy-> Kamion: have all the banners you like
<Kamion> well, in an abbreviated form due to crap ssh clients
<pappy-> Kamion: i will not support it and i will suppress it whereever i can and force it back to default looking style.
<pappy-> i want to make it look like a virgin daemon.
<mdz> Kamion: is there any way to override the cdebconf locks so that I can run two instances?
<pappy-> its not like some kind of obfuscation.
<pappy-> it is just not granting attackers an unwanted (and preventable) advantage.
<pappy-> nothing less.
<Kamion> pappy-: I'm sure; however I'll do what I think is best for my packages, such as openssh ...
<pappy-> Kamion: i don't think you will add -hardened to an openssh package that gets compiled by a hardened compiler.
<Kamion> no but the version string will reveal it to one who knows the history of the package
<pappy-> And if you did, i would be able to reverse it for my openssh packages.
<pappy-> So if we all keep our packages nice and handy.
<pappy-> the user base will decide in the end.
<Kamion> for somebody coming into an existing community and trying to get them to accept changes, you're taking an awfully aggressive tone, mister
<pappy-> Kamion: do you think so, Mister?
<pappy-> Kamion: i did not come here, i was invited.
<pappy-> you won't have to accept my changes.
<azeem> (somebody now tries to be quiet)
<pappy-> we just take the best out of your development works and put our stuff into it.
<pappy-> whether you like it or not, i am better than you, Kamion.
<trulux> Kamion: pappy- is a friend of mine, often he is acid, but he knows pretty well what he talks about
<azeem> pappy-: how old are you?
<trulux> anyway, don't fight please
<pappy-> azeem: not old enough.
<Kamion> haha, this is classic
<pappy-> trulux: we are just getting warm with each other, thats the usual practice.
<azeem> pappy-: there is a code of conduct lying on this channel, did you read it?
<pappy-> azeem: should i?
<ogra> yup
<azeem> if you want to participate and stay, I'd say yes
<pappy-> azeem: does it state that i have to shut up?
<azeem> pappy-: RTFM
<pappy-> azeem: i do not recall starting this "one" here.
<pappy-> you may call it "issue".
<ogra> http://www.ubuntulinux.org/community/conduct
<pappy-> and i really tend to be bored by stuff like that.
<trulux> pappy-: stop please, it's late, no point for make an ass kicking party
<pappy-> trulux: am i?
<pappy-> trulux: you know me and you know when i reached temperature.  so far i am very very cool.
<azeem> still, daniels is the coolest guy on the block
<pappy-> trulux: what if this guy treats me like a jackass and thinks he can make something out of it?  putting it bluntly: i won't go down that road in here.
<trulux> pappy-: ... don't start such type of conversation again, you know i disliked it when it happened in hard-tch list....
* azeem wanders off
<trulux> pappy-: if you don't like Kamion or anyone else, ignore him
* pappy- seen enough ubuntu for tonight.
<trulux> oops
<ogra> fh-trier.de ?
<mvo_> ogra: fh-trier.de?
* Kamion suggests not inviting people with known bad attitudes; it just makes life hard for everyone
<trulux> sorry, but don't misunderstand pappy, when you work together with him you know how to enjoy it
<ajmitch> that was fun..
<trulux> he is just a bit "acid"
<trulux> ajmitch: not really but i'm surpirsed
<trulux> haven't thought that pappy would start such a flame here ;D
<trulux> tseng: hey
<trulux> Kamion: there?
<Kamion> yes
<mdz> Kamion: I just noticed that firmware loading is still broken because the initrd has the old version of hotplug
<trulux> Kamion: anything wrong after the little fight? I'm sorry about it, don't be offended, it was just a stupid conversdation typical pof guys working harder in the wrong hours ;)
<mdz> Kamion: has the initrd not been rebuilt?
<Kamion> mdz: hm, I'll check, what's the fixed version?
<mdz> if not, I can't remove the casper symlinks yet, no?
<Kamion> yes, it's been rebuilt ...
<mdz> Kamion: ubuntu8 or later
<Kamion> trulux: not particularly, have just had the same conversation a number of times before and am not particularly impressed with the line of argument, having thought about it in some depth; but he's entitled to his point of view
<Kamion> I'm just saddened that people take such hard-line approaches to security
<Kamion> mdz: you should have an initrd.list file on the CD
<Kamion> in /install
<mdz> Kamion: it says ubuntu7
<Kamion> hotplug-udeb 0.0.20040329-16ubuntu7
<Kamion> hmm, bah
<mdz> ubuntu8 was uploaded at ~0100 UTC
<mdz> maybe just missed it
<trulux> Kamion: i can imagine
<Kamion> 1763   F Jan 18 To hoary-change (  46) Accepted debian-installer 20041227ubuntu6
<Kamion> 1766     Jan 19 Matt Zimmerman  (  47) Accepted hotplug 0.0.20040329-16ubuntu8 (
<trulux> mdz: did you have time to read my paper?
<Kamion> mdz: ping lamont for a daily build?
<mdz> trulux: URL?
<mdz> lamont: ping ^^^
<trulux> mdz: it is in the wiki, i sent it to you i think
<trulux> anyway, i will grab for it again , NP
<Kamion> mdz: I waited for all the symlink changes to be complete and built before uploading the new initrd
<mdz> Kamion: ah, ok, so that bit at least is safe
<trulux> mdz: https://www.ubuntulinux.org/wiki/HardeningNeededResources
<trulux> mdz: if you give me a chance i can try to do half of the work for SELinux deployment in two weeks
<mdz> trulux: I can't offer you human resources; we have none to spare
<trulux> it just depends on how and when Hoary will get released
<trulux> mdz: NP, i will recruit them ASAP
<ajmitch> trulux: you want me to do the other half then? :)
<mdz> trulux: so excluding that, you are saying that all you need are machines?
<Kamion> trulux: I'm sorry if he felt offended, but he did come back extremely dismissively to my initial remark, before I'd even finished typing the explanation
<mdz> trulux: you will take care of autobuild infrastructure and whatever else is necessary?
<ajmitch> mdz: there are a few of us working on it
<trulux> ajmitch: you will be the one working behind the scenes ;P
<ajmitch> selinux deployment shouldn't need much in the way of changes to packages..
<ajmitch> trulux: why do I get stuck behind the curtain? :)
<Kamion> I understood that there was a good bit of work needed in the packaging toolchain
<trulux> mdz: right, we need building machines, and we could take care of the rest of things
<trulux> ajmitch: lah, just joking
<Kamion> Keybuk works for us is the dpkg maintainer, he's talked to people before about this in case you weren't aware
<Kamion> s/is/and is/
<trulux> Kamion: yeah, he is not offended, it's difficult to make him feeling like that, don't worry ;)
<ajmitch> Kamion: yes, and manoj is working on hacking dpkg at the moment, iirc
<Kamion> trulux: heh, should imagine :)
<ajmitch> he's been quite active in selinux work lately
<trulux> yeah
<Kamion> yes, I need to get back to Manoj about openssh
<trulux> i must go to bed in 10 mins
<trulux> :(
<ajmitch> rjc is helping advise on policy, I think
<Kamion> trulux: resources> hm, why alpha? we don't support that architecture at the moment
<trulux> rjc is one of the best guys to help with that, he has wroten near the 30% of the SELinux policies
* Kamion fixes the resources page to be ReST, it looks like it was meant to be that way
<jdub> tseng: libdbus-cil
<trulux> Kamion: it's not the important one, as seems to be in the last position
<mdz> trulux: I don't think it is necessary to try to bootstrap on 5 architectures at once.  I think it might be possible to offer an x86 build machine; I will check into it
<jdub> tseng: not sure if daniels has fixed it yet or not
<jdub> morning all
<trulux> mdz: ok, great
<ajmitch> jdub: ubuntu .au meetup going to be in sydney?
<ajmitch> mornign jdub 
<haggai> seb128: back
<jdub> the next conf will be in sydney or canberra
<trulux> i will try to talk tomorrow night
<ajmitch> jdub: aha
<trulux> now it's bed time
<trulux> good night!
<ajmitch> night trulux 
<sivang> night trulux 
<ajmitch> jdub: just got to see if I can scrounge up the $ from the govt :)
<seb128> haggai: is /usr/share/applnk needed for KDE ? tvtime has 2 desktop files, one in /usr/share/applications/ and one in /usr/share/applnk/ for KDE according to the debian/rules
<mdz> Kamion: hey, db_register seems to have done the trick
<mdz> I wonder why that wasn't necessary before
<Kamion> mdz: you had initial-passwd-udeb loaded by anna, probably
<Kamion> mdz: that would have loaded the questions
<mdz> ahh
<Kamion> but now nothing was registering the questions so there was nothing for db_set/db_fset to work on
<mdz> makes sense
<mdz> Kamion: last bit is to change sudoers to use NOPASSWD
<Kamion> not something that had occurred to me in advance, but debconf-set-selections does a similar trick for preseed
<mdz> is there a way to specify a sed address range which means "the line _after_ the one matching this regex?"
<Kamion> mdz: perhaps a never-asked debconf question in shadow would be better?
<Kamion> "Require password for sudo?"
<mdz> mvo_: update-notifier is segfaulting for me on the live CD
<mdz> Kamion: if you're ok with that, sure
<mdz> Kamion: casper also currently forces the user password to empty, but I'd like to find a better way for that too
<Kamion> yeah, not sure how to work that
<mdz> group setup seems to work fine
<trulux> ajmitch: http://apt.debian-hardened.org/hoary/
<trulux> ajmitch: there you can find the new packages, just finished the uploading and repository updating
<trulux> now, bye!
<ajmitch> great, thanks :)
<trulux> ajmitch: err, tell pitti about them, so he could make the upload
<trulux> bonna noite!
<trulux> :)
<mdz> gah, so hot here
<mdz> 30C today
<haggai> seb128: not any more - that was the older KDE standard but current KDE can also use /usr/share/applications
<ajmitch> trulux: we *have* to work on a better method of installing policy - answering 1001 questions is not a good way :)
* ogra hands over his -2C to mdz
<mvo_> mdz: segfaulting :( ?
<Simira> mdz: send some over here!
<seb128> haggai: ok, so I can drop the /usr/share/applnk one (that makes a double entry in the GNOME menu) ?
<Kamion> mdz: has California moved to the southern hemisphere recently or something?
* Simira gives mdz a -6C
<mdz> mvo_: yes, i can send a stack trace if you need one
<mvo_> mdz: reproduceable?
<mdz> Kamion: it stopped raining
<haggai> seb128: yup, please do
<mvo_> mdz: please do
<Riddell> haggai: what was the change that you made to KDE's menus?
<mdz> and now we have record heat instead
<mdz> which, mind you, is preferable
<mdz> mvo_: 100%
<seb128> haggai: nice, thanks
<haggai> Riddell: using the Gnome template (looking for filename)
<Kamion> mdz: I think you lied and you don't live in California at all; you really live somewhere in the sixth circle of Hell
<Kamion> mdz: it's good that they let you out for holidays though
<mvo_> mdz: is it on a downloadable image? if so I would like to grab it and have a look
<mdz> http://weather.yahoo.com/forecast/USCA1107_c.html?force_units=1
<haggai> Riddell: /etc/menu-methods/stuff
<mdz> mvo_: the downloadable image requires a few fixes in order to work
<mdz> need to wait for casper 0.21 to build, and then do another live CD build
<Kamion> mdz: gar, apt still thinks the cache is not authenticated
<mdz> average high for january is usually 19C
<Kamion> mdz: /var/lib/apt/lists/_cdrom_dists_hoary_Release.gpg exists
<Riddell> haggai: what is the advantage in your change?
<mvo_> mdz: then just send me the stacktrace please. and ping me when a live-cd is ready
<jdub> haggai: lots of OnlyDisplayIn=KDE stuff to be done
<jdub> haggai: want me to file bugs for you?
<Kamion> mdz: however apt-cdrom doesn't appear to have added a _Release.gpg file
<jdub> haggai: i might just mail the kubuntu lists when i set them up
<jdub> haggai: you definitely want kubuntu and kubuntu-devel?
<mdz> hmm, still no oo.o2 build? :-(
<Kamion> mdz: can I make it do so?
<Riddell> jdub: kubuntu-user and kubuntu-devel I'd say
<mdz> Kamion: hmm, apt-cdrom is weird
<mdz> Kamion: I don't think anyone has considered the possibilty of signed CDs as yet
<Kamion> can somebody consider it real fast? :)
<mdz> copying _Release.gpg into place will override it and have it consider the source authenticated
<mdz> but it really ought to verify the signature before doing that
<Kamion> it doesn't seem to copy the Release file even
<mdz> weird, I say
<robtaylor__> fabbione: ping?
<Kamion> mdz: so I could work around it in archive-copier? it's blocking Array CD 3 so a quick fix would be ideal
<mdz> elmo: around?
<mdz> haggai: what's the next blocker for oo.o2?
<haggai> Riddell: 1. the files conflict 2. attempt to follow ubuntu menu structure
<haggai> mdz: moz problems, the same as are blocking OOo1
<Kamion> mdz: copying Release and Release.gpg seems to work; how evil is that?
<Kamion> assuming I do a gpgv first
<haggai> mdz: ubunutu's libs now have extra symbols in them which breaks OOo's internal moz libs
<mdz> haggai: who's working on it?
<haggai> mdz: me
<mdz> haggai: oh, good :-)
<mdz> is it a mozilla problem or an oo.o problem?
<mdz> Kamion: it's less evil if you do a gpgv first
<haggai> OOo really, it's their b0rken internal patched libs that cause the problem
<mdz> Kamion: at that point, it's only as evil as messing with /var/lib/dpkg
<haggai> but because of their patches it makes it hard to fix quickly
<haggai> jdub: re OnlyDisplayIn=KDE, why is that needed?
<jdub> haggai: things like kcontrol, etc.
<mvo_> mdz: I can have a look at the stacktrace today, otherwise I go to sleep :)
<jdub> haggai: logged into gnome with kde installed recently? :)
<haggai> jdub: surely if they are installed on the box, they should have menu entries?
<haggai> jdub: yeah :)
<jdub> haggai: not everything should
<jdub> kcontrol (particularly where it sits in the menus, but even disregarding that) really shouldn't
<Kamion> mdz: OK, I think I'll do that, mark it TODO, and file a bug
<haggai> jdub: ok, take e.g. you install a kde proggy on your mainly gnome system and don't use KDE.  The prog has a kcontrol module - now what?
<mdz> mvo_: go to sleep; I will mail you something
<jdub> haggai: in general, i'd hope that the app would point to it too
<mvo_> mdz: thanks
<jdub> haggai: see nautilus file manager properties, etc.
<jdub> haggai: my only worry with splitting off kubuntu-* is that we'll miss out on lots of integration discussion
<jdub> haggai: i'll almost certainly subscribe to kubuntu-devel, but won't be tracking it closely
<robtaylor_> hey. i've just been playing with getting jackd to work on ubuntu :)
<haggai> jdub: yeah, I understand that, but the ubuntu lists are already too much traffic
<haggai> jdub: they are not a friendly place to nuture new devs who aren't into Gnome ;)
<robtaylor_> 1 problem from the off, apparently the realtime-lsm module needs security configured as a module. any chance of this happening?
<jdub> haggai: that's definitely true
<jdub> haggai: but i'm already convinced
<jdub> haggai: i'm wondering how to help with the integration problems it introduces
<haggai> jdub: we should maybe crosspost stuff that is applicible to both or something, but I think much traffic won't be really interesting such as whether to include the menu shadow patch or not etc
<haggai> jdub: maybe we need a place to talk about derived distributions in general?  oh no another list..
<jdub> fear :)
<robtaylor_> haggai: and debian-custom wont suffice?
<jdub> this is about ubuntu derivatives
<lifeless> daniels: ping
<haggai> robtaylor_: I guess debian-custom would only be suitable for a subset of the discussion, since much will talk about deriving from ubuntu
<robtaylor_> haggai: yep, i'm seeing the issue now
<robtaylor_> whats kde doing on the sound server front, out of interest?
<haggai> dieing slowly :(
<robtaylor_> :(
<haggai> the arts maintainer has just thrown in the towel
<robtaylor_> cos this is something it'd be nice to solve for both desktops..
<robtaylor_> well,i can see why..
<haggai> yup, maybe polypaudio is the way to go.  I'm not following the KDE discussion
<jdub> haggai: polypaudio... :)
<jdub> is lennart on the kde lists?
<haggai> jdub: dude I was at the BOF :)
<jdub> pushing for it?
<haggai> no idea sorry
<robtaylor_> jdub: what do you reckon to the curredn discussion on desktop-devel-list? i think i'm just pretty much reiterating what we decide at the bof, no?
<jdub> nothing's going to happen in 2.10 timeframe
<robtaylor_> obviously :/
<jdub> for 2.12, gnome will switch to gstreamer at the library level and deprecate esound
<robtaylor_> i'm slighty confuesed about this, i thought gstreamer only defined audio chains *within* a process?
<sivang> mdz: so udebs are not at all suited at creating live cd targets? maybe casper could be used to create installer iso then :)
<robtaylor_> surely you need to specify that apps should use gstreamer-polypaudio as the final sink/
<robtaylor_> or is this something runtime configurable, and i've missed something completely? ;)
<mdz> sivang: udebs are used only for the bootstrap process
<mdz> sivang: you don't need to change the bootstrap process at all
<ajmitch> jdub: how many more gnome 2.x releases are planned?
<Kamion> sivang: casper is very specific to the live CD task ...
* Kamion hacks archive-copier egregiously
<sivang> Kamion,mdz : ok :) I will try to keep on track :)
<sivang> mdz: what is the casper applet? what python modules are needed to run it?
<jdub> ajmitch: NaN
<Kamion> jdub: *laugh*
<thully> Hi - which snapshot of Hoary works best for installation?  I tried the last few days and they didn't work well - also, I tried installing Warty and then dist-upgrading from a snapshot CD (as I already had one burned and didn't want to download again) and I got a bunch of dependency problems.
<jdub> ajmitch: http://www.gnome.org/~jdub/blog/projects/gnome/1095703226
<sivang> mdz: could you tell me how do I extract the cloop image so I can loop mount it?
<ajmitch> heh
<mvo_> mdz: thanks for the backtrace
* mvo_ goes to bed now
<mdz> sivang: you use the tools in cloop-utils
<mdz> sivang: the casper applet is hypothetical
<mdz> I haven't written it yet
<amu> sivang: extract_compressed_fs  filename.cloop >bla.chroot 
<ajmitch> jdub: I guess the gnome people are wanting to commit to ABI/API stability for awhile then?
<sivang> amu,mdz : thanks alot :)
<jdub> ajmitch: see live.gnome.org/ThreePointZero
<mdz> sivang: my thanks will be good documentation for the customisation process ;-)
<Kamion> thully: 20050119.2 appears to work except that it has problems with apt authentication so you have to say 'y' to aptitude
<jdub> ajmitch: the major interest in 3.0 is deprecating the crap
<jdub> ajmitch: well, sorry, removing the deprecated crap
<Kamion> thully: this turns out to be because apt-cdrom doesn't support authentication, so I'm testing a workaround right now
<ajmitch> jdub: that's what I understood, that there's a fair bit of accumulated crap since 2.0 :)
<ajmitch> that has been deprecated
<thully> oh - cool, the last few releases have had some significant breakage - does this image fix the issue where the created user isn't in the sudoers group?
<ajmitch> sadly I've only done a little coding with gnome, mostly with python
<thully> not group - file I mean
<Kamion> thully: yes, I fixed that a day or two ago; nobody reported it :P
<jdub> not much has actually been deprecated yet
<jdub> but there are lots of things to be purged
<Kamion> I happened to notice it myself :)
<mdz> Kamion: lamont has done a d-i build for us; do i need to get elmo to BYHAND it?
<Kamion> mdz: yeah
<mdz> elmo: pretty please?
<thully> I'm still seeing the date problems that I've seen since the warty pre-release
<thully> timezone, I mean
<Kamion> thully: there was also a good deal of breakage in ubuntu-desktop installability which I only managed to sort out today
<sivang> mdz: Ok, on the TODO list, I don't forget promising this :)
<Kamion> thully: gah, how can that have persisted?!
<thully> well, I wonder how it slipped into the Warty release even!  evidently I'm the only Ubuntu user who uses dial-up a significant amount
<Kamion> I don't understand this at all, that code is now in an utterly different place
<thully> Well, it doesn't happen on Debian - maybe check their code
<Kamion> thully: we were already using their code
<thully> yes - but with changes
<Kamion> yes, I know, I made most of those changes
<Kamion> which is why I'm so baffled
<thully> I dunno - I'll jive 0119.2 a shot and see if it by any chance disappears
<thully> give
<Kamion> thully: you've tried an image that has the timezone question in the first stage, I take it?
<thully> yeser
<thully> yes
<Kamion> ok
<Kamion> thanks for your eternal patience :-)
<Kamion> I'd like to know what /etc/timezone, the /etc/localtime symlink, and 'date' look like when chrooted into /target before the first reboot
<thully> So, does anyone know why autohinter is disabled by default in recent Hoary snapshots?  I liked having it on by default (it's subpixel which causes issues on CRT, not autohinter)
<Kamion> hwclock.sh is not now run during the timezone question, which I'd thought might be what was causing your problem
<jdub> so i looked at the ubuntu backports repos yesterday
<thully> Kamion: I'll check that out
<jdub> they are *insane*
<Kamion> hwclockfirst.sh *should* take care of it
<jdub> there are going to be a bunch of very unhappy users trying to upgrade to hoary soon
<crimsun> jdub: because of the version madness?
<jdub> yeah
<ajmitch> jdub: brokenness?
<Kamion> what have they done?
<jdub> serious, serious brokenness
<mdz> jdub: those repositories sprung up like a week after warty released
<jdub> Kamion: you kinda have to look at the version numbers to truly understand
<mdz> jdub: *six months* ffs
<jdub> mdz: uh huh.
<mdz> people are so afraid to upgrade to hoary that they are willing to subject themselves to worse breakage because of backports
<ajmitch> oh how I need a decent monitor for my hoary box, to see gnome in all its glory
<elmo> uh.. another d-i daily?
<Kamion> the 403 on warty-backports/main/binary-i386/Packages.gz is pretty special
<Kamion> elmo: mdz was crying for it for live CD testing :-)
<mdz> elmo: the hotplug fix I did yesterday didn't make it, apparently
#ubuntu-devel 2006-01-23
<Kamion> yes, there's a known bug about vmware disks IIRC
<tepsipakki> which is a trivial fix
<tepsipakki> s/fix/to fix/
<tepsipakki> s/a // ;)
<wasabi_> Curious: /etc/sudoers has $admin in it by default.
<wasabi_> %admin I mean.
<Kamion>  o mysql-client-4.1 mysql-server-4.1                          {mysql-dfsg-4.1}
<Kamion> infinity: ok to demote to universe?
<wasabi_> admin is uid 1000, there is also a group admin with gid 1000.
<wasabi_> This was the first group I created during install.
<Kamion> wasabi_: admin's only a uid if the initial user you create is called 'admin'
<Kamion> which is a bit of a corner case :)
<wasabi_> Ahhhh.
<wasabi_> I was wondering if %bob would be in there in the case of that.
<Kamion> I didn't expect anyone to do that ...
<tseng> % denotes a group
<wasabi_> My first (and only) user is always admin.
<Kamion> hmm, that's pretty awkward to work around
<wasabi_> adm seems more appropiate.
<Kamion> I think I might just ignore it, it produces essentially the same result in your case anyway
<wasabi_> %adm in there.
<Kamion> no, adm is for viewing log files, it just has a crap name
* ogra imagines that former win admins might call the first user admin
<wasabi_> Ahh.
<wasabi_> Well hell.
<Kamion> we went through all the possibilities when we introduced the admin group, and none of the existing groups seemed suitable
<wasabi_> I'd be all right with establishing a default admin group in a system gid range.
<Kamion> there is one
<wasabi_> You introduced the group?
<wasabi_> oh I just create the admin user.
<wasabi_> What's the gid supposed to be?
<Kamion> it just gets created after user creation
<Kamion> adduser --system, no fixed gid
<wasabi_> Hmm. So mine is 1000 because my user was named admin
<Kamion> if an admin group already exists as a result of initial user creation, the system group won't get created
<wasabi_> Ahh.
<wasabi_> I see. That works out.
<Kamion> I think that's better, it fails more gracefully in your case
<wasabi_> Yeah.
<wasabi_> I am now clear!
<Kamion> in general we try to use adduser rather than fixed ids
<wasabi_> Yeah, I follow.
<wasabi_> I wish there was some way to prevent clashes in distributed user bases.
<wasabi_> MS figured it out.
<Kamion> theoretically most of the existing fixed ids can be phased out, but I haven't had the stomach for the necessary combo base-passwd / adduser hacking yet
<Keybuk> there's probably a good wine for that
<wasabi_> At some point in the future can we stop with this too: admin:x:1000:1000:Administrator,,,:/home/admin:/bin/bash
<wasabi_> ,,,
<Keybuk> I get asked silly questions from strangers in Tescos ... "which wine is good for chicken?"  "which wine is good for beef?"  "which wine is good for hacking on console-tools?"  etc.
<wasabi_> Haha.
<daniels> wasabi_: er, you do know what gecos is, right?
<wasabi_> Nope. ;)
<Kamion> wasabi_: try chfn
<wasabi_> Oh. Heh.
<Kamion> the fifth field of passwd is the gecos field and contains several comma-separated components
<Kamion> Treenaks: brief description of promotion/demotion and main inclusion reviews now in DeveloperResources
<wasabi_> Is it just me or is /var/run/nscd missing by default?
<wasabi_> Nope, not just me.
<schlomo> Hi sorry to bother you
<schlomo> it's possible to load fglrx in 2.6.12-9-386 breezy ? *ERROR* Unable to the open some already present DRM kernel module! when load fglrx with modprobe
<schlomo> I have to update kernel ? it's a known problem ?
<schlomo> it's not possible sorry
<schlomo> didn't find anything on bugzilla
<infinity> Kamion: Yessir.  Demote away.
<Kamion> infinity: done
<StevenK> Oh crap.
<StevenK> infinity: Look at jnethack on amd64!
<StevenK> infinity: It's been reported as a Debian bug, too.
<infinity> StevenK: Don't wanna! :)
<infinity> StevenK: (Will look at it in just a bit, after I've settled into my morning routine)
<daniels> mkfontdir segfaults
<StevenK> Who has access to keyring RT? I've sent an e-mail to it, and the reply quoted my e-mail saying "This has no content"
<StevenK> daniels: It seems that bdftopcf is throwing out crap mkfontdir can't understand, from my (limited) investigation.
<daniels> score
<swat_> hi guys, anyone about who knows about gstreamer/rhythmbox. i'm trying to figure out if i am experiencing a bug, or just something gone bad on my machine
<HiddenWolf> swat_: cvs snapshot that dapper uses isn't fully ported yet.
<swat_> HiddenWolf: i see - it could be a gstreamer problem though. basically if i tell it to play using my internal card on my laptop the standard intel one, all is fine. if i give it the usb creative card, it bombs out and goes mental
<swat_> if this is to be expected at this stage of development fair enough, i was just wondering if it was worth filing a bug report for
<HiddenWolf> swat_: please do.
<swat_> it wasn't a problem in hoary, so i assume it is some sort of issue - rather than not being supported
<HiddenWolf> swat_: new kernel, hotplug to udev transition, there has been messing with the default sink, and the gstreamer 0.8 -> 0.10 thing. It can be a lot of things.
<swat_> so i should submit a bug to the rhythmbox thing anyway
<swat_> and it'll get bounced around one assumes
<HiddenWolf> right
<dholbach> elmo: can you please remove evolution-caldav from Dapper?
<daniels> elmo: fyi, x11-common should go into main, and when it does, xorg-common and xserver-common should be melanied
<elmo> daniels: k
<HiddenWolf> debian takes legality dead-serious. :/
<HiddenWolf> Software. Daniel Carrera [23] wondered how he is
<HiddenWolf> supposed to fulfil the source code requirement of the GNU [24] GPL when
<HiddenWolf> he is handing out OpenOffice.org CDs during an exhibition. Andrew
<HiddenWolf> Suffield [25] explained that the easiest way is to prepare copies of
<HiddenWolf> the source and give them to anybody who asks for them.
<HiddenWolf> odm
<HiddenWolf> isn't that a bit, ehm, zealous?
<daniels> argh
<Kamion> people do get asked for source code when handing out CDs at exhibitions
<Kamion> at least occasionally in the context of whether they're meeting licence requirements
<Kamion> it's a lot easier to have your answer prepared than to be stumped
<HiddenWolf> Shouldn't it be enough to have your awnser "sourcecode is published at XYZ location" ?
<HiddenWolf> If it isn't, than isn't shipit in violation of the gpl?
<Kamion> shipit includes a written offer last I checked
<Kamion> (which I don't think anyone's ever taken up ...)
<azeem> it does
<Kamion> you have to either (a) accompany binaries with source (b) include written offer (c) if non-commercial, pass on the offer of source you received
<Kamion> when I've handed out Debian CDs at exhibitions at the past, we went for (b)
<Kamion> but that does require having a contact address of somebody willing to mail out CDs
<Kamion> just pointing them to a web archive isn't sufficient, IIRC, because you can assume that a fair proportion of people who are wanting to get CDs from you rather than do the download themselves won't have the bandwidth to download the source either
<Kamion> I'm not *entirely* sure the GPL says that straight out but it seems reasonable behaviour
<daniels> i thought there was some form of media restriction on the source offer
<daniels> being that you have to at least make it available through the same medium
<daniels> but I could be mistaken
<Kamion> "on a medium customarily used for software interchange"
* HiddenWolf thinks floppy disks
<Kamion> I think you could argue convincingly that archive.ubuntu.com plus the Internet is such a medium
<Kamion> (e.g.)
<Kamion> but I'm not sure everyone actually agrees with me there, so shrug
<dholbach> night guys.
<daniels> dude, we don't use the interweb for anything
<daniels> night dholbach
<Kamion> the last paragraph of GPLv2 section 3 does suggest that access to copy from a designated place is not quite the same as distributing on a medium, though
<Kamion> so, whatever; it's easy enough to comply with the strictest reading in case anyone asks, and it makes the odd person happy and saves you aggro
<ds> imo, it should be thought of as an honor to be able to have source CDs for people
<Kamion> we kick out source CD images as part of our daily CD image build process
<Kamion> (yes, we have been asked for them, too)
<HiddenWolf> daniels: nice changelog on xorg. :)
<HiddenWolf> daniels: xlibs-dev description: pac -> package
<daniels> (oops)
<infinity> daniels: Any urge to look at the mkfontdir 64-bit hatred?
<tseng> infinity: awakeish?
* Burgundavia wonders whether to respond to sabdfl with "sorry, ubuntu-devel is not for bug reports. Please file them in LP"
<infinity> tseng: Maybeish.
<tseng> infinity: hardware detection on my desktop flight 3 install is pretty bunk, i seem to remember you are the guy
<daniels> infinity: i'd be lying if I said yes
<womble> Burgundavia: Go for it.  Please.  <grin>
<daniels> infinity: i'll check it out if I get time after looking at a few xorg issues
<infinity> tseng: Keybuk is the guy, actually.
<tseng> ah, well its past his bedtime
<infinity> tseng: Define "bunk".
<tseng> its not loading modules
<tseng> in single user, my nic module is not loaded for example
<tseng> in a normal boot X goes totally bonkers and displays garbage on my dvi, seemingly hung
<tseng> so not much clue from that angle yet
<jdub> Burgundavia: i don't think that would be inappropriate
<tseng> a startx in single user says "you have no devices, jackass!"
<Burgundavia> jdub, yes, that is why I didn't do that
<infinity> tseng: Hrm, S10udev is meant to catch all the devices that didn't get loaded in the initramfs.
<jdub> Burgundavia: or backwards -> i think it would be appropriate
<HiddenWolf> jdub: double denial is always tricky. :)
<infinity> tseng: You'll definitely want to either file a bug or talk to Keybuk directly though.
<tseng> infinity: indeed.
<Burgundavia> HiddenWolf, jdub, gahhh! I give up
<HiddenWolf> tseng: make startx sign the code of conduct. :)
<LaserJock> what is the copyright/license for debian/* ?
<daniels> LaserJock: generally debian/rules is licenced under the gpl (look in the file itself), and the rest isn't copyrightable
<LaserJock> daniels: what does copyrightable mean exactly?
<HiddenWolf> LaserJock: if you can claim copyright or not
<LaserJock> so does that mean public domain?
<Burgundavia> LaserJock, anything that is not copyrightable is not copyrightable. Effectively the same as PD
<LaserJock> interesting
<Burgundavia> PD is for things which have had their copyright lapse, but they are still technically under copyright
<daniels> if I write 'the grass is green', that doesn't deserve copyright protection
<HiddenWolf> daniels: not? ;)
<daniels> HiddenWolf: ?
<HiddenWolf> daniels: joke.
<Burgundavia> daniels, that is debatable, depending on the country
<Burgundavia> basically, you need to demonstrate that you actually did something
<HiddenWolf> Burgundavia: of course you can claim copyright, to get it is a different story.
<LaserJock> but packaging is a lot of work so I'm not sure why it would be non-copyrightable
<Burgundavia> LaserJock, the descriptions are copyright, probably the same license as the program, as a derived work on the main body
<Burgundavia> scratch that
<Burgundavia> probably gpl, as part of the packaging, as daniels said
<HiddenWolf> LaserJock: it's a lot of work, but it is not unique, your achievement specifically, or otherwise protectable
<HiddenWolf> LaserJock: You're doing work following a guideline, the guideline might be copyrightable, the work itself not, afaik.
<Burgundavia> LaserJock, however, if you quoting a small piece of the work, US copyright law has a thing called fairuse. This is what reviewers use
<LaserJock> hmm, it seems pretty unique to me but the docteam has gotten me all paranoid about licenses ;-)
<Burgundavia> LaserJock, you should be paranoid about copyright. It can and will bite you in the ass
<LaserJock> It just seems odd to me that we don't have to say anything about the copyright of the actual packaging when we are packaging
<psusi> what is the right way to go about getting something included in the initrd on the install cd?  how exactly is that built up from the udebs?
<infinity> psusi: For testing, just rebuild debian-installer with your udeb in build/localudebs
<infinity> psusi: For the "real thing", what gets included is defined by archive priorities.
<psusi> infinity, so building debian-installer from source installs the udebs in build/localudebs to a chroot somewhere?  then snatches the kernel and initrd out of that chroot?
* psusi thinks it is time to udebify dmraid
<psusi> what I'm getting at is if the udeb's postinst adds scripts to /usr/share/initramfs-tools and calls update-initramfs, that will get the right stuff into the initrd for the install cd yes?
<infinity> Erm, no.  I'm not positive how that all works, now that d-i has moved to initramfs.
* infinity caves in and uploads a "neon24" source package for now, until stuff like openoffice and bazaar have been adapted to the new API.
<Burgundavia> any idea why impilinux.org.za redirects to ubuntulinux.org?
<psusi> for that matter, why don't I see any udebs in the archive?
<HiddenWolf> Burgundavia: isn't impilinux the distribution that sabdfl bought, that'll put a paid ubuntu deriviate translated to za languages to market?
<HiddenWolf> I'm sure I read something about it, once.
<Burgundavia> HiddenWolf, yes, but impi should still have it own page
<Burgundavia> http://mybroadband.co.za/nephp/?m=show&id=828
<infinity> psusi: Err.. I do.. (http://archive.ubuntu.com/ubuntu/pool/main/b/binutils/ is an example)
<HiddenWolf> Burgundavia: perhaps they'll put up a new site when they are ready?
<infinity> psusi: If you mean "why don't I see them in Packages.gz", the answer to that should be reasonably obvious.  udebs shouldn't be installed on running systems.
<psusi> ohh... I see
<Burgundavia> HiddenWolf, no idea, but http://www.impilinux.org/ gives me a blank page
<HiddenWolf> Burgundavia: well, you'd expect them to use launchpad and such, but there is nothing there either, afaik
<HiddenWolf> Burgundavia: guess it's a ghost untill it's promoted.
<Burgundavia> HiddenWolf, I met the impi guys at UBZ
* psusi wonders WTF Build-conflicts: means... can't be build at the same time as that package???
<daniels> surprisingly, yeah
<psusi> what kind of sense does that make?
<psusi> don't you build only one package at a time?
<elmo> can't be INSTALLED at the same time as that package is being built
<HiddenWolf> Burgundavia: *shrug* Can't imagine sabdfl sinking a lot of money into something without a good plan, but I'd have no clue as to the plan.
<psusi> ohhh... wow... weird
<Burgundavia> HiddenWolf, personally I think Impi might just fail, but hmm...
<Burgundavia> 3 versions, 3 different base packages does not confidence build
<Burgundavia> 2 different DEs
<infinity> elmo: Can you NEW neon24, please?  (Yes, this is IncreasingDuplication, go me, it should be hammered out in the next few weeks/month)
<HiddenWolf> Burgundavia: I'd expected to see those guys active in the ubuntu world, links everywhere and such, but that hasn't happened yet. Who knows.
<Burgundavia> HiddenWolf, one of the impi guys was in #ubuntu-motu toda
<elmo> infinity: new for what?  main or universE?
<infinity> elmo: main, sorry.
<infinity> psusi: "Having this package in the build chroot completely hoses MY build" is a pretty common case, actually, but one that isn't tripped on enough (due to build chroots usually starting "clean") for people to add Build-Conflicts very often.
<psusi> wackey
* psusi wonders if he can't just mv dmraid*.deb dmraid*.udeb
<infinity> No.
<infinity> psusi: udebs follow a different policy.
<psusi> I mean for testing ;)
<HiddenWolf> Burgundavia: *shrug* One guy, no website, big plans. Time will tell seems to be the correct saying for the matter.
<Burgundavia> HiddenWolf, I think it is two
<psusi> infinity, btw... you DID say you had no idea why that dmraid bug was assigned to you, and I should reassign it to fabio right?  or did I imagine that?
<infinity> psusi: Yes.
<psusi> good
<Burgundavia> jdub, are there trademark issues with nUbuntu?
<kent> regarding trademarks this seems to be a violation in some way. www.ubuntu.se  Its in english so you can read it.  Its a commersial company I think.  (given that ubuntu is trademarked and it applies to swedish law - which i think it does..)
<Burgundavia> kent, remember that ubuntu also means something and that appears to have nothing to do with comoputers
<Burgundavia> kent, see also ubuntu.org
<HiddenWolf> kent: shees, what a philosophical babble. :)
<Burgundavia> HiddenWolf, awful. All this loving stuff
<kent> Burgundavia, ah :)
<HiddenWolf> Burgundavia: ahaha. :)
<kent> ahahah^2
<Burgundavia> kent, however, nUbuntu is a derived distro
<HiddenWolf> Burgundavia: the idea is good, but it's a tad much. :)
<HiddenWolf> Burgundavia: read ubuntu.org
<HiddenWolf> Canonical Go Ahead
<HiddenWolf> Today I received an email from Canonical about using the Ubuntu name and logo. We have got permission from them to use the name "Ubuntu" and Ubuntu logo. So people having doubts about us using the Ubuntu name and logo, you can stop worrying. :)
<Burgundavia> HiddenWolf, yes, but what are you using it for?
<HiddenWolf> Burgundavia: I'm not using it. I just found out it existed 10min ago. :)
<Burgundavia> HiddenWolf, where is that quote from?
<HiddenWolf> Burgundavia: nubuntu.org
<Burgundavia> ah
<Burgundavia> jdub, nevermind then
<HiddenWolf> Burgundavia: google does wonders. ;)
<Burgundavia> HiddenWolf, I haven't checked their page is several days
<Burgundavia> they did hit the front of digg
<HiddenWolf> hm
<dilinger> oh man
<dilinger> so what on earth is udevplug actually doing in dapper?
<dilinger> mkdir("/dev/.udev/queue", 0755)         = -1 EEXIST (File exists)
<dilinger> nanosleep({0, 10000000}, NULL)          = 0
<HiddenWolf> I'd rather see that energy move into ubuntu proper, but I guess it's good to have a healthy set of derivs to work with.
<dilinger> i see *tons* of those in strace output, until finally:
<infinity> dilinger: What's it do, or what's it supposed to do?
<Burgundavia> HiddenWolf, sabdfl is  right about derivs
<dilinger> nanosleep({0, 10000000}, 0)             = ? ERESTART_RESTARTBLOCK (To be restarted)--- SIGALRM (Alarm clock) @ 0 (0) ---
<dilinger> exit_group(1)                           = ?
<dilinger> infinity: yes
<infinity> dilinger: It's supposed to do bus scans and generate hotplug events for coldplugged hardware.
<infinity> dilinger: I'm not sure if that's what it IS doing for you. :)
<dilinger> 30% of the way through the 2.5M strace file, it starts w/ those
<dilinger> that's the entire rest of it
<infinity> Well, I guess you've just volunteered to talk to Kebuk about it. :)
<infinity> Keybuk, too.
<dilinger> where is he?
<HiddenWolf> in bed.
<dilinger> d'oh
<HiddenWolf> I should hope
<dilinger> any idea what 's up w/ udev permissions, too?
<dilinger> crw-rw---- 1 root root 1, 3 2006-01-17 22:57 /dev/null
<infinity> dilinger: He should be around in a few hours...
<dilinger> ok
<HiddenWolf> dilinger: it's crack, up to you to decide if it's a good or a bad trip. :)
<infinity> My /dev/null is fine.
<dilinger> what's really strange is that once i added the strace to udevplug, it booted faster
<dilinger> before, it was hanging for like 10 minutes
<psusi> infinity, I'm getting the feeling from reading the README that localudebs/* are just tagged on to be installed during bootstrap, but won't be used for building the initramfs
<infinity> psusi: Stuff in localudebs should end up in your mini.iso and be useable.
<infinity> psusi: (The mini.iso is basically just isolinux, a kernel, and the d-i initrd, and not much else)
<psusi> infinity, yea... it will end up in the iso and it will be installed by anna during the setup bootstrap, but dmraid needs to be installed when the initrd is built, and I don't think it will be if placed in there
<infinity> psusi: Oh, I see what you're saying.  I also think you don't quite understand how d-i hardware detection works.
<psusi> <G>
<infinity> psusi: At any rate, why would you care about dmraid running RIGHT AWAY?  It just needs to run before partman.
<infinity> psusi: Up to partman, we don't even care if we have a local disk at all.
<psusi> the problem is most udebs are just installed by anna during the bootstrap... but dmraid has to be there when the initrd is built for it to be included... just having it installed after bootup won't work
<psusi> because it doesn't "run" when installed anymore... I changed it to only set the initrd hooks, and it is expected to run in the initrd
<psusi> of course... I suppose I could have the udeb built such that it runs dmraid when it is installed...
<infinity> Fine for an installed system, probably a broken assumption for d-i.  But you'd want to talk to Kamion about that further.
<psusi> rather than setting the mkinitramfs hooks
<psusi> hrm... yea.. that sounds like the right thing to do... have the normal deb just set the initramfs hooks, and have the udeb just run when installed
<psusi> because anna can load some udebs that might be required to access the hardware after the initrd stuff has already run
<infinity> psusi: Right.
* psusi just felt his brain swell again
<psusi> then again, that could be the beer
<infinity> psusi: It will need to be run after (or as a part of) hw-detect.
<psusi> ok... so I'm thinking it will need to be added to pkg-lists/access
<psusi> and it's postinst should just run dmraid -ay, and the package itself should only include the executable... screw the docs and the mkinitramfs hook scripts
<infinity> Right.
<psusi> ok... cool... shouldn't be too hard to do..
<infinity> And, if you can futz with the build system enough to build the binary twice, the dmraid binary in the udeb should be compiled with -Os
<infinity> Actually, if it's meant to end up in the iniramfs on installed systems, it might not be a bad idea to just compile the whole thing -Os anyway, and only do one pass.
<infinity> Small initrds make people happy.
<psusi> it's usually a good idea to use -Os anyhow as half the time it generates code that runs faster as well, due to fitting in the cpu cache better
<psusi> ;)
<psusi> but... that is another thing I've been wondering about initrds... early on in the live of that bug, Fabio mentioned klibc...
<psusi> as far as I can see, klibc is NOT being used in ubunutu initrds
<infinity> It is, but so is glibc.
<infinity> In other words, it's bloated.
<psusi> heh, yea, having both is stupid ;)
<infinity> I'm rewriting bits of initramfs-tools to now select one or the other, based on your installed package set.
<psusi> so I don't see any point in klibc then
<psusi> especially since it seems to be a general practice to statically link to it
<psusi> I say  just put libc.so in there and everyone use it
<infinity> (ie: we check to see if anything in your hooks requires glibc, if so, copy in the glibc-linked klibc-utils, and don't use klibc at all... If you don't need glibc, we use klibc exclusively, and get a smaller initrd)
<infinity> That's the plan, anyway.
<psusi> when it uses klibc, is it -shared?
<psusi> and how much smaller is klibc.so anyhow?
<infinity> The idea that klibc and EVERYTHING YOU MAY POSSIBLY WANT IN AN INITRD!! will be able to get along is a pipe dream we've given up on.
<infinity> It's shared, and it's tiny.
<psusi> like how much smaller than normal libc?
<psusi> 5k?  25k? 1 MB? ;)
<infinity> -rwxr-xr-x 1 root root 17020 2006-01-17 07:18 /lib/klibc-t2jM36h7OcxUNTDzncfER2p7kd4.so
<infinity> -rwxr-xr-x 1 root root 1138716 2006-01-14 01:22 /lib/libc-2.3.6.so
<psusi> WHOA!?!@#
<psusi> how the hell they do that?
<infinity> It's kinda featureless. :)
<infinity> (or glibc is kinda feature-bloated, pick one)
<psusi> haha, so it's not really usable then? :)
<psusi> that's what I'm saying... is glibc just that bloated, or is klibc so stripped to the bone as to be hardly usable?
<daniels> both
<psusi> heh
<infinity> It works well enough for the purpose of "tiny initrd, if you need it"  Which was the point.
<psusi> true... if all you need in there is busybox and a few kernel modules
<psusi> so should I then have a klibc and non klibc deb and udeb?
<infinity> I thought dmraid and klibc didn't get along right now anyway..?
<psusi> don't get alone?  the only thing about mixing them that I know of is it is rather stupid to add a smaller libc unless you can remove the larger
<infinity> At any rate, for the forseeable future, we'll probabl have glibc in the initramfs, so I wouldn't bother.
<psusi> ok
<infinity> If you can test that it does build and work with klibc, that's cool too, I don't mind. :)
<psusi> the upstream package has a --with-klibc configure option
<psusi> also dietlibc I think
<infinity> Having it doesn't mean it works.
<psusi> it has some other options to you can use to strip out some less needed features for the udeb
<psusi> btw.. is there a reason for using isolinux instead of grub on the cd?
<infinity> Yes, it works better.
<psusi> how so?
<psusi> doesn't grub umm... totally kick ass?
<infinity> Not for CD booting, apparently.
<infinity> syslinux (and by extension, isolinux) is the king of booting removable media on braindead PC hardware.
<lifeless> psusi: AFAIK grub does not have a iso support module.
<psusi> what difference does the medium make?
<infinity> psusi: How the BIOS chooses to try to boot it makes a big difference.
<infinity> psusi: And isolinux deals with a lot more broken BIOSes than grub does.
<HiddenWolf> infinity: and syslinux looks prettier. :)
<lifeless> psusi: you need a standalone driver for the fs and the ability to understand what the BIOS is expecting of you
<psusi> lifeless, so it can't boot el-torito native mode, put it and the kernel and initrd into a hd image and build it to use hd emulation boot
<lifeless> syslinux is king.
<infinity> psusi: Back in "the day", grub was tried on the CD images, failed miserably in certain cases, and isolinux was used instead.
<psusi> those broken bioses will get you every time... when I was working on ReactOS I ran into a problem with the boot loader because it was written to use the bios disk number stored in the boot sector instead of the number the bios passes in CL
<psusi> and in my case, the boot sector had 0 since mtools figures it's formatting a floppy
<psusi> only the drive was 80
<psusi> turned out the reason the number exists in the first place and was being used from the boot sector is because a lot of bioses are broken and don't pass the boot disk number in CL
<psusi> that was about as annoying as when I was working on the floppy driver and found out that no drives ever made actually support the detect disk command the standard called out for, which is why you have to tell the bios what kind of floppy you have, and the kenrel has to get that info from the bios and run with it... even if it is wrong
<mjg59> psusi: It's not "a lot", but yeah. grub only just started dealing with that
<psusi> it pissed me off that because some idiot wrote a broken bios somewhere, the boot loader couldn't auto detect the boot medium on my machine, and had to rely on the hard coded value in the boot sector
<psusi> I don't know how windows manages to boot from drives other than the primary master... or can it?
<psusi> because fat boot sectors ALLWAYS say bios disk 80... unless it's on a floppy, then it's 0
<infinity> ntldr can chain to other partitions, but ntldr itself needs to be either on BIOS 0x80 (and on an active partition), or it needs to be chained from elsewhere (like grub)
<psusi> and for grub to chain it, grub hooks int 13 to trick ntldr into thinking it's on disk 80 doesn't it?
<infinity> Yes.
<infinity> And that's all ntldr needs to be able to read far enough to read its config file (boot.ini), and from there it can start loading device drivers and boot "properly".
<psusi> wait... does it hook int 13 and fake disk 80, or does it write 81 into the boot sector?
<psusi> if you change the disk number in the boot sector to the correct value, it would probably work too
<psusi> it's just that dos/windows allways formats hard disks with an 80 in there
<infinity> If grub rewrites boot sectors when chaining, that's a bug, IMO.
<infinity> (And I'm pretty sure it doesn't)
<psusi> another stupid thing it does apparently is store the absolute lba sector number of the partition in the boot sector, and so the boot loader uses that rather than adding local offsets to the starting sector of the partition according to the MBR
<psusi> so if you move the partition, you have to change the hidden sectors field in the boot sector for it to still boot
<psusi> I seem to remember seeing some command in grub that has it rewrite the boot sector to switch active partitions
<infinity> I'd have to look at my girlfriend's computer, where such an icky setup is in place.
* psusi studies the hackery that is bootchart-udeb
<wasabi> Trying to find a suitable vmnet module for your running kernel.
<wasabi> The module bld-2.6.12-9-i686up-Ubuntu5.10 loads perfectly in the running kernel.
<wasabi> UNF!
<infinity> WMware distributes pre-built modules for Ubuntu now?
<infinity> Neat.
<daniels> yay proprietary software
<HiddenWolf> infinity: yeah, all we need is a .deb for player.
<infinity> elmo: I suppose neon24 will need binary NEW as well, since those binaries were removed yesterday. :/
<wasabi> Hah. VNC breaks because it can't find xfonts-base.
<wasabi> Because it got moved out of /usr/X11R6
<wasabi> How in the heck to change this.
<wasabi> Ahh I see. It pulls it's config from /etc/X11/xorg.conf if it exists.
<daniels> hi janew
<psusi> wow... I think I've udebified this package
<psusi> hrm...probably should validate the depends...
<psusi> hrm... when I try to build debian-installer it says it can't find libdebian-installer4
<psusi> well, it's late... I'll pick this up tomorrow...
<JaneW> hi daniels
<Den> Anyone know if today's dapper live iso built properly, no errors, etc?
<HiddenWolf> Den: check the timestamp, if it hasn't built, it'll not be of today
<HiddenWolf> Den: if it's workable / usable, no clue.
<Burgundavia> Den, there is an error log somewhere, maybe under people.ubuntu.com/~cjwatson
<Den> HiddenWolf: Thanks - the time stamp is new, but yesterday Mithrandir  told me it didn't build properly, even though there was an updated time stamp.  Thats why I asked. Thanks!
<dieman> aruuugh. default dupload host is ubuntu ;)
<dieman> thats what i get for using my ubuntu box to sign a debian upload
<dieman> (i did build and test on my unstable box, yes)
<HiddenWolf> ahaha
<Burgundavia> dieman, oops, but what did you expect?
<HiddenWolf> dieman: don't let d-devel hear. ;)
<dieman> heh
<dieman> lots of people know i use ubuntu a bit more now
<dieman> its sort of how i get paid
<HiddenWolf> heh, yeah, but people can be touchy. :)
<dieman> omfg you signed on ubuntu?
<dieman> if people are that sensitive they need to take a quick reality check :)
<dieman> its not like im stupid enough to build it in the wrong place :)
* HiddenWolf chuckles
<Den> Burgundavia: Thanks - Hey, there's a lot of stuff there - any clue as to where the error log might be?
<dieman> christ, katie already emailed me
<dieman> just caught the run
<Burgundavia> Den, start digging, no idea
<dieman> (into the queue, that is)
* HiddenWolf throws Den a shovel
<dieman> the big issue is that my private key is on an efs on a usb disk
<Burgundavia> dieman, I have heard of a few cases either way
<dieman> Burgundavia: heh.
<Den> Anyone - is there an automatic way to search down the tree of a web site for, say , any text that says "error" or "log"?
<infinity> dieman: I've removed the default_host completely from dupload.conf on my machine, so I'm forced to use either "--to anonymous-ftp-master" or "--to ubuntu"
<Den> Like, some firefox plugin, perhaps?  Or, even easier than that?
<dieman> infinity: yeah, that seems best.
<dieman> ive not even explored motu stuff yet, haven't had to modify any of the packages yet.
<dieman> of the universe packages, that is
<dieman> and my boxes are still on hoary, anyhow.
<infinity> Slacker.
<dieman> heh
<dieman> no, just dont want 3-4 distributions around
<HiddenWolf> You only need one. Dapper. :)
<dieman> its confusing enough to have woody and hoary machines
<dieman> to the users
<dieman> (woody is going away very fast)
<infinity> Yeah, I think I have woody, sarge, sid, breezy, and dapper in the wild right now.
<infinity> No warty or hoary, though.
<dieman> hoary is pretty good
<dieman> ive been ok with it
<dieman> worst problem is having to backport some x stuff
<dieman> for i945 graphiucs
<infinity> I liked it well enough, but hoary->breezy was smooth enough that I just upgraded stuff and was done with it.
<dieman> and kernel drivers for intel hd audio on amd64/xeon
<infinity> The woody machine still in the wild is being reinstalled from scratch, since it was far too customised to be sanely upgraded to sarge or breezy.
<dieman> ive got 236 i686 hoary machines, and 33 amd/em64t hoary machines
<infinity> Instead, I have a parallel installation, and am hand-porting configs over, one-by-one.  Ugh.
<dieman> and 79 woody machines left.
<dieman> so im nearly up to 350 machines
<infinity> Student labs?
<dieman> labs, desktops, clusters.
<dieman> just got a 10x 1u dual opteron 270 cluster
<dieman> 4gb of memory for each box
<infinity> Sexy.
<dieman> need to get PBS setup on those still.
<dieman> we've been using condor for the most part, but they want to go to PBS since thats what the big iron at the supercomputer center runs
<dieman> and its easier to teach the grads one interface
<dieman> im excited about dapper though, thats for sure
<dieman> basically i freeze to what i put in the student labs, unless we have insane hw issues
<dieman> (ie: dell/intel screw us over with a completely new platform)
<HiddenWolf> dieman: what university do you work at?
<infinity> UMN
<HiddenWolf> ah
<dieman> university of minnesota, twin cities
<dieman> in the computer science department
<HiddenWolf> google thinks it's University of New Mexico. :)
<dieman> unm != umn :)
<HiddenWolf> heh
<HiddenWolf> right.
<HiddenWolf> allnighter. :)
<HiddenWolf> hey pitti 
<pitti> Good morning
<infinity> Yo, pittster.
<dieman> i'll definately be asking my boss to go to the next ubuntu conf/meeting though..
<dieman> i acquired some more help at work, so ive been working on offloading tasks when i can
<pitti> hey infinity 
<pitti> moin HiddenWolf 
<bytee_> does there exist a package list of the various Ubuntu releases, or must I install them individually to find out ?
<HiddenWolf> bytee_: packages.ubuntu.com
<bytee_> HiddenWolf: thanks
<pitti> eek, wvdial asks me for a telephone number
<pitti> I don't even have a modem in this box
<dieman> heh
<infinity> pitti: Yes, I know.  Debconf priority too high.  I've filed a bug in Debian, and if I don't get a reponse ASAP, I'll just fix Ubuntu.
<infinity> (I fear the Debian maintainer will response with "well, if you don't have modems, why are you install wvdial anyway?", in which case I'll just patch ours to use a lower prio..)
<infinity> s/response/respond/
<Mithrandir> isn't it part of the laptop task in Debian, or something?
<infinity> Mithrandir: If so, then I suppose Debian would have the same complaint as us about the priority.
<Mithrandir> yes. :-)
<ajmitch> changelogs not being updated on packages.u.c at the momentw?
<infinity> ajmitch: That's a longstanding issue (we don't control package.u.c)... Just s/packages/changelogs/ in the URL, and it'll magically work.
<StevenK> changelogs on packages.u.c haven't been updated for quite some time.
<ajmitch> ok
<infinity> (Same layout, different host, which we do control)
<ajmitch> who does control it?
<StevenK> Frank Litchenheld
<StevenK> djpig
<ajmitch> ok
<StevenK> Kick him for me. :-P
<ajmitch> ah, I was blind
<StevenK> Was? :-P
<mdke> i mailed him about the missing css too, no reply as of yet
<ajmitch> be nice :P
<mdke> perhaps he is not around
<StevenK> According to /whois, he's been sleeping for 22 hours.
<ajmitch> last status update on the frontpage is very recent
<mdke> oh yeah, he's fixed the css ;)
<Mez> jdub: ping
<sivang> Morning all!
<Treenaks> Google Talk is open :)
<sivang> Treenaks: in what sense?
<Treenaks> sivang: it can talk to non-google jabber servers now
<pitti> hi sivang 
* sivang hugs pitti 
<nnonix> update-notifier taking 100% cpu after latest update
<pitti> bah, where are dholbach and seb128 when I want to hit them? bonobo or sth. is totally broken
<sivang> hey pitti , 'sup?
<pitti> sivang: dunno, first nautilus complained about a bonobo error, and after restarting gnome nothing works any more
<sivang> oh man, I'm dist-upgrading. I'll let you know if I ecnounter this as well
<pitti> interesting to work without a WM :)
<StevenK> pitti: Still VM-less?
<sivang> oh, nice, wvdial debconf question on dist-upgrade
<sivang> but I don't have modem nor use dial up :)
<pitti> StevenK: no, seems to work fine now
<pitti> sivang: known bug, infinity deals with it
* sivang 's dist-upgrade almost done
<\sh> hmmm..can wvdial detect first if a modem is connected, and then ask for the rest like username, dialupnumber etc?
<Treenaks> \sh: I have a modem in my PC; I don't want wvdial to ask me for dialup-parameters as the modem is not connected  to a phone line
<Treenaks> (as I don't have those)
<\sh> Treenaks: well..so it's better to detect it first, and then eventually ask: do you want to configure your dialup. 
<Treenaks> \sh: maybe
<sivang> \sh: pitti said that infinity works on that :)
<\sh> sivang: ah nice...I didn't see it, don't have a backlog :)
<sivang> Treenaks: we need another question, "Do you want to configure dial up connection settings"
<sivang> \sh: actually , pitti told me :)
<sivang> nice, last upgrade made gnome-terminal a bit slower to fire up.
<pitti> and the tabs ridiculously big
<Treenaks> sometimes gnome-term starts eating 100% CPU time and I have to kill it
<Treenaks> but I haven't figured out what triggers it yet :(
<pitti> infinity: hm, for adding the sudo help, do you think I should rather change the conffile /etc/bash.bashrc, or change base-files to change /etc/profile if it's unmodified? (IMHO changing bash is enough, though)
<sivang> pitti: for a fix like that , https://launchpad.net/distros/ubuntu/+source/irssi-text/+bug/26106. Do we sync to upstream version , or include the patch ourselves?
<Ubugtu> Malone bug 26106: "segfault when /quit'ing irssi-text" Fix req. for: irssi-text (Ubuntu), Severity: Normal, Assigned to: Debian Bug Importer, Status: Unconfirmed
<pitti> sivang: if there is a new upstream version that fixes it, today is a very good day to upload it
<pitti> sivang: tomorrow is UVF
<pitti> Kamion: ^ smae question as to infinity
<sivang> bah, ok, I will take a look , if not we need to get that patch it - it's un-nice to have irssi quit with a core dump
<sivang> (except for those who like core dumps)
<Mithrandir> pitti: you're touching all the shells now, or are you already done?
<pitti> Mithrandir: sudo is done, and I'm currently tinkering with /etc/bash.bashrc
<pitti> Mithrandir: I can move the code to /etc/profile if we decide to modify base-config (and its postinst) instead
<pitti> Mithrandir: too bad that /etc/profile is not a conffile
<Mithrandir> pitti: I am going to nuke the PATH setting out of all the shells and base-files (as well as adding a dep on libpam-modules (>= 0.79-3ubuntu3), but if you're already touching the shells, I'd love if you could do it.
<pitti> Mithrandir: oh, that means you need to touch /etc/profile anyway?
<Mithrandir> pitti: yes, but if you're already going to do that..
<Mithrandir> :-)
<pitti> Mithrandir: I could add code to base-file's preinst to remove an unmodified /etc/profile, so that the postinst restores it again, but that seems non-transactional and hackish to me
<pitti> Mithrandir: yes, I can do the PATH change together with that, no big deal
<pitti> hi seb128 
<seb128> hey pitti
<pitti> Mithrandir: it just sucks that profile is no conffile, so I'm a bit lost how to change it properly
<Mithrandir> pitti: just copy over the new one if the md5sum matches the old file?
<pitti> Mithrandir: hm, I could determine the md5sum in the preinst and store it somewhere, right
<pitti> Mithrandir: or just store the flag whether it can be nuked
<maswan> pitti: btw, suggestion: in the usn:s mailed, how about putting in a link to the webpage (http://www.ubuntu.com/usn/usn-244-1) to make it easier to refer to it to people not getting the mails?
<pitti> maswan: and how do the people see the link in the email if they don't read it?
<Mithrandir> pitti: uh, just md5sum it in the postinst, rather?
<pitti> maswan: ah, sorry
<maswan> Of course, now that I know there are those urls, I could probably guess my way through to them, but I just found out and I've wanted to link to them previously and then poked around in the list archive
<pitti> maswan: I mixed up 'to' as 'for'
<pitti> maswan: yes, I can do that
<pitti> Mithrandir: md5sum against what?
<pitti> Mithrandir: it's not a conffile
<Mithrandir> pitti: if you look at the postinst, you see the "install_from_default" function, right?
<maswan> pitti: thanks. mostly collegues etc ("hey, you're the kernel guy, are we safe against this?")
<pitti> Mithrandir: sure
<Mithrandir> pitti: it could easily be extended to get a (list of) md5sum(s).
<pitti> Mithrandir: this could check a flag created in the preinst
<Mithrandir> why do you care about preinst?
<pitti> Mithrandir: oh, you mean statically put the md5sums into the postinst
<Mithrandir> yes.
<pitti> *shudder*
<pitti> oh well
<Mithrandir> where else would you have them?
<Mithrandir> you could have the static list in preinst, but the effect would be exactly the same.
<pitti> Mithrandir: in the preinst we would still have the old template file in /usr to check it against the one in /etc
<Mithrandir> you probably want to upgrade the file if it's not the newest but the second-to-newest too.
<mdke> elmo, Znarl, docteam svn repo new members, please. At least respond to my pings if there is a problem.
<Mithrandir> pitti: or just make that flag file, it should be innocent enough.
<Mithrandir> (my example is _very_ corner-case-ish)
<pitti> Mithrandir: ok, I'll write something and show it to you for a peer reviwe
<dholbach> hello developers!
<pitti> hi dholbach 
<Mithrandir> pitti: great. :-)
<mdke> hi dholbach 
<pitti> Mithrandir: and apart from that I rip out the PATH setting?
<dholbach> hey pitti, mdke
<Mithrandir> pitti: yes, please.
<pitti> ok, no problem
<Mithrandir> pitti: what shells will you be touching?
<pitti> Mithrandir: profile should cover the ash-like shells, that should already be good enough
<Kamion> pitti: considering that doing an upgrade for most people involves successfully using sudo, I think it's only important to make this work on new installs, not on upgrades
<pitti> Mithrandir: I can change tcsh, too
<Kamion> pitti: so changing the first creation of /etc/profile should be fine
<pitti> Kamion: and for Mithrandir's $PATH change?
<Kamion> pitti: that needs to be done on upgrade
<pitti> hm, so it would actually be more difficult to do $PATH on upgrade and the sudo hint not
<Mithrandir> heh.
<pitti> *scratching head*
<Mithrandir> pitti: ok, I'll need to touch zsh and bash since they set PATH in their rc files.
<pitti> Mithrandir: oh, you mean /etc/skel/.bash_profile ?
<pitti> it's not in /etc/bash.bashrc
<Kamion> if PATH is only in skel dotfiles now, we can't fix it all the way on upgrade
<Mithrandir> pitti: I'm wondering if that skel/.bash_profile is ok.
<Mithrandir> Kamion: it's just an "add ~/bin if it exists"
<pitti> Mithrandir: it should be
<pitti> Mithrandir: that's why I wonder which file bash you need to change
<pitti> s/bash/in bash/
<Mithrandir> pitti: I probably won't need to change bash, then. :-)  Just zsh and zshbeta
<Mithrandir> and /etc/crontab
<pitti> Mithrandir: where will PATH be set?
<Mithrandir> pitti: pam_env
<pitti> Mithrandir: as soon as I upload this, people won't have PATH set any more
<pitti> is that already in place?
<Mithrandir> pitti: they will, as long as you add the versioned dependency on libpam-modules.
<Mithrandir> yes
<Mithrandir> I uploaded it last night.
<pitti> cool
<Mithrandir> gdm needs to change
<pitti> so, Depends: libpam-modules (>= 0.79-3ubuntu3), right?
<Mithrandir> yes
<pitti> if /usr/bin/getent group admin | grep -q "\<$USER\>"; then
<pitti>     if [ -x /usr/bin/sudo -a ! -e $HOME/.sudo_as_admin_successful ] ; then
<pitti>         echo
<pitti>         echo 'To execute a command as root, run "sudo <command>" and enter your password.'
<pitti>     fi
<pitti> fi
<pitti> does that look sane?
<Mithrandir> I'd rather use "if groups | grep -q admin; then"
<Mithrandir> it also isn't i18n-ised. :-P
<pitti> if groups | grep -q "\<admin\>"; then
<sivang> pitti: ok, just talked to upstream, I we need to make it a local patch, shall I roll on a package and send you a link to the debdiff for review?
<pitti> Mithrandir: we also have lpadmin, so we need the boundary checks
<sivang> pitti: (context: irssi core dump)
<pitti> sivang: sure, that would be nice
<sivang> pitti: k
<Mithrandir> pitti: true.
<pitti> Mithrandir: cool, I didn't know 'groups' yet. There seems to be half a million way to get user/group info :)
<Mithrandir> pitti: heh. :-)
<triceratops> are there any plans to bind NIC MAC addresses via udev? I'm asking this because I have a computer here which always mixes up the NIC apearence (eth0 is mostly not the same nic after reboot).
<Mithrandir> triceratops: the installer writes out a /etc/iftab which is used by nameif
<triceratops> AFAIK there are two ways to bind a NIC address to a certain name, nameif and udev
<triceratops> Mithrandir: Hhhm, it's a breezy box upgraded to dapper. May be I should add a /etc/iftab by myself.
<Mithrandir> triceratops: it has been added in /etc/iftab since warty, iirc
<triceratops> Mithrandir: But having a closer look to udev the udev way looks smarter to me..
<Kamion> pitti: grep -qw to save you having to do word-matching in the regex
<Kamion> Mithrandir: I'd like to change that to generate udev rules
<Kamion> I understand the SuSE installer does that
<Kamion> (which should answer triceratops' question)
<pitti> nice, thanks
<triceratops> Kamion: Yepp, perfect... :-))
<pitti> I learn new little improvements every day :)
<triceratops> Kamion: It might be an idea to have some update-NICname script to do so after installation
<Kamion> triceratops: not my problem :)
<Kamion> but yeah, I guess it could be done in the udev maintainer script on upgrade or something - not sure that's wise, it'll be up to Scott
<triceratops> Kamion: Not my problem having this or not my problem/job to do this ;)
<Kamion> the latter
<Mithrandir> seb128/dholbach: would either of you like to patch out the setting of PATH from gdm or should I?
<seb128> Mithrandir: to change what?
<seb128> I was going to upload a gdm package this morning
<Mithrandir> seb128: don't set PATH in the config.
<seb128> I've 2.8.0.5 ready on my disk
<seb128> why?
<Mithrandir> seb128: because it's now done by pam.
<seb128> it has been asked during warty or hoary for a reason IIRC
<seb128> oki
<seb128> will change that for the upload
<Mithrandir> seb128: and add a dependency on libpam-modules (>= 0.79-3ubuntu3)
<seb128> that works
<Kamion> seb128: (this is one-true-path)
<Mithrandir> excellent, thanks.
<seb128> np
<Kamion> pitti: ispell-et looks like it's obviously ok to promote?
<pitti> Kamion: yes, I also wrote a report
<Mithrandir> doko: thanks for doing whatever magic you did to make ooo2 installable
<pitti> Kamion: hrm, I forgot to link it from the queue page, my bad; I put it into promoted
<doko> Mithrandir: use the neon sources from OOo ;-P
<Kamion> pitti: ok, just leave it there
* Mithrandir sticks his fingers in his ears and goes "la, la, la"
<Mithrandir> doko: ^^ :-P
<pitti> Kamion: I added it now
<doko> Mithrandir: yeah, but fine enough as a short term fix
<pitti> doko: yay code duplication :)
<Mithrandir> doko: sure.
<Kamion> pitti: mozilla-locale-* are ok to demote now, right?
<Mithrandir> pitti: you should put him against the wall for crimes against ReducingDuplication. :-)
<Kamion> doko: (neon24's back ...)
<pitti> Kamion: yes, we'll demote mozilla soon
<doko> pitti: please fix mozilla before demoting
<pitti> doko: ?
<doko> Kamion: will it stay?
<doko> pitti: try to install mozilla-dev
<Kamion> doko: it'll disappear before dapper release, according to the changelog
<pitti> doko: do I really have to? Dependcies are ok, and I don't really want mozilla
* seb128 kicks the libc causing crashes with utf-8
* seb128 kicks malone to not be able to query for a keyword to comments of a bug
<pvanhoof> err
<pvanhoof> installing x11-common wants to remove  ...
* pitti gets out of seb's way
<Mithrandir> seb128: file a bug.
<pvanhoof>  vncserver x-window-system-core xorg-common xserver-common xserver-xorg xserver-xorg-core etc etc etc
<pvanhoof> is that normal?
<Mithrandir> pvanhoof: there's something funky in the dependencies there, but I haven't had the time to track it down just yet.
<pvanhoof> I think it's trying to remove all xorg related packages
<Mithrandir> (and apparently, nobody else has either)
<seb128> Mithrandir: the libc crash has quite some dups already (on differents apps), for malone query there is a bunch of bugs too
<pvanhoof> ok, will not upgrade x11-common then ;)
<HiddenWolf> pvanhoof: Mithrandir daniels went loose on the x packages earlier. :)
<doko> pitti: I think this way of demoting packages is rather unfriendly. it breaks all universe packages b-d on a package which we just let fall down
<pvanhoof> okay, tell us when it's safe to upgrade :)
<pitti> doko: ENOCLUE - what's broken with m-dev?
* mvo wonders where his bugs has gone. update-manager has only two now, yesterday it where ~15
<pitti> ooh, btw, mvo
<doko> pitti: it has an = dependency on the nspr and nss packages ...
* mvo hides from pitti 
<pitti> mvo: I got this 'failed to contact gamin/fam' dialog box again this morning, and it looks as if it was from update-notifier
<mvo> pitti: interessting, I kicked fam out and switched to gnome-vfs instead
<mvo> pitti: I'll have a look
<pitti> doko: oh, I see; I still have the old libnspr-dev installed, that's why it works for me
<Kamion> mozilla-locale-* demoted
<mvo> pitti: do you know what version it was?
<pitti> mvo: hm, the one from yesterday's dist-upgrade
<pitti> mvo: I dist-upgraded again this morning, so if I get it again, I'll poke you
<mvo> pitti: thanks, for all I care gamin/fam can go away now :)
<pitti> mvo: yes, I'm pretty sure that I still had the previous version this mornig
<mvo> ok, thanks
<Kamion> seb128: should something depend on python-gobject?
<seb128> Kamion: if you mean "should something be change to Depends on it",no
<seb128> pygtk Depends on it
<seb128> but some app may drop the pygtk Depends in favor of pygoject
<seb128> (like flumotion)
<Kamion> seb128: no I actually mean the metapackage, not python2.4-gobject
<Kamion> nothing depends on that at the moment
<seb128> oh
<Kamion> (and so anastacia wants to drop it)
<Kamion> I think python-gtk2 should probably depend on python-gobject; if you have the first metapackage then you probably want the second too
<seb128> hum
<seb128> I'm not sure there is a main app using it and not pygtk atm
<Kamion> (will file a bug if you want, otherwise the seeds need to be changed)
<seb128> should python-gtk2 Depends on python-gobject?
<seb128> I was not sure
* StevenK comes back from playing PS2.
<seb128> python-gtk2 Depends on python2.4-gtk2 which Depends on python2.4-gobject
<seb128> but python-gtk2 could also Depends on python-gobject
<seb128> will do that change
<Kamion> seems simplest, if you don't mind that' thanks
<Kamion> s/'/;/
<pitti> oh, shit, why doesn't bash read /etc/profile for X shells...
<Mithrandir> seb/dholbach: either of you doing a rebuild of evolution-exchange?  I'd like to get -desktop installable.
<infinity> pitti: sudo help, say what?
<pitti> infinity: nevermind, this decision just sorted itself out since /etc/profile is not read in x terminals
<pitti> infinity: so I have to alter /etc/bash.bashrc anyway to add a note about sudo in terminals
<infinity> pitti: You're talking about having something spew "to become root, do 'blah'" when a shell is spawned?
<pitti> yes
<infinity> pitti: Since new installs will all have bash as the default shell, no reason to do it for all shells.
<pitti> we discussed this in yesterday's TB
<pitti> infinity: sure, just for completeness
<ptlo> pitti: profile is read for "login" shells, (can be forced with -l option to bash), and afaik x session is regarded a login shell, the terminals spawned in it aren't
<pitti> well, tcsh and zsh are pretty popular, too, so maybe we should change them, too
<infinity> pitti: <shrug>... Anyone who can figure out how to change their shell with "passwd -s" can probably figure out sudo. :)
<pitti> infinity: chsh might be easier, but probably true
<Mithrandir> infinity: is daniels going to fix the xorg-server FTBFS or should  I investigate?
<infinity> pitti: And most people will change their shell... From the shell.  So they'll see the help at least once.
<pitti> heh, true :)
<infinity> Mithrandir: No idea.
<Mithrandir> infinity: 'k, I'll poke it, then.
<doko> dholbach: do you still intend to update bittorrent?
<dholbach> Mithrandir: seb128 is going to upload a new version.
<dholbach> doko: yes, any objections or do you have it prepared already?
<seb128> ups, forgot that yesterday evening
<seb128> Mithrandir: yeah, new version coming in a few min
<dholbach> doko: if not, i'll take care of it later.
<infinity> Mithrandir: Yeah, rebuilding evo-exchange doesn't work, it needs a new version for new e-d-s API changes, apparently.  (I already tried)
<Kamion> pitti: yeah, I agree with infinity, no need to fork all shells for this
<pitti> Mithrandir: ok, so I'll change base-files entirely for you :)
<doko> dholbach: no obejctions at all :)
<dholbach> doko: ok, cool.
<infinity> dholbach: While you're at it, do you want to LSBify that init script (I was going to, but hadn't done it yet)
<dholbach> infinity: i'll take a look at it.
<infinity> dholbach: If not, don't worry.  I can do it sometime after UVF.  It's not urgent.
<dholbach> infinity: there are some other things to fix as well - i'll do it in one upload.
<pitti> Mithrandir: http://paste.ubuntu-nl.org/7313
* irvin is away: I'm busy
<infinity> pitti: Do you intend for that md5sum thing to become pseudo-conffile-like?
<pitti> infinity: yes, see the debdiff
<infinity> pitti: Cause if so, you could auto-generate new sums in debian/rules, and keep that file up to date.
<pitti> true
<pitti> well, it changed once in the whole ubuntu history
<infinity> Yeah, but if it changes again, someone will forget to update the md5sums file, so may as well automate it.
<infinity> Fire-and-forget changes are good.
<pitti> true, I'll add it to the clean rule
<seb128> Mithrandir, infinity: evolution-exchange uploaded
<Mithrandir> seb128: thanks
<seb128> np
<Mithrandir> pitti: thanks a lot. :-)
<pitti> hehe :)
<pitti> Mithrandir, infinity: http://paste.ubuntu-nl.org/7314 (if you would like to do an eyeball check)
<Mithrandir> pitti: uh
<Mithrandir> echo "`md5sum share/profile | cut -f 1 -d\  | cat share/profile.md5sums - | sort -u`" > share/profile.md5sums
<Mithrandir> that kinda nukes profile.md5sums first.
<pitti> Mithrandir: it avoid a temporary file
<Mithrandir> you can't know the execution order, share/profile.md5sums might be truncated before the ` ` command is done
<pitti> hm
<pitti>         LIST="`md5sum share/profile | cut -f 1 -d\  | cat share/profile.md5sums - | sort -u`"; \
<pitti>         echo "$$LIST" > share/profile.md5sums
<Mithrandir> sure, that should work.
<Kamion> ($$? is this in a makefile?)
<infinity> if [ ! grep -qw `md5sum share/profile` share/profile.md5sums ] ; then echo `md5sum share/profile` >> share/profile.md5sums; fi
<Kamion> infinity: ew, don't use [ ]  for that
<infinity> Err, with the appropriate cut/awk to extract it.
<Mithrandir> Kamion: yes, makefile.
<infinity> Err, minus the test.
<infinity> Kamion: Yeah, I was thinking out loud, shoot me. :)
<Mithrandir> md5sum < share/profile >> share/profile.md5sums
<pitti> Kamion: it's debian/rules, so yes
<Kamion> one of these days I'll get sponge into coreutils :)
<pitti> sponge?
<Kamion> then '(cat share/profile.md5sums; md5sum < share/profile) | sort -u | sponge share/profile.md5sums' would work
<Kamion> soaks it all up and *then* squeezes it all out
<Mithrandir> heh
<pitti> lol
<Kamion> http://riva.ucam.org/svn/cjwatson/bin/sponge
<pitti> so, this damn thing works fine now, I won't touch it any further
<sivang> Kamion: ah it's not packaged?
<pitti> Mithrandir: if you want to do any aestnetic change to the postinst, feel free :)
<Kamion> sivang: no, too trivial to be worth its own package
<sivang> Kamion: right :) I glanced at it now
<Kamion> as I say, I keep meaning to ask the coreutils folk whether they'd accept it, but I'd need to rewrite it in C for that
<Mithrandir> Kamion: should be trivial to rewrite in C, though.
<Kamion> yeah
<pitti> Mithrandir: well, indefinitively large buffer handling :)
<Mithrandir> 'cept the coreutils folk will want to make it i18n-ised and able to read mail.
<Mithrandir> pitti: malloc, dude.
<Kamion> pitti: no more than sort
<Mithrandir> :-)
<pitti> Mithrandir: realloc(), sure
<Mithrandir> Kamion: well, your current version doesn't use temporary files or anything.
<Mithrandir> pitti: that too.
<Kamion> oh, yeah, sort uses tempfiles, forgot that
<teroedni> Does The Mac G5 work in Ubuntu
<teroedni> ?
<teroedni> anyone knows?
<teroedni> :)
<infinity> teroedni: Yes.
<teroedni> so a 2.5GHz Quad-core PowerPC G5 would work with smp ?
<teroedni> in Ubuntu?
<teroedni> That would be infinitiv power:) guess it could compile pretty good:)
<infinity> teroedni: No, the quad-core machines are still a little bit unsupported, AFAIK... I was thinking of ordering one to see about fixing that.
<infinity> teroedni: Though, perhaps that is old news, and 2.6.15 fully supports them now.  I might be out of touch.
<teroedni> wow if you do
<teroedni> i really envy you;9
<teroedni> I really wants to order it myself
<teroedni> but my economy wouldnt let me yet:D
<teroedni> infinitiv:You got money to order a such achine?
<teroedni> machine
<theine> Is anybody working on this: https://launchpad.net/malone/bugs/28544 ?
<Ubugtu> Malone bug 28544: "kernel BUG at net/ieee80211/ieee80211_geo.c:81! (2.6.15-12.17)" Fix req. for: network-manager (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<theine> Ubugtu, that bug is not network-managers fault!
<theine> The bug is actually entirely in Dapper main.
<Kamion> don't talk to a bot
<theine> Kamion, I just realized that ;)
<theine> Nice bot though
<Znarl> Weekly graph
<Kamion> elmo: please sync silo-installer, overwriting Ubuntu changes
<Lathiat> hrm, how could i get a count of main and universe packages?
<siretart> Lathiat: use grep-dctrl on Packages.gz or Sources.gz, depending on what you want
<mvo> Lathiat: you could also use python-apt
<Diziet> How can I tell whether my upload's build is wedged somehow ?  I wasn't expecting to find it still listed as `building'.  (firefox, uploaded at 2000Z last night.)
<AlinuxOS> pitti, ?
<mvo> Diziet: this upload here: http://people.ubuntu.com/~lamont/buildLogs/f/firefox/1.5.dfsg-4ubuntu1/ ?
<pitti> hi AlinuxOS 
<Diziet> mvo: Ah, I should have gone up a directory.  Thank you.
<Kamion> Diziet: "Building" unfortunately just means "buildd admin hasn't confirmed it as failed yet".
<Kamion> this can be somewhat irritating; I think next week's Soyuz rollout will make the build logs more visible though ...
<mvo> Diziet: cheers
<Diziet> Harmpf.  POSIX ate my Makefile.  Nearly all of my Makefiles that I have ever written by the looks of it.
<Kamion> Perhaps this change ought to have been hidden behind POSIXLY_CORRECT.
<Diziet> sed -e 'stuff \\\n\t\tother stuff\\\n\t\tmore stuff\\\n\t\t'  is not allowed any more AFAICT.
<Diziet> I just read a rant about this on debian-devel and it was very inconclusive.  And it seems that there is no way to express it in a way that works with both the old and new formats.
<Kamion> sure there is, in this particular case
<Kamion> sed -e 'stuff' -e 'other stuff' -e 'more stuff'
<Diziet> Maybe we should have a .OLD_LINEBREAKING pseudo-target.
<Diziet> Indeed.
<Kamion> and I think shifting the command into a define works with both old and new, though I'm not sure about that
<Diziet> Also, I've let my local building chroot get out of date, which is how I didn't spot it myself.
<Kamion> (but that's ghastly)
<Diziet> Do you have a good reference for the change ?  Make's syntax is very badly documented.
<Diziet> If `no' I'll go looking myself.  Someone must have explained it at least semi-coherently on some mailing list at some point.
<Kamion> info make Execution
<Diziet> I've not got the new make installed here yet.  I was going to check there when it had arrived.  Thanks.
<Kamion> relevantly:
<Kamion>    A shell command can be split into multiple lines of text by placing a
<Kamion> backslash before each newline.  Such a sequence of lines is provided to
<Kamion> the shell as a single command script.  The backslash and newline are
<Kamion> preserved in the shell command.
<Kamion> and they're preserved even inside quotes, which of course sed doesn't like
<Kamion> at least I think that's the problem, I haven't verified carefully
<Diziet> Yes, almost certainly.
<Diziet> The error message is a complaint from sed.
<Kamion> It was mentioned in /usr/share/doc/make/NEWS.Debian.gz which is the only reason I was aware of it at all (due to apt-listchanges).
<Diziet> It's extremely annoying of them to have retrospectively introduced hundreds of bugs into code I wrote years ago.
<Mithrandir> mdke: I'm starting to look at your ubuntu-docs thingy now.
<janimo> Kamion, I mirrored my seeds branch at http://startx.ro/jani/ubuntu/xubuntu-dapper/
<janimo> and modified the update script in the meta package
<janimo> does it have to be mirrored on chinstrap for CD image?
<Kamion> not chinstrap, but it does have to end up on people.u.c
<Kamion> hang on a moment, I'll deal with that
<janimo> only http, no rsync access
<Kamion> that's fine, pulling now
<Kamion> ok, mirrored
<Kamion> I'll pull it every 15 minutes
<janimo> good, so should I change the update script to use your mirror instead of mine?
<Kamion> yeah, just make it be like the other -meta packages
<janimo> for consistency with the other metas
<Kamion> I will get round to your suggestion to move that into germinate, just haven't done it yet
<janimo> thanks
<janimo> btw any idea wrt the 64M install OOM killings
<Kamion> you now have germinate output at http://people.ubuntu.com/~cjwatson/germinate-output/xubuntu-dapper/
<Kamion> no, that sort of thing is hard
<janimo> would var syslog help?
<Kamion> we may be able to tweak lowmemcheck to have different thresholds, but if the reality is that the installer requires more memory than that, then that's reality
<Kamion> no, it wouldn't
<Kamion> there's ongoing work upstream on cutting down memory requirements, and I poke things from time to time as well, but it's not something I can commit to solving I'm afraid
<janimo> if it requires so much RAM is it still worth using busybox instead of a grownup shell?
<Kamion> yes
<Kamion> a lot of it is due to poor kernel module udeb splitting, I think
<Kamion> I am *not* going to start on the huge divergence from Debian that switching to a different shell would be
<janimo> for Debian then not ubuntu
<Kamion> it would make my work very difficult, because I would no longer be able to trust that testing under Ubuntu is valid for commits to Debian even to the extent that I do now
<Kamion> no, Debian absolutely will not do that
<janimo> saving 1Mbyte with busybox but requiring 64 either way seems strange
<Kamion> sorry
<Kamion> the requirement is less than 64 in Debian
<Kamion> as I say the increased requirements in Ubuntu are I think due to poor kernel module udeb splitting
<janimo> ah so udebs are a local prob.
<janimo> I remember it was last time too with the restricted modules
<Kamion> and also using busybox is not just about memory, it's also (in Debian) about fitting on constrained-space media such as floppies
<janimo> but now it crashes at when starting partitioning
<Kamion> that does suggest we're relatively close to the limit
<Kamion> there isn't that much that can easily go though
<Kamion> not that's a non-trivial size anyway
<janimo> why does it use so much memory? does not each installer step start with all mostly ram free
<janimo> or does RAM increase with each stage?
<Kamion> about the only thing we can do is fiddle around with partman to try to install some filesystem module udebs after setting up swap
<Kamion> the entire installer runs out of RAM
<Kamion> every feature added to the installer consumes some RAM
<janimo> ah so it does not run from the CD?
<Kamion> no
<Kamion> the initramfs is loaded from the CD with the base of the installer, and then the rest is loaded at run-time
<janimo> I suppose that with gtk it will be even larger then
<Kamion> but the initramfs takes memory too
<Kamion> yes
<Kamion> not switching to that yet though
<janimo> it would be ironic to be able to run xubuntu but not install it on a lowmem machine :)
<Kamion> cdebconf frontends are structured such that we could easily still build a newt installer for that
<Kamion> or even switch at run-time and udpkg --remove the ones we aren't using or something, though that's more fiddly
<janimo> and drop some features of the current installer?
<Kamion> *shrug* there aren't actually that many features you can drop before you start not being able to install
<Kamion> most of the interesting features that you might consider optional (e.g. Kickstart support) are actually really small and not worth dropping
<janimo> then I don;t understand what you meant by 'new installer for that'
<Kamion> newt, not new
<Kamion> it wasn't a typo
<Kamion> newt is the user interface library we use in the current installer
<janimo> but AIUI we are using newt now
<Kamion> yes
<Kamion> I'll look at lowmem, see if its thresholds can be fiddled to help out with the current problem
<janimo> so what was 'for that' ? what could we build a newt installer for?
<Kamion> in the event that we switch Ubuntu to a gtk installer sometime down the line
<Kamion> then it would be reasonable to continue using the newt installer for Xubuntu
<janimo> ah, ok
<janimo> I understood a separte newt installer for xubuntu now, and was wondering what to drop from existing one to fit in the RAM
<janimo> ok
<Kamion> implementing the mmaping suggestions in http://bugs.debian.org/329743 would help too
<Kamion> that's not entirely trivial work though
<sladen> mvo: where's michael.vogt@ubuntu.com--2005/apt--pdiff--0 mirroed?
<mvo> sladen: http://people.ubuntu.com/~mvo/arch/ubuntu/
<mvo> sladen: sorry, I forgot to include that in my mail
<Kamion> janimo: ok, we can support 64MB installs in lowmem mode at least
<mvo> sladen: it's also available in debian/experimental
<janimo> Kamion, does that mean d-i detects low mem and does some stuff differently?
<Kamion> janimo: yeah, once I tweak the thresholds for Ubuntu
<janimo> thanks
<Kamion> janimo: it drops back to English-only
<janimo> that's all that si different?
<Kamion> few other things
<Kamion> in HARDCORE lowmem mode (level 2) it skips loading some bits of the installer too
<Kamion> so you get fewer filesystem options, that kind of thing
<janimo> is there a link with all packages/source code archives involved in d-i?
<janimo> just for reading :)
<infinity> Kamion: How small did smarenka get lowmem in the end, for sarge/m68k release?
<Kamion> easier to get that from upstream
<janimo> upstream I mean
<Kamion> svn+ssh://svn.debian.org/svn/d-i/trunk
<infinity> Kamion: I don't suppose he actually managed to hit his target of supporting 8MB machines.
<janimo> cool
<Kamion> infinity: no, more like 25MB I think
<infinity> Ouch.
<infinity> Oh well.  Better than nothing.
<Kamion> well, hmm
<janimo> ahm, ssh? I hope there is anonymous too
<Kamion> actually no, the level1 threshold is 25MB, I think he got lower than that in lowmem mode
<Kamion> janimo: sorry, svn://svn.debian.org/svn/d-i/trunk
<infinity> janimo: http://svn.debian.org describes all the access methods.
<janimo> yep checking uout now
<slomo_> elmo: please sync tomboy, libgdiplus, fatsort, libogg, pygame, taglib, njb-sharp from debian/unstable and banshee, ipod-sharp, libipoddevice from debian/incoming... ubuntu changes can be dropped
<siretart> there are quite a lot of sync requests pending, is there a problem with the syncing script or just too overloaded people?
<Kamion> janimo: should I try to find some way to skip restricted modules in lowmem mode?
<Kamion> most of those are things like newer wireless cards, I'm guessing they're not massively useful on most 64MB machines
<ogra> Kamion, thats what i do on thin clients ...
<ogra> l-r-m takes up 15MB 
<Kamion> well, this is in the installer
<janimo> Kamion, I suppose so, although some smalish laptops may still have an USB wireless stick in them
<ogra> but that also uses a tmpfs for them, doesnt it ?= 
<janimo> but if that's what it takes to make it work with 64M sure
<Kamion> nic-restricted-* is smaller, but still takes up a reasonable amount of space
<infinity> janimo: LRM doesn't support any USB wireless devices anyway.
<Kamion> ogra: the installer's *all* tmpfs
<ogra> ah,k
<ogra> lol
<janimo> infinity, good then
<Kamion> janimo: I can do it without that, but can get it lower if we kill the restricted modules too
<janimo> Kamion, sure
<infinity> janimo: Just ath_pci, which comes in MiniPCI and PCMCIA (PC Card, if you prefer) flavours.
<janimo> if it won;t install poeple will file bugs so it's ok
<janimo> and if this fix is going to be in the next daily I can test both laptops on which flight 3 failed, yay
<Kamion> hmm, not quite sure how to do this though
<Kamion> I could just take the sledgehammer approach of dropping the whole restricted component
<Kamion> but that's a bit nasty
<ogra> Kamion, depends 
<infinity> Oh, actually..
<Kamion> probably won't be in the next daily
<Kamion> ogra: ?
<ogra> Kamion, if you have a very lowmem machine its unlikely you use a nvidia 64MB card
<Kamion> ogra: nvidia has nothing to do with nic-restricted-* which are the only restricted udebs
<infinity> janimo / Kamion : nic-restricted-firmware (not modules) contains the firmware for the acxNNN cards, some of which are USB, and are supported.  The driver's already in the kernel, just not the firmware.
<janimo> how large is this udeb?
<Kamion> infinity: hmm, yeah, good point
<infinity> janimo / Kamion : If that's valuable, you may want nic-r-f, but not nic-r-m
<Kamion> -rw-rw-r--  1 cjwatson cjwatson 799332 2006-01-13 10:55 /mirror/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.15/nic-restricted-firmware-2.6.15-12-386-di_2.6.15.4-2_i386.udeb
<Kamion> -rw-rw-r--  1 cjwatson cjwatson 195678 2006-01-13 10:55 /mirror/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.15/nic-restricted-modules-2.6.15-12-386-di_2.6.15.4-2_i386.udeb
<Kamion> -rw-rw-r--  1 cjwatson cjwatson 508642 2005-12-15 02:15 /mirror/ubuntu/pool/main/b/binutils/binutils-static-udeb_2.16.1cvs20051214-1ubuntu1_i386.udeb
<mdke> Mithrandir, great, I'll keep checking my email this afternoon in case you have problems
<janimo> anyway most 64M machines won't have such hardware so dropping them is ok if this is the only easy way to solve the lack of mem prob
<infinity> Right, and if you drop nic-r-m, you get to drop binutils too, AND drop the tempfs footprint of the linked objects.
<mdke> Riddell, fixed the kubuntu-docs web builds. We need to get together and figure out why the path was changed at some stage tho
<Kamion> janimo: we can get below 64MB without doing this, but we can get lower if we do this too.
<Kamion> not sure how much lower, of course
<janimo> Kamion, as you see fit
<Mithrandir> mdke: it's mostly along of "wtf were people smoking here?" :-)
<janimo> since machines come with ram sizes in powers of 2, 62M vs 55M may not make a difference
<infinity> janimo: No, but 62 versus 46 is good (I've had a few 48MB machines). :)
<janimo> I know that's why I said 55 ;)
<janimo> so the smaller the better if it's not too much work
<mdke> Mithrandir, ah
<infinity> Dropping the restricted stuff completely could buy you close to 16MB.  Maybe.
<infinity> No, maybe not.
<infinity> But a fair whack, anyway.
<Riddell> mdke: ok, cool
<janimo> server install option does not affect the installer footprint at this stage right?
<janimo> thinking that not only old desktops but quite some servers may have just 64M
* ogra is working with 64MB thin clients all day 
<Kamion> janimo: no
<janimo> ogra, do they need to run D-i themselves?
<Kamion> that's independent
<ogra> janimo, nope
<janimo> ogra, so it is not affected by d-i taking up over 64M
<ogra> janimo, they boot from the network ... i only need a slimm installed system (kernel and X)
<ogra> but even that wasnt easy to achieve ...
<ogra> the default took about 96MB on breezy ...
<ogra> you'll need to drop a lot of services we start by default ...
<Mithrandir> ogra: it seems like your ubuntu-artwork package doesn't clean up the mess it made in breezy (wrt firefox home page)?
<ogra> Mithrandir, i didnt upload one yet
<Kamion> hmm, there's something wrong with lowmem, the udeb with most of the hacks in it isn't getting installed
<Mithrandir> ogra: you didn't upload one what?
<ogra> Mithrandir, infinity wanted to introduce alternatives for the ff page 
<janimo> but there are quite a few 64M boxes running some risky redhat 7.0s I assume which could use some dapper love
<ogra> Mithrandir, edubuntu-artwork  for breezy
<Mithrandir> ogra: yes, I'm working on fixing that in breezy-updates.  I'm talking about dapper.
<ogra> Mithrandir, huh ? 
<ogra> works flawless here 
<janimo> servers of course
<ogra> janimo, yes, but you need to drop stuff from the default to not eat up all memory with useless processes 
<Mithrandir> ogra: it won't work in the case of : install breezy, install edubuntu-artwork/dapper, remove edubuntu-artwork/dapper, you don't have a working ff home page.
<infinity> ogra: This is xubuntu we're talking about here, it uses different seeds.
<infinity> ogra: So, I assume he's installing fewer scary RAM-eating things by default.
<ogra> infinity, even for minimal and standard ? 
<ogra> Mithrandir, i was relying on the change to alternatives in breezy 
<Kamion> minimal is shared between all derivatives; standard currently is but doesn't have to be
<infinity> ogra: You can't rely on the breezy fix to fix dapper, that's just broken.  What if a breezy user doesn't have -updates in their sources.list?
<Mithrandir> ogra: that still leaves index.html.orig on the file system.
<infinity> ogra: Or goes straight from a breezy CD to a dapper upgrade?
<ogra> Mithrandir, hmm, right 
<ogra> infinity, understood ...
<ogra> but nothing i'll care for now, one day before UVF :)
<Mithrandir> ogra: also note that I filed bug 28885 against you a short while ago.  _Please_ read the debian policy manual on what you're allowed to do in maintainer scripts and what you aren't.
<Ubugtu> Malone bug 28885: "changes other packages' conffiles in maintainer scripts" Fix req. for: ubuntu-artwork (Ubuntu), Severity: Major, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/28885
<ogra> Mithrandir, err, thats according to seb128 the only way to change a gdm theme 
<seb128> hum
<ogra> grmpf ... why am i not allowed to change that bug ...
<Mithrandir> ogra: then gdm needs to grow a new way for you to change the theme.  You must not ever change conffiles in maintainer scripts.
<seb128> for the record I never said to edit a conffile 
<janimo> seb128, ogra I am interested in a way to change the default gdm theme too
<ogra> could someone whi is allowed change it to edubuntu-artwork and assign it to me ? 
<seb128> I just said gdm.conf is where the theme are defined
<ogra> its hard to get aware of bugs if i'm not ever subscribed to them
<ogra> seb128, you told me its the only way 
<seb128> grrrrr
<seb128> I said gdm.conf is the place for that
<janimo> seb128, one way would be to use gdm.conf-custom but I am not sure it is a clean way to override the default gnoem them
<Mithrandir> ogra: what's your LP username?
<seb128> I didn't said to sed it with a maintainer script!
<ogra> Mithrandir, ogra iirc
<seb128> I changed the bug
<ogra> thanks
<ogra> seb128, thats not what i said ...
<seb128> Mithrandir: usually IRC nicknames work for the distro team people
<Mithrandir> uh, wtf?
<infinity> seb128: Really?
<seb128> infinity: it's my experiance with mvo pitti ogra dholbach 
<seb128> experience
<seb128> maybe I'm just lucky :)
<Mithrandir> ogra: anyway, it's assigned to you now.
<seb128> keybuk works too
<ogra> yup, saw that, thanks
<infinity> seb128: Maybe those just happen to be their launchpad logins too?  (Mine is definitely not infinity)
<mvo> seb128 knowns them all, because he likes assigning his bugs to us :P
<seb128> infinity: probably :)
<seb128> mvo: I like to share :)
<ogra> Mithrandir, am i allowed to divert a gdm.conf ? 
<seb128> mvo: isn't that nice ? :)
<Mithrandir> ogra: no, you can't divert conffiles.
<mvo> seb128: :)
<ogra> grmpf
<Riddell> ogra: but you already edit it don't you?
<ogra> Riddell, yes
<Riddell> so why divert?
<seb128> Riddell: because 2 packages can't ship the same file
<ogra> Riddell, to not edit it in the future 
<seb128> Riddell: atm it sed the gdm conffile on install to modify it
<ogra> but if thats no option either, i have no idea how to do it 
<Kamion> ogra: you need to get gdm to provide a proper way for you to do it
<ogra> yes
<seb128> ogra: patch gdm to teach him an alternative way
<mdke> Mithrandir, one last thing, can you email me a link to a binary once you've done so I can check it, really quickly? would appreciate it
<Kamion> you can't just go storming in doing whatever seems to kind of work (until you consider upgrades)
<Kamion> I realise that making things work now is a valuable thing to do, but there's also doing it in a way that doesn't need major cleanup later :)
<Riddell> ogra: what's wrong with editing the file?
<Kamion> Riddell: maintainer scripts must never edit conffiles; it causes dpkg prompts on upgrade
<Kamion> when the user never edited the file and will be totally confused about what to say to this prompt
<sivang> dooglus: are you Chris Moore ?
<sivang> ah, he's away
<sivang> pitti: http://muse.19inch.net/~sivan/fix_irssi_segfault.diff
<sivang> pitti: let me know if to upload the source 
<Kamion> right, lowmem level2 can handle 48M installs at least; trying lower
<pitti> re
<sivang> pitti: you lost connection or osmething?
<pitti> sivang: no, I was at lunch
<pitti> sivang: patch looks fine
<pitti> sivang: did you send it to Debian, too?
<pitti> sivang: would be nice to just sync the package
<pitti> sivang: oh, it's already for Debian
<sivang> pitti: what do you mean? :)
<pitti> +irssi (0.8.10-2) unstable; urgency=low
<sivang> pitti: ah , right :)
<sivang> I will email the maintainer, how much time can we wait for the sync?
<sivang> until tomorrow ?
<pitti> sivang: no, we can sync until maybe a week before release
<pitti> sivang: for such trivial patches at least
<sivang> pitti: so there is enough time for me to contact him , then
<pitti> sivang: (of course not for new upstream versions, and stuff)
<sivang> pitti: debian is also considered upstream in the UVF sense?
<pitti> yes
<sivang> so how come we sync until week before release?
<pitti> sivang: well, we will stop autosyncinc
<jdub> sivang: in large part, debian *is* the U in UVF :-)
<pitti> but we can manually request syncs after checkign them 
<sivang> jdub: :)
<ogra> sivang, we can still cherrypick trivial fixes
* sivang goes to check the package version in debian sid
<Tm_T> known issue? there's some md5sum mismatch in repositories
<Tm_T> atleast in se. mirror
<Tm_T> I'll check what fi. mirror gives
<Tm_T> yes, only se. mirror has that mismatch issue
<Kamion> 32MB install!
<jjesse> infinity: i have a question on wv-dial, just did an apt-get update && apt-get dist-upgrade today on dapper and it asked for a phone #, username, and password but i don't have a modem installed
<pitti> jjesse: known bug, and lots of complaints already :) we'll fix that ASAP
<jjesse> pitti: awesome thanks
<Kamion> it's been fixed in dapper already
<\sh> pitti: you are our security pope :) and I think you know debsecan...would you like to remove it from the archives, or should we try to make it working for ubuntu?
<\sh> .oO(to have a nice utility for ubuntu server :))
<pitti> no, I never tried it
<ogra> \sh, whats wrong with using it with the debian database ? 
<pitti> \sh: no idea how it works, but ubuntu-cve already provides something that coudl be utilized for sth like that
<ogra> it will at least give you indicators to look for in the ubuntu usn list
<\sh> ogra: I checked it with a sid chroot and an actual dapper system...there are differences
<\sh> ogra: and I have to check what's inside this http://secure-testing.debian.net/debian-secure-testing/project/debsecan/release/1/ database (sid e.g.) and check the data..
<ogra> i think you are still able to check debian security as it is in ubuntu now ...
<ogra> i dont think thats wrong ..
<ogra> and i wouldnt remove it ...
<\sh> ogra: it's actually very usefull. but I wonder what's the difference (despite the fact of different package version numbering)
<ogra> additionally i wouldnt put time into it one day before UVF if there are not a lot of bugs (iondicating that many users use it)
<\sh> ogra: it hasn't to do with bugs in the package...the request was: "it's not useful for ubuntu, please can you remove it" I say, it can be useful for server admins and others, so we leave it and make it work somehow.
<\sh> ogra: the only change we have to do is "adding ubuntu releases" and "updating a external database" (the database we have to analyse)
<\sh> ogra: which is propably something for dapper +1
<ogra> yes
<\sh> but very reasonable for the ubuntu server project (imho)
<ogra> "can be useful" is not really something i'd look at short before UVF, "is used by many users" would rather be my goal
<\sh> ogra: apt-get install debsecan ; man debsecan it's very useful...and how can u measure "used by many users" ?
<ogra> \sh, many bugs filed == many users that care for it
<Kamion> janimo: ok, down to 32MB should now work fine, at least on i386
<\sh> ogra: then it's worth to not remove it :)
<Kamion> below 52MB you'll go into lowmem level 2 where you have to select udebs yourself; I measured 32MB by selecting none of them
<ogra> \sh, does it have many bugs ? 
<\sh> ogra: http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=src&data=debsecan&archive=no&version=&dist=unstable (i think it's enough)
<ogra> where are the bugs in ubuntu ? i dont care about debian bugs for a ubuntu rewrite/fix 
<doko> Kamion: how's the installer package called, that lets you choose the timezone?
<ogra> do a s/users/ubuntu users/ in my above sentences
<\sh> ogra: ok...then it's not usable, because it doesn't support ubuntu correctly...so would you like to request the removal then? ;)
<Kamion> doko: tzsetup
<Kamion> well, tzsetup-udeb is the binary
<ogra> \sh, i really have other probs to care for atm we have UVF tomorrow ... decide yourself ...
<\sh> ogra: you see :) i think it's worth it...let's see what we can do about it...it's not an urgent project
<ogra> as long as you can use it to detect debian USN from a ubuntu system it might be helpful 
<\sh> ogra: yagisan just found the database structure...and we can add our security stuff to it..let's see
<doko> Kamion: thanks
<sivang> whoopsy, just saw the sudo message, before I read it to end, I was afraid something went wrong in the terminal :)
<mhz> jdub: ping
<doko> hmm, what's a reliable criterium to filter launchpad bug reports?
<Mithrandir> doko: ^X-Generated-By: Launchpad  ?
<doko> yeah, just found X-Launchpad-Bug: distribution=ubuntu
<Mithrandir> Riddell: hmm, any reason why you're setting the priority of /usr/share/doc/kde/HTML/en/kubuntu/about-kubuntu/index.html to 40 and not something higher?
<Riddell> Mithrandir: should it be set higher?
<Mithrandir> Riddell: I would imagine it should be higher than ubuntu-docs, since if you have both ubuntu-docs and kubuntu-docs installed, the kubuntu should be preferred?
<Mithrandir> Riddell: (based on the "ubuntu is the base, kubuntu builds on that, so if you install kubuntu stuff, you probably prefer that")
<Riddell> Mithrandir: when it's been discussed here we decided it's impossible to tell which the user prefers when they have both installed, and I think I was trying to be polite to ubuntu by setting the priority the same.  I'm happy to have a higher priority of course :)
<Mithrandir> Riddell: *shrug*, if it's already been discussed, I'd be fine with going with that.  Just wondering since I'm doing the breezy-updates stuff now.
<Riddell> Mithrandir: bump it up to 45 or something then
<Mithrandir> Riddell: sure.  It'll be more consistent with the previous behaviour (where you dpkg-diverted the file) too.
* Diziet does   for f in r*; do cp -a firefox-1.5.dfsg $f & done
<sivang> OMG evo is crashing on me, and I need an important email from IBM :p
<sivang> and it's POP3 , so it's no longer on ther server. I'm screwed
<Diziet> Given an Ubuntu bugzilla bug number, how do I quickly find the same bug in LP ?
<Diziet> Oh, there's a weirdo URL in the transition announcement.
<Kinnison> http://launchpad.net/malone/bugtrackers/ubuntu-bugzilla/%s
<Kinnison> is what I changed my "ubug" mozilla keyword to
<Diziet> Now that I have the LP bug ID I want to know how to close it by sending email.
<Diziet> But LP's ghastly web UI has no link (that I can find) to the email interface manual.  I found https://wiki.launchpad.canonical.com/MaloneCommandInterface but that doesn't seem to cover closing.
<\sh> Diziet: give me one sec I give you an example
<Diziet> Oh, it's here under `Noting a product release or source package release infestation'.
<\sh> Diziet: affects /distros/ubuntu/%s status Fix Released
<Diziet> Right.  Where did you get that ?
<\sh> (if it's right with the last fix for malone) 
<Diziet> But in fact the bug is invalid and I want to blow it off.
<\sh> Diziet: from my tool :
<Kamion> http://bugzilla.ubuntu.com/<bugzilla-id> gives you a link to the LP bug
<Diziet> kamion: Oh, very useful, great, thanks.
<Diziet> \sh: Your tool is the reference manual ?
<\sh> Diziet: https://wiki.launchpad.canonical.com/MaloneEmailInterface?highlight=%28LaunchpadProposalTemplate%29%7C%28MaloneSpecification%29%7C%28%28Status%29%5B%3A%27A-z%2C%5Cs%5D%2A%28DraftSpecification%7CEditedSpecification%29%29%7C%28%28Status%29%5B%3A%27A-z%2C%5Cs%5D%2AMaloneSpecification%29
<\sh> argls
<\sh> wiki.launchpad.canonical.com/MaloneEmailInterface
<Diziet> Oh, of course, I'm looking at the wrong page.
<\sh> shiddy search function of moin
<Kamion> 'status rejected' would presumably act to blow off the bug
<Diziet> So is MaloneCommandInterface obsolete ?
<Kamion> no, the link \sh gave links to MCI
<\sh> Diziet: but be carefull..the status commands are not updated, when I checked the day before yesterday
<Diziet> https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc seems to be what I'm supposed to be reading.
<Kamion> I think you're basically supposed to do "No, this bug makes no sense at all.\n\n status rejected\n"
<\sh> Diziet: so you have to adjusted them from the webpage like "fixed" is now "fix released" or "pending upload" is "fix committed" or something
<Kamion> to nnnnn@bugs.launchpad.net
<Diziet> What, just mix commands in with running text ?
<Kamion> (the leading whitespace being significant)
<\sh> Kamion: and gpg signed the mail must be :)
<Kamion> I've noticed bradb introducing commands with leading whitespace
<Diziet> Dammit, where is this DOCUMENTED ??
<Diziet> GRRR.
<Kinnison> Diziet: docs? *snort*
<Kamion> aha, found it
<Kamion> https://wiki.launchpad.canonical.com/MaloneEmailInterfaceUserDoc
<\sh> Diziet: for me it's my lpbugs.py but before...I just asked on #launchpad :) 
<Kamion> the previous links were specifications, not documentation; that page is intended as documentation
<Diziet> MaloneEmailInterfaceUserDoc isn't a reference manual, it's a pile of examples.
<\sh> Kamion: but outdated
<Kamion> Can't help you there ...
<Diziet> Yes, yes, I'm not asking for _you_ to help me.  But GRRR.
<Kamion> UserDoc does at least say that commands are introduced by leading whitespace, which appears to be mentioned nowhere else
<Diziet> `#
<Diziet> Status: BrainDump, MaloneDocumentation
<Diziet> '
<Diziet> Says it all really.
<\sh> Diziet: you want to reject the bug right?
<Diziet> Yes, yes, I'm trying to be taught how to fish, not be given a fish.
<Diziet> We've got too much of a culture of giving out fish, round here.
<Diziet> But in fact it turns out that the pond is dry.
<\sh> ok...
<Diziet> So I shall, erm, pour oil on it, thus mixing my metaphors beyond repair.
<\sh> you write in the mail (beneath your text)<tab whitespace whatever space> affects /distros/ubuntu/<sourcepackage> status Rejected
<Kamion> \sh: perhaps you should go and write a reference manual for it, so that we don't have to tell the next person who wants to know?
<Diziet> Can I write it above my text and use `done' ?
<Kamion> or somebody who can be authoritative on the syntax
<\sh> Diziet: sign the mail and send it to <lp bugno>@bugs.launchpad.net
<Kamion> I *believe* you can write it above the text and as long as your running text doesn't have leading whitespace you're fine. (No idea if it has a done command; it *should*, damnit.)
* Kamion resists the impulse to take an lp checkout to find out the real answer
<\sh> Kamion: well...it's all documented in this nice little documentation, before the change of malone..everything worked out of the box :)
<\sh> but the right thing (tm) to do is to ask bradb i thinkl
<Kamion> and hold him down until he writes better documentation and links it from the Malone UI ...
<Mez> has katie been updated or something?
* Diziet rants some more.
<Diziet> I'm going to make myself very popular with the LP people I'm sure.  But this stuff isn't rocket science !
<Kamion> don't worry, a lot of people are throwing bug reports at Malone just at the moment
<Kamion> and it's exactly what it needs
* Kinnison nods
* Kinnison expects the same for soyuz very soon
<\sh> Diziet: everything what can be improved, you should tell them :) 
<Kinnison> And I expect those will be *really* ranty
<HiddenWolf> Heh
<\sh> Kinnison: ETA for soyuz? rumours said, next 2 to 4 weeks?
<Kinnison> \sh: There's a deployment sprint next week
<Diziet> You saw my rant about the godawful page layout, which mpt had written down since SEPTEMBER.  That's FOUR MONTHS ago.
<Kamion> we are in a position where the distro team have a fair bit of influence over the Malone team's priorities right now, because they know our workflow depends on them; so we should take advantage of that
<Kamion> (imo)
<Diziet> That at least is something.
<Kinnison> Kamion: yep, you should
<\sh> Kinnison: cool :)
<Kamion> (page layout does take second place to missing-but-required functionality, though)
<Kinnison> also, iirc, daf has been assigned to help the malone UI for now
<Diziet> But if getting us angry is the best way to motivate LP in the right direction, what does that tell us about the LP project's ability to take and believe external input ?
<Kinnison> So they have more manpower
<HiddenWolf> Kamion: push for an interface that is _easy_ to use for newbies. You want to take every hurdle you can out of the process.
<Kinnison> Diziet: There's a huge issue here -- that the LP team worked essentially in isolation for a year to implement mark's vision
<Kinnison> Diziet: and now we have to match that to everyone elses's expectations
<Diziet> It's a BUG SYSTEM.  It's not for use by the ignorant, it's for use by DEVELOPERS.
<ogra> Diziet, the ui is not *this* bad, you just need to open ff with the double of your window width and cnter it ;P
<Kamion> HiddenWolf: the intent is for newbies to be steered towards filing support requests, not bugs
<ogra> s/window/screen/
<\sh> guy, sorry to say, working with LP and konqueror is just a nice thing to do :)
<\sh> .oO(setting every font to monospace 8)
<Kamion> so that those can be triaged a bit more effectively and avoid flooding developers with duplicates or poor bug reports
<ogra> \sh, not if you need to scroll 3m because the text interface is to small
<ogra> s/small/slim/
<\sh> ogra: that's why I wrote a remote bug requester :) 
<ogra> \sh, that doesnt fix the web UI
<\sh> ogra: some magic regexp and I was happy :) 
<ogra> the menus need to go from the right and left side
<\sh> ogra: well it will fix sometimes my scrolling disability
<Kamion> LP has a larval support system already. Look at the difference between the quality of the typical support request and the quality of the kind of bug we'd like to get. Consider that it may not always be worthwhile to educate users to the point where they can file the sort of bug we'd like to have; instead for some people it might be better to have them go through an intermediary.
<\sh> Kamion: well...I like those bug reports very much...very informative https://launchpad.net/malone/bugs/28784
<Ubugtu> Malone bug 28784: "KDE applications crash (Kontact, kicker, amarok etc)" Fix req. for: qt-x11-free (Ubuntu), Severity: Normal, Assigned to: Kubuntu Team, Status: Unconfirmed
<\sh> just a good and shiny subject line...and a backtrace report without debug symbols and no explanation
<Diziet> I think I'll let the bugs go hang and go and wrestle with firefox some more.  That's more fun.
<Kinnison> Diziet: FYI, launchpad only supports v4 keys currently
<pitti> Diziet: were you able to fix the ftbfs?
<Kinnison> Diziet: this is a known issue
<Kinnison> Diziet: I don't know the status though
<Diziet> kinnison: OIC.  Niiice.
<Diziet> pitti: The FTBFS is trivial and I will definitely fix it in my upload at the end of the day today.
<pitti> cool
<Diziet> Although I don't know if the fix will take on amd64.
* ogra will report back about amd64
<sivang> pitti: the DD is going to include the patch together with some more fixes tonight probably, so we could sync it tomorrow , overriding ubuntu changes. (currently there are none)
<pitti> sivang: then it'll be autosynced, unless that is deactivated earlier
<pitti> sivang: thank you
<pitti> sivang: (if that happens, just ask for a manual sync)
* desrt feels the need to inform pitti that his name was invoked in a recent posting to d-d-l
<sivang> pitti: yes, I will look on it, as a heavy irssi user it's fun to take care for its bugs :)
<sivang> pitti: bascially, all packages that do not contend with ubuntu local changes are un-manely autosynced?
<Diziet> Bah, the metadata for 5 firefox trees won't fit in my buffer cache.
<pitti> desrt: what's d-d-l?
<Diziet> I think my fs must be misoptimising its use of cache.
<sivang> desrt: yes, which ml is that?
<desrt> pitti; desktop-devel-list.
<sivang> oh
<desrt> pitti; gnome discussion list for... everything, really
<pitti> oh, I don't know that one
<desrt> someone said something along the lines of "it's secure because it's in hal"
<pitti> hm, depends in which hal :)
<\sh> hal9000, dave
<sivang> pitti: probably yours :)
<desrt> in reference to the ability of any user to shutdown the system instantly by calling hal
<pitti> desrt: btw, the gentoo maintainer replied to the long thread as well, he shares our opinion
<desrt> pitti; that's very good
<desrt> pitti; i'm fighting the proposal for g-p-m inclusion in the desktop on several points... one of them is the hal issue
<pitti> hm, is there any possibility to jump to a particular bug in malone?
<desrt> by number?
<desrt> launchpad.net/bugs/### will forward you to the right place
<\sh> lpbug:<bugno> is doing that for konqueror :)
<\sh> would be cool to have something like this for ff as default :) but I don't know anything about those shortcuts in ff
<pitti> desrt: hm, I meant a small input box like in bz
<pitti> but yes, that's good enough
<pitti> (a ffox search plugin would rock for that)
<desrt> pitti; make a firefox keyword
<desrt> pitti; very easy
<sivang> pitti: https://launchpad.net/bugs "Jump to bugreport"
<sivang> desrt: how do you do that?
<desrt> sivang; add a 'quick search'
<desrt> keyword 'lp'
<desrt> like https://launchpad.net/bugs/%s
<desrt> then you can type 'lp 1234' in the bar
<sivang> ok cool, I will add those
<Mithrandir> mdke, Riddell, ogra: please do look at the packages in http://people.ubuntu.com/~tfheen/doc-fixes/ ; those will be uploaded to breezy-updates unless there's something broken about them
<\sh> desrt: do you think it would interesting to have those little things included in ubuntu? I'm doing it for kubuntu and konqueror by default..but I'm missing it as standard for ff in gnome 
<sivang> \sh: I think it would 
<sivang> it's working nicely in konqi
<\sh> sivang: well for lazy people like me
<mdke> Mithrandir, will test now, thanks
<ogra> Mithrandir, why is the update-alternatives in the prerm, not postrm script ? 
<ogra> Mithrandir, apart from that, it installs fine here 
<Riddell> Mithrandir: looks good to me
<Riddell> kubuntu that is
<Diziet> *sigh*  I suppose I'll have to deploy a general-purpose V4 GPG key.
<mdke> Mithrandir, what's the 5.10-7 stuff?
<wasabi> Hey so I was thinking. Is there a swap daemon which could dynamically create swap files as RAM is needed?
<wasabi> with some sort of upper limit, etc.
<mdke> Mithrandir, works nice here. I'm just slightly confused by the tiny diff, did you do a diff on the breezy version? it should be huge
<ogra> wasabi, ltsp has such a thing, you can probably adopt it for normal swap stuff
<ogra> wasabi, look for ltspswapd at ltsp.org
<infinity> pitti: Hrm, I think your sudo help text would look better with the blank line trailing it, not leading it. :)
<infinity> pitti: (Stuff squished up against a prompt is hard to read)
<pitti> infinity: hm, maybe both then?
<pitti> infinity: before there is often motd, and a blank line looks better then
<infinity> There's never an MOTD in an xterm/gnome-terminal, which is where I expect people will be watching for this.
<infinity> (and the motd always has a trailing blank line too, no?)
<pitti> infinity: ok, I'll swap that around then
<infinity> Hah, and I can't actually find a system where I haven't replaced the stock MOTD.
<infinity> So much for that data point.
<pitti> mine hasn't a trailing blank, and I'm using the default one...
<tepsipakki> what the heck happened to cdimages.ubuntu.com?
<pitti> infinity: fixed
<tepsipakki> now it shows the front page of "the bazaar project"
<lionelp> tepsipakki: in fact, the url is http://cdimage.ubuntu.com/
<lionelp> (with no "s" at the end of cdimage)
<tepsipakki> both worked 5min ago =)
<lionelp> someone played with apache conf' :)
<tepsipakki> apparently
<Kamion> cdimages.ubuntu.com is supposed to be a CNAME for cdimage.ubuntu.com, although I don't think we've ever guaranteed that the former will work
<Kamion> cdimage is two hosts; I think it's more likely that only one of them is configured to deal with cdimages.u.c correctly than that somebody changed the Apache config
<Riddell> pitti: a package in kubuntu main just released a version with qt4, how much would you object to an upload?
<infinity> Are we not trying to avoid qt4 in main until post-dapper?
<pitti> *sigh* two days later, and UVF would have saved us :)
* infinity considers putting his ReducingDuplication foot down.
<Riddell> there really is no way to avoid the fact that we're going to have programs that use qt3 and some which use qt4 for some time to come
<infinity> Riddell: Sure, but not in a release we have to support for 3 years sanely, pretty please? :)
<jdub> ... after dapper ... :-)
<infinity> Riddell: If we can avoid it for dapper, the floodgates open for dapper+1, and it's all good.
<neuralis> infinity: which mysql did you end up deciding on?
<Riddell> if we support qt3 there shouldn't be a problem supporting qt4
<infinity> neuralis: 5.0
<neuralis> infinity: good deal.
<infinity> neuralis: With a rolling UVF exception, so we can get last-minute fixes.
<infinity> Riddell: That's a nice theory, but as a man whose supported multiple upstream codebases at the same time, I can tell you it's a pain in the ass.
<neuralis> infinity: excellent. they seemed to have fixed a great deal of the initial 5.0 bugs already.
<infinity> neuralis: Yes, that's what I based my decision on.  Both the current stability, and their impressive responsiveness.
<infinity> neuralis: I've no doubt it'll be as solid (or more) as 4.1 would have been for us.
<infinity> neuralis: And I really, really, really didn't want to support more than 1 (see above)
<Kamion> Znarl: 82.211.81.176 is part of cdimage.ubuntu.com but seems to give ECONNREFUSED to connections on port 80
<neuralis> infinity: yes, it's a good decision, and supporting both is more or less out of the question.
<infinity> neuralis: I also joined the Debian MySQL team in an effort to keep closer tabs on our pet bugs.
<infinity> neuralis: So, it's (in my opinion) well maintained. :)
<neuralis> infinity: they have 5.0 where, in experimental?
<infinity> neuralis: Nope, we've shoved it into sid as well.
<infinity> neuralis: 4.0 and 4.1 are both going/gone.
<neuralis> cool. i, for one, welcome our new 5.0 overlords.
<neuralis> infinity: still need to talk to malcolm and jane about server certification, as there seems to be serious confusion about it.
<Znarl> Kamion : Ok, I'll take a look.
<infinity> neuralis: I'm not surprised.  It was a bit confusing when we all sat down to discuss it the first time. :)
<Kamion> Znarl: thanks
<pitti> re
<Kamion> yes; die 2.6.12, die
<Kamion> we no longer need initrd-tools in main even, do we? since we supported initramfs-tools in breezy
* ogra thought that was dropped in breezy ...
<ogra> we had a discussion about it ...
<Kamion> nope, was still needed on hppa and ia64 until recently
<Kamion> but now those are fixed
<ogra> oh
<ogra> kick it out then :)
<Kamion> in process
<Diziet> *blink*  Brad Bollenbach has just sent a 0.5Mb TIFF to the launchpad-users list.  Is this considered normal behaviour over there ?
<Diziet> No, you stupid Emacs, I do not want to display the image in my Emacs frame !
* Kamion demotes linux-source-2.6.12 to universe.
<ogra> Kamion, really ? 
<Kamion> yes, was just waiting on the initrd-tools fix
<ogra> Kamion, didnt we want to drop unused kernel sources to avoid confusion ? 
<pitti> why not drop it completely?
<Kamion> dropping is up to elmo
<ogra> ah
<Kamion> I tend not to do removals, much easier to get those wrong
<Kamion> demotion is reversible
<Kaloz> hmz
<Kaloz> as noone else have an idea, I ask it here :P
<Diziet> `Launchpad could not import this OpenPGP key, because  at http://keyserver.ubuntu.com:11371/pks/lookup?search=0x67F23500&op=get. Check that you published it correctly in the'
<Diziet> etc.
<Kaloz> so, it seems like hdparm and the kernel doesn't detect the cache on my notebooks hdd. anyone can give an idea where to look for fixing this problem?
<Kinnison> Diziet: keyserver sync time issues
<Kinnison> Diziet: there's a bug filed about it already
<Diziet> Is keyserver.ubuntu.com not one machine then ?
* Kinnison hasn't a clue
* Diziet reports it as 28910.  Even if there are synch problems, it garbled the error message.
<Treenaks> Kaloz: the 'Write cache enabled' bit is writable, not readable, afaik
<Kinnison> Diziet: *nod*
<Kaloz> Treenaks: nah, i mean dmesg prints out the cache size in the hdd
* Kinnison goes to cook dinner
<Kinnison> ciau
<Kaloz> Treenaks: but just googled around more, it seems some toshiba-specific problem.. or better call it lack of support
<Kaloz> Treenaks: eg. hdparm says "BuffType=unknown, BuffSize=0kB"
<Diziet> They're going to love https://launchpad.net/malone/bugs/28908 too.
<Ubugtu> Malone bug 28908: "phishing vulnerability" Fix req. for: launchpad (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<Diziet> Thank you, stupid bot.
<Diziet> I'm particularly impressed by "a??phishing vulnerabilitya??" (which is how it looks in my - admittedly prehistoric - IRC client.)
<Treenaks> Diziet: it loves you too :P
<Treenaks> Diziet: it looks fine in my UTF-8-enabled setup
<Diziet> Oh, I, see, another Kuhn-
<Diziet> induced braindamage.
<Treenaks> with nice rounded quotes
<Diziet> (To be fair, Markus Kuhn just vigorously promulgated the problem; he didn't actually introduce it in ISO646.)
<mdke> what package is this a bug in: when my screen greys out (e.g. gksudo password prompt), after it comes back to normal it fades in but then flashes once.
<mvo> mdke: gksu
<mdke> mvo, thanks
<Bicchi> what kernel version is going to be on dapper?
<Burgwork> Bicchi, .15
<mdke> mvo, i've confirmed https://launchpad.net/distros/ubuntu/+source/libgksu1.2/+bug/5970, which was assigned to you coincidentally :)
<Ubugtu> Malone bug 5970: "Flicker when fading back in after password prompt" Fix req. for: libgksu1.2 (Ubuntu), Severity: Normal, Assigned to: Michael Vogt, Status: Confirmed
<Bicchi> Burgwork: any chances on using .16
<bddebian> Howdy
<mvo> mdke: we fixed that in the past why removing the fadeout screen before the release :) I personaly like it because it shows that something pretty big is going on (you become root), but our usability team is not really keen on it. 
<Burgwork> Bicchi, not by deafult
<Kamion> Bicchi: no, will be too new
<mvo> mdke: what is likely to happen is that we remove the fade-effect again
<Kamion> we can backport individual targeted fixes if need be, but we need a bit more stability than we can count on for 2.6.16 at the point of dapper release
<Kamion> as in, more time to stabilise
<mdke> mvo, ah, how about using the fade but eliminating the irritating flicker
<Bicchi> does anyone knows when the upgrade to mono will be on backports. from what i understand they are having problems building the 1.1.1X series
* netjoined: irc.freenode.net -> brown.freenode.net
<wftl> Hello all.  Other than the Evolution alarms applet and the sound level applet, are there any apps that get swallowed into the notification area in Dapper? Now that Sound Juicer replaces the CD player, I'm having trouble finding anything that is specific to the NA.
<tseng> gaim, gajim, banshee, muine, blam, tomboy, beagle
<tseng> (i could go on)
<tseng> its used by many apps
<tseng> wftl: the mixer applet isnt a notification applet, either
<tseng> its seperate
<wftl> tseng : Thanks, I just couldn't see to launch an app that wound up there. Appreciate the clarification on the mixer applet.
<wftl> Of course, of the apps you mentioned, the only one in a default Ubuntu install is GAIM.
<seb128> rhythmbox
<wftl> seb128, excellent. I'll add that to the description. 
<seb128> description of what? (just curious)
<wftl> Sorry, my next book is on Ubuntu.
<tseng> "next"?
<wftl> tseng : http://www.marcelgagne.com/mybooks.html
<wftl> I just like to make sure I keep my facts straight.
<wftl> :-)
<seb128> hehe
<tseng> hm quite a few books
<wftl> I like to keep busy.
<wftl> tseng : seb128 : in case you are curious -- http://www.aw-bc.com/catalog/academic/product/0,1144,032142722X,00.html
<seb128> wftl: nice!
<tseng> ya
<sivang> wftl: are you working with Marjan Bace, or Blace Bace ?
<wftl> sivang, no, I'm not. 
<wftl> I'm sorry to say I don't know either of them.
<sivang> wftl: just a sec, I'll toss you the link of the publisher house, AFAICT they are also working on a book
<wftl> Always good to know these things, sivang. :-)
<sivang> wftl: http://www.manning.com/
<wftl> As far as I know there are two other books being worked on right now, all due to appear before June.
<sivang> cool :)
<sivang> you have links?
<Burgwork> sivang, there are many books in the works, inlcuding an oreilly one
<sivang> Burgwork: nce to know that, the oreilly one is probably gonna be good
<wftl> There's one by somebody named Keir Thoman, at APress, called "Beginning Ubuntu Linux : From Novice to Professional"
* sivang wonders if the oreilly one is by someone from the community
<wftl> The Manning Press one is "Desktop Linux with Ubuntu" by Mark Stone.
<Burgwork> sivang, not that I know of
<wftl> Aside from my own "Moving to Ubuntu Linux", I don't know of any others.
<Burgwork> http://www.oreilly.com/catalog/ubuntuhks/
<jdub> wiki.ubuntu.com/UbuntuBooks
<jdub> ha ha -> Tips & Tools for Humanizing Linux
* sivang wonders if Jono included any ubuntu hacks in his book
<Burgwork> sivang, Jono is writing a book?
<ogra> grrr
* ogra kicks g-p-m ....
<ogra> crashy thing
<sivang> Burgwork: wrote, it seems http://www.oreilly.com/catalog/linuxdeskhks/
<Burgwork> sivang, ah
<crimsun> elmo: please sync rxvt-unicode from Sid, discarding Ubuntu changes
<Nafallo> giftnudel: your nick means poisonnoodle in Swedish :-)
<mbreit> Nafallo: here in germany (and giftnudel seems to be german) it means the same ;)
<giftnudel> that's what it's supposed to mean (although originated in german)
<Nafallo> hehe, oki :-)
<sivang> nice, how good shape is that in? http://doc.ubuntu.com/ubuntu/packagingguide/C/
<sivang> Burgwork: ^^
<Burgwork> sivang, being worked on actively, by LaserJock 
<sivang> very , and I mean, very cool
<LaserJock> oh, it will be better
<LaserJock> sivang: I'm doing a complete rewrite right now
<sivang> ah, I was sure http://debiansystem.info/ was open source book, that is downloadable somehwere
<sivang> LaserJock: nice, the strucutre looks very good
<LaserJock> sivang: the outline of what I'm doing is at wiki.ubuntu.com/UbuntuPackagingGuide
<LaserJock> sivang: I didn't write what is on doc.ubuntu.com. That was Unfrgiven
<kosmokramer> must go today 2 alienware laptops price 550 each including shippin case and wireless router, or 1 alienware desktop at 550 including shipping, monitor, speakers, keyboard and mouse and of course the tower. message me on aim at mikcomputing, msn at mcsltd3@hotmail.com or yahoo at mcsltd2 if interested and want to buy
<Burgwork> any ops to kick the bastard?
<sivang> heh
<Burgwork> sivang, how goes home user backup?
<sivang> Burgwork: stalled for the last 2 days, I'm still at work. suddenly we need to release after endless QA cycles...
<Burgwork> sivang, isn't it midnight+ there?
<sivang> Burgwork: yep :)
<sivang> Burgwork: to see some code, you can visit http://mercury.linuxguru.net/~sivan/home-user-backup/utilities/
<kosmokramer> must go today 2 alienware laptops price 550 each including shippin case and wireless router, or 1 alienware desktop at 550 including shipping, monitor, speakers, keyboard and mouse and of course the tower. message me on aim at mikcomputing, msn at mcsltd3@hotmail.com or yahoo at mcsltd2 if interested and want to buy
<sivang> that's a week old snapshot , I have more I haven't push'd yet
<sivang> oh bullocks,
<sivang> .
<wftl> I've noticed that Nautilus doesn't preview JPG files.  Is this a patent issue?
<infinity> wftl: It does here.
<infinity> wftl: Are you viewing them over a network?.. It won't do previews on samba shares and the like (to conserve bandwidth, and make the window not take 20 minutes to load)
<wftl> infinity, they are local files on a Dapper system.
<wftl> If I convert them to png, they display fine.
<torkel> wftl: how big are they?
<wftl> torkel, this one is 155K
<torkel> wftl: that should be small enough :-)
<wftl> a 62K file doesn't work either.
<wftl> Interesting.
<dholbach> doko, infinity, mdz: the problem with a newer bittorrent is debian bug 298814 - I
<Ubugtu> Debian bug 298814: "New upstream version available" Package: bittorrent, Version: 3.4.2-3, bittorrent/3.4.2-5., Severity: wishlist, Maintainer: Michael Janssen  http://bugs.debian.org/298814
<dholbach> doko, infinity, mdz: 'm not license expert enough to judge this.
<Burgwork> dholbach, I wouldn't touch the new version
<dholbach> Burgwork: oh?
<Burgwork> dholbach, the mirror thing. The choice of venue is legal stuff I don't understand
<infinity> dholbach: Looks problematic to me, yes.
<dholbach> infinity: so I'll do just the LSBifying.
<infinity> dholbach: Hrm.  The license at http://www.bittorrent.com/license/ doesn't seem to have the mirroring verbage... Or I can't find it.
* infinity reads more carefully.
<dholbach> infinity: hrm.
<Burgwork> infinity, seems to be fixed
<infinity> dholbach: If the sources you download contain an exact copy of the license at that URL, it doesn't seem to have the same problems mentioned in the bug report.
<infinity> dholbach: The source distribution clauses in that license are basically the same as the GPL, which is fine for us.
<Burgwork> infinity, I am looking at a tarball of 4.5.3
<infinity> Burgwork: Is it the same as http://www.bittorrent.com/license/ ?
<Burgwork> infinity, I will diff it
<infinity> Burgwork: If so, I'd say it's all good.
<dholbach> We should follow up on the bug report, if the license is good and get exception for the sync.
<infinity> Oh, wait.  It still has the choice-of-venue clause hidden at the end.
<dholbach> He'll have to re-do big parts.
<infinity> Section 13.
<Burgwork> infinity, no difference, and the source for 12 months appears to be gone
<dholbach> No bittorrent in main then.
<infinity> dholbach: You might want to ping mdz to get his gut feeling on how Ubuntu feels about choice-of-venue.  Debian tends to consider it non-free, but it's a fairly pedantic view.
<Nafallo> we DO have bittornado in main, no? :-)
<dholbach> Nafallo: and gnome-btdownload
<infinity> gnome-btdownload uses bittorrent as a backend.
<mdz> infinity: context?
<Nafallo> I wonder how hard it would be to have it use bittornado instead :-P
<infinity> mdz: http://www.bittorrent.com/license/ -- Section 13.
<infinity> mdz: Do we consider that non-free?
<Burgwork> dholbach, why do we have bittorrent and bitornado  in main?
<dholbach> mdz: concerning the bittorrent update before UVF - they changed the license in the meantime, which kept the Debian maintainer from packaging it.
<infinity> Everything else in the license (granted, I was speed-reading) seems fine to me.
* infinity runs off to the store to get some breakfast before hacking on thunderbird.
<dholbach> Burgwork: no idea.
<Burgwork> dholbach, as part of ReducingDuplication, we should throw one out
<Kamion> desktop: * gnome-btdownload       # simple GNOME frontend for bittorrent downloads
<Kamion> supported: * bittorrent             # rapid p2p download, for efficient large file distribution, perhaps for desktop
<Kamion> supported: * bittornado             # used on the servers.
<Kamion> yay seed comments
<Burgwork> ah
* Burgwork once again proves why he is not a developer and does not work for Canonical
<infinity> I take it bittornado's tracker is superior to bittorrent's?  Or we just preferred it at one stage?
<Nafallo> so we need a gui for bittornado so we can throw bittorrent out? ;-)
<Burgwork> Nafallo, you should be able to rework gnome-bt to use it
<Kamion> Burgwork: the seed comments *are* kind of hidden in a basement behind a sign saying "beware of the leopard", but anyway ...
<Kamion> infinity: if it's superior to bittorrent's, I shudder to think what bittorrent's tracker must be like; the bittornado one apparently really sucks
<Kamion> but it's possible it's still better for all that
<Burgwork> Kamion, yes, I but I have looked at them before
<Burgwork> Nafallo, if you relaly want to make me happy, finish http://www.amedias.org/~koke/gnome-torrent/ and get it installed by default
<infinity> Kamion: Could have just been a case of "first tool we tried, and never switched"... Might be worth pinging elmo/Znarl about in the interest of ReducingDuplication.
<ogra_> grrr
<Nafallo> Burgwork: well, my sparetime starts to get limited atm :-/.
<infinity> Kamion: Heck, most people weren't even aware that bittorrent shipped a tracked until the init script showed up a month ago.
<ogra_> why is g-v-m crashing constantly for me on amd64 ? 
<infinity> s/tracked/tracker/
<j^> bittornado added support to share all torrents on one port first; bittorrent should be able to do that now too
<dholbach> ogra_: it does on i386 too and pitti is investigating it.
<ogra_> dholbach, g-p-m as well :/
<ogra_> dholbach, but you will love me, i switched g-p-m to cdbs for consistency with the rest of the gnome pkgs
<dholbach> ogra_: Wow! How did that happen?
<j^> Burgwork did you look at freeloader?
<dholbach> elmo: Could you please remove evolution-caldav from the archive? The code went into evolution-data-server.
<ogra_> i guess it will be adopted by the debian gnome team one day, so i thought it should use the same packaging system
<Burgwork> j^, nope
<j^> Burgwork its in universe
<Burgwork> j^, their screenshots show some suspicous download activity ;) http://www.ruinedsoft.com/freeloader/1.png
<mdz> infinity: not clearly; only if we were to interpret it as discriminating against persons/groups/fields of endeavor
<mdz> dholbach: if it's questionable, let's not force it
<dholbach> mdz: my take too.
<dholbach> So I'll just clean up the init script.
<sivang> hey mdz 
<Nafallo> daniels: thanks! :-)
<daniels> Nafallo: hm?
<Nafallo> daniels: re #28911 ;-)
<daniels> oh, no worries
<mvo> anyone interessted in testing the dist-upgrade feature of update-manager for the breezy->dapper upgrade? add "deb http://people.ubuntu.com/~mvo/update-manager /" to your sources.list and install update-manager then. it will offer you a dist-upgrade to dapper then.
<seb128> mdz: do we want gaim 2.0 for dapper? They should have the 2.0 beta 2 out soon but no fixed calendar afaik (they planned 2.0 for december but delayed after feedback from beta 1)
<seb128> s/calendar/schedule
<ogra> soounds risky ...
* Nafallo agrees with ogra
<Burgwork> mvo, anything we should be watching for in particular?
<Nafallo> let's put gajim in main ;-)
<Burgwork> shipping without it means bad PR
<jdub> seb128: as gaim2 maybe :-)
<ogra> jdub, in universe ?
<dholbach> ogra: in dapper-backports :)
<ogra> lol
<mvo> Burgwork: it should (hopefuly) be self-explained. you can back-out, no worries :)
<Burgwork> mvo, no, in a testing sense. Any place where you think it might break
<seb128> jdub: hum, could do that ... but there is still the question to know if that's an UVF potential exception
<mvo> Burgwork: I'm mostly interessted in seeing how it copes with "real" systems, not my test-systems (where it does a pretty good job calculating the upgrade)
<OpsVentus> Right now I'm using Qt3 for GUI (in combination with c++) but now I'm thinking about updating to Qt4 but this is a large change, so I want to check if Qt4 is the way to go or if there's a better cross-platform(mainly KDE/GNOME/Windows/OSX) toolkit for small programs?
<OpsVentus> So what's everybody's opinion?
<Burgwork> mvo, ok
<dholbach> OpsVentus: You'd better ask in #kubuntu.
<OpsVentus> dholbach: but I program in GNOME and want the program's to work good in GNOME, still #kubuntu?
<spacey> OpsVentus, wxwindows?
<OpsVentus> spacey: why's wxWindows better?
<dholbach> OpsVentus: If you ask about QT4, they might have more expertise with it.
<OpsVentus> ok, gonna go there
<spacey> OpsVentus, no idea, just know its crossplatform :p
<mdz> doko: why internal neon for openoffice.org?
<OpsVentus> yeah, so is qt
<ogra> or gtk
<mdz> doko: is it a big project to update it for new libneon?
<mdz> seb128: if it doesn't have a credible schedule, I think we probably shouldn't
<doko> mdz: it's temporary, just wanted OOo to be installable again
<seb128> mdz: should we package it as gaim2 and switch it 2.0 comes soon?
<seb128> s/it/if
<mdz> seb128: if you have time to do the extra work, sure
<Nafallo> gaim2 would have the benefits of testing and community love (atleast in #ubuntu.se).
<seb128> mdz: hum, good point. I'll try to find somebody motivated to do it if possible ... :)
* ogra sighs deeply ...
* ogra starts the 2187523875th build of g-p-m
* sivang hugs ogra
<ogra> sivang, thanks i need it ..
<sivang> ogra: you're welcome, always.
<ogra> :)
<Nafallo> daniels: did you ever upload the fixed x11-common? I can't see it on dapper-changes.
<OpsVentus> I wrote a Sudoku game, any intressed to include this in (K)Ubuntu?
<ogra> OpsVentus, #ubuntu-motu 
<OpsVentus> ok
<ogra> but given the fact that we have UVF tomorrow, its unlikely that you can get it in in time
<daniels> Nafallo: 'fix committed', not 'fix released' ;) just sorting out clean chroot testing
<OpsVentus> then next release or something
<Nafallo> daniels: oh. I thought committed was uploaded :-P. but okey :-).
<daniels> aiui, bugzilla -> malone terminology is PENDINGUPLOAD -> Fix Committed, RESOLVED/FIXED -> Fix Committed
<daniels> er
<daniels> the latter should be Fix Released
<ogra> uploaded :)
<daniels> i guess it assumes we're all using version control
<lucas> problem is that malone sometimes considers that fix commited bugs are "fixed"
<lucas> and doesn't display them in normal listings
<lucas> (I opened a bug about this)
<daniels> oh, cool
<Nafallo> hehe, go bzr! :-)
* infinity munches on breakfast and prepares to test x11-common.
<theine> Are there any guide lines on when a certain bug is to be specified as minor,normal,major,etc...?
<theine> I mean classified...
<infinity> theine: If it's a small annoyance or typo or something, it's minor, if it's like 99% of most bugs, it's normal, if it seems like a bug that would affect EVERYONE and be a big hindrance, it's major, if it's OH MY GOD, THE WORLD IS CRASHING IN AROUND US, IF IT'S NOT FIXED, NO ONE CAN USE THEIR COMPUTERS, it's critical.
<dooglus> sivang: I am.
<dooglus> sivang: (in response to "14:54 < sivang> dooglus: are you Chris Moore ?")
<theine> infinity, thanks, I didn't expect the bar for critical to be that high
<daniels> theine: critical is HOLY SHIT YOU MUST DROP EVERYTHING NOW TO FIX THIS
<theine> So a reproducible bug that leads to a system freezy every time on certain hardware is to be clasified as normal?
<theine> daniels, ok, good to know...
<daniels> theine: it's the bug equivalent of your boss calling you at 3am because a fortune 50 customer's site is down
<Kamion> generally people shouldn't report bugs at critical; leave it to developers to do that triage
<daniels> theine: probably major there
<Kamion> otherwise we just get into the habit of downgrading critical bugs at sight, which of course has its own problems :)
<infinity> theine: Depends on the popularity of the hardware and the driver in question, really.  If it's, say, a very common IDE controller, and it happens for everyone, that's major.  If it's an obscure USB wireless dongle that you and one other guy own, it's probably normal.
<sivang> dooglus: oh hi :) I already updated the bug report, as you might have already seen
<theine> infinity, I'm actually refererring to this: https://launchpad.net/malone/bugs/28544
<Ubugtu> Malone bug 28544: "kernel BUG at net/ieee80211/ieee80211_geo.c:81! (2.6.15-12.17)" Fix req. for: network-manager (upstream), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<ogra> lol
<ogra> we just discussed this one in #ubuntu-bugs :)
<infinity> Well, it would be helpful if that wasn't filed against network-manager. :)
<ogra> yup :)
<theine> infinity, exactly, that leads me to my next question. How does one go about transferring the bug to linux-source or whatever?
<theine> ogra, and I guess it was decided to classify it as having normal severity?
<ogra> yes
<sivang> dooglus: thanks for the patch. programs should never exit with a segfault/coredump.
<theine> ogra, but the reason is not that network-manager is not in main, is it?
<ogra> theine, the reason is that network-manager breakage is no reason to classify anything as critical
<ogra> or major ...
<infinity> theine: What version does your ipw2100 driver report in dmesg when it's loaded?
<theine> ogra, well, it's actually linux kernel breakage
<dooglus> sivang: yes, I saw thanks.
<ogra> theine, thats the prob ...
<theine> infinity, 1.1.3 and I guess that's the problem. it should be 1.1.4
<infinity> theine: Yup.  1.1.4 resyncs with ieee80211-1.1.7
<infinity> theine: Bugged BenC about it.  Should be fixed in the next kernel upload.
<dooglus> sivang: it was a strange one.  I hadn't looked into glib before, but the memory allocation is strange.  the call to "free" actually changes the contents of the memory it's freeing.
<theine> infinity, cool, thanks
<ogra> theine, change the bug to fix pending ;)
<theine> ogra, okidoki
<Burgwork> theine, transfering a bug is a beast in LP
<ogra> ARGH....
#ubuntu-devel 2006-01-24
* ogra kicks g-p-m 
<theine> Burgwork, so what's best to do? file another one in that category it actually belongs to?
<Kamion> no
<theine> ok...
<Kamion> just leave it now, infinity's already changed it
<theine> Kamion, sure, I will, I was more asking in general...
<floam> is there any way to turn off this new logout dialog? I figured it was a prototype or something
<sivang> dooglus: so swapping the lines fixed that modifications? (I assume so, since upstream accepted the patch)
<floam> but it appears that it's supposed to stay like that since it's being touted https://wiki.ubuntu.com/DapperFlight3
<Kamion> theine: either click on the package name under "Fix Requested In", which is (unintuitively) a link to a status editing scren
<ogra> floam, its still work in progress
<Kamion> screen
<floam> ogra: oh
<theine> Kamion, ah, ok, thanks
<dooglus> sivang: it was freeing a node from a linked list, and then using the node to free the data that the node pointed to.  you should use something after freeing it.
<floam> ogra: is there a discussion or more information about it somewhere?
<Kamion> theine: or use one of the "Request fix" links to create a new bug task rather than change the existing one (this is if the bug is really in more than one place and multiple things need to be fixed)
<ogra> floam, on the ubuntu-desktop ML
<dooglus> sivang: usually you can get away with it, since 'free' won't destroy the contents of the memory, it will just mark it as free for future use; but in this case the call to free actually overwrote the memory immediately, causing the crash
<dooglus> s/should/shouldn't/ , of course
<sivang> dooglus: that's why you better make sure you're dynamic list allocation is done by order :)
<sivang> dooglus: s/allocation/deallocation/ 
<sivang> dooglus: thanks for this info, and thanks for the patch as well.
<dooglus> sivang: no problem.  I don't like seeing bugs in ubuntu either :)
<floam> ogra: ah
<floam> if they just want to have a window full of buttons that do different actions I wonder why they don't just get rid of the log out button in the menus
<sivang> dooglus: :)
<Riddell> daniels: am I correct in thinking the fontconfig version won't be upgraded between now and dapper?
<floam> and instead just make it a submenu with all of those options in it.
<sivang> dooglus: in this case, you also fixed it upstream, and debian and ubuntu :)
<daniels> Riddell: i'm not responsible for fontconfig, but probably
<daniels> Riddell: why?
<Riddell> daniels: there's a qt speedup patch which requires a version of fontconfig from recent CVS
<daniels> Riddell: do you know what specifically it requires?
<daniels> and do you have a link to the patch?
* infinity raises an eyebrow at daniels.
<infinity> Build-Depends: dpkg (>= 1.7.0)
<Riddell> daniels: http://websvn.kde.org/branches/qt/3.3/qt-copy/patches/0066-fcsort2fcmatch.patch?rev=493585&view=auto
<infinity> dpkg (1.7.0) unstable; urgency=low
<infinity> [...]  -- Wichert Akkerman <wakkerma@debian.org>  Sun,  5 Nov 2000 17:28:39 +0100
<elmo> btw, whoever was asking about bittornado before, we absolutely need the tracker from tornado
<infinity> elmo: Check.
<infinity> elmo: The bittorrent tracker is teh suck?
<daniels> infinity: i assume that's in xorg?
<infinity> daniels: Yeah. :)
<daniels> infinity: if so, detrius from the original.  don't blame me.
<infinity> Cruft from xfree86, carried over?
<daniels> yeah
<elmo> infinity: from when I tried it yes, and I haven't any particular inclination to try again as everyone I know who runs a debian style torrent server uses tornado
<daniels> Riddell: uhm, so why not just apply the fccfg.c.patch?
<infinity> Cause you never know when someone might build it with a 6 year old dpkg.
<infinity> elmo: Fair 'nuff.
<elmo> infinity: 6 years in Debian time is like, a realease and a bit :-P
<daniels> infinity: now you're thinking like a Debian X packager
<infinity> daniels: You take that back.
<ogra> mjg59, the g-p-m situation looks quite bad ... i cant get 0.3.4 running more than 0.5sec no matter what i do here
<elmo> speaking of Debian X packagers, where did gravity go
<daniels> elmo: what do you mean, where did he go
<elmo> apparently the << Conflicts considered harmful message didn't reach them yet
<elmo> daniels: he's not been on IRC the last couple of times I checked, but I haven't looked very hard
<elmo> also his typo took out the entire debian buildd network today
<elmo> IT WAS FUN
<daniels> he's not on IRC overly much; he can't IRC from work
<daniels> haha, awesome
<daniels> HE"S FAIRLY RESPONSIVE TO MAIL
<elmo> mail is so 6 years ago
<daniels> jdub: dude, this keyboard has a sticky shift key
<sivang> how can one type take out the entire buildd network ?
<sivang> elmo: lol
<jdub> daniels: i told you that you'd go blind if you kept doing that. now your keyboard is sticky too.
<elmo> because the buildd network has single points of failure
<elmo> like, say, apt
<sivang> s/type/typo/
<infinity> sivang: By having syntax in your control file that dpkg-dev lets through, but apt-get COMPLETELY FLIPS OUT ON.
<infinity> (Of course, this is really a dpkg-dev bug for letting it slip through, and an apt bug for flipping out so badly, but it's more fun to blame gravity's thinko..)
<lucas> elmo: I saw him yesterday or the day before on IRC
<sivang> infinity: nice to know this can be done with small type, and not with a carefully crafted something :)
<sivang> elmo: have you switched timezones or something? or are always awake that time?
<elmo> sivang: I don't work in a UK timezone
<Riddell> daniels: that's what I'
<Riddell> daniels: that's what I'll be trying next
<sivang> elmo: ah , I see. like jblack
<mvo> infinity: what was it that made apt explode? (not that I would care :P)
<daniels> sivang: elmo comes awake at night to feast on the souls of the undead and/or tinned tuna
<sivang> elmo: that explains why you are so quite during EU daylight zone :)
<sivang> daniels: hey, I'm alone at the office, trying to make this final QA cycel in which I don't find any more bugs to fix, that's too scary for me atm. /me shivers
<ogra> sivang, whats daylight ? 
<infinity> daniels: That one looks much better.
<daniels> infinity: bangin'
<infinity> daniels: Shall I sign and upload it for you?
<sivang> ogra: hehe
<daniels> infinity: i'm one step ahead
<daniels> infinity: but thansk :)
<daniels> also, thanks
<infinity> mvo: Two Provides fields, one of which was versioned.
<sivang> the hummings of the Dual Xeons and pSeries servers here seem like they will come up and steal my sole..
<elmo> mvo: speaking of which, we really should fix that
<infinity> mvo: It may have just been the versioned provides alone that killed it.  The error message seemed to indicate it was flipping out on the version.
<elmo> if we ever want to be able to do versioned provides
<sivang> ogra: do you also work different timezones?
<elmo> mvo: (for versions of we meaning you of course ;)
* mvo runs
<daniels> infinity: versioned provides? awesome
<mvo> infinity, elmo: where can I download the package to reproduce the problem?
<elmo> mvo: spohr.d.o/~james/
<mjg59> ogra: I'd suggest talking to upstream
<infinity> daniels: It was meant to be a Replaces, he thinkoed it.
<infinity> (Hence why there were two Provides fields, one was correct, one was the Replaces-that-wasn't)
<ogra> mjg59, will do, but we'll most likely miss UVF through that 
<ogra> mdz, can i ask for a gnome-power-mmanager UVF exception in advance for version 0.3.4 ? 
<daniels> elmo: itym /~troup/
* sivang cries for having to work late late tonight not having time to give home-user-backup some love.
<elmo> daniels: indeed
<mdz> ogra: when will you upload it?
<ogra> mdz, since i'm in this strange conference from tomorrow on, not before sunday night 
<mdz> it looks OK, but it can't have an indefinite extension
<mdz> ogra: monday is fine
<ogra> ok
<ogra> then i can care for my other stuff, thanks 
<mvo> elmo: thanks, I have all I need now to reproduce the problem
<elmo> ah, crap UVF
<infinity> That's not the first time that's been said today.
<infinity> And I'm sure it won't be the last. :)
<dholbach> good night everybody.
<sivang> night dholbach 
<slomo_> elmo: please sync tomboy, libgdiplus, fatsort, libogg, pygame, taglib, njb-sharp, cowbell from debian/unstable... ubuntu changes can be dropped... and banshee, ipod-sharp, libipoddevice from debian/unstable but seems like they're currently somewhere between incoming and pool ;)
<dholbach> bye sivang
<ajmitch> slomo_: hopefully they'll get in sometime before UVF :)
* ajmitch is hoping zope 3.2 manages to get in & synced automatically
<dilinger> has keybuk been around?
<slomo_> ajmitch: yes... well, we'll see :)
<slomo_> ajmitch: oh... they're in the pool now ;) problem solved...
<ajmitch> are they? good
<mvo> dilinger: he dosn't feel very well currently
<dilinger> mvo: ok, thanks
<dilinger> i just wanted to make sure i'm not somehow missing him (ie, new nick or something)
<dilinger> yay
<dilinger> http://article.gmane.org/gmane.comp.gnu.parted.bugs/7325
<dilinger> i thought they were just going to ignore that
* mvo goes to bed now
<sivang> night mvo 
<mvo> night sivang 
<infinity> Meh, that same obscure ldd/fakeroot segv on firefox/amd64...
* infinity sighs.
<infinity> I was kinda hoping it would magically go away.
<jcole> fyi, i talked about a floppy install for ubuntu, here's an example for creating a small iso :) - http://www.instalinux.com/cgi-bin/coe_bootimage.cgi
<jcole> no prompts btw when using that method
<sistpoty> elmo: please sync scapy from unstable, ubuntu override ok. thx.
* robertj isn't entirely sure that he wouldn't rather his old notification bubble back
<robertj> is that from upstream?
<tseng> yes.
<seb128> and that's really likely to change before dapper
<seb128> some other shape/theme/etc
<robertj> I think less is more really is right on here
<ogra> hmpf 
<ogra> after a suspend to ram my touchpad stops working :/
<Lathiat> ogra: sucky
<ogra> Lathiat, yup
<ogra> sound is also muted
<seb128> anyway time to sleep here, later
* psusi needs help integrating the dmraid package into debian-installer.... any d-i gurus around? ;)
<sistpoty> elmo: may I ask you to sync childsplay from unstable (went into archives few hours ago) which doesn't have any ubuntu changes? Thx.
<minghua> elmo: can I ask (an MOTU to ask) for a sync from Debian incoming?
<minghua> elmo: I am the Debian maintainer of a universe package and a new version just got uploaded
<sistpoty> elmo: you can take my motu ok for minghua... if it breaks I'll make him fix it ;)
<minghua> thanks sistpoty :-)
<sistpoty> np minghua
<sistpoty> good night everyone
<daniels> on my reasonably-new, extrodinarily expensive radeon x850 xt pe, glxgears with dri gives me a stonking 13 fps
<daniels> take that, glxgears as a benchmark
<Tm_T> daniels: and drivers support that card already?
<Tm_T> I think no
<Tm_T> might be the reason ;)
<daniels> Tm_T: this is with dri
<daniels> (i'd know if it wasn't)
<daniels> and my system can do a little more than 13fps in software rendering
<Tm_T> hehe
<daniels> in fact, I'd go so far as to say, orders of magnitude more
<Tm_T> so then you have my lucky number as fps, congrats ;--P
<SEJeff> So why did the new logout dialog get nixed for the ugly one in the new gnome panel? Is this an upstream decision?
<SEJeff> I'm just curious
* freeflying is away: Away at the moment
<daniels> ah, 2985, that's more like it
<daniels> (he says, shamelessly benchmarking with glxgears)
<infinity> I'm telling Daniel that you do that!!
<daniels> infinity: so which order do you do symlink<->dir transitions in?
<Tm_T> daniels: what you did?
<daniels> Tm_T: disabled drm debugging
<Tm_T> :)
<infinity> daniels: Ship the directory in the package, delete the link in preinst.
<daniels> infinity: and for dir -> symlink?
<infinity> daniels: (since in the old package, the "link" couldn't have contained files, it can't possibly try to remove any)
<infinity> daniels: And for dir -> symlink, ship link in package, do dir->link swap in POSTinst.
<daniels> okay, cool.  ta.
<infinity> (To avoid having the link replace the dir, then dpkg follow the link to remove old files)
<infinity> Why it unpacks, then removes old files, I'll never know.
<infinity> But whatever. :)
<infinity> It's documented in policy, it just takes some real world banging of heads against walls before you really believe that what policy says is true. ;)
<infinity> (I may have permanent scarring)
<daniels> i remember getting it the wrong way around, so then I inverted it, then I got told *that* was the wrong way around, and ...
<infinity> Heh.
<infinity> Well, the only "right" way is the one that works.
<infinity> Which is different depending on your starting point.
<infinity> The worst is if you have a directory with stuff in it that you want to convert into a symlink... With that same stuff in it (ie: locally installed crap)
<infinity> Most dir->link stuff if in /usr/share/doc, so an rm -rf sets you on your way.
<infinity> For the moving bit, you may want to consider actually moving dir/* to a temporary directory, creating the link, then moving it back (still in the postinst, though)
<daniels> yeah
<infinity> With appropriate rollback support, should the postinst abort. :/
<daniels> that part can be SEP. ;)
<infinity> <nod>
<infinity> I just cheated in that one upload of xmumble that I did, by just yelling at the user if they had crap there. ;)
<daniels> x-common, which is getting merged into x11-common
<infinity> Some days, I'm of the opinion that "if you didn't install it to /usr/local or /opt, you deserve to have it removed by dpkg anyway", but then I remember that I'm not actually that mean.
<daniels> learn 'em good and proper.
<daniels> 'user data? not any more!'
<daniels> if you install crap into /usr/include/X11 or /usr/lib/X11, you deserve exactly what you get
<daniels> imo
<infinity> Hrm.  thunderbird builds on exactly one arch.. The one I tested on.
<infinity> How inconvenient.
<infinity> daniels: Yeah, I wouldn't have any problems with you claiming total ownership of those directories and just assuming what's there can go away.
<infinity> daniels: Of course, in the Debian case, you'll run into some user that has been hand-compiling some ancient imake-using crap for the last 10 years, and has been installing his own headers to X's directories, and he'll cry.
<infinity> And gravity can cross that bridge when you push him over it. :)
<daniels> haha.  indeed.
<infinity> I can't see any Ubuntu user even knowing or caring what X's include and library directories are for.
<Burgundavia> infinity, and if they do, they should know what to do
<Tm_T> yo/
<Tm_T> whops
<daniels> infinity: the problem with /usr/lib/X11 is that it's sort of /usr/lib/X11, /etc/X11, /usr/share/X11, and /usr/bin/X11 rolled into one
<daniels> (or was, traditionally, before Debian mangled it, and the modular hilarity refused to countenance the same kind of stupidity.)
<infinity> daniels: Yeah.  As is common with ancient UNIX stuff.
<infinity> daniels: Heck, we still ship /etc/rmt ... \o/
<infinity> Go hysterical raisins.
<daniels> isn't that tape backup shiz?
<infinity> <nod>
<Tm_T> two things I'm waiting in *NIX world: X replacement and working sound system
<daniels> woooooo
<daniels> Tm_T: oh, X is fundamentally broken
<Tm_T> aye
<daniels> Tm_T: it's just that any other system is worse, if only by virtue of not being X
<daniels> the thing is, X's fundamental breakage isn't what you think it is, doesn't really matter that much these days, and is worked around by extensions anyway. :)
<Tm_T> daniels: aye, replacement was bad word, but I'm not good with vocabulary
<Tm_T> but I've been fighting with sound problem now whole night... errh
<daniels> it could certainly be more optimal, but it's generally fine
<Tm_T> aye
<Tm_T> generally fine it is
<Tm_T> I really need justworks(tm) software mixing
<Tm_T> though that would save only half in my problem, but it would be good improvenment anyway :)
<Tm_T> oh well, breakfast ;) ->
<infinity> Hrm, is gnome-volume-manager crashing when I login a shiny new feature?
<trs81> infinity: yeah, I've noticed that too
<trs81> I was going to report it, but launchpad doesn't know about the latest version
<Burgundavia> infinity, evil plot by Riddell to make us all switch to Kubuntu
* Lathiat laughs
* dilinger watches firefox crash and sighs.   i hate this browser.
<jblack> doko: Still around?
<jblack> Looks like dapper might have a bit of a serious problem. Postfix bombed out here.
<jblack> I'm still working out how to chase it, but it looks like postfix is dependant upon a missing /usr/sbin/postfix-script. 
<lamont> jblack: that's two reports.... hrm..
* lamont investigates
<jblack> I tried symlinking /etc/postfix/postfix-script to /usr/sbin/postfix-script.
<jblack> That gets rid of the postfix -v check error, but then postfix still bombs out for some unknown reason.
<lamont> what's the error exactly?
<jblack> When I ran postfix check -v:
<jblack> /etc/postfix/postfix-script: line 211: /usr/sbin/postfix-script: No such file or directory
<lamont> and when that's commented out>?
<lamont> er, fixed
<infinity> Line 211 of /etc/postfix/postfix-script.
<infinity>         $command_directory/postfix-script quick-check
<infinity> Oh, you got there already.
<lamont> infinity: yeah - found that.  that's bug #1.
* infinity shuts up.
<jblack> postfix check no longer errors
<lamont> and all is well?
<jblack> Nope. :( 
<jblack>  /etc/init.d/postfix starts, but the daemon doesn't run.
<jblack> Nor do I see anything running in init.d
<jblack> /var/log/mail.(log|warn) are both 0 length.
<jblack> postfix -v start reports a bunch of dict_evals, and returns back to the shell with no apparent error. 
<lamont> sh -x /etc/init.d/postfix start says?
<Mithrandir> Riddell: please merge your seeds, you still have python-musicbrainz in there.  kthxbye.
<jblack> a lot of stuff... usplash_write 'SUCCESS ok'
<jblack> a fir printfs, a tput, echo '[ ok ] '.. return 0, exit 0.
<Mithrandir> ogra: ^^ same goes for you.
<lamont> jblack: my issue is that I can't actually reproduce this bug...
<jblack> You want to play here?
<lamont> if that works for you...
<infinity> lamont: What's the correct fix to /etc/pf/pf-script?   Just point it at itself on line 211?
<jblack> Ok. Let me setup so that you can get in.
* infinity will try to reproduce this right now.
<lamont> fwiw, there's a debian bug on this already...
<infinity> postfix chroots by default?
<lamont> yes
<jblack> lamont: mind pasting me a ssh key in msg? 
<tepsipakki> lamont: I guess mount will not get nfs4-support before upstream?
<lamont> tepsipakki: see debian experimental. please test
<lamont> well, it'll hit there tomorrow's dinstall
<tepsipakki> oh??
<tepsipakki> that's great
<tepsipakki> where is it now?-)
<lamont> right now, see incoming.debian.org/util-linux_2.12r-5.1nfs4*
<tepsipakki> wow
<tepsipakki> will test it for sure
<Mithrandir> ogra: why update-alternatives in prerm rather than postrm> because the docs says that's the usual style.
<lamont> infinity: line 211, change '$command' to '$config'  - see if you can reproduce this on a dapper box/
<infinity> lamont: Yeah, I can reproduce.  It pretends to start fine, but leaves no daemon running.
<lamont> tail mail.log
<lamont> er, /var/log/mail.log
<infinity> Ah-ha.
<infinity> Jan 19 17:29:06 localhost postfix/master[6772] : fatal: /etc/postfix/master.cf: line 83: no valid IP address found: smtp
<lamont> yeah.
<viviersf> :/
<lamont> which is, um, wrong.,
<Mithrandir> lamont: is there any reason why it doesn't try to see if smtp.foo exists before suggesting it?
<lamont> Mithrandir: with the line starting 'smtp' it's supposed to bind to INADDR_ANY
<lamont> infinity: grab source, change the -O2 back to -O1 in debian/rules, and see if rebuilding fixes things
<infinity> lamont: You think this is an optimiser bug?
<lamont> "think" might be a bit strong
* lamont needs to go to bed before he face-plants...
<lamont> and I'll admit that it's almost grasping at straws, execpt that we used to just blindly do -O1, and there are new compilers between -3 and -5
<lamont> because, anyway you slice it, this is working on code that should be just fine, hasn't been touched, etc.
<viviersf> daniels, ping
<daniels> viviersf: sup sup
<lamont> infinity: anyway, I'm going to go catch about 6 hours sleep, then fix the bug... any details you may have by then would be very welcome...  Otherwise, no biggy.
<viviersf> daniels, i have to go set up a acer c200 tablet today, and i was wondering if you didnt have any info / comments on the tablet on it ?
<viviersf> i cant seem to find anything on the internet
<daniels> viviersf: ... no
<viviersf> problem being xorg + wacom :(
<daniels> yeah, that's non-trivial to fix
<Den> Hi - Do I need a new password for launchpad bugzilla that is different from bugzilla.ubuntu.com?  I entered a bug on b.u.c about 3 weeks ago, & just noticed a msg about that moving to launchpad, & I can't log in there.  Was moving bugzilla to launchpad done within about the last 3 weeks?
<viviersf> lol seems im going in blindlu
<viviersf> and hoping for the best
<minghua> Den: according to the announcement: http://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000051.html you need a new password for lanuchpad
<Den> minghua: Thx!
<daniels> gar.  why does the meeting have to be at 1am.
<Mithrandir> Den: I'm still working on getting you a live cd.  Sorry for it taking forever, but the rest of the distro team seems busy trying to break stuff around me. ;-)
<Den> Mithrandir: Good morning :)  Thanks.  Keep up the good work!
<Den> Mithrandir: are you a full time employee for ubuntu?  
<Den>  Mithrandir Also, since you got a firewire cd, great that you can test that out yourself too,
<Den> Mithrandir: And, the whole reason I got into needing this iso is cause of a bug with external hard disks getting offlined during a 10 GB file copy, so, do you have an external firewire or usb2 HD to test a 10GB file copy on?
<Mithrandir> Den: yes, I have a 80G USB2 drive.
<Den> Mithrandir: did I tell you, & do you still have, the err # of the bug I submitted on external drive copyy fail?  Have you been aware I submitted a bug on that?
<Mithrandir> Den: no, I'm not aware of any such bug, but I imagine it's a kernel issue, so BenC is the man to talk to.
<Den> Mithrandir: Are you the person who would work on that?
<Mithrandir> no, BenC would probably.
<Den> Mithrandir: Yes, BenC told me to get a new kernel to see if that fixes the bug, which is why I am wanting the iso for Dapper - to get the new kernel.
<Mithrandir> Den: ah, ok.  I'll do my best today as well, then. :-)
<Mithrandir> Diziet: dude, 1.5.dfsg is a really, really broken version number.  Could you please make mozilla-firefox-locale-en-gb & friends be installable on i386?
<Den> Mithrandir: Thanks.  this bug is holding up my being able to use kubuntu for serious work.  That's why I m eager to get the iso & see if the new kernel fixes this bug.
<Mithrandir> Den: understandable.
<Den> Mithrandir: any eta for when the bugs holding up the iso will be fixed, and the iso available?
<daniels> whois den
<Mithrandir> Den: today might be a bit bumpy, since daniels is going to do a bit of X uploads, but I'm hoping for tomorrow
<Den> Mithrandir: Thanks.  Anything yoyu can do to get a woking iso asap is greatly appreciated! :) Please email me as soon as you think a working iso should be availble. :)
<Mithrandir> Den: yup, will do.
<Den> Anyone - How do I get help w/ launchpad not logging me in?  This channel?  some other channel?  I just created an account there, but it refuses to log me in.  When I try to log in, it just drops me back at the main page, not logged in.  What's up? any ideas?
<daniels> stop refusing cookies?
<Den> Is this a known bug?  
<Mithrandir> Den: #launchpad might be able to help you
<Den> I gota let it have cookie?  If so, it should say so.  I didn't see any msg from launchpad  about needing cookies.
<Den> Cookies got me in.  Very frustrating to not have it tell me I neeeded cookies. 
<infinity> Unless there's a big ugly session ID in the URL, it's a fair bet that you need a cookie to login.
<infinity> That's just kinda how the interweb thingee works.
<doko> infinity: please could you requeue openoffice.org2 on powerpc? same error as last time ...
<tepsipakki> lamont: util-linux_2.12r-5.1nfs4 built and installed fine on dapper
<tepsipakki> next some mount-trickery
<tepsipakki> well, it mounts nfs4 shares, what else is there.. =)
<pitti> Good morning
<dholbach> good morning
<pitti> hi dholbach 
<dholbach> hellas pitti!
* pitti hugs dholbach 
* dholbach hugs pitti back.
<dholbach> pitti: how does icon-naming-utils look? :)
* pitti whistles innocently
<pitti> dholbach: sorry, what?
<pitti> :)
<Mithrandir> Riddell: is there any way to, programmatically, determine if one is on kubuntu?  Do you change lsb_release or something, f.e?
<dholbach> pitti: it's just 62 k big, that'S a piece of cake for you ;)
* dholbach hugs pitti
<daniels> g'morning pitti, dholbach
<pitti> morning daniels
<dholbach> hellas daniels!
* dholbach hugs daniels
<Mithrandir> uh, is there any way to reject a bug and at the same time give a reason?  Just saying "rejected" looks a bit unfriendly.
<minghua> elmo: if you accepts sistpoty's support for me, please sync scim 1.4.4-1 from incoming/unstable, dropping ubuntu changes, thanks
<infinity> Mithrandir: Give the reason in the status whiteboard, it gets sent out with the reject email.
<pitti> Mithrandir: use the status field
* dholbach hugs Mithrandir, infinity and minghua too.
<Mithrandir> thanks.
<Mithrandir> hiya dholbach
<minghua> hi dholbach :-)
<dholbach> Hey koke!
* infinity holds dholbach's dog ransom until gnome-terminal starts behaving better.
<jsgotangco> yeah
<koke> hi there!
* Mithrandir feels a bit bad about rejecting a translation.
<dholbach> infinity: i'm 10 seconds before uploading a new version
<dholbach> infinity: so leave my dog out of it :)
<infinity> dholbach: Does the new version not freeze every 10 minues, eating 100% CPU for 30 seconds, later, rinse, repeat? :)
<daniels> g'morning mvo
<mvo> hey daniels 
<dholbach> It says something about not crashing at startup. GNOME bug 327313
<Ubugtu> Gnome bug 327313: "crash on startup" Product: gnome-terminal, Component: general, Severity: blocker, Assigned to: gnome-terminal-maint@gnome.bugs, Status: RESOLVED, Resolution: FIXED http://bugs.gnome.org/show_bug.cgi?id=327313
<dholbach> infinity: uploaded.
<infinity> dholbach: Nah, mine doesn't crash on startup, mine just hogs resources every once in a while.
* infinity shrugs.
<infinity> We'll see.
<dholbach> Yeah. :)
<infinity> I'll file a bug if it persists for another week or so.
<infinity> (ie: if it's still happening by sprint time)
<infinity> Oh look, I think I fixed the thunderbird PPC FTBFS.
<daniels> iz gtk bug
* infinity waits for the build to finish anyway, out of paranoia.
<infinity> What time it the distro meeting today?
<dholbach> That sounds great. The terminal seems to be in the state as most other parts of GNOME are, getting all code stuffed in before Feature Freeze. :)
<dholbach> 14 utc?
<infinity> Ugh.  1am for me.  And I have to leave at 5am to catch a plane.
<infinity> That'll be fun.
<dholbach> poor you. :-/
<daniels> infinity: there should still be a red eye platinum in the bar fridge.  use it wisely.
<infinity> Oh well, I'll probably be up packing anyway.
<daniels> (tastes really good with vodka, but I brought all that with me, so.)
<Mithrandir> what's a red eye platinium?
<daniels> Mithrandir: awesome-tasting energy drink.  combines far better with vodka than red bull.
<jsgotangco> evil au concoction
<Mithrandir> daniels: ahkay.  I've never been fond of vodka and red bull, though.
<infinity> Oh, speaking of alcohol...
<Mithrandir> they both taste better alone
<daniels> infinity: drink the beer and you're dead
<infinity> Mithrandir: I don't think any beer will be travelling with me, due to the "carrying all my carry-on around to hotels, and into Tokyo" business..
<Mithrandir> infinity: shame. :-/
<daniels> infinity: jal?
<daniels> infinity: heathrow has decent duty-free
<infinity> daniels: Da.
<infinity> daniels: LHR duty-free sells Coopers?
<Mithrandir> infinity: not that I know of.
<daniels> not coopers, no.
<infinity> Yeah, exactly. :)
<infinity> Mithrandir: I'll see how nice I'm feeling, but the idea of carrying bottles around with me all over doesn't sound very good.
<infinity> Mithrandir: You may just have to come visit and get pissed.
<Mithrandir> infinity: why can't you stick them in the luggage proper?
<infinity> Cause they'll explode?
<Mithrandir> (and yes, I guess I will come to .au again, but probably not this year)
<infinity> I've never had good experience with beverages in checked luggage.  Ever. :)
<Mithrandir> not IME
<pitti> hi again
<infinity> I've had cans explode, bottles break (and well-packed ones, too, I think baggage handlers just hate me)
<pitti> bwah, I just had a very nasty DoS
<pitti> dholbach: can you please teach n-cd-burner to clean up after itself?
<daniels> i got bottles from cph -> lhr -> bcn -> lhr, but somewhere in between lhr and mel, one of them leaked just a tiny bit, and suddenly all of my white shirts, weren't
<daniels> but I did have like eight bottles
<dholbach> pitti: clean up?
<Mithrandir> daniels: packing them in a plastic bag would be a good precaution, yes.
<pitti> dholbach: my daily backup just tried to stick a 4 GB ~/.image.KLDF file into the backup archive, which overrun /var and left my machine unusable and unbootable
<daniels> Mithrandir: hindsight, 20/20
<daniels> Mithrandir: they were pretty well padded in clothes
<Mithrandir> heh.
<pitti> dholbach: that's a DVD image produced by n-c-b
<daniels> infinity: dude, the side of my case won't even go on any more
<infinity> daniels: Ouch.  Got bendy?
<daniels> infinity: i can't bend it back into shape.  i took a photo of it just then, and now my camera's crashed.  taking batteries out for a while isn't helping.
<daniels> not my day.
<infinity> Mithrandir: I'll see what I can do, but I'm not making any promises. :)
<Mithrandir> infinity: thanks anyway.
<dholbach> pitti: and it was a successful burn?
<pitti> dholbach: yes, from yesterday
<pitti> dholbach: anyway, even if it's an unsuccessful one, there should be a signal handler that ensures cleaning up the tmpfiles even after crashes
<dholbach> pitti: right - want me to file the bug report (upstream) and CC you or you want to do it?
<pitti> dholbach: you know I'm lazy :)
<pitti> anyway, no reason to shift my work to you
<pitti> I'll file one
<dholbach> No, it's ok.
<dholbach> Just take care of icon-namin-utils ;-p
* dholbach hugs pitti.
<\sh> oh well I'm a lucky guy
<\sh> is UVF including the 19th or am I allowed to upload as quick as I can a new upstream version?
<Burgundavia> pitti, you might want to comment on desktop-devel about the security issues with the current design for g-p-m
<\sh> I just got the message of a new pykde snapshot which fixes the most bugs I patched away from pykde.
<\sh> http://mats.imk.fraunhofer.de/pipermail/pykde/2006-January/011994.html
<infinity> \sh: If it builds and tests okay, upload it, fast. :)
<pitti> Burgundavia: I'm not on that list, do you have an URL?
<\sh> infinity: cool...I just woke up..have to be quick then :)
<Burgundavia> pitti, http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00329.html
<\sh> gnarf..it's not yet on the bloody servers
<mvo> Burgundavia: what's the opinion about libnotify/notification-daemon?
<Burgundavia> mvo, in, but I am not a gnome developer nor should you take anything I say an canon
<Burgundavia> mvo, there have been no serious objections to it
<mvo> Burgundavia: thanks, that's good news (even with your caveat)
<Burgundavia> mvo, how easy would it be to abstract gnome-app-install to be distro-agnostic?
<mvo> Burgundavia: actually, it should be fairly easy because from it's POV it only needs a working package cache and desktop-files or channels. the actual backend that fetches/installs is relatively small and should be easy to e.g. switch to smart 
<Burgundavia> mvo, I assume update-manager is the same way? Just wondering if it would be worth proposing them upstream
<mvo> Burgundavia: I think we can try that for g2.16 when we build our tools on top of smart. it's way more disto-independant
<Burgundavia> mvo, cool
<Burgundavia> mvo, are we thinking smart for dapper+1
<mvo> Burgundavia: I think gnome will only accept it when it works with at least one other distro (that is, a rpm based one) :)
<Burgundavia> ya
<mvo> it's not set in stone, but there is a strong tendency I think
<infinity> mvo: Well, it would work with apt-rpm, I suppose. :P
<Burgundavia> infinity, apt-rpm has basically been dropped by fedora. g-a-i would need to work with yum
<infinity> Burgundavia: Yeah, I know, hence the ":P"
<mvo> infinity: haha, right. but it seems that the distros using it switch to smart. and our python-apt is not available elesewhere AFAIK
<Burgundavia> infinity, I get tortured by a FC4 machine at work daily
<mvo> another problem is that I would have to use cvs again if it was a official gnome package :P
* mvo pats bzr
<LetterRip> hello all - Blender Foundation is currently on RC2 of blender 2.41, while we had hoped to have a release ready for today, and it is extremely unlikely for there to be any real change to current code base, it would be a bit more convenient if we could use the full release that will happen Monday
<LetterRip> otherwise we would need to ask the debian package maintainer to try and do the RC2 version into debian
<infinity> LetterRip: You're better off asking for a UVF exception once the release is out, than discussing it now.  Odds are, if it's within a week, it'll be accepted, if there's a compelling reason to want the new upstream.
<LetterRip> here is the list of changes since our 2.40 release about a month ago
<LetterRip> http://mediawiki.blender.org/index.php/Competitive_Analysis/ReleaseNotes241
<LetterRip> infinity - ok
<LetterRip> it is mostly bugfixes - but isn't a 'bugfix only' release
<LetterRip> infinity - who would I contact for a UVF exception once the release is out?
<LetterRip> is there a doc somewhere?
<infinity> LetterRip: mdz and/or Kamion would be your best bet.
<LetterRip> ok much appreciated
<Riddell> Mithrandir: we don't change lsb_release so you can't tell if it's kubuntu
<Mithrandir> Riddell: 'k.
<infinity> LetterRip: And, of course, it should be packaged already by someone (either the Debian maintainer, or one of our maintainers) before asking for such an exception.  Hard to consider software that isn't actually available.
<Riddell> openoffice checks for various environment variables of course
<LetterRip> infinity sure
<Riddell> and you could check if kubuntu-desktop is installed
<LetterRip> Larstiq would probably package it today if I asked, but didn't want to ask unless absolutely necessary
<LetterRip> also didn't want to package an RC2 with full release so close
<LetterRip> thanks for your help
<infinity> LetterRip: Well, if the full release is likely to be (almost) identical to RC2, it's worth packaging now, so it's a simple matter of swapping tarballs and incerementing the version in the changelog when the final release is out.
<LetterRip> infinity - ok
<Riddell> Mithrandir: I merged the seeds yesterday to remove python-musicbrainz
<Mithrandir> Riddell: you need to upload kubuntu-meta too.
<Kamion> Mithrandir: I merged edubuntu seeds yesterday for another reason, but didn't upload -meta.
<LetterRip> infinity I think the only thing that might change is the addition of a few more docstring translations, and possibly one or two more bug fixes
<Riddell> Mithrandir: true
<Mithrandir> Kamion: should I do that for you/ogra?
<LetterRip> ok thanks for your help
<LetterRip> I'm off to sleep...
<mdke> Mithrandir, ubuntu-docs looks good to me. thanks very much for doing that! do you know if the dapper packages are already ok?
<Mithrandir> mdke: I hope so.
<ogra> Kamion, Mithrandir, whats wrong ? 
<infinity> Mithrandir: Someone should double-check that the dapper packages migrate properly. ;)
<infinity> Mithrandir: (But it can be done later..)
<Mithrandir> ogra: you include python-musicbrainz in your seeds => edubuntu-desktop uninstallable
<ogra> ah, k
<mdke> Mithrandir, the dapper packages were made a while back so they might not have the same fix. I think that Riddell sorted it out, but a double-check would be a good idea I think
<mdke> Mithrandir, we build them from our svn repository, so if any changes are needed, lemme know and I'll make any changes
<Kamion> ogra: (I've already merged your seeds while doing something else - you just need to update edubuntu-meta)
<ogra> Kamion, yup, got it ... i was just missing the piece of conversation that introduced all the highlighting in here :)
<ogra> hmm...
* ogra wonders why he has a -meta-0.46 locally ... built on monday and has the change, but isnt uploaded ...
<Mithrandir> mdke: I'll go over the dapper packages as well.
<ogra> hmpf
<mdke> Mithrandir, thanks a lot, hopefully you won't have the same problem
<triceratops> How may I fill a bugreport against a package from universe which isn't registered in malone yet?
<sivang> morning all
<sivang> ogra: did you sleep at all ? :)
<ogra> yes, some hours
<ogra> 3 or 4
<sivang> :)
<dholbach> triceratops: tell the guys in #launchpad to import it.
<triceratops> dholbach: Thanks, will do so...
<jk_work> kernel 2.6.12-10 won't boot my laptop. 2.6.12-9 will. Any info you want?
* sivang wonders if the http://cdimage.ubuntu.com/vmware/Ubuntu-5.10.zip image includes DB2Express
<Kamion> sivang: no
<Kamion> it's a simple Ubuntu 5.10 install
<sivang> Kamion: ah , ok.
<ogra> Riddell, ping
* #ubuntu-devel  [freenode-info]  if you need to send private messages, please register: http://freenode.net/faq.shtml#privmsg
* Kamion scratches his head and tries to match up console-data's idea of keymaps with gfxboot-theme-ubuntu's
(daniels/#ubuntu-devel) Kamion: cxkb ftw
(Riddell/#ubuntu-devel) dholbach: is this a bad sign? http://muse.19inch.net/~jr/tmp/libfreetype.diff
<dholbach> Riddell: no, seems like they just added a function and changed internal stuff -  that part looks good.
<Kamion> daniels: yeah, I know I'll have to change it later, but we need a keymap menu RSN
<teroedni> Hello:)
<dholbach> Riddell: we should have input on this from our cjk testers.
<Riddell> dholbach: well it fixes the CJK problem, I've confirmed that, it's just the patches are quite large and I don't know much about freetype to say if something else might randomly break
<dholbach> Riddell: me neither. :(
<Mithrandir> Kamion: having a menu there would be really, really nice, yes, since I can then just map the names from the menu to X keyboard maps in casper and mark simplified-live as implemented. :-)
<Riddell> dholbach: and you were the other guy who commented on the bug report :)
<dholbach> Riddell: Yeah, because I synced freetype at the time and brought breakage to Ubuntu. :)
* infinity smacks his forehead.
<infinity> daniels: Not testing if a directory is a symlink before dumping the contents and exiting 1?
<pitti> Riddell, infinity: I didn't follow the qt4 discussion yesterday, did you discuss this any further?
<Riddell> pitti: since everyone seemed to object to qt4 in main for dapper I've not uploaded it
<pitti> well, we have to balance that with the features we lose by not having it
<pitti> Riddell: how much would break without qt4?
<daniels> infinity: ?
<infinity> daniels: Oh, it's a copy and paste of my old code from somewhere else, isn't it?  So it's my fault. :)
<daniels> if [ -d "/usr/bin/X11" ] ; then
<daniels> [...] 
<daniels>   if ! rmdir /usr/bin/X11 2>/dev/null; then
<daniels> [...] 
<infinity> daniels: (Little known fact, "test -d" is true if the target is a directory.. Or a symlink toa directory.
<daniels>     exit 1
<Riddell> pitti: nothing would break, and it is only the calculator program, but it adds some features that people have been asking for (e.g. keypad)
<daniels> infinity: oh my.
<infinity> daniels: So you need [ -d foo ]  && [ ! -L foo ]  or some such.
<daniels> infinity: so I guess -d /usr/bin/X11 && ! -L ... yeah
<pitti> Riddell: do you expect more programs that use qt4 by dapper release? I. e. do you have a similar UVF exception like gnome?
<infinity> I hope xorg doesn't circualarly depend on x11-common at this point, or I'll have to bootstrap this by hand. :)
<infinity> daniels: Uploading fix?
<Riddell> pitti: I don't know of any others that are likely to release qt4 versions imminently and we don't have a UVF exception
<daniels> infinity: s/ing/ed/
<infinity> Spiff
<\sh> Kamion: send via email, (matt and jonathan included)
<infinity> daniels: Oh, that's fortunate.  xorg's build-deps don't pull in a single X lib... Phew.
<\sh> waiting for xorg to be installable again ;)
<daniels> infinity: well, it's just metapackages
<\sh> dpkg: error processing x11-common (--configure):
<\sh>  subprocess post-installation script returned error exit status 1
<\sh> Errors were encountered while processing:
<\sh>  x11-common
<\sh> argl
<Kamion> Mithrandir: I'm just trying to figure out how to transform Linux console maps automatically into something I can use within gfxboot. It's ... not exactly trivial.
<\sh> BREAKMYUBUNTU
<Mithrandir> Kamion: is there a specification for gfxboot maps somewhere?
<infinity> daniels: Yeah, but debhelper's dependencies grow every week. :)
<Kamion> Mithrandir: array of [ scan-code plain-ASCII shifted-ASCII altgr-ASCII ]  (you can leave out ones that are just the same as the US map, although I think that might be too much trouble)
<daniels> shawarma: dude, the exact same issue was just discussed not 25 minutes ago
<\sh> daniels: you mean \sh and yes...
<daniels> yeah, that
<Kamion> Mithrandir: playing with loadkeys -m at the moment
<daniels> i also mean s/minutes/lines/
<\sh> while I wait...I'm watching neal armstrong landing on the moon
<giftnudel> \sh, what's your time now?
<\sh> 13:11 UTC / 14:11 local time
<Mithrandir> Kamion: I guess I should just sit down and write lcxkb, then
<giftnudel> \sh, well the date is surely something * 196?
<\sh> giftnudel: it's named "NASA 50 years of space exploration part 1 :)
<jdub> daniels: xfonts-* to be purged on dist-upgrade - transient package oddness or intentional? (i'm upgrading for now)
<Kamion> Mithrandir: in fact, UTF-8 for each of the plain, shifted, and altgred codes seem to work
<daniels> jdub: uh
<daniels> jdub: unintentional
<daniels> ah, I see
<daniels> transient
<jdub> heh, transient because you're uploading a fixed package? ;-)
<Mithrandir> hooray, most stuff got installable again
<daniels> notice how your upstream is choked right now? :)
<teroedni> will xorgand xorg common work together or are they completely broken apart/ i can see that xorg use 7 and xcommon 6.8:O
<Nafallo> teroedni: since yesterday we have x11-common :-)
<Nafallo> (and since today it works ;-))
<mvo> some change to x-window-system-core made ubuntu-desktop uninstall on dist-upgrades apparently
* mvo looks closer
<daniels> mvo: transient
<teroedni> nafallo:xorg common 7.0 version?
<mvo> daniels: great, so it will be gone with the next upload?
<Kamion> Mithrandir: hmm, I don't think loadkeys -m is good enough - it doesn't output Unicode
<daniels> mvo: yep
<mvo> daniels: thanks :)
<daniels> teroedni: xorg-common, xserver-common, and x-common are deprecated
<daniels> x11-common is the new hotness
<daniels> Kamion: loadkeys -u -m?
<Mithrandir> Kamion: how much would you love me if you had lcxkb before the sprint?
<mvo> it looks like I picked a bad timing for asking for testing on the dist-upgrade process then :)
<daniels> mvo: haha
<teroedni> ohh then im installing the wrong package:/
<Mithrandir> mvo: extreme stress-testing. :-P
<daniels> mvo: it should be gone by the time the dev team meeting's over
<Mithrandir> infinity: the buildds are coping with most of daniels' fallout and it should all stabillise a bit in a little while?
<daniels> pfft, I wasn't even trying
<Kamion> daniels: tried that, it outputs 0x00a4 for Euro
<daniels> Kamion: d'oh
<Kamion> which is the ISO-8859-1 currency symbol, not the Euro symbol
<Kamion> anyone know how the Euro stuff works?
<daniels> 'badly'
<mjg59> Kamion: It's where the Euro symbol is in 8859-15
<mjg59> (In case that's non-obvious)
<Kamion> mjg59: aha
<\sh> hmmm...do i have the imagination, that the ammount of bug reports increased since the merge to malone, or is it fact? 
<mjg59> Why it's outputting in 8859-15, I have no idea
<daniels> \sh: decreased
* Kamion tries something not in ISO-8859-{1,15}
<\sh> hmm..then it's something else...I wonder if I have to adjust my sieve filters
<infinity> Mithrandir: For some value of coping.  I'll be handholding during the meeting.
<Kamion> Christ. loadkeys -m spits out 0xf0a4 for "currency" (U+00A4) and 0x0151 for "odoubleacute" (U+0151)
<teroedni> yea i wish i knew earlier:/ Ive most have the most broken system currently:Evrything was removed:O
* Kamion ponders just ignoring anything not in ASCII
<daniels> teroedni: if you're not prepared to face this sort of breakage, development branches are not for you
<Nafallo> or a bit more careful what you ack for that matter :-)
<teroedni> daniels:I guess im just a little bit suprised/ I am completely broken I havent even got a terminal any longer:P well well :P
<teroedni> daniels:Thanks for the tips :Atleast :I cant be dumb enough to do the same mistake twice:P
<pvanhoof> ow, some x-server related upgrades
<pvanhoof> is it save to upgrade dapper atm? :)
<pvanhoof> safe
<infinity> pvanhoof: No.  Any other questions?
<pvanhoof> :p
<Nafallo> :-)
* Nafallo just removed a bunch of xserver-xorg-{driver,input}-* :-)
<pvanhoof> The following packages will be REMOVED:
<pvanhoof>   ddd libxp6 sun-j2sdk1.5 vncserver x-common x-window-system-core xfonts-100dpi xfonts-75dpi xfonts-base xfonts-scalable xorg-common xserver-common
<pvanhoof>   xserver-xorg
<pvanhoof> is that normal when installing x11-common :) ?
<pvanhoof> or should I wait a few days? ;)
<infinity> pvanhoof: Did you not just ask 15 minues ago if stuff was broken, and I said "yes"?
<pvanhoof> right, I'll wait a few days
<teroedni> pvanhoof:Yea wait ;)
<pvanhoof> :p
<teroedni> Hope i get answer on this:imsorry if im being a pain in the ass
<teroedni> but does the latest build work with x11-common?
<pvanhoof> going to upgrade firefox nevertheless ..
<pvanhoof> :p
<pvanhoof> and the x11 stuff can wait
<infinity> Kamion: Any urge to do a quick cron.daily again, to get us back on track?
<infinity> Kamion: Then I should be able to fix the world during the meeting.
<\sh> hehe
<infinity> Kamion: Err, waiting for everything to hit accepted, of course (so, in 30 seconds or so...)
<Kamion> infinity: running
<infinity> Danke.  You're a lifesaver.
<Kamion> xorg 7.0.0-0ubuntu5 INSTALLED on all architectures
<\sh> "SuperAdam, The Hero Who Fixed the World" ;)
<infinity> \o/
<lamont> tepsipakki: does it mount nfs v3 shares?
<Kamion> well, the big three and ia64 anyway
<Nafallo> again, and again, and again... :-)
<tepsipakki> lamont: yes
<tepsipakki> I've used a patched version for three weeks without problems
<Kamion> Mithrandir: I have what looks like a working console-keymaps-at / loadkeys -m scraper now - it's just a matter of some textual transformations
<\sh> oh I love daniels, kamion and infinity :) 
<Kamion> Dapper status meeting, in case anyone missed it
<Kamion> er, is missing it :)
<Kamion> (#ubuntu-meeting)
<\sh> Kamion: the autosync tool is not switched off by now?
<daniels> jdub: i just committed the fix for your quebecistani craptop to xorg head
<mjr> so, I seem to have heard that dapper would contain some tools for centralized package management, is that so and any links?
<daniels> whois mjr
<mjr> mjr is someone who's doing some lectures on Linux, also Ubuntu, as well as a homebrew centralized package management system for the purposes of transitionin the CS department here to it
<shaya> infinity: thundebird now has its own problem
<shaya> /usr/lib/mozilla-thunderbird/mozilla-thunderbird-bin: symbol lookup error: /usr/lib/mozilla-thunderbird/components/libgfx_gtk.so: undefined symbol: pango_xft_get_font_map
<infinity> shaya: When/how are you managing to get that?
<shaya> just installed 1.5
<shaya> running from command line
<infinity> shaya: Oh, feh.  I haven't upgraded to -0ubuntu2 yet.  Maybe enabling pango broke something internally.
<infinity> I can revert that change for now and deal with it in a week.
<shaya> let me try to build it locally
<shaya> see if it works
<shaya> hmm
<shaya> X is uninstallable right now
<daniels> yes, we know
<shaya> I say this as I can't install the one dep I need to build thunderbird
<shaya> oh well
<infinity> shaya: Feh.  Looks like I'm calling into /usr/lib/libpangoxft-1.0.so.0.1101.1, but not linking to it.
<infinity> GO THUNDERBIRD!
<infinity> Or, go pango.  I dunno who to blame.
* infinity just reverts the pango support for now.
<shaya> so if it's LD_PRELINKED? 
<infinity> I'll sort it out in a week, after I'm back from VAC.
<shaya> enjoy your hoover
<infinity> Yeah, this works fine:
<infinity> LD_PRELOAD=/usr/lib/libpangoxft-1.0.so.0.1101.1 mozilla-thunderbird
<teroedni> i have big problems with network-admin
<teroedni> it often locks using rt2500 driver
<shaya> yes it does
<teroedni> and i want to submit bugs
<teroedni> ahh so it is a known issue?
<teroedni> eg any point in bug reporting on this?
<shaya> infinity: for some reason thunderbird just launched konqueror
<infinity> shaya: Then Konq is your default browser somewhere.
<shaya> hmm
<shaya> x-www-browser
<infinity> That'd be the one.
<shaya> yes
<shaya> figuring this out
<shaya> wondering why
<infinity> Anyhow, pango support reverted and uploaded.
<shaya> oh well
<shaya> I liked the nice fonts
<shaya> :)
<infinity> In a week or so, Tbird 1.5 will get more love and polish.  Right now, I just want it in and more or less functional.
<shaya> so how do I update alternatives manually
<infinity> Pango support will come back when I come back, I just need to fix the bug.
<infinity> With a plane to catch in 3 hours, that's not gonna happen. :)
<shaya> hmm
<shaya> why does firefox have priority of 70 for x-www-browser, but konq 100
<tseng> shaya: because if you install kubuntu-desktop over ubuntu, its assumed that you prefer kde stuff
<tseng> ubuntu = base
<shaya> didnt install kubuntu-desktop
<shaya> just konq
<tseng> so the same thing i just said applies
<shaya> I guess it makes sense
<tseng> feel free to write a patch to read users minds
<tseng> it has to go one way or the other
<shaya> it be nice if there was a debconf message that is normally hidden, but that one can hit on dpkg-reconfigure that could ask about that
<shaya> i.e. assume user wants it
<shaya> but give easy way to change it by running one command and changing it
<tseng> if you were that knowledgeable
<tseng> it wouldnt be a strech to expect you to know 'sudo update-alternatives --config x-www-browser'
<shaya> ah
<shaya> didnt know about config
<tseng> you do now :)
<shaya> just did a --set
<shaya> config seems saner
<shaya> but it doesnt update the slave
<shaya> weird
<shaya> oh well, not going to worry about it right now
<ogra> mvo, want a bug as reminder for the xss issue ? 
<mvo> ogra: thanks
<mvo> I added it to my tomboy notes for the meeting
<ogra> err ...
<ogra> ah, k
<infinity> Kamion: Feel like one more forced cron.daily, just to clear this mess out?
<dholbach> mdz: ping
<mvo> woah, after my dist-upgrade, I have *no* interfaces anymore on startup (not even lo)
<Kamion> infinity: running
<infinity> Kamion: Ping me when it passes apt-ftparchive?
<Kamion> ok
<tseng> mvo: does Detecting Hardware script take forever to run?
<tseng> i think it is rcS.d/S10udev
<mvo> tseng: no, seems to be normal
<tseng> hm mine sits for several minutes than fails
<pitti> hi jdthood, how are you?
<tseng> (i am seeing the same thing about nic modules etc not being loaded)
<tseng> and Keybuk hasnt been here for 2 days
<jdthood> pitti: Doin' fine
<Kamion> infinity: past, in ziyi
* Kamion runs to the school run
<Mez> infinity: any chance of updating enigmail as well as thunderbird please?
<infinity> Mez: Not until I get back from vacation.  The changelog notes where you can get a working enigmail plugin.
<Mez> infinity - already have one :D
<infinity> Mez: Well, there you go.
<\sh> infinity: which country?
<infinity> \sh: Vacationing in London before the sprint(s)
<\sh> infinity: nice :) 
<\sh> Kamion/mdz: do you need more informations about pykde uvf exception?
<mdz> dholbach: pong
<rburton> am i being dense, or is there not a product in malone for xorg
<dholbach> mdz: I just queried you.
<mdz> infinity: I don't object to the renaming of thunderbird, but the timing is awkward
<Treenaks> rburton: there is a product for every small subsystem :)
<mdz> \sh: I've only just begun email for this morning
<rburton> Treenaks: the only driver i can find a product for is synaptics
<Treenaks> https://launchpad.net/distros/ubuntu/+source/xserver-xorg-driver-ati/ works fine too
<rburton> ok, i'll go via distros in the future
<Nafallo> infinity: YAY! linuxdcpp switched to cdbs! :-D
<Nafallo> that means scons in not a problem anymore, right? :-)
<\sh> mdz: ok :) 
<janimo> jdub, is changing reply-to settings on lists.u.c prohibited? I change it for xubuntu-devel but w/o any error it just sets it back to default
<janimo> by popular request I want to set it to reply to list insted of poster
<Treenaks> we need better mail clients
<janimo> webmail mostly
<janimo> is the cause
<Treenaks> Webmail clients need to get better
<janimo> tell that to google
<mdz> janimo: if the list participants prefer to set reply-to, there's no reason not to do so.  I don't know why changing the setting isn't working for you
<mdz> -users is reply-to, iirc
<janimo> me neither, I just check the box say submmit changes and the radio buttons is the default after page refresh
<jdub> janimo: hrm, i'll take a look
<mdz> Treenaks: there is an X.org project which should group all of the products
<mdz> https://launchpad.net/projects/xorg
<janimo> thanks
<Treenaks> mdz: ah, cool
<Treenaks> mdz: the structure of everything in launchpad is still a bit unclear to me
<Treenaks> even _with_ the new look
<janimo> is soyuz rollout implying world imports will be done in bzr instead of bazaar?
<jdub> oh man
<mdz> janimo: they're unrelated, but yes, afaik the plan is to import to bzr.  #launchpad will know more
<jdub> now the mailman pages are https
<mdz> jdub: can you approve my -devel-announce mail if no one has already?  I have no idea what the admin passwords are anymore
<jdub> janimo: it's something to do with the https setup
<tseng> Treenaks: what new look?
<janimo> jdub, mine or the servers?
<jdub> mdz: ok
<\sh> elmo: I think you missed my sync requests...the last week...ncbi-tools6 and g-wrap from sid, dropping ubuntu changes :) thx :)
<Treenaks> tseng: the one without the tabs :)
<tseng> hm
<jdub> janimo: i assume the server, but firefox has been 'interesting' recently
<tseng> i didnt notice they were missing
<jdub> janimo: hrm, no, i just tried from windows too
<Treenaks> tseng: ('new' being relative, I guess I saw it first in December)
<janimo> jdub, ok then I wait, thanks
<jdub> mdz: the only one there was the ubuntu women mentors post
<jdub> oh, i know what it is
<jdub> Znarl, elmo: who did the mailman https change?
<Znarl> jdub : I did it!
<jdub> Znarl, elmo: the list configurations need to be changed to point to https
<mdz> jdub: was approved already, it seems (UVF)
<jdub> mdz: ok
<elmo> jdub: eh?
<jdub> elmo: currently, the pages are forced to https, but the form is pointing to http
<jdub> elmo: and thus, not working
<Znarl> Ah, yes.  Good point.  Will change that jdub.
<elmo> jdub: only the admin pages are forced, and they work for me?
<jdub> elmo: definitely don't work for me - try changing config
<jdub> Znarl: thanks
<elmo> hang on tho, if we change this, doesn't it change for everyone?
<elmo> like will it affect the listinfo pages?
<elmo> because if it does, we need to get a proper cert for l.u.c
<jdub> oh, you only want to force it for admin/login?
<elmo> anyway this is way -ECHAN
<jdub> hold on
<jdub> proper cert?
<jdub> since when has that stopped us? :)
<Nafallo> lol
<\sh> elmo: thx :)
<\sh> Kamion / mdz: short update to the UVF exception report of pykde..it doesn't break anything. 
<siretart> elmo: I think some sync request got lost somehow: please sync the following packages from unstable, ok to drop ubuntu changes: wmfire xmms-jack, sdcv, arson, dx. Thanks in advance!
<\sh> oh wow...mark met my favorite indian ubuntu women contact :)
<jsgotangco> :D
<\sh> which is really great :) 
<Kamion> mdz: yeah, I did a pass over u-d-a moderation this morning
<seb128> elmo: is there a place where we have informations like why python-musicbrainz has been dropped?
<Mez> jdub: ping
<elmo> seb128: it wasn't built from source
<elmo> and no, right now, the removals file isn't public
<elmo> so for now, ask any of the 5+ people with logons to jackass
<elmo> and then wait for the new soyuz world order
<WaterSevenUb> pitti, quick question... are breezy langpack updates still planned before dapper?
* pitti waves hands and looks at carlos 
<WaterSevenUb> :)
<dilinger> ugh
* dilinger looks at gajim in breezy
<dilinger>  /usr/share/gajim/COPYING?  no copyright file in /usr/share/doc/gajim?  /usr/share/gajim/src?
<\sh> Launchpad ... The Final Frontier..we are writing the year 2006 ... These are the adventures of the spaceship Ubuntu
<\sh> dilinger: what?
<\sh> dilinger: lemme check
<carlos> WaterSevenUb, pitti I will try to provide pitti with updates for tomorrow
<\sh> argl...
<carlos> so the answer is yes ;-)
<\sh> pykde is just building and blows my machine
<pitti> carlos: yay, that would be a good time to build new langpacsk
<pitti> current ones are scary (seb128 will certainly agree)
<\sh> dilinger: latest gajim upload?
<Riddell> \sh: blows?
<seb128> pitti: yeah, I was going to ping you, stuff like xchat-gnome have no translation atm :p
<\sh> Riddell: yeah...increasing the cpu load to 99 ,)
<WaterSevenUb> carlos, hhmm... shouldn't this be announced beforehand such that translators ultimate things? My understanding is that we are talking about first breezy langpack updates in locale, if not all...
<WaterSevenUb> in some locale....
<pitti> mvo: is there a reference bug for 'lo' not being ifup'ed? I have a dup for that
<carlos> WaterSevenUb, well, we still have some problems with its generation
<\sh> dilinger: ok COPYING is easy to fix...the rest is quite ... not really complicated, but complicated
<pitti> seb128: hm, half of my dialog boxes are not translated any more either 
<carlos> WaterSevenUb, we will do the announcement when we are able to give concrete dates
<dilinger> \sh: i may just end up packaging it properly
<dilinger> \sh: if i use it.  i've been working on a jabber client in ruby, using glade
<dilinger> this seems very similar, though
<seb128> pitti: right, that too
<\sh> dilinger: let me check why the python stuff is in /usr/share/gajim/src it can be, that upstream has a bug there...
<WaterSevenUb> carlos, as you said tomorrow you will give pitti updates I understood you were rolling out the tarballs tomorrow :)
<mvo> pitti: I havent found one yet
<dilinger> \sh: not sure what python policy is for that, but i would imagine the stuff in src should go in /usr/lib/python*/gajim, and the stuff in data would be in /usr/share/gajim
<pitti> mvo: ok, then I'll bless this one as a reference bug. Shall I assign it to Scott?
<pitti> mvo: (you seemed to have suffered from this a lot, that's why I ask you)
<carlos> WaterSevenUb, yes, that's the plan but if we announce it today, is useless as people is not going to have enough time to do useful updates
<carlos> WaterSevenUb, the idea is to get this fixed as soon as possible and running on concrete dates
<\sh> dilinger: it should and I apologise for not seeing this..but I'll take care...and bug upstream if this is something serious (and fixing it now for ubuntu)
<pitti> WaterSevenUb: well, once this works, we can release updated langpacks more often
<carlos> so people knows, for instance that every 1st of month we do a roll out
<\sh> dilinger: only for the record, gajim in is the same layout
<dilinger> \sh: yea, i figured it was just the case of someone leaving the default layout
<mvo> pitti: I think scott is the right person, can you subscribe me to it as well please?
<pitti> sure
<WaterSevenUb> pitti, carlos, ok... great :) announce as much as you can even when it's too late in any case :)
<\sh> dilinger: it's even in upstream makefile...I'll fix this now and check if I need to fix upstream sources as well *gnarf*
<\sh> uh nasty
<\sh> cd /usr/share/gajim/src in /usr/bin/gajim *grr*
<dilinger> haha
<dilinger> nice
<dilinger> i checked to see whether it was a symlink
<dilinger> didn't think to look at the actual script
<bedo> Hi all
<\sh> just branching 0.9.1 and *censored* fixing it completly
<bedo> I'm trying to boot a self-made ubuntu distro, based on breezy, with a self-made preseed. It's going well, when it gives me an error like: check target/var/log/bootstrap fo details. But tjis file dowsn't exist! Any hints?
<Kamion> bedo: it's probably /var/log/messages in breezy, apologies for the error getting out of sync with the code there
<Kamion> in dapper everything the installer says will just be in /var/log/syslog; they were still a bit split out in breezy
<bedo> so i've to check what's wrong in /var/log/messages?
<ogra> often its enough to use tty4, did you look there for errors ?
<bedo> i'm looking
<bedo> i'm writing from another pc so i can try my iso "live" :)
<Diziet> Is there anyone whose toes I'd be treading on if I just fixed the m-f-locale-* conflict by editing m-f-locale-all ?
<Diziet> I think I have the right dhange.
<Diziet> s/dha/cha
<bedo> chroot: cannot execute mount: No such file or directory
<bedo> now i'm looking for the packages i've made myself, there can be something wrong :)
<bedo> Maybe :)
<Kamion> Diziet: I doubt it
<Kamion> bedo: you tried to chroot before the base system was installed, probably
<Kamion> ogra: /var/log/messages is displayed on tty3, not tty4
<ogra> oh, sorry
<Kamion> /var/log/syslog goes on tty4, but in breezy debootstrap output was not sent to syslog
<Kamion> but in any case I normally find nano -v to be more useful even for /var/log/syslog, as you can search and scroll
<ogra> i really miss ping in the installer
<Kamion> the scrolling output on tty4 is useful if you're watching a long process go by and something's wrong with the status bar
<Kamion> er, progress bar
<bedo> In the installation phase it can't download some files
<bedo> so the base system couldn't load
<Kamion> bedo: which?
<bedo> which files? many
<bedo> link libs
<bedo> like libs sorry
<Kamion> bedo: perhaps your mirror or network is broken
<\sh> dilinger: I fixed it now for the installation things...but I have to bug upstream because there is a glitch in their logic :)
<bedo> i'm installing all with CDs
<ryanpg> this may be considered a "support" question by some but... is there any reason to upgrade current dapper from the flight 3 cd? 
<mvo> ff is a bit crashy today? (on amd64)
<\sh> dilinger: and thx for finding this issue :)
<\sh> mdz: thx for the approval
<\sh> btw...
<\sh> short and easy question: regarding the uvf announcement, autosync should be stopped, right?
<pitti> \sh: isn't it?
<Mithrandir> Diziet: what's the status of the "fix firefox version number" issue?
<\sh> pitti: I had some autosyncs now in my autosync folder from 16:24 DCT
<bedo> Solved!
<bedo> the problem was the wrong path in the Packages file
<bedo> :)
<dilinger> \sh: np, thanks for fixing it
<dilinger> \sh: does it pass lintian checks?
<\sh> dilinger: I can't tell...will see later when I build it :) I have to wait for my final pykde test build :)
<Diziet> Oh, FFS.  m-f-locale-all has what should be an FTBFS but it doesn't notice due to lack of set -e.  I added the set -e because it blundered about at me and that's why my build is broken now.
<Diziet> And I have no idea how it was supposed to work or anything.
<Mithrandir> Diziet: I read that as "I'm working on it".  Thanks.
<Diziet> mithrandir: You're welcome.
<pitti> Diziet: I'll take a look at it
<pitti> Diziet: if you give me the details?
<Diziet> You sure ?
<pitti> Diziet: well, I consider -all largely my task/fault
<Diziet> I'll email you a diff.  Apply it to your package, run debian/rules update-debian-files, run debian/rules build, it bombs.
<pitti> (unless you want to fix it, that is :) )
<Diziet> No, I don't want to fix it if you can tell what the problem is :-).
<pitti> Diziet: ok, that sounds good
<pitti> I'm not aware at all about problems in update-debian-files so far
<pitti> (apart from the fact that it's utterly hackish, of course)
<pitti> but I didn't bother changing it too much compared to Debian
<pitti> since I hope that we can eventually drop it completely
<\sh> ok...while pykde is building I should go shopping
<Diziet> Yes, it's not u-d-f that's going wrong.  It's giving me an error:   unzip:  cannot find or open chrome/bg-BG.jar, chrome/bg-BG.jar.zip or chrome/bg-BG.jar.ZIP.
<Diziet> but I'm pretty sure I'm only seeing it because I added some set -e's.
<Diziet> YHM
<Diziet> The diff has my fix for the firefox version screwup, and the set -e's.  See the debian/changelog, which I edited accurately.
<Diziet> my fix for the firefox version screwup> which I _think_ I have right but I was going to do a test build and then tripped up, as you see.
<dilinger> isn't today upstream version freeze?
<Kamion> dilinger: yes, there's a mail on -devel-announce about it
<mdz> fun, gnome-terminal just freaked out and is spinning on the CPU. anyone else see this?
<pitti> mdz: hm, mine just doesn't start any more from time to time
<mdz> mine is running, but won't redraw or anything
<Kamion> it does that for me on the live CD from time to time, but I'd put it down to a mad live CD or unionfs bugs or something ...
<mdz> strace shows no syscalls, gdb backtrace is garbage
<Kamion> oh, in my case it's when I'm trying to start it before the window appears
<dilinger> mdz: ltrace?
<mdz> nothing, seems to be in a tight loop somewhere
<mdz> dunno why gdb gives only '??', not even any symbol names
<Kamion> smashed stack?
<mdz> apparently, but it changes as it sits and spins
<mdz> oh well, killing it
<pitti> Diziet: btw, I just made a very interesting discovery: if I start firefox without a ~/.mozilla, it crashes; but if I ssh -X test@localhost and start firefox as user test (without .mozilla again) it works
<seb128> mdz: no bug about that and it works fine for me but I've not updated to today new version
<dilinger> ah, what the hell
<mdz> seb128: neither have I
* dilinger upgrades to dapper on his laptop
<mdz> seb128: I'll call it sunspots unless I see it again
<seb128> ok
<seb128> quick questions guys, slomo has prepared a xine-lib for main without patented codecs, would you keep naming the binary package libxine1c2 ?
<seb128> or libxine-main and have a libxine-universe and libxine Depending on both to not drop feature silently?
<pitti> so we still need it for main at all?
<seb128> we said we would evaluate both
<pitti> otherwise, your second solution seems correct if the new libxine1c2 is in universe
<seb128> so have a xine and a gstreamer totem for main
<pitti> 'k
<seb128> pitti: yeah, but anyway we will have to rebuild stuff with libxine-main so it doesn't work :/
<pitti> the rdepends list is not too scary, so we can do the transition for main
<pitti> universe/multiverse packages are certainly fine to depend on libxine1c2
<seb128> right
<\sh> another transition?
<seb128> small one
<pitti> seb128: amarok kaffeine kdeaddons kdemultimedia totem
<bddebian> Hello
<seb128> pitti: in fact no need to rename for that
<\sh> what about universe ?
<pitti> seb128: why not?
<seb128> pitti: we can keep libxine1c2 and add a Depends on libxine-extracodecs for universe package
<seb128> pitti: what advantage do we have to rename libxine1c2 to libxine-main?
<janimo> mdz, can you promote the xfce packages pitti reviewed for main if not all their dependencies are approved yet?
<mdz> janimo: not really; that would make them uninstallable
<pitti> seb128: ok, the extra depends WFM, too
<pitti> janimo: what's still missing?
<janimo> mdz, ah ok I'll remove the deps from xubuntu-meta then
<janimo> pitti, some panel plugins
<pitti> packages you don't consider ready for release yet?
<janimo> some still don;t come from debian as they are not uptodate yet
<seb128> pitti: we have to transition anyway, better to keep libxine1c2 for main, create a new libxine-extracodecs and make universe packages Depends on it ... what do you think?
<janimo> oh, they are ready for release but may be hairier for you to review :)
<janimo> but ok I'll give you a list
<pitti> mdz: btw, janimo and I talked about langpacks for xubuntu; they are small enough to not justify split out packs
<janimo> pitti, I shall add them to the queue then ok?
<pitti> seb128: sounds sane; indeed there even are fewer universe packages that use libxine than main ones :)
<Kamion> janimo: getting anywhere with the cdimage/debian-cd hacking for xubuntu?
<pitti> janimo: yes, please write any concerns about maturity into the reports
<janimo> Kamion, had no time yet sorry
<Kamion> np
<seb128> grumpf, gnome-session hacking ...
<seb128> re :)
<janimo> will look at it once things are in main
<Kamion> not like I've had time either
<\sh> seb128: giving the motus more work? ,)
<bddebian> Heh
<janimo> pitti, they are mature just not from the same upstream, they are community plugins. I'll make a short list and drop the rest from xubuntu-desktop for now to keep it safe
<seb128> \sh: rebuilding 5 packages to put a Depends on a new package ... really few work, that's like 10 min for slomo
<\sh> seb128: hehe...it's less :)
<ulaas> x is ok now?
<pitti> Diziet: bwah, heisenbug. 'firefox' segfaults, but "firefox --debugger 'strace -o /tmp/ffox.strace'" works like charm of course
<Diziet> Nice.  i386 ?
<pitti> amd64
<Diziet> Um, which version ?
<ulaas> safe to upgrade now?
<pitti> so it works as user 'test' without debugger, and as 'martin' with debugger, and crashes as 'martin' without debugger. go firefox
<pitti> 1.4.99+1.5rc3.dfsg-1ubuntu4
<pitti> and gdb doesn't help at all
<Diziet> That's quite old really.  I think we should concentrate on fixing the FTBFS and see if it still does it in the 1.5 release version.
<Mithrandir> uh, where has my applications, system and places menu gone?
<Diziet> I had them for lunch.  Sorry.
<Mithrandir> seb128: is ^^ a known bug?  I haven't removed them.
<Mithrandir> bad Diziet!
<elmo> ok, guys, I think I'm caught up on syncs
<seb128> Mithrandir: nop, not known
<pitti> \o/ thanks elmo
<elmo> if you haven't seen your sync on dapper-changes, and the source isn't in the archive, please reping me about it
<ogra_> only 40 ? 
<siretart> thanks elmo!
<Diziet> syntax error at -e line 3, near "while"
<Diziet> syntax error at -e line 7, near "}"
<Diziet> Execution of -e aborted due to compilation errors.
<Diziet> make[4] : Nothing to be done for `export'.
<Diziet> And then it just carries on.  ?!
<seb128> Mithrandir: is your panel frozen?
<bddebian> 'bout time elmo
* bddebian hides
<Mithrandir> seb128: unsure.  It fixed itself when I killall-ed it.
<Diziet> pitti: Did that diff look sane to you ?  Was I right about it being broken before I got to it ?
<bddebian> martink == madduck?
<pitti> Diziet: didn't look at it yet, sorry; I'm trying to chase this crash
<seb128> Mithrandir: let me know before killall it it that happens again :)
<Diziet> pitti: OK.
<martink> bddebian, no
<Diziet> Re the crash: did you already move ~/.mozilla aside ?
<bddebian> martink: Ah, OK, sorry
<Mithrandir> seb128: willdo
<pitti> elmo: could you already process the removal and backport requests, too?
<elmo> pitti: I did, AFAIK
<pitti> Diziet: yes (as I said above)
<pitti> great, thank you
<bddebian> Sorry to ask in here but does anyone know how to crack a bios password on a ThinkPad R31 without the security chip replacement thing?
<janimo> hmm at least xfprint, xterminal and xffm4-icons are still in http://archive.ubuntu.com/ubuntu/pool/universe/
<mdke> elmo, any chance you have a minute or two to talk about the docteam svn server?
<pitti> janimo: true, AFAICS only the non-arch-all debs were removed
<dilinger> oops, maybe i should've waited
<pitti> janimo: on, rather, did xfprint ever built at all?
<janimo> only debs not sources too?
<dilinger> looks like libapt broke
<Diziet> pitti: Oh, err, so what's different about `martin' ?
<pitti>    xfprint | 4.2.1-1ubuntu2 | breezy/universe | source
<pitti>    xfprint | 4.2.1-1ubuntu2 | dapper/universe | source
<pitti>    xfprint | 4.2.1-1ubuntu2 | hoary/universe | source
<janimo> in hoary we useed it
<janimo> but in breezy got superceded by xfprint4
<pitti> Diziet: that's what I'm asking myself, too
<Kamion> right, this officially rocks
<pitti> Diziet: I'm in more groups
<Kamion> complete conversion of console-keymaps-at into gfxboot keymaps and a working keymap menu
<pitti> Diziet: does ffox read gconf or anything like that? or just .mozilla?
<pitti> Diziet: but if it would depend on the state of some files, then it shuold fail under strace as well *headdesk*
<Kamion> even the French keymap works
<pitti> Diziet: (did I mention that firefox -g works as well?)
<Diziet> pitti: I couldn't say, I'm afraid, what ff reads.
<pitti> Kamion: you better make sure, otherwise your panel will break in interesting ways :)
<Kamion> FSVO "works" that means "does mad azerty things"
<Diziet> But yes, since the new mime handling I think it uses gconf.
<Diziet> That is, it calls some gnome mime library which might well look at gconf data.
<janimo> elmo, please sync/override xfmedia and if possible change my sync notification address from email.ro to jani@u.c . thank you
<ogra_> elmo, scim is missing from the syncs i think, should be at 1.4.4-1
<pitti> Diziet: hm, moving aside .gnome2 doesn't help either
<elmo> janimo: xfmedia is broken, different orig.tar.gz in Debian and Ubuntu, I can't sync
<janimo> oh, weird
<janimo> never mind than, sorry
<elmo> janimo: changed your email
<janimo> thanks
<elmo> ogra_: what's minghua's name?
<elmo> name + email
<ogra_> Ming Hua <minghua@rice.edu>
<Diziet> pitti: When you try it as test, do you run it as test displaying to your own display, or in a test login session ?
<pitti> Diziet: in my own display
<Diziet> You could move aside ~ I suppose.
<pitti> $ gdmflexiserver
<Kamion> the only problem with hacking on keymap support is that sometimes I'm left going "WHERE DID MY DOWN KEY GO?"
<pitti> Segmentation fault
<pitti> bwah
<pitti> Diziet: my whole ~? Sure
<ogra_> just make sure to have all commands you'll ever need in your history ;)
<pitti> Diziet: I'll try it in a separate display if that helps
<pitti> seb128: confirmed, new gdm fixes gdmflexiserver segfault
<seb128> pitti: cool, thank you
<Diziet> No, if you're already trying it in your display then we know it's not something in your display that's breaking it.  So we're left with permissions or ~.
<Diziet> You could do binary chop on the groups list I suppose.
<pitti> Diziet: ok, that gets some consistency. In complete 'test' session, firefox segfaults, too
<Diziet> Ooo.
<Diziet> But not when debugged, no doubt.
<pitti> Diziet: sure thing
<Diziet> Looks like infinity's workaround for the amd64 FTBFS works.
<Diziet> Do you fancy trying ronne:~iwj/firefox-4u2/firefox_1.5.dfsg-4ubuntu2_amd64.deb ?
<pitti> sure
<pitti> btw, ssh -X martin@localhost from the 'test' session segfaults
<pitti> so it's not overly consistent
* pitti downloads new crack
<ulaas> is common remove safe?
<ulaas> is xcommon remove safe?
<pitti> Diziet: btw, how is 1.5.dfsg- >> 1.5.z999 ?
<pitti> and indeed, the newly generated debian/control is seriously screwed
<Diziet> pitti: Eh ?
<pitti> Diziet: it misses all the language names
<Diziet> That's still the old package.  From yesterday.
<pitti> - for Mozilla Firefox (Arabic language, ar).
<pitti> + for Mozilla Firefox ( language, ar).
<Diziet> Oh, sorry, you're talking about m-f-l-a.
<pitti> yes, sorry
<Diziet> 1.5.dfsg- isn't supposed to be >> 1.5.z999.
<pitti> oh, sure, Conflicts:. My bad
<pitti> ok, I'll figure out what fails in debian/rules and try to fix it
<Diziet> It manages the language names here.  You mean my change around CURLANGXPATH ?
<Diziet> I just added that because if you say    xpath yada yada | sed yada yada   and xpath isn't installed, it just blunders on without noticing.
<pitti> Diziet: AFAICS you just split the command, right?
<Diziet> Because    false | true   ==   true
<Diziet> Yes.
<pitti> yes, I understood it that way
<pitti> maybe it's easier to check for which xpath at the start and exit 1 if not, but it should work under -e
<Mithrandir> or use bash and PIPESTATUS
<Diziet> There's a set -o you can say with modern bash, too, to make    false | true  ==  false.
<Mithrandir> pipefail
<pitti> Diziet: meh, new ffox requires a new libnspr4, too
<Diziet> Yes, 'fraid so.  But that's probably fairly painless.
<Diziet> Just get the whole lot and dpkg -iGROEB
<pitti> sure
<Diziet> Amazingly the new nspr has not been _too_ bad.  Just a few more obscure things broke.
<dilinger> how come there's no gstreamer0.10-plugins-bad ?
<dilinger> there's -good and -ugly
<pitti_> yay, go network
<pitti_> Diziet: still segfaults :(
<Diziet> Damn.
<Diziet> Does it do it if you debug it, now ?
<Mithrandir> Diziet: hmm, firefox builds fine in dapper for me..
<Diziet> mithrandir: amd64 ?  fakeroot ?
<Mithrandir> Diziet: yes
<Diziet> The amd64 FTBFS is a fakeroot bug.  Hmm.  How interesting.
<Diziet> And does it run ?
<Mithrandir> Diziet: no idea yet.  I'm just wondering why it ftbfs on the buildds.
<Diziet> I reproduced the FTBFS on ronne's dapper chroot.
<Diziet> ronne:~iwj/firefox-4u2/firefox-* is the build tree.
<Diziet> (after I applied infinity's suggested workaround)
<Diziet> (ie, it FTBFS, I applied the workaround, then it built; that tree is the finished build)
<Mithrandir> Diziet: it segfaults if I run it with the wrapper script, but works if I do LD_LIBRARY_PATH=bla /usr/lib/firefox/firefox-bin -a firefox
<pitti> Diziet: same behaviour still
<Mithrandir> Diziet: turning off the esddsp thing makes it not crash on startup
<Diziet> mithrandir: Oh!  Can you get the wrapper script to print out the environment and figure out which variable is ....
<Diziet> ... ah.
<Diziet> Is there flash involved here at all ?
<Mithrandir> Diziet: (confirmed with changing auto to none in /etc/firefox/firefoxrc)
<Mithrandir> on /usr/share/ubuntu-artwork/home/indx.html?  I hope not.
<Diziet> Right :-).
<pitti> Diziet: not at all
<Diziet> Just checking you hadn't got a different start page or anything.
<Mithrandir> anyway, there's no 64 bit flash plugin available so it wouldn't have ran.
<Diziet> I'm starting to run short of time if I want to get an upload out today.
<Diziet> So I think I'll have a quick look and if I can't see it straight away I'll just disable the esddsp option on amd64.
<pitti> Diziet: Mithrandir hit the nail - changing auto to none fixes the crash
<Mithrandir> if you change the default to "none" on amd64, nobody will kill you, I suspect.
<Diziet> For now anyway.
<pitti> Diziet: yes, we want alsa anyway
<Diziet> Do we ?  I know naaathing.
<pitti> esd == the suck
<ogra> hrm ...
<pitti> ... for !ltsp
<pitti> anyway, nice to have this workaround
<pitti> Mithrandir: however you found that out, you rock :)
<Diziet> What's this about ltsp ?
<pitti> Diziet: ltsp needs esd for remote audio
<pitti> alsa itself doesn't support network audio
<Diziet> Ahm.
<pitti> but in Ubuntu proper we don't use esd by default any more
<pitti> it's still there for the apps that want it, though
<Mithrandir> it's a crash in libesddsp.so, I suspect.   I need a debugging version, I think.
<Diziet> Maybe ltsp should set FIREFOX_DSP=esddsp ?
<pitti> Mithrandir: this rings a bell
<Diziet> Well, I'll change the default on amd64 for now.
<pitti> Mithrandir: I had a similar esd bug ages ago that mystically disappeared under strace
<pitti> thanks
<Mithrandir> pitti: I can reproduce it with gdb, so..
<pitti> oh, it works fine under gdb here
<pitti> as it does with strace
<pitti> which is really annoying if you want to find the reason
<Mithrandir> pitti: if you LD_PRELOAD /usr/lib/esound/libesddsp.so.0 too?
<Diziet> Can I select on uname -m output or should I make it depend on the build architecture ?
<Mithrandir> Diziet: use the target architecture from dpkg-architecture.
<Mithrandir> so cross-compiles (hahahha) will work.
<pitti> Mithrandir: indeed, then it crashes
<Diziet> mithrandir: YM dpkg --print-architecture I take it.
<pitti> Diziet: is there a reason we would ever want to use esddsp at all?
<pitti> Mithrandir: doesn't that use the OSS interface?
<Mithrandir> Diziet: dpkg-architecture -qDEB_BUILD_ARCH is what I meant, I think.
<Diziet> pitti: I have no idea really what esddsp is.
<pitti> oh, wait, the other way orund
<Mithrandir> pitti: it means flash doesn't hog the sound device.
<pitti> it emulates an OSS interface through esd
<Mithrandir> pitti: yes.
<perofal> if I want to help is not important if I use amd64 vercion or 386 one?
<pitti> ok, then disabling it on amd64 is no big deal since there is no flash plugin anyway
<pitti> perofal: does it crash for you as well?
<pitti> perofal: Mithrandir and I am on amd64
<pitti> s/am/are/
<perofal> I havent installed it yet
<perofal> downloading the fight 3 cd right now
<perofal> :(
<perofal> I am have downloaded the 386 vercion
<Mithrandir> bingo, the fault is in libesd somewhere.  I get mplayer to segfault too.
* Mithrandir rebuilds with -g.
<Mithrandir> (why on _earth_ isn't that in the default cflags?)
<perofal> pitti : the amd64 is broken?
<pitti> CONFIG_OPTS+= --enable-debugging
<pitti> Mithrandir: ^ doesn't that suffice?
<Mithrandir> apparently not.
<pitti> Mithrandir: oh, no, I see - CFLAGS="-O2"
<Mithrandir> pitti: anyway, works with -g :-(
<pitti> yay heisenbugs
<bddebian> heh
<Mithrandir> no, I'm lying.
<\sh> bah...whoever said, that concatening source files is better for the compiletime...I shoot him
<Mithrandir> esddsp isn't thread-safe.
<wasabi> My car got stolen. =(
<\sh> wasabi: damn...
<dilinger> whee!
<dilinger> can't install xserver-xorg, the kernel likes to hang when doing network related stuff..  good times
<tseng> dilinger: happy UVF
<bddebian> tseng!!
<dilinger> UVF?
<tseng> bddebian: dude!
<tseng> dilinger: version freeze
<dilinger> ah
<dilinger> hehe
<tseng> dilinger: when we theoretically stop breaking things in horrific ways
<bddebian> tseng: How you been?
<tseng> bddebian: good, you
<dilinger> it's a good thing i didn't intend to actually do any real work today
<bddebian> Busy and frustrated :-(
<pkern> Hi. How is the outer mixer in Gnome called (the one controlled by media keys)? I need it to look for/to file a bug about the mixer not using the correct sound card specified in Preferences > Sound.
<tseng> pkern: the media keys normally control Master mixer
<tseng> so does the mixer applet
<pkern> tseng: The mixer applet is configurable. The other mixer is not.
<tseng> im aware
<pkern> tseng: It controls the wrong master, despite playing system sounds on the correct soundcard.
<tseng> there used to be a gconf folder for acme
<tseng> not now, it seems
<tseng> acme being the standalone version of multimedia key grabber before it was integrated into gnome-control-center
<tseng> there was a bit of namespace sharing for awhile
<shaya> anyone know why evolution is asking me to unlock my secret key?
<Treenaks> to get to your email password?
<shaya> why?
<shaya> it stores it in gnome keyring now?
<shaya> so every time I use evo its going to ask me at least once?
<tuhl> hi
<tuhl> any beagle guys online?
<tseng> you could try asking your question
<shaya> except, I dont know what password it wants
<tuhl> best does not start in upstream
<tseng> it works better.
<shaya> not my gnome keyring password
<tseng> "in upstream?"
<tuhl> best
<tuhl> Unhandled Exception: System.DllNotFoundException: libbeagleuiglue
<tuhl> in (wrapper managed-to-native) Beagle.Util.GeckoUtils:blam_gecko_utils_init_services ()
<tuhl> in <0x00007> Beagle.Util.GeckoUtils:Init ()
<tuhl> in <0x0006c> Best.Best:Main (System.String[]  args)
<tseng> dont do that please
<tuhl> tseng: sorry
<tseng> now please start at the begining
<tseng> you built beagle from source?
<pkern> tseng: gnome-volume-control, thanks (=
<pkern> tseng: Within /apps/
<tuhl> tseng: no by installing packages
<tseng> so why did you say upstream
<tseng> pkern: erm theres nothing in there :)
<tseng> pkern: or i would have pointed you straight to it
<tuhl> tseng: people told me that dapper is (upstream :-))
<tseng> uh
<pkern> tseng: I've got "active-element" with the name of the wrong sound card.
<tseng> tuhl: than people are making stuff up.
<tseng> anyway the beagle package is pretty broken
<tseng> pkern: huh, just window_{height,width} here
<tuhl> tseng: beagle-query works
<tseng> ok well best uses firefox to render html snippets
<shaya> Treenaks: never mind
<shaya> I'm an idiot
<shaya> somehow pgp got checked
<tseng> it needs rebuilt against the latest firefox
* shaya butts his head against a wall
<tseng> among other things
<shaya> that dialog should be clearer: "PGP Signing: Trying to unlock key for ...."
<elmo> mdke: grr
<\sh> oh damn...
<elmo> mdke: hint, IRC is a lossy medium, don't use it to chase people
<pkern> tseng: That's in the ui folder below. But then I haven't yet checked if it worked. It's a breezy->dapper dist-upgraded install anyway. On breezy it did indeed work with the right sound card, on dapper it did not.
<tuhl> tseng: who will recompile it?
<mdke> elmo, right. I can mail you, or you can reply directly to my mail to -devel today
<elmo> mdke: or you could have mailed in the first place
<mdke> elmo, since I didn't, I can do it now
<elmo> mdke: instead of uselessly pinging repeatedly on IRC, which I only just saw as I was going through the sync backlog
<elmo> mdke: doing it now isn't remotely helpful after you've just complained loudly to the world
<mdke> elmo, it's not a private thing, nor is it a blaming thing. I just want to discuss it
<elmo> mdke: no you want to complain
<mdke> elmo, I don't, I want a solution
<mdke> i wouldn't complain, I'm not paying anyone to do anything for me
<elmo> mdke: you're either delusional or being dishonest
<elmo> if you don't see how your post amounts to complaining and not very usefully at that
<mdke> i disagree
<mdke> the system doesn't work, i wanted to ask if there is an alternative system
<tuhl> will we see ekiga in dapper?
<elmo> the system demonstrably does work because you're using it
<elmo> changes don't happen as fast as you'd like
<elmo> which I accept, but when you can't even be bothered to ping us over anything but IRC I have very little sympathy for you complaining like this
<mdke> elmo, right. There's no point arguing about the definition of "work" because it depends on your point of view
<mdke> elmo, i've sent about 5 mails to RT
<elmo> no you haven't
<elmo> I just checked
<mdke> before and in between pinging on irc
<mdke> ok, they are not arriving then
<elmo> there are two tickets open, and one of them has the initial mail and a ping
<elmo> and the other has the initial mail
<elmo> well that's convenient isn't it
<mdke> meh
<mdke> you're too excited about this, i just want a solution
<slomo_> tuhl: afaik yes... dholbach wanted to do it
<elmo> I'm not even remotely excited about this, trust me
<mdke> elmo, ok, so let's stop looking for blame
<elmo> mdke: too late for that after your useful post
<elmo> but thanks for playing the "I wasn't trying to blame anyone" game
<mdke> elmo, i said in my mail that the reasons the system is slow are perfectly understandable. I can't be more clearer than that.
<Diziet> seb128: ping
<mdke> gah, "more clearer"
<Diziet> seb128: Did you say you'd rebuilt yelp to work with recent ff ?
<seb128> Diziet: pong, dholbach was on it (and doing a new version too)
<Diziet> Oh, right.  So it's not known to work atm ?
<dholbach> Diziet: Is it on AMD64 already?
<Diziet> The new ff ?  It will be on ff as soon as I upload it.
<dholbach> s/it/a new working version
<dholbach> ah right.
<Diziet> But I promised seb128 I'd test my upload with yelp.
<dholbach> Well the thing I build yesterday evening was crashy.
<Diziet> And currently it doesn't (on i386, that is).
<dholbach> Horrible on AMD64, not-really-usable on i386.
<Diziet> crashy on amd64> We think that's an esd problem - see scrool.
<Diziet> Oh, you mean yelp was crashy ?
<dholbach> Yes, the new one.
<dholbach> I can upload a package to rookery, if you want to play with it.
<Diziet> Oh.  Well on my testbed it fails to find libgtkembedmoz.so.
<dholbach> (the new one that is)
<Diziet> No, I just want you to say you don't mind if I upload my latest ff even though yelp doesn't work with it.
<Diziet> The previous ff doesn't work with yelp either.
<Diziet> That is, with yelp from current dapper.
<dholbach> Diziet: Go ahead, I will retry then.
<Diziet> OK.
<dholbach> Cool, I'll keep you updated.
<janimo> Znarl, re the https lists.u.c that jdub brought up earlier
<Znarl> janimo : Yes?
<janimo> anything holding it up?
<janimo> it dtil doesn't work here
<janimo> still
<pkern> tseng: You were right. There's no schema for it in gconf, just the value.
<pkern> And gnome-volume-properties calls a Removable Drives and Media Preferences window onto the desktop *cough*
<Znarl> janimo : I will let you know when it's done.
<janimo> Znarl, thanks. 
<Mithrandir> ok, I rock.
<Mithrandir> Diziet/pitti: I got firefox working with esddsp
<Diziet> Oh, good :-).
<Diziet> My upload to disable it is on the way :-).
<\sh> I need another beer...
<Mithrandir> Diziet: a trivial mutex around the dsp_init in esddsp.c seems to at least let firefox start.
<Diziet> Excellent.
<Diziet> esddsp.c is in esddsp or in ff ?
<Mithrandir> esound
<Diziet> Right.
<Diziet> Well, I'll revert the disablement next upload then.
<Diziet> I assume you'll upload new esound ?
<Mithrandir> Diziet: either way works, I guess.
<Mithrandir> Diziet: I was going to get pitti to do it, but if he's not responding soon, I'll just do it.
<Diziet> Better to fix it than to disable it I think.
<Diziet> OK.   Whatever you like.  Anyway, it's time I was going.  Thanks for your investigations !
<Mithrandir> pitti: do you want to fix it, or should I just upload the changes I have?
<Mithrandir> Diziet: also, why are you calling configure with --disable-xprint, but build-dep on libxp-dev?
<Diziet> Mistake.
<Mithrandir> ok
<Mithrandir> fixed, or do you want a bug about it?
<Diziet> I've added it to my list (on paper!) here, and will fix it next upload.  No need for a bug unless you feel like it.
<Diziet> Thanks for pointing it out.
<Mithrandir> ok, fine.  Just trying to make it not get lost.
<Diziet> Quite so.
<janimo> Dizier, add the deb on libnss3 on the paper too :) thanks
<janimo> dep not deb
<Mithrandir> I wonder why this dsp bug didn't show itself on i386, though.  Maybe nobody has tried on an SMP machine.
<Diziet> janimo: Already fixed in today's upload.
<janimo> Diziet, ok thanks
<Diziet> mithrandir: Or maybe the race comes out differently.
<Diziet> janimo: NP.  It was on the paper already, you see :-).
<Mithrandir> Diziet: strange that it should be dependent on architecture.
<Diziet> Races are allowed to depend on the phase of the moon :-).
<Mithrandir> well, true.
<Diziet> Anyway, I'm going to stop work now.  Thanks for your help and I'll check scrool tomorrow morning so feel free to `Diziet: ...' things and I'll see them.  Or email me.
<Diziet> Goodnight.
<seb128> Diziet: sorry I was away. Just upload firefox we will manage, thanks for trying/asking before :)
<Diziet> NP
<seb128> see you later !
<janimo> seb128, you mentioned in todays meeting something needed being done to gdm but no time
<zul> hmmm...interesting yelp crashes if i try to go about->ubuntu
<dholbach> janimo: DapperDesktopPlan
* dholbach hugs janimo btw
<dholbach> :)
<janimo> thanks daniel
* janimo hugs daniel
<janimo> and murphy :)
<dholbach> ... sleeping :)
<janimo> dholbach, the GdmRoadmap link is broken on that page, but I read the rest
<dholbach> Yeah
<dholbach> UDU/GdmRoadmap maybe
<ulaas> eieeeeeek. my x screwed. please tell me it is fixed already :)
<crimsun> elmo: please sync xastir from Sid, overriding Ubuntu changes
<dilinger> ah, sweet!  daniels just fixed xserver-xorg
<ulaas> yipppeeeeeeeeeeeeeeeeeeeeeee
<seb128> re
<ulaas> did it hit the servers?
<seb128> janimo: https://wiki.ubuntu.com/DapperDesktopPlan
<dilinger> of course, it still tries to run /usr/bin/X11/X, which doesn't exist
<ulaas> dilinger: oh. nooooo.
<janimo> seb128, and what do you think is the best way to chose different themes depending on ubuntu variant?
<janimo> I see ogra needs such feature and I do too
<dilinger> and xserver-xorg contains /usr/X11R6/bin/X, which is a symlink to /usr/bin/X (which doesn't exist)
<seb128> janimo: making a patch to add a such feature
<dilinger> and i can't message him because this irc network is lame
<ogra> janimo, i think adding a commandline option to gdmsetup or writing a own commandlien binary using the code from gdmsetup to modify the config is the way to go
<ogra> seb128, ^^
<janimo> ogra I thought so too, but it would be maybe better to pass not just the theme but the location of the config file
<janimo> what do you think
<janimo> it would be even better if the gdm.conf file could handle includes
<janimo> so we don't have essentially similar files with just one line changed
<janimo> I though maybe not gdmsetup, but have gdm have the config file name taken form and env var if exists or fall back to the hardcoded name
<janimo> but maybe upstream has a better idea
<ogra> yes thats pretty upstreamish ...
<ulaas> ls
<ulaas> ooops. please fix x. otherwise i will be sending console commands all the time..
<dilinger> ah-ha
<dilinger> cd /usr/bin && ln -s Xorg X
<dilinger> that fixes the broken X symlink issue
<janimo> ogra , gdm --help
<ulaas> dilinger: is it safe when the package gets fixed?
<janimo>  --config=CONFIGFILE     Alternative configuration file
<janimo> we may use this?
<janimo> make /etc/init.d/gdm call gdm with a variant specific config location
<ogra> then you would have to rewrite the initscript i guess
<janimo> sure
<ogra> hmm
<dilinger> ulaas: ?
<pitti> Mithrandir: (sorry, was at dinner)
<pitti> Mithrandir: I don't sit on esound, if you have fixed it, go ahead ;)
<ogra> /etc/default/gdm could carry such a thing
<janimo> or even /etc/defaults/gdm
<janimo> :)
<ogra> :)
<dilinger> ulaas: dist-upgrading to the latest dapper, installing xserver-xorg, and making that symlink makes stuff work for me
<dilinger> where "stuff" is X :)
<dilinger> (gdm)
<ogra> then its an easy scripting task 
<mjg59> Argh why has gnome-power-manager broken again
<janimo> right, no need to bother upstream or add patched
<mjg59> ** (gnome-power-manager:5954): CRITICAL **: HAL does not have PowerManagement capability
<ogra> janimo, lets do it like that ... 
<ogra> mjg59, i didnt upload a new version yet
<janimo> ogra, good, do it and I'll use it too ;)
<ulaas> dilinger: sure man. i just wanted make sure that a when this issue gets fixed that i hope that symlink is safe in case i forgot it  there.
<mjg59> ogra: Does new hal need new g-p-m?
<ogra> mjg59, 0.3.4 is at hughsies desk currently, seems one function he wrote doesnt return from glib
<ogra> it shoudlnt ... but i'm not sure
<mjg59> ogra: Well, it's broken since I upgraded
<mjg59> (With the above error)
<ogra> currently i cant even test, it simply segfaults
<dilinger> ulaas: oh, i have no idea.  i'd like to talk to daniels about it, but i don't feel like dealing w/ freenode registration
<mjg59> ogra: Can you drop back to 0.3.1 and take a look at that?
<dilinger> ah, he's on oftc
<ogra> mjg59, i want it fixed before monday, but i have to go to a conference in about 12h 
<ogra> (and didnt sleep much last night ...) 
<mjg59> Ok
<ogra> i wont be able to look at it before sunday 
<dilinger> wasm
<dilinger> wasn't there some gui wireless access point finder thingy for gnome?  is that in dapper?
<dholbach> network-services? wifi-radar?
<mjg59> dilinger: There's NetworkManager, but since my last dist-upgrade it's started crashing whenever it connects
<dilinger> mjg59: ah.   that doesn't seem to actually do anything for me
<dilinger> oh, nevermind
<dilinger> it did break my /etc/resolv.conf
<dilinger> so it does *something* ;p
<ogra> yeah, thats n-m :)
<mjg59> ogra: Ok, new hal requires new g-p-m
<mjg59> So the one in the archive currently is broken
<ogra> ok
<ogra> but new g-p-m segfaults :(
<ogra> evil situatuion after it worked so nice for so long
<Znarl> janimo : Fixed now.
<janimo> Znarl, thanks
<dilinger> interesting
<dilinger> it does list access points in the pulldown for the wireless card's if properties
<dilinger> well, at least the one essid that's on this floor
<pkern> Who's the Ubuntu contact in the launchpad for confidental security bugs?
<pitti> pkern: me
<pitti> pkern: or, rather, security@ubuntu.com
<pkern> pitti: k.
<dholbach> pkern: In Launchpad bugs can be marked as confidential as well.
<pkern> dholbach: Yep, that's why I needed the Cc address
<dholbach> pitti: <fejj> yea, I'm going to make a 1.5.10 release of g-v-m shortly
<pitti> with that stupid crash fixed?
<pkern> Hm. What's the correct value for "distribution"? It doesn't accept "breezy" nor does the popup find something.
<pitti> dholbach: cool, I already wanted to upload a workaround
<pitti> pkern: Ubuntu
<pitti> pkern: breezy is a release
<pkern> Doesn't work anyway, it bails out. ;)
<pitti> elmo: btw, if you remove a package from ubuntu (like the mozilla-firefox-*), does it automatically land on the sync blacklist?
<LaserJock> the latest xorg updates want me to get rid of vnc4server, will I be able to reinstall it after it is removed?
<pkern> Perhaps anyone could fix mozilla-thunderbird-enigmail, so that people using it could update to 1.5 ;)
<dholbach> pkern: If I understood correctly, infinity wanted to do that once he got off the plan and managed the jetlag.
<pitti> mdz: does syncing a new upstream version from debian fall under 'complete merges' or UVF?
<pkern> dholbach: Fine. Thanks. (:
<pitti> mdz: poppler 0.4.4 integrates the recent security updates and thus allows us to drop the patch
<LaserJock> pkern: the changelog says you can use the enigmail binaries for now
<mdz> pitti: either way, it requires an exception now
<pitti> mdz: ah, I see
<mdz> pitti: if it's a bugfix-only release I'm unlikely to object
<pitti> mdz: I want to do another poppler bugfix, so I need an -ubuntu upload anyway
<pitti> mdz: I'll take a look at the upstream changelog
<dilinger> mjg59: i guess this should be an obvious thing, but maybe i'm hitting a bug or something.. how on earth do you unsuspend an x40? :P
<dholbach> dilinger: press the power button?
<ogra> or attach a 380V powerline, but note that this wakes it up only shortly :)
<dilinger> dholbach: yea, i would've thought that would work..but no love
<ogra> did you suspend or hibernate it ? 
<dilinger> suspend
<dilinger> well, the suspend button
<dilinger> which looks like it made it hibernate
<dilinger> but regardless, i can't seem to wake it up now
<ogra> hmm, remove the battery ?
<ogra> (hard reset)
<pitti> mdz: the new release includes all recent xpdf security patches and a bugfix in the jpeg decoder
<pitti> mdz: oh, and a build system bug fix
<mdz> pitti: fine by me
<pitti> ok, thanks
<seb128> mdz: any objection to a libxine1c2 to libxine-main transition now? (package splitted to libxine-main libxine-extracodecs, libxine1c2 beeing universe Depends on both ... that allow updates from 5.10 without dropping features for people using universe), slomo did the packages changes for it
<teroedni> will the new init.d/hdparm break anything
<teroedni> please answer...i dont wanna reinastall a third time
<teroedni> Thanks for all answers:)
<dholbach> teroedni: It might be cleverer to read bug reports, or scan the relevant mailing lists than flaming around here.
<dholbach> seb128: libmusicbrainz merge done :)
<seb128> dholbach: you rock :)
<dholbach> Merci.
<teroedni> dholbach:oh right sorry :(
<dholbach> seb128: Qu'est-ce que vous gens dit en franais pour "somebody rocks"? :-)
<seb128> "t'assures" :)
<pkern> "vous gens dit"? ;)
<daniels> seb128: bon soir baguette croissant
<pkern> lol
<seb128> daniels: s/bon soir/bonsoir
<daniels> dang
<seb128> daniels: et c'est pas l'heure du petit dj :)
<tseng> erm
<daniels> seb128: parlez vous c'est la vie?
<tseng> dholbach: nicht werstehen was Sie sagen :)
<dholbach> hahahahaha
* dholbach knuddelt tseng.
<pkern> Hihi.
<tseng> :D
<stratus> duvido que entendam portugues :)
<seb128> tseng: du must french gesprochen
<tseng> seb128: nein!
<dholbach> seb128: LOL! :)
<seb128> :p
<tseng> must i think is nehmen or something
<seb128> daniels: ca veut rien dire ta phrase :)
<tseng> ich muss
<daniels> itisi
<dholbach> Is the conversation of the last 4 minutes an example of why we don't do 2 week conferences? :-)
<daniels> nai poroja
<pkern> Possiamo parlare anche un po' d'italiano? ;)
<daniels> dang
<daniels> i mean, itisi nai poroja
<stratus> pkern, yes (and i really can understand you but i don't speak italian)
<pkern> stratus: I wouldn't say that I do. Heh. (=
<stratus> pkern, lol
<pkern> stratus: I had some Italian and French at school, sufficient to survive, but probably not much more left. (=
<pkern> So a `ln -s Xorg X' in /usr/bin is currently needed, good to know.
<TerminX> I hate to bother you good people, but is there a fix for the broken Thunderbird in Dapper, or should I just downgrade?
<Burgwork> TerminX, downgrade for now
<TerminX> so I'm not the only one who can't compose? :)
<Burgwork> TerminX, https://lists.ubuntu.com/archives/dapper-changes/2006-January/005040.html
<Burgwork> TerminX, that might be your bug
<TerminX> hm
<TerminX> Tbird runs for me, but if I try to compose a message it tells me "An error occurred while creating a message compose window. Please try again."
<Burgwork> TerminX, please file a bug
<mdz> seb128: sounds ok, how many packages affected?
<TerminX> Burgwork: heh, oops, too late.. purge and reinstall fixed it
<seb128> mdz: 2 packages for main, 10 for universe
<mdz> seb128: yeah, no problem
<seb128> mdz: cool, thanks
<seb128> slomo_: go for it :)
<slomo_> ok, fine :) i'll upload in ~1 hour, need to get some food before ;)
<seb128> mdz: BTW about poppler we will need poppler 0.5, evince guys will require it for GNOME 2.14
<mdz> seb128: is it released yet?
<pitti> if it's approved, then I'll upload 0.5 right away instead of 0.44.
<pitti> 0.4.4, even
<seb128> mdz: poppler 0.5 is, evince 0.5 will come today
<mdz> ok
<seb128> thanks
<dholbach> apt-get.org build finished
<dholbach> 450 good, 733 bad
<dholbach> 26 repos gave 404 error
<dholbach> WOW
<LaserJock> dholbach: so what does that mean?
<dholbach> I will review around 450 packages.
* daniels chortles.
<LaserJock> hmm, that's a lot.
<dholbach> and if one or the other of 733 sounds interesting and I'm not tired enough, I'll try fixing it.
<seb128> :)
<LaserJock> dholbach: I had riddle fix one of those a little while back
<LaserJock> Riddell I mean 
<LaserJock> dholbach: is it ok for us to be fixing those apt-get.org packages?
<dholbach> If somebody wants to help me review, I appreciate that, but I'd like it better, if we could get the REVU stuff sorted out until FeatureFreeze.
<LaserJock> dholbach: I would volunteer to help, if you want me to. I'm not sure if I'd be much help though.
<dholbach> LaserJock: We can have a look together and see how good it works. Thanks for the offer.
<mjg59> dilinger: Power button or FN key
<lucas> dholbach: please ask for the removal of ruby-gnuplot instead of importing it please
<dholbach> lucas: removal?
<LaserJock> lucas: it shouldn't be imported since the apt-get.org version hasn't changed
<LaserJock> dholbach: I got lucas to do a new package for Debian
<lucas> yeah, it's a very old version
<lucas> like 2001
<lucas> I packaged it inside debian and hope to get it in before FF
<LaserJock> but the name is different, right
<LaserJock> so we should ask for removal of the old one
<lucas> yeah, but the binary package name will conflict
<LaserJock> dholbach: so who do we ask about removal?
<dholbach> elmo
<LaserJock> lol, shoulda known. I was thinking that.
<dholbach> :-)
<LaserJock> I must be psychic
<LaserJock>  elmo, is the answer to most of the questions I ask here ;-)
<LaserJock> s/,//
<dholbach> I'll call it the day. Have a nice evening.
<lucas> you too
<mdz> seb128: are you mostly using the email interface or the web interface?
<mdz> (for malone)
<ajmitch> morning
<ajmitch> elmo: I made some sync requests by email awhile ago that haven't appeared on dapper-changes, want me to resend?
<elmo> zope-theworld?
<ajmitch> yes
<elmo> ok, found it sorry, doing
<ajmitch> thanks
#ubuntu-devel 2006-01-25
<slomo_> elmo: do you remember why you put faad2 into multiverse? and should every package containing that sources or great parts of it be in multiverse too?
<elmo> slomo_: it came from Marillat
<elmo> anything from Marillat automatically ends up in multiverse
<elmo> (came + originally)
<azeem> heh
<slomo_> elmo: hehe ok :) i ask because i'll upload a NEW package (well, split of xine-lib) soon including the complete faad2 sources... where will you put it?
<elmo> slomo_: I dunno, I'll have to have a look at the license, and what it contains, patent-wise etc.
<slomo_> elmo: it's the same as the current xine-lib tarball which is in main... but only the ffmpeg and faad plugin are used
<dilinger> mjg59: hm, i'll have to try that later.  power button certain didn't work (w/ dapper's kernel)
<mjg59> dilinger: Worked here last time I checked, but I'm not on -13 yet
<mjg59> (since -12 is broken with NetworkManager)
<mjg59> BenC: Still not in the archive :(((((((((
<BenC> mjg59: people.ubuntu.com/~bcollins/
<BenC> there's a -13-686 in there somewhere
<mjg59> Heh
<BenC> it's only missing a few unrelated patches from the real -13, but it fixes the oops
<mjg59> Super
<mjg59> That'll do nicely
<BenC> mjg59: oh, the daily from yesterday works fine too
<mjg59> BenC: Ooh
<mjg59> I'll grab those
<mjg59> BenC: There still seems to be some problem with powernow-k7 (I'm told, I don't have any hardware to test it)
<crimsun> mjg59: -13's in a.u.c; I installed it about an hour ago
<dilinger> oh god
<dilinger> they just keep making xchat's interface shittier and shittier
<dilinger> they stuck a close window thing where the left/right shift for tabs used to be
* dilinger grumbles and hops on a plane
<BenC> don't think I'll be doing this dist-upgrade
<BenC> wants to remove 285 packages
<lmanul> Hey guys, is this "fd buffer read" problem while upgrading breezy today already known ? Can't find a bug in malone but I'm just checking before I file a useless bug :)
<crimsun> elmo: please sync aewm, lablgtkmathview, nvu, qucs, saods9, sndobj, soap-lite, sqlrelay, xtranslate, and xwit from Sid, overriding Ubuntu changes (re-requested, all were requested prior)
<elmo> crimsun: nvu is broken, diffren;t orig.tar.gz
<elmo> in debian/ubuntu
<crimsun> elmo: ok, thanks
<crimsun> elmo: thanks again. Please also sync octave2.1 from Sid, overriding Ubuntu changes (also a re-request)
<elmo> octave2.1 is in the broken list
<elmo> not for orig.tar.gz tho
<LaserJock> elmo: I thought octave2.9 was in the broken list
<elmo> LaserJock: err, good point, well madew
<elmo> crimsun: done, sorry for missing all of those
<crimsun> elmo: np, thank you :)
<bhearsum> is there any documented procedure for installing ubuntu with an nfs root?
<\sh> elmo/ Znarl : planet.ubuntu.com looks like it's down
<psusi> wow... now that is awesome
* psusi finally groks the zsync with lookinside algorithm
<elmo> \sh: fixed, thanks
<\sh> elmo: no problem
<elmo> \sh: do you know what you (MOTU) guys decided to do about UVF?
<\sh> elmo: yes...we are sticking with the UVF, but if it's necessary we will write exception reports for universepackages with some special attachments (diffstats, changelogs and rationals and risk reports), sending them to dholbach, he collects those reports and he decides which ones will be send to kamion/mdz for approval
<elmo> \sh: ok - what about new packages?
<elmo> oh, crap scim
<\sh> elmo: if they are not introducing new libs for main or deps for main (like in breezy times, you remember), we will push them until feature freeze. But this only applies to packages which are not in ubuntus or debians archives. 
<\sh> and now I wonder, why libarts1-dev complains about libqt3-mt-dev not installable in my amd64 pbuilder, but in a clean chroot it's installable...fun again...
<\sh> elmo: it was discussed and approved that universe will follow the Release Schedule for main this time :)
<psusi> any debian-installer gurus around?  I think I've got a good udeb setup for dmraid, but I can't seem to get it correctly integrated into the setup cd... I build d-i from source with the udeb added, and threw the initrd on the setup cd, updated the md5sums file, and burned it
<psusi> but the setup complains that it can't find the Packages file... but I didn't touch the Packages file
<Den> Why does firefox take about 3 seconds to responding when decreasing the font size, when in my 2 yr old debian system it was instantaneous?  Is this a firefox or ubuntu problem?
<Mithrandir> Den: I tested the live cd on the ieee1394 device yesterday and it worked just fine.  Assuming we manage to get ubuntu-desktop and ubuntu-live installable today, you should have a CD in not too long.
<daniels> please file a bug on launchpad.net/malone/ rather than using the development channel for support
<Den> Mithrandir: Thank you _very_much.!
<Den> daniels: I'm trying to determine where the bug might be - has anyone else noticed this behavior of firefox?
<Den> daniels: And if this isn't the correct channel for such questions, no problem - what channel would you suggest I ask in?  I thought I'd ask in this channel in order to have a greater chance of reaching a specialist in the relevant sw?
<daniels> well, you could start with #ubuntu, really
<Den> Mithrandir: Will you please email me before you leave work & let me know the status, so I know beore this weekend if I can get an iso to try out?
<Mithrandir> Den: sure
<Den> Mithrandir: Thanks!
<Mithrandir> doko: I can't get -I to diff to DTRT on i386 either?
<perofal> what is this thing about a oem user on flight cd 3?
<perofal> I got installed the cd and I get missed the part were it says tha oem is the default user....
<perofal> also another thing is that the multiverse responsitory on the osurces.list does not work It should be replaced
<pitti> good morning
<zakame> hi pitti :)
<janimo> hi pitti
<doko> Mithrandir: my test case was diffing the gs-gpl source with the new upstream gnu ghostscript source using diff -ur gs-gpl-8.15 -I Id: gnu-ghostscript-8.16 (works on i386, but not amd64)
<Mithrandir> 'morning pitti
<Mithrandir> pitti: care to fix m-f-l-a?
<pitti> Mithrandir: yessh
<Mithrandir> pitti: thanks
<carlos> pitti, I'm generating the final language pack for breezy
<pitti> yay
<carlos> pitti, I'm doing a full export of main (we can now select just main pofiles)
<carlos> The export has 6923 pofiles
<pitti> carlos: that's nice, so I can drop that logic from langpack-o-matic in the future?
<carlos> we still miss some of them
<pitti> ok, no problem, I can merge them with the final breezy version
<carlos> pitti, yes, you don't need to remove translation domains
<carlos> pitti, we have that information already in our database
<pitti> carlos: do you do a full export, or just things that changed since the breezy release?
<carlos> pitti, full export
<pitti> carlos: since I had to drop so many stuff back then, a full export might be adequate
<pitti> ok
<carlos> yeah
<pitti> and next time we can do a relative one?
<carlos> yes
<carlos> that's the idea
<pitti> nice
<carlos> a relative one since yesterday
<pitti> what's the status for dapper?
<carlos> pitti, nothing until you use launchpad to build packages
<carlos> that's one or two weeks
<carlos> if all things work as planned
<pitti> ok, then I better generate new ones today from the buildds
<pitti> and update them in two weeks with rosetta love
<carlos> yeah
<carlos> oh, I forgot one thing...
* pitti holds his breath
<pitti> what's the catch? :)
<carlos> pitti, we need to edit some of the exported .po files
<carlos> to change the encoding information
<carlos> I will try to fix that issue today, but just in case I'm not able to have that on time for the rollout
<carlos> the exported .po files are using UTF-8 encoding
<carlos> but the .po header is not yet updated
<seb128> mdz: around?
<Mithrandir> seb128: care to reupload contact-lookup-applet?  iz uninstallable due to new eds, it appears.
<tepsipakki> seb128: do you know how to start gnome-screensaver safely without having to re-login?
<seb128> Mithrandir: I had plan to have a review of all the stuff that needs a rebuild for eds soname changes, now is good time for it, I'll do that now :)
<seb128> tepsipakki: type gnome-screensaver on a command line?
<seb128> mdz: ping is about libnotify / notification-are new versions coming today, upstream define them as
<tepsipakki> seb128: doesn't start the dialog when I lock the screen
<seb128> "
<seb128> The current release, as I mentioned, is very broken. The new one will
<seb128> fix a *lot* of major bugs, crashers, API usage, and installation
<seb128> issues, as well as usability and visual bugs."
<seb128> mdz: can we get freeze exception for that? 
<Mithrandir> seb128: excellent, thanks.
<seb128> np
<seb128> tepsipakki: what do you mean?
<tepsipakki> actually, when I lock the screen it only fades black
<tepsipakki> doesn't show the password-dialog or even the screensaver itself
<tepsipakki> but theres some output on the cmdline ;)
<seb128> restart your session
<tepsipakki> :)
<tepsipakki> I have to reinstall this anyway, my sata-disk is being killed
<tepsipakki> slow and painful dead..
<tepsipakki> death..
<carlos> pitti, forget what I told you. I already fixed that
<carlos> pitti, I'm doing also a full export for Hoary
<Mithrandir> Riddell: could you update qt3 to not depend on xlibs-static-dev, but rather the correct set of packages it needs?
<pitti> Diziet: ping
<dholbach> good morning
<Mithrandir> hiya daniel
<ajmitch> morning dholbach 
<dholbach> hello Tollef, Andrew - how are you?
<ajmitch> good :)
<Mithrandir> angry at all the uninstallable packages. :-)
<dholbach> I can imagine.
<Mithrandir> dholbach: if you'd coordinate fixing all the stuff which is uninstallable due to the new eds, I'd appreciate that.  (seb said he'd start reviewing it, but I don't know if it just landed in his queue or if he's already on it)
<dholbach> Mithrandir: I uploaded some already.
<Mithrandir> uhm, .. coordinate with seb on.., not just coordinate
<Mithrandir> coolie, thanks
<Mithrandir> new xorg which should fix up a bunch of uninstallables hits after this cron.daily.
<dholbach> elmo: please remove evolution-caldav.
<Mithrandir> dholbach: oh?  Has it been integrated into -plugins or upstream?
<dholbach> into evolution-data-server
<seb128>     * amd64:132
<seb128>     * i386:135
<seb128>     * powerpc:124 
<seb128> utch
<Mithrandir> dholbach: nice. :-)
<seb128> lot of packages have installation issues atm
<Mithrandir> seb128: a lot of it'll go away with the new xorg, since that reintroduces xutils and xbase-clients.
<seb128> Mithrandir: ah nice
<Mithrandir> we should probably go through the packages depending on those and fix the deps.
<Mithrandir> (at some point, but it's less urgent as long as they are installable)
<seb128> The following packages have unmet dependencies:
<seb128>   libqt3-mt-dev: Depends: xlibs-static-dev (>= 4.3.0.dfsg.1-4) but it is not installable
<seb128> is anybody working on that one?
<raphink> it makes kdelibs4-dev uninstallable, too
<raphink> seb128: actually I have
<raphink> The following packages have unmet dependencies:
<raphink>   kdelibs4-dev: Depends: libarts1-dev (>= 1.5-rc1) but it is not going to be installed
<raphink>                 Depends: libqt3-mt-dev (>= 3:3.3.5) but it is not going to be installed
<raphink>                 Depends: libavahi-qt3-dev but it is not going to be installed
<seb128> raphink: the base issue is what I copied before probably
<raphink> hmm
<raphink> at what time?
<raphink> xlibs-static-dev you mean?
<Mithrandir> libqt3-mt-dev needs xlibs-static-dev
<Mithrandir> I'm not sure if we should reintroduce that or nuke xlibs-dev.
<raphink> hmm
<raphink> is 1.5.0 newer than 1.5-rc ?
<ajmitch> dpkg --compare-versions
<raphink> thanks ajmitch 
<dholbach> Mithrandir: as Debian sent out FTBFS bugs for the packages that build-dep on xlibs-dev and we probably could just sync/merge their efforts, it might make sense to get rid of it, no?
<Mithrandir> dholbach: we're in UVF, though.
<seb128> Mithrandir: Debian dropped it we should do it too
<dholbach> we have one week for merges.
<Mithrandir> Kamion_: ^^ any thoughts on what we should do?
<Mithrandir> xserver-xorg-input-wacom seems to be gone -evdev seems to have moved to universe, causing -input-all to be uninstallable too.
<seb128> Mithrandir: we are still doing remaining sync
<seb128> hum
<Mithrandir> seb128: yes, but we need to decide what we should do, then go for it.  It's not obvious to me that we want to get rid of xlibs-dev just yet; it'll probably hit the motus fairly hard too.
<seb128> ~370 packages Build-Depends on xlibs-dev atm
<seb128> I would say we have better to do
<seb128> let's keep xlibs-dev for now :)
* raphink doesn't get how dpkg --compare-versions work
<Mithrandir> that means reintroducing xlibs-static-dev.
<seb128> Mithrandir: that would be a lot of work for no win imho
<Mithrandir> raphink: dpkg --compare-versions $ver1 lt $ver2 && echo "y" || echo "n"
<raphink> oh ok thanks
<Mithrandir> seb128: yeah, it's one of those cleanups we want to do, but it's not urgent.  IMO.
<seb128> Mithrandir: 22 packages Build-Depends on that one, do we need it?
<Mithrandir> seb128: xlibs-dev depends on it.  That's easily fixed, though.
<seb128> Mithrandir: that's one those cleanup we will get for free from Debian after dapper
<Mithrandir> yes
<Mithrandir> I'd like to have Kamion's opionion before we go for it, though.
<seb128> so no point to spend the efforts to rebuild ~370 packages now
<seb128> yeah, np
<dholbach> We have enough time and some new MOTUs can do their first uploads then :-)))
<Mithrandir> dholbach: you're evil. ;-)
* siretart *sighs*
<dholbach> Mithrandir: That'd be the soyuz stress test. :-)
<ajmitch> dholbach: sounds like fun :)
<seb128> dholbach: yeah, those lazy guys need some action
<dholbach> hahaha :)
<Mithrandir> we seem to have a new kernel uploaded too, time for new lrm and linux-meta, I guess.
* dholbach hugs seb
* seb128 hugs dholbach
<ajmitch> Mithrandir: another one already?
<ajmitch> -14 now?
<Mithrandir> ajmitch: nah, probably just the meta and lrm which needs updating.
<seb128> Mithrandir: l-r-m and l-m have been uploaded next to linux
<seb128> (according to -changes list)
<Mithrandir> seb128: they're listed as being uninstallable, though.
<seb128> "   * Kernel ABI bump for linux-source-2.6.15 2.6.15-13 (Look Adam!! I got it
<seb128>      right the first time!!)."
<Mithrandir> haha :-)
* ajmitch is still waiting for his alsa driver to be fixed upstream :)
<seb128> ;)
<Mithrandir> might need NEW-ing
<Kamion_> Mithrandir: tend to agree with seb128
<Mithrandir> Kamion_: so, fix xlibs-dev to depend on the proper set of packages, fix the 22 packages depending on xlibs-static-dev?
<Kamion> Mithrandir: what needs to change in xlibs-dev?
<Kamion> Mithrandir: and yeah, only 22 packages seems easy enough to deal with
<Mithrandir> Kamion: xlibs-dev depends on xlibs-static-dev
<Mithrandir> if we don't reintroduce -static-dev, that needs to be fixed. :-)
<Mithrandir> I'll also drop the dependencies on non-existing -input and -driver packages.
<Kamion> ah, ok
<Mithrandir> if we could have the rest promoted (under the obvious, we already had the code in xorg), xorg should be happy.
<Mithrandir> obvious rule, even
<Mithrandir> sounds like a plan?
<janimo> Kamion, no bazaar archive just a patch for cd-image xubuntu bits
<janimo> http://startx.ro/jani/ubuntu/xubuntu-cd/
<pitti> Diziet: unping; translations did not work any more, but that was just due to the s/mozilla-firefox/firefox/ path change
<pitti> Diziet: btw, set -e was a great idea; it uncovered a lot of bugs in the xpi processing
<Kamion> Mithrandir: sounds reasonable
<Kamion> janimo: ok, will look once I've wound through the rest of this morning's to-do list
<Kamion> thanks
<Mithrandir> Kamion: thanks, effectuating that, then.
<Kamion> is that better than "doing"?
<Mithrandir> it's the same, I think.
<Kamion> heh
<Kamion> janimo: fyi, you'll need to merge the commit I just made to the Ubuntu seeds for 2.6.15-13
<pitti> Mithrandir: uploading new m-f-l-all package now; I had to fix a fair number of bugs, so it took a little longer
<Mithrandir> pitti: thanks a lot.
<pitti> but now I can enjoy a German firefox again :)
* seb128 would enjoy a french epiphany browser if somebody was updating the language-packs for gnome :p
<dholbach> seb128: sorry, pitti just updated the german one. :-p
<pitti> seb128: langpacks are on today's list, too
<pitti> seb128: OTOH my list today is scaringly long (well, as always), let's hope I'll manage it
* seb128 hugs pitti
<pitti> Hi jvw_, how are you?
<seb128> pitti: I know that too well ...
<Riddell> Mithrandir: should I upload a qt which doesn't depend on xlibs-static-dev?
<seb128> pitti: I tend to finish my TODO list at 2am this week
<seb128> Riddell: that would be nice, so poppler could build
<Mithrandir> Riddell: does it use libxf86config?
<pitti> seb128: oh, it built fine for me?
<Riddell> Mithrandir: I don't see why it should
<Mithrandir> Riddell: just nuke the dependency, then.
<seb128> pitti: "libqt3-mt-dev: Depends: xlibs-static-dev (>= 4.3.0.dfsg.1-4) but it is not installabl" on the buildd
<seb128> (s/bl/ble)
<Mithrandir> there, new xorg uploaded.  Let's see how this fares.
<pitti> anothe one? *sigh*
<pitti> yesterday we already had about 3000 mDhanielStones...
<Mithrandir> just xorg, it's just a meta package.
<ulaas> slomo: ping
<ulaas> hi! whats up with X?
<janimo> Kamion, will do the seed merge now
<Mithrandir> ulaas: in the middle of a couple of transitions.
<ulaas> Mithrandir: thanx for reply. any way to solve it manually just to ease the pain or wait?
<Kamion> janimo: thanks
<janimo> Kamion, actually bzr pull brings no changes in ubuntu-dapper
<Mithrandir> ulaas: just wait, it will hopefully be ok in a few hours
<ulaas> Mithrandir: ohh thats great news. thats fast. thank you so much you guys rock!!
<janimo> btw how urgent are these syncs usually? I  check the seeds once every couple of days or even more ferquently
<ulaas> ls
<ulaas> hehe
<Kamion> janimo: perhaps you have an http_proxy set? I definitely pushed changes this morning
<janimo> I do have http_proxy
<Kamion> try unsetting and pulling again
<janimo> I want; aware it was caching these too
<Kamion> yeah, it can be a bit annoying
<Kamion> it'll be more urgent once we start building xubuntu CDs; this particular change is necessary for CD images to keep working at all
<Kamion> kernel ABI transitions are like that ...
<janimo> Kamion, ok I'll see about them being up-to date and fix the proxy, thanks
<seb128> re
<seb128> great
<seb128> xorg is b0rked
<seb128> where is daniels when you need him? :)
<Mithrandir> seb128: what' b0rked this time?
<seb128> $ setxkbmap -layout 'fr' -model pc105 -print | xkbcomp - :0.0 2>&1 | grep -v Warning
<seb128>                   Ignoring extra symbols
<seb128> X Error of failed request:  BadValue (integer parameter out of range for operation)
<seb128>   Major opcode of failed request:  148 (XKEYBOARD)
<seb128>   Minor opcode of failed request:  9 (XkbSetMap)
<pitti> seb128: the X->Xorg missing symlink?
<Mithrandir> what's, even
<Mithrandir> oh, fun.
<seb128> ie: gnome-settings-daemon just crash
<seb128> no theme, ni icon for GNOME
<Mithrandir> seb128: you were taking xkb, weren't you? :-)
<pitti> . o O { I feel like saying similar things when seeing a French keyboard :) }
<Mithrandir> haha
<seb128> Mithrandir: does it start by a g? *g*
<pitti> Mithrandir: quick, rename the package
<seb128> pitti: I'll bring you a french keyboard, you will learn loving them :)
<Mithrandir> seb128: that's easily fixed. :-)  Seriously, didn't you and daniels talk about that at UBZ?
<pitti> seb128: oh, I converted from de to en_US some months ago, I'm happy with that :)
<seb128> Mithrandir: yep I did, but I'm not as skilled as him in that area, I know some stuff but I could still use some advice from him :)
<pitti> Riddell: hrm, kdelibs breezy-securit still has -ubuntu2, not 1.1, but nevermind
<seb128> pitti: BTW it chockes the same way on "de"
<pitti> hm, I can type German and Russian fine here, lemme try that command
<pitti> seb128: I get a ton of warnings, but no errors
<seb128> pitti: so that's something local to my box, *great* :)
<pitti> seb128: hmm, how do I teach the gnome keyboard selector to take over again? that setxkbmap command disabled it
<seb128> pitti: the applet of the capplet?
<pitti> hm, whatever is in my panel and allows me to change keyboard layout
<seb128> right click on it, there is a menu
<seb128> try picking it again
<jordi> seb128: does 2.13 still crash a lot when doing keyboard stuff in control-center?
<seb128> jordi: if you use bugged xorg yep
<jordi> hrm
<jordi> should be more robust
<seb128> jordi: those crash are due to xorg errors, not to GNOME
<seb128> jordi: try beeing robust to something that crash under your feet ... :)
<pitti> seb128: doesn't work
<seb128> pitti: select an another one switch back :)
<jordi> seb128: ah
<jordi> so it's the libs crashing
<jordi> that's bad
<pitti> seb128: well, I can't select another one any more, that's the problem
<seb128> pitti: what does it do?
<pitti> seb128: I can click on whatever I want, and even reset to defaults and add the other lazouts again
<pitti> layouts, even )bah=
<pitti> (bah)
<jordi> seb128: is xklavier 2.1 safe?
<pitti> hm, typing on de is *hard*
<seb128> jordi: it should yep
<jordi> seb128: I'll nmu debian now then
<seb128> pitti: killall gnome-settings-daemon :)
<Mithrandir> Kamion: can you please promote xserver-xorg-input-evdev, xserver-xorg-driver-sisusb and xserver-xorg-driver-voodoo under the "we had this source in main already" rule?
<pitti> seb128: merci, that was it
<seb128> pitti: np :)
<Kamion> Mithrandir: done
<Mithrandir> Kamion: thanks
<Mithrandir> seb128: where has libtotem-plparser0 gone?  There's a bunch of stuff which is uninstallable because of it.
<seb128> Mithrandir: soname bump
<seb128> Mithrandir: I'm doing that right now
<Mithrandir> great, thanks.
<Mithrandir> sorry for nagging.. it's just that it's one of the relativetly few things holding back a working live cd.
<Mithrandir> or at least, a buildable one.
<seb128> Mithrandir: np
<pitti> Good morning Ubugtu !
<pitti> Hi Seveas 
<Seveas> hi there
<HiddenWolf> mvo: ping
<mvo> hello HiddenWolf 
<HiddenWolf> Hi. :)
<HiddenWolf> Just saw your screenshots for the dist-upgrader.
<HiddenWolf> screenshots gave me the impression the progress bar indicates only the progress of the step, rather than for the progress.
<HiddenWolf> eh, process
<mvo> yes, mpt complained about that though. so it will probably change
<HiddenWolf> Please. if a progress bar moves to hunderd, you get that feeling in your gut that it's nearly done.
<mvo> also it can be frustrating I guess to wait for the upgrade process. because it can take *ages*
<mvo> to get through all stages including downloading and installing :)
<HiddenWolf> I'd suggest have 2 progress bars. One for the current step, one for overall progress.
<HiddenWolf> People want to know how much time it'll take, even if roughly.
<HiddenWolf> they also dont' want to see a "frozen" progress bar
<mvo> sorry, my lunch is ready, we must discuss that further late :)
<HiddenWolf> :)
<mvo> but I fully agree
<HiddenWolf> Go eat. :)
<mpt> HiddenWolf, progress of subsidiary tasks is better shown using text underneath the progress bar
<mpt> Whenever I see a progress bar that fills up and then empties again I think "well, make up your mind, are you finished or not?"
<pitti> Riddell: any idea why libkipi has heaps of po files, but doesn't build .mo files out of them?
<Riddell> pitti: nope, let me have a look
<Riddell> pitti: it seems to make .gmo files
<pitti> grumpf
<pitti> what is a .gmo?
<pitti> the same as a .mo with a different name?
<Riddell> just what I was wondering
<seb128> pitti: yep
<pitti> ok, so shall I teach pkgstriptranslations to strip those as well
<janimo>  Files ending with `.gmo' are really MO files, when it is known that these files use the GNU format.
<janimo> from infor gettext
<janimo> info
<pitti> and teach langpack-o-matic about them?
<pitti> thanks janimo 
<seb128> pitti: the po folder has .gmo files after the build and they are installed as mo usually
<janimo> evince and gdm uses those too
<pitti> seb128: I see
<pitti> seb128: but I only consider the installed, not the built mo files
<seb128> pitti: is there some package installing .gmo?
<pitti> Riddell: would it hurt to install the files with a .mo extension?
<pitti> seb128: can't be many
<seb128> is there any?
<seb128> that seems weird to me
<pitti> I don't have any
<pitti> but indeed, package builds produce .gmo often
<Riddell> pitti: they do get installed with a .mo, but the package doesn't put them in either of the .debs, I'll fix that now
<pitti> Riddell: ah, I see :)
<pitti> thanks
<tepsipakki> latest firefox keeps segfaulting on me
<tepsipakki> wont start
<pitti> tepsipakki: even without esddsp?
<seb128> use epiphany :)
<tepsipakki> pitti: where's that set?
<pitti> /etc/firefox/firefoxrc
<pitti> FIREFOX_DSP="none"
<pitti> "auto" was the previous default, which broke esound on amd64
<pitti> or, rather, triggered an esound bug
<Mithrandir> yeah, I should get around to fixing esound, I haven't done that yet.
<Mithrandir> or rather, uploading my fix.
<pitti> ===== Processing /home/lamont/public_html/translations/20060110/apt_0.6.43.1ubuntu1_i386_translations.tar.gz =====
<pitti> wftl: apt_0.6.43.1ubuntu1: 3 domains, but 7 pot files
<tepsipakki> pitti: yes, that fixed it. why wasn't that updated automatically?
<pitti> ^ mvo: now, that are funny numbers
<pitti> tepsipakki: it was in the latest package
<tepsipakki> pitti: I have 1.5.dfsg-4ubuntu3 here, x86
<pitti> tepsipakki: ah, only the amd64 default changed
<tepsipakki> ok
<pitti> tepsipakki: wait for Mithrandir's fix or change it to none manually
<HiddenWolf> mpt: text only has a meaning if you can convey it to the user.
<HiddenWolf> mpt: I don't want a progressbar that fills then empties
<HiddenWolf> I'd want one to show overall progress, filling slowly.
<HiddenWolf> another to fill for each task
<HiddenWolf> "unpacking" means nothing to my aunt, a little bar filling up does.
<pitti> mvo: are those additional 4 pot files really just garbage?
<mpt> HiddenWolf, so you'd have five progress bars in the window, with the third to fifth ones starting once the previous one had finished?
<mvo> pitti: yes, it's a bit odd
<HiddenWolf> mpt: no, two
<HiddenWolf> mpt: one for the task at hand, one for overall progress.
<mpt> If you have only two, the second one is constantly emptying and filling up again
<mpt> which makes it pretty useless
<HiddenWolf> it's only there to show movement.
<mvo> pitti: apt's build-system .. well .)
<mpt> mvo, those screenshots look pretty good
<HiddenWolf> mpt: if you have only one, on a slow pc, it might take ages to move, and someone might consider it frozen and fuck up his upgrade.
<Treenaks> HiddenWolf: you don't want 5 progress bars. You want one progress bar for the entire 'upgrading' process
<Treenaks> (maybe with a 'this could take a while' message, or some other way of being more verbose)
<mpt> HiddenWolf, that's what the text is for -- it doesn't matter *so much* if people don't understand what the step is (though it should be made understandable if possible), the main thing is that the numbers keep changing :-)
<mvo> mpt: thanks, the progressbar needs fixing, that well :)
<mpt> "Borzleworping 129 MB of 355 MB..."
<Mithrandir> mpt: a progress bar which never moves isn't very useful either, though.  A progress bar serves two purposes: see how far you've come, and see the rate of progress.
<Mithrandir> if the rate of progress is small enough, you can't see it.
<tseng> will dpkg undestand muine-0.8.4pre1 < muine-0.8.4
<tseng> or do i need to express it some other way
<Mithrandir> tseng: dpkg --compare-versions.
<HiddenWolf> mpt: I'd rather see a second progress bar rather than semi-confusing garble text
<Mithrandir> (you need to express it some other way)
<HiddenWolf> mpt: that'll either move to slow to be read, or mean nothing
<HiddenWolf> eh, fast
<mpt> yes, text in a progress window or status bar shouldn't update more than about two or three times a second
<HiddenWolf> mpt: I can't read three lines a second either.
<Mithrandir> that gives you "there is progress", but it doesn't tell you rate of progress.
<Mithrandir> if we have an "estimated time left" + some text which says what it's doing, that's fairly ok
<mpt> Mithrandir, a progress meter that covers only 1/5 of the task doesn't tell you the rate of progress either!
<mpt> estimated time left is always a good thing, though, yes
<Mithrandir> mpt: it should cover the full task, I don't think anybody is arguing against that?
<mpt> Mithrandir, HiddenWolf was ... but anyway.
<mpt> mvo, how about "Cancel" and "Upgrade" instead of "No" and "Yes"? :-)
<HiddenWolf> Mithrandir: my suggestion was to have two seperate bars. One for the current task, one for the overall progress
<HiddenWolf> Mithrandir: imho that's the best way to display all usefull information in a non-scary way.
<HiddenWolf> but I've said enough about it.
* mpt thinks g-i-t's stock icons for "No" and "Yes" should be skulls or dead kittens or something
<HrdwrBoB> haha
<mpt> mvo, and instead of having a window title "Upgrade distribution" then a heading "Distribution upgrade", perhaps just a title "Upgrading Ubuntu" (or "Upgrading System" if being brand-specific is really annoying)
<dholbach> I suppose nobody is here to give back gnome-icon-theme?
<Mithrandir> dholbach: lamont crashed a few hours ago, so no, not in some more hours.
<dholbach> Ok.
<mvo> mpt: you mean, no heading at all (or only a small one)?
<mpt> mvo, no heading at all
<mvo> ok
<mpt> so, title
<mpt> overall progress bar
<mpt> time remaining (if that's possible to calculate
<mpt> )
<mpt> text about the current stage
<mvo> right, no "unpacking: nadanada" anymore under the progressbar :) ?
<mpt> that's text about the current stage, isn't it?
<mpt> that's fine
<mvo> it will currently display also what packcage (unpack linux-kernel, unpacking gedit, unpacking liblsb etc) it works on, that needs to go away I suppose (it makes my heart bleed to remove nice features).
<mpt> why does it need to go away?
<mpt> Constantly updating text like that shows that stuff is happening, which is good
<mpt> even if the package names mean little to your aunt
<mvo> ah, then I misunderstood you earlier
<mpt> hmmm
<mvo> "hmm"?
<HiddenWolf> ok, this is confusing.
<HiddenWolf> 3 letter nicks should be banned.
<mpt> mvo: "To upgrade, Ubuntu needs to download 623 MB, and change 1127 packages (adding 335, removing 29, and changing 763).   ( Cancel ) (( Upgrade ))"
<mpt> That avoids the "packages are going to be, packages are going to be, packages are going to be" in the current alert
<mvo> *nod* I'll change that
<mpt> (actually, change the last "changing" to "updating")
<mpt> cool
* mpt gets around to reading the HIG's section on progress windows, and realizes it's full of nonsense
<mpt> Make a progress window look like an alert, with a Cancel button where the OK button normally goes? Yeah, that's a good idea
<HiddenWolf> mpt: if you want to get users who don't look/read to pause and consider, switching the order of OK and Cancel will usually do the trick.
<mpt> HiddenWolf, Windows shareware often does that
<mpt> WinZip does, for example
<HiddenWolf> I know, and it works, that's why they do it.
<mpt> so you have to look at the nag screen for 0.5 seconds instead of 0.2 seconds :-)
<HiddenWolf> the intent here is to not have you press "kill my pc (yes/no) with yes preselected and obvious, at least not without thinking even a bit.
<mpt> I still couldn't describe anything else that appears in that window, though
<pitti> Riddell: kde-i18n-pt is screwed, it installs .po files instead of .mo files
<mpt> so, mvo, disclaimer: How I suggested to arrange the progress window is quite different from what the HIG suggests. I think that part of the HIG is nonsense, but I will not mind *at all* if you follow it instead of me.
<Riddell> pitti: investigating.  any others which do that?
<pitti> Riddell: still going down my list, not so far
<mvo> mpt: I will discuss it with some HIG gurus and see what they think. changing the ui shouldn't that hard, so either way, I appreciate your input very much
<pitti> Riddell: no, it's the only one
<pitti> Mithrandir: do you know whether mailman uses gettext at all? it has a lot of po files, but doesn't install any mo files
<Mithrandir> pitti: unsure.
* mpt finds a rewrite of the HIG's progress windows section rusting in his home folder
<Treenaks> mpt: commit it :)
<Treenaks> mpt: (submit it?)
<mvo> mpt: haha, send it in :)
<mpt> hmm, I wrote this last year sometime then forgot about it
<mpt> yeah, I should send it in
<mpt> it needs illustrations though
<pitti> Mithrandir: ok, nevermind. mailman installs translations into /var/lib/mailman/messages instead of /usr/share/locale/, so pkgstriptranslations don't pick them up
* Kamion 's brain explodes at backspace vs. delete handling in console-data
<Kamion> I'm just going to ignore both in the gfxboot keymap handler and let gfxboot sort them out by scan code, I think
<Treenaks> Kamion: Try ssh'ing into FreeBSD boxes...
<Mithrandir> Kamion: we should just be able to get rid of console-data soon anyway. :-)
<Kamion> the French keypad down-arrow handling is annoying too
<Kamion> generates 2 by default, and you have to use altgr to make it be Down, I think, but I can't type AltGr-KP2 on my PowerBook keyboard so I can't test it
<Riddell> pitti: fixed version uploaded
<Mithrandir> Kamion: go french keymaps?
<Kamion> yeah
<Mithrandir> grrrr
<Kamion> Mithrandir: ok, as of not-very-long-from-now, gfxboot will give you a Linux console keymap name on the command line, e.g. "kbd-chooser/method=de-latin1-nodeadkeys"
<Mithrandir> Kamion: can I have an X keyboard map name instead, once lcxkb is working?
<Kamion> Mithrandir: once that all works, probably, yes, although I'll need to fiddle with gfxboot-theme-ubuntu to make that happen
<Mithrandir> Kamion: I'm hoping to have something working decently at least before the sprint.
<Kamion> but it would be nice to get the console keymap stuff in in the meantime
<Mithrandir> as in, you want casper to do something with it?
<Kamion> just set it as debian-installer/keymap in /target before reconfiguring X and xorg should sort it out
<Mithrandir> possibly.  Daniel did some changes related to this which may break us a bit
<Kamion> if those break the live CD with that suggestion, they'll break the install CD too
<Mithrandir> yup
<Kamion> from the changelog it didn't sound as though it would break, though
<tvo> which pkg is the live cd cd check? (for bug report)
<Kamion> tvo: casper
<tvo> Kamion: ok thanks
<seb128> Kamion: could you give a retry to poppler?
<Kamion> seb128: done
<seb128> thanks
<tepsipakki> how can I link a bug in launchpad to a upstream bug? it asks for a product
<Kamion> tvo: you realise returning to the menu involves rebooting, right? :)
<seb128> Kamion: is xine-lib waiting on something?
<tvo> Kamion: hmm, actually I didn't.  But I do now you mention it :)
<Kamion> seb128: it's in NEW
<Kamion> is it urgent?
<seb128> Kamion: could it be accepted/libxine-main1 promoted (it's a rename of libxine1c2 without parts with patent issues), so totem/python-gnome-extras/rhythmbox can build and be installable again
<seb128> Kamion: it's block Mithrandir to do a CD I think
<seb128> s/block/blocking
<Mithrandir> seb128: \o/ :-)
<Kamion> ok, give me a moment to check it over
<seb128> sure
<tvo> Kamion: that's unfortunate, but maybe do the reboot automagically after user presses a key?
<tvo> or show a message or something like that..
<Kamion> so, uh, can we really put e.g. mad and real decoders in main?
<Kamion> I mean I know they've always been there, so I guess it shouldn't block acceptance
<seb128> Kamion: hum
<seb128> that would be a question for slomo
<Kamion> neat, libxine1c2 conflicted/replaced itself
<seb128> Kamion: reject it for now, I'll do a new totem upload using previous libxine
<seb128> that's easier
<seb128> and we will sort that with slomo later
<Kamion> too late
<seb128> oki, works fine too
<Kamion> those decoders were already in main, so it's not like the situation is regressing or anything
<seb128> right
<seb128> it was just in case you had some reticence to accept it
<Kamion> meh, I guess that means I have to process xine-extracodecs too though
<seb128> thank you
<seb128> xine-extracodecs is multiverse
<seb128> no hurry
<Kamion> yeah, but libxine1c2 for upgrade path
<seb128> correct
<seb128> but do we care about daily upgrade path for people tracking dapper?
<Kamion> not really :)
<seb128> they can live with installing extracodecs by hand if they jump on the update
<seb128> but right, if you want to do it now that's done and upgrade is smooth :)
<Kamion> only done the source NEW
* Mithrandir ponders
<pitti> Riddell: hm, libkipi now has po/ca/{libkipi.po,ca.po} - which is the right one?
<pitti> Riddell: hmm, ca/ca.po seems to be generated during build, but no other language does that (they all just use libkipi.po); this breaks the import
<Kamion> janimo: do you actually have a xubuntu-artwork-usplash package yet?
<janimo> yes
<janimo> in breezy even
<Kamion> oh, so you do, sorry for not checking
<Riddell> pitti: eek, that's something I left from my tests when I was playing with the package earlier
<pitti> Riddell: I'm already at fixing it
<Riddell> libkipi.po is correct one
<pitti> (If you don't mind)
<Riddell> go ahead
<pitti> yes, I saw it in the debdiff
<pitti> uploaded
<pitti> Diziet, seb128: since the last dist-upgrade I can't open links from the terminal any more, I get an error dialog. known bug?
<seb128> pitti: what does it say?
<seb128> pitti: does "gnome-open http://a_website" work?
<pitti> freely translated: "Address http://bugzilla.gnome.org/show_bug.cgi?id=327350 could not be opened. Error on execution of the associated command of the default action'
<Ubugtu> Gnome bug 327350: "crash (double free) on mpg playback" Product: GStreamer, Component: gst-plugins-ugly, Severity: normal, Assigned to: gstreamer-bugs@lists.sourceforge.net, Status: UNCONFIRMED
<pitti> erm, yes, that's the one I triage right now
<Kamion> janimo: hmm, your checkout of debian-cd was quite out of date - adapting your patch for various changes since then
<pitti> seb128: nope, same result
<pitti> Error showing url: There was an error launching the default action command associated with this location.
<pitti> Diziet: ok, seems to be a gnome error, nevermind
<seb128> pitti: gconftool-2 -g /desktop/gnome/url-handlers/http/command
<Treenaks> On amd64, I sometimes have to launch firefox twice to get one window
<pitti> seb128: a-ha: /usr/lib/mozilla-firefox/firefox "%s"
<pitti> seb128: it should be lib/firefox
<pitti> seb128: or rather /usr/bin/firefox maybe?
<seb128> pitti: did you set that by hand?
<pitti> certainly not
<seb128> the GNOME capplet sets "firefox %s"
<pitti> grep http/command /home/martin/.gconf/%gconf-tree.xml -> no result
<seb128> pitti: sure
<pitti> seb128: gconf-editor shows an 'a', that's 'automatic', right?
<seb128> pitti: it's an xml file
<seb128> so it's 
<seb128> <http>
<seb128>   <command>
<seb128> not the same line :)
<seb128> pitti: grep firefox /home/martin/.gconf/%gconf-tree.xml
<pitti> indeed
<pitti> there is the entry
<pitti> odd, I never touched that (at least not delibarately)
<seb128> if you use system, preferences, preferred app capplet?
<pitti> ok, thank you
<seb128> what value does it say?
<seb128> np
<seb128> and admire the new capplet look :)
<pitti> heh, I never saw that dialog, nice one :)
* pitti admires
<seb128> thank you ;)
<pitti> anyway, it says /u/l/m-f/f, not surprisingly
<seb128> it's weird
<pitti> and 'custom'
<pitti> I change it to 'Firefox'
<seb128> something changed it one day
<seb128> I doubt that's the capplet, it has no path coded, just commands name
<pitti> hmm, custom terminal emulator, too?
* pitti sets terminal from custom to g-t
<seb128> what command?
<seb128> what was the custom value?
<pitti> Command: gnome-terminal
<pitti> Execute flag: -x
<pitti> heh, what's an "Ubuntu terminal emulator"? :)
<seb128> that may be a bug of the switch to the next capplet
<seb128> pitti: a request from Mark to rename Debian terminal emulator :p
<pitti> cool, I can set mutt as prefered mail reader
<pitti> seb128: ah, the /etc alternative, I guess
<pitti> ok, it works again
<pitti> I'm fairly sure that I didn't touch it, but if it was only an intermediate breakage, let's ignore it
<pitti> I'll do a breezy->dapper upgrade at some point anyway
* pitti hugs seb128, thanks
<seb128> right, the Ubuntu terminal emulator is x-terminal-emulator
<seb128> yeah, I'll be careful when I do upgrades as well
* seb128 hugs pitti
<seb128> the custom terminal emulator might be a bug on upgrade, I doubt than a the capplet set the /usr/lib path for firefox though
<seb128> maybe some evil app writting the gconf key
<seb128> or an extension
<seb128> or something ...
<pitti> well, the advantage of changing ffox' path is that it uncovers all the little places where it's stored, and shouldn't be
<seb128> like breaking the apps linked against it? :p
<seb128> (the .so have moved too)
<pitti> seb128: ... or breaking the translations :)
<seb128> he he
<Treenaks> security down?
<pitti> Treenaks: hmm, Znarl just worked on the servers... Znarl?
<janimo> Kamion, I patched against patch-213 AFAIK
<janimo> I updated now and the only new thing is ypou recent commit
<janimo> or is it a multi-config project? I did not recurively update I admit
<Treenaks> pitti: '[Connecting to security.ubuntu.com (82.211.81.138)]  *nothing*
<Kamion> janimo: you need to update in debian-cd as well as just in cdimage
<Kamion> janimo: anyway, applied now, thanks!
<tepsipakki> will nscd ever be supported on ubuntu? ldap-setups practically depend on it..
<tepsipakki> clients, that is
<pitti> Treenaks: <Znarl> pitti : It's just very very slow right now.
<Treenaks> pitti: it times out twice, but it works now
<janimo> Kamion, thanks! I did not know cd-image was a separate project. 
<Kamion> (oops, I forgot the credit to janimo in my last commit message - very hard to add back now though, sorry)
<gond> hi. I've got some questions about your debian-installer. Where does it get its sources.list from
<janimo> Kamion, np at all :)
<Kamion> gond: it generates it itself on the fly
<pitti> Kamion: bzr uncommit works pretty well nowadays :)
<gond> from which data? I'd like to influence that ;-)
<Mithrandir> Kamion: uncommit ; fix ; commit?
<pitti> Kamion: (it saved me once from a stupid commit I didn't want to do)
<Kamion> gond: which version of Ubuntu are you installing?
<janimo> Kamion, don't bother really
<Kamion> Mithrandir: already pushed
<Kamion> bit too much effort to go around frobbing all the mirrors
<janimo> pitti, uncommit using bzr 0.7 ?
<gond> Kamion: its the breezy version of the installer
<Kamion> gond: and in what way would you like to influence it?
<pitti> janimo: I use jbailey's CotD
<gond> I want it to get the udebs from one source and the debs from another one
<Kamion> gond: you can do that with preseeding; search for apt-setup in http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/apcs01.html
<Kamion> gond: and see http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/ch04s06.html
<gond> Kamion: does it work with kickstart? I want to use the ubuntu-breezy installer to install sarge ;-) 
<Kamion> gond: sorry, that's totally unsupported and fairly unlikely to work properly
<Kamion> gond: no, kickstart only lets you set a single URL for both udebs and debs
<Kamion> although you can use the 'preseed' extension to kickstart to apply a few preseeding tweaks if you're already using kickstart for other things
<gond> Kamion: we are using kickstart for our ubuntu-client installation; our servers are still working on sarge, and we want to use autoinstallation. Kickseed is much more readable...
<Kamion> in fact, yes, I'm certain that the breezy installer will fail in fun ways if you try to use it with sarge.
<Kamion> it would be more sensible to backport kickseed and the busybox-cvs changes it needs and try to fit those into the sarge installer somehow, then.
<Kamion> It would still be a non-trivial amount of work even for somebody already familiar with the internals of the installer
<gond> Kamion: is debian working on kickstart?  
<Kamion> gond: I'm working on porting Kickstart compatibility to Debian d-i in my spare time, yes
<Kamion> but it probably won't end up in the mainline installer for space reasons - instead there'll be separate initrds available or something
<sbalneav> Well, we'll try that again
<sbalneav> Morning all
<Kamion> http://lists.debian.org/debian-boot/2006/01/msg00372.html and followups
<gond> Kamion: That could be a problem. It should be easy to maintain...
<Kamion> gond: as author, I dispute that somewhat :-)
<Kamion> there's a reasonable amount of work that needs to be done in Debian before it can work there at all
<Kamion> some of that work will take up additional space and make it harder for things like very low-memory installs to be supported
<Kamion> at least, so the lead d-i developer reckons
<Kamion> I'll do what I can, but I cannot simply override people's objections
<gond> Kamion: We will need this thing ;-) What can I do to help you
<pitti> Hi sbalneav 
<Kamion> gond: you probably can't - I've already set more or less everything possible in motion
<Kamion> thanks, though
<sbalneav> Hey there pitti!
<Kamion> and in any case it still won't support sarge
<Kamion> you *have* to use preseeding for that
<gond> Kamion: it can't be backported?
<Kamion> gond: 15:11 < Kamion> It would still be a non-trivial amount of work even for somebody already familiar with the internals of the installer
<Kamion> and even then, not really, because you'd have to have a private archive with e.g. a custom version of tasksel
<Kamion> and quite possibly base-config too
<gond> Kamion: These things would not be a big problem. Its more work to get preseed etc. working
<Kamion> gond: I really think you're overestimating the difficulty of preseed by an order of magnitude here
<Kamion> I know what's involved in both (a) getting kickstart working in sarge and (b) getting preseed working in sarge
<Kamion> and (a) is a good order of magnitude more work than (b)
<Kamion> you can also get the kickseed source and use it as a reference for the sorts of things you'll need to preseed
<gond> Kamion: I'll have to think about it... 
<Kamion> although it probably won't be quite right for sarge (I've tried to insert comments where I depend on new features of various packages), so it'll take a few iterations
<Kamion> I realise Kickstart is a lot simpler to use for simple autoinstalls (that's why we did it, after all) ...
<gond> Kamion: I'll have a look at it. You are often in this channel?
<Kamion> yes
<gond> Kamion: I'll come back to you
<Kamion> one of the problems with kickstart in sarge would be that there's no way to select individual packages to install other than by preseeding base-config/late_command to do an apt-get install by hand
<Kamion> that would apply to preseeding too
<Kamion> if you only need to select tasks, then it's easier
<gond> Kamion: I just want to do a base install. no extra packages. Thats done by our software deployment
<carlos> pitti, dude, I just restarted the export because I forgot that the .pot export was not working and the process failed...
<Kamion> gond: that would make kickstart easier, certainly
<carlos> pitti, anyway, I think it will take only 2-3 hours
<gond> Kamion: *g*
<pitti> carlos: I have theather this evening, I won't be around at that time any more
<carlos> pitti, anyway, the tarballs will appear at mawson.ubuntu.com/~carlos as usual
<carlos> pitti, and will be generating weekly exports as usual for breezy and hoary
<pitti> carlos: nice
<carlos> pitti, just tell me the URL of the tarball you use
<carlos> so I can set the timestamp to that one
<carlos> so we can do an update next time
<maswan> regarding the current security.u.c slowness, is that due to machine or network trouble? in case of network saturation, you can always dump more releases-downloads on us
<lamont> dholbach: gnome-icon-theme_2.13.5.1-0ubuntu1 given-back
<seb128> lamont: could you give back totem too?
<mxpxpod> is anyone else having problems when dapper boots up, it fails when it runs /etc/init.d/dns-clean?
<BenC> am I to understand that mono programs are actually win32 executables?
<mjr> BenC, not really
<BenC> file reports it as PE windows executable
<BenC> does it contain bytecode of some kind?
<mjr> the bulk of it is CLI bytecode
<lamont> seb128: done
<seb128> thanks
* lamont gets ready to head officewards
<mjr> apparently there's also a PE header; not sure if there's some win32 init code or somesuch, but most is CLI
<lfittl> BenC: ati binary driver 8.21.7 is out, do you plan to update l-r-m?
<pitti> tar xzf data.tar.gz
<pitti> tar: .: Cannot utime: Operation not permitted
<pitti> what???
<BenC> lfittl: inifinity does l-r-m
<BenC> pitti: maybe it can't get the utime for the file you are tar'ing up?
<pitti> I want to extract a file actually
<BenC> hmm, wait, maybe it's overwriting a file
<BenC> yeah, just noticed that
<lfittl> BenC: k, thanks, I will ask him when he is online
<HiddenWolf> BenC: I've been wondering for a while, is there anything in the kernel infrastructure to enable an optical mouse to dim it's light when not in use?
<BenC> lfittl: he really doesn't like that :)
<BenC> lfittl: we're in an upstream version freeze, so it will depend on whether it is warranted or not
<spike> hey there, security.u.c down?
<BenC> HiddenWolf: my optical mice do it automatically
<BenC> HiddenWolf: must be your mouse that doesn't support it
<HiddenWolf> mouse does, ubuntu doesn't
<BenC> ubuntu shouldn't have to
<HiddenWolf> note-to-self: ditch MS-mouse. :)
<BenC> I have 5 different optical mice, all by logitech, and they all dim automatically
<Riddell> lamont: please give back k9copy
<HiddenWolf> Hm, My old, dirty, ragged MS intellimouse must want a hint from a driver or so.
<HiddenWolf> BenC: thanks, I'll get myself a logitech. :)
<dholbach> lamont: merci beaucoup
<Kamion> Mithrandir: panel_version=$(chroot /target /usr/bin/dpkg-query-query -W --showformat='${Version}' gnome-panel-data 2>/dev/null) || panel_version=""
<Kamion> Mithrandir: that code in casper-bottom/22gnome_panel_data looks like a typo to me (extra -query)
<slomo> Kamion, seb128: i could move the mad plugin too but i thought it is ok this way... the libxine-main1 binaries are only linked against libmad and libmad is no dependency of libxine-main1 but only a suggests... that's the same way as before. and for the conflicts, they're all versioned and imho there should be no problems but i may be wrong...
<seb128> slomo: libxine1c2 Conflicts with libxine1c2 ..
<Kamion> slomo: conflicts> my point was that libxine1c2 used to conflict with *itself*. :-)
<Kamion> (harmless, because dpkg ignores it, but silly)
<seb128> slomo: and for mad the goal was to move libmad to universe and that's not possible if libxine Build-Depends on it
<slomo> damn, indirectly it conflicts itself... right... that's because of the version numbers... i'll fix it, thanks for noticing :/
<Kamion> does anything need fixed now? I was commenting on the old situation
<slomo> seb128: i asked you some time ago about libmad and you said it would be ok this way :P but no problem, i can move it in the other package for the next upload
<slomo> Kamion: no, i haven't changed anything since then... but i'll do now
<seb128> slomo: you asked that? I should have misred it
<seb128> misread
<slomo> seb128: well, np :) i'll move it to the other package
<poningru> sorry to disturb but 
<poningru> anyone know if/when launchpad et al will be freed
<Kamion> #launchpad
<poningru> asked there no one responded
<azeem> poningru: try again later, then.  This channel is not the right place
<poningru> ok sorry
<pitti> seb128, Riddell: mmm, fresh langpacks in http://people.ubuntu.com/~pitti/langpacks/ - try them while they are hot :)
<seb128> thanks
<pitti> seb128, Riddell: if you have a minute, do you want to test them ?
<Mithrandir> Kamion: yes, that looks like a typo
<seb128> pitti: will do
<seb128> after having kicking who broken evince :)
<seb128> Error: Couldn't find a font for 'Helvetica Bold'
<seb128> some font thing failed
<seb128> Error: Couldn't find a font for 'Helvetica'
<seb128> some font thing failed
<seb128> Error: Couldn't find a font for 'Courier Bold'
<seb128> some font thing failed
<spike> hi there
<pitti> seb128: erm, *shaking* it worked fine yesterday
<pitti> hi spike 
<mdz> seb128: around now
<spike> can I paste 5 lines? (discussion on ubuntu-server)?
<pitti> Good morning mdz
<mdz> morning
<seb128> mdz: cf some lines after the ping IIRC (libnotify)
<pitti> spike: you already wasted one for the question :)
<seb128> mdz: hi :)
<spike> 17:43:59 < spike> based on http://httpd.apache.org/docs/2.0/mod/core.html.en#allowoverride, default is AllowOverride All
<spike> 17:44:55 < spike> and apache2.conf has no AllowOverride directive but for icons/errors and public_html Directory statements
<spike> 17:45:13 < spike> wouldnt it be safer to define a global AllowOverride None?
<spike> 17:47:59 < spike> same goes for "Options" directive. default is All and I cant see anything about it, and would consider only "Indexes" a saner default
<mdz> seb128: it doesn't *seem* horribly broken to me; what's your opinion?
<spike> my first installation of apache2, ran 1.3 so far, and I'm a bit perplexed about default config
<pitti> Mithrandir: hmm, may it be that you accidentially swapped the '$REGEN' logic in locale-def?
<BenC> is there anything besides banshee that can play songs from an iTunes share?
<pitti> Mithrandir: erm, locale-gen? now it regenerates locales on langpack install
<mdz> seb128: is it a gnome thing or a fd.o thing?
<pitti> Mithrandir: and REGEN does the opposite of KEEP now
<BenC> banshee loves to crash as soon as I hit play on my powerbook
<spike> should I send that to the ML? post on the wiki? what's the best approach to discuss that?
<seb128> mdz: I think it's quite ugly atm and upstream put a lot of work on it, we still have time and there is some API changes that GNOME will probably use for 2.14
<seb128> mdz: fd.o but used by gnome-applets and some other GNOME stuff
<slomo> BenC: rhythmbox compiled against gst 0.8 can do it too
<Mithrandir> pitti: I think I did it the right way around.  Doesn't locale-gen de_DE.UTF-8 forcefully regenerate the locale?
<mdz> seb128: ok, let's do it
<seb128> thanks
<seb128> mdz: xchat-gnome 0.9 has been released today too, they did it because they learned that the Ubuntu freeze was this week and they wanted to get the current SVN ameliorations/fixes for it ... do we want to update too?
<Mithrandir> spike: mod_userdir sets allowoverride FileInfo AuthConfig Limit and Options  MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<seb128> mdz: about xchat-gnome, jdub would like to switch back to xchat. Did he discuss with you about that? What is your opinion?
<spike> Mithrandir: eh, and? that's for ~/public_html only, no? how does it make saner default for common hosting under /var/www/?
<pitti> Riddell, seb128: new packs look good to me
<spike> Mithrandir: a stricter default overridden in vhosts sounds better to me
<Mithrandir> spike: it's in the default vhost here.
<Riddell> pitti: these packs contains the locales now as well?
<spike> aaaah, ok
<spike> Mithrandir: tnx, didnt see it, just inspected httpd/apache2/.conf and conf.d
<BenC> slomo: 0.8 or 0.10?
<slomo> BenC: gst 0.8
<BenC> is gst 0.8 newer than gst 0.10, or am I missing something? :)
<Riddell> ah no, just calls install-language-pack
<Riddell> pitti: yep, look good to me
<mdz> seb128: jdub said nothing to me
<mdz> seb128: I am pretty happy with xchat-gnome; it has a few quirks but overall seems better integrated than xchat
<pitti> Riddell: no, not any more
<pitti> Riddell: thanks, so I'm throwing them at the buildds now
<seb128> mdz: I'm happy with it too and got almost no real complain (small UI issues and missing feature from people on that chan, but they are not basic users :), dunno where jdub got his feedback
<seb128> mdz: is update to 0.9 ok?
* dilinger tries xchat-gnome; xchat sucks
* spike hugs irssi
<HiddenWolf> I'm afraid I'll like -gnome less.
<seb128> HiddenWolf: objective criticism is welcome, any comment to make it better?
<seb128> pitti: language packs work fine here
<pitti> seb128: thank you for testing
<seb128> np
<pitti> seb128: did you see apparent improvements?
<seb128> xchat-gnome is translated :)
<pitti> or, rather, regression fixes?
<seb128> no issue noted no
<mdz> seb128: update to 0.9 is ok with me
<seb128> will do it so, thanks
<spike> Mithrandir: you there? I was pondering about that apache thingie a bit more
<BenC> slomo: nice, rhythmbox recompiled works nicely
<slomo> BenC: can you file a bug about the banshee crash on ppc with backtrace etc?
<BenC> the normal banshee doesn't crash, it's my local compile
<slomo> hmm, interesting... ok ;)
<slomo> seb128, Kamion: new xine-lib / xine-extracodecs uploaded... with hopefully correct conflicts this time and mad moved out of main
<seb128> thank you
<LaserJock> anybody know why xserver-common isn't around anymore?
<seb128>    * Merge xserver-common and xorg-common packages into x11-common.
<carlos> zyga, hi, language packs snapshots are being generated again since today
<carlos> but this time weekly
<LaserJock> seb128: thanks, what about all the packages that depended on xserver-common?
<seb128> LaserJock: all, like 4 packages .. they are to rebuild
<LaserJock> seb128: oh, sorry. I was trying to get a vncserver and most of them depend on xserver-common. I assumed it was a bigger problem
<LaserJock> seb128: I'll just wait then :-)
<seb128> apt-cache rdepends xserver-common
<zyga> carlos: hello
<zyga> carlos: thanks, is the url the same?
<carlos> zyga, yes
<LaserJock> seb128: weird, I didn't get anything
<carlos> zyga, breezy's one is alsmot finished
<carlos> will appear soon
<zyga> carlos: thanks, I'll dig out my old infrastructure
<carlos> ok
<seb128> LaserJock: you probably have no deb-src
<LaserJock> seb128: I do and it works for other packages. Oh, well. As long as it's not a big thing, I can wait
<seb128> k
<BenC> "Totem was not able to play this disk: No reason"
<slomo> BenC: totem-gstreamer and a dvd?
<dholbach> Have a nice evening and weekend.
<\sh> BenC: sounds like windows :)
<\sh> BenC: I had to laugh, when I saw the picture of this error message right above a similar windows error message (last time on the planet before the planet spam algorithm started ;))
<BenC> slomo: yeah
<slomo> BenC: totem is built against gst 0.10... and gst 0.10 has no dvd support yet
<BenC> why is everything moving to 0.10 if 0.10 is lacking important features? :/
<slomo> BenC: the only missing feature is dvd plugin and some other less important plugins... and dvd will be done hopefully soon
<BenC> being able to play itunes shares is pretty important, atleast to me
<slomo> rhythmbox from cvs can do it now afaik
<BenC> why is rhythmbox not able to use daapsharing with gst 0.10?
<BenC> ah
<rob^^^> slomo: eek, I thought that was in breezy
<rob^^^> worked well last time I tried it
<BenC> rob^^^: probably was, but is currently broken in dapper
<slomo> breezy had gst 0.8 and only the rhythmbox from the backports can do daap
<mdz> rob^^^: breezy used gstreamer 0.8
<BenC> atleast davs:// appears to be working with nautilus now
<BenC> that was my other gripe for awhile
<rob^^^> is there a gst testing list that is put out by fluendo? I saw something about it on p.g.o but I reloaded and someone had upgraded their blog and spammed it into nowhere again
* rob^^^ tries planet gstreamer
<\sh> looks like LiveJournal mass url changing mess
<rob^^^> how hard is it to not post a story that has the same date and time as nother that has been seen
* rob^^^ goes to see if there be source about
<hunger> Hmmm... now that /etc/network/if-*.d works, couldn't all network services get started there (if a non-lo interface goes up)?
<mdz> lamont: around?
<mdz> lamont: it looks like linux-restricted-modules-2.6.15 needs a retry with libqt3-mt-dev 3:3.3.5-1ubuntu15
<mdz> on i386
<lamont__> mdz: ok
<lamont__> mdz: done
<lamont__> time to go fetch kids in a couple minutes, then I'll be home
<mdz> lamont__: thanks
<lamont__> mdz: at least I hope it gets the new qt3.... I just gave it back, assuming that qt3 was in the archive for it...
* lamont__ leaves the computer at work and goes to fetch kids
<mdz> lamont__: it is
<zyga> good night friends
<mdz> lamont__: looks good now, thanks
#ubuntu-devel 2006-01-26
<Tm_T> sooo, -13 kernel isn't that good, right? atleast here was several issues with it
<crimsun> do you mean -12?
<mdz> works fine here
<Tm_T> well, part of /var was gone (that part atleast what apt uses) and network wasn't working
<lamont__> mdz: ping
<mdz> lamont__: pong
<lamont__> UVF/universe question for you...
<lamont__> in december, I uploaded lablgl_1.01-9ubuntu1 to use ocaml-3.09.1
<lamont__> Jan 7, the debian maintainer uploaded lablgl_1.02-1, also building with ocaml-3.09.1
<lamont__> however, no merge ever happened.
<lamont__> but lablgtk did sync from debian (and is now ftbfs, d-w lablgl>=1.02-1)
<mdz> a sync is fine with me if MOTU don't object
<lamont__> is that worthy of a sync?
<lamont__> ah, ok
<crimsun> it's fine with me
<slomo> same here ;)
<crimsun> I was going to ask for it in Dec
<lamont__> mdz: and as an FYI:
<lamont__> sound/vorbisgain_0.36-1: Dep-Wait by buildd+vernadsky [optional:out-of-date] 
<lamont__>   Dependencies: debhelper (>= 5.0.10)
<lamont__> dapper has 5.0.7ubuntu2
<lamont__> crimsun: done
<lamont__> slomo: ditto
<crimsun> danke
<lamont__> sladen: just oh btw, e2fs-zero.py doubled the size of the hppa loopfs. :(
<slomo> mdz: another UVF question here... when upstream has a "bugfix-only" branch and we want to follow this, i.e. get a new upstream version with only bugfixes... is it likely to get an UVF exception? this mostly affects mono and stuff depending on it
<xhaker> gconf
<mxpxpod> what's going on with sound on powerpc in the latest dapper? alsa can't seem to find the soundcard (2.6.15-13)
<Burgundavia> mxpxpod, please file a bug
<mdz> slomo: yes
<lamont> dear openoffice.  please don't &*)%$^&%*_)$^*&%_(&) steal focus when you start.  kthxbye
<sladen> lamont: oooh, funky.  does e2fsck reckon the filesystem is still okay?
<sladen> lamont: both before and afterwards;
<lamont> sladen: haven't really played with it
<lamont> I'll do some investigation though
<lamont> just not today
<sladen> lamont: the grunt work is done by e2fsdump or something so hopefully it doesn't screw up the data in the meantime.  if it's *exactly* twice as long is that a 64-bit issue somewhere?
<sladen> lamont: okay
<lamont> not exactly 2x
<lamont> 3.9e6 instead of 2.1e6
<lamont> er, e9
<psusi> eh? what's going on?
<psusi> did I somehow miss part of this conversation?
<lamont> psusi: tons of scrollback ago
<psusi> I guess so... over an hour I guess too... or however long I've been logged on
<lamont> yeah, IIRC, something like 15 hours or so ago.
* lamont ^5s sladenb
<lamont> psusi: I've been in conversations that took literally _days_ simply because of absolute time-slew. (both parties online for 8+hours, never the same 8 hours)
<lamont> er, no part of those 2x8 hours being overlapping at all
<lamont> it makes for some rather disjointed discussions, esp when they happen in a public channel
<psusi> omfg
<sladen> psusi: I gave up reading IRC by anything other than highlights...
<psusi> who reads that much scrollback?
<lamont> psusi: if the tab is blue, you go find it.
<psusi> lol.... wow
<lamont> and knowing that the other person does that means you can drop little nonsequitors for them to answer.
<lamont> dunno how true it still is, but most of the original ubuntu crew working towards warty fits into the crowd that plays catchup on scrollback, at least looking for higlights, as the start of their day
<psusi> anyone know a debian-installer guru?  I think I have managed to udebify the dmraid package, but I can't get it built into a custom setup cd right to test it... 
<psusi> after building d-i from source and burning, setup complains that it can't find the Packages list... but it's there, i didn't touch that file
<psusi> only replaced initrd.gz
<psusi> and updated it's md5sum in md5sums.txt
* psusi spends about 2 hours reading email at the start of his day ;)
<lamont> hrm... the udeb is going to live in cdrom/pool/....
<lamont> which means fixing Packages, Packages.gz, fixing Release, Release.sig, and then (maybe - dunno if breezy was nicer in this respect) hacking ubuntu-keyring and doing that over again, so that the CD still verifies.
<psusi> I built it into the initrd
<psusi> I think...
<lamont> if it's truly something that just lives in the initrd, then you're probably OK w/out mucking with Packages et al.
<lamont> i386?
<psusi> I got the source package for debian-installer, and added it to the package lists in there and built it
<psusi> amd64
<psusi> that resulted in a kernel image and an initrd... so I copied the initrd to the directory tree I extracted from the flight 3 iso
<lamont> then it's probably just the magic mkisofs command, which can be found on the LiveCDCustomizationHowTo page on the wiki
<psusi> and updated the md5sums.txt, burned and booted
<lamont> admittedly, solving a slightly different issue.
<psusi> did that
<lamont> then where is it dying>?
<psusi> well, actually I read SetupCDCustomizationHowTo
<lamont> ok
<psusi> d-i says it can't find Packages
<lamont> and there's a /cdrom/dists/$Mumble/binary-amd64/Packages.bz2 file?
<psusi> I *think* that the udeb can live in the initrd... it contains a single binary, /sbin/dmraid, and a postinst that runs dmraid -ay
<lamont> with the right md5sum in .../Release?
<lamont> if it's in the initrd, then it doesn't run a postinst...
<psusi> lamont, I didn't touch anything in dists, it's all exactly as is from the flight3 cd
<lamont> since that's just a copy of a few binaries
<psusi> hrm....
<lamont> d-i litteraly says it can't find the Packages file?
<psusi> yea
<lamont> or it can't find your udeb?
<psusi> can't find Packages
<psusi> which I thought was really odd
<lamont> that could be a bad burn command, causing it to not be where it's supposed to be...
<psusi> I looked... it was there
<lamont> how well does your CD compare to one that boots?
<lamont> ok
<lamont> dunno.  I've bludgeoned around building CD's before, but not much recently.
<psusi> hrm... so... if you build d-i with the udeb, it installs it into the initrd, but won't run postinst on boot?
<psusi> the non udeb version of the package installs files in /usr/share/initramfs-tools so that mkinitramfs will build dmraid into your initrd
<psusi> should I just let the udeb do that too and build it into d-i?  or does d-i not use mkinitramfs like that?
<lamont> the initrd is "enough stuff to get us booted to the point where we can find the CD and load the rest of d-i from the cd"
<psusi> k... sounds like it shouldn't be there then... where should it be such that it will have it's postinst run?
<psusi> and how do I get it there?
<lamont> but I'm kinda fuzzy on what the official process is for whatever it is you're trying to do with it....
<lamont> adding new udeb's is not something I'm familiar with
<psusi> dmraid is a program that scans the disks for bios metadata identifying the hardware fakeraid configuration, and programs the kernel device mapper to access it... it's a binary that you need to call before setup runs partman basically ;)
<psusi> and obviously, dm-mod needs to be loaded as well
* lamont -> bed
<nnonix> Are you guys handling w32codecs any differently in dapper?
<Amaranth> still not handling them at all
<Amaranth> seeing how it's massive copyright infringement
<nnonix> Well, that's one way to handle them
<Amaranth> nnonix: you realize what w32codecs is, don't you?
<nnonix> yes I do
<nnonix> but I'm a rebel
<nnonix> :)
<nnonix> check this
<nnonix> gstreamer0.10-plugins-ugly
<nnonix> gstreamer0.10-plugins-ugly-multiverse
<Amaranth> ugly != illegal in US
<Amaranth> not all of them, anyway
<Amaranth> the ugly package is basically some really crappy plugins that need lots of love to make it into good or bad
<nnonix> Yep, I just found the -ugly humorous
<Lathiat> if i remove x-common xorg-common xserver-common will it break my system?
<Lathiat> im despratel in need of an upgrade my kde is only half working :\ heh
<Lathiat> suppose i could leave the X upgrades back
<l0st-bit> Hello
<Tm_T> Lathiat: I think you can remove them
<Lathiat> 02:14 < seb128>    * Merge xserver-common and xorg-common packages into x11-common.
<Lathiat> ah
<Mez> Lathiat: ping
<Lathiat> Mez: pong
<Mez> Lathiat: any prgress on the thing for katapult? 
<Mez> I cant see you in the channel - or I'd have pinged you there
<Lathiat> Mez: been to busy to do anything as yet
<Mez> kool
<Lathiat> got linx.conf.au this week might find some hacking time :)
<Mez> kool
<triceratops> Does someone know which application is resposible for mountung 'varlock -t tmpfs /var/lock' in dapper?  It seems that some folders, e.g. /var/lock/clamav where not created.
<pitti> hi
<HiddenWolf> hi pitti 
<csj> Mithrandir, hello, I download i386.squashfs  and  `mount i386.squashfs /mnt -t squashfs -o loop`  but it seems read-oonly, could you give me some advice to re-mster it?
<mdke> Mithrandir, how are we looking on the ubuntu-docs update? did you upload it already?
<marseillai_> hi! i currently got a dapper on my laptop (MSI S260) and i can not use hibernation. i've made many tests but no way to solve the problem for me. i would do a bug report but i don't really know how to do. I assume it must be done on launchpad? but what file i must include with the bug report? perhaps /var/log/dmesg ? perhaps another? could you help me please. thanks and sorry for my english mistakes, i'm french.
<mdke> marseillai, include what you can with the bug report, and the developers will ask for what they need
<marseillai> oki but
<marseillai> what do you think the can need ?
<mdke> marseillai, your video card?
<marseillai> mdke: intel i915
<mdke> marseillai, there is likely a bug open about that, hang on
<mdke> try bug 29218
<Ubugtu> Malone bug 29218: "Hibernation resume failure on Thinkpad T43" Fix req. for: acpi-support (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29218
<marseillai> mdke: i didn't know this bug but it seem it's not the same
<marseillai> Going to hibernation works seems to work fine too
<marseillai> but on wake i got a "normal" boot
<mdke> marseillai, ok, file a separate bug
<marseillai> i'll do!
<marseillai> thx for your help
<marseillai> so. It's really not easy to report a bug ... :s
<mdke> marseillai, in that case, you need to report a bug with the bug reporting software ;) or ask in #launchpad
<marseillai> is it important to say i use kubuntu ?
<mdke> marseillai, the more information the better
<marseillai> oki
<marseillai> mdke: last question : i'm writing my report here : https://launchpad.net/ who can i attach a file ????
<mdke> marseillai, make sure you file the bug on ubuntu, under the package acpi-support, then afterwards, attach a file with "Add Attachment"
<marseillai> https://launchpad.net/distros/ubuntu/+source/acpi-support/+bug/29281
<Ubugtu> Malone bug 29281: "hibernate doesn't work" Fix req. for: acpi-support (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<marseillai> is it ok ?
<mpt_> marseillai, that's fine
<marseillai> thanks for your help mdke 
<mdke> np
<siretart> lamont: could you please give back gnucash? I cannot reproduce the problems from the buildd logs on my laptop.
<siretart> oh wait. it depends on xfree86-common 
<siretart> is this supposed to work in dapper?
<torkel> siretart: shouldn't it be x11-common nowdays?
<siretart> torkel: seems so. the question is if I really have to touch the package
<siretart> but I think I have :/
<segfault> why "w" takes so long to execute now?
<segfault> real    0m2.035s
<HiddenWolf> Is todays daily-live sane?
<Evaso> hi, actually ubuntu automatically recognize new installed hard-drive?
<HiddenWolf> Evaso: #ubuntu
<Evaso> HiddenWolf: i want only know for backporting to debian is not a support request :)
<mdke> Evaso, #ubuntu might be able to help
<Evaso> i try it
<mdke> ok
<Evaso> mdke: seems that also ubuntu needs to manually mount or edit /etc/fstab for new hard-drive
<siretart> Evaso2: yes
<Evaso2> This is a problem for some newbie that after come back to computer assistance doesn't find his new hard drive in ubuntu
<siretart> right
<siretart> but what should be done in case a new hard drive is inserted?
<siretart> the user is expected to partition and create filesystem on it
<Evaso2> why doesn't let the disk manager of gnome-system-tools the let you to mount new harddrive 
<siretart> I don't expect newbies to even understand what this means and how to do it
<Evaso2> also to interact with fstab
<siretart> it does? really?
<Evaso2> yes it let to mount new haddriwe because is scan devices
<Evaso2> and not fstab
<siretart> interesting
<Evaso2> also gparted (gtk gui) 
<siretart> yes
<Evaso2> let to partition new harddrive because scan devices
<siretart> if you really care about this, could you please write a spec documenting what should be done in this case?
<siretart> because I think this really needs more discussion
<Evaso2> i could but my english is not at the level of an human understendable spec :)
<mdke> do it in your language, and ask someone on a local community team to translate it
<mdke> or correct it
<Evaso2> where i could to post the english version?
<mdke> Evaso2, on the wiki
<HiddenWolf> mdke: launchpad?
<mdke> Evaso2, on the wiki, create a new page using "SpecTemplate" and then you can make a spec entry in launchpad if you wish
<Chipzz> *sigh*
<Chipzz> who to fuck was smoking what on earth when they invented the seriously crakpotted idea of /var/run and /var/lock mounted as a tmpfs?
<HiddenWolf> aren't those supposed to contain only temporary information?
<Chipzz> they stay mounted after boot
<Chipzz> WORSE
<Chipzz> they get mounted after booting a kernel without initramfs!
<Chipzz> $#%$## !
<siretart> ?
<Chipzz> I have a kernel compiled with make-kpkg, without the need for any initrd/initramfs at all, and it breaks horribly :/
<Chipzz> e2fsck output getting spewn over the console with brown * beside it (like the failed stuff), network not starting up at all...
<siretart> Chipzz: try asking the guys in #ubuntu-kernel. 
* raphink is sorry for the spam yesterday. My connection is back to a normal state now.
<Mithrandir> mdke: sorry, haven't gotten around to uploading it yet.. been out skiing today.  I'll try to get to it on Monday.
<jsgotangco> hi guys
<HiddenWolf> who is the livecd guy?
<xhaker> might be the casper wizard
* Mithrandir calls down a lightning bolt to strike HiddenWolf
<Mithrandir> HiddenWolf: 'sup?
<jsgotangco> heh
<HiddenWolf> Mithrandir: works fine here, but the blue loading bar and the "loading linux" with lotsa dots message really have to go.
<Mithrandir> what blue loading bar?
<HiddenWolf> right after the menu.
<Mithrandir> HiddenWolf: the "loading linux" messages come from the kernel.
<Mithrandir> oh, that one.
<HiddenWolf> there is a windows-like popup loading bar, dissapears in a bit.
<Mithrandir> they have nothing to do with the live cd, it's a bootloader thing.  Fight over it with Kamion
* HiddenWolf swings a fat club at Kamion ( Mithrandir told me to)
<HiddenWolf> Mithrandir: and networking didn't come up, but I guess that's known. ;)
<Mithrandir> HiddenWolf: that's known, yes.  I'm blaming Scott for that one.  I guess we'll find a solution to that at the distro sprint.
<HiddenWolf> Mithrandir: make the kernel messages go, or land behind the menu or something. Spoils the good impression.
<Mithrandir> HiddenWolf: if you want the "loading linux" thing to go away, you have to convince BenC, not me.
* HiddenWolf swings a club at BenC_ too (before Mithrandir tells me to)
<lamont> mozilla, gnucash given back
<Mithrandir> mdz: regarding 29223, our livefs is about a week old, it doesn't have any of the one-true-path stuff in it.
<mdke> Mithrandir, ooh nice. thanks
<ryanpg> updated dapper, Xorg.0.log says:
<ryanpg> (EE) Failed to load /usr/lib/xorg/modules/extensions/libGLcore.so
<ryanpg> (EE) Failed to load module "GLcore" (loader failed, 7)
<ryanpg> known bug? or should I file one?
<azeem> did you check whether it is known?
<ryanpg> azeem, I'm still getting the hang of launchpad/malone whatever
<ryanpg> so no
<ryanpg> https://launchpad.net/distros/ubuntu/+bugs?field.searchtext=libGLcore.so&search=Search&orderby=-priority%2C-severity turns up nothing but who knows If I searched correctly
<ubuntu_> anyone knows whats the package for network-admin? I want to fill a bug for dapper
<thierry_> anyone knows whats the package for network-admin? I want to fill a bug for dapper
<crimsun> thierry_: use http://packages.ubuntu.com 's search
<thierry_> thanks
<winkle> thierry_: gnome-system-tools
<thierry_> crimsun, winkle : if you want to check the bug, its 29314 on launchpad... very strange one
<HiddenWolf> \sh_away: could you please not break planet again? :)
<mdz> Mithrandir: odd, I wonder why a) I haven't received any livefs build failure notifications (lamont/infinity?), and b) why the PATH changed
<lamont> mdz: checking. any == no arch built?
<lamont> mdz: stale lock file... removed, I'll have to track down why the previous build died without removing it though...
<alinux_> hello boys :)
<alinux_> I'm searching for pitti
<mdke> AlinuxOS, you'll find him here monday to friday
<AlinuxOS> mdke, thanks :)
<\sh> actually it's weekend nobody should work today, only totally screwed people like me...who are upgrading gentoo boxes 
<mdz> lamont: thanks
<AlinuxOS> how can I definite a default language  with locale?
<AlinuxOS> sudo dpkg-reconfigure locales dosen't work anymore like in breezy.
<AlinuxOS> I'm using dapper in this moment.
<lamont> mdz: anything you want/need before I disappear for several hours?
<mxpxpod> has anyone seen multiple syslog processes getting launched in dapper?
<mxpxpod> I had like 20 running just a moment ago
* lamont back in many hours
<taomaster> any easy way to install java?
<mdke> taomaster, try #ubuntu or search the wiki
<taomaster> ok  thanx
<mxpxpod> I just logged into gnome on dapper and it's not recognizing any of my settings
<mxpxpod> I have all of the defaults
<HiddenWolf> mxpxpod: #ubuntu
<dilinger> <dilinger> rock!
<dilinger> <dilinger> i just upgraded to the latest initramfs/kernel packages in dapper
<dilinger> <dilinger> it looks like it fixed all the udev problems
<dilinger> <dilinger>  /dev/null and friends now even have the correct permissions
* dilinger figured that was more applicable to this channel
<mxpxpod> dilinger: what arch?
<dilinger> mxpxpod: amd64
<mxpxpod> dilinger: hmm
<mxpxpod> dilinger: after you upgraded, did you run anything?
<dilinger> nope
<dilinger> just rebooted
<mxpxpod> dilinger: I still have udev problems... plus I have a gconf problem now
<dilinger>   487  sudo apt-get install linux-restricted-modules-2.6.15-13-amd64-k8  initramfs-tools busybox-initramfs
<dilinger> + linux-image-amd64-k8
<dilinger> i left the rest alone
<ryanpg> I have udev problems too, gnome-volume-manager perhaps also
<ryanpg> USB storage devices no longer show up on the desktop... they do in computer:/// though
<ryanpg> quite odd
<mxpxpod> ryanpg: I can't log into gnome right now
<ryanpg> mxpxpod, you win
<segfault> any idea on why "w" takes so long now to run?
<mxpxpod> ryanpg: it's like gconf is hanging
<ryanpg> mxpxpod, when that's happend to me before I've moved .gconf and .gnome2 to a temporary locatoin
<mxpxpod> ryanpg: except that I'd like my settings to be saved...
<ryanpg> mxpxpod, move back one part at a time and see what breaks? :)
<mxpxpod> ryanpg: heh
<ryanpg> mxpxpod, I've really done that
<mxpxpod> ryanpg: no dice
<ryanpg> mxpxpod, ?
<mxpxpod> ryanpg: I moved them and it still hangs
<ryanpg> ic
<ryanpg> mxpxpod, well maybe you should ask in #ubuntu then :(
<mxpxpod> ryanpg: somethings really strange with dapper... I know that when I reboot, /etc/init.d/dns-clean fails to run and I have to create /var/run/pppconfig before it will work
<ryanpg> mxpxpod, yeah I found that too
<jc-denton> hi all
<jc-denton> did anybody here already try to build beagle
<mxpxpod> ryanpg: and with the latest kernel, I can't get a sound device
<ryanpg> mxpxpod, I roll my own
<mxpxpod> ryanpg: I used to, but I don't have time anymore ;)
<torkel> jc-denton: you will probably have better luck asking in #ubuntu-motu
<jc-denton> well i'm trying to build it
<dilinger> why is lm-sensors always on crack? :(
<mxpxpod> ryanpg: hmm, ok, this is strange... I'm getting a wierd error in my .xsession-errors file...
<dilinger> -5V:       -3.74 V  (min =  +4.85 V, max =  +4.45 V)       ALARM
<dilinger> who writes this crap?
<jc-denton> but i always get this error with ./configure
<jc-denton> checking for mono.pc... configure: error: missing the mono.pc file, usually found in the mono-devel package
<jc-denton> i think i forgot something
<jc-denton> but i have no idea what
<mxpxpod> jc-denton: wait, you have mono working?
<torkel> do you have libmono-dev installed?
<jc-denton> i thik
<jc-denton> torkel: not sure
<jc-denton> well monodevelop works
<jc-denton> ah ok
<jc-denton> that was missing
<mxpxpod> man, powerpc gets the short end of the stick
<Mez> jdub: ping
* Mez wonders why planet.ubuntu.com = the blog of dholbach
<mdke> it is because livejournal set the feed to all have the same date
<jc-denton> ouh
<jc-denton> checking for MONO... configure: error: Package requirements (mono >= 1.1.10) were not met.
<mxpxpod> jc-denton: yeah, I get that too
<jc-denton> i've got only mono 1.1.8.3
<jc-denton> :(
<jc-denton> is there a way to get a newer mono?
<torkel> 1.1.13 is in dapper
<jc-denton> i have breezy
<jc-denton> and i cannot setup dapper right now
<torkel> try to find a backport of it maybe?
<Mithrandir> mdz: I don't know how livefs build failures are communicated?
<jc-denton> i had one but it was completely broken
<Den> Mithrandir: U here???
<Den> Hi all - anyone know if Mithrandir is around?  whois sho's he's beewn idle 6 min
<tseng> Den: he was here just before you joined, maybe your enthusiasm scared him off? :)
<tseng> jc-denton: building things from source isnt really the aim of this channel 
<jc-denton> tseng sry
<jc-denton> but the people in #ubuntu didn't seem to have a clue
<tseng> http://apt.filefind.net/
<tseng> you can try this for mono backports
<tseng> but I in no way support it
#ubuntu-devel 2006-01-27
<jc-denton> thx
<mxpxpod> tseng: do you use spamassassin?
<tseng> mxpxpod: no, i got tired of fooling around with all that stuff
<tseng> gmail does it for free
<mxpxpod> tseng: heh
<tseng> without draining my time and server resources
<mxpxpod> tseng: no, I meant on your client
<mxpxpod> with evo
<tseng> oh, definately not
<tseng> i have 5 pcs between work and home, client side anything is out
<mxpxpod> heh
<tseng> dinner
<tseng> mxpxpod: cya
<Den> tseng: Ahhh - I was just told the same thing in real life!!!
<Den> Anyone know if the  dapper daily live iso built properly today?  I see the timestamp on the archive is today. Is there any way to tell if the build completed properly?
<jc-denton> humm
<jc-denton> i upgraded
<jc-denton> but now i get this: http://rafb.net/paste/results/huKDEI45.html
<jc-denton> well i'll probably try later
<jc-denton> but first thx a lot for help
<AlinuxOS> alive?
<kent> hmm.  the new update manager by michael vogt seems to ask me for my root-password, which i dont have enabled on a default breezy.  Running with sudo seems to work though.
<johnl> i386 flight cd3 b0rks on boot for me (well before any gui might appear) with "no record for /block/ram0 in database" messages followed by  "can't access tty" message.  this is with an external usb cd drive.
<johnl> this a known issue?  I see mention of initramfs broken in the topic...
<johnl> on an ibm x40 laptop
<shaya> anyone around
<shaya> can someone try typing 44 - 44 (enter) in gcalctool and see if it works?
<shaya> wondering if I'm going nuts
<kent> 44-44 is 0 in my gcalctool. :)
<LaserJock> is xserver-common gone for good? should we replace build-deps with x-common instead?
<tseng> x11-common, no?
<LaserJock> tseng: ok, yeah. Why does that keep changing?
<tseng> x-commono + xserver-common = x11-common
<LaserJock> oh, ok
<shaya> kent: hmm, something must be wrong, keep getting invalid expression
<shaya> malformed expression that is
<kent> shaya, this is not supportchannel. ask in #ubuntu.  (and are you sure you are typing in the correct expressions then?)
<shaya> yes
<shaya> weird
<shaya> unsure
<shaya> not asking for support
<shaya> I guess I dont understand what the "use arithmetic precedence" option means
<shaya> as it messes things up
<kent> if you dont know what it is, why are you using it then?
<shaya> good Q, wondering how it got set
<shaya> I assume it lets you right an entire equation
<shaya> but a normal x-y (enter) doesn't work with it enables
<shaya> but works fine without it enabled
<shaya> just dont see the entire equation
<Mez> doko: ping
<psusi> isn't partman the partitioner used in the setup cd?  why doesn't it have a -udeb target package?
<Mez> Kamion, ping
<StevenK> doko: Any plans to upload a vnc4 that doesn't FTBFS? Since it should also stop depending on xserver-common.
<Mithrandir> Den: now I am.
<Den> Mithrandir: Hey! (I gotta find out how to get Konversation to beep me when I'm mesaged)
<Den> Mithrandir: Anyway  - how's the iso build going?  I saw the timestamps updated in dapper-live, and did an rsync, which only dl's about 500KB, iirc.
<Den> Mithrandir: but I didn't get an email from you yet, so I was waiting a bit in the hopes I'd ge an email, & would know if the iso built ok & I should burn it & try it.
<Mithrandir> Den: yeah, image still failing to build; some xine stuff is uninstallable.
<Mithrandir> Den: the timestamp is misleading.  It uses the last successfully built image.
<Den> Mithrandir: Ah. .... 1) do you have ian iso I can dl directly from you (as we tried last week)
<Mithrandir> Den: no, sorry
<Mithrandir> Den: though, I verified that the image booted on my machine with an ieee1394 drive, so it should be good to go.
<Den> Mithrandir: 2) Is there a way I can look at the dapper-live-iso webpage & tell by myself if it built ok (so I can know I should try to rsync & burn & try)?
<Den> Mithrandir: Can I get that iso from you that you verified worked ok?  (Is that the question you said "no" to?)
<Mithrandir> Den: it's on a machine in the office, I can give it to you tomorrow.
<Den> Mithrandir: Ok, that's fine.  Will    you email me & le me know the details of the dl link, & anything else I should know?
<Den> Mithrandir: Cant you ssh into your office machine & set up a link for me to dl from?
<Mithrandir> Den: sure
<Mithrandir> Den: no, I don't have ssh through the FW enabled.
<Den> Mithrandir: I am shocked! :)
<Den> Mithrandir: BTW, iirc, you're in Norway. & you work for ubuntu. & cannonical is ubuntu.  & cannonical is in isle of mann.   & is that where your office is?
<Mithrandir> Den: my office is just downtown here in Oslo.
<Den> Mithrandir: Is that an ubuntu office?
<Mithrandir> Den: the people working from Canonical are mostly working from home, but I and a some of the UK people are working from a real office.
<Mithrandir> Den: no, it's a company I helped start a few years back and I still do occasional sysadmin stuff for them.  In return, I have my workplace there.
<Den> Mithrandir: Also, how come you are able to get the iso to build at your office, but it won't build on the dapper-live iso server?
<Mithrandir> Den: because on the server, I can't do evil tricks and upgrades, it's a fresh install
<Den> Mithrandir: is it a matter of on your system you cut out the bad parts that block the build on the iso at the server?
<Mithrandir> Den: http://people.ubuntu.com/~cjwatson/testing/dapper_probs.html ; if you look at that page, ubuntu-desktop is uninstallable.  As long as it stays that way, new live fs builds will fail.
<Den> Mithrandir: Remember about a week ago we discussed a bit about that "base" system, and was there a way to build that into a bootable iso.  I think we stopped talking about that cause you thought the reqular dapper iso was about to be properly built.  Givne that that looks unlikley right now, is it possible to build that "base" iso, so I can a) make sure the boot from firewire scsi cd works, and then when that's ok, b: try the latest ker
<Den> ile on external disk - disconnected" problem BenC told me to get the latest kernel for.?
<lifeless> doko: around ?
<Mithrandir> Den: yes, it's possible, no, I can't do it.  If you download an ISO, replace the casper/filesystem.squashfs file on it with the base file you downloaded, that should work.
<Den> Mithrandir: Please clarify:
<Den> Mithrandir: 1) You cant do it cause it's impossible, or work constraints, or???
<Mithrandir> Den: because I'm not the one who has set up the cd build system.
<Den> Mithrandir: 2) If i dl _which_ iso?  From _where_?  Replace the file with _what_ "base file I dld"?
<Mithrandir> Den: I'm sorry, but it's a sunday for me and I don't have time for hand-holding you through the process of rebuilding an ISO image.
<Den> Mithrandir: Can you, & would it be worth it, for you to get whatever is needed to do it?
<Den> Mithrandir: Ok.  May I save those questions for your work day, & ask you then?
<doko> lifeless: good morning
<doko> Mez: pong
<doko> StevenK: hmm, not really. the current one includes it's own XFree86 source, needs to be changed to use the xorg server
<Mez> doko: is libstdc++5 going to be removed from ubuntu ?
<doko> Mez: for dapper it probably will stay in universe
<Mez> doko: I'm jsut wondering - as I've come across a package that is in non-free (rar) that requres libstdc++5 (binary package!)
<doko> Mez: that probably should be rebuild using the default g++
<Mez> doko - upstream havent done it yet
<Mez> and they dont distribute the source
<Mez> damn non-free
<zyga> hello
<pef> hello
<lifeless> hey doko
<ajmitch> evening
<lifeless> so I wanted to chat about the python install method/policy
<lifeless> I had a semi-flame chat on debian-devel a few weeks back, which actually resulted in a good idea or two
<lifeless> hey ajmitch 
<Mez> hmm
<Mez> does anyone on here have a seen script?
<Mez> !seen infinity
<doko> lifeless: yes, and the the current one on debian-python
<lifeless> doko: I guess I should read that ;)
<lifeless> doko: I was thinking I could run the core of what came up past you and then you'll know
<doko> I have to run now, let' try to make it this evening (UTC)?
<lifeless> rather than me getting deep into it
<lifeless> tomorrow morning UTC perhaps ?
<lifeless> I have a late night tomorrow due to back to back meetings from 9-10 UTC and 11-12 UTC
<lifeless> so 10-11 UTC - anytime in there 
<doko> lifeless: would be fine, I have to get a new passport before, not sure if I'm excatly back at 10
<lifeless> k
<irvin> mvo
<zyga> any rosetta devs around?
<mdke> seems that the link to planet on the wiki (planet.ubuntulinux.org) goes to the fridge (jdub)
<Mez> elmo: just to let you know I'm now recieiving katie emails again - so forget about trying to fix it - it seems to have fixed itself now I'm on a new host - I guess i had something wrong on my old one
<sivang> anybody see pitti, tell him I am looking for him :)
<tseng> sivang: it is sunday
<sivang> tseng: yes I know, he rarely, but do comes online on sunday , so I tried my luck
<irvin> sivang, here comes pitti 
<Tm_T> run! hide!
<Tm_T> err
<Tm_T> irvin: thanks for warning, we're secure now
<pitti> hello everybody
<sivang> pitti: hi! :)
<psusi> how is it that partman, which is used by the setup cd, has no udeb?  it's control file only builds a non udeb target
<azeem> psusi: there are several other partman-* packages with .udebs I believe
<azeem> unless things have changed at some point
<psusi> apt-cache search partman shows only the one
<azeem> does apt-cache return .udebs?
<psusi> wait... damnit... yea, I need it to search for source packages, not binaries
<psusi> hrm... how do you do that?
<azeem> grep-dctrl or something, maybe
<psusi> and... why is it broken up into more than one source package anyhow?  rather than one source that builds both binaries?
<azeem> no idea
<psusi> looks like apt-cache -s search partman should do it... but it's being a jackass and saying partman is an invalid operation
<psusi> like it's treating it like a command instead of a parameter to the search command
<psusi> nevermind...
<torkel> psusi: drop '-s'
<psusi> torkel, I thought it was to ask it to search for source packages... it isn't... I'm trying to get it to search for source packages
<torkel> psusi: -s is not for searching source packages
<pabs3> hi all, should I be surprised that launchpad isn't in sync with packages.ubuntu.com? for example http://packages.ubuntu.com/dapper/source/xchat https://launchpad.net/distros/ubuntu/+source/xchat
<psusi> torkel, right... that's what I just said... so how DO you search on source packages? :)
<azeem> 16:52 < azeem> grep-dctrl or something, maybe
<psusi> I don't have a control file to grep, that's the point, I'm trying to find the source file which contains the control
<psusi> s/file/package
<psusi> wait...
<Chipzz> psusi: apt-cache show $package
<Chipzz> or dpkg -s $package if it's installed
<psusi> Chipzz, I don't know the name of the package, I'm searching for it...
<Chipzz> what do you know?
<psusi> I know partman is used in the setup cd, but when I apt-get source partman, it gives me the sources only for the non udeb package... which is weird... someone sugested that there's a seperate source package for the setup udeb
<psusi> so I'm looking for source packages that contain partman in their name ;)
<mdke> pef_aw, i can hibernate here now
<mdke> it's slow, but it works
<pef> mdke: have you changed something special ?
<mdke> upgraded
<pef> mdke: new kernel or acpi-support package ?
<mdke> oh damn wrong channel
<towolf> Salve, how do I get /proc/bus/usb/* back?
<towolf> oh, usbfs isn't mounted? well...
<matchthis> must go today message me if interestedon aim at mikcomputing, msn at mcsltd3@hotmail.com or yahoo at mcsltd2 only if your interested and want to buy! .  prices are 550 each includes shipping case and wireless router.2 alienware products, 1 area51-m 5700 notebook, and one area51 7500 desktop tower system.  
<moyogo> hi
<moyogo> there's a license problem with a font package
<Kamion> Mez: yes?
<moyogo> the ttf-arabeyes packages uses Bitstream Vera glyphs for Basic Latin characters
<moyogo> but ttf-arabeyes is GPL
<moyogo> it should be BitStreamVera License + GPL
<irvin> mvo: ping?
<mvo> irvin: pong
<irvin> mvo: about the update-manager... http://netgarage.thefluxproject.com/dump/shots/ubuntu/update-manager/wtf.png
<mvo> irvin: "proud peacock" is a test-distro that should never be shown
<mvo> I assume you use my backport for update-manager?
<irvin> mvo: yes i was testing it last night and two days before that. 
<mvo> irvin: and you got that instead of 'dapper'? did it happen on dapper? or breezy?
<irvin> mvo: i did get "dapper".
<Amaranth> lmao
<Amaranth> New distro release codename 'cock'
* Amaranth dies
<irvin> mvo: i was on breezy then. 
<mvo> Amaranth: the  "proud peacock" release 
<mvo> irvin: then you moved to dapper and got the other one?
<irvin> mvo: no. i was planning to upgrade to dapper last night using update-manager but i got that instead :(
<mvo> irvin: so you are still on breezy?
<irvin> mvo: not anymore. i couldn't wait to i popped in a cd and upgraded. 
<irvin> mvo: i'm gonna test your script generator on synaptic =)
<mvo> irvin: I see, I think I know what happend. after you upgraded lsb-release update-manager was assuming you run dapper and checked if there is another upgraded distro release available, it found one (my test-entry) and offered a upgrade
<mvo> it's a bug in the update-manager, because it shouldn't allow upgrades to "unsupported" distros (it's flaged unsupported in my test-meta-release file)
<mvo> irvin: please do that and let me know if it works well :)
<mvo> I'll fix that tomorrow problem with the upgrade tomorrow, sorry for the strangness involved 
<irvin> mvo: there was one minor issue though, i had mirrormax backport previously on my (breezy) sources.list, the update-manager died with an error because it couln't find a 'dapper' release on mirrormax
<mvo> irvin: thanks, can you please mail me your (old) sources.list? it should be available in /etc/apt/sources.list.distUpgrade
<Amaranth> irvin: mirrormax backports are dead
<Amaranth> irvin: and this is why 3rd party repos are bad :P
<mvo> irvin: I'll fix that issue then too. some people had trouble with the missing "dapper-backports" componenet in the current archive.ubuntu.com
<mvo> Amaranth: update-manager tries to detect and disable them ;)
<irvin> mvo: yes that one too.
<mvo> irvin: please send me your sources.list. did the upgrade otherwise worked? or did you just use the cd after it failed initially?
<irvin> i'll email you my old sources.list
<irvin> mvo: i used the cd last night, but two days ago it was working.. here are some screenshots: http://netgarage.thefluxproject.com/dump/shots/ubuntu/update-manager
* mvo wonders if ff is crashing for everyone (on amd64) every 5 minutes or only for him
<mvo> irvin: would you mind to send me the ~/dist-upgrade.log and ~/dist-upgrade-apt.log as well then? I'm trying to gather some data about the packages that are upgraded/removed etc to see if it makes the right decisions
<mvo> irvin: thanks for that link with the screenshots :)
<irvin> mvo: ok. i'll send them as well
<mvo> btw, do you think it should automatically disable sources in the sources.list it wasn't able to fetch? 
#ubuntu-devel 2006-01-28
<irvin> mvo: i think so yes. otherwise, we need to start update-manager again
<mvo> I think I'll add that to the next version, thanks
<kent> mvo, would you want my dist-upgrade.log and dist-upgrade-apt.log?  I ran it but it failed first becaus of it couldn't download two or three files (which synaptic and apt has failed some time before, probably becaus of the server and my netspeed) but the second time it downloaded everything but failed when wanting to overwrite some file with coreutils.  It seems like it has nothing to do with the update-manager and instead to do with dapper-pro
<kent> blems..
<mvo> kent: thanks! yes, I would be interessted in the files (it includes the upgraded package information, I'm interessted in those). 
<mvo> it seems to me like it should auto-retry to fetch failed files at least two or three times 
<mvo> I got another report about that before
<kent> mvo, il send you the files now then.  just a second or two..
<mvo> kent: thanks! I'll have a close look tomorrow, it's rather late here already
<mvo> thanks everyone for the nice feedback and testing! you are a great help!
* mvo is off to bed now
<ds> swfdec needs to be resynchronized with Debian, because the maintainer screwed it up
<jsgotangco> good afternoon
<pitti> Hi
<sivang> morning all!
* pitti hugs sivang 
* sivang hugs pitti 
* zakame hugs sivang 
* sivang hugs zakame 
<torkel> group hug :-)
<sivang> yeah :)
<mvo> hello Diziet, around?
* sivang hugs mvo 
<pitti> Mithrandir: ppc live CD (current) hangs at 'Mounting root file system', known bug?
<pitti> Hi StevenK 
* StevenK waves to pitti.
<Mithrandir> pitti: the current live cd has an ancient live fs image, so possibly.
<pitti> Mithrandir: due to u-desktop uninstallability?
* StevenK comes back after ripping his Dual Athlon to pieces and putting it back together again.
<Mithrandir> pitti: yes.  I spent most of last week not fixing that. :-/
<Den> Mithrandir: Hey Mith! How's th progress on the dapper live iso your local build?  Think it might be available today?
<Mithrandir> Den: I said I'll mail you when I have it ready, I'm still going through my email.
<dholbach> good morning
<jsgotangco> good morning dholbach 
<dholbach> good morning mr. gotangco
* sivang hugs dholbach 
<dholbach> hey sivang
<Mithrandir> seb128: my panel is acting up again.  It's not frozen, but my applications menu is gone, the applets work, but my clock applet is skewed to the right.
<mvo> Diziet: ping?
<seb128> vuntz_: around? :) (for Mithrandir's panel issue)
<seb128> Mithrandir: let's try if vuntz (who is upstream for it) has some idea :)
<janimo> ogra ping
<sivang> can anybody tell me what's wrong with that construct:
<sivang>    File "DeviceInfo.py", line 106
<sivang>      if !(self[device] ['ReadWrite'] ):
<sivang>         ^
<sivang> SyntaxError: invalid syntax
<Mithrandir> it not self[device] ['ReadWrite']  ?
<torkel> move ! inside () ?
<mdke> Mithrandir, did you upload ubuntu-docs already? we have another bug that we could fix quickly
<Mithrandir> mdke: no, I haven't uploaded yet.  I was going to do it RSN.
<vuntz_> seb128: pong
<Mithrandir> mdke: what's the other bug?
<mdke> Mithrandir, a sample/ directory is missing from the debian/install, which means that some links are broken in the Starter Guide
<Mithrandir> vuntz_: my panel is screwing up.  The applications/system/places menu is gone, my clock is skewed so only half of the MSD of the minutes is visible.
<seb128> vuntz_: hi :) Do you have any of what could do what Mithrandir described some lines up
<Kamion> sivang: use "not" rather than "!"
<Kamion> sivang: or "~" if you want bitwise negation
<mdke> Mithrandir, is trivial fix
<Mithrandir> mdke: can you give me a patch?
<Kamion> sivang: probably "if not self[device] ['ReadWrite'] :"
<mdke> Mithrandir, yeah, but I'm not very good at patches. Now is the time to learn. Where is the source again?
<seb128> Kamion: is libtotem-plparse1 waiting somewhere to be accepted/promoted? :)
<Mithrandir> seb128: it just got NEWed
<seb128> nice
<seb128> Mithrandir: should fix the instabillity issues for GNOME stuff
<sivang> Kamion: thanks a lot,getting used to use '!' for year took it's toll :)
<Mithrandir> seb128: yeah, which is why I nagged Kamion about it. :-)
<vuntz_> Mithrandir: does right-click on the panel do something?
<seb128> thank you ;)
<Mithrandir> mdke: download http://people.ubuntu.com/~tfheen/doc-fixes/ubuntu-docs_5.10-6.1.tar.gz and http://people.ubuntu.com/~tfheen/doc-fixes/ubuntu-docs_5.10-6.1.dsc ; dpkg-source -x ubuntu-docs_5.10-6.1.dsc ; move that to another place, dpkg-source -x again, do your changes in one of the directories, check that it builds nicely, do a diff -ru directory1 directory2 and put that somewhere I can get at it.
<Mithrandir> vuntz_: it focuses the panel, but nothing more, no.
<vuntz_> Mithrandir: you might also want to attach the panel with gdb and interrupt it to get an idea of what it's doing
<mdke> Mithrandir, ok i'll try that thanks
<vuntz_> Mithrandir: 'focus the panel'?
<Mithrandir> vuntz_: alt-f3 (which usually focuses my deskbar-applet) also loses focus from the current window, but without focusing deskbar-applet.
<Mithrandir> vuntz_: my pterm loses focus.
<vuntz_> you shouldn't be able to focus the panel by clicking on it
<vuntz_> weird
<vuntz_> is this 2.13.5 ?
<vuntz_> and are you using metacity?
<Mithrandir> no, using openbox
<vuntz_> ah
<Mithrandir> ii  gnome-panel    2.13.5-0ubuntu3 launcher and docking facility for GNOME 2
<Ubugtu> Error: Error getting Gnome bug #2: NotFound
<vuntz_> if you can attach to the panel with gdb and get some stack traces to know what it's doing, please do so :-)
<Mithrandir> http://pastebin.com/518809
<vuntz_> do you know when it started to happen? and what you were doing at this time?
<Mithrandir> unsure, but it's not the first time.
<vuntz_> apt-get install gnome-panel-dbg :-)
<Mithrandir> last time, it went away for a while when I killed it.
<seb128> gdm_new_login() ?
<vuntz_> (stack trace is corrupted)
<seb128> vuntz_: what does it do with gdm stuff?
<Mithrandir> vuntz_: http://pastebin.com/518827
<vuntz_> Mithrandir: cool
<Mithrandir> vuntz_: i386, btw.
<vuntz_> Mithrandir: please open a bug in GNOME bugzilla and attach your ~/.recently-used file there
<vuntz_> you can move away this file to fix the problem
<vuntz_> hrm
<seb128> Mithrandir: if you have no GNOME account open a malone bug, I'll forward
<Mithrandir> seb128: thanks.
<vuntz_> do you always get this stack trace when you interrupt it?
<seb128> np
<vuntz_> it might mean your ~/.recently-used file keeps being rewritten
<Mithrandir> vuntz_: http://pastebin.com/518828 is the new one.
<mvo> notify-damon changed the name again to notification-daemon
* mvo weeps
<vuntz_> (or maybe gnome-vfs is buggy and sends a lot of events)
<Mithrandir> vuntz_: it's not changed in the last two hours according to stat(1)
<vuntz_> does renaming the file help?
<Mithrandir> as in, the panel should just fix itself without further ado?
<pitti> Mithrandir: did you upload the esound fix yet? I want to do an upload of esound (changing shlibs), but don't want to interfere with yours
<Mithrandir> pitti: no, I haven't.  I can give you the patch?
<vuntz_> Mithrandir: well, it might just fix the issue, yes :-)
<pitti> Mithrandir: works for me, thanks
<Mithrandir> vuntz_: well, it haven't fixed itself yet, at least.
<Mithrandir> pitti: 'k, I'll find it and put it somewhere for you.
<Mithrandir> also, gnome-vfs should grow a multi-hop syntax similar to what tramp uses.
<Mithrandir> so you can use ssh-over-ssh transfers.
<Mithrandir> vuntz_: is there any more useful debug info I can give you, apart from my .recently_used?
<Mithrandir> s/_/-/
<vuntz_> Mithrandir: you can strace the process and see if it opens ~/.recently-used a lot of times
<Mithrandir> vuntz_: seems to be locked on a futex.
<vuntz_> ah
<hunger> Damn, I am stupid! Just spend 30min researching why my fan was making so much noise and then realized it is the dishwasher running.
<chmj> lol
<Mithrandir> lamont: if you could please give-back rhythmbox and gnome-python-extras, that'd be appreciated.
<janimo> pitti, do language-pack-XX mo files have priority over the ones installed by specific packages?
<pitti> janimo: no, the other way round
<janimo> pitti, thanks. and there's no easy way to reduce this duplication of files when they are the same right?
<lucas> hi
<pitti> janimo: normally there shouldn't be much duplication
<pitti> janimo: only if a universe package got moved into main and has never been rebuilt since then
<janimo> pitti, do language-packs contain only mo files which are not yet installed by specific packages then?
<pitti> janimo: no, they contain all mo files from packages which were in main at the time of the langpack generation
<vuntz_> Mithrandir: I'm not sure, but being locked on a futex in the libc looks like a libc issue to me
<pitti> elmo: please sync crawl (universe, security update)
<janimo> pitti, bu duplication I meant that both a package and the langpack seem to contain the same .mo file
<Mithrandir> vuntz_: or something in gnome doing something it shouldn't in a signal handler.  I saw the same issue in gzip some time ago, but that was on an SMP system.
<pitti> janimo: yes, that will happen in the corner case I mentioned above
<janimo> pitti, for instance langpack-ro has mo files for dpkg sed aptitude ie all main packages since the beginning
<janimo> does it mean the langpack was not regenerated ?
<vuntz_> Mithrandir: possible, although I don't think there are any signals involved here
<pitti> janimo: erm, where's the problem? all of these packages are in main, so their translations should be in the langpack
<Kamion> dpkg and aptitude at least are explicitly excluded from stripping because they're used in the installer before language packs are installed
<pitti> ah, yes
<Kamion> so their translations will indeed be duplicated; that's intentional
<pitti> I should probably blacklist them in langpack-o-matic
<Kamion> well, it's good to get updates for them
<janimo> pitti, no  problem at all I just do not understand whether some mo files are supposed to be installed by both the packages and the langpacks
<Kamion> I don't think langpack-o-matic needs to blacklist them
<janimo> I see so only the ones used by th e installer have two .mo versions, thanks
<Mithrandir> seb128: what description do you want for the bug?  "gnome-panel seems to hang randomly, attaching ~/.recently-used as per IRC discussion"?
<Kamion> pitti: we can probably take some of those packages out of the blacklist now that we're using a single-stage installer, actually
<Kamion> pitti: at least base-config and passwd can be removed
<Kamion> (but at your leisure, no urgency)
<pitti> Kamion: what about debconf-i18n and apt?
<vuntz_> Mithrandir: I think there's a libc6-dbg package, so if you can install it... :-)
<Kamion> pitti: translations for apt are still needed in the event that the language pack isn't available on install media
<pitti> Kamion: oh, I rather do it now, it's trivial
<Kamion> pitti: and I think likewise debconf-i18n
<pitti> ok, alright
<seb128> Mithrandir: yep that's fine, thank you
<Kamion> and iso-codes translations are needed at installer build time
<seb128> Mithrandir: put the backtrace too the bug too :)
<Kamion> so yeah, I think it's just base-config and passwd
<pitti> alright, I upload now
<Mithrandir> vuntz_: sure, after lunch.
<mdke> Mithrandir, diff is here: http://mdke.org/debs/ubuntu-docs.diff Just building it now, but I don't envisage it will have any problems
<mdke> Mithrandir, ok it builds
<mdke> Mithrandir, lemme know if there are any problems :) thanks
<janimo> Kamion, what other files are required to be created for a xubuntu CD, but which are not part of regular deb uploads?
<janimo> I think you said the gfxboot logo is one like that
<mdke> Mithrandir, oh no, stop the press, that's wrong
<Kamion> janimo: yeah, I'll create that though
<janimo> Kamion, thanks so that's the only one?
<Mithrandir> mdke: coolie; I'll just check the packages a final time, then upload.
<mdke> Mithrandir, no hang on, I need to do you another diff
<Kamion> janimo: it's the only one I can think of right now, certainly
<mdke> Mithrandir, that one was crap
<Mithrandir> mdke: *sigh*, ok. :-/
<mdke> disregard it entirely
<mdke> sorry
* Mithrandir hugs patch -R
<ssdo> how implemented is gstreamer0.10 in dapper flight3? I have in my synaptic both gstreamer0.8 and the gstreamer0.10, which among them i am using?
<dholbach> ssdo: both
<dholbach> ssdo: some packages didn't make the transition yet
<ssdo> ok...so gstreamer0.10 then is not that ported in dapper 3 then...
<dholbach> ssdo: yes, some pieces are not ported yet
<HiddenWolf> ssdo: totem, sj and rhytmbox use 0.10, the rest uses 0.8
<HiddenWolf> afaik
<ssdo> my rythmbox does not play mp3 format...hows this?
<HiddenWolf> Because it's not fully ported, and/or you'r missing codecs
<HiddenWolf> Then again, don't use mp3 where you can avoid it.
<ssdo> ok...so for now if I want to play mp3's i will have to use beep or xmms...
<dholbach> ssdo: check the gstreamer plugins you have installed.
<ssdo> hiddenwolf: yes..i am converting many of them into oggs. read in the forums about coverting mp3s to oggs..
<dholbach> But this is more of a #ubuntu discussion.
<ssdo> ok sorry for intruding...be back to #ubuntu discussion,,,
<ssdo> thanks a lot
<dholbach> Don't worry. :)
<mdke> Mithrandir, ok http://mdke.org/debs/ubuntu-docs.diff is right. 1000 apologies
<Mithrandir> mdke: ok, you're happy now?
<mdke> Mithrandir, very
<Chipzz> evolution-plugins, gnome-applets, python-gst and serpentine are the packages I have installed that still need to be ported
<Chipzz> but more importantly: gstreamer 0.10 has allmost no plugins yet
<seb128> Chipzz: gstreamer0.10-python has been accepted 10 days ago
<seb128> Chipzz: gnome-applets/serpentine have patches/have been ported upstream
<seb128> and the evo plugin is a detail
<Chipzz> # apt-get install gstreamer0.10-python
<Chipzz> Reading package lists... Done
<Chipzz> Building dependency tree... Done
<Chipzz> E: Couldn't find package gstreamer0.10-python
<Chipzz> or am I doing something dumb? ;P
<dholbach> Chipzz: accepted 10 minutes ago.
<Chipzz> ah minutes, not days ;P
<seb128> Chipzz: source package != binary package ...
<dholbach> oh, /me misread
<seb128> Chipzz: sudo apt-get install python-gst0.10
<seb128> Chipzz: apt-cache search gst python too
<seb128> apt-cache can be useful
<seb128> (I'll not comment on the dumb part :)
<Chipzz> seb128: ah ok now I see... serpentine uses python-gst
<Chipzz> it's early for my - brain not fully booted yet
<seb128> when I say "upstream" that's to make the difference with the distro
<Chipzz> I know what upstream is ;)
<Chipzz> what I wanted to point out was that serpentine doesn't need a recompile if you rename python-gst0.10 to python-gst (which you probably cant do :P)
<seb128> that's a wrong assumption
<seb128> the API have changes
<seb128> changed
<seb128> that's not a matter to use one of the other, you have to rewritte the code
<Mithrandir> mdke: ok, ubuntu-docs as well as kubuntu/edubuntu stuff uploaded to breezy-updates.
<seb128> so to Depends on one specific version
<Chipzz> I know about api changes, but most of them should be transparant, no?
<seb128> no
<Chipzz> ;)
<HiddenWolf> Chipzz: check the bugs on gnome bugzilla to see how much trouble it is. :)
<mdke> Mithrandir, you are truly a wizard, thanks so much for doing that
<Mithrandir> mdke: let's just hope I didn't make it all blow up in interesting ways first. :-)
<mdke> Mithrandir, i'm sure it is fine. Do we need to get someone to remove my previous upload to breezy-updates (via dholbach) of that package?
<mdke> maybe it is already deleted
<seb128> Chipzz: the patch for serpentine to change from python-gst to 0.10 is a 589 liner
<Mithrandir> mdke: not if it was rejected.  I'll see if I see a reject soon
<Chipzz> ieks
<mdke> Mithrandir, it was uploaded in december but I don't know whether it was rejected or not
<Chipzz> I'ld expect a smaller patch for a high-level language like python
<janimo> pitti, when I talked about duplication I wasn't aware of pkgstriptranslations and that .debs are stripped of mo files. Now the picture is a bit clearer :)
<seb128> Chipzz: API change is API change, whatever the language is
<janimo> any hope that mozilla and ooo will use gettext?
<lifeless> seb128: so how do I unbreak my gnome icons ?
<seb128> lifeless: what is broken?
<lifeless> volume control, show/hide all windows, trash
<Mithrandir> mdke: RN [  10: Ubuntu Installer       ]  ubuntu-docs_5.10-6.1_source.changes ACCEPTED
<seb128> lifeless: how broken? what theme do you use? svg one? is librsvg2-common installed?
<mdke> Mithrandir, that is your one? rock
<Mithrandir> yeah, it's mine
<lifeless> seb128: yes thats installed, though there is a pending update
<lifeless> how broken ? red X with a white page behind them
<lifeless> uhm, my blue one from waaay back
<seb128> lifeless: what icon theme is that?
<lifeless> uhm let me see
<lifeless> theblues-gtk2-saphire
<lifeless> oh thats controls
<lifeless> 'default' icons
<seb128> does changing the icon theme make a difference?
<lifeless> yes
<lifeless> I clicked on flat-blue and the DEFAULT line disappeared
<lifeless> thanks
<seb128> np
<seb128> seems you were using a theme which is not available/got uninstalled or something
<lifeless> yah
<lifeless> its a pity its not easier for us gnome-ignorant to figure out
<seb128> right, it should make clear that you theme you try using is not available
<seb128> Kamion: could you give a retry to rhythmbox/gnome-python-extras now than libtotem-plparser1 has been accepted?
<Riddell> Mithrandir: kubuntu-docs rejected?
<Mithrandir> Riddell: hmm, did I mess up something in the upload
<Mithrandir> ?
<Kamion> seb128: done
<seb128> Kamion: thanks
<Mithrandir> Riddell: I'll look at it.
* sivang wonders if python could support changing dicts in run time and not give RuntimeError: dictionary changed size during iteration
<pitti> sivang: make a temporary copy or use a queue instead
<pitti> s/instead/in addition/
<Mithrandir> Kamion: would you mind forcing a retry of rhythmbox and gnome-python-extras, I'd be grateful
<sivang> pitti: created a temporary copy already, I'll go check if a queue is better
<Kamion> Mithrandir: already done, see above
<Mithrandir> Kamion: oh, sorry, thanks.
<sivang> pitti: http://www.python.org/dev/doc/devel/lib/module-Queue.html ?
<pitti> sivang: might even be a bit too heavy; can't you iterate over an array while append()ing to it?
<sivang> pitti: that's what I did :) thanks
<sivang> pitti: does "Introspect error: The name org.freedesktop.Hal was not provided by any .service files
<sivang> pitti: mean that hald couldn't not be started when queried?
<pitti> sivang: hm, hald is not running?
<sivang> pitti: no, but I want to trap this error , to ive a proper msg to a user
<sivang> pitti: I killled it intentionally
<pitti> ah, I see
<sjoerd> sivang: system bus services are never automagically started
<sivang> sjoerd: ah, I confused that with libnotify, where when you kill the notify-daemon, it starts up automagically when you attempt sending a notifciation. (at least by testing from the examples in the src)
<Mithrandir> Riddell: what was the kubuntu-docs reject message?
<sjoerd> sivang: right, that's because it works on the session bus :)
<Riddell> Mithrandir: From: Debian Installer <installer@ftp-master.debian.org>
<Riddell> To: Jonathan Riddell <jriddell@ubuntu.com>,
<Riddell>         Ubuntu Documentation Team <ubuntu-doc@lists.ubuntu.com>
<Riddell> Mithrandir: did you upload to debian?
<Riddell> Rejected: Unknown distribution `breezy-updates'.
<Mithrandir> Riddell: apparently.  Thanks.
<Mithrandir> Riddell: reuploading now.
* mvo goes for lunch
<seb128> lunch, good idea
<sivang> pitti: interesting, has error behavior changed recently for dbus? (I think I'm getting different exception class now)
<pitti> no clue
<sivang> pitti: k
<Mez> Who's the listmaster around here?
<Mithrandir> yay, ubuntu-desktop installable on ppc and i386 again.. now I just need amd64 to build rhythmbox and we're set.
<pitti> Mez: jdub 
<tseng> Mithrandir++
<Diziet> How long should I expect to wait for a reply from Malone, when I send it an email ?
<pitti> Diziet: last time, it took about 3 minutes for me
<Diziet> And is it ` status fix-released' or ` status fix released' or something else ?
<pitti> mjg59: ping
<sivang> anyone idea why I am getting:
<sivang> Introspect error: The name org.freedesktop.Hal was not provided by any .service files
<sivang> ?
<sivang> (hald is down, intentionally, and I'm trying to GetALlDevices() from it by python)
<pitti> sivang: well, you get it because there is no process behind org.fd.Hal, what's the surprise?
<pitti> sivang: hald is the process that implements the org.fd.Hal service
<sivang> pitti: it didn't do that a couple of upgrades before , that's all :)
<pitti> hm, maybe new dbus 0.60 semantics
<ogra> seb128, if you find a minute to have a look at bug #29404 during the day and give an opinion, that would be nice 
<Ubugtu> Malone bug 29404: "gdm should support alternate config file for cdd branding" Fix req. for: gdm (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29404
<seb128> ogra: yeah, I've noticed it, will do
<ogra> thanks :)
<janimo> ogra \o/
<ogra> :)
<janimo> was about to ping you about it today ;)
<Mithrandir> ogra: can you please get edubuntu-desktop installable again soon?
<ogra> Mithrandir, yup
<pitti> ogra, mjg59: new hal with privilege separation code uploaded; in principle it can now execute power management stuff (well, system.d/hal.conf still needs to adapt the policy to libpam-foreground)
<janimo> ogra we need to set up alternatives for that file I suppose?
<sivang> pitti: wow, already finished? :)
<ogra> pitti, so lets see if hughsies patch works to make g-p-m not crash for us :)
<ogra> (just working on that))
<pitti> sivang: well, sjoerd did the bulk work, I  only integrated the patch and minimized privileges of various parts
<janimo> ogra, does /etc/issue say ubuntu for derivatives too?
<Kamion> janimo: yes
<ogra> janimo, dunno, i'd rather look at lsb_relese
<ogra> *release
<Kamion> lsb-release says ubuntu for derivatives too
<Kamion> the only difference in derivatives is that you have different packages installed; those packages should take care of whatever they need
<sivang> pitti: cool :)
<Mithrandir> can we make debtags not try to connect to debtags.alioth. on installation?
<enrico> Mithrandir: many people asked already
<enrico> Mithrandir: I'm planning to look into a smart way of generating an initial database without connecting on network
<enrico> Mithrandir: I was planning of doing it in February, though, as I have a work to finish on January
<enrico> Mithrandir: if someome is in a hurry for it and would like to do it, I'd be happy to share my plan for it
<enrico> Mithrandir: basically, the idea is to provide a --no-download commandline option to debtags that will force it to use the cached versions of the data files, without downloading them from the net, to rebuild the database
<Mithrandir> enrico: why can't you package the data files up and have it depend on debtags-data or something?
<enrico> Mithrandir: the data files ARE packaged.  And debtags does use them if the network is missing.
<enrico> Mithrandir: the binary database needs to be generated, and that's why I run debtags update in postinst
<Mithrandir> enrico: ah, ok.
<enrico> Mithrandir: I've been asked to avoid the download because it slows down an install considerably if the network is slow, and it makes sense
<pitti> oh, sh**, I forgot to update alsa-utils to 1.0.10
<pitti> Kamion: can you approve UVF exceptions, too, or only mdz?
<Kamion> pitti: yes, I can
<Kamion> mail me+mdz
<pitti> ok, will do, thanks
<Mez> Kamion: can you set up new mailing lists?
<Kamion> Mez: no, try jdub
<Mez> Kamion: np - will wait for mdz to get back - it's not that important atm anyways
<Kamion> Mez: mdz != jdub
<Mez> lol - I know - but well - I need to speak to mdz about whats going on anyways ;)
<mvo> Kamion: what about universe UVF exception for stuff we are upstream for? I would like to upload a new gdebi (direct deb installer)
<Mithrandir> Riddell: you'll soon have a shiny set of new live cds.  Please do test them.
<Mez> mvo: Process for UVF exceptionsin universe: https://lists.ubuntu.com/archives/ubuntu-motu/2006-January/000177.html
<mvo> Mez: thanks
<Mez> mvo: np
<Kamion> mvo: goes through the same process, but in general that sort of thing should be OK for a while
<mvo> Kamion: thanks
<sivang> so, I've done "raise Exception('AnError')" from a method, but when trying to catch it I get, NameError: name is not defined.. any idea?
<sivang> should I define this this exception as a type rather then raising it on the fly with Exception(..) ?
<Mithrandir> Riddell: kubuntu live cds published.  Please test.
<dholbach> lamont: can you give back gnucash on amd64? or look up why it was not built according to the buildlogs?
<dholbach> lamont: can you additionally please give back lablgl?
<mantiena> Kamion, hi
<Kamion> mantiena: hello
<mantiena> Kamion, what is ubuntu-express status ? Do you have at least partially working GUI installer ?
<Kamion> mantiena: I have something working but very flaky and with a horrible UI on my disk; I hope to upload something working and marginally less flaky later this week
<Kamion> if you want to know status of things I'm doing, read the dapper development status reports that are posted weekly to ubuntu-devel-announce
<zul> Kamion: sorry to bug you but i had to drop the graphics.diff to get the new grub working
<Kamion> zul: how come? that comes directly from Debian
<Kamion> zul: any chance you could talk with otavio about that?
<zul> Kamion: dont remember exactly but it looked like the patch got corrupted or something ill talk to otavio
<Kamion> ok
<Kamion> I imagine he'll want slightly more detail than that ;-)
<Kamion> also, if merge-o-matic is giving you garbage results, try just doing the merge by hand, it's usually not that hard
<zul> yeah ill send him a build log 
<Kamion> just sending people a build log of packages they didn't produce is rarely all that productive IME
<Kamion> at minimum I imagine he'd want the Debian->Ubuntu interdiff
<zul> ok cool
<Kamion> and you might find that producing that helps ...
<Simira> so, Ubuntu got me a job anyway
<zul> congrats
<Simira> they usually don't take trainees or similar candidates, but my "background with Ubuntu was very interesting"
<sivang> Simira: what's your job then ?
<sivang> Simira: (and congrets , now you won't have to let tollef travel by his own :) )
<Simira> sivang : the place is Linpro. They have support, sertification courses, and several services in Linux. I believe they are largest on Linux services in Norway. At least one of them.
<Simira> hehe, I can't travel now, I have to work :p
<sivang> Simira: oops, I mis-understood :) but , hey that's more then cool!
<sivang> Simira: you're going to provide support and certification help then?
<Simira> sivang : a documentation project to start with. They offer all kinds of services, so I might have a future there. They delivere software, projects, support, network/web/database solutions and a lot more.
<sivang> Simira: nice, I'm sure you'll do great :)
<Simira> sivang : I hope so. I am really excited.
<Mithrandir> gaim should have per-target language (for spellchecking), so it doesn't try to parse me talking with Scott as Norwegian.
<sivang> heh
<mvo> Kamion: notify-daemon changed the name back to notification-daemon. I'll have to change the seeds again to fix that. sorry for the disruption :/
<Kamion> ok, assuming it's got a UVF exception
<mvo> Kamion: it got one (seb128 asked about it at the end of last week)
<lamont> dholbach: libgl-dev "pretend-avail"ed
<Kamion> mvo: ok then
<Kamion> sivang: yes, just define a new class for your exception
<dholbach> lamont: erm, uhm, do I need to do something about it? I don't quite understand. :-)
<lamont> dholbach: if lablgl dies again, it'll need (1) better build-deps and (2) me to clear the bogus ones again.
<lamont> if it builds, great.
<lamont> but I kinda doubt it will.
<dholbach> lamont: i built it in pbuilder.
<lamont> as for gnucash, I think that it's b0rked by a soname change - does it install for you?
<lamont> dholbach: libgl-dev is a virtual package.. which causes pain.
<lamont> specifically: /etc/sbuild.conf:       "libgl-dev"                     => "xlibmesa-gl-dev",
* lamont will slap it around a little later today.,
<dholbach> I see.
<dholbach> I'll try gnucash again later, it built though.
<lamont> must get ready and head into town for a thing.
<dholbach> lamont: have fun.
<lamont> I wish
<lamont> anyway, I'll look more deeply at both in about 3.5-4 hours or so.
<dholbach> Thanks a lot.
<bddebian> Hello
<dholbach> hello bddebian
<bddebian> Heya Daniel!
<ogra> mjg59, new g-p-m for you to play with ...
<ogra> does python-gnome2-desktop replace python-gnome2-extras ? 
<sbalneav> Morning all
* pitti waves to sbalneav 
<ogra> morning scott
* sbalneav waves to ogra and pitti
<ogra> Kamion, do you have to manually approve gnome-power-manager ? mdz allowed an UVF exception for it until today
<Kamion> ogra: if mdz's already approved it, it doesn't need anything from me
<ogra> oki, i just dont see it hitting the buildd
<Kamion> gnome-power-manager | 0.3.4-0ubuntu1 | dapper/universe | source, amd64, i386, ia64, powerpc
<Kamion> what's the problem?
<ogra> i dont see it building, but i'm likely to impatient :)
<Kamion> er, that output says it's already built
<ogra> hmm, then the buildlogs are out of sync
<Kamion> they're only synced every 20 minutes or so and it can take quite a while for them to sync since the directory is huge
<ogra> yup
<ogra> i'll just wait patiaently ...
<pitti> Mithrandir: do you have the esound patch somewhere?
<Mez> elmo: ping
<Mez> elmo isnt here :D
<Mez> elmo: unping
<Mithrandir> pitti: http://err.no/patches/esound-esddsp-threading-fix.diff .  Can you make up a changelog entry?
<bddebian> Heya Mez
<Mez> bddebian, hey
<dholbach> re
<doko> dholbach: rationale for 29428?
<dholbach> doko: if you refer to vnc, I thought the 'Ubuntu' task was a bit pointless, the 'vnc (Ubuntu)' was enough; I switched back to 'Major', once I realised it was you that filed the bug report.
<doko> dholbach: I'm ok to leave it at severity normal, if pitti wants to support us with XFree86 4.2 security updates for the release  ;-P
<dholbach> Arg.
<ogra> lol
<ogra> ajmitch, whats up with zope3 and python2.4-mechanize ?
<ogra> lamont, can you give back dia ? builds fine in a pbuilder, looks like libgtk2.0 and its -dev were out of sync last try ...
<Kamion> Mithrandir: do you want to take the kbd-chooser merge, since I suspect you have local modifications to kbd-chooser anyway? (merges ought to be done by Thursday, though, so if it's going to take longer, I can do it)
<Mithrandir> Kamion: sure, I can do it.
<Kamion> it's yours, thanks
<sivang> morning mdz 
<bddebian> Heya sivang
<sivang> hey bddebian , how are you?
<neuralis_> mdz: hi. according to the latest dev status meeting, you feel community server testing can start immediately; is there anything you need from me before you feel comfortable approving the spec?
<bddebian> sivang: Not bad thanks. You?
<sivang> bddebian: pretty good, hacking on some python classes, nice to see how I get pieces together to form a working code.
<bddebian> :-)
<pitti> Mithrandir: thanks; sure
<Mithrandir> pitti: care to kick it in Debian's direction too?  I think the patch isn't complete, but it does at least solve the "esound falls over immediately".
<pitti> Mithrandir: sure
<Mithrandir> thanks
<ogra_ibook> Mithrandir, once dia is rebuilt, edubuntu-desktop should be fine again
<Mithrandir> ogra_ibook: what about zope and such?
<ogra> Mithrandir, that only holds back edubuntu-server, not used on the livecd
<Mithrandir> true dat.
<ogra> :)
<Mithrandir> I guess I should go and break casper, then? ;-)
<ogra> as you like, your baby ... :)
<Mithrandir> I could fix the "network interfaces are not configured on the live cd" bug.
<ogra> cool :)
<dholbach> mdz, Kamion: could you please promote gnome-python-desktop to main? (gnome-python-extras was split into gnome-python-extras and gnome-python-desktop upstream) - gedit wants it already and I'll review the other rdepends asap
<ogra> oh, transition ? 
<dholbach> ogra: some bits went here, some bits went there - the list of rdepends is around 20 packages, so it's a "small transition" only
<pitti> Mithrandir: could you give me a short explanation about how the absence of locking caused a crash?
<pitti> Mithrandir: i. e. did ffox try to call esddsp twice, or anything?
<ogra> dholbach, i'm sure there is more 
<Kamion> Mithrandir: oh, please do
<pitti> Mithrandir: this function looks so utterly innocent...
<Mithrandir> pitti: it tried to initialize multiple times, and since it has global variables which are twiddled as part of the initialization, things went boom
<dholbach> ogra: aha?
<ogra> dholbach, oh, its only -extras ? 
<Amaranth> ogra: gnome-python-extras split into two thigns
<Amaranth> things
<siretart> what was the workaround for the installation problem with netinstall and libesd-alsa0 colliding with libesd0?
<pitti> siretart: what is the offending package with a libesd0-only dependency?
<Kamion> siretart: regenerate breezy Packages lists to make kubuntu/edubuntu un-netinstallable again
<siretart> pitti: libesd-alsa0: collides: libesd0 but 0.2.34-1ubuntu5 is to be installed
<Kamion> need to bug elmo, I see that still hasn't been done
<pitti> siretart: I know, the conflict is correct
<siretart> Kamion: err, sorry? I'm trying to netinstall a preseeded ubuntu and using archive.ubuntu.com (using apt-cacher, though)
<Kamion> siretart: another workaround is to preseed base-config
<pitti> siretart: but there is a package which depends on libesd0 instead of libesd0|libesd-alsa0?
<Kamion> siretart: yeah, I know, breezy was broken and we all lose
<siretart> Kamion: I know I read the workaround for preseeding base-config, but I don't remember what I exactly need to put in
<Kamion> siretart: preseed base-config/package-selection=~t^ubuntu-standard$|~t^ubuntu-desktop$
<Kamion> or 'base-config base-config/package-selection string ~t^ubuntu-standard$|~t^ubuntu-desktop$' if in a preseed file
<siretart> Kamion: Thanks, I'll try
<Kamion> btw, confirmation that this is fixed in dapper would be good - I'm pretty sure it is, but haven't actually made sure
<siretart> will do as soon as I get this setup here fixed
<siretart> we are 'upgrading' our automated d-i setup from sarge to breezy, but I intend to install dapper automatically as well
<\sh> hmm..does anyone know why savane is not available as official package for debian or ubuntu?
<Kamion> dholbach: done
<dholbach> Kamion: merci beaucoup.
<Mez> woah!
<Mez> I'm actually impressed by one of those emails that tries to trick you into installing a virus/getting you to do somethine
<Mez> It's like - I almost got tricked by it
<sivang> 52checking
<sivang> err, ECHANNEL
<Kamion> dholbach: shouldn't python*-gnome2-extras depend on python*-gnome2-desktop to make partial upgrades work properly?
<dholbach> Kamion: it's the other way around - -desktop wants -extras and I just uploaded packages, which grab -desktop, if they need it
<Kamion> really? I thought stuff moved from -extras to -desktop
<Kamion> which would indicate that -extras should depend on -desktop to make sure the latter gets pulled in on upgrades
<Kamion> (e.g. unpackaged third-party programs that use the bindings)
<dholbach> they moved stuff to -desktop which is not always needed (like gtop, nautilusburn), we wouldn't like to depend all those packages on it
<Amaranth> dholbach: no, they moved things to desktop which wrap things that are in the desktop suite
<dholbach> Amaranth: Yes, but effectively are not used that often (8 of 22 source packages did). :)
<dholbach> so we're both right.
<seb128> dholbach, Kamion: right, gnome-python-extras stuff have been moved to a new -desktop
<seb128> Kamion is right on partial upgrade
<dholbach> What do you suggest to do?
<seb128> but I think it sucks to force people to install a zillion of extra stuff
<Amaranth> hey, while we're talking about g-p-e and such, the way redhat handles it is really nice
<Amaranth> they break all the pieces up into separate packages
<seb128> Amaranth: a binary by module? np
<seb128> nop
<seb128> yeah, that sucks
<dholbach> Arg, yes - we had that discussion a while ago.
<tseng> gtk-sharp is done nicely
<Amaranth> how is it done?
<tseng> libgtk-cil, libgnome-cil, libglade-cil
<tseng> etc
<tseng> so the shlibs are all just so
<ogra> hmm, does anyone know if there are libnotify python bindings yet ? 
<Kyral> nothing comes up when I search
<sivang> ogra: I'm just talking with ChipX86 , Robot101 , and nomed about that :)
<sivang> ogra: nomed has some nice wrapper made ontop of dbus, that can be used to achive almost the same
<ogra> i dont have a real need for dbus here, i just want a bubble connected to an icon 
<sivang> ogra: I'm interested in doing something like, but I will try first to do something local for home-user-backup, then when I'm done with it and have more time, I am going to try writing somethign like that..will be a nice experience
<ogra> yup
<sivang> ogra: then better use a premade C bin, and call it from your python code..
<slomo> ogra: you can use the dbus interface... it's really simple
<ogra> nah, i can live without a bubble, would just have been a nice add on
<sivang> ogra: otherwise I think its only send up a notificatio up the bus to notify-daemon 
<sivang> ogra: what is it that you need a bubble for?
<ogra> slomo, any doc about this ?
<slomo> ogra: not really :/ you could take a look at service-discovery-applet for an example...
<ogra> oki, will do
<slomo> ogra: but the current version in dapper needs a patch for the new API... only some parameters have changed... i'll upload it tomorrow
<slomo> ah well, i could do it now ;)
<bddebian> slomo!!!!!!!!!!!!!!!!
<sivang> ogra: http://svn.berlios.de/wsvn/dss/dss-main/nomed/trunk/Nomed/utils/notification.py?op=file&rev=0&sc=0
<sivang> ogra: that prooved to be interesting for my notifications :)
<Burgwork> sivang, how is the home user stuff going?
<sivang> Burgwork: progressed some bits today :)
<Burgwork> sivang, not working crazy hours any more?
<slomo> hi bddebian :)
<sivang> Burgwork: not for the time being, we released the work product today 
<sivang> Burgwork: care to do some testing for me?
<Burgwork> sivang, sure, but not a for a few days
<sivang> Burgwork: ok, ping me up when you have time
<Burgwork> sivang, I am snowed in under writing projects
<slomo> sivang: yes, that does the same as we use in s-d-a :) but much easier to read because of less distracting stuff ;)
<sivang> slomo: :) I acutally have the author   
<mjg59> piRock
<mjg59> ogra: Also rock
<slomo> sivang: what?
* bddebian sucks
<sivang> slomo: I had network latency :)
<slomo> sivang: ah ok :)
<sivang> slomo: I talked to the author of that one, so I t was a bit easier to understand.
<sivang> slomo: what file in s-d-a there's the dbus communication code?
<ogra> mjg59, i adopted the gdm-signal stuff for now, i can remove it again if you want to rule everything by hal in the future
<slomo> sivang: src/service-discovery-applet.in
<slomo> sivang: it's easy to understand but dbus initialization etc are somewhere else
<sivang> slomo: yes, I see the code is a bit cleaner
<sivang> slomo: but it doesn't use callbacks for notification, am I right?
<slomo> sivang: callbacks for what? it just calls the dbus function to show a nice bubble when it gets an avahi event :)
<mjg59> ogra: Can you switch it back to hal for now? The necessary code is there now
<sivang> slomo: I need some callbacks there :) I'll just try to merge the best of both code bases :)
<ogra> will do
<slomo> sivang: where do you use callbacks for what reason? ;)
<mjg59> ogra: Might need a tiny bit of tidying up in hal, but I'll sort that
<ogra> mjg59, it didnt work when i tried, thats hy i switched ... i'll upload the fix tonight.
<lamont__> hrm.. so how do I kick X so that it will notice the mouse again...
<lifeless> doko_: we have a patch for python that niemeyer is digging out
* lamont__ applies the ugly-but-working solution
<lifeless> doko_: its a difflib problem that is affecting our imported archives conversion to bzr...
<lifeless> doko_: we need to get a python in the dc with that included rolled out - whats the easiest way to get such a package to elmo ?
<lifeless> doko_: niemeyer says hes going to commit it to svn, if that helps
<doko_> lifeless: that would be nice, I'll fetch it from svn then
<doko_> lifeless, elmo: which distribution? breezy?
<sivang> slomo: https://wiki.ubuntu.com/HomeUserBackup
<lifeless> doko_: breezy
<ajmitch> morning all
<bddebian> Heya ajmitch
<lamont__> seb128: ping
<seb128> lamont__: pong
<dholbach> Have a nice evening.
<sivang> night all
#ubuntu-devel 2006-01-29
* mvo goes to bed now
<keherman> hey guys, seems like the blackbox package is broken
<keherman> get dpkg error when installing, so i could file a bug -- but not sure if you guys have seen it
<Burgwork> keherman, please file a bug on it
<crimsun> nothing on malone for that source
<keherman> Burgwork, bug #29503, https://launchpad.net/distros/ubuntu/+bug/29503, "Blackbox fails to install if Fluxbox is also installed due to shared /usr/bin/bsetroot"
<Ubugtu> Malone bug 29503: "Blackbox fails to install if Fluxbox is also installed due to shared /usr/bin/bsetroot" Fix req. for: Ubuntu, Severity: Normal, Assigned to: Nobody, Status: Unconfirmed
<Ubugtu> Malone bug 29503: "Blackbox fails to install if Fluxbox is also installed due to shared /usr/bin/bsetroot" Fix req. for: Ubuntu, Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29503
<Burgwork> keherman, thanks
<keherman> :-)
<Kamion> bug #29502 is a duplicate of that, right?
<Ubugtu> Malone bug 29502: "Blackbox fails to install if Fluxbox is also installed due to shared /usr/bin/bsetroot" Fix req. for: blackbox (Ubuntu), Severity: Normal, Assigned to: Nobody, Status: Unconfirmed http://launchpad.net/bugs/29502
* Kamion marks it thus
<Burgwork> Kamion, I thought that LP bug about duplicating bugs had been squashed
<Kamion> ? ECONTEXT
<keherman> Burgwork, when i entered the bug into bugzilla, launchpad produced an error
<Burgwork> Kamion, sometimes LP doubles up bugs like that, likely due to the reporter clicking enter twice
<Burgwork> Kamion, I reported it and thought it was fixed
<Kamion> Burgwork: the text was sufficiently different that that didn't seem to be the case
<keherman> Burgwork, i clicked the BACK button to retry -- but there was definitely an error
<Burgwork> Kamion,  ah
<Riddell> Mithrandir: kubuntu live CD looking nice
<keherman> Can some dev tell me how to locate where "Sound an audible bell" is being stored for the sound settings?  Is there some source I can grep somewhere which would have this info?
<mjg59> Ngh.
<mjg59> Is anyone able to explain the libpam-runtime conffile handling to me?
<psusi> ohhh snap... the new thunderbird 1.5 in dapper just exited with no error message when I tried to reply to a message
<psusi> didn't even get a bug buddy or anything
<mjg59> BenC: Around?
<BenC> mjg59: vaguely
<mjg59> BenC: Was the /etc/pam.d/common-* stuff after you were involved?
<BenC> yeah, way after me
<mjg59> Right, I probably need to find Sam, then
<mjg59> Sorted
<AlinuxOS> hello, someone knows... what package generates /usr/share/applications with files with *.desktop sufix ? I need to translate some things...
<LaserJock> AlinuxOS: the .desktop files are created by the packages they are for
<mjg59> I've uploaded hal, dbus, pam and libpam-foreground
<mjg59> If people install all of those, then gnome-power-manager should work
<psusi> mjg59, hey... hal-set-property is _supposed_ to work from inside a callout isn't it?
<mjg59> I've no idea, I'm afraid
<psusi> blast...
<mjg59> But the privilege separation code is in now
<mjg59> So you can get stuff run as root
<psusi> I could do that with suid before ;)
<ogra> mjg59, will test tomorrow, it seems the packages arent in the archive yet ...
<psusi> problem is hal-set-property can't seem to connect to hal from inside the callout
<psusi> if I fork it in a background pipeline, it works, but it has to be done within the script or other fdi policies can't match on the properties it sets ( since it checks them before they are ever set )
<mjg59> ogra: I've been uploading stuff over the past couple of hours. It should all hit soon.
<mjg59> ogra: Works fine here now, in any case
<ogra> yes, but its 4:30 and i should get some sleep :)
<ogra> GF looks unhappy :)
<mjg59> Heh
<wasabi__> Don't suppose there is a nice gnome pptp config utiolity available yet?
<dholbach> good morning
<ulaas> hi. is X still broken or it is me?
<mdke> ulaas, it's you
<Mithrandir> ulaas: what's the problem you see?
<ulaas> mdke: you are direct :)
<ulaas> Mithrandir:give me a sec
<fabbione> who is supposed to make a new enigmail for new thunderbird?
<Mithrandir> fabbione: infty, I guess
<fabbione> ok
<ulaas> Mithrandir: it is like it was before. somethig like xauth -notcp -blah blah blah could not execute command..... i think i need to reinstall x. how do i apt-do it?
<Mithrandir> ulaas: do you have ubuntu-desktop installed?
<ulaas> Mithrandir: hmm no. and i dont know why not.
<Mithrandir> ulaas: install that (and by extension, x-window-system-core) and you should be fine.
<ulaas> Mithrandir: already getting. thanx. will there be any other transtions on x?
<Mithrandir> ulaas: I hope not.
<pitti> Good morning
<ajmitch_> morning pitti 
<ulaas> Mithrandir: well. if it is for dapper. i would love a thousand more ;)
<poningru> will firefox 1.5.0.1 make it into dapper?
<pitti> mjg59: meh, the scripts were already installed into /usr/lib/hal, and we don't want them all; but I agree that share is better, I'll fix that
<janimo> dholbach, ping
<dholbach> janimo: pong
<janimo> hey, is putting tango-icon theme pkgconfig file is usr/share intended?
<janimo> others are in usr/lib
<dholbach> oh it is?
<janimo> gnome-icon-theme puts it there too so there may be a reason
<janimo> usr/share/pkgconfig and usr/lib/pkgconfig
<janimo> maybe icon themes should be there since they are not libs?
<dholbach> Mithrandir: is any stuff supposed to be in /usr/share/pkgconfig?
<Mithrandir> dholbach: arch:all packages with .pc files should stuff them there.
<dholbach> Ah cool.
<janimo> aha :)
<dholbach> Thanks
* dholbach hugs Mithrandir
<Mithrandir> np
<pitti> Kamion: Good morning! could you already take a look at the alsa-utils changelog?
<pitti> meh, why has the sftp:// semantics of bzr changed *again*?
<Kinnison> pitti: They've been made sane, instead of correct
<pitti> Kinnison: how can I specify a directory relative to ~ now?
<pitti> and sftp://host//absolute/dir wasn't so insane IMHO *sigh*
<Kinnison> I *think* it's sftp://hostname/~/blah
<Kinnison> sftp://hostname/absolute/dir makes more sense to me
<Kinnison> the need for a double-slash broke too many people's brains
<pitti> well, it's not what I'm used to with ssh
<pitti> hm, maybe
<Kinnison> pitti: I assume you mean scp, and that uses : as the host/path separator
<Kinnison> pitti: so it's hardly a fair comparison
<Kinnison> hostname:relative/path hostname:/absolute/path is much easier to understand than hostname/relative/path and hostname//absolute/path
<mdke> Mithrandir, did ubuntu-docs fail to build? It hasn't hit breezy yet
<pitti> Kinnison: hm, maybe bzr should use the colon then :)
<Mithrandir> mdke: doesn't seem to have been tried at all yet.
<Kinnison> pitti: It's not a URL in that form
<Kinnison> pitti: Or at least, not one that people would recognise
<Kamion> Kinnison: er, have they been changed again after 0.7? because I thought 0.7 used //absolute
<Kinnison> pitti: I think it's bad that we switched twice, I think we should never have switched to //absolute
<Kinnison> Kamion: Not sure
<Kinnison> Kamion: I use my branch of mainline most of the time so I don't know when the switches were
<Kamion> also surely //absolute could still be supported ...
* Kinnison never uses sftp urls either
* Kamion is utterly reliant on sftp URLs
* Kinnison uses rsync nearly all the time
* Mithrandir hugs rsync
<mdke> Mithrandir, maybe it needs to be pushed through by Kamion/mdz?
<Kamion> mdke: yes, breezy-updates requires manual approval
<Kamion> pitti: ok, give me a moment
<mdke> Kamion, do you have time to look at ubuntu-docs as uploaded by Mithrandir yesterday? It should have fixed all the problems with edubuntu-artwork
<Kamion> mdke: I'll do it today, yes
<mdke> Kamion, yay, thanks
<dholbach> Hey seb128!
<seb128> hi dholbach
<pitti> Hi mdz 
<mdz> morning
<pitti> mdz: how is London? :)
<mdz> miserable
<mdz> it's very cold and my mail is fucked
* pitti stares at the blue sky and the sun outside and wonders...
<pitti> uh
<Kamion> mdke: um, so, is 5.10-7 dead now?
<Kamion> ubuntu-docs 5.10-6.1 seems to be the thing to actually review
<dholbach> seems London is around +20C warmer than Berlin
<mdke> Kamion, is that my upload from december? that should be killed yeah
<Mithrandir> Kamion: 5.10-6.1 uploaded by me yesterday is the right one.
<Kamion> dunno how to reject from -updates
<Kamion> Mithrandir: there's a duplicate Conflicts field in ubuntu-docs
<Kamion>  Conflicts: ubuntu-quickguide (<< 5.10), ubuntu-faqguide
<Kamion> +Conflicts: kubuntu-docs (<< 5.10-0.6.1), edubuntu-artwork (<< 0.1.0-9.1)
<Kamion> Mithrandir: what upgrade combinations have you tested?
<Mithrandir> Kamion: I've tested breezy only.
<Mithrandir> I'm unsure how that managed to pass. :-/
<Kamion> dpkg probably picked the second Conflicts field, I guess
<Kamion> I don't think it's clever enough to merge them, but ICBW
<fabbione> hey mdz
<Mithrandir> Kamion: I can fix that easily enough.
<seb128> hi mdz
<mdz> morning fabbione, seb128
<Kamion> Mithrandir: I can't help feeling that kubuntu-docs and edubuntu-artwork ought to use different priorities for the firefox-homepage alternative, but OTOH I can't see a good way to decide which should be higher
<Kamion> Mithrandir: otherwise, it all looks right to me
<Mithrandir> Kamion: apart from the duplicated Conflicts field.
<Kamion> Mithrandir: so if you give me an ubuntu-docs 5.10-6.2 with that Conflicts bug fixed, I'll approve it
<Mithrandir> will do
<Kamion> mdz: in lieu of the ability to reject, can you make sure to refrain from processing the obsolete ubuntu-docs 5.10-7?
<mdz> yep, I don't intend to be doing any archive processing this week in fact
<Kamion> thought not somehow
<mdz> we're on the same time zone anyway
<Kamion> mdke, Mithrandir: ok, all approved
<fabbione> doko: ping?
<mvo> mdz: has gdebi (direct deb installer) a exception for UVF because it is part of the ThirdPartyPackages spec? or will I have to ask for approval?
<pitti> ogra: do you care about moodle?
<mdz> mvo: it has an exception because upstream is following our release schedule ;-)
<tepsipakki> kamion: have you had time to look at #28462 yet?
<Kamion> tepsipakki: hm, no, sorry
<Kamion> tepsipakki: it does look like it must be a problem with your mirror though; have you tried the same thing with archive.ubuntu.com rather than ubuntu.hut.fi?
<Kamion> I can't seem to get to ubuntu.hut.fi from here to have a look
<tepsipakki> no I haven't
<tepsipakki> true
<tepsipakki> it's mirrored with apt-mirror
<Kamion> that said - is it actually managing to install anything from universe? I looked down the list logged by pkgsel and couldn't see anything non-main there
<Kamion> archive.ubuntu.com might be worth a try anyway, just to eliminate mirror problems from consideration
<mvo> mdz: isn't it great to have upstreams who follow our cycle ;) thanks!
<Kamion> because it does seem to have added universe to sources.list, which is the only plausible point where that could fail
<tepsipakki> kamion: well, those "no candidate version found" indicates that it doesn't find them? dlocate, for example is in universe
<Kamion> tepsipakki: right, but that could easily be because the universe Packages file is broken
<Kamion> e.g. empty
<tepsipakki> the mirror works fine after d-i
<Kamion> uh
<tepsipakki> well, I'll just try a.u.c to be sure ;)
<Kamion> oh, give me a second, an idea
<Kamion> is this a CD install?
<tepsipakki> no, netboot
<Kamion> I bet the CD install handling in apt-setup-udeb.postinst is misfiring
<Kamion> yeah, must be
<Kamion> ok, I can fix that
<Kamion> tepsipakki: should be fixed in apt-setup 0.4ubuntu6; thanks for the nudge
<tepsipakki> great, thanks!
<pitti> Kamion: thanks for the alsa review
<mjg59> pitti: I've uploaded - they didn't seem to be in /usr/lib
<pitti> mjg59: nevermind, I cleaned it up now
<pitti> mjg59: does the new hal now do what it should for power management?
<mjg59> pitti: Oh, cool. Yes.
<pitti> mjg59: I tested it with the mount interface, and that worked fine
<mjg59> dbus has been fixed, pam has been fixed, g-p-m has been fixed
<pitti> but I disabled that because it's horribly flawed
<pitti> yay
<pitti> mjg59: I'll take another look at pam_fg today and approve the report
<pitti> thanks for fixing the bugs
<mjg59> Sure
<ogra> pitti, yes, i care for moodle, whats up with it ? 
<pitti> ogra: /msg
<mjg59> Anyway, as of now g-p-m, pam, libpam-foreground, dbus and hal, everthing works
<pitti> mjg59: rock :)
* mvo is away for lunch now
<pitti> Kamion: can you please sync mydns? (security update)
<janimo> mjg59, dbus ftbfs
<janimo> previous version was broken too (ubuntu7)
<mjg59> JaneW: Probably not my problem, then
<mjg59> NGH IRSSI HATE
<mjg59> Oh, it might be my fault
<mjg59> I'll fix it later
<JaneW> mjg59: huh?
<mjg59> JaneW: Sorry, misdirected
<pitti> :x
<StevenK> Hence the irssi hate ....
<pitti> whoops, ECHAN
<JaneW> oic, np
<ogra> mjg59, its your problem :) it fails applying the console patch ...
<mvo> Kamion: ping
<mvo> Kamion: ok for me to do a ubuntu-meta upload now? including your grub,espresso-grub change?
<xulin> hi 
<xulin> there is an imporant missing package in alsa .. 
<Kamion> pitti: syncs -> elmo please
<pitti> ok
<Kamion> mvo: yes
<pitti> xulin: which?
<stratus> mvo, gdebi 0.1.4 uploaded.
<xulin> pitti, alsa plugins .. 
<xulin> in 1.0.9 version they make a seperate .tgz in alsa projet for plugins 
<pitti> xulin: it's in universe already
<pitti> alsa-plugins |   1.0.10-1 | http://archive.ubuntu.com dapper/universe Sources
<xulin> pitti, ah .. great :s .. sorry i don't find it in http://packages.ubuntu.com/ :/ 
<pitti> hm, that could be out of date
<xulin> non .. it okay packages is .. libasound ..
<xulin> libasound2-plugins
<xulin> when i clic : /dapper/universe/libs/libasound2-plugins was not found on this server.
<xulin> strange :] 
<xulin> libasound2-plugins is present in warty .. hoary .. but nothing in breezy and dapper :/ 
<Kamion> it's not in breezy, but:
<Kamion> libasound2-plugins |   1.0.10-1 | dapper/universe | amd64, hppa, ia64, powerpc, sparc
<Kamion> I believe packages.ubuntu.com is having problems at the moment
<Kamion> oh, and
<Kamion> libasound2-plugins |    1.0.9-2 | dapper/universe | i386
<pitti> hm, ftbfs then?
<xulin> Kamion, ah ok .. if it's present in dapper it's ok :) .. 
<xulin> need to go 
<pitti> although I see amd64 packages here
<xulin> bye
<Kamion> pitti: alsa-lib FTBFS on i386
<Kamion>         dpkg-shlibdeps -Tdebian/lib64asound2.substvars debian/lib64asound2/usr/lib64/libasound.so.2.0.0
<Kamion> /usr/bin/ldd: line 161: /lib64/ld-linux-x86-64.so.2: cannot execute binary file
<Kamion> dpkg-shlibdeps: failure: ldd on `debian/lib64asound2/usr/lib64/libasound.so.2.0.0' gave error exit status 1
<Kamion> check how other biarch libraries do that, I guess
<pitti> 'k, I'll check that
<mvo> stratus: thanks, did you merged the latest stuff too?
<stratus> mvo, i did the upload yesterday and our trees were in sync, so i guess yes
<stratus> mvo, i even applied one or two minor fixes, please sync.
<stratus> mvo, oh no, the fcntl stuff and some others aren't in 0.1.4 upload
<stratus> mvo, merging conflicts...
<mvo> stratus: no problem :) I should have informed you, sorry
<jsgotangco> hi all
<stratus> mvo, np if you think it's urgent (but it seems to be minor) i can upload 0.1.5 tonight
<stratus> mvo, merge now, please.
<stratus> mvo, can you check if you can reproduce that bug installing gizmo-project package? It's still unreproducible (to me) with 0.1.4.
<zul> morning
<seb128> Kamion: when new libnotify hits NEW please accept/promote it, somebody broke libnotify0 by shipping a new soname without changing the binary package, that's fixed now but apps will not start until they are rebuilt against the new one
<\sh> doko__: pingeling :) are you writing an UVF exception report for https://launchpad.net/malone/bugs/29552 ?
<Ubugtu> Malone bug 29552: "Include vnc4server for amd64 in dapper. Source deb inside" Fix req. for: vnc (Ubuntu), Severity: Major, Assigned to: Nobody, Status: Unconfirmed
<Mithrandir> \sh: that is total crack, or at least was it last time I looked at the source
<\sh> Mithrandir: that's why I asked doko :) regarding the comment mentioning his nick :)
<Keybuk> ok... this is quite depressing; my laptop display is flickering on console
<Keybuk> if it breaks just before the sprint, I'm going to be grumpy
<Kamion> judging from that diff.gz there's still a complete copy of X inside
<\sh> is tightvncserver not enough? 
<Kamion> Mithrandir: wow, the live CD is actually acceptably quick to boot in qemu now
<\sh> I remember the breezy times, when I tried to fix vnc4 to work with gcc-4..and it bitched around a lot
<Mithrandir> Kamion: scary.
<Kamion> takes a while for GNOME to come up, but it gets to X comparably quickly to a real system
<Mithrandir> I assume that's from an ISO image on disk?
<Kamion> yeah
<Kamion> ok, yeah, I suppose that's cheating a bit
<Mithrandir> that gives you approximately zero seek time, but I still find it good.
<dreamind> Hi folks :)
<dreamind> can anybody tell me if there is a version of the avm isdn drivers for ubuntu which might be compatible with make-kpkg for debian?
<dreamind> because I'm currently building a package of avm's fritz drivers for debian.
<dreamind> and I want not to reinvent the wheel
<Mithrandir> dreamind: they're already in linux-restricted-modules in Ubuntu
<Kamion> ah, hmm, let's try 512MB of memory instead of 128MB, that might help GNOME somewhat
<dreamind> Mithrandir: yes I know this, but is it compatible to make-kpkg?
<dreamind> and I don't see the source of that somewhere...
<Kamion> source package name is linux-restricted-modules-2.6.15
<Kamion> in the restricted component, not main
<Mithrandir> dreamind: http://archive.ubuntu.com/ubuntu/pool/restricted/l/linux-restric
<Kamion> it's not exactly in the form you'd need for a Debian module source package, I don't think
<Menoz> hi all! I have a problem with remastering! Can someone help me?
<Menoz> :)
<dreamind> Kamion: ok, then I'll finish my started work, but I'll have a look at them
<Kamion> Menoz: what's your problem?
<Menoz> thanks Kamion!
<Menoz> i'm trying to add/remove some package from install cd
<Kamion> (I didn't say I could help)
<Menoz> :)
<Menoz> but
<Kamion> have you read https://wiki.ubuntu.com/InstallCDCustomizationHowTo?
<Menoz> i've seen that, when I create the file Packages
<Menoz> yep
<Menoz> but, and also waikato guide :)
<Menoz> but my problem remains
<Menoz> and it is:
<Menoz> when I create the Package file
<Menoz> it is significantly smaller than the original one!
<Kamion> well that would kind of depend on how you're creating it
<Menoz> (obviuously, with the same packages installed)
<Menoz> I've seen thatr
<Menoz> the Pa] ckages file I create
<Kamion> you should use diff between the old and the new versions to see what's missing
<Menoz> yep, I've done it
<Menoz> and I've seen
<Menoz> that
<Menoz> every package
<Kamion> could you please hit enter slightly less often? thank you.
<Kamion> you're filling up an awful lot of vertical scrollback.
<jsgotangco> :D
<Menoz> (pardon) hasn't the lines starting with "Origin:" and "Task:"
<Kamion> Origin's unimportant, Task is trickier
<Kamion> hm, to be perfectly honest I'd be inclined to approach this by editing the old Packages file in a text editor
<Menoz> hum
<Kamion> failing that you'd need to generate an ExtraOverride file and put it in your apt-ftparchive configuration
<Kamion> the file looks a bit like this:
<Kamion> adduser  Task  ubuntu-minimal
<Kamion> alacarte  Task  ubuntu-desktop
<Kamion> alien  Task  ubuntu-ship
<Kamion> should be possible to generate it from the original Packages file
<Kamion> in breezy you'll need Archive-Copier-Set headers too
<Menoz> well, I found this link: http://mirrors.xmission.com/ubuntu/indices/ ; could it be useful?
<Kamion> no, cdimage regenerates all those on the fly
<Menoz> ok. So, do you know how can I generate this file?
<Kamion> I don't have a script to do it for you, no
<Kamion> I would have to write it, but other less busy people could probably do that too :)
<jp_> im having an issue when m trying to get dapper on an amd 64 box  I got the installer couldn't fin a kernel for the box  what's that?
<jp_> thanks"
<Menoz> ah, I tought there was a program that do this automagically :)
<neuralis> jp_: please ask on #ubuntu; this channel is for development only.
<Kamion> Menoz: the CD image generator does it automatically, but it's not at all easy to set up, and it generates images from scratch rather than customising existing ones
<Menoz> cd image generator
<Menoz> ?
<Kamion> you don't want it
<Kamion> the code we use to generate images in the first place
<mdz> what Kamion is saying is that we don't have a convenient script to do what you want, but it certainly would be nice if someone contributed one
<mdz> it should be a very approachable project
<Kamion> another useful project would be to make debian-cd put its generated override files onto the CD image so that that script would be unnecessary
<mdz> there would still be call for an "i've added/removed/changed some packages on the CD, fix everything up" script regardless
<Kamion> yeah
<Menoz> ok, but this problem is solvable in another way, because someone  has customized ubuntu :)
<Kamion> it would make the task more approachable though
<mdz> Menoz: oh?  it seems entirely possible that they simply wrote the script
<Kamion> or just did the last few steps by hand ...
<Kamion> hmm, I think Archive-Copier-Set can go away now in dapper
<slomo> mdz: hi... do you have any objections against an UVF exception for avahi 0.6.5? it's almost a plain bugfix release but nothing too important was fixed... changelog is here: http://avahi.org/milestone/Avahi.6.5
<Menoz> ok, thanks. However, a bash script that does this job isn't toot difficoult to write down
<Kamion> Menoz: feel free :-) I suggest documenting the process on InstallCDCustomizationHowTo for the next person
<Menoz> ok, good
<Menoz> thanks!!!!!!!!!!!!
<mdz> np
<Menoz> sorry: what is the format of this file? (centericq won't let me scroll up )
<Kamion> <package>  <field name>  <field contents>
<Kamion> same format as http://mirrors.xmission.com/ubuntu/indices/override.breezy.extra.main, but different contents
<Menoz> ok, thanks
<mdz> slomo: no, I don't
<slomo> mdz: ok, thanks... i'll prepare a upload later :)
<Kamion> ok, Archive-Copier-Set cruft dropped for dapper now
<BenC> what good is the suspend option in gnome when it logs you out
<BenC> is that supposed to happen?
<Keybuk> BenC: ogra removed the binary that it uses I think
<ogra> nope
<BenC> is that the gdm-signal thing?
<ogra> i did remove the gdm-signal call from g-p-m, i didnt touch gnome-session
<ogra> (since g-p-m uses hal for root tasks now)
<pitti> Hey Keybuk, how are you?
<Keybuk> hmm, I mis-interpreted your changes then :)
<Keybuk> I read it as you removed gdm-signal itself
<Keybuk> pitti: I'm good :)
<ogra> Keybuk, yes, from the g-p-m code
<ogra> (i didnt upload gnome-session or gdm recently :) )
<BenC> I haven't tested this in a long time, so it's probably not recent
<BenC> just odd that it does a logout before it actually does suspend-to-ram
<BenC> I usually just close the lid, so never noticed
<Treenaks> BenC: when will the next kernel upload be? (/me misses music from his mac mini :))
<ogra> hmm, is the libnotify 0.3.X protocol documented anywhere ? seem the old (pre 0.3) spec is completely obsolete 
<BenC> Treenaks: today
<Treenaks> BenC: cool!
<ogra> i cant convince my popup message to use an icon :/
<verwilst> hellow!
<verwilst> i seem to have found some bugs, but not sure to which package to link it to..
<verwilst> everytime i reboot, /var/run/clamav, /var/run/avast4 are gone so the daemons don't start
<verwilst> and /var/run/mysql has wrong permissions then ( it needs an additional o+rx )
<ogra> verwilst, please file bugs for the apps that misbehave 
<verwilst> ogra: well yeah, but maybe it's a cleaning script that misbehaves? ;)
<Mithrandir> verwilst: file bugs on the packages.  /var/run is now a tmpfs.
<kent> verwilst: there is some bugs regarding the /var/run/* problems in malone already for some services like mysql etc.  Go look and perhaps add a comment.
<verwilst> ooh
<verwilst> cool
<verwilst> okido
<verwilst> thanks!
<jsgotangco> good night
<sbalneav> Morning all!
<ogra> hey scottie
<sbalneav> Hey ogra!
<bddebian> Hello
<siretart> why is /var/run now tempfs anyway? what advantage does this bring? so far, I see quite a lot of breakage..
<Keybuk> basically solves huge numbers of race conditions
<Keybuk> we need *somewhere* writable early in the boot sequence to store pid files, temporary state files, etc.
<Keybuk> otherwise we have a chicken-and-egg problem
<Keybuk> can't-start-udev-until-we-have-var-run
<Keybuk> can't-check-and-mount-root-filesystem-until-we-start-udev
<Keybuk> etc.
<Keybuk> the only bug it introduces is that some packages assume that they have subdirectories in /var/run with certain attributes
<Keybuk> which, granted, the FHS says they're allowed to do
<Keybuk> it's trivial to fix though, just a mkdir in the init script
<siretart> err, could you please point me to some discussion for what udev needs to write into /var/run?
<Keybuk> siretart: dhcp pid files.  network ifstate file.  alsa state files.  etc,.
<ogra> there must be irc logs of that discussion
<ogra> it happened either here or in -meeting iirc
<Keybuk> it's happened here, then was agreed in a TB meeting
<siretart> hm. i see.
<Kamion> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-January/000048.html
<siretart> hmhmm. would mounting over a unionfs (udev writes to a tempfs, which is unioned over a non-tempfs /var/run) be a solution?
<Keybuk> siretart: that's a solution looking for a problem, isn't it?
<siretart> thanks for the link
<Keybuk> it's FAR easier to just add a mkdir call in the few places it's still needed
<siretart> Keybuk: I'm a bit sceptic about the 'in the few places ... needed' part
<Keybuk> siretart: it's easy to find out, just grep the archive for any package with a /var/run/* in it
<Keybuk> there weren't that many
<siretart> Keybuk: will debian use the same approach? can I expect DDs to be happy about such patches?
<Keybuk> siretart: no idea, ask DDs
<siretart> Keybuk: I think I'm talking to one right now ;)
<Keybuk> siretart: most of the packages in -desktop already had such patches from Debian, because people had filed bugs there when they tried the same thing
<Kamion> I see no reason why Debian developers would have any issue at all with trivial patches to support /var/run on tmpfs
<Kamion> after all, they'd be no-ops if /var/run isn't on tmpfs
<siretart> ok. thanks again for the pointer.
<Keybuk> I've discussed the /var/run-as-tmpfs thing in Debian before, and it was certainly my impression that most people thought Debian *should* support it
<seb128> doko__: is some python sys.path issue known on dapper atm?
<seb128> Kamion: did you accept/promote libnotify1?
<Kamion> seb128: not yet, I've had better things to do today than sit polling helena output
<Kamion> I'll do it now
<Kamion> in future it would be much better if you could only ask me to do something once it's actually built and uploaded
<Kamion> or at least built, since I guess you can't tell whether it's uploaded or not
<seb128> Kamion: I asked on IRC 2 hours ago when mvo screwed libnotify0, but no big deal, thank you :)
<seb128> oh, sure
<Kamion> yes, and at that point it wasn't in the queue, nor was it the next time I checked, and then it fell off my stack
<seb128> understood, sorry for that
<seb128> I'm not sure if stuff points to NEW when they are accepted or built in fact
<seb128> that's why I ping after upload usually
<Kamion> ok, accepted/promoted now
<seb128> thank you!
* mvo grabs a brown paperbag
<Kamion> it hits NEW if the source package name is new
<Kamion> (on source upload)
<Kamion> if not but some binary package names are new, then it hits NEW after the buildds munch it, when they upload the binaries
<seb128> ok, thanks
<slomo> Kamion: hi, can you either move xine-extracodecs (with all binary packages) to multiverse or libxine-extracodecs back to universe? currently libxine1c2 in universe depends on libxine-extracodecs and is uninstallable because of that...
<seb128> and for new source/binary it hits NEW 2 times so?
<Kamion> accepted mails get sent when source uploads hit queue/accepted (implying either that they didn't go through NEW, or that they've just been NEW-approved)
<seb128> ok
<seb128> thanks for the explanations on that :)
<Kamion> seb128: yes
<seb128> doko__: is that known?
<seb128> <gicmo> /usr/lib/python2.4/site.py: broken symbolic link to `/etc/python2.4/site.py'
<seb128> <gicmo> hmm /etc/phython2.4 is empty
<seb128> <gicmo> ii  python2.4-minimal     2.4.2-1ubuntu2        A minimal subset of the Python language (version 2.4)
<Kamion> slomo: would prefer if you asked elmo, I hear rumours he wasn't too happy about me accepting -extracodecs but I didn't get the details so I'd rather steer well clear
<Mez> is infinity on holiday or something
<Kamion> Mez: yes
<Kamion> (the former)
<slomo> Kamion: ok, i'll send him a mail... is he on vacation or something currently?
<Mez> Kamion, ah makes all the more sense why I cant get in contact with him
<Mez> when is he due back
<Kamion> slomo: perhaps he finds he gets more work done when not on IRC ... a tempting idea actually
<Keybuk> Kamion: interesting ... does this mean he'll either avoid sharing a conf. room with you in London or will he try out his alternate idea from Montreal and thus you should be worried if he sits in the same room as you?
<Lathiat> irc really is a suck at ties for getting work done
<Lathiat> *times
<Kamion> Mez: just send him mail, I'm sure he'll get to it when he gets back - I prefer not to give out full details of people's "hi, my house is empty" times in public if they haven't done so themselves
<Kamion> Keybuk: what was his alternate idea? :)
<Mez> Kamion: I didn't think of it that way :D
<Mez> Kamion: I believe it was somehting to do with tying people to chairs and forcing them to under the watchful eye of a brothel madam
<Mez> or something similar
<Keybuk> Kamion: "I need to find someone people I hate"
<doko__> \sh, Mithrandir: vnc4: if it's based on xorg sources, it's less crack, but you can still smoke it ...
<Kamion> heh
<doko__> seb128: I can't see when /etc/python2.4 should be empty, of course when it's purged, but not earlier ...
<seb128> doko: it's happening for 3 person now
<doko> seb128: new installations?
<seb128> no
<seb128> daily dist-upgrade for that guy
<doko> seb128: it's not touch in any way. strange.
<seb128> in fact the 2 others guys probably have a different issue
<seb128> they have it on the colony 3 CD
<seb128> flight 3 I mean
<doko> live??
<seb128> and pygobject was broken when the CD have been rolled I think
<seb128> doko: gicmo has a standard install, gedit was crashing because pygtk not found, we traced that to /etc/python2.4 not beeing here
<Diziet> Aaargh, FFS, I don't want sys.exit to raise a bloody exception, I want it to _exit_ dammit !
* Diziet switches to using os._exit
<Keybuk> heh
<Keybuk> you know what's really fun
<Keybuk> when you do something like:
<Keybuk> try:
<Keybuk>    os.fork()
<Keybuk>   # in child
<Keybuk>   exec()
<Keybuk>   sys.exit(255)
<Diziet> *snort*
<Keybuk> because then the sys.exit gets handled by the exception handler OUTSIDE of where you thought the child could exist
<Diziet> What does that remind you of ? :-)
<Keybuk> exactly the same bug I once found in dpkg? :p
<pef> hello
<bddebian> Hello pef
<pef> heya bddebian :)
<seb128> Kamion: could you give a retry evolution update-notifier builds ?
<fabbione> doko: ping?
<doko> fabbione: pong
<fabbione> doko: hey dude...
<fabbione> doko: in the last bash upload, bash completion on ssh $host<tab> is broken :(
<Kamion> seb128: evolution's in accepted, nothing to retry
<fabbione> it stalls on a very long sed
<fabbione> doko: i also have 2 questions.. any gcc/gcj/ooo2 upload plans within the next 24 hours?
<Kamion> seb128: and update-notifier's in sync in the archive for everything except hppa/sparc, also nothing to retry
<fabbione> actually one question...
<seb128> Kamion: yeah, it was probably dep-wait and retried itself, thank you
<fabbione> Kamion: sparc is getting there.. 4 buildds running atm
<doko> fabbione: uploads: no, bash_completion; ehh, I'll look again, I did want to _fix_ it :-/
<fabbione> doko: ok thanks :)
<dholbach> elm
<dholbach> oops
<bddebian> elmoops?
<pef> what should I do when a package build-depends on now non longer existent automake1.6 package ? try to build it with automake1.7 1.9 ?
<bddebian> pef: Yep :-)
<pef> bddebian: or try to build with automake1.{7,8,9} and set bdepends to automake1.7|automake1.8 and so ?
<Treenaks> BenC: Who do I poke for bcm430x breakage?
<bddebian> pef: I really don't know
<bddebian> I'm stupid and have forgotten more than I ever knew :-)
<pef> :^)
<pef> bddebian: thanks anyway I think keeping version-depends as lower as possible is the better solution
<pef> diner
<vuntz> Kamion: may I query you some words about lmanul for tonight's cc meeting?
<janimo> ogra, do you know if g-p-m/hal will be used for reboot shutdown as well besides power management?
<pitti> janimo: it can be used for that
<janimo> yes but will it be used ? :)
<janimo> I see hal has got the scripts
<janimo> it would be nice to have one interface
<janimo> and make gdm use it too
<pitti> then you had to dbusify gdm
<pitti> not worth the trouble IMHO
<pitti> unless upstream wants to do it
<Kamion> vuntz: sure
<janimo> hmm, gdm cannot do suspend ATM right?
<pitti> janimo: it shuold be able to
<pitti> janimo: at least the logout dialog can
<janimo> ah I seem to recall calling pmi directly 
<pitti> yes
<janimo> in debian/patches
<janimo> pitti, but if it was do do it though hal, then via dbus is the only way right? g-p-m is not there at that point
<pitti> janimo: right
<pitti> I have heard some weird hacks to give gdm it's own g-p-m, but that's pretty crazy
<janimo> is hal supposed to be up at login dialog point
<pitti> janimo: alternatively gdm could use dbus-send
<pitti> janimo: yes, it is
<pitti> but if it fails for some reason, you couldn't shutdown your box
<pitti> so better not rely on hald if we can avoid it IMHO
* pitti -> dinner, bbl
<janimo> good point
<Diziet> Can I do this ?
<Diziet> autodebtest (0.5.1) dapper unstable; urgency=low
<pitti> I'll go offline during dinner to save some modem costs (I want my main network back, bah) - cu later
<Kamion> Diziet: more conventional would be to upload to unstable and ask James Troup to sync the package to dapper
<Diziet> OK, I'll do that.  Do I have to wait for my ack from ftp.debian ?
<Kamion> (I'm not sure whether the above would work or not)
<Diziet> I was sort of hoping each would ignore the unknown suites, but that did seem rather optimistic ...
<Kamion> oh, you'd have to wait until it's NEW-processed in Debian
<Kamion> we don't sync from non-publicly-visible locations to avoid hat confusion
<Diziet> Yes.  In this case I'm wearing both hats at once.
<Kamion> hat confusion for James
<bddebian> heh
<Diziet> Ah, yes, very sensible.
<bddebian> Better than gender confusion I suppose :-)
* Kamion -> dinner
* Keybuk -> dinner also
<BenC> Treenaks: bcm43xx.berlios.de
<dholbach> See you tomorrow - bye!
<mdke> my GNOME crashes when I try and logout. I don't see a bug on it, is it known?
<crimsun> mdke: are you current as of now?
<crimsun> it should be fixed now
<mdke> yesterday
<mdke> crimsun, thanks i'll upgrade
<dana2>  has to go today 1 alienware laptop 1 alienware desktop. price 500 each includes shipping and carry case for the laptop or monitor/keyboard/mouse for the desktop. message me if your interested at mcsltd1@hotmail.com, or ogd443 on aim or mcsltd2 on yahoo messenger. these MUST go today!
<crimsun> quit it.
<tseng> crimsun: it cant hear you, you need a kline.
<\sh> for free I would take it..you pay the shipping fees....
<\sh> lamont: can you tell me why lablgtk2_2.6.0 only compiled on amd64 but not on i386/ppc?
<crimsun> \sh: Dep-Wait by buildd+terranova
<\sh> crimsun: grmpf...
<\sh> I didn't check the lists...gnarf
<\sh> crimsun: on what? 
<crimsun> liblablgl-ocaml-dev
<\sh> should be there...
<\sh> lamont: could you free lablgtk2_2.6.0 from it's dep-wait? thx :)
<\sh> actually it's there in my i386 chroot
<crimsun> well, lablgl ftbfs on [!amd64] 
<crimsun> (http://people.ubuntu.com/~lamont/buildLogs/l/lablgl/1.02-1/)
<\sh> oh I'm damned...another package to fix before everything else
<\sh> fck
<\sh> ok..fixing "gal"s unmet dep first...
<lamont> lablgl_1.02-1_20060124-1959-i386-successful.gz
<\sh> then lablgl
<lamont> \sh: lablgl stands a very good chance of living now
<\sh> lamont: don't confuse me now, pls :)
<crimsun> ah, it just finished
<lamont> \sh: give lablgl about 20 minutes before you worry about it
<lamont> or maybe 30
<\sh> lamont: but if everything is ok now, and lablgl is installed, please release lablgtk2 from it's dep-wait...whileI
<\sh> while I'm checking out gal
<lamont> \sh: once lablgl is really, there, lablgtk2 _WILL_ release from it's dep-wait
<\sh> lamont: ah good to hear...I thought it needs manual intervention :)
<ogra> lamont, did you get my give back request for dia ? 
<lamont> the only time I have to actually get involved in releasing a d-w is when the package is dep-waited on something that isn't there (either virtual packages like libgl-dev, or removed packages like lib${foo}3)
<lamont> ogra:sorry - looking now
<ogra> thanks :)
<ogra> i'm not in a hurry :)
<lamont> dia is main or universe?
<ogra> main
<ogra> at least dia-gnome is
<ogra> which is what i need for edubuntu-desktop 
<\sh> hmmm..this is more strange...libgal2.4-0, libgal2.4-common is in universe, while libgal2-dev is in main...something is wrong here, isn't it?
<ogra> the libs were not in sync during the build attempt
<\sh> oh god..plural == are in universe
<lamont> buildLogs/Lists/dapper.all.amd64:graphics/dia_0.94.0-17.1: Installed by buildd+crested [optional:out-of-date] 
<lamont> buildLogs/Lists/dapper.all.hppa:graphics/dia_0.94.0-17.1: Installed [optional:out-of-date] 
<lamont> buildLogs/Lists/dapper.all.i386:graphics/dia_0.94.0-17.1: Installed by buildd+rothera [optional:out-of-date] 
<lamont> buildLogs/Lists/dapper.all.ia64:graphics/dia_0.94.0-17.1: Building by buildd+weddell [optional:out-of-date] 
<sivang> hi all
<lamont> buildLogs/Lists/dapper.all.powerpc:graphics/dia_0.94.0-17.1: Building by buildd+ross [optional:out-of-date] 
<lamont> buildLogs/Lists/dapper.all.sparc:graphics/dia_0.94.0-17.1: Needs-Build [optional:out-of-date] 
<lamont> given back on ia64 and ppc
<ogra> thanks :)
<\sh> ogra: what was the url to have a look on the demotions and promotions from main to universe, and vice versa?
<Kamion> \sh: libgal2-dev's in the list to be demoted to universe
<\sh> Kamion: ah...thx :)
<mvo> janimo: hi! do you plan to use update-manager in xubuntu as well? or does it has too many gnome depends for you :) ?
<Kamion> I'll leave it until I've checked with seb128 though
<ogra> \sh, anastacia.txt in mdz's people account
<Kamion> \sh: http://people.ubuntu.com/~mdz/anastacia.txt
<Kamion> it's a bit of a mess at the moment
<janimo> mvo, I looked at it and had quite some gnome deps :)
<janimo> if they can be cleanely factored out I'd like to use it
<\sh> Kamion: could be this the reason why it's uninstallable right now?
<janimo> mvo, it does have a python part also right?
<Kamion> in main? yes
<\sh> Kamion: yes, -dev in main and lib in universe
<Kamion> yes
<\sh> Kamion: thx
<mvo> janimo: I ask because we'll have the upgrade-tool for dapper and it might be interessting to have that working with xubuntu as well
<mvo> janimo: it's all python (pygtk+python-apt)
<janimo> mvo, if it's all python it's fine except
<sivang> pitti: ping
<janimo> the python-gnome bindings are not too fine grained from what I saw
<janimo> and if you use for instance gnome-canvas instead of needed that single gnome leaf library
<martinhj> str til?
<mvo> so python-gnome2 is too much for you, riht?
<janimo> it brings all in (ui,bonobo,vfs) on disk I mean not memory thankfully
<martinhj> sorry
<janimo> mvo, I think it is too late to have a python-canvas separate package
<janimo> you do not actually use bonobo or other core gnoem stuff I assume?
<mvo> janimo: I will have a look, it don't use that much gnome, it may be possible to make it plain pygtk+python-glade
<janimo> most uses of gnome libs (C and python) I see fall into calling gnome_help or gnome_program init
<mvo> janimo: the important stuff is the gnome help system
<janimo> which could be done with ftk
<janimo> ok, gnome.display_help is equivalent to exec yelp
<janimo> or even better gnome-open
<janimo> if it's installed (gnome envirnment) great
<janimo> if not maybe a small popup dialog telling that to the user
<janimo> this is how I replaces gnome.help  with the exec in launchpad integration lib so gaim, firefox etc do not depend on gnome in breezy
<janimo> mvo, thanks if you could make it gtk/glade only it would be awesome
<mvo> I would be interessted in it to make xubuntu-desktop upgrades possible 
<janimo> mvo, yes me too :)
<mvo> janimo: xubuntu-desktop is availabe in breezy as well, right? 
<janimo> so the updater is a python program and also a gnome applet IIRC?
<janimo> mvo, yes in breezy too
<mvo> janimo: the applet is a C application (a seperate one)
<janimo> that is not essential right? I mean the updater can be launched as a standalone app
<mvo> yes, exactly
<janimo> but I may adapt it to the xfce panel as a plugin
<mvo> it should already run in the xfce panel as it's a normal tray applet
<mvo> but it uses gnomevfs
<janimo> does the app have a systray component and uses libnotify?
<mvo> yes, both
<janimo> I have just looked today at g-p-m and it is similar
<mvo> it's probably harder to rip out the gnome stuff there
<mvo> update-manger should be much easier
<janimo> except its use of (understandable) gnomesession saving it could be just as well written with gtk 
<mvo> yes. it uses gnome-vfs though to monitor for apt/dpkg activity (and hooks)
<janimo> oh yeah swicthed from gamin IIRC
<mvo> yes, we may be able to get rid of libgamin for dapper
<janimo> oh is it not a core gnome dep?
<tseng> not anymore
<janimo> does vfs talk directly to inotify now?
<tseng> ya
<mvo> that's why I switched as well
<AlinuxOS> people how can I translate gnome-menus in my own language...?
<AlinuxOS>  I've alredy done it... compile .po file into .mo file... put it in right directory..but menus are still in english :((
<janimo> mvo, I have an older update manager (0.40) source pkg and grepping through it shows that indeed gnome.init and gnome.help_display_desktop are used only
<janimo> gtk.init and exec gnome-open may just do the trick
<trappist> it seems alsaconf was very intentionally left out of alsa-utils.  anyone know why?
<mvo> janimo: thanks, I'll try to find time tomorrow to fix that and fix the dist-upgrader to know about xubuntu-desktop as well
<janimo> mvo, thanks :)
<trappist> I was about to file a bug on the package but I thought I'd have a look first to make sure it wasn't intentional
<trappist> the lines that remove it are preceded by "# do not install alsaconf for Ubuntu"
<Burgwork> trappist, you need to talk with pitti about that I believe
<wasabi_> Something just busted up my networking. Looks like the handling of /etc/networks/interfaces changes
* trappist hilights pitti
<wasabi_> I ended up having two auto eth0 lines in it, so networking failed on start.
<pitti> re
<pitti> trappist: yes?
<pitti> trappist: you miss alsaconf?
<trappist> pitti: wondering about omitting alsaconf from alsa-utils.  they say you're the guy to ask.
<trappist> I do
<pitti> trappist: uh, we removed it back in warty or so; basically you should never need it
<sivang> pitti: hi
<pitti> since hotplug & co automatically care for loading drivers and such
* pitti waves to sivang
* sivang hugs pitti
<trappist> I know there are other solutions, but I've been noticing in #ubuntu for example that it's sorely missed.  online documentation points to it, sound doesn't always 'just work', people coming from other distros are accustomed to it, etc.
<\sh> pitti: did you read the CVEs about openmotif?
<pitti> \sh: no, which?
<sivang> pitti: have you had a chance to see nomed's stuff, the mount notifications stuff done by some guy who started the dsslive.org project. It seems very nice, written in python. something I think could power up the user experience on desktop Ubuntu.
<\sh> pitti: https://launchpad.net/malone/bugs/29398
<Ubugtu> Malone bug 29398: "CVE-2005-3964: Two exploitable buffer overflows in openmotif" Fix req. for: openmotif (Ubuntu), Severity: Normal, Assigned to: MOTU, Status: Unconfirmed
<pitti> sivang: I never heard about that
<pitti> \sh: I see
<\sh> pitti: I tried to get some patches from openmotifs homepage...but nothing I found about it...
<\sh> pitti: only new upstream version
<\sh> pitti: but most likely the new version has this buffer overflow as well, and the reporter wasn't testing it with 2.2.4 as I understand him
<trappist> pitti: I know there are other solutions, but I've been noticing in #ubuntu for example that it's sorely missed.  online documentation points to it, sound doesn't always 'just work', people coming from other distros are accustomed to it, etc.
<sivang> pitti: I see, well there's an svn repo that represents a debian source pkg, with that guy's assitance, I instaleld on on my dapper and it works nicely. he also makes it configurable with xml files to match against mout / plug actions. The nicest thing about it, is that it allows you to responde to plugging events, so you can mount a CD rom volume if you inserted one, usb drive volumes etc. basically I understood from him he is going to extend it 
<pitti> \sh: they don't have a public cvs?
<pitti> trappist: hm, I'm not totally sure why we removed it back then, mdz should know
<\sh> pitti: ah..I just looked at the wrong place...openmotif.org is that what I need, will investigate further tomorrow, 
<pitti> sivang: sounds like gnome-volume-manager
<pitti> sivang: what's the difference to g-v-m?
<trappist> pitti: according to http://www.ubuntuforums.org/showthread.php?t=52941 the reason is pretty much what you said, but imho "shouldn't be needed" isn't the same as "shouldn't be provided"
<pitti> \sh: http://cvs.motifzone.net/cgi-bin/cvsweb.cgi/openmotif/?cvsroot=openmotif
<sivang> pitti: this is not a volume manager, but rather volume mount notifications stack that can work with g-v-m or something else.
<sivang> pitti: or maybe it is? :)
<\sh> pitti: nothing
<pitti> trappist: well, I wouldn't mind shipping it again; can you talk to mdz tomorrow? Maybe I'm not aware of the reasons
<ogra> iirc, it broke the setups 
<ogra> but dont ask in which way, thats all i remember ...
<trappist> pitti: I'll keep an eye out for him, thanks
<pitti> thank you
<lamont> Unpacking vpopmail-bin (from .../vpopmail-bin_5.4.4-1_hppa.deb) ...
<lamont> Creating vchkpw group.../var/lib/dpkg/tmp.ci/preinst: line 71: addgroup: command not found
<sivang> pitti: if it's easy to do with g-v-m, is this something that could be / is rejected by UI usability stand point?
<pitti> sivang: dunno, for that I need to know what that program actually does
<pitti> sivang: g-v-m's purpose is to execute desktop actions in response to hardware changes
<seb128> pitti: what is the topic?
<sivang> pitti: and it's arbitrarily extendible, as in adding / removing new actions right?
<pitti_> yay my network
<sivang> pitti_: I'll replay :)
<sivang> pitti_: and it's arbitrarily extendible, as in adding / removing new actions right?
<sivang> err
<sivang> :)
<sivang> pitti: changing nicks just as I address you :)
<pitti> sivang: no, g-v-m isn't; you can arbitrarily define the actions for a fixed set of events
<segfault> i'm unable to boot in vmware using the latest kernel. has anyone tried?
<sivang> pitti: ah, I see. still adding notifications (as in libnotify desktop notifications) is independent of that.
<ogra> sivang, having an additional g-v-m-dbus-listener process that pops up messages if mount/umount messages hit the dbus should be quite trivial
<sivang> ogra: yes, that's what I'm saying :)
<ogra> but who would want popups for all events ? :)
<sivang> ogra: also allow you to respond to them, for example I get many complaints from converted people from windoze, that they need to "find" the computer item in places, and then browse and mount their volumes.
<sivang> ogra: they would prefer it popping up as windoze does, allowing them "to browse" or wahtever
<ogra> apart from "i dont know how to hanlde this device" i wouldnt know any usecase 
<tseng> if it doesnt know how to handle it
<tseng> chances are the user doesnt know where to go from there anyway
<Lathiat> 
<ogra> yes
<ogra> sivang, for me a window opens if i plug in a device ...
<ogra> no need for a popup
<pitti> and an icon appears on the desktop as well
<ogra> tseng, the popup could have a button that starts the hwdb client and opens a bugreport with the hwdb id attached ;)
<sivang> yes, but if their desktop is currently out of ficus, or minimized they don't get it
<sivang> ogra: lol
<tseng> ogra: sure
<sivang> tseng: what do you mean "if it doesn't know how to handle it" ?
<tseng> sivang: no driver is hotplugged
<sivang> tseng: yes, but what has it go to do to the notification stuff?
<bradb> Hey all, I'm looking for some feedback on UI prototypes for the reports for packages you've told Malone to send you bugmail on.
<bradb> http://flickr.com/photos/84096161@N00/
<jbailey> bradb: How is that changed if I don't want it to send me bugmail at all, ever.
<jbailey> ?
<bradb> search_results, simple_search, and advanced_search
<bradb> jbailey: segmentation fault
<bradb> I guess these would be mostly irrelevant to you, for now.
<jbailey> bradb: Well, I expect to receive bugs, but I prefer to use  a web interface and the search queries, especially as you have them there.
<jbailey> I'm wondering if the idea of subscribing to a package and receiving bugmail is infinitely coupled.
<bradb> It needn't be.
<bradb> But in the short term it will continue to be.
<jbailey> 'k
<sivang> pitti, ogra : the code I saw is here http://svn.berlios.de/wsvn/dss/dss-main/nomed/trunk/?rev=0&sc=0
<Burgwork> bradb, sorry, I don't like your new bug page. It is still much too busy
<sivang> ogra: (I sent you something from there the other day)
<sivang> anyway folks, I gotta hit bed already :-(
<sivang> night all
<Evaso> any support for dm-raid in the live-cd/installer of dapper?
<bradb> Burgwork: How would you prefer it to look? (With consideration for page loads and clicks required to get things done.)
<Kamion> Evaso: psusi has been working on it
<Kamion> but no, not yet
<Burgwork> bradb, the top table needs some data ordering by priority. Everything is all the same size
<Evaso> Kamion: is there something in the svn?
<Kamion> Evaso: no
<bradb> Burgwork: According to whose priority? :)
<Burgwork> bradb, the one you figure out must people need
<bradb> Burgwork: In any case, I'm interested in getting your and others' feedback on the three pages noted above. What do you think of those?
<Burgwork> advanced search isn
<Burgwork> t bad, working within the existing limitations of the LP interface
<Burgwork> bradb, your bug listing method is crap, to be honest
<Burgwork> it needs to be in a table, to be trivially resorted
<Burgwork> like the old method
<bradb> Burgwork: How would you suggest a table layout be done in the three column layout?
<Burgwork> bradb, I would like to junk the three column layout, to be honest
<tseng> Burgwork++
<bradb> You guys can help make these things change if you write your concerns to launchpad-users@.
<bradb> If you don't, they'll remain as they are right now.
<tseng> are you sure you want to *invite* Burgwork to post on your list?
<tseng> he is unstoppable
<jbailey> bradb: Hover-based fisheye for the side columns YOU KNOW YOU WANT IT BABY!
<bddebian> Heh
<bradb> *invite*? launchpad-users is public. :)
<jbailey> bddebian: Hey, two days in a row.  Good to see you. =)
<tseng> dont say I didnt warn you
<bddebian> jbailey: Thanks, you too
<Burgwork> bradb, I would suggest you talk to jbailey and Keybuk. The presented an excellent layout at UBZ to mpt (I snuck in to watch)
<bradb> Burgwork: I've talked to them, and saw the layout.
<jbailey> Burgwork: Ah, I'm pretty certain we inflicted that on just about everyone in the launchpad team. =)
<Burgwork> jbailey, excellent work!
<jbailey> And most of the conference, given our hallway usability studies. =)
<bradb> I hate the portlets at least as much as you guys, but I can promise you they'll be there for as long as you guys aren't writing your complaints in a place that the sab can see them.
<bradb> I doubt he reads l-u@, but at least we have archive URLs.
* Burgwork sighs and signs up to another mailing list
<bradb> Burgwork: I get the impression that you think we *chose* this layout. :)
<Burgwork> bradb, here is good quote for you. "After the table layout change, that was the straw that broke the camels back for me and bug triaging in Malone"
<bradb> Burgwork: You're preaching to the choir dude.
<Burgwork> hey, I don't work for Canonical. I can email sabdfl and tell him how LP needs a new layout without risking my job!
<bradb> Burgwork: Then you should.
<mjg59> Ok, I've uploaded a fixed dbus
<bradb> Burgwork: iwj did. :)
<ogra> mjg59, \o/
<Burgwork> anyway, the work part of the my nick actually means I supposed to be working and not on IRC
<bradb> ok
<torkel> pitti: ping?
<pitti> hi torkel 
<torkel> hi pitti
<torkel> pitti: did you forget to actually depend on alsa-util in you upload of control-center?
<pitti> torkel: well, yes and no. I patched debian/control instead of debian/control.in
<pitti> torkel: thanks for spotting
<pitti> *grumpf*
<torkel> np
<mjg59> Oh why is dbus FTBFS now?
<ogra> mjg59, configure.in:220: error: possibly undefined macro: AM_PROG_LIBTOOL
<AlinuxOS> pitti, hello :)
<mjg59> That shouldn't be an issue
<mjg59> Hm. No, maybe it is.
<ogra> in any case some autotools stuff ...
<mjg59> Oh, probably needs to build-dep on libtool
<segfault> anyone tried 2.6.15-13-686 in vmware 5.0?
<pitti> mjg59: shouldn't it rather avoid calling autobreak during package build?
<mjg59> pitti: No, because that defeats the object of having broken out patches
<torkel> segfault: does it even build? I tried to build latest vmplayer some time ago, but it failed on -12 IIRC, and I didn't have time to look into it
<segfault> yes, i'm running vmware. but after the latest update, it doesn't boot anymore. i have lvm partitions :-)
<segfault> and it cant find them
<torkel> segfault: hm, guess I should retry a build then
<Tm_T> humm, no fonts matching to -misc-fixed-medium-r-semicondensed--*-*-*-*-c-*-*-*
<Tm_T> not good
<Tm_T> problem is, osd_cat doesn't work ;)
<pitti> jordi: ping
<\sh> bah...I hate mozilla sources and location changes...moving from one location to another location
<pitti> good night everybody
<tseng> bye pitti 
#ubuntu-devel 2007-01-22
<facenew> OT: a 30-min movie mocking kim jong il and his secret agent buying something from china: http://www.youtube.com/view_play_list?p=EE52D9ED01495685
<mdke> surely on the cusp between on-topic and off-topic
<jdub> hrm
<jdub> what's with elementtree not working with python2.5?
<jdub> oh, perhaps it was included with python2.5
<BradonH> just looking for feedback on an idea i had. Launchpad is https://blueprints.launchpad.net/ubuntu/+spec/voip-tech-support
<BradonH> maybe ill try the #ubuntu irc..
<jdong> cjwatson: ping; is it possible for future backports processing to note the corresponding LP bug # in the changelog? That'd be really helpful for the UWN guys who try to document dapper/edgy updates in each issue
<somerville32> jdong: How would it help me?
<somerville32> jdong: Are backports upload notifications not sent to -changes ml?
<jdong> somerville32: it is sent to $distro-changes
<somerville32> Right
<somerville32> We simply list backports
<somerville32> Why would we need to refer to the bug reports for them?
<jdong> somerville32: sometimes certain backports have more significance than "it's just a backport".... with my free time I'd like to expand on at least some of them
<somerville32> Ah, ok
<somerville32> Sounds fair enough
<jdong> and if I'm not around for doing that it'd be cool if others can do the same :)
<jdong> just trying to think how I could make that easier to do
<jdong> somerville32: like most notably, the recently built p7zip backport implements multithreaded compress and decompression for 7zip, which is a BIG deal for dual/quad-core users
<jdong> and lzma is now easy enough that a caveman can use it (tm)
<somerville32> Oh my
<somerville32> :)
<jdong> if not mentioned I doubt 90% of our user base would figure that out on their own... and being able to see the backport LP bug that led to a particular backport would be enlightening to a degree for those who like to "screen" their updates
<Chipzz> jdong: those who like to screen their updates would install apt-listchanges? :)
<jdong> Chipzz: well, having it in a weekly magazine like form makes more sense :)
<jdong> like look at FWN
<jdong> they have full blog-style changelogs for all their updates :)
<jdong> all 80 bazillion
<Chipzz> fwn = fridge weekly news?
<jdong> fedora
<Chipzz> is apt-listchanges installed by default btw?
<Chipzz> might be a good idea, given that the news file sometimes has quite important information
<jdong> no, it's not by default...
<Kano> hi, please update mc in feisty. it is broken badly!
* Mez growls
<Mez> cjwatson, ping regarding devscripts
* Mez bitches on the mailing list
<owh> Greetings. On Jan 2 I sent an email to the u-devel list as suggested by sistpoty. I didn't receive any replies. I am not sure if I asked the wrong question, or broke any etiquette rules, but would like some feedback. This is the message: http://article.gmane.org/gmane.linux.ubuntu.devel/23154,
<Mithrandir> owh: you might just have asked a question not many people are interested in.  Your mail isn't inappropriate, at least.
<owh> Mithrandir: That's something then :-)
<owh> How would I best go about soliciting feedback?
<owh> I am reluctant to implement new functionality as a bug fix.
<tepsipakki> something in feisty decides to remove my .Xauthority on login
<Mithrandir> owh: once Martin Pitt (pitt) shows up, you might want to talk to him, he's been doing most of the work on removable devices, etc, where fat is most common.
<Mithrandir> owh: sorry, pitti is his irc nick.
* owh goes and hunts for his TZ :-)
<Mithrandir> CET, so he should be around soonish.
* mjg59 yawns
<owh> Mithrandir: Excellent. Thanks for that.
* Mithrandir leaves for the sprint.
<mjg59> I have no idea what time my body thinks it is
<LaserJock> where is the sprint being held this time?
<tepsipakki> Oslo?
<tepsipakki> Laserjock: ^
<LaserJock> oh yeah
<mjg59> Yeah
<LaserJock> seems like that would be a fun place to visit
<owh> Sprint?
<LaserJock> although I've always wanted to go for my Nobel acceptance speech ;-)
* owh thought the reference was to catching the bus :-)
<LaserJock> although I'm not sure Physical Chemists fair to well winning Nobel's
<LaserJock> I guess I'll just have to resign myself to making Ubuntu core-dev one of these days ;-)
<owh> LaserJock: One step at a time...
<olympionex> what source does the livecd use for setting up the /etc/passwd when booting?  Something appears to be overwriting the /etc/passwd file in the squashfs.  I've checked the initrd, and preseeding and unionfs branches, but I don't see it yet.
<owh> pitti: Have you got a few moments to talk about FAT32?
<pitti> owh: hi; not sure whether I'm the right one to talk to, but what's up?
<LaserJock> olympionex: could it be when the Livecd user is set up?
<owh> pitti: I have been debugging dosfstools with sistpoty and sent an email to u-devel about some feature development. I would like some feedback on the message. http://article.gmane.org/gmane.linux.ubuntu.devel/23154
<owh> pitti: I was told by Mithrandir:  that you have been working with removable drives where lots of FAT happens.
<pitti> owh: I'll take a look at it in a bit (we'll have a talk now)
<owh> pitti: We, as in you and I, or you and others where you are?
<pitti> owh: distro team meeting/sprint in Oslo, just started 5 minutes ago :)
<owh> Cool
<Mithrandir> pitti: I didn't know whom to point owh to, but you was my best guess. :-)  Feel free to redirect if you think somebody else is better/more appropriate.
<pitti> Mithrandir: sure
<olympionex> LaserJock: I believe that is what I'm looking for.  Where is that user setup?
<LaserJock> olympionex: I think there is some casper script that does it. I'm not positive about that though
<Mithrandir> olympionex: casper preseeds the debconf db and calls the appropriate bit of user-setup
<Mithrandir> bhale: you're the winner of a main inclusion report for serpentine.  muine needs it.
<olympionex> Mithrandir: where are those preseed configurations located?  I found the ubuntu.seed which has very little, so it must be after that
<Mithrandir> olympionex: in /usr/share/initramfs-tools/scripts/casper-bottom/10adduser
<olympionex> Mithrandir: thank you
<dholbach> good morning
<simira> morning :)
<Mithrandir> seb128: gnome-applets need an upload; new libobbs soname.
<dholbach> hey simira
<dholbach> Mithrandir: can you tell me, once you get libgtksourceviewmm out of binary NEW? (it's not urgent, just nice to know) :)
<fabbione> Mithrandir: can i come close to you and look how SRU are done at archive management level? (yeah know.. glibc.. stuff like that :))
<jonibo> where does one report packaging bugs...?
<jonibo> gnome-applets has bad dependency on liboobs.
<Mithrandir> fabbione: "q -Q unapproved -s edgy-updates accept glibc" you mean? :-)
<fabbione> jonibo: launcpad
<fabbione> launchpad.net ^^
<jonibo> but "gnome-applets" does not use launchpad for bug tracking...
<fabbione> Mithrandir: yeah :)
<Mithrandir> jonibo: don't.
<jonibo> it is not an upstream bug but a packaging bug.
<Mithrandir> jonibo: a) it's already reported, b) it will be fixed automatically with the new gnome today.
<jonibo> ok... thanks.
<jonibo> but for future reference, how would I have reported it... launchpad does not accept bugs for this package.
<fabbione> jonibo: yes it does.. you just didn't look in the right place
<jonibo> fabbione: where? i am looking at it now and do not see it...
<Mithrandir> jonibo: if you go https://launchpad.net/ubuntu/+source/gnome-applets and you can choose "report a bug"
<jonibo> got it!  thanks.
<owh> pitti: I'm just going to cook some meat on the barbie, but I'll be back.
<seb128> jonibo: no need of open bugs about bad Dependencies during unstable cycle, they are automatically listed
<\sh> moins
* Mithrandir looks around for a victim^Wmotu who can ack some sync requests.
<Mithrandir> doko: python 2.5 includes python-chardet, was it so?  Should I remove it from the archive, then?
<ajmitch> Mithrandir: fire away
<Mithrandir> ajmitch: look at the bugs ubuntu-archive is subscribed to and with status=needsinfo
<doko> Mithrandir: is it?
<doko> I don't think so
<Mithrandir> doko: or some other python package I uploaded.
<StevenK> 2.5 incles cytpes, I'm not certain if any others have been subsumed into it
<ajmitch> celementtree, iirc
<ajmitch> so there are a few 
<pochu> maybe elementtree also?
<pochu> :)
<ajmitch> sure, there is a list of them
<Mithrandir> hi Scott
<Mithrandir> cjwatson: 51149 > I thought I fixed this in dapper..
<Keybuk> hey Tollef
<Keybuk> greetings from heathrow ...
<Keybuk> NB: I hate (a) flying (b) eyas
<ogra_> yay, Scott is coming !
* ogra_ agrees totally with b
<ogra_> (and a bit with a)
<Mithrandir> seb128: speaking og gnome control center, can you tell me why I don't have a control center menu item?
<Keybuk> they typo'd my passport number on my ETA to Sydney ... which was fun to sort out at the check-in desk
<Keybuk> and for an encore, booked my connecting flight to Oslo on the day *before* mthe previous leg arrived :p
<bhale> Mithrandir: sorry, are you sure? 'apt-cache showsrc muine | grep serpentine'
<Keybuk> which is always fun to find out after 24h on a plane
<fabbione> Keybuk: having fun eh?
<Keybuk> fabbione: categorically, no!
<Keybuk> the bright side is that the cheapest way to get me on the flight today was to send me Business Class, so I'm stocking up on the free coffee and muffins
<Mithrandir> bhale: hmm, no.  It was on feisty_probs.html for a while.
<fabbione> Keybuk: ehehe
<Keybuk> which prevents me from eating the Tim Tams I bought for you all
<thom> heh
<bhale> Mithrandir: there was a muine cd burner plugin, but we never packaged it
<iwj> Keybuk: So are you going to be late or will you make the flight originally intended ?
<bhale> separate source
<bhale> shrug :)
<Keybuk> iwj: I'm on the flight I originally intended to be on :)
<iwj> ... and upgraded.  Excellent :-).
<Keybuk> how is Oslo anyway?  cold and snowy, I hope?
<iwj> Yes, cold and some snow.
<Keybuk> it will make a refreshing change after the 40'C in Sydney
<Mithrandir> bhale: well, if it's fixed itself, I'm happy.
<StevenK> Keybuk: It so wasn't 40.
<Keybuk> StevenK: it was on Sunday :-/
<bhale> Mithrandir: alright, if it turns out to be a real problem please hit me with the clue bat
<StevenK> Hrm. I don't remember it being 40.
<seb128> Mithrandir: do you have a gnomecc.desktop to /etc/xdg/menus/settings.menu?
<Mithrandir> seb128: looks like it, yes.
<seb128> Mithrandir: what version of gnome-panel is installed? did you restart your panel since you updated it?
<Mithrandir> ii  gnome-panel    2.16.2-0ubuntu4 launcher and docking facility for GNOME 2
<Mithrandir> I think I've rebooted since, so yes.
<seb128> version is correct
<seb128> could you try to restart the panel in case?
<Mithrandir> seb128: my user isn't a member of the admin group, though
<seb128> Mithrandir: should not make a difference
<zyga> hello
<Hobbsee> hey zyga 
<simira> dholbach: are you guys back from lunch? Can you prod Tollef for me?
<dholbach> simira: can't see him
<dholbach> simira: but I'll prod him once he's near me
<simira> dholbach: hrmf. Probably meeting someone then.
<jwendell> doko, around? i'm getting error related to myspell while compiling firefox (feisty). Any idea?
<doko> jwendell: works fine for me (and on the buildd's as well)
<jwendell> doko, i just did an apt-get source firefox and ran debuild on it...
<triceratops> due to freedesktop org Bug 7097 keystrokes for Zoom X Desktop don't work. Am I right that the listed patch No2 is not included in Ubuntu Xorg? Does anyone know if there is a way to have X zoom keystrokes?
<Ubugtu> Malone bug 7097 in util-linux "util-linux: [hwclock]  want option to suppress drift information in --show" [Unknown,Unconfirmed]  https://launchpad.net/bugs/7097
<owh> doko: I was told on the weekend that you are the one to talk to about OO.o - I have figured out that the official downloaded version is different from the Ubuntu shipped on - in my case, specifically the Empty/Not Empty Auto Filter is missing. In the Ubuntu package I am unable to determine where you get the OO.o source from, The readme just says that it is out of date WRT v2.0.
<jwendell> doko, mozMySpell.h:59:24: error: hunspell.hxx: File not found
<jwendell> doko, it seems ./configure is not translating @MOZ_MYSPELL_CFLAGS@ ...
<jwendell> doko, any idea?
<doko> jwendell: did you rebuild configure?
<jwendell> doko, yes, i ran autoconf
<doko> owh: http://go-ooo.org/packages/OOE680/
<doko> jwendell: not my problem anymore :)
<jwendell> wow, thanks
<owh> doko: Tah muchly :-)
<jwendell> somebody can help me on compiling firefox? i'm just trying to help ubuntu...
<jwendell> dholbach, which command should i run to become autoconf.mk.in in autoconf.mk ?
<dholbach> autoconf?
<jwendell> dholbach, it looks for a configure.in file...
<dholbach> ah, you don't have that, hm
<jdong> infinity: ping?
<infinity> jdong: pong.
<jdong> infinity: did you get the messages I left for you from like two days ago? :)
<infinity> jdong: The one about the whacky build failure?
<jdong> infinity: yeah....
<infinity> jdong: I got it, I looked at it for a few seconds, went "that's not an obvious failure I know" and backburnered it for a bit while I'm putting out some bigger fires.
<infinity> jdong: Could you perhaps email me about it, so it doesn't slip off my radar?  IRC backscroll is a horrible TODO list.
<jdong> ok, sure
<infinity> jdong: Thanks.
<bddebian> Heya
<Kano> hi, could someone update xine-ui to the one from sid?
<Kano> vdr keybindings are missing in feisty one and there are 2 menu entries for it
<jdong> Kano: you might get a better response in #ubuntu-motu, the channel for universe development
<Kano> ok
<saispo> hi
<saispo> anyone work on debian-installer ?
<carlos> pitti: ping
<pitti> hey carlos
<carlos> pitti: hi, I'm looking at https://launchpad.net/ubuntu/+source/language-pack-gnome-es/+bug/79589
<Ubugtu> Malone bug 79589 in language-pack-gnome-es "language-pack-gnome-es not fully translated" [High,In progress]  
<carlos> pitti: how's that you uploaded a 20061201 package on 2007-01-15 ?
<pitti> carlos: apparently because there haven't been any updates since that date
<pitti> carlos: I only upload a new version to the dailies if there are actually changes
<carlos> so you mean that since 1st December, daily packages have been exporting the same ?
<carlos> no one did a translation in Dapper?
<pitti> carlos: not all of them, just for gnome-es
<carlos> oh, I see
<carlos> ok
<carlos> I'm a bit confused
<carlos> pitti: which tar.gz from Rosetta should I check?
<carlos> latest
<carlos> or the one on December?
<pitti> carlos: check for what?
<pitti> new translations?
<pitti> well, we should diff both then, I guess
<carlos> pitti: check why gnome-panel is not translated
<carlos> ok, so the timestamp in the version
<carlos> is the timestamp of the export from Rosetta, right?
<pitti> right
<carlos> ok
* carlos investigate a bit more
<carlos> hmm, I don't have any tarball from December, I removed them already as part of the cleanup we agreed to do from time to time...
<carlos> I will check latest one
<keescook> mornin'!
<zul> hey keescook 
<keescook> hi zul :)
<pitti> hey keescook, had a nice time at LCA?
<keescook> pitti: hi pitti.  yeah!  I spent the bulk of my time exploring Sydney, but I had fun meeting some (previously) online-only friends, listening to talks, hacking^Wusing the wifi, etc.
<pitti> keescook: I enjoyed the sun, Nice, and Monaco/Monte Carlo in the meantime :)
<keescook> pitti: excellent!  Looks like you were quite busy on Mon/Tue with security things, too.  Thanks!
<Mez> thx to whoever did the sync of ra
<Mez> r
<Mithrandir> you're welcome
<Mithrandir> hmm, three clicks, one selection and three key presses to go to a bug report, mark the right task as fix released, assigned to me, with the contents of the clipboard as reason.  Not all bad.
<pitti> Mithrandir: but this will be reduced to zero with ChangelogClosesBugs soon? :-)
<Mithrandir> pitti: no, since those are syncs.
<Mithrandir> but having alt-shift-[qwertyuio]  for opening tasks, alt-shift-p for paste-reason-mark-as-fixed-assign-to-me and alt-shift-s to save the report is really useful.
<Mithrandir> doko: can you confirm https://launchpad.net/ubuntu/+source/xchat-systray/+bug/79608 ? You uploaded xchat last, so I guess you might know.
<Ubugtu> Malone bug 79608 in xchat-systray "xchat-systray is not necessary in feisty anymore" [Undecided,Confirmed]  
<Mithrandir> ogra_: ping
<Mithrandir> kthx
<doko> Mithrandir: just the python update, but I can confirm that it's in the systray without having xchat-systray installed
<fabbione> same here
<Mithrandir> ogra did too, but thanks. :-)
<jwendell> doko, can you check my patch for bug 68663?
<Ubugtu> Malone bug 68663 in firefox "[Edgy]  Incompatible with Google Toolbar." [Medium,Confirmed]  https://launchpad.net/bugs/68663
<doko> jwendell: sorry, no.
<jwendell> mdz, can you?
<nukeDev> Hi All
<mdz> jwendell: the patch is consistent with your analysis of the problem; I can't say whether it's correct, but it sounds reasonable
<mdz> jwendell: the myspell change seems unrelated and potentially incorrect; doko recently changed it to use hunspell instead of myspell
<doko> mdz: ?
<jwendell> mdz, i could not compile firefox without that change... i was getting errors related to myspell stuff
<mdz> doko: firefox (2.0.0.1+0dfsg-0ubuntu2) feisty; urgency=low
<mdz>   * Build using hunspell instead of myspell.
<pitti> hi glatzor 
<doko> mdz: spellchecking works with this version
<mdz> jwendell: it seems to build OK on the autobuilders: https://launchpad.net/ubuntu/+source/firefox/2.0.0.1+0dfsg-0ubuntu2
<glatzor> evening pitti
<jwendell> mdz, doko, at least, that patch shows that the fix for that bug is easy to be made. Is there any chance it get in the next firefox release?
<mdz> jwendell: sure, but there's no one working on a new firefox release at the moment
<somerville32> Bug #56161 <-- Can a core-dev please upload? :)
<Ubugtu> Malone bug 56161 in mousepad "Segfault when saving files on AMD64" [Medium,In progress]  https://launchpad.net/bugs/56161
<mdz> somerville32: I believe there's a team in launchpad for that purpose; this channel isn't continuously monitored for such requests
<somerville32> mdz: I have subscribed them but I thought I might make a quick shout out in here to catch someone's attention.
<cjwatson> saispo: yes
<cjwatson> saispo: ... but it's dinnertime now, so send mail or something
<Mithrandir> dholbach: https://launchpad.net/ubuntu/edgy/+source/wxwidgets2.6/+bug/59138 seems to be missing a +1 from another motu-sru member; could you perhaps look at it?
<Ubugtu> Malone bug 59138 in wxwidgets "[SRU: EDGY]  amule crashes when I close a tab" [Unknown,Unknown]  
<dholbach> Mithrandir: i'm only the guy who set up the team - not really part of it
<Mithrandir> ok
<dholbach> StevenK, crimsun, siretart?
<nukeDev> Hello all
<nukeDev> Hi
<somerville32> Hi
<GNUro> Hi!
<slomo_> are uploads not processed currently?
* LaserJock hugs Mithrandir 
<nyu> hi
<nyu> where can i get the source of the installer?
<nyu> (the one used in dapper)
<tsmithe> https://launchpad.net/ubuntu/+source/ubiquity
<nyu> thanks tsmithe 
<tsmithe> np
<nyu> tsmithe: is there a public svn of that?
<tsmithe> hmm
<tsmithe> may be
<tsmithe> i guess it is probs in bzr, though
<tsmithe> dunno
<tsmithe> ask cjwatson 
<nyu> oh
<nyu> cjwatson: there?
<mpt> nyu, there's also #ubuntu-installer specifically for installer discussion
<nyu> ah ok, thanks
<cjwatson> nyu: https://wiki.ubuntu.com/InstallerDevelopment
<sistpoty> lamont: can you please give back osgcal on i386? thanks ;)
<cjwatson> slomo_: I think I've reprocessed the lost uploads
<lamont> sistpoty: once I figure out how, sure... will advise. :-)
<sistpoty> lamont: ok, thanks :)
<lamont> heh.  done sistpoty 
<sistpoty> thanks
<lamont> I remember being told it was now trivial... and sure 'nuf.....
<lamont> sistpoty: so yeah, poking me is a viable option.  likewise Mithrandir and infinity 
<lamont> and probably at least someone else...
<lamont> hrm... maybe not infinity now... dunno
<sistpoty> lamont: ok, thanks very much for the help and advice :)
* lamont has lost track of some of the current activities of his former coworkers
<cjwatson> yes, infinity
<lamont> cjwatson: thanks - I
<slomo_> cjwatson: thanks... looks good :)
<lamont> 'd forgotten where the split landed.
<cjwatson> anyone in launchpad.net/~launchpad-buildd-admins
<lamont> yeah -doh
<keescook> slomo_: are you around?  Have you considered enabling the "make check" bits in the dbus package?  I kind of like seeing unit tests run during a build.  :)
<pochu> hey, ubugtu is down?
<kent> is there documentation on ubuntu.com about formalia for contact persons for LoCos? that is,  what Ubuntu expects out of them etc,   ?
<mdke> kent: yeah, loads on the wiki
<kent> mdke: ok.  I will look there then.  thanks for the help.
<mdke> kent: start here: https://wiki.ubuntu.com/LoCoTeams
<mdke> kent: any questions -> #ubuntu-locoteams or the equivalent mailing list
<kent> mdke: ok.  we seem to have problems with the leadership/support for the current leadership  in the swedish LoCo.  I was curios of what is expected etc,  I might apply for it if I can combine it with my current work schedule.
<kent> thanks anyway
<pochu> kent > contact jono
<mdke> well, try resolving it first 
<mdke> then if you need help contact jono
<pochu> yep
<mdke> kent: so, specifically - https://wiki.ubuntu.com/LoCoTeamHowto#head-dcd5ebe11aedfba20759fa5e2aa5114d3d8c6499, https://wiki.ubuntu.com/LoCoTeamLeader, and https://wiki.ubuntu.com/LoCoResolvingProblems
<kent> pochu: I think our current leader have contacted him about the problems.  Our contact has resigned. Right now, its hard to really grip what is happening. but we will solve it. We will have a meeting next sunday to elect new leadership. 
<pochu> kent: good luck
<pochu> kent: if you need something, you can joing #ubuntu-locoteams, there you can get help
#ubuntu-devel 2007-01-23
<kent> pochu: we went from a more anarchistic community with meritocrasy (spelling?) to a more formal group with elected people, economy etc.  Personally I think we did that in a wrong way, but even so.. we have a bit of a mess to solve.  but nothings is impossible.  :)
<pochu> kent: yes, we the spanish community also are having some problems
<pochu> but I think we shouldn't talk about this on the -devel channel. Join #ubuntu-locoteams and we speak there
<pochu> ;)
<kent> pochu: ok.
<slomo_> keescook: not useful... the unit tests require a configure flag which enables code that should not be in distribution packages... configure even warned about them last time i checked ;)
<keescook> slomo_: oh!  that's unfortunate.
<keescook> I had assumed it was just a check for building the tests or not.  :(
<slomo_> keescook: yes... but otherwise the test suite seems to be really good ;) 
<keescook> it actually changes the binaries?
<slomo_> just not useful for packages
<slomo_> yes
<keescook> dang
<slomo_> it enables additional asserts and other stuff
<keescook> well, this'll just be another use-case for doing package tests.  :)
<keescook> (and, you can ignore my email...)  :)
<dosnlinux> would this be a good place to ask about why certain scripts do what they do? like why /etc/acpi/lid.sh checks the ac adapter before unthrottling xscreensaver
* #ubuntu-devel  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
<dholbach> good morning
<iwj> http://www.pseudorandom.co.uk/2006/cthubuntu.png
<tsmithe> eh?
<fabbione> iwj: LOL
<tsmithe> :( /me doesn't get it
<Burgundavia> tsmithe: do you know what cthulu is?
<Burgundavia> iwj: http://www.warbard.ca/temp/CthulhubuntuLogo.png
<tsmithe> nope
<Burgundavia> http://en.wikipedia.org/wiki/Cthulhu
<iwj> I think the pseudorandom one is more in the authentic touchy-feely Ubuntu style.
<Keybuk> seb128: tomboy keeps crashing :-(
<Burgundavia> iwj: latter is my brother, bored one evening
<seb128> slomo_: tomboy keeps crashing apparently :p
<seb128> Keybuk: slomo_ maintains it
<Burgundavia> iwj: last line of http://www.linux.com/article.pl?sid=06/12/14/2027244
<seb128> ogra: new gnome-power-manager tarball to package
<ogra> finally !
<seb128> yeah
<ogra> thanks :)
<seb128> grab it while it's hot ;)
<seb128> np
<seb128> ogra: 
<seb128> http://download.gnome.org/sources/gnome-power-manager/2.17/gnome-power-manager-2.17.90.tar.gz
<ogra> heh, already there :)
<seb128> k
<slomo_> Keybuk: that's good ;) works fine for me though.... if you have it as panel applet please run it from a terminal with "tomboy --panel-applet" and then add it to the panel again... and then put everything from the terminal into a bugreport... i'll look at it later today
<Keybuk>  Multiple document element was detected.  Line 12, position 17.
<Keybuk> it keeps saying that
<slomo_> hm
<Keybuk> (plus running that doesn't show it on the panel :p)
<slomo_> did you use the bullet-point feature?
<Keybuk> yes
<Keybuk> quite extensively
<slomo_> Keybuk: ok... upstream told me that there seems to be a bug with this feature that generates broken xml files for the notes sometimes... and nobody could reproduce it :/ there should be instructions on how to fix it by hand on the tomboy mailinglist...
<slomo_> Keybuk: it's at least a known bug that is on top of their todo lists :)
<Keybuk> do you have a link?
<Keybuk> (e.g. to the mailing list!)
<slomo_> Keybuk: http://lists.beatniksoftware.com/pipermail/tomboy-list-beatniksoftware.com/2006-December/000067.html
<Keybuk> slomo_: thanks
<Keybuk> that fixes it
<lifeless> mvo: http://people.ubuntu.com/~robertc/possible-conflicts.txt - look for tuxtype
<mvo> lifeless: ah, nice!
<lifeless> yeah, but its still buggy :(
<mvo> oh? how so?
<lifeless> look for tuxtype :)
* mvo looks
<desrt> pitti; hello
<pitti> hey desrt 
<desrt> pitti; there's a small problem in feisty related to that patch i hacked up
<pitti> desrt: the macbook one?
<desrt> turns out that the feisty kernel (dapper didn't do this) clobbers the backlight register on resume from sleep
<desrt> sets it to all-zeros
<lifeless> BenC: are you benc@u.c ?
<desrt> no idea why -- but it will need to be fixed too
<BenC> lifeless: bcollins@u.c
<desrt> BenC; i don't suppose you've seen any reports of this yet?
<ogra> seb128, g-p-m will be problematic :( the functions we apply the libpam-foreground patch to is just vanished ... no mention in the changelog or something :(
<desrt> [just quickly if you have so i can avoid fighting launchpad for info] 
<seb128> ogra: you know upstream, right? ;)
<ogra> yes, i mailed him and i'm in #hal ...
<seb128> ok, wait to get a reply from him probably then
<ogra> but still, it seems there is no replacement for gpm_manager_is_policy_timout_valid() at all ...
<seb128> that will be easier that way
<seb128> there is a new gnome-screensaver to package if you want ;)
<ogra> heh, yes ... i wanted to update the new default saver as well ... thats good
<lifeless> BenC: thanks
<tfheen> mvo: about ; https://launchpad.net/ubuntu/+source/popularity-contest/+bug/51149 what with the last comment?
<Ubugtu> Malone bug 51149 in popularity-contest "popularity-contest does not work out of the box" [High,In progress]  
<mvo> tfheen: reading it now
<tfheen> mvo: also, as you can see ubuntu-archive isn't subscribed.
<mvo> tfheen: subscribed the ubuntu-archive team. libnfsidmap2 needs the same priority as libnfsidmap1. can you do it? or should I write a bugreport?
<tfheen> mvo: I can just change that
<mvo> tfheen: that would be good, thanks
<mvo> it confuses the upgrade
<tfheen> fixed.
<mvo> thanks!
<dholbach> ogra: new gnome-power-manager and new gnome-screensaver
<mvo> tfheen: it will be in the archive with the next archive update?
<tfheen> mvo: yes.
<ogra> dholbach, see backlog :P 
<dholbach> ok
<fabbione> hmm
* desrt falls over and takes out dholbach on the way down
<fabbione> seb128, dholbach: Package: libgnomevfs2-0 -> Depends: libgamin0 | libfam0
<fabbione> did you two say that we don't use gamin anymore?
<desrt> pitti; vbetool is a workaround to the problem.  vbetool is still broken on macbook, though, due to incorrect sequencing of the startup scripts in rc2.d
<seb128> fabbione: we don't, gam_server should not be running
<desrt> pitti; choose your poison :)
<seb128> fabbione: the problem is inotify doesn't work everywhere
<fabbione> seb128: ok so why do I get the "end from FAM server connection" error from libgamin0 ?
<seb128> fabbione: and when inotify doesn't work it fallbacks to gam_server then
<fabbione> feh
<fabbione> ok
<seb128> because you use NFS where inotiy doesn't work?
<fabbione> i guess i will have to go back hacking idiotify
<pitti> desrt: (sorry, in a meeting, will catch up later)
<desrt> pitti; no prob.  i'll write some more info into the bug
<desrt> cheers
<fabbione> seb128: it did work from breezy and broke only recently
<seb128> fabbione: maybe a new bug in the gnome-vfs gam code, that needs debugging
<fabbione> seb128: yeah somewhere
<tfheen> mvo: hmm, but your upload doesn't disable compression, does it?
<tfheen> hm
<tfheen> it does.
<ogra> seb128, how do the volume control hotkeys work, arent they supposed to use the backend i selected as default for the mixer applet ? 
<seb128> ogra: no, the device selection is to the sound capplet
<seb128> that's not the one from the applet
<ogra> hmm, so i cant change the hotkey backend at all ? 
<ogra> ah, sorry
<ogra> yay, works :)
<ogra> seb128, thaks
<ogra> +n
<seb128> np
<tfheen> crimsun: I'm rejecting your curl upload, it's not been approved by the SRU team.
<cjwatson> mvo: do you know what the comments from Mr Canis on that bug are about?
<cjwatson> mvo: (the popcon bug)
<mvo> cjwatson: yes, I commented about it. I was asking him what the exact error was
<cjwatson> ok, thanks
<cjwatson> let the bug know if it needs to be changed, obviously
<mvo> cjwatson: the feisty version works well so far
<lifeless> keescook: Zak says hi
<lifeless> (your clone)
<tfheen> mvo: why have you uploaded two update-managers with the same version number?
<mvo> tfheen: probably a mistake. both to edgy-proposed? why does the archive not reject them then? are they identical?
<tfheen> mvo: yes, both to -proposed.
* ogra tries to find out if bug 63132 justifies an SRU or if its rather a backport 
<Ubugtu> Malone bug 63132 in fuse "fuse-utils 2.5.3-2.1ubuntu3  installation (edgy) crashes in post installation phase" [Undecided,Fix released]  https://launchpad.net/bugs/63132
<tfheen> ogra: "does not work in edgy" => SRU.  "New version with shiny feature" => backport.
<ogra> tfheen, does not work in edgy if i compiled my own kernel too ? 
<ogra> we dont support monolithic kernels, so i'm a bit ambivalent
<Mithrandir> it's not appropriate for a backport; it's a bug fix, not a shiny, new feature.
<ogra> ok
<Mithrandir> cjwatson: there's a kernel in -proposed; we should just accept it, assuming the version number is sane-ish?
<Mithrandir> mvo: they're the same; I'll reject the newest one.
<mvo> Mithrandir: thanks and sorry
<Mithrandir> mvo: np.  IMO, soyuz shouldn't allow you to upload two entries with the same version to a queue.
* mvo agress with Mithrandir
<pochu> Mithrandir: I don't know if you know this, but the latest updates have broken my wireless
<pochu> Just to notice you about this
<cjwatson> Mithrandir: yes, per https://wiki.ubuntu.com/StableReleaseUpdates
<Mithrandir> pochu: "the lastest updates"?
<pochu> yesterday ones
<pochu> this morning I have boot and it doesn't work
<pochu> I'm with the wire
<cjwatson> at the very least you need to state what release you're running
<Mithrandir> pochu: which distro are you running?
<pochu> Feisty, of course
<pochu> yep, I know it's development
<Mithrandir> well, file a bug, then
<pochu> oh well
<pochu> thanks
<sfllaw> pitti: Ping?
<sfllaw> pitti: Does apport log the architecture?
<pitti> sfllaw: yes, in Uname:
<sfllaw> Ah yes.
<sfllaw> I see now.
<Mithrandir> cjwatson,mvo : we need to discuss an SRU procedure for app-install-data{,-commercial}
<mvo> Mithrandir: yes, if we could do that today, that would be great. only "app-install-data-commercial" is affected
<mvo> cjwatson: ---^
<Mithrandir> mvo: well, if we for some reason would want to update the normal one, the same procedure would probably be followed.
<mvo> right
<cjwatson> Mithrandir: after lunch?
<Mithrandir> cjwatson: sure
<seb128> Mithrandir: https://launchpad.net/ubuntu/+bug/81108 is most likely a duplicate, on what package should I look for the bug? ;)
<Ubugtu> Malone bug 81108 in Ubuntu "machine doesn't restart when pressing enter after cd eject on live session or install" [Undecided,Unconfirmed]  
<Mithrandir> seb128: casper.
<Mithrandir> and it's a dupe, yes.
<seb128> thank you
<jwendell> !info firefox
<gpocentek> Mithrandir: is it possible to get thunar out of new? it has a new binary package (thunar-doc)
<cjwatson> gpocentek: we'll have pitti do that in a moment
<gpocentek> cjwatson: great, thanks, and thanks pitti :)
<erdinc> hi everyone
<erdinc> crimsun you got a sec?
<Hobbsee> erdinc: contentless ping warning
<erdinc> is there anyone who is using vlc?
<Hobbsee> sounds like a #ubuntu type question - please see the /topic
<erdinc> not exactly
<Hobbsee> might help if you actually asked it, too
<erdinc> in ubuntu vlc has a static link to ffmpeg or dynamic?
<Hobbsee> dunno, sorry
<erdinc> I checked redhat fedora and suse all made as static link to ffmpeg
<erdinc> anyway thanx
<erdinc> sorry to disturb
<ogra> erdinc, crimsun is on US time ... might be a bit early for him
<erdinc> :) I saw he is away for 9hours :)
<erdinc> I'll come at night to ask again thank you all
<saispo> how can i debug debian-installer please ?
<cjwatson> saispo: more information please
<cjwatson> saispo: also, #ubuntu-installer
<pitti> gpocentek: I did your sync (my first one, yay :) )
<pitti> gpocentek: erm, s/sync/new/
<gpocentek> pitti: thanks and congrats :)
<saispo> hi cjwatson :)
<jdong> cjwatson: can you do a quick backport for me.... bug 80642.... due to Flash 9 becoming final all flash 9 beta packages will no longer work
<Ubugtu> Malone bug 80642 in edgy-backports "please backport  flashplugin-nonfree_9.0.31" [Undecided,In progress]  https://launchpad.net/bugs/80642
<jdong> (adobe removed the flash9beta tarball from their download servers; installing will result in a wget error)
<Mithrandir> jdong: sounds like an SRU candidate to me.
<cjwatson> Mithrandir: there's already a backport
<Mithrandir> oh, ok
<jdong> Mithrandir: flash7 in edgy/dapper still work
<jdong> (I think)
<cjwatson> jdong: just apper, or edgy too?
<cjwatson> er, dapper
<jdong> cjwatson: both
<cjwatson> only dapper seems to be approved
<Mithrandir> I was about to add that as extra condition.
<jdong> cjwatson: really? I just hit the approval button on both....
<jdong> edgy was approved earlier in the discussion
<cjwatson> there's no approved comment for edgy
<jdong> yeah, first comment, edgy was approved
<cjwatson> oh, duh
<cjwatson> sorry, missed that
<jdong> no problem :)
<cjwatson> I don't know what bug states reliably represent backport approval
<jdong> cjwatson: I use in progress to represent approval
<jdong> of course that doesn't preclude anyone else from hitting the in progress button....
<cjwatson> yeah, that's why I look for comments from a member of ubuntu-backporters
<cjwatson> although I could use the activity log, granted
<cjwatson> jdong: done
<Mithrandir> StevenK,siretart : could either of you look at https://launchpad.net/ubuntu/+source/spampd/+bug/76861 please?
<Ubugtu> Malone bug 76861 in spampd "[SRU]  spampd 2.30" [Undecided,In progress]  
<bddebian> Heya
<GNUro> Hi!
<siretart> Mithrandir: +1
<Mithrandir> siretart: can you note it in the bug log too?
<Mithrandir> siretart: and thanks. :-)
<Mithrandir> hurrah, edgy-proposed down to one entry (which we need to decide on a policy for)
<crimsun> Mithrandir: hmm, I thought https://bugs.launchpad.net/ubuntu/+source/curl/+bug/73447/comments/4 was the approval.
<Ubugtu> Malone bug 73447 in curl "SRU Request to fix Curl Segfault" [Low,Confirmed]  
<Mithrandir> crimsun: I must have been asleep, let me recheck
<Mithrandir> crimsun: accepted
<crimsun> Mithrandir: thank you
<cjwatson> Mithrandir: so where's this archive admin greasemonkey script of yours?
<Mithrandir> cjwatson: http://err.no/src/pasteandmark.user.js and you want to patch greasemonkey with http://err.no/patches/greasemonkey_GM_fromClipboard.diff too
<Mithrandir> alt-shift-[qwertyuio]  to open/close tasks, alt-shift-p to paste clipboard, mark as fix released, assigned to you (in the open task).  Alt-shift-s to submit the form.
<Keybuk> meh; can't get FreeDOS to work :-/
<ogra> why do you want that ?
<_ion> Are you going to replace autoexec.bat with upstart?
<Keybuk> to update my laptop's bios
<_ion> ;-)
<mjg59> Keybuk: How are you trying to get it to work?
<Keybuk> mjg59: usb disk, formatted as a bootable hard disk -- it boots the freedos kernel and hangs
<mjg59> Just dump a freedos image in /boot and then set grub up to boot it using memdisk
<Keybuk> memdisk?
<mjg59> Part of isolinux
<mjg59> Uh, syslinux
<mjg59> You boot memdisk as the kernel, give it a floppy image (1.44 or 2.88) as an initrd, and then it does magic
<Keybuk> does it have to be 1.44 or 2.88 ?
<mjg59> It emulates floppy access, so I doubt bigger will work
<mjg59> But I haven't seen a BIOS update that won't fit on a 1.44MB floppy yet
<Keybuk> I guess I just need command.com and kernel.sys ?
<Keybuk> what does root have to be?
* Keybuk tries it without
<mjg59> And a boot sector oh neve rmind
<ogra> Mithrandir, cjwatson, could one of you approve python-ltsp ? i have some people wanting to contribute that poke me all the time ...
<Mithrandir> ogra: I'm doing -proposed and -updates, I might do source new afterwards.
<ogra> that'd be cool, thanks 
<Keybuk> mjg59: sweet, that worked.  thanks
<mjg59> Winning
<Mithrandir> dapper-proposed emptied out.
<Keybuk> . o O { if only you could flash your bios from vmware }
<mjg59> Hm.
* mjg59 sets his sources.list back to the UK
<mjg59> Keybuk: Some time, we should really provide a package for doing that sort of thing magically
<Keybuk> yea
<Keybuk> I found an evil perl script to turn a file/block device into a "bootable" dos image
<Keybuk> it used nasm
<mjg59> ...
<mjg59> Oh, that makes sense
<Keybuk> dosemu wasn't being helpful, it either complained that I couldn't use a "whole disk image" or would only boot from it
<lifeless> qemu perhaps 
<mjg59> lifeless: Does qemu provide hardware-level access?
<mjg59> Keybuk: I'd be very scared indeed if vmware let you flash your bios
<mjg59> Certain issues of what virtualisation actually means...
<Keybuk> I find it kooky that this laptop has a CPU that provides virtualization features
<lifeless> mjg59: no
<mjg59> lifeless: Not likely to be helpful for bios upgrades, then :)
<lifeless> mjg59: but being a machine emulator should boot rather better I'd expect
<mjg59> dosemu can pass io port access through to the hardware
<mjg59> So there's actually a reasonable chance of it working
<mjg59> Also a reasonable chance of it bricking your hardware
<Keybuk> dosemu didn't work directly because it was in protected mode
<Keybuk> and also wasn't helpful for trying to make a bootable image
<neuralis> mjg59: by the way, have you had reports of strange EC lockups after resume in HP's newish business-series laptops?
<\sh> dear gnome main devs, I have to say, gnome looks awesome in feisty...:) 
<ogra> \sh, where exactly ? 
<\sh> ogra, the control center is quite cool...
<ogra> argh
<ogra> not really imho 
<\sh> I like it, feels like the kde-systemsettings now
<ogra> yes
<ogra> and its slowing you down a lot
<ogra> like KDE
<Riddell> how does it slow you down?
<ogra> Riddell, in the former variant i could just quickly click on the item i needed ... now i have to wait until a window pops up and then i have to search for the item
<ogra> menus are simply faster 
<Riddell> hasn't that been in upstream gnome for ages as default?
<ogra> additionally i have a lot of stuff in the system tools menu (due to edubuntu and ltsp) 
<ogra> so my control center is horribly full
<\sh> Riddell, i never used gnome upstream 
<ogra> Riddell, it was dropped for usability reasons in gnome 2.2 or so ...
<ogra> it was there in the beginning of the 2.x seriaes
<ogra> but after the first usability study they disabled it ... 
<\sh> the only thing which I don't understand is this addressbook panel plugin, and I don't like evolution, because it's too slow when I work with my imap server. tbird is much faster, so is kmail
<Riddell> ogra: I see, thanks
<sfllaw> Mithrandir: Ping?
<sfllaw> Mithrandir: Can you look at bug 59946?
<Ubugtu> Malone bug 59946 in xubuntu-system-tools "Admin tools require admin group membership" [High,Confirmed]  https://launchpad.net/bugs/59946
<sfllaw> Mithrandir: It seems like gnome-nettool hasn't been accepted into edgy-proposed.
<Mithrandir> sfllaw: doesn't seem to have been uploaded.
<sfllaw> pitti: Ping?
<sfllaw> pitti: In #59946 (see above) you seem to have touched lots of packages.
<pitti> sfllaw: right
<sfllaw> pitti: Are gnome-panel, gnome-applets, gnome-netstatus, gnome-nettool, gnome-system-tools, and gnome-nettool the only ones?
<pitti> sfllaw: system-tools-backends too
<sfllaw> pitti: Because it looks like gnome-nettool isn't in edgy-proposed because you didn't upload it.
<sfllaw> Yes, that too.
<pitti> sfllaw: gnome-nettool was broken before already, we could do that separately (seb128 did that patch)
<sfllaw> So I don't have to test that gnome-nettool works correctly?
<sfllaw> And if so, can we have a bug number that will be SRUed?
<sfllaw> pitti: ?
<pitti> sfllaw: yes, and yes
<pitti> seb128: you mentioned that there already was a bug about gnome-nettool?
<Riddell> mvo: able to look at konsole with me for a sec?
<ogra> Riddell, as QT guy, what do you think about replacing scribus in main with scribus-ng ? 
<Riddell> ogra: what's scribus-ng?
<ogra> the 1.3 version afaik
<ogra> the one we have in main is 1.2
<Riddell> right.  I believe it's pretty stable, but I'd want to ask the scribus people if they'd get annoyed if we did that
<ogra> but 1.3 is already nearly a year old ... 
<ogra> ok
<Riddell> unfortunately I've forgotten the password to the top secret scribus developers channel
<Riddell> we could just have both packages in the archives
<ogra> we do already
<ogra> but we shouldnt have both in main
<ogra> i just asked in #scribus
<Riddell> I see
<keescook> lifeless: heh.  tell him "hi" for me too.  :)  I chatted with him briefly at LCA
<\sh> gnomefreak, ping...do you know if #74887 happens in dapper, edgy or feisty? :)
<LaserJock> is there a time where MIRs and promotions to Main stop happening? I'm guessing maybe FF
<somerville32> The MIR I filed weeks ago has yet to be reviewed, lol
<visik7> hi
<gnomefreak> \sh_away: its edgy i havent tested it on feisty since im using ff3.0 on feisty.
<siretart> enrico: around? I'd like to talk to you about python-debian
<enrico> siretart: hi
<enrico> siretart: let's talk
<siretart> sure! :)
<siretart> feisty has bzr 0.14 now, and I'd like to have bzr-buildpackage updated 
<siretart> unfortunately, it depends on python-debian_0.1.1, which is not in debian yet
<siretart> enrico: what are your plans about python-debian in the short term?
<enrico> wow, really?
<enrico> it's in experimental atm
<enrico> just two days ago I posted to the list proposing to upload in unstable
<enrico> no reply so far afaik
<enrico> it's in experimental because it was uploaded during the etch freezish, where the idea was "only upload to unstable what's for etch"
<enrico> siretart: if you can pull it from exerimental into feisty, I'd say you can do it
<siretart> enrico: that's fair enough. feisty is currently not in freeze, and I'd like to have something usable there
<siretart> enrico: the package from experimental is in feisty since some days now, but it seems I need something newer for james' 0.14 branch
<enrico> siretart: oh
<siretart> enrico: I'd really appreciate an upload to unstable. we neededn't request a sync to testing, so etch should be safe for python-debian
<enrico> siretart: I'll post to the list again saying that we have another reason for unstable
<siretart> enrico: does python-debian 0.1.1 include python-deb822?
<enrico> siretart: it should
<siretart> that'd be cool
<siretart> okay, subscribed to both mailing lists
<enrico> siretart: I admit I still haven't figured out what's the purpose: dato had something in mind, but he is now on extended leave
<siretart> enrico: I hope he's doing better now, or in the mean time...
<siretart> enrico: would you please ping me on irc when python-debian hits debian (no matter if unstable or experimental)
<siretart> enrico: I'd like to merge it into feisty
<enrico> siretart: I might not remember in this period
<enrico> siretart: but if you subscribed to the list, you should see it
<siretart> enrico: already done. okay
<enrico> siretart: thanks
<Evaso2> i was starting a discussion on debian about this release method http://wiki.debian.org/LivingSystem
<Evaso2> do u think that could be used also for ubuntu instead of time based release?
<LaserJock> Evaso2: interesting idea, kinda needs more development (the wiki page is a bit confusing). However, I would think it would be harder business users and people offering support
<LaserJock> how would you propose going about radical changes?
<Evaso2> LaserJock... sorry it is only a very rought wiki stub
<LaserJock> sometimes you can just incrementall approach a change
<Evaso2> it was started by me moths ago (i'm not native english) 
<Evaso2> and was modified by StephenKeeling
<Evaso2> on 2006-03-28
<Evaso2> Support is not a problem
<LaserJock> if you have a constantly moving target it would be I should think
<LaserJock> what "daily" snapshot do you support?
<Evaso2> LaserJock the policy will be oriented at a slowly upgrade
<ajmitch> but you haven't said why it's not a problem
<LaserJock> Debian/Ubuntu today could be different than Debian/Ubuntu 3 months from now
<Evaso2> it is so slowly that almos all users could follow "stable" updates
<LaserJock> how do you support that?
<Evaso2> so u support the actual system that all customers must to follow
<LaserJock> so you are relying on people constantly updating to the latest "stable"
<Evaso2> yes it is a kind of advanced concept of backport to security
<LaserJock> so what happens when, for instance, Debian switches from python2.3 to python 2.4
<Evaso2> there could be introduced with the right polices to stable a trasaction system of dependecies like in DBMS
#ubuntu-devel 2007-01-24
<Evaso2> a sort of commit rollout + dependecies etc. 
<Evaso2> when the trasaction is stable in testing and compilant with the policies it will bel applied to the stable "trunk"
<Evaso2> s/bel/be
<LaserJock> seems like it requires a lot of "policing"
<LaserJock> and I'm not seeing a clear advantage to a time-based release
<Evaso2> not a lot of policiing somthing like in the wiki stub are already good
<Evaso2> the trasaction is only a concept for loking packages with dependencies
<Evaso2> you could not upload a new upstream release if the upload broke the trasaction already in testing (for example abi changes)
<LaserJock> it would just seem to me that a constantly moving target would not be as stable, as supportable, nor able to make changes as well
<LaserJock> at least to a "release" level
<LaserJock> for development or "unstable" purposes it seem to make some sense
<LaserJock> basically like what unstable is for the most part
<Evaso2> probably but this work around many problem about backporting upstream bugs
<Evaso2> we need an extra work for backporting upstream bug fixing in stable release
<Evaso2> without a proper "stable" release we could try to itroduce slowly new upstream version in the trasaction
<HrdwrBoB> I don't think people want that
<Evaso2> HrdwrBob: probably :) we could talking also about this
<HrdwrBoB> "I am running Ubuntu X.XX
<HrdwrBoB> is a lot easier than
<HrdwrBoB> "oh I last updated foo and bar, here is my complete system version list"
<Evaso2> mhh... the alterative is I'am running Ubuntu without any X.XX
<LaserJock> Evaso2: your idea is similar to Gentoo it would seem
<LaserJock> Evaso2: but you have no idea what package versions you are running with that
<LaserJock> what if a person doesn't have internet access
<LaserJock> or limited access
<TheMuso> 
<TheMuso> 
<LaserJock> they may still have whatever version was on the "snapshot"
<ajmitch> TheMuso: I agree
<TheMuso> ajmitch: lol
<Evaso2> LaserJock the problem of internet access is relative also at security fix
<TheMuso> speakup decided to screw with sticking keys again after switching to this box using a kvm
<LaserJock> Evaso2: yes it is
<Evaso2> LaserJock : or also at stable upgrade that fix bugs
<LaserJock> sure
<LaserJock> but if you have no internet wouldn't you rather have a tested, stabilized distro then the latest "daily"
<Evaso2> we could simply have a checksum to know if we run the actual sistem
<Evaso2> probably updates could will come 1 time at week 
<Evaso2> so trasaction will be committed to stable one time at week
<Evaso2> when ready
<LaserJock> well, I doubt that Debian or Ubuntu would be good fits for this system
<LaserJock> but perhaps some derivatives might want to try it
<LaserJock> it might have some advantages
<LaserJock> for us I think the time based release also provide timelines for development
<Evaso2> it is an alternative concept about not to compleetly break the upstream flow
<LaserJock> it has both technical and social consequences
<Evaso2> but the time based release will be relative to meet the periodical trasaction clock for prepare the trasaction from the devel system
<Evaso2> the time based release could be fragmentated and not so monolitich
<Evaso2> for example on the next transaction clock in the meeting we coiche to complete and polish the python x.x trasaction
<Evaso2> naturally this transaction must be well tested in the dev system  (no rc or important bug) before could be committed
<Evaso2> this could let also to us to shorting the time we could integrate upstream bugfixing instead to try to backporting it
<Evaso2> LaserJock: There is still a some kind of weekly or monthly or clock time oriented goals
<popey> if I want to report a bug in the gnome doofer that comes up when i press the volume control soft keys on my laptop, what would that be?
<popey> hmm, hotkey-setup?
<jdub> wow, just doing an upgrade and suddenly everything is totally gouging the cpu
<jdub> like, gconftool-2 suching 80% over at least a minute
<jdub> hrm, no, longer
<cjwatson> Evaso2: you're free to start an Ubuntu derivative which works that way and try it out, but I'm pretty confident that Ubuntu isn't going to make that sort of change. Sorry.
<Evaso2> cjwatson: it is only for talking about an issue i doesn't want to create a fork for a derivate only for test an idea
<cjwatson> I'm sorry, but we're not going to do it within Ubuntu
<jdub> Evaso2: i tend to think that method will eventually take over, but it would require an enormous amount of work right now
<Evaso2> jdub: what do u mean for "take over"?
<jdub> Evaso2: it will become the 'normal' way free software is delivered
<Evaso2> jdub: really or are u joking? :)
<cjwatson> it would not be compatible with Canonical's commercial processes without serious (and expensive) reengineering of those processes
<cjwatson> it's much easier to do this sort of thing when you're starting a project
<cjwatson> once the project is up and running, change at that sort of fundamental level is difficult and expensive
<cjwatson> and once people's jobs are depending on success, there's more resistance to untried ideas
<Evaso2> cjwatson: sure i'm also sure that it has too many reengineering 
<Evaso2> cjwatson: i agree with u on this two issues
<jdub> Evaso2: no, i'm not joking; but that's just my take on what the future may bring
<cjwatson> I'm not really convinced that it can supply coherent enough support commitments and user messaging
<Evaso2> jdub: yes my was only a teoric discussion i doesn't think really that ubuntu or debian could really partical try somthing like this
<cjwatson> but this is the wrong forum to go into it in detail
<Evaso2> there are already support problem in ubuntu because it cannot control time freeze release for all the foss apps
<Evaso2> this is issue was already in a Mark post on his blog
<Evaso2> mainly the ubuntu choiche is to sync with gnome time release clock
<cjwatson> "the current system is imperfect" does not imply "any other possible choice is better"
<cjwatson> I was not arguing that the current system was perfect
<cjwatson> but, within the context of Ubuntu, efforts are better spent on minor tweaks than on total scorched-earth release process redesign, at this point
<Evaso2> i think that no one system is perfect and mainly is not perfect forever for an evolving word :)
<cjwatson> by necessity, the latter will essentially produce no useful results except for possibly the founding of a new project to experiment with it
<cjwatson> warty was when we were free to experiment :)
<jdub> within the context of "we release in six months... starting from before X people were even here" ;-)
<Evaso2> i think that probably could be experimented only with a little number of packages to try to test the system
<cjwatson> I'm aware that the current process has its trade-offs; I was there (and argued about them) when it was set up
<cjwatson> (as was jdub)
<cjwatson> but you need to recognise that every process has its trade-offs, and you would simply be exchanging one set of disadvantages for another
<Evaso2> i think that actually the problem is every distro is overloaded on distro vs upstream issue
<cjwatson> pages about release processes need to explicitly acknowledge the disadvantages as well as the advantages, otherwise they're just advocacy
<Evaso2> yes for my stub i see problem with debian (but less with ubuntu)
<Evaso2> for debian a see a problem to try to put in a good state a trasaction that keep too many time
<Evaso2> so begin to missing many upstream releases
<Evaso2> and this problem could be the same with the universe side of ubuntu
<jdub> brr, this cpu hogging business is bizaare
<Evaso2> upstream has its work time but if you are to slow to but dependecies trasaction in a good shape you begin to miss upstream release while you fix package with dependecies (what i call a trasaction ecosystem)
<Evaso2> s/too slow to put
<cyberix> https://bugs.launchpad.net/gnome-panel/+bug/81205
<Ubugtu> Malone bug 81205 in gnome-panel "Clock applet doesn't allow me to choose Monday as the starting day of the week" [Unknown,Unknown]  
<popey> hmm, do only *some* bugs appear here?
<popey> oh, sorry, that's ubunu-bugs isn't i
<mdke> popey: only ones which people call. Such as bug 12345
<Ubugtu> Malone bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]  https://launchpad.net/bugs/12345
<popey>  /ignore popey
<Evaso2> but probably in the future the  new linuxfoundation (osdl + fsg) with the lsb a linux kernell could try to begin to define a universal linux syncro clock to sync all the major linux distro (and problably many little opensource project begin to sync releases to this clock)
<Evaso2> so we will have a sort of universal timeline to sync (the opposit of tha actual FOSS asyncro system)
<Hobbsee> any core dev people around?  i'm looking for a sponsor
<dholbach> good morning
<cjwatson> pitti: you're in ubuntu-archive in LP now too, so you should be a full archive admin; let me know if there's anything you can't do
<Mithrandir> pitti: you want to subscribe to ubuntu-archive@lists.ubuntu.com, probably.
<pitti> cjwatson: just checked, account seems to be ok; thanks
<pitti> Mithrandir: alright
<pitti> ah, thanks for adding me to the team, just appeared
<Keybuk> pitti: what's wrong with this picture? -- http://people.ubuntu.com/~scott/feisty-20070123-7.png
<Mithrandir> Keybuk: your machine seems to be bored for a while while booting.
<Treenaks> Mithrandir: bored with S08loopback even
<Mithrandir> yeah, seems like it can't resolve its own hostname
<Mithrandir> "host" is running for exactly ten seconds.
<Keybuk> Mithrandir: yes
<Keybuk> it's not unusual to have no DNS server when you're only bringing up lo :p
<Keybuk> it's not trying to resolve its hostname, but looking for a local SOA
* Keybuk would argue that needs a "!= lo" in there
<Treenaks> Keybuk: ifrename... ;)
<Keybuk> Treenaks: ?
<Treenaks> Keybuk: isn't it possible to rename the 'lo' device to something else?
<Treenaks> Or will that break other things horribly too?
<Keybuk> I don't think it's possible
<Treenaks> ok, nevermind then
<pitti> Keybuk: yup, there's a bug about it
<pitti> Keybuk: bug 80268
<Ubugtu> Malone bug 80268 in avahi "Avahi daemon should not try to resolve hostnames during bootup" [Undecided,Unconfirmed]  https://launchpad.net/bugs/80268
<Mithrandir> seb128: if you could come over here afterwards and I'll fix up the rest of the bits of the greasemonkey script for you.
<seb128> Mithrandir: now or after the debhelper demo?
<Mithrandir> seb128: whenever you want. :-)
<seb128> ok, after the demo then ;)
<Hobbsee> hey Mithrandir, seb128, and Keybuk 
<seb128> hi Hobbsee
<Mithrandir> morning, Hobbsee
<Hobbsee> ;)
<Mithrandir> Riddell: do you want to add knetwork-manager to your -desktop seed yourself or should I do it?
<pitti> lifeless: look at bug 81237, that's a funny one
<Ubugtu> Malone bug 81237 in apport "Errors from python interpreter give apport crash dialog!" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81237
<pitti> lifeless: (just to amuse you, I'll fix it)
<lifeless> pitti: ah yeah, jamesh and I had a fix for it
<lifeless> pitti: its not trivial to fix. I'll dig up the log about the right way later
<pitti> lifeless: oh, I thought about something like 'InterpreterPath == ExecutablePath -> ignore'
<lifeless> pitti: 'python foo.py' -> foo.py may be packaged
<pitti> lifeless: check the arguments then, too? hmm
<lifeless> there are a couple of variables we can cross check though
<lifeless> its in my irc logs from las year somewhere ;)'
<pitti> lifeless: if I run python in /usr/lib, I get ExecutablePath == /usr/lib
<Keybuk> you don't exclude /usr/local from that?
<Keybuk> I've had that dialog at least once for a python script in /usr/local/bin
<pitti> Keybuk: I do
<pitti> Keybuk: ah, probably not for interpreted scripts
<lifeless> Keybuk: this is about interactive python, but if you get a dialog when you shouldn't, file a bug with some details ;)
<Keybuk> lifeless: bug #81244
<Ubugtu> Malone bug 81244 in apport "Is run for programs in /usr/local" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81244
<pitti> Keybuk: thanks
<cjwatson> dholbach: does <or> work yet?
<dholbach> cjwatson: yes
<cjwatson> hmm
<dholbach> cjwatson: 'not' too
<cjwatson> can't get 79029 to match "no active autopartitioning choice"
<dholbach> do you have the clue file for that somewhere so I can try myself?
<dholbach> cjwatson: ^
<cjwatson> (that would be a false positive as it happens, but still)
<\sh> moins
<cjwatson> dholbach: http://people.ubuntu.com/~cjwatson/tmp/ubiquity.info
<cjwatson> I'd suggest hacking bughelper to limit to just bug 79029 or it'll take forever
<Ubugtu> Malone bug 79029 in ubiquity "Feisty Herd2 - Installer crashed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79029
<\sh> sabdfl, thank you for your mail :) 
<dholbach> cjwatson: i'll give it a special bug list url but thanks for the hint
<Riddell> Mithrandir: it's already in
<Mithrandir> Riddell: coolie
<dholbach> cjwatson: working on it
<dholbach> cjwatson: can you try  http://daniel.holba.ch/temp/possiblefix.patch ?
<cjwatson> trying
<dholbach> cjwatson: does   ./bughelper -A -l http://tinyurl.com/2ykot4   work for you?
<\sh> doko: if you have time, can you look at http://librarian.launchpad.net/5720669/buildlog_ubuntu-feisty-i386.ldaptor_0.0.43-0.4ubuntu2_FAILEDTOBUILD.txt.gz and tell me how can we fix it (e.g. setting it back to python2.4)
<StevenK> I note the command that fails is dia -t png-libart --export=ldap-is-a-tree.dia.png.tmp ldap-is-a-tree.dia
<\sh> oh my god...right..i didn't see the glibc warning...
* \sh needs new glases
<StevenK> There's no bug against it, either.
<fabbione> *** glibc detected *** dia: free(): invalid pointer: 0x09392ea0 ***
<fabbione> fix dia :)
<Treenaks> StevenK: there is a bug against dia for that..
<StevenK> Treenaks: Oh? I must of missed it.
<Treenaks> StevenK: https://bugs.launchpad.net/ubuntu/+source/dia/+bug/79188
<Ubugtu> Malone bug 79188 in dia "Dia hangs while starting" [High,Confirmed]  
<StevenK> Ah, I was looking for bugs mentioning glibc
<Treenaks> StevenK: well, it does mention it.. in the description text
* StevenK nods.
<StevenK> So, which lucky person gets to valgrind dia? :-)
<seb128> fabbione: what about you fixing bugs instead of just pointing them? ;)
<Treenaks> StevenK: seb128 ;)
<StevenK> Actually, doko touched it last. :-)
<seb128> StevenK: the upstream SVN has the required changes, that's a "work with new python" change
<seb128> it's trivial to backport probably
<StevenK> seb128: Point me at the patch, and I'm happy to throw you a debdiff?
<seb128> the problem is that it has been commited to CVS and touch like 15 files, and there is not an unique changeset
<seb128> you need to look at every file change and collect the diffs, which I've been to busy or lazy to do
<seb128> wait
<seb128> http://svn.gnome.org/viewcvs/dia/trunk/plug-ins/python/
<seb128> "	* plug-ins/python/*.c : don't mix PyObject_NEW() with PyMem_DEL()"
<seb128> grab that diff for every file
<seb128> that will probably work
<fabbione> seb128: because it's part of my new job to just point them out :)
<seb128> that's not support request
<seb128> what other new job did you get?
<fabbione> seb128: handing over all my stuff to you ;)
<seb128> I don't think so
<fabbione> seb128: it's fun tho :)
<seb128> I don't doubt of it :p
<StevenK> Come on librarian, send me data slower.
<saispo> hi
<doko> \sh, StevenK: reverting to 2.4 is not an option; better fix the 2.5 bugs
<StevenK> doko: Doing so now
<doko> StevenK: thanks
<StevenK> doko: I shall bug either you or seb128 when I have a debdiff for dia
<seb128> StevenK: attach it to the bug, I'll do the upload
<StevenK> seb128: Aye. I'll poke you here when I've done so
<seb128> cool
<tkamppeter> I have a question about getting new packages from universe to main. I have made the appropriate reports and added the packages to the queue, but when I announce it on ubuntu-devel, I get messages that my postings await moderator approval because I am not a developer. Where should I announce my main inclusion requests?
<kylem> ubuntu-devel-discuss is the open list and probably the best place.
<tkamppeter> Then I think the instructions on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements should be appropriately changed.
<\sh> doko, thx :)
<seb128> mdke: around?
<mdke> seb128: (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)
<seb128> mdke: have your changes for the help menu been approved and need to be applied?
<tkamppeter> Like: 3. #
<tkamppeter> The request and the link to the report are sent to ubuntu-devel@lists.ubuntu.com or ubuntu-devel-discuss@lists.ubuntu.com.
<cjwatson> tkamppeter: I think ubuntu-devel is appropriate.
<cjwatson> although there is an open question of whether it makes sense to post MIRs to a mailing list at all
<lifeless> sfllaw: I have the edit back.ping me when you want this meeting
<tkamppeter> cjwatson, then we should really change the instructions on https://wiki.ubuntu.com/UbuntuMainInclusionRequirements. Which address do you like should I send the announcements of main inlusion requests to?
<cjwatson> tkamppeter: I have updated the process following a brief discussion here
<cjwatson> tkamppeter: you do not need to announce it anywhere; Martin Pitt (the primary reviewer) gets notified via a wiki subscription
<cjwatson> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements fixed
<tkamppeter> cjwatson, thanks.
<pitti> lifeless: seems that sys.argv == ['']  for interactive python sessions even if I run 'python -O -E'
<pitti> lifeless: that's why your binary = os.path.join(cwd,argv[0] ) produces '/usr/local'
<StevenK> seb128: Bug 79188 updated with my debdiff. I have tested that I can reproduce the problem, and also that my fix does indeed fix the problem.
<Ubugtu> Malone bug 79188 in dia "Dia hangs while starting" [High,Confirmed]  https://launchpad.net/bugs/79188
<seb128> StevenK: good, I'll have a look now, thank you
<StevenK> seb128: Great, thanks. And no problem. :-)
<ogra> seb128, StevenK, i'm just trying to get the dia from experimental building ... i'd assume that patch is included
<seb128> right
<seb128> ogra: let me know if it works fine, otherwise I'll upload the patched package
<ogra> yep
<Hobbsee> Mithrandir: or another archive admin, ping?
<ogra> only finishing the tuxtype build ...
<Mithrandir> Hobbsee: humm?
<Hobbsee> Mithrandir: i think there were two uploads of murrine today?   can you make sure the last one gets uploaded please?  :)
* Hobbsee got confused with revu
<Mithrandir>   159376 | S- | murrine              | 0.41-0ubuntu1        | 7 hours 30 minutes
<Mithrandir>   | * murrine/0.41-0ubuntu1 Component: main Section: gnome
<Mithrandir>   159377 | S- | murrine              | 0.41-0ubuntu1        | 7 hours 20 minutes
<Mithrandir>   | * murrine/0.41-0ubuntu1 Component: main Section: gnome
<Mithrandir> so yes, two uploads. :-P
<Mithrandir> I'm merging casper now, I can do it afterwards.
<Hobbsee> Mithrandir: :(  realised after i'd uploaded the first one, went "bugger"
<Hobbsee> cool, thanks :)
<frennkie> Hello, does anybody know how likely it is that there will be a backport of libc6-xen for Dapper Drake LTS (6.06) (see: https://launchpad.net/ubuntu/+source/glibc/+bug/50331/+viewstatus)
<Ubugtu> Malone bug 50331 in glibc "Please backport libc6-xen" [Wishlist,Unconfirmed]  
<frennkie> okay, so what does unconfirmed mean ?
<mneptok> what is the nature of the breakage on Dapper? does it affect security?
<Mithrandir> frennkie: not going to happen.
<frennkie> *cry* why not, do you know?
<Hobbsee> Mithrandir: well, the backporters might decide to smoke their crack pipe, again...
<Mithrandir> Hobbsee: well, I just rejected it and I would be really, really surprised if any other archive admin though it was a good idea.
<Mithrandir> frennkie: because we don't backport core libraries like, glibc.
<Hobbsee> Mithrandir: heh, yes, i know.  i thougth the ubuntu backporters were separate to you guys - jdong's team
<Mithrandir> Hobbsee: they're still subject to ubuntu-archive approval.
<Hobbsee> ah :)
<frennkie> ok, thats a point.. but as dapper, will be around and used for another 4 Years maybe it would be good to have proper xen supoort in it..
<Hobbsee> frennkie: i believe you just got told by one of the 3 archive admins "no" - that's very very unlikely to change...
<Mithrandir> frennkie: sure, that would be nice.  Unfortunately, as long as that means backporting glibc, it's not going to happen.
<frennkie> okay, got it now. thx!
<StevenK> ogra: Any news, re: dia?
<ogra> StevenK, seems 0.96-pre1 is gone ... seb128 will apply your patch
<ogra> (i got it from alioth some weeks ago ... it ftbfs'ed ... seems they didnt get it fixed)
<StevenK> ogra: Great, thanks
<seb128> ogra: you can also grab the new tarball and do the update if you want ;)
<ogra> after lunch then :)
<h4writer> (gnome) can I ask here how come that a list of anything sometimes shows white places? Like the user list in Gaim. Or the list of menus in "menu layout". If I'm not wrong those are created with python: treeview (treestore)
<cjwatson> does anyone here have moderator privileges on the "Installation and Upgrades" forum on ubuntuforums.org? I need a comment marked sticky
<h4writer> But it is annoying and I need to be fixed
<h4writer> *it
<Treenaks> h4writer: this is not a support channel
<Treenaks> h4writer: also, use launchpad.net to file bugs
<h4writer> ok
<h4writer> thanks
<ogra> StevenK, seb128, do we have a bug for the dia segfault ? i just uploaded
<seb128> ogra: uploaded what?
<ogra> dia
<seb128> what version?
<ogra> 0.95.0-4.1ubuntu3
<seb128> grumpf
<ogra> the patched one with StevenK's patch ...
<seb128> I had that ready
<ogra> i told you i'D do it after lunch when you asked
<seb128> ogra: https://launchpad.net/ubuntu/+source/dia/+bug/79188
<Ubugtu> Malone bug 79188 in dia "Dia hangs while starting" [High,Confirmed]  
<ogra> thx
<seb128> np
<Stargazers> Hi. I have a question about Python and Feisty. Is there problems with Feisty locales or something, cause jBrout should add IPTC as UTF-8, but it won't do it on Feisty?
<Stargazers> And always I get errormessage in Feisty, I paste a url of errormessage, moment.
<Stargazers> http://stargazers.kapsi.fi/screenshots/errormessage.jpg <-- This kind. This won't appear on Dapper or Edgy.
<Stargazers> I mean, if I write IPTC-tags with DigiKam 0.9.0 and then look in jBrout, scandinavian chars won't work. And same if I add tags with jBrout and then look them DigiKam, scandinavian chars won't work. But it seems that problem is on jBrout that writes tags without UTF-8, but programmer said that it does. So, is there problem in Python packages in Feisty now?
<alex-weej> grr
<alex-weej> every time i try to install build dependencies
<alex-weej> i just get a message like
<alex-weej> E: Build-dependencies for gossip could not be satisfied.
<alex-weej> i have no idea what's going on, anyone got an idea?
<Hobbsee> alex-weej: not enough info
<Hobbsee> alex-weej: means that one of the build deps is broken
<seb128> alex-weej: that's not an user support chan
<Hobbsee> ie, not installable
<Hobbsee> and it's the wrong channel
<alex-weej> seb128: i'm trying to "develop"
<seb128> alex-weej: still not the right chan, that's not a chan to ask how to build a package
<alex-weej> whatever
<Hobbsee> heh
<cjwatson> mvo: you can close bug 81225
<Ubugtu> Malone bug 81225 in realplayer "realplay requires libc6 2.5" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81225
<erdinc> crimsun got a sec?
<alsaberk> hi erdinc
<ogra> seb128, http://people.ubuntu.com/~ogra/dia/
<erdinc> cliebow use this: http://cekirdek.pardus.org.tr/~ismail/dist/bcm43xx-firmware-3.130.20.0.tar.bz2
<bddebian> Heya
<jdong> are you guys aware that libc6-dev from archive.ubuntu.com main is unfetchable...
<jdong> http://archive.ubuntu.com/ubuntu/pool/main/g/glibc/libc6-dev_2.4-1ubuntu12.2_i386.deb
<jdong> that URL
<jdong> generates 403/forbidden
<elmo> yes, it's deliberate
<jdong> ah
<jdong> recalling an update?
<lifeless> elmo: is it listed in Packages at all ?
<elmo> lifeless: yes
<lifeless> meep. analyzer fall down go boom
<elmo> jdong: yes
<jdong> is this related to the libc6 update not liking libpthread.so.20 thing?
<Mithrandir> yes
<jdong> ah, ok
<jdong> lovely :)
<lifeless> and the toe bone is conneted to the foot bone
<bddebian> hehe
* jdong is done playing 20 questions
<lifeless> jdong: dont you mean .20 questions ?
<jdong> LOL
<jdong> BOO
* Keybuk still hasn't figured out why anyone would have libpthread20 installed
* jdong is equally confused
<Keybuk> or why anyone would have a /usr/lib/libc.so.6 symlink
<Mithrandir> Keybuk: it gets pulled in by gnupg-agent, for instance.
<Mithrandir> hmm, no
<Mithrandir> that's libpth2
<Keybuk> Mithrandir: no, that's libpth20
<jdong> Mithrandir: I can't find anything that rdepends libpthread20....
<jdong> but I have come across 3 users that experienced the update problem
<lifeless> perhaps its installed from $old-version
<jdong> perhaps
<jdong> what is the officially sane workaround for this, BTW
<lifeless> wait
<jdong> mmm :)
* jdong probably committed a taboo with how he helped those 3 people..... :D
<Mithrandir> ogra: I can accept python-ltsp on the condition that you clean up debian/ ; you're shipping effectively empty post- and preinsts (remove them), same goes for README.Debian, your debian/rules file has a configure target, but the package has no configure program, so it's useless.
<ogra> Mithrandir, python-central rewrites the postinst files during build
<ogra> but i'm fine dropping README.Debian and cleaning rules
<ogra> (python-central through dh_pycentral)
<Mithrandir> ogra: yes, it replaces the #DEBHELPER# token.  If you don't have any live code in there yourself, remove the file.
<ogra> does it still create it ? i thought it needs a skeleton ...
<ogra> but if that works i'll remove it
<Keybuk> *confused*
<froud> whose the best person to speak to about packaging of docbook and docbook-xsl?
<jdong> cjwatson: ping; did you find the moderators you were looking for?
<_MMA_> Mithrandir: Have you had a chance to look at the ubuntustudio-meta package again or will someone else be looking at it?
<Mithrandir> _MMA_: it was accepted half an hour ago.
<froud> Over at docbook project we're trying to contact all package maintainers for DocBook. How can I discover who is doing this for Ubuntu?
<_MMA_> Thank you. Ill let my team know. ;)
* MikeSmith waves
<MikeSmith> I do the docbook-xsl builds and releases
<MikeSmith> the upstream ones
<MikeSmith> I'd like to help get the edgy docbook-xsl package more up-to-date/synced up with the Debian one
<ogra> Mithrandir, all fixed, want me to upload the fixed one before you approve ? 
<Mithrandir> ogra: nah, I put it in, but please upload the new one.
<MikeSmith> Debian docbook-xsl is at 1.71.0.dfsg.1-1.1
<ogra> Mithrandir, will do as soon as the accepted mail is here ... thansk a lot
<ogra> *thanks
<MikeSmith> edgy one is at 1.68.1.dfsg.1-0.2
<MikeSmith> which is very very old now
<MikeSmith> 18 months or more old
<froud> MikeSmith: apt-cache show says Adam Di Carlo <aph@debian.org>
<froud> for docbook
<froud> and Mark Johnson <mrj@debian.org> for docbook-xsl
<Mithrandir> MikeSmith: docbook-xsl in feisty is 1.71.0.dfsg.1-1.1
<froud> Mithrandir: yes, but dapper ppl what repository updated ... what to do?
<Mithrandir> froud: nothing?  We're not introducing new upstream versions in released distributions.
<MikeSmith> froud - DocBook stylesheet package is docbook-xsl
<MikeSmith> and I know the Debian packager for it quite well
<MikeSmith> my concern is just about making sure that Ubuntu users have easy access to the latest
<MikeSmith> Mithrandir - thanks
<froud> MikeSmith: seams they must install manual or dist-upgrade :-)
<ogra> Mithrandir, hmm, i had the accepted message from soyuz ... but get a NEW message for the next upload ... seems i had a little race condition here ... sorry
<MikeSmith> froud, Mithrandir - OK. So updated package don't get backported to dapper and edgy?
<Mithrandir> MikeSmith: correct.  That is, they can be requested, but they're not automatically backported.
<Mithrandir> (requested into -backports, not into the normal repo)
<froud> Mithrandir: who does that?
<Mithrandir> froud: https://wiki.ubuntu.com/BackportsHowto
* MikeSmith bookmarks that page
<Keybuk> jdong: ping ping ping ping ping
<jdong> Keybuk: pong pong pong pong pong pong?
<jdong> -1
* ogra shades his ears
<Keybuk> jdong: don't suppose you have a record of when you installed libpthread20 ?
<Keybuk> e.g. in /var/log/dpkg.log* ?
<jdong> Keybuk: I was not affected....
<MikeSmith> Mithrandir - so I guess I should file a bug if I want to request it be backported?
<Keybuk> jdong: oh, bah
<Mithrandir> MikeSmith: correct.
<jdong> Keybuk: some people who were affected came to me :(
<Keybuk> jdong: do you know of them?
<MikeSmith> Mithrandir, froud - big thanks
<jdong> Keybuk: wildtangent on #ubuntuforums (currently not on there; he had this problem yesterday), and a forum search can yield quite some more :)
<Keybuk> jdong: can't find why anyone would have that installed though
<jdong> Keybuk: heh, I'm just as puzzled
<jdong> Keybuk: when the fixed libc6 package is released, will that automatically apply OK for people who already attempted applying the broken update?
<jdong> i.e. will any apt-get -f install coercing be necessary?
<Keybuk> jdong: the fix will automatically apply; assuming users haven't tried to force the issue themselves
<jdong> ok
<popey> who looks after planet.ubuntu.com?
<popey> I have moved my domain but the rss planet doofer is still going to the wrong host for updates
<Spads> popey: Any ubuntu-member can update it
<Spads> popey: see https://wiki.ubuntu.com/PlanetUbuntu
<popey> no, you don't understand
<popey> the entry is correct
<popey> but their box is doing incorrect dns lookup
<popey> caching the old IP
<lifeless> how long  ago did you move host ?
<popey> last week
<popey> its the only thing still hitting my apache logs
<lifeless> what was your TTL before you moved ?
<popey> good question
<popey> i don't know
<Spads> what's the hostname in question?
<Spads> I can take a look
<popey> popey.com
<lifeless> planet runs a new process each time, so any caching is oming from the datacentre NS servers
<popey> it is of course not a big deal, but I want to shut that apache down
<lifeless> popey: what ip should it resolve to ?
<jdong> Keybuk: I've posted a forumwide announcement urging people not to try their own ways of "fixing" the problem; also quoted your post asking for grepping of dpkg.log -- will ping you if any meaningful replies show up :)
<popey> 212.13.198.80
<lifeless> Spads: ^
<Spads> popey: is there another FQDN for the IP in question you could use?
<popey> bishop.popey.com
<Spads> bishop.popey.com has address 212.13.198.80
<Spads> that's on the planet host
<Spads> so if you change it to that it should fix your problem for now
<popey> that wont work
<popey> apache will send that request elsewhere
<Spads> I see.
<popey> different virtual host
<Spads> popey: I've put in a bit of a workaround.  /msg me if you still see hits from the planet system on the wrong host over the next hour
<popey> thanks Spads 
<lifeless> Spads: bind is over enthusiastic ?
<Spads> lifeless: it's a little more complicated than that
<lifeless> Spads: ah well. over a beer sometime perhaps
<seb128> ogra: the upstream build works fine, the debian build call "xmlto -o doc/en/manual html doc/en/dia.xml" though
<seb128> ogra: change doc/en/usage-layers.xml to be valid UTF-8 (quotes around the background word to change) and it builds fine
<ogra> seb128, oh, then its a leftover from the old packaging
<seb128> or drop the xmlto call
<ogra> right ... do we need it at all ? 
<ogra> hmm, well, if i drop it it will be a delta ... i'll rather do the quoting
<seb128> ogra: doesn't look like
<seb128> ok
<seb128> ogra: from the changelog previous version lacked that xml, maybe that's why they built it with the package
<seb128> ogra: the current tarball ships it though
<ogra> ah
<seb128> I would just comment the xmlto calls for the moment
<seb128> we will adapt when syncing with Debian next time
<ogra> yep, already testbuilding
<AnAnt> I got a question about python: why isn't there a /usr/lib/python.so that can be set using /etc/alternatives/ ?
<AnAnt> hello 
<AnAnt> ?
<\sh> Mithrandir, can you give-back again ldaptor? :) thx 
<\sh> StevenK, doko, ldaptor compiles fine now with the StevenKs dia fix :) 
<\sh> StevenK, thx for that :) 
* keescook waves hi
<kylem> morning kees.
<keescook> hiya kylem
<ogra> hey keescook 
<keescook> hiya ogra
<pitti> hey keescook 
* keescook hugs pitti
* pitti hugs keescook back
<jdong> keybuk... argh, come back :)
<jdong> http://ubuntuforums.org/showpost.php?p=2057950&postcount=2
<jdong> ^^ you've got one person whose dpkg.log shows a libpthread20 being installed
<cjwatson> jdong: no, I didn't
<jdong> cjwatson: I've posted a forum-wide announcement regarding not trying workarounds for the libc6 thing
<jdong> hope that suffices
<cjwatson> jdong: yeah, I saw - I think that will suffice, thanks
<jdong> np :)
<cjwatson> jdong: a rebuild is in progress that removes the check
<jdong> good to hear
<cjwatson> jdong: regarding http://ubuntuforums.org/showpost.php?p=2057950&postcount=2, the entire dpkg.log would be useful
<cjwatson> jdong: Keybuk will be travelling for a while now, so I'd better take that over
<lifeless> mdz: cjwatson: http://people.ubuntu.com/~robertc/possible-conflicts/
<jdong> cjwatson: yeah, just told the guy to attach the log to the LP bug report
<cjwatson> jdong: thanks, much appreciated
<jdong> not a problem, glad to help
<mdz> lifeless: greatly improved!
<mdz> lifeless: can we collapse the cases which are identical across architectures into a single line?
<lifeless> mdz: yes, that will happen another day though, as it does not currently buffer - which is needed to detect that
<cjwatson> pitti: I was wondering if it'd be possible for ubiquity to use its own crash handler iff apport won't be around to catch the crash
<cjwatson> pitti: do you think just skipping the crash handler if apport can be imported would do the job?
<seb128> cjwatson: stop reassigning bugs to GNOME packages :p
<cjwatson> seb128: hey, they were yours :-)
<cjwatson> seb128: you can always get revenge by finding unassigned installer bugs
<pitti> cjwatson: either that, or just checking whether apport-gtk package is installed, or /usr/share/apport/apport-gtk exists?
<seb128> looks like indeed :p
<cjwatson> pitti: or maybe apport to be frontend-agnostic
<cjwatson> /usr/share/apport/apport?
<pitti> cjwatson: right, just mentioning that people can uninstall apport-gtk but have apport installed
<pitti> cjwatson: right
<cjwatson> mm
<cjwatson> right, I see your point
<pitti> cjwatson: however, that shouldn't be an issue in the live system
<cjwatson> I guess the gtk frontend can check for apport-gtk and the kde frontend can do similarly when there's a kde frontend
<pitti> cjwatson: I can add Provides: apport-frontend if it helps
<pitti> or that
<cjwatson> I'm happier with checking a file than the dpkg database, as it'll be faster
<pitti> right
<mdz> lifeless: if you fix the '-' delimiter and remove the header ('possible conflict:') I think we can get what we need by post-processing against a whitelist
<cjwatson> plus I prefer to do as little work as possible in an exception handler
<pitti> cjwatson: I think in general, checking for /u/s/a/apport is equivalent to checking for import apport; the latter doesn't check for GUI existance either
<lifeless> sabdfl: this was fun
<cjwatson> mkay, I'll check for /usr/share/apport/apport-gtk I think
<ogra> seb128, g-p-m uploaded
<seb128> cool
<ogra> my pbuilder took nearly 2h to resolve the deps ... something is wrong here
<Mithrandir> \sh_away: given-back
<RememberPOL> ffmpeg in mainstream repo is outtdated causing a lack of support for video is FLV files (audio works, [in VLC] )
<Burgwork> RememberPOL: ffmpeg in which distro?
<RememberPOL> well
<RememberPOL> I'm running Xubuntu 6.10
<RememberPOL> but it uses the mainstream ubntu distro
<RememberPOL> *mainstream ubuntu repo
<RememberPOL> http://slexy.org/paste/1074
<Burgwork> ffmpeg is updated for the upcomign 7.04
<RememberPOL> yes but can't it be put into the existing repo so i don't have to wait three months and upgrade my OS, or compile ffmpeg myself?
<RememberPOL> or maybe i can find a fiesty deb instead of compiling
<RememberPOL> heh
<Burgwork> the issue is that newer ffmpeg breaks api/abi, so you need to recompile a bunch of other things
<Burgwork> that being said, it may be backported
* lamont grumbles at bluetooth
<RememberPOL> abi?
<Burgwork> application binary interface
<LaserJock> I don't think libraries are that likely to be backported
<RememberPOL> so installing a fiesty ffmpeg deb won't really help here?
<Burgwork> not unless you have all of the depends of ffmpeg from feisty as well
<Burgwork> the issue is not Ubuntus. It is that the ffmpeg upstream doesn't understand how ffmpeg is really used
<RememberPOL> so all non-fiesty ubuntu users have to upgrade to fiesty before being able to play flv files.
<RememberPOL> :x
<LaserJock> well, software progresses. Sometimes you have to upgrade to get what you want
<Burgwork> yes
<RememberPOL> k
<lamont> so how come my phone will pair  with my home machine, but not with my laptop?
<Burgwork> I would write the ffmpeg people and complain to them about how they cannot keep api/abi stability
<RememberPOL> i guess i'll just install vlc/flash on my windows vm
<Burgwork> and what it hell is causes end users
<lamont> Burgwork: or at least learn about sonames
<LaserJock> RememberPOL: we would have to also update every package that is built using ffmpeg
<Burgwork> lamont: anything at all, besides "install from cvs"
<lamont> that is, they can change the abi if they must,  but they should version the soname
<lamont> right
* lamont wonders what distro/os they use themselves...
<lamont> certain distros are prone to produce "what's an soname?" type questions from the developers... kinda scary
* lamont finally bludgeons bluetooth into happiness
<RememberPOL> Sweet I solved my issue (of FLV video not playing in Xubuntu 6.10 due to outdated ffmpeg [fixed in fiesty-7.04, not being backported because ffmpeg breaks api/abi] ) by downloading http://download.macromedia.com/pub/flashplayer/updaters/9/flash_player_9_linux_dev.tar.gz then extracting libflashplayer.so and flashplayer.xpt from /flash_player_9_linux_dev/plugin/debugger/install_flash_player_9_linux.tar.gz/install_flash_player_9_linu
#ubuntu-devel 2007-01-25
* Chipzz frowns :)
<Chipzz> chipzz@Reel:~/test$ ldd /usr/bin/gnome-terminal | grep -i xdmcp libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb71a9000)
<Chipzz> where the hell did that come from? :)
<Chipzz> *scratches head*
<mdke> I'm guessing you typed it in
<Chipzz> no :)
<Chipzz> I mean the xdmcp dependency of gnome-terminal
<Chipzz> makes little sense :P
<mdke> there was a new release of gnome-terminal recently, you could have a look in the changelog I guess
<TheMuso> c
<somerville32> b
<bddebian> a
<LaserJock> z
<LaserJock> wrap-around
<adhoc> hi guys
<adhoc> any ideas on the impact of the Bind 9 security announcement by ISC ?
<mjg59> bhale: Do any of the beagle preferences work yet?
<mjg59> I'm trying to get beagle to skip indexing my kernel source directory (for fairly obvious reasons), but it doesn't seem enthusiastic
* Solarion upgrades t ofeisty herd 2
<Solarion> heya mjg
<Solarion> mjg59: I had thought they were
* mjg59 watches beagle enthusiastically index all the new .kos
<Solarion> weird
<Solarion> maybe it takes a bit to take effect?
<Solarion> are there any particular pointers to heed when making an ubuntu vmware image?
<Solarion> notably, for the player
<Solarion> anyone know why ubuntu-dekstop would be held back upgrading to feisty herd 2?
<Solarion> it also seems to want to remove 21 packages.
<jdong> mjg59, I feel your pain... I've had beagle digress a bit too far doing its indexing before, too :D
* netjoined: irc.freenode.net -> anthony.freenode.net
<keescook> adhoc: which bind announcement?
<torkel_> keescook: probably http://marc.theaimsgroup.com/?l=bind-announce&m=116968519321296&w=2
<keescook> torkel: ah, thanks.  funny, they haven't listed it here yet: http://www.isc.org/index.pl?/sw/bind/bind-security.php
<keescook> hiya cjwatson
<Mithrandir> cjwatson,mvo,pitti: could we have a discussion about how we want to do SRUs for app-data-commercial?
<mvo> Mithrandir: please, if possible now, it shouldn't take long
<mvo> (hopefully :)
<lifeless> http://people.ubuntu.com/~robertc/possible-conflicts/
<Mithrandir> mvo: sure, whenever is fine for me.
<ajmitch> lifeless: that looks useful
<lifeless> ajmitch: excellent.
<pitti> Mithrandir, cjwatson, mvo: fine for me, now or in the next hours
<ajmitch> file per package might be a bit easier to read, though
<dholbach> good morning
<lifeless> ajmitch: not as easy to post process through I think
<ajmitch> hey daniel
<\sh> moins
<lifeless> BenC: http://people.ubuntu.com/~robertc/possible-conflicts/
<BenC> lifeless: thanks
<lifeless> ajmitch: let me know about changes you would like. Doing per package files is possible I guess, but needs some consideration i think
<lifeless> ajmitch: a new version of the content arrives ~ 25 past the hour
<Slant_Laptop> I'm investigating 49221. My theory at the moment is it is caused by the system clock shifting forward during the fadeout.
<ogra> Robot101, hey, thanks for the pulse hint ... :)
<Robot101> ogra: aha, np. :)
<Robot101> ogra: why is the asound pulse thing missing?
<Robot101> it's the last piece of the jigsaw puzzle
<Slant_Laptop> Yup.
<Slant_Laptop> That's confirmed.
<ogra> Robot101, no idea, i only synced pulse from debian and disabled all jack related things so we could get it to main 
<ogra> so it will be missing in debian as well ...
<mneptok> heya mako 
<bhale> mjg59: the only notable thing that didnt work was "start search and indexing automatically", because it was a suseism. it works now with fdo autostart
<mjg59> bhale: Hm. I added an exclusion, but nothing seemed to happen.
<mjg59> Does it need a daemon restart?
<bhale> mjg59: hm, ive added some mail folder exclusions recently and they seem to be working
<mjg59> Hm.
<bhale> unsure on restarting
<mjg59> Hm.
<mjg59> Now I can't get it to notice stuff I put in there...
<bhale> ah
<mjg59> So it seems to be working ok now
<bhale> rock. see if it removes the index of stuff in there, mail seemed to
<bhale> whihc means i get relevant emails up front when searching, instead of all my spam
<mjg59> Yeah, seems to have done
<mjg59> If I copy a file out of the excluded directory, it shows up
<mjg59> Remove the copy and it vanishes again
<mjg59> So that seems good
<bhale> cool.
<bhale> the next release looks to have a lot of QoS stuff
<mjg59> I think it doesn't help that something in 2.6.20 is killing ata throughput
<mjg59> I'm only getting 10MB/sec off disk
<bhale> ugh..
<mjg59> Can you try doing a hdparm -t and see what you get?
<bhale> sure
<mjg59> I'm interested in finding out how general this is
<bhale>  Timing buffered disk reads:  126 MB in  3.02 seconds =  41.66 MB/sec
<bhale> i would guess this is normal, possibly a bit low/
<bhale> 7200rpm sata
<mjg59> What chipset?
<bhale> intel ...
<mjg59> Hm
<mjg59> I'm only getting 20MB/sec off my Intel sata system
<mjg59> Let me try bumping the kernel
<bhale> 00:1f.2 IDE interface: Intel Corporation 82801GBM/GHM (ICH7 Family) Serial ATA Storage Controller IDE (rev 01)
<mjg59> Kernel version?
<bhale> 20-5
<bhale> generic
* mjg59 upgrades
<bhale> its morning here, I have to run to work
<bhale> good luck with that
<mjg59> bhale: Hm, faster again on -5
<mjg59>  Timing buffered disk reads:  212 MB in  3.00 seconds =  70.55 MB/sec
<tepsipakki> mjg59: hi, does usplash support svg-themes?
<mjg59> No
<tepsipakki> ok
<tepsipakki> it was reported in August to suppot that :)
<tepsipakki> +r
<mjg59> Really? By whom?
<tepsipakki> UWN
<tepsipakki> let me check
<tepsipakki> https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue8
<mjg59> Oh
<mjg59> SVGA images
<mjg59> Not SVG ones
<tepsipakki> hah
<mjg59> Someone's got the wrong idea
<tepsipakki> there are bugs about getting more resolutions supported, but the artwork-team would like to have a single svg-theme to support them all
<tepsipakki> anyway that's how I understood it
<tepsipakki> my "30 HP accepts only plain vga or the max 2560x1600
<tepsipakki> not that I'm rebooting this a lot ;)
<mjg59> Well, usplash won't usefully do anything outside the standard vesa ranges
<tkamppeter> doko, ping
<pitti> BenC: for some reason your magic command to only build the powerpc flavour is not in my bash_history any more; could you please tell me again?
<BenC> CONCURRENCY_LEVEL=4 fakeroot debian/rules binary-debs flavours=powerpc
<seb128> ogra: ping
<sfllaw> mvo: Ping?
<sfllaw> mvo: There's an apt-listchanges bug that I'd like you to look at...
<mvo> hello sfllaw
<sfllaw> mvo: Want to come over and look?
<sfllaw> apt-listchanges claims:
<sfllaw> The gtk frontend needs a working python-gtk2 and python-glade2.
<sfllaw> Those imports can not be found. Falling back to pager.
<sfllaw> And it's because
<sfllaw> > /usr/share/apt-listchanges/apt_listchanges.py(122)make_frontend()
<sfllaw> -> gtk = __import__("AptListChangesGtk")
<sfllaw> (Pdb) n
<sfllaw> ImportError: 'Bad magic number in /usr/lib/site-python/AptListChangesGtk.pyc'
<sfllaw> Is there any more information you need in a bug report?
<mvo> sfllaw: that is feisty?
<sfllaw> Yes.
<mvo> sfllaw: I have a look, thanks. how is the sugarcrm verification going?
<sfllaw> Downloading to verify.
<mvo> great, thanks
<mvo> sfllaw: what date does this file has?
<sfllaw> 10-20-2006
<sfllaw> mvo: ^^^
<sfllaw> jono: mdz wanted me to mention UbuCon to you, which is in three weeks in New York.
<jono> sfllaw: right, I had a mail about it which I need to get to
<jono> sfllaw: did he just want to make me aware of it or something else?
<sfllaw> jono: Make you aware of it, in case you wanted to go.
<sfllaw> jono: Both mdz and I will have trouble attending.
<sfllaw> jono: I have to apologize to John, as I had offered to give a talk that I cannot now present.
<jono> sfllaw: will see what I can do, might be able to fit it in, but I am travelling a bit over the next few months
<jono> if I can make it, will get there :)
<sfllaw> jono: Thanks.
<jono> np :)
<sfllaw> jono: Sorry for the short notice.
<jono> no worries :)
<bddebian> Heya
<sladen> sfllaw: that clashes with SkyCon in Ireland---which I think Jono might already be at?
<jono> sladen: bugger, I thought the dates sounded funny
<\sh> hmmm..since this morning, there is no sound coming from my headphones or speakers..(ibm TP T43)...all alsamixer configs are correct...anyone getting this problem too?
<\sh> neither gnome, kde or xfce...
<bddebian> What has happened to gnome-vfs-mime.h??
<lifeless> BenC: https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/80958 <- that sdhci crash
<Ubugtu> Malone bug 80958 in linux-source-2.6.20 "sdhci error report in syslog" [Undecided,Unconfirmed]  
<BenC> lifeless: interesting...maybe a BIOS update would hep too?
<lifeless> BenC: brand new motherboard as of 2 weeks ago
<lifeless> BenC: I'm 95% sure its at the latest rev already
<BenC> lifeless: It's still possible that there may be an update
<lifeless> if there is, HTF do I apply it ?
<BenC> lifeless: My Intel machine was able to do it from a downloadable ISO
<\sh> uh...now it's playing sound only from the port replicator jacks 
<lifeless> mdz: I plan to do a launchpad update this afternoon, is that ok ?
<jdong> lifeless, many BIOS manufacturers are nice enough to give ISO formatted update downloads... else they'd give you boot floppies
<lifeless> jdong: no floppy drive
<jdong> lifeless, in the latter case, burn them into a bootable ISO :)
<jdong> bootable ISO =  virtual floppy drive
<mdz> lifeless: this afternoon UTC, meaning in the next couple of hours?
<lifeless> mdz: yes
<sladen> \sh: file bug, hassle mjg59 has he has a handle on most of the sound jack issues
<lifeless> mdz: should not affect soyuz
<mdz> lifeless: expected length of the outage?
<lifeless> mdz: 10 minutes or less
<mdz> lifeless: ok, please notify ubuntu-devel
<\sh> sladen, well, funny thing, yesterday, same kernel, the laptop jacks were working...since this morning after the updates, the default behaviour is just gone.. 
<sladen> \sh: report it quickly so that whoever made the change can put 2+2 together
<lifeless> mdz: done
<sladen> cjwatson: is your wiki documentation for hacking the installer up somewhere, I haven't found it with a casual google
<lifeless> wiki.ubuntu.com/InstallerDevelopment/TODO IIRC
<fabbione> iwj: http://people.ubuntu.com/~fabbione/lvm_get_md_right.diff
<gnomefreak> who is our ff developer atm? i know we are working on hiring one but do we have one in meantime?
<iwj> gnomefreak: No, we don't really have one in the meantime.  There's the mozillateam list which has some keen people on it.
<gnomefreak> iwj: yeah me
<gnomefreak> lol
<iwj> Sorry, I get confused by irc nicks :-).
<gnomefreak> local news feeds and help are only in english. im assuming thats us
<iwj> I think so, yes.
<gnomefreak> since upstream packages are correct
<gnomefreak> ok i will see if anyone on the team knows how to work this one out
<iwj> We should probably move some of that customisation to our locale package stuff.
<gnomefreak> is ther ea general local package i can add to bug?
<jdong> can an archive admin clear backports binary NEW please?
* Starting logfile irclogs/ubuntu-devel.log
<AnAnt_> I got a problem with pbuilder, I have set COMPONENTS="main restricted universe multiverse" in /etc/pbuilderrc
<AnAnt_> yet, when I run pbuilder it cannot find packages that are in universe !
<krang> Hey all, I'm not sure if this is a bug, but if I edit /etc/network/interfaces to set a static IP for my one NIC, then save and restart networking, I see that UDP port 68 is still open with dhclient3 listening on it. Should that be happening?
<Mithrandir> how are you restarting the networking?
<krang> /etc/init.d/networking restart
<Mithrandir> that doesn't touch the interfaces, use ifup/ifdown
<keescook> goood morning
<ogra> evening
<ogra> :)
<kylem> vietnaaaaaam
<krang> Mithrandir: are you sure it doesn't touch the interfaces? My IP had changed to the static one I set at the end of it
<Mithrandir> krang: it shouldn't no.
<krang> Mithrandir: er, maybe that's a bug then, because it definitely did
<krang> Mithrandir: yeah, I just looked at the script for that, it's nothing *but* if-up and if-downs. Which, on reflection, would explain why dhclient was still there afterwards
<_MMA_> Hello guys.
<_MMA_> I have been asked by hopeful Ubuntu Studio users if it would be possible to use a different limits.conf when we install "linux-lowlatency"?
<_MMA_> Look at the section marked "Real-Time Support" for reference to what I mean: https://help.ubuntu.com/community/UbuntuStudioPreparation
<_MMA_> Is there a good way to go about this?
<lifeless> _MMA_: have a package that configures that. It should not be tied to the kernel IMO
<lifeless> ok, lp is going down for a short period now, 10 minutes at most
<jdong> ^^ famous last words
<lifeless> done
<lifeless> jdong: pfft
<jdong> lol
<czr> are there any ia64-people around?
<czr> failed to install 6.06.1 on an rx2600, just have some questions about the state of the port
<DogWater> Hi, does anyone know of a plausable work around for [Bug 79562] 
<Ubugtu> Malone bug 79562 in Ubuntu "Edgy netboot/mini doesn't pick up kernel security fix" [Undecided,Unconfirmed]  https://launchpad.net/bugs/79562
<torrr> torrr	I want to choose a distro for "TerminalServer" with linux,I am wondering if ubuntu-desktop would be a good choice
<torrr> 09:32	torrr	I am know how to make Gentoo be a terminalServer, since I tested it in VMWare, I've just been told by CrossOver Office, that they support ubuntu better
<torrr> 	torrr	and I have been told that Gentoo is good for servers, and now I wonder if ubuntu-desktop would perform well in a multi-user environment, compared to other distro's
<LaserJock> torrr: this is not the right channel
<LaserJock> torrr: continue the discussion in #edubuntu or ask #ubuntu
<Adri2000> can I ask an archive admin to 'give back' a package which FTBFSed on one (or two) arch or have I to upload a new version for rebuild?
<geser> Adri2000: which one?
<Adri2000> geser: mplayerplug-in
<Adri2000> geser: amd64 FTBFS should be fixed now
<keescook> lamont: do you have any test cases for testing bind backports?  I've started doing some backports, but I'd like to have a way to test.  :)
<geser> Adri2000: then ask Mithrandir or lamont for a give-back
<lamont> keescook: generally speaking I (1) package upstream bits, and (2) install it on my nameserver for a bit
<Adri2000> lamont: :)
<keescook> lamont: heh.  do you use dnssec?
<lamont> Adri2000: whcih package?
<lamont> keescook: what's that? :-)
<Adri2000> mplayerplug-in, amd64 please
<lamont> keescook: I'd love  a patch for sarge... :-)
<keescook> lamont: yeah, saw that; thought I'd talk about it here since I'm currently doing the Ubuntu changes so far.  :)
<keescook> sarge is 9.2.x...
<lamont> ah, right.. you are in that channel.  cool
<lamont> yeah
<lamont> my personal pref for sarge would be to package 9.2.8 and be happy.  that won't fly with some though
<keescook> hehe
<keescook> even the 9.3.3 backport worries me.  9.3.3 seems to be missing a bunch of UNLOCK calls.... 
<keescook> er, sorry, 9.3.2
<lamont> right
<keescook> I want to test the code paths... but the advisory barely tells me what was causing the problems.  bleh
<lamont> my usual argument runs something along the lines of "ISC does a good job of not introducing new instability into a fix-release.  There is no way that I can duplicate the level of testing and auditing that the community provides for their releases.  kthxbye"
* lamont has cvs
<lamont> keescook: sometimes that argument wins
<keescook> lamont: I'm not sure I can convince pitti.  :)
<keescook> do you have any insight into actual proofs-of-concept for the issues they mention?
<lamont> vendorsec might have something - haven't looked.  more likely it's just going to be what's in the changelog and the source.
<lamont> I can possibly scare up a cvs diff for you if you think that'll help
<keescook> vsec has nothing (though we've asked ISC -- no response).  source has no details either.  :P
<keescook> the diff is pretty clear.  but I'm not (yet) familiar with bind9 guts, so I'm not sure how to hit the code from the outside
<keescook> I guess I'll just keep testing and hope ISC gets back to vsec.  :)
<lamont> keescook: any CVE assigned to this yet?
<keescook> lamont: yeah, CVE-2007-0493 CVE-2007-0494
<lamont> keescook: both CVE for all of the diff releases?
<keescook> lamont: yeah, looks like it.  both 9.2.8 and 9.3.4 seem to be entirely security updates for the same two issues.
* lamont does the first build of 9.3.4-1 to find out what lib filename changes there are
<keescook> yeah, I noticed they bumped the lib/dns/api ... 
<lamont> hrm... ENOPITTI - he's harder to convince when he's not here...
<lamont> yeah - abi bumps are normal for them
<LaserJock> heh, that's the funniest error I've seen lately
<keescook> lamont: I assume the bump is real due to the addition of that reference counter, but it wasn't clear to me if that was an _external_ ABI or not...
<lamont> they seem to be good about abi major and minor numbers
<lamont> wow.  no  filename  changes in 9.3.4
<lamont> keescook: lately I've taken to running 9.4.0 release candidates, with an eye towards actually configuring dnssec
<keescook> lamont: yeah, what do you make of the abi changes as far as backporting goes?
<lamont> now you see part of why I don't bother with backporting :-)
<lamont> or rather, strive to  avoid it
<keescook> :)
<lamont> _IFF_ I was backporting, and there was an abi bump between 9.2.x and 9.3.0, then I'd be tempted to make a similar change to the abi for the 9.2.x, esp if I could land it between 9.2.4 and 9.2.8's name
<lamont> the good part is that they tend to leave some room when they bump abi numbers
<lamont> e.g., 22 -> 32
<lamont> (9.3 -> 9.4)
<keescook> yeah, this has wandered into territory I'm less familiar with.  I haven't done a lot of abi changes.
<lamont> keescook: what all versions do you need for ubuntu?
* lamont is too lazy to go look
<keescook> 9.3.1,2,3
* lamont considers where to vomit
<keescook> yeah
* lamont begins his quest by looking at the differences between 9.3.1 and 9.3.2 to justfiy just rolling them all to 9.3.4
* lamont uploads 9.3.4-1 and 9.4.0~rc2-1
<lamont> now to ponder 9.2 and 9.3.1->9.3.4
<lamont> from the in 9.3.3 but not 9.3.1 category:
<lamont> +2066.  [security]       Handle SIG queries gracefully. [RT #16300] 
<lamont> +1997.  [bug]            Named was failing to replace negative cache entries
<lamont> +                       when a positive one for the type was learnt.
<lamont> +                       [RT #15818] 
<lamont> +1951.  [security]       Drop queries from particular well known ports.
<lamont> +                       Don't return FORMERR to queries from particular
<lamont> +                       well known ports.  [RT #15636] 
<lamont> none of that was  in 9.3.2
<keescook> has it all been bug fixes and security then?
<keescook> sounds like a reasonable full-upgrade.  :)
<lamont> there are some port fixes for OS's that we don't care about
<lamont> new RR type assignments
<lamont> all kinds of robustness cleanup, etc.
<lamont> on the downside, 9.3.1->9.3.2 and 9.3.2->9.3.3 have soname changes
<lamont> brightly, 9.3.3->9.3.4 doesn't
<keescook> right.  that's the part I'm not sure how to handle.  or rather, I haven't dealt with before
<Adri2000> lamont: can you give back mplayerplug-in on amd64 please? https://launchpad.net/+builds/+build/293970
<lamont> that package name is just plain wrong,  fwiw
<lamont> given back
<lamont> on GP, /me gives back ia64 as well
<Adri2000> lamont: likely to FTBFS again on ia64
<Adri2000> because xulrunner:  feisty ia64   Failed to build
<lamont> yeah
<lamont> keescook: fwiw, upstream has a regression suite for bind9 that they run on each release.  I haven't seen it, fwtw
<lamont> kidfetching time
<keescook> lamont: ah, too bad they don't share that test suite...
<Seveas> keescook, ping
<keescook> Seveas: hiya.  just about to head to lunch, what's up?
<Seveas> check the new & improved usn feed please
<keescook> Seveas: sweetness!  Looks great.  :)  Thanks!
<Seveas> yw
<jdong> argh, the dreaded cannot mount /dev/foo on /root: no such file or device
#ubuntu-devel 2007-01-26
* jdong is 5 minutes from totally giving up on wifeinpeices.jd.lan.....
<jdong> any pointers why initramfs would say /dev/sdb1 doesn't exist, but I go to do it manually, and it does magically exist?
* jdong goes hunting in initramfs-tools
<keescook> jdong: race with the kernel.
<keescook> one sec, let me find the bug
<jdong> keescook: actually, no, I think I found it :)
<keescook> oh?
<jdong> keescook: initramfs's fstype is blissfully unaware of reiser4
<keescook> aaah
<keescook> different problem.  :)
<jdong> lol
* jdong goes in and hacks out fstype :D
<jdong__> PWNED :)
<jdong> Linux wifenpieces 2.6.19-beyond2 #1 SMP Thu Jan 25 14:42:08 EST 2007 i686 GNU/Linux
<keescook> is publication on hold?
<gnomefreak> keescook: publication? as in uploads?
<keescook> gnomefreak: yeah.
<lamont> keescook: yeah... maybe I'll see if I can get it from them wearing my day-job hat
<gnomefreak> keescook: i believ ethey are in sprint this week
<keescook> gnomefreak: right, but does that mean freeze?  uploads were working earlier this week.  :)
<gnomefreak> so it will slow down and pick up torwards end of sprint. iirc that is what happened with edgy
<gnomefreak> keescook: no freeze that i know of
<keescook> okay, just thought I'd double check
<gnomefreak> if it is its not listed on the release schedule
<bhale> keescook: my upload didnt show up either
<keescook> bhale: publication from LP to the archives must be down for some reason
<ajmitch> how annoying
<ajmitch> launchpad guys know about it yet?
<bhale> oh
<bhale> my upload wasnt even accepted
<keescook> ajmitch: I've poked them, yeah
<lamont> keescook: do you care about bind 9.2.4?
<keescook> lamont: I don't, no.  thanks, though
<lamont> keescook: what?!?! no warty patch???  slacker!
<lamont> :-)
<bhale> haha
<keescook> Oct 31 2006 was a good day for me.  :)
<lamont> keescook: btw, I have issues with the ubuntu patch in bind9....
<lamont> 9.4 sets the defaults for allow-recursion and allow-cache-query to localhost and localnets respectively...  that's not what the ubuntu patch does...
<keescook> lamont: ah, yeah, had wanted to talk to you about that.  what're your thoughts?
<lamont> I added a NEWS file in 9.4.0~rc2-1 (rc1-3???) about the change, and called it soup.
<lamont> I have no plans to change the default for 9.3
<lamont> setting it to allow amplifier attacks via any machine on the cable service provider's local net of 2000+ homes doesn't strike me as really solving the issue at all...
<lamont> this also let me avoid changing the conffile at all... :-)
<keescook> I figured that was a corner case since many people have a NAT device between them and the cable.  And those that don't are usually running pretty customized named's.
<bddebian> lamont or keescook: You wouldn't happen to know what happened to gnome-vfs-mime.h would you?
<lamont> and in 9.3, allow-recursion really just determines your response to something not in the cache - you'll still cough up whatever's in the cache.
<lamont> bddebian: sounds like a gnome question... :)
<ajmitch> bddebian: what do you mean? it still seems to be there
<keescook> lamont: ah, so really it should have included allow-cache-query { localnets; }; as well?
<bddebian> ajmitch: In gnomevfs2-dev?
<lamont> keescook: and allow-recursion {localhost}
<lamont> if you're going to lock it down until the admin configures it to what he wants, lock it down... don't go half way
<ajmitch> libgnomevfs2-dev: /usr/include/gnome-vfs-2.0/libgnomevfs/gnome-vfs-mime.h
<lamont> keescook: matching the 9.4 default would have been a good thing, you see.... :-)
<keescook> lamont: I didn't want to limit it to localhost for fear of breaking people that were using named in a default config on a local business network.
<bddebian> ajmitch: That's on feisty?
<ajmitch> bddebian: of course
<lamont> in a local business network, localnets tends to break me just as badly as localhost, for most companies
<bddebian> wtf
<keescook> then when they got an update, it would blow up their DNS
<ajmitch> updated only a few minutes ago
<keescook> for big companies, yeah
<lamont> _NONE_ of the company nameservers in HP are on the same subnets as _ANY_ desktop or non-dns server.
<keescook> again, I figured a larger company would have a customized named.conf
<keescook> right
<keescook> my concern was with people that installed named, but didn't change the named.conf
<lamont> and, with the conffile change, the upgrade gui silently screams to a halt until you open the terminal and discover that it's asking you a question...
<lamont> HP also specifically has _NO_ recursion restrictions on its nameservers
<lamont> administratively prohibitive
<keescook> I wanted to limit the impact as much as possible.  For me personally, I totally agree with the 9.4 defaults and will happily defend them for ubuntu too.  :)
<lamont> of course, HP also has >1% of the total core-routable unicast IPv4 address space...
<lamont> our bad
<lamont> the next acquisitions are: Apple, MIT, and Ford Motor.  then we can advertise 16/6. :-)
<keescook> eek
<lamont> well, I doubt they'll do that...
<keescook> no way to change the external recursion issues, eh?
<lamont> I objected to the compaq merger on the basis that 15/8 and 16/8 do not aggregate.
<keescook> heh
<lamont> too many networks to list, and new business partners that use HP for recursion on a frequent basis.  maintaining the list is beyond the scope of sensibility
<lamont> and besides, I _use_ those nameservers sometimes. :-)
<keescook> yeah.  would be interesting to see a "no new DNS servers can have recursion" or something like
<lamont> the authorititative servers do not allow recursion
<lamont> the non-authoritative servers exist to serve.
* keescook nods
<bddebian> Gah, duhhhh: error: gnome-vfs-module-2.0/libgnomevfs/gnome-vfs-mime.h
<lamont> when I was in charge of DNS at HP, my assertion was that when we saw the network/cpu load due to, uh, unauthorized queries for NTP and/or DNS, then and only then would we consider blocking the miscreants.
* keescook nods
<lamont> my replacement was there for the discussion, and concurs.. now it's just a question of how long we can hold back the masses...
<keescook> heh
<lamont> OTOH, certain parts of the company were managing zone delegation by configuring forwarders on every &*%&*)%_ nameserver instead of adding the SOA RR.. sigh
<lamont> that, uh, changed.
<keescook> owchy.  :)
<lamont> 'twas an education exercise....
<lamont> hrm.. just need alpha, m6k and powerpc to finish building 9.3.4-1 for debian (and several to upload their built bits)...
<lamont> keescook: feel free to point pitti at me and I'll defend why 9.3.4 is a good plan for breezy and forward...
<lamont> dunno that he'll buy it, of course.
<keescook> how does the abi change work, since that's an issue for earlier release regardless?
<bddebian> ajmitch: That did it, thanks.. I'm such a dork :-(
* jdong sets pounce on Keybuk to beg for readahead-list gnome prefetching :D
<grndslm> would it be fairly easy to integrate the insight debugger into gedit somehow or at least integrate gdb and insight's design/commands??
<TheMuso> c
<dholbach> good morning
<_ion> adequate morning
<fabbione> morning
<joejaxx> its 3am here
<joejaxx> everyone in the us is sleep lol
<ogra> seb128, http://bugzilla.gnome.org/show_bug.cgi?id=400662 :-D
<Ubugtu> Gnome bug 400662 in gnome-power-manager "please add ubuntu patch to upstream source" [Enhancement,Resolved: fixed]  
<ogra> that was the last patch apart from LTSP :)
<seb128> ogra: nice, and did you forward the crasher?
<ogra> yep
<ogra> seb128, http://bugzilla.gnome.org/show_bug.cgi?id=400654 ... ours is linked to it
<Ubugtu> Gnome bug 400654 in general "segfault on ppc architecture since upgrade to 2.17.90" [Critical,Unconfirmed]  
<Riddell> Mithrandir: can you give back kdeutils and kdeartwork please?
<Mithrandir> Riddell: given-back
<pitti> cjwatson: I reviewed the xubuntu-system-tools diff for bug 59946, I'd like to approve the -proposed upload; is that ok for you?
<Ubugtu> Malone bug 59946 in xubuntu-system-tools "Admin tools require admin group membership" [High,Confirmed]  https://launchpad.net/bugs/59946
<cjwatson> pitti: yes
<cjwatson> I approved it too
<pitti> cjwatson: mvo's new app-install-data for proposed is trivial (capitalizations of the Eula), I'll approve that
<cjwatson> pitti: ok
<cjwatson> sladen: http://wiki.ubuntu.com/InstallerDevelopment
<ogra> fabbione, BenC ... https://launchpad.net/ubuntu/+source/yaboot/+bug/81589 
<Ubugtu> Malone bug 81589 in yaboot "iMac G3 Keyboard and ramdisk load problem" [Undecided,Unconfirmed]  
<fabbione> pitti, cjwatson: 81598
<Mithrandir> iwj: we're supposed to discuss grub 2 at some time, prod me when you have time.
<fabbione> pitti, cjwatson: and I have the uploads ready 
<pitti> bug 81598
<Ubugtu> Malone bug 81598 in lvm2 "[SRU]  lvm2 check if device is md is broken on big endian machines" [High,Confirmed]  https://launchpad.net/bugs/81598
<sfllaw> pitti: Ping?
<sfllaw> pitti: Bug 59946?
<Ubugtu> Malone bug 59946 in gnome-system-tools "Admin tools require admin group membership" [High,Fix committed]  https://launchpad.net/bugs/59946
<pitti> sfllaw: yes?
<sfllaw> Did you accept Gauvain's patch to edgy-updates?!?
<pitti> sfllaw: no, to -proposed
<sfllaw> Phew.  OK.
<pitti> sfllaw: sorry if I typo'ed in the bug report
<fabbione> pitti: bug #81125 (SRU for dapper)
<Ubugtu> Malone bug 81125 in glibc "libc6 update for Edgy fails due to sanity check" [High,Confirmed]  https://launchpad.net/bugs/81125
<tkamppeter__> doko, ping
* Mez -> bed
<cypher1> i am getting little dissatisfied with Ubuntu's uptime :(
<ogra> dont shut it down then :)
<cypher1> ogra, :) by uptime i meant the time interval between a reboot.. not booting time :)
<ogra> i know what uptime is ...
<cypher1> ogra, sorry..
<ogra> ogra@aleph:~$ uptime
<ogra>  10:34:34 up 384 days, 15:54,  1 user,  load average: 0.00, 0.00, 0.00
<cypher1> ogra, hah.. thats cool
<cypher1> my sys crawls after 3 days
<cypher1> ogra, can FF be a reason ?
<ogra> might be, but this is not a suport channel ...
<ogra> file a bug if you thin it's worth one ...
<ogra> *think
<cypher1> ok thanks
<ogra> seb128, 
<ogra> # Add translation domain to .desktop file
<ogra> echo 'X-Ubuntu-Gettext-Domain=dia' >> debian/dia-gnome/usr/share/applications/dia.desktop
<ogra> /bin/sh: cannot create debian/dia-gnome/usr/share/applications/dia.desktop: Directory nonexistent
<ogra> make: *** [install-stamp]  Error 2
<ogra> :((((
<mvo> cjwatson: could you please have a look at the SRU proposal for bug  #81428?
<seb128> ogra: did you move the .desktop to the dia package?
<Ubugtu> Malone bug 81428 in app-install-data-commercial "sugarcrm needs update of app-install-data-commercial and a synaptic fix" [High,In progress]  https://launchpad.net/bugs/81428
<seb128> ogra: or did they rename it?
<ogra> i have a dia.desktop.in.in
<seb128> ogra: find debian -name "*.desktop"
<ogra> in the source
<BenC> Anyone willing to performa a test for me?
<BenC> cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
<seb128> ogra: what about the find?
<BenC> do this on edgy kernel and feisty kernel and tell me if they are the same or not?
<ogra> nope
<BenC> mdz: ^^
<seb128> BenC: 
<seb128> $ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
<seb128> 1500000 1400000 1200000 1000000 800000 600000
<seb128> oh
<ogra> ogra@edubuntu:~/packages/dia-0.96-pre3$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
<ogra> 1600000 800000 
<BenC> seb128: .17 or .20?
<seb128> will try on edgy in a few min
<seb128> that's .20
<ogra> here too
<BenC> ok
<seb128> I also have .17 on feisty and edgy on my laptop
<seb128> which one do you want?
<cypher1> BenC, in edgy 1733000 1333000 1067000 800000
<ogra> seb128, but the packaing is based on our last package ...
<ogra> (i made it fro the new tar.gz)
<ogra> *from
<seb128> ogra: what does that find print?
<ogra> nothing as i said ...
<ogra> there is no .desktop file we ship in the debian dir
<ogra> we have an upstream .desktop.in.in file in the source which i would have expected to be installed
<ogra> ogra@edubuntu:~/packages/dia-0.96-pre3$ grep applications debian/*
<ogra> debian/dia-gnome.files:usr/share/applications
<ogra> debian/rules:   echo 'X-Ubuntu-Gettext-Domain=dia' >> debian/dia-gnome/usr/share/applications/dia.desktop
<ogra> and dia-gnome should install it 
<mdz> pitti: ping
<seb128> ogra: well, the question is to know if the "make install" does install a .deskop
<seb128> desktop
<ogra> yep
<seb128> if it does the find command should print it
<seb128> make install is made to debian/tmp
<dholbach> mdz: there's https://wiki.ubuntu.com/MOTU/Launchpad/Guide
<seb128> the find is to run after build
<dholbach> mdz: I just searched for 'ubuntu-universe-sponsors'
<ogra> ah, sorry, i ran it on the clean source 
<dholbach> it looks a bit confused though
<mdz> dholbach: all your docs are belong to SponsorshipProcess
<seb128> ogra: np, could you try again after build? ;)
<ogra> yep
<ogra> copying to a new dir ...
<dholbach> mdz: looking
<seb128> brb
<mdz> dholbach: soon
<mvo> BenC: freq is the same on my machien on edgy and feisty
<BenC> mvo: thanks
<mvo> cheers
<seb128> BenC: 
<seb128> on feisty: 1500000 1400000 1200000 1000000 800000 600000
<seb128> on edgy: 600000 800000 1000000 1200000 1400000 1500000
<BenC> seb128: Ok, so the same, just reversed for sysfs show...thanks
<seb128> right, np
<ogra> seb128, hmm, not even /usr/share/applications :(
<ogra> but the .desktop file is in the source dir after the build
<seb128> ogra: add a cp to debian/rules and bug upstream about it 
<ogra> yeah
<ogra> tats what i'm currently doing ... but it's odd ... i see the code to copy it to $datadir in the makefile ...
<ogra> (applicationsDATA_INSTALL) "$$d$$p" "$(DESTDIR)$(applicationsdir)/$$f"; ....
<seb128> ugly :p
<ogra> and not working apparently :)
<ogra> it doesnt even get installed for the dia package
<ogra> not only dia-gnome 
* Riddell spams feisty-changes
<ogra> Riddell, again !
<doko> tkamppeter__: pong
<tkamppeter__> doko, have you seen the mail from Henrique about HPLIP 1.7.1?
<doko> tkamppeter__: yes
<doko> tkamppeter__: just prepare hplip packages for ubuntu then
<tkamppeter__> doko, is there something special I have to know about when packaging HPLIP? For now I have only synchronized fromm Debian.
<tkamppeter__> Especially HPLIP is heavily patched because the Python directories are moved to other places.
<doko> tkamppeter__: no, just take the packaging; the only thing hmh does is to rerun the auto tools; maybe you can ask him to checkin the 1.7.1 sources, so that the same upstream tarball can be shared.
<mdz> dholbach: there seems to be no link from MOTU to MOTU/FAQ
<dholbach> mdz: fixed
<mdz> thanks!
<dholbach> cjwatson: inheritance of clues is working now - once somebody reviews it, it'll be in bughelper.main (ubiquity could inherit from partman, ... then, and a '-v1' would find all the inherited clues on the "first level", and so on)
<cjwatson> mvo: updated 81428
<cjwatson> dholbach: neat, thanks
<cjwatson> Riddell: MOTU/Packages/Packaging/Kubuntu has a link to http://kubuntu.org/~jr/kubuntu_01_kdepot.diff which is a dead link; could you update that?
<Riddell> cjwatson: done
<incorrect> are all packages in ubuntu from debian or are some of ubuntu's teams creation?
<bhale> incorrect: some only exist in ubuntu
<bhale> or are changed between debian and ubuntu
<incorrect> does ubuntu do anything different to debian in the way they use dpkg?
<bhale> could you be more specific?
<bhale> not really
<bhale> we added a Breaks: command
<bhale> which i think might be in Debian now
<ogra> luunch
<incorrect> i am working on packaging snmp 5.4 has i have run into issues with the stock release
<incorrect> i am just looking at what the easiest way would be to drop the updated source code into a package
<seb128> non-debug backtraces are pretty much empty at the moment with feisty, does anybody has an idea of what could be causing that?
<seb128> usually you have function names, atm most of them are "??"
<siretart> enrico: any news about some new python-debian upload? I didn't notice anything on the mailing list
<mdz> seb128: dholbach says that /apps/compiz/general/allscreens/options/active_plugins must have 'decoration' in the list, but mine only has [gconf] 
<seb128> mdz: right, looks like there is some problem with desktop-effects since the compiz 0.3.6 update
<seb128> I've grabbed the new desktop-effects from fedora just before the sprint, might still have a bug to fix though
<seb128> it's on my list of things to look at
<seb128> unset the key with gconf-editor to go back to the schemas default list
<doko> Mithrandir: until when should the iso testing be done?
<Mithrandir> doko: just ignore that mail for now. :-)
<sfllaw> pitti: For bug 81428, can you set things to Fix Confirmed when you accept things into -proposed?
<Ubugtu> Malone bug 81428 in synaptic "sugarcrm needs update of app-install-data-commercial and a synaptic fix" [Undecided,In progress]  https://launchpad.net/bugs/81428
<pitti> sfllaw: didn't I? sorry
<pitti> sfllaw: ah, that was a misunderstanding; I set it back
<sfllaw> Thanks.
<seb128> is there an easy way to test if a bug is a pam one?
<seb128> like https://launchpad.net/bugs/81559
<Ubugtu> Malone bug 81559 in gdm "15 character password limit in GNOME login" [Wishlist,Confirmed]  
<Mithrandir> seb128: try if it works from the console, using login?
<Mithrandir> my password is > 15 chars, though
<seb128> a 20 chars password works fine on my laptop as well
<saispo> anyone work on ubuntu-installer, i have a question about repository inclusion, i try to include universe, but not working...
<cjwatson> saispo: preseed 'd-i apt-setup/universe boolean true'
<cjwatson> saispo: the Canonical distro team is at a work sprint in Oslo at the moment, so please don't get too impatient if it takes a while to get answers this week
<newz2000> Hey, how prominent should the DVD releases be on the download page?
<newz2000> Do we want to encourage people to get those, or would we rather them get the CDs?
<ogra> newz2000, thats rather a question for elmo :)
<newz2000> ogra: because of bandwidth/mirror issues?
<ogra> yep
<ogra> DVDs are significantly bigger
<newz2000> well, Znarl and I were discussing it and were curious how the devs felt about supporting the DVD release
<ogra> and often not mirrored
<Znarl> ogra : Besides bandwidth/mirror issues, is there any other reason users should be discouraged from downloading DVDs?
<ogra> promoting them would put more load on the DC
<Mithrandir> newz2000: they're supported, but clients have trouble downloading them, they're about 8x bigger than a CD image, etc so I don't think we want to promote them very much.
<cjwatson> ogra: if the sysadmins are happy with that, it's their decision. I'm sure Znarl is competent to judge
<cjwatson> the other problem with DVDs is that they aren't tested very well
<newz2000> cjwatson: that's the key point
<Mithrandir> Znarl: some clients aren't able to download files bigger than 2GB.
<cjwatson> we build them because they're frequently requested, and they're useful as physically-portable package archives if nothing else (as well as installation images)
<ogra> well, i'm surely the wrong person to ask here, i'm fighting to keep CDs for edubuntu users  ... my userbase sits in countrys where you only get bad dialup bandwith and often no DVD writers
<ogra> (often not even readers)
<newz2000> So for best user experience, the CD is the choice, because the DVDs are not as rigorously tested (and downloading/burning them is more difficult)
<newz2000> ?? (that was a question)
<cjwatson> definitely
<ogra> right
<newz2000> ok, that's good to know. If that changes, would someone tell me? I'm going to de-emphasize the download DVD links
<Znarl> Anyone want to guess when that may change in the future?  When the DVDs will become more popular?
<fabbione> Znarl: when Canonical will ship free HD-DVD and Blueray burners to everybody? ;)
<newz2000> fabbione: OK, well, I think I"m going to need one of those for testing purposes... also a HD LCD TV.
<zul> fabbione: soon i hope :)
<Znarl> Right now mirrors are discouraged from mirroring DVDs, there's no rsync modules for it, no instructions.  Just thinking if that may need to change in future.
<Mithrandir> fabbione: they're a bit expensive still, but not that bad.   About 650.
<seb128> kwwii: gtk-icon-sizes="panel-menu=16,16:panel=16,16:gtk-menu=16,16:gtk-large-toolbar=16,16:gtk-button=16,16"
<seb128> kwwii: to copy to .gtkrc-2.0, workaround for your toolbar icon problem, let me know if that works for you
<Mez> cjwatson, is there a ML (or central email) for the CC?
<elmo> Mez: community-council@lists.ubuntu.com
<Mez> elmo, cheers
<cypher1> seb128, can you pls again tell me the email address i have to notify if i am interested in working a particular spec
<seb128> cypher1: ubuntu-devel@lists.ubuntu.com
<Mez> seb128, surely -discuss ?
<cypher1> seb128, thanks
<Mez> cypher1, that should be ubuntu-devel-discuss I think (unless you're an ubuntu dev already ? )
<cypher1> Mez, i am new to ubuntu devel
<Mez> cypher1, then it'll be ubuntu-devel-discuss@lists.ubuntu.com
<cypher1> Mez, i will sent to -discuss.. thanks
<kwwii> seb128: apparently not :-(
<seb128> Mez: works fine for me with gedit by example
<seb128> Mez: if you want to work on a spec better to mail ubuntu-devel
<Mez> seb128, but surely - if it's a read only list ?
<seb128> Mez: that's not notice devels you are working on, not to discuss between contributor
<seb128> Mez: no, or people could not post on it
<seb128> that's a moderated list
<Mez> seb128,that's what I meant. ..
<Mithrandir> stuff is moderated through once in a while, though
<cypher1> i sent to ubuntu-devel-discuss.. hope its ok..
<kwwii> seb128: it does seem to make some icons smaller, but not all icons in a toolbar in one program
<fabbione> Mithrandir: yeah... well.. still too pricy for my wallet
<Mez> Mithrandir, ah ... lol - I thought it was aruto-rejected ;)
<Mithrandir> fabbione: you get free DVD burners if you buy a hot dog or fries in a shop. though.
* Treenaks just wants working X drivers ;)
<Treenaks> I've only been waiting since breezy :P
<fabbione> Mithrandir: "can I have a BigMac DVD Menu please with big fries and 2 cheese burgers?"
<Mithrandir> fabbione: yes, just about it.
<fabbione> heh
<ogra> Treenaks, and then your life would be so empty ... nothing to complain about ... we cant be that evil :)
<jdong> can a kind archive admin clear backports NEW queue please? if it's already been done, sorry in advance for the noise
<Treenaks> ogra: but it's a LaptopTestingTeam laptop! :)
<ogra> Treenaks, so you can go on to test it eternally, isnt that great ! ;)
<Treenaks> ogra: But.. but... :'(
<Treenaks> ;)
<ogra> (i totally agree btw ... new X drivers would be nice)
<Treenaks> ogra: #20283 if you care ;)
<ogra> i think i looked at it plenty of times :)
<Treenaks> *kicks bot* bug 20283
<Ubugtu> Malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Unknown,Needs info]  https://launchpad.net/bugs/20283
<gnomefreak> are we keeping xorg at the version it is for feisty? i figured X updates would have happened already i only saw a couple of X merges
<ogra> i'd love ati 3D support for my ATI Radeon XPRESS 200M .... but you simply cant have everything 
<Treenaks> ogra: I just want it to set its modes properly.. the rest is OK already :)
<sfllaw> Riddell: Got any time?
<Riddell> sfllaw: always for you
<fabbione> gnomefreak: you are welcome to merge the packages....
<gnomefreak> fabbione: wish i could i never got the hang of merging. i just wasnt sure if we were keeping it the same :(
<Mithrandir> sfllaw: nag, nag.  When can I get my bug texts?
<bddebian> heya
<saispo> cjwatson: ok, thanks for the information
<sfllaw> Mithrandir: Where's my libc6 2.3.6-0ubuntu20.1 in dapper-proposed?
<fabbione> sfllaw: being removed... that's not the one you need to check
<fabbione> you want 20.3 that's building
<sfllaw> That's what I mean.
<fabbione> it's building..
<crimsun> seb128: Is it feasible for us to update libgpod to 0.4.2? (changes noted at http://sourceforge.net/project/shownotes.php?group_id=67873&release_id=478662 )
<seb128> crimsun: it's planned and on my TODO, there is a bug comment about it already, just lot to do, I'll look at that
<crimsun> seb128: ok, thanks, just wanted to prevent duplication of effort :-)
<seb128> np
<bdmurray> cr3: bug 77835 was not associated with a package.  I set it to the kernel, linux-source-2.6.20 as the system was having trouble rebooting.
<Ubugtu> Malone bug 77835 in linux-source-2.6.20 "Feisty Herd 1 installation hangs on reboot" [Undecided,Unconfirmed]  https://launchpad.net/bugs/77835
<lifeless> dholbach: - 
<lifeless> tree.branch.repository.get_revision(tree.last_revision()).timestamp
<dholbach> lifeless: ROCK!
<sfllaw> pitti: Bug 59946 is ready for upload to edgy-updates.
<Ubugtu> Malone bug 59946 in gnome-system-tools "Admin tools require admin group membership" [High,Fix committed]  https://launchpad.net/bugs/59946
<sfllaw> pitti: I will notify the #xubuntu guys.
<cjwatson> jdong: I did it this morning after seeing your earlier request; I think you weren't around at the time or I'd have told you, or maybe I just forgot
<jdong> cjwatson: ah, ok, I just noticed the packages arriving. Thanks!
<cjwatson> bdmurray: yeah, the kernel has some fixups for reboot quirks in particular hardware
<cjwatson> probably just needs a bit of extension
<bdmurray> cjwatson: that was with Herd 1 would it be different in Herd 2?
* siretart wows at https://wiki.ubuntu.com/UbuntuForDebianDevelopers - Great Summary!
<cjwatson> bdmurray: probably not particularly
<jdong> when is Keybuk around usually?
<jdong> or anyone else who can discuss readahead-list
<cjwatson> bdmurray: I doubt it's changed much; I added a note to the bug asking for the information you usually need for this particular problem
<jdong> "apparent" GNOME startup speed greatly benefits from a 2nd readahead consisting of the login sequence at the end of the bootup
<cjwatson> (output of dmidecode, and try reboot=b to see if that fixes it)
<jdong> IMO it's benefitial if we do a idle-priority readahead of the GNOME stuff needed to login
<cjwatson> jdong: he might be around next week; he had to leave a day or two ago
<jdong> ok
<mdz> sfllaw: your opinion on bug 81692?
<Ubugtu> Malone bug 81692 in malone "Display team emblem on bugs from project contributors" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/81692
<sfllaw> Hold on, Firefox is stalled.
<sfllaw> Installing epiphany.
<sfllaw> mdz: I think there is merit to this request.
<sfllaw> Do we display all emblems?  Or just a selected list?
<cjwatson> mdz: how about the bugzilla.gnome.org points system? that's essentially analogous to log(karma)
<cjwatson> and is explicitly intended to serve a similar function
<sfllaw> cjwatson: That's a fair assessment.
<sfllaw> cjwatson: That way, it's not exclusive to developers.
<sfllaw> If only there were some actions that would decrease someone's karma...
<Mithrandir> sfllaw: don't we have a bunch of people who're not developers but still members of teams?
<sfllaw> Mithrandir: Well yes.  But which teams are useful ones to display?
<sfllaw> Do we have to maintain this list?
<sfllaw> I don't object, but that sounds like annoying work that we'd forget to do.
<Mithrandir> the only risk I see with putting all of them there is some people will create bogus teams to get more emblems.
<seb128> the log(karma) idea looks like a good one
<cjwatson> sfllaw: "waiting"
<cjwatson> karma should be displayed as log(karma) anyway
<cjwatson> if it is already, it should be displayed as log(log(karma))
<Treenaks> ( karma mod max(karma).. just to annoy people ;) )
<mdz> cjwatson: I think that teams offer us the chance to do much better than a questionable quantitative guess
<mdz> sfllaw: in my proposal, I said that only teams which were relevant to the product or distro context made sense to display
<sfllaw> mdz: I have no objection to either scheme.
<mdz> so e.g., ubuntu-qa, ubuntu-dev and ubuntu-core-dev in our case
<sfllaw> mdz: Perhaps _both_ would be useful to some degree.
<mdz> all of which I think would be very helpful
<seb128> well, team give one information
<seb128> there is a difference of competence and activity between qa people though
<saispo> hi seb128 :)
<mdz> I don't think activity means much
<mdz> in terms of this proposal
<seb128> right
<seb128> the point system is complementary
<mdz> agreed
<Mithrandir> in some cases, other teams might be relevant, like if answer a backport or sync request, I do it as a member of ubuntu-archive.
<mdz> Mithrandir: that's one that is (or will be?) tied to the distro in launchpad as well
<Mithrandir> mdz: ok, I misread your list as an exhaustive list.  When it wasn't, disregard my comment.
<jdong> is there anyone here who deals with ia64....
<jdong>   libsmjs-dev: Depends: libmozjs-dev but it is not going to be installed
<jdong> ^^ a buildd spewed that back at me...
<mdz> Mithrandir: you and simon both did; I wonder if I should rewrite it more clearly
<Mithrandir> jdong: looking
<mdz> I added punctuation
<jdong> Mithrandir: apparently it's because xulrunner FTBFS'ed on ia64
<jdong> Mithrandir: is it possible to initiate a rebuild once that situation is corrected without having to reupload?
<jdong> only ia64 is affected, all the important arches built fine :D
<Mithrandir> jdong: yes, it's called a give-back
<jdong> how does the whole give-back thing work?
<Mithrandir> jdong: I click a button, the buildd tries to build the package again.
<jdong> Mithrandir: ha cool :D magical
<cjwatson> mdz: bugzilla.gnome.org has stuff like (points: 5) and (developer, points: 27) which I think is the sort of level of information we should be aiming for
<Mithrandir> anything which is in dep-wait state gets retried automatically, anything which ftbfs-ed because of uninstallability needs to be given-back by hand.
<Mithrandir> once in a while, we give-back everything and hope it works itself out.
<cjwatson> mdz: because in addition to whether they're a developer or not, it's useful to know if somebody is an experienced bug reporter or somebody who just showed up
<mdz> cjwatson: right.  the 'developer' part of that is simple in Launchpad, while the points are not :-)
<jdong> Mithrandir: out of curiousity how long does it take to rebuild everything :)
<cjwatson> sure it is, we have something that's essentially identical to the points thing
<Mithrandir> jdong: a full archive rebuild is about a week, iirc.
<mdz> cjwatson: karma is so not what we want!
<cjwatson> the units are just bonkers, but they can be converted by simple mathematics
<cjwatson> karma is only wrong because it's so massive, surely
<elmo> cjwatson: no it also has bad bias problems
<jdong> Mithrandir: wow; has that been done yet given the DT_GNU_HASH thing probably needs a rebuild to take effect?
<elmo> cjwatson: the support and spec tracker are massively overweighted in particular
<elmo> Mithrandir: that's main
<elmo> well that's main with one buildd per arch - we don't have recent (if any) figures for a full archive rebuild
<Mithrandir> elmo: oh, ok.
* jdong somehow has a bazillion karma points.....
<elmo> jdong: and we don't rebuild the world on demand because it breaks mirrors and makes our users hate us
<Mithrandir> elmo: I thought it was roughly what our rebuild tests took.
<jdong> probably from changing statuses on backports tickets
<elmo> Mithrandir: we only rebuild test main
<jdong> elmo: I can imagine :)
<cjwatson> elmo: true
<Mithrandir> elmo: ok.  I imagined we did *, but apparently not.
<cjwatson> I guess we can always click through to the karma if we care
<cjwatson> (talked with mdz offline)
<jdong> but is everything in feisty to be rebuilt for dt_gnu_hash?
<cjwatson> no
<jdong> or has the important stuff already been handled :)
<cjwatson> there have been various proposals for a rebuild for certain gcc problems
<cjwatson> *if* a rebuild happens at all, it'll be because of that, not for extra features
<jdong> Mithrandir: can you also try to shed some light on why my avidemux ftbfs'ed on 3 arches?
<jdong> https://launchpad.net/ubuntu/+source/avidemux/1:2.3.0-0.0ubuntu2
<jdong> I cannot reproduce the error in a pbuilder
<jdong> and it seems to have breezed past that step on two pbuilders
<jdong> arches*
<Mithrandir> ia64, same problem
<jdong> yeah, but i386 puzzled me the most
<pitti> mvo: debdiff looks good, bug 81429
<Ubugtu> Malone bug 81429 in app-install-data-commercial "Please verify opera and realplayer on edgy-proposed" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81429
<jdong> mv: cannot stat `t-es.gmo': No such file or directory
<jdong> those kind of errors, that is
<jdong> and why they didn't happen on the other arches or inside my pbuilders
* jdong in fact didn't change the source at all... it was just a rebuild against newer x264
<mvo> pitti: https://wiki.ubuntu.com/StableReleaseUpdates
<Mithrandir> jdong: amd64 and i386 failure modes are the same.  Unsure what the underlying cause is from just looking at the build log
<kylem> http://librarian.launchpad.net/5900582/10_radeon_fix_agp_fastwrite.diff heh
<LaserJock> cjwatson and mdz: the Ubuntu Packaging Guide also is a good resource for UbuntuDevelopment
<mdz> LaserJock: can you follow up by email to the list?  I'm packing up here
<LaserJock> k
<gpocentek> pitti: thanks for the x-s-t upload
<mdz> thanks
<pitti> gpocentek: your're welcome; thanks for the fast preparation and testing
* pitti is glad to finally have this one settled now
<gpocentek> :)
<milli> keescook: I don't see that CVE-2007-0493 and CVE-2007-0494 are available on cve.mitre.org yet...  has it only been pre-released to vendors?
<milli> lamont: stop telling everybody how to exploit HP's name servers!  ;-)
<lamont> milli: ssssshhhhhH!!!!!
<keescook> milli: yeah, that came from through the vendor contacts, but they'll be public when they show up.  I'm not sure how quickly the CVE lists are updated.
<milli> keescook: then I assume CERT is going to produce something shortly too.
<elmo> those CVEs are public
<elmo> I saw them on NISTs RSS FEED
<elmo> err, 'feed' even
<milli> elmo: k, ty.  They are not posted nor searchable on cve.mitre.org yet.
* milli is concerned about DoS attacks on a few good customers
<jdong> Mithrandir: would you be ok with trying a rebuild and see if the failure is consistent?
<jdong> Mithrandir: I am at a loss as to why that happens... I must be losing my sanity
* nixternal notes that jdong really never had any sanity, so I guess he couldn't be losing it :)
<jdong> nixternal: don't make me post a reiser4 howto on the wiki based on my tinkering yesterday!
<nixternal> haha, watch it now, Reiser is in court these days, so I might be very well frightened
<jdong> nixternal: the machine was named wifenpieces
<nixternal> hahahaha
<nixternal> jdong: and that isn't German
<jdong> nixternal: wifenpiecen
<zul> the reiser jokes are getting lame :)
<jdong> zul: I know... I don't make that many anymore
<jdong> zul: so when will feisty have reiser4 patch? :D
<jdong> (ok, that reiser joke is still not old)
<zul> jdong: never
<jdong> zul: haha :)
<zul> jdong: you think im kidding
<jdong> zul: I don't think you're kidding.
<jdong> is there a command-line option for pbuilder for passing arguments to pbuilder-satisfydepends.pl?
<jdong> (me is looking for a way to trigger bypassing version checking on build-deps)
<jdong> nvm, found it
<zul> hey ajmitch 
<lool> Hi there, I wonder whether Ubuntu folks looked into the weird .desktop file "vulnerability" where one can trick nautilus into displaying a .desktop file as a regular image and launch anything: <https://bugzilla.novell.com/show_bug.cgi?id=238503> (seen on freedesktop's xdg)
<lool> It seems this is a very old bug which doesn't affect Xfce nor KDE, and I don't think it was fixed in GNOME at all
<keescook> lool: I haven't read the bug yet, but I'll look into it.
<lool> keescook: Great; the thing is I don't know where to start
<lool> keescook: The discussion on xdg brings a couple of interesting points, thread
<lool> argh
<lool> <http://lists.freedesktop.org/archives/xdg/2007-January/thread.html#9150>
<keescook> lool: I'd agree, that's a security problem.  I'll track it; thanks for the heads-up.
<juliux> hi
<juliux> is it a knowing bug that the feisty isos are not working on core duo pcs?
<juliux> http://www.transtec.de/D/D/products/personal_computer/pc/mini_pc.html?mod=prod&name=SY600MTA45-A this is the pc i test it
<siretart> is there somewhere an howto howto debug usplash scripts? e.g. how to start usplash manually in a booted system?
<sladen> 'usplash'
<siretart> sladen: it complains on a missing /dev/fb0. how to create that?
<juliux> hi siretart 
<siretart> huhu juliux 
<sladen> siretart: wah.  Do you not have a framebuffer?
<juliux> siretart, very strange errors here with feisty on a intel core duo
<siretart> sladen: this is on amd64, and in principle, usplash works for me
<siretart> juliux: huch?
<juliux> siretart, https://launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/81720 
<Ubugtu> Malone bug 81720 in linux-source-2.6.20 "edubuntu feisty install iso not working on intel core duo cpu" [Undecided,Unconfirmed]  
<juliux> siretart, it is the computer we get for free for the expos
<siretart> juliux: oh, that's bad
<siretart> juliux: who's sponsoring?
<juliux> siretart, transtec;)
<juliux> siretart, also two thinclients
<siretart> juliux: cool
<juliux> siretart, and i will use this also as a testing system for edubuntu
<siretart> sladen: oh, on my laptop, it works. seems that nvidia
<siretart> is interfereing
<siretart> juliux: bad that it doesn't boot :(
<juliux> siretart, i will try a upgrade from edgy
<davmor2> siretart there is a big bug in 64bit with nvidia cards :(
<siretart> davmor2: do you have a bugno for reading about it?
<davmor2> hang on I'll get it
<davmor2> siretart Bug 32389 is one
<Ubugtu> Malone bug 32389 in linux-restricted-modules-2.6.17 "[upstream]  nvidia-glx doesn't restore state on NV35/NV36 cards. Causes random mess on screen or system hang." [High,Confirmed]  https://launchpad.net/bugs/32389
<davmor2> Bug 56587 is two
<Ubugtu> Malone bug 56587 in usplash "[edgy]  usplash segfaults" [Medium,Fix released]  https://launchpad.net/bugs/56587
<siretart> sladen: okay, usplash works in principle now, I can use PROGRESS to set to progress bar. any idea why usplash_write "TEXT foo" doesn't print foo for me?
<davmor2> you kinda get the drift anyway.  I personally got onto nvidia about it and they now have it listed as an official bug with their developers but it's if or when they do something about it
<siretart> davmor2: thanks
<siretart> davmor2: but I doubt this is my problem. here it seems there isn't a /dev/fb0
<davmor2> siretart there are others and it effects more than just the nv35/36 cards but I can't remeber which exactly.
<davmor2> siretart that's right dev/fb0 is the framebuffer that is screwy with these cards in 64bit but not 32bit try a 32 bit live it'll work fine 64bit though and it throws it's dummy out the pram :)
<Chipzz> davmor2: no offence meant, but a little punctuation wouldn't hurt you ;)
<siretart> davmor2: interesting...
<jlawler> Does anyone know of an easy way to do remote package management (preferably on multiple simultaneous computers)?
* Chipzz sits there staring at that sentence ;P
<siretart> davmor2: I'm currently rather trying to fix cryptsetup with usplash. working on my laptop now :/
<LaserJock> jlawler: ssh? :-)
<siretart> jlawler: clusterssh, cfengine, puppet, choose your poison ;)
<davmor2> chipzz:  Dyslexia means I spend most of my time spell checking, forgive me if my lack of reading means my grammer goes to pot.  I tend to write as it is in my head which means it makes sense to me, sorry.
<davmor2> Thank god for in-line spell checking :)
<jlawler> Aight, the reason I asked about remote package management is because I have been thinking about what it would take to roll out and actively administer >100 ubuntu desktops.  It seems like there are more than a few tools that are missing to facilitate this, and I was trying to figure out what I'm missing.
<jlawler> I don't know if puppet or cfengine will quite meet my requirements
<siretart> jlawler: for managing cluster > 100 nodes, you'll have more problems than just installing packages. have a look at the cfengine tutorials
<siretart> jlawler: we're using it at our university for managing the students computers (about 120 debian nodes, I think)
<jlawler> siretart:  I hadn't seen cfengine before, and I'm planning on taking a look at it.  The reason I'm bringing this up in -devel is I'm debating writing a new program to tackle this.  However, I don't want to reinvent the wheel...
<torkel> jlawler: http://www.informatik.uni-koeln.de/fai/
<jlawler> torkel:  does fai handle updating specific packages, or does it require you to reimage an entire node?
<enrico> siretart: I got a private reply: the guy that knows things better is in vacation until sunday
<torkel> jlawler: they have something called softupdate, though I never tried it so I don't know how well it works
<enrico> siretart: I could go on myself but I'd prefer to wait for him, since I don't know very well what are the news with the other modules in the pakcage
<jlawler> So does this seem like a redundant piece of software, or something that would fill a genuine need?
<siretart> enrico: okay.
<siretart> enrico: I'd love to have a usable bzr-builddeb, so perhaps I'd have to upload some preprelease. I need to talk with james about that
<Chipzz> davmor2: oh, my apologies. didn't know. never mind I said that then.
<juliux> siretart, with a upgrade from edgy to herd2 the system boots
<enrico> siretart: I'd love to have it around as well
<siretart> juliux: yay. installer broken! :(
<enrico> siretart: lately I keep producing nice cool things that need that package
<siretart> enrico: in debian, the problem is rather the package stuck in NEW, and a too old bzr in unstable
<siretart> enrico: wow. nice to hear :)
<enrico> siretart: Just blogging a new one now
<davmor2> chipzz: it's okay it doesn't bother me.  It's not till some one points it out that I realise I've done it.  In my head I see the punctuation but it doesn't always get transferred from my head.  No biggy though.
<juliux> siretart, so package is debian-installer?
<siretart> juliux: most probably not, but I'm not sure how to diagnose the problem. do you know where it actually hangs?
<juliux> siretart, after the keyboard decetion the installer loads some drivers and then is hangs up
<siretart> juliux: via alternate or via live installer?
<juliux> siretart, install cd from edubuntu
<siretart> juliux: then I'd file against debian-installer. colin can reassign it if necessary
<juliux> siretart, thxs
<siretart> how to flush the keyboard input buffer from a shell script, suitable for early userspace?
<siretart> can I use stty for this?
<whadar> what tool do you use for feisty to monitor file access?
<exobuzz> is there any plan to make knetworkconf profiles actually work for feisty? they were broken on edgy and still seem broken on feisty https://bugs.launchpad.net/ubuntu/+source/kdeadmin/+bug/73788
<Ubugtu> Malone bug 73788 in kdeadmin "Network profiles completely broken" [Undecided,Confirmed]  
<pochu> what do you think about bug 81751?
<Ubugtu> Malone bug 81751 in ekiga "remove ekiga from default ubuntu-installation" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/81751
<pochu> It talks about changind defautls (changing a program)
<caci> never used it, but isn't it supposed to be a premier app on the gnome desktop
<Amaranth> pochu: can telepathy do SIP?
<pochu> Amaranth: SIP?
<Amaranth> http://en.wikipedia.org/wiki/Session_Initiation_Protocol
<Amaranth> standard VoIP stuff
<dsas> Amaranth: I don't know if it does it yet, but I think Nokia were sponsoring hacking on it.
<Amaranth> telepathy is the end goal but it's not quite ready yet
<pochu> Amaranth: so I leave the bug open, right?
#ubuntu-devel 2007-01-27
<Robot101> dsas: nokia are tusling with their legal department to determine if they can release it
<Robot101> (the SIP backend they have)
<v_> hi... what ubuntu edgy package contains shadow utilities?
<v_> i've just installed a system using debootstrap, so i don't have it
<Liberax> hi anybody has experimented the pptp bug on amd64 with network manager?
<pochu> Liberax: what bug?
<Liberax> https://bugs.launchpad.net/ubuntu/+source/network-manager-pptp/+bug/67881
<Ubugtu> Malone bug 67881 in network-manager-pptp "Crash while trying to connect to PPTP server" [Undecided,In progress]  
<Liberax> pochu: i'm looking for someone to check this patch
<pochu> Liberax: I've never experienced this issue, so I won't be able to test it
<Liberax> pochu: you need to run on amd 64
<pochu> Liberax: haha, and I don't have either an amd64 machine
<pochu> :)
<pochu> Liberax: try asking on #ubuntu-motu
<Liberax> pochu: are there plan to release nm 0.7 on festy?
<pochu> Liberax: I think n-m 0.7 hasn't been released
<pochu> am I right?
<Liberax> yes but i think nm is proposed as an official gnome 2.18 module
<Liberax> pochu: i doesn't know if they release 0.7 on it
<pochu> if it's going to be in gnome 2.18, I think it will be in Feisty
<LaserJock> not necessarily
<LaserJock> not *all* modules in Gnome get a UVF/FF exception
<pochu> LaserJock: do you know if n-m is going to be by default in feisty because the network reaming specs?
<Burgwork> pochu: currently it is installed by default
<Burgwork> roaming, not reaming
<Burgwork> reaming is something entirely different :D
<pochu> Burgwork: typo
<pochu> don't know what reaming means, wanted to say roaming :)
<Burgwork> ream is a rather rude term in general english
<pochu> Burgwork: I installed Feisty about 2 weeks ago and Feisty wasn't by default
<pochu> Burgwork: are you sure it is now?
<Burgwork> the plan is yes, provided it doesn't break things too badly
<Burgwork> the reason it has been removed before
<LaserJock> yeah, it was difficult in Edgy
<LaserJock> I haven't tried it in Feisty yet
<Mirv> and Dapper, and Breezy.
<LaserJock> :-)
<pochu> I have it, and it works fine
<Burgwork> it still doesn't understand static IPS
<pochu> but my intel driver has been broken
<LaserJock> they biggest problem for me is I generally static IPs
<Mirv> don't know if n-m can succeed before the whole wlan stuff proceeds further in linux
<crimsun> Burgwork: I'm presuming, then, that it doesn't play nicely with resolvconf.
<Burgwork> probably not
<LaserJock> ugg, resolvconf and nm have caused me so much networking headache
<crimsun> I use resolvconf with udhcpc quite merrily.
<crimsun> dhcp3-client (dhclient) causes me endless pain.
<Liberax> i think that if the network is configured statically on the admin panel (gome system tools) nm applet will not control the device
<LaserJock> it's annoying to have all my computers set up and then on reboot it's all overwritten
<Burgwork> Liberax: I don't know if that has been written yet
<Burgwork> the GNOME people wanted that before they would accept NM in
<LaserJock> smart
<Liberax> i tested this on edgy.. as i can remember
<LaserJock> the gnome system tools app doesn't like me either though
<pochu> there is a bug in malone about static ip address
<LaserJock> yes
<Burgwork> it is not a major priority, afaics from the NM todo list
<Burgwork> apparently NM can handle static IPs, just no GUI for it
<Liberax> i tink that the device is configured on /etc/network/interfaces nm applet will not control the device
<Burgwork> that was an Ubuntu specific patch, afaik
<pochu> I don't care, as long as I use dinamical ips
<pochu> :)
<Burgwork> except when you run into a network that requires it
<LaserJock> I only have 1 computer out of 5 that I use regularly that has a dynamic ip
<LaserJock> :/
<pochu> I don't do that :)
<Liberax> Burgwork: i doesn't know if it work also on redhat or other distro network file configuration
<pochu> LaserJock: do you really have 5 computers?
<pochu> are they servers or what?
<bhale> i have at least 4
<LaserJock> pochu: 2 at home, 3 at work
<bhale> at least 5
<bhale> not counting servers
<Burgwork> Liberax: they don't use /etc/network/interfaces
<pochu> LaserJock: don't you work at home?
<pochu> :)
<LaserJock> umm, no
<LaserJock> sometimes
<LaserJock> but I'm a chemist and the lab doesn't run well from home
<pochu> oh, don't you work for canonical?
<Liberax> Burgwork: i mean if nm check other backend network config files
<LaserJock> pochu: umm, no. Most people here don't
<pochu> I tought all ubuntu devs worked for canonical
<LaserJock> haha
<pochu> thought
<pochu> :)
<LaserJock> not even close
<pochu> then, just mdz and mark?
<pochu> :)
<LaserJock> if you count MOTUs there are something around 80 devs
<pochu> ups
<LaserJock> and about 15-20 are Canonical, I think
<LaserJock> could be a bit off there though
<pochu> haha
<pochu> :)
<pochu> and you are a motu, right?
<LaserJock> yes
<pochu> so you are an ubuntu dev
<LaserJock> yes
<pochu> :)
<pochu> I learn very quickly
<pochu> :)
<LaserJock> not a core-dev though
<pochu> core-devs work for canonical?
<LaserJock> well, it's a bit complicated
<Burgwork> pochu: a good number do, maybe even most
<crimsun> But no, not all core-dev are Canonical employees.
<LaserJock> all the canonical devs are core-devs
<pochu> do you do?
<pochu> and Launchpad devs are?
<LaserJock> Canonical
<Liberax> How do I setup a static IP address with NetworkManager?
<Liberax> NetworkManager has limited support for static IP addressing. Configuration of static IPs is distribution specific and should use that distribution's normal network configuration methods.
<Liberax> For example, on Fedora Core, using the system-config-network tool or editing /etc/sysconfig/network-scripts/ifcfg-eth1 to set a static IP up for the device 'eth1' would result in NetworkManager using that static IP configuration whenever you connect to an access point using eth1. Obviously, since static IP configuration is always a manual task, NetworkManager is not able to automate the process in any way.
<pochu> then all the devs who don't work for canonical do their work just for fun?
<pochu> as me?
<LaserJock> well, not sure about fun
<LaserJock> ;-)
<LaserJock> but we are mostly volunteers yes
<Liberax> Burgwork: so work also on redhat style distro
<pochu> but if you don't earn money, and you don't be fun with what you are doing here, why do you do it?
<Burgwork> Liberax: I have no idea. I avoid the Fedora machines at work like the plague
<LaserJock> pochu: sometimes it's more like a job, except you don't get paid
<pochu> LaserJock: can't understand :)
<LaserJock> most of us do it because we believe in Ubuntu and its community ( I think that could be a fairly general statement )
<Liberax> I think on debian style and redhat style file configuration if the text config file is edited network manager doesn't control the device configured manually
<pochu> well, I can't understand just if you don't enjoy it
<LaserJock> but sometimes it's very hard, time-consuming, and aggrivating
<pochu> LaserJock: that's a good argument
<pochu> :)
<LaserJock> so yes, we like to do it, but that doesn't mean it's always fun
<Burgwork> cya all
<pochu> LaserJock: and don't you are an IT?
<pochu> if you are chemist...
<LaserJock> no, not at all
<LaserJock> I've never taking a computer/IT class in my life
<pochu> but you know a lot, and you like computers...
<LaserJock> *taken
<pochu> right?
<LaserJock> and my research doesn't really involve computers at all
<LaserJock> well, I know a bit and I like working on computers
<pochu> thanks for the class
<pochu> :)
<bddebian> Gah, did I miss a class? 
<pochu> bddebian: you did :)
<bddebian> Figures, I have no class :-)
<pochu> I had, but I didn't go today
<pochu> :)
<okaratas> hello
<pochu> okaratas: hello
<pochu> cjwatson: ping?
<pochu> LaserJock: do you know anything about ubiquity bugs?
<dsas> pochu: If you haven't saw it https://wiki.ubuntu.com/DebuggingUbiquity has some info on ubiquity bugs
<dsas> well, it has info even if you have saw it...
<pochu> haha
<pochu> dsas, thanks
<bddebian> How long is everyone going to be at the devel sprint?
<mjg59> Mostly leaving today
<bddebian> mjg59: Ah, thx
<bddebian> mjg59: Were you the one that told me we ripped libGLw out a while back?
<mjg59> No
<bddebian> OK
<azeem> bddebian: I think daniels did that, back then, but I'm not sure
<azeem> well, ripping it out, not telling you
<bddebian> Yeah.  I'm wondering if it's gone for good.
<bddebian> What the heck happened to daniels anyway?
<azeem> I seem to remember rodarvus mentioning it might come back
<azeem> not sure though
<bddebian> I can't get xbvl to build without it, even with --without-MESA :-(
<azeem> then maybe it's time to throw out xbvl? :)
<bddebian> Heh, works for me :-)
<bluefoxicy> an exchange server would be nice.
<bluefoxicy> thunderbird/lightning, evolution, xfce with ical based calendar...
<bluefoxicy> all storing things in different places.. you MUST use Evo to get calendar in gnome's clock to work... MUST use xfce's thing to get their calendar to work... damn.
<bluefoxicy> since we can't agree on where to put calendar data...
<bluefoxicy> I don't know why, but it tends to take an act of God (or an LDAP implementation) to get 6 different apps to store the same basic information in the same place, even though they all use the same format.
<_ion> Yeah.
<_ion> With opensync, you can probably synchronize each app's calendars  you might have to write a plugin for xfce first, though. :-)
* bluefoxicy wonders about a configurable user-local server that stores data in ~/
<_ion> There seems to be plugins for evolution and sunbird already.
<bluefoxicy> like, thunderbird/evo connects to exchange server at localhost:55555 (or over a UNIX socket), asks for <some mail account)
<bluefoxicy> local server POP3's out, gets mail.
<bluefoxicy> repeat for other silly things that store same crap in different places
<_ion> Eww. Why not just use IMAP?
<_ion> For mail, that is.
<bluefoxicy> IMAP rather than exchange perhaps :P
<bluefoxicy> but exchange gets you calendars
<bluefoxicy> (IMAP + Exchange == Evo + Sunbird can both use it!)
<_ion> I wonder, actually, whether it would be feasible to use IMAP maildirs as calendar storage. Just tell the MUA "this is a calendar" and have it store each calendar item as a "message" in a specified format.
<bluefoxicy> ugly hack
<bluefoxicy> I would prefer something that fools existing idiots-- err, applications into thinking they're getting data from somewhere.
<_ion> I don't really see why that would be either ugly or a hack.
<bluefoxicy> as ugly as googlefs
<_ion> That's something completely different. :-)
<bluefoxicy> i.e. using <storage container A> to store <subject matter B> by wrapping it up to look like <Subject matter A>
<bluefoxicy> think about it
<bluefoxicy> it would have a From:  and a To:  and would probably be sent through the SMTP/POP3 system and be duplicated
<bluefoxicy> Client<->IMAP<->{email system}  Client tells IMAP to send/view messages, if it sends it goes out to the email system, if it sends to self it comes back :/
<_ion> Maildir items are just headers + content. They are perfectly suitable for calendar items. You don't need to define From: and To:, neither you need to (or should!) use SMTP/POP3.
<bluefoxicy> IMAP lets you dump arbitrary junk into it?
<_ion> For example, here's an information organization tool that uses mailbox as its storage format. It's just perfectly suitable. http://modeemi.cs.tut.fi/~tuomov/riot/
<_ion> You can open its data file in Mutt and see the "threading" correctly.
<_ion> It has nothing to do with e-mail, but still it's totally suitable. Just like storing calendar items in that format. :-)
<_ion> IMAP servers magically handle whatever's needed for multiple clients to be connected simultaneously.
<_ion> http://freshmeat.net/projects/imap_calendar_proxy/
<_ion> HTTP, the *Hypertext* Transfer Protocol, has proven to be suitable for other things than just hypertext. Why wouldn't that be the case with IMAP?
<YeaSt> ?
<balarka> hi
<somerville32> You gotta love it when apport reports it's self crashing, lol
<Mez> espescially if it crashes when it reports itself crashing
<siretart> mjg59: around? I have a usplash question for you
<Goliath23> hi
<Goliath23> where can I read the changelog of the linux kernel package from 2.6.15-26 to 2.6.15-27? and is there an alternate install cd (text install with possibility to setup a raid) that uses the latter kernel version?
<Seveas> keescook, ping
<Seveas> err nvm, you're probably sleeping
<Seveas> anyway: if USN's contain sourceforge bugs, the link to the bug is busted
<zoli2k> I wrote  some c++ header files for data visualization and I would like to put it to our internal server and allow other scientist to install them on ubuntu. 
<zoli2k> Is there any tutorial how to start build easily and correctly deb packages for ubuntu?
<v_> hi. will it cause problems if i installed two packages that provide the same meta package, or whatever it's called, ie. two packages that provide system-log-daemon
<v_> ok
<v_> i read the topic, just now
<v_> oops
<v_> :P
<Seveas> zoli2k, on help.ubuntu.com you can find the packaging guide
<Seveas> zoli2k, by the way: beginners packaging questions are more suitable for #ubuntu-motu
<MetaBookfoziS> hola
<MetaBookfoziS> why the kubntu feisty herd cd2 hasn't got partitionmanager ?
<MetaBookfoziS> it want's to write my whole disk... (but i'm don't want that)
<_ion> mbiebl: Updated the diff, https://launchpad.net/ubuntu/+source/tracker/+bug/81800
<Ubugtu> Malone bug 81800 in tracker "New upstream release: 0.5.4" [Undecided,Unconfirmed]  
<linuxboy_> herd 2 doesn't work on my asus A6V I booted on live-cd Kubuntu 7.04 then press on F6 and I remove quiet et splash and put 1 instead then press enter
<linuxboy_> after battery state..... I have a black screen :(
<Hobbsee> linuxboy_: filed a bug?
<Hobbsee> linuxboy_: with /var/log/syslog and /var/log/xserver.0.log ?
<linuxboy_> I run the feisty with a live-cd ....
<Hobbsee> oh wait, a live cd
<Hobbsee> so it doesnt boot at all, even without quiet splash there?
<linuxboy_> ok I can file a bug but what do I put in ?
<Hobbsee> linux-kernel-2.6.20, i'd guess.
* Hobbsee wonders if it works in recovery mode
<linuxboy_> it boots ..... 
<Hobbsee> right
<Hobbsee> so you do get the logs
<linuxboy_> but after the battery state field the screen turns off :(
<linuxboy_> how I can get the logs ?
<Hobbsee> ahhh
<Hobbsee> i'm not sure....hrm.
* Hobbsee wonders what battery state is
<linuxboy_> I was in console ...... when I booted .....
<linuxboy_> you know each step appears 
<Hobbsee> ah
<linuxboy_> and after battery state there was something with local.rc 
<Hobbsee> oh...there
<linuxboy_> and no screen anymore :(
<Hobbsee> in failsafe X mode, presumably?
<linuxboy_>  I am on a laptop asus A6V 
<linuxboy_> yes I try in safemode with vesa 
<linuxboy_> but it's the same thing
<linuxboy_> I put also acpi=off
<linuxboy_> I have to eat and I come back after .... and I will try the daily live-cd .....
<linuxboy_> thanks !
<Hobbsee> ah
<Goliath23> I think I found a "low hanging fruit" feature request/bugfix for the raid-konfiguration in the text installer, shall I report it in launchpad?
<Hobbsee> Goliath23: yes.  file under debian-installer
<Goliath23> thing is: if you setup one ore more big raid devices after finishing the partition part the installer hangs pretty long with the plain blue screen while in the background the new md devices are synced
<Goliath23> I think via /proc/mdstat a progess bar could be easily implemented
<Goliath23> is that a bug ore feature request?
<Goliath23> pretty long means several minutes, 160 gb raid took 10-15 minutes or so
<Goliath23> without visual notification most users probably think that their computer hangs, especially with quiet disks ;)
<linuxboy_> Hobbsee: ok re ....
<Hobbsee> Goliath23: worth putting it in, i expect
<linuxboy_> how I can get errors messages ?
<Goliath23> Hobbsee: ok.. damnit, I have to use launchpad again. :) I try to file it for debian-installer
<Goliath23> problem is: try to search for package "debian-installer" gives you all packages since all depend on it I guess
<Hobbsee> Goliath23: https://launchpad.net/ubuntu/+source/debian-installer/+filebug
<Hobbsee> linuxboy_: i dont know..
<Goliath23> Hobbsee: https://launchpad.net/ubuntu/+source/debian-installer/+bug/81816
<Ubugtu> Malone bug 81816 in debian-installer "setting up raid partitions takes very long and installer shows no progress bar for it" [Undecided,Unconfirmed]  
<Goliath23> I couldn't find fields to select version and so on, so I wrote it in the description
<Hobbsee> Goliath23: cool ;)
<Goliath23> kk
<Goliath23> thanks for making the raid setup so easy, enabling me to configure a database server for my girlfriends clinical laboratory! I love kubuntu ;)
<Goliath23> and ubuntu of course *g*
<solemnwarning> Why does ubuntu detect a pccard to compact-flash adaptor and use the devices sd* when debian uses hde because it's detected by pccard IDE?
<kokoa> hello
<linuxboy_> hey !
<linuxboy_> https://bugs.launchpad.net/ubuntu/+bug/81826 :(
<Ubugtu> Malone bug 81826 in Ubuntu "[feisty herd2]  [27.01.2007 i386-desktop]  screen cuts off after the steps battery state and local.rc !" [Undecided,Unconfirmed]  
<linuxboy_> some help ? :(
<_MMA_> linuxboy_: #ubuntu+1
<linuxboy_> _MMA_ ??
<linuxboy_> what is it 
<linuxboy_> ah ok
<pirast> do we need urgency=high for security updates?
<Adri2000> pirast: I don't think so, 'urgency" is used in debian to say that a package needs to go into testing quickly, so that's useless in ubuntu
<Adri2000> s/"/'/ :)
<crimsun> pirast: I'm taking a SVN snap of vlc, so #76810 is in progress.
<crimsun> 78610, rather
<fabbione> siretart: #81841 is a duplicate of another one
<fabbione> known problem
<fabbione> siretart: and kernel isn't at fault really. it's a race between libdevmapper/udev/lvm2
<siretart> fabbione: ?!?! - this means that this race is causing vg data corruption?!
<fabbione> yes
<fabbione> as i said.. it's a known problem
<siretart> puh. that's pretty critical, I'd say
<fabbione> no it's not.. that kind of mess is not common
<fabbione> we have a fix that's pending upload
<siretart> fabbione: is this the same race that prevents systems with root on lvm on raid booting?
<fabbione> no different one
<siretart> :(
<fabbione> it's a race creating devices in /dev
<fabbione> and sometimes you get hooked to the wrong one
<siretart> fabbione: I do run several ubuntu servers which use several layers of lvm snapshots for backup purposes
<siretart> so I wouldn't say this was too uncommon
<fabbione> it's when you create multiple snapshots at the same time that you hit the issue
<fabbione> not when you do one at a time
<siretart> yes, on these systems I'm doing this
<siretart> to simulate something similar to the windows shadow copies
<siretart> shadow volumes, or however that crap is called
<fabbione> in any case there is a duplicate in LP
<fabbione> so please go look for it
* siretart looks
<fabbione> yeah but in any case when you create ONE at a time is not a problem
<fabbione> when you create tons in one go it might be an issue
<pochu> _ion: ping?
<fabbione> and it depends on tons of factors
<siretart> bug #81841
<Ubugtu> Malone bug 81841 in lvm2 "creation of multiple snapshots currupts LVM metadata of volume group" [Undecided,Unconfirmed]  https://launchpad.net/bugs/81841
<_ion> pochu: pong
<siretart> no, I'm holding several snapshots in paralell for some longer time
<pochu> _ion: are you working on the update of tracker?
<_ion> pochu: Yep.
<siretart> given this bug, I come to the conclusion that lvm isn't robust enough for that :(
<pochu> _ion: then we were doing the same ;)
<pochu> _ion: do it you, because I'm a little noob
<pochu> ;)
<gezzabob> hi all
<siretart> fabbione: perhaps bug #76421?
<Ubugtu> Malone bug 76421 in lvm2 "system crash when creating more than one snapshot of a lvm volume" [Undecided,Unconfirmed]  https://launchpad.net/bugs/76421
<pochu> _ion: did you see that you need to add libmagic-dev to the build-depends?
<_ion> pochu: Yes, please take a look at the diff i've posted to bug #81800.
<Ubugtu> Malone bug 81800 in tracker "New upstream release: 0.5.4" [Undecided,In progress]  https://launchpad.net/bugs/81800
<_ion> pochu: A diff from the 0.5.3 packaging so far: http://librarian.launchpad.net/5908617/tracker.interdiff
<pochu> _ion: ask in #ubuntu-motu
<siretart> fabbione: or maybe you mean our good ol' friend bug #38409?
<Ubugtu> Malone bug 38409 in Debian "creation of snapshots fails unpredictably" [Unknown,Unconfirmed]  https://launchpad.net/bugs/38409
<fabbione> siretart: yeps
<fabbione> the latter one
<fabbione> anyway.. back to have some fun
<fabbione> it's saturday
<siretart> wow. I thought that one was worked around, since it didn't appear in dapper nor edgty
<siretart> and not before some weeks in feisty
<siretart> :(
<fabbione> siretart: in feisty we did revert the workaround to get the proper fix.. you are running feisty.. live with it.. it's development
<siretart> well, sure, I know
<gezzabob> am I in the right place to chat about an idea Ive been thinking about...  something alone the line of linux (ubuntu) running on a multi core 64 system but in a way that will allow 2xkenels to run at the same time.  Its a weird idea and not one of the norms but it would have its benefits eg better security (each kernel can check the other for rootkits etc) and also things like when one kernel gets updated the other can take contr
<gezzabob> ol keeping the system running while the other restarted etc...  
<siretart> fabbione: would you agree raising severity to critical?
<siretart> i've seen some other critical bug which is about dapper screwing the hardware clock on some dell laptops
<siretart> so I think the impact is about comparable
<gezzabob> im not really a developer as such but look into things like this working on a it call desk at night can get a bit boring and I usually have a lot of spare time to research such ideas
<fabbione> Simira: no, becaue as i just told you is known and we are about to land the proper fix
<fabbione> siretart: ^
<siretart> ah, ok
<gezzabob> I have looked over many programming languages I much prefer asm and c/c++ hence my liking for linux has a whole it promotes free thinking and the environment for development
<gezzabob> ive dabbled with linux from scratch and osdev intresting stuff, been a user now of ubuntu and want to become a bit more active in its development but not sure where to start really
<gezzabob> anybody here point me in direction how I could help out and wheres good to start etc
<gezzabob> any where I can get a look at developing code and pointers how to debug it etc so I can learn more and hopefully be useful
<crimsun> gezzabob: please see the topic.
<gezzabob> yes crimsun sorry if I am being a pain but i am only looking for somewhere to start thats all any suggestions
<gezzabob> oh yes i see now oops sorry didnt spot that earlier  have fun .....:)
<siretart> crimsun: yay. xine-lib 1.1.3 finally now in debian-experimental, following the binary package split
<crimsun> siretart: rockin'
<pirast> Adri2000, thanks
<pirast> crmsun, what's about the security bug in edgy, dapper, breezy?
<pirast> crimsun
<pirast> crimsun, do you also fix them? if not, I have a .debdiff for at least edgy prepared
<crimsun> pirast: if you can generate the debdiffs for those, that would be appreciated.
<crimsun> pirast: keescook would take care of those; attach the debdiffs, please.
<pirast> crimsun, okay, goes to security-review ml then..
<pirast> crimsun, already nominated some releases, but it seems that it has to be reviewed..
<pirast> crimsun, i will assign the ubuntu task to you then, okay?
<crimsun> I'll handle feisty, and I'll approve the others, but please don't assign breezy/dapper/edgy to me [yet] 
<pirast> crimsun, yeah, ill assign the edgy task at least to me..
<pirast> dapper should follow then
<pirast> crimsun, there's another security issue in vlc
<pirast> besides the moab one
<pirast> (let's move to motu chan)
<gortan> ubuntu is a devel
<mdke> sfllaw: any progress on the ubuntu-docs in -proposed? I'd like to get that out of the way, I have another simply update to do soon
<gouchi> Hi
<gouchi> any news about https://blueprints.launchpad.net/ubuntu/+spec/linux-kernel-crash-dump ?
<linuxboy1> re !
<linuxboy1> https://launchpad.net/ubuntu/+bug/81826
<Ubugtu> Malone bug 81826 in Ubuntu "[feisty herd2]  [27.01.2007 i386-desktop]  screen cuts off after the steps battery state and local.rc !" [Undecided,Unconfirmed]  
<bddebian> Heya
<_ion> Hi
<bddebian> Hello _ion
<keescook> crimsun: something went wrong with the builds of acroread in the buildds.  I'm still tracking it down.  I didn't want you to think I'd forgotten it.  :)
<linuxboy1> somebody knows how to use sysprof ?
<linuxboy1> https://launchpad.net/ubuntu/+bug/81826
<Ubugtu> Malone bug 81826 in Ubuntu "[feisty herd2]  [27.01.2007 i386-desktop]  screen cuts off after the steps battery state and local.rc !" [Undecided,Unconfirmed]  
#ubuntu-devel 2007-01-28
<li> hellp
<li> names
<crimsun> keescook: ok
<asdx> hi
<asdx> do i need to install some 32 bit libs for running 32-bit apps on ubuntu
<asdx> firefox for example
<asdx> 32 bit firefox
<asdx> on 64 bit ubuntu
<Mithrandir> use a chroot or a 32 bit installation.  That's much easier.
<Mithrandir> also, your question has nothing to do with ubuntu development, so please take it to #ubuntu.
<cypher1> can anyone please clarify what is the use of /usplash_fifo after usplash has finished its task ??
<cypher1> geser, hi
<cypher1> geser, any idea what is the purpose of /usplash_fifo after the usplash has done its job ?
<mjg59> There isn't one
<cypher1> mjg59, which release are you using
<Hobbsee> cypher1: feisty.  duh?
<cypher1> Hobbsee, no edgy
<Hobbsee> cypher1: as in, the release that mjg59 is running is likely feisty.  likely most of hte other devs too, so they can fix it
<cypher1> Hobbsee, ok .. so it seems got fixed in feisty ? :)
<Hobbsee> cypher1: dunno
<mjg59> It was fixed in edgy
<mjg59> Feel free to delete the file
<cypher1> Hobbsee, i have been looking to work on a usplash spec and had send a mail to ubuntu-devel and ubuntu-devel-discuss and had not seen any reply.. so i belive i can start working on it ?
<Hobbsee> cypher1: well, you're not a MOTU or core dev, so your mail to ubuntu-devel would have been moderated
<cypher1> Hobbsee, ah i remember getting a mail.. but does that mean it is still not approved ?
* Hobbsee shrugs
<Hobbsee> dont know if jono's gone thru the queue - fi it has been approved, it would ahve gone into the archives
<cypher1> Hobbsee, ok thanks
<keescook> hiya pitti
<antibody> hi...I'm using herd2 ...and...everything is ok
<antibody> but there is an option(in recent updates not in cd)
<antibody> that disappeared
<antibody> it's about setting diferent governors
<antibody> (cpufreq) when i'm with ac power and in battery
<Hobbsee> hey pitti, keescook 
<antibody> that option disapeared
<antibody> what can I do?
<keescook> hi Hobbsee 
<Mez> pitti, hey there, quick question
<Mez> do you think it's worth making a security release of xchat/konversation to make them connect by default to freenode via port 8001, therefore avoiding the issues with the DCC exploit
<pitti> hi Hobbsee 
<pitti> Mez: if xchat has an exploitable bug, that should be fixed instead of being worked around
<Hobbsee> pitti: it's the routers that need fixing
<Hobbsee> pitti: and i dont think you can get ubuntu to fix people's routers.
<Mez> pitti: the issue is that when someone sends something, some router firmware bugs out and crashes out the router.
<StevenK> "Searching for crap routers on your network .... Breaking into them .... Patching them .... All done."
<pitti> Mez: ok, please mail me; I need to leave soon, I'm not actually here
<Mez> nothing we can do to fix it other than workaround
<StevenK> Sounds great to me. :-P
<Hobbsee> StevenK: haha
<Mez> StevenK, I wish
<Mez> pitti: will do - the konv patch is already in feisty
<pitti> Mez: sounds like -updates to me
<Mez> pitti: cool ... 
<Mez> argh
<Mez> SRU
<Mez> :(
* Hobbsee watches Mez abandon his plan
<Mez> Hobbsee, lol - they dont like me when I do SRUs
<Hobbsee> Mez: i dont like the complexity of SRU's, so dont file them.  problem solved
* Hobbsee filed one.  it's still not in hte archives yet.
<StevenK> Hobbsee: What's complex about them?
<Hobbsee> StevenK: so many steps to follow, takes so long.  feels like one has to prod every step of the way
<Hobbsee> etc :)
<StevenK> I quite like the process - we aren't taking any chances, and want to be sure it fixes the problem and doesn't cause new ones.
<Mez> StevenK, but for something like changing the port on konv?
<StevenK> Right, but if you make exceptions .....
<StevenK> Hobbsee: Personally, I felt a great sense of accomplishment when wlassistant landed in -updates. :-)
<Hobbsee> hehe :)
<Hobbsee> true
<Hobbsee> StevenK: or making packages installable again
<StevenK> I can see your points, but I don't see the value in creating exceptions for certain conditions, since they could just leave us getting bitten again.
<keescook> pitti: totally awsome retracing, done in my i386 chroot.  I now get warnings like:
<keescook> WARNING: library /usr/local/java/jre1.5.0_10/plugin/i386/ns7/libjavaplugin_oji.so not found in system packages -- ignoring
<pitti> cool!
<keescook> and I also get:
<keescook> WARNING: library /usr/lib/gtk-2.0/2.10.0/engines/libubuntulooks.so not known to firefox 2.0.0.1+0dfsg-0ubuntu2 dependencies (using gtk2-engines-ubuntulooks 0.9.12-2)
<keescook> \o/
<okaratas> hello
<keescook> my goal of doing retracing of other people's crashes is a tiny bit closer.  :)
<okaratas> how are you ubuntu-devel ?
<enrico> I finally found the way to crash nautilus on edgy: place the file http://www.enricozini.org/store/blowUp_F_001.swf in your desktop
<enrico> I reported the bug using reportbug on edgy, I hope it's worked
<enrico> It crashes when it tries to extract a thumbnail for it
<antibody> :/ in herd how can I config cpufreq stuff from gui? the options in power configuration is not there anymore
<sladen> cypher1: it's a bug, in older versions of usplash
<Amaranth> oh good that crap is finally gone from gnome-power-manager
<Amaranth> antibody: the ondemand governor is almost always the one you want
<antibody> 3C3CI know
<okaratas> i open ubuntu networking channel > #ubuntu-network
<okaratas> i channel registered.
<okaratas> mruiz, Mez join channel > #ubuntu-network please :)
<Adri2000> fabbione: could you merge afbinit please? since it's only sparc. http://merges.ubuntu.com/a/afbinit/REPORT
<poningru> cjwatson: ping
<poningru> have a bug in the splash screen of install -> f1 help menu
<poningru> namely they dont correspond to the correct stuff on the boot options
<poningru> i.e live debian-installer/probe/usb=off
<poningru> now the question is should I file it against ubiquity? even though its not, but https://launchpad.net/~ubuntu-installer says I should
<torrrrr> Hi, I set up my network in GUI and the configuration get lost, I set it up in resolv.conf, and it gets overwriten. Any idea?
<mdke> torrrrr: you can try a support channel, such as #ubuntu, #ubuntu+1 or other support resources at http://www.ubuntu.com/support
<torrrrr> mdke: I did try ubuntu, and people ahve tried to help, but nothing helped
<mdke> torrrrr: this channel generally isn't for further support, you have to try other support resources, or you think there's a problem with ubuntu, file a bug at http://bugs.ubuntu.com
#ubuntu-devel 2008-01-21
<linos2> has anyone see an error like this X Error: BadDevice, invalid or uninitialized input device 168
<Hobbsee> linos2: please see the /topic
<Hobbsee> (and if you put that error into google, you'll find the answer, too)
<linos2> Hobbsee, sorry about that..... thank you
<monzie> Hi all
<monzie> What happenned to the libapache-mod-ssl package?
<monzie> It was there in 7.04 but is not in 7.10
<monzie> If it has been taken out for a reason, can someone please tell me how to install mod-ssl on 7.10
<monzie> !ubotu apache
<ubotu> LAMP is an acronym for Linux-Apache-MySQL-PHP. However, the term is often used for setups using alternative but different software, such as Perl or Python instead of PHP, and Postgres instead of MySQL. For help with setting up LAMP on Ubuntu, see  https://help.ubuntu.com/community/ApacheMySQLPHP - See also the Server CD installation process (different in Edgy+)
<StevenK> monzie: Use Apache 2, it includes SSL.
<Mithrandir> monzie: apache 1 is dead and has been for a while; you should have migrated to Apache 2 by now.
<ScottK> monzie: #ubuntu-server is a better place for that kind of question, but StevenK is, as usual, right.
<Mithrandir> morning, StevenK
<StevenK> morning Mithrandir
<monzie> StevenK:  i have Apache2
<StevenK> monzie: Then you don't need libapache-mod-ssl, that's for Apache 1
<Mithrandir> all libapache-* modules are for apache 1
<StevenK> That too.
<monzie> ok
<monzie> StevenK, Mithrandir: http://pastebin.ca/867200 ( that's the output of apache2 -l on my sytem)
<monzie> I cant see SSL there
<StevenK> Then the module isn't enabled.
<StevenK> monzie: Run 'a2enmod ssl'
<Mithrandir> : tfheen@xoog ~ > ldd =apache2 | grep ssl
<Mithrandir>         libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00007fb5ae419000)
<monzie> StevenK: thanks!
<StevenK> monzie: No problem.
<monzie> StevenK: I am sure there was a a reason for not having a "libapache2-mod-ssl" I guess
<StevenK> Yes, because it's included in the Apache 2 package.
<monzie> ok
<monzie> Thanks room!
<warp10> Good morning
 * Mithrandir idly wonders when ooo-l10n is going to be fixed.
<carlos> pitti: good morning
<pitti> hey carlos, good morning
<carlos> pitti: I wonder whether you managed to get .deb packages for Hardy language packs
<carlos> or did you delegate it already ?
<thegodfather> morning pitti
<pitti> carlos: I just got jtv's /msg that they are ready
<pitti> carlos: I think I'll sit down with Arne today and show him how to build them
<carlos> ok, I thought you had your script executed automatically ;-)
<carlos> pitti: I will need to ask you to remove all lang_country directories again as we did with latest Gutsy lang pack....
<pitti> carlos: oh, thanks for the warning
<carlos> pitti: btw, full Hardy export took only 15 hours 20 minutes
<carlos> pitti: so we don't need to wait 2-3 days to get one
<carlos> anymore
<pitti> \o/
<carlos> pitti: that's using production, no need to use a mirror so we get latest information available in Launchpad
<carlos> pitti: btw, we are going to announce Hardy translations opening today and I wonder whether we could announce also that starting later today or tomorrow we would have language packs updated twice per week
<pitti> carlos: yes, please do announce it; I'll either sit down with Arne today or do it myself
<pitti> carlos: but it'll be a few hours/a day, since they take quite some time to build
<carlos> ok, thank you
<carlos> so we will say in next days
<carlos> "in next days"
<carlos> pitti: thanks for handling this
<Robot101> "in the next few days" would be more idiomatic :)
<carlos> Robot101: thanks ;-)
<geser> good morning
<geser> pitti: Hi, as you merged debhelper in the past have you time to review bug #184545?
<ubotu> Launchpad bug 184545 in debhelper "[Merge] debhelper (6.0.2ubuntu1)" [Undecided,New] https://launchpad.net/bugs/184545
<pitti> geser: I am fine to do it, I just don't know when I'll be able to; can you please subscribe me, so that I'll get a bug mail?
<geser> pitti: done and thanks
<geser> pitti: please give-back: haskell-cgi haskell-glut haskell-openal hslogger. Thanks
<pitti> geser: done
<dholbach> thekorn, bdmurray: could it be that pylpbugs broke?
<dholbach> thekorn, bdmurray: http://paste.ubuntu.com/3743/
<thekorn> dholbach, hi, will have a look at this during my lunch-break
<dholbach> thekorn: you ROCK
<LucidFox> Is https://wiki.ubuntu.com/No-Mono-by-Default relevant anymore?
<ogra> LucidFox, look at the LP spec page, it should tell you the status
<mjg59> LucidFox: What do you mean by relevant?
<mjg59> It's not an approved spec
<ogra> (if it was even approved to be implemented etc)
<mjg59> So it's as relevant as it was when it was written (arguably not very)
<LucidFox> it says review
<LucidFox> The issue is, someone is asserting that Mono will be removed from the default installation, and points me to that page
<ogra> thats nonsense
<LucidFox> I want to repel his argument
<ogra> we just moved f-spot to be the default photo app
<ogra> would be silly to drop mono *now* :)
<ogra> mjg59, do you plan to drop by this week in th eoffice ?
<mjg59> ogra: With luck, on Wednesday
<ogra> cool !
<keescook> mjg59: saaay... is there a way to access the CPU thermal sensors on the core 2 duo/quad cpus?  (I don't seem to have an ACPI output for it on my desktop)
<mjg59> keescook: Hm. I think someone wrote a driver to do that.
<keescook> mjg59: ah, have an pointers to it?  I've been having a bad time googling for such things.  :P
<mjg59> Yeah, having some trouble finding it
<mjg59> keescook: http://www.lm-sensors.org/wiki/Devices suggests lm-sensors has one (coretemp)
<keescook> ah!  I thought lm sensors was deprecated in favor of the acpi goo
<mjg59> If acpi doesn't provide it, deprecation isn't helpful :)
<keescook> well, heh, yeah.  :)
<mjg59> We seem to ship a version of coretemp
<mjg59> But it doesn't /seem/ to bind for me
<mjg59> Oh, no, wait
<mjg59> It just doesn't print anything to dmsg - I've got stuff in /sys/devices/platform
<keescook> ah-ha!
<keescook> one for each cpu.  :)  hmmm... which actually has the current value...
<mjg59> temp1_input
<Company> it works on my macbook
<Company> with lmsensors
<keescook> mjg59: cool, thanks.  "sensors" reports them all happily. whee
<stgraber> moin
<monzie> Hi all
<monzie> how do i generated Apache certificates in Ubuntu 7.10?
<monzie> apparently the "apache2-ssl-certificate" packages has been taken out
<monzie> I am following https://help.ubuntu.com/community/forum/server/apache2/SSL
<thekorn_> dholbach: this error is weird, I can't reproduce it,
<thekorn_> which version of py-lp-bugs are you using, do you have local (uncommited) changes in sponsoring or py-lp-bugs?
<dholbach> thekorn_:  no, none :-/
<ganesh> i installed ubiquity & created a live cd but it is not installing from that cd , help me to resolve my problem
<ganesh> ln-, yeah it a development question
 * sistpoty|work is away: coffee break
<calc> any ubuntustudio people here? i forgot who was nagging me about OOo before
<calc> i have a question for them when/if they show up
<zul> pitti: can we get xen-3.2 out of new?
<pitti> zul: yes, it's just a matter of finding some time to attack NEW
<_MMA_> calc: I'm in whatever channel you wanna talk in. :P
<zul> pitti: great, no problem
<TheMuso> calc: yes, I am around.
<tbf> what's the rationale behind installing .la files?
<tbf> they only cause trouble?
<tbf> s/trouble?/trouble!/
<Chipzz> tbf: I wouldn't say everyone here is positive about installing .la files (ie some/a lot of people here share your opinion)
<tbf> Chipzz: well, that's why i ask for the rationale
<seb128> you need those to do static building
<slangasek> not if you have .pc files
<seb128> right
<slangasek> tbf: the sole rationale for installing .la files is that they facilitate static linking using metadata that's available in the same directory as the lib itself, without having to centrally register the information (i.e., with pkg-config)
<slangasek> tbf: IMHO this doesn't outweigh the various disadvantages of installing them; so for the most part I would say there's no "rationale" for installing them in Ubuntu, they're just installed because this is what libtool does by default
<Chipzz> tbf: oe of the problems with .la files is that if you wanted to get rid of them, you would have to do so top-down
<tbf> seb128: the only guys how need static linking a propritary software vendors....
<Chipzz> *one
<tbf> seb128: and most of the time even they cannot make use of it, since the libs they want to link are LGPL
<Mithrandir> tbf: no, that is wrong.
<Mithrandir> like, sash is a perfectly good example of a tool that needs to be statically linked.
<tbf> Mithrandir: ok, one additional case exists: boot imagges
<Mithrandir> why would boot images need to be statically linked?
<tbf> Mithrandir: but for the entire gnome stack for instance it is pointless to link statically
<tbf> Mithrandir: 'cause you can strip unneeded symbols
<tbf> Mithrandir: without dynamic linking you need the entire libc, with static linking you just need space for the code you really use
<Mithrandir> tbf: I know how static linking works.  I was contradicting your claim that static linking is only useful for proprietary software authors.
<tbf> hmm... maybe want some libtool switch "no, no f***ing .la file, please"
<seb128> tbf: stop using libtool if you don't need it?
<tbf> seb128: were is the camera?
<seb128> ?
<tbf> seb128: well, from your words i guess this is a hidden camera show
<seb128> tbf: that's what Keybuk suggested previous time there was a similar discussion on this chan, if you don't want la files you don't need to use libtool there is easier way to get a library built
<tbf> seb128: libtool does some useful stuff, and the only result of not using it, are many bug reports for your gnome packages
<tbf> "migrate to libtool please"
<tbf> seb128: well, but for gnome packages, libtool's la files don't make any sense, as gnome files have that information in their .pc files
<tbf> s/gnome files/gnome libraries/
<seb128> tbf: so why not stop building those?
<tbf> seb128: the pc files?
<seb128> no the la
<tbf> seb128: well, stopping to build .la files is exactly what i want
<ganesh> i installed ubiquity & created a live cd but it is not installing from that cd , help me to resolve my problem
<tbf> seb128: i want to tell libtool "do not build .la files for this library"
<seb128> tbf: you might get the "stop using libtool if you don't need it" reply
<tbf> seb128: libtool knows how to build shared libraries on solaris and with mingw32 for instance...
<tbf> seb128: also automake works much better with libtool, than without
<seb128> I don't know enough about libtool to discuss that
<Keybuk> tbf: don't use libtool
<Keybuk> for gnome packages, pkg-config provides all the answers
<Keybuk> libtool is unnecessary
<tbf> Keybuk: the opensolaris guys will disagree, for instance
<Keybuk> tbf: but you just said you don't care about portability
 * sistpoty|work is back
<tbf> Keybuk: how that?
<Keybuk> you *need* .la files on solaris
<Keybuk> if you delete them, you're declaring that you only care about Linux
<tbf> nice
<Keybuk> since you're using knowledge about the Linux dynamic link loader
<tbf> Keybuk: so how can i rid of them on linux, please?
<Keybuk> tbf: don't use libtool
<tbf> Keybuk: why do you try to be an idiot?
<Keybuk> tbf: ?  I'm not being an idiot
<tbf> Keybuk: i never said you are one.
<Keybuk> <tbf> Keybuk: why do you try to be an idiot?
<Spads> Keybuk: why do you *fail* at being an idiot?
<tbf> Keybuk: trying is different from being
<Keybuk> tbf: http://www.ubuntu.com/community/conduct
<Keybuk> tbf: please read that, carefully
<tbf> Keybuk: guess you also should read it
<ganesh> i installed ubiquity & created a live cd but it is not installing from that cd , help me to resolve my problem
<Mithrandir> tbf: it would help if you stopped coming across as so agressive.
<tbf> Keybuk: repeating "don't use libtool" really doesn't help, if the person you talk to repeatedly say, that he needs most features of libtool
<Mithrandir> ganesh: you're off-topic for this channel; please take it elsewhere (#ubuntu-installer, possibly)
<Keybuk> tbf: libtool has one feature
<Keybuk> it provides a common interface to shared library generation across all platforms
<Keybuk> you've said you do not want that feature
<Keybuk> ergo you do not want to use libtool
<Keybuk> libtool does *nothing* else
<Keybuk> if you remove .la files, you are deliberately breaking libtool and attempting to circumvent it
<Keybuk> at which point, why use it at all?
<ganesh> Mithrandir, ok
<Mithrandir> Keybuk: hmm?  Doesn't it track dependencies between static .a libraries and help you link them into a static object?
<tbf> Keybuk: group pressure?
<Keybuk> Mithrandir: only if you use .la files
<Keybuk> as soon as you delete .la files, you can no longer do that
<Chipzz> Keybuk: your argument is flawed; you do want the common interface, but you do not actually need the .la files for obtaining that goal *on linux*, just on *other platforms*
<Keybuk> at which point, why use libtool at all
<Chipzz> but since ubuntu is linux you don't need the .la files
<Keybuk> Chipzz: but as Mithrandir points out, you actually *do* need them for that goal
<Keybuk> otherwise you can't do static library linking
<Chipzz> Keybuk: afaik not on linux; only on other platforms lacking certain features
<Mithrandir> and then it comes down to whether we actually want to support people linking, say, gtk+ statically.
<Keybuk> Chipzz: yes, you do
<tbf> Keybuk: but why should i care about artifacts for building __static__ libraries, if i want a tool for building __shared__ libraries?
<Keybuk> tbf: gcc is perfectly capable of building shared libraries
<tbf> Keybuk: and why should i care about dependency tracking information, if i have a more reliable variant?
<Mithrandir> tbf: libtool know what magic knobs you need to twiddle on different platforms for building shared libraries too.
<Keybuk> tbf: so why use libtool if you have a more reliable variant?
<tbf> Keybuk: well, and libtool doesn't only do dependency tracking. it also knows which commands to invoke with which arguments
<Keybuk> tbf: so do you, since you know how the the linker works
<Keybuk> and libtool's knowledge depends on it having its control files
<Keybuk> as soon as you take away its control files, libtool's own commands it invokes don't function properly
<tbf> Keybuk: well, and it takes care about injecting --rpath information, so you can use your shared libs from your source dir...
<Keybuk> it just happens that they function "well enough"
<Keybuk> tbf: that breaks if you remove .la files
<tbf> Keybuk: so libtool does alot of useful stuff
<Keybuk> tbf: and it cannot do *any* of that, if you remove the .la files
<Keybuk> ergo : remove the .la files => why are you using libtool?
<Mithrandir> I'm wondering if we could rip out the dependency tracking bits of libtool and have it use pkg-config for that, while retaining its knowledge on compiler flags to build shared libs.
<tbf> well, then we are at the point that libtool most probably is seriously broken....
<Keybuk> as soon as you remove .la files, libtool becomes nothing more than a very large, very complicated shell script that expands to a gcc invocation near-identical to the libtool invocation
<Keybuk> (on Linux)
<tbf> ....since it regularly uses the wrong .la files
<Keybuk> tbf: it never uses the wrong .la files ;)  what happens is that libtool's generic interface requires you, when you rebuild a library, to rebuild all libraries and programs that depend on it
<Keybuk> it happens that Linux's library implementation doesn't require this
<Keybuk> but since many library implementations *do* require this, libtool requires it
<tbf> Keybuk: i do that, i do that
<tbf> Keybuk: nevertheless it regularly grabs .la files from /usr/lib, instead of whatever-dir i asked it to use
<Keybuk> tbf: next time it does it, please feel free to tar up the image, and grab me on IRC -- I'll happily help debug it for you
<Chipzz> Keybuk: but, often it's nogt a matter of you wanting or not wanting libtool, it's a matter of *upstream* wanting libtool; so you have no say in it
<Keybuk> Chipzz: but we already change upstream by removing .la files
<Keybuk> upstream probably use libtool because automake depends on it for libraries
<Chipzz> Keybuk: yes, but that's related to what Mithrandir said:
<Chipzz> 15:07 < Mithrandir> tbf: libtool know what magic knobs you need to twiddle on different platforms for building shared libraries too.
<Keybuk> but we don't need those knobs
<Chipzz> Keybuk: often, libtool is used for *that* purpose, and the things you say are actuall irrelevant
<Keybuk> it's a trivial matter to replace the ltmain.sh in source packages with something that only has the magic knobs for ubuntu
<Keybuk> (we replace it most of the time anyway, along with config.guess and config.sub -- we just replace it with the full libtool one)
<Chipzz> Keybuk: upstream does, for portability to other platforms we don't care about
<Keybuk> then we could cut libtool out entirely
<Keybuk> automake would still work, things would get built relying on pkg-config, etc.
<Mithrandir> I'm somewhat wondering what problem you're trying to solve then.
<Mithrandir> apart from "libtool is a pile of spaghetti and I want tuna for lunch!"
<Keybuk> there's tuna in libtool
<Chipzz> Keybuk: the matter of fact is very simple IMO; libtool is often used because of the relative convenience (of not having to figure out 10 gcc switches) of the automake/libtool combo, and for portability; and most often not for the things you mention
<Hobbsee> mmm...tuna
<Mithrandir> Keybuk: there are also bits of metal and brains in libtool.
<Keybuk> Chipzz: except those switches rely on the existance of a file that packagers subsequently delete
<Keybuk> libtool *really* assumes it has a .la file
<Keybuk> and its behaviour without one is quite undefined in many circumstances
<Mithrandir> Keybuk: all of them at varying degrees of radioactivity, of course.
<Chipzz> but it still works without?
<Keybuk> no, it really breaks
<Keybuk> it just happens to work on the buildds without
<Keybuk> for example, when you don't ship a .la file in /usr/lib, a .la file *anywhere else in the path* will trump it
<Keybuk> and you'll end up linking with the wrong libraries
<Keybuk> so builds work on the buildd, since they're fresh
<tbf> so how do i get back the .la files, after agressively erasing them from /usr/lib?
<Chipzz> unless I'm grossly mistaken, I have build numerous libs in the past even with the .la files it depended on gone
<Keybuk> but fail on people's machines
<slangasek> Keybuk: er, but /usr/lib is normally the last dir in the lib search path anyway?
<Mithrandir> tbf: reinstall the packages providing them.
<slangasek> so if you have .la files elsewhere in the path, that's breaking things anyway
<Chipzz> Keybuk: um yeah, but users shouldn't really be building from source anyway
<tbf> Mithrandir: any magic for doing this automatically?
<Keybuk> slangasek: not at all
<aquo> i had a look at /var/log/dpkg.log and many lines are printed multiple times? is this a bug?
<Keybuk> thanks to multi-arch weirdness, it's somewhere in the middle (it just happens to be specifically at the end too)
<Keybuk> I've demonstrated the failures many times
<Keybuk> and I've argued repeatedly about this
<Keybuk> and people still ignore me, and still come to me with their problems afterwards
<Keybuk> so meh
<Mithrandir> tbf: cd /var/lib/dpkg/info; grep -lr la$ *.list | sed s/.list$//| xargs sudo apt-get --reinstall install
<Mithrandir> tbf: untested, of course.
<tbf> Mithrandir: looks reasonable - thank's alot
<slangasek> Keybuk: not me, I just concatenate invectives and will libtool to implode
<Mithrandir> possibly make that grep pattern \\.la$
<Keybuk> I long ago came to the conclusion that libtool is the wrong solution
<tbf> Mithrandir: already did that ;-)
<Keybuk> and lost the will to care about writing the right solution ;)
<slangasek> Keybuk: speaking of which, what would you recommend for a pair of libtool "module" .las where one requires symbols from the other, using the current sensible-libltdl behavior of RTLD_LOCAL?
<slangasek> Keybuk: ... and the module .la doesn't have a name beginning with "lib"? :)
<Keybuk> can't A needed B?
<slangasek> (this apparently causes libtool to go stark raving at install time, and try to convert the .la file's path into a -l option)
<Keybuk> foo_la_LDADD = bar.la
<Keybuk> prog_LIBS = foo.la
<Keybuk> doesn't that work?
<slangasek> "prog_LIBS"?  that sounds like it's the wrong answer for a dlopen()ed module?
<Keybuk> oh, dlopen
<Keybuk> that should still work though?
<slangasek> anyway, I suspect that doesn't work; from what I see, libtool says "oh, you linked with this thing called bar.la, we're relinking, let's turn that into a -l option and look for -lbar"
<slangasek> the best workaround I've found is to provide a libbar.$mumble symlink
<slangasek> (the naming scheme for the modules is set upstream, well-established and documented)
<TheMuso> evand: for q quick start, you can find resources for developers on http://live.gnome.org/Accessibility
<slangasek> calc: hoi, what news on ooo-l10n?
<evand> thanks TheMuso!
<calc> slangasek: its building... hasn't failed yet so that is good news
<calc> slangasek: i remembered the fact we change some i18n stuff in ubuntu so i removed that patch and it seems to be working
<calc> slangasek: so if it does work i will have to examine the patch closer to find what it is breaking
 * calc needs a bigger box for OOo compiling
<\sh_away> seb128, did you read #184607 and bug #184176? would you like to fix gconf ? :)
<ubotu> Launchpad bug 184176 in gnucash "[hardy]Gnucash fails to build with libgconf2-dev 2.21.1-0ubuntu1" [Medium,New] https://launchpad.net/bugs/184176
<\sh_away> bug #184607
<ubotu> Launchpad bug 184607 in gconf "pkgconfig file says "Requires glib" instead of glib-2.0" [Undecided,New] https://launchpad.net/bugs/184607
<calc> slangasek: is it safe for me to upload once i get it resolved (hopefully later today) or is there anything it would block thats important?
<seb128> \sh: no I didn't read it yet looking now
<slangasek> calc: er, I presume that once you have it fixed you *should* upload, since the lack of up-to-date l10n packages leaves ooo metapackage uninstallable and makes the hardy out-of-date list quite horrid :)
<calc> slangasek: yea i was planning on it, but it will load a buildd for a while so wanted to make sure nothing else is pressing in the buildd queue right now
<slangasek> ah, not from my POV
<calc> ok
<calc> i'll get it uploaded today then assuming it finishes build i should be able to resolve the bad patch issue fairly quickly (i hope)
<bryce_> MacSlow: I didn't find anything in the -intel git log
<MacSlow> bryce_ ok so we might get a point in the xorg-crowd for fixing that :)
<bryce_> :-)
<bryce_> fwiw, xrandr -o 1 still locks up X  :-P
<Hobbsee> MacSlow: fixing what?  :)
<MacSlow> Hobbsee, https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/175774
<ubotu> Launchpad bug 175774 in xserver-xorg-video-intel "[hardy] Enabling "Normal" effects produces badly drawn window shadows." [Critical,Confirmed]
<Hobbsee> MacSlow: nice!
<bryce_> MacSlow: ok I've built a test deb for these changes
<bryce_> brb
 * calc noticed that his build hasn't actually reached where it failed before
<slangasek> TheMuso: you may want to merge ubuntu.hardy seed changes into ubuntustudio change; pwlib had an ABI change that ekiga has just been rebuilt for, the seeding of the plugin packages needs to be updated to match
<_MMA_> slangasek: joejaxx can also handle this. I'll make sure he knows.
<slangasek> _MMA_: ok, cheers
<slangasek> _MMA_: picking on TheMuso because I know what timezone he's currently in :)
<_MMA_> Thanx for the heads up.
<_MMA_> slangasek: hehe. :P
<TheMuso> Actually, i need to talk to joejaxx about the way he is merging. He is not using bzr merge, which IMO he should be.
<slangasek> heh
<_MMA_> Oh ouch.
<TheMuso> As it then shows parent commits from the ubuntu seeds.
 * slangasek nods
<TheMuso> slangasek: Picking on me? it seems like other people are more jetlagged than me, and they arrived earlier than I, and didn't have as far to go. :)
<_MMA_> TheMuso: Well if you feel like kickin' ass and taking names while you're in London rock on. \m/ We should still talk to Joe.
<TheMuso> _MMA_: Yes, I agree.
<TheMuso> But, I won't rule out feeling tired some time this evening.
<_MMA_> TheMuso: Sure.
<slangasek> TheMuso: right, "picking on you" because I know you're in my timezone.  and in walking range.
<TheMuso> Yes there is truth in that.
<calc> i found that sleeping pills seem to somewhat help with jetlag
<TheMuso> usually only takes me 1/2 nights, and I'm right.
<TheMuso> of good sleep.
 * Hobbsee finds not travelling the most effective form of jetlag avoidance
<calc> though i didn't experience any nighttime kookiness
<calc> Hobbsee: ;P
<TheMuso> I would rather not use anything to artificially simulate the boy to either feel sleepy or more awake.
<TheMuso> stimulate the body
<calc> http://en.wikipedia.org/wiki/Crook_and_Ladder
<TheMuso> I do have the fact that I sleep deeply on my side.
<Hobbsee> calc: :)
<Keybuk> Riddell: KDE 4 to have a six-monthly release schedule?
<calc> i obviously still have jetlag as i have a strong desire to go back to the hotel and sleep :-\
<calc> and all the caffeine doesn't seem to help much
<Riddell> Keybuk: that's the rough plan
<calc> Riddell: aligned with Gnome?
<Riddell> Keybuk: but 4.1 still has some must have features so it could slip if they do
<Riddell> calc: goodness no
<Keybuk> Riddell: is there any particular reason, apart from sheer bloody-mindedness, that they didn't pick the same rough dates as GNOME? ;)
<calc> Keybuk: because KDE != Gnome? ;-)
<calc> and to cause Ubuntu pain
<Keybuk> it isn't just Ubuntu though
<Keybuk> it causes every distribution pain
<TheMuso> I've noticed the amount of soft drink that is consumed around here. Its scary.
<Riddell> well 4.0 happenes to come out in january so that sets the current schedule
<Keybuk> TheMuso: I'm trying to move everyone onto jelly bellys
<TheMuso> Keybuk: Oh yeah. Thats even better.
<Keybuk> TheMuso: would you like some?
<Riddell> calc: january and july would be a perfectly convenient schedule for us
<calc> Riddell: maybe they could scedule 4.1 to come out in Sept then to give them extra time ;)
<Riddell> calc: that might happen in its own course
<Riddell> Keybuk: where are you reading this anyway?
<TheMuso> Keybuk: Thanks for the offer, bt no thanks. I am trying to keep from using artificial/sugar stimulents.
<Keybuk> Riddell: planet ubuntu, of course
<calc> ok its past the failure point for ooo l10n (i think) so that is a good sign :)
<TheMuso> calc: Do you have a beefy laptop, or are you building this on a fast home box?
<calc> TheMuso: both, but i am building on my home box
<TheMuso> right
<calc> TheMuso: my laptop is core2duo 1.7GHz 4gb ram, my home machine is core2duo 2.8GHz 2GB ram
<TheMuso> Ah ok.
<calc> TheMuso: i already had ccache primed on my home system so i just used that
<TheMuso> ah
<calc> even with ccache its taking 5hr+ for the l10n build though
<Keybuk> I built oo.o once
<Keybuk> it took >5hr just for "apt-get build-dep" :)
<calc> Keybuk: hehe
<TheMuso> Keybuk: You were obviously somewhere with little/no bandwidth. :p
<calc> TheMuso: ooo requires a LOT
<TheMuso> calc: I doubt that not.
<calc> though it wouldn't take 5hr at the office to download its build-deps
<Keybuk> calc: one would hope not
<calc> is it normal for a system to not allow access for the ~ 3300MB - 4096MB range?
<calc> i have a i945 laptop and wasn't sure if it was a chipset or bios issue, at least when running x86_64
<calc> in ia32 it probably is a issue due to needing space for pci map
<RainCT> mvo: ping :)
<mvo> RainCT: pong
<RainCT> mvo: before I upload fusion-icon (to Debian).. is it's priority extra for some reason or did you just forget to change it? :P
<mvo> RainCT: I think I forgot to change it (I can't remember any particular reason)
<crimsun> is Ted Gould present at the sprint?
<ogra1> crimsun, yup
<calc> crimsun: need him?
<crimsun> calc: yes please, concerning cleanup-audio-jumble
<calc> crimsun: he said his irc client is currently broken but he would try to get online
<crimsun> calc: many thanks!
<calc> crimsun: you might try emailing him until then
<calc> yipee! i got l10n debs being spit out
<calc> now i just need to look through the diff to find the offending code
<TheMuso> heh
<TheMuso> is that for amd64, or i386?
<calc> its being compiled on amd64 but is indep
<calc> it looks like my patch didn't do anything
<calc> so i am going to reapply it, maybe i forgot to regenerate ooo-build afterwards when i did it before
<calc> i don't see how this patch could have done anything to cause it to fail where it did
<TheMuso> Oh fun.
<calc> but it is the only patch I made that I know of to the language stuff that isn't in debian which worked out of the box
<TheMuso> Right.
<calc> slangasek: so if you didn't see above i have made ooo l10n build but after looking at the patch I left out I am not sure why leaving out the patch helped, so i am going to try rebuilding with using the patch and regenerating the ooo-build build stuff
<calc> slangasek: i wonder if it worked because of the aotcompile file change
<calc> slangasek: since iirc language stuff is threaded it could have failed in a weird way due to running out of memory
<agd5f> are there known issues with hardy and AMD64?  I've gotten a kernel panic with every image I've tried?
<calc> running the full build if this works i will upload (probably in 5hr or so
<pochu> soren: may I ask you to ACK bug 176007?
<ubotu> Launchpad bug 176007 in vinagre "Please sponsor vinagre_0.4 into Hardy" [Wishlist,New] https://launchpad.net/bugs/176007
 * seb128 kicks tracker
<seb128> eating 100% cpu four hours and the applet has no label about it being indexing or anything
 * pochu kicks seb128 :)
<seb128> pochu: heh
<seb128> what did I do?
<pochu> kick tracker? ;)
<seb128> its eating all the cpu without a good reason
<pochu> seb128: tracker-status?
<seb128> that deservers some good kicking
<seb128> that hangs
<seb128> and the applet has no label or count or anything
<pochu> That's odd.
<pochu> Do you mean the progress bar isn't there?
<mjg59> It means the daemon has stopped responding
<pochu> Here it works quite well... after I told it not to index ~/dev and ~/tmp
<seb128> #8  0xb7ddb4d7 in sqlite3InvokeBusyHandler () from /usr/lib/libsqlite3.so.0
<mjg59> seb128: What about the other threads?
<seb128> mjg59: lack of debug packages I'll try to get debug backtrace
<seb128> one thread has enough informations to indicate it was indexing INBOX
<seb128> and there is 2 threads with libsqlite functions
<seb128> one being stopped on sleep apparently
<mjg59> Hm
<seb128> oh
<seb128> what my be an interesting detail is that my laptop is running on battery at the moment
<seb128> so it should not start and eat batteries
<seb128> what might be
<mjg59> Yeah
<soren> pochu: Sure thing!
<soren> pochu: Done.
<pochu> seb128: It doesn't do initial index on battery, but that's not the initial index I guess...
<pochu> soren: thanks :)
<mjg59> pochu: You can disable both types individually
<pochu> seb128: You are using evo right? There's this crash in LP, although it doesn't mention libsqlite: bug 180220
<ubotu> Launchpad bug 180220 in tracker "trackerd crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/180220
<seb128> pochu: it should do nothing on battery
<_MMA_> seb128: I added my xsession-errors to bug 183199. Might give you some idea. Hopefully I can track down more details with crimsun later.
<seb128> pochu: yes
<ubotu> Launchpad bug 183199 in gnome-control-center "System sounds aren't being played in Hardy." [Undecided,New] https://launchpad.net/bugs/183199
<pochu> mjg59: Right. But do we disable both by default? I thought only initial index was deactivated.
<mjg59> Yes
<pochu> Ok, sorry then.
<crimsun> _MMA_: (pointer for later:  check capplets/sound/ and libsounds/)
<_MMA_> k
<seb128> crimsun, _MMA_: I've no pulse running so it might use aplay
<mjg59> seb128: No, I don't think that follows
<seb128> _MMA_: do you have pulsesomething running?
<mjg59> seb128: Even if I'm on battery, if I save a new file I want it indexed
<seb128> mjg59: what?
<seb128> mjg59: depending how much indexing takes
<mjg59> seb128: Per-file, it should be very little
<seb128> right
<mjg59> The hard drive will be spun up anyway
 * _MMA_ fires up the Hardy test box.
<seb128> mjg59: not sure how much indexing a mail takes but you can easily have hundred of mails there
<seb128> brb
<seb128> restarting my session
<seb128> _MMA_: do you have pulseaudio-esound-compat installed?
<seb128> does installing it and restarting your session makes any difference?
 * _MMA_ looks.
<_MMA_> pulseaudio is running.
<_MMA_> And we mirrored what Ubuntu had in its seed list sound-wise.
<seb128> does paplay /usr/share/sounds/login.wav work correctly?
<Keybuk> bryce: err, I've just had my external screen blank
<Keybuk> how do I get it back?
<_MMA_> seb128: pulseaudio-esound-compat is installed. paplay /usr/share/sounds/login.wav does yield sound. Playing that same file through gnome-sound-properties does not.
<bryce_> Keybuk: restart X maybe?
<Keybuk> bryce_: a less drastic solution? :p
<bryce_> hehe
<bryce_> Keybuk: there might be an xrandr incantation to bring it back
<bryce_> Keybuk: any clues in Xorg.0.log?
<Keybuk> no
<Keybuk> at least nothing I understand
<agd5f> bryce_: you know of any AMD64 issues with hardy?  I've get to find an image that boots.  stuff scrolls by pretty quick, but looks like something about the ioscheduler then I get a panic
<bryce_> agd5f: hmm, I've not tested on my amd64 system lately
<selckin> mine hanged somewhere after hd detection without any messages, started working when i used /dev in root= instead of UID
<bryce_> agd5f: have you tried the 32bit x86 images or just 64bit?
<agd5f> just 64 bit, I ran out of blank cds :)
<bryce_> agd5f: which hardy version(s) have you tested on?
<agd5f> alpha3 and yesterday's snapshot
<bryce_> ok, that's a -4 kernel
<seb128> _MMA_: I figured what is wrong
<bryce_> can you send us a stack trace or dump?  (photo maybe?)
<agd5f> yeah
<agd5f> bryce_: I'll file a bug
<seb128> crimsun, _MMA_: that's an esound bug
<bryce_> agd5f: cool.  I'm sitting next to tim gardener, and he said he'll take a look
<bryce_> brb, testing a 965 compiz fix...
<BenderUnit22> ~/clear
<_MMA_> seb128: Ok. Hopefully crimsun and I can sort it out.
<_MMA_> seb128: I did get an odd issue when searching for pulseaudio-esound-compat in Synaptic. (not related to the package.) Synaptic completely locked until I killed update manager. I've never seen that before.
<seb128> _MMA_: the bug is an esound one, I'm going to look at fixing it now
<seb128> _MMA_: it's using .esd and not .esd-1000
<_MMA_> seb128: Awesome. Thanx. Let me know if I can help.
<seb128> _MMA_: you are welcome
 * _MMA_ sends TheMuso to give Seb a hug. (If Sebastian is in London that is) :P
<TheMuso> lol
<_MMA_> ;)
<slangasek> pitti: is the gnome-keyring-manager -> seahorse seed change ok for upload?
<\sh> doko, reping crystalspace ... again the question you mentioned "configure --without-java" in your last upload..but it's commented...
<doko> \sh: hmm, can't remember ... maybe just do what debian does
<\sh> doko, k..:)
<pitti> slangasek: yes, it is
<slangasek> pitti: ok, ubuntu-meta uploaded then
<pitti> yay
<agd5f> bryce: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/184883
<ubotu> Launchpad bug 184883 in linux "hardy AMD64 kernel panic on boot" [Undecided,New]
<agd5f> bryce: looks like a bios issue
<agd5f> I hardcoded the ram voltage and now it seems to boot ok
<crimsun> _MMA_: didn't you test the /tmp/.esd symlink I suggested several days ago?
<_MMA_> crimsun: I did. Lemmie see what I told you.
<crimsun> _MMA_: did you log out and back in after creating the symlink (I don't see why that would have been necessary)?
<_MMA_> crimsun: After doing that the sounds didnt play but I got "(gnome-sound-properties:6093): Gnome-WARNING **; error caching sample <-1>!"
<pochu> soren: btw, and in case you missed it, I attached a debdiff to bug 183169 ;) I've of course tested it with vinagre 0.4, and it solves the issue (for "localhost:1" and for "Ã±lkjadf~@|#")
<ubotu> Launchpad bug 183169 in gtk-vnc "Crash if hostname contains invalid characters" [Medium,Confirmed] https://launchpad.net/bugs/183169
<basy> Are there any installers for man pages? I need to install man pages for develop with openGL, i have mangl.tar.Z and there are *html and *3gl manuals, any idea how to install that?
<basy> plz
<Seveas> basy, this is not a support channel
<basy> <Seveas> and which one is for support?
<Seveas> basy, #ubuntu
<basy> i ll try  there sorry
<Keybuk> ...we could always just remove openoffice from the seeds and replace it with abiword and gnumeric...
<evand> seconded
<LaserJock> gnumeric is pretty darn sweet, at least from my experience of scientific spreadsheet use
<mjg59> gnumeric is fine. Abiword, less so.
<LaserJock> I agree
<LaserJock> although I've had Abiword do a little better with some things
<LaserJock> as far as .doc compatibility
<LaserJock> my only personal issue with s/openoffice/abiword+gnumeric/ is having an Impress replacement
<Keybuk> mjg59: the abiword in gutsy/hardy is nice
<Keybuk> I've found it much nicer for writing in
<mjg59> It's nice, but it's not very /useful/
<mjg59> At least, for the common case of dealing with .docs
<Keybuk> yeah, the file format stuff maybe not
<mjg59> (Yes, I know this is a ridiculously hard problem)
<Keybuk> but openoffice is less useful since it's not INSTALLABLE :)
<LaserJock> mjg59: have you seen any tests on that? I'd be interested in what abiword fails with regarding dealing with .docs
<johanbr> In my limited experience, abiword handles .doc files fine. Although I never receive very complex documents...
<mjg59> LaserJock: They look different to when I open them in OpenOffice :)
<LaserJock> mjg59: yes, although in my experience Abiword actually looked closer to Word than OpenOffice did
<mjg59> Hm. Mine's the opposite
<LaserJock> but I only have a limited case
<mjg59> But, as I said, this is hard
<LaserJock> I have a book chapter I'm working on, so it's decently complicated but no graphics, just text
<LaserJock> the only thing I really saw that Abiword failed at was in using multiple fonts at the same time, abiword just picked one whereas OO.o kept the font list
<ScottK2> IMO, .doc compatibility is a must.
<LaserJock> ScottK2: yeah, but it's kinda subjective, IMO, which is the problem
<LaserJock> it'd be nice to have a systematic way of evaluating
<ScottK2> OOO 2.3 has gotten it to a point where I almost never have a problem.
#ubuntu-devel 2008-01-22
<LaserJock> ScottK: yeah, I have a much easier time with .doc files than .pdf
<LaserJock> although I did get a nice macro'ized doc file the other day and sent it back and the person said that it was 75 pages of junk ;-)
<matteo> hi all
<matteo> i'm making a package for hardy
<matteo> but I want a backport for gutsy too
<matteo> how do I name the backport?
<RAOF> !backports > matteo
<matteo> tnx
<mgunes> are there plans to ship an svn snapshot of Network Manager 0.7 if 0.7 final isn't released in time for Hardy, or is the fallback plan to ship 0.6.5? I haven't found any relevant info in the nm-ifupdown-death-match blueprint.
<RAOF> mgunes: I believe that the current thinking is that 0.7 is not going to be more useful than 0.6 by the time Hardy needs to stabilise, but we're still looking into it.
<mgunes> RAOF, that's what I was thinking; thanks.
<matteo> can I tell dh_installman to compress manpages?
<StevenK> dh_compress should do that
<StevenK> (I think)
<RAOF> man dh_compress suggests that it will do it by default.
<matteo> RAOF: somethig suggests me that I have to run it after dh_installman
<RAOF> Probably, yes.  Otherwise the man pages you want to compress won't be where dh_compress is looking.
<matteo> just before dh_builddeb should be fine
<matteo> isn't stupid to compress a manpage of 1.5kb?
<matteo> it should be against the policy
<matteo> "By default, dh_compress compresses files that debian policy mandates should be compressed, namely all files in usr/share/info, usr/share/man, usr/X11R6/man, files in usr/share/doc that are larger than 4k in size"
<minghua> It is not against the policy.
<matteo> it may not
<matteo> but it's stupid
<minghua> Note the "all files in /usr/share/man" part.
<matteo> and 1.5 file will be 4k on disk
<RAOF> Not necessarily.
<matteo> ah right
<matteo> smart FS like reiser and XFS will move them into the inode
<RAOF> Ding!
<matteo> ;)
<matteo> is a bad practice use -jX in the makefile?
<matteo> it can overload the buildd
<matteo> or the buildd compiles a package at time?
<RAOF> I'm pretty sure some packages already do parallel-builds (maybe some java packages?).
<LaserJock> mysql uses -jX in it's building
<matteo> $(MAKE) -j$(fgrep -c processor /proc/cpuinfo)
<matteo> that will work under bash
<matteo> but not in make
<matteo> any hint?
<RAOF> matteo: Set a make variable to $(shell fgrep -c processor /proc/cpuinfo) ?
<matteo> $(MAKE) -j$(shell fgrep -c processor /proc/cpuinfo)
<matteo> yes, found in the docs
<matteo> http://theoryx5.uwinnipeg.ca/gnu/make/make_81.html#SEC80
 * LaserJock kicks his DSL
<LaserJock> go faster!
<LaserJock> matteo: mysql-dfsg-5.0 uses:
<LaserJock> MAKE_J = -j$(shell grep -c processor.* /proc/cpuinfo)
<LaserJock> ifeq (${MAKE_J}, -j0)
<LaserJock>   MAKE_J = -j1
<LaserJock> endif
<matteo> mm
<matteo> that could be flacked
<matteo> let's say a PCu has an ID written in lowercase
<matteo> model name      : AMD Athlon(tm) 64 X2 Dual Core Processor 4400+
<matteo> and it reads:
<matteo> model name      : AMD Athlon(tm) 64 X2 Dual Core processor 4400+
<matteo> grep will find twice the values
<matteo> grep -c ^processor /proc/cpuinfo
<matteo> that is better IMHO
<LaserJock> yeah
<RAOF> Debdiff's welcome? :)
<matteo> E: aacplusenc_0.14_source.changes: bad-distribution-in-changes-file hardy
<matteo> can I ignore it?
<LaserJock> yep, it means you're not running hardy
<matteo> i'm running hardy
<LaserJock> so it doesn't recognize it as a valid release
<LaserJock> hmm, that's odd
<minghua> LaserJock: People shouldn't ignore that, they should install the most recent version of lintian (available in -backports) IMHO.
<LaserJock> minghua: well, I would encourage it, but if it's really important it shouldn't go in -backports
<matteo> apt-cache policy lintian
<matteo> 500 http://it.archive.ubuntu.com hardy/main Packages
<minghua> It's important for developers.
<matteo> that's not a backport
<minghua> Developers should have a hardy chroot anyway.
<minghua> I'm just saying no lintian errors should be ignored.
<minghua> If you use gutsy, get the lintian in -backports.
<LaserJock> minghua: well, I disagree slightly, but it is important I agree
<LaserJock> minghua: he's using Hardy he said
<minghua> LaserJock: Yes, I am aware of that.  I have no explanation to matteo's problem
<matteo> i use hardy, and I have a gutsy chroot
<LaserJock> matteo: you weren't in the gutsy chroot?
<matteo> no
<matteo> i'm at home
<matteo> btw, my package is the AAC+ encoder discussed in the forum
<matteo> and now packaged into medibuntu
<minghua> matteo: What is your lintian version anyway?
<matteo> 1.23.42
<minghua> That doesn't sound right...
<matteo> $ fgrep hardy /usr/share/lintian/checks/lintian.desc
<matteo>  distribution should be one of hardy, gutsy, feisty, edgy or dapper.
<minghua> I take that back.  1.23.42 is indeed the hardy version.
<LaserJock> matteo: maybe you should check your changelog entry to make sure there's not a typo
<matteo> http://pastebin.ca/868056
<matteo> seems fine to me
<LaserJock> weird
<matteo> indeed
<matteo> btw, 04:01 AM here
<matteo> gnite
<matteo> http://ppa.launchpad.net/teknoraver/ubuntu/pool/main/a/aacplusenc/aacplusenc_0.14.tar.gz
<matteo> this is the package
<matteo> if someone will try to figure out the lintian mistery
<warp10> Hi all
<Elly> win 15
<Elly> damn
<ion_> lose 19
<mpt> Goooooooooooooooooooood morning Ubuntu lovers!
 * Hobbsee hides under a rock, away from mpt, here too
<seb128> hey Hobbsee
<Hobbsee> hiya seb128!
<Hobbsee> morning other canonicalites.
 * pitti hugs Hobbsee
 * Hobbsee hugs pitti back
 * ion_ unhugs both pitti and Hobbsee
 * Hobbsee gives ion_ the boot
<slangasek> gpocentek: any news on gnumeric?
<gpocentek> slangasek: I uploaded it 2 hours after you asked me last time
<slangasek> ah, hmm
<gpocentek> and I installed it from the repos, so I guess it's ok
<gpocentek> slangasek: is there a problem with the package?
<slangasek> gpocentek: no, I was just misreading the NBS info for goffice :)
<slangasek> apparently libgoffice-0-5 only depends on itself and can be removed now :)
<gpocentek> ok :)
<psicus78> hi
<psicus78> do you know if it exist any tool that allow to find out (and then install) all the build-dependencies of a package which is not debianized yet? I mean get all the libblabla-dev required at build time?
<gouki> psicus78: Try asking on #debian-motu
<dholbach> gouki: #ubuntu-motu maybe?
<psicus78> dholbach: I just asked, thanks!
<mantiena-baltix> hi all
<mantiena-baltix> lool: hi, are you online ?
<lool> mantiena-baltix: I am
<tjaalton> pitti: hey, do you know if nvidia-glx-config is used anymore? I'd guess restricted-manager has replaced that?
<tjaalton> seems that it was last changed in edgy
<mantiena-baltix> lool: I have few questions about updating cheesy package
<mantiena-baltix> lool: I saw you comments at bug #180624
<ubotu> Launchpad bug 180624 in cheese "cheese new upstream version 0.3.0" [Undecided,Incomplete] https://launchpad.net/bugs/180624
<mantiena-baltix> lool: I wanna to package new cheesy version - 2.21.5 for testing uses (I have about 30 ubuntu users, which have webcams and wanna test ;) )
<lool> mantiena-baltix: Sure
<lool> mantiena-baltix: Are you Steve?  Or what's your name? :)
<mantiena-baltix> lool: so, which would be the easiest way to update cheese package ?
<lool> mantiena-baltix: If you followed the discussion on the bug report, there are a couple of things missing from the initial effort by Steve
<mantiena-baltix> lool: no, I'm not Steve, which reported that bug
<mantiena-baltix> lool: yea, I noticed that
<mantiena-baltix> lool: last comment from Steve was:
<mantiena-baltix> Â Steve Stalcup wrote     on 2008-01-18:
<mantiena-baltix>  Hi LoÃ¯c, It seems there is a new version available. I have corrected everything except for the patches, which seem to be Ubuntu specific.
<mantiena-baltix> lool: is this true ? You wrote about more problems in your comment, maybe Steve was attached updated interdiff ?
<pitti> tjaalton: it's not advertised anywhere any more
<pitti> tjaalton: except for the package description, I think
<tjaalton> pitti: ok, I'll remove it then
<pitti> tjaalton: yes, r-m is the prefered method, it works better, too
<pitti> tjaalton: great
<lool> mantiena-baltix: (Sorry, i'm in the middle of another conversation)
<lool> mantiena-baltix: My very last comment in the bug, comment #13, explains how to update the first of the two patches which needs updating
<lool> mantiena-baltix: The first patch is an easy one, so if you're familiar with updating patches, it should be an easy job; if you're not, perhaps you can read the wiki pages on patch systems which I've outlined in the bug report
<lool> mantiena-baltix: When one of Steve or you updates the first patch, I'll check how the other patch (which is much harder) compares to the new upstream and guide you folks into updating it
<mantiena-baltix> lool: I understand all your comments about patches, but I ask are there more problems in last interdiff ( AFAIK http://launchpadlibrarian.net/11198342/cheese_0.3.0-0ubuntu1.interdiff.gz )
<geser> pitti: please give-back: haskell-alut. Thanks.
<lool> mantiena-baltix: To my knowledge, the last interdiff was pretty good apart of porting of the patches
<lool> mantiena-baltix: There were other minor spurious changes which I'd prefer not seeing, but these were acceptable
<lool> mantiena-baltix: But this was against an older release of cheese; in the mean time a newer one came out, and it might desirable to rebase the changes on the new upstream
<lool> Albeit I am happy to sponsor the intermediate one
<mantiena-baltix> lool: btw, could you tell me how to work with these interdiff files ? I did apt-get source cheese from hardy and manually downloaded latest cheese source (2.21.5) and interdiff.gz, how to include improvements from interdiff.gz ?
<pitti> mantiena-baltix: gzip ../path/to/interdiff | patch -p1
<lool> mantiena-baltix: The interdiff is between the current diff in hardy (which is against 0.2.4) and the diff by Steve (0.3.0 I think); you should first apply his interdiff as a patch to the initial diff or as a patch against the hardy source tree (it should work I think), and then uupdate to the new upstream
<pitti> usually
<pitti> erm, gzip -cd
<lool> or gunzip -c :-P
<pitti> or zcat
<lool> you win!
 * lool cooks zpatch
<lool> mantiena-baltix: If you don't succeed, poke me again and I'll provide the commands
<mantiena-baltix> so, I will use gunzip -c , right ?
<lool> mantiena-baltix: zcat is what you want here ;)
<lool> mantiena-baltix: But it all boils down to gzip uncompressing a file and piping the result to patch
<StevenK> ian_brasil: Hi! I've sent you a few e-mails, have you recieved them?
<ian_brasil> nope...don't think so
<mantiena-baltix> yea, I understand this
<StevenK> ian_brasil: I'm happy to resend them if you priv-msg me your prefered address.
<mantiena-baltix> lool: so, it seems I finished update, excluding hildon.patch
<gouki> dholbach: yeah! Don't know what happened there.
<Aloha> how long does pbuilder install take on average?
<Hobbsee> depends how fast your net connection is
<Aloha> i have dsl
<Aloha> its my first venture into package building, i've always just done tarballs
<Aloha> should be fun
<mantiena-baltix> lool: still online ?
<lool> mantiena-baltix: Yup
<mantiena-baltix> lool: look at ftp.akl.lt/baltix-linux/Baltix-Ubuntu-packages/gutsy/cheese/
<Riddell> zul: how come the xen source package includes the version number?
<lool> mantiena-baltix: Couple of things first: 0.3.0-0ubuntu1 wasn't uploaded, so it would be best to merge the two changelog entries as to have one changelog entry per upload
<zul> Riddell: this for hardy?
<lool> mantiena-baltix: Next, you should use -0ubuntu1 for the Ubuntu revision of new upstream releases
<Riddell> zul: yes
<lool> mantiena-baltix: The -1 revision is usually reserved for Debian
<zul> Riddell: typo
<Riddell> zul: it's been doing it for some time
<lool> mantiena-baltix: Bad things can happen if you don't as I think this is used to decide whether the package comes from Debian or not (if you don't have ubuntu in your version string, the package will be merged from Debian I think)
<mantiena-baltix> lool: ok, I forgot it
<lool> mantiena-baltix: Now let me review the 0.3.0 -> 2.21.5 diff...
<zul> Riddell: its something we inherited from debian way back in feisty it can probably be dropped for hardy so its just xen
<lool> mantiena-baltix: In the mean time, I recommend you attach your work, especially the diff, in the bug report; this way, nobody else will redo the same work you already did in the mean time
<mantiena-baltix> lool: wait I minute I will add lithuanian translation into .desktop file
<lool> mantiena-baltix: It's not critical for Ubuntu; translations are usually handled by Rosetta anyway (I think); you might want to send it upstream directly, and we will get it with the next release
<mantiena-baltix> lool: it is enough to attach only .diff.gz (without interdiff) to bugreport ?
<lool> mantiena-baltix: I think at this point it's easier to attach your interdiff; please mention the changes you did relative to the last published interdiff though
<lool> mantiena-baltix: Err your *diff*
<lool> Not your /interdiff/; sorry, typo
<mantiena-baltix> lool: lithuanian translation is critical to lithuanians ;) I'm doing gutsy backport, where cheese is not in main, so, not handled by Rosetta
<lool> mantiena-baltix: Do you mind if we move to #ubuntu-motu as to not flood this chan with universe packages' stuff?  :)
<lool> mantiena-baltix: I meant it's not critical to do it in the source package; I think you can do it in Rosetta as well
<mantiena-baltix> lool: ;) AFAIK cheese is in main now ;) btw, I got a build error during building package
<lool> mantiena-baltix: But I'll happy to review it if you do :)
<lool> mantiena-baltix: Wow, indeed
<mantiena-baltix> dh_installdirs -pcheese
<mantiena-baltix> dh_installdocs -pcheese ./README ./NEWS ./AUTHORS
<mantiena-baltix> cp: cannot stat `TODO': No such file or directory
<mantiena-baltix> dh_installdocs: command returned error code 256
<mantiena-baltix> make: *** [binary-install/cheese] Error 1
<lool> mantiena-baltix: We can stay here then :-P
<lool> mantiena-baltix: This TODO file was probably dropped upstream but the packaging tries to install it; remove it from the list of docs to install and mention it in changelog
<mantiena-baltix> stupid build system...
<mantiena-baltix> ;)
<lool> mantiena-baltix: Concerning your changes; you properly catched the new librsvg2-dev build-dep, but you mention it was "missing"; it wasn't really missing since the previous version didn't require it -- in the process of the 0.3.0 review, we discovered the package was lacking build-deps (even the current hardy version), hence the mention of "missing" build-dep
<mantiena-baltix> lool: so, librsvg is new build-dep ?
<lool> mantiena-baltix: Exactly, it's simply a new requirement
<lool> mantiena-baltix: You can simply mention "Add a librsvg2-dev (>= 2.18) build-dep" for example
<lool> mantiena-baltix: It's really nitpicking at this point; but since we're at it... ;)
<lool> mantiena-baltix: I just noticed something about the dependencies
<lool> mantiena-baltix: If you diff README between 0.3.0 and 2.21.5, you'll see:
<lool> -  - gstreamer-plugins-good-0.10  >= 0.10.15
<lool> +  - gstreamer-plugins-good-0.10  >= 0.10.6
<lool> In the dependencies
<lool> mantiena-baltix: As you can see, cheese has a gstreamer0.10-plugins-good dependency, but it's unversionned; could you please use the version mentionned in the new README?
<mantiena-baltix> I've noticed this, I think these changes were made by uupdate
<ion_> benc: Btw, thereâs a fixed nvidia_connected attached to bug #182237.
<lool> mantiena-baltix: Also, what about the "pango" requirement in configure.ac?
<ubotu> Launchpad bug 182237 in linux-restricted-modules-2.6.24 "restricted manager does not recognize nvidia 8600M GT on hardy" [High,Confirmed] https://launchpad.net/bugs/182237
<calc> mjg59: ping
<mjg59> calc: Hi
<calc> mjg59: i am playing with resume on my laptop in 64bit mode and I think I may have gotten further
<mjg59> Mm?
<calc> mjg59: if i set  3 > /proc/sys/kernel/acp_video_flags it will resume at console
<mjg59> Right. That's because it's executing the code natively rather than in x86emu.
<mantiena-baltix> lool: whan problems can be with pango ? libgtk2.0-dev depends on pango-dev
<calc> mjg59: but if i add that to a file in /etc/acpi/suspend.d/ and then try to resume i get a blank X window (black screen with a cursor)
<calc> mjg59: is there something i need to do to get X to come back correctly?
<ion_> benc: Did my message get though? :-)
<calc> mjg59: i tried disabling save vbe state, post video, and use dpms but i got the black screen/cursor issue
<mjg59> calc: Figure out why it's not coming back correctly and fix the driver? :)
<lool> mantiena-baltix: It's currently true that libgtk2.0-dev depends on pango-dev but you can't rely on that: first, cheese *directly* needs pango, second, imagine the version of the pango build-dep in cheese is higher than the gtk -> pango dep
<calc> mjg59: ah so its a bug in the driver at that point?
<mjg59> calc: Fundamentally, failure to resume video is a bug in the driver at any point
<calc> mjg59: when its black like that i can switch VTs to console and console still works ok
<lool> mantiena-baltix: In general, you need to map upstream checks to build-dependencies as close as possible
<calc> mjg59: ok
<lool> mantiena-baltix: Do you mind if I attach the diff I grabbed from you to the bug report and note down the remarks I made above to not let them bitrot in an IRC log? :)
<calc> mjg59: there is/was a bug in Ubuntu where it won't turn on the screen if acpi_video_flags isn't set to non-0
<calc> mjg59: for even console video
<BenC> ion_: don't think so
<mjg59> calc: Yes. That's because x86emu is broken.
<mjg59> (somehow)
<ion_> benc: Thereâs a fixed nvidia_connected attached to bug #182237.
<ubotu> Launchpad bug 182237 in linux-restricted-modules-2.6.24 "restricted manager does not recognize nvidia 8600M GT on hardy" [High,Confirmed] https://launchpad.net/bugs/182237
<calc> mjg59: would that affect even i386 resumes? it wasn't resuming even on i386 to a console before i set that flags file
<mantiena-baltix> lool: sorry, I don't understand your last message :(
<mjg59> calc: We had working i386 resume on your system before
<Mithrandir> calc: does it help if you close the lid and reopen it?  That fixes the "fails to turn on the screen" bug for me.
<Mithrandir> or "fixes".
<lool> mantiena-baltix: Do you mind if I summarize what we just discussed in the bug report now?
<calc> mjg59: yea it works in gutsy but is broken in hardy along with several other users here at hardy sprint
<mjg59> calc: That's probably the change from acpi-support to pm-utils
<mjg59> I'll be there tomorrow
<calc> Mithrandir: hmm not sure i can try that again, though changing /proc/sys/kernel/acpi_video_flags to 3 works fine on i386, but comes back with a mostly dead X on 64bit
<calc> mjg59: cool :)
 * calc hugs mjg59 
<mantiena-baltix> lool: I'm making new diff.gz now, which includes your wishes ;)
<calc> mjg59: acpi-support is still installed on hardy but maybe its not using it?
<mjg59> acpi-support is installed but not used for suspendresume
<calc> mjg59: ah ok
<lool> mantiena-baltix: Cool
<calc> mjg59: i guess that could explain why changing /etc/defaults/acpi-support didn't change anything for me
<mjg59> Yeah
<mjg59> I need to clean that up
<calc> mjg59: i believe all the affected users here are using i945 intergrated video
<calc> mjg59: me, robert collins, and i forgot who the other person i heard was having trouble
<calc> mjg59: is pm-utils user configurable?
<mjg59> Yes, but not as trivially
<calc> ok
<mjg59> Check the quirks in /usr/share/hal/something/fdi/bonghits/misc/other
<calc> heh nice dirname ;)
<StevenK> Haha
<mantiena-baltix> lool: btw, Do you think, that cheese can depend on gstreamer (>= 0.10.15) and gstreamer-plugins-base-0.10  >= 0.10.15, but gstreamer-plugins-good-0.10  >= 0.10.6 ?
<mantiena-baltix> lool: isn't this strange version (0.10.6) simply a mistake in new README ?
<jdong> I think mjg59 means /usr/share/hal/fdi/information/10freedesktop/
<jdong> :)
<StevenK> I think I prefered that directory name when it included 'bonghits'
<StevenK> As in, "You'll need some to send patches to files underneath this directory'
<jdong> StevenK: well he'd be in the position to make that happen :D
<lool> mantiena-baltix: I think the previous version was a mistake
<lool> mantiena-baltix: I guess they copied the gstreamer-plugins-base-0.10 version for gstreamer-plugins-good-0.10
<lool> mantiena-baltix: We certainly don't have gstreamer0.10-plugins-good 0.10.15: the latest version is 0.10.6
<mantiena-baltix> lool: ya, I just noticed this ;) Btw, why we need to use gstreamer 0.10.15 ? cheese compiles fine with 10.14 ;)
<calc> bbia testing s2ram stuff
<lool> mantiena-baltix: It might be runtime features
<lool> mantiena-baltix: Or simply to prevent people from running cheese which this version as the combination might have bugs fixed in the new release -- it's pretty bad to add such dependencies, but many upstreams do
<pitti> lifeless: deb     http://ddebs.ubuntu.com hardy main restricted
<calc> mjg59: do we have s2ram?
<calc> mjg59: i don't see it installed on the hardy cd or in apt-cache
<mjg59> calc: No
<lool> calc: Hmm I think it's supposed to be in uswsusp, but I only see s2disk and both
<mjg59> It's explicitly not built
<mjg59> It turns out that having three different ways of triggering suspend to RAM that use different pathways and different quirks is mad
<mantiena-baltix> lool: look at new diff.gz in ftp.akl.lt/baltix-linux/Baltix-Ubuntu-packages/gutsy/cheese/
<calc> lool: no s2* are installed on the cd
<calc> so i need to modify /usr/share/hal/fdi/information/10freedesktop/20-video-quirk-pm-toshiba.fdi for my particular laptop?
<mjg59> Yes
<mjg59> Then hal probably needs restarting
<mjg59> Note that we're slightly different to upstream - a bunch of quirks are enabled by default
<calc> mjg59: what do i use to dump what hal sees for my laptop?
<mjg59> lshal
<mjg59> See /usr/lib/hal/scripts/foo/bar/hal-system-power-suspend-linux
<lool> mantiena-baltix: Could you please attach it to the bug report?  I'll make my comments them directly
<lool> s/them/there
 * lool needs coffee
<mantiena-baltix> OK, I just compile them before attaching, ok ?
<mantiena-baltix> Btw, There are nothing to translate in https://translations.edge.launchpad.net/ubuntu/hardy/+source/cheese :(
<lool> mantiena-baltix: Sure
<lifeless> pitti: thanks
<lool> mantiena-baltix: I just discussed this with pitti (thanks pitti!), and two things are needed for it to appear
<lool> mantiena-baltix: First, it needs to be rebuilt since its promotion to main
<lool> mantiena-baltix: that will happen after I sponsor the new cheese for example
<lool> mantiena-baltix: Second, we need to patch cheese's .desktop file to have a X-Ubuntu-Gettext-Domain
<lool> mantiena-baltix: Forget about the second thing: it's done automatically in CDBS packages using gnome.mk
<lool> mantiena-baltix: So you should see the translations imported after the next build
<mantiena-baltix> ;)
<lool> mantiena-baltix: Can you please attach your diff to the bug?  Or I can do it if you prefer
<calc> hmm it died, oh well i'll beat on it later
<mantiena-baltix> lool: I prefer you ;)
<lool> mantiena-baltix: What's your name?  are you subscribed to the bug report?
<lool> Mantas KriauÄiÅ«nas?
<mantiena-baltix> Yes, I'm subscribed through Baltix-members team ;)
<mantiena-baltix> lool: you should use UTF for my surname
<mantiena-baltix> as in ISO-8859-1 there re no Ä or Å«
<TheMuso> o/c
<slangasek> um, he /did/ use UTF for your surname? :)
<mantiena-baltix> lool: hey, I already translated 40% of cheese-lt.po ;)
<lool> mantiena-baltix: I've sent my review
<Aloha> i uploaded my source to my ppa and i got an acceptance email but i can't see anything on the launchpad site. anyone got any ideas?
<Hobbsee> Aloha: see #launchpad for ppa support
<Aloha> Hobbsee, thnx!
<mantiena-baltix> lool: it seems fix_desktop.patch doesn't work :(
<mantiena-baltix> maybe it should be against desktop.in.in, not against desktop.in ?
<lool> mantiena-baltix: Indeed!
<lool> mantiena-baltix: I didn't notice the new file
<mantiena-baltix> lool: btw, new cheese package (without hildon patch) doesn't work in gustsy at all :(
<calc> mjg59: i must be confused as i can't determine how pm-utils suspends a system
<calc> mjg59: it appears to call /usr/sbin/pm-suspend which calls the nonexistant s2ram?
<\sh> hmm..can someone look why last upload of ipe (from yesterday) and gnucash (from one hour ago) isn't showing up in hardy?
<lool> mantiena-baltix: What do you mean with "doesn't work"?
<mantiena-baltix> lool: I see only grey background, but nothin from my webcam :(
<lool> seb128: I received some words from danw that some fixes are still flowing in libsoup and he wants to up a tarball next WE for 21.90
<lool> mantiena-baltix: Did the older release work for you?
<calc> looks like pm-suspend calls into /usr/lib/pm-utils/functions pm_main which uses s2ram or blindly just suspends by writing mem to /sys
<calc> but i have to be misreading this or why would that likely ever work
<calc> mjg59: ping?
<sjoerd> calc: if your version of pm-utils is the same as debians that's indeed the case
<calc> sjoerd: you mean it just blindly tries to write mem to /sys/power/state ?
<calc> sjoerd:  so this hal stuff doesn't even get used because s2ram isn't included in ubuntu (!?)
<sjoerd> calc: it tries to use s2ram, if that's not available it writes mem to /sys/power/state
<sjoerd> Not sure what happens with the quirks if uswsusp isn't installed
<mjg59> calc: Hi
<mjg59> pm-suspend doesn't call s2ram
<mjg59> Which then writes to /sys/power/state, yes
<seb128> lool: ok
<calc> mjg59: it calls pm_main which calls do_suspend which tries to use s2ram
<mjg59> Yes, but if s2ram isn't there it's fine
<calc> mjg59: so if a machine has any kind of quirks its hosed?
<mjg59> No
<mjg59> Quirks are called on resume
<calc> mjg59: since as far as i can tell none of the quirks are used unless s2ram is installed
<seb128> lool: there is no hurry anyway, the dav code is not ready to be used yet
<calc> mjg59: oh hmm
<mjg59> calc: Check the hooks
<mantiena-baltix> lool: 0.24, backported from hardy works fine, 0.3 - doesn't work, same problems like in 2.21.5
<mantiena-baltix> lool: maybe this is because in gutsy is gstreamer 0.10.14, not 0.15, which is "officially" needed according to devs
<calc> mjg59: i am confused as to where the pm-suspend exported args (if not using s2ram) end up getting parsed/used
<mjg59> The hooks
<lool> mantiena-baltix: Could be
<\sh> pitti, ping missing packages and I didn't receive neither an error message  nor a positive ack  from LP
<calc> mjg59: those are the files in eg /usr/lib/pm-utils/sleep.d/99video ?
<pitti> \sh: which source?
<mjg59> Yes
<calc> mjg59: ok
<\sh> pitti, ipe from yesterday and gnucash (about one hour ago)
<dx9s_work> what channel deals with packaging (.deb) again?
<dx9s_work> some master of the universe thing... forgot ..ubuntu-motu ?
<pitti> https://edge.launchpad.net/ubuntu/+source/ipe
<pitti> \sh: ^ it's not there at all
<dx9s_work> yeah that's it
<pitti> \sh: sure that you uploaded it?
<\sh> pitti, Successfully uploaded ipe_6.0pre30-1ubuntu1.dsc to upload.ubuntu.com.
<pitti> \sh: hm; cprov, any idea?
<\sh> pitti, the same .upload file for gnucash
<\sh> pitti, while octave2.9 from yesterday worked :(
<\sh> pitti, should I reupload?
<cprov> pitti: let me check
<cprov> pitti: (Ubuntu Core Developers <ubuntu-devel-discuss.ubuntu.com>: no @ found in email address part.)
<pitti> hah
<pitti> \sh: ^
<calc> mjg59: ah i understand how it works now :)
<calc> mjg59: thanks for the help :)
 * calc goes back to beating his laptop
<\sh> pitti, oh well...it's wrong anyways...
<\sh> cprov, this could be worth a "reject email" ;)
<\sh> cprov, hiding this error leads to confusion ;)
<cprov> who would receive those ?
<\sh> cprov, the uploader?
<cprov> we can't find out who is the uploader if the changesfile is broken, maybe when we have authenticated upload backend, but not now
<persia> cprov: Can't you tell from the signature, even if the data is useless?
<pitti> cprov: the gpg signer?
<\sh> cprov: as pitti said, the .changes file is signed (the .dsc, too) so it should be easy to find out who was it
<cprov> yes, we could fallback to the signer
<\sh> which is a good default, even for sponsored uploads
<cprov> file a bug, we can try to implement something in the next cycle, but it seems to me that it could be solved in a better way if you check changesfile consistency locally.
<\sh> cprov, yes, but humans make errors ;) so it's good to have a automatism for this, too :)
<persia> cprov: also, .changes upload is just FTP.  Too easy to circumvent a local check
 * cprov nods
<calc> ok i got it working as well as I did when manually suspending
<calc> it still shows a black screen with the cursor though for whatever reason
 * calc testing something he found on a webpage, heh
<calc> hmm still about the same
<calc> on amd64 i just get a black X screen with cursor :-\
<lool> seb128: I think we should add Breaks in nautilus for e.g. nautilus-sendto and other extensions-1.0
<seb128> lool: not sure, I don't want to force people to uninstall evince because the properties page will be ignored
<seb128> lool: we should rather add those one we have rebuilt versions
<lool> seb128: I was pondering adding conflicts in the extensions
<seb128> the easier might be to ask alex to change the soname
<lool> seb128: It's not really the same thing; the ABI for extensions can change more frequently than the SONAME
<lool> seb128: Do you think you could add a Provide in the new nautilus like we did for Gtk+ and Pango modules?
<seb128> lool: not sure about this one
<lool> seb128: Like Provide: nautilus-extensions-2.0
<lool> seb128: The idea is that I can simply depend on that instead of conflicting with nautilus version numbers
<lool> seb128: And in the case of gtk / pango, the depends is generated on the fly
<robertj> are there known issues with Xorg auto-detection of 2560x1600 displays on nvidia-nonfree?
<gaspa> pitti: have you got some minutes, for some usplash-endless-boring-things?
<pitti> gaspa: involved in some other things, but I'll catch up with answers here
<gaspa> pitti: do you prefer a mail?
<gaspa> perhaps i'll prefer mail too... :P
<Mithrandir> robertj: unsure.  Send me one and I'll test. :-)
<pitti> gaspa: ok, WFM
<lool> seb128: Argh, we're epoched on nautilus in Ubuntu?
<seb128> lool: yeah, not sure why, I think a typo command or something some cycles ago or something similar
<lool> Sucks
<kagou> Hi
<mdz> seb128: I get a conffile prompt for /etc/gconf/schemas/panel-default-setup.entries from gnome-panel-data, though I do not think I ever edited it
<seb128> mdz: the schemas should be in /usr/share, looks like it's due to the changes I did when packaging the new version, I'll fix it with the next upload
<pitti> mvo: FYI, got gen-contents running now, let's see what falls out of it
<lifeless> win 20
<ion_> lose 42
<pitti> mvo: HAH!
<mvo> thanks pitti
 * pitti tracks it down to some dir permission error
<mdz> seb128: ok, thanks
<seb128> you are welcome
<wasabi> I see we're giving pulse another try.
<wasabi> Far as I can tell it's still broken with flash.
<persia> wasabi: This is the first time for pulse.  polyps were indigestible :)
<wasabi> Ahh yes. Was polyp last time.
<wasabi> There a game plan posted anywhere?
<TheMuso> wasabi: There is a package to use pulse with flash
<persia> wasabi: https://wiki.ubuntu.com/DesktopTeam/Specs/CleanupAudioJumble
<wasabi> Oh! Yeah.
<hunger> What happened to the plan to put etc under version control? I read that there was a proposal to that effect for gutsy IIRC.
<wasabi> I heard about that last time i tried pulse, but it had bitrotted to the point of not compiling.
<Ng> hunger: it's quite a scary thing to do if you don't have humans controlling it, or lots of corner cases taken care of
<hunger> Ng: It is?
<Ng> hunger: especially when your vcs tool isn't hot on permissions, yes :)
<hunger> Ng: I am asking since I have been using etckeeper (which is horribly outdated in ubuntu) and am very happy with that.
<ogra1> http://people.ubuntu.com/~ogra/Bildschirmfoto.png
 * ogra1 thinks its a strange world ....
<hunger> Ng: Git is not... but that is what metastore it seems to work reasonably well:-)
<lifeless> Ng: now?
<Ng> lifeless: I only have about 20 minutes, and elmo isn't here, but sure
<lifeless> k, coming to you
<Ng> cool
<ogra1> mvo, ^^^
<ogra1> (see the screenshot)
<lool> seb128: You started nautilus 2.21.7 already?
<seb128> lool: there is no such tarball?
<\sh> seb128, thx for the gconf fix :) now everything will be good with gnucash ;)
<lool> seb128: Err I meant 6, my mistake
<seb128> you are welcome
<seb128> lool: I've updated this morning, that's the ppa version
<lool> seb128: I miscomputed in my head
<lool> seb128: I see it's in now, sorry
<\sh> seb128, but I wonder now, why it FTBFS on our buildds but not on my sbuild
<seb128> \sh: maybe you had glib1.2 installed?
<seb128> lool: ok
<\sh> seb128, hmmmm
<\sh> seb128, similar bug as with the gconf thingy?
<\sh> well...build-deps say libglib2.0-dev
<seb128> \sh: no idea why it built
<\sh> seb128, ok..something is pulling in libglib1.2
<robertj> Mithrandir: isn't that why you have mac-daddie Mark, to buy you equipment needed for testing ;)
<\sh> seb128, ok..now I get the very same FTBFS error...loooks like something changed somewhere
<robertj> can someone take a look at http://pastebin.ca/868789 and http://pastebin.ca/868790 , xorg.conf and the log, and let me know what package I should file that against?
<infinity> robertj: I may be missing the (EE), but what's the bug, exactly?
<mvo> pitti: ok, if only event.d is important, then its really straightforward I think
<robertj> infinity: its not taking the specified mode and then autodetecting an incorrect one with very bad results, causing a flashing screen and killing X doesn't get my term back
<mvo> pitti: http://paste.ubuntu.com/3782 is the list including system.d
<infinity> robertj: Ahh, it doesn't like your manual modeline, I see.
<infinity> robertj: The driver (nvidia, from LRM) is responsible for your hatred there.
<infinity> robertj: Feel free to file the bug, but good luck getting closed-source drivers fixed. :/
<bryyce> robertj: file it against your driver
<pitti> mvo: looks like most (if not all) of the extra ones are session bus
<bryyce> timo will be uploading a new lrm shortly (tomorrow perhaps) with new fglrx and nvidia
<mvo> pitti: yeah, even better :)
<bryyce> there've been a few complaints about misdetected modelines
<robertj> but why wouldn't it take mine, did I botch it? ModeLine       "2560x1600@60" 348.2 2560 2752 3032 3504 1600 1601 1604 1656 -hsync +vsync
<bryyce> robertj: dunno, that looks ok at first glance
<robertj> stole that modeline from http://aufrecht.org/blog/archive/2007/02/ too
<mvo> pitti: http://paste.ubuntu.com/3783/ that is the list with only event.d in the package
 * robertj files 185149
 * robertj files bug #185149
<ubotu> Launchpad bug 185149 in linux-meta "NVidia driver doesn't work with 3007WFP" [Undecided,New] https://launchpad.net/bugs/185149
<robertj> regression :(
<Riddell> doko: lest you care, W: icepick: manpage-has-errors-from-man usr/share/man/man1/icepick-javadoc.1.gz /tmp/zmanmkAWAN:305: `.' not last character on line
<\sh> cprov, could it be, that soyuz somehow forgot to fill hardy-changes with some packages? got accept messages for my uploads...but they are not announced anymore on hardy-changes...
<cprov> \sh: let me check
 * \sh checked lists.ubuntu.com, too, so my mailserver is ok ;)
<cprov> 17:50:20 DEBUG       Subject: Accepted: ipe 6.0pre30-1ubuntu1 (source)
<cprov> 17:50:20 DEBUG       Recipients: hardy-changes@lists.ubuntu.com
<cprov> \sh: ^ ?
<\sh> cprov, check the archive ;) it's not on the list :)
<\sh> could be that mailman went crazy...
<pochu> \sh: same here. And there have been very few mails today, although I think seb128 has done quite a few uploads.
<\sh> pochu, yepp
<pochu> \sh: perhaps the disks are full, do you remember that? ;)
<\sh> pochu, no :)
<\sh> pochu, but my disks are not full ;)
<pochu> \sh: when ubuntu-bugs@ wasn't archiving mails anymore due to the disks being full :)
<pochu> \sh: not yours :)
<\sh> gnucash fixed...
<\sh> pochu, well, hopefully elmo or some other canonical sysadmin is working on this problem :)
<infinity> \sh: If mailman is backed up, it may we be my fault (bombarded it with a few thousand failure logs this morning), it should recover...
<\sh> infinity, cool :)
<infinity> ... eventually.
 * toresbe waves
<toresbe> Out of curiosity... are people here aware of Ubuntu Cola?
<toresbe> There is a new brand of cola (at least new to Norway) called "Ubuntu Cola" being sold in Fair Trade stores in Oslo
<LaserJock> hmm, is it brown? :-)
<toresbe> the colour scheme of the bottle is white with orange and brown details, very much like the Ubuntu Linux software scheme
<bahadunn> where would I go to enquire about any license restrictions on selling computers with ubuntu pre-installed?
<toresbe> http://dnausers.d-n-a.net/dnetGOjg/020885.htm
<toresbe> oops
<toresbe> http://www.vl.no/samfunn/article3295507.ece
<toresbe> :)
<Seveas> bahadunn, trademarks@ubuntu.com for trademark concerns
<bahadunn> email is the only way then?
<Pici> toresbe: FYI: #ubuntu-devel isnt for random chat, mainly for Ubuntu development, you're welcome to join #ubuntu-offtopic to discuss the lighter side of Ubuntu and all other stuff.
<toresbe> Pici: Oh yes, I'm quite aware of it. I just thought that the developers might get a kick out of it, and I was curious to know if any of the developers knew about it.
<Pici> toresbe: Okay, just making sure :)
<somerville32> toresbe: Cute. :)
<Seveas> bahadunn, no licenses of software included with ubuntu prevent you from selling it preinstalled. The only thing that I don't know all details is about is the Ubuntu trademark. Yes email is the prefered if not only way for such questions
<toresbe> Pici: no prob. I'm not going to hang around here terribly much.
<bahadunn> Seveas: okay got it
<bahadunn> Seveas: thanks very much for the information
<Seveas> thegodfather, wth? :)
<thegodfather> Seveas: ?
<thegodfather> Seveas: my adsl keeps bouncing..
<Seveas> thegodfather, I just like the alternate identity :)
<Seveas> fits you
<thegodfather> it has _always_ been me
<thegodfather> :)
<calc> helllo
<calc> er hello
#ubuntu-devel 2008-01-23
 * lamont wonders if any german speakers are awake for a totally-off-topic translation question
<Hobbsee> heh
<Hobbsee> try #ubuntu-de?
<lamont> feh
<lamont> be logical.
<Hobbsee> my german won't be anywhere near good enough
<lamont> Hobbsee: they're all speaking german there!!!! :-)
<Hobbsee> they should speak some english :P
<StevenK> Wouldn't it be funny if lamont got kicked for speaking English ...
<lamont> StevenK: hehe
<lamont> they sent me to google
<StevenK> Haha
 * ScottK looks around for an archive admin ...
<StevenK> Bit late for them.
<ScottK> True.
<ScottK> I thought maybe slangasek or Hobbsee might be up and about.
 * lamont tickes Hobbsee 
 * Hobbsee stomps on lamont's feet
<lamont> ScottK: I give you Hobbsee, live and in person.
 * Hobbsee bites
<ScottK> Heh.
 * Hobbsee claws
 * Hobbsee uses the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! â¢ on ScottK
 * Hobbsee sets lamont and ScottK on fire
<ScottK> Hobbsee: After you're finished chewing on lamont, would you please accept the 3 uploads sitting in dapper backports?
<lamont> "Jesus saves.  Gretsky steals, shoots,  SCORES!!!"
 * ScottK warms up.
<ScottK> (It's been cold here lately)
<ScottK> Thanks.
<Hobbsee> let me see....
<lamont> 'twas below zero (Fahrenheit even...)  this morning
<Hobbsee> sylpheed* and php*?
<ScottK> Yes.  Two for slypheed.
<Hobbsee> yep.  done.
<lamont> php-clamavlib_0.12a-4~dapper1_source.changes
<lamont> sylpheed-claws_1.0.5-5.1ubuntu0.1~dapper1_source.changes
<lamont> sylpheed-claws-gtk2_2.6.0-1.1ubuntu1.1~dapper1_source.changes
<ScottK> Hobbsee: Thanks.
<Hobbsee> you're welcome
<lamont> we now return you to your regularly scheduled topic.
<lamont> (and thanks)
 * Hobbsee sets lamont on fire again, then.
<lamont> ah.  warmth.  thanks
<lamont> danke, even
<Hobbsee> :)
 * Hobbsee smashes edge with a large brick
<lamont> edge or edgy?>
<Hobbsee> lamont: can you do it somehow?  launchpad is scrweing up.  again.
<StevenK> I'm suspecting edge.launchpad.net
<StevenK> Ah. I was right
<Hobbsee> it's edge.  and production.
<ScottK> How can LP be screwing up, Ubuntu doesn't have a release or freeze on right now?
<Hobbsee> edge fails with a timeout, production fails with a non-timeout-oops.
<lamont> oh.  edge.  yeah
<lamont> Hobbsee: what exactly are you doing that's timing out?
<lamont> (url??)
<Hobbsee> accepting the dapper backports packages
<Hobbsee> https://edge.launchpad.net/ubuntu/dapper/+queue?queue_state=1&queue_text=
<lamont> Hobbsee: and I have your OK to accept those on your behalf?  (just to see if it'll work for me)
<Hobbsee> lamont: yeah
<lamont> Waiting for edge.launchpad.net.................................
<lamont> Accepting Results:
<lamont> OK: sylpheed-claws-gtk2, OK: sylpheed-claws, OK: php-clamavlib
<lamont> not the quickest update I've ever seen
<Hobbsee> right, so it works for you then?
<lamont> yeah.
<lamont> I should have just done one, then we could have played more.
<lamont> sorry
<lamont> hopefully it's not duck-related.
<Hobbsee> thanks
<Hobbsee> ScottK: upload more crackports, please
 * Hobbsee tried it multiple times
<ScottK> Hobbsee: You need to get the tech-board to approve my core-dev application before I can do it without a beard like lamont.
<ScottK> ;-)
<Hobbsee> hehe
 * Hobbsee has almost no say over the techboard, sorry
<Hobbsee> when did they want their meeting?
<lamont> Hobbsee: I wonder if maybe it's because ScottK's sig is on the .dsc files...
<Hobbsee> lamont: as to why it got into unapproved?
<lamont> no, as to why it OOPSed
<ScottK> Hobbsee: All backports go to unapproved.
<lamont> because crackporting is an unapproved activity
<lamont> Uploaded By:  Scott Kitterman
<lamont> WIN
<lamont> https://edge.launchpad.net/ubuntu/+source/sylpheed-claws/1.0.5-5.1ubuntu0.1~dapper1
<ScottK> I got accepts for all three.
<lamont> PENDING: Dapper  pocket Backports  in component universe  and section mail
<lamont> it's in universe... you could have done that one
<lamont> same for -gtk2
<ScottK> lamont: Nope.  Backports uploads always take a core-dev
 * lamont grumbles at ScottK 
<lamont> oh, really?
<ScottK> Even for Universe.
<ScottK> Yeah.
<lamont> how, interesting
 * lamont ponders, remembers whyu
<zul> lamont has a beard?
<lamont> zul: no, apparently I _am_ one
<zul> ah ok apparently i missed that part
<ScottK> And a very helpful one at that.
<StevenK> I don't see how beards are helpful in the usual case ...
 * ScottK neither (it's really pretty obsolete), but it seemed like a funny way to put it.
<ScottK> Thanks again Hobbsee and lamont.
<ScottK> That's 8 down.  6 to go.
<Hobbsee> you're welcome
 * lamont stares at his firewall rulesete
<lamont> s/e$//
 * ScottK looks at the 1807 packages needs-building for Hardy and despairs his dapper-backports will ever build.
<LaserJock> seriously?
<ScottK> Yeah.
<ScottK> That's down about 100 already from it's peak.
<lamont> ScottK: launchpad.net/+builds shows 104 for i386
<ScottK> Well these are all arch: any, so whatever you did to hppa is going to slow things down.
<lamont> huh?
<lamont> your backports will be a while before hppa (655) gets to it, but what do you care?
<lamont> or does it actually require it to be current everywhere before it publishes (/me thinks "no")
<ScottK> lamont: Now, but I won't relax until it's all done.  Only clamav needed to go through binary New and that's done.  That's the only one it would have mattered for.
 * lamont wears his "being good" hat
<lamont> Hobbsee: did you try to accept all 3 packages each time (edge)?
<lamont> or just one?
<Hobbsee> all
<lamont> if it happens again, try just one at a time... 'twould be an interesting data point
<lamont> word is that it's not duck-related
<bddebian> I suppose pitti is asleep this time of day?
<zul> most likely
<warp10> Heya
<jackdaw> hello, i
<pitti> Good morning
<pitti> bdmurray: hi
<pitti> bdmurray: unping; that was supposed to be 'bddebian'
<gaspa> pitti: morning.
<pitti> hey gaspa
<pitti> gaspa: getting to your mail, promised (I'm a bit backlogged on the sprint)
<gaspa> pitti: np.
<gaspa> i'm not in a hurry. :)
 * gaspa remembers someone's blog... :P
<Keybuk> calc: openoffice.org-core overwrites something in common
<mpt> Gooooooooooooood morning Ubuntu lovers!
<TheMuso> mpt: isn't that a bit old? :p
<mpt> TheMuso, old? It's only the second time I've ever said it
<TheMuso> mpt: Well ok then.
<RAOF> mpt: TheMuso works on fuzzy pattern-matching, so it *is* a bit old :)
<TheMuso> RAOF: lol
<bdmurray> pitti: wow, that usually happens the other way around
<pitti> bdmurray: ETABCOMPLETION :)
<slangasek> ScottK: this is sprint week, it's late for me too. :)
<geser> good morning
<pitti> hi geser
<geser> Hi pitti
<ion_> Freenode.find_by_channel_and_status('#ubuntu-devel', :nonidle).each {|person| greet person }
<evand> Anyone have an objection to me building a new i386 desktop CDs, or know what the giant warning in cdimage's crontab means?  pitti, slangasek?
<slangasek> evand: which warning, the "do not re-enable"?
<slangasek> that one means that I failed to delete the warning when reenabling the cronjobs
<asac_the_2nd> bryce: http://ubuntuforums.org/showthread.php?t=669262
<evand> slangasek: heh, gotcha
<evand> and yes, that one
<slangasek> evand: it definitely doesn't apply, since the cronjobs below it are all enabled ;)  so yeah, if you need a new desktop build, go ahead
<evand> ok, I'll remove the warning as well then
<asac_the_2nd> bryce: its bug 182038
<ubotu> Launchpad bug 182038 in xserver-xorg-video-nv "Black rectangle instead of image in FF3 [Hardy]" [Undecided,Confirmed] https://launchpad.net/bugs/182038
<calc> Keybuk: yea i'll have to fix that in the next upload :\
<tjaalton> asac_the_2nd: I'll forward it upstream (xorg)
<calc> Keybuk: the work around for now is to uninstall the package it is overwriting, it should have replace/conflict that old package version :\
<asac_the_2nd> tjaalton: thanks
<seb128> lifeless: http://bugzilla.gnome.org/show_bug.cgi?id=264264 looks like your issue but it has been duplicated and the other bug has been closed so you might want to reopen or open a new one
<ubotu> Gnome bug 264264 in Mailer "Crash: mouse grab freeze during mail DnD" [Normal,Resolved: duplicate]
<lifeless> thanks seb128
<seb128> you are welcome
<calc> mjg59: ping
<asac_the_2nd> ogra1: http://bazaar.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.7
<asac_the_2nd> ogra1: deb http://ppa.launchpad.net/asac/ubuntu hardy main
<emgent> heya *
<calc> anyone happen to know why the regular gstreamer plugins don't do mpegdemux, just the fluendo plugin?
<calc> is it a patent issue or something like that?
<calc> "The main difference between this and the plugin from gst-plugins-ugly is that this one allows demuxing of MPEG2 transport streams.
<calc> "
<hunger> q
<calc> seb128: i see the weather is a tooltip actually on the new clock but the temperatures seem off
<calc> seb128: it claims it is -20C in Houston, heh
<calc> that would be about like Hell freezing over ;)
<seb128> calc: it seems to be working for me
<seb128> calc: 3.6Â°C for Houston here
<calc> it actually says '-4.7F' i did the conversion in units
<calc> is there a way to force the clock applet to update (like there is in gweather)?
<seb128> not that I know
<seb128> 38.6Â°F for houston
<zul> calc: -20C is nothing
<calc> zul: in Houston it is
<calc> zul: Houston is probably > 15C right now
<zul> only :)
<calc> zul: ah well 3.6C anyway (its still early in the day there)
<calc> seb128: switching back to C it says -20.4C heh
<calc> seb128: oh i know what is wrong
<zul> calc: -9C outside where I am
<calc> seb128: i have to pick a timezone not a city, so its giving me the temp for chicago
<seb128> calc: picked the wrong houston?
<seb128> calc: hum? I picked the Houston Intercontinental Airport in the locations list
<calc> seb128: i am now more confused than before, i see what i did wrong finally
<calc> seb128: i picked America/Chicago and didn't even notice the "Find" button
<calc> oops
 * ogra1 is a bit irritated by all the popunder windows
<calc> hmm when i changed to Houston Intercontintental it changed my timezone setting
<calc> to Monterrey, not sure if that is the same as Chicago so I switched it back
<calc> works now though for temp :)
<calc> anyone else notice gweather (applet) complains about it can't find the xml locations file?
<calc> ah i see a bug is already filed
<pecisk> nautilus-connect-server will return soon? :) gvfs works nicely so far with ssh connections
<seb128> pecisk: no
<seb128> pecisk: gvfs does mounting now and the mounts are listed, gnomevfs worked differently
<pecisk> I see, but nautilus-connect-server dialog will be rewriten or something else will come?
<seb128> pecisk: not clear yet, you can read the mail sent by alex on the GNOME desktop list this morning on the topic
<bryce_> seb128: btw, that bug I showed you earlier appears to also occur with xterm, so is probably not gnome terminal specific
<pecisk> seb128: I quite don't get it. How someone will create connection to server?
<pecisk> ok, I will read all thread
<pecisk> thanks for info
<pecisk> :)
<seb128> bryce_: looks like a xorg issue ;-)
<bryce_> :-P
<seb128> pecisk: ctrl-L, enter your URI, the server is automatically mounted on first use and stay there
<seb128> pecisk: gnome-vfs didn't do this mounting so the connect server was an handy way to use the same URL again
<seb128> that was basically opening URI every time you used the shortcut
<pecisk> I see
<pecisk> but CTRL+L is somehow very cryptic for common user
<seb128> where now the mount stay there and is listed in all the applications during the session
<pecisk> you have to enter all parameters there
<seb128> not really
<seb128> if you can connect somewhere and a password is required it'll ask for it
<seb128> and you can browser smb shares
<pecisk> hmmm
<pecisk> yeah, I see know
<pecisk> now
<pecisk> when I think, this is much easier, I have to admit
<pecisk> only question how to create shortcuts to reuse connections - as launchers?
<seb128> pecisk: that is not done yet
<pecisk> ok
<pecisk> thanks for info, nice work guys
<seb128> you are welcome
<pochu> cjwatson_: hi. I'm still moderated in ubuntu-devel@lists.ubuntu.com. Could you please whitelist me? pochu@ubuntu.com. Thanks!
<Hobbsee> pochu: mail unmoderated, anyway
<MacSlow> mvo, having keyboard-shortcuts exposed in the window-action-menu needs a patch to libwnck, which would introduce a gconf-dependency
<MacSlow> mvo, I asked vuntz and he said it would be ok if I provide a configure/compile-time settable option for this
<mvo> MacSlow: where does it currently get the keyboard shortcuts from?
<MacSlow> mvo, not at all
<MacSlow> mvo, it's not exposing them in any way
<mvo> but when I right-click, I see "ALT-F7" here etc
 * MacSlow starts metacity...
<MacSlow> hm... metacity does maybe not use libwnck for the action-menu?!
<MacSlow> mvo, my gues was right... metacity does not use libwnck for the action-menu
<mvo> MacSlow: right. perhaps we should also move that into gtk-window-decorator then?
<MacSlow> mvo, I would like to fix that... I mean libwnck using gconf to obtain keyboard-shortcuts
<MacSlow> mvo, hm... no... I don't like that
<mvo> MacSlow: so that metacity would use it? yeah, that sounds better
<MacSlow> not that I want to patch metacity afterwards too to use it...
<MacSlow> just place stuff in the correct places
<MacSlow> mvo, argl... crap...
<MacSlow> mvo, retrieving the shortcuts from gconf will need to look for metacity- or compiz-specific keys explicitly
<MacSlow> thus it would be required to do window-manager-specific code in libwnck...
<stgraber> mvo: Are you aware of a bug causing aptitude and apt to produce lots of empty lines + confirming the upgrade/install (sort of simulating the enter key) ? (only happens when apt did "Calculating upgrade" or aptitude did "Building tag database" before)
<stgraber> I have it for quite some time now and managed to reproduce it on all my Hardy systems so far
<bryce_> kees, bug 184492 is being blamed on the gutsy xserver security update, but afaik the changes shouldn't have effected suspend at all...  can you take a look at this one and comment?
<ubotu> Launchpad bug 184492 in xorg-server "xserver-xorg-core update breaks suspend in gutsy" [Undecided,New] https://launchpad.net/bugs/184492
<bryce_> keescook: also bug 184869
<ubotu> Launchpad bug 184869 in xorg-server "ALT Super keys swapped after upgrade" [Undecided,New] https://launchpad.net/bugs/184869
<mpt> Keybuk, ExitStrategy involves a bit of kernel work now, so I'm not sure it belongs in the DesktopTeam/ wiki namespace
<slangasek> lool: wrt your changelog entry for the latest nautilus upload, is there any handling for older packages that require nautilus-extensions-1.0?
<slangasek> lool: I stumbled across this via totem, which is currently FTBFS because the build rules look for /usr/lib/nautilus/extensions-1.0; the FTBFS is an easy fix, but it set me to wondering about upgrade handling from older versions
<lool> slangasek: seb128 wanted to upload nautilus as fast as possible and said we would add the Breaks when the packages are actually ready
<lool> slangasek: The provides is just to be able to use Depends in the extensions instead of Breaks
<lool> slangasek: After the extensions have been uploaded, we should add a Breaks on the old versions in nautilus
<lool> seb128: ^
<slangasek> lool: alrighty; as long as it's on your radar then
<slangasek> in totem's case the nautilus extension is optional functionality, so I guess it should be exempt
<lool> Hmm that's a good point
<seb128> slangasek: it's optional functionality for most of the other packages as well
<seb128> slangasek: totem, file-roller, evince
<lool> We should use suggests or recommends then
<seb128> Recommends when apt will install those in Ubuntu
<slangasek> seb128: so do you want the breaks to apply to these packages?  they aren't really broken
<lool> We should suggests or recommends as we see fit but recommends wont work until apt supports them :)
<seb128> slangasek: no, that's why I uploaded nautilus yesterday
<slangasek> maybe we need [Depends,Recommends,Suggests] and [Breaks,Bruises,Inconveniences]
<lool> mvo: \o/
<lool> slangasek: But what about Build-Recommends and Build-Suggests?   :-P
<slangasek> heh
<Mithrandir> slangasek: I want "Stabs" as well.
<pitti> doko:    * lsb-cxx: Drop dependency on libstdc++5, not needed by LSB-3.1.
<pitti> doko: WOHOOO!
<pitti> doko: that sounds like we could drop gcc-3.3 to universe?
<doko> pitti: lets see; talked with Matt Taggert and Marc Tardiff about it.
<doko> pitti: please fix grub not to build with gcc-3.4 ;-)
<soren> kvm needs gcc-3.4, too.
<soren> Preemptive response to the inevitable "but that's not in main": Yet.
<slangasek> postemptive response: better fix that if you want it to be? ;)
 * doko will mention that in the MIR for kvm ...
<soren> with a bit of luck Fabrice will fix this within a few days.
<soren> (it's a qemu problem, really)
<doko> please check as well, if it does build with gcc-snapshot
<soren> It doesn't.
<\sh> seb128, would like to do me a favour and work on https://bugs.edge.launchpad.net/ubuntu/+source/libmicrohttpd/+bug/184400 It's a blocker for a sync
<ubotu> Launchpad bug 184400 in libmicrohttpd "[MoM SYNC] libmicrohttpd 0.2.0-1" [Undecided,Confirmed]
<slangasek> joejaxx: did TheMuso talk to you yet about getting the ubuntustudio-desktop seed changed for the libpt-plugins package name change?
<TheMuso> slangasek: No I had forgotten about that one, but I did talk to him about other seed related stuff, such as merging.
<TheMuso> The funny thing is, if it was me doing seeds, I would have jst done it. :)
<TheMuso> slangasek: joejaxx should be subscribed to get emails of seed changes, so he should know about that.
<joejaxx> slangasek: nojoejaxx@venus:~/ubuntustudio.hardy$ cat desktop | grep libpt * libpt-1.10.10-plugins-v4l * libpt-1.10.10-plugins-v4l2
<joejaxx> :)
<joejaxx> but i already made the changes the day it was made :)
<joejaxx> unless there was another change and i did not receive an email about it
<slangasek> joejaxx: that's the one, yes.  any chance it can be uploaded then, so I can make the old ones disappear? :)
<TheMuso> slangasek: Does that require a -meta refresh?
<joejaxx> yes :)
<TheMuso> Right.
<TheMuso> joejaxx: You do that, and I;ll do the -meta.
<joejaxx> TheMuso: ??
<pitti> doko: grub> ah, that
<slangasek> TheMuso: he said he already changed the seed, so isn't the -meta all that's left? :)
<TheMuso> slangasek: Yes, but I thought there was also other stuff to be done as well.
<TheMuso> for the studio seeds that is
<slangasek> ah, ok; nothing else from my end, dunno what else you guys have pending
<TheMuso> In any case, I'll do the meta. joejaxx if there is anything that I need to wait for you to do, plesae let me know now.
<TheMuso> please
<joejaxx> nope there is not :)
<TheMuso> joejaxx: Ok thanks.
<joejaxx> TheMuso: you are most welcome
<joejaxx> :)
<joejaxx>  /win 107
<joejaxx> klfjgkfjgk
<ion_> 107? Whoa.
<keescook> bryce_: odd bugs.  there was nothing in the CVE fixes that were related to video drivers...
<bryce_> keescook: well neither issue seems driver related
<bryce_> keescook: otoh, I can't fathom why those would have broken from the update
<keescook> yeah, and the 2nd one scares me a lot -- they have selinux enabled?  if so, their machine isn't running upstart.  who know what else is weird.
<\sh> hmm...will  synced "new packages" (not in ubuntu yet) from debian directly be delivered to the archives or are they just pushed like "new packages to ubuntu" into the new queue?
<slangasek> they have to go through binary new
<seb128> \sh: just did the syncs, the new sources will be in NEW but we usually accept debian packages to universe quickly
 * _MMA_ thanx seb128 for the Ardour sync.
<\sh> seb128, thx :)
<TheMuso> slangasek: About to upload the new meta now.
<TheMuso> So you can do what you were going to do.
<seb128> mr_pouit: around?
<slangasek> TheMuso: cheers :)
<mr_pouit> seb128: yes
<seb128> mr_pouit: I did demote to xfce to universe, could you close all the tasks?
<mr_pouit> seb128: ok ^^
<seb128> thanks
<seb128> mr_pouit: you can likely do it by mail like you opened the tasks ;-)
<mr_pouit> seb128: I hope so :p
<matteo> hi
<matteo> Now running lintian...
<matteo> E: amrenc_0.5.1~gutsy1_source.changes: bad-distribution-in-changes-file gutsy
<matteo> that's definitely a lintian bug
<lool> seb128: http://people.ubuntu.com/~lool/packages/cheese/2.21.5-0ubuntu1/hardy/cheese_2.21.5-0ubuntu1.dsc
<lool> seb128: thanks
<seb128> you are welcome
<sistpoty|work> matteo: yes. looks like lintian was synced from debian instead of merged
<ScottK> matteo: That's not a proper Ubuntu revision number
<ScottK> matteo: If it's ubuntu something it'll know about gutsy
<matteo> it's ubuntu hardy
<ScottK> It looks like a backport to Gutsy from Hardy.
<ScottK> It it's a sync from Debian, .changes should say unstable, and it'd be fine.
<jdong> should there really be a linux64 binary on i386 Ubuntu? :)
<sistpoty|work> ScottK: however lintian was synced from unstable... though I guess lintian doesn't know anything about gutsy, hardy etc. any longer
<ScottK> sistpoty|work: It does.
<ScottK> sistpoty|work: It just looks for an ubuntu revision before it remembers
<ScottK> sistpoty|work: Debian incorporated all the Ubuntu changes in their version.
<ScottK> sistpoty|work: If they missed a spot, then it's a bug.
<sistpoty|work> ScottK: oh, cool.. didn't know that :)
<ScottK> Now for backports, it'd be useful to have lintian look for either ubuntu or an ubuntu release name in the revision.
<\sh> seb128, one sync you forgot (it's also new to ubuntu but in debian): bug #184389 :)
<ubotu> Launchpad bug 184389 in ubuntu "Sync liboglappth from debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/184389
<seb128> \sh: synced
<\sh> seb128, thx a lot :)
<seb128> you are welcome
<Keybuk> mpt: it's probably easier to separate off the kernel work into a spec we can give to that team, and depending on it for various pieces
<mpt> Keybuk, ok
<mpt> (though it's only two sentences or so)
<jdstrand> msg NICKSERV help
<jdstrand> oops...
 * zul hands jdstrand a "/"
<jdstrand> thanks zul!
<CarlFK> something changed in the last 12 hours to cause Jan 23 19:14:40 main-menu[3081]: WARNING **: Configuring 'grub-installer' failed with error code 1   http://dev.personnelware.com/carl/temp/Jan23/b/log/syslog
<CarlFK> cjwatson: ping ^^^
<shaya> I'm wondering who is in charge of apt?
<shaya> or who knows its internals well?
<jdong> shaya: ask your question and see if we know the answer?
<shaya> want to know if there's some place I can look to see how apt does dependency management
<shaya> i.e. determining which set of packages is "good"
<shaya> for research project, don't want to reinvent the wheel
<shaya> want to credit debian/apt for the work
<ToyKeeper> shaya: You probably should just get the source and start reading...  with any luck, it may include enough documentation to answer your questions, but if not, the code shouldn't be too bad.
<desrt> dearest #ubuntu-devel, plz upload new flashplugin-nonfree package to gutsy!!
<desrt> my fingers are getting sore from explaining how to fix this to everyone
<lamont> slangasek: is it to late to ask for a sync of git-core from sid?
<rzr> desrt: ask louder ..
<Kmos> lamont: i think the feature freeze is only near 4th february
<ScottK2> Kmos: 14 Feb.
<Kmos> or that :)
<Kmos> so it now has a fixed date, nice.
<ScottK2> Kmos: It's been 14 Feb for a very long time.
<Kmos> ScottK2: ok
<Kmos> thx
<matteo> hi all
<matteo> where should I make a proposal about many packages?
<matteo> i'll explain
<matteo> newer dpkg supports other compression modes other than gzip
<matteo> it supports bzip2 and lzma
<matteo> using lzma with packages with docs will help a lot to riduce package size
<matteo> since text compresses very well
<ion_> Iâm quite sure dpkg and apt in Ubuntu support lzma.
<jdong> ion_: isn't that a hardy thing though?
<ion_> Most likely.
<matteo> yes, it's new in hardy
<matteo> btw compressing it's very slow
<matteo> but it's done once, in the buildd
<matteo> http://pastebin.ca/870179
<matteo> ~4MB saved on 26
<matteo> exactly 15%
<infinity> matteo: No need to "propose" it, we added the support for a reason.
<matteo> "we"?
<infinity> matteo: But we need to finish up infrastructure support before we start compressing anything with lzma.
<matteo> are you in the core team?
<jdong> matteo: he's buildd admin :)
<infinity> matteo: Err, I run the buildds, among other things.
<matteo> cool
<matteo> man bc
<matteo> oops
<matteo> it's good to hear that the ubuntu team often change things
<matteo> not being very conservative a-la-debian
<matteo> also, the slowdown with bzip2 isn't too much
<infinity> Debian's not all that conservative, per se, they just have more people to convince every time something changes.
<matteo> so it could became the default compress mode
<Mithrandir> matteo: uh, no.  It's much, much slower.
<matteo> Mithrandir: twice
<jdong> matteo: twice isn't much?
<jdong> matteo: I guess when compared to lzma ultra, sure...
<Mithrandir> it's not like people aren't complaining about unpack speed already..
<matteo> jdong: imagine how many things you can put in the ubuntu CD
<jdong> Mithrandir: lzma's unpack is in line with gzip IIRC
<matteo> unpack is ever fast
<jdong> definitely advertised by its author to be faster than bzip2
<Mithrandir> jdong: it needs more memory or something, I thought?
<matteo> just compressing is slow
<jdong> Mithrandir: no, less memory than bzip2
<jdong> Mithrandir: just compressing is a BEAST.
<matteo> but compression is made *once*
<jdong> right
<jdong> and we have control over the compression hardware
<matteo> the buildd make it, the it's just a mirror push
<infinity> Decompression of lzma is still memory-intensive, comparatively.
<mantiena-baltix> hi all
<mantiena-baltix> lool: hi
<infinity> Users with 4GB machines might not care, people with more conservative setups could be upset if we changed the default compression (so we won't)
 * Mithrandir yawns and wanders off to bed.  See you all tomorrow.
<infinity> The whole plan was to first change all the bzip2 packages to lzma (since that's an obvious win), then change some others where the space saving is too good to pass up.
 * sladen really should just do a modified version of gzip with larger dictionary support.  It would have 95% of the cases we actually want
<jdong> infinity: you're right, lzma levels 5 and higher are significantl more memory intensive then gzip
<matteo> qt4-docs needs 34MB to uncompress with LZMA
<matteo> that's on my system
<sladen> lzma decompress (_not_ compress) is basically  dictionary size + extra
<jdong> matteo: if we don't use level 9 to compress, it'd be a lot less
<matteo> so it's definitely not a memory issue
<jdong> matteo: hold on, 34MB decompression memory is not an issue?
<matteo> impressive, lzma unpacks faster than bz
<jdong> I'd say anything over 5MB is an issue
<matteo> jdong: why?
<jdong> matteo: on a minimal-requirements system, it would easily push into swap
<matteo> ubuntu reccomends minimum 265MB ram
<mantiena-baltix> sorry for disturbing, why you are talking about LZMA compression ?
<jdong> mantiena-baltix: yes
<sladen> bzip2 is ~2-4 * block size (900kB), so 4MB.  dictionary based (Deflate, LZMA) are going to win on decompression, with compression being an exp factor of dictionary size
<jdong> matteo: ok, so booted to GNOME you're already using 130 or so in DE, open Firefox is 50MB, add restrited modules in there you barely have 30MB left over
<jdong> matteo: and we *require* 64MB
<jdong> matteo: we suggest 192MB
<jdong> we only recommend 256 for desktop effects
<sladen> jdong: I would cap the LZMA dictionary at 4MB, 8MB tops
<jdong> sladen: agreed, unless the package significantly benefits and is only for high-end systems anyway
<mantiena-baltix> jdong: you answer is pretty short for question "why ?" ;)
<jdong> sladen: what's clear is that LZMA level 1 both compresses faster and better than bzip default....
<jdong> well always faster, most times better
<sladen> jdong: which is still 100x-200x the length for deflate
<matteo> http://pastebin.ca/870199
<jdong> sladen: oh I'm not gonna try to compete with deflate for resource usage :D
<sladen> jdong: that's what I'd expect.  lzma is a dictionary compressor; compression is a case of string matching
<sladen> jdong: bzip2 is a qsort of 900,000 strings of length 900,000 bytes
<matteo> quicksort?
<jdong> sladen: well can you show a deflate implementation with similar ratio to lzma without the resource usage?
<sladen> jdong: sure.  for only for a dictionary of  < 2^15
<matteo> you talks so much about decompression speed, ignoring completely download speed
<sladen> jdong: deflate has hard-coded 20 year old limits.  LZMA doesn't
<sladen> matteo: download *RAM* usage
<jdong> sladen: I see. Isn't deflate with a bigger dictionary more or less lzma?
<matteo> what's the problem with a 30MB usage?
<sladen> jdong: yes.  But the coding stage on the backend that saves another 1% is semi-heavy, and could be left as the plain Huffman used in Deflate
<matteo> apt uncompresses an archive at once
<sladen> matteo: ...requiring 30MB to unarchive it?
<matteo> and so?
 * sladen hands matteo a 128MB machine with a LiveCD
<mantiena-baltix> I have a simple question for any ubuntu developers - why wine packages in ubuntu gutsy and hardy are more than 3x bigger comparing with same wine packages in official winehq.com repository and also with older wine package from ubuntu feisty, edgy and dapper ?
<_MMA_> sladen: Be realistic. :P
<jdong> matteo: look you might not care about RAM usage just like how I am hooked up to 125MB/s internet and don't care about download speed :)
<jdong> matteo: but 30MB is quite extreme for decompression RAM usage
<sladen> _MMA_: what's unrealistic about that?
<sladen> the problem here is that 30MB _is required_.  Otherwise decompression is _impossible_
<_MMA_> jdong: So is having 80MB OO.o updates on dial-up.
<jdong> _MMA_: I agree. both scenarios are unwanted
<sladen> it is not using more RAM to make it go faster.  It is /necessary/ to have that much scrollback to copy and paste from
<jdong> _MMA_: but 80MB download at a slow speed is POSSIBLE , while having insufficient free RAM to decompress is not very possible
<jdong> _MMA_: it's not like if you feed it half the RAM it wants, ti'll decompress half as fast.
<matteo> it's always possble
<matteo> put something in the swap
<matteo> extract
<matteo> then restore it
<matteo> the kernel does daily milion times
<matteo> why can't we do once at setup time?
<jdong> matteo: what about an openoffice update? You'd have an update manager, a GNOME DE, plus whatever else the user has running
<_MMA_> Im just not always keep on holding back progress while worrying over 8 year old hardware.
<jdong> _MMA_: well IMO dial-up is 20-year-old hardware. :P
<sladen> _MMA_: "just works" means being compatible
<jdong> done.
<sladen> damn those 20Kbit/s connections people   ...via their mobile phone
<_MMA_> sladen: Just my opinion. You have to cut things off sometimes. Not Vista-like but at some point things should move along.
<_MMA_> If all you have is 128MB RAM use a Alt disk and Fluxbox.
<sladen> _MMA_: indeed, so I think that finding a trade-off using ~3MB-4MB of dictionary would be good
<jdong> _MMA_: it doesn't matter *WHAT* disk you use, an update later can easily require that you have 30MB RAM.
<jdong> _MMA_: and on a system like that, there's not much idle stuff you can just swap out
<mantiena-baltix> _MMA_: lots of people have slow connection in also in these days - for example in lithuania about 50% of internet users have slower than 128 kbit/s internet speed
<matteo> sladen: i can't immagine the kernel unable to allocate 30MB ram
<sladen> I've looked at many areas of compression within Ubuntu.   LiveCD, download-size, upgrade-minisize {size, download, time}, mirror size, ---the problem is that we can't optimised for all of them at once
<_MMA_> jdong: Hence my opinion that our minimum required RAM is more like 256. Thats really not so much to ask.
<_MMA_> s/is/should be
<matteo> and RAM is very cheap
<sladen> _MMA_: for X.  But not for a virtual server running Apache, that you might allocate 64MB to
<jdong> matteo: I have several special-purpose systems with 64MB RAM running Ubuntu
<jdong> matteo: and there's no reason why they should be unable to unpack linux-headers-generic now
<_MMA_> sladen: Still I fell thats a corner-case.
<mantiena-baltix> _MMA_: High Ubuntu RAM requiremens are because of putting ~35 MB of unneeded restricted modules in RAM
<sladen> RAM does not grown on trees.  It grows in fast-eastern-Asian fabs
<sladen> _MMA_: four corners, and you're trapping in a cage.
<_MMA_> :)
<jdong> mantiena-baltix: how do you propose storing them in license-compliant form? :)
<sladen> jdong: I thought they were pruned if the hardware wasn't present after boot
<jdong> sladen: nope
<jdong> sladen: all three nvidia.o's, at 10MB/each or so, are in a tmpfs
<jdong> sladen: it also adds around 2 secs to bootup
<mantiena-baltix> jdong: there are at least 2 very simple solutions:
<mantiena-baltix> 1. compile and store in RAM only these modules, which are really needed on that hardware
<mantiena-baltix> 2. after installation restricted modules could be stored into hard disk instead of tmpfs in RAM
<mantiena-baltix> almost nobody will need 3 nvidia modules at once
<mantiena-baltix> each takes about 9 MB of RAM
<jdong> mantiena-baltix: nobody, indeed, will use all 3 nvidia modules at once. the unused ones should certainly be removed from tmpfs
<jdong> mantiena-baltix: our packaging doesn't even allow 3 userlands to be installed side by side
<sladen> mantiena-baltix: (it _can't_ be stored onto the hardware disk => distribution in a linked form)
<mantiena-baltix> so, I can't install different nvidia-glx packages if I have 2 different NVIDIA video cards on my system, which require different nvidia-glx package ?
<jdong> mantiena-baltix: that's correct, they conflict each other
<matteo> sorry
<matteo> got disconnected
<matteo> i was sayng
<matteo> i work in the openwrt project
<matteo> and we use lzma in routers
<matteo> both kernel and rootfs
<matteo> our machines has usually 8,12 or 32MB ram
<jdong> matteo: well at boot time, you guys have full control over what's in the RAM (namely, nothing)
<jdong> matteo: if we compressed the kernel with LZMA, I'd have zero complaints
<matteo> and the rootfs?
<jdong> matteo: what if you guys packaged your updates in LZMA that needed a 16MB dictionary to unpack? Would the nat conntrack tables be happy?
<sladen> jdong: solution to the Nvidia issue might be to have a initramfs hook that causes a rebuild and adds a marker for which ones could be used
<mantiena-baltix> jdong: If nvidia-glx packages conflicts each other and, AFAIK, nvidia-glx packages also conflicts with ATI/AMD xorg-driver-fglrx package, I think I have simple solution for this situation
<mantiena-baltix> we don't need to link and put into tmpfs any of such modules until one of nvidia-glx or xorg-driver-fglrx packages is installed
<jdong> mantiena-baltix: true, they can't be used simultaneously
<mantiena-baltix> it's very simple to detect during boot time which of nvidia-glx or xorg-driver-fglrx packages is isntalled and link only needed nvidia.ko/fglrx.ko module or no modules at all if there are no nvidia-glx/xorg-driver-fglrx packages installed
<mantiena-baltix> how you like my idea ?
<bigon> does somebody know where http://paste.debian.net/47563 comes from?
<bigon> I have reinstalled my hardy machine yesterday and I get that now
<bigon> everytime I install something that call scrollkeeper
<mantiena-baltix> also we need to check if NVIDIA/ATI hardware is on that system - one simple command: lspci |grep VGA does this job
<mantiena-baltix> So, could anyone tell me why wine packages in ubuntu gutsy and hardy are more than 3x bigger comparing with same wine packages in official winehq.com repository and also with older wine package from ubuntu feisty, edgy and dapper ?
<mantiena-baltix> I think it's a bug
<mantiena-baltix> look at http://archive.ubuntu.com/ubuntu/pool/universe/w/wine/?C=S;O=D
<BlackDiamonds> could some one take a look at this bug -> https://bugs.launchpad.net/ubuntu/+source/linux-wlan-ng/+bug/185179
<ubotu> Launchpad bug 185179 in linux-wlan-ng "card is not recognized in live session" [Undecided,New]
<BlackDiamonds> and say if the proposed solution is possible ?
<mantiena-baltix> BlackDiamonds: I can look - I have linux-wlan-ng supported card now :)
<BlackDiamonds> is it usb ?
<mantiena-baltix> yes
<BlackDiamonds> the current work around on the problem is to install the linux-wlan-ng package on a livecd session and then unplug, then replug the device
<BlackDiamonds> this is really really annoying because the chipset is quite popular and a lot of people use it
<mantiena-baltix> yea, I meet with this problem too
<BlackDiamonds> I have been using work arounds for ages on various linux distros and it would be nice to finially see a solution to make it "just work"
<BlackDiamonds> the best solution for the long term would have some one recode the drivers to make it support all of the kernel wireless extentions and then have it in the kernel but that will take a while, I hope an effort will start when the chipset is no longer being used in new cards
<BlackDiamonds> mantiena-baltix, thank you very much for looking at the bug
<mantiena-baltix> BlackDiamonds: Don't thank me - I'm not official ubuntu developer - I think you should make a bugreport to include linux-wlan-ng package into official ubuntu CD
<BlackDiamonds> another bug report ?
<BlackDiamonds> wouldn't it be best to keep it on this bug ?
<mantiena-baltix> BlackDiamonds: I don't know - ask official ubuntu developers or search in wiki.ubuntu.com about this procedure
<BlackDiamonds> alright thanks
<BlackDiamonds> also any place to get an offical ubuntu developer ?
<mantiena-baltix> I think here
<Kmos> if some admin here.. the apport-retracer on datacenter is down..
<mantiena-baltix> cool
 * Mez points Kmos to #canonical-sysadmin
<Kmos> Mez: thanks
#ubuntu-devel 2008-01-24
<articpenguin3800> will ext4 ever be in ubuntu
<RAOF> Yes.  Your actual question is "will ext4 be in Ubuntu before it's in the mainline kernel".
<RAOF> To that question I don't have an answer.
<articpenguin3800> it got merged in 2.6.19
<articpenguin3800> and ty tso said the stable version will be in 2.6.25
<RAOF> Well, that suggests that Hardy+1 should have ext4 enabled, at least.
<articpenguin3800> prob wont be default though
<RAOF> Indeed.
<RAOF> I'm personally very happy for not-hugely-tested-for-many-years filesystems to not be default.
<articpenguin3800> to me its just ext3 with extents
<RAOF> So it'll need a few less years testing before it's well tested.
<BlackDiamonds> is there a dev roadmap somewhere so once can see the features planned for hardy ?
<RAOF> blueprints.launchpad.net/ubuntu is about it.
<BlackDiamonds> thanks again RAOF
<BlackDiamonds> also, while you are here, how do I find out which packages are in main and which ones are in restricted ?
<RAOF> apt-cache policy <pkgname> is a good tool
<BlackDiamonds> thank you once again
 * emgent night.
<\sh> moins
<\sh> pitti, ping seahorse, did you ever try it with a gpg smartcard reader?
<\sh> pitti, seahorse can't cache the keys passphrase...so it can't be used with a smartcard reader, or you set e.g. your keyid explicitly with (debuild syntax) -k'0x<yourkeyid>!' <- the exclamation mark is important
<\sh> pitti, the set keyid is not the keyid of the signing key on the card FYI
<pitti> \sh: smartcard> no, I don't have such a thing
<\sh> pitti, see :) and I'm hitted by this phenomenon...actually "don't cache passphrase" helps or setting -k'0xC098EFA8!' in my case..this will override gpgs default checking for a signature key
<slangasek> lamont: yes, it was too late then because I had left for dinner; it's not too late now because I'm in the office
<ogra> canonical, the company with the time shifting office ....
<StevenK> It's a feature
<ion_> I want a controllable time dilation field generator.
<RAOF> ion_: I'll go you halves!
<ion_> -EPARSE
<ion_> sh: Thanks for the information!
<\sh> pitti, I debugged a bit further...
<slangasek> tjaalton: can you clarify for me why linux-restricted-modules has introduced a new "dummy package for easy transition" that has never existed in Ubuntu before? (fglrx-amdcccle)
<\sh> pitti, it looks like that you need restart the pcscd (the daemon for accessing at least this reader)
<\sh> pitti, after that you get this output http://paste.ubuntu.com/3825/
<ion_> slangasek: IIRC the changelog said itâs for transition from the AMD debs.
<\sh> pitti, and then it works...but with pinentry and with no seahorse dialog
<tjaalton> slangasek: people are using the ATI installer generated debs, and upgrading to a new release fails
<tjaalton> slangasek: and debian does it too
<tjaalton> slangasek: I mean they have that package as well
<tjaalton> for the same purpose
<\sh> restarting session
<ion_> Away nicks ftw.
<tjaalton> slangasek: actually, I haven't checked what version numbers the ati debs use..
<tjaalton> but we have an epoch now, so it should upgrade nicely
<slangasek> tjaalton: ok; that was the speculation, but I wanted to confirm since the changelog/package description seemed ambiguous to me, thanks
<tjaalton> slangasek: yeah, mostly copied from debian :/
<\sh> pitti, it looks like that only gpg-agent works together with the pcscd nicely including caching of the smartcard pins
<\sh> pitti, with only seahorse-agent in this session it doesn't work
<davmor2> just wanted to say gvfs buggy but much better nice work :)
<soren> cjwatson_: Would you object in any way if I changed openssh to generate the host keys from the init script, if they don't exist instead of doing it at postinst time?
<coolbhavi> not able to change USB mouse to ps/2 mouse.. system is not recognising the mouse
<coolbhavi> please help
<TheMuso> coolbhavi: #ubuntu for support.
<\sh> cjwatson, ping console-data, you added with the last merge the decision-tree* targets in debian/rules right?
 * pitti defeats grub and does the hardy dance
<lool> doko: I think you were proposing using -Bsymbolic by default; a blog post on today's planet gnome might interest you: http://www.gnome.org/~michael/activity.html#2008-01-23
<lool> Hmm was mentionned yesterday as well
<slangasek> pitti: is the hardy dance less or more embarrassing than the warty dance? :)
 * Hobbsee waves to pitti.  finally caught up, have you?
<pitti> slangasek: I think it gets worse with every release
<pitti> hey Hobbsee
<\sh> infinity2, bug #183495 please share the crack pipe you smoked to realise your idea ;)
<ubotu> Launchpad bug 183495 in openbios-sparc "[FTBFS] openbios-sparc (1.0~alpha2+20070816-1) fails to build in hardy" [Medium,New] https://launchpad.net/bugs/183495
<doko> lool: yes, but it is -Bsymbolic-functions
<lamont> \sh: the only "workable" idea I've seen for something like 183495 is what palo does... and it's broken-ish
<\sh> lamont, for me it looks like that every idea we had to deal with those packages, is somehow broken-ish...and imho involves all the time a buildd admin to install/remove/or whatever it needs
<lamont> palo builds the offensive binary bit in the clean targetr.
<\sh> lamont, well this doesn't help when you don't have <insert your arch here you need to build <arch>-bios>
<\sh> lamont, well, adams idea would work if I would knew how to fetch an alien build-dep, e.g. i386 would build an Arch: all package, and the source pkg depends on the _sparc.deb...who do you do this in an automated environment?
<\sh> s/who/how/
<lamont> \sh: you have the requisite pieces of said alien-arch deb in the source package (since fetching the deb isn't reliably doable)
<\sh> lamont, so you upload first the source-package which builds the e.g. bios-sparc.deb on the sparc buildd and then you fetch it from sparc archive and push it into a new source package which build Arch: all packages...
<lamont> binary builds can't create source packages.
<\sh> lamont, the other way around...
<\sh> you need to create a new source package first, which uses the already available alien arch .deb to produce an Arch:all package
<StevenK> bryce:
<StevenK> Ooops
<ScottK> I would appreciate it if whoever is arvchive admin for today would please have a look at libetpan in binary New for dapper-backports.  It's the last manual step needed in the clamav backport to Dapper.  It's holding up the sylpheed-claws-gtk2 backport (depwait) and so the currently available dapper sylpheed-claws-gtk2 is not compatible with the current dapper-backports clamav.
<ScottK> Thanks.
 * lamont notes that (at least in gutsy) pciutils depends on a lib in oldlibs
<\sh> seb128, mr. ubuntu-gnome :) what can I say to gnome not always opening a window when an LVM device is generated by sbuild ?
<\sh> seb128, I just deselected all hotplug and other media to be appearing on my desktop...but LVM devices are just popping up like mad
<seb128> \sh: no idea, might be a gvfs thing
<\sh> seb128, any idea where I can plug my brain in and find a solution to stop this annoyance? in some hidden gconf settings eventually?
<\sh> seb128, it's the gvfs mounttracker who receives the dbus messages..and act on it...where can I adjust those settings?
<seb128> \sh: not sure you can, gvfs is really new
<seb128> \sh: can you describe how to trigger the bug?
<\sh> seb128, well, use sbuild with LVM and start building a package...sbuild will create a snapshot lvm mount it and voila...you have a window with the contents of this mount
<ion_> Yeah, Nautilus seems to open a new window for everything that is mounted now.
<ion_> If i go to sftp://foo and gvfs mounts it, in addition to the active Nautilus opening it, a new window is opened as well.
<\sh> seb128, which is in fact a normal behaviour for normal mounted devices, but using snapshots this can be annoying
<\sh> seb128, forget my statement about "normal behaviour" Re: ion_
 * lamont stabs at cdbs
<pitti> mmmm cdbs :)
 * Hobbsee stabs at lamont
 * ion_ stabs at Hobbseeâs knife
<\sh> pitti, saw my comment about seahorse? (filed a bug btw) I removed seahorse from Xsession.d now and back to gpg-agent
<pitti> \sh: no, I didn't saw it
<pitti> and I'm not really a seahorse expert unfortunately
<lamont> pitti: I mean, what's so hard about writing an actual makefile that people find the need to bury everything under magic callback hooks that are burried 4 levels of included-makefiles away?
<pitti> lamont: because we rather change build policy at one place rather than in 500 source packages
<Hobbsee> ion_: i don't have a knife.  i don't *need* a knife.
<\sh> pitti, well, this regression will hit everybody who is using a gpg smartcard (e.g. some of FSF people do) (bug #185563)
<ubotu> Launchpad bug 185563 in seahorse "[hardy] seahorse agent doesn't work with gnupg smartcard readers" [Undecided,New] https://launchpad.net/bugs/185563
<lamont> pitti: never mind reviewing those packages to make sure it's the right change, etc. :-)
<pitti> lamont: stuff like fixing translation domains, producing .pot files, symlinking gnome help files, etc.
<pitti> lamont: with your argument you can also argue that using debhelper is bad because you don't see the raw commands that are executed
<pitti> also, what's the point of writing 50 lines of boilerplate every time?
<lamont> pitti: the best thing I can say about cdbs is "it's not DBS"
<lamont> or rather, "It's a vast improvement  over DBS"
<slangasek> gar, is there any way at all to remove an update-alternatives slave without removing the master?
<lamont> slangasek: vi?
<lamont> or were you meaning in a postinst?
<slangasek> lamont: you mean /usr/share/cdbs/1/class/vi.mk?
<slangasek> yes, in a postinst
<lamont> hrm.. that would tend to lead one to really wanting to use update-alternatives, wouldn't it.
<lamont> sed would be bad. :-)
<slangasek> don't tempt me
<slangasek> sed is my weakness
<pitti> use perl then :-P
<lamont> or patch update-alternatives?
<Mithrandir> lamont: cdbs solves a completely different problem than DBS does.
<Mithrandir> slangasek: remove both, reinstate the master?
<slangasek> pitti: "it's my weakness" as in "I can't resist it"
<slangasek> Mithrandir: that would kill the user's selections
<Mithrandir> slangasek: you could save it..
<pitti> soren: hm, building kvm-source now changed kvm from hanging in X to immediately segfaulting
<slangasek> Mithrandir: apparently I can get away without doing that, I can just take over the slave name with a new path and it DWIM
<soren> pitti: Ping me when you're back at your seat.
<seb128> \sh: you can unactivated the new mounts window opening in the media tab in the preferences dialog
<\sh> seb128, I did already...doesn't help
<seb128> weird
<\sh> seb128, yepp
<\sh> seb128, I can see some hal rules which are triggering that...
<\sh> seb128, and I don't know if they are handled like removable or hotplug media
<seb128> no idea
<asac_the_2nd> ANNOUCE: network manager 0.7 for hardy in my ppa ... it could deserve some moderate testing. remember to get the packages it would upgrade to your cache so you can downgrade without network in case it breaks :)
<asac_the_2nd> https://edge.launchpad.net/~asac/+archive
<seb128> require debugging and I've no similar setup nor willing to configure sbuild only to look at that we have a lot of other issue which impact on normal desktop use
<Hobbsee> asac_the_2nd: are they working for at least 1 user already?
<seb128> asac_the_2nd: that one has the dbus configuration?
<seb128> Hobbsee: I'm running it since this morning without issue
<Hobbsee> cool, OK
<tjaalton> sweet, fedora will use upstart
<asac_the_2nd> seb128: yes ... it should be fine by now
<asac_the_2nd> Hobbsee: sure :) ... i guess a single person can live without network :)
<Hobbsee> hehe :P
<asac_the_2nd> soren: ready?
<soren> asac_the_2nd: I just finished the un-cancellable stuff,yes.
<soren> asac_the_2nd: And you want me to make sure that I have packages for my current existing network-manager, libnm-util, and wpasupplicant around?
<soren> asac_the_2nd: Ok, here goes nothing.
<tjaalton> asac_the_2nd: the new n-m failed on my laptop, doesn't recognize the devices at all
<emgent> keescook, ping
<emgent> hard idle :Â°
<keescook> emgent: pong, hi!
<emgent> heya :)
<emgent> all good? :)
<emgent> malone 173153
<ubotu> Launchpad bug 173153 in audacity "[CVE-2007-6061] Denial of service and deletion of an arbitrary directory tree via symlink attack" [Undecided,Confirmed] https://launchpad.net/bugs/173153
<emgent> gutsy feisty e dapper ready, when you have time to upload, rembmer :P
<ion_> sh: Yay for ruby1.9! Thanks for merging. :-)
<\sh> ion_, hope it works
<lool> slomo: Do you have the libsoup2.4 2.3.0~r1050 tarball around?  I'd like to push it to hardy
<simon360> anyone here able to give me some help? I want to replace grub with gfxboot on the live CD, so the installer won't install grub, but will install gfxboot instead
<simon360> I also need a bit of help making a gfxboot theme :\
<simon360> and am somewhat noobish at developing :P , although I've been a Linux user for a few years
<_MMA_> simon360: Reconstructor is the easiest way to do this.
<pitti> soren: almost, but not quite...
<soren> pitti: Erm... I'm sorry to hear that.
<soren> No biscuit?
<pitti> soren: I see the desktop, but no panel, etc.
<simon360> _MMA_: I'm using reconstructor, but it doesn't replace grub with gfxboot afaik
<soren> pitti: -ESOMEBODYELSESPROBLEM
<soren> pitti: I blame seb :)
<pitti> soren: I don't think so; the screen is cut off at the top
<pitti> soren: the window is too small to see the entire screen, and I can't scroll
<simon360> I have a simple gfxboot theme already, but I had something fancier in mind...
<simon360> just a sec
<simon360> http://img.skitch.com/20080124-g184as8q142wb4b82kq66jnhag.png
<simon360> would something like that be easy/possible?
<simon360> I know how to change the text, colors, backgtround, etc.
<simon360> but moving the menu to the right is something I haven't figured out
<_MMA_> simon360: The Ubuntu Forums #ubuntu-derivative or maybe #ubuntu-installer might be better places for this.
<simon360> alright, thanks
<calc> _MMA_: pitti said that we can demote ooo language-support-* depends once apt autoinstalls recommends
<calc> _MMA_: so not yet but soon hopefully
<_MMA_> calc: Awesome. Should shave a bit off Xubuntu and Ubuntu Studio disks. :)
<somerville32> calc: Moving to Universe is not a demotion :P
 * somerville32 makes posters to help spread the new paradigm.
<_MMA_> somerville32: He's just talking about moving deps. Not actual packages.
<somerville32> haha, sorry, hair trigger ;]
<_MMA_> Yeah. Holster that thing. ;)
<\sh> seb128_, this is really annoying...we need to fix that behaviour...
<seb128_> you are welcome to send a patch, nobody else ran into the issue yet
<seb128_> need to go to dinner now
<Kano> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/151974
<ubotu> Launchpad bug 151974 in xserver-xorg-video-ati "[RV410] X700SE [1002:5e4f] - DRI images corrupted" [Undecided,Confirmed]
<Kano> does anybody like to compile a new mesa for gutsy?
<\sh> pitti, can you check this: http://pastebin.ubuntu.com/3838/ (this is send out from dbus when a snapshot lvm device comes up, and I don't find anything in lshal about it)
<calc> somerville32: not moving to universe, moving from Depends to Recommends
<slomo> lool: sure... one moment
<slomo> lool: http://slomosnail.de/~slomo/temp/libsoup2.4_2.3.0~r1050.orig.tar.gz
<slomo> lool: i hope it gets accepted in debian soonish
<\sh> I wonder if it's a sane setting for nautilus to set preferences->media_automount_open to false or to fix nautilus not to open local mounted devices, especially lvm snapshots
<keisangi> hi there
<keisangi> i have a problem with ubuntu 7.10 on my lenovo thinkpad x60,
<Seveas> keisangi, support in #ubuntu
<keisangi> inside eclipse, i have choppy sound and no keyboard responses
<keisangi> i'm developping a game in java using lwjgl/slick2d
#ubuntu-devel 2008-01-25
<Seveas> keisangi, this channel is for development *of* ubuntu, not *on* ubuntu
<keisangi> i tryed other distro, like zenwalk-linux (slackware based distro) and everything seems works
<keisangi> Seveas, yes, but i wont get any help on #ubuntu channel about this particular problem ..
<Seveas> keisangi, that doesn't make this a support channel
<keisangi> i don't know where to ask
<Seveas> !support | keisangi
<ubotu> keisangi: the official ubuntu support channel is #ubuntu. Also see http://ubuntu.com/support and http://ubuntuforums.org
<keisangi> Seveas, ok, could you point me to a support channel where i could discuss eclipse , java and ubuntu ?
<Seveas> #eclipse and #ubuntu come to mind :)
<keisangi> they will tell me to go to #lwjgl
<keisangi> #Eclipse will tell me to see with #ubuntu
<keisangi> everyone try to dodge the stinky problem ;)
<Seveas> well, #ubuntu it is then :)
<keisangi> i said two line earlier that #ubuntu ppl are likely to tell me to go to #lwjgl or #eclipse
<crimsun> (there's #ubuntu-java)
<keisangi> crimsun, ah nice
<keisangi> i try this one
<keisangi> thanks
<jdong> crimsun: ooh you appeared! Could I bug you to sponsor another new transmission?
<crimsun> url?
<jdong> bug #185292,
<ubotu> Launchpad bug 185292 in transmission "Please update to 1.02" [Wishlist,Confirmed] https://launchpad.net/bugs/185292
<crimsun> jdong: ACKed.
<jdong> crimsun: thanks :)
<BlackDiamonds> if it's in main, it's supported by offical devs right ?
<jdong> what are "official devs"?
<BlackDiamonds> people with an @ubuntu.com address
<jdong> All Ubuntu members have an @ubuntu.com address; developers are a small subset of this group
<BlackDiamonds> oh what ?
<BlackDiamonds> what is an ubuntu member then ?
<jdong> BlackDiamonds: http://www.ubuntu.com/community/ubuntustory/components should answer your question about main vs universe
<jdong> And http://www.ubuntu.com/community/processes/ about members, developers, etc
<lamby> Why is the ubuntu-devel mailing list moderated?
<elmo> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
<lamby> Well, that does not help to explain why my post was discarded, dispite it seeming to match the criteria.
<lamby> I will repost to -discuss.
<LaserJock> lamby: I doubt it was discarded, probably just stuck in the moderation queue
<lamby> I will repost anyway, I don't have the time to watch the archives to see whether it's accepted or not.
<LaserJock> that reminds me ...
 * LaserJock wanders off to look at the latest fun on -discuss
<nxvl_work> does the Developer Sprint is taking place?
<nxvl_work> or this development circle there was no one?
<yo> can someone help me with ver 7.1?
<jdong> Can someone confirm/explain why sudo seems to forget environment variables?
<gQuigs> can I confirm my own needs-packaging bug (185804) or does it need something else?
<gQuigs> https://bugs.launchpad.net/ubuntu/+bug/185804
<ubotu> Launchpad bug 185804 in ubuntu "[needs-packaging] BadRAM Linux Kernel Patch" [Undecided,New]
<ScottK2> gQuigs: Packaging questions in #ubuntu-motu
<gQuigs> oh..oops
<pitti> Good morning
<gaspa> 'morning -.-
<pitti> \sh_away: that looks like a gnome-vfs message, not sure where it comes from; maybe check with seb128?
<\sh> seb128, the problem from yesterday was a result of nautilius -> preferences -> media_automount_open = True (gconf setting) this happens with all devices which are just mounted but not handled as special devices...
<seb128> you told me that this key was set to wrong yesterday?
<pitti> mathiaz: your patch in bug 52866 looks ok; can you please upload?
<ubotu> Launchpad bug 52866 in php5 "SOAP response for associative array is different on ubuntu 6.06" [Undecided,In progress] https://launchpad.net/bugs/52866
<\sh> seb128, nope...I never said this...I was thinking something strange happens...and I tracked it down to this setting...set this key to False everything is fine...and only the symbols are on the desktop (despite the fact that some of them are staying on the desktop after unmount)
<seb128> I told you to change the key in the preferences and you said you already did that and that didn't change anything
<\sh> seb128, this was the setting in System -> Preferences -> Removable Media which I disabled...but this didn't help...I think the preferences dialog comes from gnome-volume-manager or whatever we use, but not from nautilus
<\sh> seb128, the real solution is to set the nautilus gconf key to false...
<lool> slomo: Thanks!
<\sh> seb128, as far as I could track down the problem (reading gnome-volume-manager source and nautilus-application.c) those two are involved when mounting devices. gvm handles special devices like usb/ipod/cd/dvds but not e.g. /dev/sdb3 when it's mounted manually...
<seb128> \sh: the key you describe is the one I told you to change yesterday
<seb128> \sh: it's the browse media when inserted in the nautilus preferences, media tab dialog
<seb128> \sh: I just verified it does change the gconf key
<\sh> seb128, well then I didn't understand you correctly...I meant the global preferences for media
<seb128> alright
<seb128> but I wrote that it was the nautilus dialog
<\sh> seb128, then I didn't see "nautilus" ... after so many windows popping up
<pitti> dholbach: Alter!
<dholbach> pitti: ALTER!
<pitti> dholbach: do you know what p-lp-bugs does when a bug has multiple source packages?
<pitti> dholbach: i. e. bug.sourcepackage
<dholbach> pitti: I find it more accurate to look at all bug tasks and see what their bug status, source packages, etc are
<dholbach> pitti: bug.infotable
<pitti> dholbach: right; can I iterate over all of them?
<pitti> aah
<dholbach> pitti: for task in bug.infotable
<pitti> rock'nroll
<dholbach> pitti: you can branch http://people.ubuntu.com/~dholbach/sponsoring/ for an example
<pitti> cool, looking at it right now
<pitti> dholbach: rock, it works, I just wrote a pitti-o-matic-sync-bug-bitch script
<dholbach> pitti: party on
<emgent> moin
<davmor2> pitti:  would gvfs cause gnome-mount to have issues?
<seb128> davmor2: why should it?
<pitti> davmor2: unknown ATM, but it worked fine for me yesterday
<pitti> davmor2: --verbose?
<seb128> davmor2: gnome-mount doesn't use gvfs yet
<davmor2> I've updated my main system to hardy as I no longer need a stable system so I can play
<davmor2> I was putting my favourite cd's back into rhythmbox and gnome mount kept giving me errors bug 185748
<ubotu> Launchpad bug 185748 in gnome-mount "gvfs/gnome mount issues with stability" [Undecided,New] https://launchpad.net/bugs/185748
<davmor2> I took a screenshot it's on there
<davmor2> also the cd would lock up about 3 cd's in
<seb128> davmor2: how a cd can lock up 3 cds?
<seb128> I'm not sure I understand what you describe
<davmor2> sorry the thirdish cd would lock up
<seb128> no idea about that
<seb128> is that data or audio CDs?
<davmor2> rhythmbox converts the cds to ogg on the thirdish cd it would just stop at some point I would have to restart the system to free up the disc again
<seb128> davmor2: doesn't seem to be a gnome-mount issue, rather a nautilus one
<davmor2> seb128:  It also happens with my usb pen.  so much of the data copied across fine then it just stopped.  This didn't happen on my test system when gnome-vfs was inplace.
<davmor2> locking up that is (sorry not clear again)
<seb128> looks like a gvfs or nautilus bug
<seb128> do you get the issue using gvfs-copy ?
<davmor2> I had no issues using sftp in nautilus to copy the files I wanted off my other machine rather than trying from the usb
<davmor2> seb128:  How and I'll try it?
<TheMuso> I'm triaging casper bugs, and I have found one that referrs to xforcevesa. This doesn't appear anywhere in casper, so what package takes note of this kernel command-line flag?
<seb128> davmor2: dunno what you are copying, but it's basically "gvfs-copy source destination"
<davmor2> seb128: np will try now
<pitti> \sh: please use standard requestsync in the future, and be more accurate about the source (dcc isn't in unstable, etc.)
<\sh> pitti, ah well, you commented on it, that it was moved in the past
<davmor2> seb128: gvfs-copy command not found ?
<\sh> pitti, and that you wanted to move it into multiverse
<seb128> davmor2: sudo apt-get install gvfs-bin
<warp10> dialign-t-doc is in Debian non-free because documentation is missing source. It must be synced in multiverse, right?
<pitti> \sh: done that, and synced
<Kmos> warp10: if section on control is non-free, it automatically goes to multiverse :)
<\sh> pitti, thx :)
<davmor2> seb128: right installed but it can't recursively copy a directory
<pitti> Kmos: ('automatically' is not quite true...)
<pitti> warp10: that doesn't sound quite right
<pitti> warp10: it would be in non-free because the doc has a non-free license
<pitti> warp10: if it was gpl with no source, then it is unredistributable and can't go to non-free/multiverse either
<Kmos> pitti: the sync script doesn't check for non-free and contrib ? i think it did =)
<warp10> pitti: well, according to debian/copyright it is released under LGPL, but source is not available. I check it with debian maintainer too, his answer was: "dialign-t-doc is in non-free because it is missing sources"
<pitti> warp10: that's wrong then, and it should be removed from Debian
<davmor2> seb128: I'm trying the individual tar.gz file it seems to lock up on instead
<seb128> what do you mean?
<warp10> pitti: wow, too bad! Well, I'll avoid to request a sync in Ubuntu, therefore
<persia> pitti: pdfedit works too :)
<pitti> persia: not the prefered form of modification
<persia> pitti: I disagree that that is always the case, having used pdfedit to generate new files in the past, but suspect you are correct in this case (and the vast majority of others).
<davmor2> seb128: I have a folder full of tar.gz files that I backed up (evolution etc)  I can't copy the folder so I'm coping the file where it seems to lock up.
<seb128> davmor2: "lock up" = hang?
<davmor2> yes sorry
<seb128> use the --progress option maybe to know if it's copying
<davmor2> seb128: It's hanging again and I can't access the pen drive now
<seb128> looks like a gvfs bug then
<davmor2> is there any wat I can help find out what?
<seb128> ps ax | grep gvfs ?
<ion_> UUOps ;-)
<ion_> pgrep -l gvfs
<seb128> ion_: ?
<seb128> ion_: what is your point there?
<ion_> Nothing serious. Just repeating the popular UUO* meme.
<davmor2> 10823 ?        D      0:00 gvfs-copy /media/disk/docs-backup.tar.gz /home/davmor2
<seb128> what is UUO?
<ion_> <foo> cat foo | wc -l  <bar> UUOC! wc -l foo   (Useless Use Of Cat)
<davmor2> seb128:  If I reboot and try the --progress will that tell me where the hold up is?
<ion_> http://www.catb.org/jargon/html/U/UUOC.html
<seb128> ion_: ah, didn't know about that, learning every day ;-)
<davmor2> seb128:  I noticed too that the trash applet isn't showing trash any more either it is in the folder
<seb128> davmor2: not really, no need to reboot, you can likely kill gvfsd
<seb128> davmor2: known issue, will be fixed with the new gnome-applets tarball
<davmor2> okay thought it would be
<seb128> the trash location changed, gio is using the freedesktop one
<davmor2> seb128: Just tried killing 10823 nothing happened.
<ion_> Would it be possible to move /lib/udev/watershed to some directory typically in PATH? watershed is useful for many other things than just udev. For instance, i have /lib/udev/watershed a-podcast-fetcher in my crontab.
<seb128> davmor2: try using -9?
<davmor2> seb128: no
<davmor2> seb128:  I just checked system-monitor it says it's uninterruptible
<Mez> who maintains PHP in ubuntu?
<pitti> Mez: server team (soren, dendrobates, keescook, some others)
<pitti> Mez: mathiaz, too
<Mez> ah, well, we've found an issue here :D
<Mez> broken functionality :D
<Mez> definately worth a patch for LTS, and hopefully for SRU too :D
<aquo> can anybody tell me what /var/lib/dpkg/available is used for?
<mathiaz> Mez: did you file a bug in LP ?
<Mez> mathiaz, not yet -
<Mez> we're getting it into upstream first (I work with one of the main PHP devs - he's fixing it atm)
<mathiaz> Mez: excellent !
<Mez> mathiaz, :D It's a one line fix - but he's testing it
<mathiaz> Mez: please file a bug in LP, and put a link to the upstream php bug and patch.
<Mez> mathiaz, I will do :D though whether he creates a bug ...
<pitti> BenC: can you please send me your hal debdiff, so that I can check it into bzr?
<Mez> mathiaz - it's pretty rare, and has been there for 2 years at least
<lool> asac_the_2nd: Hmm NM just prompted me for a password it should have known about; perhaps because it couldn't associate and thought this might be because of a password mismtach
<davmor2> seb128:  right rebooted so I can use my system again.  How do you want me to file the bug and what against?
<seb128> davmor2: open it against gvfs but I doubt we have enough informations to make anything useful from it at right now
<aquo> is apt-get update; apitude safe-upgrade the same as aptitude update; apt-get upgrade?
<davmor2> seb128: no problem
<persia> aquo: No.
<aquo> persia: uhhh. that is not good.
<aquo> if i want to use aptitude for package management this interferes with the apt-get that is used in periodic scripts ...
<aquo> (unattended-updates, cronjobs)
<persia> aquo: The difference isn't with "update", but with "upgrade".  For details, check the source, or search for some of the early documentation on why aptitude.  This isn't really the forum for longer discussion of the differences.
<aquo> persia: so apt-get update and aptitude update produce the same system state?
<aquo> i know that there are differences with the recommends on so on with aptitude ...
<persia> aquo: SImilar enough to not be worth discussion.  I don't remember if it is the same.
<aquo> i am just curious if the use of apt-get update in cronjobs needs to be replaced by aptitude update if i want to use aptitude.
<unop> aquo, in my opinion it is you can use anything you like apt-get, aptitude, dselect, dpkg, synaptic -- they all work on top of APT, and it shouldnt matter what you use
<aquo> in apt: /etc/cron.daily/apt
<davmor2> seb128: bug 185904 is there any thing else you want adding to it?
<ubotu> Launchpad bug 185904 in gvfs "GVFS:  Unable to copy tar.gz backed up data from pen drive" [Undecided,New] https://launchpad.net/bugs/185904
<aquo> so apt-get update; aptitude safe-upgrade is the same to aptitude update; aptitude safe-upgrade?
<aquo> dpkg doesn't work on top of apt in my opinion
<seb128> davmor2: having backtraces of gvfsd and gvfs-copy would be nice
<unop> aquo, safe-upgrade does not remove packages when situations warrant removing certain packages to upgrade others -- the aptitude manpage has more
<davmor2> seb128: how or wher do I get them?
<aquo> un_op: i am not asking about the upgrade process, i am interrested in the update progress?
<seb128> davmor2: https://wiki.ubuntu.com/DebuggingProgramCrash
<aquo> unop: i know that
<unop> aquo> so apt-get update; aptitude safe-upgrade is the same to aptitude update; aptitude safe-upgrade?
<unop> aquo, ^^ no
<unop> oops
<unop> sorry misread
<unop> aquo, i'm inclined to say yes here
<davmor2> seb128: ta
<seb128> you are welcome
<mvo> unop: yes, apt-get update/aptitude update behave the same
<aquo> unop: no problem, i am just curious on how package management works
<aquo> mvo: so they are interchangeable, and i don't have to run aptitude update if i have the cronjobs that are included in apt
<unop> aquo, well, i used to think aptitude was a better apt-get (atleast when i was with debian) but with ubuntu, the line that seperates the two is somewhat different, essentially they serve the same purpose and are quite interchangeable
<mvo> aquo: yes
<mvo> unop: the only real difference left is that aptitude has a nice ui, a different problem resolver (and in ubuntu that it installs recommends-by-default)
<aquo> thank you for that information.
<unop> mvo, yes, and autoremoves unneeded depenencies when a package is removed (something like apt-get autoremove ..)
<pitti> ScottK2: stepic> hm, what's the purpose of this when the changes are machine detectable? isn't the purpose of steganography to hide data repudiatably?
<pitti> thekorn: AssertionError: Wrong XPath-Expr in InfoTable.parse() 'type' (https://launchpad.net/bugs/122396)
<ubotu> Launchpad bug 122396 in poppler "[apport] evince-thumbnailer crashed with SIGSEGV in CairoFont::create()" [Medium,Confirmed]
<pitti> any idea?
<thekorn> pitti, not right now, but will check in a moment
<pitti> thekorn: thanks a lot
<mvo> unop: right, but the auto-remove information is unified
<pitti> thekorn: ah, seb128 just mentioned that this happens with bugs which have an upstream task
<asac_the_2nd> mbiebl: hi, did you find some time to take a look at my nm 0.7 eni branch yet?
<asac_the_2nd> mbiebl: https://code.edg.launchpad.net/~asac/network-manager/main.eni
<asac_the_2nd> ups
<asac_the_2nd> ;)
<mbiebl> hi, asac_the_2nd
<asac_the_2nd> i think you figure
<thekorn> pitti, ok, then it might be fixed in the .main branch
<mbiebl> The current checkout doesn't compile...
<mbiebl> I had a missinge eni-private.h something...
<asac_the_2nd> hmm ... let me see
<asac_the_2nd> which revision?
<mbiebl> 2757
<mbiebl> eniplugin-internal.h that is
<asac_the_2nd> mbiebl: ok ... let me push the revision I used to build the preview package (i didn't include the system settings daemon yet)
<thekorn> pitti, it is bug 184594
<ubotu> Launchpad bug 184594 in python-launchpad-bugs "AssertionError: Wrong XPath-Expr in InfoTable.parse() 'type'" [Undecided,Fix committed] https://launchpad.net/bugs/184594
<mbiebl> Have you read my email, about getting the Debian and Ubuntu closer in sync again?
<asac_the_2nd> mbiebl:  damn ... now i remember why i haven't pushed yet. that branch is locked for 68 hours. apparently that doesn't go away automatically
<pitti> thekorn: ah, thanks
<asac_the_2nd> mbiebl: i am currently in uk and my alicedsl connection went down 30 minutes after i left my house ... can read it earliest this weekend
<asac_the_2nd> mbiebl: but yes, i am all for it ... i hope we can submit most patches we need for 0.7 upstream so we should be more in sync
<mbiebl> asac_the_2nd: would be great.
<pitti> thekorn: subscribed; I'll roll it out to the retracers once it's fixed in hardy
<mbiebl> especially the sysv init related stuff is already in the Debian NM 0.6 package.
<asac_the_2nd> mbiebl: and we could review what we have and why you don't need it ... if you are interested.
<mbiebl> Yeah, would be cool if we could discuss this.
<asac_the_2nd> mbiebl: https://edge.launchpad.net/~asac/+archive ... there is the 0.7 package we currently use to evaluate it
<mbiebl> asac_the_2nd: Well, as people requested it, I had built 0.7 packages for Debian also, some time ago.
<mbiebl> http://debs.michaelbiebl.de/networ-manager
<asac_the_2nd> mbiebl: https://code.edge.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.7 ... thats the packaging branch we have
<mbiebl> I'll start this weekend to push this version to the pkg-utopia svn in the experimental branch.
<mbiebl> asac_the_2nd: while at it, we had a short discussion on #pkg-utopia, about starting dbus earlier and stopping it later.
<mbiebl> Something around S10/K90.
<asac_the_2nd> i have no problem with that ... we start nm at 26 or something for now ...
<mbiebl> This would make it also possible to stop NM later during shutdown.
<asac_the_2nd> mbiebl: you need to bump soname
<asac_the_2nd> mbiebl: hmm ... now that i think about it ... do we need to stop it at all?
<mbiebl> Well, think for the scripts in if-*.d/
<mbiebl> They wouldn't be run otherwise.
<mbiebl> Another problem, that is currently nagging me, is how to handle network-manager upgrades.
<aquo> mbiebl: will the new NM include features for running user-independent?
<asac_the_2nd> aquo: when its finished ... yes.
<asac_the_2nd> mbiebl: in which regards? restarting the applet?
<mbiebl> No, the problem that the internet connection is dropped when you restart NM.
<asac_the_2nd> mbiebl: yes ... that will change once we have system connection support
<mbiebl> Is a bit unfortunate if you upgrade a system via SSH ;-)
<mbiebl> asac_the_2nd: don't think so.
<mbiebl> NM will still tear down the connection on stop afaik.
<asac_the_2nd> mbiebl: hmm ... i haven't looked into lately, but we should really take care that this is not done anymore for system configured connections ... same for "tearing down at startup"
<asac_the_2nd> mbiebl: have you asked dan williams about his vision for this? fedora must have the same issue
<mbiebl> What do you mean by that?
<mbiebl> asac_the_2nd: fedora never restarts daemons on package upgrades ;-)
<asac_the_2nd> mbiebl: network manager does not only not stop interfaces if you stop it ... it also brings them down and up again if you start it.
<mbiebl> You mean it tears down a connection configured via ifupdown?
<asac_the_2nd> mbiebl: yes it would ... but we don't manage those through nm in ubuntu (to workaround  this issue)
<mbiebl> So, you want to have ifupdown establish a connection and then hand it over seamlessly to NM or what?
<asac_the_2nd> mbiebl: but thats independent from ifupdown ... it will always bring all interfaces down it wants to manage on startup. to fix that it should introspect the route and interface state and if that matches the system connnection setting do not bring it down ... anyway, i somehow have the feeling that the multiple device support will make this go away.
<asac_the_2nd> mbiebl: no ... i want ifupdown to conflict network manager ... once it supports multiple devices
<asac_the_2nd> for now its just a workaround so people can still roam even though they have configured their wired connection through /etc/network/interfaces.
<mbiebl> Hm, ok.
<asac_the_2nd> mbiebl: but the problem you want to fix (not down interfaces when stopping) is tightly coupled with the problem that it tears down interfaces at startup
<aquo> asac_the_2nd: do you have use cases that describe the update of NM?
<mbiebl> But if you want to conflict with ifupdown anyway, why use the rather hard to manage /e/n/i format for configuring the system-settings daemon?
<asac_the_2nd> mbiebl: for legacy reasons
<asac_the_2nd> people should just seamlessly use their old configuration
<mbiebl> One problem I see is, that the ifupdown format is quite flexible.
<asac_the_2nd> and because its "the debian way" to configure things ... why to chage that?
<mbiebl> aliased interfaces
<mbiebl> pre/post up/down actions.
<asac_the_2nd> mbiebl: yes ... we won't be able to have a perfect mapping ... but covering 90% of the use-cases in the begginning should be enough imo.
<mbiebl> How do you want to map that information to NM?
<asac_the_2nd> he rest is unlikely to use nm anyway
<asac_the_2nd> mbiebl: which information?
<asac_the_2nd> the actions you refered to above?
<mbiebl> Well, just see the proposed configuration for wpa_supplicant roaming?
<mbiebl> which uses virtual devices names.
<mbiebl> and id_str in wpa_supplicant.conf
<mbiebl> or mappings in /e/n/i
<mbiebl> stuff like.
<asac_the_2nd> mbiebl: did you take a look at the eniplugin.c file? ... thats a pretty basic approach still, but we can improve that. you have example config for that use-case?
<mbiebl> asac_the_2nd: here is an example http://pastebin.ca/871988
<asac_the_2nd> mbiebl: ok i am pushing the latest now to a different branch ... given that the other is still locked
 * asac_the_2nd looking
<asac_the_2nd> mbiebl: do you have the wpasupplicant file as well?
<mbiebl> wpa_supplicant.conf contains different configurations which have an id_str, which matches the virtual device name.
<asac_the_2nd> mbiebl: is that a debian specific thing?
<asac_the_2nd> or upstream wpasupp?
<mbiebl> http://pastebin.ca/871992
<mbiebl> /usr/share/doc/wpasupplicant/README.modes.gz
<mbiebl> Read roaming mode
<asac_the_2nd> hmmm ... afaict it should map pretty well to the new configuration framework in nm
<mbiebl> Not Debian specific.
<asac_the_2nd> the parse for that probably should be distribution independent though
<mbiebl> asac_the_2nd: lemme check the sources, if id_str is really upstream or a Debian/Ubuntu specific patch
<asac_the_2nd> mbiebl: maybe we should write down the open points somewhere?
<mbiebl> Agreed.
<asac_the_2nd> good
<mbiebl> wpa_supplicant/config_ssid.h
<mbiebl> id_str seems to be upstream supported. I'm not sure if other distros use a similar mechanism though to implement a roaming mode.
<asac_the_2nd> so the name in the iface line in interfaces has to mach that id_str right?
<mbiebl> That's how it's implemented in Debian, yes.
<asac_the_2nd> sorry ... need to eat ... bbl
<mbiebl> Ok, I'll write an email to you this weekend, with all the different points I have in mind.
<mbiebl> Together with your input, we then should add this info to a wiki or something.
<ScottK2> pitti: It's an extreme form of security by obscurity.
<ScottK2> pitti: (stepic)
<ScottK2> I think it's an interesting concept.
<ScottK2> pitti: While you're doing archive stuff (hope you still are), I'd appreciate it if you would binary new libetpan in dapper-backports.
<ScottK2> That's the last manual step in the clamav-0.92 transition in backports for dapper.
<pitti> ScottK2: ah, looking
<ScottK2> pitti: Thanks.  The rdepens for it are already sitting in depwait for it, so there's no further rebuilding.
<ScottK2> rdepens/rdepends
<articpenguin3800> what version kernel does hardy use
<zul> 2.6.24
<articpenguin3800> the rc based of 2.6.24 or the stable one that got released yeterday
<zul> right now its rc8 but its being rebased to 2.6.24
<articpenguin3800> does that mean hardy fiesty edgy and dapper will get 2.6.24 or are there kernels frozen
<articpenguin3800> i meant gutsy not hardy
<amitk_> articpenguin3800: Only Hardy gets a 2.6.24 kernel
<articpenguin3800> ok
<asac_the_2nd> mbiebl: great .... then lets get things going :)
<Kmos> zul: rc8 is over.. it's now 2.6.24 final :)
<mbiebl> asac_the_2nd: nice talking to you!
<asac_the_2nd> mbiebl: i pushed the latest: https://code.edge.launchpad.net/~asac/network-manager/main.eni1
<mbiebl> asac_the_2nd: about the soname bump: this should be done upstream imho.
<asac_the_2nd> yes ... thats why i committed it to that branch
<mbiebl> asac_the_2nd: will you contact dcbw about that?
<Hobbsee> Kmos: dude, learn to read please.
<asac_the_2nd> yes ... i will send it upstream. we just needed it now to package it decently
<asac_the_2nd> i think this weekend or latest on monday
<Hobbsee> Kmos: if you'd actually read the changelog, and read what zul said, you'd know that ubuntu's kernel is currently at rc8.
<mbiebl> asac_the_2nd: great
<ScottK2> pitti: Thank you.
<Kmos> Hobbsee: i found it :)
<Kmos> Hobbsee: lagged.. 30 secs
 * Kmos jesus!
<Hobbsee> Kmos: how is your lag relevant?  you clearly responded to zul said, and the new linux metapackage was published hours ago.
 * Hobbsee checks the email about Kmos
 * Hobbsee notes that adding stuff in here is classed as contributing to ubuntu development, which is one of the things that kmos has been asked not to do.
 * Hobbsee therefore will prohibit him from doing so.
<mbiebl> asac_the_2nd: The debian/ directory in 0.7 still contains a lot of 0.6 cruft (nm-vpn-properties, which is no longer in NM, outdated copyright files) etc.
<mbiebl> asac_the_2nd: I'll work on the debian/ directory during this weekend and will do a thorough cleanup.
<asac_the_2nd> mbiebl: are you talking about the ubuntu package?
<mbiebl> yeah.
<ogra> Hobbsee, is that really necessary ?
<mbiebl> What I wanted to propose is, that I'll look after debian/ and you can concentrate on the eni plugin.
<asac_the_2nd> mbiebl: yes, there might be cruft left. it was an initial release for evaluation here
<mbiebl> I'd like to get the contents in debian/ in sync again as best as possible.
<asac_the_2nd> mbiebl: great .... i have two more commits here
<Hobbsee> ogra: as far as i know, not contributing to ubuntu development actually meant just that
<Hobbsee> which includes talking crap in channel
 * ogra heavily disagrees
<asac_the_2nd> mbiebl: i am fine with sharing workload that way.
<Hobbsee> ogra: i can quiet him if you wish
<ogra> Hobbsee, obviously you manage to ignore other people that talk crap ...
<mbiebl> asac_the_2nd: are you fine to name the init script /etc/init.d/network-manager and /etc/init.d/network-manager-dispatcher?
<pitti> Hobbsee: just relax a little...
<ScottK2> ogra: Other people haven't been told by MOTU Council to desist.
<mbiebl> That's how I had already called them in the Debian 0.6.5-1 package?
<Hobbsee> ogra: true, but they don't talk crap for months, and they don't get a mandate from the MOTU council to stop contributing to ubuntu development.
<ogra> ScottK, thats not relevant here
<Hobbsee> ogra: how is it not relevant?
<Hobbsee> ogra: it's entirely based off that decision
<ogra> being rude and kicking people *is* relevant though
<asac_the_2nd> mbiebl: i would be fine with that ... however the upstream tree ships NetworkManager (no Dispatcher though) ... anyway, whatever we do, we should submit it upstream
<Hobbsee> ogra: sorry, i'm not seeing where i'm being rude - i'm seeing where i'm saying a statement of fact.
<mbiebl> Well, init scripts is a thing I usually don't submit upstream.
<mbiebl> As every distros uses their own anyways.
<asac_the_2nd> yeah .... then we should ask for removal :)
<mbiebl> asac_the_2nd: ;-)
<dholbach> that kernel comment was probably not right, but it was definitely ignorable
<Hobbsee> dholbach: am i wrong in thinking that "being asked not to contribute" and contributing, correctly or not, still should be forbidden?
<lifeless> we've kicked diots from the channel before
<ScottK2> dholbach: Sure.  It's all ignorable, but if the MC decision isn't going to be enforced, what value does it have.
<Hobbsee> dholbach: last i checked, doing what you say is actually a good thing
<dholbach> it's not all black and white, is it?
<dholbach> he did not file a sync request or anything, just offered a comment to a discussion
<ScottK2> dholbach: The MC's decision seemed to draw a pretty clear line.  On this channel you are either contributing to Ubuntu development or off topic.
<lifeless> dholbach: because its not on malone its not disruptive?  That seems to be what you are saying
<dholbach> sorry, clicked on the wrong button
<Hobbsee> [01:03] <dholbach> it's not all black and white, is it?
<Hobbsee> [01:03] <dholbach> he did not file a sync request or anything, just offered a comment to a discussion
<Hobbsee> [01:04] <ScottK2> dholbach: The MC's decision seemed to draw a pretty clear line.  On this channel you are either contributing to Ubuntu development or off topic.
<Hobbsee> [01:04] <lifeless> dholbach: because its not on malone its not disruptive?  That seems to be what you are saying
<Hobbsee> dholbach: being asked not to contribute to ubuntu development, then talking on an ubuntu development, giving incorrect info, even worse...i'm not sure how that *isn't* black and white
<Chipzz> ScottK2: I would disagree with that assertment... I'm not an ubuntu developer, I just lurk here, sometimes commenting when something interesting passes or if I have an opinion I want to add
<ScottK2> Chipzz: And those comments are part of ubuntu development and welcome.
<Hobbsee> dholbach: btw, i would have thought that filing bugs was also ubuntu development - is this not the case?  kmos doesn't appear to think so.
<dholbach> lifeless: no that's not what I said - IRC behaviour can be very disruptive
<dholbach> lifeless: I just thought that his comment did not warrant to ban him from the channel - and so thought 5 people who directly informed me of what happened (I wasn't around when it happened
<Chipzz> Hobbsee: I would say that depends; for example, sync requests, which kmos has fucked up repeatedly in the past, may be considered development, whereas reporting a bug may not?
<Hobbsee> Chipzz: i would have thought any triaging other people's bugs definetly classed as development.
<Chipzz> dholbach: except it wasn't just that comment; the ban was an accumulation of frustration over Kmos during the last couple of months
<lifeless> it seems to me that either:
 * calc stopped going to #ubuntu after seeing what qualifies for a ban there
<lifeless> kmos should be banned from this channel permanently (because we have banned him by MOTU council fiat)
<lifeless> OR
<Hobbsee> calc: yeah.  strict rules, for a 1200 person channel, i'm afraid :(
<Hobbsee> calc: there's no real other way to do it, apart from a channel split
<lifeless> kmos should be kicked anytime he diverts discussion (with a note that "you are being distruptive").
<lifeless> I think that Hobbsee's kick was a little odd because the specific behaviour wasn't noted (but thats why a permanent ban makes sense to me)
<TheMuso> lifeless: IMO the latter is probably more appropriate.
<ScottK2> Either way the question is about if he should be let back on, not if the kick was correct.
<lifeless> I'll note that there is an ongoing cost with kicking every time kmos is out of line: its his persistent behaviour of being out of line that lead to the ban
<Hobbsee> lifeless: true - it was only in the statements directly above, not in the kick message.
<Hobbsee> which was partially due to lazyness
<ScottK2> And the MC decision was made after he was given chances to reform.
<lifeless> Hobbsee: well, it can be percieved as hostility/rudeness
<lifeless> Hobbsee: not saying I percieved it that way though
<Hobbsee> lifeless: so, for the next time, i'll remember to set a ban, then to use /remove.
<Hobbsee> lifeless: kmos has, unfortunately, proved that he will not reform.  repeatedly.  i don't see the second option as being viable, based on how many ops there are in channel
<lifeless> Hobbsee: I suggest mailing the list and suggesting that the appropriate follow through on the motu council decision is to set bans across ubuntu-dev*
<Chipzz> Hobbsee: while I agree with banning kmos, I think lazyness can be excused at times; for example when something is being discussed, and just asking would not break the flow of the conversation (ie the person having to look it up not being to participate in the discussion)
<lifeless> and kick and ban from the lists
 * persia advocates muting over banning, as channel and list archives are public anyway: no reason to limit realtime vs. delayed access
<Hobbsee> lifeless: i asked if that should happen if he violated his conditions, and got no reply.  at some point, you need to take action if no one else will.
<Hobbsee> FWIW, it's now a mute, not a ban
<lifeless> Hobbsee: well, in which case send a mail to the relevant list saying its been done :)
<lifeless> silence is permission as they say
<Hobbsee> lifeless: oh, sure, i'll be doing that.  but i figured that it might be worth dealing with the fires from here first.
<lifeless> ;)
 * Hobbsee helps put out a spot fire in #ubuntu
<lifeless> Hobbsee: oh, also - for your piece of mind, do what I did to sven many months go: '/ignore' :)
<Hobbsee> lifeless: forbidden for irc operators, i'm afraid :(
<Hobbsee> lifeless: by policy
<lifeless> Hobbsee: thats a good reason not to be op:)
<Hobbsee> lifeless: well, i avoided getting on the council :)
<Hobbsee> Chipzz: true
<aquo> what are you guys doing here? is this discussion development related?
<Hobbsee> aquo: ish.  discussing the handling of the issue of one of the people being forbidden from doing ubuntu development anymore.
<aquo> 30 minutes time spent for kmoz, i think you could do things that are more fun to you in this time ...
<lifeless> yup
<soc> hi
<soc> will landscape ever be released or will it only be available for canonical's subscribers?
<slangasek> geser: is there a xulrunner MIR pending that I don't know about, or does mono-tools need fixed up to use mozilla instead?
<calc> slangasek: doesn't firefox 3 use xulrunner?
<calc> slangasek: so probably no MIR yet but maybe will be soon?
<ion_> firefox-3.0 Depends: xulrunner-1.9
 * persia thought xulrunner != xulrunner1.9
<calc> oh nm then, i don't know the difference
<slangasek> ah, then I guess mono-tools needs to use xulrunner-1.9-dev instead of libxul-dev?
<ogra> slangasek, asac_the_2nd would know
<persia> slangasek: If it works, but there were a few packages in universe that couldn't port easily.
<calc> asac_the_2nd: ping ^
<ogra> calc, he's in a discussion atm
<calc> ogra: ah ok
<StevenK> xulrunner-1.9 was already in main, wasn't it?
<calc> StevenK: yea its in main
<calc> ff3 isn't yet
<ogra> ff3 isnt yet afaik
<ogra> heh, snap
<calc> hehe
<slangasek> StevenK: right, I just haven't followed at all so had no idea what the right fix was for the mono-tools dep-wait
<StevenK> Ahh
<jkt|> afternoon, folks
<jkt|> could you please tell me what sources are used for the http://packages.ubuntu.com/hardy/utils/kphotoalbum-kde4 package?
<jkt|> I'm wondering because we haven't released the kde4 version yet
<calc> jkt|: i don't know myself but kde packagers typically get packages before other people, at least they did when i was the maintainer for Debian
<james_w> jkt|,  https://launchpad.net/ubuntu/hardy/+source/kphotoalbum-kde4/4.0.0-0ubuntu1
<calc> jkt|: if you aren't already on it you may want to get someone to add you to the kde packagers list (assuming you package for gentoo)
<jkt|> let me rephrase it -- we do have code in svn, but it isn't of production quality and we haven't asked packagers to package it
<jkt|> I'm one of upstream devs in kphotoalbum
<calc> jkt|: oh that is interesting then :) /me points at Riddell
<calc> jkt|: he might know
<jkt|> calc: thanks, I'll ask him
<calc> hmm actually nixternal uploaded it from the changelog so he would know more than Riddell
<james_w> jkt|, it is nixternal's name in the package
<jkt|> nixternal: could you please clarify how you managed to release kphotoalbum-4.0.0 while we (its upstream) haven't tagged it yet? :)
<calc> jkt|: Riddell does most of the kde stuff but in this particular case nixternal uploaded the package
<james_w> jkt|, it is not unusual to package svn snapshots, however it is unusual to package it as a version that hasn't been released.
<jkt|> james_w: yep, if it was marked as a snapshot, I wouldn't be here :)
<jkt|> thanks for you help, let's wait for him
<calc> yea it was packaged as 4.0.0-0ubuntu1 which would imply it was final instead of something like 4.0.0~betaFoo-0ubuntu1
<jpatrick> jkt|: you can atch the rest of us at #kubuntu-devel :)
<exarkun> According to gdb, the Python 2.5 source package in Hardy does not quite match up with the python executable from the Python 2.5 package.
<exarkun> A backtrace includes source lines which are blank and in between function definitions.
<exarkun> Should I not expect to be able to use the source package to get source lines from gdb like this?  Or is there a bug in one of these packages?
<StevenK> exarkun: Perhaps the Python 2.5 source package has patches applied before building, listed in debian/patches?
<exarkun> Hmm.  There's a bunch of files in that directory, yea.  I'm not extremely familiar with how patches work inside Ubuntu packages.  I applied the .diff that came with "apt-get source ...".  Some hunks of it applied, others didn't.  I didn't think to look for patches elsewhere, too.
<asac_the_2nd> slangasek: yes ... mono gecko binding is the only thing left in main that i have to create a patch for to use xulrunner-1.9-dev
<StevenK> asac_the_2nd: What about liferea? :-)
<asac_the_2nd> i have a patch for that iirc
<StevenK> asac_the_2nd: If you have a patch for Liferea, throw it at me ...
<asac_the_2nd> StevenK: so that i don't confuse ... liferea is C(++)?
<StevenK> asac_the_2nd: Liferea is C, the Mozilla bindings are (the only file) in C++
<asac_the_2nd> then i have a patch ... yes.
<StevenK> asac_the_2nd: Mail it my canonical address, and I'll look it over during my flight
<asac_the_2nd> but i couldn't access my machine at home for the whole week. will send as soon as i am home again (given my machine didn't burn down)
<StevenK> Oh, fair enough, then I'll look during the week
<asac_the_2nd> StevenK: yeah ... will arrive home tomorrow in the evening ... so probably you get it on sunday
<StevenK> asac_the_2nd: Sounds great. :-)
<asac_the_2nd> StevenK: did you try those in my xulrunner-porting branch?
<asac_the_2nd> http://codebrowse.launchpad.net/~mozillateam/xulrunner/xulrunner-porting/files/asac%40jwsdot.com-20080116133320-ut6kwdkzc7eunmmv?file_id=liferea-20071214201407-8w8sqpz3ygwfopay-1
<Riddell> jkt|: ping
<StevenK> asac_the_2nd: I didn't, since I didn't know it existed. :-)
<jkt|> Riddell: pong
<Riddell> jkt|: you need to talk to toma, kphotoalbum is released with extragear (ftp://ftp.kde.org/pub/kde/stable/4.0.0/src/extragear)
<asac_the_2nd> StevenK: please try ... as i am not sure if they work against xulrunner package we have in the archive atm
<asac_the_2nd> if they don't let me know ... i will fix them up
<Riddell> jkt|: he has a list of extragear packages who have agreed to be relased at the same time as KDE and kphotoalbum is inluced
<jkt|> Riddell: wow, ok, probably we screwed communication to kde release folks, then
<StevenK> asac_the_2nd: Sure, I've made a note, I'll have a poke.
<asac_the_2nd> great
<jkt|> Riddell: I recall the question, but I thought it was opt-in, not opt-out
<jkt|> Riddell: thanks
<Riddell> jkt|: http://techbase.kde.org/index.php?title=Projects/extragearReleases
<slangasek> asac_the_2nd: ok, thanks. :)
<jkt|> nixternal: unping
<goodhabit> Hello. I have some trouble. I am linux newbie, also ubuntu newbie. I have found some software, and with helps of manuals, google, brain I have compiled some software. But, as I understood,"make install" is wrong-way. And I need making deb file. I am started googling forward and found some manuals for it (#ubuntu also). But there are some issues I cannot solve. But as I told allready I need that package. Maybe someone could help me with packaging?
<slangasek> tjaalton: no news on bug #133192?
<ubotu> Launchpad bug 133192 in xserver-xorg-video-ati "Blank screen or distorted image because of wrong default AGPMode value" [High,Confirmed] https://launchpad.net/bugs/133192
<slangasek> goodhabit: for beginner packaging help (if you plan for the package to eventually go into Ubuntu), #ubuntu-motu is better
 * Hobbsee snorts at the MOTU ML
<Hobbsee> ScottK2: neat.  thanks.
<Hobbsee> ScottK2: i prefer not to have to react to that thread myself.
<\sh> can someone deal with the ubuntu-devel@lists.ubuntu.com ML to have sh@sourcecode.de whitelisted as being a ubuntu-dev again? :)
<pochu> Same for pochu@ubuntu.com pretty please
<Hobbsee> \sh: pochu done
<\sh> Hobbsee, thx
 * Hobbsee assumes it's supposed to be added manually
<pochu> Thanks Hobbsee :)
<slangasek> Hobbsee: I think I'm not whitelisted on there either?  steve.langasek@ubuntu.com or such
<pochu> Hobbsee: possibly, since I'm a motu for 2+ weeks...
<Hobbsee> slangasek: *sigh*
<slangasek> sorry, I had no idea what the process was so I was not dealing with it until the opportunity suddenly presented itself ;)
<\sh> hehe
<Hobbsee> slangasek: done
<slangasek> Hobbsee: cheers
<pitti> ArneGoetje: https://translations.edge.launchpad.net/ubuntu/gutsy/+language-packs
<pochu> pitti: do you have a clue why apport didn't retrace bug 178101? Will it do it if I add a needs-i386-retrace tag?
<ubotu> Launchpad bug 178101 in vinagre "vinagre crashed with SIGSEGV in setcontext()" [Medium,Incomplete] https://launchpad.net/bugs/178101
<pitti> pochu: it was broken for quite a while
<slangasek> and at this point it won't because the ddebs are probably no longer available
<pochu> Hmm, right.
<Ng> slangasek: so if I have a segfault from the new package from today I should let apport do its magic to a new bug?
<slangasek> pitti or bdmurray probably have more useful opinions in that regard
<pochu> Ng: there has been one, and the retrace failed.
<Ng> ah
<pochu> https://bugs.edge.launchpad.net/ubuntu/+source/vinagre/+bug/185047
<pitti> yeah, seb128 and I just found a pretty weird bug
<pitti> ddebs are disappearing from the Package indexes
<pochu> weird, indeed
<pitti> ArneGoetje: script pushed to the main branch
<pitti> ArneGoetje: please do bzr merge bzr+ssh://bazaar.launchpad.net/%7Epitti/langpack-o-matic/main/
<pitti> ArneGoetje: ah, s/bzr+ssh/http/
<pitti> ArneGoetje: bzr merge lp:langpack-o-matic
<bddebian> pitti: Oh, have a sec about plr?
<\sh> pitti, ping bug #185959, when I finished the list, can we work together on this transition, regarding syncs from debian ?
<ubotu> Launchpad bug 185959 in xmds "octave3.0 transition" [Undecided,Confirmed] https://launchpad.net/bugs/185959
<pitti> \sh: yeah, that's ok
<pitti> \sh: for this kind you can just give me a list in IRC
<pitti> bddebian: one sec, yes (pretty busy here); just ask, I'll answer eventually
<\sh> pitti, that's what I though we do :) if this is finished, we can get rid of octave2.1 and octave2.9 :)
<bddebian> pitti: Well apparently upstream has a new one for 8.3 but it's beta so I'm still unsure what to do with it.  Package the beta for 8.3 or leave 8.2 and try to fix it somehow.
<pitti> bddebian: you can upload the one with 8.3beta to experimental
<bddebian> Hmm, OK, I'll check on that, thanks
<tjaalton> slangasek: I need to check if upstream has reverted to the previous default values
<geser> asac_the_2nd: re mono-tools: when I filed the bug I tested that it builds in a pbuilder with xulrunner1.9-dev.
<slangasek> tjaalton: ok.  might be nice to have that fix included in alpha4, since it was release-noted for 3
<geser> slangasek: re mono-tools: I was waiting on asac's feedback or sponsoring on bug #183895
<ubotu> Launchpad bug 183895 in mono-tools "[hardy] Replace build-dependency on libxul-dev with xulrunner-1.9-dev" [Undecided,New] https://launchpad.net/bugs/183895
<slangasek> geser: yep, asac_the_2nd clarified later, thanks
<geser> pitti: what's the status on bug #184545?
<ubotu> Launchpad bug 184545 in debhelper "[Merge] debhelper (6.0.2ubuntu1)" [Undecided,New] https://launchpad.net/bugs/184545
<tjaalton> slangasek: indeed
<pitti> geser: no time during the sprint, sorry; next week, I think
<geser> ok
<mbiebl> asac_the_2nd: tested the main.eni1 branch
<mbiebl> the plugin crashes: http://pastebin.ca/872251
<nixternal> jkt|: kphotoalbum was a sync, I didn't upload it
<Hobbsee> nixternal: you'll get blamed anyway
<nixternal> so that means that Debian had it first and all I did was request for it to be sync'd
<nixternal> I know :p
<nixternal> I have it tattooed on my forhead
<\sh> nixternal, lol
<\sh> nixternal, didn't you know, even when you are the one who requested a sync, you are the one to blame...;)
<nixternal> nah, it is a valid question...but I do remember seeing kphotoalbum-kde4 in ktown after tagging
<nixternal> jkt|: kphotoalbum is still in ktown stable/4.0.0/src/extragear with a modification date of 2008-01-04
<snikker> when i run "ps2pdf file.ps file.pdf", i've got this error: "Bus error". this appen only from today. can you help me?
<\sh> snikker, the last update was from the 23rd of Jan...
<\sh> snikker, try this: apt-get --reinstall ghostscript
<\sh> snikker, it works for me here...as mhb told you in #kubuntu-devel, thx :)
<Riddell> nixternal: I've discussed this with him
<Riddell> nixternal: it was a mis-communication with extragear admins
<nixternal> roger dodger, that is what I figured
<nixternal> actually I was wrong about the sync, I was thinking that because I just did the kphotoalbum sync of 3.1.0...got nervous for a second thinking I blasted the KDE 3 version with the KDE 4 version
<snikker> \sh: i've reinstalled ghostscript but i've got the same error... what could be the problem?
<\sh> dunno...please file a bug with strace ps2pdf <.ps> <.pdf> on launchpad :)
<snikker> \sh: ok thanks :)
<snikker> \sh: solved with strace. i've reinstalled "libgs8" and now it work again! thank you! :-)
<\sh> snikker, so that's what I thought...you hit by something during the install (mostly your hd cache had a hickup or so...)I had it once in a while, when I was compiling heavy stuff with a lot of swapping and trying to install new packages at the same time :)
<marcin_ant> hi all so called "developers"
<marcin_ant> I know that this what I am going to tell will be rude and you can ban me
<\sh> hmm? what'll come now?
<marcin_ant> but I just need to tell you guys that because of your *&^*&^*&^*&^ (put some ugly words here)
<thom> i'm hoping this is good. it's taking long enough
<marcin_ant> ugly upgrade procedure - from feisty to gutsy I have to go to my car and drive 120km
<marcin_ant> only because after upgrade eth0 in my server is now eth2 and I need to go there because I have no remote access
<marcin_ant> thank you guys, thank you very much :(
<Chipzz> not as good as I expected :P
<robertj> meh, does suck though
<thom> well, that sounds like you killed your iftab which is written by the installer to avoid exactly this issue
<Chipzz> marcin_ant: try not using networkmanager on a server?
<\sh> marcin_ant, well...the problem is not the upgrade...the problem is not having an Remote Insight Board like ilO or eRIC
<marcin_ant> not to mention that aliases in /network/interfaces are broken too
<BenderUnit22> Running a server without remote access, how did you manage to upgrade it from Feisty to Gutsy?
<BenderUnit22> I must be overlooking something obvious. :/
<marcin_ant> Chipzz: I don't use network manager
<Chipzz> BenderUnit22: he means "remote hands"
<Chipzz> BenderUnit22: which is another word for "someone to go push the reset-button" :P
<BenderUnit22> If he has that, surely he wouldn't have to drive there to have it fixed?
<marcin_ant> Chipzz: I had pretty nice /etc/network/interfaces but now after reboot eth0 is eth2 and I my ssh session is lost
<Chipzz> marcin_ant: you should never have done a kernel upgrade from remote location anyway
<\sh> marcin_ant, you should think about a cheap remote insight board, or a little cyclades terminal switch where you can attach your serial port for accessing grub during bootup to rename your eth2 to eth0 ,-)
<marcin_ant> sure but maybe you guys could think about fixing udev (am I right that it's udev fault?) ???
<Chipzz> marcin_ant: upgrading a kernel (certainly between versions, ie not minor ubuntu versions) should always be done at the console
<Chipzz> marcin_ant: if you don't know that... no offence, but then you're a crappy sysadmin
<thom> marcin_ant: see earlier. the installer creates a file to ensure this doesn't happen
<thom>  /etc/udev/rules.d/70-persistent-net.rules
<marcin_ant> and what guys about this: SIOCSIFFLAGS: Cannot assign requested address
<marcin_ant> SIOCADDRT: No such process
<marcin_ant> Failed to bring up eth2:1. ?
<elmo> Chipzz: err, I'm not sure that's a helpful attitude
<thom> this is way offtopic for here anyway
<elmo> Chipzz: I've done hundreds of remote kernel upgrades; sometimes there's no choice.  and I don't think it makes me a crappy sysadmin
<elmo> but thom's right too, this is offtopic
<marcin_ant> Chipzz: do you think that I always have time to ride from place to place just to push some buttons?
<marcin_ant> Chipzz: I thought this is why someone invented ssh and other network tools
<thom> guys
<marcin_ant> thom: toght
<marcin_ant> thom: right
<marcin_ant> thom: I'm sorry - I use ubuntu from it's beginning and I really appreciate your work
<marcin_ant> but things like this really _shouldn't_ happen in ubuntu _server_
<marcin_ant> call me crappy admin - but all I have to say at the moment is that I'm maybe crappy sysadmin - but propably because sys that I admin is crappy
<Chipzz> elmo: I think that as a sysadmin, you should be aware that things can go wrong when doing certain things - like upgrading the kernel
<marcin_ant> and now plonk/ban/kill me - I need to go and ride... :[
<marcin_ant> Chipzz: I'm aware but I'm still annoyed
 * thom notes he's done about 20 edgy->gutsy upgrades in the last month remotely without issue *shrug*
<marcin_ant> thom: I upgraded from dapper to feisty without issues too but now.. no luck unfortunately
<ScottK> marcin_ant: You did a dapper direct to feisty upgrade on this box before?
<marcin_ant> ScottK: yes!
<ScottK> marcin_ant: Gut feel tells me that's why.
<marcin_ant> ScottK: ?
<ScottK> The sysv init to upstart transition happened in Edgy and so the odds of something weird happening if you skip that step on non-zero.
<ScottK> Also the switch to UUID based device numbering was in Edgy too.
<ScottK> Dapper -> Feisty is unsupported and untested.
<ScottK> I know from my own experimentation that there can be TTY troubles (there's a bug on that somewhere).
<marcin_ant> ScottK: so are you going to tell me that I should install gutsy from cd and it should resolve some problems?
<ScottK> That's what I would do since you've upgraded through an untested and unsupported path.  We know from the Dapper -> Hardy upgrade testing that's going on now that there are issues.
<ScottK> We certainly don't know what they all are.
<ScottK> I'd suggest you've got your system into an unknown state and there's no good way back.  It might be fine, but if it's a long drive, you probably don't want to take that risk.
<marcin_ant> ScottK: well I have to go there anyway... So I could do some clean installation
<ScottK> Better one longer complete trip than having to go back in a week when something else weird happens.
<marcin_ant> ScottK: well that's right - because problem with eth0->eth2 is one thing
<marcin_ant> ScottK: but I also had this: SIOCSIFFLAGS: Cannot assign requested address
<marcin_ant> SIOCADDRT: No such process
<marcin_ant> Failed to bring up eth2:1.
<ScottK> Who knows what else is hiding so far.
<ScottK> Just nuke it and start over.
<marcin_ant> ScottK: ehhhh clean installation + shorewall + dansguardian + squid + etc etc... guys - call me crappy sysadmin but how could you name distro "ubuntu-server" while it has such ugly network issues after upgrade?
<ScottK> marcin_ant: I've upgraded a lot of machines and never had such problems.  I think the problem is that you took a non-standard/untested path.
<marcin_ant> it should be "ubuntu-beta-notready-hazardous-server" :[
<marcin_ant> ScottK: ??? I just upgrade from release to release... you call this non-standard?
<ScottK> marcin_ant: Maybe I misunderstood you then.
<ScottK> marcin_ant: I thought you said you upgraded direct from Dapper to Feisty, skipping Edgy.
<marcin_ant> ScottK: I installed Edgy on this machine - then upgraded to Feisty without issue - and now from Feisty to Gutsy
<ScottK> marcin_ant: OK.  Then I take it back.  I completely misunderstood.
<ScottK> I've done a bunch of Feisty/Gutsy upgrades, so I've no idea exactly what would be your problem.  Sorry for leaning on you about the wrong thing.
<marcin_ant> ScottK: problem is that I don't know how to solve this too... :(
<marcin_ant> ScottK: because I know that I don't have ssh connection now because of mess with eth[x]
<marcin_ant> ScottK: but another thing is that I had virtual network interfaces that are broken now too
<marcin_ant> ScottK: and I know how to fix problem with messed eth interfaces - but don't know why I cannot bring up eth2:1 and eth2:2
<ScottK> Once you have local access you ought to be able to put it back to eth0.
<ScottK> Dunno what to tell you on that.
<marcin_ant> ok guys I have to go
<marcin_ant> I know that you hate people like me... and I... almost understand ;)
<marcin_ant> but sometimes it's good to have some "feedback" from real life users/sysadmins ;)
<marcin_ant> need to go... to this crappy server.. maybe I will switch to gentoo/fedora/whatever...
<jablko> there is a package in the debian repositories which i'd like available in ubuntu
<jablko> is there something like filing an RFP on WNPP in ubuntu?
<elmo> https://wiki.ubuntu.com/SeedManagement <-- could use some serious  love by someone who actually knows current practice (i.e. not me)
<marcin_ant> oh... before I go: Bug #148929 in udev (Ubuntu)
<ubotu> Launchpad bug 148929 in udev "Gutsy beta renumbers ethernet interfaces after boot (dup-of: 145382)" [Undecided,Confirmed] https://launchpad.net/bugs/148929
<ubotu> Launchpad bug 145382 in busybox "[Gutsy] broken 70-persistent-net.rules" [Undecided,Fix released] https://launchpad.net/bugs/145382
<\sh> jablko, which package?
<marcin_ant> mhmm and I'm not alone with my second problem: Bug #123773
<ubotu> Launchpad bug 123773 in ifupdown "'SIOCSIFFLAGS: Cannot assign requested address' when setting up ip alias" [Undecided,Confirmed] https://launchpad.net/bugs/123773
<\sh> marcin_ant, btw..I just did a remove dist-upgrade session on a customers server..from dapper-server to gutsy... no problem at all
<\sh> s/remove/remote/
<jablko> \sh: solr-tomcat5.5
<\sh> jablko, source package please?
<geser> \sh: solr
<\sh> hmm..java crap ;)
<geser> \sh, jablko: blocked on the FTBFS of lucene2
<\sh> geser, the source package looks strange: binary-dep on sun-java5-jre | sun-java6-jre but b-d on sun-java5-sdk only
<\sh> s/sdk/jdk/
<geser> \sh: the sun-java6-jre can execute the code compiled with sun-java5, so it looks ok
<geser> at least I was told so
<\sh> geser, sure...that's not the problem...I'm asking me why they are not building the code with java6..but well it's java nothing for me
<robertj> ooh hardy upgrade went very smooth, the system crashed fairly hard at the end but a reboot and retry and things are good
<geser> \sh: I'm not yet deep enough in java packaging to understand it. I just looked at some java packages FTBFS in the past.
<robertj> lots of bugs fixed
<ScottK> marcin_ant: I just noticed which channel this is.  Support is OT on this channel.  You might have more luck on #ubuntu-server
<jablko> geser: sorry, i searched launchpad for a solr bug, how did you determine it was blocked?
<jablko> oh, launchpad bug 185917?
<ubotu> Launchpad bug 185917 in lucene2 "lucene2 jdk dependence" [Undecided,New] https://launchpad.net/bugs/185917
<geser> jablko: I looked at the build-dependencies of solr and saw that liblucene2-java isn't available yet
<jablko> geser: how did you then find lucene2 FTBFS?
<geser> jablko: I remember seeing it on http://qa.ubuntuwire.com/ftbfs/
<geser> jablko: else I would check which source package builds liblucene2-java, check it is in hardy and check then the build status
<robertj> bwahhaaha, ssh:// read-write in gedit at last!
<jablko> geser: ok, thanks much!
<robertj> this really brings an insane gleam to my eye
<juacom99> hi just one simple question
<juacom99> i'm trying to program a chat server for ares P2p that works on linx
<juacom99> is there something i shuld know before i satrt developing?
<juacom99> sorry i just tead the topic
<juacom99> nm
<Pelo> evening folks
<Pelo> I was wondering , is there a link to view the "official" hardy desktop theme ?
<Pelo> or the latest version of it
<LaserJock> Pelo: it probably changes enough that people aren't putting up many "snapshots"
<Pelo> LaserJock,  I was just wondering about the general direction of it , some of the alternatives are quite nice ( most are hideous) , I just tried to look up the "real" one but I couldn'T find it , so I wondered
<tlacuache> question about a package I got off of packages.ubuntu.com... i wanted to look at the ubuntu patches to the original source for a package. so i went to http://packages.ubuntu.com/gutsy/net/dsniff and downloaded [dsniff_2.4b1+debian.orig.tar.gz] and [dsniff_2.4b1+debian-15ubuntu1.diff.gz]. the first .gz contains the original source. the second .gz contains a .diff file, but it's not like a regular .diff file i'm used to using with patch
<tlacuache> when i try to apply it with patch, i see files created like debian/patches/06_urlsnarf_zeropad.dpatch
<tlacuache> i really just want to apply the patch to the source code correctly
<tlacuache> any pointers?
<crimsun> dpatches can be applied using patch just as "ordinary" unified diffs.
<crimsun> the specific patch maintenance system is called dpatch.
<tlacuache> ah, sweet
<tlacuache> ok i get it
<tlacuache> i apply the patch
<tlacuache> then i do dpatch apply-all
<tlacuache> and it actually modifies the source code
<tlacuache> thanks
<crimsun> yw.
<emgent> keescook, ping
<emgent> someone remove " xorg-server security update blocked, fix in progress" in the topic :P
<crimsun> emgent: you can; it's not locked.
* emgent changed the topic of #ubuntu-devel to: Archive: OPEN | Hardy Alpha 3 released | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty/gutsy, #ubuntu+1 for hardy | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<emgent> oh true
<emgent> :D
<Kopfgeldjaeger> good night
#ubuntu-devel 2008-01-26
<pochu> Any main sponsor who could upload http://emilio.pozuelo.org/~deb/gedit.debdiff for me? It fixes a FTBFS. TIA!
<zoke> what policies/mechanisms are in place to work more with upstream/debain and to reduce deltas ?
<crimsun> pochu: ACKed.
<pochu> crimsun: thanks :)
<LaserJock> zoke: that's an interesting question
<LaserJock> zoke: patches are automatically sent upstream, we encourage all developers/contributors to move things upstream
<zoke> I see
<LaserJock> but specific policies I'm not so sure
<LaserJock> mostly we just try to "do the right thing" and work with upstreams
<LaserJock> certainly not perfectly all the time, but that's the goal
<bddebian> LaserJock: Don't lie, we never give back.. ;-P
<ScottK> I think the stats on http://merges.ubuntu.com/main.html and http://merges.ubuntu.com/universe.html show us doing a reasonably good job over time.
<bddebian> ScottK: :_)
<LongPointyStick> elmo: no point updating seed management before cjwatson does his stuff with the new seeds
<linos2> anyone know how to compile an application .exe file extension using the gcc command?
<RAOF> linos2: gcc -o foo.exe foo.c
<RAOF> However, that (a) doesn't do what you actually want, and (b) isn't a question for #ubuntu-devel
<linos2> RAOF, sorry, but do you know where I could find such a channel?
<RAOF> Well, #gcc might be a good one.
<linos2> I tried, but nobody home
<borschty> i'm not sure, but take a look at the "winegcc"-command included in wine
<linos2> ok.. thanks guys
<kagou> Hi
<kagou> i'm investigating #181561
<kagou> what's the difference between kernel in desktop and alternate iso ?
<Seveas> kagou, there shouldn't be a difference afaik
<Seveas> bug 181561
<ubotu> Launchpad bug 181561 in linux "Hardy alpha 3 daily-live i386 dont't boot" [Undecided,Incomplete] https://launchpad.net/bugs/181561
<kagou> Seveas, or this is the case :(
<kagou> do we have tools to re-create (and to customize) "official" iso ?
<jkt|> nixternal: yeah, there was a mistake in communication between us and kde folks
<jkt|> thanks for a hint
<jdong> kagou: yes, the livecd is casper (see LiveCDCustomization or something like that on the wiki)
<jdong> kagou: and alt CD is just debian-installer; Debian has great docs on customizing that
<bddebian> pitti: Are you around by any chance?
<geser> Hi bddebian
<bddebian> Heya geser
<lamont> hrm... which package do I reassign bug 120829 to ... (pmount/gnome prefs/etc, apparently fixed in gutsy)
<ubotu> Launchpad bug 120829 in util-linux "/dev/sda3 is mounted despite the 'noauto' option in fstab" [Undecided,New] https://launchpad.net/bugs/120829
<crimsun> lamont: gnome-volume-manager
<lamont> thanks
<jcole> is webmin called something else these days?
<jcole> hmm, http://packages.debian.org/webmin shows 2006 as last update
<jcole> there is a fresh .deb on http://www.webmin.com/ though... perhaps there were some licensing issues or something
 * jcole googles
<ScottK2> !webmin | jcole
<ubotu> jcole: webmin is no longer supported in Debian and Ubuntu. It is not compatible with the way that Ubuntu packages handle configuration files, and is likely to cause unexpected issues with your system. See !ebox instead.
<jcole> thanks ScottK2
<Sjimmie> !ebox
<ubotu> ebox is a web-based GUI interface for administering a server. It is designed to work with Ubuntu/Debian style configuration management. See the plans for Hardy at https://wiki.ubuntu.com/EboxSpec
<jcole> Sjimmie: ebox looks very nice :)
 * jcole is surprised there is no ftp server admin module in ebox?
<dexem> jcole: but it's easy to develop a shinny new one ;)
<dexem> jcole: anyway, you could install your preferred ftp server and control the firewall access with ebox
<jcole> dexem: true, and there is already a samba admin module there that can probably be used as a template...
<jcole> http://xmb.stuffucanuse.com/xmb/viewthread.php?action=attachment&tid=4782&pid=13894
<jcole> oops
<jcole> nm that
<SR71-Blackbird> hey, do I need to patch the kernel 2.6.24 from kernel.org with some ubuntu patch to get stuff working? i tried the normal kernel.org version and my sound(alsa) and wireless (iwl4965) isn't working
<nepbabu> SR71-Blackbird, i think u need to patch the src with ubuntu specific changes
<nepbabu> i know it's freaking saturday O_o
<poodlesucks> can sounds get trapped?
<poodlesucks> can sounds get trapped?
<ion_> Yes.
<poodlesucks> poodlesucks> how and where?
<azeem> poodlesucks: I think you're off topic, please notice the /topic
<poodlesucks> fucking assholes
<poodlesucks> can lights and air get trapped ? can it crush us? where does all the sounds produce go to? is the sound/light/air radiation bad for our health? can air take away all of our cells by blowing wind like a sand?:D thank you
#ubuntu-devel 2008-01-27
<mok0> I am fixing a piece of code that's giving me a bunch of warnings:  "deprecated conversion from string constant to âchar*â" . The code becomes really ugly when you have to cast every string constant. What is the rationale behind this change of the C language?
<ln-> if you have to cast every string constant, that sounds a lot like you're doing something wrong.
<ln-> but what do i know, i'm not an ubuntu developer.
<LaserJock> mok0: seems like I've read something about that recently, but can't for the life of me remember where
<ln-> mok0: how about showing a piece of code that gives these warnings?
<ion_> mok0: AFAIU a string constant should either go to a const char * or be strduped.
<mok0> I can pastebin some code
<mok0> you'll see it looks ugly
<mok0> wait, I'll paste a oneliner here.
<mok0>  if (showprogress) StartProgress((char *)"Locating Bonds",atom.size() );
<mok0> every time there's a string constant, you have to cast it :-(
<ln-> i'd say: You're Doing It Wrong
<ion_> char *foo = "bar";  /* wrong, either use const char * or strdup */
<geser> mok0: what does StartProgress expect? a char *?
<mok0> const char *
<geser> then remove the (char *)
<mok0> Then you get the compiler error
<mok0> warning
<geser> Hi bddebian
<bddebian> heya geser
<ion_> mok0: Are you sure StartProgress expects a const char *? Please recheck.
<mok0> ion_: it doesn't matter what it expects. I tried changing it
<mok0> ion_: either way, you get the same warning
<mok0> even in an initializer: const char *str = "Hello world";
<mok0> This is g++ 4.2.3 from hardy
<mok0> using -Wall
<mok0> But it's going to give us tens of thousands of warnings from existing code :-(
<geser> mok0: I just checked: I get the warning for "char * foo = "bar";" but not for "const char * foo = "bar";"
<geser> mok0: luckily it just warnings an not errors
<mok0> geser: what about in a function call ?
<mok0> geser: I think I read somewhere that the policy recommends compilation with -Wall
<geser> mok0: http://paste.ubuntu.com/3925/ (ignore the linking error)
<geser> mok0: gcc (GCC) 4.2.3 20080114 (prerelease) (Ubuntu 4.2.2-7ubuntu1)
<mok0> geser: you are getting the same warning
<mok0> geser: I can't tell if it's both functions
<mok0> ... or only func1
<geser> mok0: I get it only for the func1 call
<mok0> hmm
<ln-> mok0: but doesn't that paste show the opposite of what you claimed?
<mok0> ln-: I claimed that changing the function didn't make a difference.
<mok0> geser shows that I am wrong
 * mok0 wants to check again
<geser> mok0: did you also changed the prototype in the header?
 * mok0 forgot to change the prototype :-(
<ln-> 02:15 < ln-> if you have to cast every string constant, that sounds a lot like you're doing something wrong.
 * ln- can foresee the future.
<mok0> ln-: Yeah.
<mok0> ln-: the solution is to make string constants "const char
<mok0> "const char *"
<ln-> yes, but it's not a "string", it's a pointer.
<mok0> ln-: aie
<mok0> const char *str = "hello world";
<mok0> but: char *str = "hello";  is commonplace
<geser> but also wrong as you can't modify str without a segfault
<geser> and the compiler will only warn you for const char *
<mok0> geser: ? the compiler accepts the latter
<mok0> former
<mok0> sorry
<geser> "hello" is by definition a const char *, so assigning it to a char * isn't wise
<mok0> geser: yes
<ln-> actually, you can modify str, but not *str
<mok0> ln-: so, you can invalidate the pointer?
<geser> ln-: yes, unprecise wording from my side
<mok0> But, still, char *str = "hello"; is used all over the place, so there are going to be lots of things to change
<ln-> mok0: not only invalidate, but you can make it point somewhere else.
 * geser thinks about the difference between "const char *" and "char * const" again
<geser> mok0: buggy code should be fixed instead of disable the warning
<mok0> geser: exactly, that's what I mean
<mok0> geser: Perhaps I'm ignorant, but I think the warning is pretty new
<mok0> geser: I've never had to deal with it before
<geser> mok0: I've seen it only recently too (since hardy, but I didn't look much at build logs during gutsy development)
<berto-> hi everyone.  i am running 6.06.1 LTS server and compiled a Xen 3.0.4 kernel.  When I boot into the Xen kernel I lose my SATA tape drive (Quantum DLT-V4).  Anyone know if there are any special modules I need besides st and sg that are built into the Ubuntu kernel?
<persia> berto-: It's a weekend, so most developers are not present.  Also, you might want #ubuntu, as that appears to be a support question.
<berto-> persia: ok, thanks.  i've tried in #ubuntu, i'll try again.
<persia> berto-: You might also try answers.launchpad.net/ubuntu/ if nobody currently around has an answer.
<berto-> persia: will do, thanks!
<berto-> persia: no luck in #ubuntu; i've posted a question on launchpad (https://answers.launchpad.net/ubuntu/+question/23184)  thanks for the tip!
<persia> berto-: Your welcome.
<linos2> anyone know where I could find a list of gcc command syntax for pentium and amd athlon processors
<LaserJock> linos2: have you checked the gcc man/info pages?
<linos2> LaserJock, no.. let me check. thanks
<linos2> LaserJock, I am trying to find out information about the i586-mingw32msvc-gcc command.  I don't have it in my man pages.  Do you know where I could find this on the net?
<LaserJock> linos2: google? sorry, I'm not much help
<linos2> LaserJock, thanks anyway
<coastGNU> lamont: ping
<coastGNU> lamont: Is there a chance that #186274 (debian bug-No.462662) will make it to hardy before feature freeze?
<linos2> can someone tell me what is the file name gentoo equivalent make.conf under ubuntu called?  thanks inadvance
<persia> linos2: No direct equivalent
<linos2> persia, where are the flags set under ubuntu kde desktop version edgy eft?
<persia> linos2: Likely in the individual packages, although I think KDE has some commonality.  apt-get source for the package that interests you, and look in the rules file.
<linos2> persia, ok thank you very much
<linos2> persia, one last question, where is the file that contains the CPU type?
<LaserJock> persia: those would just be additional flags no? aren't there common flags given to all?
<LaserJock> linos2: /proc/cpuinfo?
<persia> LaserJock: I don't think so.  debian/rules is just a makefile.
<Nafallo> !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.
<lamont> coastGNU: 462662 is on my list to evaluate - at first blush, the patch looks not-unreasonable.
<lamont> given the submitter, I'm inclined to trust it
<lamont> coastGNU: esp since feature freeze is 2 weeks away
<coastGNU> lamont: submitter; thats why I told it Joey :)) Thanks a lot.
<lamont> heh. ok
<lamont> anyway, it'll be in the next upload
<lamont> and patch filed upstream
<coastGNU> I'm writing an article about oem setup of all major community distributions for the german freeX magazine. So giving that the patch will make it into hyrdy that would be a tremendous example how fast a suggestion makes it into a debian package. ;)
<coastGNU> s/hyrdy/hardy/
<lool> A wave of FUD on Ubuntu SRUs is spreading on Planet GNOME :-/
 * Fujitsu sighs.
<Fujitsu> `common sense actions'
<Fujitsu> It's common sense to update packages in stable releases without a good reason. I see.
<lool> It's completely unfounded critics: the examples taken are glomm which is supposed to have serious bugs rendering it unusable but not visible in Launchpad -- if true this warrants a SRU; gnome-games which saw a SRU for gutsy already; and gnome-games being out of date in *hardy* while it simply didn't build because of a new build-dep which needs promotion to main
<lool> And then everybody running screaming that you should run Fedora instead
<geser> does Fedora have a "better" SRU policy?
<Fujitsu> geser: I believe they just push new upstreams.
<Mithrandir>  â A new version of configuration file /var/run/grub/menu.lst is available, but the   â
<Mithrandir> wtf?
<Mithrandir> configuration files in /var/run, now that's a new one.
<snikker> i've got some trouble to run vmware (libpng12 error) after the update of some packages, i'm under gutsy on amd64
<ScottK2> snikker: See /topic.  This isn't a support channel.
<snikker> ScottK2: yes, i know, but i've already tried yesterday in #ubuntu with no success... now i try again..
<Seveas> snikker, that doesn't make this a support channel.
<snikker> Seveas: ok, sorry for that...
<ln-> yeah, next you will be instructed to get a support contract.
<\sh> ln-, ?
<Nafallo> \sh: get a support contract ;-)
<\sh> Nafallo, ;)))
<\sh> who do I need to bribe to add more libs to ia32-libs?
<ln-> keescook: what does " Declined  for Dapper  by Kees Cook  "  mean in this context: https://bugs.launchpad.net/bugs/cve/2006-7229 ?
<geser> \sh: ia32-libs is in universe and TIL is pitti
<\sh> geser, well, if it's in universe I could do all by myself...great....
<\sh> ln-, because it's already fixed in linux-source-2.6.15_2.6.15-26.47?
<\sh> ln-, http://changelogs.ubuntu.com/changelogs/pool/main/l/linux-source-2.6.15/linux-source-2.6.15_2.6.15-26.47/changelog
<\sh>  * skge: Update to version in 2.6.17, to obtain fixes and D-Link DGE-530T
<\sh>     support.
<\sh>     - Malone: #55847
<ln-> and when is this linux-source-2.6.15_2.6.15-26.47 coming out, or is it out already?
<ln-> because... the latest Dapper kernel still suffers from this bug.
<ln-> that is, 2.6.15-51-686.
<\sh> ln-, it was already released
<\sh> ln-, if this issue still exists, please ping benC on ubuntu-kernel and ask why the fix is not working anymore...
<\sh> 2.6.15-51 looks like a dapper-proposed kernel to me
<Nafallo> \sh: the fix is not working cause the user has the wrong kernel :-)
<Nafallo> so no need to ping Ben about it.
<ln-> what is "the wrong kernel", and what would be "the right kernel"?
<\sh> Nafallo, well, the proposed kernel series could be the next -security upload, so it should contain the 2.6.17 skge source as described in the changelog :)
<Nafallo> \sh: but it isn't from what I remember
<Nafallo> the 50 ABIs are something weird and obscure :-P
<\sh> Nafallo, then something went wrong with it...so the -kernel guys are the right people to ask why...
<ln-> 2.6.15-51-686 came through apt as a normal update.
<Nafallo> ln-: what happens if you use 26.47 or later?
<calc> has anyone noticed that nautilus can't open text documents unless they end in .txt now?
<\sh> ln-, check your sources.list please..if you have dapper-proposed enabled
<calc> its something that appears to have changed in gnome/nautilus in the past couple weeks
<calc> it says "There is no application installed for this file type"
<calc> for a text file i have called "irc.channels"
<ln-> \sh: no, i don't have.
<Nafallo> calc: lots of stuff has that. docx, rar, zip amongst other.
<calc> Nafallo: huh?
<calc> Nafallo: this is just bog standard text edited with vi, before gnome/nautilus knew how to open it, i think it probably used 'file' to determine what it was, now it seems it must be using the file extension
<Nafallo> calc: that they are not associatied. at least here.
 * calc probably needs to ping seb128
<calc> looks like he isn't online right now though
<ln-> Nafallo: 26.47 is in dapper-proposed or something?
<calc> Nafallo: but yea i know what you mean wrt docx, etc
<calc> Nafallo: this is happening on just a standard text file
<calc> ccheney@desktop-c2d:~/Desktop$ file irc.channels
<calc> irc.channels: ASCII text
<calc> nautilus should be able to figure that one out (it used to anyway)
<\sh> ln-, the last dapper-security kernel image is Package: linux-image-2.6.15-25-686 as far I can read the Packages.gz from dapper-security
<\sh> ln-, and Package: linux-image-2.6.15-51-686 comes from dapper-proposed
<\sh> ln-, so you have somehow dapper-proposed channel activated somehow
<ln-> err.. we used 2.6.15-25-686 something like more than 6 months ago, since then there have been -26, -27, -28 and -29, and now -51.
<Nafallo> https://edge.launchpad.net/ubuntu/+source/linux-source-2.6.15
<\sh> well dapper-security is the latest kernel-image linux-image-2.6.15-29-686 to be more accurate
<crimsun> linux-source-2.6.15 | 2.6.15-51.64 | dapper-updates | source, all
<\sh> crimsun, bah...that's why I don't use -updates on my dapper server ;)
<ln-> actually, i don't think i'll be spending any more time trying to get this bug fixed.  if a trivial vulnerability cannot be fixed in 15 months, then it obviously cannot and will not.
<\sh> ln-, as I said, ask BenC .. he knows why this is not anymore in the -updates kernel...
<ln-> "anymore"? has it been at some point?
<\sh> ln-, in the -security kernel skge source was updated to the 2.6.17 skge source...so yes, -security kernel has (should have) the fix ready...I don't know why -updates kernel doesn't have, but I'm not using -updates packages at all, only -security
<ln-> \sh: are you referring to 2.6.15-26.47 in the changelog, and the line: "skge: Update to version in 2.6.17, to obtain fixes and D-Link DGE-530T support." ?
<\sh> ,
<\sh> ln-, yes
<ln-> \sh: in that case, take a close look at this bug report: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/65631
<ubotu> Launchpad bug 65631 in linux-source-2.6.15 "skge driver broken: invalid call to spin_unlock causes system crash" [Medium,Fix committed]
<ln-> i.e. the one related to the CVE report.
<ln-> \sh: it appears that the update from 2.6.17 was exactly when the driver was *broken*, not fixed.
<\sh> ln-, then something really strange happend, and it's still a bug for the kernel guys...
<CarlFK> UsePAM fell out of hardy's /etc/ssh/sshd_config - where can I see proof, and maybe a reason not to file a bug report?
<Chipzz> debian changelog would be a good place to start
<CarlFK> according to #debian, it is still in
<Chipzz> no, the debian changelog of the package
<Chipzz> lemme give ou a hint
<CarlFK> ah - is this the most recient: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssh/openssh_4.7p1-2/changelog
<Chipzz> zless /usr/share/doc/openssh-server/changelog.Debian.gz
<CarlFK> "    - Remove hacks to support the old PAM configuration scheme."   think that applies to
<CarlFK> UsePAM?  the change caused an account to get locked out
<CarlFK> er, that sounds like a migration issue.  fresh box, same setup that worked on gutsy doesn't work on hardy
<CarlFK> cjwatson your name is on openssh_4.7p1-2/changelog - should I assign a bug against it to you?
<CarlFK> hi buddy :)
<Nafallo> CarlFK: you never assign bugs to anyone else.
<Nafallo> CarlFK: I'm sure Colin has OpenSSH as bug contact.
<CarlFK> Nafallo: are you saying that as the general policy, or did you scan my bug reportting history and see a trend? :)
<Nafallo> CarlFK: I'm saying that is the policy.
<Nafallo> CarlFK: subscribe, but not assign.
<CarlFK> Nafallo: figured.  it just happens that 90% of the bugs I find seem to fall into Colin's inbox
<\sh> who is responsible for the ubotu bot?
<Mithrandir> \sh: seveas, I believe
<\sh> Mithrandir, thx
<ln-> where is the discussion about the recent xorg update that broke things?
<ln-> the why-it-happened-and-how-to-prevent-it discussion.
<\sh> ln-, on the ML?
<\sh> ln-, if there was such a discussion, then on the ML or in one of the bug reports
<ln-> one of the bug reports it was implied that there would be such a discussion, and i was wondering if someone has a url to it, if it ever took place.
<\sh> what could trigger an restart of trackerd even with trackerd disabled in gnome-session management?
<ion_> Some program querying its DBus interface, i think.
<zoke> are we shipping hardy with NM 0.7 ?
<Riddell> evand: seen this? http://ubuntuforums.org/showthread.php?p=4214799
<Skiessl> can someone make a multithreaded version of pdfcrack? :/ it's too slow atm
 * Mithrandir kicks java in the nuts.
<Mithrandir> I can choose between icedtea which doesn't contain HTTPS/SSL support or j2re1.4 which dies with java_vm: xcb_xlib.c:82: xcb_xlib_unlock: Assertion `c->xlib.lock' failed.
 * Mithrandir sighs and goes to do something else.
<Fujitsu> There's an environment variable you can set to fix that error.
<Mithrandir> X_STAB_HARDER?
<Fujitsu> Hah.
<Fujitsu> LIBXCB_ALLOW_SLOPPY_LOCK, perhaps.
<Fujitsu> Set it to 1.
<Jultomten> I'm having trouble with Apache 2.2.4/Ubuntu 7.10 hanging after a while, answering connections but not providing any responses. Anyone feel like helping me debug it? It's hung right now.
<persia> Mithrandir: Running sed -i 's/XINERAMA/FAKEEXTN/g' /opt/sun-jdk-1.6.0.02/jre/lib/i386/xawt/libmawt.so for sun-java6-bin is also reported to work (see bug #87947)
<ubotu> Launchpad bug 87947 in libx11 "xcb_xlib.c:50: xcb_xlib_unlock: Assertion `c->xlib.lock' failed." [Medium,Fix released] https://launchpad.net/bugs/87947
<Chipzz> Jultomten: this channel is not for support
<jdong> vorian: hey, ktorrent-kde4 3.0~rc1 is out, ktorrent.org, you gonna grab it?
<vorian> jdong: sure\
<jdong> vorian: awesome :)
<vorian> jdong: what version were we going with here?
<jdong> vorian: 1:3.0~rc1 should work?
<vorian> ah, right
<vorian> :)
<jdong> http://ktorrent.org/downloads/3.0rc1/
<vorian> already working on it jdong :)
<jdong> :)
<jdong> one step ahead :)
<jdong> vorian: you got the watchfile okay, or do I need to give you the one I just wrote for 2.x.x?
<vorian> jdong: this worked for me
<vorian> http://ktorrent.org/downloads/([0-9].*)/ktorrent-(.*)\.tar\.bz2
<vorian> (and notated on the changelog)
<jdong> vorian: I'd do (^3\.[\d\.]+) for the directory
<vorian> I'll give it a whirl
<jdong> vorian: currently both give the same result but it's better if we more explicitly catch the 3.x.x series
<vorian> good point
<bryce> lool: I've also heard sru-related issues from other corners
<bryce> lool: I myself have felt the process to be rather bureaucratic and overly time consuming
<bryce> lool: unfortunately, when I raised the concern (particular as related to sru's for X drivers), the sense seemed to be "It's good that it's hard and time consuming to do sru's, that way people won't bother doing them unless it's extremely important."
<bryce> lool: yet I think in actuality the result is people also aren't doing sru's even when it *is* important.
<bryce> lool: I also worry that out of hand dismissing complaints about the sru process, may result in hiding real problems that may end up hurting Ubuntu longer term
<LaserJock> bryce: I think perhaps a "backporting only" policy is also a bit frustrating for upstreams that do bug-fix only releases
<bryce> LaserJock: that's certainly true
<jcastro> bryce: LaserJock: I just sent a mail to the upstream guys wrt. the SRU policy
<bryce> LaserJock: it's ironic that with Inkscape, I put a lot of extra effort to ensure we got 0.45.0 out in time for Feisty feature freeze - which we did but missed several important bugs in the process - and then put out a subsequent 0.45.1 bugfix-only release to fix the issues, but it ended up that every release EXCEPT Ubuntu benefitted from the bugfix release.
<bryce> er, "every distro EXCEPT Ubuntu..."
<jcastro> bryce: I think revisiting the SRU policy might be a good idea
<elmo> bryce: well you could avoid that by targeting beta, like gnome does/we do with gnome
<jcastro> especially if upstream is jumping up and down
<LaserJock> elmo: but that's only to a certain extent
<elmo> and I'd like to balance 'woo SRUs for all' by reminding people that we can only take so many 'blue screen of death' SRUs...
<LaserJock> elmo: what about bug fixes after Ubuntu's release
<bryce> elmo, well, we'll see... we're going to be in a similar situation this time around
<LaserJock> elmo: yes, but should we punish *all* packages for that? It seems to me that some sort of differentiation between X and kernel type packages that are hardware-related and more difficult to ensure no regressions and desktop packages that have a much lower risk of "big" problems
<LaserJock> seems to me that 1-2 weeks of -proposed testing should easily determine if a SRU is gonna work or not
<LaserJock> that first sentence wasn't "well formed" exactly
<LaserJock> just trying to say that our exposure to risk is fairly dependent on the type of software and how upstream does releases
<elmo> LaserJock: sure.  but there's also sometimes a big disconnect between upstreams and the impacts of changes they're making
<elmo> on users
<elmo> you say 1-2 weeks of -proposed testing is enough for anyone, but I'd ask how we know it's getting tested in proposed
<bryce> LaserJock: agreed - particularly in the case of a discrete end application like Inkscape, the worst damage that can occur would be that inkscape would be broken, but it would certainly be not in our upstream interest to risk that
<elmo> stuff going into -updates scares the hell out of me.  -security is a necessary evil, but I (and I'm just one data point of course), would run around disabling -updates on users computers if the SRU policy got any more slack
<bryce> I can see a strict policy being more important with kernel, driver, or library updates
<jcastro> bryce: I was just brainstorming that a "desktop SRU" might be a good idea
<elmo> I don't understand the fixation on hardware related packages.  if someone takes out thunderbird in -updates, it might as well be X, for users in our office, f.e.
<jcastro> for desktop apps
<elmo> no mail - no work
<jcastro> elmo: but what if you get an explicit message from upstream to ship an upgrade?
<LaserJock> elmo: true, but testing is easier, in general
 * Fujitsu notes that we have enough breakage in -security, and daren't think what a slacker SRU policy would do.
<elmo> jcastro: that should be taken into account, but it's not gospel, any more than we don't ship completely unmodified packages from upstream as a rule
<jcastro> elmo: fair enough
<elmo> LaserJock: yeah, that's a fair point
<LaserJock> Fujitsu: but if upstream is fixing bugs for our users why should we not get those fixes to users?
<elmo> it's possibly worth pointing out that the last couple of major breakages in -security have come from _upstream's fixes_
<emgent> heya
<Fujitsu> elmo: Exactly.
<Fujitsu> Samba, X...
<LaserJock> yes, that can certainly happen
<elmo> LaserJock: hello, false dichotomy ;-)
<jcastro> elmo: and on top of that, some upstreams do bugfixes only on certain branches, and some do new feature work
<jcastro> it's a tough problem to fix
<LaserJock> but throwing out the baby with the bath water is not helpful
<bryce> I'd never argue that testing should not be thoroughly done or that the process should be "slacker"; but that the sru process as currently written is extremely labor intensive to whomever wishes to push the sru along, and is likely resulting in people not wishing to help in the sru process, with the consequence that justifiably important sru's are not getting through.
<LaserJock> if what we need is more testing then fine, let's get better testing
<LaserJock> but our current policy is to basically not even let a lot of things get that far
<Fujitsu> Where do we get better testing?
<elmo> LaserJock: err, how so?
<jcastro> is there an lp query that shows pending SRUs that haven't been applied?
<bryce> also, as the SRU page indicates, SRU != security updates
<bryce> security updates have a much slacker process than the SRU process
<LaserJock> elmo: our current policy is turning off people because of "excessive bureaucracy" and we have a "backport only" policy rather than allowing a new upstream release
<bryce> since they can't wait several weeks or months to go out
<LaserJock> Fujitsu: well, the guy I talk to said maybe some better PR "Get the latest gnome early!!" might help
<LaserJock> as far as I can tell very few people are being recruited to test
<bryce> LaserJock: I had really good results recruiting testers via the forums for checking my Xorg packages during gutsy
<LaserJock> I certainly don't have the solutions here, but it seems that Ubuntu is much stricter for SRU than other distros
<bryce> agreed
<Burgundavia> fedora is loser, but then has isuses with that
<asac> bryce: well you can get general feedback, but you will miss corner cases ... and those are mostly the ones that regress in such an upstream-bugfix-only-release
<LaserJock> and it makes me wonder if were fixing a lack of testing by using stricter policy
<LaserJock> *we're
<Fujitsu> Fedora appears to push new upstream versions for security fixes, even if they have other fixes/features.
<asac> LaserJock: we allow reviewing by that policy ... and reduce the risk of regressions
<LaserJock> asac: but a lot of people look at the policy and just don't bother
<LaserJock> I would think that the "weeding" out should be done at testing time, not paperwork time
<elmo> so, one thing I don't understand about "it's too bureaucratic" - can you give a concrete suggestion of how it could be made less so?
<LaserJock> elmo: well, if you look at Fedora basically any developer can push to -updates and the often push new upstream release
<LaserJock> or rather to a -proposed like repo
<elmo> LaserJock: so you're advocating removing the entire SRU process?
<asac> LaserJock: well ... testing is good, but as i said above, its not enough: you will surely miss corner cases.
<bryce> elmo: I would point to the length of https://wiki.ubuntu.com/StableReleaseUpdates as a starting point - it's tiring to read let alone follow all the steps
<LaserJock> elmo: umm, I guess I'm saying that that seems to work for others
<jcastro> elmo: http://blogs.gnome.org/phomes/2008/01/26/ubuntu-update-policy-suckage/
<Fujitsu> Does it work?
<LaserJock> elmo: I'm not convinced that we need *no* SRU policy, but perhaps a significantly looser one would still work
<jcastro> LaserJock: I don't think comparing to fedora is fair
<LaserJock> oh?
<LaserJock> why not?
<jcastro> they specifically don't have a "stable" release like we do
<Fujitsu> Don't they?
<jcastro> they like, push new major kernels, dbus, etc., to their "stable" release
<LaserJock> but they have a very succesfull product
<Fujitsu> Ew.
<jcastro> "stable" being defined as "unchanging"
<broonie> Automated building of SRU candidates without an ack from the team might be helpful for jollying the process along (this may be happening now, duno).
<LaserJock> jcastro: but that's exactly what people are often upset about
<jcastro> LaserJock: that depends.
<asac> LaserJock: you usually don't know the voice of those that are happy - even though they might be the majority
<jcastro> If I was deploying something, in production, I don't want major new versions, I want something unchanging
<elmo> LaserJock: dude
<elmo> LaserJock: you're never going to make everyone happy
<bryce> elmo: there are a lot of "musts" which are sometimes difficult to do.  For example, you "must" provide a test case to reproduce the issue.  In many cases users will tell you "X randomly fails," and confirm that such and such a patch fixes it.  But then you're left having to translate "randomly fails" into a reproduceable test case.  I usually just give up and refuse to sru the fix.
<LaserJock> elmo: granted
<geser> people will also complain if one updates of hundred breaks their system
<jcastro> ^^^
<elmo> LaserJock: if you removed the SRU process like you suggested, I would start a blog just so I could rail about how much Ubuntu sucks
<Fujitsu> geser: Rightly so.
<LaserJock> but it seems like we're working much more on the assumption that our stable releases are "stable" and "bug free" than is reality
<elmo> LaserJock: some of us value stability and can deal with known bugs vs the risk of regressing production environments
<jcastro> elmo: he didn't suggest removing the SRU process, just relaxing it
<elmo> jcastro: actually he did
<bryce> elmo: I also ran into massive bureaucracy with trying to get 0.45.1 into feisty.  That bug fix release had several dozen patches to fix a wide variety of issues reported upstream.  It was reviewed and only 4-5 were deemed "critical fixes".
<crimsun> does Ubuntu have a release manager who can kindly override SRU policy?  (where "kindly" obviously implies "sanely")
<LaserJock> elmo: no, I didn't, I said that was what Fedora did
<LaserJock> elmo: I said previously that I think relaxing it might be a sane thing, but not getting rid of it entirely
<jcastro> I don't think that doing something because Fedora does it is a good idea either.
<LaserJock> no, of course not
<LaserJock> I'm just trying to look at examples
<bryce> elmo: unfortunately, the main issue users complained about wasn't included in that list, and 2-3 of the fixes were hard to describe.  Also, extracting those specific 4-5 fixes from the set was time consuming since upstream hadn't individually called out each patch.
<jcastro> fair enough
<Fujitsu> bryce: One should shoot upstream in that case. If you stab them enough, they normally eventually release sane patches.
<LaserJock> because if upstreams are saying "Ubuntu is a problem because it's not taking our bug fixes" I'd like to know it it's really us or if that's a general problem with all distros
<elmo> Fujitsu: ha ha.  bryce == upstream
<elmo> bryce: sure, I'm not arguing the current practice is perfect.  and perhaps y'all should get a similar exemption to the gnome guys
<LaserJock> crimsun: that'd be nice
<jcastro> I think that there should be an SRU process where upstream can say "we're upstream and we'd like this version to be the one in a stable ubuntu release."
<elmo> bryce: I'm just super leary of more breakage in -updates, and think the 'make SRUs easier' crowd are waving their hands a little vigourously ;-)
<broonie> It might also help if the process were more directly implemented in Launchpad - given the latency involved it'd be good to avoid procedural errors.
<bryce> Fujitsu: trust me, I was thinking seriously of shooting myself after going through all this!
<elmo> broonie: yes, that jumped out at me too
<elmo> there's a lot of manual fluff in there that could at worse be scripted, or better yet have built-in LP support
<LaserJock> yep
<superted> does anyone know if there will be any regularity to language packs in hardy and if so how often they will be realeased?
<LaserJock> elmo: I think I'd advocate "make SRUs saner" over "make SRUs easier"
<asac> LaserJock: for that you need to state what is not sane atm
<asac> ?
<LaserJock> asac: blanket policies
<LaserJock> lots of manual work
<LaserJock> when, as elmo said, a lot of this should be in LP
<bryce> elmo, it seems that the only two options are excessive hand waving, or just ignoring the whole SRU process and let users suffer
<bryce> I hate to admit that I've pretty much adopted the second option.
<jcastro> asac: but in this case, bryce is upstream, shouldn't he have direct control of how his package is represented in ubuntu?
<elmo> bryce: I strongly disagree
<elmo> bryce: the problem is both you and laserjock are complaining but unwilling to break things down into _specific_ things which could be improved
<LaserJock> elmo: ok, let me break it down, at least as far as I can see it
<LaserJock> 1) better tracking of upstream release of stable series
<geser> jcastro: that assumes a sane upstream that only wants a bugfix release in a stable distro and not the last and "best" release of their software
<LaserJock> 2) some sort of classification or tiering that make high-risk packages harder to break and low-risk packages easier to update
<LaserJock> 3) increased testing efforts
<jcastro> geser: yep. that's what makes this so hard. You can't have a blanket policy if you want to make everyone happy, it really all depends per-project
<jcastro> which is why this is so hard
<LaserJock> those are a few things that I think might help
<bryce> elmo, ok I thought I was being specific enough:  Reduce the number of steps, quantity of labor, and number of iterations with reviewers/approvers involved in filing an SRU.
<jcastro> you can't just blindly say "upgrade at will, you're upstream."
<asac> jcastro: in general i would say no. upstream will always push to fix as many bugs as possible, so their application is perceived as prefect as possible to the majority of their users. the distro itself is more scared about regressions that might hit a minority of production deployments.
<elmo> asac++
<jcastro> asac: probably because upstreams mostly care about their package, not how it affects the rest of the distro
<LaserJock> asac: right, so we're trying to get as many fixes with the least amount of regressions
<asac> jcastro: for bryce case, i don't know ... their is certainly a conflict and it depends on how he resolves this in his own heart
<elmo> bryce: well, umm, not being funny, but 'reduce the number of steps' isn't specific.  "take out step 5, it's unnecessary for this reason" would be specific
<bryce> elmo, I went through a number of ideas with pitti at the previous sprint, but basically got told, no, no, no, no.  So I gathered there was little benefit to try giving specific change requests; everything just gets denied.
<jcastro> asac: for example in your case, if we blindly accepted FF's upgrades and just upgraded everything, half the distro would break
<asac> jcastro: right ... well fixing bugs will benefit them more, but we have to be the ones denying requests so we can really claim to provide a stable distro
<crimsun> bryce: did you suggest a $release-proposed-upstream component?
<jcastro> bryce: out of curiosity, do you guys have an inkscape ppa?
<asac> jcastro: yes ... unfortunately firefox is really a case where we do this ... and i always start to pray after the upload - which is why how hard it is to guaranteee regression-freeness.
<elmo> (I have to run away - interesting discussion though...)
<jcastro> nite elmo
<LaserJock> asac: but FF is a bit of a tough case
<asac> (i try to review as hard as possible, but there are 200 bug fixes vs. 70 security fixes in such a release)
<asac> LaserJock: yes, but we track them carefully ... we have to think about all packages if we want to come up with a policy
<asac> there might be upstreams with really strict policies ... but there might be ones with slacky policies
<LaserJock> asac: but that's my point, we need finer grained policy. A blanket policy doesn't seem to really suffice
<jcastro> asac: EXACTLY!
<bryce> jcastro: yes we do
<asac> but those that have strict policies usually provide individual patches anyway
<asac> and thus providing them as "backports" shouldn't be a problem
<asac> LaserJock: well ... the reviewer somewhat has to decide and who can bend the policy. its mostly about what is "critical" and how risky do those patches look like
<asac> so its not really a blanket policy atm imo
#ubuntu-devel 2009-01-19
<billisnice> alpha 3 out?
<Laney> billisnice: see /topic
<billisnice> lol, seeing the topic would be good
<billisnice> does ext4 install auto this time?
<directhex> is ext4 upgradable live, the way 2->3 is?
<Laney> I think so, but you don't get some feature or other
 * Laney knows not much about this
<billisnice> I still do not know how to switch to ext4? Where are the instructions
<Laney> billisnice: Probably best for #ubuntu+1
<RAOF> directhex: Yes it is, but some features only apply to new files.
<directhex> RAOF, and backward compatible e.g. using the ext2 driver for windows?
<RAOF> directhex: Not new files; they'll be using extents, which aren't backwardly compatible.
<directhex> hm. i hope someone cobbles together a driver, then
<NCommander> persia, you around?
<persia> NCommander, ?
<NCommander> persia, do you know how to modify a COPYING file to include two licenses (do I just stick the second one in there or do I need to list what files are licensed what (everything has the right header)
<persia> NCommander, Context?  You're working upstream, and merging in code with a different license?
<NCommander> persia, no, upstream has code under two licenses, the copying file only has one, but they're willing to change the copying file provided I give them a diff :-)
<NCommander> (and thus also let me get the compontent into Ubuntu once I repack)
<persia> Well, I don't know best practice for that.  My personal preference when reviewing copyright for a package is that COPYING contains information about who holds copyright over which files, and under which licenses, with pointers to external files (also in ./) for specific licenses when multilicensed, or an inline license when there is only one.
<persia> I suspect that's against the intent, and that best practice would be for COPYING to contain something like "foo is released under the the GNU Public License version 3, and includes components bar and baz previously released under the GNU Lesser Public License version 2.1, ..."
<NCommander> Ok, that works for me.
<jharr> cjwatson, maxb: I'm trying to build a bootable chroot. binfmt stuff isn't working (trying to execute perl scripts with [ba]sh); e1000.ko module isn't loading automatically (am I missing a modprobe package or something?).
<jharr> cjwatson, maxb: there's a lot of things I could hard-code for my purposes, but I'm trying to get it to work automatically. I'm building a vnfs capsule generator script for perceus and want it work on other hardware.
<jharr> If anyone has suggestions as to where to go to ask for this sort of thing, let me know. From what I know about #ubuntu, this question is probably not well suited to that channel :p
<persia> jharr, regarding binfmt, is binfmt-support installed in your chroot?
<persia> jharr, It's mildly offtopic for this channel, but no, there's probably not a better place (to my knowledge).
<jharr> persia: thx :)
<jharr> You know, I'm an idiot for not checking this... /usr/bin/perl is there, but it's 0 bytes
<jharr> Turns out /dev/pts wasn't being mounted by debootstrap, which borks perl's install.
<jharr> Let me see what version of debootstrap I have (I'm doing this from a CentOS 5.2 box and an rpmforge.net verison of debootstrap, don't hit me).
<jharr> I'll go poke around with that, thanks for the tips.
<bluefoxicy> WARNING: The following packages cannot be authenticated!
<bluefoxicy>   libavdevice52 libimlib2 ffmpeg
<bluefoxicy> ^^^ is this supposed to happen  after apt-get update fails ENONETCONNECTION?
<jharr> Installing binfmt-support in a chroot and it's borking at the "setting up" phase. Apparently because it's getting the wrong info from uname (b/c of the chroot)
<jharr> FATAL: Could not load /lib/modules/2.6.26.5-2.nsa1/modules.dep: No such file or directory
<dholbach> good morning
<jharr> dholbach: good morning
<dholbach> hey jharr
<jharr> maybe this is in the init script for it
<jharr> Is there any way to prevent a package from calling an /etc/init script?
<jharr> when it's installed
<grndslm> how do the three different repos work (regular, -updates, & -security)??  if an update is made to -security... the code in the other 2 are also updated?  or if an update's made to -updates... the code in -security isn't updated, right?
<LaserJock> nothing goes into the regular repo after release
<LaserJock> stuff goes into -security for security updates or -updates for critical non-security updates
<LaserJock> but often times the stuff in -security get's copied over to -updates to take some of the load off the servers
<karthik> hey help me where can i get info on how to create a workspace
<LaserJock> grndslm: does that sort of answer the question?
<grndslm> LaserJock: kinda
<grndslm> mostly yes
<LaserJock> karthik: what do you mean by a workspace? I'm guessing this isn't the right channel
<karthik> LaserJock: we can some define it as a virtual desktop..
<LaserJock> karthik: you should probably ask #ubuntu
<karthik> LaserJock: i'm trying to implement using a c program
<superm1> jharr, --no-start as an argument to dh_installinit.  there's a variety of other ones too for other situations.  look at dh_installinit's man page for more
<jharr> superm1: thx
<karthik> hey any one help abt how to create a virtual desktop
<karthik> using a c prog
<pitti> Good morning everyone!
<Hobbsee> hey there pitti!
<StevenK> pitti!!
<pitti> I'm back from skiing, and still in one piece :)
<tkamppeter> pitti, hi
<apw> pitti, thanks for applying mdz's patch saves me a job
<pitti> apw: you're welcome :)
 * apw throws away his debdiff
<pitti> apw: I just ran the script, and it works fine here on a Dell Latitude D430 after I fixed "pmi suspend" -> "pm-suspend"
<apw> yeah i seem to have something installed on my test boxes which isn't standard and i don't know why
<apw> is powermanagement-interface non-standard and if so how have i gotten it
<apw> i was under the impression that was the official interface to these operations
 * apw wonders how he would find out such a thing
<directhex> hm. pitti, you're the oracle for such things. can you tell me why the "ndoc" source package is in main? are there any clues in the vast swathes of files which decide which section to put things in?
<pitti> apw: pmi was installed by default until intrepid
<apw> hmmm, thats unhelpful
<cjwatson> jharr: you don't actually need binfmt-support unless you're trying to get things like Windows executables to execute automatically; #! lines are interpreted by the kernel and the only userspace support they need is for the relevant interpreter to work
<apw> i guess i need to go get the launcher and find out what the heck it calls
<pitti> directhex: http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.jaunty/rdepends/ndoc/
<pitti> apw: "launcher"?
<pitti> apw: if you mean the gnome-power-manager applet
<pitti> apw: it does a hal call, which in turn calls pm-suspend
<apw> i mean the thing that adds the suspend things to the menuything
<directhex> pitti, "* Extra seed"?
<pitti> directhex: yes, because the library is pulled in via dependencies, we keep the util in main, too
<cjwatson> jharr: dh_installinit --no-start is useful if you're building a package but I suspect that superm1 didn't realise you were building a chroot. Usually people just want to stop daemons being started. There are a couple of ways to do that kind of thing which hook in at different levels: to stop just the daemon being started, you can dpkg-divert the start-stop-daemon program; to stop the init script being called at all ...
<cjwatson> ... (usually), write a policy-rc.d script (see the invoke-rc.d(8) manual page).
<directhex> pitti, hm, i wonder why antlr uses it - it's a java thing!
<cjwatson> the antlr source package builds a libantlr2.7-cil binary package
<cjwatson> note that the antlr->nant arc is a build-dependency not a dependency
<directhex> bah, circular build dep between nant & ndoc
<mdz> apw: powermanagement-interface is something which is installed by default, but it's old and should probably be superseded by more recent development
<mdz> apw: this part of the stack needs the same sort of analysis and cleanup that slangasek is doing for hotkeys
<apw> yeah we are doing some stuff on this on the obsolete acpi duplicate suspend machinary
<mdz> TheMuso: I'm noticing that on both systems I've upgraded to Jaunty, my mixer levels are now muted by default, when they used to be set to sensible values
<cjwatson> mdz: powermanagement-interface was installed by default, but is no longer in jaunty
<cjwatson> that should be read "is no longer installed by default in jaunty" rather than "no longer exists in jaunty"
<cjwatson> it's still installed by xubuntu-desktop for some reason
<mdz> cjwatson: oh, good.  I didn't notice as it wasn't removed during the upgrade
 * mdz purges it
<mdz> a piece of history though
<mvo> cjwatson: I guess I should add a config entry that remove it for ubuntu-desktop users then on upgrade?
<cjwatson> mvo: hopefully it can drop to universe by jaunty release; but in the absence of that, I guess so, yes
<mdz> apw: as I wrote in the thread, pmi is actually doing something pretty close to what you'd want (talking to hal via dbus), it's just that it's probably no longer used by much of anything except your script ;-)
<mdz> apw: a copy/paste of the dbus-send logic might be the appropriate thing if there's no better tool for this case
<mdz> apw: I assume we'll want a very similar script for hibernate testing which will have the same issues
<pitti> mdz, apw: "gnome-power-cmd.sh suspend" would replicate it, but it needs to run as user, not roo
<pitti> t
<pitti> but you need root for programming the automatic wakeup (once that actually works)
<apw> and its gnome specifc i guess
<mdz> pitti: running as the user sounds like a feature
<pitti> yes, it is
<pitti> mdz: it would be, yes
<mdz> though there are a couple of things in the script which require root at the moment
<mdz> enable_trace and disable_trace
<apw> yeah the wakeup needs root right now, but that doesn't mean we can't dip in and out
<mdz> set_wakeup_timer
<mdz> writing the log too
<apw> its not impossible to split it into two cooperating halves
<thekorn> pitti: hi, when you have a minute, can you please look at bug 314212, I'm wondering if we should work around this in py-lp-bugs by trying to reupload if lp.net/+storeblob timeouts
<pitti> apw: you could use $SUDO_USER and such hacks, but I really think that using dbus-send to hal is the right thing to do
<ubottu> Launchpad bug 314212 in apport "Apport unable to report crash - urlopen error timed out" [Undecided,Confirmed] https://launchpad.net/bugs/314212
<pitti> thekorn: hm, I thought that would have been fixed in LP last week?
<mdz> apw: we'll need to do it anyway to make it fit nicely into a desktop-oriented test framework
<apw> pitti, i tend to agree that next step is probabally to use dbus.  tehn we can work on splitting it so that it can run as user at least in part
<mdz> I  think checkbox insists on running as root at the moment, but I'm inclined to consider that a bug (->cr3,heno)
<apw> which would fit with what mdz is suggesting there whcih i assume would include a pretty interface
<thekorn> pitti: me too, but there were some new reports about it over the weekend and some people complaining in #u-bugs
<thekorn> pitti: maybe this needs a launchpad task
<mdz> thekorn,pitti: I've had some cloakroom problems this morning as well
<mdz> I've seen both a) apport opening file://ubuntu rather than http://launchpad.net in firefox, and b) NotFound on the +filebug URL with the cloakroom ID
<pitti> mdz, thekorn: I wonder whether we are really talking about the same thing
<mdz> the former was intermittent, the latter persistent
<pitti> one was that the upload suceeded, but the +filebug/DEADBEEF page said "no such page"
<pitti> the other is that the upload itself times out/fails
<mdz> pitti: I agree that using dbus-send is the right thing to do, but it would be nice to abstract it away in a nice function which knows which dbus method to call and which argument to pass, etc...and we are back to pmi :-)
<mdz> pitti: is a) either of those, or are there three different problems?
<thekorn> pitti: right the "no such page" one was supposed to be fixed in lp last week
<pitti> mdz: a) sounds like you are using some test backend again?
<mdz> pitti: I literally retried with the same configuration and it worked
<pitti> mdz: b) is bug 311690, I believe
<ubottu> Launchpad bug 311690 in launchpad-foundations "Delay between blob submission and blob availability causes Launchpad to OOPS." [Critical,Fix released] https://launchpad.net/bugs/311690
<mdz> well, a different crash report actually, but otherwise the same
<pitti> mdz: if you have a reproducer for file://ubuntu, can you please mail me/create a bug report?
<mdz> pitti: 311690 was workaroundable before by waiting a few seconds and reloading; this time it's persistent
<pitti> so this needs to be reopened then?
<tseliot> hey pitti
<pitti> hey tseliot
<mdz> pitti: I can reproduce every time on this crash file, I'll send it to you
<mdz> pitti: while we're on the subject, I was thinking about whether it's still a good idea to defer collecting the hook information etc. until the user is notified about the report.  don't we have a beter chance of getting accurate and relevant data if we run the hooks and collect package info immediately when the crash happens?
<pitti> mdz: two reasons for this: (1) hooks often collect user data (gconf keys), but kernel-triggered apport runs as root, and (2) hooks can potentially take a lot of time, which doesn't have a progress bar when the crash happens
<pitti> mdz: however, for quick hooks which depend on timely information, we could have another class of hooks which run right away
<mdz> pitti: (1) is a legitimate concern, and perhaps there should be two types of hooks.  we already have both hooks which break because they require root, and hooks which expect user context (e.g. an X display)
<mdz> pitti: regarding (2), I think it's OK to run them in the background with high nice+ionice and not worry about how long it takes
<mdz> pitti: sometimes I've already installed updates before I report the bug, and the package info will be wrong
<pitti> mdz: oh, and a third reason is that at the time when the crash happens, we don't even know which package it belongs to
<mdz> pitti: it also makes it harder for things like X, which wants to get the log file before it's rotated away
<mdz> pitti: we can look that up, the only reason we don't do it is (2) right?
<pitti> mdz: right, because dpkg -S takes so awfully long
<mdz> not only because it takes so long, but because it bogs down the system (I think ionice -c3 would address that)
<pitti> mdz: ionice/nice would take care for the "bog down system" only partially
<pitti> since you still need to wait for that long until the app actually disappears and you can restartit
<pitti> but in a dev release that's certainly bearable
<mdz> pitti: why? it should be possible to collect the info after the process has ended
<pitti> hmm
<pitti> apport could fork()/setsid() itself after collecting core dump and /proc, probably
<seb128> what is the discussion about? running apport on stable versions?
<pitti> seb128: no, running hooks when the crash happens, as opposed to when the UI runs
<seb128> ah ok
<pitti> running it on stables is not just a performance issue (that's actually the least important reason)
<tseliot> seb128: I have fixed this bug and provided upstream with patches (which are no longer workarounds): https://bugs.edge.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/307306
<ubottu> Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress]
<seb128> tseliot: that was not a gnome-settings-daemon bug then?
<tseliot> seb128: it was a bug in both gnome-settings-daemon and gnome-power-manager. They use an expensive RandR call every time an event is triggered
 * pitti hugs tseliot
<seb128> tseliot: ok
<tseliot> pitti: the patches are in the upstream reports, if you want to try them
<cjwatson> doko_: have you noticed that there are comments in bug 235070 indicating that it isn't fixed in hardy?
<ubottu> Launchpad bug 235070 in gcc-4.2 "Please apply libgomp patch to GCC for Hardy Heron" [Undecided,Fix committed] https://launchpad.net/bugs/235070
<cjwatson> (despite the presence of that patch in hardy-updates)
<apw> cjwatson, is it reasonable to rely on the fact that a dpkg-buildpackage will 'clean' your source tree before packaging it|
<cjwatson> apw: yes
<cjwatson> (there's an -nc flag in case you don't want that)
<apw> and would it be reasonable to fix permissions in your source tree while cleaning it
<apw> you can't say -nc with -S its not legal
<cjwatson> yes, but it might be better to fix permissions just before using the scripts in question
<cjwatson> actually, I think I may have misunderstood you
<cjwatson> you cannot rely on clean being run after extraction
<cjwatson> and adding executable bits before building the source package will do you no good - they need to be applied after extraction
<apw> so there is no hook for makeing sure the tree is ready
<cjwatson> do it in the build target instead
<cjwatson> sure there is, 'build' :-)
<cjwatson> build can depend on whatever it needs
<cjwatson> (or just do it inline)
<apw> and thats safe in the face of parallel builds
<cjwatson> if debian/rules is written correctly, yes
<apw> got any info on what 'correctly' is in this cas
<apw> case
<cjwatson> info make
<cjwatson> I believe it has information on ordering
<cjwatson> for example, 'build: dep1 dep2' means that dep1 and dep2 may be run in parallel, while 'build: dep2' and 'dep2: dep1' means that dep1 must be completed before dep2 starts
<apw> that would make sense to my expectationh of make behavior
<apw> ok will try it that way.  i do not want to fix every build target for the kernel, its toooo likely to go wrong
<cjwatson> you already have prepare- targets in debian/rules.d/2-binary-arch.mk
<apw> yeah but they are for the binary components, and i need to ensure i beat the headers too
<cjwatson> you can also call debian/rules recursively if it makes things easily
<cjwatson> easier
<cjwatson> so 'rulename:\n\tchmod blah;\n\tdebian/rules prereq1 prereq2'
<cjwatson> policy and the dpkg-dev toolset just specify a minimal interface - it's for maintainers to build richer things on top of that
<apw> i think i can use the same prepare concept in here for everything, have a general prepare
<apw> its just a lot of complexity to paper over the loss of information in the packaging system.  sigh
<luisbg> is it a holliday today in the USA?
<directhex> MLK today
<directhex> i think that's an optional holiday
<luisbg> directhex, ok cool thanks
<apw> optional?
<luisbg> :)
<tkamppeter> pitti, please do not yet upload CUPS or pass through my upload into-proposed (bug 310575). I have still to add a fix.
<ubottu> Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Medium,Fix committed] https://launchpad.net/bugs/310575
<pitti> tkamppeter: ok; I rejected it from the intrepid queue
<ogra> urgh, hall in C++ ?
<ogra> *hal
 * ogra is scared
<tseliot> ogra: are you talking about libhal++ or what?
<ogra> tseliot, about the recent annoucement on the hal ML
<ogra> yes, seems to be libhal++
<ogra> a fork/reimplementation
<ogra> "HAL/C++ is a _reimplementation_ of libhal and libhal-storage in pure C++, using dbus-C++."
<tseliot> aah, this one: http://projects.backtrace.info/pmwiki.php?n=Main.Halmm
<tseliot> ok
<ogra> right
<tseliot> sooner or later we'll use DeviceKit
<ogra> "It is modeled after the original libhal and libhal-storage, but does not aim at complete adherance to the original API."
<ogra> thats scary
<tseliot> it depends on what you plan on doing with it
<ogra> well, apps will still use libhal for quite a while ... it takes its time until linked apps will switch
<broonie> ogra: It does make some sense to have an API that makes sense in the language you're working with rather than another language that happens to link with it.
<ogra> broonie, right, but it doesnt make sense to reimplement it in a fresh fork ...
<ogra> instead of just adding to the existing code and thus keep API/ABI compatibility
<broonie> Uh, doing something sensible in $OTHER_LANGUAGE rather implies breaking those; one of the wins with DBusing stuff is to keep a cross language ABI at the DBus level rather than lib level.
<ogra> well, still new implementation requires new documentaion etc etc ... while as tseliot says a completely new system is in the work
<Keybuk> mvo: do you know of anything that would call udev{adm ,}trigger on an upgrade?
<james_w> is it fine for any old package to use lzma compression and Pre-Depend on the relevant dpkg version?
<pitti> james_w: for most, anyway; it should probably be avoided for base packages, to avoid breaking debootstrap
<james_w> it's easystroke in universe
<james_w> the contributor, and upstream maintainer, added it in the latest upstream version, I just wanted to make sure it wasn't against policy
<tkamppeter> pitti, I have released Foomatic 4.0 last week. Intrepid ships only a BZR snapshot. The BZR snapshot has some bugs, once Intrepid does not pass the LSB 3.2 compliance tests (http://bugs.linuxbase.org/show_bug.cgi?id=2423) and second, there are two bugs reported to Ubuntu: bug 299918 and bug 303691
<ubottu> Launchpad bug 299918 in foomatic-filters "Cannot print duplex in intrepid with Ricoh Aficio 2060, Ricoh Aficio MPC3000 or Brother HL-4050cdn using the openprinting drivers" [Medium,Fix released] https://launchpad.net/bugs/299918
<ubottu> bugs.linuxbase.org bug 2423 in lsb-test-printing "foomatic-rip tests fail against foomatic-filters-4.0" [Normal,Resolved: notourbug]
<ubottu> Launchpad bug 303691 in foomatic-filters "Intrepid, print broken with Minolta PagePro 8L printer" [High,Fix released] https://launchpad.net/bugs/303691
<tkamppeter> So I am thinking about an SRU for Intrepid updating foomatic-filters to 4.0.0 final.
<pitti> tkamppeter: are any of those regressions from hardy?
<tkamppeter> Yes, as Hardy still shipped the Perl version (3.0.x) of foomatic-filters. All three bugs did noty occur with that version.
<pitti> tkamppeter: remember that if you upgrade to the final 4.0, *all* of the changes have to pass SRU criteria, otherwise we should just backport the specific changes (if they are serious)
<tkamppeter> pitti, concerning bug 310575 now everything is ready, new fix committed to the BZR and uploaded to -proposed.
<ubottu> Launchpad bug 310575 in cups "A3 pdf file is cropped and printed on A4 paper" [Medium,Fix committed] https://launchpad.net/bugs/310575
<Keybuk> what's the right format of version number for an upload to hardy-propsed?
<ogra> oldver.1
<ogra> and make sure to not clash with security :)
<Keybuk> do you have to upload with hardy-proposed in changelog or hardy?
<mvo> Keybuk: udev-triggered-on-upgrade> no, but I can try to find out more about it - does it seem to happen on a standard upgrade?
<Keybuk> mvo: I guess - mdz is the only person to have reported it so far
<pitti> mvo: any idea what to do with bug 241431?
<ubottu> Launchpad bug 241431 in update-manager "edgy to feisty upgrades fail due to use of old-releases" [Medium,Fix released] https://launchpad.net/bugs/241431
<mvo> pitti: uf, the proper fix is to backport the code from the jaunty version so that it auto-detect if it needs to use archive.u.c or old-releases.u.c
<mdz> Keybuk: I'm on the machine now; is there anything I can look at for clues?
<Keybuk> mdz: I'm surprised there's nothing in /var/log :-/
<mvo> Keybuk: ok, is this for bug #317944 ? I have a look on my auto-upgrade testing image if it shows a similar behavior
<ubottu> Launchpad bug 317944 in udev "Wrong permissions in /dev after Intrepid->Jaunty upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/317944
<Keybuk> mvo: right
<mdz> Keybuk: syslog shows that syslogd was restarted a few minutes after the ctime on /dev/null, which explains why its socket is unmangled
<Keybuk> mdz: no messages from udevd?
<pitti> mvo: I don't feel we should do that for feisty, but for gutsy/hardy/intrepid it might be worthwhile?
<pochu> Keybuk: hardy-proposed
<mvo> pitti: ok
<mdz> Keybuk: none (ever, so far as I see)
<mdz> the only occurrence of 'udevd' is in dmesg
<Keybuk> right, it'll be in your dmesg history
<Keybuk> kern.log has timestamps
<mdz> Keybuk: it's not in kern.log at all
<mdz> dmesg.0:[   20.478679] udevd version 124 started
<mdz> dmesg.1.gz:[   22.546635] udevd version 124 started
<mdz> dmesg.2.gz:[   19.596002] udevd version 124 started
<mdz> dmesg.3.gz:[   18.636002] udevd version 124 started
<mdz> dmesg.4.gz:[   19.456003] udevd version 124 started
<mdz> those are the only occurrences
<mdz> (notably, it isn't in my current dmesg)
<lool> bug #223324 has 32 dups and seems to be a dup of bug #221781; is there a way to mass fix the dups of 223324?
<ubottu> Launchpad bug 223324 in scrollkeeper "Parser error in ///usr/share/gnome/help/blackjack/el/blackjack.xml : Entity 'ÎÎ¿Î®Î¸ÎµÎ¹Î±' not defined" [High,Triaged] https://launchpad.net/bugs/223324
<ubottu> Launchpad bug 221781 in scrollkeeper "scrollkeeper crashes during upgrade and causes maintainer script failures for various packages" [Undecided,Confirmed] https://launchpad.net/bugs/221781
<lool> If not, I think I'll just close 223324 and point at the other bug in a comment
<pochu> lool: not that I know of from Launchpad, but maybe bdmurray has a script to do it with python-launchpad-bugs
<pochu> I think I heard about such a script in the past
<james_w> https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-March/000800.htm
<james_w> https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-March/000800.html I mean
<lool> james_w: Thanks
<lool> It looks like I should spend some time to clean it up and integrate with u-d-t
<seb128> is there anybody working on freetype in ubuntu or talking to upstream sometimes?
<seb128> bug #277294 has quite some duplicate
<ubottu> Launchpad bug 277294 in freetype "evince crashed with SIGFPE, trying to seek in KXTGA930.PDF" [High,Confirmed] https://launchpad.net/bugs/277294
<seb128> doko_: http://lists.gnu.org/archive/html/freetype-devel/2008-08/msg00023.html indicates that could be a gcc issue, could you perhaps investigate this one?
<Keybuk> mdz: just to confirm something
<Keybuk> mdz: /etc/udev/rules.d is basically empty on your box, right?
<mvo> Keybuk: upgrade is running, it will be finished in ~30min
<soren> I'm working on a new package. It's somewhat lacking in the clear licensing area.  Only a select few source files specify the license, there's no "top level" license file or anything (the few source files with licensing information correctly state the copyright holder and references the Apache license).
<soren> I'm curious what the minimum to ask them to add would be for it to be acceptable for us.
<soren> I suspect this is not uncommon, so perhaps someone has already written up a template bug text for this sort of thing?
<Keybuk> generally a top-level licence is enough
<Keybuk> but that licence will likely say each source file should have a reference to it too
<cjwatson> missing licences from individual source files is a widespread failure/practice (depending on your POV)
<cjwatson> the GPL just says that it's "safest" to add notices to each source file, not that you must
<cjwatson> I think the idea there is that if you don't, people might rip out an individual file and say that they didn't know about its licence
<mok0> cjwatson: It's an exception that people do it
<mok0> cjwatson: exactly
<cjwatson> mok0: I wouldn't go that far but it certainly isn't anywhere near universal
<Keybuk> we still permit such things in the archive though
<cjwatson> I have never heard of a legal basis for saying that a top-level licence wouldn't apply to the other files
<mok0> The problem is: if just a couple of files are missing license clause, is it because upstream forgot, or did he rip the file off somebody
<ogra> though if you want your package to enter debian at some point you better add a license note to each single file :)
<cjwatson> a judge would not be looking at the individual files; he/she would be looking at the whole thing, and if there's a top-level file that says "everything in this package is under licence foo", then you'd have a pretty damn hard time persuading the judge otherwise
<mok0> ogra: is that a requirement for Debian?
<ogra> mok0, not sure, but i had a bunch of packages i had to work on, even if its not, you will drown in a bunch of bugs about it there
<cjwatson> Debian's ftpmasters will complain about inconsistent licences of course, but I've never heard of them complaining about missing licence statements in individual source files
<cjwatson> and I would be extremely surprised if they did
<mok0> cjwatson: I've done a ton of reviews, and I rarely see the license clauses included properly
<ogra> no, its rather the self declared debian license police that pokes you with bugs about it :)
<cjwatson> some Ubuntu archive administrators have got into the habit of complaining about that, and personally I think it is substantial overkill
<soren> cjwatson: Ok. So if I ask them to add the Apache license to the tarball and have them put a file that said who the copyright holder is and references the Apache license, that would acceptable?
<cjwatson> soren: yes, I'd say so
<soren> cjwatson: Lovely. Thanks!
<mok0> I've been telling uploaders that without a license file in orig.tar.gz, we can't distribute the package
<mok0> I've also told them to _attempt_ to get upstream to add clauses to indiv. file
<mok0> s
<cjwatson> yes, you clearly must have some statement of the licence in the tarball
<cjwatson> well
<cjwatson> actually, I think it's permissible to get an e-mail clarification from upstream and to put that in debian/copyright, pending a new upstream release
<cjwatson> I have done that myself in the past
<mok0> cjwatson: that's a good idea
<ia> hello. i use alpha-3 with latest updates. http://www.markshuttleworth.com/wp-content/uploads/2008/12/jaunty904_notifications_example1_web_092.swf - this notification system looks very useful, but how can view it in action? i mean, which apps and what kind of events supports such notifications? and technical question - it's just some impove of notification-daemon, or something else? and where i can find out, which api's in which languages allow to initiate s
<ia> uch notifications? i will be very appreciate for any useful information :-)
<cjwatson> ia: that's work in progress, not (as far as I know) yet in jaunty
<ia> cjwatson: oh, right. just in some news they tells, that it's already can be seen in work :-)
<ia> however, how do you think, it's some layer over notification-daemon, or some brand new notification system? if second, then how it names?
<cjwatson> ia: no idea, sorry
<mvo> Keybuk: during my upgrade test in kvm I got no udevd started message (except for one) and the /dev/null permissions look ok too - that was a default ubuntu-desktop base-image that I used for the test
<superm1> cjwatson, jharr yes i didn't realize that jharr was building a chroot. thanks for the extra comments
<lool> james_w, pochu: Pushed new lp-set-dup script in ubuntu-dev-tools
<james_w> lool: cool, did you port it to lplib? :-)
<lool> Yes
<james_w> ah, nice, thanks
<pochu> lool: in the end, bug 78596 should be fixed, but for the meantime that'll be useful :)
<ubottu> Launchpad bug 78596 in malone "Automatically handle moving duplicates across when duplicating a bug with dupes" [High,Triaged] https://launchpad.net/bugs/78596
<lool> pochu: Agreed
<lool> james_w, pochu: BTW happy to get any review
<lool> jpds: Hey I pushed some 3/4 ubuntu-dev-tools changes; I'd like to upload the package, but would love you to have a look to check I didn't break anything; how are you building the package?  debuild -i good enough?
<james_w> lool: looks pretty good to me. Would it be better to do the obvious thing if I request a bug be duplicated against a bug that is already a duplicate of something else?
<james_w> though the rarity of that situation and the added complexity of doing a check for circular references may not be worth it
<tkamppeter> pitti, back to the foomatic-filters 4.0.0 SRU, all changes (see newest changelog entry in Jaunty package) are bug fixes, and for me it looks like that all are regressions against Hardy. And the Infinite loop when supplying a page range is even a security vulneribility, as a user can block the printing system by sending a job with page-specific option setting.
<tkamppeter> pitti, every fix by itself is a small patch (up to 10 modified lines), only the modification to fix the infinite loop is somewhat bigger.
<lool> james_w: I preferred failing and offering the good command line to run
<pitti> tkamppeter: do we have some LP bugs which correspond to the changes? please use those for the SRU
<lool> james_w: (just need to copy paste the suggested command line)
<james_w> yeah, it's sensible, but a tool telling you *exactly* what to run is normally pretty bad UI
<james_w> the safety check may justify it though
<tkamppeter> pitti, for the two items mmarked appropriately in the debian/changelog, yes, I can at least add another one for the infinite loop vulnerability.
<lool> james_w: I didn't want to autofix it, but I guess I could prompt to ack the change and proceed indeed
<james_w> that could work
<liw> what's the proper way of asking for an application to be included in the default Ubuntu desktop install?
<pochu> lool: on line 52, suggestion is unused, isn't it?
<pochu> as you're dying in the next line without using it
<lool> pochu: ah thanks, forgot to drop a die() on line 53
<lool> pochu: (fixed)
<lool> james_w: I implemented prompting to use the duplicate of main bug
<james_w> thanks lool, you rock
<lool> Eh thanks for the good comments
<tkamppeter> pitti, I have reported the infinite loop problem as bug #318816
<ubottu> Bug 318816 on http://launchpad.net/bugs/318816 is private
<tkamppeter> pitti, I have also reported bug 318818 now.
<ubottu> Launchpad bug 318818 in foomatic-filters "Intrepid fails LSB 3.2 tests on foomatic-filters" [Undecided,New] https://launchpad.net/bugs/318818
<pitti> tkamppeter: is the lsb failure actually something to worry about? it's not something SRU worthy per se
<tkamppeter> pitti, I do not know how important LSB failures are considered at Ubuntu. Therefore I reported that. Most important is the infinite loop, and all the rest can be considered as regressions against Hardy.
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek to start in #ubuntu-classroom in 17 minutes
<NCommander> DktrKranz, ping
<cjwatson> pitti: can you have a look at http://launchpadlibrarian.net/21351698/buildlog_ubuntu-jaunty-i386.glib2.0_2.19.5-0ubuntu1_FULLYBUILT.txt.gz ? It looks as if pkgstriptranslations is running twice in parallel on the same package, and the result is a corrupted translations tarball (which is crashing the publisher, which is how we noticed it)
<apw> pitti, apport -- when a report is generated i assume its the reporting script's reposinsibility to prevent a double trigger of the report?
<grndslm> could somebody please unban me from #ubuntu....  i made one funny ha ha and somebody screamed for the ops
<pitti> apw: double trigger? if you mean it triggers while you are still writing it: you need to create it as 000, write it completely, and then chmod it to 600
<pitti> cjwatson: looking
<cjwatson> grndslm: this isn't an escalation channel - go to #ubuntu-ops, please
<grndslm> k thanks
<apw> no i mean if i find file /foo and that is my trigger, when i converted that into a spool file, i assume it is _my_ responsibility to remove /foo as well
<pitti> cjwatson: ugh, how weird; I don't have an offhand idea, I need to try and reproduce this in a chroot
<pitti> apw: it could be done in the apport init script if you don't need it any more for other purposes
<apw> my worry is if we don't will we not file the same bug every boot from then on
<tkamppeter> pitti, I have added everything for the foomatic-filters SRU to bug 318816 now (you are subscribed to it) and nominated the bug 303691, bug 299918, and bug 318818 for Intrepid.
<ubottu> Bug 318816 on http://launchpad.net/bugs/318816 is private
<ubottu> Launchpad bug 303691 in foomatic-filters "Intrepid, print broken with Minolta PagePro 8L printer" [High,Fix released] https://launchpad.net/bugs/303691
<ubottu> Launchpad bug 299918 in foomatic-filters "Cannot print duplex in intrepid with Ricoh Aficio 2060, Ricoh Aficio MPC3000 or Brother HL-4050cdn using the openprinting drivers" [High,Fix released] https://launchpad.net/bugs/299918
<ubottu> Launchpad bug 318818 in foomatic-filters "Intrepid fails LSB 3.2 tests on foomatic-filters" [High,New] https://launchpad.net/bugs/318818
<apw> pitti, ahh we do remove it anyhow, good
<jharr> cjwatson: thx for the help. I now realize that with binfmt-support. Somewhere along the line /usr/bin/perl was fine in the chroot, but perceus builds a cpio archive (which was fine) but the kernel apparently has issues decompressing cpio archives that have hardlinked files in them.
<cjwatson> jharr: the *kernel* - are you sure? that should be entirely userspace and using only very common syscalls
<jharr> cjwatson: perl was ending up as a zeroed file.
<cjwatson> if link(2) is failing you have pretty bad problems!
<cjwatson> sure, you described the symptoms earlier; I was questioning your attribution of the cause to the kernel
<jharr> cjwatson: the cpio archive was the initrd.
<cjwatson> ah, I see
<cjwatson> you have perl in your initrd?
<jharr> cjwatson: yeah, perceus is a tool to pxeboot stateless clusters.
<apw> jharr, can't you remove the links in there, and remake them after boot (if the kernel support is inadequate)
<cjwatson> jharr: scary. just make them symlinks then, I suppose
<jharr> cjwatson: There are several things that could go wrong in between. I won't attribute it to a kernel bug, but I'm going to continue on in my work until I have time to poke around at that specific issue...
<cjwatson> well, no, if it's in the initrd you're probably right, that's unpacked entirely in kernelspace
<jharr> I do just remove the links for now.
 * ogra wonders where to find more infor about a debootstrap error ...
<ogra> W: Failure trying to run: chroot / dpkg --force-depends --install
<ogra> seems to break at the beginning of the second stage
<pitti> thekorn: with p-lp-bugs, can I get the bug's original description somehow?
<cjwatson> ogra: /debootstrap/debootstrap.log in the chroot (probably; find -name debootstrap.log)
<ogra> well, the prob is that its not a chroot and i cant get that log easily
<ogra> its http://people.ubuntu.com/~ogra/arm/build-arm-rootfs
<cjwatson> there is a bug about the lack of feedback there
<ogra> wrapping the second stage into qemu
<cjwatson> oh
<ogra> and its not my error, but a users
<cjwatson> ogra: upgrade debootstrap to the current version in jaunty
<cjwatson> I fixed that very bug last week
<ogra> i dont want him to upload his 4G image :)
<thekorn> pitti: you mean without removed whitespaces?
<thekorn> pitti: .description_raw
<cjwatson> (or tell the user to do so; whatever)
<ogra> oh, he might be running it on intrepid
<pitti> thekorn: no, that's not the originally filed one
<thekorn> pitti: ok, got it now, no you cannot
<cjwatson> see the debootstrap 1.0.10ubuntu2 changelog; the command was supposed to be 'chroot / dpkg --force-depends --install libc6' but the variable that expands to 'libc6' wasn't being set in --second-stage mode
<pitti> thekorn: bug 315728, someone added stuff below the apport data
<ubottu> Launchpad bug 315728 in xserver-xorg-video-radeonhd "[RV610] Xorg crashed with SIGSEGV in xf86InitViewport() (Testing Jaunty)" [Undecided,Incomplete] https://launchpad.net/bugs/315728
<pitti> thekorn: and in the middle of apport data there are empty lines
<ogra> ah
<lool> directhex: Hey, I heard you're working on the C# transition which affects f-spot, beagle, tomboy in the default install; it's been some days that these prevent upgrades; is there a bug for whatever blocks progress right now?
<thekorn> pitti: if you need it, file a bug, I'm happy to add .original_description, should not be hard
<thekorn> or use launchpadlib, it's bug.messages[0] there
<pitti> thekorn: I think I'll just try and work around it, since i need to add some code to deal with the empty lines anyway; then it'll also work in stable versions
<pitti> thekorn: launchpadlib> can't yet, due to firewall restrictions on the DC host :(
<|ntegra|> hello
<|ntegra|> I have an idea for ubuntu, but I am not a programmer
<cjwatson> brainstorm.ubuntu.com is the place you want, then
<|ntegra|> thanx cjwatson
<DktrKranz> NCommander: (late) pong
<NCommander> DktrKranz, what's the status of dietlibc in Ubuntu?
<DktrKranz> NCommander: I had some tests on i386 and amd64, those archs are in good shape. I have some doubts about sparc and ppc, though and I have no hardware to test.
<NCommander> DktrKranz, I'm looking at ARM ATM
<NCommander> It cores when built with DEBUG=0, but works when built with DEBUG=1
<NCommander> :-/
<DktrKranz> ah...
<DktrKranz> it's probably related to stack protector
 * NCommander tries removing that
<NCommander> DktrKranz, ARM EABI support only exists in CVS HEAD, whats your feelings on going to a CVS version?
<DktrKranz> there were some commits since current version, some interesting ones for ARM, IIRC
<jpds> lool: Everything looks OK to me, I build the package by copying it to /tmp, rm -rf .bzr there and debuild -S -sa.
<DktrKranz> NCommander: if you want, I can prepare a snapshot upload, have you some PPC hardware to test it? I'd like to readd stack protector support
<NCommander> DktrKranz, I can give you a shell on my PowerPC box
<DktrKranz> NCommander: that's would be awesome
<lool> jpds: Ok; I think you could use "debuild -i -S -sa" instead to skip the copying step if you like; -i will also ignore .bzrignore which is why I was asking how you do it
<NCommander> DktrKranz, if I do the same on my ARM box, can I get working ARM support :-)?
<DktrKranz> NCommander: I can give it a try
<DktrKranz> just prepare me a chroot/pbuilder
<NCommander> Well, I'm building diet ATM with -fno-stack-protector to see if I still get a core dump
<NCommander> Ugh
<NCommander> I think its a problem with -Os
<NCommander> :-/
<jpds> lool: I don't know what -i does, can't find it in the manpages..
<lool> jpds: It's a dpkg-buildpackage falg
<lool> Which tells it to use its default exclusion res
<lool> jpds: Sorry, I was actually hinting at the wrong flag: it's -I
<lool> (I actually pass -i -I via ~/.devscripts)
<lool> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-I -i"
<apw> pitti, i am trying to test this apport stuff and when i respond to the '*' on the task bar, i get as far as submitting the thing and it tries to send my browser to file:///ubuntu/+source/linux/...
<apw> that sounds wrongo
<jpds> lool: Oh, neat. Feel free to upload when you want.
<lool> jpds: done
<apw> pitti, also when it took me to launchpad it didn't have a title set and as i'd not been told anything much about the bug i might not have had a clue what to put in that box?
<jpds> lool: Thanks! :)
<lool> jpds: BTW I keep getting this on upgrades:
<lool> dpkgÂ : ubuntu-dev-toolsÂ : avertissement - le conffile Â«Â /etc/bash_completion.d/pbuilder-distÂ Â» n'est ni un vrai fichier ni un lien (= Â«Â /etc/bash_completion.d/pbuilder-distÂ Â»)
<lool> (file is neither a real file nor a symlink)
<lool> And indeed it's a directory
<pitti> apw: curious, mdz sent me a similar problem today; I'll look into it
<jpds> lool: OK... I personally don't use bash, I think \sh wrote that.
<lool> jpds: I don't use bash either, but I get this while installing hte package
<lool> In the package I see:
<lool> -rw-r--r-- root/root       919 2008-08-18 11:54 ./etc/bash_completion.d/pbuilder-dist
<lool> But on my system it's a dir
<jpds> Hmm.
<lool> Probably since:
<lool>   * debian/ubuntu-dev-tools.install: install bash_completion/pbuilder-dist in
<lool>     /etc/bash_completion.d/ instead of /etc/bash_completion.d/pbuilder-dist/
<lool> Presumably this required some preinst on upgrades which was forgotten
<apw> pitti, how does apport decide to push some information into the main body, or as an attachment?
<pitti> apw: if it's text, and < 5 lines, it gets into description, otherwise attachment
 * pitti -> dinner
<apw> hmmm
<lool> jpds: Could you check out the preinst snippet I added?  Not perfectly pretty, but couldn't find a way to have it much cleaner but still safe
<lool> jpds: Works for me on upgrades; not that I get a conffile merge prompt because I upgaded across multiple versions without really getting the new conffile
<jpds> lool: Looks OK; I personally have it installed as a file... no idea where the dir came in.
<lool> jpds: For people upgrading between the time the error was introduced and the time it was fixed
<mdz> Keybuk: re: CVE-2008-4311, which releases are affected?
<Keybuk> mdz: all, ever
<lool> jpds: pushed tagged updated changelog for next version uploaded
<lool> +,,,,
<mdz> Keybuk: ah, I skimmed over the bit that said it was believed not to be exploitable
<Keybuk> mdz: right
<mdz> Keybuk: so no action is needed in stable releases, but we should fix things up going forward in Jaunty?
<Keybuk> so D-Bus was passing messages by default, instead of denying them
<Keybuk> but it turns out that's basically ok, since most messages should have been allowed
<Keybuk> and the few services that have privileged messages actually took care to deny them to other people anyway
<Keybuk> (which implies they tested their policy, found they got through, added the deny rules ... and didn't think to ask anybody why that worked when it shouldn't have :p)
<Keybuk> so we can breathe a bit of a sigh of relief, and just fix things going forwards
<jpds> lool: Thanks for the fix.
<lool> thanks for the review
<tseliot> Keybuk: ok, point taken ;)
<Keybuk> tseliot:
<Keybuk> ?
<tseliot> Keybuk: about fixing apps which rely on dbus e.g. my policykit stuff
<Keybuk> tseliot: you fixed your ages ago ;)
<tseliot> Keybuk: in Jaunty, it wasn't uploaded to Intrepid though.
<Keybuk> tseliot: shouldn't need to be aiui
<tseliot> ok
<apw> pitti, i have proposed a branch for merging to apport, does that get to you direct?
<doko_> pitti: which package should bug #318507 be assigned to?
<ubottu> Launchpad bug 318507 in glibc "Wrong first day of week for "C" locale" [Low,Confirmed] https://launchpad.net/bugs/318507
<Keybuk> is that a bug?
<Keybuk> surely C has no specific first day of the week?
<apw> i think the complaint is that the result has changed between intrepid and januty not that it is one day or another
<pitti> doko_: isn't C defined in libc6?
<apw> and cirtainly that appears to be true here too
<ScottK> pitti: Is there a web resource for "I want my package to use apport when it crashes, what do I need to know."?
 * ScottK has an upstream he's hoping to get to do it.
<doko_> pitti: ahh, ok, yes for C
<pitti> apw: in theory I should have gotten a merge request mailed, but I didn't
<pitti> doko_: all 'real' locales are in langpack-locales source
<doko_> urgh, we don't apply Debian's localedata patches ...
<Keybuk> there should be a locale that gives you randomly undefined results ;)
<pitti> ScottK: https://wiki.ubuntu.com/Apport is the "homepage" with some further links
<ScottK> pitti: Thanks.
<pitti> ScottK: and https://wiki.ubuntu.com/Apport/DeveloperHowTo is probably closer to what you are looking for
<ScottK> OK
<cjwatson> Keybuk: POSIX 2008 doesn't define "first day of week" at all. That said Saturday is probably a silly choice anyway
<Keybuk> cjwatson: exactly ;)  it shouldn't be possible to display a calendar in the C locale
<Keybuk> since there are no defined names for weekdays, and certainly no defined start of the week :p
<cjwatson> Keybuk: it doesn't define "first day of week" for any other locale either, and actually there are defined names for weekdays in C
<Keybuk> but then I'm old fashioned about strictly following standards <g>
<Mithrandir> Keybuk: does it just omit names and start of week, or does it explicitly say "day names and first day of week is undefined in the C locale"?
<cjwatson> day        "<S><u><n><d><a><y>";"<M><o><n><d><a><y>";\
<cjwatson>            "<T><u><e><s><d><a><y>";"<W><e><d><n><e><s><d><a><y>";\
<cjwatson>            "<T><h><u><r><s><d><a><y>";"<F><r><i><d><a><y>";\
<cjwatson>            "<S><a><t><u><r><d><a><y>"
<cjwatson> etc., in the POSIX locale
<cjwatson> Mithrandir: it defines day names, and omits any mention of first day of week entirely (that's a glibc extension, I think)
<Mithrandir> so it's perfectly legal to choose any day, then? :-)
<Keybuk> Single Unix extension, apparently
<Keybuk> cjwatson: it doesn't necessarily follow that the POSIX locale only contains what's in the POSIX specification ;)
<cjwatson> Keybuk: sure, but you said "there are no defined names for weekdays" :-)
<Keybuk> defined in the spec ;)
<cjwatson> I'm deeply confused. They are defined in the spec.
<cjwatson> there's a bit of a difference between the POSIX locale having some extras, and it not having stuff that the spec says it has
<Keybuk> I did not think there was a spec for the C locale ;)
<cjwatson> 'The strings "C" and "POSIX" are reserved as identifiers for the POSIX locale'
<cjwatson> chapter 7 of Base Definitions
<Keybuk> fair enough
 * Keybuk stands in the corrected corner
<cjwatson> ;-)
<afflux> the retracer seems to just have closed a crash bug of mine, which is perfectly alright, since I can't reproduce this anyway. The only problem I see here is that I reported this bug more then a month ago, and since then, the package got updated, and with it obviously the debug symbol packages.
<afflux> I'm not sure whether this really was intended, so I thought it might be worth it letting you know.
<Notch-1> hi, please take a look here: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/318821
<ubottu> Launchpad bug 318821 in casper "reboot issue in persistent/casper mode" [Undecided,New]
<doko_> cjwatson: fix for 235070 uploaded using the patch from intrepid
<directhex> who feels like giving https://bugs.launchpad.net/ubuntu/+source/nant/+bug/318683 a tickle?
<ubottu> Launchpad bug 318683 in nant "Please sync nant 0.85.dfsg1-6 (main) from Debian experimental (main)." [Undecided,New]
<idnzor> hi, i was wondering if someone could help me out with contact information
<idnzor> i wanted to start contributing my user experience expertise to the ubuntu project
<idnzor> i work for a user experience consultancy as a usability analyst, and want to start working outside of work on ubuntu/gnome based projects to give something back to the community
<james_w> idnzor: that's great. The ubuntu-desktop list may be a good place to start to discuss Ubuntu/GNOME usability
<idnzor> james_w: thanks, i posted the same above on there, however, i am just waiting for a response
<james_w> the channel, or the mailing list?
<idnzor> the channel
<idnzor> would you recommend the ubuntu-desktop mailing as well then?
<james_w> yeah, an email is more lasting, so you don't need the right people to be looking at the channel right now
<idnzor> ok thanks, i will look into it
<james_w> tedg: you're up!
<tedg> james_w: Oh, I thought I was in an hour...
<james_w> 'fraid not
<NCommander> BTW, random question, does anyone know a good IRC proxy?
<maxb> If you like irssi, it can be a proxy itself, at the same time as being a client.
<Ape3000> I use irssi as proxy and Xchat as the visible client
<asac> TheMuso: what - in theory - needs to be done in jaunty to get my line-in directed to my speakers ;)?
<ogra> you take a soldering iron ... some wire ...
<asac> heh
 * ogra definately did to much ARM HW enablement the recent time 
<asac> am i supposed to be in pulse-rt group or something?
<asac> http://paste.ubuntu.com/107079/
<ogra> "For enabling real-time/high-priority scheduling please acquire the appropriate PolicyKit privileges" heh ... come to our shop at www.policykit-addons-for-cheap-money.com :)
<asac> TheMuso: am i supposed to be in pulse-* groups?
<DTee> Hi would any developers be willing to answer some questions to help with my FInal Year Dissertation?
<DTee> It won't take long.
<TheMuso> asac: Depends on the card. It has nothing to do with pulseaudio. You need to adjust the line mixer levels in the alsa mixer.
<TheMuso> mdz_: Daniel T Chen aka crimsun committed a fix for that in bzr yesterday, which I uploaded. Latest alsa-utils should fix that issue, and yes its a well reported bug.
<mdz_> TheMuso: ok, thanks
<asac> TheMuso: i have HDA NVidia Realtek ALC883
<TheMuso> asac: Right, you will have to load alsamixer and fiddel with the line mixer, unmuting where necessary.
<asac> TheMuso: is there a way to reset alsamixer to default?
<TheMuso> asac: sudo alsactl restore should do it
<TheMuso> maybe sudo is not needed, but I think it is.
<asac> TheMuso: doesnt complain if i dont pass it
<superm1> that won't necessarily set it to defaults, but more so to the last set of recorded values wouldn't it?
<asac> TheMuso: interestingly i wasnt in pulse-rt group .... when were i supposed to be added there?
<TheMuso> asac: You aren't added to that by default, and for the most part its not needed for average use.
<asac> TheMuso: hmm ... before i added myself i had no sound at all
<TheMuso> superm1: Yes thats right. I think alsactl init will reset values, however you may want to use sudo /etc/init.d/alsa-utils reset
 * asac tries to remove himself again
<asac> hmm ... gstreamer-properties hangs when testing pulsesrc
<TheMuso> asac: Which one exactly?
<asac> TheMuso: the default. (just reads pulsesrc)
<TheMuso> asac: Is this for input or output?
<asac> TheMuso: input
<TheMuso> ah ok
<TheMuso> asac: have you got a capture device set in the alsa mixer?
<asac> TheMuso: i try to get my line-in on my speakery :(
<asac> TheMuso: let me double check
<TheMuso> asac: Ok, your board's hda code implementatino may not be set entrely correct, or have you gotten line in to work before?
<asac> TheMuso: i have two captures: Line and Mic
<asac> TheMuso: i cant really remember if it ever worked :/
<TheMuso> asac: Right. In alsamixer's capture mode, you can set one of 3 capture sources, or at least thats what mine has. The sources can be set either to line, mic, or front mic.
<TheMuso> But you can still only capture from one source at a time.
<asac> TheMuso: ok. let me try to plug in a mic
<asac> to see if its really just line not working
<asac> TheMuso: so if is push up Mic Boost, i can here my voice ;) ... thats good. but capturing source doesnt have any influence at all for that
<TheMuso> asac: Right, is the word capture displayed under any of the sources?
<asac> TheMuso: only thing i have is two CAPTURE channels, but thats not it, right?
<TheMuso> asac: Well if it works anythinglike mine, you can select which source you want, either mic, line, etc. Pressing space bar on one of those should enable it for capture.
<asac> oh
<asac> let me check
<asac> yeah
<asac> both had CAPTURE
<TheMuso> interesting
<TheMuso> asac: What are you using that is plugged into line in?
<TheMuso> asac: and in the playback sectino of alsamixer, is line unmuted?
<asac> TheMuso: so if i go to the "Capture" view of alsamixer i see 7 things (from left to right): front mic, mic boost, capture, capture 1, digital, Input Source, Input Source 1
<asac> TheMuso: currently only the first "capture" has a red CAPTURE above it
<TheMuso> asac: Ok, you want to go to input source, and choose line.
<asac> TheMuso: problem is that input source has no influence whatsoever ... unless i mute the "Mic", i can hear the mic
<asac> TheMuso: atm, both input source things have "Line" ... still mic is working
<TheMuso> asac: Right. Go back to the playback sectino of alsamixer, and check the line level, and check if its unmuted.
<TheMuso> section
<asac> TheMuso: line in playback section is unmuted (i see 00) and has 100/100 level
<asac> TheMuso: i have a PS3 connected to line-in ;)
<TheMuso> asac: Right, and you are sure its currently playing audio?
<asac> TheMuso: pretty sure. a demo is running
<TheMuso> asac: Ok.
<asac> TheMuso: anyway, dont want to bother you with this. only thing i dont understand is that if i select "Line" for all input sources in alsamixer, the mic is still working
<TheMuso> Well if line is unmuted and set to full volume, and input source is set to line and capture is enabled and you still get nothing, theres something up somewhere?
<TheMuso> s/?/.?
<TheMuso> gah
<broonie> It's perfectly normal for hardware to be able to mix multiple inputs together so having to mute others isn't that surprising.
<TheMuso> asac: Hearing the mic will always be possible. Even though you can hear the mic, you can't necessarily record it unless the options in the capture are set so you can.
<asac> broonie: so you say i should mute everything else?
<asac> TheMuso: one last thing. i see hw:0,2 in alsasrc command ... where do those numbers come from?
<TheMuso> asac: 0 is the card number, and 2 is the subdevice.
<asac> TheMuso: ok. where does that subdevice number come from ;)?
<TheMuso> asac: As it stands, I can't help but think that the hda chip on your board is not known properly. Could you either check to see if an existing bug report exists for your board, and if not, file one and assign ubuntu-audio? Then run http://www.alsa-project.org/alsa-info.sh and post the URL in the bug?
<TheMuso> asac: THis will help track down the proper information for the hda chip, and I can check upstrea for any patches etc.
<TheMuso> asac: THe number of devices on the card, I don't really understand that bit a great deal yet, in terms of alsa.
<asac> ok
<asac> thanks
<TheMuso> asac: np
<cjwatson> doko_: thanks
<LaserJock> anybody have an obvious reason why Xephyr would be unacceptable for Main?
<asac> TheMuso: file against what package?
<directhex> LaserJock, what's the sales pitch FOR it being canonical-supoprted?
<TheMuso> asac: linux, and assign ubuntu-audio
<asac> cool
<LaserJock> directhex: because it's better than Xnest?
<directhex> reasonable argument ;)
<cjwatson> LaserJock: so, with the Edubuntu task renaming you did, there is currently no way to prevent those packages having Task: edubuntu-edubuntu-desktop
<cjwatson> and tasksel will have to change accordingly
<cjwatson> LaserJock: I don't suppose you want to think up a different name?
<LaserJock> good lord
<cjwatson> otherwise I have to get Launchpad patched ...
<LaserJock> is it just edubuntu-desktop that's the problem?
<LaserJock> can I name it like desktop-gnome for instance and it'd be ok?
<cjwatson> every task in the edubuntu seeds gets "edubuntu-" prefixed
<cjwatson> so desktop-gnome would be fine (and likewise edubuntu-desktop-kde -> desktop-kde)
<broonie> asac: It'll probably help.
<cjwatson> arguably more descriptive than the present name too
<asac> TheMuso: ok its 318985
<TheMuso> asac: Ok thanks, if assigned to ubuntu-audio I'll get it in my bugmail.
<LaserJock> cjwatson: ok, since we're trying to do a bit more DE-neutral stuff by having both a gnome and kde variant it's maybe best all around to do desktop-gnome and desktop-kde
<LaserJock> I'm not sure I want to mess with transitioning edubuntu-desktop .deb to something better for Jaunty though
<LaserJock> but for the seeds anyway it makes sense
<calc> how do i enable nvidia driver in jaunty?
<calc> i thought it was via system->hardware drivers but that just pulls up a completely empty dialog
<raof> calc: There'll be the small problem that you'll need to edit xorg.conf & disable ABI checking before they'll work
<calc> raof: oh it doesn't work currently due to the transition to xorg 1.6?
<raof> calc: The driver works, mostly.  You just need to mess with the config.  The Hardware Drivers thing doesn't work for (at least) that reason.
<calc> ok
 * calc also isn't too impressed by the new castrated audio setup
 * calc hopes his headset still works properly or he may need to switch to something other than Gnome
<directhex> i could do with jaunty on my myth box. no hdmi audio from intrepid
<cjwatson> LaserJock: yeah, just the seeds will be fine. Thanks!
<directhex> or i could just compile my own alsa...
 * calc plugs his usb headset in and sees what happens
<calc> looks sane enough, but no way to test anything anymore
<calc> and it appears to be able to change the volume you now have to change the output in gnome to that device, which is insane
<TheMuso> calc: Yeah there have been complaints about the new volume control only controlling pulseaudio. This is not my area, I just maintain the infrastructure underneath. See recent warthogs discussion.
<calc> so eg i'm talking on voip and want gnome to play audio from apps through speakers, but voip via the headset to adjust the headset i have to route the gnome audio through the headset now, or resort to using alsamixer/alsactl
<calc> TheMuso: ok
 * calc wonders what pulse buys us that dmix doesn't?
<calc> other than more bugs
<TheMuso> calc: Being able to move your VOIP output from speakers to your headset without restarting the VOIP application.
<TheMuso> for one
<calc> TheMuso: but thats not really a feature thats a bug ;-)
<TheMuso> calc: Being able to send audio over the network to another machine.
<calc> ok
<TheMuso> calc: How is that a bug?
<RainCT_> TheMuso: is the application specific volume stuff also from PulseAudio?
<calc> TheMuso: to be able to adjust the audio for voip it does that regardless if you want it to or not :-\
<RainCT_> or was that also possible with ALSA?
<TheMuso> RainCT_: app specific audio volume control is pulse
<RainCT_> nice
<calc> network audio has been around a long time, just no one used the apis for it
<RainCT_> finally it's useful for something :P
<calc> at least a decade iirc
<TheMuso> calc: Yeah but again you can move it over the network transparently without stopping it.
<calc> ah ok
<calc> TheMuso: this is all in theory of course as ubuntu doesn't install any of the support to actually do it (or does it now?)
<TheMuso> calc: The volume control applet is supposed to either have it, or be getting it, so far as I know. I could be wrong however.
<raof> The "Choose a device for sound output" radio buttons should actually switch (a) the default output for new streams, and (b) all the current streams.  It doesn't do that now.
<raof> I presume it will before release, otherwise it's just a big UI lie.
<calc> ok
<directhex> anyone wanna  buy a hardware-mixed audigy? :p
 * TheMuso shudders. Audigy cards have a shocking chip in them.
<TheMuso> Yes they can do hardware mixing, but they internally resample to 48KHz.
<TheMuso> nick TheMuso
<TheMuso> wrong window
<directhex> TheMuso, audigy 2, then.
<TheMuso> directhex: RIght, I am not sure what chip those cards have.
<directhex> TheMuso, ca0102.
<TheMuso> Means nothign to me.
<TheMuso> nothing
#ubuntu-devel 2009-01-20
<mrz0g> evand
<calc> seagate took their firmware fix offline to fix it
<calc> seagate doesn't inspire confidence with not even being able to make their fix work, segfaults on trying to flash
<nhandler> So when in the development cycle do we make update-manager's -d flag work?
<raof> Should be working now; that's how I updated, pre alpha-1.
<nhandler> raof: Well, when I updated pre-alpha 1, I went the update sources.list dist-upgrade approach. Now, I just did a fresh install of intrepid the other day. But update-manager -d doesn't show anything
<bluesmoke> nhandler: it's sudo update-manager -c -d
<bluesmoke> -c tells it to check for a distro upgrade, -d tells it to use a development one
<raof> You could try adding a -p, to update using the update-manager from -proposed.  I'm not sure if there's one there yet.
<bluesmoke> yeah, I always try to remember to do sudo update-manager -c -d -p
<bluesmoke> usually forget the -p though :P
<nhandler> No luck bluesmoke. It still says I am up-to-date
<nhandler> This is interesting. In the terminal, it says "current dist not found in meta-release file
 * calc understands a bit about this pulseaudio/mixer mess esp after reading all Realtek codecs are considered "buggy" :-\
<TheMuso> calc: where did you read about the realtek stuff?
<calc> the Gnome 2.26 module inclusion discussion heats up thread on desktop-devel-list@gnome.org
<TheMuso> ah ok
<calc> there is a link to a list of drivers that are broken wrt PA support
<TheMuso> hrm interesting.
<calc> and on that list is all snd-hda-intel realtek codecs
<calc> so not every realtek codec but most of the modern ones anyway
<TheMuso> interesting, since realtek is one of the most popular.,
<calc> and if i read the page right all intel ac97 is broken as well
 * TheMuso wonders whether they are broken in a hardware sense or software sense.
<calc> driver sense afaict
<TheMuso> Oh great.
<calc> it seems they might need things like jack sensing support added (?)'
<calc> apparently thats a new feature in alsa
 * calc has no idea about that stuff
<TheMuso> Yeah it is a new feature, jaunty won't likely have it.
<calc> stuff was mentioned like the fact there are separate mixers for headphones vs speakers on laptops
<TheMuso> yeah I've seen that.
<calc> the thread is pretty long but there was some interesting stuff in it, seems to be all about PA
<TheMuso> not on my own hardware, but I have heard of it
<calc> mine has that
 * TheMuso needs to read it.
<calc> apparently the new PA stuff in 2.25 doesn't work well with it
<calc> i'm still on 8.10 on my laptop
 * TheMuso gets the thread URL
<calc> i'm not surprised it probably has issues the new mixer app is so dumbed down i was surprised it could work at all
<calc> http://mail.gnome.org/archives/desktop-devel-list/2009-January/msg00251.html
<TheMuso> yeah i have it
<calc> that isn't the beginning of it, just where i am in the thread currently
<TheMuso> oh ok.
<calc> it sounds cool in theory but i don't know that they can dumb down alsa well enough to have it 'just work'
<calc> if they can do it sanely i will be impressed
<TheMuso> And not forgetting different drivers for USB/other PCI cards also have different mixers.
<calc> but then gnome seems to shoot for an 80% solution and leave the other 20% to use KDE ;-)
<bluesmoke> TheMuso: I have jack sensing already
<calc> TheMuso: yea thats how i noticed it works weird with my usb headset
<bluesmoke> If I plug in headphones the speakers turn off but I can turn them back on with alsamixer
<TheMuso> bluesmoke: Jack sensing is more than just that.
<TheMuso> bluesmoke: It can detect what type of device is ocnnected, i.e speakers, headphones, microphone, etc.
<bluesmoke> ah
<calc> i might try upgrading to jaunty on my laptop and just deal with the breakage :)
<bluesmoke> so it would turn on digital out automatically
<dtchen> jaunty's kernel doesn't have that work, though
<calc> yes that is useful but not letting the user turn it off isn't particularly great
<raof> Hm.  Where's bugzilla for the new volume applet?  I'd like to check if some features already have bugs or not.
<calc> eg if you have your system hooked up via hdmi to a tv does it always play out that interface since its hooked up?
<calc> having good defaults with no way to override them... isn't good
<calc> and having to go into the terminal isn't a real solution
 * calc should be arguing this with the PA upstream not with poor Ubuntu maintainer ;-)
<TheMuso> calc: PA itself has no UI, its other utilities that sit on top of PA that give the UI.
<calc> TheMuso: ah well gnome-volume-control (or whatever the tray thing is)
<TheMuso> calc: gnome-volume-manager, yeah thats GNOME stuff.
<calc> ah ok
<bluesmoke> gnome-volume-manager is utopia stuff, not sound
<dtchen> raof: http://tinyurl.com/g-m-bugs
<TheMuso> sorry gnome-volume-control is what I meant
<raof> Urgh.  They're thinking of removing the applet entirely, leaving us with the crazy notification icon.
 * raof thinks that's 100% pure UI crack.
<calc> raof: yep and converting the old version to a notification icon as well
<calc> raof: so they act the same for fallback
 * raof presumes he's not the only one who's wierded out by a volume control icon that only turns up after something has started playing.
<calc> heh
<TheMuso> thats stupid I agree
 * calc bbl
<TheMuso> No other OS does that.
<ScottK> TheMuso: It's innovation then.
<TheMuso> ScottK: if you could call it that. I'll bet KDE has more sane plans. :)
<ScottK> That's my impression.
<dtchen> although I hear 4.2 has gained a PA backend for Phonon?
<calc> well gnome is full of crack recently it seems, they broke gnome-session and didn't seem to care too much
<ScottK> dtchen: I don't think we're using it though.
<TheMuso> ScottK: Riddell has talked to me about possibly enabling it at least.
<TheMuso> ScottK: I can't remember the exact conversation, and I'd have to ask him again what he was thinking as I don't entirely remember myself.
<raof> I didn't think PA was a possible backend for Phonon.  Isn't phonon a GStreamer abstraction?
<ScottK> I think it's meant to be more generic than that.
<raof> But you say "play me this mp3 file", right?
<ScottK> TheMuso: Providing it as an option is much different than here's the new default.
<raof> I mean, I know it's more than a gstreamer abstraction, but it's a *media* abstraction, not a soundserver abstraction?
<TheMuso> ScottK: I know
 * raof has tried to understand, but *still* doesn't get what phonon buys KDE.
 * ScottK thought it was sound, but has tried to avoid knowing much about it.
<LaserJock> calc: I think full on crack, that's why I'm using KDE presently after years of Gnome usage
<raof> Fun new volume control bug: have two audio devices, one set to full volume, the other one (which is actually playing audio) set to a much lower, comfortable value.
<raof> Click the "Choose output device" radio button for the 100% volume device.  This results in the other, active device having its volume changed to 100%.  This is awkward when said other device is my USB speakers, which are painfully loud at that volume.
 * TheMuso would try KDE if there was sufficient accessibility.
<dtchen> raof: well, it's rather very WIP; stream migration isn't quite present
<ScottK> TheMuso: Feedback on what's missing would be appreciated.
<raof> dtchen: For values of "quite" equal to "at all", yes.
<TheMuso> ScottK: Its got to do with frameworks etc. QT is not yet hooked up to the at-spi framework, and won't be till at-spi is on dbus. It will be a while yet.
<TheMuso> ScottK: In simple terms, I can't even use a screen reader with KDE. KDE/Troltek know about this afaik but nothing can be done till other bits that will eventually e shared between gnome and KDE are done.
<ScottK> I see.
<bluesmoke> You would think someone would be paying for this work to happen if they really care about it
<TheMuso> bluesmoke: What work?
<bluesmoke> porting at-spi to dbus
<bluesmoke> If Qt Software is stalled on that happening they could speed it up
<TheMuso> bluesmoke: Its being done currently, but will take time.
<TheMuso> bluesmoke: and accessibility is a minority thing, so there are not that many people who do care about it.
<TheMuso> bluesmoke: And I am happy to wait. GNOME is serving me ok for now.
<jharr> So is there a script somewhere that's responsible for building the ubuntu release ISOs?
<dholbach> good morning
<jharr> I've seen plenty of "customize ubuntu's live CD for your needs", but no "this is how ubuntu builds their release installers."
<jharr> including the mini installers.
<LaserJock> jharr: that's debian-cd and ubuntu-cdimage
<jharr> LaserJock: thx.
<jharr> is ubuntu-cdimage a package somewhere?
<LaserJock> I don't think so
<LaserJock> jharr: look at the Launchpad projects of the same name
<LaserJock> and look at the bzr branches they have
<jharr> LaserJock: cool, thx
 * lamont tries to remember how to get X to spill a config
<pitti> Good morning
<LaserJock> uh oh, time for bed
<LaserJock> hi pitti
<tkamppeter> pitti, I got an answer on bug 318818, telling that an SRU consisting of a replacement of the released version by a newer upstream version needs TB approval and on the Wiki page https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions is written that the package build needs integrated regression tests (like CUPS has).
<ubottu> Launchpad bug 318818 in foomatic-filters "Intrepid fails LSB 3.2 tests on foomatic-filters" [Medium,In progress] https://launchpad.net/bugs/318818
<pitti> tkamppeter: I just replied to that
<tkamppeter> pitt, thanks, I also replied to your comment now.
<emgent> pitti: around ?
<pitti> emgent: hi
<emgent> hello pitti
 * pitti watches the jaunty retracers behave well -- finally
 * seb128 hugs pitti
<seb128> pitti: how did you fix the apt error thing?
<pitti> seb128: it was a bug in my "update apt cache for every retrace" commit
<pitti> seb128: after apt.Cache.update() you must call apt.Cache.open()
 * pitti hugs mvo
<pitti> seb128: since the archive doesn't change that much for intrepid, we only saw it for jaunty
<seb128> ah ok
<pitti> tkamppeter: btw, the idea of pet-bug is to be bugs which are very old already and you always wanted to work on, but didn't have time for in earlier releases (due to focus on feature development); they shouldn't be used for recent bugs
<pitti> tkamppeter: btw, is the cups SRU in the queue still valid, given that you recently proposed another pdftops fix in the bug?
<amitk> Can somebody accept the arm binaries from the last kernel build: https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-4.11/+build/840124
<amitk> pitti: ^
<ferrariii> hey i have tried to create a new workspace using the existing window manager on the host.. but i'm unable to do it .. .somebody please help me
<ferrariii> hey i have tried to create a new workspace using the existing window manager on the host.. but i'm unable to do it .. .somebody please help me
<pochu> ferrariii: this is not the right chanel for such questions, please ask in #ubuntu
<pitti> amitk: I'm not sure to which components I should put them; had there ever been any kernel armel debs in jaunty?
<amitk> pitti: not yet
<amitk> cjwatson requested it
<pitti> amitk: ok, I'll put them all into main then, and see what falls out later
<amitk> pitti: thanks
<amitk> pitti: I misread that. There were no udebs before
<amitk> pitti: the debs existed as far back as -2.2 https://edge.launchpad.net/ubuntu/+source/linux/2.6.28-2.2/+build/802941
<pitti> amitk: hm, I don't seem them on http://archive.ubuntu.com/ubuntu/pool/main/l/linux/
<pitti> oh, ports
<lool> zul: Hey, I think you uploaded the latest squid merge?  squid is uninstallable (and unupgradable) on all arches because squid-common was never rebuilt as the i386 build failed; did you have a look into this?
<lool> directhex: Not sure whether you saw my ping yesterday: I heard you're working on the C# transition which affects f-spot, beagle, tomboy in the default install; it's been some days that these prevent upgrades; is there a bug for whatever blocks progress right now?
<pitti> amitk: done
<directhex> lool, i don't know if there's an open bug for it. AFAIK the problem(s?) are related to the gnome# library getting changes in debian experimental which require an abi bump & rebuild
<seb128> ok, bug #197762 seems to be a frequent user complain, somebody wants to look at that for jaunty?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/197762/+text)
<seb128> not sure if that's linux to blame or who should be assigned to the bug
<seb128> bug #197762
<ubottu> Launchpad bug 197762 in linux "file transfers on USB disk are very slow" [Undecided,Confirmed] https://launchpad.net/bugs/197762
<directhex> lool, the one who knows most about it is slomo. if i get a chance today i'll try to investigate myself since he's rarely about
<seb128> the bug mostly gets frustrated users comments right now
<slomo> directhex: which bug?
<directhex> slomo, something surrounding your gtk# or gnome# updates (which were merged around alpha2 time) causes issues. i think it might just need a resync, build-dep change, and rebuild. but i've not had time to investigate myself
<directhex> i thyink sebner was investigating, but iirc he's off to do military service
<slomo> the only problem i'm aware of (that shouldn't disappear by merging the latest versions of gnome#/gtk# and uploading gnome-desktop# from NEW) is, that many packages need to be transitioned for the gnome# API change
<directhex> API, not just ABI? balls
<lool> directhex: thanks
<slomo> yes, there was quite some API cleanup... for example the panel applet stuff (which is not in gnome-platform but -desktop) was moved to gnome-desktop#
<slomo> oh and the gnomeprint stuff too
<directhex> blarg
<directhex> lool, i don't know how much chance i'll get today though
<lool> slomo: So the libs were pushed, but tomboy/f-spot/banshee aren't in a shape to use them?!
<slomo> lool: no idea who had the great idea to sync/merge it to ubuntu :) tomboy only needs a build-dep change but iirc f-spot/banshee need some code/build system changes
<lool> slomo: Lovely   :-/
 * slangasek raises his hand
<lool> slomo: Is upstream working on porting?
<slangasek> getting rid of mono 1.0 is going to be a significant savings on our CDs; unfortunately I didn't learn until after merging gnome-sharp2 from experimental that the pieces weren't all there yet
<slomo> lool: no idea about f-spot but for banshee i have this on my todo list ;)
<directhex> to be fair to slangasek, he was only trying to help, and i don't think anyone realised what a bad idea using gnome# from experimental was (whilst we were busily recommending everything ELSE mono related from experimental was great)
<slomo> i guess i should've been a bit more explicit in the changelog :)
<directhex> realistic question: does this warrant an epoch?
 * slangasek whimper
<directhex> i don't know how much trouble the API change will cause
<lool> I'd rather not epoch in Ubuntu and not in Debian
<directhex> lool, i know, but slomo's in charge of gnome# in both
<slomo> well, it should be fairly easy to port all packages... it just needs someone to do it ;)
<lool> slomo: Actually banshee is installable
<lool> So it's only tomboy and f-spot for me, and tomboy is said to be trivial
<slomo> yes, tomboy is just a b-d change... i'm surprised that banshee works though. libgconf2.0-cil became libgconf2.24-cil
<slomo> same for libgnome2.0-cil
<tkamppeter> pitti, did you get my answers on your last messages here? Or did you reply something? I had a network interruption shorttly after that?
<slomo> so i guess the old binary packages are still there or something
<pitti> tkamppeter: I didn't get answers from you
<tkamppeter> So I will repost them:
<seb128> I would rather try to update f-spot if upstream didn't yet than use an epoch
<tkamppeter> sorry, I thought these are the bugs I thought to be most important or put the most effort into.
<lool> slomo: I don't know whether it works, it's just installable
<tkamppeter> pitti, the fix in the pdftopdf filter which is the proposed SRU fixes a regression against Hardy and so makes the behavior of the filter workflow in the cases mentioned by the bug at least equal Hardy. The proposed fixes on pdftops and pstopdf in the last 5 or so postings are to really fix the problem of mixed-page-size documents and printing with the paper size given by the document.
<slomo> lool: ok :)
<slomo> well, i've to get some food now... bbl
<pitti> tkamppeter: if there wasn't an explicit "LSB compat" fix, but LSB compat only broke due to the other regressions, that's fine
<pitti> tkamppeter: okay, so the current upload in intrepid-proposed is not obsolete then?
<tkamppeter> pitti. yes.
<pitti> seb128: did you ever see a double-pkgstriptranslations build as in http://launchpadlibrarian.net/21351698/buildlog_ubuntu-jaunty-i386.glib2.0_2.19.5-0ubuntu1_FULLYBUILT.txt.gz ?
<seb128> pitti: no, just the one which got mentionned on #soyuz yesterday
<pitti> I tried to replicate it locally, without success, and had a long hard stare at the code
<pitti> I have NFC where it would fork
<seb128> pitti: how would you notice it out of a publisher crash?
<pitti> hm, good question
<seb128> I don't look at build logs so closely when the build success usually
<slomo> lool, directhex: for porting just keep in mind that platform stuff is now in gnome-desktop# (i.e. panel applet, gnomeprint), that all pkg-config files have a different version number now and that every removed method will have a better alternative (iirc some deprecated/obsoleted methods were removed)
<pitti> seb128: well, if that was the reason for the publisher crash, then I guess it didn't happen before
 * pitti spots "InterpreterPath: /target/usr/bin/perl" in a crash report and sighs -- aufs FTW
<james_w> pitti: there's someone in #ubuntu-bugs with a report of a regression in Intrepid. metacity is now segfaulting on login.
<james_w> pitti: so far it is hinting towards libc6 in -proposed or cups in -security
<pitti> james_w: uh, we didn't update that for a while
<james_w> pitti: I'm asking them to narrow it down as we speak
<pitti> james_w: libc6 was updated 11 days ago for some fortify regression fixes
<pitti> james_w: so he runs -proposed?
<james_w> http://pastebin.com/m711f0ba5 <- stacktrace  http://pastebin.com/d7369120b <- which-pkg-broke
<james_w> yeah, -proposed enabled
<james_w> and those two packages updated today as you can see
<pitti> so downgrading libc6 or libcups2 should telll
<james_w> they're currently downgrading libc6
<james_w> perhaps I should have started with cups actually
<pitti> james_w: the cups security update only affected the scheduler, not the library
<james_w> pitti: interesting, thanks
<james_w> I'll let you know how things go, but I wanted to mention it early
<pitti> james_w: thanks a heap!
<pitti> james_w: where is which-pkg-broke? apt-cache search doesn't catch that
<james_w> pitti: debian-goodies
<pitti> awesome
<james_w> really useful tool
<james_w> pitti: will a downgrade of libc6 require a restart for metacity to start using the new one?
<pitti> james_w: yes, but I thought it previously crashed on startup?
<pitti> all running programs need to be restarted for using the new libc6
<james_w> k
<james_w> they have rebooted since the upgrade
<james_w> but not since the downgrade
<james_w> and it crashes when metacity starts, they are using an alternative WM at the moment
<pitti> then it should work immediately
<pitti> james_w: of course, theoretically, it could also be libcups2 now misbuilding due to new glibc, or something similarly hairy
<james_w> urgh
<pitti> so downgrading that too is still worthwhile testing
<james_w> yup
<james_w> the cause of the bug seems to be an empty gconf setting though, but that is a bit odd
<pitti> seb128: FYI, all bugs are retraced now, and retracer is fully on auto
<seb128> pitti: excellent!
<apw> superm1, hey you about?
<james_w> pitti: panic off it seems. Corrupted gconf defaults were the cause. Why that happened is not clear, but I can't see a link to the updates.
<directhex> shameless plug: http://ubuntuforums.org/showthread.php?p=6584115
<tseliot1> directhex: no repository for jaunty?
<directhex> tseliot1, no. do you want one? it's the same source package for any dist with cairo >= 1.8
<tseliot1> directhex: sorry, I had missed the line about Jaunty in your post
<directhex> tseliot1, it's not in jaunty yet due to NEW slowness (when it's in exp i'll requestsync)
<directhex> tseliot1, but if you like, i can just quickly upload a jaunty version to my ppa
<tseliot1> directhex: please do it :-)
<directhex> uploaded. waiting for build.
<tseliot1> directhex: thanks a lot
<directhex> build started
<tseliot1> great
<seb128> james_w: we get some bugs every now and then where the gconf settings are not correctly set for some softwares, there is a bug open about this bug gconf doesn't log enough to give a real clue about when and how that's happening, and usually doing a new schemas registration works correctly
<directhex> it's a 9 minute build.
<james_w> seb128: sounds about right
<liw> if I suspect a license problem with a package in Ubuntu, what should I do?
<liw> that is, is reporting it as a public bug the right way to do it?
<directhex> tseliot1, build, pending the usual LP delays creating Packages.gz
<directhex> s/build/built/
<tseliot1> directhex: thanks again
<directhex> tseliot1, no problem - i'm pleased as anything to avoid a disappointing miss for moon as happened with the olympics
<kagou> Hi
<kagou> Hi, I'm testing beta of bibble5. Bibble5 is not compiled for 64bits, so I'v installed ia32 and bibble5 is ok. In the last beta libuuid1 is needed, but libuuid1 installed is for x86-64 architecture.
<kagou> I can not find an elegant way to install the 32bit version of this lib
<kagou> I'v manually downloaded and manually extracted lib in /lib32 but it's dirty
<kagou> is there a way to simplify this ?
<maxb> No, there is no elegant way to install 32bit libs if they are not specifically packaged
<kagou> maxb, is there a possibility to use a 64lib in a 32bit emulation ?
<maxb> no
<kagou> wow that's problematic
<Keybuk> dholbach: does your nag script take into account bugs that were tagged for sponsoring, but for which the tag was removed and the sponsor subscribed themselves to chase for more information? :p
<kagou> maxb, thanks
<dholbach> Keybuk: it counts uploads and bug traffic on the sponsoring mailing lists
<dholbach> Keybuk: which tag are you using there?
<PeakerWork> I remember "deb-make" could make a debian package out of a normal source. What replaced it?
<PeakerWork> I want to build a package for the newest git sources
<directhex> there's no way to create a package without doing some actual packaging work which doesn't suck hard
<directhex> you MIGHT be thinking of dh_make (which creates a skeleton packaging setup)
<directhex> you might be thinking of checkinstall (which takes some source & jumps all over your /usr
<PeakerWork> dh_make yeah
<jdstrand> pitti: hi! regarding my ufw SRU. A bug just came in today that I would like to fix in that SRU. would you mind if I revved the version with the fix and updated the bug, or would it be better to hold off and do another SRU later?
<pitti> jdstrand: is it a bug in the changes you made to that SRU, or an independent one?
<pitti> jdstrand: usually it's better to shove through one SRU completely, then start with the next round
<pitti> and in the mean time, stash changes into bzr
<jdstrand> pitti: it is a completely new, unique bug
<jdstrand> pitti: independent of that SRU
<pitti> jdstrand: second, the new bug should match the SRU criteria (some in the previous one really were borderline, like the removal of rc0.d symlink)
<jdstrand> pitti: oh, I thought we discussed that one on IRC...
<jdstrand> pitti: but I don't think you'll have a problem with me fixing this new one
<jdstrand> :)
<pitti> jdstrand: yes, and I approved it :) but as I said, I think it's borderline
<jdstrand> bug #319226
<ubottu> Launchpad bug 319226 in ufw "ufw fails if /etc under subversion revision control" [Undecided,In progress] https://launchpad.net/bugs/319226
<jdstrand> pitti: cool. btw, on a totally unrelated note-- while I always had procmail recipes for my ubuntu email, your talk in UDS on how you have your four classes of email *totally* helped me out
<pitti> jdstrand: depends on how it fails, I guess
<pitti> jdstrand: glad to hear it :)
<jdstrand> pitti: I'm actually able to see things as they come in and not be completely buried
<jdstrand> pitti: thanks! :)
<pitti> jdstrand: my feeling as well, it allows me to keep up with the important bits without getting swamped
<jdstrand> pitti: re bug> it exits with error about finding a hidden file in the ufw directory. It is a superfluous check, cause I don't read in any hidden files anyway...
<jdstrand> pitti: but I'll just do another SRU, as you suggested
<pitti> jdstrand: it doesn't sound very urgent, so I'd recommend waiting until this one is in -updates
<jdstrand> pitti: np. thanks for your feedback :)
<pitti> jdstrand: (people will either have noticed by now and found a workaround, or are using a completely different solution by now)
 * jdstrand nods
<directhex> tseliot1, does that package work for you? i posted a link to a SL game which should be an adequate test
<tseliot1> directhex: it didn't but I'm running firefox 3.1. I had to install the firefox extension manually
<directhex> tseliot1, it ought to work on 3.1, the deps were fiddled especially
<tseliot1> directhex: I doubt it's specific to your package though. The same happened to me with some other plugins before
<directhex> tseliot1, is this ff3.1 from the mozillateam ppa?
<tseliot1> directhex: no, I extracted the tarball from mozilla's website
<directhex> tseliot1, aha. do you want to get the package working, or do you prefer to use the .xpi?
<ogra> oooh, cjwatson is back :)
<directhex> tseliot1, symlink /usr/lib/moon/plugin/libmoonloader.so in your tarball firerfox's plugins folder. it doesn't check /usr/lib/xulrunner-addons, which is an ubuntuism
 * ogra gently points cjwatson to the ubuntu-devel ML discussion about debootstrap
<tseliot1> directhex: ah, ok thanks
<directhex> tseliot1, applies generally for plugin packages
<tseliot1> yes, I picked that up
<cjwatson> ogra: ok
<ogra> ha! i knew i'd get Keybuk intrested in the thread if i mention upstart somewhere ... that magically summons him *g*
<Keybuk> ogra: err, you mentioned Upstart?
<ogra> indeed i did
<Keybuk> I didn't notice that
<Keybuk> I jumped into the thread because cjwatson and I were just talking about debootstrap and making devices the other day
<ogra> ah
<cjwatson> ogra: actually, the only thing I wanted to say has already been said
<ogra> Keybuk, init does if it cant write to /dev/console, so indeed i mentioned upstart :)
<cjwatson> ogra: i.e. it's already in backports (and pitti also said that SRUs for stable releases would be fine, which I agree with)
<ogra> cjwatson, backports ?
<cjwatson> yes, backports
<ogra> i'm talking about jaunty there
<Keybuk> ogra: init does what?
 * ogra should probabaly have mentioned that
<pitti> well, I said that *backports* are fine, and that I'd rather not stuff it into SRUs
<cjwatson> ogra: are we looking at different threads? I'm looking at Subject: piuparts, debootstrap and newer releases
<ogra> cjwatson, "missing /dev/console in debootstrap --foreign, a bug or not ?"
<cjwatson> pitti: err, right, sorry, I oversimplified. (You did say that it would be bearable but you'd rather not.)
<cjwatson> ogra: oh, I haven't pulled down all my mail yet. I'll get to it
<Keybuk> ogra: looking at debootstrap's code, I can't see why /dev/console would be missing
<pitti> well, either way; if we need them for something, let's do them
<cjwatson> pitti: as people said, they're already in backports
<ogra> Keybuk, "attempting to kill init" involves upstart (in some remote way :) )
<Keybuk> oh, wait, yes I can
<Keybuk> ogra: sure, you can't start any init if you don't have at least /dev/console or /dev/null
<cjwatson> I've been sticking debootstrap into backports myself for years anyway, since I know the backport is trivial :)
<Keybuk> that's not Upstart specific
<ogra> Keybuk, thats what my mail said :)
<Keybuk> cjwatson: so it turns out that "console" is not made by MAKEDEV std
<cjwatson> Keybuk: so add consoleonly to that?
<ogra> Keybuk, it also said that you could (indeed thats very ugly) make init call mknod first :)
<Keybuk> consoleonly makes other things too
<Keybuk> ogra: no I can't, the filesystem is read-only
<cjwatson> consoleonly makes one other device, namely tty0
<Riddell> pitti: you uploaded calibre?  it includes code under the four clause BSD which would be incompatible with the GPLed code
<ogra> oh, right
<Keybuk> cjwatson: oh, sorry, was reading console)
<cjwatson> which doesn't seem like too much of an imposition
<Keybuk> . o O { man, makedev doesn't do anywhere near anything similar to udev }
<pitti> Riddell: oh argh, forgot about that
<cjwatson> Keybuk: btw, mind if I upload udev? I fixed its udeb earlier today
<Keybuk> cjwatson: how did you fix it?
<cjwatson> added lib/udev/devices/{net,pts,shm} to udev-udeb.dirs
<cjwatson> udev.installer-startup got kind of upset when cp /lib/udev/devices/* failed
<pitti> Riddell: it's used in a plugin in calibre-bin (msdes.so)
<Keybuk> heh, sure
<pitti> Riddell: what was that problem again, the advertising clause/
<pitti> ?
<Riddell> pitti: yes (well potential problem still looking at it)
<Keybuk> cjwatson: I haven't thought about the groups issue yet
<cjwatson> Keybuk: that's OK, it's cosmetic rather than important
<Keybuk> we may end up just growing udevd --no-groups or something
<cjwatson> aye, that's the kind of thing I was thinking about
<cjwatson> I couldn't imagine you wanting to tweezer apart all the rules again just for the udeb
<wasabi> Hmm. All this talk about Wine is interesting. I wonder if we're every going to get it to integrate so it acts like eral windows with regards to having per-machine stuff.
<cjwatson> Keybuk: so what do I need to do with bzr-builddeb to make this build properly?
<Keybuk> cjwatson: you can't ;)
<Riddell> pitti: so it's a GPL 3 python app loading and using an incompatible licence plugin
<cjwatson> I don't think I remember the conclusion of your discussion with James
<cjwatson> Keybuk: ah. what's the magic dpkg-buildpackage argument then? :-)
<Keybuk> cjwatson: bzr clean-tree && dpkg-buildpackage -S -i(.bzr|.git-ignore|test)
<Keybuk> iirc
<pitti> Riddell: merely shipping the source is okay, right? so if I just disabled building and shipping the plugin it should be okay, until we sort this out with upstream?
<Riddell> pitti: yes that's fine
<Keybuk> err
<Keybuk> cjwatson: bzr clean-tree && dpkg-buildpackage -S -i(.bzr|.gitignore|test)
<Riddell> pitti: I'll reject for now then
<pitti> Riddell: okay
<cjwatson> Keybuk: yeah, that does the right thing, thanks
<Dreig_> http://www.pennergame.de/change_please/6086543/
<dholbach> Ubuntu Developer Week - Day 2 just about to start in 17m in #ubuntu-classroom :)
 * pitti is still creating his talk...
<Jarlen> yay :)
<Jarlen> it was a really nice start yesterday
<dholbach> pitti: you luckily still have a bit of time left :)
<dholbach> Jarlen: yeah, it was fantastic :)
<Jarlen> well, depends on how you define fantastic
<dholbach> in my view it was FANTASTIC :)
<Jarlen> if you rule out that I didn't make 50% of my homework because I was reading Ubuntu developer stuff, then yah, it was fantastic :P
 * dholbach hugs Jarlen
<Jarlen> from an ubuntu point of view, I really enjoyed it!
<Jarlen> is there ever any events like this from a community point of view, instead of the developer POV?
<dholbach> Jarlen: there's an Ubuntu Open Week two times a year too
<dholbach> other sessions are less regular
<Riddell> pitti: do you know what's to be done with the language packs waiting in hardy-proposed New?
* dholbach changed the topic of #ubuntu-devel to: Archive: open, MoM running, alpha-3: released | Ubuntu 8.10 released! | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | this week: https://wiki.ubuntu.com/UbuntuDeveloperWeek
<Jarlen> dholbach: ah, yeah, the open week looks a bit more diverse
<pitti> Riddell: they should just be rejected IMHO, we haven't introduced new langauges into stables so far
<dholbach> Jarlen: less focussed on development
<Jarlen> we're working on a community track for the danish 9.04 release party, so some inspiration could be great :)
<Riddell> pitti: ok, seems a bit harsh on the people doing the translations needlessly though
<dholbach> Jarlen: best to ask your users what they'd like to see :)
<Jarlen> and a global IRC session/brainstorm/week to get inspired would be a great start :)
<cjwatson> pitti: we haven't? I'm sure I've accepted new language packs into stables lots of times
<cjwatson> inc. when you were driving langpack-o-matic :-)
<pitti> cjwatson: yeah, unfortunately it still spits out new languages, since we do not have a per-release list of supported locales
<cjwatson> I don't see it as a big deal to accept them
<pitti> i. e. new locales which got introduced into e. g. intrepid or jaunty aren't present yet in dapper and hardy
<pitti> no, it's not a big deal, I just didn't do it so far
<Baby> pitti: ping!
<pitti> Baby: pong
<Baby> pitti: which file was BDS4? there was one in old versions but upstream replaced it
<pitti> Baby: the msdes stuff?
<Baby> yup
<pitti> Baby: oh, indeed that's not BSD any more, but public domain and GPL 2+
<pitti> so we just need to fix the copyright file
<Baby> in the version I uploaded to Debian it is not BDS4
<Baby> yup
<pitti> Riddell: ^ will do that, it was just obsolete debian/copyright
<Baby> I had 2 or 3 mails with upstream some time ago to fix that :)
<Riddell> nice
<Baby> :)
<pitti> right, I'll upload the current bzr head to Ubuntu then
<Baby> we might think about upgrading it to latest version
<Baby> upstream releases once or twice a day XD
<Baby> usually with just one or 2 lines of change between versions
<pitti> Baby: that, too
<Baby> XD
<pitti> Riddell: anything else which was wrong with it?
<Riddell> pitti: nope
<Baby> the only issues I found were that BSD4 thing and the fonts, and they were both fixed :)
<nijaba> dholbach: did soren reply to you regarding tomorrow presentation?
<dholbach> nijaba: no, he didn't
<nijaba> dholbach: I guess he is really sick
<jsmidt> Which command will merge Ubuntu and Debian changelogs?
<tseliot1> directhex: now it tells me that moonlight was compiled with 1.0 support only while 2.0 is required
<tkamppeter> pitti, did you have another look at the foomatic-filters SRU? bug 318816, bug 318818, bug 299918, bug 303691
<ubottu> Bug 318816 on http://launchpad.net/bugs/318816 is private
<ubottu> Launchpad bug 318818 in foomatic-filters "Intrepid fails LSB 3.2 tests on foomatic-filters" [Medium,In progress] https://launchpad.net/bugs/318818
<ubottu> Launchpad bug 299918 in foomatic-filters "Cannot print duplex in intrepid with Ricoh Aficio 2060, Ricoh Aficio MPC3000 or Brother HL-4050cdn using the openprinting drivers" [High,Fix committed] https://launchpad.net/bugs/299918
<ubottu> Launchpad bug 303691 in foomatic-filters "Intrepid, print broken with Minolta PagePro 8L printer" [High,Fix committed] https://launchpad.net/bugs/303691
<pitti> tkamppeter: I thought we sorted that out this morning? I'm ok with it
<tkamppeter> pitti, can you then approve the foomatic-filters package to enter -proposed? And can you also let the cups package enter -proposed? Thanks.
<pitti> tkamppeter: yep, will do next time I'll process SRU
<tkamppeter> pitti, which day/time is SRU for you?
<pitti> tkamppeter: every other day roughly
<Golgata> hope someone can help me. i want to create a container usable with virtualbox which i can later burn to a dvd... sb got an idea?
<tuxcrafter> hi all , i saw the discussion about the debootstrap on the mailinglist
<tuxcrafter> i would like to ask some questions about this
<tuxcrafter> i am doing some testing on emdebian and i got the following error while debootstrapping
<tuxcrafter> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512067
<ubottu> Debian bug 512067 in buildd.emdebian.org "debootstrap: sysvinit: init: timeout opening/writing control channel" [Normal,Open]
<Golgata> maybe customizing the ubuntu-livecd is easier?
<tuxcrafter> does somebody know where this bug comes from it is very similair as the issue descussed on the ubuntu-devel mailinglsit
<Keybuk> tuxcrafter: sounds like you're using a sysvinit tool
<tuxcrafter> Keybuk: i think some sub script needs some device node...
<tuxcrafter> because sysvinit should know not to start services when in debootstrap
<Keybuk> Ubuntu does not use sysvinit
<tuxcrafter> true .. :-p upstart
<kirkland> pitti: hey, can you push ecrypftfs-utils 53-1ubuntu13 from proposed -> updates?  it's been in proposed since 2008-11-05
<Keybuk> there is no /dev/initctl in Ubuntu
<cjwatson> it sounds entirely unrelated to the issue recently discussed on ubuntu-devel, to me
<tuxcrafter> cjwatson: it could be i am still trying to get more info on the issue
<cjwatson> tuxcrafter: (I fixed the issue recently discussed on ubuntu-devel, and am fairly confident ...)
<tuxcrafter> cjwatson: how did you debug your issue?
<cjwatson> tuxcrafter: I already know debootstrap very well, so that probably isn't much use to you; besides, when I turned up today people had already more or less figured it out
<cjwatson> tuxcrafter: FWIW debootstrap's Makefile (in the source package) calls MAKEDEV with some arguments, and you can look up what those arguments do in /sbin/MAKEDEV
<cjwatson> tuxcrafter: somebody should extract /debootstrap/debootstrap.log from the failed chroot and attach it to that bug report; it is likely to offer more detail
<tuxcrafter> cjwatson: i will start searching for the debootsrap log, did you used some book/website to get all your knolage of debootstrap or did you investigated the code?
<ogra> cjwatson, thans for the quick fix ! :)
<ogra> *thanks even
<fabbione> Keybuk: what's the rationale for forcing udev rule files from /etc/ to /lib.. ? I can see in other distro that it's possible to use both directories...
<fabbione> Keybuk: specifically they use /lib for rules that should not be modified by the users (like all those *persistent* stuff) and left the others in /etc untouched
<cjwatson> tuxcrafter: I read and worked on the code
<Keybuk> fabbione: udev rules aren't configuration files in the normal sense, but a turing complete programming language
<Keybuk> those shipped by a distribution that provide the *default* behaviour should be considered acting and behaving as built-ins
<Keybuk> so are shipped in /lib
<Keybuk> (a future udev could compile them into the udevd binary, for example)
<Keybuk> udevd reads /etc/udev/rules.d afterwards, so any user rules can override anything made by default
<Keybuk> separating the files means that a user's own rules become individual in their own right
<Keybuk> and aren't confused by upgrades, etc.
<Keybuk> this isn't an Ubuntu-specific change
<Keybuk> in fact, in jaunty, the primary change has been to drop the old Ubuntu rules files and instead use standard upstream rules files
<fabbione> Keybuk: hmm ok.. yeah i know it's not Ubuntu-Specific..
<Keybuk> these are shared between Ubuntu, Fedora (so RHEL too), Gentoo and SuSE
<fabbione> that's why i know other distros allow both
<fabbione> yeps :)
<Keybuk> we just happened to be a bit quicker at moving everything from /etc to /lib because our upload privilege system allows one person to make the changes
<Keybuk> the plan is that all distributions would move to their packages shipping rules in /lib over time
<fabbione> actually you are not that quicker at all
<fabbione>  /lib was used in F10 and before alread
<Keybuk> right. but F10 only uses /lib for the rules shipped by udev itself, not by third party packages, right?
<fabbione> for what i can see...
<Keybuk> my understanding was that the latter transition was expected to take longer
<Keybuk> (from harald)
<fabbione> hmmm
<Keybuk> upstream software should also now feel confident about just installing rules into /lib/udev/rules.d by default
<fabbione> thinking out loud...
<Keybuk> and expect that to work on most of the major distributions
<fabbione> is it possible to disable certain *persistent* rule in a configurable fashion?
<Keybuk> yes
<fabbione> the reason why i jumped in to ask is because i can fix upstream as well (for redhat-cluster at least) to match new distro fashions ;)
<fabbione> so we don't have to carry around deltas for nothing
<Keybuk> if you install to /lib/udev/rules.d, you're obviously free to GOTO over a rule supplied by upstream udev
<Keybuk> (assuming that's what you mean?)
<fabbione> example: persistent-net-foo.rule in /lib...
<fabbione> the one that generates ethX <-> Mac association
<Keybuk> the 70-persistent-{cd,net}.rules files are in /etc because they're configuration
<fabbione> i don't want it enabled... can I disable it?
<Keybuk> sure
<Keybuk> echo '#disabled' > /etc/udev/rules.d/75-persistent-net-generator.rules
<fabbione> how will that work in the new system?
<fabbione> ok
<Keybuk> files in /etc trump default rules
<fabbione> so if the file is /lib../75-persistent-net-generator.rules
<fabbione> and there is an equivalent in /etc...
<fabbione> the one in etc > lib ?
<fabbione> right?
<Keybuk> then the file in /etc is used insteead
<fabbione> ok perfect
<fabbione> sounds good
<Keybuk> that's the correct way to deal with "I just don't want this functionality" kind of behaviour
<Keybuk> for example, also if you wanted to specifically not run programs, etc.
<Keybuk> otherwise you'd normally just create your own files, /etc/udev/rules.d/50-fabbione.rules etc.
<fabbione> gotcha
<fabbione> thanks
<Keybuk> you can also disable the generator rules by something like:
<cjwatson> fabbione: FWIW, the README files in /{etc,lib}/udev/rules.d/ document this
<Keybuk>   /etc/udev/rules.d/10-fabbione.rules:
<fabbione> it's mainly because i have some fancy hw where some of those things fail
<Keybuk>     SUBSYSTEM=="net", NAME="%k"
<Keybuk> fabbione: we'd like to know about that fancy hardware; your personal customisation is likely something we should ship in udev by default!
<fabbione> cjwatson: ok thanks..
<fabbione> Keybuk: no you don't :) I am sure as soon as I mention that architecture that starts with S and ends with 64 you run away screaming :P
<Keybuk> fabbione: if it's an architecture supported by the linux kernel, it should be supported by upstream udev
<fabbione> Keybuk: for example on sparc, it's very common that all onboard NIC share the same Mac address
<Keybuk> iirc, on sparc, the onboard nics can be identified by something else though, right?
<fabbione> Keybuk: on hardy it triggers a rename race in udev because of the different net-generator/net-keep-the-same-eth etc. scripts
<Keybuk> yeah, that's something we should certainly support upstream
<fabbione> Keybuk: it depends from the hw.  not all of them do and it's not that easy as it involves a much more complex operation in poking into OBP
<fabbione> Keybuk: where often OBP mapping != kernel mapping...
<fabbione> Keybuk: anyway i appreciate all your explanation. I'll fix my little upstream corner once i am back from sick leave
<Keybuk> np
<Keybuk> most of us (including kay and harald) hang out on #udev as well
<fabbione> oh it's alright.. i really don't have time to hack that too
<fabbione> you might want to know that udev works just fine on m68k...
<fabbione> even after a potato -> sid dist-upgrade ;)
<liw> what's the process of getting an application included in the default Ubuntu desktop install? who decides this?
<tjaalton> Keybuk: hey, I've got problems with jaunty and root on SAN (multipath). init gives up waiting for root, so I'm dropped in busybox, but running kpartx manually and exiting the shell makes the boot resume
<Keybuk> tjaalton: I don't know much about multipath I'm afraid
<Keybuk> is multipath-tools and its udev rules installed into the initramfs?
<tjaalton> yes
<tjaalton> hence kpartx working
<tjaalton> but what I'm thinking is that maybe it gives up too early
<maxb> liw: Is it packaged? Is it in main?
<tjaalton> it takes some time to probe the devices
<liw> maxb, is packaged, is in main (system-cleaner-gtk is the package)
<Keybuk> is there a /lib/udev/rules.d/*-multipath.rules ?
<tjaalton> Keybuk: yes
<Keybuk> is there a /lib/udev/rules.d/*-kpartx.rules ?
<tjaalton> yes
<Keybuk> tjaalton: what number has the kpartx.rules ?
<tjaalton> Keybuk: 95-
<cjwatson> liw: any core developer may edit the seeds
<Keybuk> tjaalton: no idea then, sounds like it should all work to me
<cjwatson> liw: if it's likely to be controversial, a discussion on ubuntu-devel@ or ubuntu-desktop@ would be polite
<cjwatson> liw: there's no more heavyweight process than that
<Keybuk> tjaalton: that rules file runs kpartx for you when devices are added
<liw> cjwatson, ack, I*ll e-mail ubuntu-desktop (I assume that's the more appropriate list)
<tjaalton> Keybuk: but what if I'm dropped to busybox before it's run?
 * ScottK alters the Kubuntu seeds every time Riddell takes a vacation.
<tjaalton> is it possible?
<Keybuk> tjaalton: there's a three minute timeout
<Keybuk> if it takes more than three minutes to setup, sure, you'll be dropped to busybox first
<tjaalton> Keybuk: oh, it's certainly shorter.. maybe 10sec
<Keybuk> actually it might only be 30s now
<tjaalton> I need to measure it..
<Keybuk> shorter than that implies it failed to mount perhaps?
<Keybuk> did it say "Gave up waiting" ?
<tjaalton> the error message says that it didn't find root, and the devices are not set up either
<Keybuk> or "Could not mount"
<tjaalton> the former
<Keybuk> implies that the device setup hasn't worked then
<tjaalton> is there a way to add some debug output?
<Keybuk> nothing automatic
<Keybuk> boot with break=premount
<Keybuk> rm scripts/init-premount/udev
<Keybuk> /sbin/udevd --debug > /dev/udev.log 2>&1 &
<Keybuk> (wait a second or two)
<Keybuk> /sbin/udevadm trigger
<Keybuk> then ^D to continue the boot as before
<tjaalton> great, thanks.. I'll try that first thing tomorrow
<Keybuk> please be sure to mark the udev.log *before* you run kpartx by hand
<Keybuk> tbh, I would actually at that point kill the running udevd
<Keybuk> then start another one up with a different log file
<Keybuk> (so we can see what happens when you run kpartx)
<tjaalton> ok, I'll play with it
<ScottK> cjwatson: Congratualtions on tech board.
<cjwatson> thanks!
<cjwatson> though somebody still needs to actually add me to the team ;-)
<jpds> cjwatson: Congrats!
<james_w> congratulations cjwatson
 * robbiew gives a "whoohoo!" for cjwatson
<liw> cjwatson, onneksi olkoon
<robbiew> ??????
<robbiew> :P
<liw> "congratulations" in Finnish. no point in wasting an opportunity to be weird.
<lool> cjwatson: Thanks for the debootstrap fix
<lool> cjwatson: Should I forward to Debian?
<cjwatson> lool: I already committed it upstream (i.e. Debian)
<cjwatson> so thanks but no need
<cjwatson> can't upload it because the installer is frozen, but it's in svn
<pitti> cjwatson: congratulations, and many thanks for your always insightful and correct advice
<lfaraone> Hi, would problems with the livecd "shut down" option not actually powering off after halt be a bug in casper, or what?
<ogra> cjwatson, oh, you made it ! congrats :)
<cjwatson> lfaraone: depends; if it's due to filesystems not being unmounted or something similar, then yes - but, if possible, try to find out if an installed system doesn't manage to power off either
<cjwatson> lfaraone: if the latter is the case, then it's likely that the kernel needs to add an ACPI quirk for your system, and the way to get that done is to file a bug on the kernel and attach the output of dmidecode
<lfaraone> cjwatson: well, it _does_ power off in intrepid, I don't have an install d jaunty system.
<lfaraone> *on this system
<cjwatson> lfaraone: there are various reboot= parameters one can give to the kernel to tweak this
<cjwatson> otherwise, debugging it is probably a somewhat tedious matter of adding set -x to bits of the init system called on shutdown
<lfaraone> cjwatson: it prints out its final "system halted" screen but doesn't die.
<cjwatson> that means userspace is all done and it's up to the kernel
<cjwatson> well, unless it's calling the wrong syscall to power off, but ...
<lfaraone> cjwatson: so you're betting that this problem would also occur in an installed system.
<cjwatson> that would be my guess. it's always possible I'm wrong
<lfaraone> wooh, we have a REGRESSION.
<pitti> calc: do you plan to have ooo-langpacks for jaunty? I. e. should I approve the "jaunty" goal proposal?
<lfaraone> cjwatson: would it be sufficent for me to ninstall the jaunty kernel on my intrepid install, or should I upgrade fully to test?
<calc> pitti: i'm working on it during jaunty but it won't land until jaunty+1 i think
<pitti> calc: ok, I decline it as a jaunty goal then
<calc> pitti: i'll be working with sun the week after the sprint in hamburg on it
<calc> pitti: is there a way to put it for 9.10 already, or just have to leave it unassigned for now?
<pitti> calc: the latter, I think
<calc> ok
<calc> pitti: similiarly the ooo-splitbuild will only be in ppa until jaunty+1
<cjwatson> lfaraone: I think the kernel alone should be sufficient
<lfaraone> cjwatson: thanks
<LaserJock> cjwatson: congrats! I'm glad to have you on the TB
<LaserJock> it was very much a win-win situation for us, IMO :-)
<cjwatson> Kees would have been an excellent TB member too, in some ways I'm sorry it had to be a choice; perhaps we can rectify that at a later time :-)
<LaserJock> definately
<pochu> cjwatson, kees: thanks both for running for the position!
<pochu> LaserJock: how do you know? I see nothing in u-d-a or u-a
<cjwatson> https://launchpad.net/~ubuntu-dev/+polls shows it
<pochu> oh, I was looking directly into ~techboard to see if any had been already added to the team
<cjwatson> no, I figure somebody will get round to that at some point :)
<kees> cjwatson: congratz!  I'm honored to have been nominated, and I'm happy to have you on the TB.  :)
<maxb> I filed an NBS bug and subscribed ~ubuntu-archive about 3 weeks ago - should I assume that all the argive admins are tied up with Hardy.2, or should I be wondering if I did something wrong in the bug? (LP 311585)
<ubottu> Launchpad bug 311585 in gcc-4.2 "NBS: lib[64|32]ffi4" [Undecided,New] https://launchpad.net/bugs/311585
<ScottK> maxb: What are you expecting to happen?
<directhex> chorus of angels would be nice
<maxb> Well, NBS binaries get removed, right? And for some reason those ones aren't showing up at people.ubuntu.com/~ubuntu-archive/NBS/
<maxb> So I thought I should be calling attention to them
<slangasek> yes, the bug being filed is helpful - I'm aware of the bug, but didn't get to it on my last couple of archive days
<ScottK> OK.
<slangasek> (not all the archive admins are tied up with hardy .2, but I am :)
<ScottK> slangasek: Any idea why they aren't on the NBS list then?
<slangasek> it's helpful to have the bug filed in this case because it's a some-archs-only NBS
<ScottK> Ah.
<slangasek> the NBS report only detects when the package is gone from debian/control, not when it shifts arch coverage
<maxb> Thanks, just wanted to make sure I'd done the right thing with the bug
<mathiaz> archive admins: why was the checkbox upload rejected?
<mathiaz> Riddell: ^^ nevermind - I've got the answer.
#ubuntu-devel 2009-01-21
<etate> allo ppl, i'm looking for a package that is apparently supposed to be in a repo, but cannot find it
<etate> gwydion-dylan-dev to be precise
<etate> by supposed to be i mean "was last year"
<ScottK> We've got nothing like that.  In the future, #ubuntu is the support channel.
<etate> oh my bad
<etate> by "we've got nothing like that", you mean, there isn't a package in the ubuntu repositories?
<etate> s/a package/the gwydion dylan package/
<ScottK> Searched on qwydion and got nothing.
<ScottK> See http://packages.ubuntu.com.
<etate> nice, thanks
<dholbach> good morning
<tjaalton> calc: is OO.org 3.1 planned for jaunty?
<tjaalton> Keybuk: heh, the server keyboard doesn't work in premount phase
<tjaalton> so that didn't work out
<tjaalton> maybe I could use the serial console..
<tjaalton> Keybuk: ok, so for some reason it doesn't match the "RUN+=kpartx .." rule
<dholbach> ara_: would it be a good idea to get the qa tools into Ubuntu proper? WDYT?
<ara_> dholbach: yes, I think it should be a good idea. To do so, it needs a lot of cleaning first ;-)
<dholbach> ara_: we're before feature freeze - I think we can handle a few bugs :-)
<dholbach> ara_: maybe it makes sense to take a look at ubuntu-dev-tools for the packaging
<ara_> dholbach: ok, I'll have a look
<dholbach> ara_: let me know how it goes :)
<ara_> dholbach: are you sending me homework, teacher? ;-)
<dholbach> ara_: I'm really not into teacher games - my dad is a teacher and in the street where I grew up there were lots of teachers and lots of their kids became teachers too, I was really hoping to avoid the same fate :-)
<tjaalton> Keybuk: think I got it.. the rule has just %N in it, when it should probably be /dev/%k
<ara_> dholbach: don't worry; I have been always good at self-learning, Mr. ;-)
<tjaalton> Keybuk: but it still timeouts way too early
<tjaalton> the timeout seems to be around 20s
<tjaalton> when it took ~1min to probe the SAN
<tjaalton> Keybuk: ^^
<pitti> Good morning
<evand> morning
<Hobbsee> hey there pitti!
 * pitti hugs Hobbsee and evand
<Hobbsee> :)
<pitti> tjaalton: btw, I reviewed all Fedora hal patches yesterday, and there was just one tablet related which was relevant and still applied to git head
<pitti> tjaalton: feedback appreciated if it works the way you want now
<tjaalton> pitti: great, thanks
<tjaalton> ogra might want to test it now
<nijaba> dholbach: hello.  still no reply from soren, what do you think we should do regarding tonight?  I can prepare to do it alone, but may not have all the answers to questions
<dholbach> nijaba: is there anybody else from the server team who might help out?
<nijaba> dholbach: sincerely, most of the dev on vmbuilder was done by soren and I
<dholbach> nijaba: probably it'd make sense to collect all the questions you don't have answers for, promise answers and do a blog post about it later on
<dholbach> nijaba: blogging about vmbuilder would be a good thing anyway ;-)
<nijaba> dholbach: ok, sounds like a plan
<dholbach> rock on
<dholbach> nijaba: thanks a lot for taking care of it
<nijaba> dholbach: first time I prepare this type of thing.  I think it makes sense to prepare what you want to say in advance, right?
<nijaba> dholbach: so that just mostly do cut and paste during the session
<nijaba> (apart for Q&A)
<dholbach> nijaba: I usually do it ad-hoc, but I know that a lot of people prepare text in advance
<nijaba> dholbach: ok, thanks
<dholbach> I think it makes sense to prepare stuff, especially if it's complicated stuff
<nijaba> dholbach: preparing in general is not an option, agreed
<nijaba> dholbach: I just wanted to know best practice for actual pre made text
<dholbach> it's definitely fine to paste in stuff
<nijaba> dholbach: then I think that's what I'll start with. thanks
<dholbach> thanks Nick
<nijaba> np
<lool> Keybuk: There's this warning / error when upgrading dbus:
<lool>  * Reloading system message bus config...                                       Error org.freedesktop.DBus.Error.Failed: Element <syslog> not allowed inside <busconfig> in configuration file
<lool> Or any service doing a dbus reload actually
<Unggnu> hi all
<lool> Keybuk: My understanding is that the running daemon doesn't know about this new <syslog/> mechanism
<Unggnu> Is there a reason why the CD bootloader doesn't show the current Ubuntu version?
<Unggnu> I guess it would make sense. The release name would be fine too.
<cjwatson> Unggnu: no particular reason; file a bug against gfxboot-theme-ubuntu, please
<fabbione> Keybuk: is there a way to cope with this udev stuff without using Break: by any chance?
<Unggnu> cjwatson: thx
<fabbione> Keybuk: maybe a clever "postinst" that will create the rule file in the right place?
<fabbione> Keybuk: it makes it very hard to do backport of the cluster stack to a stable release for testing basically..
<andrew_sayers> Hi all, I'm thinking about how to get devs back into ubuntu-devel-discuss.
<andrew_sayers> Would there be any value in making a Thunderbird plugin that only showed messages that have been replied to with "+1"?
<seb128> not sure the people you try to bring back there use thunderbird ;-)
<seb128> and having +1 replies on lists doesn't seem something to encourage
<andrew_sayers> I don't know how to hack evolution, and it's easier to play around with ideas in Javascript than Procmail :)
<andrew_sayers> I disagree about the +1 thing - I for one am very aware about accusations of noise, but don't feel like a I have a good understanding of what constitutes signal vs. noise.
<seb128> why do you want to bring extra people to this list?
<seb128> what is the issue you are trying to solve?
<Hobbsee> seb128: because it's the list that users are pointed to to communicate with developers
<seb128> I for one read the list but I usually don't find discussion really interesting or worth replying that's why I don't post there
<Hobbsee> however, the S/N ratio has gotten so bad that most developers either a) never read it, or b) unsubscribe.
<BUGabundo> andrew_sayers: do you have any idea how many of them are left, compared to one year ago?
<seb128> Hobbsee: that's why we had the -discuss split no?
<andrew_sayers> BUGabundo: no, sorry.
<Hobbsee> seb128: precisely
<seb128> Hobbsee: you are trying to get a -discuss-discuss now?
<andrew_sayers> The thing is, I suspect there's going to be a constant chase unless we get some form of moderation.
<Unggnu> cjwatson: consider done Bug #319545
<ubottu> Launchpad bug 319545 in gfxboot-theme-ubuntu "ISO boot loader should show the Ubuntu version or relase name" [Undecided,New] https://launchpad.net/bugs/319545
<Hobbsee> seb128: I thought you were asking about the issue that he was trying to solve, and I thought I answered that...
<seb128> andrew_sayers: there is already a moderated list and there is -discuss
<andrew_sayers> There will always exist users that think they need a dev, but either don't, or don't know how to ask the question.
<andrew_sayers> seb128: Yes, and the moderated list is too restrictive, and the unmoderated list is not restrictive enough.
<seb128> get somebody to Cc the moderated list when a discussion is worth it rather than try to create a new moderation system there?
<Hobbsee> andrew_sayers: moderating that list too might be a good idea.  I don't think there's a charter for what should be on there, apart from "this is how users can contact developers by mailing list", which should probably change, too
<seb128> Hobbsee: you want to moderate that list and create a discuss-discuss not moderated next?
<Hobbsee> seb128: halfway there.  Ditch the rest of the traffic to the forums or brainstorm or something.
<Hobbsee> or just plain /dev/null it with an explanation.
<seb128> there is already a moderated list, what would be the point to have an another one?
<seb128> -discuss is for open discussion
<Hobbsee> because people can't be trusted to DTRT on the unmoderated one.  OTOH, if they actually *had* a charter for that list, perhaps that would improve.
<seb128> if something should be escalated get somebody to cc the other list?
<andrew_sayers> One problem with moderation is that it gives the wrong impression, like people aren't invited.
<seb128> Hobbsee: well, there is no DTRT there
<seb128> andrew_sayers: well, that's why -discuss is where people are pointed and it's not a moderated list
<seb128> I'm not sure what you consider the issue there
<andrew_sayers> Maybe I should have pointed that comment at Hobbsee :)
<cjwatson> Unggnu: thanks
<Hobbsee> andrew_sayers: i'd firstly start by finding out what the ideal charter is (as in, what kind of questions / mail should be there), and then getting it written up on the u-d-d list.
<Hobbsee> andrew_sayers: indeed.  Although, at the end of the day, they're (unfortunately) right.  Mail that doesn't make the 'cut' as signal mail, rather than noise, is effectively unwelcome, whether it's just ignored, or killed by moderation.
<andrew_sayers> Hobbsee: There's a philosophical issue between us here: you're suggesting a pre-hoc set of rules laid down based on logic, I'm suggesting a post-hoc set of rules set down by precedent.
<cjwatson> there is a charter for -devel-discuss
<seb128> andrew_sayers: it seems that what you are trying to do is to get busy people to read user issues when they don't want to read about those, that's not really a technical issue
<Hobbsee> cjwatson: beyond "this is the way for users to contact developers?"  I'll have to go check that
<andrew_sayers> Not really - also, I'd like to point out that one dev's signal is another dev's noise.
<cjwatson> but I agree with seb128; there is no point in repeatedly moderating previously unmoderated lists in succession, and creating further unmoderated lists as a result
<cjwatson> andrew_sayers: I think that's relatively rare actually
<cjwatson> Hobbsee: https://wiki.ubuntu.com/UbuntuDevelModeration
<cjwatson> or https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html is a better link
<cjwatson> that has the charters for -devel and -devel-discuss both
<Hobbsee> hrm, i thought that's what it said.
<cjwatson> andrew_sayers: if there is a problem with the -devel moderation being too strict, then maybe that problem would be easier to solve
<cjwatson> andrew_sayers: do you have specific examples of problems there?
<andrew_sayers> cjwatson: TBH, I don't subscribe to -devel, I'm put off by the moderation and general reputation of it.
<Hobbsee> andrew_sayers: not sure on your pre-hoc / post-hoc comment.  Where would you be planning to put the post-hoc set of rules?  How would they be implemented.
<cjwatson> general reputation?
<andrew_sayers> Hobbsee: Generally, precedent-based systems don't have a written set of rules, you just pick it up as you go along.  That said, I shouldn't be surprised if there ended up with a page on help.ubuntu.com.
<Hobbsee> andrew_sayers: right.  The only problem with that sort of situation is that it can be perceived to be biased, and i'm not sure how one goes about solvign that.
<cjwatson> andrew_sayers: I think it would be good to have the rules for the list better-known and more clearly-defined (if necessary); I don't think that requires moderation
<cjwatson> BTW, the information from the link earlier is at https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss too
<andrew_sayers> cjwatson: It's a developer list for people involved in the development of Ubuntu.  I have yet to make a direct contribution to the distro, so it would be kind of like interrupting a private party.
<emgent> james_w: ping
<cjwatson> andrew_sayers: that's the exact signal/noise thing we were addressing with the list split, though, and the major reason developers pay more attention to -devel than to -devel-discuss
<james_w> hi emgent
<emgent> james_w: good morning
<emgent> james_w: cane you explaine to me this ACK https://bugs.launchpad.net/ubuntu/+source/drupal6/+bug/317337 ?
<ubottu> Launchpad bug 317337 in drupal6 "Please sync drupal6 6.6-2 (universe) from Debian unstable (main)." [Wishlist,Confirmed]
<cjwatson> andrew_sayers: you can't make -devel-discuss magically attractive to developers to read unless you say that only people with the necessary background to form qualified opinions can post opinions :-)
<Hobbsee> Ideas and suggestions about future development of Ubuntu  <-- should probably be for brainstorm
<emgent> s/cane/can/
<andrew_sayers> Hobbsee: Good point, how about changing "+1" to "<ping devs>" or something that sounded less judgemental and more like signalling that devs should be interested.
<cjwatson> Hobbsee: not exclusively
<andrew_sayers> cjwatson: I disagree.  You do it by having people with said background flag up posts that devs would be interested in.
<Hobbsee> emgent: I think you're mistaking drupal6 with drupal5 there
<cjwatson> andrew_sayers: why wouldn't such people just move the thread to -devel?
<emgent> Hobbsee: the same problem..
<Hobbsee> cjwatson: so it should be in multiple places?  I wasn't aware of that, but OK
<cjwatson> much simpler than a complex flagging system (remember, please, that developers generally have a favourite mail client and are uninterested in changing)
<james_w> emgent: what's the issue with it?
<andrew_sayers> cjwatson: aside from the reasons I specified above, they would have to port the whole thread and act as a go-between.
<Hobbsee> emgent: then pull the debian version, and make additional changes after that.  There are no ubuntu changes on it currently.
<emgent> james_w: ubuntu use postfix in default not exim4
<cjwatson> Hobbsee: the correct place for ideas varies wildly - yes, we advertise brainstorm as the main place because that gives us de-duplication and voting and such, but that isn't to say that mailing lists are necessarily inappropriate (or even wishlist bugs)
<andrew_sayers> Actually, now I remember my other problem with subscribing to -devel.  If I can only post a reply when I get permission, but you can post one whenever you like, there's a disparity there that could be quite frustrating.
<Hobbsee> cjwatson: right.
<cjwatson> andrew_sayers: surely not, all that's necessary is to call the attention of developers to it
<cjwatson> andrew_sayers: yes, that's why cross-posting between -devel and -devel-discuss doesn't work
<Hobbsee> andrew_sayers: excluding the recent fiasco with the desktop screenshots, the u-d list gets moderated pretty quickly, most of the time.
<emgent> james_w: can you invalidate bug please ?
<james_w> emgent: yes, but we haven't patched every package, and that's not something that has changed in Debian, so we're not making the situation any worse by syncing that package
<andrew_sayers> cjwatson: I agree about calling dev's attention, I just disagree about the best mechanism.
<emgent> james_w: last drupal version use postifx and IMHO is good to continue this road
<emgent> ubuntu decided a standard road with postifx
<emgent> so.. why ack wrong sync ?
<Hobbsee> emgent: then why not fix the bug, and mark the syncs invalid?
<andrew_sayers> There is an evidential issue here.  I'm assuming there's a significant number of people that don't know what signal would look like, or do but don't want to take issues to -devel for other reasons...
<james_w> emgent: no it didn't: http://packages.ubuntu.com/jaunty/drupal6
<cjwatson> andrew_sayers: nothing that depends on a specific mail client will be viable
<andrew_sayers> Would a questionnaire sent to both lists work at all?
<Hobbsee> emgent: iirc this was discussed a few weeks ago when I was looking at the queue.  But no one's actually done anything about it.
<andrew_sayers> cjwatson: which client(s) do most devs use?
<cjwatson> varies
<emgent> Hobbsee: ya correct, i mean explaine the problem to bhavani shankar and tel him to make the correct merge
<Hobbsee> emgent: where is this policy actually documented.
<Hobbsee> s/./?/
<cjwatson> you can grep User-Agent headers if you want statistical information; my point is not that you should be hacking on some different client, but that developers use a wide variety of clients and simply hacking one of them is unlikely to be useful. (Also I think the mail client is completely the wrong layer for this anyway.)
<emgent> dont remember now, i'm not at home.. but anyway there are a doc in wiki if i remember well
<Hobbsee> hrm.  brainstorm got updated.
<emgent> and anyway the problem is that drupal is used by loco and more people (see popcon), and it`s creazy change the mailbox deps
<emgent> *mailserver*
<Hobbsee> emgent: then why wasn't it done months ago?
<james_w> emgent: but the drupal6 in the archive won't change
<cjwatson> last 1000 User-Agent headers in -devel have alpine, gnus, icedove, IMP, kmail, mutt, pan, squirrelmail, thunderbird
<emgent> Hobbsee: someone acked it.. and someone uploaded sync..
<emgent> but IMHO it's a big error.
<andrew_sayers> cjwatson: Looking on the bright side, that's only one web-based client.
<Hobbsee> emgent: then make your changes, rather than complaining about it?
<cjwatson> andrew_sayers: I repeat, hacking the mail client won't work
<cjwatson> andrew_sayers: perhaps the right answer here is that people reading -devel-discuss who're qualified to say "developers should be paying attention to this" (with good s/n ratio) should also be qualified to file a well-documented bug that will sail through bug triage
<andrew_sayers> cjwatson: I don't see how that helps... do you mean something like, if I write 10 good bug reports, I'm allowed to start CCing things to -devel?
<cjwatson> huh? no, that's not what I mean
<cjwatson> filing a well-documented bug is a way to bring something to the attention of developers
<cjwatson> and surely that's the right way to deal with many things on -devel-discuss
<andrew_sayers> Ah right.  Many interesting points don't fit neatly into a bug report though.
<andrew_sayers> For example, that thing a while back about bugs not getting fixed... it started out as just another flame, then turned into an interesting procedural discussion.
<emgent> Hobbsee: correct, i'm olny asking..
<emgent> errare humanum est
<emgent> s/olny/only/
<emgent> james_w: correct? :)
 * Hobbsee personally doesn't see the rationale for "this sync is not correct, as it did not follow a piece of documentation somewhere on the wiki, which may, or may not be policy, so the person should be told off", but whatever ;)
<james_w> emgent: I'm happy for you to do whatever you want, I don't see why you needed to come to me with it.
<james_w> emgent: it didn't change in the sync, and I'm not going to start reviewing the entire package to ACK a sync request.
<cjwatson> andrew_sayers: if more things were dealt with that way, then the volume of -devel-discuss could be expected to drop somewhat, making it more appealing to developers to read
<james_w> emgent: no-one filed a bug on the issue, no-one fixed the package that is currently in the archive, and it would have been really easy to upload a fix for this after the sync was done.
<andrew_sayers> cjwatson: What are your thoughts about a questionnaire?  I've got the time at the minute to put the work into one, and it would help clear up all our assumptions.
<emgent> james_w: i only asked why, because for me it`s an error.. dont worry
<andrew_sayers> E.g. to what degree this is a problem of education, reputation, ease-of-use, etc.
<cjwatson> andrew_sayers: I'm not sure I have any thoughts on a questionnaire
<Hobbsee> fwiw, there don't seem to be many bugs on that list now.
<cjwatson> except for "please make sure replies don't go to the list" ;-)
<james_w> emgent: I make lots of mistakes, but you will have a hard time selling this one as an error to me though. Thanks for catching the issue and doing something about it though.
<Hobbsee> it's more random discussion about stuff in ubuntu, and new things
<andrew_sayers> Hobbsee: you're referring to -devel-discuss there?
<Hobbsee> or at least, that's what my looking at the archives tell me.
<cjwatson> andrew_sayers: speaking only for myself, I find that having other people draw my attention to things they think I should be reading doesn't work very well
<Hobbsee> andrew_sayers: yes
<cjwatson> andrew_sayers: they draw my attention to lots of noise, and dismiss the things I would actually have really wanted to fix with "oh, it's meant to be like that"
<cjwatson> (or similar)
<emgent> james_w: me too. ;)
<andrew_sayers> cjwatson: true.  I think everyone that's ever written a program has experienced that :)
<andrew_sayers> cjwatson: Where do you get your best tips then?
<cjwatson> andrew_sayers: I cannot give you a single answer to that
<cjwatson> andrew_sayers: bug reports, IRC, mailing lists that are low enough s/n to be worth reading, people phoning me up in a blind panic about stuff :-)
<andrew_sayers> cjwatson: Fair enough.  Last question then - If I subscribed to -devel and posted a questionnaire (to compare the results with -devel-discuss), would I get booed off stage?
<elmo> I can vouch for that last one
<cjwatson> andrew_sayers: busy people tend to be extremely reluctant to participate in what they see as "market research"
<cjwatson> andrew_sayers: if you wanted to figure out which of the respondents are developers, I would recommend doing that by looking at the membership of the ubuntu-core-dev and ubuntu-dev teams in LP
<cjwatson> it may well not be statistically significant, of course
<andrew_sayers> And if mailman will give me a list of subscribers, I can at least come up with some rough numbers about the number of devs still on -devel-discuss.
<andrew_sayers> Hmm, it won't.  Is there someone I could ask to check the correlation between -devel, -devel-discuss, and those teams?  A couple of numbers wouldn't take much time or violate any privacy.
<james_w> emgent: as a bonus I just fixed the other two packages in the archive that still preferred exim
<emgent> james_w: thanks for this
<james_w> and at the same time making a mistake :-)
<emgent> james_w: heheh :-)
<directhex> ta seb128
<james_w> does the script used to sync pick up the requested version from the bug, or does it take the latest in the requested <that word for unstable,experimental etc. that I've forgotten>
<cjwatson> the latest
<Keybuk> lool: correct, just ignore it
<cjwatson> if you want a specific version, flag it in the subject line
<seb128> directhex: you're welcome
<directhex> seb128, now only 3 apps (libs is a distinct topic) in ubuntu haven't been transitioned as part of the mono 2.0 transition. one's waiting on a lib in debian NEW, one's waiting on a new mono package.
<seb128> directhex: ok
<tkamppeter> keybuk, hi
<Keybuk> hi
<tkamppeter> Keybuk, it is about bug 318262, you have moved it to HPLIP without giving any comment.
<ubottu> Launchpad bug 318262 in hplip "/dev/bus/usb/*/* files (device nodes for libusb) of printers must be readble and writable for user "lp"" [High,New] https://launchpad.net/bugs/318262
<Keybuk> that's because I just did an upload
<Keybuk> has to be on hplip for lp to close it
<tkamppeter> What did you upload?
<Keybuk> hplip, obviously
<tkamppeter> Keybuk, you uploaded it only some minutes ago?
<Keybuk> yes
<tkamppeter> This second it came through. Thanks.
<Keybuk> that rule should be suitable for upstream
<Keybuk> and eventually for inclusion in udev-extras
<tkamppeter> Keybuk, as soon as LP has generated the debdiff I will apply it to the Debian BZR, as we are managing the package there.
<tkamppeter> Keybuk, you mean HPLIP upstream or UDEV upstream?
<Keybuk> HPLIP upstream at first
<Keybuk> but a little later on, udev-extras upstream
<Keybuk> (which is where we think such "device catalogue" rules will go)
<tkamppeter> Keybuk, is there a way to generally make /dev/bus/usb/*/* accessible for "lp" if the device is a printer? Or do we need a list of each and every printer to do this?
<tkamppeter> Keybuk, the problem is that soon CUPS 1.4 will get released and its USB backend is libusb-based.
<Keybuk> how do you know whether or not the device is a printer?
<Keybuk> it's not as if USB has any kind of class information :-/
<Keybuk> (well, not one that anyone bothers with anyway)
<Laney> Why did I get both rejected and accepted mails for all of my syncs that were processed today?
<Laney> "The source audit - 1.7.11-1 is already accepted in ubuntu/jaunty and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload"
<seb128> Laney: not sure, I did the syncs the normal way and they seemed to have been synced correctly
<directhex> yeah, happened to me too
<directhex> didn't wanna bring it up in case i seemed ungrateful
<Laney> :O
<Laney> I was just raising it incase something went wrong
<Laney> seems to have appeared fine though
<tkamppeter> Keybuk, somehow the Kernel's usblp module can also detect (and very reliably) whether a USB device is a printer. AFAIK it checks for USB interface class 7 and subclass 1. I use this method also in /usr/share/hal/fdi/policy/10osvendor/10-hal_lpadmin.fdi for the hal-cups-utils. They auto-setup a printer even if the usblp module is not available.
<Keybuk> yes, BUT
<Keybuk> the usblp module is a driver that operates on USB *interfaces*
<Keybuk> USB interfaces to indeed have a class as you describe
<Keybuk> and the interface is exposed as /dev/usblpN
<Keybuk> you're telling me that CUPS plans not to use USB interfaces at all
<Keybuk> but access the USB device in a raw fashion through the raw device access node /dev/bus/usb/XXX/YYY
<Keybuk> since that raw device is *one* per USB device, the interface class does not apply
<Keybuk> indeed, since it's a raw device, there's no requirement for you to even acknowledge the usb interface specification
<Keybuk> if you access the device in a raw fashion, it's up to you to figure out whether it's a printer or not
<tkamppeter> So one has to look into the CUPS 1.4 sopurce code to see what the new backend actually does.
<tkamppeter> Keybuk, I assume that it polls the IEEE-1284 device ID. If the USB backend does not succeed it is not a printer or so.
<tkamppeter> Keybuk, could UDEV do such things or would we need HAL then.
<Keybuk> HAL is going away
<tkamppeter> HAL is going obsolete? What will replace it?
<asac> james_w: http://paste.ubuntu.com/107768/ ... bzr-builddeb version confusion?
<Keybuk> udev and DeviceKit
<ogra> devicekit
<asac> james_w: nevermind
<asac> ;)
<tkamppeter> Things change quickly, nothing seems to live for more than 2 years, I am wondering why we are still working with CUPS, Foomatic, and Ghostscript.
<Keybuk> same reason that scanner stuff stays in a largely broken state
<Keybuk> geeks don't use paper :p
<ion_> :-)
 * pitti hugs his ebook reader
 * directhex rolls up an ebook & beats Keybuk with it
<asac> doko_: jflex was now promoted. do you have the comments lool made on your radar still?
<Keybuk> directhex: don't forget to call me "bitch"
<tseliot> lol
<directhex> ooo err
<asac> doko_: ok created a follow-up bug for the comments and targetted it for jaunty beta (319607) so it doesnt slip through. Thanks.
<Keybuk> cjwatson: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commit;h=5f03ed8a56d308af72db8a48ab66ed68667af2c6
<Keybuk> this should solve the installer case ;)
<cjwatson> Keybuk: perfect, thanks
<cjwatson> when is resolve_names == 0?
<Keybuk> cjwatson: see the next patch ;)
<Keybuk> libudev supports ==0 to mean "resolve names for each event"
<Keybuk> so I added --resolve-names=late as well
<Keybuk> but did that separately in case Kay decided that he wanted to drop the support for the other
 * cjwatson nods
<Keybuk> glatzor: watch out for future packagekit releases
<Keybuk> it's possible that hughsie may port to the new policykit
<glatzor> Keybuk, Thanks for notifying. Which new policykit? I plan to to stick at 0.3.x in jaunty.
<mrvanes> anyone any idea why the last hal update segfaults on my personal built 2.6.28.1 kernel and not on jaunty's default?
<Keybuk> glatzor: davidkit released 0.90 pre today
<glatzor> Keybuk, the later release of Fedora already lead to some late feature additions in previous cycles.
<tjaalton> hrm, sounds seems busted.. alsamixer can't find libasound_module_conf_pulse.so
<Keybuk> cjwatson: got a moment to be a teddybear?
<cjwatson> Keybuk: teddybear? (I have to go out now to take B to his cello lesson, back for the meeting ...)
<unstable> Is there a rough feature list for Jaunty somewhere?
<Keybuk> need to bounce an idea off someone, and in the process of telling that person about it, work out the solution for myself ;)
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 to kick off in #ubuntu-classroom in 23 minutes! :-)
<mvo> go dholbach go
 * mvo cheers
<dholbach> mvo: no... seb128 go! :)
<mvo> no seb128 here .)
<mvo> he ran away!
<dholbach> he's up first in 17 minutes
<Keybuk> \o/ I now have iPhone reminders for my work calendar
<calc> tjaalton: no
<Keybuk> tkamppeter: err, why did you change the priority of the hplip rules?
<Keybuk> package rules should be 40, see /lib/udev/rules.d/README
<tkamppeter> Keybuk, I have overtaken it from upstream, the original rules file had 55.
<Keybuk> right, but 55 is wrong ;)
<tkamppeter> Keybuk, does 40-xx not say 40 and higher?
<Keybuk> no
<Keybuk> 40-xx means 40
<tkamppeter> Keynuk and rules coming with packages seem to be all < 60 in this file.
<Keybuk> basically 40 for everything unless you have a good reason not to
<tkamppeter> Keybuk, the last line of the hplip.udev file has a RUN+="<some little shell script for scanner setup>". Is it still 40 then or is it now 85 due to running a program?
<Keybuk> you're reading the old REAMDE
<Keybuk> the current one has no clause about running programs needing to happen later
<Keybuk> unless you need information from the udev db
<Keybuk> your file seems pretty self-contained, so it can basically go anywhere
<Keybuk> thus 40 ;)
<Keybuk> btw, can I just point out that the RUN rule won't work anyway ;)
<Keybuk> so it's kinda irrelevant
<tkamppeter> Keybuk why does RUN not work? Deprecated? How to replace it?
<Keybuk> tkamppeter: read your rule
<Keybuk> what does it do?
<ion_> keybuk: Want to bounce the idea off me? :-)
<Keybuk> tkamppeter: shall I just tell you ? :p
<Keybuk> the filesystem is read-only when udev runs
<Keybuk> you can't edit config files <g>
<Keybuk> and why isn't that support just built-in to sane-backends in the first place ?!
<ogra> Keybuk, ugh, no more RUN ? ltspfs kinda relies on that
<cjwatson> ogra: does it edit files from a RUN rule?
<tkamppeter> Keybuk, when it identifies the device as an HP printer it owner, group, mode and in addition the sane_hpaio env var. And if this var is set, it edits /etc/sane.d/dll.conf and this it actually did for me.
<Keybuk> tkamppeter: won't work on boot
<Keybuk> also *PLEASE* do NOT set OWNER
<Keybuk> really, don't
<Keybuk> that's reserved for other rules, just set GROUP
<tkamppeter> Keybuk, I have simply taken it from upstream, so that we need not to maintain our own. Setting OWNER upstream has really overdone it as GROUP is enough with the permissions they give.
<Keybuk> then upstream is wrong
<Keybuk> we can patch it in Ubuntu
<Keybuk> bug #319660
<ubottu> Launchpad bug 319660 in hplip "Cannot edit configuration from udev rules" [Undecided,New] https://launchpad.net/bugs/319660
<Keybuk> bug #319661
<ubottu> Launchpad bug 319661 in hplip "Must not set OWNER in udev rules" [High,New] https://launchpad.net/bugs/319661
<Keybuk> bug #319662
<ubottu> Launchpad bug 319662 in hplip "udev rules should be 40-*.rules unless there's a good reason" [High,New] https://launchpad.net/bugs/319662
<Keybuk> tkamppeter: assigned them to you
<ogra> cjwatson, it runs scripts that create files
<Keybuk> note that Ubuntu's udev is completely pristine
<Keybuk> we have no patches to upstream udev
<Keybuk> and we only ship the upstream udev rules
<Keybuk> without modification
<Keybuk> therefore your upstream is also wrong, they should match the default udev upstream
<tkamppeter> The Ubuntu package of HPLIP ships a /etc/sane.d/dll.d/hplip which makes sane-backends using hpaio, so if the UDEV rule does not work is no problem.
<Keybuk> not the strange configuration of other distributions
<Keybuk> tkamppeter: then please drop the RUN rule
<Keybuk> tkamppeter: oh, I have yet more bugs
<Keybuk> you use SYSFS{...}
<Keybuk> that should be ATTR{...}
<Keybuk> bug #319665
<ubottu> Launchpad bug 319665 in hplip "Uses deprecated SYSFS instead of ATTR" [Undecided,New] https://launchpad.net/bugs/319665
<tkamppeter> As it seems that HPLIP's UDEV file breaks all and everything with current Ubuntu (and probably all other distros which use current UDEV), the best is if you send me your file again, I only merge in the new device numbers and I propose it to upstream. Simply attach it to your bug report.
<tkamppeter> Keybuk, I will add an upstream task then and ask them to use the new UDEV rules file.
<Keybuk> tkamppeter: if you hadn't had deleted the file I uploaded, you wouldn't need to
<Keybuk> I'm sure you can retrieve it from Launchpad
<Keybuk> old source packages and builds are made available from there
<Keybuk> you probably even have the .dsc and .diff.gz in your working directory
<tkamppeter> Keybuk, sorry, I simply followed the policy of taking as much as possible from upstream ...
<Keybuk> since assumedly you downloaded it, then deleted the correct file out of it to replace it with your incorrect one
<Keybuk> we don't have a policy
<Keybuk> we have a policy of fixing upstream of course
<Keybuk> cjwatson: so, have an interesting issue
<Keybuk> during upgrade of udev, it's probably wise to stop it and start it again after
<Keybuk> but because it's an rcS.d script, the start and stop have other side-effects
<Keybuk> is adding a start-daemon and stop-daemon option valid?
<cjwatson> you've always said that you couldn't really stop/start udev, I thought
<Keybuk> well, you can't really
<Keybuk> but there's an interesting bug with this particular upgrade
<Keybuk> if you cause udevadm trigger to be run, all of your device nodes will lose permissions
<Keybuk> now, I'd say it's a bug that anything is doing udevadm trigger at all
<Keybuk> but mdz disagrees, and says udev shouldn't fail so badly
<cjwatson> perhaps it would be wiser to have a restart-daemon option, to avoid encouraging people to leave udev stopped?
<tkamppeter> Keybuk, are the first three lines of the original UDEV rules also broken/deprecated:
<tkamppeter> ACTION!="add", GOTO="hpmud_rules_end"
<tkamppeter> #SUBSYSTEM=="ppdev", OWNER="lp", GROUP="lp", MODE="0660"
<tkamppeter> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GOTO="pid_test"
<tkamppeter> SUBSYSTEM!="usb_device", GOTO="hpmud_rules_end"
<cjwatson> well, /etc/init.d/udev restart calls udevadm trigger :-)
<mdz> Keybuk: that's not true, I didn't express an opinion either way about whether it was a bug that udevadm trigger was being run
<Keybuk> cjwatson: yes
<cjwatson> Keybuk: in general it's certainly valid to add extra custom options to init scripts beyond the standard set
<cjwatson> and often useful
<mdz> I did say that the system probably shouldn't melt down in this case though
<Keybuk> mdz: the only way to make it not melt down is to stop/start the udev daemon
<Keybuk> which will cause other bugs
<Keybuk> personally I still think we should find out what caused the melt down
<cjwatson> I wonder why udevadm/udevd don't have some kind of versioning in the protocol they use to talk to each other
<Keybuk> cjwatson: they do?
<cjwatson> then why can't you just bump the version and make udevadm refuse to do anything if talking to an older udevd?
<Keybuk> because udevadm never knows what udevd it's talking to
<Keybuk> udevd knows what version of udevadm it is
<Keybuk> but that'd involve patching the udevd already running ;)
<cjwatson> it wouldn't
<cjwatson> let me explain
<cjwatson> if udevd is talking the old protocol, udevadm can carry on and behave as before
<Keybuk> "talking" ?
<Keybuk> I think you're assuming some kind of full-duplex protocol here <g>
<cjwatson> oh
<cjwatson> hm, ok, that's unfortunate
<Keybuk> it's just a single message sent from udevadm -> udevd
<Keybuk> what happened in mdz's case is that the old udevd was still running
<cjwatson> you could change the message to one that an older udevd will ignore
<Keybuk> and had noted that it's configuration had all gone away
<Keybuk> that's ok in of itself
<cjwatson> TRIGGER_2 rather than TRIGGER
<Keybuk> cjwatson: I can't imagine Kay would accept that patch
<Keybuk> actually
<Keybuk> I'm being silly
<Keybuk> there's no udevadm->udevd contact at *all* in this case
<Keybuk> udevadm trigger doesn't contact udevd
<Keybuk> it walks sysfs and pokes the kernel uevent node
<Keybuk> the problem is that trigger causes the running udev (the old one, with no configuration) to rebuild /dev
<Keybuk> since it has no config, it just reverts the whole thing to root:root/660
<tkamppeter> Keybuk, is 'ACTION!="add"' and 'SUBSYSTEM!="usb_device"' also deprecated?
<Keybuk> tkamppeter: no recent kernel has a usb_device subsystem
<Keybuk> cjwatson: of course, now I think about it - the traditional stop in preinst start in postinst won't work either - the installed udev package wouldn't stop
<cjwatson> there are two traditions here :)
<ogra> so is RUN deprecated ?
<ogra> (sorry, had network probs)
<Keybuk> ogra: only for you ;-)
<tkamppeter> Keybuk, as I want to find a rules set which is best compromise between upstream
<ogra> Keybuk, :P
<cjwatson> for daemons you don't want to be stopped for very long (and udevd is definitely one such), it's usual to do restart in postinst
<Keybuk> tkamppeter: the rules I uploaded are the best ones to be shipped upstream
<cjwatson> ogra: Keybuk never said that - he said that you couldn't write to files from a RUN rule
<Keybuk> tkamppeter: since they match udev upstream
<ogra> cjwatson, ah, then i misunderstood
<Keybuk> cjwatson: my concern about the restart in postinst is that it's likely after whatever problem mdz had anyway
<tkamppeter> Upstream supports "Linux kernel 2.4.19 and above (2.6.x recommended)." Am I safe dropping usb_device subsystem support then.
<Keybuk> tkamppeter: udev doesn't support 2.4.x :p
<cjwatson> Keybuk: I don't suppose there's any way to tell what version of udevd is running?
<Keybuk> cjwatson: no
<tkamppeter> And 2.6.x dropped usb_device entirely already from the beginning?
<Keybuk> no
<Keybuk> 2.4 doesn't even have /sys
<cjwatson> Keybuk: you could divert udevadm in preinst, replace it with /bin/true, and put udevadm back in the postinst
<cjwatson> after restarting the daemon
<cjwatson> you may vomit now
<Keybuk> cjwatson: I _like_ that idea ;)
<cjwatson> it's actually sort of elegant in a twisted kind of way
<cjwatson> and would cope with all the packages that probably try to use udev while it's unconfigured
<Keybuk> indeed
<cjwatson> you might want to replace it with something a little bit more sophisticated than /bin/true, of course
<Keybuk> surely you'd want packages that were trying it on to fail anyway?
<cjwatson> it would be nice if it still passed through info
<cjwatson> I'm not sure - but you get the general idea I think
<cjwatson> I expect that a number of packages are avoiding dependencies on udev for one reason or another
<cjwatson> (mostly bogus in Ubuntu)
<cjwatson> there is a wider problem here
<Keybuk> wider problem?
<cjwatson> lots of packages have conditional-use idioms in their maintainer scripts - i.e. "use this feature if it is present"
<cjwatson> there is no way to check "use this feature if it is present and the corresponding package is configured"
<cjwatson> the lack of this has caused a number of really rather fun upgrade problems of late, particularly around perl, but also elsewhere
<cjwatson> by diverting udevadm, you'd be simulating this feature by force :)
<tkamppeter> keybuk, I have attached an udev rules file to propose to upstream to bug 319660, WDYT, is it OK?
<ubottu> Launchpad bug 319660 in hplip "Cannot edit configuration from udev rules" [High,New] https://launchpad.net/bugs/319660
<tkamppeter> keybuk, I hope this works with all 2.6.x kernels, has nothing deprecated concerning UDEV and also not rules which are not working on boot.
<Keybuk> tkamppeter: nothing works with all 2.6.x kernels and the current udev
<Keybuk> udev's compatibility is based on, for lack of a better word, epochs
<tkamppeter> So udev rules always need to be made individually for each release of a distro?
<Keybuk> the latest version of udev is compatible with the latest kernel release, and previous kernel releases for a given time period
<frandieguez> hi to all
<Keybuk> that time period is pretty much deliberately chosen based on the release cycles of distributions
<TheMuso> tjaalton: can confirm the alsamixer bug, working on it now.
<frandieguez> I've generating a custom live cd with uck
<frandieguez> but I need to put a link into all the desktop users
<frandieguez> put it into /etc/skel is the only way?
<frandieguez> thanks after all
<Keybuk> you can't even *compile* udev with kernels older than a year or two
<Keybuk> the current minimum version of kernel it supports at all is 2.6.22
<jdstrand> kirkland, nijaba: so I just installed screen-profiles 1.12-0ubuntu1, and for giggles had it add /usr/bin/screen-launcher to .bashrc. Interesting side-effect: I open a gnome-terminal and do some stuff. I open another gnome-terminal and I an attached to the same screen session and when I type in one terminal, it shows up in both
<tkamppeter> Keybuk, so it seems to be better then that if we upstreamize these UDEV rules that we should do it in udev-extra and not in HPLIP?
<Keybuk> tkamppeter: that's the long-term plan
<jdstrand> kirkland, nijaba: that is intended?
<kirkland> jdstrand: yes, by design
<Keybuk> at least for that kind of rule
<kirkland> jdstrand: F6 to detach
<nijaba> jdstrand: yes, I find it very usefull
<jdstrand> kirkland: but F6 takes me out of screen entirely
<Keybuk> tkamppeter: perhaps a better way to put it
<kirkland> jdstrand: you can add/remove it independently from your .bashrc or .bash_profile
<Keybuk> "udev doesn't care about backports"
<jdstrand> kirkland, nijaba: I can see the utility, it was just quite surprising
<Keybuk> personally, if I maintained hplip upstream, I'd just state that you need a recent kernel and recent udev for it to work
<tkamppeter> HPLIP tries to make everything so that it works with the maximum possible amount of distros, therefore probably these UDEV rules. which work on Jaunty but can break on Jaunty+1 due to deprecated stuff in there.
<Keybuk> and wouldn't bother supporting 2.6 releases older than a year or two, let alone 2.4!
<kirkland> jdstrand: i think that's the effect of adding it into .bashrc
 * nijaba loves surprising jdstrand :)
<kirkland> jdstrand: i think it's the .bash_profile bit that does it on login
<nijaba> kirkland: no, the -Xrr does it
<jdstrand> kirkland: oh it certainly was-- it didn't do that before the change to .bashrc
<kirkland> jdstrand: anyway, open a bug, if you like, and we can separate that functionality in the profiles-helper, to allow for adding to both, none, one, or the other
<tkamppeter> Keybuk, so perhaps I simply put our UDEV rules into the package for now and do not upstream them to HPLIP. Feel free to upstream them to udev-extra.
<Keybuk> actually
<Keybuk> now I think about it
<Keybuk> udev doesn't even work on ARM ;)
<jdstrand> (well, screen-launcher did it-- whatever screen-launcher behind the 'screens' I don't know :)
<kirkland> Keybuk: can we discuss encrypted swap at the Berlin sprint?  I'm curious if/how that's going
<Keybuk> I should probably mention that at some point
<ogra> Keybuk, ?
<Keybuk> ogra: oh, hai
<ogra> Keybuk, what does make you think udev doesnt work on arm
<ogra> works just fine
<Keybuk> ogra: ARM doesn't implement pselect() or ppoll()
<Keybuk> it's possible to deadlock due to a race condition in the libc wrapper
<ogra> well, the deamon runs and i have devices that are not statically there
<kirkland> jdstrand: i've changed my work model a little bit
<Keybuk> sure, but every now and then, probably only whenever a CEO of an important client tests it, you'll end up with a wedged udevd and not much in /dev
<ogra> so to some extend it works
<Keybuk> and probably a hung boot
<kirkland> jdstrand: i now have one gnome-terminal tab per host I ssh to
<ogra> and i dont see any segfaults or anything
<Keybuk> (you'll hit exactly a similar bug with Upstart)
<Keybuk> oh, it won't segfault
<Keybuk> it'll just hang
<kirkland> jdstrand: and within each gnome-terminal tab (a single host), i'm running a screen session with multiple tabs on that host
<Keybuk> sitting in select()/poll() waiting for a signal that'll never happen
<ogra> strange, i havent had any probs since i started with arm
<Keybuk> there's probably lots of programs that'll experience the same bug, really
<Keybuk> ogra: you know about pselect() etc. right?
<Keybuk> why they exist?
<jdstrand> kirkland: that certainly seems sane
<jdstrand> lord knows my 9 open terminals isn't...
<kirkland> jdstrand: :-0
<kirkland> jdstrand: it adds a key stroke ....
<Keybuk> put simply, you have children and you want to break out of select() when a child dies so you can reap it
<ogra> Keybuk, well, reading/writing to fds
<Keybuk> you might write code like this
<kirkland> jdstrand: when i want to ssh somewhere, i'm now doing, ctrl-shift-t then F6
<Keybuk>   sigprocmask (SIG_UNBLOCK, &set, NULL);
<Keybuk>   select (...);
<Keybuk>   sigprocmask (SIG_BLOCK, &set, NULL);
<Keybuk> where set includes SIGCHLD
<cjwatson> Keybuk: does udev not use the standard self-pipe workaround?
<jdstrand> kirkland: ctrl-shift-t is to open a new tab in gnome-terminal, right? (meaning-- you didn't override that in screen did you?)
<kirkland> jdstrand: righto
<Keybuk> cjwatson: no, it deliberately uses ppoll() because the standard self-pipe workaround has another bug when you fill the pipe up ;)
<jdstrand> (I do use tabs as well, but often I like to see stuff at the same time)
<Keybuk> ogra: the problem with the above code is that it's racey
<cjwatson> hmm, I suppose that does actually happen in udevd with the number of processes it spawns
<ogra> Keybuk, but really, i havent seen any probs with udev yet on the five different boards i have here
<Keybuk> ogra: if the SIGCHLD occurs after sigprocmask but before the select(), you will never terminate the select() due to SIGCHLD
<ogra> right
<Keybuk> so pselect() was invented, that atomically changes the signal mask around a select()
<Keybuk> but ARM doesn't implement it
<Keybuk> so any program using pselect() or ppoll() is susceptible to the same race condition
<Keybuk> pgraner: it would be nice if the kernel could implement those syscalls on ARM ;-)
<ogra> ogra@******:~/linux-omap-2.6-old$ grep -R pselect *|grep arm
<ogra> arch/arm/include/asm/unistd.h:					/* 335 for pselect6 */
<ogra> hmm
<jdstrand> kirkland, nijaba: actually, I'm not entirely sure I do see the utility of this feature. can you explain a use case (the shared screens between to separate gnome-terminals)
<Keybuk> kirkland: encrypted swap?  I've not seen anybody working on that
<kirkland> jdstrand: hmm, so you think the .bash_profile entry would be sufficient?
<kirkland> Keybuk: uh-oh...  then this has slipped through the cracks
<Keybuk> kirkland: who is the assignee?  I thought you were :p
<Keybuk> you were the only person at UDS who was interested in it that I noticed
<TheMuso> tjaalton: Hrm after a restart, it works for me now.
<kirkland> Keybuk: hmm, rick has shifted me off of ecryptfs stuff
<jdstrand> kirkland: well, you would then still have the same behavior as soon as someone checked 'Run command as login shell', no?
<kirkland> Keybuk: anyone using encrypted-home will absolutely need encrypted-swap, for their solution to be at all secure
<Keybuk> kirkland: the spec is assigned to you, and you are drafter
<kirkland> Keybuk: in that scenario, all of their supposedly encrypted data will live in memory in the clear
<Keybuk> but no spec has been drafted
<jdstrand> kirkland, nijaba: keep in mind, I'm not saying it isn't useful, I just don't know how it is :)
<kirkland> Keybuk: fark...  it didn't get reassigned
<Keybuk> I maintain my basic objection to the idea
<kirkland> Keybuk: i'll raise this with rick immediately, ask how to proceed
<kirkland> Keybuk: breaking hibernate?
<Keybuk> it's not possible to encrypt swap in the multi-user machine case
<nijaba> jdstrand: I have mutiple virtual desktop (web/email/chat/dev/office/calendar).  I keep terminal open in a few of them to follow stuff, copy and paste etc.  I like to be able to see the same stuff than in my other virt desktops
<jdstrand> nijaba: couldn't that be achieved with a sticky window?
<nijaba> jdstrand: the *some of them* part would not
<jdstrand> (aka 'Always on visible workspace')
<liw> if you're worried about encrypting swap, why not use the whole-disk encryption things that already work well?
<jdstrand> nijaba: true enough
<jdstrand> kirkland, nijaba: fyi, bug #319691
<nijaba> liw: would work only if swap is stored in files, not in its own partition, which would not be encrypted, IIUC
<ubottu> Launchpad bug 319691 in screen-profiles "unexpected behavior when screen-launcher is in .bashrc" [Undecided,New] https://launchpad.net/bugs/319691
<pitti> tseliot: where is the new version of dontzap?
<nijaba> jdstrand: in the reverse, do you really open multiple terminal to the same host, or would you open multiple windows in screen?
<jdstrand> nijaba: I do everything, but I'm nuts
<nijaba> jdstrand: aren't we all?
<jdstrand> heh
<jdstrand> nijaba: if I ssh into another host, 9 times out of 10, it will be in a separate gnome-terminal
<liw> nijaba, my swap seems to be in a partition (or lvm volume), and encrypted
<nijaba> jdstrand: yes, I do the same, but I have different profiles in gnome terminal that opens to diffrent hosts
<jdstrand> nijaba: beyond that, it is highly dependent on what I am doing (ie, do I need to see two terminals at once)
<nijaba> jdstrand: I have learned to color code my window to different host, to avoid shuting down the wrong one :)
<pitti> tseliot: oh, Vcs-Bzr:, nevermind
<liw> nijaba, with the standard encrypted-lvm setup Ubuntu already supports, that is
<jdstrand> nijaba: I use different colored prompts...
<tseliot> pitti: right ;)
<pitti> bzr FTW
<nijaba> jdstrand: yep, I do too, but in that case, I open to terms, both using the same screen env, but focusing on different screen windows
<liw> (of course, anyone really caring about their security and privacy, doesn't do anything sensitive on a multiuser machine ;-)
<ion_> nijaba: apt-get install molly-guard
<jdstrand> nijaba: but I'm in no way suggesting that screen-profiles be adjusted to my workflow, only questioning if the current setup is a good default
<nijaba> jdstrand: ttytt, I have no idea, that's why I like discussing it :)
<tkamppeter> Keybuk, fixed HPLIP is uploaded. All is tested with therre HP printers and it works.
<tkamppeter> s/therre/three/
<nijaba> ion_: thanks, quite a usefull addition to make to my "standard package list"
<nijaba> liw: huh, you're right, I just started a vm with this setup, and the swap is in lvm, indeed.  Thought it was external...
<asomething> ScottK: hi, you closed bug 275375, but I don't see the package in jaunty-changes, the archives, or the build queue. how do you know that a sync has been done?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/275375/+text)
<asomething> bug 275375
<ubottu> Launchpad bug 275375 in deluge-torrent "Please sync deluge (1.0.7.dfsg-3) from Debian experimental" [Wishlist,Fix released] https://launchpad.net/bugs/275375
 * cjwatson responds to somebody reformatting a patch as a debdiff for sponsorship (by adding the changelog, and not crediting the original contributor) by committing the patch upstream, crediting the original contributor, and *not* crediting the person who reformatted it as a debdiff
<cjwatson> I hope this is reasonable ...
<LaserJock> cjwatson: nice
<asomething> ^oops, that should be in ubuntu-motu
<cjwatson> james_w: should lp:~james-w/bash-completion/ubuntu be moved to ~ubuntu-core-dev?
<james_w> cjwatson: probably.
<cjwatson> I was about to upload bash-completion and noticed that branch
<james_w> ah
<cjwatson> james_w: will you, or should I just branch from you and push?
<james_w> Debian maintain it in bzr, so a "bzr send" would be appreciated
<cjwatson> my laptop can't send mail itself. How do I tell bzr send to output to a file so that I can scp it to my mail machine?
<cjwatson> (yes, I should fix my laptop)
<james_w> cjwatson: I can't move it to core-dev, as I'm not a core-dev, so please push and I'll delete that branch
<james_w> bzr send -o file
<cjwatson> oh, I'd forgotten you weren't core-dev
<cjwatson> ok
<cjwatson> (why not? :-) )
<kirkland> jdstrand: for me, the use case is the first launch of my gnome-terminal
<jdstrand> kirkland: I see the utility in starting screen in the terminal absolutely-- I'm talking about the shared screen business
<jdstrand> (where other terminals are attached to the first one by default)
<tkamppeter> Keybuk, fresh HPLIP uploaded, now it is your action item to upstreamize the UDEV rules to udev-extra.
<shaya> does anyone else see tracker killing desktop performance due to the same sqlite issue as firefox?
<pitti> wasn't that due to calling fsync() a lot, which doesn't really do what you want on Linux?
<shaya> yes
<shaya> and tracker is current killing my system
<shaya> very heavily modifying sqlite db's
<shaya> and sqlite calls fsync in default config
<shaya> hence, I assume its same issue
<shaya> for instance, can't watch a video, as it locks up the system on fsync and hence constant stutter
<Keybuk> http://bazaar.launchpad.net/%7Eubuntu-core-dev/udev/ubuntu/revision/2414?compare_revid=2411
<Keybuk> cjwatson: that should do the trick, I think
<cjwatson> Keybuk: looks fine, I think. (It would be cleaner to use "cat <<'UDEVADM'" so that you don't have to escape all the dollar signs.)
<cjwatson> Keybuk: perhaps "without a dependency on udev" => "while udev is unconfigured" in case users happen to run udevadm in that period?
<Keybuk> true
<cjwatson> Keybuk: what used init.d restart (now refresh-devices)?
<Keybuk> cjwatson: nothing
<cjwatson> ok
<cjwatson> I take it it isn't possible to use that in case the sequence number changed?
<Keybuk> that has other bugs ;)
<Keybuk> most of the system doesn't like it
<Keybuk> e.g. network manager
<cjwatson> right
<apw> pitti, about?
 * Keybuk has a clever idea
<apw> pitti, i have an apport fix proposed for merging and suspect you are the only one who will look at it :)
<cjwatson> Keybuk: I was going to look at bug 285531, but it seems like more your kind of thing. Fancy grabbing it?
<ubottu> Launchpad bug 285531 in acpid "acpid initscript speedup" [Wishlist,Triaged] https://launchpad.net/bugs/285531
<Keybuk> sure
<cjwatson> thanks
<\sh> cjwatson: bug #314004 happend to me during hardy -> intrepid dist-upgrade just now...
<ubottu> Error: Could not parse data returned by Launchpad: HTTP Error 502: Bad Gateway (https://launchpad.net/bugs/314004/+text)
<cjwatson> \sh: I need all the appropriate log files (including /var/log/installer/syslog) filed as a *separate* bug report please, as it may not in fact be the same issue even if it looks like it
<cjwatson> \sh: also /var/log/dpkg.log
 * cjwatson &
<\sh> cjwatson: /var/log/installer/syslog is empty..(I was using apt-get dist-upgrade) but I can check for dpkg.log
<cjwatson> \sh: it should have been created during installation. It is likely only readable by root, but is not likely to be empty
<\sh> cjwatson: believe me :) http://paste.ubuntu.com/107931/ :)
<\sh> cjwatson: it's not installed via d-i it was more a automated installation by hoster. but apt-get dist-upgrade should full dpkg.log
<NCommander> cjwatson, ping?
<NCommander> cjwatson, could you look to seeing if we could merge the fix for http://bugs.debian.org/504555 into our initramfs-tools? It would be handy for the ARM port
<Keybuk> NCommander: probably better off directing that one at me
<NCommander> Keybuk, the RedBoot MTD support would be useful since a lot of ARM devices use RedBoot, do you think there would be any issues with merged that patch in?
<Keybuk> NCommander: looked sane to me
<Keybuk> can you file a bug?
<Keybuk> feel free to assign it to "scott"
<NCommander> Keybuk, sure
<\sh> NCommander: hmm...ubuntu on my nas device?,-)
 * NCommander already has Ubuntu on his NSLu2
<NCommander> :-)
<\sh> NCommander: hopefully redboot doesn't fck up during install, if so, Ican throw away my nas device ,-)
<NCommander> \sh, we don't reinstall RedBoot (actually, ATM, we don't even have an installer for NAS)
<\sh> NCommander: if we will have it, I'll test :)
<ogra> NCommander, you didnt tell him about the if_first_name_stephan_and_last_name_hermann_wipe_redboot() function ?
<NCommander> ogra, oh, that spec got implemented?
<\sh> ogra: lol :)
<ogra> secretly, shhh
<ogra> :)
 * NCommander now has four machines running different versions of Ubuntu
<NCommander> woo :-P
<\sh> ogra: you know why I do have a Nas device? Because a friend wanted to have linux on it, I fragged it, and now it's mine and runs ,-)
<ogra> heh
<\sh> and it looks like that I fragged the dev esx too
 * ogra knows why he doesnt let \sh near his machines :P
<NCommander> ACK, VMWARE
 * NCommander dies
<\sh> ogra: not my fault ;) select 20 instances at once and tell esx to suspend it...with 18gig ram, and 16 gb occupied...that means: die esx die
<ogra> heh
<NCommander> \sh, so much for VMware's fault tolerant solutions
 * NCommander notes that fault tolerance often isn't user tolerant ...
<\sh> NCommander: yepp...
<\sh> and reminder: doing esx updates via cli is much faster then doing it via vcenter update manager
<NCommander> Keybuk, bug #319730
<ubottu> Launchpad bug 319730 in initramfs-tools "Please merge in RedBoot MTD fixes from Debian" [Medium,Triaged] https://launchpad.net/bugs/319730
<TomJaeger> Hi.  How do I add an ubuntu package to a bug?
<\sh> time to leave the office and go home...good night folks
<cjwatson> \sh: if it was installed specially, I'm not really sure I can help
<cjwatson> \sh: for custom installs like that, just installing grub first would be fine, assuming that that's appropriat
<cjwatson> e
<directhex> nobody's planning on putting dh7.1 into jaunty are they?
<shaya> there's a crasher bug in firefox in intrepid that was fixed in 3.0.2 that is still crashing ubuntu's build
<shaya> https://bugzilla.mozilla.org/show_bug.cgi?id=441368
<ubottu> Mozilla bug 441368 in SVG "Crash [@ nsSVGFEGaussianBlurElement::SetupPredivide] opening SVG file" [Normal,Verified: fixed]
<shaya> the test case in that bug crashes my intrepid firefox
<dtchen> shaya: might want to repeat in #ubuntu-mozillateam
<lfaraone> Hi, how long does it take for NEW synced packages to be approved?
<seb128> lfaraone: until an archive admin process those, some hours to some days usually, why?
<dtchen> there's no upper bound, but usually less than one working week
<seb128> lfaraone: I just newed the one synced today
<maxb> Which channel would I be best off in for finding someone to give me hints on how to debug some guts of network-manager?
<seb128> maxb: either this one or #ubuntu-bugs
<lfaraone> seb128: I saw :)
<lfaraone> seb128: thanks.
<seb128> lfaraone: you are welcome
<maxb> thanks
<LaserJock> hmm, these new signed PPAs are a bit unfriendly in terms of UI
<directhex> a smidge
<LaserJock> the help page just tells you to see if the fingerprint is the same and keep downloading
<LaserJock> I wonder how helpful it is to sign the packages if you don't let apt/dpkg verify the signature
<maxb> no help at all, but I imagine the annoyance of the warning will drive people to sort out adding the keys to their apt keyring
<maxb> I whipped up a maxb-ppa-keyring package for my own PPA, but it would have been nice if template packages for that had been made officially
<LaserJock> or at least had a gpg line to get it
<superm1> maxb, LaserJock bug 319355
<ubottu> Launchpad bug 319355 in soyuz "Feature request: automatically generate deb w/ PPA keyrings" [Undecided,Confirmed] https://launchpad.net/bugs/319355
<hongli> hi. I want to repackage gtk with a backported fix from upstream
<hongli> is there any documentation on how to do this?
<pochu> hongli: no, but that would be like with any other package
<hongli> but how do I do it in general?
<hongli> I know how to build a deb, I know how to code. but what I don't know is how gtk's build system integrates with the debian package building process
<hongli> specially because debian/ubuntu keeps its own patch set
<pochu> apt-get source gtk+2.0; cd into the unpackaged package, put the patch in debian/patches, add a changelog entry and rebuild it
<directhex> pochu, no series/00list etc?
<hongli> so am I supposed to apply all the patches, then run ./configure && make install DESTDIR=/foo, then copy 'debian/' into /foo/DEBIAN, then package /foo?
<pochu> oh, yeah
<pochu> we use quilt for it
<pochu> err
<pochu> hongli: does your patch touch configure.ac or any Makefile?
<hongli> no
<pochu> then you should do something like this:
<pochu> 00:18 <@    Np237> export QUILT_PATCHES=debian/patches; quilt delete 15_blahblah; quilt push 14_blahblah; quilt new 15_blehbleh; quilt edit foo.c bar.c ... ; quilt refresh
<pochu> but you don't need to delete any patch :)
<hongli> quilt huh, first time I've heard of that tool
<pochu> it's like git but for patches :P
<hongli> is there an ubuntu document about quilt?
<hongli> I was looking in https://wiki.ubuntu.com/ContributeToUbuntu
<pochu> hmm, let's see
<pochu> !quilt
<ubottu> Sorry, I don't know anything about quilt
<hongli> I haven't found anything that mentions quilt
<pochu> there's something in Debian
<pochu> it's the same, so you can use that
<pochu> http://pkg-perl.alioth.debian.org/howto/quilt.html
<hongli> hm, if only there's a 'The Definite Guide to Contributing to Ubuntu' or something like that :(
<LaserJock> pochu: there's the patching part of the Packaging Guide
<pochu> hongli: ^
<pochu> !patch
<ubottu> Patches are files describing the changes in code to achieve some results.  There are a number of ways these can be produced, but https://wiki.ubuntu.com/Bugs/HowToFix and https://wiki.ubuntu.com/PackagingGuide/PatchSystems may provide some useful guidelines.
<pochu> second link :)
<hongli> so is quilt what all debian packagers use for maintaining downstream patches?
<pochu> nope
<LaserJock> https://wiki.ubuntu.com/PackagingGuide/PatchSystems#quilt%20(example%20package:%20xterm)
<pochu> there's quilt, dpatch, simple-patchys, modifying sources in the diff.gz...
<hongli> ok
<pochu> "You can install 521 updates"
<pochu> ouch!
<hongli> another question, is there a way to increase awareness or priority for a certain ubuntu bug?
<hongli> I've been an ubuntu user for years
<hongli> but unfortunately each new release introduces new regressions
<hongli> most of them are marked 'low priority' on launchpad
<hongli> I'm wondering how to get more attention to them. is donating a good option?
<pochu> hongli: yeah, you can discuss about it in #ubuntu-bugs
<pochu> hongli: I think if you say it's a regression it will be given a higher priority
<hongli> these days I'm a very busy man and I wouldn't mind donating some money if I can get regressions fixed
<hongli> I discovered 2 annoying bugs upon installing 8.10 yesterday (was using 8.06 previously)
<hongli> one is that setting the keyboard repeat rate doesn't work (X.org bug)
<hongli> the other is that the gtk file dialog is unusably small
<hongli> the latter is so obvious that I wonder how it got past QA
<hongli> which is why I was asking how to repackage gtk so I can fix the bug myself
<pochu> because it may be due to your configuration
<hongli> this is a clean install
<pochu> oh
<pochu> hongli: if the patch is small, there could be an Stable Release Update
<pochu> but since it's GTK, it may well be rejected as it may not be worth the risk for such a fix
<hongli> the alternative is a literally unusable file dialog
<hongli> so I think fixing this is the only answer no matter what the risk is. don't you agree?
<savvas> hongli: did you report them? http://bugs.launchpad.net/ubuntu/+filebug
<hongli> it was already reported: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/285285
<ubottu> Launchpad bug 285285 in gtk+2.0 "GtkFileChooser dialog size randomly broken" [Low,Fix committed]
<hongli> I confirmed the bug as well
<hongli> fix was committed upstream
<hongli> but not backported to intrepid
<hongli> so I guess I'll wait for a few days and see how they respond to this bug report
<savvas> hongli: nominate it if you want, but I don't think it will be approved, jaunty is just a few months away
<hongli> "a few months" is quite a long time
<savvas> hongli: www.ubuntu.com/testing :)
<hongli> if this bug doesn't get fixed, and if I don't have the time to do it myself (I probably don't),
<hongli> then I'll have to use OS X :(
<hongli> something which I want to avoid because the keyboard on my macbook sucks
<savvas> hongli: ubuntu 8.04 has the same problem?
<hongli> no, 8.04 is okay
<savvas> so?
<savvas> there are regular backports to the long term release
<hongli> downgrading means I can't use the latest software packages
<hongli> what I actually want is to be able to keep my software as up to date to upstream as possible, while still being stable
<hongli> instead of stable but stuck with ancient versions
<savvas> hongli: then you want debian testing
<hongli> not ubuntu?
<directhex> "stable" by definition means "not constantly changing"
<Hobbsee> hrm.  jaunty actually works now.
<savvas> ubuntu gets most of its packages from debian (and vice versa)
<hongli> directhex: formally you may be right, but "stable" means "things don't crash/have lots of bugs" as far as most end users are concerned
<hongli> and that's what I mean with "stable" as well
<hongli> change is okay, but I want things not to crash or have lots of bugs
<hongli> and that things don't break
<LaserJock> right, which is why we have a Stable Release Updates policy
<savvas> hongli: there are way to get around with different distributions, debian testing seems to be what you need - at least for now, until jaunty is out
<hongli> I have used all kinds of distros in the past
<directhex> hongli, and how do you apply QA to a new upstream version?
<hongli> directhex, use it, check whether there are obvious bugs, if so reject it, if not accept it?
<directhex> hongli, there are 25000 packages in the archive. and a lot of bugs which happen as a result of intersections between those 25000
<hongli> anyway, that isn't important right now. suppose that I can't get the fix backported to intrepid by just raising my concern
<hongli> can I donate money to someone to have it done anyway?
<hongli> even if it's just a third party package
<hongli> as long as it's fixed
<LaserJock> hongli: I'm doubting money is going to do much
<hongli> heck, can I pay one of you to do it?
<LaserJock> hongli: but you might ask around for to see if somebody would want to do it for you
<hongli> I have a job so I can't do this every time I encounter a bug
<LaserJock> but I'd first see if an SRU is possible, it might be
<hongli> SRU?
<LaserJock> Stable Release Update, getting the fix into intrepid-updates
<LaserJock> it's a fairly minor bug, but if there's enough demand for it maybe it'd make it
<hongli> LaserJock, with all due respect, why do you think it's "minor" if the dialog is unusable by default?
<hongli> and by unusable I mean it
<LaserJock> because you can easily resize it
<hongli> but I encounter it dozens of times, on a daily basis
<LaserJock> sure
<hongli> in the mean time, someone posted this issue on reddit
<LaserJock> it's an annoyance, no doubt
<hongli> this spawned *320* comments
<hongli> 90% negative
<hongli> and yelling how gtk/ubuntu sucks
<LaserJock> but compared to applications that don't even start or crash
<hongli> it's giving you a bad reputation
<LaserJock> it's minor
<LaserJock> hongli: I certainly understand where you're coming from
<LaserJock> but it's not always that straightfoward
<LaserJock> and in comparison to the other bugs out there this one if fairly minor, even though annoying
<LaserJock> *is
<LaserJock> of course that doesn't mean we can't give it a go at fixing it
<LaserJock> the fix is 1 week old and looks fairly invasive
<hongli> ok I understand that there are lots of packages and that you have to prioritize
<hongli> if I can't provide you with manpower, is there anything I can do to help?
<hongli> is financial help really not worth much?
<LaserJock> I don't think particularly helpful, though I could be wrong
<LaserJock> hongli: your comments for today on that bug are probably helpful in raising the bugs profile
<directhex> you want a patched gtk package? one off?
<hongli> I want a patched gtk package that fixes the resize bug
<directhex> and you already know the revision which fixes it?
<hongli> the file dialog resize bug
<LaserJock> directhex: there's 4 svn commits that are supposed to fix it
<hongli> frederico mentions the revision on the upstream bug tracker
<LaserJock> directhex: in the Gnome bug that's linked
<hongli> has anyone ever considered a "bounty repository"?
<hongli> that is, users who experience regression/annoying bugs like this can put up bounties
<savvas> hm.. I just noticed something on debian testing: Get:56 http://ftp.no.debian.org testing/main 2009-01-19-0229.27.pdiff [2341B]
<hongli> users can donate
<hongli> interested developers can fix these problems
<savvas> is the new aptitude getting package differences?
<hongli> and publish the changes in a third party repository
<maxb> pdiffs are nothing new
<LaserJock> hongli: we've done a bounty system in the past and it didn't work
<hongli> what went wrong?
<LaserJock> well, frankly I think people underestimate 1) how much money it takes and 2) how much people don't do this for the money
<pochu> hongli: this is your bug, isn't it? http://blogs.gnome.org/mortenw/2009/01/21/the-gtk-file-chooser-dialog/
<hongli> pochu: no I'm not him
<hongli> but yes it's the bug I mean
<pochu> I mean your bug, not your blog :)
<pochu> hongli: money is not going to help you get the bug into intrepid-updates probably, as it's not a metter of somebody doing it but rather of the SRU team accepting it
<hongli> LaserJock: I was about to ask whether enough effort was spent on marketing the system
<hongli> but if 2 is true then it is a problem that isn't easily fixed
<pochu> it can help you if you find somebody that is willing to prepare the packages in a private repository, though
<hongli> short of getting corporations to hire developers
<pochu> but I'd suggest try to get it accepted for an SRU before, as that will benefit everybody using intrepid
<directhex>  ChangeLog                    |   44 ++++++++++++++++++++++++++++
<directhex>  gtk/gtkfilechooserdefault.c  |   66 ++++++++++++++++++++++++++++++++++++++----
<directhex>  gtk/gtkfilechooserdialog.c   |   65 ++++++++++++++++++++---------------------
<directhex>  gtk/gtkfilechoosersettings.c |   67 +++++++++++++++++++++++++++++++++++++++++++
<directhex>  gtk/gtkfilechoosersettings.h |   16 ++++++++++
<directhex>  5 files changed, 219 insertions(+), 39 deletions(-)
#ubuntu-devel 2009-01-22
<LaserJock> yeah
<pochu> ouch
<hongli> has gtk switched to git?
<pochu> err
<pochu> 44 changelog lines for one fix???
<hongli> it was using svn last time I checked
<pochu> hongli: it still uses svn
<LaserJock> it's svn still I think
<directhex> fails to apply to intrepid package
<LaserJock> the "fix" includes new gconf keys, etc.
<directhex> this is non-trivial
<LaserJock> that's probably like a $200 fix ;-)
<hongli> urgh. I wonder whether removing that one liner that was mentioned earlier will fix it
<hongli> LaserJock: you know I'm almost willing to pay the $200 if this costs me significantly more time :)
<hongli> I'm not a teenager anymore so I can't affort all-week-hacking-sessions like I used to
<hongli> in the mean time I'm trying to fix what seems to be a bug in gnome-power-manager...
<directhex> jms@destiny:/tmp/gtk+2.0-2.14.4.orig$ patch -p1 < ../part2.patch
<directhex> patching file gtk/gtkfilechooserdefault.c
<directhex> patching file gtk/gtkfilechooserdialog.c
<directhex> patching file gtk/gtkfilechoosersettings.c
<directhex> patching file gtk/gtkfilechoosersettings.h
<directhex> jms@destiny:/tmp$ diffstat debdiffy.diff
<directhex>  debian/patches/099_fix_small_filechooserdialog.patch |  398 +++++++++++++++++++
<directhex>  gtk+2.0-2.14.4/debian/changelog                      |    7
<directhex>  gtk+2.0-2.14.4/debian/patches/series                 |    1
<directhex> big patch
<pochu> indeed
<directhex> build build build
<pochu> PPA!
<hongli> I've heard of the PPA. how does it work?
<directhex> pochu, i'm not cluttering my own PPA with things like gtk
<directhex> hongli, upload source package, get repository.
<hongli> is it just a repository that happens to be maintained by a random person that has a launchpad account?
<directhex> yes
<hongli> hm you say *source* package
<pochu> hongli: it's a Launchpad service for every user or team
<hongli> so launchpad builds packages for different distro versions for you?
<pochu> right
<pochu> for the one you upload it
<directhex> only different ubuntu versions, but yet
<hongli> so how do you deal with differences between distro versions?
<pochu> you can upload to hardy, intrepid, jaunty, etc
<directhex> stupid crappy slow c
<hongli> for example, suppose that you're packaging git which depends on git, but ubuntu 8.04 comes with libsome_dependency1.2 while 8.10 comes with libsome_dependency1.4
<hongli> the package names are different in both distro versions
<directhex> you upload once per target release
<hongli> so you have to upload one source package per ubuntu release?
<directhex> it can handle multiple versions of the same package (but not multiple copies with the same version number)
<directhex> so yes, you'd upload 1.0-1~intrepid~ppa1 and 1.0-1~hardy~ppa1 separately
<maxb> though you can save yourself bandwidth by only including the .orig.tar.gz once
<directhex> if you remember the right debuild flags to do so
<pochu> does it?
<LaserJock> as long as the .orig.tar.gz is in either Ubuntu or your PPA you don't need to include it
<directhex> hurry up, pbuilder
<pochu> and I was always uploading the orig tarballs...
<directhex> pochu, well, it's only a problem when you're an OOo packager :)
<pochu> well, eclipse is *huge* too ;)
<directhex> yes
<directhex> and has elite java powers meaning it eats ram for fun
<pochu> heh
<pochu> so does wxwidgets2.8
<directhex> no really, i worked on ikvm packaging, and the ikvm build process involves compiling openjdk
<directhex> i thought there was a terrible memory leak, but no! the memory leak is called "javac"
<directhex> 1.3 gig of ram later, it finishes
<pochu> heh
<directhex> dpkg-deb: building package `libgtk2.0-0' in `../libgtk2.0-0_2.14.4-0ubuntu2_amd64.deb'.
<directhex> hongli!
<hongli> nice, thanks :) I appreciate it
<hongli> let me test
<hongli> oh, I'm on x86 :/
<pochu> PPA!!
<pochu> :P
<TheMuso> 8/c
<hongli> this one, right? https://launchpad.net/~directhex/+ppa-packages
<pochu> nice split
<pochu> good night folks
<pochu> hongli: good luck!
<hongli> thanks pochu
<hongli> gnight
<hongli> how do I install a PPA's gpg key? there doesn't seem to be any instructions
<hongli> or a download link to a gpg file
<hongli> ok never mind, I figured it out. :) just not as easy as the one-liners I'm used to
<LaserJock> yeah, I think they're working on that
<LaserJock> they just started really rolling out the package signing
<hongli> directhex: I don't see libgtk in the package list
<hongli> time to sleep, bye
<calc> if i you rename a folder in evolution does it not really rename it?
<calc> i tried renaming my old folder for the mailing list to the new name and then changing my filter but it claims the new name doesn't actually exist
 * calc is going to brute force fix it by moving all messages deleting the folder then recreating it (maybe that will work?) :)
 * ScottK considers trying to seduce calc back to the dark ways of KDE ...
<calc> ScottK: does kmail not eat mail anymore, back when i maintained people were always complaining about how crap it was ;-)
<calc> back then i just used mutt
 * calc is beginning to think he should go back to mutt with imap
<ScottK> For pop3, no it does not in my experience.
<ScottK> No idea about imap, although I understand it's way better than it used to be.
<calc> ScottK: ok
<ScottK> calc: I've also heard it got substantially better in KDE 4.2 (haven't tried it yet).
<calc> if thunderbird wasn't so bad i would have stayed with it
<calc> ScottK: ok
<calc> whenever they fix sorting based on imap headers i will probably switch back to thunderbird
<calc> that bug has been open for ~ 6 years though so i doubt it will be anytime soon
<calc> wow evolution just crashed on me while moving messages
<calc> lovely
<calc> and now it won't start back up
<calc> f*ck bus error from less i need to reboot
 * ScottK has bugs filed on mozilla (seamonkey) prior to 1.0 still open.
<calc> bbl
<calc> actually i'm on irc from a stable machine, just via ssh :)
<calc> even deleting and remaking the folder in evolution doesn't work
<raof> directhex: Do you have any idea why libmono-cairo2.0-cil doesn't ship a pkgconfig file?
<raof> Also, I'd like to stab f-spot's autofoo maintainer for putting all of the pkg-config dependencies in a single call.
<ScottK> On the off chance that there's an archive admin awake, paying attention, and with a moment to do something (and an associated willingness), would you please accept kdebase-workspace into intrepid-proposed.  This is part one of the bluetooth fix for KDE and part two has to build against it.
 * StevenK mumbles
<Junowat> hi everyone
<ScottK> StevenK: Thank you.
<StevenK> ScottK: Oh, you saw?
<ScottK> Got that accepted.
<ScottK> that/the
<Junowat> I was hoping to find out more about Ubuntu Developer Week.
<Junowat> is this an active room?
<ScottK> Not so much this time of day.  Try #ubuntu-classroom later in the day (not sure how much).
<Junowat> unfortunately that was on Monday
<Junowat> https://wiki.ubuntu.com/UbuntuDeveloperWeek/
<Junowat> I was hoping that there would be an overview of the different development teams somewhere
<Junowat> I am a developer
<Junowat> and I wanted to see which teams needed people and where I would fit in based on my skills
<ScottK> What are you interested in?
<ScottK> The Ubuntu Developer Week presentations go on all week.
<Junowat> I'm interested in doing programming work (as well as build/packaging)
<ScottK> Are you interested in KDE/Gnome/Server stuff ....
<Junowat> why not?  =)
<Junowat> I am open to all of them.
<Junowat> though I have only used Gnome (not KDE)
<ScottK> It's generally better in the long run if you focus where your interests are.
<Junowat> right
<ScottK> Then I'd suggest #ubuntu-desktop, but it'll probably be quiet this time of day.
<Junowat> I agree
<Junowat> well that is why I am trying to find out what the different areas are
<Junowat> in other words, what are the choices (and then pick out of a,b,c, ... etc)
<ScottK> There are really as many choices as all the stuff in the Ubuntu archive.
<ScottK> In #ubuntu-motu we package and maintain the Universe repository.  We also teach people about packaging.
<ScottK> It might be best to start there.
<Junowat> OIC that makes sense
<Junowat> I'd need to know that process in order to work with any of the teams
<Junowat> I looked on the Ubuntu developer wiki here: https://wiki.ubuntu.com/UbuntuDevelopment
<Junowat> and it seemed like there are only 2 different groups: ubuntu core developers and MOTU
<Junowat> that seemed a bit simplistic and I was hoping for more
<ScottK> The archive is divided into two main parts and those teams follow those.
<ScottK> But there are also people who focus on Gnome, KDE, and Server things.
<ScottK> Also language specific areas too.
<ScottK> For example, #ubuntu-java
<Junowat> you seem to know a lot about this ScottK
<Junowat> thanks!
<Junowat> Is there any resource online that I can use to find out more
<Junowat> (I don't want to pepper you with all my questions)
<ScottK> https://wiki.ubuntu.com/UbuntuDevelopment pretty well will lead you everywhere eventually.
<ScottK> Which you already started with.
<Junowat> thanks ScottK
<Junowat> appreciate the info
<ScottK> Junowat: You're welcome.
<Junowat> From what you're telling me as well as what I read on the dev wiki, it looks like the motu team is where I should start (plus they offer mentoring)
<Junowat> cheers!
<lamont> WTH did booting an intrepid dhcp host result in resolv.conf having both search and domain directives?  I mean, this isn't 1992
<calc> wow it took 26m to install jaunty, seems a bit slow
<raof> Is that from livecd?
<calc> from alt cd
<bluesmoke> dude I wish mine were 26m
<raof> That's closer to expected, but still a while.
<raof> I'd be concerned if that was the livecd!
<bluesmoke> my LiveCD installs have always taken like 30-40 minutes
<bluesmoke> except for maybe the very first one I did when we first started doing LiveCD installs
<raof> What sort of hardware are you installing on, and are you including time to do the configuration?
<raof> This install took longer to select keymap, language, partition, username, etc than it did to actually install.
<LaserJock> holy smokes
<calc> raof: 26m c2d laptop and did selections as fast as possible, already pre-partitioned so just selected manual and told it what to format as
<LaserJock> I think mine always take at least 30 min.
<raof> Again, we're talking the livecd?  Strange!
<LaserJock> both
<calc> raof: my 26m was amd64 alternate cd (not live cd)
<calc> raof: and was timed from the time it booted until it rebooted
<raof> Right.  26m isn't too bad for the alternate cd.
<raof> That's probably about what mine takes.  The live cd was much, much faster.
<calc> livecd is too slow, heh
<calc> raof: the livecd installs faster for you than alternate cd?
<raof> Yes.
<calc> hmm ok
 * calc thought it would have been slower due to having to boot into gnome
<raof> Oh.  I was calculating from "Start the installer", not "boot the CD".
<raof> It might be longer from that.  But I was testing the live session, anyway.
<calc> oh ok
<LaserJock> 95% of the time I do Alternate installs so I might be wrong on my LiveCD timings
<raof> But blitting the files to disc & formatting was ~5min, or so.
<calc> ah thats not too bad
<calc> i formatted 160gb which seemed to take almost that long itself
 * calc is wondering why he installed jaunty after seeing gnome panel not start
<calc> oh it finally started it just took forever, omg
<calc> wow something is really wrong with this its dragging badly
<calc> and my cursor is jumping all over the place
<calc> and xorg is sitting at 50% cpu usage doing nothing
 * calc thinks he will reinstall intrepid
<glick> hey is a squashfs red error usually a sign of a bad cd-room when booting a live cd?
<liw> glick, yes
<savvas> will ubuntu have support for apt pdiff?
<LaserJock> at some point maybe
<savvas> LaserJock: do you know how it works? is it a binary diff or does it work with source packages?
<LaserJock> savvas: well, pdiffs just give you deltas for the Packages or Sources index files
<LaserJock> makes apt-get update faster for often-updating systems
<dholbach> good morning
 * slangasek waves
<dholbach> hiya slangasek
<tjaalton> TheMuso: it's still busted here
<pitti> Good morning
<pitti> apw: I didn't get an email about a merge request; which branch?
<directhex> pitti, is the debhelper version jaunty ships with finalised?
<pitti> directhex: we can update it if necessary, but without a particular reason it is yes
<directhex> hm. joeyh made some lovely changes to 7.1 which broke mono-related things to death. they've been worked around, but now it's either dh7.1 in jaunty, or merges rather than syncs needed to revert those workarounds in some key packages (including mono itself)
<apw> pitti, https://code.launchpad.net/~apw/apport/suspend-resume-report-stress-log
<directhex> my gut says merging is safer at this stage in the release
<directhex> my gut also says merges freaking suck
<pitti> directhex: yes, if we can sync a lot of packages with that and avoid merges, it's definitively preferable
<directhex> pitti, to sync things, i need dh7.1. the minor irony being i think dh generally needs merging, not syncing ;)
<directhex> pitti, let me know which you prefer to do. i need to go and see a power meter about some watts
<pitti> directhex: oh hang on, 7.1 is experimental; I hope that's just because testing is frozen, not because it breaks stuff
<directhex> pitti, so do i :/
<directhex> pitti, experimental is the new unstable. we need a new repo for experimental things too experimental for experimental!
<seb128> we need to get lenny available and start using unstable again rather ;-)
<directhex> seb128, well, the problem with releasing on the same day as duke nukem forever is...
<dholbach> are there any reports of sound not working in jaunty?
<DktrKranz> dholbach: I had some issues, I worked-around it with alsamixer
<DktrKranz> they're related to bug #315971
<ubottu> Launchpad bug 315971 in pulseaudio "'Front' and 'PCM' mixer control elements must be unmuted by default on HDA platforms" [High,Confirmed] https://launchpad.net/bugs/315971
<dholbach> DktrKranz: ahhh, thanks
<dholbach> that made it work again :)
<tjaalton> unfortunately alsamixer fails to work here :/
<tjaalton> but that's already on lp
<DktrKranz> dholbach: you have to redo it every reboot, saving settings is not enough, but at least it works :)
<dholbach> DktrKranz: narf!
<dholbach> DktrKranz, tjaalton: do you know if there's a way to set "sound profiles"? what I'd love to do is set specific values for mic and mic boost (depeding on if I use skype or record a mixtape)?
<tjaalton> dholbach: sorry, no idea
<dholbach> TheMuso: ^ do you know if such a thing exists?
<dholbach> or maybe set the mic settings with a script or some such?
<broonie> dholbach: That's not there yet.
<broonie> There's some in progress work on ALSA scenario support (the embedded world *really* wants it) but there's nothing standard ATM.
<dholbach> broonie: do you know if there's a hackish way to mess with the settings via a script?
<broonie> alsactl store -f <filename>
<broonie> alsactl restore -f <filename>
<dholbach> ahhhhhhhh!
 * dholbach hugs broonie
<broonie> will save and restore all the settings.
<dholbach> that sounds like rock and roll to me
<broonie> The core of teh scenario stuff is being able to do that automatically and only adjust some controls.
<directhex> know what would be nice? if soft-pin-based chips like ALC888 could gain hardware support from a userland file rather than from a compiled-into-kernel list of per-model pin maps
<directhex> even better, the ability to read pin maps from windows .inf files
<broonie> AIUI half the problem is that the data you're supposed to be able to read from H/W is often full of lies.
<broonie> There are already some facilities for reconfiguring HDA stuff from user space, it'd be more front end work than anything else doing what you want.
<broonie> (AIUI, I've not worked much on HDA.)
<directhex> it took 3 years for this mac to get audio support in ubuntu, despite having a "supported" chip, due to a lack of valid pin map in the kernel module
<broonie> directhex: The ALSA people (mostly Takashi for that) are very quick to turn that stuff around, sounds like an issue getting the issue upstream to them :(
<_max> Anyone happen to have a deeper understanding of how the ubuntu-netinstall works? im trying to modify it to instead of executing the installer, execute a script (a backup script).
<kwwii> pitti: heads up, some issues with internationalization, naming and freaky problems with the emblem interface were found by an artwork member...I pointed him your (and seb's) way as I have no idea what is going on
<kwwii> just so you know why you are being subscribed to human-icon-theme bugs :-)
<pitti> kwwii: okay
<cjwatson> _max: yes - have you read the preseeding documentation?
<cjwatson> _max: you can't really not execute the installer *at all* though.
<cjwatson> but you might perhaps want to run the bits of it that do hardware detection?
<_max> cjwatson, well what im trying to do is replace a very expensive product we use with something simple, since we only use like 2% of the product anyway =/
<_max> my intention is to netboot a kernel (ubuntu is usually able to detect just about everything)
<_max> then load a script that determines mac address + time, and dd's an image through tar.gz onto a nfs drive.
<cjwatson> some hardware detection happens in userspace, remember
<_max> i thought il create a netboot image for save and one for restore.
<_max> Yes thats true.
<cjwatson> _max: so have you tried using preseed/early_command? You could have it run a script and then reboot.
<_max> we basicly only have one type of server though, and its just smudged with linux friendly intel chips.
<cjwatson> (see https://help.ubuntu.com/8.10/installation-guide/i386/appendix-preseed.html)
<_max> cjwatson, i have not, i will now, thank you :)
<cjwatson> and https://help.ubuntu.com/8.10/installation-guide/i386/preseed-advanced.html#preseed-hooks
<directhex> mmm... d-i preseed...
<cjwatson> I don't suppose anyone could translate https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/57470 for me?
<cjwatson> ogasawara: http://qa.ubuntu.com/reports/ogasawara/jaunty-buglist.html seems to return HTTP 403 all of a sudden
<StevenK> cjwatson: Google translate does a fairly decent job of translating it
<cjwatson> thanks
<primes2h> pitti: Hi :-)
<primes2h> pitti: kwwii told me to contact you...
<primes2h> pitti: I know he told you about emblems issues...
<primes2h> pitti: I just need to ask you something about internationalization...
<\sh> doko_: looks like that our (and obviously others) sun-java6-jdk/jre is heavily broken :( (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6755573) and I can reproduce this quite easily
<pitti> primes2h: sure, what's up? (sorry for delay, was at lunch)
<pitti> primes2h: ah, you sub'ed me to a bug; will look at it soon
<primes2h> That's nice.. I would like to ask you another thing about human-icon-theme....
<primes2h> I made a patch for this bug #172353
<ubottu> Launchpad bug 172353 in human-icon-theme "Human theme has non-translatable emblem names." [Low,Confirmed] https://launchpad.net/bugs/172353
<primes2h> (I faced the other bug working on this one)
<primes2h> Is it normal that I have to launch make update-po manually from eithin /po directory in human-icon-theme to regenerate .po files?
<primes2h> from within
<primes2h> If I build the package (e.g. ./autogen.sh and make, or debuild) it doesn't regenerate new .po files.
<pitti> primes2h: regenerate> you mean merge to an updated pot? yes
<pitti> it really shouldn't
<pitti> packages which always merge po files on build are a pain in the butt
<pitti> (cause constant stream of diff noise, etc.)
<primes2h> ah, ok...
<pitti> and usually a dev knows when he changed a string, and wants to update the languages he knows about
<primes2h> so, before building the package I need to launch make update-po.
<primes2h> That's what I needed to know.
<primes2h> Thank you very much!
<pitti> primes2h: hang on
<primes2h> ok
<pitti> primes2h: *why* do you need to update them so often?
<pitti> primes2h: this bug doesn't sound like needing to update actual translations?
<primes2h> no, I nedd this just with the patch i made, because it set up emblems translation.
<pitti> primes2h: right, but that still doesn't need merging the .po files
<primes2h> There isn't in the original package.
<primes2h> I'll let you show...
<pitti> primes2h: let's take a step back
<pitti> primes2h: do you know what msgmerge is and when to use it?
<primes2h> in fact no :-). but please follow me for 1 moment. :)
<primes2h> compare po in gnome-icon-theme with po in human-icon-theme.
<primes2h> in gnome-icon-theme you find emblems strings
<primes2h> in human-icon-theme no.
<hwilde> is there a roadmap for the future of nm and /etc/network/interfaces ?
<primes2h> I had a look at human-icon-theme source and I find there is a lack of translation infrastructure for emblems (.icon.in files etc...)
<pitti> primes2h: right, msgunfmt /usr/share/locale-langpack/de/LC_MESSAGES/human-icon-theme.mo just has one string (the theme name)
<primes2h> in gnome-icon-theme instead you can translate them
<pitti> right
<primes2h> because it has the correct infrastucture.
<primes2h> That's the issue of bug #172353
<pitti> so the strings aren't marked as translatable in the Code then?
<ubottu> Launchpad bug 172353 in human-icon-theme "Human theme has non-translatable emblem names." [Low,Confirmed] https://launchpad.net/bugs/172353
<primes2h> and that's what my patch does.
<primes2h> yes, because in the code there are just the icon files, but not the .icon.in files.
<primes2h> (and you need to change Makefile.am and POTFILES.in  too obviously)
<primes2h> but when I build the package I found that .po files remain the same (one string)
<primes2h> it's not "updated"
<pitti> primes2h: right, then you need to do update-po exactly once
<primes2h> Correct!
<pitti> (not with every build)
<primes2h> yes, my question was if it's normal, I don't know about it
<primes2h> if it's normal for this kind of patch
<primes2h> have a look http://pastebin.ubuntu.com/108177/
<pitti> primes2h: yes, that's the purpose of update-po; if you change strings in the source, you need to call it once to provide translators with an updated 'template'
<primes2h> this is my first patch, could you please have a look if it's correct?
<pitti> primes2h: please don't use debian/patches/
<pitti> human-icon-theme is an ubuntu native package, please just change it inline
<pitti> primes2h: it is maintained in bzr instead, so please feel free to make a branch and mention the branch on the bug
<pitti> primes2h: if you don't want to use bzr, just make a normal debdiff
<pitti> but please no patch system
<pitti> primes2h: I don't understand why we need a separate .icon.in file? shouldn't the string be extractable from the actual .icon file? or .icon.in be generated from .icon?
<pitti> how does gnome-icon-theme do that?
<primes2h> I think .icon is generated from icon.in. if you llok at gnomne-icon-theme source you'll find .icon.in file in scalable/emblems/
<primes2h> and .icon files are generated during building.
<pitti> primes2h: ah, ok; then the source package shouldn't ship .icon any more
<savvas> pitti: do you have a minute to spare?
<primes2h> in human-icon-theme source there no .icon or .icon.in files at all.
<primes2h> just .svg files
<pitti> !ask | savvas
<ubottu> savvas: Please don't ask to ask a question, simply ask the question (all on ONE line, so others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<savvas> pitti: Bug #23568, bug #140934 and bug #304767 link to upstream http://bugzilla.gnome.org/show_bug.cgi?id=354661 - one of them is private, can you choose one "master" from them?
<ubottu> Launchpad bug 23568 in gnome-system-tools "[time-admin] The timezone selected during install is different in (Gnome) Clock" [Low,Fix released] https://launchpad.net/bugs/23568
<ubottu> Launchpad bug 140934 in system-tools-backends "Default Time zone/City for Serbia(Europe) Should be Belgrade" [Medium,In progress] https://launchpad.net/bugs/140934
<ubottu> Bug 304767 on http://launchpad.net/bugs/304767 is private
<ubottu> Gnome bug 354661 in s-t-b "time-admin fails to lookup "Europe/Helsinki" as time zone value" [Minor,Unconfirmed]
<savvas> I don't know if the private one is duplicate though
<pitti> savvas: I can't read the private one either
<primes2h> pitti: I'll do a simple debdiif and I'll show you later, ok?
<pitti> savvas: I guess the first ones are really dupes, but I can't be 100% sure without testing the upstream fix
<pitti> primes2h: cheers
<primes2h> pitti: Thank you very much...
<savvas> pitti: I'll see if I can create a patch for debian and ubuntu packages
<hwilde> anybody on lm-sensors:   sensors-detect could modprobe the modules it suggests adding to /etc/modules, would be helpful
<Karnaugh> hrm
<Karnaugh> is there a specific channel for the ubuntu livecd
<Karnaugh> trying to figure out how to remaster it to have a maximum screen resolution
 * calc wonders how linux can md5sum a 700mb file in 1.7s off a hd
<pitti> Penguin Power!
<pitti> calc: maybe it was still in the cache?
<cjwatson> Karnaugh: the Ubuntu live CD just uses X's automatic configuration, so if you're having trouble with that, you would be best off talking to the X people
<doko_> \sh: 6u12 isn't released yet
<ScottK> doko_: Are we going to get python 2.6 soon?
<Karnaugh> cjwatson: well, when I replace the empty /etc/X11/xorg.conf with the same basic one dexconf creates but with some mode lines
<Karnaugh> cjwatson: it gets overwritten at boot
<doko_> ScottK: yes
<Karnaugh> cjwatson: so I would assume something from Ubuntu changes is forcing dexconf to run
<ScottK> doko_: Great.  I'm also looking forward to Python 3 support in pycentral.
<ScottK> I've got one module to package that supports it upstream already.
<cjwatson> Karnaugh: that would be /scripts/casper-bottom/20xconfig in the initramfs, which runs dpkg-reconfigure xserver-xorg
<calc> pitti: hmm i guess so, it seemed to spit out real info
<cjwatson> Karnaugh: if you have already configured X in the squashfs, then you can remove that script from the initramfs (with the caveat that that means it will probably only work well on similar systems to yours)
<Karnaugh> cjwatson: ok thanks
<Karnaugh> cjwatson: the config it seems to create is bland enough that the rest of X auto config stuff should just happen
<Karnaugh> cjwatson: problem I have is often it decides to use resolutions way higher than the screen is really usable on
<cjwatson> Karnaugh: that's an X bug, and we'd appreciate it if you could report it so that we can make it work
<Karnaugh> cjwatson: righto
<cjwatson> (cf. http://wiki.ubuntu.com/X/Reporting)
<Karnaugh> cjwatson: got 3 of the same IBM boxes here which do it - I think the LCD is crap though so DPMS doesn't work
<calc> Karnaugh: what size lcd and what resolution was it attempting?
<Karnaugh> calc: 17" LCD and I don't know what res it tried, the LCD just spazzed outand turned off but X was starting fine behind it
<calc> Karnaugh: oh ok
<tkamppeter> pitti, when will you do your next SRU/-proposed run?
<pitti> tkamppeter: tomorrow morning
<tkamppeter> OK, I asked because of letting CUPS and foomatic-filters go into -proposed.
<tkamppeter> pitti, in bug 308817 I have proposed a simple patch backported from GS 8.64 to solve the problem for at least a part of the reporters (with the others probably bitten by bug 299918). We could SRU it, too. I could make a GS package for Intrepid which you could move to -proposed tomorrow, too.
<ubottu> Launchpad bug 308817 in cups "duplex printing through CUPS no longer works" [Undecided,Confirmed] https://launchpad.net/bugs/308817
<ubottu> Launchpad bug 299918 in foomatic-filters "Cannot print duplex in intrepid with Ricoh Aficio 2060, Ricoh Aficio MPC3000 or Brother HL-4050cdn using the openprinting drivers" [High,Fix committed] https://launchpad.net/bugs/299918
<pitti> tkamppeter: a gs patch backported to cups?
<tkamppeter> pitti, the bug has a ghostscript task which I have nominated for Intrepid. The CUPS task I will mark invalid.
<tkamppeter> And ubottu will still consider this a CUPS bug: bug 308817
<ubottu> Launchpad bug 308817 in ghostscript "duplex printing through CUPS no longer works" [Undecided,Fix released] https://launchpad.net/bugs/308817
<tkamppeter> ubottu has improved!
<ubottu> Sorry, I don't know anything about has improved!
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - Day 4 to kick off in #ubuntu-classroom in 19m. :-)
<calc> umm if you aren't hooked up to a network when installing via alternate cd it comments out the security lines in sources.list ?!
<cjwatson> calc: fixed in jaunty
<calc> cjwatson: great :)
<ogra> calc, else it would hang in apt-get update
<cjwatson> ogra: not true any more
<ogra> right
<calc> ogra: it doesn't verify all the other lines in the sources.list though and doesn't comment them out, it just comments out the security ones
<cjwatson> hasn't been true for a long time. It was just a mistake in apt-setup that it behaved this way
<cjwatson> I'd really prefer people not to say "it's meant to be that way" about installer bugs, especially when I've already answered them :)
<calc> heh :)
<calc> i tried going to jaunty last night after intrepid blew up on me but it was too broken to use
<calc> xorg was sitting at 50% cpu and cursor was jumping all over the place :-\
<pitti> calc: might be bug 307306
<ubottu> Launchpad bug 307306 in gnome-power-manager "upgrade to 2:1.2.99.2-0ubuntu1 makes session utterly slow" [High,In progress] https://launchpad.net/bugs/307306
<pitti> calc: did you check Xorg.0.log for thousands of randr calls?
<calc> pitti: no, it was so slow i barely could get it to shut down
<tkamppeter> pitti, bug 308817 is now ready for an SRU. New Ghostscript uploaded into -proposed.
<ubottu> Launchpad bug 308817 in ghostscript "duplex printing through CUPS no longer works" [Undecided,Fix released] https://launchpad.net/bugs/308817
<pitti> calc: that is the case for me as well when running on battery or changing anythign power related
 * ogra curses qemu 
<calc> pitti: i have the same video as listed in that bug so its most likely the same bug
<calc> pitti: i was running on AC when i was seeing the problem
<ogra> why does it offer me a mode that redirects stdio if it doesnt accept ctrl-c on stdio then :/
<ogra> silly thing
<cjwatson> I recently applied Peter Clifton's patches, but haven't been running for long enough to be certain that they fix the problem for me
<ogasawara> cjwatson: hrm, I'll investigate why the jaunty-buglist is broken.  Feel free to use http://qa.ubuntu.com/reports/ogasawara/qa-jaunty-buglist.html as an alternate view for now
<cjwatson> it feels a bit smoother, but we'll see
<cjwatson> ogasawara: thanks
<ogasawara> cjwatson: http://qa.ubuntu.com/reports/ogasawara/jaunty-buglist.html is back up
<cjwatson> thanks!
<cjwatson> asac: threw an ancient bug over to you, bug 8980
<ubottu> Launchpad bug 8980 in network-manager "hostname -f does not return a proper FQDN" [Medium,Confirmed] https://launchpad.net/bugs/8980
<cjwatson> asac: I'm changing the tag from qa-jaunty-foundations to qa-jaunty-desktop; if you reassign it back for whatever reason, could you set the tag appropriately too?
<asac> sure
<ScottK> cjwatson: I'm not sure how that got pushed to network-manager.  I've seen that on servers with no NM at all.
<cjwatson> ScottK: Well, read my last comment, as there is definitely a network-manager bug
<cjwatson> ScottK: if you think there is an issue with *current* installations, I need the full /etc/hosts file
<cjwatson> in which case it should not be reassigned back from network-manager, but an extra task should be added on netcfg
<ScottK> OK.  Let me check and see if if I stil have it anywhere.
<asac> cjwatson: nm doesnt touch /etc/hosts if you have ifupdown plugin in use. there were times when NM did this during intrepid cycle though.
<asac> anyway, its still a bug
<asac> nm seems to behave not properly for debian when you enable the "update host" feature
<cjwatson> asac: That explains why I can't trigger it now, certainly; but we should bring that code into line with current practices just in case
<asac> which isnt the default hough
<ScottK> cjwatson: Does a hardy box count as a 'current' installation?
<cjwatson> ScottK: yes
<cjwatson> current enough to be interesting, anyway
<asac> cjwatson: you should be able to reproduce by disabling ifupdown in /etc/NetworkManager/nm-system-settings.conf
<asac> and killall nm-system-settings afterwards
<cjwatson> ScottK: (reload the bug and look at my last comment)
 * ScottK looks
<calc> is there a way to restore evolution backup on a new install without having to 'setup' evolution again first?
<ScottK> cjwatson: Added to the bug.
<calc> i have the backup but it won't let me get to the point to restore it without setting it up first afaict
 * calc thinks this was a bit of a oversight by developers
<calc> doh i see it is there
<calc> nevermind
<calc> you just have to go past the first page to get to it :)
 * calc doesn't recall seeing that page the last time he had to do a restore
<cjwatson> ScottK: that log shows, from postfix configuration:
<cjwatson> Jan 26 16:41:46 in-target: setting destinations: mailout02.controlledmail.com, mailout02, localhost.localdomain, localhost
<cjwatson> ScottK: which sort of suggests that hostname --fqdn worked at installation time - where else would it get that?
<ScottK> Interesting.
<cjwatson> ScottK: is it possible that anything else could have deleted the FQDN from /etc/hosts?
 * cjwatson goes to have a poke at netcfg
<ScottK> I don't have any non-packaged software on that box except a few scripts that definitely aren't doing that.
 * ScottK can't think of anything unusual installed there.
<cjwatson> it *is* possible for netcfg to write it that way, admittedly
<cjwatson> I'm just wondering how postfix got it
<ScottK> I think it may come up in a debconf question for postfix
 * ScottK tries to remember
<cjwatson> ScottK: it looks like static networking; can you confirm?
<ScottK> Yes. It's static
<lamont> --fqdn comes from resolv.conf comes from dhcp...
<cjwatson> ScottK: OK - and can you attach /etc/resolv.conf?
<cjwatson> lamont: no DHCP
 * lamont is in meeting
<ScottK> cjwatson: Sure.  Getting.
<azimutt> buenas
<apw> jerone, about?
<ScottK> cjwatson: Added resolv.conf to the bug.
<ogra> dpkg-preconfigure: unable to re-open stdin:
 * ogra wonders if that should worry him
<ScottK> cjwatson: I did confirm that there's s debconf question in the postfix setup that might explain it having that information.
<cjwatson> ScottK: looks like the domain wasn't set at netcfg time. Final question, I hope; /var/log/installer/cdebconf/questions.dat?
<ScottK> cjwatson: Attached.
 * calc notes 8.10 is now not working for him either stupid iwl3945 isn't connecting anymore
 * calc hopes 9.04 ends up being more reliable than 8.10 wifi
 * calc has had trouble with 8.10 wifi many times and didn't need it to happen again today
<ScottK> calc: Did you try the kernel in -proposed?
<calc> ScottK: i think evolution in proposed ate my system so i was trying to avoid using proposed anymore
<ScottK> Generally a good rule, but IIRC there are some 3945 fixes in it.
<calc> hmm ok i'll see if i can somehow selectively upgrade just the kernel
<LordMetroid> Does Evolution need to be installed?
<calc> LordMetroid: if i want decent imap support, well in this case just slightly more decent than thunderbird
<LordMetroid> I've never found such an application relevant to my interests...
<ScottK> calc: Enable proposed and then apt-get install the appropriate kernel metapackage
<LordMetroid> But if I try to remove it, the package manager wants to remove whole gnome...
<LordMetroid> Is this a bug?
 * calc is going to test -7 first then maybe upgrade to the one in proposed
<calc> LordMetroid: hmm did you try removing evolution or evolution-data-server?
<calc> LordMetroid: e-d-s is used by gnome in general but i think you probably should be able to remove evolution the app
<lool> cjwatson: When starting a vm with init=/bin/sh and a rootfs created with debootstrap --foreign, if I launch debootstrap's second state directly it fails installing base-files and base-passwd because dpkg insists on PATH being set
<lool> cjwatson: Simply typing export PATH in such a shell is enough to allow installation; do you think this should a) be done in debootstrap b) be allowed in dpkg or c) left to the end-user?
<cjwatson> how come PATH isn't set?
<lool> cjwatson: The shell sets it, but it's not exported by default
<lool> the default value of PATH is sane BTW
<cjwatson> even the kernel sets PATH when invoking processes
<calc> is all that i need installed via apt-get install linux-generic to go to the proposed kernel?
<cjwatson> ah, although not while invoking pid 1
<lool> Eh
<cjwatson> lool: I think it should be exported by default in the shell
<lool> cjwatson: So it's a /bin/sh issue?
<lool> I think that makes sense
<cjwatson> yes, it sounds like a dash bug to me. It's the sort of thing you don't normally notice
<cjwatson> because almost every process gets PATH from its parent, and thus already exported
 * lool tries to find out how to fix this in dash
<ogra> cjwatson, lool, unlikely to be a dash bug, i know the mojo guys had the same issue (and they explicitly excluded dash in debootstrap)
<calc> grr same issue with -11
<lool> It's unlikely to be a dash bug but they excluded dash?
 * calc kicks 8.10 kernel :-\
<ogra> lool, they had the same issue even dash wasnt installed in the target
<ogra> lool, so it's either dash and bash or something lower level
<ogra> lool, http://www.handhelds.org/hypermail/mojo/0/0011.html
<ogra> > export PATH=/bin:/sbin:/usr/bin:/usr/sbin #VERY IMPORTANT otherwise dpkg
<ogra> > fails.
<ogra> and they run sudo debootstrap --verbose --arch arm --foreign --exclude=dash
<lool> Hmm doesn't seem too hard to fix fortunately
<calc> i keep getting wlan0: link timed out in the daemon.log
<calc> and it never connects to my AP
<ogra> remove the tinfoil wrap :)
<calc> it worked fine until 8.10 started acting up yesterday then it was fine with 9.04 but 9.04 had issues with xorg
<calc> hmm maybe i can carefully install the 9.04 kernel
<calc> any danger in using it?
 * ScottK knows at least one person who's done that.
 * ScottK waves to milli.
 * milli looks up ...
<ScottK> Aren't you running Intrepid with 2.6.28?
<calc> milli: did jaunty kernel help you?
<milli> I'm running 2.6.28.4 linux-image with Intrepid...  only real trick is you have to bring over the source of glibc and recompile and install
<calc> eh?
<calc> you have to recompile glibc?
<lool> Keybuk: I see that dash mentions Vcs-Git: http://smarden.org/git/dash.git/; couldn't find an Ubuntu branch in there though; should I strip it?
<milli> Jaunty kernel fixed all my network file system issues...  I had been having problems since 2.6.22
<lool> or s/Vcs-Git/Original-&/
<milli> glibc and the kernel are pretty tightly intertwined... unfortunately.  It's not very hard tho
<Keybuk> lool: dunno, I tend to leave those alone
<Keybuk> XSBC-Original-* isn't it?
<lool> XS- for sure, don't think we need B and C
<savvas> let
<lool> Keybuk: Problem with leaving them is when people use debcheckout or apt-get source
<savvas> *let's hope they fix the problems with atheros wireless cards as well :P
<lool> The latter will warn and the former will do the wrong thing
<Keybuk> lool: I guess
<Keybuk> shouldn't there be an update-maintainer a like that sorts this out?
<Keybuk> indeed, shouldn't update-maintainer do it? :p
<milli> calc: do you need sepcific instructions on how to do it?
<lool> It should, I even thought of fixing that script, but it slipped my mind as I don't use it
<milli> specific even
<calc> milli: no, hmm it seemed to work here without needing a glibc recompile, what happens without updating glibc?
<calc> and immediate connect without problem on jaunty kernel, yipee
<milli> you may get random crashes or hangs is all  ;-)
<calc> milli: sounds like 8.10 already to me ;-)
<LaserJock> Keybuk: how would update-maintainer be able to do it in any automated way?
<milli> I've never tried backporting a more recent kernel without re-compiling glibc
<LaserJock> Ubuntu bzr branches are sort of spread around
<Keybuk> LaserJock: if it's not bzr, on /ubuntu/ and on lp - move it out of the way ;)
<milli> but it may be "good enough" w.r.t. changes between 2.6.27 and 2.6.28 that you'll be fine.
<calc> milli: i used to run dev kernels all the time without doing glibc backports (back in 2.5 timeframe)
<pochu> bryce, tjaalton: hi folks, could you have a quick look at bug 287542 and tell me if it's an application bug or an X one?
<ubottu> Launchpad bug 287542 in gtk-vnc "vinagre crash with "BadRequest (invalid request code or no such operation)" when I try to connect to VNC server" [High,Confirmed] https://launchpad.net/bugs/287542
<LaserJock> Keybuk: but we don't yet have a complete standard for VCS, unlike for the maintainer field
<bryce> pochu: ok
<Keybuk> LaserJock: we do
<Keybuk> Bzr, Launchpad-hosted, owned by ~ubuntu-core-dev for main, ~ubuntu-dev for universe, against the package name and /ubuntu as the branch name
<LaserJock> I don't think that's actually right though
<Keybuk> lp:~ubuntu{-core,}-dev/$PACKGE/ubuntu
<bryce> pochu: application error
<LaserJock> it's mostly right
<pochu> bryce: ok, thank you!
<bryce> pochu: like it says in the error message, "This probably reflects a bug in the program."
<Keybuk> LaserJock: that's the standard, and what we're pushing towards
<milli> calc: I just like machines where uptime shows 3 digit figures and the word "days"...  ;-)
<pochu> bryce: ah, right
<pochu> bryce: unfortunately it seems to be in a library :/
<LaserJock> Keybuk: but I believe KDE for instance, doesn't use ~ubuntu{-core,}-dev
<pochu> libgtk-vnc
<Keybuk> milli: security experts like them too, they're good places to break into for the latest virus
<Keybuk> LaserJock: that's wrong then
<calc> milli: heh well i generally reinstall every 6 months anyway so i don't get uptime that long
<LaserJock> Keybuk: why?
<Keybuk> LaserJock: because it means a member of ubuntu-core-dev cannot change kde packages
<LaserJock> right
<Keybuk> which is wrong
<Keybuk> we don't have maintainership in Ubuntu in that way
<LaserJock> but it means that none ubuntu-dev can change packages
<Keybuk> (though it's worth noting that with archive reorg, the team part gets wider)
<Keybuk>  so I wouldn't check the team bit either for nwo
<LaserJock> Edubuntu will likely do the same thing
<LaserJock> I think Xubuntu does the same
<bryce> pochu: probably the lib is making an X call that the driver doesn't actually support
<milli> Keybuk: good point... although kernel security issues still aren't all that frequent
<Keybuk> LaserJock: it's certainly true that they don't use git though ;)
<milli> I don't count ssh upgrades or apache upgrades in machine uptime ;-)
<jdstrand> milli: they are nearly monthly :P
<Keybuk> so we could move non-Vcs-Bzr-on-lp out of the way <g>
<Keybuk> milli: by my count, there's been roughly one kernel security update a month over the past year
<milli> jdong: I guess I need to pay more attention then
<milli> jdstrand: oops
 * milli raises eyebrows, wonders what mailing he's not on and should be on
<Keybuk> milli: ubuntu-security-announce
<jdstrand> ubuntu-security-announce
<milli> ty
<Keybuk> also ubuntu-uptime-is-not-a-dicksize-measurement ;)
<RainCT> lol
<directhex> woo, mono session in classroom soon :o
<milli> how's this for scary...
<milli>  12:20:45 up 281 days, 23:18,  1 user,  load average: 0.40, 0.14, 0.10
<RainCT> arr those mono transitions are starting to become annoying
 * milli is a slacker
<directhex> RainCT, the gnome# one was an unexpected problem
<calc> milli: when i installed the headers it automatically upgraded libc6 as well
<milli> calc: you should be good then
<milli> I just wanted to make sure to avoid pulling in other packages from jaunty...  I pulled in 2.6.28 back in December
<cjwatson> ogra: more likely to be a bug common to both dash and bash
<lool> Yeah it is
<ogra> probably ... just wanted to point out that they have it in bash
<lool> I just fixed it for dash
<lool> It took me a while because for some reason init=/bin/sh spawns a bash despite /bin/sh being a symling to dash
<ogra> heh, my build-arm-rootfs script shrinks every day by a line :)
<ogra> yesterday i dropped mknod, today i can drop the PATH setting :)
<lool> cjwatson: http://paste.ubuntu.com/108351/ I'm going to reboot before uploading though
<cjwatson> lool: makes sense
<lool> Now if I could understand why init=/bin/sh launches bash...
<ogra> lool, filesystem issue ?
<ogra> what do you use in your image ?
<lool> ogra: ext3
<ogra> hmm, not then ...
<lool> ogra: Even running the system if I ls -l /bin/sh I see dash
<ogra> indeed
<lool> After the debootstrap it now runs dash instead of bash
<ogra> is e2fstools installed in the first or second run ?
<ogra> the only thing i can imagine is that it has to do with the filesystem ...
<cjwatson> e2fsprogs is Priority: required and thus installed in the first stage. (It has nothing to do with how the kernel interprets filesystems anyway ...)
<lool> Perhaps I misread /bin/sh -> /bin/dash which was really /bin/bash; /me redoes a bootstrap
<lool> Right
<lool> lrwxrwxrwx 1 root root 4 2009-01-22 21:00 rootfs2/bin/sh -> bash
<ogra> ah
<lool> I probably wanted to read dash but it was bash
<lool> So when you run second stage it's in bash
<cjwatson> oh, because of the complex way the symlink is handled
<cjwatson> nothing much to worry about I think
<lool> cjwatson: Yeah I was just confused and wanted to find out, but I found out that it was just me :)
<directhex> mono session now on! gogogo :p
<superm1> Keybuk, what's your opinion about applications calling 'udevadm trigger'?  I'm looking over an old bug (bug 262974), and remembering that one of the cases that causes it is because dkms calls 'udevadm trigger' to replay devices in case one of  the devices is now supported by a newly built kernel module
<ubottu> Launchpad bug 262974 in network-manager "[MASTER] networkmanager display connections twice in intrepid" [Medium,Confirmed] https://launchpad.net/bugs/262974
<apw> jerone, ping
<Keybuk> superm1: NEVER EVER DO IT
<Keybuk> in fact, you could be responsible for a major upgrade bug for jaunty
<Keybuk> minor effects of trigger:
<Keybuk>  - network manager showing multiple copies of the devices
<Keybuk> major effects of trigger:
<Keybuk>  - mounted disk drives being "corrupted" until a reboot
<Keybuk> upgrade issues:
<Keybuk>  - if you trigger during an intrepid->jaunty upgrade, your entire /dev will become root:root/0660
<ScottK> Is any of this in Intrepid?
<Keybuk> yes
<Keybuk> you can demonstrate this quite effectively
<Keybuk> if you have more then just / mounted
 * ScottK is having something very much like "mounted disk drives being "corrupted" until a reboot" recently
<Keybuk> run udevadm trigger a few times and peek in one of your mounted disks
<Keybuk> like /usr /var or something
<Keybuk> at some point, it'll declare data error or something
<Keybuk> superm1: *please* get rid of that udevadm trigger asap
<Keybuk> superm1: I would even declare this an SRU candidate
<Keybuk> you can simply modprobe the module, you know? :)
<cjwatson> so what about the installer's uses of udevadm trigger to make sure that the device is actually available before continuing? I still have never seen a good replacement for that
<Keybuk> cjwatson: e.g.?
 * ScottK admits to being in over his head and hopes for some fixoring.
<cjwatson> partitioning: wait for devices to be available before we try to mount them
<cjwatson> or mkfs them
<Keybuk> how does udevadm trigger help you there?
<Keybuk> trigger doesn't wait for anything
<cjwatson> trigger+settle
<Keybuk> you mean settle, don't you? :)
<Keybuk> well, the settle is quite correct in the installer case
<Keybuk> the trigger isn't
<Keybuk> but the installer is cut down enough that the trigger probably doesn't do any damage - just slows things up
<cjwatson> so if I take that trigger out and it breaks, you'll help me debug it? :-)
<cjwatson> in the context of ubiquity, the trigger might well run with mounted filesystems
<Keybuk> always ;)
<Keybuk> yeah, trigger on mounted filesystems is bad
<cjwatson> ok, changed it in my local tree and will test later
<Keybuk> we run a whole bunch of things on the filesystem, and if the filesystem changes under it, we can end up unmounting it or declaring it corrupt ;)
<cjwatson> how does udev manage to declare a filesystem corrupt in such a way that the kernel notices?
<Keybuk> not udev, devmapper
<cjwatson> interesting
<Keybuk> it does something inside the kernel
<Keybuk> I didn't debug much further admittedly
<Keybuk> trigger is a one-time only boot-time tool
<Keybuk> if you really must hammer your system
<Keybuk> udevadm trigger --action=change
<Keybuk> is safe
<Keybuk> the default (action=add) is _not_ safe, you're adding duplicate devices for everything
<cjwatson> are uevents guaranteed to be in udev's queue after modprobe?
<ogra> and settle will now work without explicitly triggering ?
<Keybuk> ogra: settle always works
<ogra> i remember you had to call trigger first before
<cjwatson> I mean, can the following happen? modprobe; udevadm settle "nothing to do"; "oh hey, an event arrived"
<Keybuk> ogra: you've never had to call trigger first
<ogra> oh
<Keybuk> cjwatson: at least one uevent is guaranteed to be in udev's queue
<Keybuk> but it's probably not the one you're after
<cjwatson> you know, I'm going to go and search logs at some point, because I swear you advised me to use trigger; settle originally
<Keybuk> modprobe <entire subsytem>; udevadm settle
<Keybuk> won't usually wait for devices on that subsystem
<cjwatson> so we *do* need udevadm trigger --action=change to make sure?
<Keybuk> cjwatson: no, you shouldn't need trigger at all, ever
<Keybuk> if udev is running, trigger is only telling it what it already knows
<cjwatson> let us say that we want to wait for devices on that subsystem
<cjwatson> for example, d-i's hardware detection loads subsystems and then wants to check whether you actually have any disks
<cjwatson> (so it can produce a useful error message rather than a blank partitioner)
<Keybuk> how many devices are you waiting for?
<cjwatson> completion; I'd like the kernel to be finished probing the bug
<cjwatson> bus
<Keybuk> err
<Keybuk> which bus are you thinking of? :)
<cjwatson> whatever it's currently looking at
<Keybuk> there's no such concept for most of them
<cjwatson> I suppose this is why the initramfs has that crappy sleep 300
<Keybuk> "probing" USB for example is just raising a voltage on the cable
<Keybuk> at some point, whatever devices are connected will draw some of that power and start asking for some more
<cjwatson> ok
<Keybuk> and at that point, you go "oh look, a device"
<Keybuk> there's no "and all devices that are connected are up" type event
<cjwatson> I'll probably have to rewrite disk-detect's check at some point
<cjwatson> can I just double-check the partitioning case with you? that's very important
<kees> (any reason eSATA drives don't auto-mount?)
<cjwatson> we already have the disk device, by definition
<Keybuk> sure
<cjwatson> we do whatever the block device ioctl is to get the kernel to reload the partition table
<Keybuk> yup
<Keybuk> and the kernel will change the partition table
<Keybuk> (or fail the ioctl)
<cjwatson> when that ioctl returns, will there be a uevent in the queue for the new partition devices?
<Keybuk> that reorganises /sys for that device
<Keybuk> and issues "remove", "add" and "change" uevents to udev for the partitions
<Keybuk> which udev grabs, and runs things like vol_id on
<cjwatson> right - I just need to know whether those uevents are issued (over netlink?) before the ioctl returns
<cjwatson> so that the settle is correct as a sequence point
<Keybuk> one moment
<lool> Riddell: I see you have split libwmf in two; did you seed it?
<Keybuk> BLKRRPART has a BKL around it, so there's a reasonable chance
<lool> Riddell: Cause otherwise we'll lose wmf support in Gtk+
<cjwatson> (maybe you can show me at the sprint how to check this; I have no problem grovelling around in the kernel but don't know the driver core well)
<cjwatson> Keybuk: I think we actually use BLKPG_ADD_PARTITION
<lool> Riddell: Don't know how widespread it is, but it's something which refrained me from doing the split :)
<cjwatson> (rather, remove* add*)
<Keybuk> really? fdisk doesn't
<cjwatson> parted does
<cjwatson> potentially also DM_DEVICE_CREATE for devmapper devices, whatever that turns into in ioctl terms
<Keybuk> ok
<Keybuk> well
<Keybuk> BLKRRPART, BLKPG_ADD_PARTITION and BLKPG_DEL_PARTITION are all deliberately safe
<Keybuk> the uevent will be in the queue and the /sys nodes updated when the ioctl returns
<Keybuk> DM_* are also safe
<cjwatson> ok, excellent
<Keybuk> you may obviously want to use udevadm settle to make sure
<Keybuk> a) udev has taken the event and made the device
<Keybuk> b) and isn't running vol_id or anything on it right now ;)
<cjwatson> indeed
<cjwatson> BTW, is this a change I should be pushing to Debian, if you know the udev/kernel differences well enough to say?
<Keybuk> yes
<Keybuk> this should be completely compatible ;)
<cjwatson> I'll have to do some detailed checks of update-dev uses
<Keybuk> there were some fixes in "recent" kernel history
<Keybuk> (around the .22 mark)
<cjwatson> but at least I only need to change one place
<cjwatson> Debian's on 2.6.26 now
<Keybuk> but those fixes look like they were limited to making sure that the partitions of a disk were also available before the disk event
<Keybuk> you actually get the uevents in the order
<Keybuk>  sda1, sda2, sda3, sda
<Keybuk> which seems backwards, but is in practice exactly what you want
<Keybuk> (so you can get the disk event and check for partitions)
<Keybuk> with most modules
<Keybuk> when the modprobe returns, the core objects of the module should be available in /sys and uevents queued
<lool> cjwatson: And that'd be the bash patch http://paste.ubuntu.com/108362/
<Keybuk> if the module claims a device, that should have been updated
<Keybuk> (but it may be waiting on firmware before things like class devices show up)
<Keybuk> if the module is a subsystem, /sys/bus/nnn should exist, but devices may not
<cjwatson> lool: it is suspicious that it's #if 0-ed out in bash
<cjwatson> lool: it might be worth chasing down why
<Keybuk> \o/
<Keybuk> from mdz's upgrade log
<Keybuk> Examining /etc/kernel/postinst.d.
<Keybuk> run-parts: executing /etc/kernel/postinst.d/dkms
<Keybuk>  * Running DKMS auto installation service for kernel 2.6.28-4-generic       [80G
<Keybuk>  *  nvidia ()...       [80G nvidia (): AUTOINSTALL not set in its dkms.conf.
<Keybuk> ...
<Keybuk> superm1: I'm so beating you into a pulp next time I see you ;-)
<lool> cjwatson: I see the change mentionned in CHANGES, but no rationale:
<lool> w.  Bash no longer auto-exports HOME, PATH, SHELL, or TERM, even though it gives them default values if they don't appear in the initial environment.
<lool> (bash-2.05a-rc1)
<cjwatson> lool: Chet Ramey's usually pretty responsive if you mail him, I think
<lool> cjwatson: thanks for the hint
<cjwatson> ScottK: it looks very much as if you simply didn't tell netcfg your hostname at installation time, but only told postfix
<cjwatson> the only match for "controlledmail.com" in questions.dat is for postfix
<superm1> Keybuk, OK i'll change that behavior.  I'll do an SRU for just that change too in Intrepid.
<Keybuk> superm1: bug #320200 btw
<ubottu> Launchpad bug 320200 in dkms "Never call udevadm trigger!" [Critical,Confirmed] https://launchpad.net/bugs/320200
<superm1> Keybuk, yeah just saw it in bug mail.  i'm doing another DKMS release with a handful of other stuff, and will fit it in there
<superm1> Keybuk, where  is mdz's upgrade log?  I have a suspicion what happened there but would like to verify
<kees> whoa.  I'd never seen this C convention before:   argv[0] ?: "unknown"     I thought you always had to have stuff between ? and :
<Keybuk> kees: gcc extension
<kees> Keybuk: ah-ha.
<Keybuk> kees:
<Keybuk> The middle operand in a conditional expression may be omitted.  Then if
<Keybuk> the first operand is nonzero, its value is the value of the conditional
<Keybuk> expression.
<Keybuk> superm1: bug #317944
<ubottu> Launchpad bug 317944 in udev "Wrong permissions in /dev after Intrepid->Jaunty upgrade" [Undecided,Fix committed] https://launchpad.net/bugs/317944
<superm1> Keybuk, okay thanks
<TheMuso> tjaalton: hrm I'll have to update my jaunty install and try again. Failing that, I'll do a fresh install and try again as well.
<maxb> The jaunty-added "Recommends: gnome-dbg" in bug-buddy means that a lot of -dbg packages get installed on upgrade. More interestingly, I've uninstalled evolution - but this Recommends chain pulls it back in on upgrade. Are these things that I should be reporting, and if so where, since they are general dependency mesh issues rather than relating to a particular package
<Keybuk> cjwatson: kernelwise, I guess I'm starting to understand kernel source fairly well these days ;)
<calc> bbl, seagate finally released a firmware for the 7200.11 that won't brick it
<calc> time to update my drive before it dies
<directhex> good luck
<mar77i> maybe somebody can give me a hint here: http://pastebin.com/m54d87294
<ScottK> cjwatson: I'm pretty sure if I didn't tell it the domain, I didn't get asked.  I have a vague recollection of it working with some combinations of network/no-network, dhcp/no-dhcp, and rDNS or no rDNS, but not which.
<tjaalton> TheMuso: ok, thanks
<cjwatson> ScottK: I believe you're meant to type in the FQDN at the hostname prompt
<cjwatson> maybe it isn't as clear as it might be
<calc> my drive now won't die well immediately anyway :)
<directhex> you hope
 * directhex hugs his samsung
<calc> directhex: there are ways to revive them if they do die but it involves hooking up to the drives serial port (not sata port)
<primes2h> pitti: Hello.
<primes2h> pitti: I have the correct debdiff
<directhex> calc, yay for 38k baud!
<primes2h> Could you have a look please? http://pastebin.ubuntu.com/108387/
<calc> directhex: heh, yea you just have to type a few commands into the drive to reset it
<TheMuso> Drives have a serial port? THis is new to me.
 * TheMuso doesn't think he's see it.
<calc> TheMuso: there are a few pins next to the sata port its rx/tx for a serial connection at least on seagate drives
<TheMuso> ah ok.
<calc> TheMuso: 'undocumented' pins ;-)
<TheMuso> ah
<calc> TheMuso: you can do some interesting things in there if you find the manual, including wiping the smart sector
<TheMuso> ouch
<calc> er what happened to gweather in jaunty, you can't select which weather station to use in a city anymore
<calc> is this considered 'improvement'?
<slangasek> haha
<slangasek> gweather, a comedy of errors in three acts
<calc> a place like houston is ~ 1000 sq.mi. and only having 'Houston' as an option isn't particularly useful
<ScottK> cjwatson: I'll try and carve out some time to dig back into it.
<dtchen> bryce: does 315971 persist in current jaunty?
 * bryce looks
<bryce> dtchen: I'll need to update to latest first; I'll do that and report findings on that bug
<dtchen> bryce: thanks
#ubuntu-devel 2009-01-23
<NCommander> pitti, ping?
<StevenK> NCommander: If pitti isn't sleeping, I'd be suprised.
<NCommander> ah, right
 * Hobbsee wonders what the current 'central time' is.
<stgraber> CET is 1:30am
<stgraber> (in EST :))
<superm1> Hobbsee, CST is 18:31
<stgraber> hmm, what I just said doesn't make any sense ...
<StevenK> % TZ=US/Central date
<StevenK> Thu Jan 22 18:32:19 CST 2009
<slangasek> $ TZ=CEST date
<slangasek> Fri Jan 23 00:32:51 UTC 2009
<stgraber> slangasek: isn't CEST Central Europe Summer Time ? making it non-existent at this time of the year ?
<slangasek> maybe :)
<slangasek> that might explain why it shows an hour earlier than if I type 'CET'
<stgraber> probably explains why the TZ in your date's output is UTC and not CEST as it should have been if the timezone existed
<slangasek> well, that's simply because /usr/share/zoneinfo/CEST doesn't exist. :)
<StevenK> Yeah, date has a "feature" if the timezone doesn't exist, then it must be UTC
<Hobbsee> hrm, OK, thanks.
<Hobbsee> 2am meeting. damn.
<StevenK> OpenWeek isn't so friendly for the Australian timezones this time around
<Hobbsee> nah, release team meetings
<Hobbsee> and what do you mean *this* time around?  They're not friendly *any* time around.
<StevenK> I was trying to remember ...
 * StevenK mumbles something about caffeine
<Hobbsee> they always start at 1600 utc or so.
<Hobbsee> heh, caffeine.  If only that would work in this house... ;)
<refdoc> Hi, I am one of the developers of a programme which is as a package in Ubuntu  The package you have is ancient. It is very frustrating for us as we get constantly bug reports for ancient stuff from ubuntu users,. The maintainer listed does not respond to our emails. What is the mechanism to get him/her removed and replaced by someone from us?
<cjwatson> we generally maintain packages as a group in Ubuntu rather than having individual maintainers. You may be seeing the Debian maintainer listed.
<asomething> refdoc: what is the package? do we inherit it from debian?
<refdoc> So what shall we do?
<cjwatson> is there an Ubuntu bug filed about this?
<refdoc> Gnomesword, libswrod diatheke
<refdoc> yes
<refdoc> multiple
<refdoc> I think you inherit from debian
<cjwatson> as we do with the vast majority of our packages, yes
<calc> refdoc: has a bug in debian been filed yet?
<refdoc> one of our guys maintains for years now his own repository
<refdoc> not sure
<refdoc> never looked yet
<calc> refdoc: ok
<refdoc> but people say even there they complain
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463207
<ubottu> Debian bug 463207 in gnomesword "gnomesword: new version available" [Wishlist,Open]
<cjwatson> Debian is frozen for release at the moment, of course
<refdoc> Is it now always frozen? :-)
<cjwatson> no. :-P (Note that many people in this channel work on Debian too.)
<calc> refdoc: no it was not frozen when that bug was filed
<refdoc> Sorry that was an attempt at a joke
<refdoc> so, what shall we do
<cjwatson> it would probably be fine for us to update, but it needs an enthusiastic Ubuntu developer to step up and do it. mail ubuntu-motu@lists.ubuntu.com which is a good place for that kind of thing
<refdoc> one of us maingtains his own packages for years
<refdoc> they are good and work immediately fine on clean installs
<refdoc> ok I will email there
<refdoc> thanks
<cjwatson> no offence to your developer but we do always like to make sure of things ourselves :-)
<cjwatson> sometimes people who work on the distribution have a better idea of what needs to be got right in certain areas, so it's always worth having a distro expert look it over
<refdoc> Aye, no problem, but your packages are now two years out of date in this particular case
<calc> refdoc: if you don't get any hits from there after a week or so you can email me ccheney@ubuntu.com and i'll try to take a look at it (i'm pretty busy most of the time though)
<cjwatson> not saying that's why the package is still at an old version - that's almost certainly because Daniel Glassey ran out of time
<refdoc> great calc!
<cjwatson> I can maybe ask around in debian-uk and find out if he's still active
<calc> i'm sure my father in law would like to run that program and an up to date version would be good ;-)
<calc> i'm supposed to be finishing up his system as soon as i get some spare time
<refdoc> we are moving to 3.0 release, the version you have is 2.1 or 2.2
<refdoc> ok thanks a lot to everyone!
<slangasek> cjwatson: ISTR he was presumed MIA except that he appeared in person at DebConf 7...
<calc> he came to debconf but doesn't actually update his packages, weird :-\
<arpu> hello i have the problem with ubuntu 8.10 and intel  945GM
<arpu> GL_RENDERER   = Software Rasterizer
<arpu> GL_VERSION    = 2.1 Mesa 7.2
<arpu> GL_VENDOR     = Mesa Project
<arpu> i found a lot of posts and bug reports for ubuntu but nobody knows a solution
<arpu> the only solution is to wait for  jaunty but i can not update my stable installation
<arpu> mybe some knows anything on this problem
<arpu> one of the bug reports https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/252094
<ubottu> Launchpad bug 252094 in xserver-xorg-video-intel "[i965, etc.] Poor graphics performance on Intel" [Wishlist,In progress]
<cjwatson> slangasek: so, apparently Debian has *finally* fixed the grub/xfs problems, and there's a decent chance that we can switch it on again in grub-installer at long last
<cjwatson> slangasek: how hard would a merge be? :-)
<slangasek> oh, really?
<slangasek> a merge of which package?
<cjwatson> grub
<slangasek> grub?
<cjwatson> turned out that (a) the kernel was fixed upstream in around .19/.20 to arrange that xfs_freeze -f doesn't return until I/O is complete (b) grub was doing xfs_freeze -f; write to filesystem; xfs_freeze -u which was completely broken, and xfs_freeze -f; xfs_freeze -u; write to filesystem actually works now that the kernel has been fixed
<cjwatson> or at least so I gather from a while reading Debian #239111
<ubottu> Debian bug 239111 in grub "Install report: Successful install" [Unknown,Closed] http://bugs.debian.org/239111
<slangasek> very hard, the repo is bollocked right now because of a bzr-svn bug :(
<calc> i just noticed that in intrepid there is a im status icon on the right side, why is it there when the same thing is in the tray?
<cjwatson> heh, what a title
 * jelmer wakes up
 * calc hadn't done a full reinstall in a while
<cjwatson> slangasek: yeah, I didn't expect it to be a straightforward bzr merge
<cjwatson> maybe we can just backport that patch, not sure
<calc> is the other im icon not visible enough or something?
<cjwatson> it was only in xfs_freeze.patch, really
<slangasek> cjwatson: well it was meant to be, that's why I put it in bzr! :)
<cjwatson> yeah, but I knew about the bzr-svn problems
<slangasek> jelmer: any progress on that bug which I will refer to with hand-waving because I don't have the number in front of me?
<slangasek> hrm, it's not in my subscribed bugs list
<jelmer> slangasek: maybe; I did fix one bug (for which I had a test case) related to pushing of unrelated merged trees, but there's another issue still remaining
<slangasek> maybe it got fixed and I wasn't watching
<jelmer> slangasek, If you created the combined branch by merging the debian directory into the grub directory, it does not work yet - if you did it the other way around (keeping the tree root from the debian packaging directory), it should work.
<slangasek> ok, then it's going to not work
<jelmer> the bug # is 295416, btw
<cjwatson> slangasek: (and fjp just confirmed that grub/xfs now works on a system where he could previously reproduce the bug, if you're watching #debian-boot)
<slangasek> jelmer: ah, new bug number that I hadn't seen before :)
<slangasek> er, except I'm subscribed so apparently I have
<slangasek> cjwatson: a one-time manual cherry pick, then?
<asomething> calc: there are some threads about that on the desktop list, no urls handy though
<cjwatson> slangasek: yeah, I think so
<asomething> calc: i believe that the idea is to make the fusa conrol global status for im ect eventually
<cjwatson> sounds doom-laden otherwise
<calc> asomething: doesn
<calc> asomething: doesn't sound particularly useful since the IM app is already in the tray
<arpu> re hi i think i found the problem  Virtual 2560 1888 without them all works fine
<calc> asomething: perhaps more gnome crack? :)
<calc> asomething: and the im app (pidgin or telepathy) is already essentially global setting anyway
 * calc has 5 or 6 im protocols running in pidgin and only has one status setting for them
<asomething> calc: I think it's an Ubuntu patch http://www.markshuttleworth.com/archives/233
<calc> asomething: yes, but ubuntu gnome crack ;-)
<asomething> calc: don't you mean innovation? ;-)
<calc> asomething: useless innovation, unless something hasn't been hooked up properly and is just buggy
<calc> i have within 3in of the corner a second IM status icon
<calc> that actually does what it is supposed to... control the IM program
<calc> the screenshot you posted apparently has no running IM client, or something else weird
<calc> its not in the tray
<calc> tedg: ping
 * calc thinks he will just delete it
<calc> yea that works better :)
<slangasek> better than what?
<calc> slangasek: better than a lot of wasted corner screen real estate
 * calc now has the calendar there which he uses much more often than a duplicated IM status widget
<slangasek> oh?  I still have plenty of real estate to spare on my toolbar, so. :)
<calc> i never use fusa and don't need a duplicate im applet so it was completely useless
 * calc wishes someone would fix the clock applet to have radar map support, then i could throw out gweather
<TheMuso> dtchen: I'd be interested in your thoughts re bug 235007, since a quirk already exists for this in upstream alsa, and users are reporting 3stack as a better option...
<ubottu> Launchpad bug 235007 in linux "no sound on Toshiba L40-139" [Medium,Triaged] https://launchpad.net/bugs/235007
<NCommander> hey cjwatson
<bluesmoke> hey RAOF
<RAOF> Howbidie.
<bluesmoke> RAOF: you ever get compiz++ working?
<bluesmoke> the snap port is fixed now
<RAOF> For values of "working" equal to "able to move windows without decoration", yes.
<bluesmoke> well that's creepy to see, snap only stops the window from moving, not the decoration
<bluesmoke> onestone must not have noticed (he fixed it) because he uses kde-window-decorator which does reparenting
<RAOF> Nifty.
<bluesmoke> RAOF: Just build libcompizconfig and compizconfig-python so you can use the ccp plugin and ccsm
<RAOF> Both from compiz++ branch, I take it.
<bluesmoke> I have a feeling you're missing a plugin dependency there or something
<bluesmoke> right
<RAOF> Probably.
<bluesmoke> and make sure you set PYTHONPATH to point to the compiz++ version when you run ccsm
<RAOF> Or just install it systemwide!
<bluesmoke> I'm about to, it's usable now
<RAOF> I might get myself a working GL stack and give it another whirl then.
 * RAOF wishes nvidia was as fast as nouveau.
<bluesmoke> RAOF: If you use kde-window-decorator you just need good RenderAccel and Composite :)
<RAOF> Well, I've got me _that_.
<bluesmoke> Although I dunno if even the minimize plugin works without opengl
<bluesmoke> but move, resize, and snap should work :)
<bluesmoke> Actually with Composite you can use gtk-window-decorator, kwd is only needed if you don't want to use Composite
<bluesmoke> onestone is apparently working on a plugin to handle viewport changes that will work without composite and then other plugins (wall, cube) can plug into it to provide composited and opengl effects to switching
<RAOF> Wouldn't that require you to not unmap the windows on viewport change?  How does that fly with lack of composite?
<bluesmoke> eh? they just go offscreen like they do now
<bluesmoke> viewports were not designed with composited desktops in mind
<RAOF> Hm.  There appears to be a compiz++ branch of only libcompizconfig.
<bluesmoke> RAOF: oh, right, you just have to build the python bindings against that one
<bluesmoke> the ABI changed, not the API
<RAOF> Hm.  How much do I care about protobufs?
<bluesmoke> I haven't done any benchmarks but if compiz++ gains support for it that should solve most of our startup time problems
<bluesmoke> not much, I guess
<bluesmoke> I built it because it was cool though :)
<RAOF> Hurrah for name mangling!  That configure.ac check is a thing of beauty. :l
<dholbach> good morning
<TheMuso> Hey dholbach .
<TheMuso> dholbach: Re sound volume profiles, its not possible afaik.
<dholbach> hi TheMuso
<dholbach> TheMuso: that's fine, alsactl will do what I want to do :)
<TheMuso> dholbach: I thought as much, but I don't know of a GUI equivalent.
<dholbach> ah OK
<dholbach> thanks TheMuso
<TheMuso> np
<RAOF> bluesmoke: So, that kind of works.  Still no decoration, though ;)
<bluesmoke> RAOF: You've got the plugin loaded and you're running the right gtk-window-decorator?
<bluesmoke> RAOF: Perhaps try kde-window-decorator
<RAOF> Oh, yeah.  There we go.
<RAOF> bluesmoke: Hm.  Doesn't actually seem that composite's working.
 * bluesmoke blames your driver
<bluesmoke> apparently intel, fglrx, ati, and nvidia work fine
<RAOF> This has been tested with Composite !OpenGL?
<bluesmoke> RAOF: I think I screwed up and loaded that combo once, yes :P
<RAOF> kde4-window-decorator works, but there 'aint no composite.
<bluesmoke> ok, i see what you mean
<bluesmoke> Apparently Composite doesn't have an XRender internal system, dunno how I missed that
<bluesmoke> RAOF: Hey, you need a fun project? :)
 * RAOF is fairly sure his definition of "fun" does not accomodate adding an XRender backend to compiz.
<RAOF> But I'll put it on the list, right after "Learn Portugese" :P
<bluesmoke> RAOF: Looks pretty straightforward, really
<bluesmoke> If you know XRender, anyway
<bluesmoke> The composite plugin handles basically everything, you just have to hook into it and draw stuff
<calc> bug 320351 (new gnome crack of the day)
<ubottu> Launchpad bug 320351 in gnome-applets "gweather: city options were radically reduced to uselessness" [High,Confirmed] https://launchpad.net/bugs/320351
 * calc should start a blog so he can have a gnome crack of the day meme on it ;-)
 * calc digs in svn to see if there is a reason why they did this
 * ScottK thought reduced options were a Gnome feature?
<calc> lol
<calc> because all cities are small enough the weather is the same everywhere :)
<calc> i found the commit i think
<calc> rev 518 of libgweather
<calc> Don't worry about sub-city locations; people generally aren't going to know which of the locations is closest to them, and the weather reports from all of them should be basically the same anyway.
<calc> bahaha, yea this is true of a city that is 4000 sq km
<bryce> calc, ick
<calc> generally cities only have one weather station if any at all unless they are very large cities, in which case the weather is likely not to be the same
<calc> houston is somewhere in the range of 4000 sq km and has 6 stations (maybe more?) and now they don't even tell you which one it is much less let you choose which one to use
<mininat> hi ! i've been reading the "contribute" pages of Ubuntu's web site and i was wondering if there is any task managment platform for ubuntero ?
<calc> some of the stations listed as 'houston' aren't really houston but are in the houston metro area so get grouped that way
<calc> strictly speaking houston city limits aren't that big but the stations listed for houston are in the huge area
<mininat> any task repatition platform for a devoted want-to-contribute ? :)
<bryce> mininat: welcome!  could you explain what you're looking for specifically?
<mininat> i've checked the contributes pages on the main site, developemnt team
<mininat> i checked the first stage, called "ubuntero"
<mininat> but seems there is no task list or any specific project
<mininat> and i'm looking for one to start contributing
<mininat> see what i can do etc etc
<bryce> ah, most tasks are in launchpad.net
<bryce> mininat: what sorts of tasks in particular are you looking for?
<bryce> bbiab
<mininat> i like hacking my computer, i mean, read docs, looking solutions, scripts things
<mininat> and as i want to go more deep in programming stuff
<mininat> contributing to my system community should be a cool starting point
<mininat> https://launchpad.net/ubuntu/+mentoring
<mininat> that would be a good wau to start according to you ?
<Karnaugh> [0123 09h27.42] real_name = Colin Alston
<Karnaugh> sorry about that
<pitti> StevenK, NCommander: sorry, was away doing some login time measurements, took a while
<pitti> !ping | NCommander
<ubottu> NCommander: ping yourself ;-) really the diodes all down my left side are sore
<pitti> erm
<pitti> I meant to say "Please do not send contentless pings, just ask" :)
<pitti> primes2h: hi
<primes2h> pitti: Hello.
<pitti> primes2h: thanks for working on this
<pitti> primes2h: some comments:
<primes2h> pitti: I have the new correct debdiff
<primes2h> Did you get?
<pitti> - package should drop the old *.icon files, since they are autogenerated now; the Makefile.am's clean rule should do that
<pitti> - changelog should just say "renamed *.icon to *.icon.in and marked description as translatable" or so, instead of putting that long redundant list of new files
<primes2h> In fact I made .icon.in from scratch.
<primes2h> there were no .icon file before.
<primes2h> you mean this? CLEANFILES = $(icons_in_DATA)
<pitti> primes2h: well, there certainly must have been a place before where the C strings came from?
<pitti> are they in the .svg files?
<primes2h> .icon file are created during build and then are cleaned
<pitti> primes2h: it seems wrong to maintain a separate set of files, since that would duplicate the original strings
<pitti> hm, I don't know how emblem translations work
<pitti> gnome-icon-theme doesn't ship *.icon files either
<primes2h> Exactly.
<primes2h> I got that example.
<primes2h> as example
<primes2h> strings are taken from icon.in files that I created.
<primes2h> I mean, it uses icon.in to create .icon files...
<primes2h> strings are probably taken from them,
<primes2h> and finally .icon file are removed.
<primes2h> This is how gnome-icon-theme (and human-icon-theme) works (I'm quite sure)
<pitti> primes2h: so where did the English strings for the emblems came from before?
<primes2h> from the name of the icon.. emblems-important.svg etc...
<primes2h> In fact the name was not in Capital letter.
<_max> dono if this is a bug or not, if i boot 8.10 x86 livecd, i can make changes to /etc/network/interfaces, add /etc/resolv.conf etc, and they are "kept" after actual installation.
<_max> however my /etc/apt/apt.conf was discarded.
<primes2h> have a look at Edit -> Backgrounds and emblems -> emblems
<primes2h> I guess this... but it's the more probable explanation...
<primes2h> I learnt this looking at gnome-icon-them
<pitti> primes2h: "Edit" where?
<pitti> primes2h: so whether it's from the file name or a field in the .svg file, I think the pot should be created from that one instead of a separately maintained .icon.in file
<pitti> otherwise you'd always have to make the same change in two different places
<tkamppeter> pitti, I have answered your question to bug 308817
<ubottu> Launchpad bug 308817 in ghostscript "duplex printing through CUPS no longer works" [Undecided,Fix released] https://launchpad.net/bugs/308817
<primes2h> pitti: Edit in nautilus
<primes2h> pitti: hold on, I'm on the phone.
<pitti> tkamppeter: thanks
<tkamppeter> pitti, then I think you can pass through the 3 -proposed packages, cups, ghostscript, and foomatic-filters
<epicgoo> those .a files in the dev packages use .so files. right?
<epicgoo> you link blah.a to your program and program uses blah.a
<epicgoo> blah.so
<slangasek> epicgoo: no, .a files and .so files are two different things; and this is not really the channel for learning how the linker works
<seb128> pitti: did you try to talk to dobey? he's on #ubuntu-desktop and he's the upstream icon naming specification maintainer and working on gnome-icon-theme, he likely knows about those things
<epicgoo> I know...
<epicgoo> they are different so?
<epicgoo> I am talking about the dev packages in ubuntu
<epicgoo> if you link a blah.a lib to your program (from libblah-dev), will the program use blah.so?
<epicgoo> or those .a files are just static libs
<slangasek> a .a file is a static lib, yes.
<slangasek> with the exception of libc.a, which is a linker script for arcane reasons
<epicgoo> but your program may or may not need the .so file
<slangasek> Not sure what you're meaning to ask.  If your program is statically linked against a library, it doesn't need a shared copy of that library.
<epicgoo> http://en.wikipedia.org/wiki/Library_(computing)#Naming
<epicgoo> linux =/= windows
<primes2h> pitti: icon.in files it's the way gnome-icon-theme works...
<primes2h> pitti: and I think is the best way because it's more flexible...
<primes2h> You can choose the best text to explain the icon purpose.
<primes2h> It's not necessarily the same as icon-name
<primes2h> e.g emblem-CVS-controlled.svg you can choose "CVS controlled"
<primes2h> and you can use capital letter
<primes2h> that it's missing in icon-name.
<primes2h> that is
<primes2h> pitti: In fact if you look at gnome-icon-theme changelog you see that this kind of patch was made on 2004 to add emblem translation...
<primes2h> pitti: By the way I found out another emblem untranslated (emblem-desktop) in 48x48/emblems/ 16x16/emblems/ and 24x24/emblems/
<primes2h> I need to add it in the patch.
<primes2h> pitti: You need icon.in files because POTFILES needs to know where to pick up strings for po files...
<pitti> primes2h: right, but those could be autogenerated from the actual source, like the file names or svg header?
<primes2h> No, that's the problem!
<primes2h> because now what you see on emblem name in the GUI is a sort of fallback because it's not set up for translation
<primes2h> Or better, I don't know but I think it's more complicated...
<primes2h> POTFILES doesn't work this way.
<primes2h> have a look on POTFILES.in
<primes2h> in
<pitti> primes2h: re (sorry, we have the plumber here)
<primes2h> pitti: no problem :-)
<pitti> primes2h: what I meant is: autogenerate .icon.in from the original source, then use the inltool magic to create the .pot, and throw away the .icon.in/.icon again
<primes2h> Ah, ok. It probably can be done adding code I think, but it could be a problem if, for some reason, you need to change strings name, in that case you should change .svg name
<primes2h> and it's worse
<primes2h> .icon.in files are present in gnome-icon-theme source
<primes2h> one for each svg
<primes2h> and moreover you should change linkname on each file where svg files are mentioned.
<pitti> primes2h: that's exactly what I was heading to; if you change the .svg's name, you have to remember changing the .icon.in
<pitti> .icon.in is derived information, it shouldn't be something that has to explicitly be maintained?
<primes2h> Following gnome-icon-theme changelog, you have to manage .icon.in manually (adding, removing, changing) and the correspondent Makefile.am
<pitti> hmm
<primes2h> They are needed to mantain separated code from translation things...
<primes2h> To keep all clearer...
<pitti> primes2h: but if the .icon.in file is the definitive place for the strings, then they would need to be shipped in the gnome-icon-theme package?
<primes2h> In fact they are.
<primes2h> :-)
<primes2h> Have a look at the source...
<pitti> ah, I see
<pitti> and of course again with statically replicated translations
<pitti> those spread faster than we can squash them *sigh*
<primes2h> :-)
<mib_p8yxoe6r> hi
<primes2h> pitti: In fact they are not replicated, because some strings in .icon.in are different from the svg-name (e.g. emblem-important.svg -> Important (with capital letter in .icon.in), and emblem-cvs-added.svg -> CVS added (in .icon.in))
<pitti> primes2h: ok, I see now
<pitti> primes2h: so, that looks fine then
<pitti> primes2h: mind to attach the current debdiff to the bug and subscribe me? I'll review/sponsor it
<primes2h> Ok, I just need to add emblem-desktop in 48x48(24x24,16x16)/emblems that I forgot to set up
<primes2h> Thank you! and what about changelog?
<primes2h> Do you think it's too long with all icon.in files?
<primes2h> In my opinion it's needed to keep trace of changing...
<primes2h> pitti: What do you think?
<pitti> primes2h: you could just say "Added *.icon.in: Explanation..."
<primes2h> pitti: ok! Other changes?
<pitti> primes2h: should be alright; I'll give it another review once it's attached to the bug
<pitti> primes2h: thanks for bearing with me and explaining everything
<primes2h> That's nice, thank you very much for all.
<primes2h> pitti: Just one last thing...
<primes2h> This patch expose also another bug already present in human-icon-theme, that kwwii told you yesterday...
<primes2h> pitti: bug #319991
<ubottu> Launchpad bug 319991 in human-icon-theme "Strange behaviour of some emblem icons." [Undecided,New] https://launchpad.net/bugs/319991
<primes2h> pitti: just to remaind you... :-)
<pitti> primes2h: let me ask Ken
<pitti> primes2h: ah, I guess I know
<pitti> it should be named stock-mail, not stock_mail
<primes2h> pitti: ask Ken, I am puzzled because the icon doesn't exist and I don't know where it looks for the name...
<primes2h> pitti: I go away for lunch, see you later...
<mib_730riq17> hi
<mib_730riq17> how to use autoconf and automake to change the configuration file of an existing project?
<mib_730riq17> Please give alink so that I can read and know the use of autoconf and automake
<cjwatson> the autoconf-doc and automake packages include extensive info documentation for those tools; 'info autoconf', 'info automake'
<mib_730riq17> cjwatson: thanx
<cjwatson> the autoconf documentation is also in /usr/share/doc/autoconf-doc/autoconf.html if you prefer that
<cjwatson> the automake documentation is only installed as info, but is available online as HTML in http://www.gnu.org/software/automake/manual/automake.html
<mib_730riq17> cjwatson: do the change in configure.in file needs automake( it needs autoconf)..
<mib_730riq17> cjwatson: thanx for the valuable links
<cjwatson> mib_730riq17: that depends on the project. Some do, some don't
<cjwatson> mib_730riq17: you should generally use autoreconf rather than running the individual tools
<mib_730riq17> cjwatson: autoreconf thats a new tool I heard now???Is it installed along with autoconf?
<mib_730riq17> cjwatson: I will try both the ways so that I learn all of the processes , thanx for all the info...
<cjwatson> mib_730riq17: autoreconf is in the autoconf package, and has been around for a long time
<cjwatson> it's documented in the autoconf documentation
<mib_730riq17> cjwatson: OK
<mib_730riq17> cjwatson: what are the general precaution should I take to edit the configure.in file of an existing project so that it does not damage the app or the process of installation of app...
<cjwatson> I would personally recommend keeping files in revision control so that you can easily check the diffs produced (e.g. bzr diff) and test extensively
<cjwatson> if you're using different versions of the autotools from those used to generate the previous files you have in hand, then the diff may be very large, and you may need to make changes simply to get it to work at all
<cjwatson> with poorly-written configure.in files it can be quite a difficult exercise to modify them at all, I'm afraid
<cjwatson> and you typically end up learning rather more about the autotools than you expected :-)
<cjwatson> the fact that it's called configure.in at all (rather than the modern name, configure.ac) is not a good sign to begin with
<mib_730riq17> cjwatson: actually I have the task to update the configure.in so I have to take all the pain
<mib_730riq17> cjwatson: anyways if you are new to something its always adventurous to learn...
<mib_730riq17> cjwatson: what are difs , revision control and all those stuffs ??? do u have a link to the tutorial explaining all those stuffs..
<cjwatson> mib_730riq17: you can google for "revision control" as a first step and read e.g. the Wikipedia article on the subject
<cjwatson> mib_730riq17: the 'bzr' tool I referred to is http://bazaar-vcs.org/ and there are several general tutorials on that site
<mib_730riq17> cjwatson: it seems that bzr has a bug that it does not support proxy with authentication so i think i have limited use of bzr :(
<cjwatson> mib_730riq17: #bzr may be able to help you check whether this is something you can work around
<cjwatson> there were some old bugs about this but I thought they had been fixed
<mib_730riq17> cjwatson: i tried #bzr but they confirmed that this bug has no way around and this is not going to be fixed in coming future.This was pretty rude I hope that I can help them but I dont have enough knowledge to do so :(
<cjwatson> I don't think it's rude for developers to be honest about their roadmap!
<mib_730riq17> cjwatson: after being into 1 or 2 developing projects i agree with u...
<mib_730riq17> cjwatson: can I get help from here if i am stuck during revision or i have to go to some other channel?
<cjwatson> this is really not the best channel; I would recommend you look elsewhere
<mib_730riq17> cjwatson: like...do u have any ideas?
<cjwatson> mib_730riq17: no, it depends on the problem you are having; please be creative :-)
<mib_730riq17> cjwatson: OK thanx for ur valuable time...:) bye
<kirkland> mvo: hi there, are you around?
 * pitti squashes his first pet bug
<ScottK> \o/
<jdstrand> cjwatson: fyi-- I really liked HardyReleaseNotes/ChangeSummary/8.04.2. I hadn't seen that for previous point releases and think it is a great idea.
<pitti> slangasek: ^ that's a CD space present for you (bug 123025)
<ubottu> Launchpad bug 123025 in gconf2 "stop shipping static gconf translations, use gettext at runtime" [Wishlist,Fix committed] https://launchpad.net/bugs/123025
<cjwatson> jdstrand: glad you liked it, it was a lot of work :)
<soren> pitti: How much space does that buy us?
<pitti> soren: once all the GNOME packages are rebuilt, in the order of 100 MB uncompressed and 10 MB compressed
<soren> Whee!
<pitti> well, that is, 10 MB on desktops (which has the pregenerated /var/lib/gconf/defaults/)
<pitti> on the alternates, where that tree is generated at runtime, I guess more like 5 MB
<pitti> but still not to be sneezed at
<soren> Certainly not.
<dholbach> hey soren: are you well again?
<soren> dholbach: Getting better.
 * dholbach hugs soren
<dholbach> AWESOME!
<soren> dholbach: I just got fed up with lying in my bed.
<dholbach> I can imagine
<dholbach> after lying there, getting fed and everything, having read 35 books and stuff it must get tiring ;-)
<soren> :)
<pitti> apachelogger: argh, my cdbs upload got rejected, because 0.4.52ubuntu11 is already in the archive; you didn't commit to bzr
<apachelogger> pitti: I commited, I just didn't push
<PecisDarbs> hi people, when GNOME 2.26 will be merged into Jaunty?
<PecisDarbs> in what date?
<pitti> apachelogger: I'll fix it up, since I already pushed my stuff
 * PecisDarbs plans translation stuff
<apachelogger> pitti: ok, thanks ... and sorry for the inconvenience :)
<pitti> apachelogger: ok, applied your changes and pushed
<lool> tjaalton: Hmm you don't rm_conffile() /etc/network/if-up.d/mountnfs.orig?
<lool> oh sorry already covered in the bug's comments
<tjaalton> yes, it should be fine. worked here
<lool> seb128: I don't understand what "[BLACKLISTED] libv4l_0.5.3-1" means in Bug 319975?
<ubottu> Launchpad bug 319975 in libv4l "Please sync libv4l 0.5.8-1 (main) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/319975
<seb128> lool: it means the sync didn't work because for some reason libv4l is on the not-to-sync list
<seb128> I just did some quick syncs because mvo asked one but I want to finish other things so I will not investigate that now though
<lool> # ... due to orig.tar.gz mismatch:
<lool> That would be surprizing as I thikn I sponsored all the Debian uploads and requested all syncs
<bigon> seb128: hi, what does [BLACKLISTED] libv4l_0.5.3-1 means?
<lool> bigon: See above
<cjwatson> bigon: scroll up
<lool> Beside it's a new upstream
<seb128> bigon: hey, read the channel?
<pitti> lool: could ahve been a temporary measure; should just disappear from the blacklist then
<pitti> lool: we need to do those to unbreak sync-source -a, i. e. "sync everythign unmodified from Debian"
<seb128> bigon: also do you have a bugzilla.gnome.org account?
<lool> seb128: Mind dropping it from BL and syncing?
<seb128> lool: will do later, I closed my shell on this box now and I'm in middle of something else
 * bigon should read his backlog indeed
<lool> seb128: Ok; I'm reopening the bug then
<bigon> seb128: yes l.bigonville@edpnet.be
<seb128> lool: ok
<seb128> bigon: when you reopen a gnome bug on launchpad which has an upstream task could you also reopen or comment on the upstream bug?
<seb128> bigon: ie the gnome-session crasher you reopened
<bigon> seb128: done
<seb128> bigon: thanks
 * mvo hugs seb
 * mvo hugs seb128
 * seb128 hugs mvo ;-)
<dholbach> can somebody please massage the u-d-a list?
<cjwatson> dear conference organisers, ubuntu-devel-announce does not want to submit a paper
<cjwatson> dholbach: approved your post
<dholbach> cjwatson: thanks muchly
<tjaalton> could someone kick yellow, it's been building qt4 since the 20th
<tjaalton> qt4-x11
<apw> pitti, about?
<pitti> apw: hi
<apw> pitti, did you get a chance to look at that apport branch i requested merge?
<pitti> apw: currently catching up with SRUs, then I'll review your apport branch
<apw> pitti, thanks
<pitti> apw: not yet, sorry; but next thing on my list
<apw> no, thats perfectly reasonable ... just sliding past it on my 'watch this lot list'
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek - last day going to kick off in #ubuntu-classroom now!
 * pitti hugs dholbach
 * dholbach hugs pitti back
<pitti> seb128: argh, there must be something wrong; all four retracers didn't crash in the last three days!
<seb128> pitti: where is the fun there? ;-)
<pitti> boooooring
<seb128> indeed!
<pitti> seb128: question for you in bug 207072
<ubottu> Launchpad bug 207072 in gvfs "nautilus does not display samba shares for machines inside an ADS network." [High,In progress] https://launchpad.net/bugs/207072
<seb128> pitti: replied
<seb128> pitti: basically the change means "only do mounting when accessing the share, not when listing those"
<seb128> pitti: otherwise it would try to mount all bookmarks when opening the gnome-panel places menu for example
<pitti> seb128: ugh, why did it do that before?
<seb128> pitti: and when you have bookmarks which don't reply the software hangs on timeout
<seb128> pitti: not sure what advantage it has but that was not an issue since there was no call doing ios
<seb128> pitti: that's also why the nautilus change on bug #251809 is required btw
<ubottu> Launchpad bug 251809 in nautilus "scrollbar has some problem with multiple tabs" [Medium,Fix released] https://launchpad.net/bugs/251809
<primes2h> pitti: I attached the debdiff and subscribed you.
<seb128> pitti: http://bugzilla.gnome.org/show_bug.cgi?id=524485#c32
<ubottu> Gnome bug 524485 in smb backend "nautilus does not display samba shares for machines inside an ADS network." [Major,Resolved: fixed]
<pitti> seb128: ah, and the nautilus change is to handle ENOTMOUNTED?
<seb128> pitti: not exactly, nautilus already handle ENOTMOUNTED since ssh, etc were never automounted, the code was buggy apparently and that fix the bug
 * apw wonders if there is something up with the amd64 buildds they seem very behind the curve
<pitti> apw: just busy, as it seems
<apw> yellow seems to have been doing the same job for three days?  is that likely?
<apw> https://launchpad.net/+builds/yellow
<ia> hello. could you tell me, please, how can i detect, which "server's version" contained in xorg package? i ask about it, because after last update (i use jaunty 3 alpha), when xserver starts, it shows me error message with text "module abi major version (4) doesn't match the server's version (5)"
<slangasek> pitti: ooh yay, I like cd space presents. :)
<pitti> slangasek: I uploaded nautilus and gnome-terminal, which are the two packages with the biggest saving (ls -lSr /usr/share/gconf/schemas/)
<pitti> slangasek: the rest will trickle through with the normal gnome updates
<lool> cjwatson: As debootstrap and random guru I'd rather have you decide what to do for PATH based on Chet's comments :)
 * lool doesn't feel like he has any weight to claim that the kernel or bash or debootstrap should set it
<pitti> Keybuk: could you put your udevadm howto into README.Debian or so?
<calc> how is kde 4 coming along? i may be switching back to it soon, the gnomies are scaring me :-\
 * calc filed a bug report and the response was essentially, we like to make big broad sweeping changes that break stuff, but we have this pie in the sky idea that would fix the breakage we caused if we ever get around to implementing it
<pecisk> calc: what is so scary about gnomies? :)
<calc> pecisk: see above ^
<calc> pecisk: they have done it with gdm, gnome-session, pulseaudio, and now gweather :-\
<calc> probably other stuff as well
<pecisk> calc: exactly what? :)
<calc> eg try logging out of your session with stuff open, it just kills them now instead of warning you to save (gnome-session)
<pecisk> new stuff which breaks old stuff?
<calc> pulseaudio completely replaces the audio system in 2.26 and if you have intel hda realtek it doesn't work right
<pecisk> you mean consistency
<pecisk> well
<calc> gdm was so buggy (aiui) we didn't ship the new version for the past few releases?
<LaserJock> calc: I'm with you man, I made the jump a couple weeks ago. In a few days KDE 4.2 will be out, you should try it
<calc> and now with gweather they are dropping the ability to select the station you want to see reports from, the grouping of stations per city is buggy and some cities are so big the weather is different from one side to other anyway
<pecisk> I have my share of arguments why it is bad to do so, however, I haven't seen much impact, expect logging out/quiting dialog, which was kinda stupid to do without huge warning in release
<calc> LaserJock: heh ok
<pecisk> calc: have bug report/reference about that? :)
<calc> pecisk: the gweather one is gnome bug 568813
<ubottu> Gnome bug 568813 in general "Revert commit 518: "Don't worry about sub-city locations"" [Major,Resolved: wontfix] http://bugzilla.gnome.org/show_bug.cgi?id=568813
<tjaalton> well, you can always look out ot the window?-)
<pecisk> :)
<calc> tjaalton: sure, so why not just throw all of gnome away you can do stuff with pen and paper too
<tjaalton> calc: heh
<pecisk> joke aside, removing features without warning and insight is truely GNOME developers problem now
<pecisk> tjaalton: he is partly right
<calc> i reference both Houston and London in that bug report that they are both buggy with respect to station data, but he just wants to break it
<tjaalton> surely it's a bug
<pecisk> PA is thrown in just because it is "Next Best Thing", nevermind regressions in SOUND, which is mererly a basic of OS
<Keybuk> pitti: seems an odd place for it
<LaserJock> Gnome has gotten really good about calling bugs "features"
<pecisk> :)
<Keybuk> pitti: ubuntu-policy would be better, no?
<Keybuk> or a developer's reference
<LaserJock> the volume control stuff, gnome-session, gweather, ...
<pecisk> NetworkManager :)
<calc> perhaps i should just switch with 8.10 and hope by 10.04 gnome is sane again
<calc> i can do my testing etc inside vmware :)
<LaserJock> calc: man, I don't know. I thought the same thing the time the released without a menu editor
<pecisk> Problem is that steering of development is done by people who are very protective about stuff they like
<pecisk> and they want that everyone accepts it
<pecisk> and if someone objects, he is unpolite, jerk and doesn't understand how cool this stuff will be after year or two. maybe.
<calc> LaserJock: luckily gnome finally has one of those :)
<LaserJock> calc: for now
<pecisk> LaserJock: GNOME has menu editor for quite a long time
<calc> pecisk: yea the developers don't seem to get that crap should stay in a branch until it is ready
<calc> pecisk: iirc it took several years before it did
<pecisk> I think problem is that they don't have any way to test it than force it upon users
<pecisk> and that is bad
<LaserJock> pecisk: right, but they pulled a similar to the gnome-session thing that long ago
<calc> pecisk: even when they know it is definitely broken they still force it on users, eg gnome-session and pulseaudio
<calc> gnome-session doesn't manage sessions anymore for example
<pecisk> calc: gnome-session sure was problem, but it was solved. Pulseaudio, however, isn't still acepted even as external module for GNOME
<calc> pecisk: solved when in 2.25?
<calc> pecisk: it doesn't work in 2.24
<calc> pecisk: pulseaudio is being forced into main gnome for 2.25/2.26
<pecisk> calc: what exactly doesn't work in gnome-session? :)
<calc> pecisk: when you log out it doesn't warn you to save anymore
<LaserJock> it doesn't actually do any session management
<calc> pecisk: maybe other stuff too
<pecisk> calc: it won't, so far reading GNOME devs list
<pecisk> calc: ahhh
<cjwatson> lool: ok :-/ I'll think about it on Monday, have to go now
<calc> pecisk: did someone revert the gnome-volume-* stuff then?
<pecisk> calc: well, actually they work on improvements, but they will be in distro like Ubuntu first
<pecisk> calc: no one, but no one also have accepted it as only one
<LaserJock> it's rediculous what they did with gnome-session
<LaserJock> gnome-session-save is even left with a man page
<LaserJock> yet it does absolutley nothing
<LaserJock> they had the GUI for session saving
<LaserJock> but it wasn't hooked up to anything
<LaserJock> why on earth would you do that?
<pecisk> more or less, all these problems indicates one particular issue with open source - when getting big as GNOME, Ubuntu, KDE, you have to make specs
<pecisk> what should do that button
<pecisk> what should do another button
<pecisk> etc.
<LaserJock> seems to me to  be rather release management
<calc> they even have specs in gnome afaict but they don't care that they break stuff
<pecisk> without specs, GNOME keeps crunching on "oh so shiny features" while deserting "just works" field
<pecisk> LaserJock: release management follows specs - usually :)
<LaserJock> pecisk: right, but you can spec all you want, if the features don't arrive in time you don't just ship broken stuff and say "oh well, maybe next time"
<pecisk> calc: they don't have specs on how you should log out from session
<tjaalton> what.. there's no 'gnome-session-save --kill --silent' anymore??
<LaserJock> tjaalton: no
<tjaalton> uh
<pecisk> LaserJock: but this is exactly what I am talking about ;) If new code doesn't provide warning dialog about unsaved docs, forget about inclusion
<tjaalton> so much for the lock-timeout then
<pecisk> tjaalton: it is gone the way of Todo
<tjaalton> guess I'll have to forward-port it then
<pecisk> tjaalton: due of gnome-session rewrite, which didn't landed all features it's promised
<LaserJock> pecisk: right, but the problem was that they knew that and released it anyway
<tjaalton> maybe I'll ruin my evening by reading some ml archives then..
<pecisk> :D
<pecisk> reading GNOME ml is neverending thrill these days - which features will get thrown out
<pecisk> some guy did remake for Vino dialog - for what?! Instead of adding SIMPLE CHECKBOX, he thrown Advanced tab just because it is "not worth it".
<LaserJock> I mean, it's even worse than xorg getting rid of Ctrl-Alt-Backspace ;-)
<pecisk> He didn't even evaluated which features maybe is worth to get into new version!
<pecisk> I mean - what a development is this?
<pecisk> Also infameous NetworkManager 'Auto eth0' profile, which people tried to change, and everytime it falls back to DHCP
<directhex> pecisk, oh yes, that sucks hard
<directhex> gave up using NM on a home server. unusable due to the auto eth0
<pecisk> anyway, it is getting out of handing and seriously hurting any chances for free desktop enviroments to be accepted as usable from common people. Even more, it can drive lot of them away without intent to never look back.
<tjaalton> could a buildd admin kick yellow (amd64)? it's been stuck for a couple of days now.. https://edge.launchpad.net/ubuntu/+source/qt4-x11/4.4.3-0ubuntu1.2/+build/842557
<tjaalton> a better link https://edge.launchpad.net/+builds/yellow
<NCommander> Keybuk, you around?
<Keybuk> NCommander: yup
<NCommander> Keybuk, I'm curious about the issues with upstart on ARM, specifically, what/s missing in in our kernel to make it work sanely
<Keybuk> pselect() and ppoll() just as the bug says
<Keybuk> and you mean udev, not upstart ;)
<NCommander> What bug?
<NCommander> (sorry, I was just informed of this via a meeting this morning, I haven't seen any bug)
<Keybuk> bug #319729
<ubottu> Launchpad bug 319729 in linux "ARM architecture lacks support for pselect() and ppoll()" [High,Triaged] https://launchpad.net/bugs/319729
<tjaalton> Keybuk: could you have a look at yellow (the buildd). I'd really need to get mesa  et al built on amd64 to avoid bugs like bug 320525
<ubottu> Launchpad bug 320525 in linux "jaunty unbootable on intel G45 since .28-5 kernel update" [Undecided,Incomplete] https://launchpad.net/bugs/320525
 * ogra wasnt aware either that Keybuk logged a bug
<Keybuk> I always file bugs ;)
<ogra> NCommander, i would have told you ;)
<NCommander> ogra, oh, I know :-)
<ogra> Keybuk, didnt you say upstart makes extensive use of pselect as well ?
<Keybuk> some versions do, yes
 * ogra thought he remembered something like that
<ogra> ah
<Keybuk> I suspect there's a few programs that use it
<ogra> likely
<Keybuk> since the entire point of the syscall is it solves a difficult race condition
<ogra> though i didnt see any issues yet
<NCommander> Ah
<Keybuk> you probably have seen issues
<NCommander> yeah
<Keybuk> and just not realised it
<ogra> *but* that might be because 80% of the arm kernels i use dont even have modules
<NCommander> At least they have syscall ids reserved
<Keybuk> it could show up simply as zombie processes staying around and a parent not reaping them
<ogra> so devices dont change usually
<NCommander> Oh, I had that
<Keybuk> it could show up as a module not loading or a removable device not being activated
<Keybuk> it could show up as a dns timing out instead of resolving for no apparent reason
<ogra> i might have seen the latter
<ogra> unlikely i saw the first
<ogra> usually my removable device carries the rootfs ... so its there before udev ...
 * NCommander is currently trying to find where in the kernel ppoll/pselect are actually defined so I can see the implementation
<ogra> unistd.h or so
<NCommander> ogra, oh, no, the actual function :-)
<ogra> in arm they are just a comment
<ogra> right :)
<NCommander> ogra, right, but I want to see the x86 implementation so I know what it will take to implement
<ogra> yep, understood
 * NCommander suspects its a large blob of ASM
<NCommander> Keybuk, ok, this is kinda weird. I found the function, its a blob of C thats dependent on HAVE_SET_RESTORE_SIGMASK existing, but only x86, ia64, and sparc64 seem to have it, which means this bug also effects powerpc, and pa-risc
<Keybuk> arch/powerpc/include/asm/thread_info.h:#define HAVE_SET_RESTORE_SIGMASK 1
<Keybuk> powerpc has it
<Keybuk> and who cares about pa-risc?!
<ogra> IBM !!
<NCommander> Keybuk, hrm, it must not exist in 2.6.26, since that was the source tree I was grepping :-)
<Keybuk> I mean we don't support pa-risc
<Keybuk> but we're going to support arm, and it's missing some rather handy syscalls that fix bugs!
<NCommander> I get the point :-)
 * NCommander is seeing whats goingt o be needed to implement it
<tjaalton> ogra: no, HP !! :)
<ogra> tjaalton, HP owns it ... for IBM its competition ;)
<tjaalton> ogra: ah, good point :)
<NCommander> so set_restore_sigmask is a single C function ...
<NCommander> This seems too simple ...
<NCommander> Keybuk, do you have some test code I could use to test ppoll/pselect's implementation?
<Keybuk> I'm not sure what you mean?
<slytherin> hi, is any of the kernel deveopers planning to update kernel on powerpc to bring it in sync with i386?
<ScottK> NCommander: ^^
<NCommander> slytherin, yes we are, TheMuso working on a mechanism to allow us to stay easily in sync w/ the main kernel
<slytherin> NCommander: cool
<slytherin> by the way, does anyone know why I have suddenly got non-working mouse and keyboard at GDM. I am running latest jaunty.
<tjaalton> LaserJock: btw, looking at the current gnome-session code.. and g-s-s is still there
<seb128> tjaalton: you want to work on GNOME? ;-)
<tjaalton> seb128: hehe :)
<tjaalton> seb128: I was just worried that the new g-s would have removed g-s-s --kill --silent
<LaserJock> tjaalton: it is there, it just doesn't work
<tjaalton> it's really useful on classrooms
<tjaalton> LaserJock: ah, now that's interesting :)
<seb128> nothing got killed, that's just need code and things are still not there or working correctly yet
<LaserJock> tjaalton: they rewrote the core fo gnome-session so all the outside bits are there but they don't work
<tjaalton> seb128: I'm checking the upstream bugs now to see if it's reported or being worked on
<seb128> not sure about this one but the session storing is being worked
<tjaalton> that's good
<seb128> the GNOME trolls on this channel are not really useful though
<tjaalton> I also had a quick look at the gvfs webdav bugs, and seems like it's not maintained at all :/
<tjaalton> not that I've had much time to test it, but it's going to be used extensively here..
<tjaalton> seb128: who is the upstream gvfs guy to contact?
<seb128> tjaalton: there is not one guy, depends of the code you want to change
<seb128> tjaalton: ah, webdav
<tjaalton> yes, gvfsd-dav
<seb128> tjaalton: that's gicmo on IRC
<tjaalton> there are 10+ bugs upstream that have no replies
<tjaalton> ok thanks
<seb128> that's not a lot
<LaserJock> tjaalton: yeah, common problem :(
<tjaalton> well, they are showstoppers
<tjaalton> it's not usable atm
<LaserJock> seb128: do you know if anybody is maintaining g-s-t upstream? I looked at svn but it seemed pretty dead
<seb128> that's not really true, depends of the use you want to do rather
<seb128> LaserJock: no, nobody upstream nor in ubuntu, it's being deprecated
<seb128> LaserJock: we just need an user admin tools and can stop using it on the default installation
<LaserJock> seb128: in favor of?
<tjaalton> anyway, I'll poke him and ask
<tjaalton> g-s-t = gnome-search-tool?
<calc> tjaalton: gnome-system-tools (iirc)
<seb128> tjaalton: he's busy with university recently and knows about some issues, should be better in some weeks if I understood him correctly
<LaserJock> seb128: so "we" is Ubuntu or ?
<tjaalton> calc: ah ok, so many components :)
<seb128> LaserJock: no, we being osx on this channel ;-)
<calc> LaserJock: of course deprecation in gnome doesn't mean there is a replacement.. they just throw stuff out for fun ;-)
<tjaalton> seb128: thanks, shouldn't be a problem
<seb128> calc: it's not deprecated in GNOME
<LaserJock> calc: that's what I was worried about
<jelmer> slangasek, hi
<seb128> could people stop trolling there
<seb128> I'll reply when people have constructive comments, I'm not interested in trolls
<LaserJock> I haven't seen any trolls
<calc> seb128: ok is gnome-session going to be fixed for 2.26? :)
<seb128> not reply to those trolls
 * calc gets users filing bugs against OOo because of that
<tjaalton> calc: according to the upstream bug, lucas rocha is working on it
<calc> s/troll/disillusioned user/
<seb128> same difference
<LaserJock> s/disillusioned/frustrated/
<seb128> it seems you guys don't understand how opensource is working
<LaserJock> don't give me that
<seb128> g-s-t is no deprecated there is just nobody interested to work on it
 * calc thinks Gnome thinks it is Apple and can just foist stuff on users... but Gnome doesn't have a reality distortion field like Jobs has for Apple
<seb128> other distros have their own set of tools
<seb128> and ubuntu maintainers are too busy
<seb128> and perl is not the best thing to write desktop softwares
<LaserJock> seb128: so Gnome, as a whole, doesn't feel like g-s-t is important to maintain?
 * calc is tryin to reach 0 new bugs for OOo
<seb128> there is no GNOME as a whole having ressources to thrown on code
<calc> LaserJock: from what i can see in g-s-t most of it is duplication at this point, but the idea in general seems sound as long as it is not in perl
<seb128> GNOME is not a company
<seb128> it's just a project of volunteers writing code
<seb128> if somebody stops working on a software what do you suggest doing?
<LaserJock> finding people to take it over
<LaserJock> putting out a call for volunteers
<calc> LaserJock: like you? :)
<seb128> you are welcome to try
<LaserJock> calc: we'll yeah
<LaserJock> I've been seriously trying to figure out what to do with user management
<seb128> it's easy, just make a call to find people to fix all the bugs and write new code
 * calc would have volunteered to take over libgweather but it seems upstream is alive and happy with what they are doing
<seb128> calc: I think you are overeacting to minor changes on this one
<calc> seb128: there is no way to tell which station it is using anymore and what it calls 'Houston' is a 4000 sq km area
<LaserJock> I was thinking that g-s-t was just going through a lull
<seb128> you flamed upstream before waiting for any comment from their part or before knowing if they were interested to reconsider the changes
<calc> seb128: wheather is definitely different from one side to the other, often
<LaserJock> if they plan to deprecate it then that's a whole different story
<seb128> LaserJock: they don't but same difference
<seb128> LaserJock: redhat as *-admin, mandrake has mandraketools, suse has yast
<calc> seb128: that combined with all of what gnome upstream has been doing in general and i think will be getting rid of gnome entirely from my system by 9.04 at minimum
<seb128> LaserJock: ie, nobody is paying people to work on g-s-t, so if nobody show up to write on ugly perl code it's not going to change a lot
<LaserJock> seb128: so Gnome gives up on providing useful system administration tools?
<calc> they have broken gnome-session, gdm, audio, and who knows what else with the claim they will eventually get around to fixing it
<calc> but release it as 'stable' completely broken
<seb128> LaserJock: dunno what you consider GNOME to be but you seem to have no sense of reality
<calc> so seeing them go on to break gweather was the last straw for me, i'm dumping gnome for my systems
<LaserJock> seb128: that's rather rude and uncalled for
<LaserJock> seb128: please stop making personal attacks on people for raising concerns
 * calc thinks he will switch to something that people don't enjoy breaking like flubox or something
<seb128> LaserJock: GNOME is an agregation of project maintained by volunteers, GNOME decide on what component they ship but they don't have nn people they can order to write new softwares
<calc> seb128: they could however change commit rules to not cause regressions
<LaserJock> seb128: no, but you know darn well there's organization there and people can make efforts toward getting things going
<seb128> LaserJock: that's not GNOME though but those organizations
<LaserJock> seb128: the gnome community
<seb128> calc: they could but one of the issue is that things are perceived to not move enough there
<seb128> LaserJock: what the community wants do not give you magically people writting code though
<LaserJock> seb128: of course not, I didn't say that
<seb128> calc: they have broken gnome-session and that's about it
<calc> LaserJock: i think that the issue you are seeing wrt g-s-t isn't really something that can be solved, if no one wants to work on it then no one does
<LaserJock> but if Gnome, as a community, says "we dont't really care about system administration tools", that's a bit frustrating
<seb128> and that's the fedora guys pushing too hard for changes
<calc> seb128: so they are backing out the changes for gnome-volume?
<seb128> LaserJock: they do care, they is just nobody wanting to code on those
<calc> seb128: because it now uses pulseaudio and pulseaudio is known broken on many audio systems
<calc> seb128: the new gnome-volume requires pulseaudio aiui and from looking at it
<seb128> calc: it's being used since hardy, wake up, that's not GNOME breaking anything now
<calc> seb128: but now you can't change your volume anymore if you don't use pulse on Gnome
<seb128> that's being discussed on the upstream lists though
<calc> seb128: yes and it is looking like they are going to force pulseaudio in broken as it is
<seb128> calc: the volume applet should still be working it's using gstreamer
<seb128> there is one issue there
<seb128> which is that fedora is doing most of the GNOME work
<seb128> so there is nobody having weight to counterbalancer their decisions
<calc> which is why gnome org/foundation(?) needs to adopt a no regressions policy
<LaserJock> I find it frustrating that you're saying that Gnome isn't a company but it's hard to do things becase of companies/distros
<calc> so things like this can't get just forced into gnome
<seb128> LaserJock: GNOME has no real power, softwares maintainers can basically do what they want
<slangasek> jelmer: hello
<calc> seb128: gnome board could throw out a developer that is misbehaving like debian has done on occasion
<seb128> right and stale GNOME for good
<jelmer> slangasek, What were the URLs for those grub branches?
<seb128> let's thrown out the only people doing things
<calc> seb128: stale gnome > than broken gnome
<jelmer> slangasek, I should've put them in the bug report, and can't find them anymore.
<seb128> calc: I don't agree, they are rewritten a lot right now and that will benefit GNOME 3 which we should get for the next lts
<calc> ok
<LaserJock> in the mean time people leave because of regressions
<seb128> either you push for new changes and break things on the way for a while
<slangasek> jelmer: lp:~ubuntu-core-dev/grub/ubuntu, svn://svn.debian.org/svn/pkg-grub/grub/trunk
<seb128> or maintain several codebase and slow work because you have to work on several versions
<jelmer> slangasek, thanks
<slangasek> jelmer: thank you :)
<calc> seb128: broken things (broken on purpose) should never make it into a stable release
<seb128> nothing is broken on purpose
<seb128> that's just life, the guy who started the gnome-session rewrital got a new job and moved between countries during the cycle
<calc> seb128: well then described as rewriting and pushing it out before its done, however you want to say it
<LaserJock> seb128: gnome-session without any session managment isn't broken on purpose?
<seb128> no
<seb128> on purpose, that's just trolling
<calc> seb128: they should have reverted the change before release in the gnome-session case then
<seb128> other code depends of the new dbus api that's not so trivial
<LaserJock> ok, but they left all the UI and exposed stuff that doesn't work
<LaserJock> that's broken and that's on purpose
<seb128> the guy started on the rewrital, was on track mid cycle and then vanished because he was changing job, country, etc
<LaserJock> they knew what stuff didn't work and choose to keep it anway
<seb128> LaserJock: I'm near of being really unpleasant with you now
<seb128> "on purpose"
<LaserJock> seb128: likewise
<seb128> yeah, they decided "let's screw users"
<LaserJock> I wouldn't go that far
<seb128> 'let's start on something and break it just to laugh to users'
<seb128> that's what on purpose mean
 * calc thinks this proves the case of rewrites shouldn't be done on trunk
<LaserJock> I didn't say they did it with malicious intent
<LaserJock> but I think they did do it knowingly
<seb128> that's what on purpose means
<LaserJock> no
<seb128> no, they didn't
<seb128> they were on track mid cycle
<LaserJock> yes they did!
<seb128> the guys said he would fix it
<seb128> and he didn't
<calc> ok s/on purpose/knowingly/
<seb128> no
<LaserJock> right
<LaserJock> which is why you don't release it when somebody goes AWOL
<calc> they should definitely have known it was broken before the release and just released with it as is
<LaserJock> we do that all the time in Ubuntu
<seb128> they got screwed by somebody who didn't deliver
<seb128> no we don't
<LaserJock> I don't know why it'd be so hard for an organization like GNOME to figure out
<seb128> we could have downgraded gnome-session
<seb128> and we knew about the issue
<calc> LaserJock: in Ubuntu if we have known broken things we revert them generally with a XreallyY syntax for packaging
<seb128> that's the other side of fixed schedule
<LaserJock> sure
<LaserJock> but gnome left things exposed
<seb128> we knew it one month before intrepid
<seb128> but nobody stepped to do the job
<LaserJock> just kinda dropped it out there where it was
<seb128> we did the same
<seb128> again GNOME has no paid people they can use at will
<LaserJock> sure
<LaserJock> but it shows that perhaps people are caring about what's going on enough or some other institutional/community issue
<seb128> what you do when you know you need somebody working for a week to fix the situation but have only overworked volunteers?
<seb128> either you delay schedule or just ship what you have
<LaserJock> it's called community managment
<seb128> you can't order community
<LaserJock> well, you can  quickly try to patch things up the best you can
<seb128> there was call for volunteer to fix those issues
<seb128> nobody stepped there
<seb128> who is you?
<LaserJock> i.e. take out gnome-session-save and the "Remember current running applications"
<tedg> seb128: I think the real problem is that no one defined a date where it has to be fixed to get in.  One of the things I've liked about the Evolution-dbus situation is that if it doesn't do XYZ by date A it doesn't get in this release.  No one did that for gnome-session, which I think, was a failure of the release team.
<LaserJock> tedg: exactly my point
<m1k3> What gives with Ubuntu using OLD ffmpeg? from ffmpeg website, "It is a key component in many multimedia projects and has new features added constantly. New, official "releases" are few and far between. In short, if you want to work with FFmpeg, you are advised to go along with SVN development rather than relying on formal releases."
<seb128> tedg: right, they didn't want to do a gdm situation again
<seb128> that's really fedora's fault
<calc> seb128: perhaps this is something we should look into to help out gnome then? not something to help out Ubuntu specifically, but to help them get their release engineering going properly, since we heavily depend on upstream Gnome being in a usable state
<tedg> There's generally an assumption that existing modules will continue to get in, even with complete rewrites.  I don't think that should be allowed.
<seb128> calc: they know about the issue now, that's new issues for them, they didn't really have such issues until recently
<seb128> they didn't accept the new gdm for several cycles because it was not ready
<tedg> calc: I think the processes is being adjusted, but yes, we need to clone seb :)
<calc> seb128: yet people were still trying to defacto force PA into 2.26... so it seems they still need help
<seb128> but that created tension with the fedora guys who are doing the work and are major contributors
<seb128> calc: again fedora's decision
<seb128> and there is nobody to balancer their influence there
<calc> seb128: which is why i suggest we see if we can help influence them somehow
<seb128> opensource is sort of a who-do-work-has-something-to-say
<seb128> we can by starting doing work
<slangasek> seb128: well, there was also the gvfs debacle where GNOME stopped being a useful SMB browser just in time for an LTS :(
<seb128> slangasek: again fedora did the changes and we picked the wrong cycle for a lts and where stucked between sucking choices
<calc> seb128: but as gnome is a real organization (i think?) it can decide what to let those who are doing do
<calc> seb128: it can't tell them what to do, but it can decide what to accept
<seb128> right, they didn't accept the new gdm when it was not ready
<slangasek> seb128: I would argue that if there's /any/ "stable" cycle in which GNOME is landing that large of a regression, there's a problem with the release management per se
<seb128> the new gnome-session was judged as mostly working
<calc> seb128: but they accepted the gvfs issue slangasek brought up and gnome-session
<seb128> nobody raised the issue about session storing during the unstable cycle
<LaserJock> seb128: I think I read about it before, but I could be wrong
<seb128> the gvfs smb issues was raised after they rolled the stable version
<calc> seb128: i can't even run jaunty right now because it is too buggy, i'm sure there are plenty of people in that boat
<seb128> slangasek: the issue is that GNOME has no manpower they control
<slangasek> seb128: but GNOME should have control over what goes into a release
<LaserJock> but I don't see how they could have accepted gnome-session when almost all the user-visable features are missing
<seb128> slangasek: so either they reject changes until they are ready which tend to discourage people or try to go forward and do what they are doing
<slangasek> discouraging people who are otherwise going to wind up breaking the stable release for users is not a loss
<seb128> slangasek: they do, they just have the feeling that GNOME is not moving fast enough compared to other desktop, users expectations, etc and that they should go forward rather than stepping to stop changes because of issues
<tedg> What I hope that we can do in the future is do thing like what we're doing for gdm/gpm for this release.  Do parallel releases of version.
<calc> slangasek: and after a while the developers will understand what they need to do to get into the release and just go along with it
<calc> seb128: the other desktop.. KDE? is broken as well as I understand it
<slangasek> seb128: who is "they" and who is it they're worried about trying to move as fast as?
<tedg> I think that provides a little both worlds.  Allows for easily available experimentation while still allowing for stable releases.
<seb128> LaserJock: the fedora guys didn't perceive session storing as an important thing since it never worked correctly
<calc> seb128: so trying to be like KDE 4.x releases isn't particularly helpful
<slangasek> seb128: heh
<seb128> and we didn't either
<calc> however dropping session storing also got rid of the save before logout bit
<broonie> seb128: The other alternative is to flag things more clearly to users (possibly using something like tedg mentions with alternative versions available).
<LaserJock> seb128: then why is it in the UI?
<seb128> and nobody raised that as an issue until late
<seb128> LaserJock: I already explained you that the guy doing the work changed job and country no?
<slangasek> well, session saving /used/ to work just fine for me, and has progressively degraded over the last three releases
<LaserJock> I don't understand why there's a UI for something in a stable release for something that doesn't work and nobody cares about
<calc> on the other end of this argument is Sun OOo which takes forever to get anything in, so it is a balancing act
<seb128> because the guy stopped his work mid cycle
<seb128> and nobody else picked up then
<LaserJock> can it really be that hard to remove the button and remove gnome-session-save?
<slangasek> I probably would've noticed it sooner myself if I didn't already find restarting my sessions to be a hassle
<seb128> LaserJock: send a patch?
<tedg> slangasek: The problem is that it didn't work for a bunch of use cases, and didn't recover properly.  For instance if you saved the session on a autostart app.
<seb128> LaserJock: nobody is working on this code
<LaserJock> seb128: ok, but that's not exactly a great excuse for releasing broken features
<seb128> lot of applications don't store their workspace or position or open work either
<LaserJock> sure
<seb128> LaserJock: nobody said that's an excuse, it's just how it happened, the same reason it happened for ubuntu
<LaserJock> but when you have a gtk button that's connected to an empty callback ..
<slangasek> tedg: I agree, it was broken before.  But now it's more broken.
<tedg> The problem is that the fix isn't good either.  Inventing a new API isn't the solution to poor implementations of the old one.
<seb128> LaserJock: there is a fixed scheduled, known issue but nobody stepping up, either you delay or ship what you have
<LaserJock> and an "executable" that doesn't work
<seb128> that's similar to what ubuntu do
<seb128> we don't have the manpower to fix all the upstream code
<tedg> While we can argue about the past, I'm more concerned about the future.  seb128, is gnome-session looking better for Jaunty?
<seb128> and we have a fixed schedule
<LaserJock> sure
<seb128> so we do the best we can
<LaserJock> but we rely on upstreams to have some sense of QA
<seb128> tedg: session storing will be fixed for jaunty
<tedg> \o/
<seb128> LaserJock: and if they don't we can be screwed, same for GNOME
<slangasek> but, er, GNOME /is/ the upstream? :)
<seb128> GNOME doesn't have paid people
<LaserJock> seb128: but I'm interested in how that institutionally happens and what could be done to fix it
<seb128> they just do a desktop with softwares volunteers are writting
<slangasek> seb128: no, but that's no excuse for not structuring themselves in a way that their QA is proportional to their development targets
<slangasek> if that means they have to scale back their development, so be it
<seb128> slangasek: you could say the same about ubuntu
<seb128> we did ship with those bugs too
<LaserJock> and we are constantly adjusting QA and development procedures in the wake of EPIC FAILs
<slangasek> but we didn't drive the development of the half-delivered features
<seb128> we just ship way too much code for the ressources we have
<seb128> slangasek: they didn't either, they don't control the people doing the changes, they are not paid by GNOME
<LaserJock> you act as if the only way to "control" anything is to pay people to do it
<LaserJock> which seems rather odd
<seb128> no, but when you don't have ressources you can use you are limited in choices
<seb128> either you are conservative and wait to see before doing a change
<calc> LaserJock: if they are paid they tend to disappear less frequently ;-)
<LaserJock> calc: sure, but you compensate
<seb128> or you decide to go with whatever somebody is doing and get screwed if they stop on the way
<LaserJock> FLOSS projects have been dealing with flakes for years :-)
<calc> but i think a better solution to this would be to just not allow major rewrite type changes to happen on trunk to begin with
<calc> its equivalent to us using ppa's
<seb128> that's the flip side of fixed schedule with limited ressources
<seb128> there is not a zillion of way
<seb128> either you
<seb128> - delay the version
<seb128> - allow extra ressources
<seb128> - ship what you have
<seb128> there is no way around those
<calc> i could try to shove OOo 3.1 into jaunty but i think it will likely not make it in time so do it via ppa for people to play with
<seb128> delay the version is what debian does
<seb128> allow extra ressources required having some to allow
<seb128> and ship what you have is what happens there
<LaserJock> seb128: I think that's a little simplistic
<seb128> what are the other choices?
<LaserJock> you can have release management teams and QA structures
<LaserJock> best-practices
<calc> and debian does have testing/unstable so it doesn't do the equivalent of direct commits to trunk
<seb128> calc: we could stay on not current GNOME, the issue is that GNOME fix a lot more issues than we could do with the ubuntu ressources we have
<slangasek> seb128: sorry, but I don't think either of those options you propose constitute very good release management; the better answer is "sort out a rollback path in advance and identify a milestone at which x, y, z features need to be implemented before you commit to it"
<seb128> slangasek: I agree with you and that's what GNOME usually do
<seb128> the gvfs smb issue was not raised before stable
<calc> seb128: true, and even then that wouldn't help that much since eg the gnome-session issue was broken for several upstream releases, looks like it might be fixed in 2.25
<seb128> which might shows they (and we as a distributor too) don't do enough pro-active testing
<seb128> they delayed the new gdm
<slangasek> seb128: hmm, was that a failure on our side?  I thought we had reports about gvfs smb borkage at least a month before the release
<seb128> slangasek: a month before our release rather?
<seb128> slangasek: we have our beta around their stable
<seb128> and have our stable around their .1
<slangasek> seb128: yes - and our beta is only 3 weeks before release, neh, so a month before release is before their stable? :)
<slangasek> anyway
<seb128> slangasek: well, it took me a while to get that would be a real issue for many users
<seb128> and nobody else ringed any bell early either
<slangasek> fwiw, the last two release cycles have taught me that I need to be proactive about upgrading to the devel release of Ubuntu early, and reporting all the bugs I trip over
<slangasek> seb128: right, that's fair
<seb128> what I was saying to the upstream guys recently
<seb128> their recent screwing taught me to not upgrade automatically everything now
<LaserJock> slangasek: except when there's nobody on the other end listening :(
<slangasek> seb128: did upstream have any sort of post mortem after the gvfs smb thing, to try to understand what they could do better to prevent that in the future?
<seb128> if that was this cycle I would not do the gnome-session upgrade
<slangasek> LaserJock: I report them to LP, so seb128 is always listening to me ;)
<LaserJock> slangasek: sure, but that's not always fair to seb128 :-)
<seb128> slangasek: I don't think they really did
<seb128> but the issue is clear
<seb128> they didn't see the issue coming before their stable
<slangasek> yes - the question is, how to make sure they have a perspective that lets them see the issue
<seb128> they have all the discussion on public lists anybody can raise objection
<LaserJock> do you think like having a bit more publicized pre-releases would help?
<tedg> slangasek: Convince Fedora that users like being able to upgrade their systems? ;)
<seb128> Josselin is raising concerns about the sound changes for 2.26 at the moment for example
<slangasek> seb128: I don't think it's reasonable to expect users of GNOME to have to track a discussion mailing list
<seb128> we did raise concern about the new gdm which didn't get accepted upstream
<LaserJock> like for KDE the Kubuntu clan backport all of KDE betas and rcs so peple can try them out
<seb128> slangasek: well, if somebody perceive an issue it should be raised by some way
<slangasek> for major changes, they ought to actively seek feedback from a wider base
<LaserJock> would that help Gnome out to find those issues earlier?
<seb128> LaserJock: GNOME roll new version often enough and those are in major unstable distros
<seb128> they didn't screw that much and are learning from it too
<slangasek> LaserJock: I'm not sure there's a market for pre-release backports of GNOME, and I'm pretty sure there isn't the manpower
<LaserJock> seb128: but I've never seen like a "Get 2.25.x for Intrepid today!"
<seb128> they had issues on gvfs (specific to smb that linux hackers usually don't rely on and didn't notice)
<LaserJock> slangasek: is that just because more is going on with the KDE 4 cycle
<LaserJock> ?
<seb128> and on gnome-session (they didn't perceive session storing being such an issue since most of hackers don't use it)
<LaserJock> I don't use it either
<slangasek> LaserJock: speaking frankly, at least for myself I think the unstable GNOME changes are the biggest reason *not* to upgrade to devel releases...
<seb128> there is sort of disconnection between hackers and users expectations there
<slangasek> seb128: I cannot fathom why hackers would be less likely to use session saving
<seb128> otherwise they didn't really screw up anything else
<seb128> slangasek: not less likely, that's just that nobody in the upstream community screamed
<slangasek> LaserJock: i.e., if you're willing to run the GNOME stuff that's in development, might as well run it on the Ubuntu devel series
<LaserJock> seb128: so do you know if anybody is going to write a user and group admin tool for Ubuntu then if upstream seems to not care?
<seb128> the fedora guys considered that it never worked correctly since it was not storing workspace, position, open work etc informations for most softwares anyway
<LaserJock> slangasek: ahhh, I see what you mean
<seb128> LaserJock: they still ship g-s-t which works
<LaserJock> seb128: well, except I want to modify it
<ScottK> slangasek: In Kubuntu we do get quite a number of people who are willing to run pre-release KDE versions on the current Ubuntu release.
<seb128> LaserJock: there is just nobody actively fixing issues there because nobody seems interested, how do you solve that without having money to spend ?
<slangasek> anyway, where was I... oh yes, filing a critical bug on NM
<slangasek> ;)
<ScottK> I think it's a useful risk mitigation for people who aren't up to dealing with infrastructure breakage.
<LaserJock> seb128: dude, we do it all the time
<seb128> LaserJock: you are welcome to modify it and take over maintainship upstream if you want
<LaserJock> that's how MOTU works, making slaves out of volunteers ;-)
<slangasek> seb128: "vision"
<LaserJock> seb128: well, that's sort of what I'm looking at
<seb128> slangasek: vision doesn't make things magically happen
<slangasek> (if you build... the vision..., they will come)
<LaserJock> I myself, am unlikely to be able to just up and write a new tool
<seb128> there is nothing fancy in an user management tool
<pecisk> seb128: but they show directions :)
<slangasek> seb128: what it does is encourage the people who are most likely to be enthusiastic about helping solve the problem feel welcome
<LaserJock> however, the current tools aren't so great to hack on because of being perl/C
<slangasek> that's not a sentence, but maybe you get the idea
<seb128> right
<LaserJock> what I'm wondering is if it's better to start a new pygtk tool for Ubuntu
<pecisk> guys, why are you doing this on friday night? :)
<LaserJock> or try to restart upstream
<LaserJock> or ...
<seb128> the g-s-t situation is a bit special since almost no distro use it
<seb128> so it's only upstream debian and ubuntu basically
<LaserJock> seb128: right, I guess I knew that but didn't know it :-)
<seb128> and ubuntu is using the redhat tools for different things now
<seb128> and gnome-panel clock applet can set time now
<seb128> and network-manager replactes network-admin,  etc
<LaserJock> slangasek: right, I'd like to help upstream some, but if they're not even enthusiastic about their software I'm not really either :/
<seb128> you should help the fedora guys to work on the new user admin tool
<LaserJock> seb128: they've got one?
<seb128> they have some plans and mpt contributed to the discussion
<pecisk> seb128: I think if NM wouldn't be so full of small quirks no one would even notise disappearance of g-s-t network-admin
<seb128> pecisk: nm 0.7 is supposed to do eveything network-admin does now
<slangasek> oh, I don't use g-s-t network-admin
<slangasek> I use NM exclusively
<seb128> me too
<slangasek> because it's best-of-breed for wireless managemen
<slangasek> t
<pecisk> seb128: problem is that it doesn't. NM guys even claim that they don't plan to do ppp any time soon.
<LaserJock> it took a while, but for me it's great
<slangasek> unfortunately, that's not saying much, and it's always getting in my way in other ways
<seb128> pecisk: network-admin has many limitation too
<seb128> configuring wireless using it is the suck
<slangasek> yes
<seb128> do you know of anybody who managed to configure a dsl connection?
<pecisk> seb128: sure, and I generally happy about switch
<slangasek> pecisk: fwiw, it's not friday night for all of us. :)
<seb128> network-admin is a buggy piece of code written in perl and having many limitation
<LaserJock> seb128: do you happen to know the name of red hat's user admin tool?
<seb128> network-manager is doing a much better job
<mvo> LaserJock: have you considered just replacing the perl backend with a python one for the user-admin tool? i haven't looked into it in a while but it was one of the ideas floating around
<slangasek> mvo: one word: liboobs
<pecisk> seb128: where is link about redhat rewriting user admin? :) would like to take a look
<LaserJock> mvo: I have no idea
<seb128> LaserJock: no, maybe ask mpt he participated to the discussions about the new tool
 * calc bbl, dropping off my son
<seb128> pecisk: that was discussed in some desktop team meeting previous cycle and somewhere on their wiki
<LaserJock> mvo: it's just that Edubuntu wants to get user administration better, but not a lot of experienced programmers
<pecisk> nice
<LaserJock> and so I've been trying to look around to see what the best course of action would be
<slangasek> LaserJock: I think you'll find that the UI / model are the hard part, not the programming
<mvo> slangasek: right
<seb128> anyway GNOME did screw up some things recently
<LaserJock> slangasek: perhaps, but if all people know is pythong it's hard to get them wanting to hack on perl/C
<seb128> they learnt from it and we did too
<LaserJock> yikes, bad typo I did there :-)
<pecisk> seb128: I really hope so :) I love GNOME as desktop env. and don't wanna leave
<seb128> I don't think it's fair to troll that much on them breaking things
<seb128> they only really screwed gvfs-smb and gnome-session
<seb128> and that's because nobody raised enough concern early
<LaserJock> seb128: well, the point wasn't to troll, but rather to discuss/figure out what's going on
<pecisk> seb128: that indicates that isn't tested properly. We need some written, automated tests
<LaserJock> of course frustration was also in there, so sorry for some of that
<seb128> pecisk: that and that it's not always easy to know what users expect
<mvo> well, liboops provides the gobject mapping to the dbus backend. the dbus backend could be written in python instead of perl. now its the question if the gobject model for the user is a) good b) worth the effort
<seb128> they knew about session storing being broken
 * mvo has no answer to this question
<seb128> but they though nobody was really relying on it since it never worked correctly
<mvo> but whatever is done, a dbus/polkit based model very similar to g-s-t is probably the right ansewr
<LaserJock> mvo: what if we want the UI to change a fair amount?
<pecisk> seb128: of course, but users more or less expect desktop to work and be consistent
<mvo> its kind of sad, g-s-t was really ahead of its time in a sense
<seb128> pecisk: the intrepid desktop works and is consistent
<pecisk> seb128: if there is a feature, it should work
<pecisk> seb128: comparing to what? :) Hardy has different way to log out and switch off computer. PA completely changed way of doing things :)
<mvo> LaserJock: well, the ui could talk to the same dbus service. when using python the liboops layer is not really needed
<seb128> pecisk: depends of the feature, when you rewrite code you might decide to delay some things
<walters> mvo: there is some gobject user management code in gdm that i happen to be looking at right now actually, but it's not really designed around management
<pecisk> seb128: yes, but then distro or GNOME has to be sure it is mentioned and there is clear path to have to workaround problem
<walters> s/user management/user modeling/ i guess
<mvo> walters: interessting
<pecisk> otherwise it creates confusion
<pecisk> and lot of anger
<seb128> walters: it's all you fault, you guys are going to fast in rewrites ;-)
<pecisk> in both sides - users and developers
<mvo> LaserJock: but then, if you write a new UI and a new backend you can as well skip the compatiblity with liboops I guess
<walters> seb128: heh, well FWIW i'm personally kind of unhappy at the number of incompatible breaks
<walters> though X SM *is* broken by design, it sucks to not have offered any replacement
<pecisk> seb128: for example, there is vino caplet interface rewrite going on. Good developer added support for PnP autoconfiguration of firewall, but also removed Advanced tab and icons. I personally thought that vino finally got right gui, but seemingly developer thought otherwise.
<seb128> walters: me too, I talked a bit to vuntz about it, I think GNOME should be careful about accepting rewrites too quickly the user perception about GNOME is not good for some cycles, too many things which used to work which are not in new versions
<pochu> pecisk: what icons?
<walters> seb128: yeah
<mvo> LaserJock: g-s-t is using glade (well, .ui files) so a lot of the gui stuff can be done without code
<LaserJock> mvo: well, messing with the UI without hooking it up to code doesn't work too well
<seb128> walters: right, it's broken but some things were working, ie some software were closing correctly with the session before and now users are loosing work because it stopped doing that
<maxb> Hmm, with that mesa build still pending, for amd64, would now be a _really_ bad time to try an upgrade?
<mvo> LaserJock: depends on the changes :) but sure, if you want new functionality, then certainly not
<walters> seb128: that is a more serious concern, yeah
<pecisk> pochu: http://www.bani.com.br/lang/en/2009/01/new-vino-dialognova-tela-do-vino/
<slangasek> asac: bug #320652 for you :)
<ubottu> Launchpad bug 320652 in network-manager "NM 0.7 tries incorrectly to manage openvpn tap0 device as an ethernet device" [Critical,Confirmed] https://launchpad.net/bugs/320652
<walters> seb128: i think lucasr was looking at the session bug, hopefully we'll at least get some bare bones XSM support
<seb128> walters: right
<walters> i have a much better design for session stuff, hoping to get a chance to it at some point
<pochu> pecisk: ah, the icons in the UI
<pochu> pecisk: well, I wouldn't call that a regression, but YMMV
<pochu> pecisk: although I think an advanced tab is nice to have
<pochu> I'll talk to Jonh about it
<seb128> that's another issue sometimes
<pecisk> pochu: those icons didn't hurt anyone :) well, I personally like that sections of configuration has kind of visual indication. Helps on screens with huge resolutions and when you are farer from desktop than you would like.
<seb128> there is nobody really looking at the design but maintainers do what they want
<seb128> some take good choices, some are not
<pecisk> pochu: and this dialog was actually one of few where it was done right imho
<pochu> pecisk: yeah, I agree they're nice, but I wouldn't call that a regression ;)
<tjaalton> maxb: yes, it would.. if you have intel
<Amaranth> Although and "Advanced" button/tab/section probably means you've done something wrong in your application
<Amaranth> s/and/an/
<Amaranth> So that's not a big loss in the UI
<pochu> Amaranth: not really, you can change the listening port there for example
<pochu> or deactivate the wallpaper, or a few more things
<Amaranth> pochu: I think avahi should make that unneeded
<pochu> Amaranth: sorry for my ignorance :) but isn't avahi for local connections?
<Amaranth> Sure but that's what vino is targeting
<maxb> tjaalton: I don't really understand much about what mesa is, but I thought it wasn't solely intel-related? Am I save with an nvidia card?
<pochu> not really
<walters> mvo: http://svn.gnome.org/svn/gdm/trunk/gui/simple-greeter/gdm-user-manager.h btw, if it's useful
<Amaranth> That's why the port and whether to draw the desktop background are 'advanced' and/or 'not needed' options
<tjaalton> maxb: yes, nvidia diverts that stuff anyway
<pochu> or not only
<Amaranth> pochu: The UI makes it very clear vino is meant for LAN use
<Amaranth> The UI and the defaults, rather
<tjaalton> maxb: mesa provides the OSS libGL & DRI drivers
<tjaalton> among other things
<Amaranth> pochu: Although the UPnP autoconfiguration in the new one makes it clear the developer is conflicted on what the real use of the app is
<pochu> Amaranth: does it? I have to admit I've never used vino if not with localhost, but I didn't think it was for local networks only
<mvo> walters: thanks, I have a look (<- LaserJock might be interessting for you as well)
<pecisk> pochu: well, there is no rules to say what is regression or not, so I can't objectively discuss about that ;)
<pochu> pecisk: sure, that's why I said YMMV :)
<walters> mvo: at this moment preparing a patch to make it into a public library since we need it for gnome-shell
<pochu> pecisk: did you report a bug in bugzilla yet?
<Amaranth> pochu: but vino is configured by default to work best on LANs, otherwise it wouldn't draw the desktop
<pecisk> pochu: I thought that inform developer first is enough :)
<pecisk> pochu: I left comment in that blog post
<slangasek> Amaranth: "is meant for" -- um, I don't think it's reasonable to expect people who want /non/-local VNC to have to install a different implementation, or dig around in vino's guts
<Amaranth> slangasek: You just have to know the port and have a fast connection or open up gconf-editor
<slangasek> "know the port"?
<Amaranth> hopefully the UI at least mentions the port number somewhere
<Amaranth> and it doesn't
<slangasek> heh
<Amaranth> also: "Talk to the router and try to open the door there"
<Amaranth> wtf
<slangasek> clearly a typo, should be s/router/BBS/
<Skiessi> is x known to not work correctly after the latest upgrade?
<Skiessi> or wait I'll recheck if there's any updates
<maxb> Skiessi: If your video hardware is intel and your architecture is amd64, yes, it's broken due to buildd lag
 * Amaranth remembers to not restart X
 * Amaranth stops working on compiz stuff that can freeze X
<Skiessi> video hardware is intel but I think I'm using the 32-bit version
<maxb> Skiessi: dpkg --print-architecture
<Skiessi> okay. booting
<Skiessi> i386
<maxb> I guess you  have a different problem then
<Skiessi> I'll take a pic :p
<directhex> where would i file a bug against the start.ubuntu.com google page?
<Laney> https://bugs.launchpad.net/ubuntu-website
<directhex> aha, already open as lp 305905
<ubottu> Launchpad bug 305905 in ubuntu-website "start.ubuntu Google CSE has fewer features" [Medium,Confirmed] https://launchpad.net/bugs/305905
<pochu> Amaranth: well, it shows the port in the advanced tab in 2.24, that was pecisk was complaining about
<pochu> Amaranth: and it uses the default VNC port, so there's not much you need to know unless you change it
<Amaranth> In that case it's fine to not have it in the UI
<Amaranth> and not drawing the wallpaper is usually not something you need to do
<pochu> well, what's wrong with an Advanced tab?
<pochu> I think it does no harm and otherwise you need to go to gconf
<Amaranth> pochu: "Advanced" means "I failed to find a place for these and failed to make you not have to care about them"
<slangasek> and somehow sending people to gconf is better?
<Amaranth> like the background thing, it should do that on the fly if it detects your connection is bad
<pochu> Amaranth: I disagree. Advanced means "I want to further customise it"
<pochu> Amaranth: so, should we move NM's VPN to a config file or gconf, for example?
<pochu> because if you plug your cable and it doesn't work, then it shouldn't be in the UI
<pochu> (at least that's what I understand from your reasoning)
<Amaranth> VPN is a large thing to setup and has it's own configuration section
<Amaranth> and there is no way to automatically set it up
<pochu> I don't think an Advanced tab means there's no better place for it
<pochu> it's just an advanced tab, something you likely don't want to change, but if you do, there you have
<Amaranth> It may not have to mean that but it almost always does
 * LaserJock looks around for a UserKit project
<Amaranth> Advanced turns into a dumping ground for all the things random people think they should be able to tweak and things where you couldn't decide what a default should be
<Amaranth> 100 lines of code and an option or 1000 lines of code and it just does the right thing, I'd go for the latter
<slangasek> you're assuming the latter is one of your choices
<slangasek> if there's no one to write the right 1000 lines of code, it isn't
<Amaranth> I'm saying if I'm writing the app, that's how I'd go
<pochu> having a good default doesn't mean you should hide the setting from the UI
<pecisk> Amaranth: but not in this scenario, I was there when previously that dialog was designed, and Advanced was generally accepted
<Amaranth> Or if one option was used by 90% of my users I'd ditch the option
<slangasek> sorry, but I think that's naive, you don't always anticipate all the "right" answers when writing a program :)
<Amaranth> one choice for an option, rather
<slangasek> Amaranth: er, you'd screw over 10% of the users?
<slangasek> you think it's acceptable for 10% of the users to have to dig around in gconf?
<Amaranth> I wouldn't even put it in gconf unless it was a tiny bit of code to maintain
<lamont> so... the printer config settings widgit thingy.... it seriously won't let you share printers on the network without announcing them?  sigh
 * lamont hugs vi
<pecisk> Amaranth: first, you really have any veryifable metrics about that 90% versus 10%, have you?
<Amaranth> That's problem 2, we have no idea what our users are doing with our apps
<pecisk> exactly
<Amaranth> Microsoft does, why can't we?
<pecisk> so you can't claim "90% don't need this feature"
<pecisk> Amaranth: Microsoft doesn't
<ScottK> Microsoft's number is 80%
<slangasek> lamont: hmm?  announce how?
<pecisk> Amaranth: Microsoft makes study and real ui design according to "how they think it should work"
<Amaranth> pecisk: The default in their apps is to report usage statistics
<Amaranth> How many times do you use the menu for Cut/Copy/Paste? How many times do you use the keyboard? They know these things
<ScottK> pecisk: And then you get the Vista logout/shutdown diaglogue monster as a result.
<Amaranth> Also, any easy way to figure out how to do settings: Look at what compiz does, do the opposite
<pecisk> Amaranth: ok, I think we went wrong path here
<pecisk> what I wanted to say
<Amaranth> s/any/an/
<lamont> slangasek: broadcast or multicast, dunno
<pecisk> is if there a feature, and if someone, at least two people need it, and we can have it without ruining simplicity
<pecisk> well
<pecisk> it would be nice to have it
<lamont> whatever the "look at me I HAZ PRINTAR!" IPP method is
<pecisk> and plan to have it
<slangasek> lamont: well if it's broadcast or multicast, it's not IPP :)
<lamont> whateveh
<slangasek> lamont: if it's broadcast or multicast, I guess it's ultimately avahi's doing?
<maxb> The nice folks on #launchpad have unwedged yellow. However the build on crested looks to be stuck - judging by the previous buildlog it will be killed in another couple of hours by the "150 minutes with no activity" criterion. Is it worth asking someone to terminate it earlier, in view of the previously mentioned mesa/intel/amd64 breakage?
<lamont> system -> administration -> printing -> settings -> lines 2 and 3 on an intrepid box
<Amaranth> pecisk: That way leads to GNOME 1.x
<Amaranth> pecisk: We've learned from those mistakes
<lamont> maxb: let me go look at it for giggles
<slangasek> lamont: also, server -> settings -> publish shared printers connected to this system doesn't control what you want? or is that jaunty only?
<lamont> slangasek: I want allow printing from internet, but not publish printers
<maxb> lamont: http://launchpadlibrarian.net/21472199/buildlog_ubuntu-hardy-amd64.ardour_1%3A2.7.1-2~hardy1_FAILEDTOBUILD.txt.gz  <-- the previous buildlog, which wedged in the same place
<lamont> _I_ know what they are, you see...
<pecisk> Amaranth: really? I think GNOME 1.x didn't have much features and they didn't worked well
<Amaranth> pecisk: You can look at GNOME 1.x and say "well obviously that's too complex" but it was death by a thousand cuts
<pecisk> Amaranth: what is too complex? For me is too complex to put vino into encryption mode using gconf
<Amaranth> pecisk: You ever see the configuration in GNOME 1.x? The panel had 2 or 3 "unbreak me" options you could toggle
<slangasek> lamont: hrm, I guess maybe I configured my acl in /etc/cups/cupsd.conf by hand, doh
<pecisk> Amaranth: yes, I used it for two years :)
<lamont> strace -p 17061
<lamont> Process 17061 attached - interrupt to quit
<lamont> msgrcv(272531459,
<lamont> maxb: ^^
<lamont> stupid ipc
<lamont> slangasek: like I said: vim deserves hugging
<pecisk> Amaranth: but where is connection with what I said and GNOME 1.x?
<Amaranth> pecisk: If two people want the option and it's not much code to provide put it in
<Amaranth> pecisk: That leads to configuration like GNOME 1.x
<lamont> slangasek: I mean, announcing them to the world is definitely toeing the free-beer line
<Amaranth> pecisk: You have to ignore some users wishes for the betterment of the rest of the users, the only argument should be where the cutoff point is
<slangasek> lamont: the GUI says 'publishing', I think that refers only to whether they're browseable - so not really an announcement per se...
<pecisk> Amaranth: so you have to cut it already universally accepted Advanced tab from Vino dialog just to prove that there should be cutoff?
<lamont> slangasek: well, I know that when I turned that option, it added BrowseAddress @LOCAL, and my laptop magically found all the printers on the amchine...
<lamont> just sayin'
<pecisk> I agree that introducing of new advanced features
<pecisk> that it should be clearly a line when it shouldn't be in the front of the user
<pecisk> it/there/s
<pecisk> but
<pecisk> old Vino dialog was job of some three or four bug reports
<pecisk> with requests to having these Advanced features in gui
<pecisk> including port, encryption and disabling wallpaper
<Amaranth> three or four?
<pecisk> yes
<pecisk> as far as I remember
<Amaranth> I'd be looking for more like 100
<pecisk> Amaranth: three or four with LOT of comments ;)
<Amaranth> pecisk: Encryption should probably go in the UI somewhere
<Amaranth> port and wallpaper, no
<slangasek> lamont: hmm, looks like without setting that option, my printers aren't exposed over avahi, interesting
<Amaranth> port is the default and you really shouldn't have to change it, disabling wallpaper should be an automatic thing
<pecisk> Amaranth: I agree about port and wallpaper
<pecisk> see
<pecisk> it is not that hard :)
<pecisk> anyway
<lamont> maxb: thinking here is that it's scons
<pecisk> for positive side, it was great to have such blog post about new dialog
<lamont> maxb: hardy kernel on the machine, inside whatever chroot that is
<pecisk> so anyone could comment about it on early stage
<Amaranth> pecisk: Do you use compiz?
<pecisk> Amaranth: very very rarerly. It is nice, but somehow it still have lot of artifacts
<Amaranth> pecisk: Ok then, have you ever looked at the settings for compiz?
<pecisk> Amaranth: Desktop Effects or Compiz itself?
<Amaranth> I never want to see that happen to any project ever again
<Amaranth> compiz itself
<pecisk> ahhh
<pecisk> that infamous monster configuration gui? :)
<Amaranth> The excuse for compiz was it's a research project so we have to allow all these options to see what works best
<Amaranth> The problem is we can't get rid of them now :/
<Amaranth> I tried to write a plugin that would ensure certain plugins were loaded and disable a lot of the options but couldn't make it work
<Amaranth> Originally the plugin was called 'metacity', right now it's called 'sanity' :P
<pecisk> :D
<pecisk> I understand your struggle
<Amaranth> I suppose we could just strip the XML for those options in Ubuntu, then ccsm wouldn't show them
<pecisk> Amaranth: what I really would like to see is some kind of spec for GNOME, to keep in check main features so they don't get lost, or if they are gone, there is documented workaround or solution. It would lower a confusion between users a lot.
<pecisk> yeah
 * maxb raises eyebrow at release-upgrader removing openssl-blacklist
<pecisk> anyway, was nice to discuss all this with you devs. Cheer up and keep on doing great work. And forgive us users and testers that we whine too much sometimes :)
<pecisk> see ya
<maxb> Hmm. Jockey just proudly announced that I'm using no proprietary drivers... but I'm using nvidia-glx :-/
<LaserJock> wow, nvidia must have gone open source! ;-)
<Amaranth> LaserJock: Sweet, now I can comment out the crashXServer() function
<Amaranth> and the corruptKernelMemory() one too!
<directhex> pitti, poke
<directhex> asac, poke also
<LaserJock> it's pretty late on a Friday for them
<directhex> true
<directhex> but i've found the bug which relates to a problem so infuriating i was seriously considering drastic measures like using vista, or worse, kubuntu
<slangasek> directhex: ?
<directhex> slangasek, lp 286119 has been driving me round the bend for MONTHS
<ubottu> Launchpad bug 286119 in samba "firefox 3.0.3 crashes (no SIG) on most pages w images: 8.10beta AMD64" [High,Fix committed] https://launchpad.net/bugs/286119
<directhex> perhaps longer
<directhex> i might've been unfairly blaming nspluginwrapper all this time
<slangasek> directhex: hrm, odd; never seen that bug here
<directhex> slangasek, do you have an intersection of amd64, winbind, and lots of tabs?
<directhex> and possibly not being connected to a domain is relevant too
<slangasek> directhex: er, oh, misleading description - I certainly /am/ familiar with that bug once I see which bug it is
<directhex> it was in some old sarge bugs
<slangasek> directhex: well, s/winbind/nss_wins/ - I never use nss_wins, it's Broken By Design
<slangasek> fix is supposed to be in intrepid-proposed now, anyawy?
<directhex> slangasek, no amd64 binaries that i can see. possibly buildd delay or mirror delay
<slangasek> right, amd64 seems to be lagged for SRUs
<maxb> yellow had a stuck build for 3 days, didn't help matters.
<pochu> directhex: that looks familiar
<pochu> isn't it the same as bug #214192?
<ubottu> Launchpad bug 214192 in liferea "liferea-bin crashed with SIGSEGV in _nss_wins_gethostbyname_r()" [Medium,Invalid] https://launchpad.net/bugs/214192
<directhex> pochu, description sounds identical
 * pochu duplicates it
#ubuntu-devel 2009-01-24
<mib_95abugt7> hello
<mib_95abugt7> can you give me an ETA for a package to be built in the main archive?
<cody-somerville> mib_95abugt7, not without the name of the package
<ScottK> My estimate is two days.
<mib_95abugt7> cody-somerville: xserver-xorg-video-intel_2.6.1-1ubuntu1 is the package
<ScottK> cody-somerville: We can give an estimate.  I just won't be very accurate.
<mib_95abugt7> no problem, I just want to know if it'll be soon, or I'll have to wait up to tomorrow
<mib_95abugt7> or maybe more
<cody-somerville> we can make it sooner.
<mib_95abugt7> that would be great
<mib_95abugt7> I need the amd64 version, if it matters
<Amaranth> mib_95abugt7: The buildd broke, dunno what the status is now
<Turl> Amaranth: :/
<cody-somerville> Amaranth, what do you mean?
<Turl> what about xserver-xorg-video-intel_2.5.1-1ubuntu9? it might contain the fix I need
<Amaranth>  <tjaalton> could a buildd admin kick yellow (amd64)? it's been stuck for a couple of days now.. https://edge.launchpad.net/ubuntu/+source/qt4-x11/4.4.3-0ubuntu1.2/+build/842557
<Amaranth>  <tjaalton> Keybuk: could you have a look at yellow (the buildd). I'd really need to get mesa  et al built on amd64 to avoid bugs like bug 320525
<ubottu> Launchpad bug 320525 in xserver-xorg-video-intel "jaunty unbootable on intel G45 since .28-5 kernel update" [High,Fix committed] https://launchpad.net/bugs/320525
<Amaranth> sorry for the pings guys :/
<cody-somerville> Amaranth, we have two amd64 buildds
<cody-somerville> Is there a problem with crested as well?
<Turl> Amaranth: that is exactly the bug I'm experiencing :p
<Amaranth>  <max.b> The nice folks on #launchpad have unwedged yellow. However the build on crested looks to be stuck - judging by the previous buildlog it will be killed in another couple of hours by the "150 minutes with no activity" criterion. Is it worth asking someone to terminate it earlier, in view of the previously mentioned mesa/intel/amd64 breakage?
<Amaranth> cody-somerville: yes :/
<Amaranth> although it looks like they should both be going at this point so...
<cody-somerville> So when it says "build started 19 minutes ago", its lying?
<cody-somerville> (isn't being facetious)
<Amaranth> cody-somerville: No, as those pastes show they should be working again by now
<Amaranth> cody-somerville: But I think they are a bit behind
<cody-somerville> Well, from what I can see, they only have 17 builds in the queue.
<cody-somerville> the xserver-xorg-video-intel package should build in 3 hours or so if the buildds for amd64 are working
<Amaranth> cody-somerville: how about mesa?
<Turl> 3 hours? mhm, I'll have to test tomorrow I guess
<cody-somerville> Amaranth, whats the source package name?
<Amaranth> cody-somerville: mesa
<cody-somerville> Amaranth, 3 hours as well
<cody-somerville> (to start)
<Amaranth> although I think mesa takes some time to build so...
<Amaranth> I dunno, I've only done it once
<Turl> are ubuntu.com & launchpad.net down, or is it my internet playing tricks with me?
<cody-somerville> They do see slow
<cody-somerville> (or launchpad does atleast)
<Amaranth> yeah, launchpad is a little laggy for me as well
<Turl> firefox throws "interrupted connection" on launchpad, and ubuntu.com keeps connecting, but won't show
<Turl> btw, any possibility of including php-gtk on jaunty? it isn't packaged on debian...
<directhex> no offence, but who would want to write gui apps in a hypertext parser?
<Turl> me directhex. PHP isn't just an hypertext parser. It's a complete scripting language, just like python is
<Turl> a guy did once a package, and was looking for sponsoring in debian, I contacted him once, and he said he was too busy to get sponsoring, but the package was done. Maybe you can include it? or should I talk with MOTUs?
<directhex> i'm reasonably confident that the PHP Hypertext Preprocessor is primarily centered around hypertext, but perhaps i'm just an old cynic
<Turl> directhex: php-cli exists for a reason, don't you think?
<cody-somerville> Turl, upload the source package to revu
<cody-somerville> Turl, I'll review it for you tomorrow if you'd like
<Turl> cody-somerville: I'll mail this guy once again asking him for it, I'm not the packager nor I know much about packaging.
<directhex> Turl, i just find it an immensely odd choice of language for non-hypertext tasks. php's strength lies in the ease with which you can inject a little intelligence into <html>
<directhex> each to his own, of course
<Turl> also, I need to get my jaunty working to upload it, I guess you use dput?
<cody-somerville> yup
<Turl> directhex: PHP's strength lies in it's ease of use. not on the ability to modify HTML
<Turl> directhex: there surely is a lot of other langs to use for non-hypertext tasks, the same way you can use non-hypertext languages like c++, c, etc to build webpages
<slangasek> except C and C++ programmers have the good sense not to use those languages for html processing. :)
 * directhex shoves slangasek into cgi-bin
 * slangasek opens a series of back doors
<Turl> I don't want to start a flamewar :p the fact is, php does gtk, and it's quite good at it, although documentation lacks sometimes
<directhex> and people call MY platform choices eccentric :x
<cody-somerville> Amaranth, both amd64 buildds are working fine as far as I can tell
<Turl> PHP even does GL graphics iirc
<LaserJock> and you can write a kernel in python
<directhex> LaserJock, you never tried out perl-linux? :)
<cody-somerville> Turl, btw, there is no builds in the queue for amd64 buildds. You could build that package for yourself in your own ppa.
<Turl> cody-somerville: If I knew how to use dput without a .changes :p
<Turl> LaserJock: believe it or not, http://phpopengl.sourceforge.net/
<cody-somerville> Turl, just create one
<Turl> cody-somerville: I know really basic things about packaging, "just create one" is not enough for me to understand :p
<cody-somerville> Unpack the source package and run debuild -S -sa inside OR Install a package called 'reprepro' and use the changestool to create a changefiles (see manfile for details).
<Turl> now, I need to remember how I configured my .dput.cf for my ppa...
 * Turl googles around a bit
<Amaranth> Turl: apt-get -b source mesa
<Amaranth> Turl: just build it locally
<cody-somerville> or that
<cody-somerville> Turl, Are you on Jaunty? just do dput ppa:<your lp login> <changesfile>
<Turl> apt-get -b? didn't know that one
<Turl> cody-somerville: currently, I'm on vista, as my Jaunty has no X
<cody-somerville> Turl, I have an idea. Why not install Hardy or Intrepid? :)
<Turl> cody-somerville: because I don't want to break my MBR again? I killed it once with dd, and I recovered everything but my valuable data :/
<cody-somerville> Turl, backups?
<Turl> also, I don't think the intrepid installer can resize ext4
 * cody-somerville gives up.
<cody-somerville> :]
<Turl> cody-somerville: no money to get another disk to backup? :) if you pay for it, I'll backup and install intrepid
<Turl> also, I found jaunty quite stable, despite the 2 or 3 lockups a day
<Turl> Amaranth: do you know whether the "keyboard and mouse stop responding" bug is related to this one?
<Turl> I cannot check the bug number now, launchpad won't open
<Turl> well, I'll reboot and try to build the packages
<Turl> really, thanks guys for helping :)
<caimlas> anyone know if there's a fix for the kernel post-2.6.18 I/O latency/load issues in the pipeline yet?
<Rocket2DMn> hey bryce , what is the "pet-bug" tag for?
<bryce> heya Rocket2DMn
<Rocket2DMn> i definitely lol-ed when i saw it
<bryce> heh
<Rocket2DMn> is that tag some sort of inside joke?
<Rocket2DMn> or does it actually mean something
<bryce> no, it was suggested by management for marking some long standing bugs that we'd like to get around to fixing
<bryce> so we were asked to mark 10 or so
<Rocket2DMn> ah, well, its fixed
<Rocket2DMn> \o/
<bryce> great :-)
<Rocket2DMn> yeah and two days latear i got a sweet kernel oops
<bryce> yeah I picked ones that looked like low hanging fruit we could clear up by jaunty
<Rocket2DMn> cool, i hope we can push a lot of bug fixes through for jaunty in all departments
<Rocket2DMn> tbh i was a little disappointed with intrepid
<bryce> hey speaking of pushing lots of bug fixes, here's something I did up today for tracking that for X -- http://people.ubuntu.com/~bryce/totals.svg
<Rocket2DMn> i like what i see between 1/22 and 1/23
<Rocket2DMn> some good intel fixes huh
<LaserJock> bryce: that's a rediculous amount of bugs, I feel for you dude
<bryce> Rocket2DMn: partly, although mostly that was a bunch expiring on that day.  But we did put out the 2.6 driver which hopefully will resolve a lot of those anyway
<bryce> LaserJock: heh thanks, yeah quite a load
<pwnguin> are there really close to 500 wacom-tools bugs?
<bryce> we're down from a total of around 2200 last fall
<bryce> pwnguin: no, you're reading the colors wrong ;-)  I think you're looking at the lrm bugs
<pwnguin> ah
<pwnguin> surely you can do a better spectrum than that :P
<bryce> the order of items int he key matches the order in the chart
<pwnguin> except the chart goes up and the legend goes down
<Rocket2DMn> man i hope we can nuke a bunch of those during the bug jam
<bryce> Rocket2DMn: that'd be sweet
<bryce> Rocket2DMn: the majority of these bugs need to be re-tested against jaunty, and the ones that have been tested need to go upstream
<Rocket2DMn> i wonder what a graph organizing them by date would look like
<Rocket2DMn> like a bar graph with a full month of bugs
<Rocket2DMn> that is to say, each bar is the number of bugs reported that month
<bryce> ah
<pwnguin> im guessing huge spikes at release
<bryce> more plots here:  http://people.ubuntu.com/~bryce/Plots/
<LaserJock> bryce: hmm, a whole lot of -intel bugs
<bryce> yeah, from -beta up until a month or so post-release we do see a surge in bugs
<bryce> LaserJock: yeah :-/
<pwnguin> at least with wacom-tools, there's been more activity upstream recently
<Rocket2DMn> haha yeah those 2 weeks after release are intense
<Rocket2DMn> though i guess its not as bad as it looks
<pwnguin> how many unassigned bugs do we have left?
<bryce> otoh, around that time it tends to be easier to get people to test, so it can be easier to get old bugs marked off the list, if you can stay on top of the surge
<pwnguin> 3 thousand?
<Rocket2DMn> thats just way too many bugs, i wonder how many can just be wiped out for being old
<bryce> Rocket2DMn: for X, not as many as you'd think unfortunately; we have pretty okay turnover of old bugs
<bryce> most are simply incomplete waiting on users for more info
<Rocket2DMn> yeah bryce , but how many follow up with the complete amount of information needed?
<bryce> or, we've got the info and someone just needs to look and do some preliminary analysis
<bryce> hmm, I'd say somewhere  between 10-25% follow up
<bryce> the rest end up expiring after a few months
<Rocket2DMn> thats about what i would expect, X is tough to deal with from a normal user's perspective.  Heck I have a decent understanding of whats going on and it scares me too
<bryce> me too
<bryce> ;-)
<bryce> really it's the freeze bugs I hate; those are a b!tch to troubleshoot, and we've got a slew of them
<bryce> crashes are tractable if we get a backtrace
<Rocket2DMn> you mean when X just locks up w/out actually crashing?
<bryce> right
<bryce> those are the hardest bugs
<Rocket2DMn> yeah
<Rocket2DMn> it would be nice if i had more time to play with this stuff, but unfortunately, gotta pay the rent
<bryce> pesky rent
<mib_iehgz0> hi, I'm back
<Rocket2DMn> hehe, yeah bryce , but hey, these days just glad to be employed
<bryce> quite true
 * Turl goes back and reuploads to his ppa
 * calc is almost proud of his bug stats now
<calc> 11 new and 1 confirmed, rest incomplete or triaged :)
<cody-somerville> YOU TRIAGED ALL THE BUGS IN LAUNCHPAD?!?!
<cody-somerville> :P
<calc> still have 39 bugs to send upstream
<calc> cody-somerville: all OOo bugs
<cody-somerville> oh wow... still quite the accomplishment!
<calc> yea :)
<calc> it appears i have about 26 bugs to fix for jaunty, some are dupes i still need to merge though
<calc> wth is with these PSA's telling you to unplug your cellphone charger?
<calc> i checked mine with a meter and it pulls effectively 0 watts with nothing hooked up to it, 1 watt with a phone that is charged with the lcd off, and 2 watt with the phone charged but with the lcd on
<calc> the commercial probably used more power than my charger does all day
<ScottK> calc: Clearly you're in favor of global warming and would like to see the Earth destroyed.
<kees> -love Al Gore
<gQuigs> Looking for feedback on my feature, https://wiki.ubuntu.com/Specs/no-input-recovery
<calc> ScottK: perhaps some cell phone chargers are defective?
<calc> ScottK: all i know is i own a watt meter that i check my stuff with and saw that PSA so tested mine and it seemed to be bunk
<ScottK> calc: I think it's much more likely that no one ever sat down and actually measured.
<ScottK> Remember, it's not the truth that counts, but the truthiness.
<calc> ScottK: hehe
<ScottK> Unfortunately that wasn't a joke.
<ScottK> That seems to be the prevailing wisdom these days.
<calc> a better PSA would be to have people buy watt meters and check their stuff, but that wouldn't be as cool
<calc> they cost < $20
<calc> my computer draws a lower than expected amount of power as well ~ 100W idle (iirc)
<calc> ~ 150W at full load
<ScottK> Many years ago I was involved in US Navy warship combat system design and ship integration.
<ScottK> Most of the electronics were water cooled.
<RAOF> I suppose there's a good supply of the stuff, at least.
<ScottK> They had X number of chillers to keep the cooling water at the right temperature.
<LaserJock> calc: yeah, I would think that a watt meter would be the best tool
<ScottK> They had always designed chill water requirements based on the spec values for how much heat each piece of equipment put out.
<ScottK> They got to a point where for the next version it was going to break the bank and they'd have to do an expensive chill water system redesign.
<ScottK> Someone suggested actual measurements first.
<ScottK> So they went out with some fancy calorimeters to measure how much heat was actually being dumped.
<ScottK> By the time they added it all up, it was WAY less than they'd been designing to (because all the spec values were worst case plus some margin).
<ScottK> So the redesign got cancelled because it wasn't actually needed.
<calc> heh
<ScottK> RAOF: Actually having the right water was a bitch because the water had to be sufficiently pure to be non-conductive.
<ScottK> So measuring helps.  Not enough people do it.
<calc> yea 150W on my system i think is worst case I was running some cpu burn in program that uses it much more than generally anything else
<pwnguin> distilled water isn't hard to come by...
<RAOF> Ooh.  It was _immersed_ in water, rather than using water as heat conduction?  Owch.
<ScottK> RAOF: Well that's how they got good heat transfer.
<RAOF> And a really abiding interest in keeping the water pure, too!
<ScottK> pwnguin: And keeping it pure was tough.  Even copper oxides from the pipes could be problematic.
<ScottK> yeah.
<pwnguin> ScottK: now that i think about it, warships are typically sitting on top of very very not pure water
<ScottK> The chill water pipes were copper-nickel for shock resistance, which aren't so great for keeping the water that pure.
<LaserJock> yeah, I have to have pure water for my laser or I get 25k Volts arcing
<ScottK> ;-)
<LaserJock> but I don't go through a lot so it's not that big of a pain
<pwnguin> i didnt read the full history
<pwnguin> i figured it was some dude who's like, vegstable oil cooling? try water!
<lfaraone> superm1: What's the status of bug 261721 for Dell machines? I'm experiencing it in Intrepid with -updates on an XPS m1330, although brighness isn't a problem, it's that "fn+f3" (battery status) is stuck until I go to a VT.
<ubottu> Launchpad bug 261721 in linux "X never sees brightness key release events on Dell laptops" [High,Fix committed] https://launchpad.net/bugs/261721
<pwnguin> my alma mater's nuclear plant uses water as radiation guard
<pwnguin> they like to toss hair dryers in it to show how it's awesome and distilled and safe
<LaserJock> hmm, we use an ohm-meter
<johanbr> A former Swedish prime minister went for a swim in the cooling water of one nuclear reactor.
<pwnguin> did he go on to found a school where mutants like himself could live in peace?
<RAOF> What is the ionisation potential for water, anyway?
<johanbr> He's still alive and looking normal. As normal as he did before, anyway. :)
<pwnguin> RAOF: having no idea what the phrase means, im going to say 1, because people like to base things relative to water ;)
<LaserJock> RAOF: about 12.6 eV
<RAOF> pwnguin: I meant - at what voltage density does it become conductive.
<johanbr> I'm going to guess that it's not that different from atomic hydrogen - 13.6 eV.
<RAOF> "voltage density" might be a phrase I made up :)
<pwnguin> 10.56 eV in water according to teh internets
<LaserJock> hmm, NIST has ~ 20 determinations that say 12.6 eV
<pwnguin> i defer to the scientist
<LaserJock> well, I usually defer to NIST
<LaserJock> I watched a presentation from a guy who spent 20 years trying to get another decimal place on the vibrations of the boron atom
<LaserJock> those guys are super anal
<johanbr> "boron atom" is a good setup for a joke, if nothing else :)
<pwnguin> a guy came to my uni a while back talking about atomic clock design
<LaserJock> johanbr: don't get me going on chemistry jokes ;-)
<slangasek> calc: what sort of watt meter do you have?
<slangasek> jelmer: hmmm, so does bug #320742 mean the existing repo is toast?
<ubottu> Launchpad bug 320742 in bzr-svn "Should handle joins" [Medium,Triaged] https://launchpad.net/bugs/320742
<jelmer> slangasek, no, mainly that it's an easier problem to solve than bug 295416
<ubottu> Launchpad bug 295416 in bzr-svn "branch root moving breaks missing and push" [Medium,In progress] https://launchpad.net/bugs/295416
<jelmer> as there is no root moving involved (which is hard to get right)
<calc> slangasek: kill a watt
<slangasek> calc: ok - in the past I've seen clamp-on meters that measure inductively, but I don't think those were < $20. :)
<calc> slangasek: there are some better ones that do logging as well but they are > $100
<calc> this one just shows current usage
<slangasek> ah, so it only measures instantaneous power?  Hmm, suboptimal
<calc> slangasek: it can log usage over time but not log continous instantaneous power
<calc> aiui some take a reading every 1s or 5s and log it for you to look at later
<slangasek> but it doesn't take the area under the curve, so isn't a true measurement of energy use over time
<calc> but assuming it doesn't do something really weird like spiking up for very short intervals you can get a good idea of what it is using, or am i missing something?
<slangasek> calc: the power consumption of a computer isn't flat, so sampling the current could be fairly inaccurate
<calc> well for something like a idle cell charger
<slangasek> e.g., what if your hard drive is spun down every time it samples just by chance. :)
<slangasek> right, for that it should work fine
<calc> yes on my computer it jumps around quite a bit unless i am leaving it idle or full throttle
<calc> slangasek: my original comment wrt the watt meter was that there was a PSA on tv telling you to unplug your not in use cell phone charger, and after testing mine it showed 0 watts being used, even with the cell phone plugged in it was only using 1 watt (it was already fully charged)
<slangasek> sure, I saw that
<calc> ok
<slangasek> I was inquiring out of interest in power metering generally. :)
<calc> oh ok
<slangasek> though for the time being, I know where our power is going, and I don't need a watt meter to tell me to find a solution to save on heating
<slangasek> stupid atypical winter weather
<calc> its 64F here even at midnight
<calc> it was around 80 this afternoon i think
<slangasek> it's 37F here, even at noon ;P
<calc> it seems to alternate here between freezing and 80F
<LaserJock> yeah
<calc> anyone else having trouble with debootstrap in jaunty?
<slangasek> debootstrap /in/ jaunty, or debootstrap /of/ jaunty?
<slangasek> (the answer, for me, is no in both cases because I haven't tried it lately :)
<calc> ok
<StevenK> slangasek: Shall I send you some excess heat, it's 37 degC here
<slangasek> StevenK: please to be
<calc> i'm running jaunty on my desktop and was trying to run deboostrap on it
<slangasek> StevenK: ... making a wormhole, I'll install a turbine in the mouth and it'll be a perpetual motion machine
<calc> doh i know what i did wrong, oops
<calc> i forgot to resetup my /etc/hosts file
<StevenK> slangasek: Haha
<orogor> hi here, anyone online?
<syockit> Not app development on Ubuntu, it says. Where do I go for one?
<orogor> i get very frequent system freeze, would anyone have some hint on how to debug that , if i can t  network that computer with another ?
<persia> syockit, Generally the advice is to go to a specific forum for the sort of thing you are developing, and once the app is done, then bring it to Ubuntu.
<persia> syockit, So, if you were, for example, developing a GNOME app, you'd want to visit the GNOME channels.
<persia> orogor, You may find that #ubuntu-bugs is a better place to ask for help understanding and documenting bugs.
<syockit> Actually I wanted an example of packages with multi binaries
<syockit> so I got myself pulseaudio
<persia> syockit, Oh, for packaging discussion, #ubuntu-motu is the preferred forum.
<BUGabundo> good morning
<BUGabundo> persia: can you tell me where to find crimsun ?
<persia> BUGabundo, /whois is probably the place to start.  Beyond that, I can't help you.
<orogor> persia, well actually i had something in mind , there s a linux feature that allow to bootstrap from a first kernel before starting the new one and it s  different from an initrd
<orogor> persia, would you remember how it s called ?
<persia> orogor, I don't.  Maybe something related to kexec()?  Sorry, but that's fairly well outside my knowledge.
<orogor> yes , kexec
<orogor> persia, any plan in throwing kexec into gentoo , in order to debug kernel issues ?
<orogor> alla blue scrreen from windows
<orogor> ... anyhow i ll join the bugs channel and see if they can be of any help
<BUGabundo> dtchen: ping
<emgent> morning
<BUGabundo> hi emgent
<syockit> compiling!
<orogor> persia, as far as i understand the bug you speak was solved about a year ago
<orogor> so i souldnt  have this bug when runnign hardy
 * ogra grumbles about dash's read not supporting -n or -s
<superm1> lfaraone, you need to have the upgraded kernel.  whenever it's released to -updates you'll be fine
<superm1> lfaraone, it's been in proposed since basically the week after intrepid launched
<lfaraone> superm1: so I should just enable proposed and update?
<superm1> lfaraone, you should grab the kernel from -proposed (and appropriate headers, meta, and LRM if necessary).  You don't need anything else out of proposed though
<lfaraone> superm1: Thanks!
<CruX|> hello all, I just updated my system to kbuntu 8.10, and i have problem with my keyboard. I set my keyboard rate with "xset r rate 200 70". All keys are working with exception of downarrow and leftarrow - wait delay is much bigger than 200 ms. What's wrong ? on kubuntu 8.04 it worked.
<lfaraone> superm1: sorry, i'm a bit noobish, but what's the package name of the new kernel? I can't seem to see it even after enabling proposed (and pinning to updates)
<ScottK> lfaraone: You should get it by installing the appropriate metapackage (e.g sudo apt-get install linux-generic (I think that's what it's called)) that'll pull in the new kernel packages.
<BUGabundo> ScottK mine is still on -4
<BUGabundo> I had to manually choose -5
<logari81> I think this one:
<logari81> * Drop 102_dont_vblank.patch, since the new drm code in the kernel fixes the bugs that it worked around.
<logari81> in mesa update of today destroyed this picture:
<logari81> http://img515.imageshack.us/img515/1466/screenshotfn6.png
<logari81> for my ati X700
<logari81> now googleearth with composite flickers like in intrepid and e.g. cant be projected on the cube
<logari81> I hope this is the right channel to mention that
<ScottK> logari81: Probably better on #ubuntu-kernel
<ScottK> Even better, file a bug.
<logari81> ScottK: ok thnx
<lfaraone> Has the location of UDSJaunty+1 been announced yet?
<jpds> lfaraone: No.
 * lfaraone hopes for something east-coast, there was no way he could make it to the googleplex.
<jpds> lfaraone: Seeing as it changes US->Europe, it'll probably be in Europe.
<cjwatson> ArneGoetje: I noticed that the translation focus for Ubuntu was still listed as intrepid, and changed it to jaunty. I think that makes sense at this point; otherwise shout.
 * ScottK notes to directhex a mono NMU sitting in Debian incoming and wonders if we want it?
<directhex> ScottK, it's a ~no change rebuild
<ScottK> OK, so not relvant to us then.   Thanks.
<directhex> ScottK, now, we want the version it's an nmu from, but we either need to have dh 7.1 in jaunty first, or i need to make a merge patch which reverts some changes
<directhex> and i don't think i heard a final decision r.e. dh7.1
<lfaraone> superm1: Hm, I upgraded to the new kernel, but now my nvidia kernel module won't start.
<directhex> ScottK, if you make a call on mono s/sync/merge/ or dh7.1, let me know :p
<superm1> lfaraone, yeah that's why you need to pull in all the headers too
<lfaraone> superm1: ok, what's the package name I want again?
<superm1> lfaraone, there's a metapackage to go with it.  probably linux-headers or similar
<ArneGoetje> cjwatson: where was it listed?
<lfaraone> superm1: new kernel, and now we have _intermittent_ problems with fnup-fdown, sometimes it reads one push as two
<lfaraone> superm1: however, my pwrstatus thing is fixed. thanks!
<nixternal> x-session-manager[3989]: WARNING: Detected that screensaver has left the bus
<nixternal> hahahaha
<nixternal> oops, wrong channel
<superm1> lfaraone, that's a different unrelated bug
<lfaraone> superm1: ah, kk.
<Ape3000> What does "dfsg" mean?
<ion_> Debian free software guidelines IIRC
<jpds> Ape3000: Debian Free Software Guidelines.
<jpds> Ape3000: See: http://www.debian.org/social_contract#guidelines
<lfaraone> Any main sponsors about?
<lfaraone> cody-somerville: done, package is in ppa at https://edge.launchpad.net/~lfaraone/+archive/ppa
<lfaraone> cody-somerville: and debdiff was uploaded to the bug
<cody-somerville> lfaraone, It looks like you simply add the flag to build libabiword but don't actually have it in its own binary package.
<lfaraone> cody-somerville: yes, from what I understood an additional binary package wasn't needed.
<lfaraone> cody-somerville: libabiword is _part_ of abiword, you can't mix versions and expect them to work. (and if they do, it's accidental)
<lfaraone> cody-somerville: if you'd prefer, I can split it off.
<cody-somerville> lfaraone, libabiword is not required for abiword to work if enabled, correct?
<cody-somerville> lfaraone, and your changelog says that you did create a new binary package btw
<Ramblurr> has anyone run into a bug where upgrading to the new nvidia 180 drivers removes the /usr/lib/libGL.so lib?
<lfaraone> cody-somerville: correct. will fix.
<tjaalton> Ramblurr: there's a bug about it
<Ramblurr> ah ok
<cjwatson> ArneGoetje: https://translations.launchpad.net/ubuntu
<calc> anyone happen to know the rsync command line to use to sync up an iso
<calc> its normally on iso.qa but nothing is being tested atm so doesn't show it
<calc> ah found it: https://help.ubuntu.com/community/RsyncCdImage
<calc> skipping non-regular file "ubuntu-8.10-desktop-i386.iso"
<calc> hmm weird
<cjwatson> it's a symlink - you need to sync the one from .pool
<cjwatson> rsync://releases.ubuntu.com/ubuntu-releases/.pool/ubuntu-8.10-desktop-i386.iso or some such
<calc> ah i see
<cjwatson> this is all transparent via HTTP; the rsync confusion is unfortunate but not really avoidable
<cjwatson> alternatively I think there's an rsync option to follow symlinks
<cjwatson> -L by the looks of things
<cjwatson> yeah, probably better to use -L
<cjwatson> (rather than .pool)
<calc> ok thanks for the help :)
<calc> apparently my dd of ubuntu iso from cd was a bit different from the one on the server
<cjwatson> mm, I certainly wouldn't put money on that giving bit-identical results
<calc> but not by much, heh
<cjwatson> probably just junk at start and/or end
<calc> yea
<doctormo> Question, according to the ubuntu-devel mailing list, I'm a "non-developer"
<doctormo> Despite being in all manners and motives a developer. Do I take it that there is some special flag you need to be a developer according to the mailing list?
<ScottK> You need to be a MOTU or core-dev
<ScottK> Developer means Ubuntu dev, not generic developer.
<ScottK> Some others get white listed in, but I'm not sure how that works.
<doctormo> ScottK: I see
<ScottK> There is ubuntu-devel-discuss that anyone can post to unmoderated.
<doctormo> Yes
<doctormo> Great, I'll have to join the boys club to post to certain mailing lists.
<ScottK> You can post.  It just has to go through moderation.
<doctormo> Perhaps the wording needs changing? 'non-developer' or even non ubuntu developer seems odd when your me, an ubuntu developer who just happens to operate on research instead of motu.
<cjwatson> I'm happy to add contributing developers to the whitelist if they post sensibly (and I remember when processing the moderation queue)
<cjwatson> (cf. https://wiki.ubuntu.com/UbuntuDevelopers)
<cjwatson> "Ubuntu Developer" is a formal term though, corresponding to Launchpad teams
<cjwatson> perhaps we should extend the auto-whitelist to cover ubuntu-universe-contributors
<cody-somerville> I'm in favour of that.
<cjwatson> err, universe-contributors I mean
 * Laney prepares the spam
<cjwatson> I've filed an RT request to that effect
<cjwatson> I've also linkified the text "Ubuntu developers" on https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
<doctormo> thanks cjwatson
<cjwatson> and clarified the text at the end
<ebroder> Is a FTBFS on hppa going to keep a backport from being accepted?
<Laney> What is Ubuntu's position on GFDL docs w/invariant sections?
#ubuntu-devel 2009-01-25
<lool> Wouah /var/lib/dpkg/info/hwtest-gtk.postrm
<lool> package=`dirname $0`
<lool> . $package/hwtest.postrm
<lool> hwtest-gtk needs hwtest, hwtest needs checkbox, hwtest-gtk depends checkbox-gtk, checkbox-gtk conflicts with hwtest-gtk hmmpf
<cjwatson> ebroder: no
<cjwatson> Laney: documentation is handled case-by-case: see http://www.ubuntu.com/community/ubuntustory/licensing
<cjwatson> Laney: there's a fair bit of precedent for permitting GFDL+invariants in main/universe, although I would still recommend trying to persuade upstream otherwise since there are GPL-compatibility implications; there is also precedent for just syncing stuff from Debian's non-free component and leaving it in multiverse because nobody cared enough
<cjwatson> lool: ugh, that's pretty dire
<Laney> cjwatson: I understand - so it's pretty much left up to developers' conscience
<cjwatson> lool: the checkbox-gtk conflicts on hwtest-gtk is versioned, though
<cjwatson> Laney: more or less, yes
<Laney> we've an irritating situation with ghc6 now where we merged a Debian revision that only corrected DFSG-freeness of GFDL docs
<Laney> and now have a load of uninstallable deps
<cjwatson> how did that produce uninstallability?
<Laney> some libraries have weird deps on ghc6 (< 6.8.2-999)
<Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=511756
<ubottu> Debian bug 511756 in ghc6 "ghc6: Includes GMP, which has non-free GNU documentation" [Serious,Closed]
<cjwatson> if you've already gone forward, there is no way to roll that version back such that the dependencies will be happy, regardless of our stance on the GFDL
<cjwatson> you'll have to adjust the packages with the dependencies
<Laney> yeah, I was just seeking clarification on if it was necessary in the first place
<Laney> I realise that we're committed now
<cjwatson> from the Debian bug, it looks as if fixes are available in unstable?
<Laney> yes
<cjwatson> not strictly, although we'd presumably have ended up with it at some point in a merge anyway
<Laney> just a bit of busy work
<cjwatson> it's not usually worth reverting a package split in Ubuntu
<billisnice> does anyone know how to install the codec on 9.04 like the ones at http://www.ubuntugeek.com/install-mplayer-and-multimedia-codecs-libdvdcss2w32codecsw64codecs-in-ubuntu-810-intrepid-ibex.html
<maxb> billisnice: #ubuntu-devel is emphatically not a support channel, and you asked and got an answer in #ubuntu+1. If you didn't like the answer, then follow up there.
<billisnice> ok
<billisnice> did not know
<billisnice> thanks
<maxb> Channels have topics for a reason
 * cjwatson saves lots of time clicking on LP bug tasks to set them all to fix-released, on a bug with 14 tasks
<cjwatson> >>> bug = launchpad.load('https://api.edge.launchpad.net/beta/bugs/309435')
<ubottu> Launchpad bug 309435 in libjboss-xml-binding-java "Please move jboss related packages to universe" [Undecided,Fix released]
<cjwatson> >>> for x in bug.bug_tasks:
<cjwatson> ...     if x.status != 'Fix Released':
<cjwatson> ...             x.transitionToStatus(status='Fix Released')
<cjwatson> ...
<LaserJock> cjwatson: nifty
<CyL> Would someone please recommend a good IDE for ubuntu (C ansi)?
<LaserJock> anjunta or eclipse
<LaserJock> and asking #ubuntu would probably be better
<CyL> LaserJock: thanks and sorry
<LaserJock> np
<DGMurdockIII> (doctormo): hi
<DGMurdockIII> (doctormo): you still here
<DGMurdockIII> (doctormo): if you go there http://www.nvidia.com/object/product_geforce_9400m_g_us.html click buy now you will see who is using them
<doctormo> that was odd, I don't think he meant me
<calc> ugh i think i'm getting beaten on by the iowait issue in the kernel again :\ i wish that bug would get fixed already
<calc> nothing much is using cpu except in iowait but i can barely use vmware
<Hydrant> Hi all, how can I tell what compiler was used to compile an Ubuntu package?
<Hydrant> I need to use the exact same compiler, and perhaps flags for something
<stdin> look at the build log for the package
<stdin> https://launchpad.net/ubuntu/<release>/+source/<source package>/+builds
<stdin> but it'll usually be the same version that apt-get install gcc gets for you
<Hydrant> mabye it's a library linking error or something, I'll check that log thanks
<cody-somerville> Hydrant, if you gave more context to your problem, someone might be able to help you.
<Hydrant> I can't get exception handling to work properly in an OpenOffice add-in I'm writing, and this may be due to me using a different compiler
<Hydrant> I'm trying some workarounds now
<calc> Hydrant: you may want to test against the official openoffice.org as well, its always possible you are seeing a bug in Ubuntu's version :-\
 * calc <- maintains OOo for Ubuntu
<Hydrant> it's a pain... I've tested that I can just throw an exception, and it will never get caught, OOo will just die instead
<Hydrant> http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=14568
<Hydrant> it seems there was a fix for this a while ago, I'll try official ooo
<Hydrant> calc: where do I get the official binary?
<Hydrant> you mean the debs from oo's site?
<Hydrant> nm, that was just for OO3
<calc> Hydrant: http://openoffice.org/ :)
<calc> Hydrant: yea they have debs there i think
<calc> Hydrant: linux dists patch OOo heavily and sometimes break things
<Hydrant> why does every distro patch everything so much anyways
<Hydrant> never understood that
<Hydrant> other than everyone having their own paths
<calc> Hydrant: linux dists use go-oo.org due to issues surrounding OOo, pretty much all linux dists have the same patches its just all different from upstream OOo
<calc> there are something like 600 patches to upstream OOo
<LaserJock> hmm, cheese finally works, but now everything has a green tint
<LaserJock> green cheese, ewww :(
<calc> lol
 * kees needs a way better webcam
 * calc wonders why cheese isn't in standard Ubuntu desktop
<LaserJock> hmm, so gstreamer-properties gives me the same green tint when it didn't before
<calc> seems like something that would be good to have since most laptops have webcams now
<LaserJock> so maybe it's not cheese's fault
<calc> LaserJock: did you paint your lens green?
<LaserJock> .... I don't think so :-)
<calc> heh
<LaserJock> I can actually see when it first starts up its got the right color
<LaserJock> just for a split second
<LaserJock> then it "adjusts" to the green
<ScottK> Isn't Gnome's color green?
<ScottK> Maybe it's a feature.
<LaserJock> perhaps
<LaserJock> but it worked just fine in gutsy and hardy
<seektherapy> I have a problem and no one in the Ubuntu support channel can help me .. Figured since you guys say you developed this OS you could help me
<Chipzz> no
<Chipzz> no-one in ubuntu knowing is still not a valid reason for asking here
<seektherapy> Jesus christ people !! did y'all create the OS or not
<seektherapy> and its not just me either
<seektherapy> personally i think its a developer problem
<Chipzz> seektherapy: channel rules. plain and simple
<Chipzz> there are other ways of getting support. the forums, and filing a launchpad support ticket for example
<seektherapy> Chipzz: i am actually very new at the OS .. One reason why woman do not find it user friendly
<seektherapy> I am lucky to have found this channel
<Chipzz> we, otoh, are not so lucky :P
<Chipzz> seektherapy: look, plain and simple, like I said: the rules are there for everyone, that includes you
<seektherapy> huh ? you made a statement and i responded
<Chipzz> if everyone started thinking like you, the devs would be spending all their time giving user support instead of actually developping
<stdin> !support
<ubottu> The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<seektherapy> I am in the channel
<seektherapy> I was told sound is hard to troubleshoot ..maybe because its underdeveloped ??
<stdin> no really
<stdin> *not
<stdin> it's just difficult to troubleshoot
<Chipzz> it's a sunday. most of the devs are not here anyway
<Chipzz> !weekend
<ubottu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<seektherapy> whats  better channel to ask other than the ubuntu
<Chipzz> seektherapy: anyway, like I just told you: if no-one in ubuntu know, you can ask in the forums, are file a launchpad support ticket
<Chipzz> s/ubuntu know/#ubuntu knows
<Chipzz> s/are file/or file/
<seektherapy> wonders how long dell will promote Ubuntu with this kind of bad attitude
<seektherapy> waste of time...bye
<stdin> there are other avenues of support you can take, it's your choice to take them or not. please do not insult us for nothing
<seektherapy> and i am trying to bring up a good point and its falling on deaf ears..Just google Ubuntu and soud card probles.. its a huge problem and not by the users
<stdin> google any distro and "sound card problems" and you'll see the same, it's more global than Ubuntu
<seektherapy> i mean only one user
<seektherapy> stdin: you may want to book mark this page
<seektherapy> http://connect.creativelabs.com/linux/default.aspx
<stdin> why?
<seektherapy> its a popular sound card that has a linux driver
<stdin> ok, and?
<seektherapy> you would know how to configure and install but i probably wont be able too.. maybe i am wrong but i thought developers strived to make an OS user friendly?
<stdin> I'm still wondering what this has to do with me? drivers are to do with the kernel
<seektherapy> oh...so is there a Ubuntu kernel channel
<Chipzz> work is continuously being done to make the OS more user-friendly. and the less time the devs have to spend giving support, the more time they have to actually DO that
<seektherapy> and they do have a kernal channel.. i bet i see one of you guys in there
<stdin> the kernel channel is no more a support channel than this
<stdin> and finding beta drivers for one card is nothing to do with making the OS user friendly
<Chipzz> seektherapy: I'm starting to loose my patience, really
<Chipzz> seektherapy: we already told you what the correct support avenues are. why don't you just follow these and stop wasting all of our time?
<Chipzz> 08:35 < Chipzz> there are other ways of getting support. the forums, and filing a launchpad support ticket for example
<Chipzz> 08:46 < Chipzz> seektherapy: anyway, like I just told you: if no-one in ubuntu know, you can ask in the forums, are file a launchpad support ticket
<seektherapy> then dont read what i write... i have never addressed you.. Plus i am probably old enough to be your mother
<Chipzz> and you still lack basic reading comprehension skills :)
<Chipzz> rofl :)
<seektherapy> thats it
<seektherapy> does your mother know Ubuntu?
<seektherapy> rofl...doubt it
<stdin> Chipzz: please don't antagonise people, it's against the CoC
<Chipzz> I don't see what my mother has to do with all this :)
<Chipzz> stdin: luckily I never signed it, then :)
<seektherapy> i didnt he did
<stdin> Chipzz: it's a rule of the #ubuntu channels that the CoC be followed, and against the IRC guidelines as set out by the IRC CC anyway
<seektherapy> some of you boys need to understand.. this doesnt come easy to older people.. ay least i am trying to learn..you know?
<Chipzz> seektherapy: yes, and you can learn on the forums
<Chipzz> 4th time
<seektherapy> Chipzz"s: mom is probbably a very nice women and would be ashamed to see him acting like this
<stdin> seektherapy: #ubuntu is the place to ask on IRC
<stdin> please keep personal attacks out of this channel
<seektherapy> yah, i am wasting my time in herr
<seektherapy> that wasnt personal
<stdin> whatever you consider it
<seektherapy> it ws a general comment
<stdin> even if you don't consider it a personal attack, it's completely off topic for this channel
<seektherapy> he started it
<seektherapy> ok..ok.. now you are making me feel like a child
<stdin> that is never an excuse
<seektherapy> i do need to go
<seektherapy> thanks for all the support, encouragment and help.. i am forever greatful
<seektherapy> goodbye ...bitter developers
<stdin> if you have no further business in this channel, please part
<seektherapy> learn to read std
<stdin> heh
 * Chipzz wonders why some ppl feel better than others, because the channel rules appear to not apply to them
<Chipzz> I wonder why this channel is not set +s anyway, to prevent users from "finding" it
<stdin> because we like to be transparent
<Chipzz> anyone who has any business here will/should be smart enough to find it regardless
<pwnguin> if you set it to +s you get a secret code of silence
<Chipzz> stdin: +s doesn't technically prevent anyone from joining, it only prevents the channel fmor appearing in the output of /list
<Chipzz> which IMO would be a very good thing
<stdin> all someone would have to do is ask "where is the development channel" in #ubuntu and +s is pointless
<Chipzz> "Hrrrm I didn't get any support in #ubuntu ... Let's see what other channels there are. Oh there's #ubuntu-dev, the ppl there will likely help me!"
<stdin> besides, most people who join here are not insane :)
<StevenK> No, but it helps ...
<stdin> people who join are mostly sane. people who idle here are mostly not
<Chipzz> stdin: ppl in #ubuntu in 99.99% of the cases have no reason to refer anyone here
<Chipzz> stdin: did you just call me insane? :) and isn't that a violation of the CoC? ;)
<stdin> no, it's not an attack, as I love the insane :)
<Chipzz> then again, I didn't call it an attack, I called it an insult :)
<stdin> potAYto/potAHto
<stdin> proof I'm insane, I choose text to convey a spoken difference in words
<calc> lovely i'm getting ICE in gcc now
 * calc isn't sure whether he hopes it is his pc having problems or the compiler
<Chipzz> calc: your pc would be the obvious choice as that would limit the problem to 1 pc ;)
<calc> ICE on compiling OOo on amd64 jaunty :-\
<calc> Chipzz: yea, but that would still suck for me, heh
<calc> i'll have to build a chroot on my laptop to test it out later i'm going to bed now
<Chipzz> that it would
<Chipzz> gn!
<calc> doko_: ping
 * Hobbsee sighs, and speaks to seektherapy
<directhex> something amiss, sarah?
 * calc heads back to bed
 * calc hopes the new g++ building now fixes the weird ice he got on OOO
<rzr> cjwatson: hi , about moving tuxguitar to universe, is this because it's free now ? can I help since i am the maintainer
<pitti> directhex: poke back
<rzr> cjwatson: well i am not motu i guess no
<rzr> whois nijaba
<Chipzz> !weekend | rzr
<ubottu> rzr: 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.
<Chipzz> !motu | rzr
<ubottu> rzr: motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<Chipzz> rzr: #ubuntu-motu is probably what you want
<Chipzz> rzr: #ubuntu-dev normally is only about packages that are in main
<rzr> Chipzz: ubottu : happy new chinnease year , dont trust other 2009 is the year of pinguin !
<Chipzz> rzr: ubottu is a bot and hence won't care much for your wishes ;)
<Chipzz> and: thank you :)
<rzr> BTW i came here just after i got a LP mail alert about tuxguitar
<rzr> well i'll stay here roaming
<rzr> cjwatson: actually u released it :) thx
<Hydrant> calc: hey
<LordMetroid> If I want to write an software installer, can one access the repositories and fetch whatever requirements necessary that isn't already fulfilled instead of just telling the user "requires glib >= version x"?
<cjwatson> rzr: yeah, I don't think any help is needed for that bug, I was just acting on a request to move the package to a different component since as you say it only uses free Java now
<cjwatson> rzr: BTW, I know nothing about tuxguitar; I was just the ftpmaster on duty and there's probably not much point talking to me about the details of the package :-)
<cjwatson> LordMetroid: that's what apt does
<cjwatson> (unless your system is in a broken state of some kind)
<LordMetroid> I know apt does that... Can I use apt as a part of my own installer though?
<cjwatson> apt is a library as well as a program, and has things like Python bindings (the python-apt package), so in principle yes, though of course it depends on the details
<directhex> isn't packagekit meant to abstract it so you can use the same code on fedora, suse, etc?
<LordMetroid> Hmm, that sounds mighty intersting...
<directhex> i think that's how gstreamer (or perhaps totem) handles codec installation. and possibly abiword for fonts, judging by these screenshots
<cjwatson> planned to but doesn't yet
<cjwatson> but yes, it probably should. The main outstanding problem with packagekit is that it can't cope with debconf at all - we need to marshal the debconf protocol over dbus or something
<LordMetroid> Promising, I am hoping to create a software installer program that can be used to allow people to write commercial software and have the average Joe user be able to install it on his system without trouble, I think that is mainly what is holding adaption for the Linux desktop back
<LordMetroid> My own goals are in indie games though'
<directhex> doesn't icculus' replacement for loki installer do that?
<LordMetroid> icculus?
<LordMetroid> Google isn't very helpful on icculus
<LordMetroid> ahh, the software developer
<cjwatson> LordMetroid: you mean like gdebi?
<directhex> mojosetup
<cjwatson> the problem is not that there is no way to install commercial software without trouble
<cjwatson> the problem is that there are *too many* different ways
<directhex> cjwatson, he's writing a distro-agnostic .bin installer, and asking about package manager integration to install the app's deps during install
<cjwatson> sure, and tools exist for that as well
<cjwatson> but not every software vendor delivers their package in any one single format
<LordMetroid> any one single format?
<cjwatson> realistically, the choices are (a) deliver packages in a few choices of distro-specific packaging (b) deliver LSB packages (I think we can install those without too much pain, but it might be worth looking at streamlining that process)
<cjwatson> ".bin" is meaningless as a format. It's usually a self-extracting executable of some kind that rarely has any parseable dependency information
<LordMetroid> I was thinking, compiling everything on system and fetching all that is necessary
<cjwatson> I would recommend producing LSB packages instead
<directhex> LordMetroid, xfce installer
<cjwatson> at least that way you aren't sailing against the wind
<cjwatson> at all costs, do not invent your own format
<directhex> LordMetroid, the xfce4 installer downloads & compiles things, if you want that route
<LordMetroid> ok
<cjwatson> look up the LSB Package API
<cjwatson> though also bear in mind opinions of qualified people who've looked at it :-) http://blogs.gnome.org/hughsie/2008/06/24/lsb-package-api/
<LordMetroid> I will keep that in mind...
 * cjwatson tries to find an actual real-world LSB package to test-install
<LordMetroid> I am mainly concerned about how to create an installer that will install my software without hurdles for the user to jump over
<cjwatson> the worst thing anyone can do at this point is to develop yet another installer that tries to be generic but in reality only really supports their corner of the world
<directhex> LordMetroid, can't beat real distro packages, really
<cjwatson> since there are two possible existing approaches you can use (distribute distro packages, or distribute LSB packages), it seems foolish to invent another one
<directhex> LordMetroid, some ISVs opt to include the kitchen sink in their packages & install somewhere "safe", as a way to avoid the dep question
<LordMetroid> ok
<directhex> not that that's ideal either
<directhex> i like the approach where an isv has some distro repos, e.g. opera. then again, that leads to the "how to add a repo" question which only suse handles gracefully
<LordMetroid> The problem I bumped into was that I am using bluecove for the Java Bluetooth API, which required a fresh compile in order to work properly on my system(same problem which occured on a friend of mine's system)
<rzr> cjwatson: ok acknowledge
<gordonjcp> hi
<gordonjcp> is there a good way of detecting if a package is being compiled under Ubuntu?
<gordonjcp> some sort of autotools thing, but what should I be testing for?
<directhex> gordonjcp, lsb tools
<cjwatson> test "$(lsb_release -is 2>/dev/null)" = Ubuntu
<directhex> gordonjcp, lsb_rewhat cjwatson said
<gordonjcp> directhex: basically I need to detect if someone is trying to compile on Ubuntu, and apply a bunch of workarounds
<gordonjcp> and maybe also warn them not to attempt it on Ubuntu ;-)
<directhex> gordonjcp, i use lsb_release to detect whether a package is being compiled on debian or ubuntu to pick between installation folders based on local distro things
<gordonjcp> okay
 * directhex wonders how much longer he's gonna be waiting for debian NEW
<gordonjcp> ideally I'd like it if Ubuntu supported USB MIDI properly in the -rt kernel, but since no-one seems keen to make it happen I need to warn users about possible brokenness
<Adri2000> kees: I updated my MoM branch with better escaping and file locking - if you could take a look... :)
<Keybuk> I swear, I spend more time chasing valgrind bugs/issues than real ones
<mib_pt8tdy91> hi
<kees> Adri2000: sure, yeah.  I've added it to my todo list
<calc> Hydrant: eh?
<slytherin> Hi, is anyone looking into FTBFS of xorg-xserver on non i386/amd64 arch?
<cody-somerville> Is there a definition/criteria of what a release critical bug is anywhere?
<pochu> cody-somerville: for Debian?
<cody-somerville> sure, I'm just looking for examples
<pochu> cody-somerville: severity >= serious (so serious, grave and critical)
<cody-somerville> pochu, I'm more looking for the criteria a bug has to meet to be given that severity
<pochu> ah
<Keybuk> we don't have any formal criterion
<cjwatson> cody-somerville: http://release.debian.org/lenny/rc_policy.txt
<Keybuk> other than "someone says so, and slangasek doesn't disagree"
<pochu> cody-somerville: http://www.debian.org/Bugs/Developer also explains the severities
<cody-somerville> thanks :)
<cody-somerville> much appreciated pochu, cjwatson, and Keybuk
<Keybuk> informally, things are release critical if they're broken and something we consider essential
<Keybuk> if OpenOffice didn't work, that would be RC
<calc> heh
<slytherin> need a bit help please. I am using jaunty latest and permissions are broken for /dev/null, /dev/urandom, /dev/tty*
<directhex> sounds like udev being started twice
<directhex> at a guess
<directhex> look in /etc/rc.d/ for stray udevs
<slytherin> directhex: let me take a look
<slytherin> directhex: doesn't look to be the case
<directhex> hm, okay, that's what caused it for me last time
<cjwatson> slytherin: invocations of 'udevadm trigger' are known to cause this; see Scott's recent post to ubuntu-devel
<cjwatson> slytherin: you'll probably need to reboot to sort it out all the way, I suspect
<cjwatson> slytherin: but it would be worth trying to figure out what caused the trigger
<cjwatson> (dkms is one culprit that's already been identified and (mostly) fixed)
<slytherin> cjwatson: reboot doesn't help. In fact the current kernel (2.6.27) is not booting at all. I am booting 2.6.25
<cjwatson> wow, no idea, you need Keybuk
<directhex> and a beer, i suspect
<slytherin> So I guess this is the root cause of all other problems.
<Turl> hello
<Turl> any idea how can I create a ppa for my team?
<pochu> Turl: you want #launchpad
<cjwatson> launchpad.net/~team-name/+activate-ppa
<cjwatson> it's shown in the UI
<Turl> pochu: they don't speak at #launchpad :p
<Turl> cjwatson: thanks :)
<slytherin> cjwatson: any idea where should i look for problem?
<slytherin> or how can I remove the triggers that are causing the permission problems?
<slytherin> and lastly how can I fix the boot of linux-image 2.6.27?
<directhex> grep -r udevadm /etc!
<kees> win 32
<kees> erk
<slytherin> directhex: something called mouseemu in /etc/rc* has udevadm.
<directhex> o_o
<calc> does evolution do regex match?
<calc> er for filtering?
<calc> i have some launchpad rationale's that are like Subscriber (foo) @bar
<calc> and then some that just have Subscriber @bar
<calc> so i need it to ignore the (foo) part and just match all of them
<calc> would that be Subscriber.*@bar ?
<mabafu> hi there
<mabafu> anybody listening?
<mabafu> I would like some hints on ubuntu development...
<cjwatson> slytherin's gone, but mouseemu only does udevadm settle, which is OK
<cjwatson> mabafu: http://wiki.ubuntu.com/ContributeToUbuntu and http://wiki.ubuntu.com/UbuntuDevelopment should help you
<mabafu> tks cjwatson
<rexbron> Hi, would I be able to get a core-dev to take a peak at bug 311804?
<ubottu> Launchpad bug 311804 in libraw1394 "Update libraw1394 to version 2.0" [Undecided,New] https://launchpad.net/bugs/311804
<tilgovi> anyone have any tips for how to use git with ubuntu packages for kernel
<tilgovi> I feel like I can never cleanly merge because make-kpkg dumps that debian directory in my source tree
<zul> tilgovi: check the wiki there is loads of information there
<tilgovi> am I missing something?
<tilgovi> zul, I'll do more reading, but I thought maybe someone would have a quick, stupid answer for that
<rexbron> tilgovi: https://wiki.ubuntu.com/KernelTeam should have the required info
<zul> tilgovi: the kernel package doesnt use make-kpkg afaik
<dtchen> you'd want to read debian/rules more carefully
<tilgovi> dtchen: thanks
<tilgovi> rexbron, that's very helpful, thanks. I'm understanding better now.
<bmhm> Hi, I need a quick hint with pbuilder: http://paste.ubuntuusers.de/393885/
<cjwatson> bmhm: I'm not sure what we're meant to be looking for - there's no error in that paste as far as I can see
<bmhm> oh wait a sec
<bmhm> old log
<bmhm> http://paste.ubuntuusers.de/393888/
<bmhm> line 1068
<calc> how do you write a regex to not match if a character exists?
<bmhm> grep -v ^^
<bmhm> well its [^a] for not matching a
<calc> ok
<bmhm> ^a would be lines beginning with a, common pitfall
<calc> basically i want a regex that matches for "Assignee blah" except when there is a @ eg "Assignee @ubuntu-laptop"
<bmhm> ah i see
<calc> so far I have Assignee.* matching for everything but adding [^@] doesn't remove the @ matches
<bmhm> well "Assignee[^\@].*" should work
<bmhm> escape it (\@)
<calc> grep -E "Assignee[(^@)].*" then doesn't match even when @ doesn't exist in the line
<bmhm> well its not what I said
<bmhm> if you use grep try
<bmhm> grep -v "Assignee@"
<bmhm> or
<bmhm> grep -e "^Assignee[^\@].*"
<cjwatson> you don't need to escape @
<bmhm> the round brackets are wrong btw
<cjwatson> calc: is this procmail?
<calc> cjwatson: evolution regex
<calc> cjwatson: but can't get it to work even with simple grep
<cjwatson> do you know if it supports extended regular expressions or not?
<calc> cjwatson: it seems to afaict
<cjwatson> I think ^Assignee[^@]+$ is what you want then
<calc> ok
<cjwatson> or else "Assignee [^@].*"
<calc> ah that works in grep too :)
<calc> thanks
<cjwatson> the space there is likely to be important ...
<cjwatson> the first ensures that there's no @ anywhere in the line; the second is "Assignee, then space, then any character except @, then any number of characters"
<cjwatson> the final .* probably being unnecessary since evolution probably doesn't forcibly anchor the regex to start and end of line
<calc> ok
<cjwatson> bmhm: looks like the source package doesn't contain po/Makefile.in.in?
<bmhm> well yes it does, but it's a symlink
<bmhm> anyway, I will try 7.2 instead of the svn
<cjwatson> to what?
<cjwatson> is it an absolute symlink to /usr/...?
<bmhm> to uhm... /usr/...sth about translation/
<bmhm> transutil or sth?
<cjwatson> then you need to pass --copy to one of the relevant autotools
<bmhm> ah
<cjwatson> though I didn't think gettext did that nowadays
<bmhm> "though I didn't think" ? =)
<cjwatson> I think it does it if you explicitly (and unwisely) use the --symlink option
<cjwatson> where "you" is perhaps upstream
<cjwatson> if it's that way in the upstream package, send them a cluebat :)
<bmhm> well I was trying to pass this package to the motu-team
<bmhm> or lets say https://edge.launchpad.net/globalmenu
<bmhm> I know how to build rpms (we got SLES at work), but I'm new to debs, allthough I use ubuntu for about three years now ^^
<cjwatson> this is not really specific to building debs at all
<cjwatson> the problem is that the source package you've built (and presumably also the tarball you have) contains a symlink to something not guaranteed to be on the system
<bmhm> I see, but copying the file didn't help either
<bmhm> well anyway, last try build for today, got to get to bed soon
<bmhm> so i am quite sure it's not a problem with the symlink
<bmhm> oh well
<bmhm> when using pbuilder it says configure: error: The intltool scripts were not found. Please install intltool
<ScottK> Then you're missing a build-dep.
<bmhm> do i need to recreate source pakage?
<bmhm> i just added intltool to debian/control but it didn't help
<ScottK> Then you need to rebuild the source package, yes.
<bmhm> ok thx a lot
<ScottK> debuild -S
<bmhm> debuild? I was using pbuilder
<bmhm> > sudo pbuilder create *.dsc
<jpds> I think he might use debuild to create the source package.
<jpds> meant*
<bmhm> yeah
#ubuntu-devel 2010-01-25
<quadrispro> pitti, bug 512048 -> fixed in debian, thank you!
<ubottu> Launchpad bug 512048 in simple-scan "avoid excessive dependencies" [Low,Triaged] https://launchpad.net/bugs/512048
<owen1> how to find a maintainer of a specific driver?
<crimsun> owen1: which touchpad driver? also, X Window System driver or kernel driver?
<owen1> driver for touchpad. it's elantech.
<owen1> crimsun: dell inpiron 11z and dell mini 10 both comes with this touchpad.
<owen1> crimsun: and i can't configure it at all. i am about to give up and return my laptop to dell.
<owen1> crimsun: http://ubuntuforums.org/showthread.php?t=1347942&page=2
<crimsun> xserver-xorg-input-synaptics and linux certainly are new enough
<crimsun> do you have a pointer to a specific bug report on Launchpad?
<owen1> crimsun: no. i did'n know it's a bug.
<owen1> crimsun: i'll go there and look for bug reports. maybe someone mentioned it.
<owen1> crimsun: can u take a look at this link- http://arjan.opmeer.net/elantech/
<owen1> is it helpul in any way?
<crimsun> I already looked, which is why I mentioned the above source packages.
<owen1> crimsun: i am sorry but i am a bit confused. did u find a bug report about the issue?
<owen1> crimsun: if not, i'll be happy to add a bug.
<crimsun> owen1: I did not look; I'm busy ATM.
<owen1> crimsun: np. i'll go to launchpad
<owen1> here is a similar bug - https://bugs.launchpad.net/ubuntu/+source/gsynaptics/+bug/132627
<ubottu> Ubuntu bug 132627 in gsynaptics "GSynaptics couldn't initialize." [Undecided,Fix released]
<owen1> how was it fixed?
<owen1> the original bug is for 7.04 and i have 9.10.
<owen1> i think it's related to elantech touchpads.
<owen1> they are not recognized for some laptops (inspiron 11z and mini 10)
<owen1> can anyone help me with submitting bug to launchpad?
<owen1> i am not sure if i should create new bug
<persia> owen1: If it's not the same hardware, you'll want a new bug.
<persia> You might try running `ubuntu-bug xserver-xorg-input-synaptics`
<persia> Most bug discussion happens in #ubuntu-bugs, but that's more about bug triage than about actually solving them.
<kees> pitti: say, can we just disable palimpsest?  it seems to be warning way too much (bug 438136)
<persia> You might also find useful support in #ubuntu
<ubottu> Launchpad bug 438136 in libatasmart "palimpsest bad sectors false positive" [Unknown,Confirmed] https://launchpad.net/bugs/438136
<kees> i'd kind of like to SRU it off too
<persia> kees: I was going through FTBFS this weekend, and got stuck with libpam-alreadyloggedin : it appears to get confused by some of the stack-smashing-protection, but only for i386 and powerpc.  Am I on the right track, or confused by some byproduct?
<kees> persia: hrm, confused how?
 * kees reads the buildlog...
<persia> https://launchpad.net/ubuntu/+source/libpam-alreadyloggedin/0.3-1/+build/1428110/+files/buildlog_ubuntu-lucid-i386.libpam-alreadyloggedin_0.3-1_FAILEDTOBUILD.txt.gz
<persia> I had similar sorts of issues for libpam-slurm, and ended up fixing those by adding lots more -nostdlib calls to the Makefile, but that felt like a big hammer.
<kees> yeah, -nostdlib is the right fix, but it's weird that amd64 didn't blow up in the same way
<kees> err ..  -lc
<persia> That was why I asked.  I had thought SSP would be on amd64, but nothing seems to fail there.
<kees> that would imply libc ??
<kees> persia: OH!
<kees> ld instead of gcc
<kees> wrong: ld -lpam --shared -lc pam_alreadyloggedin.o -o pam_alreadyloggedin.so
<kees> right: gcc -lpam --shared -lc pam_alreadyloggedin.o -o pam_alreadyloggedin.so
<persia> OK.  Would you be up for explaining why?
<persia> Also, if you had any ideas why it worked on amd64, I'd be interested.
<jono> any build admins able to bump a package up the queue
<jono> I need Lernid to be built in my PPA ready for developer week starting
<kees> persia: because the compiler has the logic for knowing how to call the linker correctly. i think -shared turns off somethig there
<kees> not sure why it worked on amd64, maybe the linker handles things differently there
<persia> OK.  Thanks for the hint.  I'll go look at --shared in hopes of understanding at least a little bit before uploading :)
<kees> i think this is a flaw in my modifications of the spec files, ld must be missing something.
<persia> You might also want to look at libpam-slurm if you're looking at stuff, as it shows the same broken on i386/works on amd64 behaviour if you remove my latest patch.
<persia> And it uses gcc for all the calls when doing so.
<nixternal> kees: dude, I am scared now...I live in a gated community, and the closest streetview is over 2 miles away...the community voted to not allow google in our subdivision, yet the mac address at my house is dead on, and the mac address here at my girlfriends is dead on...this is way to freaky
 * persia pipes whois output to the OMCD
<nixternal> yeah, that definitely belongs on charles darwin, now that I figured it out after the fact
<persia> Not really.  It's probably your ISP providing data.
<persia> Get a more private ISP, or set up fancy tunnels.
<nixternal> att uverse at both locations
<persia> Right.  Tunnel it is then.
<persia> Get a vhost somewhere and set up a VPN.
<nixternal> my cell phone on the other hand, isn't even close
<johanbr> that's probably the location of your carrier's internet gateway
<nixternal> if that were the case, then the gateway is in both my house and my girlfriends house :)
<nixternal> it seems that att, like persia said, is giving out way to much info
<persia> Well, depends on the user.  Some users prefer convenience to privacy.
<jono> any build admins around?
<StevenK> jono: To retry, or bump the score?
<ScottK> nixternal: I was driving to pick up one of my kids from a friends house last night and using the Google navigation feature on my 'droid.  When I got to the destination it popped up a picture of the house so I could know which one it was.  It was totally cool.
<jono> StevenK, it is down to build in two days
<jono> and I really need a Lernid and Karmic build ready for Ubuntu Developer Week which starts on Monday
<nixternal> this is really weird, persia even if I do use a tunnel, it knows where that MAC address is located
<jono> can you help bump it up, StevenK?
<persia> nixternal: Then you don't have enough hardware between your device and your tunnel.
 * persia takes this somewhere slightly less off-topic
<StevenK> jono: "It"? And I can't, but I can help get it done
<jono> StevenK, Lernid
 * Hobbsee looks in
<Hobbsee> jono: in a ppa, or main archive, or?
<jono> Hobbsee, hi! thanks :-)
<jono> it is in my PPA
<jono> Lernid 0.5
<jono> I kicked off a Lernid built and then I planned a copy for a Karmic build
 * Hobbsee looks it up
<StevenK> https://edge.launchpad.net/~jonobacon/+archive/ppa/+build/1465979
<StevenK> Hobbsee: ^
<jono> https://edge.launchpad.net/~jonobacon/+archive/ppa/+build/1465979
<jono> aha :)
<Hobbsee> jono: prodded
<jono> Hobbsee, what do you mean?
<jono> oh wow!
<Hobbsee> jono: it means i took it on a walk
<jono> you are a rockstar :)
<Hobbsee> jono: for reference, it's great if you can provide that link earlier, so buildd admins don't have to scramble looking for which you might mean, particularly if it's for a ppa ;)
<Hobbsee> haha, np
<jono> Hobbsee, will do :)
<jono> thanks!
 * Hobbsee starts to think it'd be nice for buildd to be modified to work for ppas too
<Hobbsee> jono: how clever
<jono> Hobbsee, :)
<StevenK> And lernid is built
<owen1> persia: thanks
<Hobbsee> nice, i like how it's clear on what stage it's up to now, and why it isn't there in the archive yet
<persia> owen1: That worked for you then?  Excellent.
<jono> Hobbsee, mind doing the same for https://edge.launchpad.net/~lernid-devs/+archive/lernid-releases/+build/1466114 ?
<owen1> persia: i just read your reply, didn't run that command yet
<Hobbsee> jono: prodded with the Long Pointy Stick of Doom!!!! â¢
<jono> Hobbsee, that stick is awesome!
<Hobbsee> jono: very!  it's had a long vacation
<jono> Hobbsee, good to be back :-)
<Hobbsee> so is nicely sharp and pointy, ready for it's next adventures
<Hobbsee> yup!
 * jono hugs Hobbsee :)
<Hobbsee> :D
<jono> Hobbsee, you must be so pleased :)
<StevenK> Hobbsee: That's what happens when you store the Long Pointy Stick in a pencil sharpener when you're not using it
<Hobbsee> StevenK: if i'd done that, i don't think it'd exist anymore
<Hobbsee> it'd be all sharpened out
<persia> At least it wouldn't be so long.
<StevenK> Damn, my plan has been foiled.
<jono> Hobbsee, is there likely to be a delay in publishing the packages?
<jono> as in, a 2 day delay
<jono> :)
<StevenK> jono: Nope.
<Hobbsee> jono: nah.  publishing happens every 20 minutes, last i knew
<jono> sweet :)
<Hobbsee> wow, +builds has had a lot of improvements.  Think i'll have to close some of my bugs against it
<jono> all set for Ubuntu Developer week :)
<jono> Lernid is rocking :)
<wgrant> Hobbsee: */5, now! You are behind the times.
<Hobbsee> wgrant: oh nice.  very behind the times
<Hobbsee> wgrant: seeing as you are not, do you know how i get https://bugs.edge.launchpad.net/~hobbsee to work?
<wgrant> Hobbsee: Use production.
<wgrant> There is a bug.
<Hobbsee> oh yeah
<Hobbsee> rightio
<wgrant> I believe the bugfix is yet to land, although it has been written.
 * StevenK attempts to get undistracted
<Hobbsee> fair enough
 * ScottK cheers the reappearence of the stick.
<ScottK> StevenK: Thanks for luatex.
<owen1> persia: ok, i submitted new bug. thanks
<owen1> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/512192
<ubottu> Ubuntu bug 512192 in xserver-xorg-input-synaptics "configuring Elan tech touchpad on Delll Inspiron 11z" [Undecided,New]
<Hobbsee> heya ScottK!
<ScottK> Heya Hobbsee.
<persia> owen1: Good luck.
<jono> what is the best way for me to re-build Lernid 0.5 but for Lucid?
<jono> in https://edge.launchpad.net/~lernid-devs/+archive/lernid-releases
<RAOF> jono: Looks like you should be able to safely binary-only copy that to lucid.
<dholbach> good morning
<jono> RAOF, you think?
<RAOF> jono: You could copy the source & have to poke to have it rebuilt again, but it's pure-python, right?
<jono> RAOF, it is
<jono> it just has a stack of dependenices
<jono> dependencies
<RAOF> It looks like they're all satisfied on Lucid, as well.
<RAOF> And you'll have manually specified those dependencies, because we aren't awesome enough to extract python dependancies from python source.
<StevenK> RAOF: "Yet"
<RAOF> StevenK: Indeed.
<RAOF> It's not as easy as extracting shlib depends, but it's not impossible.
<persia> RAOF: Doesn't ${python:Depends} try to do something like that?
<ScottK> persia: Mostly it helps pick the right version of the python interpreter to depend on.
<ScottK> Someday ....
<persia> Ah.  I thought it somehow dig into setup.py and did the right thing
<persia> s/dig/dig/
<persia> dug!
<ScottK> dog?
<RAOF> dag
<persia> No, really, dug.  Not quite the same vowel transition as sit/sut, but the same idea.
 * persia wishes for a sanely conjugated language as the de facto international default
<RAOF> All languages have their little excentricities :)
<RAOF> Sometimes native-speakers are even able to spell each word in a sentence correctly, too.
<StevenK> If we're lucky
<persia> Somehow I suspect some difficulties combining that with grammatical sanctity.
<pitti> Good morning
<ScottK> Good morning.
<ScottK> pitti and lool: Thanks for the quick MIR review on luatex over the weekend.
<pitti> kees: "disable palimpsest"?
<pitti> kees: oh, the bad block warning; we should perhaps disable that if it's not fixed in time, indeed
<siretart`> could someone please sync epiphany-extensions from debian/unstable? It doesn't look like it will find its way to testing soon, but epiphany 2.29 is already in lucid. I'll file a sync request laterâ¦
<pitti> siretart`: synced
<xnox> Good morning everyone! =) I have exam today, wish me luck =) Testing alternative daily cd now
<owen1> persia: someone has the same touchpad issue as me!
<owen1> how many people should be affected by a bug so it will be fixed by ubuntu developers?
<kees> pitti: it's not fixed in karmic too -- it's causing a lot of bug reports.
<kees> nixternal: yikes. :P
<siretart`> pitti: thanks!
<DktrKranz> pitti: wrt python-launchpadlib, I'm going to include fix in Debian too, thanks for fixing!
<pitti> DktrKranz: thanks! I sent a Debian bug, just didn't receive the ack for it yet
<DktrKranz> fine, thanks again :)
<pitti> DktrKranz: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566795
<ubottu> Debian bug 566795 in python-launchpadlib "python-launchpadlib: Always depend on python-simplejson" [Important,Open]
<DktrKranz> pitti: committed as http://svn.debian.org/viewsvn/python-modules?view=rev&revision=11298
<pitti> \o/
<slangasek> Keybnz: ok, I've committed my attempt at splitting the plymouth upstart job; I've exercised it every way I can think of here (startup, shutdown, with or without being pulled into the initramfs, adding some sleeps here or there to cause races), and it's standing up for me
<slangasek> Keybnz: but I'd like it if you could give it a once-over before I upload
<dpm> hey, good morning pitti. We've got a bug with a karmic-proposed language pack (bug 511837) - What's the usual procedure to sort this out? Do I simply ask you or any archive admin for removal of the package?
<ubottu> Launchpad bug 511837 in language-pack-ast "Latest language pack in 'karmic-proposed' breaks Firefox in Asturian" [Undecided,New] https://launchpad.net/bugs/511837
<pitti> hey dpm
<dpm> hey :)
<pitti> dpm: if the others work fine, then let's just remove that -proposed version, indeed
<pitti> dpm: however, a better fix would of course to upload a new langpack with a fix; so that's not easy to do?
<dpm> pitti, yeah, altough we haven't yet located the problem
<dpm> the cause, I mean
<pitti> dpm: -gnome-ast is okay, though?
<dpm> pitti, they've only complained about the -ast one, as they've noticed the problem with FF, which is in that pkg
<dpm> pitti, let me ask you something else somehow related first:
<dpm> you copied the 20090115 PPA langpacks to karmic-proposed at Arne's request, but at around the same time the 20090122 language packs were released on the PPA.
<dpm> I want to make a call for testing, but for those using the PPA it might be a bit cumbersome, since they'll have to downgrade to the 20090115 langpacks in karmic-proposed in order to test them
<dpm> Do you think it might be possible to copy all the 20090122 PPA langpacks to karmic-proposed? Is it an involved process?
<pitti> dpm: not involved for me, just takes some buildd time
<pitti> dpm: I'm happy to move them over if you want those tested instead
<pitti> dpm: language-pack-ast removed from karmic-proposed, btw
<pitti> dpm: so want me to copy ppa to proposed (except -ast)?
<dpm> pitti, if possible, yes, please, all 20090122 from the PPA to karmic-proposed except -ast
<pitti> dpm: running now
<pitti> dpm: ETA half an hour for copying the sources, and perhaps a day for all the binaries to get built
<dpm> awesome, thanks pitti!
<pitti> you're welcome
<slangasek> persia: 20:00 UTC on Friday... hmm, not having managed to get around to prepping for it this weekend, I probably shouldn't commit, no :/
<persia> slangasek: Well, let me know if you change your mind.  I'm more than happy to not get up early, and while I'll prep, it's not much (as I've given the same session a few times before).
<hiexpo> hello all
<slangasek> persia: ack, thanks
<MacSlow> seb128, do you know which module provides /usr/bin/g-ir-scanner?
<seb128> which binary you mean in lucid?
<seb128> gobject-instrospection
<cjwatson> MacSlow: http://packages.ubuntu.com/
<MacSlow> seb128, cjwatson: thanks
<lool> Is there a place where I can easily see the dependencies between pockets?
<lool> I guess it's somewhere in the Launchpad source code, I would guess near the ogre-model implementation
<persia> lool: How do you mean?  Which pockets depend on which other pockets?
<lool> persia: Yes
<lool> e.g. -proposed depends on -updates
<persia> It's main->(null), restricted->(main), universe->(main), multiverse->(main,restricted,universe)
<lool> I'm not quite sure whether -updates depends on -security since the security updates are copied
<persia> Oh, at that level.
<lool> persia: I mean pockets, not components
<persia> Oh, sorry.  I'm not sure.
<ogra> Keybnz, are you around by chance ? i'm trying to find out how plymouth is supposed to work, i seem to be able to run it imaually on my babbage board and get a progressbar on tty8 but i dont see anything on boot
<ogra> *manually
<pitti> cjwatson: in GNOME, gnome-keyring-daemon already provides an ssh auth agent and sets $SSH_AUTH_SOCK; would it be okay if 90x11-common_ssh-agent would check that condition (i. e. running gnome and gnome-keyring autostart exists) and not run ssh-agent in that case?
<cjwatson> pitti: if you can stop me being flooded with bug reports about that ssh agent sucking?
<pitti> cjwatson: (i. e. without that Xsession.d script we save the0.7 second overhead, but still retain the nice UI password dialogs)
<cjwatson> I wish we could *only* use the openssh one, frankly
<apachelogger> asac: ping
<pitti> cjwatson: well, I asked you only the second time now; but instead of just doing it, I'd rather check with you first
<pitti> I don't see an obvious benefit for day-to-day desktop use, but I'm sure you know better what else it is used for
<cjwatson> whatever, do it
<cjwatson> I'll ask you any time I get a bug about it
<pitti> cjwatson: what kind of UI would ssh-agent2 use?
<cjwatson> day-to-day> this is the fallacy of novice users ...
<pitti> right, and that's why I'm asking you :)
<cjwatson> the point is that if we're making it difficult to use the openssh agent, the GNOME one had better be absolutely robust
<pitti> since at least under GNOME, gnome-keyring does the password input, not ssh-agent (apparently)
<cjwatson> and it isn't, judging from my bugmail
<cjwatson> the openssh agent spawns ssh-askpass
<pitti> well, how do you suppress g-keyring UI today?
<seb128> you turn off the gnome-keyring autostart I guess
<pitti> I'm not talking about removing the Xsession.d file; we need it for !GNOME or for people who remove the autostart file
<seb128> using the capplet
<pitti> seb128: right
<pitti> but we can check for exaclty that
<seb128> the change would break that
<seb128> since the etc autostart will not go away
<seb128> a .local one is written
<seb128> when you uncheck it using the capplet
<pitti> seb128: ah, good to know
<pitti> now, still easy to test
<cjwatson> pitti: what exact diff are you talking about applying here?
<pitti> cjwatson: I don't have the diff yet; talking about strategy before starting to mess up things
<cjwatson> AFAICS that Xsession script *already* checks [ -z "$SSH_AUTH_SOCK" ]
<seb128> right, but it's ran before gnome-keyring
<pitti> right, but g-k is started later on
<cjwatson> how can we make it straightforward for people to use g-k for gpg but not ssh?
<pitti> if there's a good argument for keeping it running even under GNOME, I'm happy to take a look at the ssh-agent code and see whether things can be moved around
<pitti> to not block the startup for that long until it forks
<seb128> cjwatson, g-k doesn't do gpg
<seb128> cjwatson, seahorse does
<cjwatson> oh
<cjwatson> is it not seahorse that's being the ssh agent then?
 * cjwatson is confused about how all the pieces fit together
<seb128> no, gnome-keyring is
<seb128> seahorse is the gpg agent
<cjwatson> ah
<cjwatson> pitti: the good argument is that ssh-agent is much more robust
<seb128> (which we don't install by default)
<cjwatson> I keep getting bugs about the agent having died; they always turn out to be because people were using g-k
<seb128> urg
<cjwatson> we may have been reassigning some of them incorrectly to seahorse
<seb128> I will check
<seb128> but I'm subscribed to both and see very few crashers there
<cjwatson> and I think g-k doesn't support all the features either; IIRC it doesn't support time-limited identities
<cjwatson> well, it's some for g-k versus none for openssh :)
<seb128> right
<seb128> I've no opinion on whether you should better fix gnome-keyring or drop it
<pitti> oh, ssh-agent doesn't cache passphrases by default?
<pitti> ah, ignore me
<seb128> I've no issue with gnome-keyring and I expect it works for most users just sshing random boxes
<cjwatson> I'd definitely like to know why ssh-agent makes a significant difference to startup time
<cjwatson> it does hardly anything on startup
<seb128> it might have limitation than power users hit though
<pitti> http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3.png vs. http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100125-3-no-ssh-agent.png
<pitti> (note that on the former, the first gnome-session process is actually ssh-agent, due to the fork/execve'ing bootchart gets confused)
<cjwatson> an strace would be useful
<pitti> hm; I disabled the g-k autostart .desktop, and I still don't get passphrase caching
<pitti> seb128: anyway, text-mode only input isn't really an option, is it? (i. e. dropping g-k); it would break sftp gvfs connections and all that?
<pitti> cjwatson: aye, I'll give it some tracing
<cjwatson> dropping g-k isn't text-mode-only
<pitti> hm, perhaps the agent just isn't working for me
<cjwatson> ssh-add reads a passphrase from the terminal if it has one, but if it doesn't have one and it has $DISPLAY, it uses ssh-askpass-gnome
<ogra> god !
<ogra> who decided to lock my screen every time DPMS kicks in
<ogra> thats overly annoying
<cjwatson> of course we don't install ssh-askpass-gnome by default ...
<cjwatson> oh, we do
<pitti> we don't, but that could be fixed
<cjwatson> we do, it has Task: ubuntu-desktop
<pitti> ah, it's called gnome-ssh-askpass, sorry
<cjwatson> oh, the binary is, yes
<cjwatson> I wonder if it's taking ages to seed the RNG for some reason
<pitti> hm; $SSH_AGENT_PID points to ssh-agent, and $SSH_AUTH_SOCK is set as well
<ion> We could put 50 megabytes of random bits to the installer CD and have installations use the file for fast random numbers.
<pitti> FSVO "random", yes :)
<pitti> so, AFAICS the check for "will gnome-keyring be running" should be done either way, since g-k just shadows ssh-agent
<pitti> but there's still the option of disabling g-k by default and thus making ssh-agent actually used
<cjwatson> bugs in g-k relevant to ssh: bug 505278 (missing feature, arguably dangerous), bug 485537 (stability), bug 470456 (key decode problem?), bug 418879 (stability), bug 383926 (stability), bug 365589 (stability) ...
<ubottu> Launchpad bug 505278 in gnome-keyring "ssh-add -D deleting all identities does not work. Also, why are all identities auto-added?" [Low,Confirmed] https://launchpad.net/bugs/505278
<ubottu> Bug 485537 on http://launchpad.net/bugs/485537 is private
<ubottu> Launchpad bug 470456 in gnome-keyring "gnome keyring with ssh-agend breaks pubkey login" [Low,Triaged] https://launchpad.net/bugs/470456
<ubottu> Launchpad bug 418879 in gnome-keyring "seahorse fails with concurrent ssh connections" [Low,New] https://launchpad.net/bugs/418879
<ubottu> Launchpad bug 383926 in openssh "ssh-aggent stopped accepting connections" [Undecided,Invalid] https://launchpad.net/bugs/383926
<cjwatson> it appears that generally gnome-keyring just stops accepting connections rather than actually crashing
<cjwatson> the failure mode where it all gets stuck and ssh-add -l says it can't connect to the agent seems moderately common
<pitti> hm, I still can't get this to work; "ssh-agent /bin/bash" sets the $SSH_* but doesn't do any caching; so it seems the Xsession.d script is actually wrong
<pitti> cjwatson: thanks for fishing out the bugs; that's good to know for deciding which one to use by default
<cjwatson> oh and some problem with the confirmation prompt which seems like it might be bound up with a bug or two in openssh as well?  bug 209447
<ubottu> Launchpad bug 209447 in gnome-keyring "gnome-keyring-daemon does not honor constrained ssh identities" [Medium,In progress] https://launchpad.net/bugs/209447
<pitti> oh, you have to explicitly use ssh-add
<cjwatson> yes
<cjwatson> looks like I ought to backport the patch from https://bugzilla.mindrot.org/show_bug.cgi?id=1612
<ubottu> bugzilla.mindrot.org bug 1612 in ssh-add "ssh-add should not discard constraints if the agent fails to implement them" [Normal,Closed: fixed]
<cjwatson> but 209447 still indicates that ssh-add -c will be ineffective with g-k
<cjwatson> pitti: users of openssh ssh-agent and g-k do have slightly different expectations
<pitti> *nod*
<cjwatson> the expectation with g-k is (as far as I can tell?) that it loads all your identities automatically
<cjwatson> the expectation with ssh-agent is that you have to explicitly request addition of the identities you want
<pitti> but if you always have to open a terminal to do "ssh-add" and enter your passphrase, where does the UI come into play?
<cjwatson> I believe that if you use an ssh program without a terminal attached, you should get a passphrase prompt too ...
<cjwatson> it just won't cache it
<cjwatson> hmm, maybe I'm wrong
<cjwatson> if I could remember how to detach from a tty, I could test this :)
<pitti> hmm; if I kill g-k, have ssh-agent running, and use "Connect to server" (sftp), I again get a g-k dialog
<pitti> cjwatson: "nohup program"?
<pitti> no, doesn't work, sorry (that just diverts stdin)
<pitti> Alt+F2 "ssh foo" -> that works
<geser> I remember some packages linking against python and failing because of -lssl missing. Does someone remember how to fix it? Because I've a similar issue when merging vim (the python interpreter support doesn't get build-in because of this).
<pitti> I see gnome-askpass-ssh
<cjwatson> ah yes, thanks
<seb128> geser, yes, one minute, I look for the change
<cjwatson> similarly command-line sftp from Alt-F2 works
<cjwatson> I'm not sure what "Connect to server" is doing
<seb128> geser, https://bugzilla.gnome.org/attachment.cgi?id=146930
<seb128> geser, see https://bugzilla.gnome.org/show_bug.cgi?id=600706
<pitti> cjwatson: it uses gvfs' sftp module to create a virtual mount (thruogh sftp)
<cjwatson> I guess the question is whether the expectations of openssh ssh-agent are sufficiently different to make it difficult to migrate to in the Ubuntu desktop
<ubottu> Gnome bug 600706 in general "don't use LOCALMODLIBS in the configure" [Normal,Unconfirmed]
<seb128> geser, could be similar
<pitti> cjwatson: right now it seems that g-k is woven pretty tightly into gnome; I'm not sure it'd be a good idea to rip that all apart in an LTS
<seb128> there is no reason we could fix the few issues g-k has, it doesn't seem to be too buggy
<seb128> couldn't
<geser> seb128: thanks, I'll check if I get this adopted to vim. Should this be forwarded to Debian (I don't know if Debian's python and ours are similar enough to cause similar problems in Debian too)?
<seb128> geser, dunno if that's similar but the use is wrong in any case
<cjwatson> seb128: the concurrency issue is the big one, I think
<seb128> geser, having it failing it build now is just a sideeffect
<geser> ok
<cjwatson> it would be nice to add the missing agent protocol features as well, but concurrency problems are the ones that bite most users
<seb128> right
<seb128> we should try to get this one fixed in any case
<seb128> would be useful to have an overview of the behaviour difference
<seb128> and how gnome-keyring integrates in GNOME where the openssh one doesn't
<pitti> cjwatson: so, thanks for your help! it doesn't seem useful to me to have two agents running at the same time, so I'll work on that Xsession.d script
<cjwatson> looks like the bug reports on gnome-keyring are reasonably complete
<cjwatson> pitti: yes; as long as there's a reasonably easy (preferably documented!) way to use the openssh one
<pitti> cjwatson: ^ I agree; that's the very same problem right now, though (i. e. disable gnome-keyring autostart)
 * pitti ponders where to add that
<pitti> could go into a comment into that Xsession.d file, but that's not very visible
<cjwatson> that would be OK
<cjwatson> pitti: perhaps a link to http://live.gnome.org/GnomeKeyring/Ssh
<cjwatson> or just the gconftool command from there
<pitti> ah, thanks
<persia> I'd much prefer actual documentation than a web link: sometimes I am in networks where ssh is permitted and http is not.
<pitti> seb128: hm, querying for a gconf key is much more expensive than querying for the presence of an autostart file
<seb128> pitti, sure, it uses gconf
<NCommander> Does anyone know if quilt will make a directory if need be?
 * NCommander can't remember if it does on the fly
<persia> NCommander: It depends on your .quiltrc
 * persia hunts up the super-cool script
<NCommander> persia, I meant if building on the biuldds.
<NCommander> persia, I've almost finished porting likewise to ARM, but I need to add a new directory with files in it
<persia> You mean, can a quilt patch create a directory?
<NCommander> persia, yeah
<persia> Yes, that's no problem at all, so long as it contains contents.
<persia> Anyway, the cool snippet fell off p.d.o anyway.  It automagically created debian/patches if needed.
<persia> s/anyway//
<jdstrand> lool, persia: re components> https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories
<jdstrand> lool, persia: (and pockets)
<persia> jdstrand: Cool.  Thanks.
<lool> jdstrand: excellent, thanks
<persia> jdstrand: Is there a -security -> -updates copy that happens as well?
<jdstrand> persia: yes. it is a direct pocket copy after the USN is published. we used to only do it periodically, but now we do it after every security update
<jdstrand> persia: in practice, -updates should always have -security. that is a procedural issue though, not enforced by the builds. it is possible someone would not perform the pocket copy, for example
<persia> OK.  That explains why both -security and -updates ought be in the sources.list.
<persia> Is there any difference between security.ubuntu.com -updates and archive.ubuntu.com -updates ?
<jdstrand> persia: someone should not run only -updates, correct
<jdstrand> persia: someone running on -security is supported though
<persia> (just whist I have you answering questions :)
<jdstrand> persia: re security.u.c and archive.u.c wrt to -updates> I'm not sure
<cjwatson> the other reason why -security is there is that it's quicker - e.g. not dependent on mirror propagation time
<cjwatson> persia: the two -updates are identical
<persia> cjwatson: Thanks.
<cjwatson> the reason we copy stuff to -updates, at root, is that it's much cheaper for Canonical because it means we can use the mirror network - but at the same time having stuff available on -security too means that we don't have to suffer mirror lag for urgent updates
<lool> jdstrand: Interestingly, -proposed isn't built with -proposed
<lool> I expected otherwise
<seb128> lool, that avoids surprises when moving one thing to updates I guess
<persia> But we've updated things that depend upon each other before.  Was that always done by pocket-copy from somewhere else?
<lool> Same with -backports
<lool> seb128: As persia said, sometimes that might be needed
<lool> e.g. if you want to push a new xulrunner + new firefox built against it or something
<seb128> shouldn't the depends express that in those cases?
<persia> -backports definitely builds against -backports.
<persia> That's why we do things like backport newer debhelper
<lool> seb128: Even if Depends do, how do we push two source packages a and b together if a needs to build against b and b can't go in -updates alone?
<persia> I have a suspicion that -proposed builds against -proposed, just in the nature of things.
<seb128> lool, move both together?
<lool> I suspect so as well; in fact ISTR that we had incidents where we didn't move enough stuff from -proposed to -updates
<seb128> right, and I'm wondering if the policy didn't change after those
<seb128> but I'm just doing speculations
<lool> Same here
 * persia as well
<seb128> the soyuz guys probably know
<persia> So, back to the original question: is there a way to extract this information from LP, which is probably best asked in #launchpad
<jdstrand> persia, lool: I'll get an official answer on building -proposed with -proposed and update the wiki
<persia> jdstrand: Thanks.  Could you confirm my understanding about backports at the same time, and update that if warranted?
<jdstrand> persia: I'm pretty sure that is an omission-- clamav is a good example
<jdstrand> persia: but sure
<persia> clamav is special: it's often pocket-copied with rdepends (just because it has heaps of them).
<jdstrand> persia, lool, seb128: -proposed is built with -proposed and -backports is built with -backports
 * jdstrand updates wiki
<seb128> jdstrand, hi, thanks
<lool> http://paste.ubuntu.com/362605/
<lool> jdstrand: ^
<lool> lib/lp/soyuz/adapters/archivedependencies.py in lp:~launchpad-pqm/launchpad/devel
<jdstrand> lool: cool, thanks :)
<lool> It wasn't that hard to find it in the launchpad code after all, and I happened to have a checkout (fortunately)
<jdstrand> lool: I asked bigjools who did the same thing for me :)
<persia> Ah, so theoretically something could be built in updates against release, security, updates, except policy forbids it.
<jdstrand> persia: yeah, I noticed that too. I'm going to add a blurb on that as well
<lool> persia: Apparently PPAs have a mode for that
<lool> (Which kind of makes sense)
<lool> In fact the Default PPA mode is "security dependencies and recommended updates", and I think it's basically it
<geser> cjwatson: I've seen that you committed a change to lp:ubuntu/vim but didn't upload it. any reason for this? (I included your change in my vim merge)
<cjwatson> geser: I didn't see any rush to upload it
 * soren hugs geser 
<cjwatson> one of the advantages of lp:ubuntu/... to me is that I don't necessarily have to immediately upload everything I do :)
<geser> ok
<soren> geser: Thanks! That should get rid of those annoying gtk static gravity warning thingies.
<cjwatson> geser: how did you get the merge to work?  'bzr merge-package' wasn't working right for me, and I was waiting for james_w to get back so I could talk with him about it
<cjwatson> and I didn't want to do the merge outside bzr and store up trouble for later
<geser> cjwatson: by hand :(
<cjwatson> won't that make later merges harder
<cjwatson> ?
<geser> cjwatson: good question
<geser> soren: bug #511356 if you're interested
<ubottu> Launchpad bug 511356 in gnupg2 "Merge gnupg2 2.0.14-1 from Debian testing" [Undecided,New] https://launchpad.net/bugs/511356
<geser> james_w: how to handle the case when "bzr merge-package" doesn't work because it complains about different roots (have to lookup the exact error message if necessary)
<cjwatson> oh, I can answer that part of it, you need to backport a patch from bzr.dev
<cjwatson> but even after that I ran into trouble
<cjwatson> bug 494269 for the first part
<ubottu> Launchpad bug 494269 in bzr/2.0 "tree transform cannot change root id" [High,Fix released] https://launchpad.net/bugs/494269
<cjwatson> after that, I found that merge-package was basically stuck in a conflicts loop and I couldn't figure out how to get it out
<sgallagh> tjaalton: Heads-up: we found a serious bug in SSSD 1.0.3 on x86_64. We're going to try to release 1.0.4 today to address it (basically, authentications don't work in 1.0.3 on 64-bit)
 * soren would like a --please-accept-that-files-named-the-same-are-in-fact-the-same-in-spite-of-seemingly-being-from-different-roots-and-thus-having-different-file-IDs for "bzr merge"
<tjaalton> sgallagh: ok thanks, I haven't managed to get that far anyway :)
<sgallagh> tjaalton: No problem, just want to keep you in the loop
<tjaalton> sgallagh: appreciate it. I'm on the list and #freeipa as well :)
<sgallagh> tjaalton: Well, by mistake we didn't have the discussion about it in #freeipa (wrong channel), so I wasn't sure if you'd notice one patch among dozens on the list :)
<geser> cjwatson: I need sponsoring for the vim merge anyways, so I created the classical debdiff (bug #509900)
<ubottu> Launchpad bug 509900 in vim "Merge vim 2:7.2.330-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/509900
<tjaalton> sgallagh: :)
<primes2h> cr3: Hello, just tried latest language-pack and still have a problem in Karmic with checkbox translations. Do you remember?
<primes2h> cr3: Tried with latest Lucid and have problem too.
<primes2h> It seems it doesn't take updated po
<primes2h> also if it's fully translated
<primes2h> I remember there was a translation infrastructure to change, due to / issues...
<primes2h> cr3: Did you have a look, btw?
<primes2h> We know have checkbox partially translated, and translated strings cannot be updated...
<cr3> primes2h: I'm in the middle of a few things, but I believe the problem has been fixed but a new release has simply not been pushed.
<cr3> primes2h: I've been meaning to do that for a while, but I think you've just given me enough inspiration to do it today :)
<primes2h> cr3: is there a ppa to test?
<primes2h> cr3: That's nice ;)
<primes2h> Thank you
<primes2h> cr3: you meant I stress you out enough to give you inspiration, isn't it?
<primes2h> ;)
<primes2h> s/stress/stressed
<cr3> primes2h: I'm attempting to push to my own ppa, which should only take a moment: https://edge.launchpad.net/~cr3/+archive/ppa
<primes2h> cr3: cool, I'll check it out and I let you know. Thanks a lot :)
<cjohnston> Don't forget... Ubuntu Developer Week is starting in 30 minutes in #ubuntu-classroom and #ubuntu-classroom-chat  - http://wiki.ubuntu.com/UbuntuDeveloperWeek
<ion> pitti: Re: desktop-lucid-startup-speed, perhaps by now it would be feasible to make Nautilus paint a transparent background so that the root window shows through if thereâs a compositing manager. No need to paint the desktop background twice.
<pitti> ion: we don't even have nautilus render the desktop in UNE
<pitti> ion: but for standard GNOME that would be nice indeed
<ogra> is Keybuk the only pwrson currently working on plymouth or is there anyone else i could talk to about it
<mvo> ogra: tseliot most likely
<ogra> mvo, ah, thanks
<ogra> i see it working on armel if i run it manually ... but it doesnt seem to work by default during boot for whatever reason
<OdyX> ogra: look after panthera on OFTC, he packaged it for Debian
<ogra> OdyX, but i doubt he has a clue about what has been done in ubuntus initrmafs scripts to make it default :)
<ogra> *initramfs
<ogra> but thanks for the hint
<OdyX> ogra: that's exactly why I point you to him :-)
<tseliot> ogra: do you mean, if you run it manually inside X?
<ogra> tseliot, nope, i start plymouthd and trigger plmouth with a sleep on tty1, then i see a progressbar on tty7 if i switch over to it fast enough
<ogra> so in general it seems to work
<tseliot> ogra: doesn't it work if you start the upstart job?
<ogra> but it desnt seem to work during boot ... note that i only have a std framebuffer though
<ogra> hmm, i didnt test that, one sec
<tseliot> ogra: std framebuffer as in what vga16fb gives you? Or something with KMS?
<ogra> god ! why is my screen locked all the time !
<ogra> tseliot, its ARM ... they usually bring their own framebuffer driver
<ogra> but it featurewise it should be on par with vga16fb
<ogra> sorry, need to boot my board first before i can check the upstart job
<ogra> takes a minute
<tseliot> ogra: I was asking as plymouth doesn't work with vga16fb yet
<ogra> well, as i said, i see it working on tty7 if i do the above steps
<ogra> what does not work there yet ?
<tseliot> ogra: plymouth doesn't support 16 colours fbs
<ogra> ah
<mdeslaur> pitti: what are your thoughts on us releasing security updates for LP: #446299 ?
<ogra> well, the framebuffer is also used with xfbdev
<tseliot> ogra: but if you say that it works with that fb then it must be something else
<ogra> so i would suppose it supports more than 16 cols
<tseliot> ogra: I guess so
<ogra> ok, running the upstart job gets me the same as my manual thing
<ogra> hmm, but i seems it killed the framebuffer this time
<ogra> ssh connection is still fine though, but no tty switching or anything is possible anymore
<ogra> tseliot, do you know if the vga16fb issues are supposed to be solved before release ? or is there any usplash fallback plan for such setups
<tseliot> ogra: either I fix that in time or we use the text plugin. I hope it's the former ;)
 * ogra wonders why there are still so many hal processes in lucid 
<ccheney> anyone know if doko is working today?
<ScottK> I think he's on vacation today.
<ccheney> ok
<ogra> tseliot, GEEZ !
<tseliot> ogra: ???
<ogra> tseliot, it works !! ...
<ogra> ogra@babbage2:~$ /usr/sbin/plymouth-set-default-theme
<ogra> text
<ogra> :P
<ogra> ogra@babbage2:~$ sudo /usr/sbin/plymouth-set-default-theme ubuntu-logo --rebuild-initrd
<ogra> that gets me an ubuntu logo
<ogra> (no animation or anything though)
<tseliot> aah so including the theme in the initrd works
<ogra> tseliot, any idea why it defaulted to text ?
<ogra> well, not sure if i needed to include it in the initrd
<ogra> the help text said that would be needed after changing the theme
<ogra> so i just added that option ... i didnt try without
<tseliot> ogra: we don't do it by default. only in case of encrypted disks
<ogra> ah
<ogra> i'll try to revert to the former state and see if just setting it without rebuilding initrd fixes it too
<tseliot> ok
 * ogra runs sudo /usr/sbin/plymouth-set-default-theme text --rebuild-initrd
<ogra> i guess that gets me beck to original state
<ogra> *back
<tseliot> ogra: I think you could change /lib/plymouth/themes/default.plymouth and remove the text plugin from the intrd
<ogra> ah, k
<ogra> its intresting that it works flawless in our other armel hardware
<ogra> i wonder what selects text at first place
<tseliot> ogra: maybe there's some fallback which selects the text plugin
<ogra> we should amke sure its not falling back on imx51 then :)
<tseliot> slangasek: did you work something similar? ^^
<ogra>  /lib/plymouth/themes/default.plymouth looks like everything points to ubuntu-logo
<ogra> aha
<ogra> # plugins that are always required
<ogra> copy_exec /lib/plymouth/text.so /lib/plymouth/
<ogra> copy_exec /lib/plymouth/details.so /lib/plymouth/
<ogra> so text is always there
<ogra> (from /usr/share/initramfs-tools/hooks/plymouth)
<tseliot> right
<ogra> so just running update-initramfs -u while the plugin defaults to ubuntu-logo works too
<ogra> am i supposed to see any kind of animation btw ?
<ogra> i only see a white logo
<tseliot> ogra: no, that's all you can see now and it's just a provisional theme
<ogra> cool, then it all works as it should
<mathiaz> pitti: hi!
<mathiaz> pitti: Is the desktop team looking after libgda?
<pitti> mathiaz: not particularly, but in general it's desktop-ish realm
<pitti> (it's in universe, though)
<mathiaz> pitti: ah ok. I've got some request for an update of libgda
<mathiaz> pitti: I'll advise to contact the debian maintainer then
<pitti> hm, libgda3 was removed from unstable/testing
<pitti> perhaps a package rename
<mathiaz> pitti: probably libgda4
<mathiaz> hm nope
<mathiaz> pitti: libgda-4.0-4
<pitti> ah, libgda4 is it then
<primes2h> cr3: I tried latest checkbox. Strings that needed are now updated but strings with / within are still untranslated. Maybe pot/po needs to be regenerated?
<primes2h> Tried both Karmic and Lucid
<alkisg> On a newly installed system I have LANG=el_GR.utf8 instead of el_GR.UTF-8, and that breaks a lot of programs, for example LTSP. Should I modify LTSP to work around this problem, or is this some transitional phase?
<cjwatson> alkisg: (a) that's unintentional (b) it's still a bug that LTSP breaks
<alkisg> cjwatson: locale-gen $LANG returns false...
<cjwatson> programs aren't supposed to look at the locale name components themselves; or if they do they need to be very very careful :)
<cjwatson> I have no idea about locale-gen, but el_GR.utf8 is actually the canonical name of the locale that you get back from 'locale -a'
<cjwatson> although el_GR.UTF-8 is the one listed in /usr/share/i18n/SUPPORTED
<cjwatson> the installer is meant to generate el_GR.UTF-8, but programs should support either one
<alkisg> On system (a) I have Lucid installed from alpha 1, and it has el_GR.UTF-8. On system (b) I installed alpha 2 and I got el_GR.utf8
<alkisg> (LANG=el_GR.utf8)
<cjwatson> please file one bug on localechooser for generating that spelling, and another on LTSP for not supporting it
<alkisg> I think the second one should be filed against locale-gen, which returns false...
<alkisg> Thank you.
<cjwatson> we've never guaranteed that 'locale-gen $LANG' is something you can do, AFAIK
<alkisg> Hmmm....
<cjwatson> LTSP could simply check whether the current locale is working before it tries that
<cjwatson> which should be the case for a freshly-installed system
<alkisg> Got it.
<cjwatson> I rather suspect locale-gen has only ever been guaranteed to support the spellings in /usr/share/i18n/SUPPORTED
<alkisg> I'll patch LTSP to properly handle that case.
<cjwatson> alkisg: thanks
<alkisg> thank *you* :)
<cjwatson> I'll look into the odd generation as time permits
<cjwatson> would like to avoid triggering more bugs than we have to
<alkisg> cjwatson: I have a feeling it's a gdm problem, as /etc/default/locale is correct...
<cjwatson> ah, could well be then
<alkisg> Heh, and I just noticed that if I login from a console instead of using gdm, I get a proper LANG :)
<kees> can someone poke firefox in the NEW queue?
<sianis> mvo
<sianis> where are you? :)
<mathiaz> slangasek: hi!
<mathiaz> slangasek: if a daemon can be run in both the foreground and the background (ex: apache2) which option is recommended for writting an upstart job?
<mathiaz> jdstrand: hi!
<mathiaz> jdstrand: what's the directory where packages can drop uwf profiles?
<mathiaz> jdstrand: *ufw*
<jdstrand> mathiaz: /etc/ufw/applications.d
<jdstrand> mathiaz: hi! :)
<mathiaz> jdstrand: thanks!
<jdstrand> sure
<mathiaz> jdstrand: I'll mention ufw profile integration in my ufw talk about server pkg
<mathiaz> jdstrand: I'll mention ufw profile integration in my *udw* talk about server pkg
<jdstrand> heh
<jdstrand> awesome! :)
<mathiaz> jdstrand: hi!
<mathiaz> jdstrand: is there a wiki page about developing an AppArmor profile
<mathiaz> jdstrand: and how to integrate it in packages?
<jdstrand> mathiaz: https://wiki.ubuntu.com/AppArmor has a bunch of stuff and links to various tutorials, etc
<sebner> siretart`: heya, any idea when gstreamer-plugins-bad will be fixed?
<jdstrand> mathiaz: https://wiki.ubuntu.com/ApparmorProfileMigration has the basic steps for packaging-- ie, start with apparmor-profiles and then migrate a profile to the package
<mathiaz> kees: are you done for udw?
<kees> mathiaz: yup!
<kees> mathiaz: thanks :)
<slangasek> ogra, tseliot: we *shouldn't* include plymouth in the initramfs by default, but the package in the archive still does; the bzr branch has changes that should remove the need for it in the initramfs by default (I hope)
<slangasek> tseliot: the text plugin was already being included by the initramfs hook script when I got to it; it's right to have it there because plymouth uses it as a built-in fallback in certain cases (except not with ubuntu-logo, because the script plugin in the archive is broken - fixed in bzr).  I added the details plugin, which is also used by plymouth as a fallback in certain conditions.
<slangasek> ogra: ^^ so any problems you're seeing are *not* due to a fallback.. :)
<superm1> slangasek, i dont think tseliot is signed in, you'll probably want to reping later when he is
<slangasek> superm1: heh, my tab completion is lying to me :/
<slangasek> thought it was strange for him to be around at this hour... :)
<slangasek> mathiaz: foreground or background> background, if it's not samba, where apparently this confuses the crap out of upstart :)
<cody-somerville> I've noticed that the Ubuntu Core Development Team has been added to the kubuntu-dev team.
<cody-somerville> Two questions)
<cody-somerville> 1. Should I do the same for the xubuntu-dev team?
<cody-somerville> 2. Is there someway that I don't have to get e-mails about build failures in the kubuntu-ppa team's ppas?
 * sebner waves at mighty cody-somerville :)
<cody-somerville> sebner, Hi :)
<smoser> given a key id like '03683F77', is it posisble to dump the ascii armored key without first receiving (--recv) it ?
<cjwatson> no, the key id isn't enough information
<sladen> smoser: http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x0620BBCF03683F77
<smoser> thats exactly what i want, but expected i could get that more keyserver portably with 'gpg' somehow.
<smoser> cjwatson, why isn't it enough. ?
<smoser> basically i want the same as:
<smoser>  k=03683F77; gpg --keyserver keyserver.ubuntu.com --recv $k ; gpg --export --armour $k; gpg --batch --yes --delete-keys $k
<cjwatson> smoser: I thought you were asking whether you could do it without having to download anything
<smoser> well that would be magic :)
<sladen> smoser: there's nothing magic about it, all gnupg does is:
<sladen> smoser: send(5, "GET /pks/lookup?op=get&options=mr&search=0x03683F77 HTTP/1.1\r\nHost: keyserver.ubuntu.com:11371\r\nAccept: */*\r\nPragma: no-cache\r\nCache-Control: no-cache\r\n\r\n",
 * sebner is wondering if any archive admin is brave enough to kick firefox out of NEW (into the archive of course) :P
<sladen> smoser: it's normal HTTP request, that you can do with your browser as demostrated in the example above
<smoser> sladen, right. i just didn't think that the url you gave above would be an api rather than just a web browsing feature of a given keyserver
<micahg> sebner: I thought it was already done
<sebner> micahg: /me still sees it in NEW
<micahg> sebner: https://edge.launchpad.net/ubuntu/+source/firefox
<micahg> nm
 * micahg is still learning...
<sebner> micahg: https://edge.launchpad.net/ubuntu/lucid/+queue
<micahg> it was approved to build but not publish
<sebner> ack
<slangasek> sebner: I'll be processing NEW shortly, fwiw
<smoser> sladen, so i must be missing something.  how is it reasonably secure to import a key from an http (not https) server?
<smoser> i'm obviously missing something.
<cjwatson> smoser: because you can trivially check that the key ID matches for yourself
<cjwatson> and that's the sole parameter you're supplying, so the transport layer makes no difference
<smoser> so keyid is a hash (or otherwised derived input) from key
<smoser> is that right?
<sebner> slangasek: my hero :)
<smoser> i dont expect anyone to give me a full crypto lesson here, feel free to say rtfm
<cjwatson> smoser: for current key types, it's just the last eight hex digits, truncated
<cjwatson> ... of the fingerprint
<smoser> cjwatson, thanks.
<cjwatson> you can import the ascii-armoured file into a temporary keyring and use --list-keys on it to check
<cjwatson> or indeed if you just run 'gpg <file>' it'll show you
<ari-tczew> can someone sponsor for main take a look on merges?
<ari-tczew> bug 503136
<ubottu> Launchpad bug 503136 in dmraid "Merge dmraid 1.0.0.rc16-2 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/503136
<ari-tczew> bug 499671
<ubottu> Launchpad bug 499671 in texinfo "Merge 4.13a.dfsg.1-5 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/499671
<crimsun> would an archive admin please promote libglade2.0-cil-dev? (It being in universe on i386 is causing gbrainy to FTBFS.)
<cjwatson> crimsun: done
<crimsun> cjwatson: thanks!
<cjwatson> sebner,micahg: accepted firefox binaries
<sebner> cjwatson: great, thx :)
#ubuntu-devel 2010-01-26
<slangasek> mathiaz: it looks like there haven't been any ISO tests of the server CDs yet for 8.04.4; can you help with that?
<mathiaz> slangasek: yes - I plan to schedule some iso testing tomorrow
<mathiaz> slangasek: does this work into your schedule?
<slangasek> that works, thanks
<mathiaz> slangasek: 20100121.3 is the one to be tested?
<slangasek> mathiaz: yes
<persia> lamont: If you happen to find some time, could you look at bug #67544
<ubottu> Launchpad bug 67544 in fpc "PPC build of fpc fails" [Unknown,Fix released] https://launchpad.net/bugs/67544
<mathiaz> cjwatson: hi - are you still planning on fixing bug 218965?
<ubottu> Launchpad bug 218965 in netcfg "preseeding hostname doesn't work in a network install" [High,Triaged] https://launchpad.net/bugs/218965
<lamont> persia: gar
<lamont> how soon do we care enough about that for me to care?
<persia> lamont: I just noticed it was broken, and did the bootstrap, discovering it was not so hard.  Sometime prior to release would be nice, preferably prior to beta.
<persia> I have some debs, but I don't expect you to trust mine, even if I sign them :)
<lamont> ok.  I have a todo item to document this process and train one of the admins - so I think I'll document the pain and turn them loose - prolly 2-3 weeks. failing that, it'll be before the end of feb
<lamont> persia: the process is simple - I grab the tarball, unpack it on a spare ppc box, install the needed extra cruft in it, build the package, take _those_ debs, lob them in the again freshly unpacked tarball (installed), put all the ppc buildds on   manual, upload the hacked over tarball, build what needs to be built, and then restore the pristine tarball.
<lamont> trivia
<lamont> l
<lamont> and yeah, using the sid binaries
<persia> lamont: Yeah, because it doesn't work with the squeeze binaries (or didn't yesterday) :)
<persia> But training someone else does sound like the best plan :)
<lamont> so... ticket in RT, depends on my ticket to document things, due 1 march.  that should work out properly
<persia> Thanks.
<lamont> and since it's in universe, it's a perfect testcase
<lamont> gcc-snapshot/armel will be my testcase to make sure I like the wiki
<persia> I didn't see any bootstrap issues in main this weekend, so, fingers-crossed, it should be a while before that becomes a concern.
<lamont> gcc-snapshot/armel (for ada) is on my radar for this week
<persia> Does gcc-snapshot really need bootstrapping as binary?  Wouldn't it be easier to build it for all arches with gcc, and then rebuild with itself with source changes?
<lamont> fwiw, I took the bug
<lamont> no.  snapshot is turning on ada on armel...  so it has to bootstrap somewhere... bootstrapping it in snapshot is less of a pain, since it allows for testing before it goes 100% live
<persia> Aha.
<lamont> or some feature, at any rate... I'll admit to being a tad but fuzzy on it, having not read the ticket today
<persia> Hrm.  it seems in happier shape than I remembered.  I thought it failed on more arches.  But looking again, yeah, bootstrap for armel seems easiest.
<ScottK> slangasek: Did you finish your archive admin duties for today?  I was sort of hoping unbound would get out of binary New so I could transition it's reverse-build-depends tonight.
<slangasek> ScottK: still working on it; unbound is next up
<ScottK> Kewl.  Thanks.
<ScottK> I just did took care of quantlib's reverse-build-depends.
 * ccheney is trying to boot his old computer up on karmic disk to reinstall for his son and its not working for some reason, passes memtest and cd check but never gets into X
<ccheney> whats funny was it was running jaunty before, heh
<micahg> ccheney: upstart?
<ccheney> micahg: not sure what is wrong
<ccheney> micahg: i'm going to see if it will boot into direct install mode
<ccheney> i think i should try booting a jaunty disk to see if that still works
<ccheney> ah its still doing something for install mode, disk is just slow
<ccheney> yea karmic isn't working for me even in install only mode
<ccheney> probably some video driver issue
<ccheney> omg its just hideously slow
<ccheney> like what i would imagine it would take to run on a 486
<ccheney> ok so jaunty boots just fine, this is weird
<ccheney> is there a way to spin a new karmic cd with the kernel updates on it?
<ccheney> unfortunately i don't have a jaunty 64bit cd :-\
<slangasek> I wasn't aware that we had any video issues in karmic that were fixed by kernel updates?
<ccheney> ok
<slangasek> (non-trivial to respin a karmic liveCD, anyway)
<ccheney> well it doesn't seem like a video issue really, it just runs very slowly off the cd, many times slower than the jaunty disc
<ccheney> to the point i didn't wait for the actual installer to display once X finally came up
<slangasek> ah
<ccheney> same system running jaunty booted cd fine
<ccheney> i thought video wasn't working at first since it took so long for even X to start
<superm1> slangasek, there are tons of issues with intel arrandale with the karmic live media unfortunately
<superm1> much more stable after kernel updates
<slangasek> ok
<superm1> yay kms
<ccheney> i guess i could download the netinst image and install via my local mirror from ncurses :)
<ccheney> then determine what is wrong with my boot speed
<superm1> why not just throw it on a usb key instead?
<superm1> if it's CD problems
<ccheney> it seems to not like booting off usb
<ccheney> i'll have to look in the bios again to see if i can make it work
<ccheney> its an older machine athlon 64 from 2004
<ccheney> though maybe my front ports are just broken
<ccheney> i don't think its a cd issue since the cd check passed
<ccheney> hmm yea it seems to not want to boot off USB says CBIOSBoot error
<ccheney> google claims its a problem with the bios booting off usb
 * ccheney wonders why you can't burn a cd iso to a dvd
<ccheney> hmm seems to be a limit of the software i tried to use
<jmarsden> ccheney: growisofs -dvd-compat -Z /dev/dvd=image.iso    # should work for doing that.
<ccheney> jmarsden: ok
<ccheney> karmic worked fine once i installed it via mini.iso
<emgent> Riddell: ping
<persia> emgent !  Hey, do you still run your Ubuntu Developer Statistics site?
<emgent> ola persia
<emgent> no :Â°
<emgent> persia: can i pm you ?
<persia> Always :)
<emgent> danke ;)
<al-maisan> Good morning!
<dholbach> good morning
<pitti> Good morning
<siretart`> sebner: I guess it can be synced from unstable now. the actual breakage seems to be in libsdl1.2-dev, though
<persia> If that's about gstreamer-plugins-bad, SevenMachines has been working on the merge, and just did a rebuild of slv2 to keep LV2 support.
<siretart`> persia: ah, thanks
<pitti> asac: a firefox update (3.6) and a crash (accidentally hit the power button) later my firefox profile seems to be broken -- calling "firefox" just returns after a second and doesn't do anything (no error messages); another profile works; is there any hope?
<directhex> pitti, copy your bookmarks.html and erase the old profile? or do you have other stuff you want to save?
<pitti> there are plugins, history, and most of all, my keyring
<pitti> if I lose my keyring, I'm pretty much busted
<pitti> I guess I can just copy over all of that
<pitti> but I was more wondering if there's a method to add more verbosity, to find out what it's complaining about
<persia> pitti: Something like that happened to me in gutsy or hardy (I forget).  The solution was to extract stuff, and then add it back bit-by-bit.
<persia> Ended up being my custom js with my session page information, but I suspect there are lots of different causes.
<persia> Of course, if you're feeling bored, you can get a stacktrace and find the specific bit that causes it to choke, but ... :)
<pitti> well, it doesn't crash
<pitti> it cleanly exits
 * pitti already stared at strace
<persia> Oh my.
<tseliot> slangasek: are you around?
<slangasek> tseliot: regrettably :)
<tseliot> heh
<tkamppeter> pitti, hi
<slangasek> tseliot: btw, in response to your earlier inquiry - we *shouldn't* include plymouth in the initramfs by default, but the package in the archive still does; the bzr branch has changes that should remove the need for it in the initramfs by default (I hope)
<ogra> slangasek, oh, hey ... thanks for the explanation above ... what i dont get is why plymouth seems to default to ubuntu-logo on the dove subarch but not on imx51, i didnt see any arch or HW specific tests or anything that could cause this
<tseliot> slangasek: right. I was surprised to see what the package does
<slangasek> tseliot: and I added the details and text plugins to the initramfs because they're used as built-in fallbacks by plymouth, so we should always have them - except in the case of ubuntu-logo, the script plugin in the archive is broken; this is fixed in bzr
<slangasek> ogra: are you not booting with the 'splash' option on imx51?
<ogra> i do
<slangasek> are you actually seeing text, or are you just /not/ seeing a logo?
<tseliot> slangasek: what do you mean by broken?
 * tseliot is willing to bug upstream about it
<ogra> i'm seeing text and dont see a logo, the text seems to be the plymouth plugin though (i.e. fsck output is bold and the fonts slightly change on startup)
<slangasek> tseliot: see bzr for the fix :)  I hadn't gotten around to figuring out how to submit it upstream yet; if you're on speaking terms w/ upstream, feel free to pushit
<ogra> running plymouth-set-default-theme ubuntu-logo and rebuilding the initramfs gets me the logo then
<slangasek> or feel free to point me at hem
<slangasek> them
<ogra> iso it all seems fine apart from that step, i just dont get where the difference is regarding dove vs imx, they should behave the same unless there is any arch or HW specific check that prevents it
<ogra> *so
<ogra> butu the code doesnt indicate that there is
<ogra> *but
<slangasek> but if running 'plymouth-set-default-theme ubuntu-logo' fixed it, this must be the fault of whatever set your theme to something else originally
<slangasek> which doesn't seem to be the plymouth package itself
<ogra> well, what *does* set the theme ? we dont have any imx specific code here :)
<slangasek> no package is *supposed* to set the theme except for plymouth, and plymouth sets it right
<ogra> we always only went with the seeded packages in case of usplash
<slangasek> to ubuntu-logo, not to text
<ogra> so dont have any hacks or anything that could get in the way
 * ogra goes and checks debian-cd
<ogra> hmm
<ogra> CMDLINE="\"console=ttymxc0,115200 console=tty0 file=/cdrom/preseed/ubuntu.seed $EXTRA_ARGS\""
<ogra> does plymouth care for console= ?
<slangasek> no
<ogra> (thats only there for debugging during alpha)
<slangasek> ogra: when was this imx51 system installed?  Is it reproducible with alpha-2?
<ogra> yes, it was installed from an A2 image and dist upgraded
<ogra> i was noticing the difference with the plymouth errors going away and the bold fsck output after the upgrade that pulled in plymouth
<ogra> i just didnt get a logo
<slangasek> ogra: well, then the fault for the wrong theme isn't with the plymouth package, whose code has worked correctly and consistently since 7 Dec
<ogra> sadly i missed to check the actual link for /lib/plymouth/themes/default.plymouth but when i ran plymouth-set-default-theme for the first time it spit out "text"
<slangasek> errr, what do you mean, "the upgrade that pulled in plymouth"? plymouth was already included in A2
<ogra> slangasek, well, since last week for armel (it was ftbfs until i sponsored a fix)
<ogra> well, not plymouth but libdrm
<ogra> so it wasnt installed
<slangasek> I'm looking at the manifest - plymouth was in the imx51 A2 image
<ogra> bug #507765
<ubottu> Launchpad bug 507765 in libdrm "Please build libdrm-intel for ports architectures" [Undecided,Fix released] https://launchpad.net/bugs/507765
<ogra> surely a wrong version
<slangasek> yes, the version on imx51 for A2 had bugs, but not a bug in its theme handling
<ogra> weird
<ogra> well, there was a noticeable visual difference during boot before and after the upgrade
<ogra> and the "could not connect to plymouth" error vanished
<slangasek> can you check what the default.plymouth points to inside the A2 squashfs?
<ogra> one sec
<ogra> ogra@osiris:~$ ls -l /mnt/lib/plymouth/themes/default.plymouth
<ogra> lrwxrwxrwx 1 root root 18 2010-01-13 13:21 /mnt/lib/plymouth/themes/default.plymouth -> text/text.plymouth
<ogra> i'm pretty sure its still this way on newer images (i tested staurdays image and had no logo either, but dont have the image around anymore)
<ogra> *saturdays
<asac> pitti: odd
<pitti> asac: I removed the extensions now, it works again
<asac> pitti: usually if it just returns it means that firefox can see a firefox window somewhere ... so it just sends a remote command and exits
<asac> ok
<asac> pitti: could you narrow down what extension caused this?
<ttx> superm1: around ? I just hit bug 512661, I think it was uncovered by recent fix to bug 480055
<ubottu> Launchpad bug 512661 in dkms "linux-image-2.6.32-11-generic 2.6.32-11.15 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/dkms exited with return code 2 ("elif" unexpected)" [High,Confirmed] https://launchpad.net/bugs/512661
<ubottu> Launchpad bug 480055 in dkms "run-parts: /etc/kernel/postinst.d/dkms exited with return code 1 [ due to removed package with lingering files in /etc ]" [Undecided,Fix released] https://launchpad.net/bugs/480055
<slangasek> ogra: ok, got it
<slangasek> ogra: if update-initramfs is called while plymouth is unpacked but not yet configured, the initramfs hook, which calls plymouth-set-default-theme to /query/ the theme will end up doing a --reset to /set/ the theme since it hasn't been set yet
<ogra> slangasek, you mean you understood what i said or do you mean you got an idea why it is that way ?
<ogra> ah
<slangasek> so there's a race condition wrt package configure order in the livefs build
<ogra> funny that it only shows up on imx51 ... the buildd for dove and imx is identical
<persia> Well, except that they are different runs through livecd-rootfs.
<ogra> doesnt matter
<persia> (or at least I get separate reports of success/failure)
<ogra> the initramfs is created at the same point for both
<slangasek> no, it's created whenever update-initramfs happens to trigger
<persia> No.  It's created at the same relative point.  Race conditions tend to depend on actual points, rather than relative points.
<ogra> yes, relative point indeed
<pitti> asac: I should still have it in my backup; I'll try again later
<asac> k
<slangasek> ogra: ok, fix committed
 * ogra hugs slangasek 
<ogra> thanks a lot for listening to my babbling :)
<slangasek> :)
<ttx> pitti: Please see https://bugs.launchpad.net/ubuntu/+source/jetty/+bug/418836/comments/6 -- I'm trying to dump the ubuntu-only jetty6 package and replace it by the now-updated jetty package -- let me know if I need to duplicate the MIR of if the old one is enough (same code).
<ubottu> Ubuntu bug 418836 in jetty6 "MIR jetty6" [Undecided,Fix released]
<tkamppeter> pitti, hi
<pitti> ttx: that sounds fine; just ping the MIR bug, so that we have a reminder to do the actual promotion/demotion
<pitti> hi tkamppeter
<ttx> pitti: I opened a "jetty" task and subscribed ubuntu-mir to it... that should make it appear on your radar
<pitti> right, thanks
<tkamppeter> pitti, it is about an SRU for CUPS, intended fixes are for the following bugs: https://bugs.edge.launchpad.net/ubuntu/karmic/+source/cups
<tkamppeter> pitti: bug 407344, bug 487902, and bug 508731.
<ubottu> Launchpad bug 407344 in cups "pdf printing on karmic fails: pdftopdf crashed on signal 11" [Undecided,In progress] https://launchpad.net/bugs/407344
<ubottu> Launchpad bug 487902 in cups "cups 1.4.1 in ubuntu 9.10 defaults to duplex on everything. Setting manually to simplex does not fix." [Undecided,Confirmed] https://launchpad.net/bugs/487902
<ubottu> Launchpad bug 508731 in cups "pdftopdf consumes too much RAM" [Undecided,Fix committed] https://launchpad.net/bugs/508731
<tkamppeter> The first two are already fixed in the CUPS package of Lucid, the last one is already fixed on the BZR, there I want to ask you to upload the CUPS package into Debian and Lucid to make the start for the SRU.
<tkamppeter> pitti ^^
<pitti> tkamppeter: you can prepare the SRU independently; if the change is in bzr, that's good enough for a -proposed upload
<pitti> tkamppeter: but yes, I'll upload it to Debian soon, too; thanks!
<tkamppeter> pitti, is the a BZR repo with already queues changes for a CUPS SRU, or should I simply make a debdiff based on the l;ast update, cups 1.4.1-5ubuntu2.1?
<pitti> tkamppeter: there is no karmic bzr branch right now; if you prefer having one, feel free to create one; otherwise, just prepare the package and upload
<pitti> asac: hm, firefox 3.6 has non-antialiased fonts; is that just me?
<tkamppeter> OK, so I will simply prepare the package and upload it.
<asac> pitti: https://bugzilla.mozilla.org/show_bug.cgi?id=541319
<ubottu> Mozilla bug 541319 in Graphics "Poor subpixel font rendering compared to rest of system in FF3.6 on Ubuntu" [Normal,New]
<asac> regression when using in-source cairo rather than system-cairo
<pitti> asac: ah, thanks
<tkamppeter> pitti, were debdiffs between releases removed from Launchpad?
<asac> tkamppeter: you have to go to the +changelog page
<pitti> tkamppeter: perhaps; but you can just use bzr diff -c revno to extract the patches
<asac> like https://edge.launchpad.net/ubuntu/+source/uboot-imx/+changelog
<asac> (not sure if that was the question)
<tkamppeter> Thanks, asac and pitti
<slangasek> tseliot: do you have a contact address handy for plymouth upstream, then?
<slangasek> tseliot: btw, if you want a fun plymouth bug to work on, bug #509487 is nice
<ubottu> Launchpad bug 509487 in cryptsetup "[lucid] plymouth in initramfs doesn't know to chroot() when init does, can't load files from disk" [High,Triaged] https://launchpad.net/bugs/509487
<tseliot> slangasek: usually I bug them in #plymouth
<slangasek> ok
<tseliot> slangasek: I will have to implement plymouth's new look therefore I guess I'll be pretty busy
<slangasek> alrighty :)
<tseliot> well, not only because of that ;)
<tseliot> and hopefully I will deal with the 16 colours problem
<slangasek> eep, good luck
<tseliot> :-)
<ogra> does anyone have an idea why i see the "$n packages can be upgraded" message twice in my motd ? http://paste.ubuntu.com/363175/ the second value is right though
<ogra> pitti, is there any flag i can set on a partition to prevent it from getting automounted ?
<pitti> ogra: on a removable device? not right now
<ogra> hmm, sad
<pitti> ogra: you could install an udev rule to disable that, of course
<pitti> but not as normal user
<ogra> well, but a udev rule would then apply to i.e. /dev/mmcblk0p2 ... what i look for is a way to just dont mount it based on a flag on the device, so if the user reformats he can actually make use of the partition
<ogra> my prob is that we re-user the installation media as a "boot floppy" on imx51 ... the first partition holds the bootloader, kernel and the like, the second one still has the vfat with the livefs
<ogra> *re-use
<ogra> so after install the second partition always gets automounted on the desktop
<pitti> ogra: the rule can match for anything -- partition types, labels, serial numbers, device names (in sysfs), etc.
<ogra> (the first one is tagged as "non-fs-data" since it only holds raw stuff)
<pitti> ogra: /lib/udev/rules.d/95-devkit-disks.rules has some examples for partitions which shouldn't be automounted (the recovery partition kind)
<ogra> hmm, so i could write a rule based on the UUID
<ogra> during install
<pitti> ogra: the partition UUID changes with a reformat, though?
<ogra> right
<ogra> i want the user to be able to use that space if he likes to
<ogra> i just dont want it to sit on the desktop as long as it carries the livefs
<ogra> i would just delete the second partition during install, the prob is that this is hard to do on a mounted livefs :)
<JanC> ogra: deleting it is no problem...  ;)
<ogra> oh ! i could just label the partition as "Recovery Partition" during creation !!
<ogra> now thats easy :)
<ogra> pitti, thanks, that helped a lot
<pitti> heh
<pitti> it's kind of abuse, but will work, yes :)
<ogra> well, effectively it *is* a recovery partition ... just flashing the initrd back into the first partition and setting the right kernel cmdline turns the SD back into install media :)
<pitti> ah, I see
<pitti> ogra: you could also set partition type 12
<pitti> (http://www.win.tue.nl/~aeb/partitions/partition_types-1.html)
 * ogra wonders if he could seel that as a feature *g* 
<pitti> but oh well
<ogra> *sell
<ogra> hrm, i guess i have to use type 12 ...
<ogra> ogra@babbage2:~$ sudo parted -s /dev/mmcblk0 name 2 "RECOVERY"
<ogra> Error: msdos disk labels do not support partition names.
<ogra> pfft ...
<pitti> ogra: oh, that's not the partition name, it's checking for the fs label
<pitti> ogra: i. e. mkdosfs -n "RECOVERY" /dev/... should work
<lamont> I wonder, cups' believes that it should SNMP everything about the printer and store that in etc (and upstream insists that state belongs in etc)...  how do I tell it that it's not allowed to use snmp..
<tkamppeter> pitti, Karmic SRU for bug 407344, bug 487902, and bug 508731 is uploaded now, waiting for approval. Bug reports are prepared for the SRU.
<ubottu> Launchpad bug 407344 in cups "pdf printing on karmic fails: pdftopdf crashed on signal 11" [Undecided,Fix committed] https://launchpad.net/bugs/407344
<ubottu> Launchpad bug 487902 in cups "cups 1.4.1 in ubuntu 9.10 defaults to duplex on everything. Setting manually to simplex does not fix." [Undecided,Fix committed] https://launchpad.net/bugs/487902
<ubottu> Launchpad bug 508731 in cups "pdftopdf consumes too much RAM" [Undecided,Fix committed] https://launchpad.net/bugs/508731
<lamont> heh.  I guess I could tell apparmor to not let cups write to /etc/cups/printers.conf...  seems like overkill though
<pitti> tkamppeter: thanks
<ogra> pitti, ah, thanks
<ogra> i thought thats what the parted name command sets
<ogra> yep, that worked
<Riddell> asac: must say I'm impressed by your efforts in the chromium debian/copyright file
<Riddell> asac: looking at the ones in copyright.problems the one which stands out is src/net/disk_cache/hash.cc which has just been copied and pasted from a web page against the copying licence
<asac> Riddell: thanks.... finally someone giving back after all the pain i suffered
<asac> Riddell: let me check after the meeting (in 30min)
<Riddell> asac: inface there is a licence there http://www.azillionmonkeys.com/qed/weblicense.html which says "The content may be used for commercial purposes." so that's a no go
<Riddell> infact
<asac> The content may be used for commercial purposes.
<asac> you mean: "may not be used" ?
<Riddell> asac: hmm, this page is horrible to read
<asac> yeah
<asac> Riddell: which one is it?
<Riddell> but it does say at the bottom "source code shown on my website can be used freely under the derivative license, (and may be distributed under a public domain license, whether compiled into another program or not, for example)"
<Riddell> so that should be fine
<asac> "Paul Hsieh derivative license" or "Paul Hsieh exposition license
<asac> "
<asac> heh
<asac> man
<Riddell> asac: I think that web page should be added to the licences directory and then I'm fine with it
 * ogra never understood why people have to invent their own licenses ... as if there werent enough
<asac> Riddell: sure. anything else?
<Riddell> asac: don't think so, the other files in copyright.problems seem to have a pointer to LICENCE or be trivial or otherwise part of code with a clear licence
<asac> right. can you approve it and i reupload it with the license, or will you be available if i reupload with the license added in ~1h ?
<Riddell> asac: I rejected, please reupload and ping me to approve
<asac> will do
<asac> thanks!
<tkamppeter> pitti, about bug 493282, I plan to run a GSoC project for a compression method for PPD files (which due to the schedules of GSoC can only appear in Lucid+1), is it urgent that something has to be done on this bug for Lucid, like removing support for certain printers?
<ubottu> Launchpad bug 493282 in hplip "hplip-data ballooned by 2.5 MB in lucid" [Medium,Triaged] https://launchpad.net/bugs/493282
<pitti> tkamppeter: need to confirm with slangasek, but right now we aren't stuggling for CD space (for the first time in years.. :) )
<pitti> tkamppeter: so I'd call it a target of opportunity
<directhex> pitti, lack of cd space squeeze is down to gimp removal?
<pitti> directhex: that contributed a bit; but mainly we didn't add much since karmic, and in karmic we had some dramatic improvements
<pitti> (gnome help -> langpacks, etc.)
<asac> darn ... lost the chromium tarball :(
 * asac recreates
<ion> asac: In case youâre thinking of packaging chromium, thereâs a nightly build by fta in a PPA. Its packaging has fixes for some problems as well.
<ogra> heh
<ogra> hear hear :)
<ogra> ion, asac works with him on that :)
<kees> asac, pitti: that's https://bugs.launchpad.net/firefox/+bug/512615  I've linked to the upstream now.
<ubottu> Ubuntu bug 512615 in firefox "fonts are incorrectly rendered due to not using system cairo" [High,Triaged]
<ion> ogra: Alright :-)
<tkamppeter> pitti, OK, so for now I leave it as I planned.
<superm1> er slangasek i see that you approved ~mythbuntu/debian-cd/fix-autologin, but it hasn't actually been merged.  did you forget to do the merge at that time?
* cjwatson changed the topic of #ubuntu-devel to: Lucid Alpha 2 released | Archive: open | MoM running (but use bzr!) - Outstanding merges:http://people.ubuntuwire.com/~lucas/merges.html | 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
 * cjwatson wonders if he can delete the link to lucas' merges page from the topic now
<jelmer> cjwatson: Do you know if there is anybody still anybody relying on launchpad.net/~vcs-imports/grub/grub2 ?
<cjwatson> I'm not sure how well MoM will work in practice with v3 source packages, but it seems to produce something resembling output
<jelmer> It's been failing since november, and I'm wondering if I should convert it to a bzr-svn import.
<cjwatson> jelmer: no, upstream moved to bzr, we should convert to a mirror
<cjwatson> jelmer: https://savannah.gnu.org/bzr/?group=grub
<jelmer> cjwatson: thanks
<ScottK> cjwatson: What alternative source of merge information do we have?
<cjwatson> ScottK: I just fixed MoM
<ScottK> cjwatson: Ah.  Wonderful news.  Thank you.
<cjwatson> so merges.ubuntu.com should be useful again
<ScottK> I agree then.
<cjwatson> I'm not *entirely* sure what the results for v3 quilt packages will be, but at least it no longer crashes and they don't look totally insane
<cjwatson> I made it (a) chmod files under .pc so that everything's readable (b) ignore .pc for the purposes of merging
* cjwatson changed the topic of #ubuntu-devel to: Lucid Alpha 2 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> lucas: thanks a lot for keeping us going in the meantime!
<ScottK> cjwatson: Is the data refreshed already or do we need to wait for that?
<cjwatson> ScottK: it's refreshed, I waited for it to actually finish before mentioning it
<ScottK> Thanks.  Excellent.
<Riddell> pitti (ArneGoetje): should I accept the 50 odd new language packs in hardy-proposed?
<ogra> pitti, so asac suggested to rather invent something like UBUNTU_CASPER for the fs label and add that to the devkit recovery exception rules instead of using a RECOVERY label on the fat fs, any objection on me patching devicekit-disks like that ?
<pitti> Riddell: they aren't source-NEW, are they? unapproved, please do
<ogra> (i still think RECOVERY would be better though)
<asac> ogra: didnt we settle on 0x12?
<pitti> ogra: please don't
<ogra> asac, oh, did we ?
<pitti> ogra: please have casper or your installer ship its own rule instead
<ogra> ah, yes, thats possible too
<Riddell> pitti: yes source new
<pitti> Riddell: ah, please reject
<pitti> Riddell: weird, I thought we filter them out
<asac> ogra: yes. i thought thats where we ended up
<ogra> see -arm :)
<dholbach> ttx, didrocks, tedg: if you join #ubuntu-classroom now, I can op you and you can speak in there later on without having to pester anybody :)
<tedg> dholbach: I probably won't maintain an IRC connection that long... so that probably won't help :)
<dholbach> tedg: I'm sure we'll find somebody to let you speak ;)
<ttx> dholbach: done
<didrocks> dholbach: done :)
<dholbach> done done done :)
<didrocks> heh
<mok0> I am getting an error message from libtool that I never saw before:
<mok0> libtool: install: warning: ` blahblah.la has not been installed in /usr/lib
<mok0> The build used to work without a hitch
<dholbach> Day 2 of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in #ubuntu-classroom (on irc.freenode.net) in 17 minutes!
<asac> Riddell: i plan to add this snippet and mark hash.cc file licensed as such: http://pastebin.com/f5816512c
<asac> maybe check
<Riddell> asac: I think it needs to include the text of the derivative licence, and because that refers to the other licence it should include that
<asac> Riddell: hmm. i named it "public domain option" to avoid that
<asac> as we are going for that option afaiui
<sistpoty|work> mok0: maybe that thread has some hints: http://lists.debian.org/debian-devel/2009/08/msg00783.html
<Riddell> asac: yeahok
<Riddell> asac: that'll do then
<asac> Riddell: can i make that clearer somehow in that snippet?
<asac> or is that ok the way i titled it?
<mok0> sistpoty|work: thx
<Riddell> asac: nah that's fine
<sebner> hihu sistpoty|work :)
<asac> cool
<sistpoty|work> hi sebner
 * asac commits
<mok0> sistpoty|work: Hm, can't really see that it addresses my problem.
<sistpoty|work> mok0: got a build log with the failure?
<mok0> sistpoty|work: 2 secs, I'll run it again
<mok0> sistpoty|work: this is as much as my scrollback contained: http://paste.ubuntu.com/363299/
<mok0> sistpoty|work: at line 119 (and a few other places) it says: libtool: install: warning: remember to run `libtool --finish /usr/lib'
<mok0> sistpoty|work: but all of this is autotools generated
<mok0> ah
<sistpoty|work> aha, soname change
<sistpoty|work> mok0: saw the same thing?
<mok0> sistpoty|work: no... what did you see?
<mok0> :)
<sistpoty|work> mok0: 112 for example, ends with 2.0.5 but dh_install lists ...*.2.0.3 (l 450)
 * mok0 looks 
<mok0> sistpoty|work: thank you that must be it !!!
<sistpoty|work> mok0: no problem ;)
<pitti> Riddell, ScottK: is this known?
<pitti>   python-kde4-dev: Depends: python-qt4 but it is not going to be installed
<pitti>                    Depends: python-kde4 (< 4:4.3.2-0ubuntu4.1.1~) but it is not going to be installed
<pitti> E: Broken packages
<pitti> (just tried a jockey build again)
<ScottK> pitti: I think Riddell just uploaded a new kdebindings.
<Riddell> yes, it's still compiling
<asac> Riddell: we uploaded the new one
<asac> darn
<asac> ;)
<asac> reject please
<asac> :)
<asac> the license wasnt appended
<asac> man
<Riddell> asac: rejected
<asac> Riddell: uploaded ;)
<ogra> did you call it the "big waste of bandwith" release ? :)
<mileslane> Is there someone here who can answer grub2 related questions?
<mileslane> I installed WUBI 9.10 and then upgraded to Lucid.  Now I find that the Lucid kernels won't boot, and neither while my custom development kernels.
<mileslane> IIRC, the custom kernels give me an error saying that the kernel must be loaded first.
<arand> mileslane: this is not really a support channel, for lucid see #ubuntu+1
<mileslane> Thanks.
<mathiaz> cjwatson: hi - do you know what may wrong with bug 512632?
<ubottu> Launchpad bug 512632 in debian-installer "Network component not activated on a fully automated installation" [Undecided,New] https://launchpad.net/bugs/512632
<mathiaz> cjwatson: are there any new debconf questions that should be seeded to get the network detection triggered?
<asac> ogra: fta uploaded ... for him it takes 10 seconds ;)
<ogra> heh
<asac> or even less
<directhex> who accepted chromium-browser into the archive?
<sebner> directhex: It might have been Riddell
<ogra> directhex, was Riddell
<superm1> is it shipping a bunch of copies of libraries or is it nicely linking out to the rest of the system now then?
<directhex> superm1, the former
<directhex> superm1, which is why i've descended. LIKE A BAT
<komputes> What has happened to /proc/bus/usb/ in Lucid? I am trying to mount usb as defined here (instructions for karmic): https://help.ubuntu.com/community/VirtualBox/USB
<pitti> komputes: /proc/bus/usb has been deprecated since around dapper, I think
<superm1> did something change recently that packages that aren't on the live media but in the archive are in the apt cache on the live media?
<pitti> komputes: devices are in /dev/bus/usb
<superm1> like within the last day or so
<pitti> komputes: and /proc/bus/usb/devices is deprecated
<pitti> good night everyone
<soren> komputes: Yeah, what pitti said.
<soren> komputes: It's bee deprecated since forever, and has been removed more and more as we went along.
<soren> Finally, we've removed support for USBFS entirely, IIRC.
<soren> This shouldn't really be much of a surprise. Forcing users to jump through more and more hoops to get this to work wasn't just for fun :)
<komputes> so that said, the instructions to get a usb device working in a VM won't work
<komputes> as defined in https://help.ubuntu.com/community/VirtualBox/USB
<cody-somerville> komputes, We appreciate you taking the time to update them then :)
<cody-somerville> ;)
<komputes> cody-somerville: are you serious?
<cody-somerville> komputes, Well, I'm not going to do it. :P
<komputes> cody-somerville: I don't mean updating the docs, i mean losing the ability to use a usb device in a VM.
<soren> virtualbox needs to get its shit together, get with the programme, join the rest of us in the new millenium and update to the new way of doing things. Dapper was a loong time ago.
<ogra> komputes, whats the problem with using /dev/bus/usb instead ?
<komputes> soren: sure, I will try to let them know. what is the proper way of doing this?
<soren> ogra: It's a different layout.
<komputes> ogra: that it uses usbfs, which is apparantly depricated and no longer works in Lucid
<soren> ogra: And different interface in lots of other ways.
<soren> ogra: Oh, sorry, I misread what you said.
<ogra> right, but the single hook points still exist
<ogra> just in a different layout
<komputes> ogra: testing with /dev/bus/usb...
<ogra> komputes, if it expects a usbfs layout thst indeed might not work
<ogra> *that
<ogra> i.e. you cant just change the path
<komputes> ogra: the line in fstab is now "none /dev/bus/usb usbfs devgid=1000,devmode=664 0 0"
<ogra> thats likely not working, you just expose the other path but the layout changes are unlikely to be known by vbox
<komputes> soren: so what should I request from vbox regarding "update to the new way of doing things"? Link explaining our changes?
<cyphermox> komputes, I had been having major issues with virtualbox-ose to talk to USB devices... AFAIK there is no way to do it (I very well may be mistaken), however Sun's Virtualbox works just fine without modifying any files
<soren> komputes: I'm not sure. Tell them about this think called the kernel. :)
<komputes> cyphermox: only plue does usb support, now in lucid neither do usb support...
<komputes> soren: lol
<ogra> komputes, tell them that usbfs is deprecated since several years now and they should port to the actual handling of usb devices ...
<ogra> they need to read up on it anyway it seems :)
 * ogra goes afk now 
<komputes> ogra: ok, will do thanks
<cyphermox> I'm trying to figure out with the package 'congruity' won't get automatically imported from testing. Could it be because it's in 3.0 (quilt) format?
<komputes> soren: I think vbox has already caught up, usb works by default now, no need to fuss with fstab, will update docs
<geser> cyphermox: https://edge.launchpad.net/ubuntu/+source/congruity
<geser> looks up-to-date
<cyphermox> hmm
<cyphermox> i just did precisely that page.
<cyphermox> geser, sorry! I meant 'ethos'
<cyphermox> and it's not even 3.0, i'm mixing things up
<geser> I assume that syncing new packages (packages not in Ubuntu) wasn't run since 14th Jan (it's not part of the normal auto-sync)
<cyphermox> ah
<cyphermox> geser, how can I know this for sure? also, does this mean I should open a bug about this package?
<geser> unfortunately there isn't any timestamp file to check when it was done last, so you either file a bug, hope that it's done again soon (or ask an archive admin)
<ivanka> asac hi
<cyphermox> thanks
<douglasawh-work> if I'm going to maintain a package which the dependencies are not in the main repos, does that mean I'll need to set up a PPA for said package?
<geser> either get all packages into the main repo or all packages into your PPA
<geser> packages in your PPA can use packages from the main repo but not vice versa
<highvoltage> Unpacking replacement libinfinity-0.4-0 takes a long time :)
<douglasawh-work> geser: cool, getting the versions of mono that would be needed in the repos simply isn't going to happen.  Setting up a PPA should be an interesting little project. :)
<geser> douglasawh-work: just curious: which version of mono do you need?
<douglasawh-work> geser: well, it's going to change every release
<directhex> someone's already done some work on that front. was it surfzoid? i think it started with an s. anyway, i make no comment regarding the quality of those
<douglasawh-work> which is the real problem
<douglasawh-work> I can't depend on being able to get it in, even if it happens once
<directhex> douglasawh-work, it would be advantageous to make your plan clearer
<douglasawh-work> directhex geser, the details aren't worked out yet, so I can't give too many details. I spoke with a developer of the project this morning and he discussed problems they've had in the past
<douglasawh-work> I said I'd be willing to maintain it for ubuntu, but that's about where we are right now. There are a ton of dependencies.  They run their own repo right now. Not entirely sure a PPA would be better, but I'm looking into it
<directhex> douglasawh-work, right. but it's worth bouncing ideas off the current mono maintainers, surely? they have years of experience in this stuff
<douglasawh-work> directhex: indeed.  I'll do that.  I'll get all the versioning stuff worked out first.  I just wanted some baseline knowledge about that structure.  I also don't know how far back we'll want to go, so there's probably not a lot of chance of getting the latest mono in, say, 8.04
<directhex> douglasawh-work, indeed not. mono backports are excluded from the ubuntu-backports repository, due to regression risk on core frameworks. but packages may well already exist on a ppa
<mathiaz> slangasek: hi - I think all the relevant test cases have been covered for 8.04.4 -server isos
<directhex> douglasawh-work, contact details for the current mono maintainers are at http://mono-project.com/DistroPackages/Ubuntu#Further_Links including IRC channel
<douglasawh-work> directhex: thanks a ton!
<slangasek> superm1: it's been merged, just not pulled into the production directory
<superm1> slangasek, ah, just a big black box to me, so i wasn't sure :)
<mvo> ev: the GtkSpinner - looks very sexy, nice work!
<slangasek> pitti: true, we're not struggling for CD space, but we shouldn't be complacent... :)  For my part, I think this decision to ship translations of all the text strings in each ppd should be revisited
<slangasek> mathiaz: RAID1 isn't relevant?
<mathiaz> slangasek: there wasn't any RAID1 use cases at the time of Hardy IIRC
<mathiaz> slangasek: hm - RAID1 *test* cases
<mvo> ev: I will use it in software-center too, I have a self-made spinner there currently
<dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
<ubottu> Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,Confirmed]
<dupondje> can somebody check it out ? I added a debdiff that fixes this issue
<slangasek> mathiaz: right, the database backs you up, that test case was added for jaunty.
<mvo> Riddell: a friend of mine just asked me about bug #510853 - I added a patch that might help (just mentioning it to get it onto someones radar)
<ubottu> Launchpad bug 510853 in ubiquity "Installer crashed" [Undecided,New] https://launchpad.net/bugs/510853
<Riddell> mvo: thanks, I'll poke our ubiquity man
<mvo> thanks Riddell!
<dupondje> somebody awake that can sponsor a aptitude patch ?
<anon^_^> Hi, hoping for some assistance, not having a lot of luck so far..
<anon^_^> I'm observing an issue I believe exists with gnome-power-manager
<anon^_^> trying to identify the correct process for a bug report
<anon^_^> on Karmic, when system is left to idle, no movement from mouse, no input from keyboard
<anon^_^> after a period of time, an applet appears in tasktray area
<anon^_^> http://img710.imageshack.us/img710/2503/whatisthis3.png
<anon^_^> if mouse is moved, or a key is pressed on keyboard, this applet/icon will disappear from the tasktray area
<anon^_^> behavior appears to be tied to some sort of idle timer
<anon^_^> i had to use a camera to take this image, pressing print screen key would result in input from keyboard and applet would disappear
<RAOF> anon^_^: I know what you're looking at; it's a gnome-power-manager notification that the idle timer needs to be fixed in X, IIRC.
<RAOF> anon^_^: It would be good if you could reproduce that in Lucid; if it's fixed already in Lucid there's not much to do.
<anon^_^> running Karmic unfortunately and don't have a free system to spare
<anon^_^> =/
<anon^_^> I take it a patch/backport isn't expected for Karmic then?
<ion> Perhaps look at /usr/share/icons in case you find the icon with a meaningful name.
<RAOF> It's probably too minor an issue for a Karmic stable-release-update; it doesn't actually break anything much, so the danger in trying to fix it probably outweighs the benefits of fixing it.
<anon^_^> know of an existing bugreport so I can add my 2 cents?
<anon^_^> hehe
<anon^_^> seen some similar reports under xorg but none quite match up
<RAOF> I don't offhand, no.  Sorry.
<anon^_^> ok, appreciate your assistance
<ccheney> hey what happened to the daily bootcharts after jan 13?
<ccheney> did it move somewhere else?
<seb128_> ccheney, it broke while Keybuk was traveling and he's on vac this week
<ccheney> oh ok
<verb3k> why ship x264 but still not build it inside ffmpeg?
#ubuntu-devel 2010-01-27
<tlp> Hi. Apparently my Lucid filesystem contains inconsistencies and requires me to run fsck manually. The problem is, I can't ssh in and I have no option for a command prompt. Is there any way to get one, or do I have to use a LiveCD?
<tlp> I've got Plymouth, apparently.
<Sarvatt> holding shift while booting will bring up the grub menu where you can pick recovery
<tlp> cool. thanks
<tlp> heh. fsck is caught in an endless loop. The process dies because it wants me to run it manually, and then Ubuntu runs the command again. So no command prompt in recovery mode either.
<slangasek> for which filesystem?
<slangasek> what's supposed to happen is that mountall exits with an error, triggering the mountall-shell job
<tlp>  /dev/sda1
<tlp> that's the behavior I expect, yeah
<slangasek> I mean, what's the mountpoint
<tlp> I think it
<slangasek> is this the root filesystem?
<tlp> er, it's /
<tlp> yes
<slangasek> so as a workaround, I would suggest setting init=/bin/sh and manually running the fsck
<slangasek> and then rebooting
<tlp> ok. seems like something worthy of a bug report
<slangasek> after you've done that, please file a bug on mountall, yes
<ion> tlp: Did i get this right, you have Plymouth, but it doesnât ask (graphically, that is, along with the Ubuntu logo) whether to fix the filesystem problems?
<tlp> I may have been confused, because I wasn't sure what bheavior to expect, but I'll reboot now to confirm that's true.
<tlp> when I got home, the Ubuntu boot logo was on the screen and nothing else. I imagine there was a power outage or something and it stalled on fsck.
<ion> Things not quite working well when Plymouth isnât available is a known problem and will be fixed for Lucid. I was under the impression things like what youâre encountering should work by now when Plymouth is available. I havenât tested that myself, though.
<tlp> oh. No, Plymouth doesn't seem to do anything special
<slangasek> in cases where interaction is needed, mountall is supposed to exit, triggering mountall-shell, triggering plymouth to exit
<tlp> I see what looks like a loading bar briefly, which then disappears. If I press escape to make Plymouth die, I see the fsck error
<slangasek> chances are you'd get better output if text display wasn't broken in the version of plymouth in the archive
<ion> Looking at the source, the current version of mountall should tell Plymouth to say â%s filesystem has errors [SIFM]â and if the user hits F(ix), it should run fsck again with mnt->fsck_fix = TRUE.
<slangasek> that'll be fixed soon, but I wanted to give Keybnz a chance to review it before uploading
<ion> But yeah, as i said, i havenât actually tried any situation where mountall asks plymouth to output text.
<slangasek> ion: are you interested in building plymouth out of bzr and putting it through its paces, to see whether my changes are OMGbroken?
<slangasek> I'm not sure Keybuk will have a chance to review before next week, and I don't really want to upload straight to the archive without getting other eyeballs on it
<ion> slangasek: Iâll do that today, after some sleep.
<slangasek> ok :)
<ion> tlp: So, assuming Plymouth text rendering is broken, perhaps try hitting F blindly instead of escape and see if it magically runs fsck with the right flags to fix the filesystem. :-)
<tlp> k, will do
<slangasek> zul: finished my analysis of nmbd upstart conversion - bug #513035 is a blocker
<ubottu> Launchpad bug 513035 in upstart "no support for negation in env matches of job start/stop conditions" [Undecided,New] https://launchpad.net/bugs/513035
<tlp> ion: nope, doesn't seem to do anything
<ion> tlp: Anyway, booting with init=/sbin/sulogin (or init=/bin/sh for a works-for-sure but less friendly shell) and running fsck -C0 -y /dev/<device> manually should work.
<tlp> yeah, I think I can fix it. Just wanted to test your theory; thanks for the help everyone. Wasn't sure where to take this question/report, since I know this isn't a support channel.
<slangasek> tlp: I'm afraid we're well into "development" territory here, so it's clearly on-topic :)
<tlp> that was my rationale :p
<zul> slangasek: cool...interesting
<slangasek> zul: that's actually the /lesser/ blocker; the /greater/ blocker is the one I allude to in the description, that 'start on event1 and net-device-up' will cause 'ifup' to hang in some cases... I need to dig into eucalyptus to make a solid case for making that event asynchronous
<zul> ah
<ion> slangasek: Unless i remember incorrectly, Keybuk has already said the blocking behavior was a mistake that should be fixed. :-)
<slangasek> ion: the blocking behavior of /etc/network/if-up.d/upstart?   that's not what he told me last
<ion> Hm, ok, i must have mixed that up with something sadmac@#upstart said.
<slangasek> well, he may have told you something different, perhaps based on new information he didn't have when he talked to me :)
<ion> I think itâs most probable i remembered incorrectly.
<ion> Oh, sorry, i misread your initial line. I must be tired. :-) I missed the part about ifup blocking and thought you were talking about event1 blocking until net-device-up just because $randomjob has that âstart onâ stanza.
<slangasek> well - fixing that would make it irrelevant whether ifup is blocking or non-blocking, but that's the *hard* bug that we know's not being fixed in lucid
<ion> As for ifup blocking, hmm. That *is* a problematic case indeed.
<InvaderZim> help. i patched uvcvideo module for a webcam to work, and it worked, but the module was at /extra/ and the old one at the kernel tree. so after rebooting it stopped working. dmesg now gives errors typical of a module requiring a newer kernel... now i cant revert back to the old error message before patching (which was just one line of error)... I think depmod or someth has cached the problematic uvcvideo module symbols, and doesnt matter which driver 
<InvaderZim> no one?
<tlp> slangasek: Looks like someone beat me to it with bug #501801
<ubottu> Launchpad bug 501801 in mountall "Infinite-loops in fsck when booting with damaged /" [Undecided,Fix released] https://launchpad.net/bugs/501801
<pitti> Good morning
<pitti> asac: argh, now firefox does it again
<pitti> it worked yesterday, hrm
<pitti> asac: hacking extensions.{ini,rdf} is a bit inconsistent, but I think it's either the  langpacks (which are currently broken anyway and need to be updated to 3.6) or vimperator
<pitti> asac: ok, got it again, and I didn't have vimperator installed this time
 * pitti blames the outdated langpacks
<dholbach> good morning
 * pitti hugs dholbach
 * dholbach hugs pitti back
* spm changed the topic of #ubuntu-devel to: LP in R/O 09:00-11:30 UTC | Lucid Alpha 2 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<lifeless> cjwatson: ~cjwatson/debian-installer/main/.bzr is deprecated ...
<lifeless> cjwatson: can I convince you to upgrade it ? :)
<tseliot> pitti: my upload of ia32libs got stuck at 606673k/606674k for the 2nd time now (and it takes hours for me to upload it). Any ideas of what's going on?
<pitti> tseliot: LP just went down
<pitti> for upgrade
<pitti> argh, you're doing that at home? poor you
<pitti> tseliot: I did ia32-libs updates on a porter box (ronne) in the DC
<tseliot> pitti: ok, but it failed last night too
<pitti> build binaries there, and scp them to my box for testing
<pitti> tseliot: no idea about last night, though
<tseliot> pitti: can you explain me how I can do that (in private) please?
<pitti> tseliot: perhaps you can rsync it against the current versino to chinstrap and dput from there?
<asac> pitti: do you have xul-ext-greasemonkey?
<pitti> asac: not right now; that one might actually have been the culprit indeed
<seb128> re
<asac> pitti: i can reproduce ffox not starting twice with that
<asac> and seb too ;)
<seb128> une daily chart is 17.5 seconds
<seb128> asac, do you know if somebody opened a bug btw?
 * asac hopes its just greasmonkey and not system extensions in general
<pitti> seb128: uh, with 2.6.32-11?
<pitti> I can't get it below 20 with that kernel
<seb128> pitti, no, still -10
<pitti> ah
<seb128> I don't know how you get linux upgraded
<pitti> the one with broken suspend
<seb128> I use update-manager daily
<pitti> I reinstalled yesterday
<pitti> but usually I'm just using apt-get dist-upgrade
<pitti> since jaunty, update-manager doesn't appear any more in the tray, so that's faster
<seb128> urg
<seb128> I though we were on #u-d ;-)
<pitti> seb128: we are..
<pitti> the other -d?
<seb128> yeah ;-)
<pitti> yay, upload works again
<pitti> tseliot: ^ FYI
<tseliot> pitti: \o/
<tseliot> pitti: it only took 16 seconds to upload ia32-libs (it took ~6 hours here...)
<pitti> yay phat pipes
* mthaddon changed the topic of #ubuntu-devel to: Lucid Alpha 2 released | Archive: open | MoM running (but use bzr!) | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-karmic | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<geser> could an archive-admin please remove the old texlive-base-bin package (it's in NBS now)? texlive-binaries provides texlive-base-bin and all packages on http://people.canonical.com/~ubuntu-archive/NBS/texlive-base-bin have an unversioned dependency on texlive-base-bin so they continue to be installable with texlive-binaries. the only exception is jadetex but ther is bug #511399 waiting on sponsoring
<ubottu> Launchpad bug 511399 in jadetex "Update versioned build-dependency from texlive-base-bin to texlive-binaries" [Undecided,New] https://launchpad.net/bugs/511399
<geser> to get it fixed.
<geser> this should get some FTBFS resolved caused by the TeXLive update as the buildds try to install the old (now uninstallable) texlive-base-bin instead of texlive-binaries and complain about it
<directhex> Riddell, was it you who OK'd chromium-browser?
<Riddell> directhex: yes
<directhex> Riddell, how does one go about getting an exception to the usual "no bundled $everything please" rules that are widely understood to govern getting things accepted?
<Riddell> directhex: there is no such rule for getting into the archive
<Riddell> you're probably thinking of main inclusion requests
<Riddell> which aren't my area
<directhex> Riddell, so an upload with 40 meg of bundled source wouldn't get rejected on principle?
<directhex> assuming a valid debian/copyright of course
<asac> directhex: there we want to provide a great experience. software like chromium firefox without bundled third party wouldnt be able to exist given how the system libs progress/regress in different ubuntu releases
<Riddell> directhex: as an archive admin I care about licencing, namespace pollution and making sure the package actually has some source code and was ment to be uploaded, how it builds it's interesting.  it will cause problems for the MIR though if the security guys have anything to do with it
<directhex> Riddell, roger. i'll take that as a green light
<apw> pitti, where we have blueprints with no work items, what do you think of faking an item on the owner for the blueprint of 'specifiy initial tasks' or similar
<apw> such that we end up with something in there
<pitti> apw: usually you should get a mail with "this bp has no WIs"
<pitti> but sure, a fake WI works, too
<pitti> I need to leave for ~ 1.5 hours
<apw> ack
<rah> is changing the default search engine of redistributed firefox binaries permitted by the firefox license?
<directhex> rah, it wouldn't be Free Software if it wasn't permitted
<rah> directhex: you mean this software which isn't distributed by Debian, wouldn't be free software? :)
<directhex> rah, trademarks & software licensing are distinct issues. the former drove the decision to produce an unbranded version in debian
<rah> directhex: both are also cognate issues; they are both issues of intellectual property licensing
<rah> directhex: but none of this addresses the issue of whether changing the default search engine in redistributed firefox binaries is permitted by the mozilla foundation?
<directhex> rah, "intellectual property" is a made-up term designed to confuse different sections of law. but, regardless, the software license for firefox absolutely cannot say "this section is invariant, i.e. you may not change it" without it becoming non-free
<rah> the idea of the default search engine being some "section" of the software seems odd
<rah> it seems more odd than considering the firefox branding images to be a "section" of the software
<directhex> see also: http://popey.com/blog/2010/01/26/yahoobuntu/#comment-1905
<directhex> the default search engine is absolutely a question of source. a Yahoo search provider is already upstream, in mozilla/browser/locales/en-US/searchplugins/yahoo.xml
<directhex> so it's changing 1 line to make that one the default rather than google.xml
<apw> pitti, the update process for the work-items db, how does that work, do you just write over the original db?  I seem to be getting partial db's at cirtain times of the hour
<apw> pitti, it also appears to be completing between :40 and :50 now when it used to be done between :10 and :20 normally
<Riddell> ev: for kubuntu netbook we need to enable the netbook workspace at bootup of the live environment which I know how to do in casper and also for the installed environment, how do I do that?
<ev> Riddell: one option would be to put a script to do it in /usr/lib/ubiquity/target-config
<Riddell> ev: that looks like just the thing, thanks
<ev> sure thing
<d1b> ok what's with the move to yahoo?
<soren> d1b: Don't know. What /is/ with it?
<d1b> https://lists.ubuntu.com/archives/ubuntu-devel/2010-January/030065.html
<soren> Yes...
<d1b> seems like a short sighted move.
<soren> d1b: Rick explains what and why pretty well, I think.
<d1b> soren: i don't.
<soren> Hence my question:
<soren> 14:44:10 < soren> d1b: Don't know. What /is/ with it?
<d1b> soren: well this is funding microsoft
<d1b> which contributes to bug 1
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<ogra> d1b, what makes you think that ?
<d1b> ogra: yahoo uses bing for its search engine now
<d1b> that costs yahoo and microsoft gets paid for it
<ogra> d1b, wrong
<d1b> ogra: yahoo pays ms
 * soren has a difficult time getting worked up about the whole one proprietary web service by default vs. another proprietary web service by default
<ogra> d1b, you should inform yourself before ranting :)
<d1b> ogra: i have
<ogra> d1b, they share the revenue from ads
<soren> ogra: Yahoo search engine is backed by Bing. Since around 6 months ago.
<ogra> soren, thats right
<ogra> soren, i just say the assumption that yahoo pays for it is wrong
<d1b> ogra: ok fine they don't pay ms, but ms still profits
<soren> ogra: Ah.
<ari-tczew> soren: have you got time for sponsoring?
<ari-tczew> note: small merges
<soren> ari-tczew: Depends on what it is. I've got a pretty hefty fever today, I'm not exactly clearheaded, so if you can find someone else... :)
<ogra> d1b, well, effectively yahoo pays for ubuntu development through the mentioned agreement in the mail, i wouldnt say that raises MS market share in any way
<ogra> i'D rather say it lowers :)
<ari-tczew> soren, I'm looking for any sponsor too long
<soren> ari-tczew: For which package?
<d1b> http://www.chuckfrain.net/blog/2010/01/26/forced-changes-in-my-browser/
<highvoltage> yes I'm with soren on this one. it's just one proprietary search engine for another. big deal.
<ari-tczew> soren, bug 503136
<ubottu> Launchpad bug 503136 in dmraid "Merge dmraid 1.0.0.rc16-2 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/503136
<highvoltage> (yahoo's home page is way more sleezy though, showing me ads to work from home and make lots of money)
<soren> ari-tczew: I have /no/ clue about dmraid.
<d1b> highvoltage: yes but ubuntu is then funding ms.
<ari-tczew> soren, maybe this? bug 499671
<ogra> by earning money from ms ?
<ubottu> Launchpad bug 499671 in texinfo "Merge 4.13a.dfsg.1-5 (main) from Debian testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/499671
<soren> d1b: Microsoft pays Yahoo. Yahoo pays Canonical.
<ogra> how is that funding
<ogra> its lowering their income ...
<soren> ari-tczew: sorry, I'm not your man today. I'm trying to focus on super simple things I know all about already. :)
<lool> Does someone know which kernel configs upstart needs?
<lool> I'm trying to figure out why I get Event failed errors when using a qemu armel versatile kernel
<d1b> ogra: microsoft pays yahoo sure, by using yahoo microsoft profits.
<ari-tczew> thanks for all sponsor for main. I always know that you are very helpful team.
<micahg> d1b:  a little more funding for MS won't make them any bigger...a little more funding for Canonical probably will, also IMHO, bug 1 is to get MS out of first place, not crush them entirely
<ubottu> https://bugs.launchpad.net/ubuntu/+bug/1 (Timeout)
<Riddell> ev: committed to casper, could you do a quick check?  bash is so easy to make mistakes in
<ogra> in any case thats a totally offtopic discussion for this channel :)
<lool> Riddell: You mean busybox?  ;)
<d1b> next up on the mailing list, ubuntu to use the windows kernel, "we were paid for it"
<Riddell> lool: mm, even more easy to make mistakes in
<d1b> erh sorry, it just seems that way to me atm.
<d1b> i know ubuntu needs revenue.
<d1b> just if it was handled better (gui that suggests yahoo and has other options)
<ion> pitti: Great work with desktop-lucid-startup-speed, btw.
<lool> Riddell: You need to +x the scripts
<Riddell> lool: thanks, fixed
<lifeless> pitti: if I have a bunch of tracebacks, do you know of somthing that will group them?
<ev> Riddell: did you commit to lp:ubuntu/casper?
<pitti> slangasek: tkamppeter mentioned that GSoC project, but it won't land in time for lucid
<pitti> apw: update process> it's one big transaction, so most of the time it's just writing its journal
<pitti> apw: between 40 and 50? that rather sounds like the one on macaroni? people updates at :05, as before
<pitti> ion: \o/
<apw> pitti, hrm ... ok sounds like i am getting my data from the wrong place
<pitti> lifeless: if they get submitted as apport-generated bugs, they will be auto-duplicated
<tseliot> pitti: can I upload jockey after I (successfully) test it or shall I wait?
<ev> Riddell: context> 16:51 <cjwatson> superm1,pitti,ev: please note for future commits that casper is in lp:ubuntu/casper now rather than lp:caspper
<pitti> lifeless: in theory that functionality is available in python-apport as well, but it's not a two-liner to set it up; do you need this locally for something?
<pitti> tseliot: go ahead; please just ensure that you commit the changes to trunk, and merge from that
<Riddell> ev: hmm, I did not
<pitti> tseliot: like, the do_blacklist change, etc.
<tseliot> pitti: ah, ok, I won't apply the changes directly to ubuntu-core-dev. The handlers will still need to be updated manually I guess
<tseliot> as the ones in trunk are older than the ones in ubuntu-core-dev
<Riddell> ev: merged, how confusing
<apw> pitti, however i just updated and got the same partial update i get from the macaroni one
<apw> i bet i get a fuller update at 20 past
<pitti> apw: right, people is currently running
<pitti> apw: just weird that it already commits stuff
<pitti> it's one big transaction
<apw> pitti, is this thing updateing these db's in place, ie direct to lucid.db, and not to lucid.db.new then renaming
<pitti> apw: yes, in-place
<pitti> sqlite handles locking itself usually
<apw> right but thats no use if one is copying the db over wget
<pitti> apw: grabbing the people db at :30 should work fine; it's usually taking until :15 or so
<apw> and the db is appearing empty
<ev> Riddell: looks good
<apw> it might be nice to just have; cp lucid.db lucid.db.tmp; mv lucid.db.tmp lucid.db.stable
<apw> and then people who need to do what i am can just take .stable and get a complete clean db always at any time
<Riddell> ev: groovy, I'll upload
<apw> and not have to know when you are updating
<lifeless> pitti: yeah, we're categorising udd package import failures
<lifeless> pitti: e.g. http://package-import.ubuntu.com/failures/wine
<pitti> lifeless: python -c 'import apport.crashdb; help(apport.crashdb)' describes the CrashDatabase of apport
<lifeless> pitti: thanks
<pitti> lifeless: in essence, you init it with a .db filename (sqlite), and keep calling check_duplicate()
<lifeless> pitti: does it really need a db ?
<pitti> lifeless: well, you need to store the "known" master signatures somewhere
<pitti> lifeless: the sqlite usage is pretty well woven into this
<pitti> lifeless: the downside is that it is designed to work with a "crash database"
<pitti> lifeless: apport has an in-memory one, so you don't need Launchpad
<pitti> lifeless: if you neither want a sqlite db, then perhaps it's better to just reimplement it
<pitti> it's not rocket science, after all
<lifeless> pitti: :)
<lifeless> I shall poke at it - thanks!
<pitti> lifeless: look at /usr/share/pyshared/apport/report.py, def crash_signature()
<apw> pitti, so what do you think about making a stable copy of the db available at the end of the run
<pitti> lifeless: that turns a traceback (or signal crash, etc.) into a "primary key" which the retracer uses for identifying dupes
<pitti> lifeless: so you need to store those signatures somewhere (that's the sqlite db that I mentioned), and for every incoming exception you calculate the signature and look it up
<lifeless> pitti: does your code do fuzzy matching?
<lifeless> I guess you mask our variables while making the key
<lifeless> s/our/out/
<pitti> lifeless: no, it just chains the top 5 function names and the exception name
<pitti> which seems to work well for "general" crashes
<pitti> i. e. ignoring arguments
<pitti> but after that, only strict matching
<lifeless> pitti: thanks a lot; we may not end up doing anything but thats a really good pointer.
<BenC> I'm loving this new enforcement of being identified to be in certain channel
<lool> Ok so my upstart issue might be that udev wasn't starting due to lack of inotify support
<lool> What I was seeing was the "mounted /dev" event being generated but then nothing at all and a /core from /sbin/init but init still running
<micahg> pitti: do you remember on hardy if you can use apport for packages from PPAs?
<lool> Bah my kernel is 2.6.30 and I need 2.6.32 for devtmpfs
<pitti> micahg: independently of the release, apport generally disallows filing bugs for PPA packages
<pitti> micahg: some package hooks (like ubuntuone) overwrite that, though
<micahg> pitti: so I can disable it in the firefox hook if I want to get bugs?
<pitti> micahg: yes; I don't think that worked in hardy yet, though
<micahg> pitti: ok, it'll be useful for future and current testing in Karmic and up though
<pitti> micahg: ISTR that asac already asked me about that; not sure, perhaps the current daily PPAs already have that
<micahg> it doesn't seem to work for the firefox 3.6 package we made, but I can look at ubuntuone as an example
<micahg> thanks pitti
<asac> pitti: we are concerned about hardy-jaunty too ...
<asac> or will hardy just always work?
 * ogra is mr superbrave and runs update-manager -d now
<mvo> ogra: ohhh, http://people.ubuntu.com/~mvo/automatic-upgrade-testing/current/
 * ogra looks
<mvo> ogra: it will probably go ok, its mostly file overwrite issues that are left and the gui upgrade runs with --force-overwrite
<ogra> looks ok i only have ubuntu
<ogra> we'll see
<ogra> if i encounter probs i'll moan loudly :)
<zul> pitti: ping
<pitti> pong
<zul> pitti: for the psycopg2 MIR i split of the testsuite into a seperate package like when did for puppet
<pitti> zul: oh, why that?
<zul> so it can be integrated in to the qa-regression testsuite
<pitti> I thought it was just part of the source
<pitti> ah, I see
<pitti> nice
<zul> pitti: so I think that one can be promoted now if you agree
<ogra> pitti, hmm, i see a workitem for a spec of mine on the tracker listed twice (one time its done the other its todo)
<ogra> http://people.canonical.com/~pitti/workitems/canonical-mobile.html "Move uboot-imx to main to use it from the image build machines"
<pitti> ogra: weird; can you please file a bug about it?
<ogra> err, sorry, todo and postponed
<ogra> will do, whats the product ?
<pitti> ogra: ah, nevermind
<pitti> ogra: there _are_ two work items on https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-lucid-imx51-debian-cd-to-uboot
 * ogra checks 
<pitti> one as todo, one as postponed
<ogra> there shouldnt be
<pitti> that's a side effect of duplicating WIs
<ogra> oh A3 vs overall
<pitti> they won't dupe on teh per-milestone chart, but of course they will on the "entire release" one
<ogra> yeah
<ogra> sorry for the noise
<pitti> np :)
<randomaction> Do I need to file a sync request for a package recently added to Debian (now in testing)? It's not in Ubuntu yet.
 * ogra really hates the CSS layout of the spec pages ... the whiteboard became totally unreadable with that column setting
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 starting in #ubuntu-classroom (on irc.freenode.net) in 16 minutes
<pitti> randomaction: those regularly get imported, so now you don't need to yet
<randomaction> pitti: ok thank you
<dholbach> kirkland, DktrKranz: if you hop into #ubuntu-classroom now, I'll op you
<kirkland> dholbach: done
<dholbach> kirkland: thanks
<lool> I dont get why "initctl emit mounted MOUNTPOINT=/dev" fails; I reduced the script to an echo and a MAKEDEV fd
<ogra> seb128, could bug 512959 be caused by the fact that libgtk2.0-common was upgraded on armel but libgtk2.0 itself wasnt yet due to ftbfs (it just built now buit isnt published yet)
<ubottu> Launchpad bug 512959 in nautilus "nautilus assert failure: *** stack smashing detected ***: nautilus terminated" [Medium,Incomplete] https://launchpad.net/bugs/512959
<seb128> ogra, no
<seb128> ogra, libgtk2.0-common is empty basically
<seb128> ogra, it has translations on debian but those move to langpacks
<ogra> oh, k
<seb128> ogra, and some gtkrc which didn't change for years
<ogra> i just didnt see the issue yet and doing a dist-upgrade doesnt update nautilus
<ogra> http://paste.ubuntu.com/363941/ is all i get
<ogra> gnome-session was ftbfs as well i had to give it back today
<seb128> ogra, well upgrade and see if you get the issue
<seb128> or if that's a one box issue
<ogra> right
<DktrKranz> dottedmag: there I am
<ogra> well, we also have different silicon, plars is on a babbage 3.0 i'm on a 2.5
<DktrKranz> dottedmag: sorry, bad ping :)
<DktrKranz> dholbach: there I am
<ogra> so it could even be HW version related (though thats rare)
<dholbach> DktrKranz: opped you
<plars> ogra: I'm also seeing it on imx51 now
<plars> err
 * DktrKranz hugs dholbach 
 * dholbach hugs DktrKranz back
<plars> ogra: sorry, meant to say that I see it on both dove and imx51
<seb128> ogra, try upgrading by steps maybe
<seb128> ogra, ie apt-get install the new libglib2.0-0 first
<seb128> try with that
<seb128> etc
<ogra> to late
<seb128> ogra, ok
 * ogra reboots to see if it shows up
<ogra> yup, seems i have it too now though that looks more like gnome-session, nothing comes up at all
<ogra> i have a wallpaper
<ogra> and spinning cursor
<plars> ogra: yeah, that's nautilus in a restart loop in the background
<ogra> ogra@babbage2:~$ tail -1 .xsession-errors
<ogra> *** stack smashing detected ***: nautilus terminated
<ogra> yup
<slangasek> ion: any luck with bzr plymouth?
<ion> slangasek: Sorry, didnât get around to testing yet.
<slangasek> ion: no worries.  when do you think you would have a chance?  should I find some other victi^W volunteers?
<ion> slangasek: Iâm still going to test it today. Perhaps in 30 minutes or so.
<slangasek> ok, cool :)
<_Groo_> hi/2 all
<_Groo_> guys what is the proper channel for networkmanager bugs?
<ogra> plars, neither downgrading glib nor gnome-session fixes it :(
<mathiaz> cr3: hey - re bug 512632 - kirkland confirmed it
<ubottu> Launchpad bug 512632 in debian-installer "Network component not activated on a fully automated installation" [Undecided,New] https://launchpad.net/bugs/512632
<mathiaz> cr3: which version of lucid have you used to run the test?
<cr3> mathiaz: crap, it was an older version because the iso wasn't being extracted after rsync. I need to look into that
<mathiaz> cr3: ok
<mathiaz> cr3: kirkland said it was working correctly a week ago
<ion> slangasek: The splash didnât appear in initramfs. Most of the startup seemed to happen in the 80Ã24 text mode (not 1280Ã800), then the mode changed and the Ubuntu logo appeared and almost immediately after that X started and the mouse cursor appeared on top of the logo.
<slangasek> ion: "most of the startup" - so the initramfs wasn't notably more brief?
<slangasek> ion: aside from mouse cursor on the logo, did X start up ok?
<ion> slangasek: I donât know about the speed of initramfs, but the usual after-initramfs startup stuff such as the mountall stuff etc. happened without a KMS mode and without splash. The KMS mode change and the splash appeared a fraction of a second before X. X works fine.
<slangasek> oh, hmm
<slangasek> perhaps we should force plymouth to finish starting before invoking mountall
<slangasek> ion: I think 'or starting mountall' in /etc/init/plymouth.conf should achieve this?
<ion> slangasek: Iâll do a bit of debugging and testing. Shouldnât the splash have started in initramfs already, btw?
<slangasek> ion: no, /fixing/ that is what I specifically want testing on :)
<slangasek> ion: starting the splash in the initramfs slows down the boot
<ion> slangasek: What about the â/bin/plymouth --show-splashâ line in /usr/share/initramfs-tools/scripts/init-top/plymouth? I seem to be missing something.
<slangasek> ion: that script is only included in the initramfs if the 'FRAMEBUFFER' option is set; plymouth was setting this in order to work around a race condition with gdm, the changes in bzr remove this
<ion> Ah
<slangasek> ion: could you verify that adding the 'or starting mountall' to the start condition gives you more reasonable post-initramfs behavior?
<ion> Yeah, iâll try that. bbl, rebooting and testing.
<dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 => can somebody check to sponsor this ?
<ubottu> Ubuntu bug 391035 in aptitude "aptitude stops displaying downloads" [Undecided,Confirmed]
<ion> slangasek: plymouthd seems to be started very early, but for some reason, it takes a long time for the actual splash to get started. I installed bootchart now, letâs see whether it reveals anything interesting. Oh, btw, X doesnât start correctly every time. Sometimes the splash appears and disappears quickly just as X starts, and iâm left with a mouse cursor on a blank screen. At that point, the startup of the X stuff seems to hang and when i try to ...
<ion> ... type anything, it seems as if raw keycodes or soemthing like that get printed to a virtual console. The mouse cursor is still active over that screen.
<slangasek> ion: ah, doh :/ well, I'll hold off on uploading this until Keybnz can look at it
<slangasek> delayed starting of the splash relative to starting plymouthd is expected, that's largely the race condition that I was trying to fix (but it sounds like I didn't get it completely)
 * ogra hugs Keybnz 
<ogra> thats the fastest boot i've every seen !
<ogra> sad that it makes gdm feel really slow
<ogra> i just could reboot the whole day :)
<slangasek> ogra: to avoid any accidental productivity increases from not having to wait for boot? :-)
<ogra> heh
<ogra> well, i actually catch myself waiting for that darn slow gdm greeter now
<ogra> its 3sec to X here (i got a really fast SSD that didnt actually speed anything up in karmic)
<ogra> so i'm sitting for 7 sec after drumroll and cursor are there and wait for the greeter
<slangasek> 7msg Keybnz 3 seconds?  I was promised instant-on!!!1!
<ogra> haha
<Viper550> Why. Yahoo.
<Viper550> It's pretty much just going to be making Bing the default search engine.
<ogra> http://people.canonical.com/~ogra/osiris-lucid-20100127-3.png
<ogra> i wonder why the greeter takes so long to map something ... its actually starting at 5.5 sec
<ion> slangasek: Initramfs is very fast, yes. It seems the main problem with splash coming up late is that it has to wait for udev events, while udev has to wait for mountall to emit virtual-filesystems and mountall has to wait for ureadahead (i have a HDD). But anyway, even if i boot without ureadahead, it takes an annoyingly (thatâs subjective, of course) long time for the splash to appear.
<slangasek> hmm, ok
<slangasek> ion: pre-splash performance is a question I'm going to have to defer to Keybnz; I know plymouth is not intended to be included in the default initramfs, and I saw the impact it had on the benchmark when we had to start including it
<ion> slangasek: With no ureadahead, the splash only seems to be active for three seconds. http://heh.fi/tmp/bootchart/no-ureadahead.png
<ion> slangasek: This is the bootchart from a boot with plymouth flashing quickly and then X being broken. Plymouth starts awfully close to X â a race condition? http://heh.fi/tmp/bootchart/ureadahead-and-broken-x.png
<dupondje> ion: with what tool tou make that bootchart ?
<slangasek> meh need text search on boot charts
<ion> dupondje: bootchart
<slangasek> ion: mountall seems to finish in <2 sec on this system; why does it take udev so long to finish after that?
<zul> pitti: python-pastedeploy should be ok now as well
<ion> slangasek: In my bootchart, mountall seems to finish in one second and it seems to take less than two seconds from udev to gdm. What do you mean by âso longâ? The most curious thing in my bootchart is ureadahead taking so long with low disk throughput. Iâll have to investigate that.
<slangasek> ion: the no-ureadahead.png?  I see mountall starting at 4s, finishing at < 6s; then I don't see plymouth called for the first time until 13s, and plymouth-splash.conf should in the worst case start up as soon as plymouth has started and udevtrigger has finished
<ion> slangasek: The no-ureadahead bootchart is just to demonstrate that ureadahead delays the splash. Of course, everything will be generally slower without ureadahead having warmed up the cache, thatâs the point of ureadaheadâs existence. :-)
<slangasek> ion: fair enough
<directhex> Viper550, because it's a revenue stream for canonical which in real terms is low-impact on users
<Viper550> I know, but couldn't mozilla just share its Google earnings with them
<directhex> presumably not
<slangasek> ion: well, the only way to get the splash screen started sooner is to have the fb device up sooner, and that waits for udev, which isn't slow at all in your second chart - just blocked on ureadahead.  Not sure there's anything we can improve on here (aside from the race condition problem!) that won't negatively impact performance for others
<ion> slangasek: Yeah, itâs a tricky thing.
<kees> pitti: can we keep lxc out of main for now?  it's very young still and every time I use it I find security issues.
<kees> pitti: especially for an LTS
<slangasek> who was talking about soyuz sync oopses the other day?
<slangasek> seems mono can't sync due to one :/
<doko> ccheney: which version of the ubuntu-arm-thumb patch is in the OOo upload? The one with -O2 or the updated one with -fno-schedule-insns?
<ccheney> doko: the ones with O2 that were on the bug report as you mentioned in the email
<ccheney> when did you change it to -fno-schedule-insns?
<doko> today this morning, please could you update it in ooo-build?
<ccheney> ok
<doko> thanks
<ccheney> doko: done
#ubuntu-devel 2010-01-28
<sbalneav> Not sure if anyone's been working on the firefox 3.6 "no start" problem, but I've narrowed down the problem, I think....
<sbalneav> the compatibility.ini file seems to be what's stopping it from starting
<sbalneav> Specifically, the LastVersion=3.6_20100125074043/20100125074043
<sbalneav> line
<sbalneav> I'll have a look at the code, see if I can find out what's parsing it.  Buffer overrun, maybe?
<hggdh> sbalneav: you might have better response on the #ubuntu-mozillateam channel
<sbalneav> ah, ok!  Super.
<micahg> what's the q?
<micahg> oh.hmm...
<micahg> sbalneav: I'll be back on in there in a couple hours if you want to discuss
<sbalneav> Sure.
<sbalneav> I can make it start reliably now by editing the file.
<sbalneav> Ping me when you get in there.  I'm idling there now.
<Toa_Vakama> hi
<dholbach> good morning
<pitti> Good morning
<pitti> zul: pastedeploy> saw your response, will process today
<pitti> kees: lxc> ack
<ogra> pitti, so with my newly upgraded lucid laptop gdm is up after 10seconds after BIOS ... as you can see on http://people.canonical.com/~ogra/osiris-lucid-20100127-3.png X is up after 3.5 and gdm-simple-greeter after about 5.5, is there still any work going on to make the greeter map faster here ? the time from X to greeter mapping *feels* quite long
<ogra> s/is up after/is starting after/
<pitti> ogra: hm, isn't that just the period when you enter your password?
<ogra> nope
<pitti> there is no CPU and IO at that time
<ogra> i see the greeter after 10sec
<ogra> i stopwatched it
<ogra> so half the time i'm waiting for the greeter to map on the screen
<ogra> i typed my password here in this bootchart at about 15sec
<pitti> strange
<ogra> the drumroll also comes when X comes up already, that might add to the impressions of the greeter being slow
<pitti> I don't see that on my box (http://people.canonical.com/~pitti/bootcharts/tick-lucid-20100122-2.png)
<pitti> 3 secs between gdm and g-session, that's the time I need to pick user/enter pwd
<ogra> no, i'm talking about the mapping from the greeter starting to seeing it on screen
<pitti> do you bring this laptop to the sprint?
<ogra> yes
<ogra> its just that the whole bootprocess feels incredibly fast ... somehow the greeter bringup doesnt feel right in that whole scheme
<ogra> wow, you got a slow disk !
<pitti> well, "incredibly fast"
<pitti> yes, your disk is crazily fast
<pitti> however, there's this looooong udev-configure-/dk-power-manager/modprobe hang
<pitti> with the current kernel, I'm seeing something similar on the dell mini (http://people.canonical.com/~pitti/bootcharts/daniel-lucid-20100128-1.png)
<pitti> that 5 second block wasn't there with -10)
<ogra> intresting
<ogra> thats autoligin on the mini, no ?
<pitti> yes
<ogra> *login
<ogra> i should try that on mine for a test
 * pitti tries with -12 kernel
<ogra> oh
 * ogra just notices he modified his cmdline in karmic
<ogra> though i guess usbcore.autosuspend=1 doesnt change anything in the bootprocess
<pitti> worth trying, though
<ogra> hmm, why is update-grub not doing anything
<ogra> oh, its just slower than the old one
 * ogra reboots ... lets see
<ogra> god, freenode gets annoying with the broken autojoin
<ogra> pitti, no change without usbcore.autosuspend=1
<ogra> still sitting there on the xsplash wallpaper for about 5 sec
 * ogra tries autologin
<ogra> wow !
<pitti> ogra: 15 seconds now? :-)
<ogra> 9sec to desktop if i didnt miscount (some app should emit a "mapped" signal that shows up in bootchart)
<pitti> ogra: bootchart draws a red line when it's "done"
<ogra> sadly the chart doesnt really reflect how fast everything was up
<ogra> yes, when *bootchart* is done
<pitti> no, when the session stops using IO and CPU
<ogra> it was up for way over 10 seconds already and i didnt even see a tgz in /var/log
<pitti> yes, that takes a while
<pitti> it continues to measure way after the desktop is done
<ogra> the red line is at 30sec here
<ogra> but thats definately 20 sec longer than it took to map all apps on my screen
<pitti> hm, the red line usually works fine here, odd
<ogra> i had to type my keyring PW
<ogra> probably it waits until thats done
<ogra> since that still produces IO
<ogra> dhclient starts at 20sec on the bootchart
<ogra> http://people.canonical.com/~ogra/osiris-lucid-20100128-2.png
<seb128> urg
<ogra> urg ?
<seb128> your dkpower uses disk for 6 seconds
<pitti> ogra: wow, that's by and large a 10 second boot
<pitti> ogra: even with ubuntuone taking CPU like mad
<ogra> yes
<pitti> seb128: modprobe/udev-configure/dk-power hang
<ogra> bootchart totally doesnt reflect when i see the desktop though
<pitti> looks similar to the delay that we get on the mini
<pitti> that's just I/O wait, though, not actually doing I/O
<ogra> right
<ogra> note though that this SSD costed nearly 300â¬ (i decided to upgrade RAM and disk insteads of buying a new lappie last year) :) but it didnt gain me *any* speedup in karmic
<ogra> after the upgrade yesterday i nearly fell off my chair
<pitti> :-P
<ogra> (and i didnt even buy it for speed butu for battery life :) )
<ogra> *but
<seb128> weird that it didn't make any difference in karmic
<ogra> yeah, i thought so too
<ogra> but i have one odd device that the karmic kernel had issues with (touchscreen) so my modprobe looked like pitti's
<ogra> somehow modprobe looped over the device for like 10 secs, without it i might have seen speed improvements
<lool> cjwatson: Hi, since a recent upgrade of the ssh client on lucid, I get warnings in logcheck from auth.log; the following lines now appear everytime I close a ssh connection:
<lool> Jan 28 10:52:51 fox sshd[26563]: Received disconnect from 192.168.0.119: 11: disconnected by user
<lool> (before pam session is closed)
<lool> cjwatson: I don't know whether this is expected or not, in which case I'll update the logcheck rules
 * lool goes to Paris hand over some hardware and will be back in the afternoon
<lool> +to
<lool> didrocks: Leaving now
<didrocks> lool: ok, I'll leave in 20 min approximately
<lool> didrocks: Shoot for 12:15 rather than 12:00; transport takes forever here
<didrocks> lool: ok, see you :)
<pitti> mvo: rejecting your metacity karmic-proposed upload; no bug reference
<tseliot> slangasek: are you around?
<slangasek> yes
<tkamppeter> pitti, thanks for putting up my CUPS SRU
<tkamppeter> pitti, I have seen a bug report somewhere that CUPS does not start when booting an up-to-date Lucid, can it be that the upstart switchover is the culprit? Will you update the CUPS package to also start through upstart?
<pitti> tkamppeter: I believe Scott already has an upstart script, but it still causes problems
<pitti> tkamppeter: however, init scripts ought to work; if not, that's a bug in the upstart init script integration
<tkamppeter> pitti, OK.
<tkamppeter> pitti, to which package do I have to assign the CUPS-not-starting bug then?
<pitti> tkamppeter: I don't know, without seeing the bug
<Riddell> mvo: is it right that you can't have two packages doing a dpkg-diverts on the same file?
<slangasek> Riddell: yes
<apachelogger> asac: ping
<asac> apachelogger: ?
<apachelogger> asac: can you please make the firefox package replace kubuntu-firefox-installer http://bazaar.launchpad.net/~kubuntu-members/kubuntu-firefox-installer/trunk/revision/22
<apachelogger> following https://bugs.edge.launchpad.net/ubuntu/+source/kubuntu-firefox-installer/+bug/439431/comments/4
<ubottu> Ubuntu bug 439431 in kubuntu-firefox-installer "Firefox Browser Installer must be removed after it's installed" [Wishlist,Fix released]
<apachelogger> ccheney: ^
<asac> apachelogger: sure
<apachelogger> thx :)
<cjwatson> lool: it appears to be intentional
<cjwatson> lool: from what I can tell it was part of the preparation for roaming support
<StevenK> pitti: I'm going to promote EFL and related bits and close the MIR bugs tomorrow morning
<ogra> pitti, hmm, looking at /lib/udev/rules.d/69-xserver-xorg-input-wacom.rules it should be possible to assemble something similar for evtouch devices based on bug 317094
<ubottu> Launchpad bug 317094 in xf86-input-evtouch "meta bug to collect lshal touchscreen info" [Undecided,New] https://launchpad.net/bugs/317094
<ogra> just needs someone with a lot of time to look at all the lshal files
<pitti> cjwatson: thanks for fixing simple-scan ACLs!
<hdon> any idea how to deal with this kind of warning from gcc? warning: format â%lldâ expects type âlong long intâ, but argument 4 has type âint64â
<hdon> i guess i could cast it
<cjwatson> hdon: C99 defines a macro PRId64 which expands to whatever string is required to printf int64_t
<cjwatson> it's not pretty, but nor is a cast, and that's the best you can portably do
<cjwatson> hdon: you need to #include <inttypes.h> for that
<cjwatson> hdon: oh, and you need to supply the "%" yourself, so e.g. printf("%" PRId64 "\n", i);
<Sonne> hello there
<Sonne> is this the right place to ask about a problem with making an usplash theme?
<Sonne> in doubt, i'll try and ask: i have made a 256 colors 640x480 png, used pngtousplash, and compiled into .so, but when trying to load it usplash says "No usable theme found for 640x480"
<vmlintu> Are there known bigger problems with current Lucid packages? It seems like all my kvm based lucid virtual machines just stopped bootin. fsck shows up on console and then it dies with different errors like "mountall: fsck /boot [596] terminated with status 1"
<vmlintu> fsck seems to complain at every boot about unclean shutdown and often checks also fail
<vmlintu> All other kvm virtual machines boot fine and these broke with some apt-get dist-upgrade
<EtienneG> hello all - does someone know the fate of Moonlight in lucid?  I checked, it has not been packaged in Debian, was wondering if someone has been working on it
<EtienneG> err, I mean Moonlight *2*
<cyphermox> EtienneG, if it can be of any help, here's why 2 is not in Debian yet, it seems: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530251 the last comment is especially of interest ;)
<ubottu> Debian bug 530251 in moonlight-plugin-mozilla "new upstream release 2.0" [Wishlist,Open]
<EtienneG> cyphermox, that is very useful indeed
<EtienneG> thanks!
<cyphermox> especially useful since think I know exactly why you're interested in moonlight ;)
<EtienneG> cyphermox, or so you think (hint: it has *nothing* to do with Radio-Canada)
<cyphermox> EtienneG, aww
<seb128> directhex, Laney: is anybody working on getting the new gnome-sharp2 in lucid?
<EtienneG> cyphermox, in any case, I need to telegraph to this Riku Voipio guy
<EtienneG> err, I mean, to telegraph *a beer*
<seb128> directhex, Laney: the debian changes to put the .pc in the new binaries at least
<directhex> seb128, not until someone works out why mono isn't migrating it. it's been synced twice & LP eats it
<Laney> seb128: I reckon we could be persuaded
<directhex> s/it/in/
<Laney> mono needs hax to be synced
<seb128> directhex, I can sync mono
<Laney> seb128 knows the magic
<seb128> somebody told me to not do it
<seb128> !!!
<directhex> as a warning about the subsequent FTBFS, i guess
<directhex> we're mostly done with that though
<Sonne> has anyone read my question about usplash? :)
<seb128>  <seb128>      do you need mono to be synced?
<seb128> <Laney>       I think that requires more discussion
<Laney> let's discuss
<seb128> directhex, Laney: should I sync it or not?
<seb128> I want to get moving with those changes
<seb128> the earlier the transition is done the better
<Laney> the state in debian is good
<seb128> good to know but I'm asking about Ubuntu there ;-)
<mathiaz> slangasek: kees: is it a standard (best?) practice in Debian/Ubuntu that if you don't wanna have a daemon running the package should removed?
<seb128> I'm fine dealing with rdepends
<seb128> or build issues
<seb128> I just want to know if there a reason to delay that transition
<mathiaz> slangasek: kees: see bug https://bugs.launchpad.net/bugs/513749
<ubottu> Ubuntu bug 513749 in dhcp3 "dhcp3-server automatically starts ignoring startup rules on package update" [Undecided,New]
<Laney> not really, not if you understand the issues
<seb128> the issues is just that build-depends need to be updated?
<Laney> yeah, just what to look out for
<directhex> more or less, yes, that's the issue
<seb128> or do I miss something not obvious there?
<seb128> is just seems to me to be a "go through rdepends and change them for the new binaries"
<directhex> and there are very few packages remaining to be updated in sid. obviously merges in ubuntu are a second job on top of that
<mathiaz> slangasek: kees: and bug 513135
<ubottu> Launchpad bug 513135 in mysql-dfsg-5.1 "MySQL logrotate script returns with error when server isn't running" [Low,Confirmed] https://launchpad.net/bugs/513135
<Laney> seb128: that's right
<seb128> ok
<seb128> doing that now
<Laney> and if there are any ubuntu specific packages it would be cool to do those too
<seb128> directhex, Laney: anybody wanting to do the gnome-sharp2 change this afternoon?
<seb128> Laney, I've already been doing some bug I will need to do those again since we did get half of the changes
<directhex> anything in italic on http://wiki.debian.org/Teams/DebianMonoGroup/Mono-devTransition is definitely fine in sid. anything in bold is likely broken
<seb128> Laney, that's why it's better to do everything now in once
<seb128> and not changing build-depends every weeks because we get part of the new binaries
<seb128> directhex, where broken is failing to build right?
<seb128> no runtime issue for users
<directhex> seb128, right
<seb128> ok, really a non issue
<seb128> you guys are overcautious there
<Laney> we just wanted to get a significant chunk done
<Laney> but it seems like some stuff got pulled over anyway
<seb128> right
<Laney> throw the switch if you like, we'll have your back
<seb128> which means we fix several times the same source
<directhex> seb128, for full-on bullet biting, pull in anything which is green in the left column  of that wiki link - those are all the things with rdepends which are in sid and need those rdepends to be tweaked
<seb128> it turns to be extra work rather than win
<seb128> directhex, can you do the gnome-sharp2 merge now?
<seb128> or should I do that one too?
<Laney> i'll do it if it's just the changelog change
<directhex> just the changelog change as far as i can see
<seb128> Laney, it is afaik
<seb128> Laney, thanks
<directhex> seb128, i was also kinda waiting for the archive reorg, as new mono will basically need all extraneous libs to go into main using the old archive layout
<directhex> seb128, although evidently that's not happened yet
<seb128> right, let's not block on that
<seb128> it could take a while ;-)
<directhex> okay then, fine by me
<seb128> didrocks, Laney: the mono sync is done btw
<seb128> ups
<seb128> didrocks,-> directhex
<directhex> seb128, actually published? it keeps dying at that point
<Laney> it requires manual changesfile hax
<Laney> because of a \n
<Laney> (afaik)
<directhex> o_o
<Laney> http://packages.qa.debian.org/m/mono/news/20091214T162012Z.html that one there
<directhex> Laney, the line's too long so it gets cut up?
<directhex> how odd
<seb128> directhex, Laney: yes, the issues is the new lines in the .changes, I've acked that before sending it to the queue
<directhex> is this more sbuild crud? the changes file from a (pbuilder) mono build is fine on my desktop
<seb128> hacked that rather
<Laney> the soyuz parser should be more robust
<seb128> directhex, soyuz is pickier than pbuilder apparently
<seb128> there is a soyuz bug open about that
<Laney> wow
<directhex> seb128, is there any value in a list of syncables, a list of mergables, and a list of TODO?
<Laney> bzr merge-package is GREAT!
<directhex> Laney, ?
<directhex> Laney, is there a tutorial? i'm kinda pretending it doesn't exist as new workflow scares the bejeesus out of me
<Laney> oh, no, hahaha
<Laney> I thought it made a really awesome changelog...
<Laney> but it looks like slangasek has already done the work
<Laney> seb128: seems like the merge is done in bzr
<seb128> directhex, yes
<seb128> Laney, oh nice, I will sponsor that then, thanks
<Laney> you will get depwait, but I guess that's ok
<seb128> right
<directhex> righty then, time to generate a list. i love lists
<Laney> directhex: bzr branch lp:ubuntu/lucid/cats ubuntu; bzr branch lp:debian/sid/cats debian; cd ubuntu; bzr merge-package ../debian; ...; profit
 * kjyu is Sherlock Holmes
<directhex> okay, 78 packages in debian updated for transition. now to cross-reference against ubuntu
<directhex> seb128, analysis complete
<directhex> seb128, http://paste.ubuntu.com/364641/ is a list of packages which are fixed in sid, and should be syncable (i.e. they were already ubuntu==debian)
<directhex> seb128, http://paste.ubuntu.com/364642/ is the complete list of things which need to be merged (or ubuntu delta dropped if appropriate)
<directhex> which leaves a list of 25 things which are held up in debian NEW or not yet checked in either distro by me. or in 2 cases, we plan on dropping entirely
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 4 starting in 15 minutes in #ubuntu-classroom (first: Adopt-An-Upstream)
<directhex> frankly, the whole thing is *far* further along than i expected, so thanks lots to i assume mostly you
<seb128> directhex, ok thanks
<akgraner> kirkland, ping
<akgraner> do you have 2 mins or should I find you laters
<seb128> doko, is that normal that openjdk is still building or is it stucked?
<seb128> doko, the i386 build log doesn't seem to be moving and usually it takes some 7 hours and it's over 10 hours now
<doko> seb128: the test build did pass locally without problems. maybe ask lamont to have a look on the machine?
<seb128> lamont, ^
<lamont> meh
<sikor_sxe> hello, i am trying to do some customizations for the network-manager-openvpn plugin
<sikor_sxe> so i downloaded the tar.gz from "http://packages.ubuntu.com/source/karmic/network-manager-openvpn"
<sikor_sxe> ...built and installed it w/ "./autogen.sh" "make" and "make install"
<sikor_sxe> is this the correct way to do stuff?
<jdstrand> bryceh, slangasek: hey. so mdeslaur and I were discussing bug #507148. It is a pretty serious regression and will likely affect LTS upgrades significantly. I marked it 'regression-potential', but it is unassigned, unmilestoned and the importance is unset
<ubottu> Launchpad bug 507148 in xserver-xorg-video-ati "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [Undecided,Confirmed] https://launchpad.net/bugs/507148
<jdstrand> bryceh, slangasek: I don't feel comfortable setting those items, so wanted to discuss it
<dpm> pitti, a translator is asking this: <kelemengabor> Hi all, does anybody know, why are the mo files of ubuntu-docs shipped in the language packs?
<dpm>  like this: http://people.ubuntu.com/~kelemeng/udocs.txt
<dpm> pitti, is this a side effect from the move of the ubuntu-docs translations to the language packs?
<dpm> if I understand it correctly, those mo files are not used at all
<dpm> (i.e. only the xml files are)
<pitti> dpm: well, it's not a side effect, it's the entire purpose :)
<pitti> dpm: oh, we shouldn't ship the .mo for the xml files
<dpm> pitti, yes, that's what I mean
<pitti> dpm: but we do ship the translated xml files in langpacks
<dpm> the mo files are superfluous
<pitti> dpm: do we even need to import them into rosetta?
<pitti> well, I guess we're using LP to translate those
<pitti> dpm: so I guess we should blacklist them in langpack-o-matic then
<pitti> dpm: too bad that they don't have a proper ubuntu-docs-* domain prefix
<pitti> like that they are so utterly generic (bah namespace trampling)
<dpm> pitti, I can change that
<pitti> a gettext domain named "internet" or "hardware" is not nice
<dpm> I mean, I can prepend ubuntu-docs- to the domain in LP
<dpm> in fact, we renamed the templates not so long ago to include this
<pitti> dpm: that would be very helpful indeed
<dpm> pitti, let me check with mdke first, so I don't break the workflow of the docs team before changing anything...
<dpm> mdke, ^ it seems that unnecessary .mo files are being exported for ubuntu-docs translations along with the xml files in language packs. We are talking of changing the domain name for the templates in LP, which would make it easier to blacklist those files. In principle, this should not affect the docs team, but I'm letting you know just to make sure. The only difference I can see is that the exported files would be named e.g. 'ubuntu-docs-internet.mo'
<dpm> instead of 'internet.mo', but as you are exporting them as PO files, you wouldn't even notice
<dpm> (the first '.mo files are being exported' should have been 'are being shipped')
<pitti> that domain change should be done either way
<pitti> for clean namespacing
<doko> lamont, seb128: there is definitely progress in the openjdk-6 build on i386.
<seb128> doko, ok, it seemed stucked for a while and as said usually build takes 7 hours not > 11 hours
<seb128> it's annoyed that all the buildds got busy for over 10 hours at the same time
<ogra> probably the buildd has the handbrake stuck
<seb128> which means nothing else is building
<seb128> and lucid has installability issues due to the timing
<lamont> seb128: well, there are the dozen or so copies of java running from the build, but load avg is .47
<seb128> lamont, can we get a ppa buildd to build lucid for an hour? ;-)
<lamont> oh, uh... that could be painful
<seb128> oh, seems the issue is solved
<lamont> even the 1 min load on vernadsky hasn't been over 2 in the last 8 hours
<seb128> lamont, don't bother, openoffice failed to build
<lamont> before that, 'twas much higher
<seb128> we have a buildd back ;-)
<doko> yes, OOo failed to build. wonder who tested the build before upload ...
<lamont> good thing these packages are nice and modular and all... :-(
<kirkland> akgraner: yo
<kirkland> akgraner: sorry, back-to-back-to-back meetings this morning
<kirkland> akgraner: what's up?
<kirkland> akgraner: question for you ... where are the UDS Dallas videos published?
<Aissen> hi ubuntu-dev :-)
<Aissen> What's happening with linux-firmware package?
<Aissen> apparently quite a few firmwares were lost during the switch to http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git in lucid
<kees> why is sendmail in mail, and can we please remove it?
<apparle> how much time does it take for a package to be updated in the repos once it is released by original developer?
<apparle> I mean when new version is released
<Riddell> kees: on bug 503774 can you explain what you mean by "Config files (*.cfg) are all out of the local directory."?
<ubottu> Launchpad bug 503774 in virtuoso-opensource "main inclusion request for virtuoso" [High,Incomplete] https://launchpad.net/bugs/503774
<kees> Riddell: I mean that the config files have no path associated with them when they're opened.  it's literally open("whatever.cfg"), so the current directory needs to be well-controlled by whatever launches it.
<sladen> apparle: versions of software in already-released versions of Ubuntu do not generally get updated.... it can take 1 day - 6 months for newer software releases to get into an upcoming Ubuntu release---what is the software that you're interested in?
<apparle> sladen: I am interested in eagle...
<jcastro> kirkland: http://ubuntudevelopers.blip.tv/posts?view=archive&nsfw=dc
<Riddell> kees: nepomuk always starts it with config in /tmp/ presumably that isn't good enough?
<kees> Riddell: ew, no, there are some mildly sensitive config settings (like the "allow system() call")
<Riddell> kees: so nepomuk should be changed to put the config file in ~ ?
<jelkner> with whom does one talk to get an irc channel auto logged to http://irclogs.ubuntu.com?
<jelkner> specifically, #ubuntu-sugarteam
<Riddell> jussi01 ^^
<tsimpson> jelkner: rt@ubuntu.com (/whois ubuntulog)
<jelkner> tsimpson, thanks!
<maco> jelkner: we have a new channel! #ubuntu-us-dc
<micahg> pitti: for thunderbird-locales, what do we do with the locales that didn't have new upstream .xpis?
<jelkner> maco, cool
<jelkner> maco, is rt@ubuntu.com person or machine?
<maco> email address
<jpds> jelkner: Neither.
<jelkner> lol
<maco> it posts a ticket to RT which is the ticket tracker
<kees> Riddell: yeah, I'd recommend something like ~/.cache/nepomuk/ or something
<jelkner> ok, but i write to her/him in English
<jelkner> not some formal language
<jpds> jelkner: Plain English is fine.
<jelkner> cool
<jelkner> i can do that ;-)
<maco> jelkner: it's like posting a bug in launchpad via email
<Caesar> slangasek: is it fair to say that lucid is going to have eglibc 2.11.1, or is it still in a state of flux?
<kirkland> jcastro: hmm, i was specifically looking for the interview I did with akgraner, which isn't there
<bryceh> jdstrand, got your bug
<bryceh> jdstrand, looks to me like it's a fault deep down in the kernel drm memory code.
<jdstrand> bryceh: I am highly motivated to get this fixed (as is mdeslaur). I've got users that will be affected by this (besides my primary laptop) when upgrading to lucid
<bryceh> jdstrand, I've added the kernel team to the bug.  I also re-sent the bug upstream to the radeon folks (the bug had been linked to a -nouveau bug, but I don't think the nouveau bugs are looked at very well)
<jdstrand> bryceh: I can do whatever to try to work on it, as well as bring it to the sprint next week
<jdstrand> bryceh: if that would be helpful
<mdeslaur> I can prepare bribes
<jdstrand> bryceh: on of those users is my wife-- if she hits this, my productivity will seriously decrease :P
<bryceh> jdstrand, mdeslaur, heh well it looks like it's pretty far outside my area of grokkage
<bryceh> jdstrand, mdeslaur, I can suggest workarounds, but kernel coding is a bit beyond me :-)
<bryceh> jdstrand, mdeslaur, for workarounds, I'd suggest turning off KMS
<bryceh> if that doesn't do it, there are some video parameters you can set in xorg.conf, although I doubt they'd have much effect in this case.  Easy enough to test though.
<superm1> bryceh, does "safe graphics mode" turn off KMS right now on lucid live media?
<mdeslaur> I wonder if disabling compiz would help
<bryceh> jdstrand, mdeslaur, also not sure if you re-tested today but I updated -ati to a new version yesterday.  Since I suspect this is a kernel drm issue it probably won't help, but likely can't hurt to try it
<jdstrand> bryceh: I tried some xorg.conf hacks over the break, but I still had KMS on
<bryceh> mdeslaur, jdstrand, right I was going to mention #3 to shut off compiz
<mdeslaur> bryceh: I can't find how to disable kms in the debugging wiki...
<bryceh> superm1, pretty  sure it doesn't
<jdstrand> bryceh: how does one disable kms?
<bryceh> I should fix that
<bryceh> jdstrand, mdeslaur, there's a couple ways to do it - see https://wiki.ubuntu.com/X/KernelModeSetting
<jdstrand> mdeslaur: you are on up to date lucid, right?
<mdeslaur> jdstrand: yes
<bryceh> basically you want "radeon.modeset=0" as a kernel parameter
<mdeslaur> ok, trying now
<bryceh> if that works, sticking it in /etc/initramfs-tools/modules will be a good way to make it permanent
<bryceh> syntax is different there though.  "radeon modeset=0"
<mdeslaur> so, turning off kms worked. It's not even using compiz in my case.
 * bryceh nods
<bryceh> I sort of wonder if we should just blacklist your hardware from using kms entirely
<mdeslaur> bryceh: that's what I was about to suggest
<mdeslaur> at least until upstream does something
<jdstrand> bryceh: with a couple of xorg.conf tweaks, 3d worked well on jaunty
<bryceh> mdeslaur, jdstrand, ok so for that we need apw
<bryceh> jdstrand, right that was pre-KMS
<bryceh> jdstrand, probably worked ok on karmic too
<apw> bryceh, bring that to the sprint ... the problem ... i want a round table on graphics with you anyhow
<jdstrand> bryceh: without KMS, I login but I get horrible screen garbling (compiz is enabled)
<bryceh> mdeslaur, jdstrand, ok you heard it from the man - bring your laptops to the sprint and apw and I will puzzle over them
<jdstrand> apw, bryceh: by 'bring that' would actual affected hardware that I can let you use during the sprint be helpful?
<apw> if its not going to get you in trouble with the airlines and break your back perhaps yes
<apw> but more the issue at hand so we cna discuss solutions
<jdstrand> bryceh, apw: that is great! I've been quite worried that this would be a serious regression for all those radeon 7500 users out there (being so popular in laptops from a few years ago)
<mdeslaur> I can't bring my T30, jdstrand, will you be bringing yours?
<bryceh> well the general issue of "kms fails on old hardware" is an important one we should at least understand and have a plan for
<bryceh> er "old ati hardware"
<jdstrand> mdeslaur: yeah. I'll bring it and my mini 9 so people can fiddle with mine without me
<bryceh> jdstrand, your system works ok with both kms and compiz disabled?
<jdstrand> bryceh: I'll disable compiz and see
<apw> yeah if you are considering bringing extra h/w do coordinate with someone (bryceh?) so we only get one of each
<jdstrand> bryceh: it seems to in general, but notifications are a solid black box
<bryceh> jdstrand, with the corruption bug, take a photo or two of the screen, then ssh into it and do 'ubuntu-bug xserver-xorg-video-ati', reboot, file the bug in LP, and subscribe me to it, and I'll make sure it gets processed and upstream.
<bryceh> jdstrand, ok good
<superm1> bryceh, if you do get it so it's turned off in safe graphics mode, don't forget that you also need to find a way to make sure that kernel command line option gets populated over to the installed system too
<superm1> probably via a casper ubiquity hook
<bryceh> jdstrand, re:notifications - that might not be a driver issue, but check with mirco
<jdstrand> bryceh: with kms and compiz, notifications were almost correct, but not quite: http://people.canonical.com/~jamie/notify-osd.png
<bryceh> superm1, ok noted.  I probably won't get a chance to look into it until after the sprint, but it's in my gtg todo file
<apw> jdstrand, whats wrong with it?
<jdstrand> apw: which it? the notification?
<apw> yeah
<jdstrand> apw: did you see the png? the green bar and the orange lines. that doesn't happen on my desktop
<apw> isn't that normal at this stage of the release.  that it always shows those, they are debug arn't they?
<jdstrand> oh, is it? I only have lucid on that machine
<jdstrand> forgive me if that is normal for lucid at this point
 * apw checks
<bryceh> jdstrand, yeah I see the same thing on a couple of my boxes
<apw> i think it may have recently changed too, as in turned off
<bryceh> jdstrand, didn't bother to file a report but I assume it to be a notifications-specific bug rather than a driver issue
<bryceh> kind of looks like a cellpadding goof
<jdstrand> I've seen it for 4-6 weeks or so (ie, when I upgraded to lucid)
<apw> i seem to remember it was something they do in the alphas so you can see the underlying data from the client and stuff and check things are placed right
<apw> and then they hide it again
<jdstrand> bryceh: is the notifications as a black box with no kms and no compiz a known bug?
<chrisccoulson> jdstrand / apw, during the early phase of the cycle, notify-osd is run in debug mode, which is what is shown in the png
<jdstrand> ah, ok
<jdstrand> chrisccoulson: thanks
<chrisccoulson> but debug was turned back off again a couple of weeks ago, so you shouldn't see it anymore
<apw> yeah i see its changed back on my lucid box
<bryceh> jdstrand, it's not one I've heard before
<jdstrand> bryceh: ok I'll file a bug then
<bryceh> jdstrand, I do know that notifications work differently with compiz than without though.
<jdstrand> bryceh: I tried enabling compiz again, to show the garbledness and file a bug as you requested, and X locked up. I can ssh and have not logged out. shall I ubuntu-bug it from ssh?
<bryceh> yep
<pitti> micahg: drop them?
<jdstrand> bryceh: crash filed as bug #513950
<ubottu> Launchpad bug 513950 in xorg "[lucid] xorg froze after disabled KMS and enabling compiz on ATI Radeon Mobility 7500" [Undecided,New] https://launchpad.net/bugs/513950
<micahg> pitti: yeah, that's what I did (i.e. they're not in the control file), but do I need to do anything else?
<pitti> micahg: they will appear in NBS and be removed, so I don't think so
<micahg> so the users with those locales that upgrade have the old packages removed?
<pitti> micahg: usually these should have strict dependencies to a compatible version
<pitti> so they should conflict to never tbirds which doesn't support their format any more
<micahg> pitti: yep, they do, so that'll remove it then and I don't have to worry?
<jdstrand> bryceh: garbling filed as bug #513956
<Caesar> Is there a way to link to an upstream bug, when upstream is SourceForge?
<ubottu> Launchpad bug 513956 in xorg "[lucid] garbled screen with compiz but no KMS on ATI Radeon Mobility 7500" [Undecided,New] https://launchpad.net/bugs/513956
<pitti> micahg: that, or hold it back
<micahg> pitti: hold back the release until they all catch up?
<pitti> micahg: hm, ISTR that in ancient times I added some "obsolete-packages" list there, which would generate empty transitional packages for the dropped locales
<pitti> (until the next LTS)
<pitti> micahg: no, hold back the thunderbird upgrade
<micahg> pitti: asac remembers something similar, but I don't see it...maybe I should pull the hardy package?
<pitti> micahg: hm, maybe that was never done for tbird-locales, only for firefox-locales
<qense> pitti: bug 509283 was reported 10 days ago and has got the need-amd64-retrace tag but Apport still hasn't left a comment. Is CoreDump.gz broken?
<ubottu> Bug 509283 on http://launchpad.net/bugs/509283 is private
<pitti> DistroRelease: Ubuntu 9.04
<pitti> sorry, no retracer right now for Jaunty
<pitti> micahg: yep, that was it; hardy's mozilla-firefox-locale-all, debian/unavail.txt
<pitti> micahg: debian/rules has a snippet which builds control snippets from debian/templates/unavail.template
<pitti> micahg: perhaps just copy that to tbird-locales?
<micahg> pitti: should I add that to thunderbird-locales, we're going to update to 3.0.1 shortly after 3.0, but asac wants to get 3.0 as is into archive first
<micahg> and I think 3.0.1 picked up the locales, but not sure
<qense> pitti: Does that mean no Jaunty retracer for the first few months, or will there never be one anymore?
<pitti> micahg: with unavail.txt you keep teh package installed, so as soon as it's available again it'll come back
<micahg> pitti: k, I'll add that then, thanks
<pitti> qense: well, they aren't really that interesting any more
<qense> ok, shall I close the bug then?
<pitti> qense: and it's quite some maintenance
<qense> pitti: I understand, thanks for your time!
<pitti> qense: unless it already has something useful in it, sure
<qense> ok!
<pitti> this doesn't look very precious/interesting, though
<qense> no
<jdstrand> bryceh: I filed bug #513968 against notify-osd for the unreadable black box notifications with both KMS and compiz disabled. Do you want me to subscribe you to that one?
<ubottu> Launchpad bug 513968 in notify-osd "[lucid] notify-osd display black box when KMS and compiz are disabled on ATI Radeon Mobility 7500" [Undecided,New] https://launchpad.net/bugs/513968
<bryceh> jdstrand, no, not unless it's determined to be an X issue
<jdstrand> k
<jdstrand> bryceh: as you've probably already seen, I did subscribe you to the other two
<jdstrand> bryceh: you aren't subscribed to
<jdstrand> bryceh: bug #507148-- is that intended or no?
<ubottu> Launchpad bug 507148 in xserver-xorg-driver-ati "[lucid] desktop runs out of video memory on ATI Radeon Mobility 7500" [Unknown,Confirmed] https://launchpad.net/bugs/507148
<bryceh> jdstrand, I'm subbed on the upstream bug so will see when they reply
<jdstrand> cool
 * jdstrand stops bugging bryceh for now
<bryceh> jdstrand, you can sub me to the lp one; I've got it noted in gtg so I'll follow up next week
<jdstrand> bryceh: thanks for helping with this! :)
<bryceh> jdstrand, yep, glad you at least got a working system again.  Hope the underlying issue can get sorted.
<jdstrand> bryceh: me too-- I've got several radeon 7500 users that will be disappointed otherwise
<jdstrand> bryceh: well, I lied. Seems I'm having display problems with no KMS and no compiz. Can you look at http://people.canonical.com/~jamie/ooo-display-problem.png?
<jdstrand> bryceh: the rectangle around 'Default' shouldn't look like that-- at first it doesn't, but if I move another app window over it, then click oo.o to bring it to the foreground, I got that.
<bryceh> jdstrand, that looks sort of familiar.
<bryceh> jdstrand, I'm not going to worry about it since it's just a cosmetic issue and I've got many bigger fish to fry, but you might look through the Low priority -ati bug reports as there's several artifact/corruption bugs for older ati cards there
<jdstrand> k
<jdstrand> bryceh: thanks again, I really will stop bugging you now :)
<Riddell> bug 503774 updated, let me know if anything else is needed
<ubottu> Launchpad bug 503774 in virtuoso-opensource "main inclusion request for virtuoso" [High,Incomplete] https://launchpad.net/bugs/503774
<Riddell> kees ^^
<mdke> pitti: don't see any issue with what dpm proposed - we don't create or use .mo files in ubuntu-docs
<pitti> mdke: ah, good to know
<pitti> mdke: so we can prefix the domains, and then blacklist them from the langpacks
<mdke> pitti: will the po files exported from LP also be changed?
<mdke> I guess they will have the usual cc.po format?
<pitti> mdke: don't think so; just their name might change
<pitti> they are usually prefixed with the domain, aren't they?
<pitti> the last export that I got contained files like apport_de.po
<mdke> I can't remember, but yes - I think so
<mdke> the templates are already prefixed I believe
<mdke> anyway, we can work around whatever happens
<mdke> pitti: got to log out for now but happy to follow up by email if necessary
<pitti> likewise, /me -> off for the night
<mdke> bon nuit
<pitti> mdke: thanks, and good night!
<slangasek> mathiaz: 513749> best practice is to not install the daemon if you're not using it, yes; second option is to turn start links in /etc/rc.? into stop links; some packages provide /etc/default/foo, but that's horrible; worst case is to remove all the links from /etc/rc.? and expect them to stay that way
<seb128> hey slangasek, you can upload your gnome-sharp2 merge if you want the new mono version is in lucid
<seb128> slangasek, I expect you were waiting on that one to upload?
<slangasek> mathiaz: as for 513135, I think that's a bug in the logrotate script
<slangasek> seb128: ah, how did you get the new mono in?  I was getting oopses from LP trying to sync it
<seb128> slangasek, I deleted the new lines chars in the binaries list in the .changes
<slangasek> ah
<seb128> slangasek, that's a known soyuz bug
<slangasek> bug #?
<seb128> slangasek, launchpad bug #435315
<slangasek> ta
<ubottu> Launchpad bug 435315 in soyuz "new lines chars in the Binary list triggers parsing issue (dup-of: 435316)" [Undecided,New] https://launchpad.net/bugs/435315
<ubottu> Launchpad bug 435316 in soyuz "new lines in the changes file Binary: field triggers a parsing error" [Medium,Triaged] https://launchpad.net/bugs/435316
<seb128> ups that's the duplicate
<seb128> in any case you get the other bug number there too ;-)
<slangasek> Caesar: I'm not expecting any further bumps to eglibc in lucid
<Caesar> slangasek: ok thanks
<Caesar> slangasek: there's also the case of pam and that upstream bug in pam_access
<Caesar> I've just filed a bug in launchpad for it
<slangasek> yeah, saw :)
<Caesar> I can provide a patch with a backport of the fix if that is the desired outcome
<slangasek> I'll follow through next week
<Caesar> Cool thanks
<Caesar> We're just starting to ramp up on Lucid stuff now
 * slangasek nods
<Caesar> Had a bit of a distraction
<mathiaz> kees: jdstrand: mdeslaur: does it make sense to demote openssl-blacklist and openvpn-blacklist to universe?
<kees> mathiaz: they're Suggests from openssl already, but I don't see any reason to move them around.  is it causing a problem in main?
<kees> mathiaz: and do you know why sendmail is in main?
<mathiaz> kees: because of the extra seed
<mathiaz> kees: I don't see it as problem in main - we dropped openssh-blacklist to universe
<mathiaz> kees: may be I extrapolated and though openssl-blacklist *and* openvpn-blacklist should also be demoted
<mdeslaur> hmmm...I'm not sure I like that very much
<mathiaz> kees: if not I'm happy to keep them in main
<mathiaz> mdeslaur: that = ?
<mdeslaur> if, in the future, we need to add keys to that
<kees> mathiaz: we should keep the blacklists in main (all of them)
<mdeslaur> then we'll ask that people install stuff from universe
<kees> mathiaz: how do I remove sendmail from main?
<mdeslaur> if they don't have the universe repo enabled...
<mdeslaur> it gets _real_ complicated _real_ quick if we need to use them again for new blacklisted keys
<mdeslaur> I don't see why they need to be demoted...it's not like anyone's wasting time updating them or anything
<mathiaz> kees: ah ok - we can keep them in main
<mathiaz> kees: I may have misinterpretaded the thread then
<mathiaz> kees: I'll add openssh-blacklist back into main
<kees> mathiaz: what caused sendmail to be in extras?
<kees> mathiaz: cool
<mathiaz> kees: it's in an extra seed somewhere
<mdeslaur> thanks mathiaz
<mathiaz> kees: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/rdepends/ <- complete list of dependency for each package
<mathiaz> kees: in main
<kees> wheee
<mathiaz> kees: and then you may also need to check the other *.lucid/rdepends/
<mathiaz> kees: I usually grep on people.canonical.com
<kees> mathiaz: okay
<mathiaz> kees: ok - so open{ssl,ssh}-blacklist-extra were shipped on the -server iso
<mathiaz> kees: should these be brought back on there - on seeding them in main is enough
<mathiaz> kees: I guess the question is wether they should be installed by default on a server install
<kees> mathiaz: if there is room on the CD, put them on the CD.  :)
<mathiaz> kees: hmmm
<mathiaz> kees: have you found where the Extra seed is?
<seb128> slangasek, if,when you upload gnome-sharp2 could you new the binaries to main too, quite some things depwait on those
<cjwatson> extra is synthesised
<seb128> slangasek, thanks ;-)
<cjwatson> it consists of those binary packages that are produced by source packages that are in main, but binaries that are not themselves otherwise seeded
<cjwatson> so if libfoo is in main, then libfoo-utils might end up in extra if it's not seeded
<slangasek> seb128: can do
<mathiaz> cjwatson: ok - I'm looking at elinks
<mathiaz> cjwatson: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/rdepends/elinks/elinks
<mathiaz> cjwatson: according to http://people.canonical.com/~ubuntu-archive/component-mismatches.txt, elinks is a binary only demotions
<mathiaz> cjwatson: what should be done to kick the source out of main as well?
<cjwatson> mathiaz: elinks-lite is in the same source and is seeded: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.lucid/rdepends/elinks/elinks-lite
<cjwatson> or not seeded directly but build-depended-on
<mathiaz> cjwatson: ahhh
<cjwatson> (I just went up a level and looked through each file in turn until I found something interesting)
<Caesar> Is rmadison being busted a known issue?
<mathiaz> cjwatson: thanks - I'll investigate more then
<cjwatson> Caesar: busted how?  it seems to work for me
<Caesar> Hmm, it's been timing out for days
<Caesar> (for me)
<Caesar> I eventually get back a 503
<Caesar> From people.ubuntu.com
<Caesar> Let me try from home
<Caesar> Interesting, it works there
<Caesar> Have we gotten ourselves blacklisted?
<Caesar> Actually that was Debian
<cjwatson> Caesar: version of devscripts?
<Caesar> 2.10.39ubuntu2
<cjwatson> thought so
<Caesar> URL changed?
<cjwatson> you need 2.10.48ubuntu2 or better
<Caesar> Doh
<cjwatson> but if that's tedious, then rmadison -u http://people.canonical.com/~ubuntu-archive/madison.cgi
<Caesar> Couldn't put in a redirect, eh?
<cjwatson> we did
<cjwatson> it broke with the people.ubuntu.com -> people.canonical.com move that was to make way for people.ubuntu.com being an SFTP thing open to Ubuntu members
<cjwatson> unfortunately:
<cjwatson>   * Update rmadison's Ubuntu URL to cope with people.ubuntu.com ->
<cjwatson>     people.canonical.com; invoke curl in such a way as to follow redirects
<cjwatson>     by default (LP: #399891).
<Caesar> hah
<Caesar> Oh well
<cjwatson> you can just edit your local rmadison if that's convenient
<Caesar> Yeah
<Caesar> Profit!
<Caesar> Thanks
<Caesar> I must have missed the memo
<geser> do packages from a source in main but which are currently in universe a MIR to get moved to main? libmono-cil-dev depends on several packages in universe (but build from mono)
<slangasek> geser: no
<geser> a bug? or do I just ask an archive admin politely?
<slangasek> geser: it's part of the daily archive admin duties to reconcile these things; if no one else gets to it I can have a look, but not until after I finish pushing 8.04.4 out the door
<cjwatson> geser: I'll look
<seb128> geser, which ones?
<seb128> geser, I did try to new things to main but I might have overlooked one
<cjwatson> gosh, what a lot of binary promotions
<cjwatson> seb128: I'm on it
<seb128> cjwatson, ok thanks
<seb128> things will fail untill slangasek upload gnome-sharp2 anyway
<geser> seb128: the list is longer: sudo apt-get --print-uris install libmono-cil-dev | grep universe
<seb128> new binaries from it are required for most of the mono updates
<cjwatson> it's done
<geser> thanks
<seb128> cjwatson, thank you
#ubuntu-devel 2010-01-29
<ccheney> anyone know of any major issues with lucid? i am considering upgrading to it before going to the sprint next week
<ccheney> it looks suprisingly stable for an alpha release when i booted up off a usb stick
 * ccheney will upgrade and hope it works :)
<slangasek> I know of several major issues with lucid, all of which are documented ;)
<ccheney> slangasek: major enough i should stick with karmic for main dev machine still?
 * ccheney looks through alpha 3 bugs
<ccheney> hmm there is an intel wifi bug but those are fairly common in general, heh
<ccheney> ah nm i was looking at the wrong bug list
<slangasek> ccheney: nothing major enough that I'm stressing about it right now :)
<slangasek> OTOH, I'm on Intel, so plymouth works for me
<ccheney> slangasek: ok yea me too
<ccheney> slangasek: it looks fine to me so far running off usb
<jcastro> ccheney: I am having wifi issues (I think we have the same laptop) but I am also suspecting by AP (ymmv etc.)
<ccheney> jcastro: ok
<ccheney> jcastro: is it just occasional or constant?
<ccheney> jcastro: it worked ok for the brief time i was running before i rebooted to back stuff up
<jcastro> it's just real flaky, I only noticed it when I was prepping it for the sprint.
<jcastro> dropped signal, long timeouts, etc.
<ccheney> oh hmm :-\
<jcastro> but again, I am suspecting my AP, I'll let you know on monday. :D
<ccheney> ok
<ccheney> well i'll reinstall to lucid and see how it goes, heh
<ccheney> we may end up in the kernel room getting them to hound intel :)
<RAOF> Can someone give ndesk-dbus a rebuild prod?  The sync initially failed to build (probably because one of its b-ds hadn't made it through NEW at that point); it builds fine now.
<pitti> Good morning
<RAOF> Good morning.
<pitti> asac: should I remove the firefox-3.5 source package now?
<baali> I am getting this error on ubuntu 9.10 "chroot: cannot run command `/bin/bash': Exec format error", any hints?
<baali> i have looked links on linuxqustion.org and ubuntu forum and not able to fix this
<RAOF> Could be any number of things, and is probably not really on-topic for #ubuntu-devel - #ubuntu is the channel for support.
<RAOF> One obvious thing that springs to mind is whether you've built an amd64 chroot and are trying to run it from a 32bit kernel.
<Hobbsee> RAOF: prodded
<RAOF> Ta muchly.
<RAOF> Now, let's boot this new kerenl & see if cowboylaputopu will actually enter a low-power state when I tell it to suspend.
 * mneptok falls asleep
<RAOF> With bonus check for xorg nouveau-autodetection patch correctness!
<didrocks> good morning
<dholbach> good morning
<dholbach> pitti: do the special keys (xf86mail, xf86audioraisevolume, etc.) work for you in current lucid?
<pitti> dholbach: yes, they do
<pitti> dholbach: since I maintain the keymap tables, they better do :-P
<dholbach> weird, for me they don't with current lucid
<dholbach> Xf86HomePage brings up nautilus
<pitti> dholbach: and they did work in karmic? very strange
<dholbach> yes, they still worked yesterday
<pitti> !
<pitti> now, udev didn't change at all
<pitti> we got a new kernel, though
 * dholbach has a look at apt log to find out what changed
<pitti> dholbach: I didn't test the hotkeys on my laptop today ete (it's docked); but on the mini they do work
<dholbach> let me reboot with the old kernel
<didrocks> dholbach: same for me, it works
<pitti> s/ete/yet/, bah
<dholbach> it's funny when the reboot/shutdown/logout indicator sometimes doesn't show anything :)
<dholbach> ok, same with the old kernel
<dholbach> weird, I have no idea what could have changed that behaviour
<pitti> dholbach: you still have /lib/udev/rules.d/95-keymap.rules ?
<dholbach> yep
<dholbach> which gconf keys would override that somehow?
<dholbach> there was a gconf update, maybe something went funny there
<pitti> dholbach: you should first check that the generated keycodes are correct/wrong; /usr/share/doc/udev/README.keymap.txt
<dholbach> pitti: so when I open the shortcut preferences and try to change them the Xf86Mail still shows up, when I press it
<pitti> i. e. find your keyboard device (findkeyboards) and then keymap -i
<pitti> dholbach: or use xev
<dholbach> I guess the keycodes are fine, but yeah, let me check
<pitti> dholbach: is mail correct or wrong?
<pitti> dholbach: start with xev then
<dholbach> it's what was in there before
<dholbach> but it doesn't start thunderbird for me
<dholbach> same goes for raise volume
<pitti> ah, then I blame seb128
<dholbach> it just doesn't do anything
<pitti> dholbach: try in a guest session?
<dholbach> pitti: you are a clever man
<dholbach> I'll do that
<dholbach> pitti: nope, they don't work at all there
<dholbach> oh, the guest session is completely busticated
<dholbach> I can't click anything in there
<dholbach> the mouse pointer moves, but that's it
<pitti> hm; FTR it doesn't work for me either; I just get a VT with a mouse cursor, and then I have to reboot
<pitti> some weird plymouth/KMS/xorg problem
<dholbach> wow
<dholbach> ** (gnome-settings-daemon:2833): WARNING **: /usr/lib/gnome-settings-daemon-2.0/libmedia-keys.so: undefined symbol: notify_notification_show
<dholbach> ** (gnome-settings-daemon:2833): WARNING **: Cannot load plugin 'Medientasten' since file '/usr/lib/gnome-settings-daemon-2.0/libmedia-keys.so'
<dholbach>  cannot be read.
<dholbach> ** (gnome-settings-daemon:2833): WARNING **: Error activating plugin 'Medientasten'
<dholbach> (gnome-settings-daemon:2833): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
<dholbach> (gnome-settings-daemon:2833): GLib-CRITICAL **: g_propagate_error: assertion `src != NULL' failed
<dholbach> (polkit-gnome-authentication-agent-1:2843): GLib-GObject-WARNING **: cannot register existing type `_PolkitError'
<dholbach> (polkit-gnome-authentication-agent-1:2843): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
<dholbach> that's /tmp/guest-home.feqBK3/.xsession-errors
<pitti> oh, libmedia-keys.so? that seems relevant
<dholbach> undefined symbol
<pitti> dholbach: ah, confirmed here
 * dholbach hears alarm bells ringing
<pitti> dholbach: just finished a dist-upgrade on the mini
<pitti> itz gnome bug
<dholbach> itz ugly
<dholbach> didrocks: ^ fix it!
 * dholbach hugs didrocks
<didrocks> rohhhh ^^
 * didrocks hugs dholbach
 * dholbach gets another cup of coffee while didrocks fixes it
<dholbach> ;-)
<didrocks> dholbach: I'm sure you can live without it :p
 * didrocks just notices he didn't touch g-s-d contrary to other desktopers ;)
<pitti> ah, so that's why the key repetition is broken
<dholbach> pitti: "I'm sure you can live without it :p"
<pitti> I just reenabled them in the keyboard settings this morning
<asac> pitti: sure. thanks!
<asac> (ffox 3.5 removal)
<geser> could an archive admin please promote van.pydeb (python-van.pydeb) once again to main? it fell once again of it (see also bug #494104 for the last occurance)
<ubottu> Launchpad bug 494104 in van.pydeb "[MIR] Promote "van.pydeb" back to main" [Medium,Fix released] https://launchpad.net/bugs/494104
<pitti> asac: removed then
<asac> thx
<pitti> geser: sure, doing
<ogra> hrm, so the karmic->lucid upgrade stole my nodeadkeys setting
<ogra> hrm, even though according to the keyboard settings it is set to nodeadkeys
<ogra> aha, deleting the US layout (that wasnt there in karmic and i didnt select it) seems to fix my german setting
<ogra> very weird and unintuitive
<vish> ogra: kernel 32-12 ?
<ogra> -11
<ogra> i dont think its anyhow related to the kernel but rather to gnome-settings-daemon or whatever handles the kbd settings atm
<vish> k.. , i just noticed something weird with 32-12 update too , it turned off the keypress repeat settings :s
<vish> ah , maybe the gsd update did it
<ogra> works here with -11 ... i'm just running an upgrade
<ogra> lets see if i still have it after thats done :)
<ogra> aarrgghh
<ogra> mmyy  kkbbdd  ddoouubblleess  eevveerryy  lleetttteerr  ii  ttyyppee  nnooww
<ogra> sseeeemmss  ttoo  bbee  rreessttrriicctteedd  ttoo  XX
<ogra> ah, better
<ogra> so the key repetition sliders in the kbd settings both were completely moved to the left
<ogra> seb128, do you have a bug for that ? its scary !
<Tm_T> ogra: I was about to ask if you did wear thick gloves (:
<ogra> heh
<seb128> ogra, dholbach reported an issue with the keybinding code not loading yes
<seb128> ogra, but it just disable the gnome settings
<ogra> no, its the repetitionm
<seb128> it doesn't double anything
<seb128> you get what xorg do by default
<ogra> take your kbd settings and move both sliders to the very left :)
<ogra> thats what i just had
<seb128> well this code fails to load
<ogra> its g-s-d or whatever manages the kdb settings loosing its defaults
<seb128> so the setting should not be revelant
<ogra> it surely didnt for me right now
<seb128> well the gnome code crashes
<seb128> so it's not setting anything
<ogra> moving the sliders fixed it
<ogra> so it sets it at least *at some point*
<seb128> weird
<ogra> try it
<seb128> anyway I'm off to test the fix for that
<seb128> brb
<ogra> i can reproduce it by moving both sliders back
<seb128> that will be quicker than discussing how the breakage break it for you
<seb128> as said the code is crashing and I've a fix ready to test
<ogra> ok
<seb128> I don't think discussing what side effect the crash has it useful
<seb128> let's just fix it
<seb128> brb
<ogra> no, go ahead, i'll test the fix if its up+
<ogra> weird, i now have a "jack control" tool in my media menu ... and it has no close button on the wiondow
<EtienneG> pitti, I suffer from bug #454487, and gnome-settings-daemon 2.28.1-0ubuntu3 has been uploaded to karmic-proposed to fix it.  Except, it's not there and I can't find it!  Have it been pulled?
<ubottu> Launchpad bug 454487 in gnome-desktop "The program 'gnome-settings-daemon' received an X Window System error. During on a FreeNX server suring a session. The crash does not happen when xrandr plugin is disabled." [Medium,Fix released] https://launchpad.net/bugs/454487
<EtienneG> seb128, maybe you would know about the above ... ?
<seb128> EtienneG, let me look
<EtienneG> seb128, I can see it at https://launchpad.net/ubuntu/+source/gnome-desktop/1:2.28.1-0ubuntu3, but it is neither in karmic-updates nor -proposed
<seb128> EtienneG, it is in karmic-updates
<seb128> EtienneG, apt-cache policy libgnome-desktop2-11?
<seb128> EtienneG, apt-cache policy libgnome-desktop-2-11 rather
<EtienneG> seb128, ok, I must have been confused, lemme check
<EtienneG> seb128, ah, ok, got it, however, gnome-settings-daemon is still at 2.28.1-0ubuntu2
<seb128> right
<seb128> that's a different source
<EtienneG> and g-s-d is what I actually need :(
<seb128> no reason for it to change version
<EtienneG> ah, ok
<seb128> no
<seb128> the bug was in gnome-desktop there
<seb128> g-s-d uses the gnome-desktop library
<EtienneG> I see
<EtienneG> seb128, sorry for the confusion, and thanks a bunch for the help.  i think I am all set.
<seb128> you're welcome
<seb128> EtienneG, let me know if the update works for you or not
<seb128> ie if it fixes your issue
<EtienneG> seb128, yes, i will, although I will not be able to test for a while
<EtienneG> seb128, the affected system is in a walled network, complicating update
<EtienneG> seb128, I am waiting for the mirror and update infrastructure to get setup
<seb128> ok
<seb128> in any case let us know if that's still an issue with the update when you get it
<EtienneG> I was actually checking the status of all the bug i had to handle, and investigating that one.  Seems like the solution is just an update, which is good!
<EtienneG> seb128, I sure will
<EtienneG> seb128, and thanks again for the prompt response, much appreciated
<EtienneG> especially considering you guys must be insanely busy these days
<EtienneG> with travelling and stuff
<seb128> travelling is tomorrow ;-)
<EtienneG> I know, but packing and catch-up has to be today!
<EtienneG> I am actually in Europe this week
<dupondje> when get packages accepted that are in the lucid queue ? :)
<doko_> ccheney: updated the OOo patch in https://bugs.launchpad.net/ubuntu/+source/gcc-4.4/+bug/506358 again, please apply before the next try to build. Is the gsi export supposed to work? Afaicr we wanted to make this work for lucid
<ubottu> Ubuntu bug 506358 in gcc-4.4 "[armel] unable to find a register to spill in class 'GENERAL_REGS'" [High,Confirmed]
<doko_> asac: ^^^ one chunk missed, hope that the only one
<asac> thanks
<asac> doko_: btw, the dove hang on pybootchartgui import in python wasnt fixed by updating python ... but by recreating the .pycs afterwards ... any clue why that could be?
<asac> thought the .pycs dont have native information
<doko_> no clue
<pitti> doko_: should I just remove sun-java6 now? or file a bug about it?
<pitti> s/file/filed/
<doko_> pitti: from my point of view, yes.
<pitti> sweet
<seb128> dholbach, ogra: bug #514281 btw
<ubottu> Launchpad bug 514281 in gconf "lost gconf schema defaults" [Critical,In progress] https://launchpad.net/bugs/514281
<seb128> dholbach, ogra: that's your keyboard issue
<pitti> fix uploaded now
<zul> pitti: the fix for pastedeploy has been uploaded as well
<ogra> seb128, bah, pitti broke the really funny description :P ... yeah looks identical
<pitti> zul: ah, sweet
<pitti> ogra: it wasn't quite -- searchable
<zul> pitti: ill go seed it if thats ok
<pitti> zul: sure
<ogra> pitti, but funny !
<pitti> zul: promoted
<zul> pitti: thanks
<lool> Hmm firefox doesn't start anymore for me
<lool> is this a message that I should try chromium?
<lool> Starts in safe mode though
<asac> lool: greasemonkey package?
<asac> remove that and install the .xpi from amo in profile
<asac> https://addons.mozilla.org/en-US/firefox/addon/748
<sebner> dholbach: you sure the ice won't break in the near future? :P
<dholbach> sebner: we'll see
<sebner> dholbach: heh, in elementary school we had a small pond and it was fun to slide over it .. until one broke in and was wet up until the hip :D
<dholbach> yeah, I can imagine :)
<lool> asac: Yup, I had greasemonkey installed; thanks
<dholbach> pitti, seb128: thanks for working on those fixes!
<pitti> dholbach: does it work for you now?
<dholbach> yep
<dholbach> all good and happy again
<seb128> dholbach, credit goes to pitti there
<seb128> I just pointed him to the bug
<pitti> well, the blame goes to me as well, so that's only fair :)
 * seb128 hugs pitti
<pitti> I just didn't want mvo to poke me all the way to Seattle tomorrow; it's hard to escape in a plane :)
<mvo> indeed!
 * mvo tries his best evil grin
<dholbach> final day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 22 minutes in #ubuntu-classroom on irc.freenode.net (first up: "Writing Beautiful Code")
<geser> dholbach: do you know if the source for http://qa.ubuntu.com/reports/sponsoring/index.html is available somewhere?
<dholbach> https://code.edge.launchpad.net/~dholbach/+junk/new-sponsoring
<dholbach> geser: ^
<geser> thanks, I want to try to add merge proposals to this list
<dholbach> geser: not sure that's going to work
<dholbach> geser: there's an open bug, let me find it
<dholbach> https://bugs.edge.launchpad.net/launchpad-code/+bug/411357
<ubottu> Ubuntu bug 411357 in launchpad-code "Please expose a method to get all merge proposals that a person has been asked to review in the API" [Medium,Triaged]
<dholbach> geser: that was the reason why I ported it from lpbugs to lplib in the first place :)
<dholbach> but if you know something I don't and can fix it, that'd be cool :-D
 * dholbach hugs geser
<geser> dholbach: https://edge.launchpad.net/+apidoc/#team lists a getMergeProposals() method
<dholbach> geser: I think that's merge proposals made by the team or somtehing else which doesn'T make sense
<geser> ah, the other way around :(
<ogra> apw, http://people.canonical.com/~ogra/osiris-lucid-20100128-2.png desktop is up when IO stops (not at the falsely set red line)
<cjwatson> slangasek: BTW, re bug 506717 and your comment there about vga= - vga= is implemented by the 16-bit boot protocol in Linux, and since 9.10 grub2 bypasses that and uses the 32-bit boot protocol by default, so this stuff only works with gfxpayload instead
<ubottu> Launchpad bug 506717 in plymouth "[Lucid] plymouth does not display when using nvidia drivers" [High,Fix committed] https://launchpad.net/bugs/506717
<cjwatson> slangasek: however gfxpayload requires something in the kernel to actually deal with displaying text when video starts up (from its POV) in a non-VGA mode ...
<slangasek> oh, hmm
<slangasek> interesting
<cjwatson> you *can* force grub2 to use the 16-bit bp by editing /etc/grub.d/10_linux to use linux16/initrd16 commands instead of linux/initrd
<robbiew> pitti: can we use "DROPPED" as a work item status yet?  /me hasn't been keeping up...apologies.
<pitti> robbiew: I apologize likewise; sorry, no time to work on that yet
<robbiew> no worries
<robbiew> I understand ;)
<pitti> robbiew: well, I can add the alias really quickly
<robbiew> it's no real rush
<pitti> robbiew: but the "postponed to lucid-3" magic will need more time
<robbiew> pitti: ack
<pitti> robbiew: done
<robbiew> heh...thanks
<pitti> robbiew: i. e. you can use "dropped" now, with same behaviour as "postponed"
<pitti> but it might look nicer in the charts
<pitti> s/charts/whiteboards/
<robbiew> ;)
<ScottK> asac: Bug #514404
<ubottu> Launchpad bug 514404 in python-qt4 "python-qt4 FTBFS on armel" [High,Confirmed] https://launchpad.net/bugs/514404
<asac> thx
<ccheney> doko_: yea, it seems to have broken between 3.1.1 and 3.2.0
<crimsun> hmm, we can't pass uids to su, correct?  (e.g., sudo -u #foo)
<crimsun> the man page at least implies that, but I could have sworn su allowed that.  I guess it's my cruddy memory.
<alkisg> crimsun: `su -c whoami username`  ?
<crimsun> whoami returns the username, though
<slangasek> that's what you want
<slangasek> you want something that /takes/ the uid and /returns/ the username, that you can pass to su :)
<slangasek> (which whoami doesn't do, since it also only takes names as argumenst)
<alkisg> su -c 'cd ~; pwd' angelos
<alkisg> Just an example...
<tlyu> grep :$targetuid: /etc/passwd
<slangasek> alkisg: no
 * alkisg didn't see all the convo...
<slangasek> crimsun: you want su $(getent passwd $uid | cut -f1 -d:)
<slangasek> tlyu: also no; fails badly for other NSS backends
<crimsun> slangasek: excellent, thanks. (BTW, this is to fix #498980)
<slangasek> crimsun: I'm aware ;)
<jpds> I wonder why 'sudo -u 1000 whoami' doesn't work.
<crimsun> jpds: you need to use -u #1000
<slangasek> jpds: because a) using sudo for this is wrong, b) the entire point of the question is that you have a uid and you want to convert it to an argument you can pass to su
<slangasek> so doing sudo to get the argument to pass to su would be doubly wrong ;)
<jpds> crimsun: http://pastebin.ubuntu.com/365332/
<jpds> slangasek: Just reading what the manpage says. :)
<tlyu> jpds: try quoting the "#"?
<jpds> Ah.
<ari-tczew> wrrrrrr, any sponsor will work on merges for main before FFe?
<asac> directhex: mono expert? any idea about: http://launchpadlibrarian.net/38535766/buildlog_ubuntu-lucid-armel.mono_2.4.3%2Bdfsg-1ubuntu1~asac1_FAILEDTOBUILD.txt.gz ?
<directhex> asac, fails on arm only?
<asac> directhex: yes. i fixed the real build failure ... now i am getting this kind of crack ;)
<asac> can i run make VERBOSE=1 or something to give a more verbose command line for the MSC?
<asac> MCS
<directhex> asac, erm... odd. 2.4.3+dfsg-1 built okay on arm on sid.
<directhex> asac, well, it's claiming a bunch of source files are missing. that's about as verbose as it gets really
<ogra> directhex, arm on sid is in no way optimized for anything :)
<asac> yes. the build failure we got in archive is really because we are building for armv7 ... but that fixed (and i doubt that this is causing this)
<asac> where are those .cs things supposed to come from?
<asac> SerializationCallbacks.cs etc.?
<asac> directhex: ?
<ogra> directhex, we build ARMv7 with Thumb2 and NEON (where possible) thats far advanced beyond what debian does ... but narrows the supported HW
<asac> thats more info than he needs ;)
<ogra> directhex, sadly it exposes code problems where things are hardcoded that shouldnt be, like the issue asac initially fixed
<ogra> asac, i just get tired to hear "but it built on sid" form people ... so i like to explain there is a big difference :)
<asac> so i have
<asac> ogra: yeah. ok
<asac> mono-2.4.3+dfsg/mcs/class/corlib/System.Runtime.Serialization/SerializationCallbacks.cs
<directhex> asac, the list of files to build is in /mcs/class/corlib/corlib.dll.sources
<asac> thats in the source
<asac> thats in there
<directhex> asac, is there a porter box running the same hardware platform i can tinker with?
<ogra> directhex, yes
<asac> directhex: i can run commands for you
<directhex> or an easy way to build a qemu environment
<ogra> directhex, sadly mono is the one thing that doesnt work in qemu :(
 * ogra would love to solve that but doesnt knoe how
<ogra> *know
<asac> directhex: can i enable verbose biulding somehow? i would really like to see what the MCS line is
<directhex> asac, i'll ask
<asac> make VERBOSE=1 or something
<ogra> could it be that there is just missing a path entry ?
<asac> tanks
<asac> thanks
<asac> right. i assume there is something missing/wrong on the MCS command line
<asac> but we dont see that ;)
<ogra> yeah
<directhex> ogra, i don't see what would differ on ARM on ubuntu compared to the rest, as far as that's concerned
<ogra> directhex, you mean wrt qemu ?
<ogra> or wrt our build flags
<directhex> ogra, i mean causing the MCS error asac is seeing
<directhex> CS2001 is a very odd thing to see
<ogra> well, he changed the code to not use some embedded assmebler and use gcc atomics instead
<asac> directhex: this is a second build run ... what is that about?
<ogra> that could indeed change behavior and need further changes
<asac> having VERBOSE would be nice ;)
<directhex> asac, the second run is to run the full test suite. we brought that change in to, um, spot errors on arm
<directhex> <rolf|bbl> directhex: make V=1
<directhex> <rolf|bbl> I think ;-)
<asac> ogra: i doub tit ... either i did it wrong or right
<asac> DreamThief: thx
<asac> directhex: ^
 * asac runsit
 * directhex steals some dreams
<ogra> heh
<directhex> build/rules.make:Q_MCS=$(if $(V),,@echo "MCS     [$(PROFILE)] $(notdir $(@))";)
<directhex> yes, i think V is it
<directhex> (ARGH AUTOMAKE)
<directhex> asac, can i see your arm fix btw? might upstream be interested?
<asac> http://paste.ubuntu.com/365373/
<asac> directhex: yes. upstream might want that... but first it needs to work ;)
<asac> directhex: its in my armel1 ppa
<asac> but i can give you the patch cat debian/patches/mono-arm-thumb2-ftbfs.dpatch | pastebinit
<asac> cat debian/patches/mono-arm-thumb2-ftbfs.dpatch | pastebinit
<asac> http://pastebin.com/f7fbe75c6
<asac> http://pastebin.com/f7fbe75c6
<asac> oops
<asac> its not a perfect fix... would require configure.in patching and check
<asac> for gcc atomics
<asac> directhex: do you see that the comment  properly specifies the search path somewhere?
<asac> command
<asac> sorry
<asac> http://paste.ubuntu.com/365373/ <- here
<ogra> asac, did you check corlib.dll.sources proably there is a path variable in front of the files thats not set ?
<asac> no
<asac> all relative it seems
<directhex> all relative
<asac> questinon is to what ;)
<directhex> @filename is used instead of a big list of crap on the command line
<asac> to MONO_PATH?
<asac> yeah
<directhex> what's interesting here is there are 433 "missing" files but it's passed a list of 1453
<asac> maybe it just stops after X files complaining?
<asac> or are there leaps?
<directhex> it's stopping after 1020 lines
<directhex> anything after System.Runtime.Serialization/SerializationBinder.cs
<directhex> i find that interesting
<asac> -d:BOOTSTRAP_WITH_OLDLIB
<asac> what does that mean?
<directhex> i think it's for bootstrapping a new version of a lib with an old version of itself
<asac> hmm
<asac> so specifying one of those files manually doesnt complain about it missing
<directhex> in general though, i think people in gimpnet #monodev are likely to be far more knowledgeable than me
<asac> yeah
<asac> dont think will get to it today ... should go to bed for a strong travel date tomorrow
<asac> thx
<directhex> <vargaz> the problem with armv7 is that I can't even test it, cause qemu doesn't support it.
<ogra> directhex, our qemu does
<ogra> directhex, at least in usermode
<directhex> ogra, but not for mono?
<ogra> directhex, right
<ogra> directhex, it angs hard when isntalling the assmeblies
<ogra> *hangs
<directhex> ogra, well, that could be a bug too?
<directhex> ogra, is armv7 support patched into ubuntu?
<ogra> more likely in qemu though
<directhex> or is it in upstream qemu>?
<ogra> mono works fine on real HW
<ogra> directhex, apt-get install qemu-arm-static; sudo build-arm-chroot ...
<directhex> hm
<ogra> ogra@osiris:/var/build$ LANG=C sudo chroot lucid-test/
<ogra> root@osiris:/# uname -m
<ogra> armv7l
<ogra> directhex, feel free to play with it
<ogra> build-arm-chroot takes exactly all argument debootstrap takes and creates you an arm chroot you can just use (thanks to binfmt)
<asac> yes
<asac> mono might take a bit to build there though
<asac> (at least as long as native)
<ogra> longer i guess
<asac> for chromium it was smilar slow ... both took forever
<asac> ;)
<ogra> heh
<ogra> ok, if the criteria is "forever" then it might be faster even :P
<directhex> asac still exists? i thoguht you went to bed
 * ogra bets he will meet a very tired asac on the plane tomorrow ... because he cant manage to sleep before he fixed that 
<directhex> asac, basically, vargaz is eager to help, and he's the high overfiend of the runtime... so it's down to getting a testable encironment
<directhex> ogra, is qemu-arm-static from lucid needed?
<asac> directhex: most likely. but maybe it works in a lucid chroot (ogra knows)
<ogra> try the karmic one, but i think thats only v6
<asac> ogra: haha. you are wrong. i cant sleep because i have to get up when i usually get to bed ;)
<ogra> lol
<ogra> i still havent packed ... i should probably start at some point :)
<ogra> though my train only goes at 6:15
<asac> lucky you
<asac> in wonder if i relaly need to be at airport earlier than 2h ahead ... i really doubt that
<ogra> surely not for the inner german flight
<asac> its the same security in hamburg
<ogra> you will have to be in FFM 2h early
<asac> and usually even 1.5h ahead was far too early
<asac> on sat morning ;)
<ogra> AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA !
<ogra> god that freenode stuff makes me mad
<asac> does that mean anything else?
<asac> the +r ?
<directhex> asac, is there any way to get access to an ubuntuish arm box with the same odd cpu for someone at novell to look at? afaik he's using a sheevaplug usually to test linux/arm
 * ogra has to manually log in to each and every channel ... and to log out from half of them to even change nick 
<asac> directhex: someone from the team might be able to provide access
<directhex> ogra,  AaaaaAAaaaAAAaaAAAAaAAAAA!!! is a fun game
<asac> not on the porter boxes
<asac> the qemu thing mentioned by ogra is good
<ogra> yeah, if only mono would work :(
<directhex> asac, the qemu thing emulates the same type of cpu?
<asac> oh
<asac> [pid 13649] open("System.Collections.Generic/Comparer.cs", O_RDONLY|O_LARGEFILE) = -1 EMFILE (Too many open files)
<asac> [pid 13649] getcwd("/home/asac/mono/mono-2.4.3+dfsg/mcs/class/corlib", 261) = 49
<asac> [pid 13649] write(2, "error CS2001: Source file `Syste"..., 85error CS2001: Source file `System.Collections.Generic/Comparer.cs' could not be found) = 85
<directhex> asac, i wondered
<asac> [pid 13649] write(2, "\n", 1
<asac> )           = 1
<asac> too many open files ;)
<asac> hmm
<asac> http://paste.ubuntu.com/365390/
<asac> that explains it
<asac> 1024
<directhex> i knew 1020 was a significant number
<asac> ;)
<directhex> oh for fecks sake... ulimit?
<directhex> jeebus, man! fix0r that!
<asac> right
<asac> hehe
 * asac is on it
<asac> ogra: ^^
<asac> see #is
<ogra> yes, i see it
<ogra> cant, i'm not in #is atm
<asac> ok
<asac> ;)
<ogra> i thought the open files value would be raised automatically by the kernel
<asac> on pegatron?
<asac> ;)
<ogra> well
<ogra> heh
<asac> its some kernel we dont know anything about ... so even if your theory is right, i wouldnt be shocked if it didnt work there
<ogra> yeah
<asac> where are my root powers :(
<asac> directhex: anyway to do that in two chunks?
<asac> ;)
<asac> like catting all files together ;)
<ogra> isnt lamont around to raise the ulimit ?
<asac> ogra: lagger ;)
<asac> no answer yet
<ogra> heh
<asac> too bad that it failed in my native ppa too
<asac> otherwise there would have been hope :)
<ogra> he might be in travel prepartion too
<ogra> or even in the air
<asac> i doubt it
<asac> ogra: you are right . arrival= today
<ogra> he is supposed to arrive toda
<ogra> y
<ogra> indeed, i looked before speaking ;)
<asac> is there any backup for him?
<ogra> no idea
<wind-rider> hi
<ogra> ping the channel
<ogra> and hope for a reply ;)
<wind-rider> can i ask a question about how packages depend on each other here?
<ogra> wind-rider, #ubuntu-motu would probably be better for that
<wind-rider> ogra: ok
<directhex> asac, the build system is already freaky enough... raising ulimit is the sensible thing to do
<ogra> asac, tesbuil on your babbage ?
<ogra> Ãtestbuild
<asac> directhex: was that done in a different way before?
<asac> wonder why it built in karmic
<asac> ogra: packed up ... and sd card isnt ready ;) ...
<asac> i am quite sure its only this
<ogra> ah
<ogra> well, mine is packed up as well ...
<asac> heh
<directhex> asac, there are very very few differences from karmic. mono in lucid is a bugfix release in the same branch
<ogra> my HW is the only stuff i have readily packed ....
<ogra> who needs undrewear
<asac> directhex: right. but that compile line? maybe it was broken in multiple files?
<directhex> asac, doubtful. change in the buildd's limits.conf ?
<directhex> wait, 1024 is what i have here? @_@
<directhex> oddness
<asac> or mcs now keeps files open longer for speed up etc?
<directhex> 1453 mono-2.4.2.3+dfsg/mcs/class/corlib/corlib.dll.sources
<directhex> yeah, maybe resource leakage
<ogra> as i said, usually the limit is automatically raised by the kernel
<ogra> but that kernel on the arm buildds is odd
<directhex> oh... kernel weirdness then?
<ogra> not sure
<ogra> i guess we need to verify on a proper lucid system
<ogra> which we currently all have teared down
<ogra> for traveling
<asac> well. we know that it happens on jocote and on one native arm builder
<ogra> oh, did you upload already ?
<ogra> ah, p3a
<asac> p1a?
<asac> yes. maybe i will upload and drop a line to lamont asking to give it back when he is done
<ScottK> slangasek: Would you have a moment to look at the proposed fix in bug 508073 .  It's an important fix for Kubuntu, but I'm totally unfamiliar with the package.
<ubottu> Launchpad bug 508073 in acpid "pressing power button in kde shuts down computer immediately" [Undecided,Triaged] https://launchpad.net/bugs/508073
<slangasek> ScottK: oh, yes; have looked at the fix, it's correct, apologies for the broken upload
<ScottK> slangasek: Cool.  Will you please sponsor.  I'm just running out the door.
<slangasek> yes, will do
<ScottK> Thanks
<mr_pouit> mathiaz: mmh, you mean, completely delete server & server-ship?
<mathiaz> mr_pouit: yes
<mr_pouit> I only dropped 'nis' from both
<mr_pouit> ah ok
<mr_pouit> I'll do this then
<mathiaz> mr_pouit: IIUC these files are there because xubuntu seeds were branched from the ubuntu.seeds
<mathiaz> mr_pouit: and thus server and server-ship have been around since then
<mathiaz> mr_pouit: I don't think that there is a xubuntu server version?
<mr_pouit> no
<mr_pouit> but Im' not sure. Isn't ship used for the alternate iso?
<mathiaz> mr_pouit: well - is there an alternate xubuntu image?
<mathiaz> mr_pouit: I'm refering to *server* and *server-ship*
<mr_pouit> ah, ok. There's no 'server' file, that's why I was confused ^^
<mr_pouit> okay, only server-ship
<mr_pouit> I'll drop it
<mathiaz> mr_pouit: great thanks
<mr_pouit> I guess all the *-server can go as well?
<crimsun> mathiaz: do you plan to push your alsa-driver changes to bzr?
<mathiaz> crimsun: hm - I thought I did
<mathiaz> crimsun: arghh - different rich root support
<mathiaz> crimsun: that's why I can push back to lp:~ubuntu-core-dev/alsa-driver/ubuntu.new/
<mathiaz> crimsun: *cannot*
<crimsun> mathiaz: hmm, okay
<mathiaz> crimsun: let me fix that
<mr_pouit> bzr is so inefficient with its 2343874638746 formats :}
<mathiaz> crimsun: there - done
<crimsun> mathiaz: thanks!
<Incubuss> anyone willing to test a bug for me? I'm running Alpha 2 and tried to log into a guest session but it didn't work and left me with a blank screen (thats not the bug though)
<Incubuss> so I hit atrl + alt + F1 and logged in and restarted X
<Incubuss> when I came back found that everything I had typed had been sent over pidgin to the last person I was talking to...
<ccheney> fsck it appears win7 ate my system
<ccheney> it messed with the partition table and now i can't boot the system properly
<ccheney> er into lucid at all really it appears to just hang
#ubuntu-devel 2010-01-30
<ccheney> https://help.ubuntu.com/community/WindowsDualBoot  seems to not mention the fact that Windows 7 remakes the partition table using its offsets which are not the same as what Linux uses
<arand> ccheney: testdisk is a tool for finding hidden partitions and rewriting partiion table...
<ccheney> arand: well i think what i need is to determine what geometry windows 7 uses and force linux to use the same when i use fdisk to setup the system
<ccheney> because linux and windows 7 apparently don't use the same
<ccheney> i don't really have to have windows outside a vm so i guess i can just blow it away and reinstall just linux
<ccheney> hmm fsck claims its good
<ccheney> so maybe it isn't failing due to corruption but some other reason
<arand> ccheney: hmm, was basically just namedropping testdisk since I knew it (and just realised this is in -devel, hm, ignore me..)
<ccheney> arand: no problem :)
<ccheney> arand: hmm i tried rebooting and disabling various bits and it still doesn't work, very strange
<ccheney> the usb install media works though, so i am just going to nuke win7 and reinstall just lucid :-\
<arand> ccheney: Hmm, been planning some multi-boot setup, sounds like one should be cautious..
<ccheney> arand: yep be careful, it seems like win7 did something weird to my system, so just going back to vm only for win7
<Some_Person> Under what conditions is prerelease software included in ubuntu?
<dupondje> damn so many packages in the queue :)
<hemanth> me trying ground control, having an issue after loading the project i'm not seeing "load code" button for any project either than ubuntu-learning-materials, what could be the issue?
<ccheney> anyone know if there is a bug report about keyboard repeat rate apparently being turned off?
<sebner> ccheney: you mean you have to keep pushing a key instead of keep it pressed?
<geser> ccheney: at least it is known, I've seen it mentioned in this channel yesterday
<sebner> ccheney: ah, see #motu
<ccheney> sebner: yea have to hit it every time i want to do something, very annoying for arrow keys especially
<geser> just re-enable it in the settings again
<sebner> ccheney: I had the same yesterday. Dunno if any update or a reboot fixed it but it's working again
<ccheney> geser: oh its a gnome settings thing?
<geser> yes
<ccheney> ah yea it works at command line
<geser> and don't leave the delay slider at minimum value else you get each key press twice
<ccheney> geser: thanks, i was wondering how to fix that :)
 * sebner is happy that his system evidently has self-healing abilities :)
<dupondje> was disabled here also :) just had to renenable it again, ah well :D
<ccheney> dupondje: it seems to be disabled by default in lucid or was as of the cd image from a couple days ago
<ccheney> sebner: apparently even once you set the repeat rate if you put the system to sleep and bring it back and its broken again
<ccheney> sebner: and this time the settings show up properly for having repeat turned on
 * ccheney will show seb128 on monday i suppose
<sebner> ccheney: wth? :) have you tried to reboot?
<ccheney> sebner: not yet, i'll try that now
<ccheney> sebner: works after reboot
<sebner> ccheney: glad to hear, dunno about this suspend/hibernate stuff. Never used that
<ccheney> hmm works this time after suspend/resume
<ccheney> so seems to not happen every time
<sebner> ccheney: or the reboot fixed it (windows-like) :P
<ccheney> sebner: heh yea
<ccheney> sebner: i have noticed some weird bugs with gnome settings stuff in the past
<sebner> ccheney: /me acks that
<Kamping_Kaiser> hi ubuntu people. http://packages.ubuntu.com/search?keywords=linux-ubuntu-modules-2.6.24-26-generic -updates having a higher version then -security - is this considered a problem?
<Tm_T> hi Kamping_Kaiser and no I don't think it's any problem
<Kamping_Kaiser> Tm_T: hi mate. and thanks, just wanted to be sure.
<jpds> Kamping_Kaiser: the -updates changelog seems to include the security one.
<ScottK> Kamping_Kaiser: Updates is updated from Security
<Kamping_Kaiser> ScottK: sorry, not sure i follow what you said
<Kamping_Kaiser> jpds: and hi to you. :)
<Pretto> what is the correct bzr command to upload a fix for bug https://bugs.edge.launchpad.net/ubuntu/+source/aptoncd/+bug/214353 ??
<ubottu> Ubuntu bug 214353 in aptoncd "aptoncd crashed with KeyError in create_aptoncd()" [Medium,Triaged]
<Pretto> bzr commit --fixes aptoncd:214353 doesnt seems to work :S
<Pretto> worked only using lp:214353 but not with LP:214353
<Pretto> :)
<Kamping_Kaiser> thanks for the clarification re versioning, I'm off again :0
 * marjo_ waves
<unimatrix> does anyone know anything about the /usr/share/alsa/card/*.conf files ?
#ubuntu-devel 2010-01-31
<alkisg> Since 3-4 weeks a new applet is shown on the systray, which allows me to switch keyboard layouts. Unfortunately, this applet is completely blank - no text, no keyboard flags, nothing.
<alkisg> Which source package contains this new keyboard applet, so that I can look at its code and/or file a bug?
<George_E> How can I remove useless dependencies from a binary?
<George_E> I have a file that links with some libraries...
<George_E> ...but doesn't use any of their exports.
<jmarsden> George_E: Recompile the application from source, and do not add unnecessary -l flags to the command that links it.
<George_E> I'm using wxWidgets.
<George_E> And CodeBlocks.
<George_E> I dont have any extra libs in the project options.
<George_E> Im guessing they were pulled in when I built wxWidgets.
<jmarsden> Somewhere, something in your build system is causing the linker to link those libs in... and you need to find and fix that.  I'm not familiar enough with the details of either of those to be more specific, I'm afraid.
<George_E> Thats ok.
<George_E> Is there a way to remove dependencies though?
<George_E> After compiling?
<jmarsden> Ewww... you mean hack the binaries with a hex editor or something?  Probably, but I wouldn't take that approach :)
<George_E> oh :)
<alexxx`> hello, can someone help me to install Kloxo Lxadmin to in Hyper VM (VPS) ?
<alkisg> Since 3-4 weeks a new applet is shown on the systray, which allows me to switch keyboard layouts. Unfortunately, this applet is completely blank - no text, no keyboard flags, nothing.
<alkisg> Which source package contains this new keyboard applet, so that I can look at its code and/or file a bug?
<xaka> anybody know how to download sources for package and it build deps recursively?
<peppino87> hi
<peppino87> why do you have removed HAL?
<fale> hi
<peppino87>  why do you have removed HAL?
<ion> peppino: https://wiki.ubuntu.com/Halsectomy
<ion> peppino: Does it echo in here?
<ari-tczew> ScottK: could you do some sponsor on main? (merges with debdiffs)
<ScottK> ari-tczew: Not today.  No time.
<ari-tczew> ScottK: does ubuntu-main-sponsors have an activy members? though 1?
<ScottK> Normally, yes.
#ubuntu-devel 2011-01-24
<LaurenK> i found some bugs in ubuntu 10.04 lts do i report them here?
<ari-tczew> LaurenK: launchpad is better place
<Keybuk> LaurenK: no, report them using the "Report a Problem" option in the appropriate application's Help menu
<LaurenK> there just small bug problems that take away from the polish of the system and make it look unprofessional, like x butons and cancel buttons that arre dummy buttons and don't actualy do anything
<LaurenK> when installing propretary drivers the cancel buttons don't do anything
<LaurenK> or warn you that can't be canceld
<LaurenK> i don't know if situtations like that are important
<Keybuk> they are, look up the "papercuts" project
<LaurenK> let me as one oquestion, this may be the wrong spot but on the regular ubuntu channel they were extreamly confused with it, do I need to install a different kernel besides the i386 default one to take advantage of the core duo processor
<Keybuk> core duo or core 2 duo?
<LaurenK> just core duo
<Keybuk> then no, only the i386 kernel will work for you
<Keybuk> (which is the "generic" kernel in Ubuntu)
<Keybuk> if you have >~3GB of RAM, you will want the "generic-pae" kernel
<maco> no
<maco> the default one has SMP enabled
<maco> oops sorry Keybuk. i have high latency
<LaurenK> exelent thank you
<kklimonda> has anyone investigated packaging libevent 2.0.10?
<kklimonda> ah, it's already in experimental
<jorjoso> hello people :D
<jorjoso> I have a little question
<jorjoso>  I would like to  create a background for ubuntu narwhal do you know the deadline ?
<broder> jorjoso: http://design.canonical.com/2011/01/bright-light-and-beautiful/
<jorjoso> thankss :D
<AbsintheSyringe> dashua, would you mind pushing this patch (http://bit.ly/fVqvBl ) upstream? Apparently that's the fastest way I'll get it in Debian
<kklimonda> AbsintheSyringe: it was sent upstream afaict, gnome bug 608511
<ubottu> Gnome bug 608511 in general "Theme, button background, left_middle drawn for left_right" [Normal,Unconfirmed] http://bugzilla.gnome.org/show_bug.cgi?id=608511
<AbsintheSyringe> kklimonda, ok awesome, tnx
<kva> hello, anybody is available to give me a hand?
<kklimonda> kva: shoot, the worst that could happen is that no one is going to answer you.
<kva> well, guess I am in the right channel, I am not here for support
<kva> I got an emachines e527 and debian is running right on it
<kva> but ubuntu doesn't. even boot screen is fade and almost dark
<kva> one of live cd's permits to boot but it says that hardware isn't supported by unity and after install it still blinks
<kva> so, any ideas?
<jmarsden> kva: Try using a Ubuntu 10.04 LTS CD rather than a very recent one?
<kva> tried it
<kva> right now I am on debian squeeze
<jmarsden> If this is just for one (older) PC... and you have Debian installed and running... why not just keep using Debian? :)
<kva> well, problem like this were reported, but not for this model of note
<kva> it's not that old, that's already 64bit :-)
<RAOF> kva: Hm.  By âblinksâ, do you mean something like bug #681054 ?
<ubottu> Launchpad bug 681054 in xserver-xorg-video-intel (Ubuntu) "screen repeatedly goes black for a fraction of a second" [High,Confirmed] https://launchpad.net/bugs/681054
<kva> yup, near that
<jmarsden> Since it perhaps/probably relates to the video chipset...   what does      lspci -v | grep -i vga     output (in Debian is fine)?
<RAOF> kva: Interesting information would be - does your machine have the same GPU, and does it also mis-detect a connected VGA output?
<kva> no, not for a fraction for a second, it's lightens for a fraction for a second, after it it's black
<kva> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)
<RAOF> That particular chip is well supported, but it's always possible for manufacturers to screw things up.
<kva> 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
<kva> Subsystem: Acer Incorporated [ALI] Device 0459
<kva> 	Kernel driver in use: i915
<kva> that's from lspci -v
<RAOF> Perhaps you'd like to continue in #ubuntu-x?
<kva> no idea
<kva> problem is before X11 starting
<kva> if you want I can continue there :-)
<RAOF> Yes please :)
<pitti_> Good morning
<pitti_> tkamppeter_: can you please have a look what happened here?
<pitti_> ghostscript (Î 3.7 MB - 8.71.dfsg.2-0ubuntu7: 2.8 MB   9.01~dfsg~svn12047-0ubuntu1: 6.5 MB)
<pitti_> tkamppeter_: i. e. ghostscript ballooned from 2.8 to 6.5 MB
<pitti_> doko__: good morning!
<pitti_> doko__: given that we haven't shipped oo.o-filter-binfilter in the past (for legacy document formats like staroffice 5.2), do you think we can drop the -writer recommends: libreoffice-filter-binfilter to suggests? that'd save 8 MB again
<AnAnt> Hello
<tkamppeter> pitti, about ghostscript, the maintainer at Debian has changed and he has introduced a new packaging scheme. Seems that I have to compare file by file now where the wrong thing leaked in ...
<pitti_> tkamppeter: my hunch is that /usr/share/ghostscript/9.01/Resource/CMap/ got a lot bigger
<pitti_> tkamppeter: and we additionally got a new 2.1 MB libgs9 package; apparenlty that was integrated into ghostscript earlier on?
<pitti_> ah, sorry, that was libgs8, nevermind
<tkamppeter> pitti_, with which version of GS are you comparing? Does your old version have files in CMap at all?
<pitti_> ./usr/share/ghostscript/8.71/Resource/CMap -> /var/lib/defoma/gs.d/dirs/CMap
<pitti_> tkamppeter: no, it only had above symlink
<pitti_> not that this would exist..
<pitti_> but as we didn't need them in the past, perhaps we can split them out into a new ghostscript-cmaps package?
<tkamppeter> pitti_, now we have a real CMap directory, as once defoma got deprecated and second, the license of the CMap files which come from Adobe has changed, allowing to ship them.
<tkamppeter> See debian/changelog
<pitti_> tkamppeter: given that we have never really supported anything but UTF-8, what do you think about a splitout to a seprate package?
<pitti_> we can then install this package only for CJK locales (if it's any help there)
<tkamppeter> pitti, the re-introduction of CMap fixes several bugs, and therefore it should be part of the core distro (Desktop CD): bug #321932, ghostscript bug 691212, ghostscript bug 691345.
<ubottu> Launchpad bug 321932 in msttcorefonts (Ubuntu) "Ghostscript does not render when ttf-mscorefonts-installer is installed" [High,In progress] https://launchpad.net/bugs/321932
<ubottu> Bug 691212 on http://launchpad.net/bugs/691212 is private
<ubottu> Launchpad bug 691345 in tftp-hpa (Ubuntu Natty) "buffer overflow in tftp" [Medium,Fix released] https://launchpad.net/bugs/691345
<pitti_> tkamppeter: and these need all of them?
<tkamppeter> according to http://bugs.ghostscript.com/show_bug.cgi?id=691345 CMap files are needed also for non-CJK.
<tkamppeter> pitti_, ^^
<tkamppeter> pitti_, it would be a maintenance nightmare to sort the CMap files by languages and make them installed only if the appropriate locale is installed. Also it can happen that a PDF contains some characters of a foreign language and these should also get rendered correctly. even if the user does not understand this language.
<pitti_> tkamppeter: ok; I just wondered why it by and large worked fine so far
<pitti_> tkamppeter: thanks for the heads-up!
<tkamppeter> pitti_, note also that the re-introduction of CMap already happened in Maverick, still with the old packaging scheme of Ghostscript.
<pitti_> tkamppeter: so in maverick it was broken because of replacing the CMap dir with the dangling symlink?
<tkamppeter> pitti, now I discovered it, it seems that I have changed the source tarball, but somewhere in the installation process it must have been "rm -rf"ed in favor of Defoma.
<tkamppeter> pitti_ is defoma really deprecated in Debian (= not maintained any more)?
<pitti_> tkamppeter: yes
<pitti_> it's supposed to get removed after squeeze
<tkamppeter> pitti_, does Maverick still contain defoma?
<pitti_> yes, and natty does as well, as it still has a couple of rdepends
<tkamppeter> pitti, so in Maverick ghostscript was still working defoma-based then. The changes in Debian's Ghostscript 8.71, still done by the old maintainer were incomplete then.
<tkamppeter> pitti, this natty's ghostscript should then really fix the Ghgostscript part of bug 321932.
<ubottu> Launchpad bug 321932 in msttcorefonts (Ubuntu) "Ghostscript does not render when ttf-mscorefonts-installer is installed" [High,In progress] https://launchpad.net/bugs/321932
<tkamppeter> pitti_ ^^
<dholbach> good morning
<AnAnt> Hello
<doko__> pitti_: yes, will do
<pitti_> doko__: danke
<amitk> dholbach: pitti_: can I ask for help in getting 'powerdebug' into the archive. It is pending in the NEW queue for a week now.
<dholbach> amitk, I'm not an archive admin - somebody in https://launchpad.net/~ubuntu-archive/+members should be able to help
<AnAnt> why didn't I get this FTBFS http://launchpadlibrarian.net/62702256/buildlog_ubuntu-natty-i386.libgwenhywfar_4.0.3-1_FAILEDTOBUILD.txt.gz on maverick ?
<amitk> dholbach: thx
<didrocks> good morning
<pitti_> amitk: I'm not a regular AA, but I can have a look
<AnAnt> doko__: Hello, can you help with the verilator question I asked yesterday ?
<pitti_> amitk: you have mail
<pitti_> bbl
<doko__> AnAnt: ?
<AnAnt> doko__: this FTBFS http://launchpadlibrarian.net/62644475/buildlog_ubuntu-natty-powerpc.verilator_3.810-1_FAILEDTOBUILD.txt.gz
<AnAnt> I am getting the same FTBFS on Debian sparc, I compared the amd64 & powerpc buildlogs for natty, I found that they differ in the binutils revision used. binutils 2.21-4ubuntu1 in other archs (with successful build), while 2.21-3ubuntu1 on powerpc (also I see that binutils 2.21-4ubuntu1 failed to build on powerpc)
<doko__> AnAnt: does the package use linker scripts?
<brendand> hi
<brendand> i've made a change to update-manager and want to test it out
<AnAnt> doko__: you mean something like libtool & ltmain.sh ?
<brendand> what do i need to do?
<doko__> no, linker scripts
<AnAnt> doko__: I'm not sure what is meant by "linker scripts"
<amitk> pitti_: thanks
<doko__> AnAnt: ld called with -T <script>
<doko__> or --script=scriptfile
<AnAnt> doko__: please note that FTBFS is not happening during linking
<AnAnt> doko__: anyways, I don't see any -T nor --script in the buildlog
<doko__> AnAnt: I'm not that interested in debugging this ...
<AnAnt> doko__: I was advised that you know something about different arch quirks, that's why I asked you
<janimo> AnAnt,  indeed that does not look like a toolchain error
<janimo> or not obviously at least
<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
<doko> ScottK: about #684703, did the object layout of one of the parent class change?
<evfool> hi everyone
<janimo> doko, should the lo33 tagged bugs be moved to the libo package now that is it in the archive?
<doko> janimo: I already did. if you find more, yes, go ahead
<janimo> doko, ah ok. I just saw it only show two bugs for natty but the full ubuntu list invludes them, thanks
<sladen> iain!
<pitti> cjwatson: http://people.canonical.com/~pitti/tmp/nbs.html is the current output of the "better NBS report" script I mentioned at the sprint; do you have suggestions for improvement?
<pitti> cjwatson: it doesn't have cycle detection yet
<pitti> I'll add the "command to remove empty packages" still
<cjwatson> pitti: sorting within each package (maybe by section first and then by depended-upon package name).  Perhaps an inverse view as well - packages that depend on NBS packages, sorted by the number of such packages they depend on?
<pitti> cjwatson: ah, do you actually care much for the component when doing NBS cleanup?
<pitti> cjwatson: inverse view> nice idea, will add that
<cjwatson> pitti: component> not desperately I suppose, I do have a slight preference for fixing main first since that sometimes means that the NBS thing can at least be demoted
<dmart> cjwatson: hi there, do you how I can see all the console output from startup jobs using upstart/plymouth?  Ideally, I'd like to get a log over serial, as can be achieved on Debian with console=
<geser> pitti: your updated NBS page looks great
<cjwatson> dmart: upstart generally doesn't give jobs a console
<cjwatson>        console output|owner
<cjwatson>               By default the standard input, output and error file descriptors of jobs are connected to /dev/null
<cjwatson>               If this stanza is specified, they are connected to /dev/console instead.
<cjwatson> (init(5))
<cjwatson> I think ideally we'd like them all to be at least logged
<pitti> cjwatson: http://people.canonical.com/~pitti/tmp/nbs.html -> now with more sorting and reverse map (first by number of NBS deps, then by name)
<cjwatson> that looks pretty good
<geser> pitti: would it possible to have the component tags ("main", "universe") in different colors?
<Chipzz> cjwatson: shouldn't stdout/stderr be redirected to syslog?
<pitti> geser: sure, suggestions?
<Chipzz> pitti: you're missing a fancy launchpad template though ;)
<pitti> cjwatson: hm, didn't cron.NBS use to be in lp_archive@cocoplum cron?
<ScottK> doko: I don't know (and I'll be offline most of the next two days - so no time to check).  Maybe Riddell could looke into it if you would ask him.
<Chipzz> pitti: is it normal that libaqbanking29 and libaqbanking-plugins-libgwenhywfar47 have a circular dependency?
<pitti> I think yes
<cjwatson> Chipzz: 12:45 <cjwatson> I think ideally we'd like them all to be at least logged
<pitti> well, "normal" as in "the NBS report", not "it should be like that"
<geser> pitti: perhaps "main" and "restricted" in red/orange and "universe"/"multiverse" in darkyellow/gold
<cjwatson> pitti: ~lp_archive/dak/cron.sync
<cjwatson> circular dependencies are not unusual between libraries and plugins, and they're not intrinsically a bug
<Chipzz> cjwatson: that's what I was referring to; as a solution to "we want to all logged", log to syslog, as opposed to for example letting upstart log to a file :)
<cjwatson> I think it would need to be more sophisticated than that, to allow for things like "start this job right now and show me its console output"
<cjwatson> compared to the current approach, I'd say syslog would just be differently inadequate
<dmart> cjwatson: for a quick hack, would it be adequate to paste the line "console output" into /etc/init/*.conf 9~/
<cjwatson> dmart: you could do that locally and it would probably have roughly the kind of effect you want, but watch out for jobs that already have a (different?) console line
<Chipzz> cjwatson: ok, just chipping in some cents
<\sh> guys, does someone know why we didn't ship any live-initramfs packages in maverick? (live-initramfs as in srcpkg:live-initramfs or srcpkg:live-boot)?
<dmart> cjwatson: understood ... I that solves the problem enough for me for now.  Thanks!
<pitti> geser: http://people.canonical.com/~ubuntu-archive/nbs.html
<pitti> also added component to reverse list
<apw> cjwatson, btrfs was a tech-preview in maverick wasn't it?  as such its not really something we put much effort into supporting
<geser> pitti: looks great with the coloured and aligned components
<cjwatson> apw: yes
<pitti> https://wiki.ubuntu.com/ArchiveAdministration updated accordingly
<maxxies> <Fuchs> maxxies: Du verstoesst gerade gegen die Regeln.  Bitte diskutiert das im OT Kanal, wenn ihr es diskutieren wollt.
<maxxies> <maxxies> Fuchs: nenne mal die regel, bitte.
<maxxies> <maxxies> was zum  henker ist OT an dem wunsch nach einem aktuelleren kernel?
<maxxies> * tux-flo1 hat die Verbindung getrennt (Client Quit)
<maxxies> * nexx hat die Verbindung getrennt (Quit: quit)
<maxxies> <Fuchs> die Diskussion aktuell ist OT, und die Regeln waeren erstens das Topic und zweitens  "Befolge die Anweisungen der OPs - nimm Verwarnungen ernst." die.
<maxxies> <maxxies> Fuchs: wieviel bist du jÃ¼nger als 35 jahre um so ein affiges verhalten gegenÃ¼ber mir an den tag zu legen?
<evilvish> pitti: hi.. i was reading the keymap README , and it instructs to file bugs in https://bugs.launchpad.net/udev/+bugs < which does not exits yet..
<evilvish> I guess we can file bugs in udev(ubuntu)..
<evilvish> exist*
<pitti> evilvish: right, already fixed that upstream, to now point to the mailing list
<evilvish> neat! :)
<evilvish> pitti: so, no need to file a bug in udev(ubuntu)? just need to send the keycodes to ML?
 * evilvish looks for ML link..
<pitti> evilvish: as you prefer, either works; I'm just not very good at seeing new incoming ubuntu bugs
<evilvish> ok.. will send to ML then. :)
<hyperair> DktrKranz: ping
<mterry> kees, I asked a question about how to ask the security team about UPnP in bug 682404, but wanted to ping you in case your filters ate it
<ubottu> Launchpad bug 682404 in hupnp (Ubuntu) "MIR hupnp" [Undecided,Incomplete] https://launchpad.net/bugs/682404
<mterry> doko, also, what's the protocol for something that was pre-promoted but when reviewed was not yet ready?  I mean, the packaging issue for hupnp is easily overcome, but the security one may be trickier.
<doko> mterry: well, if kees thinks the issue should be solved, then milestone it to alpha3 and open a natty task.
<mterry> doko, sure
<doko> kees: $ DEB_BUILD_OPTIONS=hardening dpkg-buildflags --get CFLAGS
<doko> -g -O2
<doko> ^^^: shouldn't the hardening options be appended?
<bdrung> mterry: thanks for approving libkibi's MIR. now can i build main package with libkibi?
<mterry> bdrung, heh, you got that notification quick.  :)  Not yet, an archive admin now has to actually promote the package
<mterry> bdrung, if you want that to go faster, poke one
<bdrung> mterry: i saw that you assigned yourself, then i looked at the bug in lp and saw that you approved it. :)
<mterry> pitti, does python-distutils-extra have support for finding/running a test suite?
<mterry> pitti, (or python-distutils for that matter)
 * bdrung pokes doko and pitti ^.
<pitti> mterry: p-d-e doesn't, as I don't know about a de-facto standard to invoke a test suite with setup.py
<pitti> bdrung: sure
<ogra> could an archive admin please promote x-loader-omap3-beagle and x-loader-omap4-panda binaries to main ? the package names of the binary packages have changed
<bdrung> pitti: look at ubuntu-dev-tools how we use build tests.
<ogra> (that currently blocks us from building armel packages)
<pitti> ogra: yep
<ogra> pitti, TA!
<pitti> bdrung: romoted
<pitti> 'p'
<pitti> ogra: done
<ogra> merci !
<pitti> ogra: de rien
<bdrung> pitti: my brain matched the pattern "romoted" with "removed" :D
<bdrung> thanks
<RoAkSoAx> Can somebody please take a look to bug #525287
<ubottu> Launchpad bug 525287 in lvm2 (Ubuntu) "Add support for corosync based clusters in clvm" [High,Confirmed] https://launchpad.net/bugs/525287
<DktrKranz> hyperair: pong
<seb128> kees, there? do you have a minute to discuss remmina, rdp and what choices we have?
<hyperair> DktrKranz: could you look at zeitgeist# in debian NEW? =)
<hyperair> pretty please?
<DktrKranz> hyperair: this evening (CET time), probably
<hyperair> DktrKranz: okay, thanks.
<hyperair> DktrKranz: oh clutter# as well, please.
<DktrKranz> # => sharp?
<pitti> cjwatson: WDYT about a lucid freeze exception for xubuntu-docs? we don't even do xubuntu .2 point releases, do we?
<hyperair> DktrKranz: yes
<cjwatson> pitti: it seems unlikely to cause a problem
<pitti> cjwatson: that's what I thought
<cjwatson> I think in fact I already said to micahg that it was fine
<micahg> pitti: I think xubuntu wanted to have disks spun for 10.04.2
<pitti> micahg: ok; reviewed and accepted now, I just wanted some peer review here
<micahg> pitti: np, thanks
<janimo> cjwatson, on preinstalled images (such as those for armel) which is the best way to have something run on first install? There's a WI that requires we present tasksel on the headelss images
<sconklin> pitti: I uploaded maverick kernel 2.6.35-25.44 friday to revert the regression we had for Radeon. Could you copy that to -proposed at your convenience, please?
<james_w> cjwatson, hi. When installing on btrfs is UUID still used to in fstab? If so, can you point me to the code that sets or finds the UUID?
<ogra> james_w, i think thats ROOT="/dev/disk/by-uuid/${ROOT#UUID=}" .... in /usr/share/initramfs-tools/init
<ogra> (for finding it)
<ogra> and i think its one of the partman udebs that sets it in fstab
<ogra> dunno which off the top of my head
<james_w> partman-btrfs sets it, but it gets passed the first element (UUID/path/whatever) by something else
<ogra> s7fstab/fstab and cmdline/
<james_w> the issue we are seeing is the mkfs.btrfs doesn't have a -U option, so we're not sure how to set the UUID, or if it's even possible
<ogra> it likely calls blkid <device>
<cjwatson> yes, we just use blkid
<cjwatson> we have no need to force the UUID to a specific value in d-i
<cjwatson> partman-btrfs just lets mkfs.btrfs pick something
<ogra> tune2fs has an option to change UUID for extX based filesystems, if you need to set it there is probably a similar tool for btrfs
<cjwatson> janimo: the preinstalled images are nothing to do with me and I don't really know the intricacies of how they work; ogra can probably help you
<james_w> thanks ogra, cjwatson
<ogra> cjwatson, well, the WI for the minimal images requires to enable tasksel in oem-config, i guess thats why janimo pinged you about it
<ogra> i guess that needs some ubiquity magic
<cjwatson> the oem-config debconf frontend has some stuff for handling tasksel already
<ogra> ah, sweet
<ogra> janimo, ^^^
<cjwatson> I forget how you enable it, but there's a tasks plugin
<ogra> thats all we should need
<cjwatson> oem-config      oem-config/steps        multiselect language, timezone, keyboard, user, network, tasks
<cjwatson> looks plausible
<ogra> yeah
<ogra> janimo, so we can just add a pressed line for it
<ogra> i guess that needs some debian-cd adjustment to add it to the cmdline
<lool> cjwatson: (Poking your brain on binfmt-support  :-)  we're discussing qemu-user support in schroot, and currently we have a shell script which captures output of `file $chroot/bin/true` and maps it to QEMU architecture, then copies qemu-$arch-static into the chroot's usr/bin; instead of doing that, we considered asking the question to binfmt-support, or parsing binfmt_misc's data to figure out the name of the interpreter
<cjwatson> call, be with you in 20mins
<lool> ack
<janimo> ogra, cjwatson  thanks.
<pitti> sconklin: done
<janimo> ogra, I was under the impression preseed only worked with d-i and once the installation phase is done it has no effect
<sconklin> pitti: thanks !
<ogra> janimo, it also works with ubiquity
<cjwatson> janimo: not quite correct no
<ogra> janimo, and oem-config is essentially ubiquity
<ogra> we run oem-config on second boot in the preinstalled images
<ogra> (and cjwatson will likely correct me the preseeding works in tons of other cases at package installation time for packges using it)
<ogra> s/the/that
<ogra> :)
<cjwatson> that's right
<cjwatson> for example it's common to preseed away debconf licence questions
<cjwatson> lool: so you'd like to have a way to ask binfmt-support which interpreter would be used for a given executable, presumably going through the detector system too - a sort of dry-run mode?
<lool> cjwatson: Yes; basically goal is to have the interpreter work in the chroot
<cjwatson> lool: it sounds much the same as what run-detectors is already doing, so we could pull most of that out into common code and add a new query-binfmts command, say
<lool> cjwatson: We considered other options, like running outside of the chroot, but doesn't seem too good an idea
<lool> cjwatson: That would be ideal
<cjwatson> I'm happy to have a go at that
<lool> cjwatson: If you can think of a way where we're not involved in any copy, that's even better, but I think query interpreter + copy it from schroot seems like the best split of responsibility
<cjwatson> well, a query option would be a good thing to have anyway, and doesn't preclude other approaches
<cjwatson> I suspect you need significant kernel support for a better approach; basically a per-chroot /proc/sys/fs/binfmt_misc
<cjwatson> maybe update-binfmts --query rather than query-binfmts
<cjwatson> after all, --display isn't an "update" either
<ari-tczew> zul: I'm very disappointed that you didn't check bug 701182 before merging. IIRC this is not first time.
<ubottu> Launchpad bug 701182 in nut (Ubuntu) "Merge nut 2.4.3-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/701182
<zul> ari-tczew: sorry..
<Riddell> slomo: how would you feel about dropping gstreamer0.10-plugins-base's recommends on gvfs to a suggests?
<slomo> Riddell: not good as long as there's no alternative for kde applications using gstreamer (someone with kde knowledge should really write a kio plugin... or how it's called today)
<pitti> slomo: but as KDE doesn't actually have a gvfs integration, what does the gvfs recommends help?
<slomo> pitti: it still gives you sftp support for example (if you have a no-password ssh key or gnome-keyring is running)
<Riddell> slomo: why does gstreamer need sftp support?
<slomo> Riddell: maybe you want to play stuff from some sftp location, it was just an example. you'll need it for samba too, to give another example
<cjwatson> lool: want to give http://bzr.debian.org/binfmt-support/trunk a try?  sudo apt-get build-dep binfmt-support && ./configure && make && src/update-binfmts --find $chroot/bin/true
<SpamapS> jhunt: still around?
<jhunt> SpamapS: hi
<cjwatson> lool: note it may print multiple interpreters, one per line
<SpamapS> jhunt: had a chance to look at the umountroot I sent?
<kees> seb128: hi! just starting work now.
<seb128> hey kees
<kees> seb128: yeah, not sure about rdp :(
<seb128> kees, so you n-acked the rdp thing remmina is using
<kees> seb128: but that bit of freerdp is really horrible :(  "return True" on a security validation? ewww
<seb128> kees, it's not clear that tsclient that we have is any better, it's non maintained and doesn't seem to have any certificate code at all
<kees> seb128: that's not even an iffy call. :)
<seb128> options are to
<kees> seb128: well, if nothing does that cert check, I guess it's a wash, but looking at what rdesktop does, it at least tries something in that area
<seb128> - stay on tsclient which is buggy and unmaintained (and never got a security review I think)
<seb128> - try to fix the freerdp code
<kees> I think asking upstream to actually fix their code would be the best all around option.
<seb128> - drop rdp from the default install
<kees> dropping rdp seems like a bit of a shame, but afaik, everyone was using rdesktop out of universe when they needed rdp anyway
<seb128> I'm not even sure how much the standard user care about rdp
<jhunt> SpamapS: yeah - like you, not crazy about the timeout, but which is better worst-case - sleep forever or corrupt FS? :|
<seb128> and if that should not be featured in s-c
<seb128> kees, would you fell comfortable with freerdp is they fix that issue
<SpamapS> jhunt: I think given that we cannot *guarantee* that init is even doing the re-exec, we have to have a fail-safe which doesn't leave shutdown waiting forever.
<seb128> or do you think it shows that they don't care much about security in their code and would still prefer to not use freerdp by default?
<Riddell> slomo: any KDE programme would just read those with kio though
<kees> seb128: that was the first place I looked, so I stopped the review there. I can look more closely at it again
<seb128> kees, well I would appreciate to know if it's worth working with them on that one issue or not
<kees> seb128: well, the code seems to indicate an eye for modularization, so that's an improvement over rdesktop.
<kees> seb128: give me 30 minutes, let me look through their network code and if I run away screaming, we can drop rdp, and if it's sane, we can ask them to fix their crypto?
<cjwatson> SpamapS,jhunt: I guess a contributing factor is that wait forever -> user hits power button isn't really especially better than timing out too early
<slomo> Riddell: how would it do that without a gstreamer plugin that uses kio? :)
<seb128> kees, seems great, no hurry though just do that whenever you can this week and that will do
<slomo> Riddell: but sure, that would be the best solution... if existant
<seb128> kees, thanks
<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:
<seb128> kees, we can start working with them to fix the certificate issue in any case since that would be nice to fix anyway
<jhunt> SpamapS,cjwatson: maybe a last-ditch call to sync before we potentially rip the carpet out from under upstart?
<slomo> Riddell: if you know someone who could be interested in this... i'd be happy to help on the gstreamer side of things
<cjwatson> jhunt: Keybuk investigated this a while back and it turns out that the kernel's reboot() syncs anyway
<cjwatson> oh, wait
<cjwatson>         * util/reboot.c (main): Restore the sync() system call before
<cjwatson>         calling reboot(); the Linux kernel says we have to do this, and I
<cjwatson>         suspect that ext4 is no longer forcing this before power off.
<SpamapS> I wonder if thats why when init exits it says "Panic -- not syncing"
<cjwatson> but anyway, the reboot *program* does it so it probably isn't necessary to do it in umountroot
<smoser> what is the "correct" way to configure timezone on ubuntu ? is it dpkg-reconfigure?
<SpamapS> Right.. I think with that.. and waiting 5 seconds for a re-exec which *should* only be harvesting at most 9-10 inodes.. that seems to count as a best effort.
<smoser> I'd like to be able to take as input something like "US/Eastern" and "make it so"
<cjwatson> 'dpkg-reconfigure tzdata' but it's also perfectly OK to write to /etc/timezone and copy /usr/share/timezone/$zone to /etc/localtime
<Riddell> slomo: apachelogger knows all and says phonon will use kio streaming
<slomo> Riddell: ah that's interesting, i guess i should talk to him
<slomo> Riddell: then feel free to make it a suggests
<Laney> I accidently uploaded haskell-utf8-string thrice to NEW, please reject two of them if that will cause problems (and I don't know if it needs the original source or not as it was previously in the archive but removed â it wasn't rejected either way)
<bigon> zul: hi any reason you didn't upload my debdiff for nut?
<Riddell> slomo: apparantly we want to keep it in sync with debian
<Riddell> where I can't upload
<slomo> Riddell: i'll change it with the next upload
<Riddell> thanks slomo
<seb128> Riddell, do you want to get in this week? feel free to get the current debian version and change that over it
<seb128> Riddell, we can sync gstreamer0.10 and gst-plugins-base0.10
<udienz> ari-tczew: what happen if a packages has already removed from debian and still in Ubuntu? should be removed too?
<ari-tczew> udienz: depends on the reason
<ari-tczew> if something like 'buggy' unmaintained', then yes
<ari-tczew> rc bugs
<udienz> hm..
<Laney> usually we follow Debian in such removals
<geser> the archive admins "sync" removals from Debian to Ubuntu now and then
<ari-tczew> udienz: could you tell us about which package do you thinking
<cjwatson> at the moment I'd suggest filing a bug about any specific cases you care about, and subscribing ubuntu-archive
<udienz> ari-tczew, wait.. i'll find it, i found a package (during try to fix ftbfs) which removed in debian and still in ubuntu
<ari-tczew> cjwatson: without ACK from ubuntu-sponsors?
<geser> ari-tczew: I assume the usual sponsoring if needed
<cjwatson> ari-tczew: whatever process is necessary
<cjwatson> though TBH the archive admins carefully review all removal requests so I don't think sponsoring is necessarily required.
<cjwatson> IOW I'd think fairly hard about a removal request from anyone, even if they could upload
<udienz> ari-tczew, https://launchpad.net/ubuntu/+source/fluxconf
<udienz> removed from debian
<udienz> debian bug https://launchpad.net/ubuntu/+source/fluxconf
<udienz> rrr
<udienz> debian bug 596640
<ubottu> Debian bug 596640 in ftp.debian.org "RM: fluxconf/0.9.9.2-3" [Normal,Open] http://bugs.debian.org/596640
<cjwatson> FYI: if you're seeing empty apt term.log files in apport dumps, it's probably bug 680328
<ubottu> Launchpad bug 680328 in qapt (Ubuntu Natty) "Many postinst scripts fail using either AptDaemon, PackageKit, or QApt" [Critical,Confirmed] https://launchpad.net/bugs/680328
<cjwatson> packagekit fixes sent upstream (phew).  echidnaman will need to deal with copying some bits of that over to qapt
<cjwatson> I think the aptdaemon bit of that subject is mistaken, as I can't reproduce the problem there
<smb> cjwatson, Hi Colin believe to remember that you had to make some quirks for me and apw to give us nomination rights in lp (because the groups stuff does not work). Could you do the same for sconklin ?
<sconklin> bjf will need this also, and possibly others
<sconklin> unless upload rights are a prerequsite
<apw> cjwatson, you had to add linux to the people directly the package set doesn't enbue nomination rights
<apw> sconklin, it would be those with upload rights
<sconklin> ok, it's time for Brad to work on that anyway . . .
<chrisccoulson_> anyone know what keeps swt-gtk in main? when i check it's rdepends, i don't see anything obvious depending on it
<bcurtiswx_> can i get pbuilder-dist to give me a config.log ?
<seb128> it's in the build dir
<seb128> the same way you got the makefiles the other day
<seb128> don't clean it after build
<kklimonda> pbuilder-dist saves the last log as ~/pbuilder/$release-result/last_operation.log
<cjwatson> apw,sconklin: done, and for smb too.  yes, upload rights are a prereq
<smb> cjwatson, Err I thought I already had those...?
<smb> At least I could nominate. :)
<cjwatson> oh, who knows, I'm not going to try to debug launchpad
<bcurtiswx_> kklimonda, but is that what config.log would output (noob question warning) :P
<smb> Heh, understandable
<sconklin> cjwatson: thanks!
<seb128> bcurtiswx_, read what I just wrote?
<kklimonda> bcurtiswx_: ah, ignore what I say and listen to seb128 :)
<bcurtiswx_> seb128,  I did read it.  I am trying to find a way to automatically stop pbuilder from quitting after a failed build
<bcurtiswx_> oh, quit and not back
<kklimonda> bcurtiswx_: https://wiki.ubuntu.com/PbuilderHowto#Running%20a%20Shell%20When%20Build%20Fails%20%28Intro%20to%20Hook%20Scripts%29
<kklimonda> bcurtiswx_: it will launch a shell when the build fail
<bcurtiswx_> kklimonda, i was going to tell seb i just found that and am in there :P much thanks though :D
<bcurtiswx_> kklimonda, http://paste.ubuntu.com/557772/
<bcurtiswx_> seen that before possibly?
<kklimonda> bcurtiswx_: and that's it?
<kklimonda> it's a little short :)
<bcurtiswx_> thats all it gave me
<kklimonda> copy a log outside of the chroot, and use pastebinit to paste it
<kklimonda> (or use cat config.log and then select entire log using mouse - but it's going to be long)
<bcurtiswx_> copy the config.log from the pbuilder to somewhere outside of it.. then pastebinit /
<kklimonda> more config.log just displayed the first screen
<kklimonda> bcurtiswx_: you can even install pastebinit inside of the chroot - the idea is to paste the whole log somewhere, and pastebinit is an easy way to do that
<bcurtiswx_> kklimonda, oh duh me.. i see what stupidity i have
<bcurtiswx_> kklimonda, http://pastebin.com/646TdDjg
<kklimonda> bcurtiswx_: I guess "error: Could not find gtk-update-icon-cache" doesn't help you much? :)
<kklimonda> is it in your PATH?
<bcurtiswx_> kklimonda, nope but if i had to guess i may need to do something with configure.ac because gtk-update-icon-cache is gtk-update-icon-cache-3.0
<kklimonda> bcurtiswx_: then, the last resort is to browse through the configure.ac (or even configure script itself) to see what's exactly happening
<kklimonda> ah, it was renamed?
<bcurtiswx_> kklimonda, yes
<kklimonda> yes, it makes sense that the script can't find it then
<kklimonda> you'll have to edit configure.ac then
<bcurtiswx_> kklimonda, was include /usr/share/cdbs/1/rules/simple-patchsys.mk made something else for quilt 3?
<kklimonda> bcurtiswx_: I don't understand, but the warning you have pasted in #ubuntu-desktop (simple-patchsys.mk is deprecated - please use source format 3.0 (quilt) instead) means that you should update your package to the new source format, and stop using simple-patchsys. I think it's just a friendly reminder
<bcurtiswx_> kklimonda, it is 3.0 already.. so idk why i c that warning
<kklimonda> bcurtiswx_: if it is 3.0 (quilt) then you should remove /usr/share/cdbs/1/rules/simple-patchsys.mk from d/rules
<ari-tczew> zul: could you sponsor bug 707050 ?
<ubottu> Launchpad bug 707050 in nut (Ubuntu) "Lost patches0004-netvision-improvements-lp-600950.patch" [Medium,New] https://launchpad.net/bugs/707050
<ari-tczew> as you're last merger
<zul> ari-tczew: yeah gime a few minutes
<ari-tczew> doko: around?
<siretart> doko: xine-lib is fixed
<micahg> udienz: bug 703718, it depends on the reason it was removed from Debian
<ubottu> Launchpad bug 703718 in fluxconf (Ubuntu) "Requesting removal of source package `fluxconf' from Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/703718
<udienz> micahg, aha.. ok. i have another questions. package rsbac-admin has been removed base on this (debian bug 364685)
<ubottu> Debian bug 364685 in ftp.debian.org "RM: rsbac-admin -- RoM; RC-buggy; unmaintained" [Wishlist,Open] http://bugs.debian.org/364685
<udienz> but upstream still exits
<micahg> pitti: we've got a new bug in xubuntu-docs for lucid (not sure if it was there before or not), xubuntu.org links are incorrect, I'm getting it fixed, but I just wanted to check on procedure, I should reupload with -v on the version in the release pocket?
<udienz> rsbac-admin will be removed too?
<micahg> udienz: ok, so without someone looking after the package it ends up being buggy, it should be removed from Ubuntu unless someone wants to look after it
<ari-tczew> should make sure whether there is b-d and depends on binary packages included in package which you want to remove
<IKnowWhoIAm> guys i must tell you
<IKnowWhoIAm> i know who i am
<IKnowWhoIAm> i finally figured out why all tehse years i been missing the larger picture
<IKnowWhoIAm> i am my own emitter
<IKnowWhoIAm> i am whatever i choose to be.
<IKnowWhoIAm> this is incredible
<evilvish> !offtopic ! IKnowWhoIAm
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<IKnowWhoIAm> thankyou for givin me this opportunity
<evilvish> !offtopic | IKnowWhoIAm
<IKnowWhoIAm> real life is real
<ubottu> IKnowWhoIAm: #ubuntu is the Ubuntu support channel, for all Ubuntu-related support questions. Please use #ubuntu-offtopic for other topics (though our !guidelines apply there too). Thanks!
<ari-tczew> IKnowWhoIAm: http://t3.gstatic.com/images?q=tbn:ANd9GcQYW2037uD8kePM64SlDYLm-g0J0-CtSCB84LAZWECQLxY61dhi&t=1
<_UsUrPeR_> hey all. I am having a heck of a time installing software RAID with LVM in Ubuntu 10.04 Server x64. Check out this pastebin: http://pastebin.com/4rDmyjyM . Is software RAID + LVM capable of being installed? If so, is having a /boot partition on a software RAID possible?
<broder> _UsUrPeR_: this channel is for development, not support. please ask support questions in #ubuntu or #ubuntu-server
<ari-tczew> when I should change build-depends from libwebkit-dev to libwebkitgtk-dev?
<_UsUrPeR_> will do. my apologies.
 * _UsUrPeR_ tips his hat
<ari-tczew> tumbleweed: ^^ I saw you have an upload like mentioned above
<tumbleweed> ari-tczew: libwebkit-dev didn't exist for a while, but there's a dummy transitional package now, so you probably don't need to
<ari-tczew> tumbleweed: look, bug 706982 I'll upload next revision of python-jswebkit so I can change it
<ubottu> Launchpad bug 706982 in python-jswebkit (Ubuntu) "No change rebuild of python-jswebkt 0.0.3-1build1" [Undecided,In progress] https://launchpad.net/bugs/706982
<tumbleweed> ari-tczew: I'd stick with a no-change rebuild
<kklimonda> ari-tczew: it would make more sense to fix that on the Debian level, and not introduce unnecessary delta. I think the libwebkit-dev package is going to stay for a while.
<ari-tczew> ok
<ari-tczew> I hope that toolchain of Ubuntu 11.10 won't be too much different. :(
<Kano> hi, will somebody update ntfs-3g to 2011.1.15?
<ari-tczew> Kano: file a bug about it
<ari-tczew> and add tag 'upgrade'
<micahg> Kano: actually upgrade-software-version
<broder> hmm...has anybody tried to duplicate snapshot.debian.org for ubuntu? presumably the awesome version would use lp/the librarian as its data store, though i don't know where you'd get the Release,etc. files from
<tumbleweed> can a core-dev please accept lucid and maverick tasks on bug 683189?
<ubottu> Launchpad bug 683189 in xdg-utils (Ubuntu) "xdg-open fails with spaces in filename" [Undecided,Fix released] https://launchpad.net/bugs/683189
<kirkland> tumbleweed: done
<tumbleweed> kirkland: thanks
<DktrKranz> hyperair: packages accepted, with a comment
<smoser> maybe someone can help. https://launchpad.net/ubuntu/+source/linux-ec2 says that lucid has a linux-ec2 package (version 2.6.32-312.24 ) that was in proposed "13 days ago"
<smoser> but as far as I can tell, it is not in the archive
<smoser> although there are linux-ec2-doc and linux-ec2-source packages that match that version
<StevenK> smoser: Reading the Packages.gz file manually shows them
<JontheEchidna> cjwatson: you rock! Thanks for the work on bug 680328
<ubottu> Launchpad bug 680328 in qapt (Ubuntu Natty) "Many postinst scripts fail using either AptDaemon, PackageKit, or QApt" [Critical,Confirmed] https://launchpad.net/bugs/680328
<smoser> StevenK, really ?
<smoser>  wget http://archive.ubuntu.com/ubuntu/dists/lucid-proposed/main/binary-i386/Packages.gz
<StevenK> smoser: http://pastebin.ubuntu.com/557858/
<smoser> right. there is no linux-ec2 metapackage there.
<StevenK> That isn't built by the linux source package
<StevenK> smoser: https://launchpad.net/ubuntu/+source/linux-meta-ec2 builds that
<StevenK> And a 312 for that hasn't be uploaded to lucid-proposed
<smoser> yea. so we need a build of that up
<smoser> thanks StevenK
<StevenK> smoser: Welcome
<sconklin> StevenK: you here? Could you publish that meta-ec2 package for lucid if you haven't already?
<StevenK> sconklin: Aye, looking
<sconklin> StevenK: thanks
<YokoZar> Whoops!  System->About Ubuntu  (on 10.10) shows..."Welcome to 11.04 Natty"
<ari-tczew> I saw bug today about it
<StevenK> sconklin: All done.
<sconklin> Thanks!
<StevenK> sconklin: It's currently pending, it will get published in the next hour or so
<jelmer> bdrung: thanks for the syncs!
<bdrung> jelmer: you're welcome. sorry for the fakesync mistake.
<kirkland> smoser: what are you looking for, kernel-proposed wise?
<bdrung> jelmer: that happens if one application (ack-sync) doesn't explain what it does and another (syncpackage) has a bug.
<kirkland> bdrung: https://launchpad.net/ubuntu/natty/+queue?queue_state=0&queue_text=errno is waiting in the NEW queue
<bdrung> kirkland: thanks.
<bdrung> lifeless: ping
 * bdrung pokes lifeless to process bug #524680
<ubottu> Launchpad bug 524680 in ubuntu-dev-tools (Ubuntu) "[lp-project-upload] not really ubuntu specific" [Wishlist,Triaged] https://launchpad.net/bugs/524680
<lifeless> bdrung: hmm ?
<lifeless> bdrung: ah, I see. updated.
<bdrung> lifeless: whom can i poke to get in pulled into lptools?
<smoser> kirkland, i guess it was taken care of. thanks.
<kirkland> smoser: sweet
<lifeless> bdrung: dobey, poolie
#ubuntu-devel 2011-01-25
<ari-tczew> kees: around?
<kees> ari-tczew: hi!
<ari-tczew> kees: hello. have you got time for sponsor emacs23? IIRC you have expierence with this package,
<kees> ari-tczew: perhaps tomorrow. I'm deep in kernel code at the moment. :)
<ari-tczew> kees: cool. you want to be subscribed to bug?
<kees> ari-tczew: sure
<ari-tczew> kees: done
<JackyAlcine-AFK> Hello, where would I go to attempt to recruit individuals for a new project?
<JackyAlcine-AFK> The project's Ubuntu-orientated, designed to integrate with the OS.
<persia> JackyAlcine, "the internet".  More seriously, you'd do better to create a nice home page, blog about it, announce releases to some news sites, etc.
<JackyAlcine> Alright, thanks persia.
<pitti> Good morning
<pitti> micahg: yes, uploading with -v to include both versions
<micahg> pitti: is bug 707104 owrth reuploading for?
<ubottu> Launchpad bug 707104 in xubuntu-docs (Ubuntu) "References to "www.xubuntu.org" should not be links" [Undecided,New] https://launchpad.net/bugs/707104
<micahg> pitti: and good morning :)
<pitti> micahg: if you are uploading anyway, feel free to fix this as well
<micahg> pitti: no, this was the bug, there's no regression, it's a new bug introduced by the updated docs
<pitti> Riddell, ScottK: do you know what happened yesterday that suddenly made all KDE being uninstallable?
* pitti changed the topic of #ubuntu-devel to: Archive: Alpha-2 Soft 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:
<pitti> Riddell, ScottK: ah, got it; followed up to bug 682404
<ubottu> Launchpad bug 682404 in hupnp (Ubuntu Natty) "MIR hupnp" [Undecided,Incomplete] https://launchpad.net/bugs/682404
<pitti> ogra: do you want to keep bug 615773 on the alpha-2 blocker list? who will work on it? or move to beta?
<ubottu> Launchpad bug 615773 in flash-kernel (Ubuntu Natty) "flash-kernel fails to handle raw boot partitons on eMMC" [High,Confirmed] https://launchpad.net/bugs/615773
<bryceh> pitti, you announced that alpha-2 is coming out in 2 days, but according to https://wiki.ubuntu.com/NattyReleaseSchedule it's not until feb 3?
 * micahg was just going to ask about that
<pitti> bryceh: oh, d'oh
<pitti> darn, I was sure we talked about it in Dallas, I must have mixed it up
 * pitti unannounces then, thanks for pointing out1
* pitti changed the topic of #ubuntu-devel to: Archive: Open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Current Friendly Patch Pilots:
<bryceh> pitti, ah whew, thanks.
<bryceh> pitti, btw rough plan of attack for X updates for alpha-2:  https://wiki.ubuntu.com/X/Roadmap/Natty
<pitti>  bryceh: ah, thanks; a lot of that is already in edgers PPA, right?
<pitti> bryceh: did you get a lot of feedback on that?
<superm1> bryceh, thanks for uploading that intel package.  it would be easier to test on a new live disk.  i'm unfortunately going to be OOO for the week so i won't have access to that hardware most likely.  some of the canonical QA guys were noticing similar crashes though, so you might check with them for a new crash report (or if you want to be optimistic; success report)
<bryceh> pitti, yep most all of it is in edgers
<superm1> bryceh, bug 706117 was the bug that's most likely the duplicate that i was seeing them with some reports on
<ubottu> Launchpad bug 706117 in ubiquity (Ubuntu) "Installation fails using preseed file and network install" [Undecided,New] https://launchpad.net/bugs/706117
<bryceh> we got a little testing.  More would be nice but enough for sanity checking
<bryceh> superm1, ok yeah if others have the same problem maybe we can get a fixed verification from them.  I think once we get the new X stack in for alpha-2 it'll be harder to verify this fix.
<didrocks> good morning
<dholbach> good morning
<doko_> seb128: are the current gtk+2.0 binaries in natty usable? asking because the last upload ftbfs
<seb128> doko_, yes, I think someone would have noticed if gtk was not usable
<doko_> ok, thanks
<seb128> kenvandine was working on the build issue
<seb128> so should be fixed this week
<tkamppeter> directhex, did you have any success with Kyocera?
<pitti> superm1: can you please make bug 692911 public? otherwise it's impossible to check the state of this SRU and move it to -updates; there's another dell-recovery upload in the queue which is blocked by that
<ubottu> Bug 692911 on http://launchpad.net/bugs/692911 is private
<pitti> superm1: actually there are two
<pitti> superm1: I'll reject them both, can you please upload with either a merged changelog or with using -v to include all versions which are currently in -proposed?
<\sh> hmmm...
<\sh> Setting up tomcat6 (6.0.28-2ubuntu1.1) ...
<\sh> sed: -e expression #1, char 118: unknown option to `s'
<pitti> using s/// on a file path containing '/'?
<\sh> hmm..reading tomcat6.postinst the only seds in there are
<\sh> http://paste.ubuntu.com/558026/
<\sh> pitti: I don't mind that error...but the problem is lucid/maverick -> security update ;)
<\sh> + sed s/^JAVA_OPTS=.*$/JAVA_OPTS="-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC -Dnetviewer.monitoringConfig=/etc/netviewer/monitoring.properties"/ there is the bugger
<jfer> hi i was wondering if Acire is available for ubuntu 10.10
<doko_> ScottK: please could you add the preprocessed source for the bug reports with the symbols issues? just for the files with relevant symbol(s), including the gcc command line
<ogra> pitti, set to beta
<ogra> pitti, thanks for the reminder
<pitti> ogra: thanks
<\sh> mdeslaur: I think we have to reword the last sed line in tomcat6.postinst
<\sh> mdeslaur: it fails when you have some strange JAVA_OPTS line with slashes
<\sh> mdeslaur: bug #707348
<ubottu> Launchpad bug 707348 in tomcat6 (Ubuntu) "tomcat6 doesn't configure cleanly with JAVA_OPTS having values with slashes " [Undecided,New] https://launchpad.net/bugs/707348
 * ogra sees cjwatson's bug karma go through the roof today
<AnAnt> Hello, is there some page (preferably on Debian) regarding listing -lfoo before the object files using it when linking ?
<RAOF> AnAnt: I think it's DSOLinking; let me google it.
<AnAnt> ok
<AnAnt> erm, I don't think so
<AnAnt> http://wiki.debian.org/ToolChain/DSOLinking
<RAOF> Yup, that's it.
<AnAnt> but I don't see the mention of what I asked about there
<AnAnt> it talks about using --as-needed
<RAOF> Hm, you're right.
<RAOF> But what you're talking about is the fact that objects that contain definitions need to appear to the right of the objects that reference those definitions on the linker line, right?
<AnAnt> and yup
<AnAnt> yup
<RAOF> So, I think that's an interaction with --as-needed.  The linker *always* has that positional behaviour, but with --as-needed if the library hasn't been used to resolve some unresolved symbols already, it's dropped.
<AnAnt> RAOF: so you mean, that this is required only when --as-needed is used (which is the case in natty), right ?
<RAOF> The linker *always* has that positional behaviour; you should be listing objects with unresolved symbols before the libraries which resolve those symbols regardless.
<RAOF> I *think* that --as-needed makes things fail more often if you don't do the right thing.
<RAOF> AnAnt: You'll notice that the Debian page says âObject files, including .la files from a package build must appear before any library on the command lineâ, although it doesn't justify that.
<AnAnt> RAOF: but what I am talking about is that the -lfoo should appear before the object files, not vice versa
<RAOF> Under what circumstances is that necessary?
<AnAnt> RAOF: "gcc -lncursesw test.c" failed, yet "gcc test.c -lncursesw" worked !
<AnAnt> RAOF: that's on natty , on maverick it didn't matter
<RAOF> To me, that looks like the -lncursesw is after the object files, as expected.
<RAOF> (When it works)
<AnAnt> oh, sorry, you're right
<cjwatson> yes.  folks who've worked on other Unix systems will have seen similar things there
<cjwatson> (aside from AIX, which is totally backwards)
<cjwatson> this is one of those cases where gcc let people get away with stuff so they didn't notice, but if you were trying to be portable you'd work left-to-right anyway
<nigelb> cjwatson, pitti: Could either of you show the door to the troll in -release?
<nigelb> wait, never mind.
<persia> nigelb, You had the right channel at :49, although response took a bit :)
<nigelb> persia: Well, true. But not many there had access.
<nigelb> persia: Except for the council.
<persia> True, but that's typically enough, if it's needed.
<nigelb> So, I poked folks who actually did have access and would probably be around.
<nigelb> persia: Noted for future :)
<nigelb> persia: Also, are you backlogged on PM?
<persia> Very, although some is likely to slip, truthfully
<Daviey> cjwatson, Hi!  Do you have any thoughts on bug #699665?
<ubottu> Launchpad bug 699665 in openssh (Ubuntu) "sshd crashed during a rsync" [Undecided,New] https://launchpad.net/bugs/699665
<cjwatson> Daviey: I've looked, but I don't see any way to recover enough information from just the address dump supplied
<cjwatson> Clint's right, we need a core file really
<mdeslaur> \sh: could you nominate the affected releases in bug #654549 and subscribe ubuntu-sponsors, please?
<ubottu> Launchpad bug 654549 in tomcat6 (Ubuntu) "Tomcat6 fails to upgrade if JAVA_OPTS contains /" [Medium,Fix released] https://launchpad.net/bugs/654549
<Daviey> cjwatson, my thoughts aswell.
<Daviey> thanks for looking
<\sh> mdeslaur: well, 6.0.28 is in maverick but for lucid (6.0.24) it needs to be fixed with another upload..right?
<mdeslaur> \sh: lucid doesn't seem to have the seds in its postinst, but maverick does
<mdeslaur> \sh: so, only maverick is affected I think
<\sh> mdeslaur: ok...nominated bug #654549 for maverick
<ubottu> Launchpad bug 654549 in tomcat6 (Ubuntu) "Tomcat6 fails to upgrade if JAVA_OPTS contains /" [Medium,Fix released] https://launchpad.net/bugs/654549
<\sh> mdeslaur: to be sure, I'll check lucid on a newly installed tomcat appserver :)
<ari-tczew> hello folks, I need your help
<ari-tczew> slangasek: is it very necessary ship separate binary package smartdimmer? http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/nvclock/natty/changes?filter_file_id=smartdimmer.install-20090626033400-d3ab2kzykpm31he0-184
<ari-tczew> I'm trying forward that change to Debian, but maintainer asking me:  Is it useful to have smartdimmer as a separate package? Can it be used on non-nvidia hardware, too?
<ari-tczew> tseliot: maybe you could give a feedback? ^^
<tseliot> ari-tczew: I don't think smartdimmer is used with any driver other than nvidia
<ari-tczew> tseliot: so does it make sense to separate smartdimmer from nvclock?
<tseliot> ari-tczew: if what I said is correct, then I don't see the need to make it a separate package
<ari-tczew> slangasek: could you give a feedback to above? ^^
<zyga> mvo, hi
<zyga> mvo, just a quick question, please point me to a more appropriate person if you can, why can pip install stuff into /usr/local while gem puts stuff into /var/lib/gems/
<zyga> mvo, this is in regard to bug 706603
<ubottu> Launchpad bug 706603 in ruby1.9.1 (Ubuntu) "gem1.9.1 doens't install executables on PATH" [Undecided,New] https://launchpad.net/bugs/706603
<tseliot> ari-tczew: mjg59 (in #ubuntu-kernel) should know if smartdimmer can be used with other drivers
<ari-tczew> tseliot: thanks, I'm there
<cdbs> The new release of ubuntu-dev-tools has broken many things for me
<cdbs> I get an error, that /usr/local/bin/debian.csv and ubuntu.csv cannot be found
<tumbleweed> /usr/local/bin?
<cdbs> when I sudo touched them, the error got supressed, but pbuilder-dist began to fail to find out the proper mirrors
<cdbs> tumbleweed: I am sudo python setup.py installing the version in bzr
<tumbleweed> cdbs: eek, I really don't recommend that
<cdbs> tumbleweed: earlier when I installed from the package, the error came that ubuntutools.distro_tools didn't exist
<tumbleweed> cdbs: there are daily buids in deb form: https://launchpad.net/~udt-developers/+archive/daily
<cdbs> so I uninstalled the package and installed from bzr
<tumbleweed> cdbs: I suggest removing everything ubuntu-dev-tools (and ubuntutools) related from /usr/local
<cdbs> okay
<doko_> janimo_: is there anything which should prevent starting an armel/universe test rebuild?
<lool> cjwatson: hey, sorry for the delay; tried your binfmt-support branch, but didn't work for me
<lool> cjwatson: file /var/lib/schroot/mount/natty-armel-d45f987a-58d8-4fc4-94c6-6ca3f18de8a3/chroot-autobuild/bin/true
<lool> /var/lib/schroot/mount/natty-armel-d45f987a-58d8-4fc4-94c6-6ca3f18de8a3/chroot-autobuild/bin/true: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, stripped
<lool> src/update-binfmts --find /var/lib/schroot/mount/natty-armel-d45f987a-58d8-4fc4-94c6-6ca3f18de8a3/chroot-autobuild/bin/true
<lool> (no output)
<lool> cjwatson: strace shows it going over open("/var/lib/binfmts/qemu-microblaze", O_RDONLY) = 4
<lool> and others
<cjwatson> lool: can you put the /var/lib/schroot/mount/natty-armel-d45f987a-58d8-4fc4-94c6-6ca3f18de8a3/chroot-autobuild/bin/true binary somewhere for me?
<lool> cjwatson: http://people.canonical.com/~lool/true
<janimo_> doko_, nothing I know of
<janimo_> doko_, it takes a few builders for itself and that's all right?
<doko_> janimo_: hmm, just see that mesa is not installable. will wait until bryceh fixes it
<doko_> bryceh: I only see that x11proto-xext did fail to build
<cjwatson> lool: working on it, thanks
<lool> cjwatson: The loop on breakpoints seem to not go over the ones with magic
<lool> while (gl_list_iterator_next (&format_iter, (const void **) &binfmt,
<lool> This only goes over python2.6, wine, jexec and cli
<cjwatson> lool: it's because \x7fELF is misparsed as \x7fE L F
<cjwatson> I'm fixing it now
<lool> Hmm I was looking at the wrong loop anyway
<lool> cjwatson: So what do binfmt-support/kernel do if multiple interpreters match?
<cdbs> tumbleweed: thanks. works well now
<superm1> pitti, i won't be able to make that public, i shouldn't have included it in the changelog.  if you can reject them i'll upload again with a merged changelog instead that excludes that bug
<cjwatson> lool: tries them in sequence
<cjwatson> lool: see the comment in update-binfmts(8)
<pitti> superm1: ok, please do that then
<cjwatson> lool: please update and retry?
<lool> cjwatson: Works now!  I get a single line of output: /usr/bin/qemu-arm-static
<cjwatson> good
<cjwatson> I'll upload that then
<ogra> uuuh, magic !
<ogra> :)
<ogra> awesome
<lool> cjwatson: I'll relay that to Roger; thanks a lot!  do you have plans to upload this at a specific time in Debian?
<lool> cjwatson: Also, do you know if binfmt-support is used in non-Debian/Ubuntu distros?
<lool> cjwatson: I'm curious whether this is Debian-specific technology and whether it needs to be ./configure-able in schroot
<cjwatson> lool: I already uploaded it to experimental and synced to natty
<cjwatson> lool: I don't know of any non-Debianish distributions using binfmt-support right now; I would be happy to help make it work for them.  Is it not ./configure-able in schroot right now?  It should be
<tumbleweed> cdbs: great :)
<pitti> cjwatson, mdz, kees: 10-minute reminder for TB meeting
<lool> cjwatson: It's not yet in schroot; right now, we were discussing something like an "use_qemu" flag which meant "run file $chroot/bin/true to detect arch, and copy /usr/bin/qemu-$arch-static into the chroot"
<lool> cjwatson: But I proposed checking with you whether we could get the information straight from binfmt-support, which is much nicer
<cjwatson> oh I see what you mean, I misunderstood
<lool> cjwatson: Thanks a lot for uploading
<cjwatson> I thought you meant "should it be possible to unpack the binfmt-support source package in schroot and run ./configure"?
<Riddell> hmm, libdrm broke natty
<zyga> doko_, around?
<chrisccoulson> Riddell, and i was just about to upgrade ;)
<zyga> marjo, ping
 * zyga needs someone to talk to ;P
<tseliot> Riddell: yes, we're discussing the problem with Sarvatt in #ubuntu-x
<chrisccoulson> oh, i see what you mean about drm breaking natty now
<chrisccoulson> i can't build firefox anymore ;)
<pitti> bdmurray: did you file a bug about "bug supervisor not being able to set bug reporting guidelines for Ubuntu as a whole (not just packages)"?
<Sarvatt> the experimental libdrm-nouveau1 (who's ABI and API breaks monthly) is basically Priority: required right now thanks to mountall/plymouth and the package was renamed to libdrm-nouveau1a in debian this last abi break
<chrisccoulson> Sarvatt, what's the plan then? i'm basically blocked on the libdrm issue now ;)
<chrisccoulson> (no pressure) :-)
<cjwatson> Sarvatt: is it just a matter of rebuilding plymouth?
<cjwatson> Priority: required (unlike Essential: yes) isn't that desperately sticky - we can make it fall out of that once plymouth no longer needs it
<Sarvatt> cjwatson: can't rebuild plymouth because it requires libdrm-dev, setting up a chroot to build plymouth would bring in plymouth with the libdrm-nouveau1 requirement..
<OdyX> Hrm. /me is having a weird libdrm issue too. Shouldn't mesa get rebuilt against latest mesa-dev to get an updated depends on libdrm-nouveau1a ?
<Sarvatt> OdyX: we have a new mesa waiting to be uploaded but this needs to be fixed
<cjwatson> Sarvatt: isn't libdrm-nouveau1 still in the archive though?
<Sarvatt> yeah, libdrm-nouveau1a conflicts with it
<doko_> zyga: ?
<cjwatson> why dear god why?
<cjwatson> oh yeesh, same files
<cjwatson> what was the point of renaming if it's just going to ship the same files?
<OdyX> Sarvatt: Okay. (This makes my natty PPAs with packages Build-Depending on libgl1-mesa-dri and libqtwebkit-dev failâ¦)
<OdyX> cjwatson: ABI bump ?
<Sarvatt> i've already got a revert of the rename prepared but the debian guys aren't happy about that
<cjwatson> I suppose they're probably right
<cjwatson> can I see a build log that goes wrong?
<chrisccoulson> http://launchpadlibrarian.net/62773726/buildlog_ubuntu-natty-amd64.xulrunner-2.0_2.0~b10%2Bbuild1%2Bnobinonly-0ubuntu1_FAILEDTOBUILD.txt.gz
<Sarvatt> upstream doesn't bump the sonames but the abi/api's are incompatible, up until now we've just been rebuilding everything when we update but they have to worry about unstable/experimental issues
<cjwatson> let me think about this for a bit
<chrisccoulson> (i assume that's the same issue in my build log)
<cjwatson> ok, using Conflicts for this is against current policy, which may be part of why it broke
<cjwatson> the correct package relationships would have been:
<cjwatson> Breaks: libdrm-nouveau1
<cjwatson> Replaces: libdrm-nouveau1
<cjwatson> I suspect that if you do that then it will be happier
<cjwatson> (reference: policy 7.4)
<cjwatson> `Breaks' should be used
<cjwatson>         * when moving a file from one package to another (see Section 7.6,
<cjwatson>           `Overwriting files and replacing packages - `Replaces''),
<Amaranth> yay breaks
<cjwatson> so try that first; if even that doesn't work, then we could temporarily remove the Breaks to bootstrap our way out of this
<Laney> doko_: re your email â do you have a problem with the haskell rebuilds? I'm ready to upload the next round but just want to check your concerns...
<cjwatson> thinking about it Breaks will probably (ahem) break it too.  I suggest Replaces alone until we've unstuck the builds, and then we can add the Breaks back in afterwards
<cjwatson> it should definitely not be Conflicts though.  That would make maverick->natty upgrades a total nightmare.
<OdyX> cjwatson: hrm. Conflicts are an obligation IMHO; otherwise you allow both versions to be unpacked at the same time, while sharing the same files
<cjwatson> OdyX: this was all gone through on the policy list
<mr_pouit> pitti: hey, do you have by chance any idea why gdm is taking its time to kill its gnome-settings-daemon? Here, it is stopped much too late (maybe 10s after the user session is started), therefore it prevents the "real" xsettings daemon for the user session (xfsettingsd) from starting...
<OdyX> cjwatson: okay. Sorry.
<cjwatson> and Conflicts will cause a vastly difficult upgrade computation
<pitti> mr_pouit: not off the back of my hand; I didn't notice that here
<seb128> gdm doesn't stop it it seems
<seb128> rodrigo was investigating that the other day since users get that on GNOME as well with modern configs
<seb128> well it doesn't take 10 seconds to exit rather one but it's enough to make g-s-d fails in the user session
<cjwatson> OdyX: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578854 - particularly message #55 onwards
<mr_pouit> seb128: ah okay. I was able to preoduce that in a slow vm (hence the 10s ;), but I didn't try on a real hw
<mr_pouit> *reproduce
<ogra> jhunt, is there any chance the serial support will land in upstart before A2 ? (i have a workitem for it open and need to know if i need to postpone or can set it to DONE before A2)
<OdyX> cjwatson: Thanks for the clarification; my bad.
<doko_> Laney: do you upload a package more than once?
<Laney> if it becomes uninstallable again
<doko_> Laney: how would it?
<Laney> due to one of its rdepends changing abi
<doko_> and that cannot be done by uploading the packages in the correct order?
<Laney> that is what is done
<Laney> but if one package breaks abi then all packages from that point downwards in the graph must be rebuilt
<jhunt> ogra: there is always a chance :) Seriously, there is discussion on the upstart-devel mailing list about this. Scott has questions regarding the strategy. I'll take a look tomorrow and give you and update then if that's ok?
<doko_> hmm, ok. just thought I did see some packages uploaded more than once
<ogra> jhunt, fine with me
<Laney> not intentionally, it's possible that there could be a collision
<Sarvatt> any core-dev's around that'd be willing to sponsor http://sarvatt.com/downloads/merges/libdrm-natty-2/ so we can get this libdrm-dev mess out of the way? :)
<bdmurray> pitti: yes and I emailed the tech board about it but it was held in moderation
<pitti> Sarvatt: sure, doing
<Sarvatt> pitti: appreciate it!
<Sarvatt> plymouth will need a rebuild and the hardcoded depends changed to libdrm-nouveau1a
<cjwatson> I can do that
<cjwatson> Sarvatt: re "Temporarily lower", when the temporary period ends, please don't put the Conflicts back, of course, but add Breaks in addition to the Replaces
<Sarvatt> thank ya guys so much for the help, was beating my head on the wall on how to get out of that mess without renaming things back to libdrm-nouveau1 :)
 * Sarvatt nods at cjwatson
<cjwatson> don't thank us until libdrm builds successfully. :)
<tseliot> :)
<Riddell> TheMuso: who's our current pulse master?  module-device-manager is failing to load for me
<ogra> Riddell, beyond TheMuso thats diwic
<cjwatson> hallyn: the keyboard configuration junk is known, I'm having a hard time picking it apart but it's on my list
<cjwatson> (from #ubuntu-meeting)
<cjwatson> it has nothing to do with plymouth, for the record
<cjwatson> oh, wait, I misread the meeting log for that last bit :)
<ospiracy> string exec ( string $command [, array &$output [, int &$return_var ]] )
<ospiracy> spider ill
<ospiracy> ukposg|*
 * ospiracy osg
 * ospiracy $CGI::Pretty::INDENT = $CGI::Pretty::LINEBREAK = "";
<cjwatson> ospiracy: whatever this is, it has nothing obvious to do with Ubuntu development - please take it elsewhere
<ospiracy>       NAME1=VALUE1
 * ospiracy perl Makefile.PL make make test make install
<pitti> . o O { is it just me, or do we have a spammer's day today? }
<nigelb> pitti: not just you for sure.
<hallyn> cjwatson: yeah, i wasn't saying it was plymouth, just that i figured you were busy with plymouth this week :)
<hallyn> cjwatson: thanks, long as it's known, i'm good
<cjwatson> hallyn: actually it was just that I misunderstood an interleaved comment from SpamapS
<charlie-tca> pitti: I verified the plymouth package in -proposed for lucid works
<charlie-tca> bug 563916
<ubottu> Launchpad bug 563916 in plymouth (Ubuntu Lucid) "[details.so] No prompt for [S]kip or [M]anual recovery on server boot (or without "splash")" [High,Fix committed] https://launchpad.net/bugs/563916
<pitti> charlie-tca: many thanks! would you mind sending that to the bug?
<charlie-tca> did
<pitti> ah, right
<amorphous1> tkamppeter, ping
<janimo_> doko_, if a libo build fails midway should it be cleanly restartable using fakeroot debian/rules build or similar? I know that build system is a bit more fragile then usual
<pitti> o_O
<pitti> python -c '"%s Ã¤" % u"a"' gives me an UnicodeDecodeError, as documented
<pitti> but what kind of black magic does pygtk do? python -c 'import gtk; print "%s Ã¤" % u"a"'  -> that works
<pitti> (I don't think it's related to stdout -- I'm trying to set a GtkLabel)
<broder> that's amazing
<pitti> I checked the pygtk source for "textdomain", "locale", "UTF-8", "UTF8", nothing plausible there
<Sarvatt> cjwatson: Replaces: wasn't enough it looks like..  http://paste.ubuntu.com/558189/
<broder> pitti: i would look for something evil wherever it is that pygtk sets up the separate main loop thread and stuff
<pitti> oh, pangomodule.c does
<pitti>     /* set the default python encoding to utf-8 */
<apw> pitti, could it have changed the default binding for stdout, pushed a unicode thingy onto it?
<pitti>     PyUnicode_SetDefaultEncoding("utf-8");
<pitti> apw: that was my first guess, but my original program crashes on GtkLabel.set_label(), which doesn't touch stdout
<apw> woh that looks scarey
<pitti> barry: do you know whether I can do the equivalent of PyUnicode_SetDefaultEncoding("utf-8") in Python?
<cjwatson> Sarvatt: can you add '-o Debug::pkgProblemResolver=true' to that?
<broder> pitti: i see a sys.setdefaultencoding in the source, but it appears to be ifdef'd out
<Sarvatt> cjwatson: http://paste.ubuntu.com/558191/
<broder> hmm, no. something more complicated is going on, because sys.getdefaultencoding is #ifdef'd the same way and that works
<pitti> broder: hm, not in my copy of pygtk-2.22.0
<broder> pitt: sorry, i'm looking in python6
<broder> err, 2.6
<pitti> broder: anyway, above call looks very much like the reason
<pitti> broder: ooh, indeed! that might be the magic
<pitti> broder: right, can't call that, not available
<pitti> ok, I'm going to actually fix the source then
<broder> pitti: which is weird, because it appears to be ifdef'd the same way as sys_getdefaultencoding, which works
<tkamppeter> amorphous1, hi
<kklimonda> setdefaultencoding is available only during site.py evaluating
<pitti> so pygtk hacked around that by using the C API -- cheating!
<kklimonda> indeed
<broder> kklimonda: well, more that site.py expunges it in its main() function. that's kind of gross
<cjwatson> Sarvatt: odd, it looks like it's trying to install the old version of libdrm-dev
<cjwatson> waiting for my mirror to update so that I can chck
<cjwatson> *check
<tkamppeter> amorphous1, you want to talk with me about bug 693922?
<ubottu> Launchpad bug 693922 in Baltix "HP LaserJet 1212 error "failed to open scan device ... error on I/O with device"" [Undecided,New] https://launchpad.net/bugs/693922
<Sarvatt> cjwatson: PHEW you were right
<kklimonda> broder: right, but the effect is the same.
<amorphous1> tkamppeter, yes
<Sarvatt> cjwatson: I just caught it in the middle of updating the mirror or something, now it works
<amorphous1> tkamppeter,  I wrote you details on the private channel and sent an email
<cjwatson> Sarvatt: OK, great
<Sarvatt> bryceh: ok RAOF's mesa builds fine with the current packages, can ya sponsor it for him? http://cooperteam.net/Packages/
<smb> cjwatson, Colin, is there such a thing as daily (or at least point release) netboot images for Lucid.  I only seem to find the release versions
<smb> Oh, nm. I guess its only the pxelinux.0 that needs to be refreshed
<Sarvatt> sorry, got booted there
<Sarvatt> <Sarvatt> bryceh: ok RAOF's mesa builds fine with the current packages, can ya sponsor it for him? http://cooperteam.net/Packages/
<micahg> pitti: sorry to ask again, but I don't recall receiving an answer is bug 707104 worth reuploading for?
<ubottu> Launchpad bug 707104 in xubuntu-docs (Ubuntu) "References to "www.xubuntu.org" should not be links" [Undecided,New] https://launchpad.net/bugs/707104
<Sarvatt> here's a build log http://sarvatt.com/downloads/mesa_7.10-1ubuntu1_i386.build
<bryceh> Sarvatt, sure on it now
<cjwatson> smb: look in lucid-proposed rather than lucid
<smb> cjwatson, Ah. Thanks for the pinter
<smb> pointer even
<smb> Seems to be beer-o-clock in my mind...
<bryceh> Sarvatt, (still reviewing changes)
<bryceh> Sarvatt, ok I'm ready to sponsor RAOF's mesa upload.  Any reason I should hold off?
<Sarvatt> bryceh: nope, everything looks good to me
 * bryceh holds his ears and pushes the mesa plunger.  'Fire in the hole'
 * SpamapS dives for cover
<bryceh> uploaded
<bryceh> I should send out an announcement too, before we get too much further into these X updates
<RoAkSoAx> kirkwin 3
<RoAkSoAx> jeeeeeeeeez
<jhunt> quit
<ari-tczew> bryceh: could you be more verbose on bug 675622 ?
<ubottu> Launchpad bug 675622 in glew (Ubuntu) "Please sync glew 1.5.7-1 from Debian experimental (main)" [Undecided,Triaged] https://launchpad.net/bugs/675622
<lostinlinux> Hey everyone.. good afternoon
<bryceh> ari-tczew, tormod seems to have covered it already
<ari-tczew> bryceh: you wrote only "+1 to a sync for this." but would be nice to write why delta should be dropped even if you're developer.
<bryceh> ari-tczew, *shrug* I think tormod already covered it, no need for me to add noise
<ari-tczew> bryceh: what is "tormod" ?
<tormod> ari-tczew, hehe that is me :)
<ari-tczew> aaaaaaaaa
<ari-tczew> tormod: are you able to see changes in http://pastebin.ca/1447378 ?
<ari-tczew> this page couldn't be loaded for me :?
<tormod> ari-tczew, no that pastebin is lost. pastebin != documentation
<ari-tczew> tormod: Agreed.
<ari-tczew> tormod: unfortunately, merge ATM
<ari-tczew> tormod, bryceh: debian/watch from Ubuntu works, in Debian not
<ari-tczew> I'm looking next
<tormod> ari-tczew, what do you mean? what do you need that watch for, if we have it synced?
<ari-tczew> if someone wants to run uscan
<tormod> that's not a reason for keeping a Ubuntu delta
<tormod> get it fixed in Debian if it is important
<ari-tczew> tormod: I don't agree.
<tormod> if it is broken in Debian, we should have it fixed in Debian, and sync the next version
<tormod> and not waste time on keeping a separate Ubuntu package
<tormod> which will cause more work in the next merge cycle
<ari-tczew> tormod: please don't get me wrong. I'd like to sync package. Just making sure about delta drop.
<tormod> ari-tczew, good
<BlackZ> tormod: hello, can you review https://code.launchpad.net/~eugenesan/ppa-purge/trunk/+merge/46673 again and say if it looks good for you? thanks!
<ari-tczew> tormod: did you test glew from experimental on natty?
<tormod> BlackZ, hi, I am still not happy about the "empty repo" handling. I think it should bail out or complain massively, not just quietly finish
<BlackZ> tormod: thanks for your time! :) from your last comment I didn't understand well
<tormod> BlackZ, what is unclear?
<BlackZ> tormod: if it was ready to be merged or not
<tormod> BlackZ, aha. I hoped Eugene would fix it up, but he got quiet. I hope he's working on a way to find which packages come from a ppa :)
<BlackZ> tormod: heh. The versioning for such packages is very different so I don't think there's a "simple way" to do that
<ari-tczew> tormod: what about that change: debian/rules: Amend for pkg-config addition http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/glew/natty/revision/15#debian/rules
<tormod> ari-tczew, I tried 1.5.7-1 on Lucid and Maverick
<tormod> ari-tczew, did you read through the Debian changelog?
<ari-tczew> tormod: yes I did, but I'm going to read again
<tormod> ari-tczew, btw I don't understand why Daniel added that to the Ubuntu package instead of getting it into Debian
<ari-tczew> tormod: I also want to get to know.
<tormod> the same was done in Debian 6 months later. just duplicated effort
<ari-tczew> He did it wrong. Should add patch instead patching files directly.
<tormod> ari-tczew, yes, the Makefile change should have been in a patch
<luca__> ciao
<luca__> italiani
<luca__> ci sono
<ari-tczew> tormod: OK, I forward d/watch to debian bug 611137 and I'm giving +1 for sync.
<ubottu> Debian bug 611137 in glew "glew: debian/watch is broken" [Normal,Open] http://bugs.debian.org/611137
<tormod> ari-tczew, he probably just wanted to upload a quick'n'dirty fix without going the proper route, and know it causes us these discussions and questions :(
<tormod> ari-tczew, great, thanks for the filing that bug
<ari-tczew> tormod: yea, current glew on Ubuntu looks very shameful
<tormod> BlackZ, I am happy with the merge except the "empty ppa" hunk. I don't know bazaar well enough to do a selective merge. If this was 3-4 different git patches it would have been easier for me...
<BlackZ> tormod: I can pick up the other changes, if you want :)
<BlackZ> tormod: except the one you mentioned
<tormod> BlackZ, great! thanks. and let's encourage Eugene to handle the empty repo thing...
<ari-tczew> torkel: what do you think about request fresh sync ?
<ari-tczew> sorry, should be tormod ^^
<ari-tczew> Riddell: regarding to last cjwatson 's words, there is no need to get an ACK from sponsors. archive admins are better knowledged to review removal requests. bug 687405
<ubottu> Launchpad bug 687405 in connman-gnome (Ubuntu) "Please remove connman-gnome from natty" [Undecided,New] https://launchpad.net/bugs/687405
<persia> Please, could we continue to request sponsorship for removal requests from non-members of ubuntu-dev?
<persia> I've seen any number of such requests that were immediately unactionable for a variety of reasons, and it would be good to catch those before they reach the archive admins.
<micahg> ari-tczew: archive admins shouldn't be tasked with doing the initial verification as they already have plenty of work to do, they are of course a sanity check on the final removal
<persia> Note that any archive-admin is perfectly capable of performing the removal sponsorship if they happen to feel so motivated: the point is to encourage more folk to do initial review for non-developers, not to block action in any way.
<ari-tczew> micahg, persia: please don't gotcha me as bum rap. Just yesterday IIRC cjwatson wrote that there is no need to sponsors ACK. ubuntu-archive will take a look.
<persia> ari-tczew, My comments were intended generally, and not intended as a critique of your statement directly, but rather a critique of discouraging non-developers from requesting sponsorship of removal requests.
<ari-tczew> aha
<micahg> ari-tczew: I was simply saying that it should be up to the Archive Admins if they want to look at it, not be required for them to do it
<ari-tczew> micahg: aha
#ubuntu-devel 2011-01-26
<hyperair> hmm what's this --git format in bzr?
<hyperair> as far as i can see, bzr init-repo --git = git init
<hyperair> and bzr upgrade --git crashes and burns
<hyperair> oh and bzr fails so hard that git-bzr stopped working
<hyperair> some weird exception about LocalGitBzrDir not having repository_format
<hyperair> wonderful.
<doko_> bryceh: ping
<cjwatson> persia: I certainly don't object to our workload being reduced; but contrariwise I don't want people who know about a package, but who can't upload it yet, to feel discouraged from filing removal requests for it directly, if that seems appropriate
<cjwatson> persia: of course if any archive admin feels they'd rather not review an unsponsored request directly, but have it sponsored instead, I think that's up to them
<persia> Ah, then we're in complete agreement for the most part.  Personally, I'd rather use the metric of PPU to determine that people know about a package, but there's work to be done to make that feel less complicated.
<persia> (but I have no objection to an archive admin deciding to also sponsor such a request if submitted directly)
<cjwatson> I think "in complete agreement for the most part" may be the most persia turn of phrase I've ever read. :-)
<bryceh> heh
<persia> heh.
<persia> By that I mean that we're agreeing not only in principle, but in details for most of the space: the remainder being things that aren't yet clearly defined in either code or policy.
<cjwatson> fortunately removals are fairly rare
<cjwatson> removal requests anyway, versus ones mirrored from Debian
<persia> I think part of that comes from increased understanding of how to file RoQA removal requests (and bddebbian's tireless work in the past to drop all sorts of stuff)
<ari-tczew> awesome! Debian is starting to support our patches in parallel mode!
<ari-tczew> e.g. lilo or packagekit
<broder> hmm...does the startup event export any environment variables that you could check for in a child job? i'm wondering if you could solve bug #436936 that way
<ubottu> Launchpad bug 436936 in kdebase-workspace (Ubuntu Karmic) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged] https://launchpad.net/bugs/436936
<broder> looks like...no. oh well
<persia> I believe there was some work to make upstart have the commandline as environment variables, so that jobs would check the environment rather than the actual commandline.  My understanding is that it was implemented, but isn't yet widely used.  I may be completely mistaken.
<broder> no, that came up on the mailing list recently. i think you're right
<broder> Keybuk talked about passing bare arguments instead of just foo=bar arguments, which means that you could check for $text instead of grepping /proc/cmdline for it
<broder> though that wouldn't be SRU-able, which is kind of unfortunate
<persia> True, but a fix that prevents the class of error in the future is superior to none, even if it can't solve the past.
<persia> I'd hope that most Karmic users were well into their plans to upgrade to Lucid at this point though, as otherwise they may find themselves with difficulties soon.
<persia> (not that this necessarily addresses the need to SRU something)
<broder> it's still a problem on lucid. possibly on maverick as well
<broder> (i just updated the nominations to reflect that)
<broder> i wonder what triggers the gdm job when you come out of recovery mode, though. presumably it's not the filesystem and started dbus and (drm-device-added or stopped udevtrigger) that triggers it organically
<broder> so i wonder if you could conditionalize that check on $UPSTART_EVENTS
<persia> I'd recommend finding a fix for natty first, and then fussing about the older releases.  I suspect that fiddling the environment is a way to do that.
<broder> hmm...so the recovery mode is started by the rcS job (start on runlevel S), and does a start --no-wait rc-sysinit FROM_SINGLE_USER_MODE=y when the menu exits
<persia> So one might use [ -n "$UPSTART_EVENTS" -o "$FROM_SINGLE_USER_MODE" = "yes"] ?
<broder> i'm not sure that variable would actually propagate all the way down. i'm still trying to figure out what specifically triggers the gdm job
<persia> Or, rather, use the considtional for the exit?
<persia> I suspect it's frequently dbus starting
<broder> no, all of the conditions for gdm to start have already run before you get to the recovery menu
<broder> (so filesystems are mounted, hardware has been scanned, dbus is running, etc)
<broder> er......wait
<broder> i bet the bug isn't that check of /proc/cmdline, but rather that *nothing triggers the gdm job when the runlevel changes*
<broder> looking at logs from a verbose boot, i'm pretty sure that's the issue
 * kees wonders if we can do this for Natty? http://domsch.com/blog/?p=455
<lifeless> kees: I can't decide if its awesome or terrible
<lifeless> kees: the # in names seems liable to cause grief
<kees> lifeless: it doesn't preclude overriding the names, but for server people, it's _great_.
<broder> we talked about doing this in one of the uds sessions...the consensus seemed to be that we should
<broder> let me see if i can find the blueprint...
<broder> https://blueprints.edge.launchpad.net/ubuntu/+spec/packageselection-n-network-stack
<broder> cjwatson took the WI :)
<kees> ah-ha
<cjwatson> I was thinking of making it optional somehow.  The namepocalypse kind of worries me and I'd sort of like us to try it out before committing to it
<maco> /proc/asound/card0/codec\#0 does the # thing already....whats one more spot? :P
<cjwatson> still need to ponder
<kees> neato.
<kees> $ sudo ./biosdevname -i eth0
<kees> em1
<kees> that really would be a namepocalypse
<kees> on the other hand, /etc/udev/rules.d/70-persistent-net.rules will already keep the old name
<persia> Is there any sane way to have both entries available, to ease transition?
<broder> based on the WI, i'm assuming that the plan would be to only do this for new installations, not upgrades
<kees> broder: yeah
<kees> persia: no, unfortunately, that's part of the pain, AIUI.
<kees> cjwatson: for new installs, this actually should be pretty easy, as long as it's before udev rule "70".
<kees> anyway... just got distracted for a moment...
<persia> I thought part of the point of udev was that one could have multiple device entries for the same device more safely.  Does that not work in the case of network interfaces for some reason?
<kees> persia: network interfaces do not have /dev entries :(
<kees> therefore, no symlinks
<persia> I was hoping there was some parallel.  Oh well :(
<cjwatson> kees: it's a medium-priority item for me, so I haven't got to it yet
<cjwatson> quite tempted to make it server-only too, BTW.
<kees> cjwatson: cool
<cjwatson> or even a non-default preseeding option, possibly
<kees> cjwatson: yeah, it could just be an optional package that carries the udev rule, and the server seed includes it from the start.
<cjwatson> or server-ship or something, and install it dynamically from the installer
<cjwatson> I think it might need a udeb too though
<kees> yeah
<broder> oh, whoa. i missed that they were changing the names of all interfaces. *weird*
 * kees goes to try it on a machine that actually has multiple nics...
<james_w> I thought it kept eth0 if you just had one nic
<kees> woo. em1 and em2. how exciting. ;)
<broder> james_w: http://domsch.com/blog/?p=455&cpage=1#comment-801
<cjwatson> broder: I think it's because swapping interfaces doesn't work reliably
<cjwatson> and all their attempts to fix that in the kernel were rebuffed in one way or another
<james_w> I must have misunderstood that point in the article then
<ari-tczew> cjwatson: are you able to sponsor bash if I'll prepare a merge? I saw that you had a look on this
<cjwatson> ari-tczew: I'd rather doko did it
<cjwatson> ari-tczew: seeing as he's the Debian maintainer, I tend to leave sponsoring Ubuntu changes to it to him :)
<ari-tczew> cjwatson: but what - sponsor or full merge?
<cjwatson> up to him I guess
<cjwatson> I don't have an opinion on that, I just mean I'd rather doko dealt with it than I did
<ari-tczew> cjwatson, doko_: in general, I'd like to not touch that package, just finish started merge by udienz.
<cjwatson> I only commented on that merge because it was my patch pilot day, I think
<doko_> ? which package?
<cjwatson> 02:19 <ari-tczew> cjwatson: are you able to sponsor bash if I'll prepare a merge? I saw that you had a look on this
<doko_> ahh, ok
<cjwatson> actually I commented on it in my report.  https://lists.ubuntu.com/archives/ubuntu-devel/2011-January/032318.html
<doko_> delaying for the next upstream release
<ari-tczew> doko_: could you look on curl FTBFS? https://launchpad.net/~ari-tczew/+archive/testing/+buildjob/2223498
<doko_> no, ENOTIME
<ari-tczew> thanks
<snowrichard> hello
<snowrichard> Just got a version 1 of my application for scheduling my prescription drugs done
<snowrichard> i just added the code for the alarms to display the list of drugs to take at a particular time.
<snowrichard> about 24 hours work done on the whole project -- but I'm not very experienced with Java, or Android yet.
<snowrichard> oh sorry i am in the wrong channel -- my bad
<pitti> micahg: if it's a regression, then yes
<micahg> pitti: ok, thanks, and good morning :)
<pitti> Good morning
<micahg> pitti: err, not technically a regression as that part of the doc didn't exist before
<micahg> pitti: so, my question is, does a bug introduced by the -proposed package that isn't a regression and is just an annoyance worth reuploading for?
<pitti> micahg: ah, then not; I thought you said it was a regression
<micahg> pitti: I thought it was, I had charlie-tca verify for me and he said it was a new block of text, so no regression, but introduced by the update, I'll target for 10.04.3 then?
<pitti> micahg: sounds good
<micahg> pitti: thanks
<micahg> pitti: how soon does the testdrive fix need to be tested?
<pitti> micahg: depends on whether testdrive is on any of the images we release as part of 10.04.2
<pitti> if so, within a week; otherwise it doesn't matter too much
<micahg> pitti: ok, I can test this weekend then
<micahg> pitti: actually, doesn't have a Task, so I'm guessing it's not seeded
<pitti> cjwatson: I added "closed subgraph" detection to http://people.canonical.com/~ubuntu-archive/nbs.html now; that indeed found some more packages which can be safely removed
<pitti> the current libaqbanking complexity was a nice test case :)
<dholbach> good morning
<didrocks> good morning dholbach
<dholbach> salut didrocks
<cjwatson> pitti: cool!
<cjwatson> pitti: can I remove stuff at some point, or do you want your useful test cases preserved for a little while longer? :)
<pitti> cjwatson: I think they can go now
<pitti> as soon as qbankmanager builds again, the next bunch will disappear
<bdrung> dholbach: the harvest tool is lacking a man page, a license header, needs to be mentioned in d/control, d/copyright
<dholbach> ugh
<quadrispro> hi all
<dholbach> bdrung, I'll revert it
<quadrispro> any archive-admin here?
<dholbach> bdrung, reverted
<bdrung> dholbach: you reverted it? why?
<dholbach> bdrung, because I won't have time this or next week to write a manpage, etc
<bdrung> ok
<seb128> sucks
<bdrung> dholbach: once you have time, please use optparse in the script
<seb128> can't you just let the command as an experimental one
<bdrung> dholbach: or ask tumbleweed to write one
<jibel> pitti, hi, just to bring it to your attention, during last release meeting cjwatson mentioned that many reports were wrongly affected to initramfs-tools, I think that bug 580419 is causing this.
<ubottu> Launchpad bug 580419 in apport (Ubuntu Natty) "apport used wrong source package when filing package installation failure" [High,Triaged] https://launchpad.net/bugs/580419
<cjwatson> jibel: good catch, thanks
<pitti> hi jibel! looking
<pitti> ah, nice catch indeed; I'll see how to make it check for only the recent session
<mr_pouit> pitti: is optipng really really really safe? Because it's kind of destroying the latest window manager theme for xubuntu ;D
<pitti> mr_pouit: I ran an automatic comparison for about 3.000 images which didn't show problems; but of course this only tested with libpng
<pitti> if something uses a different library, or relies on a particular bit depth, it might indeed lead to problems
<ion> I wonder if all PNG compressors such as pngcrush break compatibility with whatever the Xfce WM uses.
<mr_pouit> I need to compare the files after and before. But if it changed a bit the colours (e.g. used a lighter grey to optimize), this would explain the issue
<pitti> mr_pouit: it doesn't change the actual colors
<pitti> mr_pouit: it does compress palettes and reduce bit depth, though
<pitti> i. e. if you have an RGB32 PNG which actually just uses 10 colors, it'll convert it to a 4-bit indexed image with a palette
<ochosi> hi pitti
<pitti> hi ochosi
<ochosi> pitti: i'm doing the artwork that was eaten by optipng (what mr_pouit mentioned)
<ochosi> so you're converting the mode from rgb to indexed?
<pitti> mr_pouit, ochosi: if you want, I can generally blacklist "*xfce*" packages from PNG optimizing
<pitti> ochosi: if it reduces the image size, yes
<mr_pouit> pitti: I quickly checked, and this particular theme seems the only one affected
<ochosi> pitti: sure, i'd rather find out why it scrambles the images in the first place
<ochosi> pitti: what's the exact optipng command you're running?
<ochosi> pitti: (so i can test it locally)
<pitti> individual packages can do "export NO_PNG_PKG_MANGLE=1" in debian/rules to disable it, FYI
<pitti> ochosi: optipng -o4 -preserve "$f"; then
<pitti> oops, sorry
<pitti> ochosi: optipng -o4 -preserve $f; advpng -z4 $f
<ochosi> pitti: k, thanks, i'll try to debug it and get back to you
<ochosi> pitti, mr_pouit fwiw i've used optipng on themes i made before but never had any problems with it. maybe a gimp-export thing...
<pitti> ochosi: many thanks
<mr_pouit> well, visually, I can't find any difference between the two pngs :P
<pitti> mr_pouit: right, there shouldn't be; see https://bugs.launchpad.net/ubuntu/+source/optipng/+bug/669457/comments/2 for the testing I made
<ubottu> Ubuntu bug 669457 in optipng (Ubuntu Natty) "[MIR] optipng" [Undecided,Fix released]
<ochosi> mr_pouit: seems it's really not as optimized as i'd have hoped, optipng just cut the size by half...
<mr_pouit> ok
<ochosi> pitti, mr_pouit: ok, i don't even have to run advancecomp on the file, optipng already breaks it
<pitti> ochosi: right, advancecomp alone really shouldn't break anything
<pitti> it doesn't change any of the file properties, just optimizes Huffman tables etc.
<ochosi> pitti: weird, optipng didn't change the mode to indexed but to greyscale...
<mjr> grayscale is 8 bits per pixel too, and doesn't need the palette
<ochosi> hm, i seem to get closer, converting the png to an indexed palette with gimp also breaks the xfwm theme
<ochosi> mr_pouit: the other themes you tested, do they use pngs at all or xpms?
<mr_pouit> I tested all available themes, including bluebird ;-)
<ochosi> mjr: right, thanks :)
<ochosi> mr_pouit: bluebird uses xpms ;)
<mr_pouit> arf, my bad
<ochosi> hehe
<ochosi> pitti: i think i was able to pinpoint the issue, but it's a bit awkward and xfwm related
<pitti> ochosi: so does it rely on a particular palette?
<pitti> or color format rather
<ochosi> hm, not really
<ochosi> it seems that if i optimize a png that contains transparency, everything works out fine
<ochosi> but as soon as i optimize a png that doesn't contain transparent pixels xfwm breaks
<pitti> ah, so it would at least take away the alpha channel?
<ochosi> i guess that's due to the fact that usually you would use xpms for non-transparent images in themes
<ochosi> yeah, i guess taking away the alpha channel from the pngs is what breaks it
<mjr> (there's -nx or the more spesific -n? options for disabling optipng from changing colorspace stuff but still doing other optimizing if necessary)
<pitti> jibel: fix uploaded, thanks!
<ochosi> mjr: changing the colorspace is not what creates problems necessarily, it's really the alpha-channel
<ochosi> (just tested it again with gimp to be sure)
 * cjwatson takes a very very deep breath and dives into an strace of 'apt-get install console-setup' across the breakage a couple of weeks ago, to try to figure out why its debconf handling went berserk
<pitti> cjwatson: good luck, and beware of the Piranhas
 * doko_ wonders about another upload-rinse-and-clean series of kde uploads
<pitti> how do you mean? it's the 4.6 final uploads?
<pitti> ah, we can demote hupnp again, thanks
<doko_> watch the build failures, no proper build dependencies like xfce
<mr_pouit> uh?
<ochosi> pitti: i reported the optipng-issue to xfce-upstream, the bug is already confirmed/reproduced, so nothing else to do on your side. thanks for your support!
<pitti> ochosi: heh, didn't do anything; great debugging, thanks!
<shadeslayer> what development files does one use for mono? libmono-devel isnt cutting it
<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
<shadeslayer> cli-common-dev did the trick ... thank :)
<cjwatson> pitti: where can I find/edit the code that generates nbs.html?
<cjwatson> ah, never mind, ubuntu-archive-tools
<pitti> cjwatson: right
<ari-tczew> mvo: ready to sponsorship?
<mvo> ari-tczew: yep
<ari-tczew> mvo: bug 705383
<ubottu> Launchpad bug 705383 in emacs23 (Ubuntu) "Please merge emacs 23.2+1-7 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/705383
<mvo> ari-tczew: looking at it now
<mvo> ari-tczew: geh, that is a big debdiff
<ari-tczew> mvo: yea
 * mvo makes a cup of tea, that review will take a little bit
<Laney> lapsang souchong?
<mvo> Laney: sencha ragi actually :)
<Laney> :)
<orangecard> join #ubunt-app-devel
<seb128> pitti, the libclutter-eglx- binaries on NBS don't really have rdepends
<seb128> not sure if that's a bug
<seb128> things depends on libclutter-1.0-0 | ...
<seb128> ie we could probably clean the eglx binaries without breaking anything
<pitti> it's half of a bug in checkrdepends
<pitti> seb128: ah, thanks
<fta> pitti, http://paste.ubuntu.com/558548/
<fta> (hi)
<pitti> seb128: ok, I'll clean them up, thanks!
<seb128> pitti, thanks
<pitti> hey fta
<pitti> fta: meh, that looks like a new upstart behaviour
<pitti> $ sudo start apport; echo $?
<pitti> start: Job is already running: apport
<pitti> 1
<pitti> jhunt: ^ known?
<pitti> that used to silently succeed
<jhunt> pitti: that's correct behaviour I believe. See section "Instances" in "man 5 init".
<pitti> jhunt: did it use to do that in maverick, too?
<jhunt> yup.
<pitti> jhunt: perhaps fta just ran into a weird package state (since usually upgrading should stop before)
<pitti> jhunt: ok, thanks for confirming
<pitti> fta: anyway, that snippet gets added by dh_installinit, so I don't think it's apport specific
<fta> pitti, i'm not sure what to tell you. only apport complained. http://paste.ubuntu.com/558554/
<pitti> fta: hm, the prerm should have stopped apport, but apparenlty didn't
<pitti> fta: if you apt-get install --reinstall apport, does that reproduce the problem?
<fta> pitti, --reinstall wants to finish the update first :P
<fta> (the configure)
<fta> stopping apport manually worked though
<pitti> right, "sudo stop apport; sudo dpkg --configure -a"
<pitti> should do
<fta> i assume i won't be the only one to hit that
<jibel> pitti, I've nothing against apport today, really, but could you look at bug 707971, that's what fta is describing.
<ubottu> Launchpad bug 707971 in apport (Ubuntu) "package apport 1.17.1-0ubuntu3 failed to install/upgrade: invoke-rc.d: initscript apport, action "start" failed." [High,Triaged] https://launchpad.net/bugs/707971
<jhunt> fta: did you notice what state apport was in before you stopped it?
<fta> jhunt, I assume it was active, i always have it active in all my desktops
<jhunt> fta: sorry, I meant what upstart state apport was in (ie "initctl status apport")
<fta> jhunt, i get it's too late now i've killed it
<seb128> pitti, well I'm still on the old version and it has
<seb128> set -e
<seb128> # Automatically added by dh_installinit
<seb128> if [ -e "/etc/init/apport.conf" ]; then
<seb128>         # start fails if already running
<seb128>         start apport || :
<seb128> fi
<fta> oh, it's reproducible
<seb128> fta, jhunt, jibel: ^
<seb128> seems dh_installinit changed?
<fta> jhunt, http://paste.ubuntu.com/558564/
<seb128> http://launchpadlibrarian.net/62684664/debhelper_8.0.0ubuntu1_8.0.0ubuntu2.diff.gz
<pitti> ah, that would be it then
<seb128> # Automatically added by dh_installinit
<seb128> if [ -e "/etc/init/apport.conf" ]; then
<seb128>         invoke-rc.d apport start || exit $?
<seb128> it does that now
<pitti> I'll reassign the bug and give some extra info
<seb128> slangasek, ^ you broke dh_installinit ;-)
<pitti> bug updated
<seb128> pitti, danke
<pitti> barry: hey, how are you? did you have a chance to review the computer-janitor pygi branch?
<barry> pitti: not yet, but i still plan to.  i'll get to that later today
<pitti> barry: cool, thanks
<barry> no, thank *you* :)
<lool> cjwatson: Hey; I have a couple of questions around blkid that I'm pretty sure you came across  :-)  first, just after creating a loop device from a file (with an offset), should I call blkid on loop, blkid -c /dev/null on loop, sudo blkid on loop, or sudo blkid -c /dev/null on loop?  I've seen the former misbehave / be a bit racy, but I'm not sure how far to go; should I call udevadm settle somewhere?
<lool> (somewhere == between loop mount and blkid)
<pitti> lool: if you want to ensure that it does probe, please use -p
<cjwatson> lool: I don't think I know any better than you wrt raciness
<lool> pitti: Do you think I need -p?
<lool> pitti: I guess -p needs root in any case?
<pitti> lool: yes, I think so; I don't see any value that the cache could bring for a fresh loop mount
<pitti> lool: yes, it does, but so does loop-mounting, so I guess you have root?
<lool> Yes we have root
<pitti> well
<pitti> it needs to be able to open the device
<lool> (I just decide command by command whether to run it as root, and prefer running commands non-root if I can)
<pitti> not for the actual probing
<pitti> so it really depends on the device node
<lool> pitti: Yup, I see -p only works as root
<pitti> you can probe the image file with -p without root, of course
<pitti> blkid -p download/ubuntu/natty-desktop-amd64.iso
<pitti> works just fine
<lool> pitti: So if I -p, I probably don't care about udevadm settle
<lool> or -c
<pitti> settle won't help you with the cache update
<lool> I thought that udev might be running blkid itself
<ogra> it does
<pitti> lool: so after the loop mount you should either wait a bit and get the new propertoes from the udev db (to avoid re-probing), or call blkid yourself
<lool> pitti: anyway, if I use -p, it doens't matter I guess
<ogra> in /lib/udev/rules.d/60-persistent-storage.rules
<pitti> lool: where "wait a bit" means "wait for the change uevent on the block device"
<lool> pitti: It's actually awesome that you replied to these questions because I have another similar issue which is typically a pitti question  :-)  we also have a case where we create a fs and loop mount it, and then ask UDisks whether it's mounted; that fails unless we sleep a bit
<lool> pitti: Is there something we can do which is better than sleep?
<lool> I tried udevadm settle, but it didn't help
<cjwatson> udevadm settle only helps when the uevent has already entered udev's queue when udevadm starts
<lool> Yes
<pitti> lool: right, unfortunately udevadm settle stops too early
<lool> I suspect the events are not emitted yet
<cjwatson> because all udevadm settle does is wait for the udev queue to be empty, basically
<lool> Yeah; I just don't know of anything better
<pitti> lool: at that point, udisks gets the uevent and does its own probing
<cjwatson> ideally the kernel needs to hand back a token which losetup can wait on
<cjwatson> that's done in a few other places (devmapper?)
<pitti> lool: do you have C/python, or need shell?
<lool> pitti: Ah, so even after the event is full processed, UDisks will have to take some time before accounting for it?
<lool> pitti: python
<pitti> lool: the "canonical" way is to wait for udisk's D-BUS signal to indicate the change event on the loop device
<lool> pitti: Ah that sounds good
<lool> pitti: Ok; I will look in that direction, thanks
<slangasek> seb128: no, I fixed dh_installinit.  What's wrong with invoke-rc.d?
<cjwatson> I think it's the #ERROR_HANDLER# being complained about, not the invoke-rc.d
<cjwatson> the old code had || :, the new code has || #ERROR_HANDLER#
<pitti> it expands to "exit $?" instead of ":"
<seb128> slangasek, see the apport bug just before my ping
<slangasek> yes, it's *supposed* to expand to 'exit $?'
<slangasek> and 'invoke-rc.d apport start' is not supposed to fail if the job is already running
<slangasek> oh, apport runs but has no pid
<slangasek> right, /that/ bug
<pitti> slangasek: according to jhunt, "start foo" exiting with 1 if already running is correct
<pitti> I guess that's why the previous scripts used || :
<slangasek> pitti: yes, we're not *calling* 'start foo', we're calling 'invoke-rc.d foo start'
<slangasek> which is *not* supposed to behave that way
<slangasek> bug #585001
<ubottu> Launchpad bug 585001 in upstart (Ubuntu) "package nfs-common 1:1.2.0-2ubuntu8 failed to install/upgrade: el subproceso script post-installation instalado devolviÃ³ el cÃ³digo de salida de error 1" [Medium,Triaged] https://launchpad.net/bugs/585001
<slangasek> this is a bug in upstart-job's init script emulation
 * cjwatson retitles that to something more useful :)
<slangasek> actually, looks like bug #603934 is the better-triaged
<ubottu> Launchpad bug 603934 in upstart (Ubuntu) "package nfs-common 1:1.2.0-2ubuntu8 failed to install/upgrade: start: Job is already running: idmapd" [Low,Triaged] https://launchpad.net/bugs/603934
<ari-tczew> oh, slangasek, I catch you. did you see my yeserday message about nvclock?
<slangasek> ari-tczew: hi there - smartdimmer is split out so hal can recommend it without pulling all of nvclock into main; as long as hal recommends it, it should be split.
<ari-tczew> slangasek: ok thanks for info. FYI, now only remaining change is smartdimmer in nvclock.
<slangasek> sure
<ari-tczew> but I;m going to add next changes - replace nvidia-glx with nvidia-current
<pitti> not that we'd care much about hal any more
<pitti> GNOME, Xfce, and now also KDE stopped using it
<pitti> I actually pondered dropping that patch from hal and syncing hal from Debian
<slangasek> pitti: why is hal still in main, then?
<pitti> slangasek: there is still some straggling packages which depend on libhal1
<pitti> and apparently landscape-client still depends on it
<slangasek> ah
<pitti> I talked to them about switching to udev long ago, but apparently they didn't yet
<slangasek> hmm, checkrdepends seems to think gimp is the only thing keeping it in
<pitti> right
<pitti> hm, I don't actually have libhal1 installed
<seb128> gimp?!
<pitti> ah, I didn't reinstall gimp after my recent laptop reinstall
<nemo>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<nemo>  2280 nemo      20   0 1781m 790m  12m S    0 20.6  25:28.56 nautilus
<nemo> :)
<nemo> pretty much all heap. guess I could try a gdb dump. oh well
 * nemo kills nautilus
<ScottK> barry: FYI, sip4 is now in Natty with Python3 support.  PyQt4 in progress and then PyKDE not far behind.
<barry> ScottK: rock on
 * ScottK waves at Quintasan (who did the sip4 work)
<Quintasan> \o/
<barry> pitti: pygobject git head doesn't seem to want to compile on natty.  doesn't like the version of gobject-introspection apparently:
<barry> configure: error: Package requirements (glib-2.0 >= 2.24.0
<barry>         gobject-introspection-1.0 >= 0.10.2
<barry>     ) were not met:
<barry>  
<barry> No package 'gobject-introspection-1.0' found
<barry>  
<zul> pitti: is the desktop team still handling likewise-open?
 * SpamapS stretches
<pitti> barry: right, needs g-i HEAD, too :/
<pitti> zul: we never really did; we were basically just sponsoring the upstream versions, and they triaged the bugs themselves
 * SpamapS loves when upstream triages bugs themselves
<zul> pitti: right there a couple of merge proposals for me do you want me to take care of them or do you want me to pass them off to the desktop team
<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:
<barry> pitti: k, i'll take another look after lunch
<pitti> zul: if you want to, please do; thanks
<zul> pitti: k
<pitti> slangasek: dup-of-dup: lp-set-dup masterid yourid1 yourid2 ... will DTRT with those
<pitti> slangasek: i. e. make all dupes of youridX a dupe of masterid first
<seb128> pitti, launchpad does the right thing nowadays as well
<pitti> oh, slangasek just seemed to have that problem
<seb128> i.e it doesn't complain about the bug have duplicates but just reassign those
<slangasek> oh, does it?
<slangasek> I didn't actually try, I saw there were many many duplicates and ran away ;)
<slangasek> decided I should do real work, like maybe fixing the bug
<cjwatson> slangasek: http://blog.launchpad.net/cool-new-stuff/dupety-dupe
<slangasek> ah, neat :)
<SpamapS> this is maddening.. strace shows php doing an strace .. but gdb never traps one.. >:|
<SpamapS> rrrrr
<SpamapS> lets try that agin
<SpamapS> this is maddening.. strace shows php doing an ioctl .. but gdb never traps one.. >:|
<apw> SpamapS, where are you putting hte breakpoint in gdb
<SpamapS> b ioctl
<SpamapS> it does break on some other cases w/ ioctl
<apw> SpamapS, could it be using another interface like ioctl_compat or syscall() direct ?
<SpamapS> trying to find where libedit is taking control of the terminal. :-P
<SpamapS> apw: would that show in strace as ioctl( ?
<apw> some might well yes
<SpamapS> *arg*
<apw> as thats someone crossing the syscall infterface asking for SYS_ioctl
<apw> not which library routine they are using
<SpamapS> I don't really see ncurses or libedit doing that..
<SpamapS> but who knows
<SpamapS> that may be the very root of the problem I'm trying to debug.. that they've gone too low level
<apw> SpamapS, good luck trying to figure that one out
<SpamapS> apw: maybe strace can help me..
<apw> not sure how?
<apw> it only sees the kernel side of the line
<SpamapS> well its showing an ioctl where gdb isn't...
<SpamapS> ahhh
<SpamapS> ltrace -S shows SYS_ioctl
<apw> ltrace ?
<SpamapS> yeah.. ltrace. :)
<apw> but either way i assume that means it is seeing a real call to the kernel, just not from the libc ioctl call
<apw> which is what we suspected
<SpamapS> yeah, so ltrace at least shows me the library calls that surround the SYS_ioctl calls
<apw> oh nice, so which one
<SpamapS> I can hook in there and step into the rabbit hole
<apw> SpamapS, let me know when you find out, useful to store away for next time
<SpamapS> apw: yeah, this little annoying bug in libedit has really driven me nuts
<smoser> just a question.  i type 'apt-get install ctags' and it says:
<smoser>  Note, selecting 'exuberant-ctags' instead of 'ctags'
<smoser> what manages that "alias" ?
<cjwatson> exuberant-ctags is the only package that Provides: ctags
<smoser> ah. i should have guessed. thanks cjwatson
<cjwatson> if there'd been more than one Provides, you'd have got an error telling you to explicitly select one instead
<rsalveti> can any archive admin help me publishing the new x-loader package version?
<rsalveti> https://launchpad.net/ubuntu/+source/x-loader
<rsalveti> still waiting to be published
<ogra> and while that archive admin is at it, an unleashing of unity-2d from NEW would also be appreciated
<ogra> :)
<ogra> (unity-2d-default-settings was merged into the unity-2d source package)
 * highvoltage wondered where unity-2d was (stgraber told me it existed so I wanted to test it :p)
<ogra> oh, and its cjwatson's archive day
<ogra> highvoltage, its there since two weeks now :)
<ogra> but only with this package you can apt-get install unity-2d
<ogra> before you needed unity-2d-default-settings
<SpamapS> apw: btw its tcgetattr that is confusing things
<SpamapS> 41	  retval = INLINE_SYSCALL (ioctl, 3, fd, TCGETS, &k_termios);
<apw> SpamapS, nice
<SpamapS> apw: luckily called only about 5 lines into the library function before my ioctl :)
<ogra> jhunt, any news about the serial stuff ?
<jdstrand> seb128: hey, shotwell has a build-depends on valac-0.10, but valac-0.10 is NBS. would you mind get that tested/fixed? (I'd ask robert_ancell, but he doesn't see to be around)
<seb128> jdstrand, there is a list a things that still use vala-0.10
<seb128> jdstrand, it's on my list of things to discuss with the desktop team, we might bring back vala-0.10 as a different source
<seb128> or we need to port the remaining items
<seb128> jdstrand, robert_ancell is at lca this week
<jdstrand> seb128: ok, thanks
<seb128> do you need that sorted now or can it wait a few days?
<jdstrand> seb128: I think it can wait
<seb128> jdstrand, ok, I will probably bring it at our meeting next week
<seb128> jdstrand, I will get back to you when we have it sorted
<jdstrand> thanks!
<ion> pitti: A small typo in jockey/handlers/nvidia.py: s/accelleration/acceleration/. Btw, is the incomplete sentence in which the word occurs intentional? How about changing it to something like âYou should install it if you wish toâ¦â?
<SpamapS> ogra: its being discussed quite a bit on upstart-devel as to how to do it for the future...
<SpamapS> ogra: also cjwatson brought up that d-i will setup a special ttySomething.conf if a serial console is used for the install..
<ogra> SpamapS, i know, arm doesnt use d-i
<ogra> SpamapS, jhunt wanted to give me an update today
<SpamapS> ogra: so we'll have to disable that in d-i if we come up with a more generic solution that respects the kernel args
<hallyn> what is d-i exactly?
<SpamapS> debian-installer
<ogra> (well, arm uses d-i as anything else, but our current preinstalled images are preinstalled indeed)
<hallyn> thx
<SpamapS> used by minimal and alternative install right? server and deskto puse ubiquity IIRC
<ogra> we dont build minimal or alternate atm, but yes
<ogra> we currently build preinstalled images, one for server is in the works
<ogra> they are fully focused on SD cards and just expand the installation partition on first boot
<ogra> the install is done beforehand
<SpamapS> ogra: given that upstart doesn't expose the kernel commandline stuff to jobs .. and will have to be patched to do so.. I think its a safe bet that parsing /proc/cmdline after the filesystem event is going to be fine in terms of not hurting boot time too much.
<ogra> k
<ogra> i thought there was a kernel patch added in maverick that was supposed to exactly do that
<SpamapS> ogra: its more of making sure that we don't step on d-i's toes and that we don't slow the boot accidentally.
<ogra> apw, was that patch ripped out again ?
<SpamapS> ogra: the kernel patch passes the console params as env vars to init yes
<ogra> right
<SpamapS> ogra: but init doesn't do anything with them
<ogra> so we should have the values
<SpamapS> no they're not copied into the child environments
<ogra> init doesnt pass them on the the jobs ?`
<ogra> ah
<ogra> then i misunderstood completely
<SpamapS> Though I haven't tested whether that can be enabled by simply saying 'env console' ... meaning to do that... but I think the way I read the code, that didn't seem to be useful.
<ogra> ok
<sebrock> I need to contact the developer or maintainer of a certain package in Lucid. However it simply says its most likely the Debian maintainer. How does that work? Who packages it for Ubuntu?
<SpamapS> for performance reasons (I think) init doesn't pass anything to children that isn't defined in the job or the events.
<ogra> so we either go with what we have as distro patch or we need to keep the existign hackery
<ogra> i would still prefer an upstart patch instead of the hacks
<ari-tczew> mr_pouit: around?
<SpamapS> ogra: I think there are some tentative +1's for the proc cmdline patch to go forward until init does the right thing w/ those env vars.
<ogra> ah, great
<SpamapS> ogra: my crazy idea was why don't we just have getty leave the serial port settings untouched and let the kernel manage them. :-P
<ogra> make the kernel pull from console= ?
<SpamapS> the kernel already sets the params from console= ..
<ogra> could be dangerous if the user heavily mistypes
<SpamapS> so if getty didn't make any attempt to change them, they'd be set correctly already
<ogra> oh
<ogra> i didnt know that
<ogra> i agree that would be cooler
<kees> wendar: oh, nice additional finds in bsdmainutils. I clearly didn't look hard enough.
<ogra> i thought getty needs them
<SpamapS> right, well its already getting stuff spewed out by kprint
<SpamapS> getty does need them, but we could patch getty to have a '--no-setserial'
<SpamapS> just open and go
<wendar> kees: thanks!
<SpamapS> but then if anything changes them.. you want getty to reset them
<SpamapS> so if the upstart job can save them off somewhere and restore them later.. that would work.
<wendar> kees: should I request a sync on the 8.2.2 debian release, or are you doing it?
<ogra> what would change them between init and getty ?
<SpamapS> ogra: getty has a cool hack where if you send a BRK then it cycles through all known baud rates
<SpamapS> ogra: useful when you want to just plugin and go and don't know the baud rate
<ogra> yeah
<kees> wendar: either way. I was going to, but requestsync doesn't see 8.2.2 yet
<SpamapS> ogra: but you'd still want it to go back to whatever the kernel had specified
<ogra> well, i like that approach
<SpamapS> me too.. the question is.. where do we store the settings?
<ogra> does it need persistance over boots ?
<wendar> kees: okay, cool, I'll leave it with you. Will make a note in the LP ticket.
<ogra> else i'd say /var/run
<kees> wendar: cool
<SpamapS> ogra: right, /var/run is my suggestion too... I was also trying to see if there's a way to store it in an env var in the upstart job.
<SpamapS> ogra: definitely doesn't need to survive reboot
<ogra> right, then /var/run/serial or some such
<SpamapS> ogra: for the future upstart console handling.. I think upstart will keep track of it.
<ogra> or something like  /var/run/console-settings
<ogra> sweet
<SpamapS> btw, does anybody know what the policy is on /etc/default files and upstart jobs? It seems like to support upgrades, all converted init.d->upstart job files need to keep sourcing that file.
<SpamapS> zul: ping, I bet you know.
<SpamapS> slangasek: ^^
<zul> SpamapS: as i understand it you shouldnt use /etc/default with upstart
<SpamapS> zul: but that *completely* breaks upgrades
<zul> SpamapS: i could be wrong
 * SpamapS looks through release notes to see if its at least mentioned there
<slangasek> SpamapS: there's no "policy", just a set of opinions :)
<slangasek> SpamapS: I've consistently taken your approach when upstarting packages - preserve behavior on upgrades where reasonable
<SpamapS> slangasek: I think /etc/default files should be sourced and respected still, or the change in behavior mentioned in the release notes.
<cjwatson> ogra: d-i> my point was more that it needs not to conflict, and that the lessons learned while implementing it in d-i should be carried over
<ogra> cjwatson, ah, indeed
<cjwatson> rsalveti: done
<rsalveti> cjwatson: thanks!
<slangasek> SpamapS: amusingly, I've just discerned why gssd and idmapd don't suffer from the startup race with equal incidence - it's because idmapd is (uselessly) sourcing /etc/default/nfs-common in a script, and gssd is execing rpc.gssd directly
<slangasek> SpamapS: anyway, yes, anywhere that /etc/default might have contained relevant config information, I've preserved that when converting to upstart even though this makes the start-up less efficient
<cjwatson> ogra: accepted unity-2d.  could you please make its Conflicts/Replaces be Breaks/Replaces instead, per current policy?
<ogra> oops, will do
<SpamapS> slangasek: I knew there had to be something fixing rpc.gssd other than "its just special" ;)
<SpamapS> slangasek: I do think we'd also be fine if we put in the release notes something about it, and maybe included a script that told you what non-default values you've used in /etc/default.
<SpamapS> slangasek: its the old deprecated conffile problem all over again isn't it?
<slangasek> well, more or less
<slangasek> if I were going to drop an /etc/default file, I would do it by migrating the settings to the upstart job and then deleting the file from /etc/default
<slangasek> which is touchy, which is why I haven't done this yet
<slangasek> now, here's a question
<SpamapS> slangasek: it seems like it should be ok.. but it would break with conffile policy to do it in maintainer scripts..
<slangasek> is it right for upstart-job to be a no-op for 'start' just because 'status' shows a PID?
<slangasek> SpamapS: yes, I like to live in my own special gray area where conffiles are concerned :)
<slangasek> (maybe that's another reason I haven't done this yet)
<SpamapS> well in this case you're technically just merging the old one into the new one.. :)
<slangasek> upstart-job> consider the case where the job has a post-stop script and the status is stop/stopping $pid
<slangasek> that doesn't sound to me like a case to turn 'start' into a no-op
<SpamapS> slangasek: right I think it has to already bean in a goal of start.
<SpamapS> bean.. hrm.. almost lunch time.. ;)
<slangasek> SpamapS: so do you think start/.* $PID is the right boundary?  Or should it just be start/running, with no PID check?
<slangasek> (a 'start' for a job that's still starting is a no-op anyway, isn't it?)
<SpamapS> slangasek: its conceivable that some jobs will use pre-start and post-stop to run whatever it is they're doing, and not have a pid.
<slangasek> yes, that's the precise bug I'm fixing right now
<slangasek> (upstart-job handles apport wrong)
<SpamapS> is it a task?
<slangasek> but what I'm wondering is if we should *only* be checking for start/running status, and ignore PIDs completely
<slangasek> I'm inclined to say the answer is "yes"
<slangasek> because bzr says I wrote the original code here
<slangasek> and I think I was wrong :)
<SpamapS> I agree on principle, but I'm not sure I understand where upstart-job is handling apport incorrectly.
<slangasek> SpamapS: it's not a task, it's a pre-start+post-stop w/ no main process
<seb128> is there any way to delete something from the unaccepted queue if I just uploaded?
<SpamapS> are you saying that when its in start/running already, that it runs start again, but fails, and this is a problem?
<slangasek> SpamapS: so upstart-job says "oh, you want to start this thing w/ no PID, let me do that for you" and then fails
<slangasek> seb128: unaccepted -> unapproved?  If so, yes
<seb128> slangasek, how?
<slangasek> seb128: q reject $thingy
<Keybuk> right, it's perfectly cromulent for Upstart jobs to have no main process
<slangasek> seb128: unless this was a generic "you"; I'm assuming I'm talking to the "you" who is an archive admin :-)
 * SpamapS thinks Cromulence should be a chief goal of any pid 1 replacement
<seb128> slangasek, well that acts on "NEW" no?
<Keybuk> SpamapS: it really embiggens the feature set
<SpamapS> slangasek: right, ok I understand, and looking at the code.. yeah.. you shouldn't care about the PID, just the state.
<seb128> slangasek, or q -Q unapproved?
<seb128> slangasek, well I've been lucky on this one the upload got rejected because it was a revision update and the tarball is not in natty
<seb128> slangasek, but that can be useful for next time ;-)
<slangasek> seb128: yes, it's 'q -Q unapproved -s $foo-proposed reject $thingy'
<seb128> slangasek, well that was an upload to natty
<seb128> not to a moderated queue
<slangasek> seb128: oh, then there's no unapproved queue at all :)
<slangasek> so no, sorry, no way to intercept AFAIK
<seb128> I was wondering if there was a way to catch it before the next run
<seb128> ok, what I think
<seb128> though
<seb128> slangasek, thanks
<slangasek> pitti, seb128, cjwatson, SpamapS: I've pushed my fix for bug #603934 to lp:ubuntu/upstart, then; I'm still testing it here, more eyeballs before I upload would be appreciated
<ubottu> Launchpad bug 603934 in upstart (Ubuntu Natty) "upstart-job returns SysV-incompatible value for 'start' when job is already running" [Critical,Triaged] https://launchpad.net/bugs/603934
<SpamapS> slangasek: that code actually reads much easier too. :)
<cjwatson> seb128: if you're quick enough then you can sudo to lp_queue and nuke it before process-accepted runs (*/5), but you do have to be quick
<cjwatson> once it hits the accepted queue, build jobs will be created and all the rest of it
<seb128> cjwatson, where is it on disk?
<cjwatson> ~lp_queue/ubuntu-queue/incoming/
<seb128> cjwatson, ok, worth knowing, thank you
<mnabil> hello guys , i want to participate in ubuntu development cycle ?
<mnabil> is there any process i should follow ?
<SpamapS> mnabil: what do you want to do?
<SpamapS> mnabil: this might be a good place to start https://wiki.ubuntu.com/UbuntuDevelopment
<mnabil> SpamapS, i know C/C++/Python and i'm involved in Lxcenter and cloud
<mnabil> i can be helpful :)
<SpamapS> https://bugs.launchpad.net/ubuntu   ... there are 87367 bugs to choose from.. have fun! ;)
<JackyAlcine> Only 87367?
<mnabil> SpamapS, thanks alot for you help
<cody-somerville> I assume libdrm-nouveau1a breaking natty bootstrap process is known?
<RAOF> It should be fixed now.
<cjwatson> cody-somerville,RAOF: maybe not entirely fixed - I've just made a pair of override changes in the archive which should help, in about an hour's time
<cjwatson> though xserver-xorg-video-nouveau will still have trouble installing
<RAOF> The new nouveau upload should be installable
<ari-tczew> Debian will be released 5th/6th February :>
<real_ate> hi all! quick question... is there a page anywhere detailing or documenting how to create "quickly" templates?
<real_ate> my searches are ending up fruitless
<blueyed> zul: can you sponsor a munin upload for me? I've just noticed that it is in main, after uploading. I upload the package to own webspace, ok?
<blueyed> zul: it is here now: http://codeprobe.de/spool/debian/munin_1.4.5-3ubuntu2.dsc
#ubuntu-devel 2011-01-27
<aljosa_> i'm looking for a technical mailing list where i can ask questions about rpm/deb formats and similar topics. is there some place where rpm/deb developers communicate?
<Keybuk> aljosa_: to my knowledge, rpm and deb developers do not communicate with each other
<aljosa_> Keybuk: really? do you know why?
<Keybuk> aljosa_: because they have nothing to talk about, I guess
<RAOF> Anyone available to sponsor a quick xserver-xorg-video-intel upload?
<StevenK> I might be
<RAOF> http://cooperteam.net/Packages contains the relevant source.
<StevenK> RAOF: 2.14.0-1ubuntu2 ?
<RAOF> StevenK: Indeed.
<RAOF> I can throw you up a debdiff if you'd like, too.
<StevenK> RAOF: Uploaded.
<RAOF> StevenK: Thanks muchly!
<RAOF> In case I haven't pointed you at it, https://wiki.ubuntu.com/ChrisHalseRogers/CoreDevApplication
<RAOF> :)
<StevenK> RAOF: Ah, let me scribble over that for you
<ari-tczew> RAOF: I guess that DMB will tell on meeting that you have endorsements only from Canonical friends :P
<broder> hmm...i would have sworn i sponsored something for RAOF...
<StevenK> ari-tczew: I've known and sponsored stuff for RAOF before we both worked on Canonical, so ...
<StevenK> s/on/at/
<StevenK> RAOF: Application endorsed.
<RAOF> StevenK: Thanks.
<ari-tczew> StevenK: Don't get me wrong. DMB just making sure that there is no favoritism.
<StevenK> ari-tczew: I think it's bunk. People that he commonly works with are commenting on his work. If RAOF just got given core-dev, *then* there would clearly be favoritism.
<persia> ari-tczew, Don't fuss about it too much.  Most DMB members have been around a long time, and tend to know who folk are to some degree.
<ari-tczew> :):)
<ari-tczew> !ftbfs | ari-tczew
<ari-tczew> [02:53] <ubottu> Sorry, I don't know anything about ftbfs
<ari-tczew> not good
<persia> Why?
<ari-tczew> persia: ftbfs should be famous phrase :)
 * ari-tczew is checking whether there is FTBFS page on wiki.u.c.
<persia> It is.  It's so famous nobody needs the bot to remind them :)
<ari-tczew> persia: but would be nice if bot could reply like: FTBFS - Failed To Build From Source. Read more on https://wiki.ubuntu.com/PackagingGuide/FTBFS
<ari-tczew> above page seems to be very poor
<ari-tczew> could anyone with good english improve it?
<persia> The language isn't the issue: the issue is that there are so very many causes that it's hard to have good examples, except for specific things (like the recent linker issues, or API transitions, or similar)
<persia> Aside from that, I'm unsure who would benefit from the factoid.  It's not hard to add, but every factoid makes the bot a bit slower.
<ari-tczew> persia: every data is important :) so let's complete it instead fruitless debating
<nigelbabu> persia: lovely mail :)
<persia> Thanks.
<nigelbabu> I guess I should poke someone to get that on the fridge
<nigelbabu> and probably the wiki
<persia> There are, of course, lots of other ways to become a developer, but I hope that path is one people can follow without being confused by all the complexity.
<nigelbabu> Yeah, the various choices are probably very confusing for a new comer.
<persia> Feel free to repost that anywhere, but please include the mention from the first paragraph that this is but one path of many, so people doing it other ways aren't necessarily doing it wrong (although they may find parts of the mail helpful in any case)
<nigelbabu> I think the whole mail would go into a blog post.  But I'm pretty sure most fridge folks are asleep.
<nigelbabu> And I'm at the Ubuntu Developer Day listening to Chase talk about touch interfaces
<persia> No huge rush or anything.  I heard people complaining about complexity and bureaucracy for months before I wrote that: most folk won't notice waiting even a week or so.
<kklimonda> masters of the unseeded? really? that sound so dirty ;)
<kklimonda> good morning
<broder> i kind of hope we can stick with masters of the universe even when universe goes away. it's just got a fantastic ring to it :)
<nigelbabu> kklimonda: lol
<persia> broder, For the next few cycles, I prefer "unseeded", if only to avoid confusion with the "universe" component.  Once we can drop the component (and there are lots of outstanding blockers), then reclaiming "universe" is very tempting.
<broder> persia: ok, i can settle for a temporary loss of awesome
<persia> broder, If you're interested in making the "temporary" shorter, try to identify one of the semantic applications of "main" vs. "universe", and then work on the necessary changes to policy, code, etc. in order to replace it with something else.
<persia> An example I haven't even begun to think about much would be translations: currently stuff in main gets translated, and stuff in universe doesn't, with exception lists both ways.  That probably needs a heap of changes in Rosetta, in the langpack mechanisms, in how translations are delivered to users, etc.
<persia> But there's lots of other things :)
<nigelbabu> the scale of the changes is um scary (sort of)
<persia> Kinda, yeah.  The initial model made sense, but it started to get fuzzy for Hoary, and we didn't start thinking about how to fix it until Intrepid, and a lot of things turned out to have been set up to use components for convenience in the meantime.
<\sh> moins
<evilvish> persia: nice mail(devel-list).. you should consider making a wiki out of it.. so that it is more permanent :)
<evilvish> .. since it is very common Q , maybe we could move it to a wiki page and link to it from https://wiki.ubuntu.com/UbuntuDevelopment#Overview%20of%20Development or similar..
<persia> evilvish, The main issue is that it's not complete: there's other ways to become a developer (although I think that one is the easiest).
<evilvish> yup.. and a wiki is way we could add upon(in future)
<persia> I guess.  My experience with the wiki is often that something there ends up being "official" in some way, and thereby sacrosanct.  Your experience may vary.
<evilvish> persia: yea.. but, you do sit on both the DMB and the regional councils ;) , though not 'officially sanctified' yet.. it is like an insider's take :)
<evilvish>  or we could get dholbach to re-blog it..
<evilvish> i usually ask new-comers to go through his blog, has some interesting posts for new folk..
<persia> If someone else wants to blog about it, I'd rather they blog about their view of a good path, rather than just reposting mine.  Something like the fridge (as suggested earlier), which regularly republishes is one thing, but blog posts ought be personal.
<evilvish> yea, but you dont blog :)
<evilvish> not sure, fridge is the right place for this though, it aint news
<evilvish> hence wiki was the closest, i could think of..
<pitti> Good morning
<persia> It's in mail archives.  With luck, it will result in a bundle of new developer applications from previously frustrated folk over the next 3-6 months.
<persia> After that, something else can happen.
<pitti> ion: typo and incomplete sentence fixed, thanks!
<m4rtin> if I install the Natty alpha to a new partition, will the update-grub script within that pick up and list my maverick partition?
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<didrocks> good morning
<cjwatson> m4rtin: it ought to, yes
<m4rtin> thank you :)
<cjwatson> (there are some cases where it might not, for example if the maverick root filesystem wasn't unmounted cleanly for some reason)
<pitti> zul: do you still actually support nut? it's one of the few packages which still pulls in hal, which is totally unsupported these days
<ion> Also, do nut users actually use nut-hal-drivers? :-)
<pitti> it's not seeded on the server CDs
<pitti> you can build it without hal support, too
<pitti> "it's" -> nut-hal-drivers
<pitti> heh, and it even conflicts to nut
<smb> pitti, Hi Martin, do you know who would be the person to ask about cdimage.ubuntu.com? Just was asked by someone where to find the maverick server images and those seem to be strangely missing.
<pitti> smb: they are on releases.ubuntu.com
<smb> pitti, Ah ok
<pitti> cdimage only has the less used ones, such as DVDs and some derivatives
<pitti> or alphas
<pitti> mr_pouit: do you know what should happen with xfce4-volstatus-icon, xfce4-governor-plugin, xfce4-cddrive-plugin? these still use exo 0.3 and HAL, and I think someone said they should just be dropped from the archive?
<mr_pouit> pitti: for xfce4-volstatus-icon and xfce4-cddrive-plugin, it's unsure. I've written that I'll drop them from the archive after FF if nobody worked to save them
<pitti> mr_pouit: ah, good
<mr_pouit> pitti: xfce4-governor-plugin doesn't use exo-0.3 though iirc
<Riddell> persia: do you or your mobile friends have an opinion on bug 708519 ?
<ubottu> Launchpad bug 708519 in qtmobility (Ubuntu) "Please drop hal dependency" [Undecided,New] https://launchpad.net/bugs/708519
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, did you start on the proxy issue of Jockey and s-c-p?
<pitti> not yet
<tkamppeter> pitti, another question, I need a new monitor for my PC, do you have an yrecommendation? Or a recommendation for a good review site?
<pitti> tkamppeter: last time I bought one I looked in c't
<pitti> they do quite thorough reviews
<pitti> otherwise I don't know a good site, I'm afraid
<jkakar> pitti: Hi!
<pitti> hey jkakar, how are you?
<jkakar> pitti: I'm doing great, thanks!  How about you? :)
<pitti> jkakar: I'm great, thanks
<pitti> having fun in Natty :)
<jkakar> pitti: Awesome. :)
<jkakar> pitti: We're just talking about what to do about the HAL dependency in landscape-client.
<jkakar> Re: bug #708502
<ubottu> Launchpad bug 708502 in landscape-client (Ubuntu) "Please drop hal dependency" [High,New] https://launchpad.net/bugs/708502
<jkakar> pitti: We don't really have the time/capacity to migrate to udev right now.
<jkakar> pitti: We're wondering about making hal a 'Suggests', so that the client can be installed without it, and making some tweaks to the code so it won't blow up if HAL isn't there.
<jkakar> pitti: The question is, will the hal package be moving to universe?
<pitti> jkakar: I was actually quite surprised that it still used it; I thought we already talked about it many years ago
<pitti> jkakar: I hope that we can move it to universe in natty or n+1
<jkakar> pitti: We did, we just haven't made time for it... too many bigger fires to deal with. :(
<persia> Riddell, Looks like upstream 1.1 is out, but still has the dependency on HAL, and I don't see any halsectomy related items on the 1.2 roadmap.  qtmobility can be compiled to not use HAL, with "reduced functionality".  I don't know of anyone actively using these APIs though, so I'd be tempted to compile with the reduced functionality (unless you know a user my apt-cache isn't finding).
<jkakar> pitti: Okay, so there's a chance it won't make it for natty.
<pitti> persia: it's not a compile-time thing; it only talks to the dbus interface
<persia> pitti, Is there a reason to move to universe, or can we just drop it?
<jkakar> pitti: I guess very few packages actually use it, right?
<pitti> persia: i. e. simply runtime
<persia> pitti, There's a compile-time option to tell it not to ask DBus about HAL.
<persia> (or else I'm reading the docs wrong)
<pitti> jkakar: it's qtmobility and landscape-client, the rest was fixed or will be in the next days
<pitti> persia: right, but ideally it would just fail gracefully if hal isn't running (I haven't checked)
<pitti> jkakar: out of interest, what do you use it for?
<jkakar> I suppose one option for us is to make hal a Suggests and do a conditional import... if hal is unavailable (because the package is gone entirely) the hardware inventory will be simply unavailable.
<jkakar> pitti: We pull the entire HAL device tree and send it to the server.  We provide a view of that data to our users.
<pitti> jkakar: is that merely for display purposes, or do you actually do something with the data?
<jkakar> pitti: Honestly, the functionality we have isn't so useful.
<jkakar> pitti: Merely for display purposes.
<jkakar> pitti: But we don't have the time to replace it with something better right now, so we're trying to figure out how to keep it working if possible.
<pitti> jkakar: the hal tree is by and large the sysfs tree
<jkakar> pitti: True.
<pitti> an udevadm info --export-db usually gives enough info about the hardware, at least in the bugs that I am looking into
<jkakar> pitti: One issue is that udev provides really crappy data on <lucid.
<pitti> and given that hal likes to break stuff, and at least slows things down (double-probing), I'd rather not force it on our users any more
<jkakar> pitti: We need to support dapper for a few more months, but more importantly, we have a number of hardy users and we want to provide a good experience for them if possible.
<pitti> jkakar: sysfs/udev on hardy should work just fine
<jkakar> pitti: Yep, agreed, getting rid of hal is the right thing to do.  We don't want to block that.  We just want to figure out if hal will be moving somewhere else (universe).
<pitti> jkakar: yes, to universe
<jkakar> pitti: It works fine, but the data it exposes is missing lots of interesting things.  The data for lucid and newer is much better/richer.
<Riddell> persia: where is the 1.2 roadmap?
<persia> pitti, qtmobility does appear to fail gracefully, from a quick look at ./src/systeminfo/qsysteminfo_linux_common.cpp
<pitti> jkakar: but the more important thing than the component is that we don't really want to force users to get hal if they install landscape, as it changes the system behaviour
<jkakar> pitti: Cool.  In that case I think what we'll do is make hal a 'Suggests' and, if people want it, they can install it from universe.  We'll do a conditional import and disable the hardware plugin if hal isn't installed.
<persia> Riddell, http://bugreports.qt.nokia.com/secure/IssueNavigator.jspa?reset=true&jqlQuery=labels+%3D+mobility_roadmap+ORDER+BY+component+ASC,+key+DESC
<pitti> jkakar: that sounds great
<jkakar> pitti: Cool, thanks.
<Riddell> persia, pitti: I think I'll move hal to a Suggests then and file a bug with upstream
<persia> Riddell, Sounds reasonable.  Do you think it's worth compiling QtMobility to not use HAL at all, or just have it be optional?
<pitti> Riddell: sounds great, thanks
<pitti> persia: I think leaving the optional support in doesn't hurt
<pitti> I don't think that anyone actually wants to install hal on mobile devices, given it's boot speed penalty and extra power drain
<jkakar> Thanks guy!
<pitti> but if they really want to..
<persia> pitti, My fear is an unmaintained HAL in universe with N tools providing slightly different functionality if it happens to be installed.
<persia> And I think most users are likely to install random things found from a web search about their problem, rather than think about the implications carefully.
<Riddell> I don't think there actually is a compile option to not use hal, it's all runtime
<pitti> persia: right, that's why I'd like to drop the dependencies and kick it into universe (as it also changes system behaviour under GNOME/KDE)
<persia> How does that help?  Universe is available by default.
<persia> (and if I ever succeed in getting rid of universe, it comes back :) )
<pitti> persia: right, but at least not installed automatically via depends
<pitti> which is my main gripe with landscape-client
<persia> Riddell, Indeed.  I read that wrong: the compile-time switch turns off DBus support entirely, which is undesired.
<persia> pitti, Is there a case for keeping HAL in the archives at all, or is it just a matter of the volume of work to eject it?
<pitti> persia: universe still has a fair bunch of rdepends
<pitti> some of them can probably be dealt with by package removals
<pitti> such as gnome-device-manager
<persia> Heh, yeah, that's just a GUI for HAL.
<pitti> or ivman/mountmanager
<persia> But to ask the question differently: does HAL provide any functionality that we expect users to want to optionally install sometimes, beyond rdepends?
<pitti> there's always udisks-automounter for those who don't want to use gnome/kde/xfce
<Laney> is debian deprecating hal too?
<pitti> persia: no
<pitti> Laney: yes, they do
<Riddell> http://bugreports.qt.nokia.com/browse/QTMOBILITY-1057 filed
<pitti> http://wiki.debian.org/HALRemoval
<pitti> Laney: ^
<persia> Ah, then I think we ought plan to drop HAL entirely, including from universe (although this may take longer than dropping from main)
<persia> Riddell, Thank you :)
<Laney> *verse can probably be done as an initiative in coordination with Debian maintainers then
<Riddell> doko: I uploaded qt3 for the GCC 4.6 include issue
<JamesPage> Hi - would it be possible to get irqbalance manually imported (its currently failing due to utf-8 characters in the changelog - http://package-import.ubuntu.com/status/irqbalance.html)
<doko_> Riddell: cool, thanks
<ari-tczew> kees: I guess you might would like have a look on bug 708607 :)
<ubottu> Launchpad bug 708607 in bsdmainutils (Ubuntu) "Sync bsdmainutils 8.2.2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/708607
<ari-tczew> cjwatson: how Merge-o-Matic gets tarball from Debian if there is no this version on ftp?
<cjwatson> ari-tczew: can I have an example?
<cjwatson> it gets all its tarballs from Debian's FTP server
<cjwatson> whether it keeps them for the same period of time as Debian does is a different matter :-)
<mdeslaur> good morning
<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
<SpamapS> jhunt_: 'morning!
<zul> pitti: er hal is gone?
<pitti> zul: it got deprecated years ago, and now it's going to universe
<zul> pitti: ah ok...ill talk to arnaud then
<zul> pitti: thanks for the heads up
<pitti> thanks
<soren> pitti: Years? Wow, time flies. It feels recent.
<pitti> soren: deprecation started in May 08
<tkamppeter> pitti, I found my new monitor now, thanks to http://www.trustedreviews.com/.
<soren> pitti: Intrepid still had it installed by default, didn't it?
 * soren reminisces
<pitti> soren: yes, it took us a while to remove all the reverse deps
<soren> Ah... Great days.
<ari-tczew> cjwatson: bluez, need merge from experimental
<cjwatson> ari-tczew: MoM doesn't show bluez at all, so I don't understand what tarball you're talking about (assuming this is a followup to your earlier question).  URL please?
<ari-tczew> cjwatson: as I wrote, experimental - MoM looks on unstable.
<cjwatson> I know.  But what tarball are you talking about?
<cjwatson> 12:43 <ari-tczew> cjwatson: how Merge-o-Matic gets tarball from Debian if there is no this version on ftp?
<cjwatson> I simply do not understand this question
<cjwatson> what missing version are you talking about?
<ari-tczew> cjwatson: MoM creates patches on: old debian version -> current ubuntu and old debian version > new debian version
<cjwatson> rmadison says experimental currently has bluez 4.87-1, and the source for that is on http://ftp.debian.org/debian/pool/main/b/bluez/ where I'd expect it to be
<ari-tczew> and I want to get source of old debian version
<cjwatson> MoM keeps the base version around in a local cache until it doesn't need it any more
<cjwatson> try snapshot.debian.org
<cjwatson> (ok, thanks, I understand your question now)
<ari-tczew> cjwatson: thanks, that's what I'm looking for ;)
<ari-tczew> I was looking *
<cjwatson> http://snapshot.debian.org/package/bluez/4.81-1/
<cjwatson> would be the base version in this case
<ari-tczew> yea I found now ;-
<ari-tczew> ;-)
<ari-tczew> dget mode on
<SpamapS> jhunt_: when you're around.. wondering in what state your upstart intro man page is, and whether it satisfies my workitem to document all of the events.
<pitti> zul: do you guys care much about nut-hal-drivers? (it conflicts with "nut"); if not, we could disable the hal part entirely
<pitti> zul: n-hal-drivers is in universe
<jhunt_> SpamapS: the intro page is very much in a state of flux right now. I'm reworking the events summary (a separate man page) to include event type. this is almost complete. The problem is keeping the table within 80 cols! :)
<zul> pitti: no we dont
<zul> i was thinking of removing it entirely
<pitti> zul: from server-ship, you mean?
<zul> pitti: yes
<jhunt_> SpamapS: you on mumble?
<pitti> zul: no objection here :)
<zul> pitti: nut-hal-drivers have already been dropped in the seeds almost a year ago
<pitti> zul: right, but the package still needs libhal-dev as build dep
<pitti> and thus keeps the source in main
<zul> pitti: ill drop the hal stuff from nut today
<pitti> zul: thanks
<quadrispro> pitti XOR cjwatson: have you a bit of time to take a look at bug #708008?
<ubottu> Launchpad bug 708008 in gmerlin-encoders (Ubuntu) "Move gmerlin-encoders-extra to multiverse" [Medium,Confirmed] https://launchpad.net/bugs/708008
<pitti> quadrispro: can do
<SpamapS> jhunt_: I am but everybody's asleep here. :-P
<SpamapS> jhunt_: and the walls are very thin.
<SpamapS> jhunt_: will you be on in an hour? then everybody will be up and gone
<jhunt_> SpamapS: funny, I'm actually working in exactly the same conditions right now too :) Yes, I'll be around then.
<Vonor> hi
<Vonor> is this the right channel to ask for help regarding compiling a package on a non-ubuntu distribution? (I'm trying to port an ubuntu package to gentoo)
<quadrispro> thanks pitti !
<SpamapS> jhunt_: ack
<Vonor> just in case someone can help. I'm trying to build the netbook-launcher application. configure complains about some package dependencies not met and I'm currently trying to fix them one by one. as seen in the build.log ( http://paste.pocoo.org/show/327822/ ) the first package is clutk, of which i just successfully installed the latest version (0.3.60) but configure still says it's not there
<Vonor> searching for clutk:
<Vonor> # find /usr -iname "*clutk*" | wgetpaste
<Vonor> Your paste can be seen here: http://paste.pocoo.org/show/327828/
<JamesPage> james_w: any chance you could manually import irqbalance for me? its currently stuck (http://package-import.ubuntu.com/status/irqbalance.html)
<Vonor> i figure that netbook-launcher explicity asks for the old clutk-0.2 is there any reason why it doesn't make use of clutk-0.3.x?
<james_w> JamesPage, it's started
<JamesPage> james_w: thankyou :-)
<cjwatson> JamesPage: bug 708537 - debconf is pure perl, there should be no way for it to crash the perl interpreter without perl being buggy
<ubottu> Launchpad bug 708537 in debconf (Ubuntu) "package mysql-server-5.1 5.1.41-3ubuntu12.9 failed to install/upgrade: segementation fault in debconf frontend" [Undecided,New] https://launchpad.net/bugs/708537
<cjwatson> JamesPage: (or without one of the C extensions that some of the frontends use being buggy)
<james_w> JamesPage, done
<Riddell> rsalveti: what changes are needed to qt as part of multimedia-arm-gles-in-ubuntu ?
<rsalveti> Riddell: bug 707794
<ubottu> Launchpad bug 707794 in qt4-x11 (Ubuntu) "libqt4-opengl on armel should be compiled with OpenGL ES 2.x support" [Undecided,New] https://launchpad.net/bugs/707794
<rsalveti> not much, but qt is not the main problem
<rsalveti> seems other packages that uses it could break on arm
<rsalveti> that's what I'm testing atm
<ari-tczew> pitti: I'd like to debate with you about 1 SRU. are you able?
<rsalveti> Riddell: but if you think it would be ok to have it with gles support now, we can work fixing the other bugs later
<pitti> ari-tczew: which one?
<ari-tczew> pitti: https://code.launchpad.net/~iheino+ub/ubuntu/lucid/w3m/bug683337/+merge/46532
<yonij> Hi...I would like to know if its possible to implement a dsm system to use with a multinode process/thread migration  system we r trying to develop........or would it b possible to port this module from another project ?.....pls sugggest....and if there is a better channel to ask this pls put that too....thnx
<ari-tczew> guess that #ubuntu-app-devel
<pitti> ari-tczew: well, I can't say that I'm particularly happy about such feature backports; we already have more SRUs than we should
<ari-tczew> pitti: so backport not SRU?
<pitti> that'd work for me; if someone really wants to push for it, so be it, but I don't think it's worth doing
<pitti> good night everyone!
<jdstrand> pitti: hi! I'm looking at NBS and see cups is still using libpoppler7. are you planning an upload for that? I can try a no change rebuild locally and upload if it builds if you'd prefer
<jdstrand> pitti: sorry for the poor timing :)
<pitti> jdstrand: I'll certainly do an upload soon, but if you want to get rid of it qucikly, please go ahead
<jdstrand> pitti: k, thanks (think I will-- I'm in a groove right now :)
<jdstrand> pitti: have a great night :)
<pitti> go, jdstrand, go!
<jdstrand> hehe
<pitti> jdstrand: if you have suggestions how to improve nbs.html, please let me know
<JamesPage> cjwatson: so does this point to a potential perl issue? happy to take some guidance on what is needed to help triage bug 708537
<ubottu> Launchpad bug 708537 in debconf (Ubuntu) "package mysql-server-5.1 5.1.41-3ubuntu12.9 failed to install/upgrade: segementation fault in debconf frontend" [Undecided,New] https://launchpad.net/bugs/708537
<jdstrand> pitti: I think the page is good, but am still getting used to it. as I go I might have more to say about it. the hardest part was trying to figure out what was on installation media. I've worked through that now
<JamesPage> james_w: thanks again
<james_w> np
<cjwatson> JamesPage: I'm not sure, I haven't really read the bug in detail, it probably needs a reliable reproduction technique
<JamesPage> cjwatson: OK; I'll go back to the reporter and see if it can be reproduced.
<cjwatson> pitti: FWIW, while I can't find the e-mail right now, Robbie e-mailed the foundations team a while back to say that somebody internal had asked for that w3m backport - possibly the Launchpad team?  I can't remember
<ari-tczew> cjwatson: that's possible since micahg has suggested to nonix4 about mail to TB about it
<SpamapS> jhunt_: still around?
<jhunt_> SpamapS: yup - can you give me 5 mins?
<SpamapS> jhunt_: I've literally got all day. :)
<ari-tczew> nonix4: as you can read above log, only full backport from natty is possible
<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:
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach back :)
<hallyn> mdeslaur: thanks mucho for pushing the kvm fix :)
<mdeslaur> hallyn: np
<shadeslayer> whats the package name for the csharp mono libraries?
<shadeslayer> currently get this http://paste.kde.org/3457/ with a package
<ari-tczew> cjwatson: I'm not sure whether Debian will upload lilo 23.1 to unstable before FeatureFreeze. I'd like to upload it from Debian git, then sync. What do you think?
<cjwatson> ari-tczew: would prefer to wait until after the Debian release - there's 2.5 weeks in there for them to do the upload
<ari-tczew> cjwatson: hmm. does Debian preparing toolchain 1-2 weeks like Ubuntu?
<cjwatson> ari-tczew: no
<Laney> unstable is going to be *fun* :)
<ari-tczew> Laney: why?
<cjwatson> ari-tczew: if nothing else, people have been uploading not-for-squeeze uploads to unstable for months anyway
<Laney> I imagine it will see a lot of activity
<ari-tczew> cjwatson: and they (people) should upload to experimental instead?
<cjwatson> not necessarily
<cjwatson> for leaf packages where it's unlikely RC fixes for squeeze are going to be needed, it's not unreasonable to upload to unstable
<cjwatson> I've done several of those myself
<ari-tczew> cjwatson: you're fired! :D
<jdstrand> Riddell: hi! I noticed that kword, krita and karbon (all koffice) were built against several NBS binaries. are you planning to do a koffice upload before alpha2?
<Riddell> jdstrand: wasn't planning to, what's NBS?
<jdstrand> Riddell: not built from source. they are pulling in extra stuff onto installation media
<jdstrand> s/stuff/libraries/
<kees> ari-tczew: yup, thanks.
<jdstrand> Riddell: I can attempt a no-change rebuild, but if there are problems with building locally I would file a bug on it
<Riddell> jdstrand: go for it
<jdstrand> ok
<kees> it's never good to ask yourself, "gee, what's eating one of my CPUs?" the answer is rarely what you want.
<jdstrand> hehe
<jdstrand> kees: your cat again?
<kees> jdstrand: hah, no, not sure the cause, but virt-manager was at 100% cpu, though totally responsive and otherwise "normal".
<jdstrand> neat
<jdstrand> Riddell: interesting:
<jdstrand> E: Build-Depends dependency for koffice cannot be satisfied because the package libdcmtk1-dev cannot be found
<jdstrand> Riddell: dcmtk is in universe, and afaics, has always been
<Riddell> jdstrand: oh yes, it's waiting on MIR process
 * jdstrand wonders how koffice ever built
<Riddell> it was only added recently, bug 702026 has some outstanding work to be done, I can do an upload with it removed for now
<ubottu> Launchpad bug 702026 in dcmtk (Ubuntu) "[MIR] dcmtk" [Undecided,In progress] https://launchpad.net/bugs/702026
<jdstrand> Riddell: that would be fantastic :)
<kees> pitti: hi! the security team needs to be coordinated with for kernel cadence publications when there is a CVE in the changelog.
<kees> pitti: what do you think the best way to give us lead time to produce a USN is?
<jdstrand> kees: fyi, he is eod
<kees> jdstrand: yeah
<janimo_> do patch system (in particular quilt) support per-arch patches, for example to have one ftbfs.armel only be applied if built on armel?
<ari-tczew> janimo_: rather debian/rules should handle it
<ari-tczew> but I dunno how to do that, sorry
<ari-tczew> I'm just guessing
<janimo_> ari-tczew, that can be done, but I was hoping for something simpler and more declarative
<cjwatson> not in 3.0 (quilt)
<cjwatson> with raw quilt you can of course generate the series file dynamically if you like, but it doesn't support it otherwise
<cjwatson> best to put the conditionals in the patch itself, generally
<micahg> janimo_: you can take a look at what fta did for Chromium WRT series patches: http://bazaar.launchpad.net/~chromium-team/chromium-browser/chromium-browser.head/view/head:/debian/enable-dist-patches.pl
<janimo_> cjwatson, micahg thanks, I'll guess I do it the ifdef way in the patch itself
<rsalveti> Riddell: what do you think about changing libqt4-opengl to gles on arm? did you see the patch?
<cody-somerville> Why is qemu-kvm-extras called qemu-kvm-extras? The stuff in qemu-kv-extras doesn't actually use kvm, right?
<fta> micahg, just added an example in my script..
<micahg> fta: cool
<fta> micahg, is it clear enough?
<micahg> fta: yes, looks fine
<mterry> doko_, was your intention with bug 684704 to get Riddell to decide to either file a MIR or drop the depends or was the intention to start a MIR itself?
<ubottu> Launchpad bug 684704 in qmf (Ubuntu Natty) "qmf MIR or qtmobility change needed" [High,Confirmed] https://launchpad.net/bugs/684704
<dobey> can i poke someone in ubuntu-backporters to look at bug 704590 please?
<ubottu> Launchpad bug 704590 in lucid-backports "Please backport couchdb 1.0.1-0ubuntu3 to Lucid" [Undecided,New] https://launchpad.net/bugs/704590
<micahg> ScottK: ^^
<kklimonda> dobey: you have decided not to push 1.0.1 through updates after all?
<ScottK> dobey: What rdepends does this affect?
<dobey> kklimonda: yeah, it's basically impossible to do right
<dobey> ScottK: python-couchdb and desktopcouch are the ones i'm directly aware of, and the same versions of those are on both lucid and maverick so shouldn't be a problem.
<ScottK> OK.
<kklimonda> dobey: what's the problem with installing couchdb 1.0.1 somewhere else, like in /usr/lib/desktopcouch/couchdb/? I know it was one of the options you were discussing and I'm cruious what's wrong with it.
<kklimonda> curious*
<dobey> kklimonda: because it's way too much work to do and support
<ScottK> Done
<micahg> kklimonda: https://lists.ubuntu.com/archives/ubuntu-devel/2010-November/032169.html
<apw> i assume compiz archive borkage is known ?
<dobey> ScottK: thanks!
<kklimonda> micahg: I do remember the discussion, but in my opinion that (creating a new package, and preparing upgrade paths) was still a better option from users' perspective. with -backports every affected user will have to install two packages by hand or risk enabling entire backports repository. Plus the discussion took place two months ago, so there was quite a lot of time to do testing.
<soren> I have a daemon I start from upstart using: exec su -c "blah blah" some_system_user
<soren> GDM shows some_system_user (as logged in, no less).
<soren> What am I doing wrong?
<seb128> soren, does that get a ck session?
<soren> seb128: ck-list-sessions doesn't list it.
<seb128> soren, is ck-history listing it?
<soren> ck-history fails :-/
<seb128> ck-history --frequent
<soren> http://paste.ubuntu.com/559230/
<soren> seb128: Yeah, that does show it.
<soren> At the very top, even :)
<seb128> soren, ok, so  seems a ck issue then
<seb128> that's what gdm is using to build its user list
<soren> http://paste.ubuntu.com/559231/
<seb128> well that and filtering on uid as well
 * soren glances at pam_ck_connector
<soren> seb128: Thanks for the hint. I looked at ck-list-sessions, and didn't see it, so I stopped looking at consolekit.
<soren> seb128: But yeah, I would have thought some uid filtering would have taken care of it, too.
<seb128> soren, you're welcome
<Riddell> mterry: I need to file a qmf MIR
<mterry> Riddell, ok, cool.  /me waits for it  :)
<seb128> soren, it's using login.defs to filter the ids iirc
<Riddell> rsalveti: patch looks fine to me, go ahead when you wish and are happy enough with the testing
<rsalveti> Riddell: ok, thanks!
<rsalveti> will have better results for tomorrow I think
<rsalveti> ping you back then
<soren> seb128: gdm, you mean? Or consolekit?
<chrisccoulson> does anyone have any clue about bug 703618? it's blocking me from testing another change to swt-gtk :(
<ubottu> Launchpad bug 703618 in tuxguitar (Ubuntu) "[natty] UnsatisfiedLinkError: no swt-pi-gtk-3555 or swt-pi-gtk" [Undecided,New] https://launchpad.net/bugs/703618
<seb128> soren, gdm was but seems we dropped our patch for that since upstream code was supposed to handle it now
<mterry> tremolux, out of curiousity, how does it pull in new ratings?  Whenever I do an apt-get update or is a separate thing?
<soren> seb128: Ah, it seems to bypass the uid check because it turns up in ck-history.
<tremolux> mterry: it gets ratings from the R&R server
<tremolux> hey kiwinote  \o
<kiwinote> heya tremolux
<kiwinote> rnr is looking sweet :)
<tremolux> kiwinote: fun times!  :)
<soren> seb128: Ah, found it.
<seb128> soren, oh?
<seb128> soren, ck bug?
<bigon> seb128: could you please sync telepathy-mission-control?
<seb128> bigon, ok, only this one or also glib and gabble?
<soren> seb128: Nope, gdm.
<soren> bug 708911
<ubottu> Launchpad bug 708911 in gdm (Ubuntu) "System users are shown in login screen if they've recently logged in" [Undecided,New] https://launchpad.net/bugs/708911
<seb128> soren, thanks
<soren> seb128: I
<soren> IÍll fix it.
<seb128> great!
<bigon> seb128: mm good question, not looked at the other updates (btw: http://people.collabora.co.uk/~cassidy/tp-versions.html)
<soren> seb128: Is there any particular numbering scheme for the patches in debian/patches in the gdm package that you want me to follow?
<seb128> soren, no
<soren> seb128: Figures. Now I can't reproduce my original problem. I've pushed a patch anyways. The issue I found is definitely accurate (minimal uid for non-system users was 500, debian policy says 1000).
<soren> seb128: I'll have to look at it again when/if it happens again.
 * soren calls it a day
<seb128> soren, ok, we had a patch from kees reading login.defs to get the number
<seb128> but we dropped it because upstream rewrote the code and said they handled that correctly now
<seb128> which seems to not be true
<soren> seb128: The patch I saw in the Lucid version just redefined the minimal uid, too.
<soren> seb128: Oh, well. I didn't upload anything, only pushed to the bzr branch.
<seb128> ok
<soren> Oh, I see Kees' patch  now.
<soren> I'll look at it again tomorrow. Now -> bedtime.
<seb128> 'night soren
<soren> 'night, seb :)
<hallyn> slangasek: were you still going to send an email to ubuntu-devel about moving qemu-kvm-extras to the arm tree?
<slangasek> hallyn: sent 2 minutes before you asked ;)
<persia> Just extras?  How about extras-static?  Will this affect regular KVM for i386/amd64/powerpc ?
 * persia goes to read email
<hallyn> slangasek: hah, awesome :)  i've been thinking for the last week that i should ask you :)
<persia> slangasek, Are you expecting changes to support for powerpc guests/chroots as a result (on non-powerpc hosts)?
 * persia isn't that fussed about degraded x86 guests on armel/powerpc hosts
<RAOF> Mmm. x86 emulation on armel.  I can think of nothing more delicious.
<RAOF> Perhaps x86 emulation on an emulated armel on x86!
<stgraber> would be fun ! doing an ls in what, 2 minutes ? ;)
<slangasek> persia: I haven't looked at the status of powerpc user emulation on either branch; if you find that it doesn't work, I'll gladly escalate and if that isn't satisfactory we can look at splitting powerpc out as well - but that makes the package transitions more complicated
<stgraber> arm chroots using qemu on x86 actually work quite well (for what I needed), running x86 using qemu on arm might be quite different though ;)
<slangasek> I know powerpc system emulation is DOA in Ubuntu because openhackware / openbios-ppc are FTBFS
<persia> Well, one can use the binaries from Debian, but yeah :)
<persia> But I'll test the static emulation for powerpc on amd64 when the new packages come out, and let you know.
<slangasek> persia: appreciate it!
<kirkland> slangasek: ping
<slangasek> kirkland: ohaipong
<kirkland> slangasek: re: qemu-linaro, will it build powerpc binaries too?
<slangasek> kirkland: yes - anything that's in qemu-kvm-extras* today
<kirkland> slangasek: my read of your email would be "yes"
<kirkland> slangasek: coolio
<persia> kirkland, Just to make sure there is alignment, the qemu-kvm package would still be providing kvm for powerpc-on-powerpc, right?
<kirkland> persia: no, i think it will be qemu
<persia> Why?
 * persia applied patches in maverick to support KVM, and doesn't understand why this would be removed
<persia> I may be mistaken, but my understanding was that there was a missing kernel bit that jk was planning to add for natty for powerpc.
<kirkland> persia: yes, that's in progress
<kirkland> persia: ibm is developing kvm patches against qemu base
<persia> Then I'm confused.  From which source should I expect to have binaries to do powerpc-on-powerpc?
<kirkland> persia: is qemu-kvm does this already, we can test and verify it, and that's fine -- that's what I would like
<persia> It did for maverick, except it couldn't boot because of a kernel option.  I'm not expecting to have time to work on that until end-Feb or March (I like powerpc, and want to do emulation, but it's always a low priority for me each cycle)
<kirkland> persia: from my current discussion with IBM, they've needed to add some other specific development, which they've done against qemu
<kirkland> persia: okay, i'll keep you posted as we learn more
<persia> kirkland, Cool, thanks.
<kirkland> persia: your preference would be to apply these changes against qemu-kvm, if possible?
<persia> I'm not sure.  I've been vaguely poking at kvm-on-powerpc since Karmic, but it's always low priority, so I haven't gotten so far.  I just don't want to end up with a separation of sources such that one works great for armel and another for i386/amd64, and having trouble finding a safe target :)
#ubuntu-devel 2011-01-28
<slangasek> persia: today the natural package split is to have powerpc-on-powerpc via qemu-linaro, but I'm obviously flexible
<persia> slangasek, I don't really care where to send patches, as long as the ones that were present in the past are retained.  I'm not sure all of them reached trunk.
<persia> (but, as noted above, I don't really spend lots of time on this)
<slangasek> ok
<persia> slangasek, Will qemu-linaro support KVM as well, or just qemu?
<slangasek> I don't know the answer to that
<persia> To me, it may make sense to have the qemu-based solutions from qemu-linaro, and kvm-based from qemu-kvm, but perhaps I'm reading too much into nomenclature :)
<broder> does anybody know of an example of how to build a bootable cd with grub2 instead of isolinux?
<RAOF> I think cjwatson did so (for a USB rather than CD, but should be fairly similar) at the rally?
<persia> I thought it was panda (Haitao Zhang) who was working on the multiboot grub2-based USB stick (not that others may not know, but that some folk may be busy)
<broder> oh look - there's a page in the grub maual about it. how helpful :)
<persia> There you go :)
<broder> although the file it refers to only shows up in my grub legacy package, so it's possible that it's out of date
<smoser> is there a way in a postinst to see if a debconf value has been set ?
<smoser> i'd like to do something if its not been seen, but something else if it has
<smoser> i'm interested in the difference between "user didn't choose anything" in a multiselect box, and "user hasn't seen the question" (due to priority)
<persia> smoser, Could you use the seen flag for that?
<smoser> and you get that with db_fget ?
<persia> Right.  debconf-devel(7) mentions it
<smoser> on my installed system, i saw exactly zero uses of 'db_fget'
<smoser> so i thought i must be doing something wrong
<smoser> i do see db_fset
<persia> I think seen is usually considered a target for FSET, rather than FGET :)
<YokoZar> If a package to be installed recommends a virtual package, and nothing providing that is currently installed, what happens?
<Guest25428> where is mark??
<YokoZar> Guest25428: at his island fortress I imagine
<Guest25428> hahaha ok
<Guest25428> he worksin this channel?
<mneptok> Guest25428: no. but smometimes he rides by in his carriage and throws shillings to the urchins.
<Guest25428> LOL
<micahg> YokoZar: nothing, it should be ignored
<YokoZar> micahg: so it doesn't pick a provider then, ok
<micahg> YokoZar: you said nothing provides it
<YokoZar> micahg: nothing providing it is installed
<pitti> Good morning
<YokoZar> micahg: but in principle uninstalled packages could provide it
<YokoZar> I'm wondering if there's any logic to choose between them, or if it defaults to nothing
<pitti> kees: saw your mail, will reply there
<YokoZar> pitti: mornin :)
<micahg> ah, hmm, well, idk then, my guess is pitti might know :)
<RAOF> YokoZar: I believe from experience that it will pick *something*; I'm not sure how it determines it.
 * YokoZar is dealing with some fallout of dummy/virtual packages
<broder> https://launchpad.net/ubuntu/lucid/+queue is the right url to look for unapproved sru uploads, right?
<broder> oh, never mind. lp finally decided to play ball
<pitti> broder: right, select "unapproved"; for some reason the default page (NEW) times out often
<broder> pitti: right, i knew that. i was just getting timeout errors so wasn't sure if i had the right page at all
<pitti> cjwatson: do you have some minutes for a d-i rebuild against kernel .38?
 * hunger wonders why his keyboard layout is currently getting broken during almost every upgrade in natty.
<dholbach> good morning
<janimo_> hello dholbach
<dholbach> hey janimo_
 * janimo_ needs to read up on patch-piloting as he's in the cockipt on Monday
<pitti> "learn to fly in 24 hours"?
<janimo_> can an archive admin let haskell-utf8-string binaries out of NEW, a few packages build dep on them. thanks
<cjwatson> pitti: yes, I'm going to deal with that this morning
<cjwatson> hunger: I have the fix for that in progress
<cjwatson> broder: grub-mkrescue (yes, the manual is currently wrong, I'm going to fix that in a bit ...)
<pitti> TheMuso, cjwatson: do you have an idea about bug 672699? did that ever actually work in the alternates? (that would surprise me)
<ubottu> Launchpad bug 672699 in debian-installer (Ubuntu Natty) "screen-reader does not work " [High,Confirmed] https://launchpad.net/bugs/672699
<cjwatson> pitti: there is a degree of support in d-i
<cjwatson> oh, wait, screen reader
<cjwatson> there's supposed to be speakup support I think
<cjwatson> whether it works in our build ...
 * cjwatson once again loses track of the logic of when bugs are release-targeted
<cjwatson> yeah, our kernel doesn't provide the speakup-modules udeb
<cjwatson> among the casualties of moving udeb handling to the kernel :-/
<pitti> ok, so that never actually worked then; sounds like we should un-target that then and drop priority?
<cjwatson> pitti: leave the priority where it is, I'll "close" the installer side of it by removing the boot option
<cjwatson> we certainly shouldn't advertise it when it doesn't work
<pitti> ah, good
<cjwatson> I've created a kernel task for the bits I need to make it work
<cjwatson> (and feel free to shove it from desktop->foundations in the release meeting agenda)
<cjwatson> it can be trade for the two apport bugs I just shoved in the other direction
<pitti> sounds fair :)
<cjwatson> mvo: could you look at bug 590998, please?
<ubottu> Launchpad bug 590998 in apt-xapian-index (Ubuntu Natty) "update-apt-xapian-index crashed with DatabaseLockError in __init__()" [High,Confirmed] https://launchpad.net/bugs/590998
<mvo> cjwatson: yes
<cjwatson> thanks
<Riddell> cjwatson: why would packages I put in blacklist in kubuntu.natty seed collection not end up in the blacklist germinate output for kubuntu.natty?
<cjwatson> don't use blacklist
<cjwatson> what are you trying to do?
<Riddell> cjwatson: avoid having geoip-database on the CD
<cjwatson> you can't as it stands, it's in standard
<cjwatson> the 'blacklist' file in seeds is horribly obsolete and we should probably remove it at some point (but it's not impossible that things don't properly check for its existence, so please don't just nuke it)
<Riddell> oh well, ok
<Riddell> I might get round to doing the kubuntu mobile seed split today
<cjwatson> the modern blacklisting facility is '!' seed entries (see germinate(1)), but it's a great big hammer whose primary effect is to make your CDs uninstallable if apt wants to pull that package in
<Riddell> seed collection split
<cjwatson> it's really only meant as an alarm bell
<cjwatson> geoip-database is pulled in because libgeoip1 Recommends it; it wouldn't necessarily hurt to investigate that ...
<mok0> I am developing a package that needs a (rather large) amount of scientific reference data. I am thinking of a solution, where this data is placed in bazaar on LP, but is it acceptable for a postinstall script to rely on bazaar? It would IMO be a pretty neat way to install the data.
<cjwatson> pitti: FYI I moved bug 681412 to your list on the release meeting agenda
<ubottu> Launchpad bug 681412 in at-spi (Ubuntu Natty) "Can not enter password for Administrative tasks using Onboard Keyboard" [High,Triaged] https://launchpad.net/bugs/681412
<ogra> fasten your seatbelts please
<ogra> @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: ogra
<cousteau`nbk> it's weird that bug 575610 hasn't been solved yet
<ubottu> Launchpad bug 575610 in epiphany-extensions-more (Ubuntu) "epiphany-extensions-more is not installable in lucid" [Undecided,Confirmed] https://launchpad.net/bugs/575610
<cousteau`nbk> (thanks, ubottu :) )
<cousteau`nbk> it's a version problem; it should be easily solved (just pick the maverick package and put it in lucid repos)
<geser> could someone please give back "gtk+2.0" on armel? it got hit by a LP bug
<cjwatson> we never "just pick the maverick package and put it in lucid"
<cjwatson> the fix needs to be backported
<cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates for how to deal with stable updates
<cousteau`nbk> cjwatson: the thing is, the package should have been in version 2.30 from the day Lucid was released
<cjwatson> geser: done
<cjwatson> cousteau`nbk: (bear in mind I know nothing about epiphany or its extensions, this is just general policy, we don't just copy packages from newer releases)
<cousteau`nbk> it's not that "there's a newer version", it's rather than the current one causes a dependency problem when trying to install
<cjwatson> understanding that will make it easier for you to have effective conversations with developers on fixing this kind of thing
<cjwatson> pitti: ^- can somebody on the desktop team look at bug 575610?
<ubottu> Launchpad bug 575610 in epiphany-extensions-more (Ubuntu) "epiphany-extensions-more is not installable in lucid" [Undecided,Confirmed] https://launchpad.net/bugs/575610
<cousteau`nbk> I mean, it would make sense to have this version on repositories if the epiphany-browser version was also 2.29, bit it's 2.30 and epiphany-extensions-more depends specifically on >=2.29 <<2.30
<cousteau`nbk> (maybe just removing that <<2.30 restriction makes it installable and it might work anyway)
<pitti> cjwatson: I'll put 575610 on our list, thanks
<cousteau`nbk> cool, thanks :)
<ogra> hallyn, around ?
<cjwatson> pitti: could you have another look at bug 638307 (which contains past discussion between you and Clint)?  The Debian maintainer wasn't particularly happy with the idea of removing it, and a number of users have popped up saying that they still need laptop-mode-tools, which makes me uncomfortable about just removing it as an archive admin action.  What should we do about this bug?  There are clearly some pm-utils bugs in ...
<ubottu> Launchpad bug 638307 in laptop-mode-tools (Ubuntu Natty) "Please remove/blacklist laptop-mode-tools. Conflict with pm-utils makes laptop-mode-tools package break suspend" [High,Triaged] https://launchpad.net/bugs/638307
<cjwatson> ... here somewhere ...
<cjwatson> pitti: I wonder if we should try to rearrange things to avoid the conflict with laptop-mode-tools instead ...
<pitti> cjwatson: it would require ripping out everything from l-m-t that pm-utils already does, and then of course you couldn't use the l-m-t configuration to configure pm-utils
<cjwatson> maybe that's the correct course of action, until such time as nobody needs it any more
<pitti> or changing pm-utils to disable hooks when l-m-t is installed
<cjwatson> I wonder if the new l-m-t Debian version changes this; it certainly moves the pm-utils hook around
<pitti> but that would mean a rather large delta to upstream, so I'd rather fix it in l-m-t
<cjwatson> (merge: bug 602881, as Bryce pointed out)
<ubottu> Launchpad bug 602881 in laptop-mode-tools (Ubuntu) "Please merge laptop-mode-tools 1.55 (universe) from debian (unstable)" [Wishlist,Incomplete] https://launchpad.net/bugs/602881
<pitti> cjwatson: it's not yet a problem in Debian as pm-utils 1.4 is only in experimental there
<cjwatson> pitti: right, but it presumably will be after squeeze releases
<pitti> right
<pitti> (the conflicts to lmt is in pm-utils experimental, too, FWIW)
<cjwatson> pitti: yeah, I noted that in the bug
<ogra> cnd, hey
<ogra> cnd, i was about to sponsor mtdev-1.1.0 but the packaging tree is missing the final commit (its still UNRELEASED in the changelog), could someone with commit access do the debcommit ?
<hallyn> ogra: what's up?
<ogra> hallyn, i commented on the merge request now
<hallyn> ogra: not sure which you mean, i'll see it in my inbox in a bit.  :)  sounds like I'll find some constructive criticism there, so thanks in advance :)
<ogra> hallyn, i was just looking at your multipath-tools merge request for natty
<ogra> but it seems you indicate in all bugs that the fixes are already there
<hallyn> ogra: yes, the changes are in natty.  lucid and maverick needs them badly
<ogra> and one of the bugs referred to is sadly private
<hallyn> I'm sorry abougt the private bug.  I wonder if I can make taht public
<hallyn> ogra: oh, sorry!  I see now
<hallyn> ogra: yes, that merge request should be cancelled, natty has the changes.
<hallyn> ogra:  i'm not sure what happened there
<ogra> thanks :)
<hallyn> ogra: so now I need the SRUs
<ogra> i was just confused
<hallyn> ogra: canceling that right now, thanks!
<pitti> ev: hm, I just got a report about someone trying to install from USB stick and failing in parted; turned out that he used a persistency file which just went full
<pitti> ev: do you really think that using this by default is a good option? perhaps we should default to not having a persistency file in usb-creator, at least not if the USB stick is < 4 GB?
<ogra> grmpf, the hal initscript is gone
 * ogra tries to find an old package/branch with it ... it had a beautiful chroot check in it i could need
<pitti> ogra: it's in bzr
<ogra> pitti, yep, looking at it now
<pitti> bz "I never forget a bit" r
<ogra> :)
<cjwatson> pitti: otherwise known as br
<ev> pitti: yeah, the current minimum is 128M which seems entirely too small
<pitti> ev: it's the second time in a few months that I got that, that's why I'm asking
<ev> I'm happy to increase it, but I'm just noticing that we're disabling the free space notification in at least KDE in casper
<ev> which I'll fix as well
<pitti> ev: cheers
<dholbach> seb128, thanks for getting somebody on the screen corruption bug :)
<dholbach> I was wondering if I should use a different irc client for the next few days already :)
<smoser> i'm asking again, now at a possibly more populated time...
<smoser> i'm interested in the difference between "user didn't choose anything" in a multiselect box, and "user hasn't seen the question" (due to priority).
<seb128> dholbach, yw!
<smoser> it looks like i could use db_fget, but i see no occurences of that in postinst scripts in my dpkg/info dir, so i supposed that htere has to be a different solution.
<smoser> my goal is to dynamically set the default value of the setting based on whether it appears to be being run on ec2.
<cjwatson> smoser: db_fget is in use in packages you almost certainly have installed, so I'm surprised.
<cjwatson> smoser: try .config scripts instead.
<cjwatson> smoser: the answer you got earlier was the right one
<smoser> huh... you're correct.
<smoser> i msust have typoed yesterday
<smoser> embarrising
<smoser> (typoed in my grep)
<cjwatson> however, I'm unconvinced of the validity of you asking this question in the first place :)
<cjwatson> are you deliberately trying to break preseeding?
<smoser> hm.. no. i'm absolutely not trying to break preseeding
<Riddell> pitti: what is it that makes a spec appear on http://people.canonical.com/~platform/workitems/natty/kubuntu-dev.html ?
<cjwatson> normally you should only be using fget to do migration of seen flags between questions and other such somewhat esoteric stuff.  in normal use you should normally only need to look at the value of the question and trust it
<pitti> Riddell: a spec must be targetted at natty, and must have work items from anyone in ~kubuntu-dev
<cjwatson> i.e. the default value of the question should be appropriate
<smoser> more i was trying to set the value correctly when user didn't see the question due to low priority
<cjwatson> that's what the Default is for
<cjwatson> in .templates
<smoser> i was thikning with pre-seeding it woudl be set to "seen"
<smoser> right, but a static default isn't really suitable for me.
<cjwatson> normally yes, but preseeders often set the priority to critical as well so that they don't have to bother with non-vital questions
<smoser> if you apt-get intsall cloud-init on your desktop
<smoser> then rigth now, it does some stupidly long (but mostly necessary) timeouts on boot (lets not get into that)
<smoser> so, i want to, by default configure it to not wait on the EC2 metadata service.
<cjwatson> can you detect a suitable default at preconfiguration time, before your package is unpacked?
<smoser> but on upgrade of someone *in* ec2, i need to turn that on ... or, possibly on first install in ec2 , but that is less necessary.
<cjwatson> if you can detect this at preconfiguration time, then the right thing to do is usually something like this:
<smoser> well, with 'essential' packages only, setting default in 'config' woudl be difficult.
<cjwatson>   db_fget question/name seen
<cjwatson>   if [ "$RET" = false ]; then
<cjwatson>     db_set question/name $appropriate_default
<cjwatson>   fi
<cjwatson>   db_input $priority question/name
<cjwatson> but if you absolutely must do it in the postinst then checking the seen flag is probably mostly ok
<smoser> so config would be preferred, thats fine.  the only reason to not chose config was that "It should only use commands that are in essential packages"
<cjwatson> right (plus debconf)
<smoser> what i'm needing or wanting to do is look for the metadata wervice (an http interface). but i can probably come up with *something* there.
<smoser> thank you cjwatson
<RoAkSoAx> howdy!! anyone ideas of what am I doing wrong with the packaging that when I'm purging a package it shows: "dpkg: warning: while removing powernap-common, directory '/usr/lib/python2.6/dist-packages/powernap' not empty so not removed." (I'm using python-central)
<pitti> apw: btw, the kernel is NEWed; is it supposed to be used for a2? If so, who can I ask about uploading -meta?
<cjwatson> pitti: it had better be, the installer's using it now :)
<pitti> ah, good :)
<apw> pitti, thanks for that, i have an update to it (same abi number) which is going in shortly; to fix arm boot issues
<apw> pitti, now thats repaired i will be uploading it
<apw> cjwatson, ahh you got ahead of me, the arm issues had me stalled for a bit
<apw> thanks both
<apw> pitti, ok both done
<ogra> @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:
<benste> someone familar with PAM + smartcards ? - I want to try login with an existing smarcard which is not writeable for system login - but can't find the right irc ? #pam@freenode does have no one in there
 * dholbach hugs ogra
<ogra> dholbach, fridays are bad for me, i owe the community 30min :)  (calls and meetings until EOD now)
<dholbach> ogra, feel free to move your slot somewhere else or swap with somebody
<ogra> but i made at least 3.5h
<AbsintheSyringe> uploading my first ppa, if I set it under natty will it work under lucid lets say, and vice versa. tnx
<AbsintheSyringe> or like in debian, I'm just targeting which series I want it to see it in
<geser> AbsintheSyringe: depends on the package (dependencies and such)
<ScottK> pitti: Our latest sip upload drops some old transitional packages.  Calibre still uses the old sip4 in build-depends.  It should be python-sip-dev.  This will apply to Debian as well (the same changes in in New in Debian).  Do you want to fix it in Debian and sync or can I just upload the fix direct to Natty?
<pitti> ScottK: I already got a Debian bug report for it; I'll upload a fix RSN
<ScottK> pitti: OK.  I'll leave it between you and the NBS list.
<pitti> ScottK: if you want to fix it now, please go ahead of course
<ScottK> Oh.  OK.
<pitti> but NBS should save me by then
<ScottK> Will do.
<pitti> s/by/until/
<ScottK> It's easy enough just to knock them al lout.
<ScottK> pitti: Upon futher consideration, I'll leave it to you.  It's got a hard coded depends on python2.6 that's got to change and the binary that needs SIP should depend on ${sip:Depends}.
<microm> I don't want to create a duplicate so how do I find out the state of this significant bug in the SRU process for ubuntu 10. The bug is https://bugs.launchpad.net/inkscape/+bug/672686/comments/12
<ubottu> Ubuntu bug 672686 in cairo (Ubuntu) "Some diagrams results in "Illegal character" in the generated pdf" [Undecided,Fix released]
<smoser> cjwatson, would you mind reading http://pastebin.com/xYWHTAe7 and telling me if it looks insane
<ScottK> microm: Looks like no one has done step 2 of the SRU process.
<debfx> Riddell: that's too bad :(
<microm> ScottK: regarding step 2, is this something an end user like me must do?
<ScottK> microm: Anyone can do it.  Usually it's someone who is very interested in getting the fix to the earlier release.
<microm> ScottK: is it bug 672686 that needs to be updated or some other bug in another bug database?
<ubottu> Launchpad bug 672686 in cairo (Ubuntu) "Some diagrams results in "Illegal character" in the generated pdf" [Undecided,Fix released] https://launchpad.net/bugs/672686
<ScottK> microm: Same bug.
<microm> ScottK: in 2.2 where the process says "... in the development branch..." is it related to this page -> https://launchpad.net/ubuntu/+source/cairo/1.10.2-1ubuntu1
<ScottK> If that's the version that fixed the problem.
<ScottK> Gotta run.
<smoser> soren, around ?
<microm> seb128: are you planning on dong anything to help bring the cairo bug fix mentioned above to ubuntu 10 (maverick), and is there anything someone like me who does not know your process can do to help?
<jhunt_> SpamapS: hi - I'm having trouble building your modded upstart for lucid for lp:#672177. Could I fling you the new initscripts pkg to see if you have better luck with testing this fix on lucid. I've tested it on maverick ok.
<broder> cjwatson: do you know how to build a cd image that boots grub? do i just pass -b cdboot.img to mkisofs and make sure there's a /boot/grub/ on the image?
<broder> actually, that doesn't seem right, but i'm not sure what i'm supposed to do
<SpamapS> jhunt_: sure
<cjwatson> smoser: looks like that "first time" code will run every time the package is upgraded.  I think the *\ Ec2,* case needs to be a bit more careful to actually match what the "first time" code sets it to
<SpamapS> jhunt_: whats the trouble on lucid? IIRC, the upstart package is already in lucid-proposed
<broder> cjwatson: oh, heh, just saw your grub-devel mail :)
<cjwatson> broder: yes, grub-mkrescue
<jhunt_> SpamapS: user error no doubt - pbuilder is failing to resolve the libnih versions required.
<cjwatson> you can also do it by hand by sort of unpacking what grub-mkrescue does, but that's more work and I haven't documented it (yet)
<smoser> cjwatson, why would it run every time the package is upgraded? on upgrade the 'seen' will get wiped ?
<broder> cjwatson: grub-mkrescue sounds fine for my usecase
<broder> thanks
<cjwatson> the thing you would need to pass to -b would be a concatenation of cdboot.img and an appropriately generated core.img, and you also need to think about the prefix and how grub.cfg should work
<cjwatson> smoser: why would 'seen' be wiped on upgrade?
<smoser> i wouldn't hvae thought it would
<smoser> but you said the "first time code" will run every time the package is upgraded
<cjwatson> smoser: I think you're missing my point - since it's a low-priority question, it will never be shown for most people
<cjwatson> which means the seen flag will never be set
<cjwatson> you probably shouldn't set it yourself - instead you need to arrange that that code is a no-op after it's been run once
<cjwatson> anyway, got to go
<smoser> fooey.
<smoser> ok. have a nice weekend.
<cjwatson> ta
<SpamapS> jhunt_: any movement on getting sysvinit's package import fixed btw?
<jhunt_> no sign yet (bug 708655 raised on udd).
<ubottu> Launchpad bug 708655 in Ubuntu Distributed Development "sysvinit package import failing" [Undecided,New] https://launchpad.net/bugs/708655
<SpamapS> james_w: ^^
<SpamapS> james_w: pretty please. :)
<SpamapS> jhunt_: got your email. This is intended for natty, yes?
<jhunt_> SpamapS: that was lucid
<SpamapS> jhunt_: ahh ok. There's no .diff
<jhunt_> SpamapS: sorry - on its way....
<SpamapS> jhunt_: ok, tests commencing
<jhunt_> SpamapS: gr8
<SpamapS> jhunt_: btw, the version should eventualy be ubuntu17.1 not ubuntu18
<jhunt_> SpamapS: in which case, I made that mistake 3 times I think :)
<SpamapS> jhunt_: for natty its incremented as such.. but for SRU's the . notation ensures that the next version will supercede it on upgrade
<SpamapS> supersede? supercede? Hrm.. irssi.. why don't you have spellcheck?
<shadeslayer> hi, im working on project neon and have a small issue with mono
<shadeslayer> one of my packages is searching for usr/lib/mono/qyoto/qt-dotnet.dll
<shadeslayer> but i have it installed in /opt/project-neon/usr/lib/mono/qyoto/qt-dotnet.dll
<shadeslayer> any ideas on how to export the proper vars on this would be helpful :)
<shadeslayer> [ preferably CMake vars ]
<ari-tczew> bryceh: ping
<SpamapS> jhunt_: so, I have a pristine lucid now with upstart and eglibc upgraded.. and still fails to remount /... now trying your version of sysvinit
<SpamapS> jhunt_: still get the 'mount / is busy' message, but I think thats just the first of the remounts failing.. there is no fsck.
<kees> seb128: what is going on with bug 708911?
<ubottu> Launchpad bug 708911 in gdm (Ubuntu) "GDM considers only users with uid < 500 system users" [Low,Confirmed] https://launchpad.net/bugs/708911
<kees> soren: you too
<SpamapS> hrm
<SpamapS> jhunt_: still issues.. but it seems to be sshd's fault
<SpamapS> sshd is not being stopped...
<SpamapS> which is probably bug 603363
<ubottu> Launchpad bug 603363 in openssh (Ubuntu Lucid) "sshd never stops, prevents umount of /usr partition" [High,Confirmed] https://launchpad.net/bugs/603363
<SpamapS> which.. I was supposed to fix for lucid.. whoops.. never did push up that branch :P
<SpamapS> but.. here's a question.. shouldn't sshd be restarted whenever libc6 is upgraded?
<SpamapS> DOH .. invoke-rc.d runs the init.d script!
 * kirkland wonders if he can upgrade his desktop without loosing a half day of productivity ...
<iulian> There is only one way to find out, kirkland.
<kirkland> iulian: indeed, i have taken the plunge
<iulian> Heh. :)
<seb128> kees, what do you mean about the bug?
<seb128> kees, you made a fix for the uid thing which got dropped since because refactored their code which was supposed to do the job
<seb128> kees, seems it doesn't, soren suggested a fix which bring back the bug from before you fix though
<SpamapS> cjwatson: I would love to get your thoughts on this bug I just filed: bug #709468
<ubottu> Launchpad bug 709468 in openssh (Ubuntu) "sshd is not restarted properly on libc6 upgrades" [Undecided,New] https://launchpad.net/bugs/709468
<barry> SpamapS: i think cjwatson is eow
<SpamapS> right.. I would hope so.. :)
<soren> smoser: Yes.
<smoser> soren, i got what i was after, thanks for responding though
<soren> kees: What's the motivation for the login.defs parsing anyways? Debian Policy seems quite clear?
<sebner> kirkland: natty?
<soren> smoser: Cool beans.
<kirkland> sebner: yes
<sebner> kirkland: works here, haven't rebooted into the new 38er kernel yet though :D
<kirkland> sebner: yeah, upgrade succeeded, haven't rebooted
<sebner> kirkland: not rebooting .. the best you can do :D
<kirkland> sebner: that's the question ;  can i reboot and do anything but fight X and compiz and desktop issues for the rest of the day :-)
<sebner> kirkland: just hibernate .. the weekend is near ^^
<hallyn> kirkland: i've been afraid to upgrade all week.  i'm going to try it this weekend i think :)
<kees> soren: "policy"? it's a configurable. gdm should respect it.
<kees> seb128: I did rework the patch once already. it seems pitti just dropped it though?
<seb128> kees, right
<seb128> "  * Drop 24_system_uid.patch; upstream handles this more dynamically now, and
<seb128>     we really want to show users with an ID of < 1000 (but >= 500)."
<soren> kees: DEbian Policy defines uid classes.
<kees> soren: login.defs is where the system vs user uid stuff is defined
<seb128> is the changelog entry, so maybe check with pitti next week why he dropped it
<kees> what's weird is that I'm running 2.32.0-0ubuntu5, and my uid still showed up.
<seb128> kees, not sure why he dropped it, I was just pointing that soren's patch will put us back in the previous bug situation
<kees> soren: what change did you make?
<seb128> kees, which might be ok but is not ideal
<seb128> kees, the vcs is on the bug
<kees> I want to still log in :)
 * kees looks
<soren> kees: I changed the minimal uid from 500 to 1000.
<kees> soren: oh! yeah, no. I need to log in :)
<soren> kees: Why is your uid < 1000?
<maco> soren: because he <3 red hat?
<soren> maco: I
<soren> I've always suspected.
<kees> soren: because I switched to Debian from RedHat in 2002, and I have a home directory/NFS server.
<kees> there's no reason to change my uid; that's just silly
<kees> gdm should respect the configured uids, since they are configurable. login.defs is that configuration.
<soren> kees: Hey, talk to Debian Policy. :)
<soren> I didn't write it.
<kees> soren: no; that's what defines the defaults in login.defs.
<soren> I just changed the defaults to match what ought to be the defaults.
<kees> soren: all the tools that implement user vs systme uids read login.defs
<soren> Except GDM.
<kees> exactly. gdm is wrong.
<soren> Which had a wrong default. I'm not aguing against reinstating your login.defs parsing.
<seb128> well if you read the upstream bug on the bug kees fixed the gdm agreed it's a bug
<kees> the login.defs patch needs to be restored.
<kees> right
<soren> I'm just saying that if it needs to have a default I really do think that default should obey DEbian (and Ubuntu) Policy.
<soren> It's really not very ambiguous. <1000 is system users.
<soren> We just happen to be lucky enough that very few people have more than 401 system users.
<soren> (0-100 being globallly assigned)
<maco> 401?
<kees> soren: your change will break my systems. it was blind luck that pitti's dropping of my patch didn't break my systems.
<maco> oh
<soren> kees: You can still log in. You just don't show up in the gdm face browser.
<soren> Right?
<kees> soren: your change will regress an actual bug. please revert it.
<soren> I'm not going to revert it. I might add your login.defs parsing, though. That way, the default is what is in debian policy, but if locally overridden, that will take precedence.
<soren> You may disagree with Debian Policy. That's fine. So do I on various points. Nevertheless, it says what it says.
<seb128> soren, not sure what is best, not showing some users or showing some that don't need to be there
<soren> I'm not going to complain if *you* revert it though.
<kees> so, patching the upstream source to fix a theoretical bug should not trump leaving it as-is to not regress a real bug. but yeah, the correct fix is the login.defs parsing. adding that is the best of all three options.
<seb128> ideally the parsing logic would come back
<seb128> until then we should default to list extra users rather than drop some off the login
<soren> screw it. This is silly. I've reverted my change.
 * SpamapS wouldn't mind seeing what ftp and uucp's faces look like after all these years sharing systems with them...
<soren> Maybe some other day I'll learn to understand what purpose those uid classes serve in debian policy if it's not to describe what we should use as defaults for exactly this sort of stuff.
<soren> bzr lacks a --introduces lp:123456  option.
<seb128> soren, well the policy works for new installs
<seb128> it doesn't mean there is not old install around or nfs configs why don't conform to it
<janimo_> doko, what do pyconfig.h files provided by python 2.6 and 2.7 reflect? Should they be as different as they are now?
<janimo_> doko, in particular the 2.7 one defines   _POSIX_C_SOURCE while 2.6 does not. This causes an autoconf warning and python2.7 is not detected by LibO conmfigure script
<janimo_> doko, mailed you
<sebner> cyphermox: I just noticed that you are the new master of the network-manger :) Mind taking a look at buh #708118 ? Quite annoying for me
<sebner> bug #708118
<ubottu> Launchpad bug 708118 in network-manager-applet (Ubuntu) "nm-applet crashes sporadically" [Undecided,New] https://launchpad.net/bugs/708118
<cyphermox> sebner, hey ;)
<cyphermox> sure, I saw it already it's the current top of stack :)
<kees> soren: I'm not sure why pitti dropped that patch. I ported it in about 5 minutes. I'll push something to the repo in a few minutes and we can both be happy :)
<soren> kees: Happy sounds good. I could use a bit of that right now.
 * kees hugs soren
<soren> kees: :)
<jdstrand> soren: dude!
<jdstrand> soren: how are you?
<soren> jdstrand: Tired :)
<soren> jdstrand: Three months release cycles means twice as many release weeks a year.
<jdstrand> jdstrand: heh, sorry man :)
<jdstrand> soren: funny, waiting for your response, I came across something I wanted to ask you about. axis2c has you listed as the maintainer
<jdstrand> soren: are you interested in fixing FTBFS for it?
<soren> jdstrand: HAHAHAHAHHA!
<soren> jdstrand: Sorry. I mean: No, not really.
<jdstrand> soren: I'm going to jot that down as a tentative 'yes'
<jdstrand> soren: thanks! :P
<soren> jdstrand: Of course you are :)
<jdstrand> soren: seriously, no worries. I'll poke someone else
<geser> jdstrand: are you perhaps interested in reviewing/sponsoring https://code.launchpad.net/~geser/ubuntu/natty/subversion/merge_1.6.12dfsg-4/+merge/47822 (it merges two CVE fixes from Debian)
<jdstrand> geser: I'm going to point you to mdeslaur. he is eod but working on subversion already
<jdstrand> geser: I don't know if he has looked at natty yet or not
<mdeslaur> nope, I haven't
<jdstrand> oh, hi mdeslaur :)
<mdeslaur> hello :)
<mdeslaur> waiting for pizza to arrive :)
<jdstrand> hehe
<jdstrand> sounds good
<jdstrand> my long lunch did not actually include eating...
<jdstrand> but I am actually >< close to eow myself...
<mdeslaur> geser: I don't have time right now, but I'll gladly look it over when I have a minute this weekend or monday morning
<geser> mdeslaur: thanks
<ari-tczew> mdeslaur: kebab rulez :P
<mdeslaur> ari-tczew: hehe, indeed, but not tonight :)
<ari-tczew> mdeslaur: then eating on night is not healthy ;-)
<ari-tczew> geser: didn't you open bug for subversion merge?
#ubuntu-devel 2011-01-29
<evfool> hi all
<evfool> does anyone know if its possible to have "message count" numbers in an application indicator (like in the messaging menu)
<ari-tczew> ogra: ping
<geser> ari-tczew: re subversion merge: why should I open a bug for a bzr-based merge?
<ari-tczew> geser: not my business, I didn't wrote that you should. Only asked out of curiosity.
<ari-tczew> geser: but commenting on MoM is welcome since I wanted to take this merge and I noticed your bzr link here yesterday.
<ari-tczew> I commented it on MoM.
<geser> ari-tczew: ok, will remember it for the next time. I used to file bugs for bzr-based merges but that was before the sponsoring overview listed them.
<ari-tczew> ok thanks
<ogra> ari-tczew, yep
<ari-tczew> ogra: PM possible?
<ogra> sure
<Quintasan|Droid> Oh snap, segfaults on X after upgrade, this was expected?
<ari-tczew> cjwatson: could you paste link to packageset page?
<ScottL> jdong, hi, you may not remember but we spoke about six months ago about ubuntu studio starting a backporting program for audio applications
<ScottL> jdong,  you had suggested that we use our own backporting ppa for testing and hosting of applications for users to upgrade
<ScottL> jdong, persia has strongly suggested that we further this working into getting the backports officially pushed into the repos
<ScottL> jdong, to this end we plan to still have a testing ppa but fill out a bug report and have two testers confirm that it works
<ScottL> jdong, hopefully this will allow the applications to be backported into the official repos with minimal effort from the official backports team
<alexbligh> if debuild runs with a normal Makefile, and does "make install", does it run with fakeroot and in a chroot environment? I am getting "mkdir -p /tftpboot
<alexbligh> mkdir: cannot create directory `/tftpboot': Permission denied
<alexbligh> "
<jef91> Anyone know their way around the ubiquity slide show installer at all?
<kklimonda> any idea why would I hit "E: Package 'libcurl4-dev' has no installation candidate" on buildds ?
<kklimonda> and then
<kklimonda> libcurl4-dev is a virtual package provided by:
<kklimonda> Using  (no default, using first one)
<geser> kklimonda: isn't libcurl4-dev a pure virtual package? I'm not sure how well LP buildds cope with pure virtual packages
<kklimonda> geser: well, they coped just fine till now :)
<geser> kklimonda: I guess it's about transimission: as you already build-depend on libssl-dev (so I assume it's ok to link with openssl) build-depend on libcurl4-openssl-dev instead (or add it as an alternative)
<kklimonda> geser: unless something in curl packaging has changed recently it should work, and I don't see any obvious changes
<geser> hmm
<geser> kklimonda: perhaps #launchpad knows an answer (during the week). Perhaps there was a change to the buildds.
<kklimonda> geser: I'll ask, it's not very urgent
<ari-tczew> I'm receiving informations from Polish LoCo that upgrading to natty shows a lot of broken dependencies.
<geser> which packages? have they something in common?
<ari-tczew> geser: I asked for examples, still waiting for more info.
#ubuntu-devel 2011-01-30
<tim> hi, is there an easy way to install a cross compiler on ubuntu? i want to test some altivec code on an x86-64 machine ...
<RAOF> @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: RAOF
<lifeless> oooh shiny
<RAOF> lifeless: Got a patch to push in? :)
<lifeless> just admiring the bottiness
<RAOF> Ooof.  bzr's fetching estimation algorithm has extremely poor behaivour on lp:ubuntu/gtk-sharp2
<RAOF> Constantly estimating (n-small) / n â (n
<RAOF> Constantly estimating (n-small) / n â (n+a bit - small) / n + a bit
#ubuntu-devel 2012-01-23
<hallyn> mdeslaur: but development release is not available there.  ok to complicate that logic with a special case?
<hallyn> slangasek: originally he thought it was a race condition, but he has deeper issues
<pitti> Good morning
<pitti> slangasek: I don't know about urfkill, I'm afraid; but I'm surprised that we need it, I thought network-manager would already handle these
<pitti> slangasek: but I guess it can be changed to be inert when n-m is running, similar to e. g. the powerbutton script of acpi-support?
<slangasek> pitti: eh, network-manager is entirely the wrong layer to handle these keys
<slangasek> because they are intended to control all antennas, not just wifi
<slangasek> n-m is not what handles the thinkpad antenna key at all, for instance; acpi-support does that currently
<pitti> slangasek: ah, I see; so that's generally the Fn+Something soft switch?
<slangasek> yep
<pitti> I certainly remember quite a lot of bug reports which say that the key is not working on a particular model
<pitti> usually in udev bugs which send the wrong key code, but even when fixing it it doesn't seem to work sometimes
<pitti> so maybe urfkill will work better with those than acpi-support
<slangasek> yes, because acpi-support only handles acpi events, not keys
<pitti> that would certainly explain it
<pitti> could we move the config files to /lib/ or /usr/share somewhere?
<slangasek> if you wish? :)
<pitti> slangasek: as you were concerned that they aren't really conffiles
<slangasek> I was mostly concerned about it being a possible sign that the code wasn't mature enough to DTRT
<slangasek> but then I found the per-vendor files which showed that to not be an issue
<slangasek> so I'm not worried about moving them, but I think it would be legitimate to do so
<pitti> installed the package now; the two per-vendor conffiles look rather harmless
<TheMuso> doko_: Ok I just confirmed that java-atk-wrapper can be used as a drop-in replacement for java-access-bridge. I have a local copy of the openjdk-6 packaging branch with the needed changes, shall I push and upload, or would you like to have a look first? (Note I have also merged your most recent upload).
<pitti> TheMuso: we also need it for openjdk-7, right?
<rickspencer3> hey all ... daily images today looking good:
<rickspencer3> https://jenkins.qa.ubuntu.com/view/Precise%20ISO%20Testing%20Dashboard/view/Daily/?
 * SpamapS looks on in awe of the awe-tomation awesomeness
<pitti> libo i386 built yesterday, so today's images should be a little less oversized, too
<dholbach> good morning
<pitti> hey dholbach
<nigelb> Hey dholbach, pitti :)
<dholbach> hey pitti
<pitti> nigelb: good morning
<dholbach> hey nigelb :)
<TheMuso> pitti: Oh yeah, we do.
<TheMuso> pitti: Although that is in universe.
<pitti> TheMuso: ah, I wasn't sure whether we'll use that by default in precise eventually
<pitti> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<pitti> argh, 72 items? seems we never quite get down to a sane number..
<seb128> pitti, that's 3 weeks of no piloting and a rally for you ;-)
<seb128> pitti, there was no piloting scheduled between mid-decembre and the rally
<bkerensa> pitti: I found out what was causing the conflicts in my requested merge for snort can I just re-request? Please :)
 * bkerensa also forwarded upstream
<pitti> bkerensa: as you prefer, but updateing the debdiff on the bug might be easier
<cjwatson> pitti: I was curious over the weekend if there was a particular reason there aren't python3-problem-report and python3-apport packages yet, despite the apport tests passing with Python 3
<pitti> cjwatson: I actually fixed quite a lot of the apport.* modules, but problem_report is particularly broken with python 3 stil
<cjwatson> ah
<cjwatson> the tests didn't seem to show that?
<cjwatson> maybe I missed something
<pitti> I need to make up my mind what makes more sense to store in Report objects: always byte arrays (more flexible, but doens't work well with real strings), always utf8 (need to be more careful with logs, etc.), or mix (too confusing)
<pitti> python3 problem_report.py -v
<cjwatson> (hmm, also https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-python-versions seems to say that apport's in update-manager's dependency chain but I don't see it there)
<pitti> fails all over the place
<cjwatson> ah, ye
<cjwatson> s
<pitti> you can run the whole suite with PYTHON=python3 test/run, FYI
<cjwatson> I thought I did, must have missed that
<pitti> cjwatson: I think I can make the whole thing work for python 3, but I didn't put urgency into this as we are missing python3-launchpadlib
<cjwatson> oh, I just ran python3 test/python, that was why
<cjwatson> pitti: yeah, barry and I are working on that
<pitti> I think I fixed pretty much all the imports etc., the remaining bits are all str vs. bytearray problems
<l3on> pitti, agda needs a rebuild too
<l3on> :)
<l3on> Package: agda-mode
<l3on> Version: 2.2.10-4build1
<l3on> Missing: libghc-agda-dev (< 2.2.10-4build1.1~)
<\sh> could it be that something broke libreoffice? eventually the last openjdk upload?
<l3on> after rebuild libghc-agda-dev (<< 2.3.0-1build2.1~)
<pitti> hey l3on
<pitti> l3on: ah, can do
<l3on> thanks :)
<pitti> l3on: for https://code.launchpad.net/~l3on/ubuntu/precise/anjuta-extras/fix-unmetdep/+merge/89639, did you check that anjuta-extras actually works with anjuta 3.3?
<pitti> l3on: agda uploaded
<bkerensa> pitti: Hopefully my merge request is much more satisfactory this time
<pitti> bkerensa: not on the sponsoring page yet, could you please toss me the URL?
<bkerensa> pitti: https://code.launchpad.net/~bkerensa/ubuntu/precise/snort/fix-for-889721/+merge/89643
<pitti> bkerensa: ah, thanks
<pitti> bkerensa: FYI, fixing the changelog syntax
<pitti> it's (LP: #889721)
<bkerensa> oh ok
<bkerensa> pitti: I pushed a fix for changelog syntax
<pitti> bkerensa: nevermind, did that while merging
<bkerensa> oh
<bkerensa> pitti: Thanks for the merge gnight!
<Laibsch> bdrung: thank you for letting me know about distro-info.  Hehe.  And Stefano and you are even the maintainer.  What a coincidence.  Let's hope packages like ubuntu-dev-tools and especially pbuilder as well as others are patched in time for precise to rely on that info instead of hard-coding it.
<pitti> l3on: did you see my anjuta-extras question?
<Laibsch> looks like ubuntu-dev-tools already depends on distro-info.  Very well indeed.
<l3on> pitti, yep :)
<l3on> just a moment ... i need my precise and I don't find ti
<Laibsch> pbuilder doesn't
<l3on> pitti, in the while.. can you take a look at ruby-sinatra ?
<pitti> l3on: yep, getting to this
<l3on> pitti, ok, anjuta-extras does not work... but, in the homepage there is a mistake...
<l3on> we have anjuta 3.3.4, that's the unstable version, and for -extras there's a unstable version too
<pitti> yeah, I noticed -- there is no corresponding extras upstream version
<l3on> but in the anjuta homepage does not appera
<l3on> http://ftp.acc.umu.se/pub/GNOME/sources/anjuta-extras/3.3/
<pitti> oh, there is? nice
<pitti> this should be packaged then
<l3on> ok, I'm working on it
<pitti> cheers
<l3on> :)
<pitti> l3on: the sinatra branches are both uploaded
<l3on> thanks again :)
 * pitti goes to the other MPs
<doko> TheMuso, thanks! see message
<gammax> Hello all, Is there anyone that may be able to help create a notification icon? It is very basic.
<cjwatson> barry: FYI it looks like you need to write an MIR for python3-chardet
<cjwatson> (it's a separate source, so more effort than usual)
<diwic> no queue on launchpad today \o/
<jibel> pitti, yesterday the retracer behaved oddly and marked crashes in software-center in Precise as duplicates of an old bug (bug 440889)
<ubottu> Launchpad bug 440889 in python2.7 (Ubuntu Precise) "software-center crashed with ImportError in /usr/lib/python2.7/bsddb/__init__.py: No module named _bsddb" [Critical,Fix released] https://launchpad.net/bugs/440889
<jibel> pitti, the only common error is they are both an ImportError in software-center
<jibel> see the original description because the main description has been updated to match the new error.
<pitti> jibel: indeed, so it seems this bug has regressed
<pitti> but it seems recent comments indicate that it is fixed again now?
<jibel> pitti, no, the original error was an import in webkit but the recent error was with bsddb in python2.7
<jibel> pitti, the point is that trhe 2 bugs are different but the retracer marked them as dupes.
<pitti> /usr/share/software-center/software-center:ImportError:<module>:<module>:<module>:<module>:<module>:<module>|440889||2009-10-02 20:40:05
<pitti> ah, that's indeed not very helpful
<pitti> jibel: filed as bug 920403, thanks for pointing out!
<ubottu> Launchpad bug 920403 in apport (Ubuntu) "different python crashes misidentified as duplicates" [High,In progress] https://launchpad.net/bugs/920403
<glatzor> barry, hello. I just wanted to inform you that I ported aptdaemon to gobject introspection.
<l3on> pitti, if you're still free, anjuta extras - merge proposed uploaded :)
<l3on> https://code.launchpad.net/~l3on/ubuntu/precise/anjuta-extras/new-version-3.3.4/+merge/89672
<pitti> l3on: nice, thanks! will do ASAP
<l3on> ok, thanks.
<pitti> l3on: ah, so you closed the other MP?
<l3on> pitti, yes, I don't know how uncommit that branch...
<pitti> that's fine; you can just delete it, or leave it to bitrot
<l3on> so I choose to remove that and create a new one
<mdeslaur> hallyn: yeah, I just need to think of a way to automatically determine which release is a dev release...let me ponder it a while
<Daviey> mdeslaur: the launchpad api tells you that.
<mdeslaur> Daviey: yeah, that'll have to wait until I rewrite the whole thing in python though :P
<Daviey> mdeslaur: perhaps asking someone closer to the API, but i imagine something based on, https://api.launchpad.net/1.0/ubuntu/current_series/ might help ?
<mdeslaur> Daviey: yes, thanks
<cjwatson> or distro-info
<cjwatson> though that runs too fast to be talking to the API :-)
<cjwatson> you can just about fit the API call into a one-liner:
<cjwatson> $ python -c 'from launchpadlib.launchpad import Launchpad; lp = Launchpad.login_with("check-series", "production"); print(lp.distributions["ubuntu"].current_series.name)'
<cjwatson> precise
<tumbleweed> if it's not python, distro-info is probably easier
<tumbleweed> we'll have to be keeping thata data up to date via SRU for other packages
<bdrung> Laibsch: you're welcome. :) distro-info is already a year old (initially lived in ubuntu-dev-tools)
<valterstr> so... I was interested in developing for ubuntu.
<valterstr> anyone could give me some pointers where to start?
<valterstr> I have programming skills, but I wouldn't call myself very advanced
<tumbleweed> valterstr: what sort of things do you want to work on?
<valterstr> well, what is there? :?
<valterstr> core development, packages. more?
<valterstr> tumbleweed: what is there?
<tumbleweed> valterstr: https://wiki.ubuntu.com/MOTU/GettingStarted comes to mind, but it's less than perfect
<valterstr> I have seen it...
<valterstr> but it doesn't really explain much.
<valterstr> it gives guidelines
<tumbleweed> you can work upstream, on packages that Ubuntu packages. You can fix bugs on things in Ubuntu, write patches for bugs in our bugtracker, test proposed fixes, clean things up, write developement utilities, etc. Really, anything you want to...
<tumbleweed> #ubuntu-motu for this, maybe?
<valterstr> will check there then.
<valterstr> thanks.
<seb128> zul, hi
<seb128> zul, could you look at bug #911888?
<ubottu> Launchpad bug 911888 in samba (Ubuntu Precise) "gvfsd-smb-browse crashed with SIGSEGV in debug_lookup_classname_int()" [High,Confirmed] https://launchpad.net/bugs/911888
<zul> seb128: yeah ill have a look today
<seb128> zul, we keep getting duplicates, basically adding smb printers and browsing smb shares is broken in precise for some weeks
<seb128> zul, thanks
 * smb knew he was broken
<seb128> smb, unfortunate name conflict :p
<smb> hehe
<zul> seb128: its supposedly fixed in 3.6.2 so ill backport the patch today
<seb128> zul, excellent, thank you
<barry> cjwatson: another alternative would be to remove the chardet requirement for feedparser.  upstream test suite fails when chardet is installed, and upstream has essentially deprecated its use in feedparser.  so i think i should just remove python3-chardet as a *dep.  thoughts?
<bdrung> tumbleweed: what do you think about http://paste.ubuntu.com/814370/ ?
<tumbleweed> bdrung: I guess that works. Bit of an odd interface, but simple enough
<bdrung> tumbleweed: or do you prefer a string parameter?
<tumbleweed> yes, that'd be a nicer interface
 * dholbach hugs pitti
<bdrung> micahg: re bug #909570, can you give me a testcase for that bug?
<ubottu> Launchpad bug 909570 in devscripts (Ubuntu) "wrap-and-sort crashed with KeyError in __getitem__(): '# Language packs below here'" [Undecided,New] https://launchpad.net/bugs/909570
<micahg> bdrung: lp:firefox
<micahg> cjwatson: about the puppet backport, natty got the right version, but maverick and lucid only got a backport from the release pocket and not updates
 * pitti hugs dholbach back
<bdrung> tumbleweed: better: http://paste.ubuntu.com/814434/ ?
<tumbleweed> bdrung: yeah
<bdrung> tumbleweed: suggestions for the FIXME?
<tumbleweed> raise ValueError ?
<cjwatson> barry: python-debian is going to want python3-chardet anyway
<cjwatson> micahg: oh, bah, sorry about that
<barry> cjwatson: okay.  i just uploaded a new feedparser without the deps on py3-chardet, but i'll review/file the MIR for it anyway
<cjwatson> barry: ok - if it's just -debian then I guess you can make it my problem if you want :)
<cjwatson> waiting for an upstream review there
<barry> cjwatson: let's say, if you get to it first, i won't complain :)
<cjwatson> micahg: can you reopen the relevant two tasks for me, please?  I can't
<micahg> cjwatson: done, thanks
<l3on> someone can rebuild python-pysqlite1.1?
<l3on> there is an unmetdep here:
<l3on> Package: python-pysqlite1.1-dbg
<l3on> Version: 1.1.8a-3ubuntu2
<l3on> Missing: python-pysqlite1.1 (= 1.1.8a-3ubuntu2
<cjwatson> micahg: should be all fixed now.
<micahg> cjwatson: looks good, thanks
<tumbleweed> l3on: it looks like that was supposed to have been deleted, but i tcame back in oneiric
<cjwatson> l3on: err, that's kind of odd ...
<cjwatson> tumbleweed: I don't see a deletion in the publishing histsory
<cjwatson> *history
<cjwatson> oh, yes I do
<tumbleweed> cjwatson: https://launchpad.net/ubuntu/+source/python-pysqlite1.1/+publishinghistory deleted in natty
<cjwatson> the phrase "WTF" comes to mind
<tumbleweed> indeed
<cjwatson> maybe we should just delete it again
 * tumbleweed hands cjwatson a garlic stake
<cjwatson> its only reverse dependencies have alternatives
<cjwatson> I've removed it and with any luck it will stay dead this time
<mneptok> if zombie movies are any indication, you have to remove HEAD
<GridCube> hello, im having a few problems, im trying to use the ubuntu-bug to report a few bugs im finding on today's xubuntu image, the problem is that im behind a proxy, so ubuntu-bug is refusing to work, i tried setting html_proxy on a terminal and launching it from there, but with no luck
<GridCube> the html_proxy does work because i just zsynced the image a few minutes ago
<pitti> micahg: should we look into releasing firefox tomorrow (my) morning (i. e. in about 12 hours)?
<cjwatson> GridCube: there is no such environment variable as html_proxy
<cjwatson> (as I told you on -release)
<cjwatson> it's http_proxy
<GridCube> sorry yes
<GridCube> thats the one i used i was just writing from memory now
<cjwatson> and #ubuntu-devel still isn't the right place to ask, as micahg said on -release
<GridCube> i know
<GridCube> :P i already asked on -bugs
<cjwatson> if you ask on several different channels in parallel, you should expect parallel responses ... ;-)
<GridCube> :P indeed
<mpt> kirkland, hi, I'd like to talk with you about privacy and encryption settings if you have time
<kirkland> mpt: please
<kirkland> mpt: sure, shoot
<kirkland> mpt: irc or voice?
<mpt> kirkland, arg, I need to go now, sorry ... What time will you be around tomorrow?
<kirkland> mpt: I'm UTC-6 right now
<kirkland> mpt: most of that work day
<kirkland> mpt: it's noon here right now
<mpt> kirkland, ok, see you in 21-ish hours :-)
<bdrung> tumbleweed: pushed distro-info. can you have a look at it? i want to upload it.
<SpamapS> Ugh.. really not a fan of the new bug listing design
<ScottK> Oh.  My.
<cjwatson> scott-work: http://cdimage.ubuntu.com/ubuntustudio/dvd/current/ merry Christmas
<cjwatson> the text is a bit wrong I guess
<cjwatson> I might leave it that way for now but feel free to file suggestions for HTML changes as bugs on the ubuntu-cdimage project
<cjwatson> hmm, suspiciously short build though!
<cjwatson> scott-work: ok, sorry, this is busted, I'll try again
<cjwatson> next build should be happier
<SpamapS> hrm.. still stuff lingering for libmysqlclient16
<micahg> looks only like 3 or 4 thinsg
<micahg> can give you a pastebin if you like
<tumbleweed> bdrung: lgtm
<cjwatson> micahg: re puppet, I've also now fixed backport-helper.py so that the same mistake shouldn't happen again
<micahg> cjwatson: thanks
<stgraber> mdz, pitti: TB meeting?
 * cjwatson grins at a Debian removal bug
<cjwatson> "Also, there seem to be 4 installations, 3 of which are mine."
<Daviey> cjwatson: the 4th is probably piuparts.debian.org :)
<jono> has Empathy been removed from the disc?
<scott-work> cjwatson: lol
<jono> I just noticed in my new install that it is not installed
<scott-work> cjwatson: but i can defintely tell you that i truly appreciate your efforts on this :)
<l3on> Hey guys... I have 4 packages that need a rebuild... since I don't have upload rights, someone can do that for me ?
<micahg> l3on: sure, which ones and why?
<l3on> micahg, well:
<l3on> This three: haskell-test-framework-hunit haskell-test-framework-quickcheck2 haskell-test-framework-th
<SpamapS> why does haskell get rebuilt every 3 weeks? ;)
<micahg> ABI changes per upload
<l3on> are against: haskell-test-framework
<l3on> this: haskell-clientsession against haskell-skein
<l3on> thanks micahg :)
<jbicha> jono: I just did a new install of precise this morning and empathy is definitely installed, maybe you did a dist-upgrade that removed it?
<jono> jbicha, hmmm odd
<jono> thanks jbicha
<l3on> micahg, here the motivation â http://paste.ubuntu.com/814739/
<micahg> l3on: yeah, makes sense
<cjwatson> l3on: fyi, although haskell is a known standard case where we need rebuilds, in general you cannot assume that unmet dependencies will be magically fixed by a rebuild
<cjwatson> I've noticed you asking for that as a sort of reflex for unmet deps - you do need to check that rebuilding will actually help
<l3on> I rebuild http://debomatic.debian.net/precise/pool/haskell-test-framework-th_0.2.2-3build1/
<l3on> but, onestly, I dind't check the other :/
<l3on> *others
<cjwatson> haskell needs to be rebuilt in dependency order - otherwise you may end up having to rebuild multiple times
<cjwatson> use http://people.canonical.com/~ubuntu-archive/transitions/ghc.html
<cjwatson> likewise with ocaml
<l3on> well.... and is that link public ?
<TheMuso> doko: https://bugs.launchpad.net/ubuntu/+source/at-spi/+bug/790240/+attachment/2689627/+files/openjdk-use-atk-wrapper.diff are my changes for openjdk-6.
<ubottu> Ubuntu bug 790240 in openjdk-6 (Ubuntu Precise) "at-spi needs demotion for precise (at-spi2-core in main)" [Medium,Triaged]
<l3on> no, because it's the first time I ever seen that ...
<cjwatson> l3on: yes
<cjwatson> I mean yes it is public
<l3on> there is some wiki page that I have not read yet ?
<cjwatson> I can hardly answer that reasonably
<infinity> I suspect there are several?
<l3on> can you give me a wikipage that links to that html ?
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel/2011-May/033270.html
<cjwatson> no idea if it is on the wiki
<cjwatson> but it's a wiki, you can edit it :)
<cjwatson> https://wiki.ubuntu.com/OneiricOcelot/TechnicalOverview/Alpha1 and https://wiki.ubuntu.com/PlusOneMaintenanceTeam/Specs/Infrastructure link to it, although neither is particularly documentation; but you specified wiki pages. :-)
<l3on> It's absolutely not clear for a new contributor all these things... there's an well known lack in devel-doc that scares me ... :/
<l3on> beh... let's go to read :) thank cjwatson
<YokoZar> Which debhelper program might be responsible for deleting a .so file in a package directory?
 * SpamapS starts a discussion about bug #871907
<ubottu> Launchpad bug 871907 in vim (Ubuntu) "vim should have "set bg=dark" by default" [Wishlist,Confirmed] https://launchpad.net/bugs/871907
<infinity> SpamapS: Agreed, ship it.
<infinity> SpamapS: (Obviously, the correct answer here is "why the heck isn't vim detecting the current terminal palette and adjusting sanely?"
<infinity> )
<infinity> SpamapS: But people who use white terminals are Wrong(tm) anyway.
 * SpamapS raises infinity a few ticks on the list of people who get to come on the space ship this December
<SpamapS> infinity: indeed, "terminal" isn't enough, we need a new bit to the emulation spec which is "normal" or "eye burning"
<cjwatson> l3on: I don't think it would be reasonable for most new contributors to need to know about the transition tracker; it's a fairly advanced archive management tool
<cjwatson> maybe s/advanced/specialised/
<micahg> l3on: I did the ones for haskell-test-framework, the haskell-clientsession one requires a few extra rebuilds on top of this and I'm not going to do that right now, are you blocked on this for something or are you just trying to fix stuff?
<l3on> micahg, fixing unmetdep in precise...
<micahg> ok, so, it's 7 rebuilds total and they have to be in the right order
<micahg> maybe I look later this week unless someone else grabs it first
<micahg> actually, it's 8 (forgot about the first one )
<infinity> SpamapS: Is there no way for vim to determine its current bgcolor?
<infinity> SpamapS: I would have thought that it would know what it inherited from its parent.
<stgraber> cjwatson: if you have a sec, the TB meeting minutes are waiting in ubuntu-devel-announce
<cjwatson> stgraber: accepted
<stgraber> cjwatson: thanks
<RAOF> We're almost ready to perform the Xserver transition, so I now need to know how to/who to do the source+binary copy from the staging PPA.
<RAOF> cjwatson: If you're not too busy/asleep, I suspect that you know how I can go about binary-copying from the X staging PPA into precise. :)
<cjwatson> yep.  needs an archive admin.  I can do it - can you give me full details?
<cjwatson> oh, wait, you ARE an archive admin
<YokoZar> If package foo version 1 provides i386 and amd64 versions, and package foo version 2 in precise only provides i386 versions (that install fine via multiarch), what happens at upgrade time?
<RAOF> cjwatson: Only for purposes of SRU-teamage.
<YokoZar> IE, do we have to special case each multiarch transition from packages that used to use ia32-libs?
<cjwatson> I think it wants an adaptation of https://wiki.ubuntu.com/ArchiveAdministration#Publishing_packages_from_the_ubuntu-mozilla-security_public_PPA
<Laney> does copyPackage(s) + include_binaries=True not work for anyone? does it work at all?
<cjwatson> Laney: wgrant seems to think it's busted, and I've seen some corroboration of that, so I intend to avoid it until I have time to write a unit test that shows up the problem
<Laney> righto
<cjwatson> I think it worked for me when copying oneiric-proposed -> precise but not oneiric-proposed -> oneiric-updates
<wgrant> cjwatson: I don't know that it's busted, I just know how many problems the implementation has had, and how little it was tested.
<RAOF> We want everything in https://launchpad.net/~canonical-x/+archive/x-staging/+packages to land in Precise.  It's all built and ready.
<cjwatson> but at least some of the implementors seem to be opposed to having the damn thing just e-mail me to tell me what the problem is
<cjwatson> so I can't debug it
<cjwatson> RAOF: should I care about the four build failures there?
<RAOF> Three of them are expected dep-waits rather than build failures; the msm failure on armhf needs fixing, but that can be done later.
<cjwatson> I'm not sure it can after I copy
<cjwatson> I mean I'm not certain it won't need a new upload
<RAOF> Oh, it will need a new upload.
<RAOF> But I'm not sure if anyone uses that driver at all, I don't particularly want to invest the time in fixing the build on armhf right now, and I don't want to delay the transition further.
<RAOF> And I *know* that no-one uses that driver on armhf right now, because it's never been built there before.
 * Laney hopes this transition will bring super meat boy back :-)
 * RAOF had no idea that super meat boy went away, so he confidently responds *yes* !
<kirkland> cjwatson: hey, any chance you're still around?
<kirkland> cjwatson: I have some questions about linux-headers and dkms
<cjwatson> RAOF: xkeyboard-config has a newer version in precise?
<cjwatson> kirkland: sort of, not sure that sounds like I'm the best person to ask though ...
<kirkland> cjwatson: who do you recommend to field this one, then?
<kirkland> maybe slangasek has some ideas
<RAOF> cjwatson: Yes, that's expected, sorry.  I should have removed that from the PPA.
<cjwatson> kirkland: I don't know.  You could ask the question to the channel first and then we could find out
 * RAOF could even have some relevant dkms knowledge
<kirkland> slangasek: cjwatson: okay, I think this should probably be a systemic problem with any dkms packages
<kirkland> RAOF: \o/
<kirkland> slangasek: cjwatson: i have a dkms package, which, of course requires linux-headers to build
<kirkland> slangasek: cjwatson: i can depend on linux-headers, clearly
<kirkland> slangasek: cjwatson: but in practice, that doesn't seem to be enough
<robert_ancell> @pilot on
<udevbot_> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<robert_ancell> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell, pitti
<kirkland> slangasek: cjwatson: because of the combination of all of the different versions and flavors that might be on a given user's system
<infinity> kirkland: Depending on headers is as much of a failing idea as depending on kernel images.
<slangasek> kirkland: there's no good solution to this problem
<slangasek> fwiw
<kirkland> slangasek: ah, okay, so this is a known issue, that others have tried to solve?
<slangasek> yep
<kirkland> slangasek: is there a currently recommended best practice?
<slangasek> there's no way to express the dependency "I need the version of the headers corresponding to the kernel the user has installed / is running"
<infinity> kirkland: nvidia* goes for a best guess of "linux-headers-generic | linux-headers", but that will fail often enough.
<kirkland> infinity: yep, which is where we are
<infinity> kirkland: Generally, the assumption is that people installing dkms packages have the right linux-* metapackage installed, or know what they're doing. :/
<slangasek> kirkland: I think whatever superm1 is doing is probably "recommended best practice"
<cjwatson> RAOF: http://paste.ubuntu.com/814880/ - please review
<kirkland> infinity: i have a check in the postinst, that can echo to the user exactly what they need to install
<kirkland> slangasek: okay, i poked superm1 about this several weeks ago, never heard back from him
<infinity> kirkland: People who watch postinst output have a high incidence of intersection with people who know what headers they need.
<kirkland> infinity: ack
<infinity> kirkland: Now, if this is a driver being enabled by jockey, I suspect jockey can DTRT (and if it doesn't, it could be taught how to)
<kirkland> perhaps what i need is a wrapper script that DTRT
<slangasek> kirkland: right - but you can work out which dkms-using packages in the archive he's touched, I guess, and look at what they do :)  (I honestly don't remember which those are)
<kirkland> and recommend that as the way to install this dkms module
<kirkland> slangasek: heh
<cjwatson> RAOF: It's possible I could do it all in one command, but then I wouldn't get version checks
<cjwatson> And I'm paranoid about this sort of thing
<RAOF> Fair enough.  I'm checking the versions, too.
<infinity> kirkland: To be fair, on a "standard" Ubuntu system (server or any desktop flavor), it's fair to assume that the right headers are installed, and dkms will "just work".
<kirkland> headers=$(dpkg -l linux-image-* | grep "^ii" | awk '{print $2}' | sed "s/-image-/-headers-/") ; sudo apt-get install $headers
<infinity> kirkland: People who break that assumption, while in an unfortunate situation from a support and DWIM standpoint, are hopefully fairly rare.
<kirkland> infinity: hmm, are you sure about that?
<infinity> kirkland: Quite.
<kirkland> infinity: i didn't think headers were installed everywhere by default?
<infinity> kirkland: We jump through hoops to make sure post-installer systems have kernel+headers that match, and a metapackage to make that persist on upgrades.
<RAOF> cjwatson: That list looks correct.
 * cjwatson idly notes that linux-headers-generic is no longer the default on i386 ...
<cjwatson> (And no idea if we always get upgrades right.)
<infinity> cjwatson: You mean generic -> pae upgrades?
<infinity> cjwatson: I have no idea either, but I'd like to hope so? :)
<cjwatson> So would I.
<cjwatson> But I hope for money to rain from the sky too.
<infinity> That's hot happening in Cambridge?
<infinity> You need to move.
<cjwatson> Sucks to be us.
<infinity> s/hot/not/
<RAOF> I hope you're hoping for notes.  Coins would be really annoying!
<infinity> I need new fingers to rain from the sky.
<kirkland> if not linux-headers-generic, what is "the default" on i386 now, cjwatson ?
<cjwatson> -generic-pae
<kirkland> cjwatson: k
<cjwatson> as announced a month or two back
 * infinity has an inexplicable craving for strawberry milkshakes, and decides it's time for lunch.
<kirkland> slangasek: cjwatson: infinity: thanks for your help
<kirkland> superm1: ping me about dkms when you have some time
<kirkland> superm1: re: the conversation I just had with infinity, cjwatson, and slangasek above
<kirkland> superm1: re: best practices on ensuring that all of the necessary headers are installed
<slangasek> infinity: new fingers> eew
<slangasek> kirkland: sure thing
<SpamapS> slangasek: think you'd have time to sponsor a mysql upload?
<SpamapS> slangasek: 5.5.20 did in fact fix compiling with gcc 4.6
<SpamapS> slangasek: I think I'll keep it in experimental though, until I figure out how to not build /usr/bin/mysql statically linked
<micahg> robert_ancell: would be appreciated if you can have a look at bug Bug #916477 after your piloting session (blocking lightdm-gtk-greeter getting into Debian)
<ubottu> Launchpad bug 916477 in Light Display Manager "gio-2.0 missing from liblightdm-gobject-1.pc" [Medium,Incomplete] https://launchpad.net/bugs/916477
<robert_ancell> micahg, do you understand why it is failing?  The greeter doesn't need to link against gio
#ubuntu-devel 2012-01-24
<Gnostus_> Is there any sort of tool that can unencrypt a copy/pasted message encrypted from PGP, problem is that im hooked up to yahoo(boo) and from what im seeing theres alot of hoops as im not paying for there pop service :\
<micahg> robert_ancell: well, it seems to need something from gio (or lightdm is exporting something it shouldn't maybe) per the build log failure
<micahg> haha, it's using gio :), the issue is probably --as-needed :)
<robert_ancell> micahg, do you have a debian system to test on?  ldd /usr/lib/liblightdm-gobject-1.so for me shows it correctly linked against on Ubuntu
 * micahg is checking in a chroot
<micahg> oh, Debian only has 1.0.6
 * micahg wonders why liblightdm-gobject-1-0 is in a multiarch patch in Debian and not in Ubuntu
<micahg> s/patch/path
<micahg> FWIW, 1.0.6 in Debian is linked against gio-2.0
<cjwatson> RAOF: all copied for the next publisher run
<cjwatson> (I believe.  Feel free to chec)
<cjwatson> +k
<RAOF> Where will tha tbe showing up?  precise-changes?
<cjwatson> Not sure, but hopefully.  They'll be in publishing histories though
<cjwatson> e.g. https://launchpad.net/ubuntu/+source/xorg-server/+publishinghistory
<micahg> manual copies usually don't end up in -changes from what I've seen
<bdmurray> I'm looking at some initramfs-tools bugs and there are a few package install failures with the following in them
<bdmurray> cp: not writing through dangling symlink `/etc/initramfs-tools/modules'
<bdmurray> when I sawy a few I mean 5 and 2 of the 5 mention parallels on a mac
<bdmurray> and I don't know of a way to tell if the others are using parallels
<bdmurray> bug 913631 is an example
<ubottu> Launchpad bug 913631 in initramfs-tools (Ubuntu) "package initramfs-tools 0.99ubuntu8 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/913631
<psusi> is dh_translations also appropriate for debian?
<stgraber> bdmurray: a blog post I found mentions the vmware tools and I confirmed that the bug you posted above is on a system with openvm-vm-* installed (VMWare guest tools)
<stgraber> bdmurray: can you see if that's the case for all of them?
<stgraber> bdmurray: http://jerram.tumblr.com/ is the blogpost
<stgraber> bdmurray: (I looked at the package list that was contained in the apt-clone tarball, but you can probably find the same in the logs)
<bdmurray> stgraber: wow, I forgot what a mess that aptclone attachment is
<stgraber> bdmurray: yeah, you need to gzip -d, then rename to .tar.gz then unpack :)
<bdmurray> stgraber: I think I'll fix that.
<stgraber> that'd be great :)
<bdmurray> which package did you find?
<bdmurray> oh open-vm
<stgraber> open-vm-dkms, open-vm-source, open-vm-toolbox and open-vm-tools
<bdmurray> you'd said openvm-vm earlier
<bdmurray> regardless I don't see it in a couple of others
<stgraber> bdmurray: any chance you can get them to paste "ls -l /etc/initramfs-tools" in the bug?
<stgraber> bdmurray: seeing where the symlink is pointing to would make figuring out the source a lot easier :)
<bdmurray> stgraber: sure, I'll ask
<psusi> is dh_translations also appropriate for debian, or is that an ubuntu thing?
<cjwatson> $ grep Ubuntu /usr/bin/dh_translations
<cjwatson>             push @result, "X-Ubuntu-Gettext-Domain=$domain\n";
<cjwatson>         push @result, "X-Ubuntu-Gettext-Domain=$domain\n";
<cjwatson> at the very least it ought not to be used on Debian without some thought and work
<cjwatson> it's not in Debian
<psusi> damn
<psusi> I was just about to merge a new upstream gparted with all ubuntu changes to debian and resync, and someone added dh_translations
<psusi> so now I guess I'll have to wait for the debian upload, and merge it back to ubuntu keeping the translations local...
<superm1> kirkland: general practice thus far has been linux-headers-generic | linux-headers, which should hit any of the desktop/server machines that have gone through an ubuntu installer proper I believe
<kirkland> superm1: okay, thanks
<superm1> it's when people start going and mucking with alternate kernels or kernels from PPAs that problems come up
<kirkland> superm1: i think that's what we've got so far
<superm1> but generally those people are intelligent enough to figure out the problem too i suspect
<kirkland> superm1: yeah, i've had trouble characterizing *when* people get into trouble
<superm1> kirkland: and actually dkms itself is the one pulling in those recommends too
<kirkland> superm1: hmf
<superm1> Recommends: fakeroot, menu | sudo, linux-headers-686-pae | linux-headers-amd64 | linux-headers-generic | linux-headers, linux-image
<superm1> so possibly are these people who are ignoring recommends by default?
<micahg> hmm...seems like an implementation detail best left to dkms
<kirkland> superm1: i'll have to check, but thanks for the pointers and sanity checks
<superm1> sure
<superm1> if you encounter some more details about a failing scenario i'll be glad to try to help accommodate within reason
<kirkland> superm1: thanks
<kirkland> superm1: i'll let you know
<superm1> ok
<robert_ancell> pitti, ping
<pitti> Good morning
<pitti> stgraber: argh, sorry, I totally missed the TB meeting; need to fix my calendar
<pitti> hey robert_ancell
<robert_ancell> pitti, hey, mfisch was trying to use the LightDM GIR bindings but the objects don't have any methods.  Can you see anything wrong with them?
<robert_ancell> pitti, e.g. 'from gi.repository import LightDM; l = LightDM.Greeter(); dir(l)' shows nothing
<pitti> robert_ancell: which package ships the .gir file?
<pitti> liblightdm-gobject-1-dev I suppose
<robert_ancell> pitti, liblightdm-gobject-1-dev
<robert_ancell> yup
<pitti> oh, Greeter is a struct
<pitti> robert_ancell: it does show stuff; apart from the standard __ bits, it has "parent_instance"
<pitti> robert_ancell: the .gir does not specify any other field in Greeter
<pitti> robert_ancell: it has a "GreeterClass" struct with some fields, though
<robert_ancell> pitti, so it's not being recognised as a GObject?
 * pitti bzr pulls trunk and has a look
<pitti> robert_ancell: src/greeter.h looks the same, though
<pitti> robert_ancell: struct Greeter with just a parent_instance
<pitti> apparently it doesn't pick up the functions anywhere, though
<pitti> robert_ancell: OOI, why did you make it a struct and functions, instead of an actual class?
<robert_ancell> it is a class afaict
<pitti> robert_ancell: oh, I see
<pitti> robert_ancell: you build the .gir from liblightdm-gobject/
<pitti> robert_ancell: and only include the .c files from there
<pitti> you also need to include the source files from src/ if you want to expose the server-side methods
<pitti> but I suppose that's not actually intended? If you just want to use the library API, then src/greeter.c should not actually be exposed?
<robert_ancell> pitti, no, I don't want to expose the server side stuff
<pitti> ok, so e. g. greeter_set_allow_guest() sohuldn't be exposed (it's from src/greeter)
<pitti> but lightdm_greeter_connect_sync ought to be exposed
<robert_ancell> yes
<robert_ancell> pitti, oh, this looks oddc: symbol-prefixes="light_dm"
<pitti> *nod*
<pitti> built from "LightDM" namespace
<pitti> robert_ancell: let me build the source, I added --warn-all to INTROSPECTION_SCANNER_ARGS
<pitti> robert_ancell: hah, --warn-all shows why
<pitti> robert_ancell: I think it's a good idea to commit that, and then fix all the warnings; want me to push the --warn-all
<pitti> ?
<robert_ancell> yes please
<pitti> (done)
<pitti> user.c:135: Warning: LightDM: invalid annotation option: tranfer
<pitti> lightdm/greeter.h:71: Warning: LightDM: symbol='lightdm_greeter_get_type': Unknown namespace for symbol 'lightdm_greeter_get_type'
<pitti> robert_ancell: ^ very useful
<robert_ancell> pitti, thanks a lot!
<pitti> let me spend a minute on the namespace bug
<robert_ancell> pitti, setting --symbol-prefix seems to fix it
<robert_ancell> (pushed)
<pitti> hah, that's what I was trying indeed
<pitti> robert_ancell: you can drop --identifier-prefix=LightDM BTW, it's the default
<pitti> i. e. it defaults to the name of the GIR
<pitti> (but it doesn't hurt)
<pitti> now, no warnings at all
<pitti> robert_ancell: ah, and now it's a proper class, too
<pitti> cjwatson: the syncs in https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1 look wrong; do you need them for examination, or can I remove them?
<pitti> cjwatson: oh, hang on -- are these the result from "sru-release", i. e. copying from -proposed?
<pitti> looks like the recent KDE 4.7.4 SRU
<pitti> cjwatson: these already seem to be in -updates, though
<pitti> jibel: I see my test scripts in https://jenkins.qa.ubuntu.com/view/Precise/job/precise-upgrade-lts/PROFILE=lts-ubuntu,alderamin-upgrade=alderamin-upgrade/19/consoleText , nice!
<pitti> jibel: however, it seems it ran the prepare_user.sh bit as root?
<pitti> jibel: sorry, the test_upgrade_user.py as root
<pitti> jibel: and can you change it to run the test_upgrade_user.py one through dbus-launch?
<pitti> jibel: for test_lts_upgrade_system.py, I think the missing autologin migration is known
<pitti> robert_ancell: ^ do you plan to read /etc/gdm/custom.conf at first lightdm installation and copy over the autologin-user value  from it?
<pitti> robert_ancell: we have an automatic upgrade test case for this now (migrating autologin settings)
<jibel> pitti, good morning
<pitti> jibel: bonjour, ca va?
<jibel> pitti, Ã§a va et toi ?
<pitti> je suis bien, merci!
<jibel> pitti, prepare_user is run with sudo as user ubuntu, should I run it with dbus-launch too ?
<pitti> jibel: yes please
<pitti> jibel: presumably you also need -H
<pitti> jibel: it seems it's trying to get the background from /root/ otherwise
<pitti> jibel: i. e. sudo -H -u ..
<jibel> pitti, no, background is not preserved on upgrade
<pitti> hm, interesting
<jibel> pitti, theme, keyboard and language settings are lost too
<pitti> do you get a /home/ubuntu/my_background.jpg after the prepare script?
<jibel> pitti, yes, I also ran the upgrade manually
<jibel> and checked the settings before and after upgrade from system settings to make sure the script was right.
<pitti> ok, that's something to investigate then
<jibel> pitti, i'll do one more upgrade this morning and will file bugs
<pitti> merci
<jibel> pitti, but at least launchers are preserved and moved to unity launcher.
<jibel> desktop launchers are also preserved is desktop was not renamed from french to english
<jibel> s/is/if
<dholbach> good morning
<pitti> jibel: right, the automatic test still fails, presumably because it's looking in /root/ again instead of /home/ubuntu
<pitti> hey dholbach
<dholbach> hey pitti
<jibel> pitti, i'll check that
<jibel> morning dholbach
<pitti> jibel: I hope sudo -H and dbus-launch will fix that
<dholbach> salut jibel - comment Ã§a va?
<jibel> dholbach, Ã§a va, et toi ?
<dholbach> jibel, oui, Ã§a va, j'ai seulement besoin d'un petit peu de cafÃ©  ;-)
<tjaalton> shouldn't 'bts' work on ubuntu too? I see emails sent from my machine but not doing anything on the debian BTS
<tumbleweed> tjaalton: I don't see any reason why it wouldn't work on ubuntu
<tjaalton> right..
<pitti> tjaalton: WFM
<Laney> it certainly does work
<Laney> you need a working MTA though
<Laney> or --smtp-host
<tjaalton> ok so just to get this right; i'm trying to mark a bunch of bugs to block one, so I ran 'bts block xxx by yyy zzz'
<tjaalton> MTA works
<tjaalton> I'll try another smtp server
<tjaalton> that helped..
<pitti> SpamapS: do you know about the status of bug 580319 for lucid, in particular 10.04.4? Is that something that's realistic to get fixed still, or should we drop it from the milestone list?
<ubottu> Launchpad bug 580319 in upstart (Ubuntu Natty) "init.d controlled services launch before all interfaces are up, thus failing to start" [Medium,Triaged] https://launchpad.net/bugs/580319
<pitti> ev, cjwatson: does ubiquity already have a convenience function/method to determine when it's in "only-ubiquity" mode? (it doesn't seem to check /proc/cmdline for that)
<pitti> I need this for bug 712677, i. e. call apport-gtk for only-ubiquity, and only write the .crash for live session mode
<ubottu> Launchpad bug 712677 in ubiquity (Ubuntu Precise) "Does not report crashes during "Install Ubuntu" installs" [High,In progress] https://launchpad.net/bugs/712677
<ev> pitti: that's determined outside of ubiquity, in the upstart job
<ev> as it affects the options passed to ubiquity-dm
<ev> but all it is, as you point out, is an option in /proc/cmdline
<pitti> ev: right, I saw that; I just found it curious that nothing else in ubiquity works differently in only-ubiquity mode
<pitti> ev: so I guess I'll implement my own check then
<ev> so we could just spawn it off of ubiquity-dm
<ev> apport, that is
<pitti> you mean "it" == update-notifier?
<pitti> I don't think we need the full thing
<ev> ohhh, right, update-notifier does the inotify watch, doesn't it?
<pitti> yes
<pitti> until we get user session upstart jobs and inotify triggers for jobs
<pitti> ev: ok, thanks! just wanted to ensure that I don't duplicate something
<ev> those would be very nice
<ev> sure thing
<pitti> hm, actually.. if ubiquity crashes with e. g. a segfault, the ubiquity-builtin excepthook doesn't actually help us
<pitti> so yes, maybe running through the piled up crashes in ubiquity-dm after ubiquity finishes is better after all
<pitti> jibel: oh, calling gsettings-data-convert segfaults; that might explain why the gconf settings are not migrated during upgrade
<pitti> seb128: ^ known?
<seb128> pitti, depend what schemas is missing
<pitti> if I call that on a live system, I get an error message about a missing unity-2d "use-strut" key, and then a segfault
<seb128> pitti, there are known issue, can you get the assert error? it should tell you what schemas,key is buggy
<pitti> sorry, no segfault, assertion
<seb128> yeah, that's known
<pitti> com.canonical.Unity2d.Launcher use-strut
<pitti> seb128: ok, thanks; that's a likely candidate for the failing user config migration test
<ara> hello pitti!
<pitti> hey ara, long time no see!
<ara> pitti, true! :)
<ara> pitti, one quick question, what are the chances of python-qt4 making it to the CD on precise? :)
<pitti> ara: in the current state, pretty much zero
<pitti> ara: it's about 13 MB compressed
<pitti> and we are 11 MB oversized
<ara> and is it anybody working in making it smaller?
<pitti> no to my knowledge; maybe
<pitti> it could be split into submodules
<ara> OK, but, to be on the safe side, better not using it
<pitti> but even then it would still use some 4 or 5 MB, which is still heavy
<seb128> pitti, hum, I can't find the bug now, maybe it was mentioned somewhere but not filed
<seb128> pitti, but feel free to open an unity-2d bug
<seb128> pitti, they list a key in their .convert which is not in the schemas
<ara> pitti, OK, thanks!
<pitti> seb128: probably bug 875590 and dupes (I'll mark a few)
<ubottu> Launchpad bug 875590 in gconf (Ubuntu) "gsettings-data-convert crashed with signal 5 in g_settings_set_value()" [Medium,Confirmed] https://launchpad.net/bugs/875590
<pitti> seb128: still, should the whole thing fail because of one wrong schema?
<seb128> pitti, no, that one is bug #916441
<ubottu> Launchpad bug 916441 in shotwell (Ubuntu) "gsettings-data-convert crashed with signal 5 in g_settings_set_value()" [Medium,Confirmed] https://launchpad.net/bugs/916441
<seb128> pitti, i.e a shotwell schemas
<pitti> indeed, duping
<seb128> pitti, " thing fail because of one wrong schema?" <- tell desrt, that's how gsettings is designed
<seb128> pitti, it's the "gsettings abort on missing schemas" discussion we have regularly
<pitti> *nod*
<pitti> seb128: ok, added an unity-2d task
<pitti> seb128: thanks!
<seb128> pitti,  to what bug?
<pitti> (will look at it soon)
<pitti> bug 916441
<ubottu> Launchpad bug 916441 in unity-2d (Ubuntu Precise) "gsettings-data-convert crashed with signal 5 in g_settings_set_value() on missing keys" [High,Triaged] https://launchpad.net/bugs/916441
<seb128> :-(
<seb128> pitti, I hope the yorba guys don't get annoyed by getting "spammed" by unity-2d comments
<seb128> let's see
<seb128> but thanks ;-)
<pitti> well, it's the same crash, and apport will dupe them all there anyway
<seb128> it's not, it's buggy schemas in 2 different applications
<pitti> and we need to fix all broken schemas; that's pretty much exactly what bug tasks are for?
<seb128> it's like saying "it's 2 aborts"
<pitti> it's _exactly_ the same abort
<pitti> we can't tell apport that the same crash is caused by two different data files from different packages
<seb128> well it's like saying "abort on a missing icons" are dups when the icons and softwares are different
<seb128> right
<seb128> well still doing it this way means that i.e shotwell subscriber will get email for bugs in unity-2d
<pitti> jibel: ^ so you can use above bug for the data migration for now; once that's fixed, we should re-check
<seb128> pitti, I will remove the shotwell component and use another bug for shotwell, I really don't want to spam the yorba guys about buggy schemas in other applications
<seb128> let's keep that one for unity-2d
<pitti> well, then let's keep that for shotwell, to keep the already existing comments
<pitti> and create a new one for unity-2d
<pitti> but it'll still be misleading for crash reporters
<pitti> as they will be led to the shotwell one
<pitti> but *shrug*
<seb128> pitti, we can keep a gconf bug for apport dup master if you want
<seb128> then open bugs about buggy softwares and add comments about those on the gconf bug
<seb128> let's rename the master "the schemas migration should ignore buggy schemas"
<jibel> pitti, ok. Is there a way to find this bug from the logs or during upgrade, any test I could add ?
<pitti> jibel: you should have a gsettings-data-convert crash in /var/crash
<pitti> jibel: but doesn't the test_lts_upgrade_user.py thing cover this now?
<pitti> seb128: or that, WFM
<jibel> pitti, nothing in /var/crash but the post-upgrade test covers this indirectly.
<pitti> seb128: bug 920894, removed unity-2d task from other one
<ubottu> Launchpad bug 920894 in unity-2d (Ubuntu Precise) "wrong use-struts key in gsettings schema causes gsettings-data-convert crash" [High,Triaged] https://launchpad.net/bugs/920894
<seb128> pitti, thanks
<pitti> now, we can't really fix one without the other, but as we don't have bug dependencies, we'll have to track it manually
<seb128> pitti, ?
<seb128> pitti, we can fix the .convert individually
<pitti> I mean, if we fix shotwell, it still affects shottwell
<cjwatson> pitti: oh, hah, is *that* what happened to them - I forgot they were going to go through the queue
<pitti> it'll still crash
<cjwatson> pitti: feel free to reject them, as I copied them separately
<pitti> seb128: anyway, we discussed it now, it's fine
<seb128> pitti, right
<seb128> pitti, btw I will backport http://git.gnome.org/browse/gconf/commit/?id=120f116e608bc1f09cf65435333e40e00c6b8ad2
<pitti> seb128: \o/
<pitti> that'll help indeed
<seb128> pitti, but that will not sort those cases, that's not missing schemas but broken keys listed
<pitti> seb128: so we sohuld reassign 916441 to gconf after all?
<seb128> pitti, no, in those cases the schemas is there, the .convert just list a key which is not in the schemas
<pitti> ah, I see
<seb128> which is a variant that git commit will not fix
<pitti> cjwatson: done; so that's not through sru-release? (as that seems to work, at least my version)
<pitti> bbl, need to go to the dentist again
<cjwatson> pitti: I had a locally modified sru-release that used Archive.copyPackage
<cjwatson> pitti: so that might actually work then - I just need to make it print a warning to go and prod the queue
<cjwatson> pitti: (or ideally have a queue API so that it could do it itself)
<pitti> cjwatson: ah, thanks
<pitti> yeah, auto-accepting from the queue would be nice indeed, but I guess a warning to do it manually would do for now
<cjwatson> no rush, it can wait until we have a queue API I think
<cjwatson> I was trying to get around Archive.syncSource timeouts without resorting to copy-package.py :)
<cjwatson> of course auto-accepting from the queue requires waiting for the PCJ to run :-(
<cjwatson> (PackageCopyJob - Archive.copyPackage is async ...)
<pitti> oh, nice! no more timeouts?
<pitti> that's still better than having to ssh
<pitti> which we have to do for every kernel update, and a lot of other packages like gtk or unity
<cjwatson> It's async, but doesn't report failures anywhere useful right now, so can be a bit confusing
<cjwatson> but yes, it is likely the ultimate solution for that kind of problem
<hrw> can someone take a look at http://people.linaro.org/~hrw/ubuntu/multiarch/elfutils.deb.diff and share opinion?
<hrw> it is not perfect probably but I managed to build few packages (rpm, kcov, systemtap, makedumpfile) with resulting packages.
<tumbleweed> is there any point in moving the stuff to multiarch locations if you aren't marking the binaries MultiArch: same ?
<hrw> ah, forgot that part
<hrw> tumbleweed: I want to be able to install :amd64 and :armel at same time for kernel/perf compilations
<tumbleweed> right. otherwise, the diff looks sane
<hrw> tumbleweed: Standards-Version needs update but this part is a thing which I have to learn
<hrw> tumbleweed: and thanks for review
<geser> isn't the debhelper compat level tied to the debhelper major version (as a lower bound)?
<tumbleweed> we try to avoid unecessary changees in debian (such as bumping standards version)
<tumbleweed> err in Ubuntu
 * tumbleweed actually tries a build of that
<hrw> geser: http://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools says ">= 8.1.3" + compat/9
<geser> ok then
<hrw> tumbleweed: I am considering sending patch to debian
<hrw> tumbleweed: otherwise this work is useless
<doko> TheMuso, could you write a MIR for java-atk-wrapper?
<tumbleweed> hrw: that's always good. still, the standards-version  bump is unrelated (except that a newer standards version is required to specify multiarch)
<hrw> ok
<hrw> ~curse m4
<tumbleweed> hrw: well, it doesn't bulid, test failure :)
<hrw> tumbleweed: pastebinit please
<tumbleweed> hrw: unrelated, I think, I get it withotu the patch too
<hrw> tumbleweed: anyway I am interested if you can share them
<tumbleweed> http://paste.ubuntu.com/815293/ could be something about my build environment (eatmydata + aufs)
<hrw> maybe. here all 70 passed
<hrw> now I need to dig out older gcc-4.6 and rebuild my cross compiler for one test
<tumbleweed> hrw: it's being confused by the chroot's full (from the outside) filenames in /proc/self/maps
<hrw> ok, sent to debian
<hrw> should I wait for Debian or can I search for sponsor to get it in Ubuntu archive?
<tumbleweed> hrw: We already have a delta, so unless that's been superseded in debian, I don't see any reason not to upload to Ubuntu directly. But, as a non-core-dev, I can't help there.
<geser> hrw: depends on how active the DD is and how urgent you need it in Ubuntu (does it block you?)
<hrw> geser: no, it does not block me so I can wait
<jdstrand> hallyn: hey. reading your libvirt-bin diff, am I right in understanding that everyone must now have a default network and that package upgrades will unconditionally enforce that?
 * diwic boots into a new X stack, seems to work fine so far
<cjwatson> bilal: could you please merge scim-chewing from testing?  it fails to build in precise right now, and it looks as though a simple merge should fix it
<cjwatson> (you're the last uploader)
<hallyn> jdstrand: no.  the opposite.  In the past it would always, on upgrade, re-enable the default net.
<hallyn> jdstrand: now the intent is to check whether the default net autostart symlink exists, and only recreate it on new installs or if it already existed
<hallyn> jdstrand: so if you have custom networking and have deleted the autostart symlink, then upgrades won't mess with your networking, like they used to
<hallyn> unfortunately that has been a lot harder for me to get right than i expected
<slangasek> mvo: heya, we seem to have stalled out somewhere on the apt merge question; what's the current status, and is there something I can do to help it along?
<slangasek> tumbleweed: thanks for your fixes to submittodebian, btw - it's working much more smoothly for me now :)
<tumbleweed> slangasek: np
<mvo> slangasek: I uploaded a bunch of stuff to debian-experimental now, if that looks solid, that will be what we use too, I had a issue with libept1 as that needs to change the binary package name when the libapt abi changes to avoid double linking against old libapt and new libapt
<slangasek> mvo: hmm, ok (time for symbol versioning in libapt? :)
<pitti> ev: I didn't commit the fix right away, but put it into a MP: https://code.launchpad.net/~pitti/ubiquity/only-ubiquity-crashes/+merge/89916
<pitti> ev: I tested it and it works, but I'd still appreciate a second pair of eyes, especially on the exit(1) and some general style issues
<mvo> slangasek: that and for getting rid of the current global symbols
<glenn___> jodh: im sorry, it was not my intention to get off topic
<jdstrand> hallyn: ok cool. I didn't read the whole postinst. thanks for explaining
<hallyn> jdstrand: hopefully I've finally got it right.  Maybe the moral is that it can't be done 100% right, and that's why debian just doesn't do net autostart by default at all.
<hallyn> i'm learning...
<ev> pitti: just one comment. Looks good though.
<pitti> ev: reason> mostly, not knowing about it :)
<ev> :)
<pitti> ev: will try again with that
<ev> cheers
<pitti> I suppose it will just work, but it was fiddly enough to get working that I'd like to actually see this myself
<psusi> pitti: you merged a patch the other day to gparted to use dh_translations, which you also seem to be the author of.  I was just about to resync ubuntu to debian's gparted.  Is it possible to set it up in such a way that it does not disturb debian?
<pitti> psusi: debian/rules, yes, but not the build dependency
<pitti> we don't have "opportunistic" build dependencies unfortunately
<pitti> psusi: the only workaround known to me is to build depend on cdbs, which pulls in dh-translations on ubuntu, but not in Debian
<psusi> pitti: and debian doesn't even have the dh-translations package?
<pitti> psusi: or we need to go back to doing things manually, but Gabor found something wrong with that previously
<pitti> psusi: no, they don't have langpacks and all that
<psusi> pitti: would it be possible to get a dummy package into debian that would satisfy the depend, and do nothing?
<pitti> psusi: you could do a hack like B-D: dh-translations | frozen-bubble :)
<psusi> why muddle the depend line?  just make a dh-translations package on debian that is just a no-op
<cjwatson> not sure even that works; IIRC Debian's sbuild always wants the first alternative
<pitti> psusi: I guess if we want to sync, we could just do the translation stuff in debian/rules; which can then be protected by dpkg-vendor --is ubuntu
<pitti> cjwatson: yeah, it really was a joke
<pitti> if we do b-d hacks, then adding cdbs would be less ugly
<pitti> psusi: oh -- you can b-d on gnome-pkg-tools
<SpamapS> pitti: re bug 580319 , its my understanding that 10.04.4 is frozen.. or has hat been extended?
<psusi> wouldn't it be easier to just have an actual dh_translations helper script in debian so the rules file doesn't need modified, and just their version wouldn't actually do anything?
<ubottu> Launchpad bug 580319 in upstart (Ubuntu Natty) "init.d controlled services launch before all interfaces are up, thus failing to start" [Medium,Triaged] https://launchpad.net/bugs/580319
<pitti> psusi: that's small, harmless, and will DTRT
<psusi> pitti: but you'd still need to modify rules to switch on dpkg-vendor right?
<glenn___> jodh: regarding upstart: should the exit code of "status ssh" be not 0 if ssh is not running
<pitti> psusi: and then in rules, something like "if dh -l | grep -q ^translations"; then --with translations, etc.
<pitti> psusi: easier, yes, but we don't have it right now, and getting it into Debian takes some time (not to mention the political discussion of "cluttering" their package namespace with it)
<SpamapS> pitti: also the fix that we did in 11.10 has been fairly controversial.. so I don't think it can be a straight backport
<stgraber> pitti: added what I hope is a detailed testcase to bug 889423 (for bridge-utils, will do the same for vlan and ifenslave-2.6 when they land). Didn't mark it verification-done as I'm the one who did the actual changes, so hopefully we can get someone to run the same tests or if you're satisfied with what I posted, feel free to change the tag yourself.
<ubottu> Launchpad bug 889423 in vlan (Ubuntu Oneiric) "802.3ad bonding not configured correctly" [Undecided,Fix committed] https://launchpad.net/bugs/889423
<psusi> hrm...
<slangasek> SpamapS: mysql-5.5 debian/watch seems to be broken
<slangasek> SpamapS: also, do you want to push an update to debian/changelog so I can build straight from svn ):
<stgraber> pitti: also, I think I'd prefer to have all 3 of them land at the same time as at least ifenslave calls the two others. They don't strictly depend on each other, but the bug won't be fully resolved until they all get updated.
<slangasek> :)
<pitti> SpamapS: frozen in the sense that we control what goes in now
<pitti> SpamapS: ack, let's drop the milestone then
<Daviey> cjwatson: Would you be able to comment on bug 920749 please? Thanks.
<ubottu> Launchpad bug 920749 in openssh (Ubuntu) "pam configuration for SSH prevents LANG override" [Undecided,New] https://launchpad.net/bugs/920749
<pitti> stgraber: right, I ignored one for now, as it seemed way too intrusive for a quick review; thanks for the heads-up
<pitti> ev: yep, works fine
<ev> great
<pitti> pushed
<pitti> (to my branch)
<ev> cool, I'll merge now
<SpamapS> slangasek: right I didn't want to --release until you ack'd. ;)
<SpamapS> pitti: for bug 711425, I'm comfortable waiting until after 10.04.4 to let that into -updates ..
<ubottu> Launchpad bug 711425 in sysvinit (Ubuntu Lucid) "portmap does not stop during shutdown, causing possible root fs corruption" [High,Fix committed] https://launchpad.net/bugs/711425
<ev> pitti: merged; thanks for this!
<pitti> ev: thanks!
<slangasek> SpamapS: ok - let me do a test-build here and confirm that myodbc builds against it without further problems first :)
<pitti> SpamapS: hm, you think it's too unsafe for 10.04.4? it's marked for this point release, after all
<stgraber> pitti: yeah, ifenslave-2.6's delta is pretty big, if looking closely you'll notice it's mostly code being moved around into separate functions with the actual addition being maybe 30 lines of code (the whole, locking, waiting and calling vlan/bridge-utils hooks part).
<cjwatson> Daviey: linked to the upstream bug which has more than enough commentary for anyone
<cjwatson> Daviey: I'll have a think about it
<pitti> need to run for today, see you tomorrow!
<Daviey> cjwatson: thanks!
<cjwatson> Daviey: I don't think I accept the milestoning though, sorry.  This has been present forever and there doesn't seem a need to rush into a solution without upstream.
<cjwatson> Particularly since it's not entirely impossible that the best fix might involve changing both OpenSSH and PAM.
<cjwatson> nuclearbob: has there been any progress with getting the conflict checker up to date?
<nuclearbob> cjwatson: not as much as I'd like.  I've been pulled onto updating reporting projects for my team a lot.  I'll try to wrap those up and get back onto the conflict checker ASAP.
<SpamapS> pitti: its safe enough, but not worth blocking 10.04.4 on.. it hasn't been verified yet
<SpamapS> pitti: and I think it may even be short a couple days on the 7 day rule too
<cjwatson> pitti: any progress on getting firefox into lucid-updates?  I'm conscious that we haven't been able to build .4 DVDs yet
<ev> pitti: stack traces to StacktraceAddressSignature is a one to many relationship, right?
<jbicha> kees: are you around?
<dholbach> kirkland, you rock!
<tumbleweed> anyone know how much RAM our biggest arm buildds have?
<ScottK> tumbleweed: Not enough.  There's some issue with ram usage on arm so we can't build large packages that used to build like qtwebkit-source.
<brendand> anyone here can talk about the HUD?
<seb128> brendand, better on #ubuntu-unity
<brendand> seb128 - is that a real channel?
<brendand> on Freenode?
<brendand> eh, typo - sorry
 * brendand typed ubunty-unity
<jalcine> jono: ping
<jono> jalcine, howdy
<psusi> pitti: the man page for dh_translations says that it fixes up desktop files... in that merge commit, X-Ubuntu-Gettext-Domain was added to the desktop.in.in file via patches/01_fix-desktop.patch.  Shouldn't that change be left out of the main sources and it's added when dh_translations is run?
 * kirkland high-fives dholbach ;-)
<slangasek> tumbleweed: what's the problem you're running into (ARM)?
<tumbleweed> slangasek: I'm going to run into trouble with pypy
<tumbleweed> actually, already have
<jdstrand> mdeslaur: when you disabled network-manager/dnsmasq integration, did you just remove this line from /etc/NetworkManager/NetworkManager.conf: dns=dnsmasq
<mdeslaur> jdstrand: yes,I just commented it out
<jdstrand> mdeslaur: thanks
<SpamapS> pitti: did you forget to @pilot out?
<slangasek> jdstrand, mdeslaur: hmmm, why are you guys disabling the dnsmasq integration?  I thought the current solution was one that passed muster with the security team; are there bugs?
<jdstrand> slangasek: I'm not sure if there is a bug there or not. I am trying to figure it out
<slangasek> ok
<mdeslaur> slangasek: I was having trouble looking up libvirt guests and disabled it, I haven't turned it back on yet as the dnsmasq issue isn't fixed yet AFAIK
<slangasek> alrighty
<jdstrand> slangasek: I do still need to fiddle with resolvconf as we discussed before for working with libvirt-- I think mdeslaur opted out of resolvconf
<slangasek> I've never had libvirt guest lookup working here fwiw; would love to have that figured out
<jdstrand> it used to work great with resolvconf as per https://wiki.ubuntu.com/SecurityTeam/TestingEnvironment#Networking_with_libvirt
<mdeslaur> slangasek: easy, use 192.168.122.1 as your dns server
<jdstrand> well, previous dnsmasq releases needed you to append '.' to the host name
<slangasek> oh, it requires manual configuration?  Well no wonder ;)
<slangasek> so if libvirt could integrate with resolvconf that'd be peachy
<slangasek> oh right
<slangasek> that's the bug, that integrating with resolconf is no longer sufficient ;)
<jdstrand> that seemed to be fixed in 11.10 or 12.04...
<jdstrand> 12.04 is weird though-- sometimes the lookups work and sometimes not
<slangasek> hmm
<mdeslaur> jdstrand: oh? seems to work reliably for m
<mdeslaur> me
<jdstrand> I still have to hup dnsmasq occasionally
<jdstrand> I haven't figured out why
<mdeslaur> jdstrand: oh, yeah, me too...it stops responding after a while
<mdeslaur> but, rebooting every 8 hours because compiz stops displaying my firefox windows mitigates the issue nicely
<jdstrand> so I guess saying it works 'fine' is overselling it
<jdstrand> it works ok most of the time
<jdstrand> mdeslaur: pfft
<mdeslaur> jdstrand: hehe
<jdstrand> seriously? I haven't had that since upgrading to precise :)
<jdstrand> (actually 11.10 was pretty solid by the time we released too)
<mdeslaur> jdstrand: yeah, I still get it with precise
<elmo> JOOI, what's the rationale for the dnsmasq stuff in network-manager?
<jdstrand> weird..
<jdstrand> elmo: https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-dns-resolving
<elmo> jdstrand: thanks
<jdstrand> hmmm
<slangasek> actually, I'm not sure that blueprint answers the question
<jdstrand> well, there is stgraber's final comment in 2011-12-13 that I think sums it up
<slangasek> oh, so it does
<slangasek> 'sabit buried though
<kirkland> wow, 92 updates today?  did 11.10 -proposed just get cleaned out today?
<jdstrand> so, aiui, dnsmasq will look at /etc/hosts for name resolution, itself if it is a dhcp server (eg libvirt) and then the other entries in /etc/resolv.conf for forwarders
<slangasek> er?  why would dnsmasq look at /etc/hosts?
<slangasek> that's nss's job
<jdstrand> I'm almost sure it does
<jdstrand> ie, when traveling I hup dnsmasq after making changes to /etc/hosts and can resolve stuff
<slangasek> and no, it doesn't look at the other entries in /etc/resolv.conf; it has its own server list, /var/run/nm-dns-dnsmasq.conf
<slangasek> jdstrand: why would you need to hup *anything* to reflect changes in /etc/hosts?
<jdstrand> slangasek: ah, maybe in this network manager configuration
<jdstrand> huping dnsmasq flushes its cache
<bdmurray> stgraber: bug 917905 might be interesting to look at
<ubottu> Launchpad bug 917905 in netcfg (Ubuntu) "netcfg hang bug in autoconfig.c" [Undecided,Confirmed] https://launchpad.net/bugs/917905
<jdstrand> man dnsmasq: It loads the contents of /etc/hosts so that local hostnames which do  not appear  in  the global DNS can be resolved and also answers DNS queries for DHCP configured hosts.
<slangasek> jdstrand: yes, but what are you doing that /etc/hosts isn't already being used directly via /etc/nsswitch.conf?  Or is this about exporting your /etc/hosts entries to the guests?
<slangasek> hrm
<cjwatson> kirkland: I moved a bunch of stuff to oneiric-updates yesterday
<jdstrand> slangasek: I do it for guests, yes
<mdeslaur> jdstrand: you mean /etc/resolv.conf, not /etc/hosts
<cjwatson> don't think I even cleared the list but there was certainly a lot of it
<slangasek> jdstrand: gotcha
<kirkland> cjwatson: so i noticed ;-)
<slangasek> mdeslaur: no, it really does both :)
<kirkland> cjwatson: thanks
<cjwatson> it was mostly mechanical :)
<cjwatson> apw: bug 921096 might be worth somebody having a look at, since it has upstream attention
<ubottu> Launchpad bug 921096 in linux (Ubuntu) "HPA partition table check does not account for the possibility of a filesystem spanning the entire disk" [Undecided,Confirmed] https://launchpad.net/bugs/921096
<apw> cjwatson, is there some upstream discussion going on do you know ?
<cjwatson> apw: Eric Sandeen got in touch with me about it on IRC
<cjwatson> since he was initially puzzled as to the cause
<cjwatson> I don't think there's any other discussion yet, seeing as that was just in the last few minutes
<jdstrand> I'm still curious about the interplay of the nm dnsmasq and the libvirt dnsmasq and the fact that 192.168.122.1 is listed first and what effect that has on name resoltuion. I don't have time to dig in but am curious if my change makes things better for me
<apw> cjwatson, my memory of the change was it was partition specific, so i suspect it won't handle whole disks without partitions
<jdstrand> if it does, I'll investigate more
<cjwatson> he said he'd see if Fedora might have a similar problem though; it would in principle affect any distro that ever shipped with default libata.ignore_hpa=1
<apw> yeah
<slangasek> stgraber: which design oversights of resolvconf were you intending to correct yet, btw?
<stgraber> slangasek: I think that WI was basically for what you already fixed (using /run, upstart job tweaks)
<slangasek> ok
<slangasek> guess we should DONE it then :)
<stgraber> slangasek: indeed
<stgraber> slangasek: the only thing I saw was broken since I switched to resolvconf on my machines is arkose as /run isn't bind mounted in the container by default, making /etc/resolv.conf point to well, nowhere. But that's a trivial bug to fix in arkose's defaults.
<apw> cjwatson, it is not clear to my mind if it is possible to guess the users intent if the mount the entire drive.  did they mean just the beginning or all of it
<slangasek> stgraber: <nod>
<stgraber> slangasek: I'll try and have a look at dhclient this afternoon see what exactly needs fixing, once that one is done, we should be ready to have resolvconf enabled by default
<slangasek> stgraber: I think the dhclient bit is low-priority, actually, since that code path is not hit in the normal usage
<cjwatson> apw: we can't guess their intent, but if we don't find a partition table on the drive then we could check to see whether there seems to be a filesystem there
<slangasek> (should still be fixed, doesn't need to block resolvconf-by-default)
<cjwatson> in principle, anyway ...
<apw> cjwatson, then we'd need to know how to know how big every filesystem thought its container is ... not very nice
<apw> i know ... lets get grub to do it :)
<stgraber> slangasek: right. Wondering about the exact timing we want for it. Do you think we should ask for more testers on ubuntu-devel before doing the seed change?
<stgraber> slangasek: at the same time I'd like to have it switched on for alpha-2 so we don't have a whole lot of time for additional testing...
<slangasek> stgraber: ironically, with the nm change to dnsmasq resolvconf-by-default is very low-risk for the dekstop because it hardly has to do anything... maybe just poke some server folks to test before flipping the switch?
<stgraber> slangasek: indeed, it's really low-risk on desktop. I'll poke #ubuntu-server and make sure the server team do a quick test of their stuff using it
<cjwatson> apw: can't the filesystem code probe a filesystem and tell you how long it is
<cjwatson> ?
<cjwatson> apw: the reports are of backup disks, btw, there's no reason to assume that they're plugged in at boot ;-)
<apw> cjwatson, they should know how much space they have in them, whether they have a highest block number referenced is less obvious
<cjwatson> hmm
<cjwatson> well, this is Eric's kind of area so might be worth talking to him about it
<hallyn> jodh: http://lkml.org/lkml/2012/1/23/535   So if we have to update /usr/share/initramfs-tools/init and some other places to make sure /dev/ptmx is a symlink to /dev/pts/ptmx and that devpts is mounted with 'ptxmode=666', would that seem acceptable to you?
<apw> cjwatson, most FSs probabally do know as it is quite common to read the first and last block to make sure you have the entire media
<stgraber> slangasek: now as to where we want to put it. Does having it as a recommend of ubuntu-standard sounds good to you?
<apw> cjwatson, where is he talking to you
<cjwatson> apw: /msg
<apw> ahh
<slangasek> stgraber: I was pondering whether it shouldn't be a recommend of those packages which would update /etc/resolv.conf previously (dhcp-client, network-manager)
<apw> cjwatson, we would also not want to do this until you tried to mount the fs either in case you wanted to zap things and become conformant
<slangasek> since it's only needed if you have a dynamic network
<cjwatson> apw: eww, so the bdev might change length in flight?
<apw> well that must happen now when hpa drops during partition discovery ... but yes not ideal
<stgraber> slangasek: if I remember my seeds correctly, that'd basically make it installed on anything with ubuntu-minimal then
<slangasek> stgraber: does that seem incorrect to you?
<slangasek> cjwatson: ^^ or to you (having resolvconf pulled into ubuntu-minimal)?
<stgraber> slangasek: it's not "wrong" but it'll definitely be annoying to me ;) Most containers on my network run with a template /etc/resolv.conf (pushed by bcfg2, a puppet like tool), these containers only have ubuntu-minimal installed
<stgraber> slangasek: and unfortunately bcfg2 as far as it sounds doesn't quite support removing packages ;)
<slangasek> stgraber: well, let's see then
<slangasek> stgraber: /etc/resolv.conf is turned into a symlink at resolvconf install time; but if you change it back, resolvconf becomes a no-op
<cjwatson> I do tend to think that it should be a recommendation of a real package not a metapackage
<slangasek> stgraber: would that still be inconvenient in your case?
<cjwatson> recommending it from isc-dhcp-client does seem not entirely risk-free though
<cjwatson> recommending it from network-manager seems easy enough
<stgraber> cjwatson: the idea was to have it everywhere, not just desktops, so we need to have somthing on servers pull it too
<slangasek> cjwatson: however, n-m isn't on the server and my intent is that if we're going to do this, we do this across the board
<slangasek> and make it the standard interface for /etc/resolv.conf updates that it always aspired to be
<slangasek> (and own the bugs, if any)
<stgraber> slangasek: indeed, I forgot it properly handles the case where we turn /etc/resolv.conf back into a file (or at least should)
<cjwatson> well, if you want it across the board, then probably recommends of isc-dhcp-client *and* ubuntu-minimal
<stgraber> slangasek: what happens on upgrade though (not that it really matters, my configuration manager would overwrite it again an hour later), do we turn it back into a symlink at upgrade time or just at initial install time?
<slangasek> stgraber: only at install time
<slangasek> cjwatson: well, u-m already depends on isc-dhcp-client, so I guess that's redundant
<stgraber> slangasek: perfect then. No problem having it be a recommends of ubuntu-minimal (or something in ubuntu-minimal if we prefer that).
<cjwatson> slangasek: it is, but do you want it to be the default resolv.conf updater only on systems using DHCP, or on all systems?
<cjwatson> redundancy isn't necessarily bad depending on what the intent is
<slangasek> cjwatson: all systems... but to me it seems that the right way to represent this is as a depends/recommends of the packages that feed the dynamic resolver info
<cjwatson> OK - is there anything other than isc-dhcp-client and network-manager that does that?
<slangasek> bind
 * slangasek searches
<cjwatson> dnsmasq?
 * slangasek swats the 'openresolv' search results out of the way
<stgraber> I don't know if we can trust resolvconf but if we can:
<stgraber> Enhances: isc-dhcp-client, dhcpcd, pump, udhcpc, ppp, ifupdown, network-manager, bind9, dnsmasq, pdnsd, totd, libc6, nscd
<cjwatson> seems like a lot to get right - I think I'd definitely like a metapackage recommendation *in addition* if we want this as the system default
<stgraber> it definitely contains hooks for bind, ifupdown, ppp and dhclient. NM has code to detect and use resolvconf, not sure for the others
<slangasek> "hooks for bind" - it's the other way around; bind's init script calls resolvconf
<slangasek> ultimately these packages should be gone through and have their NIH code for updating resolv.conf shot in favor of a dependency
<slangasek> but yeah, for now I think u-m depending is reasonable
<stgraber> slangasek: depending or recommending?
<slangasek> stgraber: hair-splitting :-)
 * stgraber starts working on the MIR as resolvconf is still in universe
<slangasek> I guess I'd do a Depends
<slangasek> phooey
<slangasek> SpamapS: ../driver/.libs/libmyodbc5.so: undefined reference to `dynstr_append_mem'
<slangasek> this may not actually be your problem though, let's see
<infinity> resolvconf was in universe for pretty solid reasons, way back when... Has it drastically improved in sanity since?
<slangasek> infinity: yes, I took a hatchet to it
<infinity> slangasek: Shiny.
<stgraber> slangasek: bug 921135 hopefully doko will have a few minutes to review ;)
<ubottu> Launchpad bug 921135 in resolvconf (Ubuntu) "[MIR] resolvconf" [Undecided,New] https://launchpad.net/bugs/921135
<slangasek> SpamapS: ok, so these myodbc missing symbols are a change in mysql-5.5; I guess there's a linker script somewhere that's suppressing these symbols from being exported, but they're needed by "external" packages (myodbc)?
<tumbleweed> ScottK: ok, so there's no chance of pypy building on ARM. I can live with that, keeps things simple :)
<ScottK> Not at the moment.  That may change.
<tumbleweed> yeah, long  term we'll want it to
<tumbleweed> JIT for ARM is still under development, anyway
<stgraber> slangasek: hmm, looking at it now, I believe dhclient's behaviour when resolvconf is installed is actually correct
<slangasek> stgraber: in /sbin/dhclient-script itself?
<stgraber> slangasek: /etc/dhcp/dhclient-enter-hooks.d/resolvconf (shipped by resolvconf) defines make_resolv_conf() as basically "return 0", so dhclient won't mess with resolv.conf anymore
<slangasek> oh, interesting
<stgraber> slangasek: then re-defines it to do the right thing
<slangasek> should resolvconf have to do that, though?  or should this be regarded as a bug in isc-dhcp-client?
<stgraber> so asumming the scripts are always sourced, it should work fine
<slangasek> but, well, at that point we can still defer and take it up with the Debian maintainer instead of introducing a delta
<stgraber> well, it seems like resolvconf is in the habit of providing hooks to integrate with name server, dhcp clients, ... so it doesn't seem completely wrong to do it this way
<stgraber> right, all the hooks are sourced and the enter hooks are basically the first thing dhclient-script executes, so that seems good to me
<stgraber> slangasek: btw, just tried booting with all persistent file systems mounted read-only (in my case, only /) and Ubuntu now boots and has network
<stgraber> slangasek: lightdm doesn't start though :)
<slangasek> nice :)
<slangasek> the first part, not the second ;)
<SpamapS> slangasek: myodbc uses private internal API's from mysql.. its *evil*
<slangasek> SpamapS: yes, but it's evil that needs to be buildable :)
<SpamapS> slangasek: so typically it will have a specific version that it is meant to be compiled with
<slangasek> SpamapS: that has certainly not been my experience historically, but it's certainly possible that upstream maintenance has gone to hell
<stgraber> slangasek: rebooting with upstart logging turned on to see how many upstart jobs explode because of the lack of writable filesystem (assuming I can get upstart to dump the logs once I remount / read/write)
<SpamapS> slangasek: upstream being our fine friends at Oracle. ;)
<slangasek> stgraber: fwiw, I do feel strongly that having resolvconf override the code in dhclient-script this way is the wrong way about, but it's not critical to fix right now
<SpamapS> btw, did we all decide it was ok for NetworkManager to own 127.0.0.1:53 ? I can see this being a problem for some people.. running dnsmasq and always pointinga t 127.0.0.1 in /etc/resolv.conf
<stgraber> slangasek: noted :) probably worth opening a bug in Debian, we already have a huge delta on isc-dhcp IRIC so would be nice to have that bit done in Debian instead
<slangasek> SpamapS: I actually had bind installed and running here when I first upgraded to the dnsmasq-enabled NM, and didn't notice any problems; of course bind was here only as a caching nameserver anyway so I subsequently removed it
<SpamapS> slangasek: its really confusing to have to dive down the rabbit hole and find the "real" dns server instead of just looking at /etc/resolv.conf :p
<slangasek> stgraber: huh, yes, we ought to re-sync with Debian on this
<stgraber> slangasek: I believe NM can actually deal with bind too, I think cyphermox showed me some code doing that
<slangasek> SpamapS: yep, I realize - that's mentioned in the blueprint
<stgraber> SpamapS: on a desktop, clicking on "Connection Information" in the NM applet will always give you the right thing
<stgraber> SpamapS: or "nm-tool" from the command line which gives you that + a whole bunch of other potentially useful information
<stgraber> (and yeah, I still run cat /etc/resolv.conf multiple times a week ... will get used to it eventually ...)
<slangasek> SpamapS: anyway, there's no new upstream version of myodbc out; and it may not have worked with 5.5.17 either since we never got that far in the build due to the _r issue
<SpamapS> slangasek: indeed, I think I tried it on Ubuntu and got a similar problem
<slangasek> SpamapS: I suspect that no one build-tested myodbc on Linux, and this happens to work on Windows because of a lack of linker script there
<SpamapS> slangasek: entirely possible it wants an *older* release
<cyphermox> stgraber: correct, NM has code that could allow you to use bind as the caching nameserver
<SpamapS> slangasek: nobody tests anything regarding shared libraries in mysql-land
<SpamapS> that goes back pre-Sun days..
<slangasek> heh, right
<SpamapS> slangasek: we may need to patch it... <sigh>
<slangasek> cyphermox: so what does that code do in light of this dnsmasq setting, if you have bind running?
<slangasek> SpamapS: yep!  do you happen to know where this linker script is hiding?
<cyphermox> SpamapS: if you want to know about the DNS servers from the cli you can sudo cat /run/nm-dns-dnsmasq.conf or nmcli con status id  "whatever the name of your connection is"
<cyphermox> slangasek: it doesn't touch bind, not sure what you mean otherwise?
<slangasek> cyphermox: does it try to *start* dnsmasq?
<cyphermox> slangasek: do you mean what resolvconf or whatnot would do if two caching nameservers are running?
<cyphermox> slangasek: yeah, if the setting is dns=dnsmasq it will try to start it
<slangasek> cyphermox: no, because you *can't* have two caching nameservers running on the same IP
<stgraber> slangasek: I suspect you'd need to manually change the dns line in /etc/NetworkManager/NetworkManager.conf to refer to bind instead of dnsmasq, assuming we actually build that plugin
<cyphermox> obvioulsy.
<slangasek> so does NM do something sensible when :53 is already in use?
<cyphermox> well, there would be an error message in syslog, but for the rest I'll have to check
<slangasek> I think that'd be a good thing to check
<slangasek> cyphermox: btw, I notice that NM is actually pointing dnsmasq at /var/run, not /run :)
<slangasek> (minor issue)
<SpamapS> slangasek: likely deep within the bowels of 5.5's cmake build
<cyphermox> file a bug, I'll fix it, there's already other things in the "queueueue"
<stgraber> slangasek: what'd be sensible for you? using the existing DNS server and hoping it's right, overriding /etc/resolv.conf as NM used to or fail to connect?
<cyphermox> (I mean of things to work on in NM, I'll get to it very soon)
<slangasek> SpamapS: oh... right, cmake :P
<slangasek> cyphermox: bug for which one?
<slangasek> stgraber: #2
<cyphermox> bug for /var/run
<slangasek> well, except not overriding /etc/resolv.conf, but using resolvconf instead :P
<slangasek> cyphermox: I don't actually care about the /var/run enough to file a bug report :)
<cyphermox> slangasek: alright, I'll try to think about it when I next look at the code :)
<ogra_> hmpf, i seem to have lots of themeing issues with the new X
<cyphermox> slangasek: stgraber: ok, looks like it already handles the case where biind or dnsmasq fail to start, and avoids adding 127.0.0.1 to resolvconf then
<stgraber> cyphermox: does it instead add the DNS servers directly to resolvconf?
<cyphermox> stgraber: yup
<stgraber> sounds good then
<cyphermox> wouldn't hurt to test this just in case, but the nameservers only get changed to 127.0.0.1 if the plugin succesfully starts
<jodh> hallyn: as long as it's fully tested of course: plymouth started from initramfs uses ptys...
<nessita> hello everybody! would anyone know when is the next Developer Membership Board meeting? https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda seems outdated (though I can guess the next date, I would like official confirmation :-))
<dobey> also, would a packageset request go to dmb or tech board?
<hallyn> jodh: frankly i haven't yet found where the final /dev/ptmx (at login) comes from.  I create a symlink in initrams's init, and do it again at /etc/init/mount-dev.conf, but i still get a simple device
<slangasek> hallyn: does it not just come from devtmpfs?
<hallyn> jodh: are you on linux-kernel m-l?
<hallyn> slangasek: I rm that one. oh!  maybe udev is doing it
<hallyn> slangasek: well, i rm that one at mounted-dev.conf
<slangasek> hallyn: there is a ptmx add event in /var/log/udev for me, certainly
<hallyn> slangasek: if it were that simple, at least we could fix that in the kernel
<slangasek> and it's listed in /lib/udev/rules.d/50-udev-default.rules
<hallyn> slangasek: yeah i'd forgotten about that.  lemme see if that helps.  thanks
<jodh> hallyn: not currently.
<hallyn> slangasek: jodh: if you want to chime in on the email thread with any concerns, that'd be great :)
<stgraber> dobey: dmb
<hallyn> ok, off to test with udev
<hallyn> oh, no, that one just sets the perms
<cyphermox> nessita: Jan 30th, according to the parent page.
<dobey> stgraber: cool, thanks. can you or someone update the wiki so there's a new agenda for the meeting next monday? :)
<dobey> cyphermox: i think she wants to add her bid for package upload privs to the agenda :)
<cyphermox> oh, I know
<cyphermox> nessita: I think you can just add your name to the agenda, but normally they ask for one full week heads up, and you should send an email to the DMB mailing list
<nessita> cyphermox: yes, I was to send the email, when I couldn't find the agenda for the next meeting. And my next question was is the full-week in advance is a hard requirement :-)
<nessita> anyways, I have no problem  waiting for the meeting after that
<stgraber> nessita, dobey: done. Btw, we usually ask for a week notice when asking for upload rights but 6 days notice is probably fine too, not like we have much on the agenda to prepare for :)
<nessita> I don't wanna go against the policies
<nessita> stgraber: I have no problem waiting for the meeting after that, really
<cyphermox> nessita: fwiw, I've been asked to abide by that rule in the past ;)
<nessita> cyphermox: and makes sense :-)
<stgraber> nessita: we have nothing to discuss at our next meeting so far, and didn't have anything at our last meeting, so feel free to add your item to the agenda :)
<nessita> stgraber: sounds great, thanks
<stgraber> nessita: also make sure to e-mail your request to devel-permissions@lists.ubuntu.com
<nessita> stgraber: doing that atm, but I was trying to find the agenda for the next meeting to add my name to it
<nessita> stgraber: my confusion is that the MOTU app that is in https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda was also for the meeting of the 16th, so perhaps the page is not ready for the next meeting?
<stgraber> nessita: it's been there for a few months
<nessita> ok, so I'll leave it there and add my name
<nessita> thanks!
<stgraber> nessita: it's an application we decided to move to e-mail (that's what the "(E)" means) but never got an answer back from the applicant
<stgraber> nessita: we'll probably drop it from the agenda soon as it's just confusing people
<nessita> heh
 * nessita was confused indeed
<stgraber> slangasek: ok, so lightdm not starting in read-only mode is cause by X needing /tmp and /var/log/ to be writable to start, then lightdm fails if /var/lib/lightdm isn't writable. Once these two are worked around, I still can't open a session :)
<stgraber> slangasek: now the only error in network logs cause by / being read only is /etc/dhcp/dhclient-enter-hooks.d/samba (samba-common) trying to write to /etc/samba/dhcp.conf.new an then moving that file to dhcp.conf. This failure might prevent other dhclient or ifupdown scripts from running (now that ifupdown checks for return codes)
<stgraber> udev-finish is also complaining it can't move /dev/.udev.log to /var/log/udev but that was to be expected and doesn't prevent anything from running (at least that I could find)
<infinity> stgraber: Surely, it can't be a goal to have a read-only /tmp and /var? :P
<infinity> stgraber: Or is this a case of "even if your FS explodes, it would be nice to be able to start a session"?
<stgraber> infinity: yeah, it was mostly out of curiosity that I was checking how much of the desktop would start without a writable /
<stgraber> infinity: the /etc stuff seems more problematic though as someone could definitely have /etc read-only on purpose
<stgraber> infinity: our default partitioning scheme is to have a big / + a swap partition, / is mounted with errors=remount-ro so in case of some filesystem weirdness, I now know that someone will get a nice black screen on vt7 with nothing starting (on a desktop, on a server you should at least get to vt1 and a login prompt)
<infinity> stgraber: Things writing to /etc are definitely bad.  But yeah, I agree that it would be nice if / was remounted ro, your system should still kinda work.
<TheMuso> doko: One has already been written and it has been approved. Just a minute, and I'l get you a bug number.
<TheMuso> doko: bug 849729
<ubottu> Launchpad bug 849729 in java-atk-wrapper (Ubuntu) "[MIR] java-atk-wrapper" [Undecided,Fix released] https://launchpad.net/bugs/849729
<doko> TheMuso, oh, thanks. then I just need to re-promote.
<hallyn> smoser: it's showing the ipxe rom name.  does it actually say it's trying to boot from pxe?  Does it look the same as when you do -boot n?
<slangasek> stgraber: samba-common - definitely a bug, I think it may have been reported in Debian already
<stgraber> slangasek: can't find one in the Debian BTS after a quick look (but the list is pretty long so might have missed it)
<slangasek> yeah... :)
<slangasek> yeah, I don't see it either
<semiosis> soren: ping?
<slangasek> so maybe it wasn't a bug; maybe it was a piece of fuzz in my brain
<maxb> Anyone around who knows how apt-xapian-index and software-center integrate? I have update-apt-xapian-index throwing warnings about unconfigured python loggers in software-center code.
<soren> semiosis: wazzup?
<semiosis> soren: i resubmitted the merge request, just wondering if you might have a chance to check it out.
<semiosis> soren: deleted the first try because i messed up my bzr branch... learning bzr the hard way :)
<soren> semiosis: Sorry, no, haven't gotten around to it yet. Do you have the link handy?
<semiosis> yes
<semiosis> soren: https://code.launchpad.net/~semiosis/ubuntu/precise/glusterfs/fix-for-876648/+merge/88603
<soren> semiosis: You know.. I think SpamapS will do a much better job reviewing that upstart job than I.
<soren> SpamapS: Would you mind taking a look?
<semiosis> soren: ok he actually helped point me in the right direction when i was starting to work on it
<semiosis> soren: was thinking about getting back in touch with him
<semiosis> SpamapS: do you remember?  http://irclogs.ubuntu.com/2011/04/12/%23upstart.txt
 * SpamapS takes a look
<SpamapS> +start on (local-filesystems and net-device-up IFACE=lo and net-device-up IFACE=eth0) or (mounting TYPE=glusterfs)
<SpamapS> semiosis: that is really convoluted.
<semiosis> :D
<slangasek> more to the point, it probably doesn't work reliably
<semiosis> the goal is to have it start once local filesystems are mounted and the network interfaces are up... or when trying to mount a glusterfs type filesystem.
<SpamapS> semiosis: do local gluster mounts *need* glusterd running?
<SpamapS> semiosis: you may need a separate "glusterd-wait" job to achieve that
<semiosis> SpamapS: if the gluster mount tries to mount from localhost, then yes.  that is, if the machine is a server & a client
<semiosis> SpamapS: if the gluster mount is mounting from a remote host, then no glusterd is required at all.
<semiosis> SpamapS: and likewise a server with glusterd need not have any client mounts itself
<semiosis> SpamapS: perhaps it is convoluted but people have been using it with success.  i distribute it in a ppa
<cjwatson> that kind of (foo and bar) or baz trick is known to trigger upstart bugs
<cjwatson> it has to either be split up or simplified
<cjwatson> https://bugs.launchpad.net/upstart/+bug/447654
<ubottu> Ubuntu bug 447654 in upstart "init: using 'and' operators can cause hangs" [High,Triaged]
<SpamapS> in this case, all of those are "signals", and not waited on..
<cjwatson> oh, hm, that's "foo and (bar or baz)"
<cjwatson> you might get away withit
<cjwatson> *with it
<SpamapS> but the assumption that eth0 is the one needed for glusterd to work is incorrect
<semiosis> cjwatson: it works pretty well actually
<semiosis> SpamapS: fair point
<SpamapS> semiosis: in 11.10 and later, you can replace all of that with 'runlevel [2345]'
<cjwatson> semiosis: with an event-driven system you can't rely just on empirical evidence, you have to analyse it too
<SpamapS> semiosis: but the mounting bit.. will cause you issues
<SpamapS> semiosis: I know it works for others, however, there is a race condition there, albeit subtle
<cjwatson> I don't think you hit the standard "and" operator problem, at least
<SpamapS> semiosis: if you are mid 'starting' and the mounting event arrives, upstart will not block the 'mounting' event, because it only blocks when the goal is changed from stop->start...
<SpamapS> semiosis: and mounting can arrive at *any* time because it happens any time net-device-up is emitted
<semiosis> SpamapS: ok if it gets a mounting event & tries to start but is already started, whats the problem?
<SpamapS> semiosis: so, in order to make that work, you need to use a second job and 'start wait-for-state'
<SpamapS> semiosis: its already *starting* .. but it may take a few seconds, and meanwhile your mount fails because its not ready yet
<cjwatson> SpamapS: all of those are signals> is that true for local-filesystems and mounting?
<SpamapS> semiosis: you need to wait until glusterd is running. Which.. btw.. sleep 1.. is also fairly trivial and may not work in all cases.
<SpamapS> cjwatson: all of the and'd conditions are signals (including local-filesystems). Mounting is or'd.. but carries its own problems.
 * SpamapS is trying to find the bug which talks about not blocking unless you change the goal..
<cjwatson> SpamapS: maybe I'm reading the mountall code wrongly but I thought it blocked
<SpamapS> cjwatson: mounting definitely blocks
<SpamapS> cjwatson: but that one is in an or.. so it should be ok.
<semiosis> fyi, bug is described here: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/876648
<ubottu> Ubuntu bug 876648 in glusterfs (Ubuntu) "Unable to mount local glusterfs volume at boot" [Undecided,New]
<SpamapS> cjwatson: or.. is that also a problem when used in conjunction with and?
<cjwatson> ah, you're right, local-filesystems doesn't block
 * SpamapS has never thought of this scenario actually
<cjwatson> no, I think it's OK here
<cjwatson> the problematic scenario would be: (1) net-device-up IFACE=lo arrives; (2) net-device-up IFACE=eth0 arrives; (3) mounting TYPE=glusterfs arrives; (4) this job starts; (5) local-filesystems arrives and blocks because the other conditions are now no longer met
<cjwatson> or similarly for the other elements of the conjunction
<cjwatson> still, I would avoid this construction because it's fragile and all too easy to innocently edit into a state where it can cause boot hangs
<SpamapS> Yeah, and truly, those other constraints are all met by 'runlevel [2345]' in 11.10 and later
<SpamapS> the mounting case can be handed by a wait-for-state job
<semiosis> ok i will try the runlevel [2345] solution that wasn't around when i wrote this
<semiosis> SpamapS: can you point me to an example of a wait-for-state job?
<SpamapS> http://paste.ubuntu.com/815874/
<SpamapS> that should do it
<semiosis> oooh nice
<SpamapS> actually
<SpamapS> http://paste.ubuntu.com/815875/
<SpamapS> WAITER is required
 * SpamapS really should write a man page for wait-for-state :-P
<semiosis> +1 for man pages
<SpamapS> semiosis: now, about that sleep 1
<SpamapS> semiosis: ideally glusterd would fork after it is ready to listen, though I am guessing it doesn't do that
<semiosis> actually i gave it the no-fork option because i thought thats how upstart liked it.
<semiosis> i guess expect-fork is the way to go now?
<SpamapS> well that is fine, but that means your post-start needs to be careful and do more than sleep 1
<SpamapS> semiosis: expect fork is the way to go when your daemon behaves the way it expects.
<semiosis> ok sounds good, i'll go the expect fork route
<SpamapS> semiosis: glusterd is probably like the 50% or so of daemons that daemonize *before* setting up their listen socket... and so can't be used that way.
<semiosis> heh, we'll see
<SpamapS> semiosis: its not easy to see w/o reading the code
<semiosis> ok
 * SpamapS realizes that it would actually be fairly easy to write a program which determines the behavior via ptrace
<semiosis> SpamapS: thanks for all your help, once again
<SpamapS> semiosis: this will get simpler once jodh finishes the 'expect exit' work
<semiosis> i'd really like to get this right and merged in to the glusterfs-server package for precise
<SpamapS> semiosis: I'm planning on writing a MIR for gluster, so I'd love for you to get that in too. :)
<jono> RAOF, hey
<RAOF> jono: Yo!
<jono> RAOF, someone posted a comment on my blog outlining some troubles with X in 12.04
<jono> would you mind replying to help him get some useful data to you guys?
<semiosis> SpamapS: MIR?
<jono> he is at http://www.jonobacon.org/2012/01/24/hud-call-for-testers/#comment-419950714
<SpamapS> semiosis: Main Inclusion Request
<semiosis> w00t!
<jono> RAOF, thanks in advance if you can take a look at this
<SpamapS> semiosis: apparently some people want it to be officially supported. :)
<RAOF> Urgh.  Because blog post comments are the *perfect* venue for bug reports :)
<semiosis> SpamapS: i'm one of them... been contributing patches to debian to keep the latest available
<semiosis> SpamapS: this upstart job is the finishing touch imho
<SpamapS> semiosis: we'll also be putting CEPH in main, so it will be a distributed block/file store shoot-out for 12.04 users. :)
<semiosis> yay
<SpamapS> semiosis: if expect fork is not appropriate, is there a command you can run to sort of 'ping' glusterd to know that it is up?
<jono> RAOF, well, I know, but I asked him for a bug
<RAOF> Yeah, I see.
<semiosis> SpamapS: not totally sure
<jono> I figured you might be able to help him to get some data into a bug report that might be useful
 * jono hugs RAOF
<semiosis> SpamapS: if it is bound to tcp/24007 that's probably enough
<RAOF> jono: Replied.
<jono> thanks RAOF
<jono> :-)
<stgraber> nicHul8
<semiosis> oops
<stgraber> yeah...
<stgraber> good thing that was a VM login prompt ;)
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso, robert_ancell, pitti
<poolie> RAOF, hi,
<RAOF> poolie: Hi
<poolie> hi, i've just put x-staging back on, and external monitors are no better
<poolie> specifically, they don't crash, but they don't set the right resolution
<poolie> i guess that may be more of a kernel thing not x
<poolie> is there anything i can do to help debug or solve it?
<poolie> i guess maybe run kernel tip
<RAOF> poolie: x-staging is now in Precise, so will no longer be helpful.  It's entirely possible that you're seeing a kernel problem; the kernel mainline builds of drm-intel-next are the things which will be most interesting there.
<poolie> is there a ppa-ish for that?
<poolie> nm i have http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/
<RAOF> Oh, sorry.  Missed your question.
<RAOF> Yeah, that's it.
#ubuntu-devel 2012-01-25
<ScottK> cyphermox: I'm looking at bluez and trying to figure out why it depends on python-gobject?  AFAICT from grepping the code python-gobject is only used in the tests.  I'm asking because it's pulling python-gobject and another stack of things into the kubuntu seeds.
<cyphermox> ScottK: ok. well, I'll be happy to drop it if it's possible. I'm about to do an upload; I can check now
<ScottK> cyphermox: Thanks.
<cyphermox> ah, I see
<cyphermox> ScottK: I kind of like having these "tests" around; though maybe they'd be better suited in a separate package
<ScottK> That or ship the tests, but drop python-gobject to Suggests.
<ScottK> I think for tests that aren't automatically run, that's reasonable.
<cyphermox> ScottK: those things really attempt to give you information about bluetooth devices more than actually being tests, but I think that's reasonable still
<cyphermox> ScottK: did you file a bug about this?
<ScottK> cyphermox: No.
<cyphermox> ok
<psusi> isn't dh_translations supposed to remove the .mo files from the package and put them in the langpack isntead?
<micahg> cyphermox: it would have been nice to document reason for the drop to suggests in bluez in a bug or in the changelog itself
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell, pitti
<slangasek> psusi: no, that's the job of pkgbinarymangler
<psusi> slangasek, ohh... so when I build the binary package, the .mo files are still there, but when it hits the archive, they get stripped?
<slangasek> psusi: pkgbinarymangler is installed in the build chroots on the Ubuntu buildds, and strips them out as part of the package build
<psusi> I see
<slangasek> (by diverting/wrapping the commands used for building, making it transparent to the actual package)
<micahg> you can do the same locally with a properly configured sbuild (and probably pbuilder as well)
<benonsoftware> Hello
<pitti> Good morning
<pitti> cjwatson: waiting for micahg; I asked yesterday, not sure about the current status
<pitti> ev: StacktraceAddressSignature is many to one
<pitti> ev: in practice, I found that > 90% of our bugs in the db just have one address signature, but some have 5, and one had 10
<pitti> SpamapS: ah, yes
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: robert_ancell
<poolie> raof, hi, current drm-intel-next has basically the same problems
<RAOF> poolie: :(
<poolie> i guess i could try digging in to that part of the kernel
<RAOF> Now, I've dropped context.  What was the problem, again?  Was it âVT-d makes my system crazyslow?â
<poolie> ah, that actually is adequately worked around by turning it off
<poolie> i guess ideally the kernel would cope if it was turned on
<poolie> no, this is bug 745112 (sorry for not quoting that) - external monitors can't reliably be set above about 1280x1024
<ubottu> Launchpad bug 745112 in linux (Ubuntu) "[arrandale] desktop is messed up with external monitors (x86_64)" [Critical,Triaged] https://launchpad.net/bugs/745112
<RAOF> poolie: Urgh.  Time to upstream that bug.
<pitti> Riddell, ScottK: do you know why calligra-libs Conflicts: koffice-libs? that seems to be the main reason for the uninstallability (http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html)
<tjaalton> poolie: would you mind opening a bugreport either on the kernel or fdo bugzilla? I can walk you through it
<poolie> tjaalton, sure, just tell me where
<poolie> can lp send it upstream or should i create it manually?
<tjaalton> don't think it can
<tjaalton> but, you can comment on the upstream bug via lp
<tjaalton> so if you don't have an account on fdo I could open the bug and you could interact with it via lp
<poolie> i think i have one - should it be there or on the kernel?
<tjaalton> either works, but I think the fdo one is used more
<tjaalton> hang on
<tjaalton> of course bugs.fd.o seems to be down atm
<dholbach> good morning
<tjaalton> poolie: https://bugs.freedesktop.org/enter_bug.cgi?product=xorg then select Driver/intel
<tjaalton> poolie: actually, scratch that
<poolie> (otp)
<poolie> but let me know
<tjaalton> poolie: as it's likely a bug in the drm driver, use https://bugs.freedesktop.org/enter_bug.cgi?product=DRI and DRM/Intel
<tjaalton> poolie: here's a list of what information upstream would like on the bugreport http://intellinuxgraphics.org/how_to_report_bug.html
<brendand> what is the meaning of putting {python:Depends} in a control file rather than just 'python'?
<geser> it's a variable that gets replaced with the correct dependency on python itself
<tjaalton> shouldn't /usr/include/$triplet/ be in the default search path for headers?
<tjaalton> because I get this http://pastebin.com/JN3JpCUU
<tjaalton> the headers are in /usr/include/$triplet/bits/*
<tjaalton> well, nothing under /usr/include/$triplet/ is found
<poolie> tjaalton, that rings a bell with me, but i think it's meant to be set outside of gcc...
<poolie> can't remember where
<tjaalton> yeah googling revealed similar issues
<tjaalton> fixed by patching the source..
<geser> tjaalton: if I read the MultiArch pages correctly then /usr/include isn't multi-arched yet
<tjaalton> geser: ref?
<geser> tjaalton: http://wiki.debian.org/Multiarch/Implementation, section "What does the end result look like?"
<geser> and two points above that header: "If your -dev package contains headers which vary across architectures then it cannot be marked as Multi-Arch: same until a policy decision is made about architecture-dependant headers and the toolchain is updated."
<tjaalton> hmm ok
<poolie> tjaalton, ok https://bugs.freedesktop.org/show_bug.cgi?id=45211
<ubottu> Freedesktop bug 45211 in DRM/Intel "[arrandale] blank external monitor at high resolution" [Normal,New: ]
<tjaalton> poolie: excellent, thanks
<poolie> do you know what project i use in lp to attach to that bug?
<tjaalton> just did that
<tjaalton> there was already xf86-video-intel "opened" for it
<poolie> huh
<poolie> just mentioning it is enough?
<tjaalton> with the upstream url
<tjaalton> but it's there now
<tjaalton> doko_: is it a mistake or intentional that bits/ etc are under /usr/include/$triplet/bits etc?
<poolie> tjaalton, surely they are platform-specific, by definition?
<tjaalton> libc6-dev-i386 installs into /usr/include/sys/?
<tjaalton> on amd64
<tjaalton> i'm just confused by all this .)
<tjaalton> :)
<tjaalton> point is that /usr/include/features.h can't find it's headers
<geser> looking at packages.ubuntu.com, libc6-dev installs some files to /usr/include/$triplet since oneiric
<tjaalton> and the fix can't be to install the i386 dev package
<tjaalton> geser: right
<poolie> tjaalton, i know it looks like it installs there, but it's actually redirected
<poolie> (may not actually be a 'redirect')
<poolie> lrwxrwxrwx 1 root 29 Jan 24 04:03 /usr/include/sys/sem.h -> ../x86_64-linux-gnu/sys/sem.h
<tjaalton> hm? which package created the symlink then?
<poolie> sorry i can't remember where this is configured
<poolie> but, there is a thing, that allows two packages to both try to install to the same place, and they get moved
<poolie> and that's what's happening here
<poolie> anyhow, that's it for me, good night
<tjaalton> ok, it's gcc-multilib
<tjaalton> installed it and now I have a symlink from /usr/include/bits -> $triplet/bits
<cjwatson> poolie: sounds like a diversion
<tjaalton> doko_: nevermind :)
<poolie> that's the word i was trying to remember, thanks
<tjaalton> another mesa build then..
<ev> pitti: cheers
<Riddell> pitti: koffice is due to be deleted but I'm busy on the KDE SC release this week so I stopped working on koffice/calligra for immediately
<pitti> Riddell: ah, ok; so will calligra grow some extra transitional packages for this then?
<pitti> Riddell: thanks for the heads-up
<Riddell> pitti: I need to look at having a smooth upgrade, maybe some transitional packages will be appropriate (it's a bit political since koffice still exists as a project)
<seb128> kirkland, hey
<seb128> Jan 25 10:57:26 localhost kernel: [ 3201.475561] Valid eCryptfs headers not foun
<seb128> d in file header region or xattr region
<seb128> Jan 25 10:57:26 localhost kernel: [ 3201.475564] Either the lower file is not in
<seb128>  a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrou
<seb128> gh mode is not enabled; returning -EIO
<seb128> kirkland, is that a known issue? those are filing my kern.log
<pitti> kirkland: ^ FWIW, I get these all the time
<pitti> I don't notice anything which actually goes wrong
<doko_> tjaalton, wondering why you would need gcc-multilib at all ...
<tjaalton> doko_: I don't have /usr/include/{sys,bits} etc without it, dunno if it's a bug then
<doko_> tjaalton, it should not be a bug, because it should fine the bits in /usr/include/<multiarch>
<doko_> what is the error?
<tjaalton> doko_: http://pastebin.com/JN3JpCUU
<doko_> tjaalton, and makedepend is aware of multiarch?
<doko_> $ dpkg -S predefs.h
<doko_> libc6-dev: /usr/include/x86_64-linux-gnu/bits/predefs.h
<tjaalton> well, rest of mesa is
<tjaalton> dunno if it needs a hammer
<doko_> tjaalton, does mesa build 32bit binaries on amd64?
<tjaalton> doko_: not that I know of
<doko_> hmm
<tjaalton> but that doesn't mean much ;)
<tjaalton> it builds a bunch of libs, that's pretty much it
<pitti> mesa doesn't build a lib32something binary package anyway
<Daviey> Mez: it goes back a long time it eems
<Daviey> err
<ScottK> pitti: No.  Riddell did all the Calligra stuff, although I'm not surprised they aren't co-installable - this is similar to the OOo -> LO migration.
<Riddell> s/did/is still in the process of/ since it's paused while I do KDE SC 4.8 :)
<tsdgeos> they are not coinstallable
<tsdgeos> at least not in the .mo level
<tsdgeos> they clash like crazy
<lamont> Daviey: bind9 uploaded to debian, will sync it once sid has it
<Daviey> lamont: that is great!  Thanks for the fast response.  When you sync, can you close the ubuntu bug aswell? :)
<lamont> will do so
<cjwatson> infinity: [adconrad] Co-ordinate the porting of ocaml-opt to armhf: TODO
<cjwatson> infinity: I think this is more or less done now; doko enabled it in ocaml itself a while back, and I got irritated by the stack of failures and went through and reuploaded nearly everything relevant earlier this week
<ogra_> heh
<cjwatson> infinity: I only just noticed the work item
<cjwatson> infinity: the only thing left is (a) coq and its reverse-build-deps (coq fails to build for some reason); (b) doing another sanity-comparison of cmx entries between armel and armhf Contents files, after LP next sees fit to regenerate them
<cjwatson> it was mostly just a matter of rebuilding everything in dependency order
<doko> hmm, did I leave something half-finished?
<cjwatson> doko: findlib had to be rebuilt to be aware that ocamlopt was available, and then everything that might have been able to build with ocamlopt had to be rebuilt
<cjwatson> doko: I only worked that out by inspection of build failures and some pondering though
<dhana013> HI guys How to build deb package from source please guide me. guys
<cjwatson> debuild
<mvo> silly(?) question - it seems now we have sudo and admin groups. but users are not auto-transitioned, is that correct?
<cjwatson> correct
<pitti> mvo: we went through some effort to teach packages to get along with either
<cjwatson> it's not entirely clear what we should ultimately do there but at the moment apps need to check both
<cjwatson> auto-transitioning in u-m might be worthwhile; is there not a bug about that, actually?
<mvo> aptdaemon uses root.admin currently for sources.list entries with private tokens
<mvo> so either that needs to become root.sudo
<pitti> jockey has the same problem, but I could get around that as it's only a first-time install matter there, so I switched to sudo
 * mvo scratches head
<dhana013> HI guys How to build deb package from source please guide me. guys
<ogra_> debuild
<ogra_> as colin said above already
<ogra_> read zthe manpage
<ogra_> *the
<geser> !packaging guide
<ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports
<dhana013> How to automate package creation from source.
<micahg> pitti: hoping to finish the testing today, lucid is almost done, but I figure that we don't want to break upgrades
<pitti> micahg: good morning; ah, thanks!
<TREllis> I'm trying to multi-arch libidl0, it depends on cpp, which means the i386 package still won't install on amd64, needs cpp:i386... does that mean cpp needs multi-arching?
<Riddell> dhana013: you can't
<Riddell> dhana013: or maybe I should answer "pay canonical" :)
<ogra_> you can, if you know how to set up a buildd :)
<ogra_> or how to write PPA build reciepes
<Riddell> yeah once you do the initial packaging there's ways to automate updates
<tumbleweed> generally speaking, automating packaging doesn't work so well. But automated updates (like the daily build recipes) do work rather well
<Riddell> and ways to help the initial packaging too but that's never anything like 100% automatic
<ogra_> alien ftw !
 * ogra_ hides :)
<Riddell> :)
<cjwatson> TREllis: Multi-Arch: foreign on cpp *might* be the right thing if the version from another architecture will work; but I would have thought that cpp has architecture-specific defaults in it ...
<cjwatson> TREllis: we don't have provision for real multi-arch of binaries yet
<tumbleweed> lamont/buildd admins: I just gave back a timed out pypy build and it went back to the same builder, yellow. If you can kill it, I can try giving it back when yellow is otherwise occupied
<lamont> tumbleweed: that's not actually solving the problem
<tumbleweed> no, I'm interested in ideas for that :)
<tumbleweed> I thought my memory check was sufficient, but it appears not to be
<TREllis> cjwatson: right I thought that might be the case. That's one of my blockers at the moment whilst trying to fix a chain of multi-arch dependancies
<lamont> if that was the build that was driving yellow into the ground with it's memory footprint, I suspect that it needs to be less agressive in its total vm footprint, probably a test suite of the "hey, this'll fit, I think" variety
<lamont> yellow has 4GB of RAM and 4.5GB of swap
<tumbleweed> it's checking MemTotal in meminfo
<lamont> and it had 42% swap free a while ago
<tumbleweed> ok, I didn't do any emprical checking on amd64, but I did check that it would build on i386 with 1.7G RAM (everything else mlocked)
<tumbleweed> and the check doubles that for 64bit
<tumbleweed> lamont: I'll try an allocation test in the next upload
<ev> WebKitGtk+ is still lacking access to DOM events in 1.7.  Does anyone know what the consensus approach for communicating with a WebKit WebView is? Please say something other than "multiplexing the title element." :)
<ev> in GI, that is
<dhana013> Riddell, then How to create custom distro based on ubuntu but not dependent with ubuntu repo.
<dhana013> How to create custom distro based on ubuntu, but not dependent with ubuntu repo.
<Riddell> dhana013: umm that's a different question, see https://help.ubuntu.com/community/LiveCDCustomization or "pay canonical"
<ogra_> could you please stop repeating yourself all the time ?
<ogra_> asking once is sufficient
<dhana013> I can't pay canonical I want to make source build to my custom distro is possible, all packages i can convert to my distro it's possible
<dobey> ev: are those bits in the .gir but just have introspectable="0" on them?
<ev> dobey: correct
<ev> I just found this from sil, which leads me to believe that document.title is still the only game in town http://askubuntu.com/a/97682/46
<dobey> ev: i think the answer is you need to fix webkit so the APIs are introspectable. i am not sure what that entails exactly, beyond tweaks to the documentation in the C code.
<ev> I'd love to have the time for that
<dobey> yeah
 * dobey also wants the vapi to get updated for vala
<dholbach> can somebody please massage my mail through u-d-a?
<Riddell> how do I make sed apply to only the first line of a file?
<pitti> Riddell: sed '1 s/foo/bar/'
<pitti> Riddell: you can specify a line number or a range
<pitti> e. g. 1,3 <cmd> for the first three lines
<Riddell> cool thanks pitti
<slangasek> cnd: your latest update of x11proto-input-dev has reverted multiarch support; is there a vcs repo somewhere that you're maintaining this package?  (Not listed in debian/control)
<dholbach> thanks for moderating it through
 * smb silently curses about non-obvious server disconnects
<smb> slangasek, While looking at bug 607039 again, I realized that this actually has been fixed by an update to 662711. I assume the best action for the former is to mark it a duplicate of the latter bug then. Probably bug 117957  can either be closed marked duplicate, too. Not sure which as that has a debian bug reference.
<ubottu> Launchpad bug 607039 in nfs-utils (Ubuntu) "NFS4 automount using replicated servers doesn't work" [Medium,New] https://launchpad.net/bugs/607039
<ubottu> Launchpad bug 117957 in nfs-utils (Ubuntu) "Need to modprobe nfs module before mounting nfs4 export" [Medium,Triaged] https://launchpad.net/bugs/117957
<barry> ScottK: the pyqt4 stuff looks good.  i'm just doing a chroot install check and if that pans out, i'll do the upload.  thanks for fixing this.  i'm also going to look at sync'ing pydbus today
<smb> slangasek, Do you think that change is worth a backport to Oneiric, still?
<ScottK> barry: Cool.
<slangasek> smb: hmm, don't we still need to fix the module aliasing somewhere here?
<slangasek> I wouldn't expect idmapd to magically autoload the nfs kernel module, but maybe I'm mistaken
<smb> slangasek, Well I'd have something for that, but practically when you did always modprobe nfs with idmap and always start idmapo now as the bug fix
<smb> +    should always be started automatically, because we can no longer assume
<smb> +    that a mount of type 'nfs' in /etc/fstab is not nfs4.  This also lets
<smb> +    things work by default with nfs4 autofs.  LP: #662711
<slangasek> smb: oh, because the idmap job explicitly modprobes nfs, right
<smb> yup
<slangasek> I'm not sure if we should backport that to oneiric.  what's your opinion?
<smb> slangasek, So fwiw nfs module always is already loaded when you try to mount, which makes the modprobe for nfs4 just silently fail but not necessary.
<smb> slangasek, Hm, the problem is there too. And the fact that lead to modprobe it in idmapd upstart would be as valid there.
<smb> (not that ANY reporter gets back to you as soon as they now a manual workaround)
<zyga> has anyone seen voidspace around here lately?
<smb> slangasek, Guess given that, we could just cover our eyes and wait until someone shouts at us
<slangasek> smb: :)  well, I think if you want to do the work to backport the change, it would be an acceptable SRU - so it's up to you whether you think it's worth the effort
<barry> ScottK: a few lintian warnings on the resulting .debs, but i think i can fix them: http://pastebin.ubuntu.com/816583/
<ScottK> barry: Sounds good.
<ScottK> Thanks.
<smb> slangasek, Given it is some work to touch the package, and that one can easily work around it by having the modprobe.d alias (as documented in the first bug), I think it is maybe not worth doing as long someone really persists. At least it is ok in Precise.
<slangasek> ok
<smb> slangasek, So what would you think I should do with that very old bug report #117957. Also mark it a duplicate of the other. Or just close it fixed with a note to the other bug?
<slangasek> smb: I wouldn't mark it as a duplicate, but I think it can be closed
<slangasek> (with a note)
<smb> slangasek, ok, will do
<hrw> make[2]: Entering directory `/tmp/gcc/test/eglibc-2.13'
<hrw> /usr/bin/install -c -m 644 include/limits.h /usr/include/limits.h
<hrw> does someone had similar attempt during (cross) build of eglibc?
<mpt> kirkland`, hi, is now a good time to talk settings?
<infinity> cjwatson: Ahh, didn't realise it was just findlib having a hissy fit.  Thanks for the catch.
<barry> ScottK: i'm giving up on the executable-not-elf-or-script lintian warnings in python-qt4-doc.  dh_fixperms does seem to be getting called, but it doesn't remove the x bit from the files (even when called manually with other cli options).  i did fix the strip problem though, so...
<ScottK> bdmurray: You just added a rls-mgr-p-tracking tag to Bug 651294.  That bug is fixed, so I don't think that's what we want.
<ubottu> Launchpad bug 651294 in xorg-server (Ubuntu Maverick) "X crash on KDM logout (still - yes, really)" [High,Confirmed] https://launchpad.net/bugs/651294
<ScottK> barry: I think the strip problem was the most important.
<barry> ScottK: agred
<bdmurray> ScottK: the latest comments indicate otherwise
<bdmurray> ScottK: feel free to remove it though
<ScottK> bdmurray: No.  That bug was fixed.  Someone is having similar symptoms.  They should file a new bug and not try to go back and comment on ones that are already closed.
<bdmurray> ScottK: well you could say as much in the bug report
<ScottK> I did.
<ScottK> bdmurray: ~ one minute before you added the tag,
<ScottK> So it's just a timing issue.
<ScottK> I'll remove it.
<ScottK> Done.  Thaks.
<ScottK> Thanks even.
<ScottK> barry: Nice job on the dbus stuff, dbus-python and python-qt4.  Thanks.
<barry> ScottK: thanks.  i'm looking at pulling dbus-python 1.0.0 from debian now.  it'll be nice to resync
<barry> debian experimental
<ScottK> Right.  Once it's built on experimental for i386, I can push the python-qt4 changes back to experimental and we can sync from there.
<barry> +1
<ScottK> barry: I mashed retry on armhf.  It was a very odd error like the builder vanished out from under it.
<barry> maybe it ran out of memory?
<shadeslayer> cjwatson: got a sec?
<wolter> has anybody tried to build totem-3.3.4 ?
<seb128> wolter, it's in https://launchpad.net/~gnome3-team/+archive/gnome3
<seb128> wolter, that's an unstable ppa though so not really recommended for use if you want a stable system (but totem 3.3 is unstable as well so you probably don't aim at something working solid)
<wolter> seb128, yeah I just want to try it to test if  a bug I reported is fixed already
<wolter> Thanks for the guidance!
<seb128> wolter, yw
<seb128> could somebody score the builds of indicator-appmenu and unity in https://launchpad.net/~unity-team/+archive/hud/+packages ?
<seb128> they need a rebuild for the precise indicator transition
<seb128> doko, pitti, cjwatson: ^
<seb128> jono, kenvandine: ^ should fix things
<infinity> seb128: I can do that.
<seb128> infinity, thanks
<jono> seb128, what should fix things?
<infinity> seb128: Err, but those are clearly PPA versions.
<jono> I disconnected
<seb128> jono, <seb128>  could somebody score the builds of indicator-appmenu and unity in https://launchpad.net/~unity-team/+archive/hud/+packages ?
<jono> thanks seb128
<seb128> infinity, yeah, and we need those rebuild to happen earlier rather than later ;-)
<seb128> libindicator got an soname update in precise
 * micahg is waiting for the unity amd64 archive build :)
<seb128> but ppa builder lag half a day behind
<stgraber> seb128: done
<infinity> stgraber: Ahh, you'd be the reason I OOPSed. :P
 * micahg would suggest blaming launchpad instead :)
<stgraber> infinity: well, no, the reason would be a bug in LP, but I certainly contributed to having that bug affect you
<stgraber> infinity: so LP doesn't like you trying to rescore something that's already building? :)
<infinity> stgraber: Well, yes.  It's a bug that when you try to rescore a build that's in the BUILDING state, it OOPSes instead of giving you a friendly message.  But you helped me trigger it.  Better? :P
<tumbleweed> I've got some local users breathing down my neck because appmenu is exporting UBUNTU_MENUPROXY in non-unity desktop environments. Is there any particular reason that this isn't done in the unity session only? (The related bugs all seem to be marked as duplicates of bug 787465 which is specific to gnome-terminal and fixed, according to jbicha)
<ubottu> Launchpad bug 787465 in gnome-terminal (Ubuntu) "View->Show MenuBar isn't working in 11.04 and later in gnome-terminal" [Undecided,Confirmed] https://launchpad.net/bugs/787465
<stgraber> infinity: yep, that sounds good, now go file a bug since you were the one who got the ooops ;)
<stgraber> tumbleweed: isn't the appmenu stuff working with KDE too?
<tumbleweed> stgraber: neither KDE or unity
<tumbleweed> awesome, fluxbox, etc
<shadeslayer> cjwatson: nvm :)
<micahg> cyphermox: I wouldn't bother much with libchamplain-0.8 or clutter-gtk-0.10, both need to be removed as soon as their rdeps are migrated
<cyphermox> micahg: i know but in the meantime it works. this was a simple patch to grab from upstream and massage to apply
<micahg> cyphermox: you could have just as easily merged claws-mail-extras-plugin or whatever and got it removed :), it's all good though
 * micahg treats versioned source package names suspiciously
<bdmurray> @pilot in
 * micahg kicks ubottu
<cyphermox> micahg: if you're not touching claws-mail-extras-plugin though I'll do the merge now :)
<micahg> cyphermox: well, was going to leave it for barry on his +1 mission next month, so I'm not touching it, but if he doesn't mind, have at it :)
<cyphermox> ah, I don't especially mind waiting either. Just picking at anything I can fix, really
<micahg> pino has an RC bug (needs sync) and needs a g_thread_init patch to build
<micahg> or update libav-extra to 4:0.8ubuntu1 (bug 921765) as I mentioned in --motu
<ubottu> Launchpad bug 921765 in libav-extra (Ubuntu) "libav-extra needs rebuild to >=4:0.8 so dev packages can be installed" [Undecided,New] https://launchpad.net/bugs/921765
<micahg> cyphermox: ^^
<cyphermox> micahg: thx
<slangasek> cjwatson, TREllis: cpp is already marked Multi-Arch: allowed; packages that need to be able to depend on a foreign-arch version of cpp need to be updated to depend on cpp:any
<slangasek> TREllis: because it's not correct to say that a cpp package of any architecture will satisfy the dependency on cpp for a package of any other architecture, because of the per-arch defaults cjwatson mentions.
<SpamapS> Ugh 20 hours for PPA builds
<micahg> SpamapS: powerpc is worse :)
<SpamapS> micahg: yeah, because in the end, you get a powerpc package. ;)
<Daviey> is listadmin broken for everyone else on precise?
<Daviey> The spam headers changed?
<micahg> cyphermox: oh, it looks like siretart is about to upload a new libav-extra to Debian
<cyphermox> micahg: ok
<cyphermox> I'm fighting pino
<micahg> oh, it's more than g_thread_init? (was the first failure I got)
<SpamapS> is there a simple way to run sbuild and say "build this .dsc, with these extra .debs installed" ?
<SpamapS> do I just have to build a new source chroot and stick them in there?
<micahg> SpamapS: try --add-depends
<SpamapS> micahg: how is that going to get my .debs into the chroot?
<SpamapS> micahg: these are .debs that are not available yet
<micahg> SpamapS: oh, I thought you meant dependencies :)
<siretart> micahg: uploading right now
<micahg> SpamapS: dpkg in --pre-build-commands from a bindmount dir in the chroot might work
<micahg> siretart: thanks
<SpamapS> micahg: yeah that seems doable but eeeeevil ;)
<micahg> SpamapS: actually, you might need --chroot-setup-commands, not sure
<micahg> SpamapS: I can tell you how to add a PPA to a single run :)
<cjwatson> --add-depends (assuming I didn't miss somebody already saying that while I was disconnected)
<cyphermox> micahg: I'm not getting a failure for g_thread_init at all, but getting all these vala errors (and now that I've fixed them I'm doing to one error in the generated C code
<micahg> cyphermox: are you building 0.2.11+dfsg-1?
<cyphermox> yes, just found out I didn't properly make sure I was building with valac-0.10, not valac-0.14
<SpamapS> micahg: dpkg -i seems to be working
<SpamapS> micahg: or rather --chroot-setup-commands w/ the dpkg -i
<micahg> cool, good to know :)
<SpamapS> of course.. its complicated because I *also* need apt-get -yf install
<SpamapS> but, seems to progress from there
<micahg> SpamapS: just chain another --chroot-setup-commands afterwards
<SpamapS> mciyeah it worked ok
<SpamapS> tab complete fail
<micahg> siretart: are you uploading to Ubuntu also or do you want me to?
<siretart> micahg: I'm about to crash, if you want, feel free, otherwise I'll do it tomorrow
<micahg> ok, I'll take care of it, thanks
<siretart> micahg: in case you're doing it, I've pushed my branches to git.debian.org. IME, merging the git branches makes it pretty easy
<micahg> siretart: it's just a sync, so I was going to grab from incoming
<siretart> micahg: oh, right. that makes it indeed even easier.
<siretart> good night!
<micahg> good night siretart
<jbicha> tumbleweed: are you still having problems w/ the ubuntu menuproxy on precise?
<mhall119> who gets to send emails to ubuntu-devel without having to be moderated?
<cjwatson> anyone in the whitelist
<cjwatson> maybe that's tautologous :)
<mhall119> is that something that I should be on, or is it normal for most people to go through moderation?
<Daviey> I ust flushe dthe list from 145 moderated mails down to about 40.
<cjwatson> the charter is "posting moderated for non-developers"
<mhall119> ok
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-December/000227.html
<mhall119> so it's not that I've screwed up my subscription to it
<cjwatson> in practice we generally add sensible people to the whitelist when we're bored of accepting their posts
<cjwatson> (this is written up in https://wiki.ubuntu.com/UbuntuDevelModeration)
<mhall119> cool, thanks
<mhall119> me and mailing lists have a love/hate relationship, so I wasn't sure if I was doing something wrong
<Daviey> mhall119: your mail should now have gone through.
<mhall119> thanks Daviey
<micahg> cjwatson: is there a sane way to sync from incoming?
<kirkland> slangasek: would you have any ideas or comment to add to https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/920609 ?
<ubottu> Ubuntu bug 920609 in ecryptfs-utils (Ubuntu) "likewise-open users with migrated home directory wonât decrypt automatically" [Low,Confirmed]
 * micahg just realized there's no source.changes file to sign
<tumbleweed> jbicha: no, it looks like tha tissue is sorted now. The question is why we are loading menu-proxy at all when not in unity. And TBH, without big smoking bugs to point at, it doesn't concern me that much
<cjwatson> micahg: syncpackage --no-lp, or wait
 * micahg supposes he can wait 4 hours
<micahg> cjwatson: when's the next CD run?
<cjwatson> takes a bit longer than that before gina gets round to the import IME
<cjwatson> depends on the CD
<micahg> ubuntu studio (libav-extra is out of sync)
<cjwatson> 17 18 * * *
<cjwatson> (UTC)
<micahg> ah, so it was already
<cjwatson> so 20 and a bit hours
<micahg> ok, I"ll just wait then
<slangasek> kirkland: do you know what the pam stack looks like in this case?
<ScottK> infinity: Any ideas on https://launchpad.net/ubuntu/+source/python-qt4/4.9-2ubuntu2/+build/3121207 - seems it's arm* specific.
<janimo> ScottK, I remember a similar error from last year, I wonder if some patches got dropped
<janimo> "unsupported function argument type - provide %MethodCode and a valid C++ signature"
<janimo> ScottK, one of the sip tools needed a patch
<janimo> ScottK, it was related to qreal/double IIRC but in a much more subtle way than in plain C++ code
<kirkland> slangasek: no idea
<kirkland> slangasek: sorry, but I've been asked this from time to time
<slangasek> kirkland: ok; have asked on the bug for a copy of the pam stack in question
<slangasek> kirkland: since it would be non-trivial to reproduce without a likewise-backed domain login, I'm not going to try to reproduce it blindly :)
<kirkland> slangasek: nope, me neither
<kirkland> slangasek: and yes, good question
#ubuntu-devel 2012-01-26
<ScottK> janimo: It's the first time the dbus/dbus.cpp code's been built on arm* in a python3 environment.  Might be something with that or barry's patch then.  Thaks.
<slangasek> cjwatson: any chance you could push your debhelper merge to the bzr branch?  importer doesn't seem to be grabbing it
<cjwatson> slangasek: hm, I didn't do it in bzr as it happens; is a local import-dsc likely to fare any better than the importer?
<slangasek> not sure :/
<slangasek> cjwatson: actually, import-dsc fails for native packages
<slangasek> so no
<slangasek> (also, not sure if it does sane things with branches for merges)
<cjwatson> I guess I can try to reconstruct something
<cjwatson> actually, I think it would be bad to try - lp:debian/sid/debhelper is out of date so if I tried it would result in a lack of merge metadata
<slangasek> right
<slangasek> so maybe we should just get the importer kicked
<cjwatson> I think so
<psusi> cjwatson, is it time to poke you about my parted/dmraid/multipath-tools merges yet? ;)
<Jatinder> Good Morning Everyone !!!
<Jatinder> How to remove complete GUI of Ubuntu 11.10?
<Jatinder> I tried this : sudo apt-get remove ubuntu-desktop
<Jatinder> but system replied that it will remove only 16kb of the data
<slangasek> Jatinder: this is not a support channel; please see #ubuntu
<Jatinder> Sir I am trying to work on derived ubuntu so thought its developers' talk
<Jatinder> so got into here
<slangasek> well, that's not a development question :)
<Jatinder> okay. i'll  leave then
<smoser> slangasek, ping
<slangasek> smoser: hey there
<smoser> https://cloud-images.ubuntu.com/server/precise/current/
<smoser> we sign SHA1SUMS and MD5SUMS with some key on nectarine
 * slangasek nods
<smoser> but that public key (as far as I know) is not distributed anywhere.
<slangasek> really? hmm
<smoser> $ gpg --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg --verify SHA256SUMS.gpg SHA256SUMS
<smoser> gpg: Signature made Tue 24 Jan 2012 09:36:24 PM EST using RSA key ID 7DB87C81
<smoser> gpg: Can't check signature: public key not found
<smoser> the same command works for me with Release and Release.gpg (from archive.ubuntu.com)
<slangasek> smoser: no, it is distributed via the public keyrings
<smoser> so what am i doing wrong?
<slangasek> smoser: e.g., gpg --keyserver pgp.mit.edu --recv-keys 7DB87C81
<slangasek> it could probably do with some more public signatures beside my own, btw :)
<slangasek> (from other people who have access to nectarine and can verify the authenticity of the key)
<smoser> hm.. yes, i suppose it could
<smoser> this obviosly exposes my grave gpg ignorance
<smoser> but how would someone come up with that key ?
<slangasek> smoser: your gpg output shows the key ID and reports that you don't have it locally; the next step if you want it is the gpg --recv-keys command to fetch it from the public keyservers
<smoser> ah. duh.
<slangasek> if you are intending to sign the pgp key yourself, please make sure to verify that the full pgp fingerprint of the key you download locally matches the fingerprint of the public key on nectarine :)
<dhana013>  Hi guys. I want make custom distro. It's based on ubuntu derivative. but not depends on ubuntu,  How to compile source code from scratch , make deb packages, please guide me.
<RAOF> dhana013: This seems unlikely to be on-topic for #ubuntu-devel.  dpkg-buildpackage is the standard way to go from source-packageâbinary package, though.
<dhana013> RAOF: Any guide how to proceed, with my creating custom destro.
<RAOF> dhana013: Um, don't?  I don't think there's a particularly good reason to.
<dhana013> RAOF: New distro creation in am my project
<dholbach> good morning
<pitti> slangasek, cjwatson: has there been any discussion about kmod by any chance? i. e. "we want this for precise" or "we want to keep it out of precise"?
<pitti> apw: ^
<pitti> newer udev versions now need it, they use libkmod instead of calling modprobe a thousand times
<pitti> which might also give a nice speedup
<pitti> but of course it's still fairly new; Fedora and Arch linux use it, but I haven't tested it yet (it's in Debian experimental)
<pitti> is that something I should have a look at, or do we want to stay at udev 175 and just backport some fixes?
<pitti> we could at least sync it into universe, so that it's easier to test and play with
<broder> i'm +1 for having it somewhere in the archive - i have some applications i'd like to use it for
<pitti> ah, we can't sync it directly, it builds a transitional module-init-tools
<pitti> I figure we do not want to do this right away, unless we decide to actually do replace m-i-t
<pitti> and that requires some merging of ubuntu changes
<pitti> so we could do a ~ubuntu1 upload without the transitional package into universe
<pitti> (~ so that we retain the option to sync)
<apw> pitti, yeah not heard anything but if thats the way upstream is rattling we should have it somewhere to play with
<pitti> apw: apparently it's the m-i-t successor
<apw> pitti, folling the libudev model i assume "do it yourself" functionality
<pitti> apw: I don't understand, I'm afraid
<apw> library to be directly involved in module loading, find out what is and isn't and load them so you don't need to fork all the time
<pitti> apw: yes, udev went into that direction
<pitti> instead of calling blkid, modprobe, and whatnot, it now uses their libraries
<pitti> I'd like to at least get the libbklid change, but I could cherry-pick that even without kmod
<pitti> if I look at http://people.canonical.com/~pitti/bootcharts/daniel-oneiric-20111027.png, the blkid and modprobe calls take no small percentage of the boot
<pitti> path_id, iput_id, usb_id are now also builtin
<apw> pitti, it would be nice to have this thing for testing and no mistake
<pitti> apw: the debian package does some transitional changes: http://packages.qa.debian.org/k/kmod/news/20120110T221730Z.html
<pitti> apw: so I think we need to apply some work to be able to install it for testing and then revert back to m-i-t
<apw> pitti, yeah, why could this not have happened a month ago ...
<pitti> apw: well, kmod existed back then, but it was still pretty young
<pitti> apw: anyway, I don't think it's particularly urgent
<apw> heh "cannot login to my machine as any user since kmod replaced module-init-tools" ... suspect there will be some fun :)
<pitti> we can probably get away with reverting the kmod bits and update to 179, or cherry-pick other changes
<pitti> I mainly wondered if there was any dicussion about that already which I wasn't aware of
<pitti> if not, I think we should stay at m-i-t for precise
<apw> pitti, no seems we missed out on the whole thing by missing plumbers
<apw> pitti, do if this dicussion is correct kmod will have a kmod binary which is the  official interface which can also be symlinked to modprobe etc.  so it should be testable at least
<pitti> yes, that's what I understood
<apw> pitti, what is daniel, 16 blkids seem like a lot
<pitti> apw: daniel is my Dell Mini 10v
<pitti> i. e. my boot speed test machine
<pitti> this was a pristine oneiric install in default partitioning mode
<apw> pitti, and how many partitions does it have
<pitti> apw: it's running over all ram/loop/whatnot devices, too
<apw> oh gawd
<pitti> apw: I think two: system and swap
<pitti> apw: you just don't see those on faster boxes as they are quicker than bootchart's measuring interval
<apw> no wonder you want to use it
<pitti> which is what makes this Abacus so nice for boot speed testing :)
<apw> yeah i wish my abacus hadn't broken, i must source another
<pitti> it's not that easy to revert, but I'll see what I can do
<Daviey> lynxman: around/
<Daviey> ?
<lynxman> Daviey: kinda, but not much, will be around in full force tomorrow
<Daviey> lynxman: k
<james_w> cjwatson, hi, were you planning a wadllib upload with your py3 changes?
<cjwatson> james_w: I was waiting for somebody with permissions to do so (i.e. not me) to do an upstream release
<cjwatson> james_w: barry has a work item to shepherd that all into the archive
<cjwatson> maybe poke the lp people if they haven't already been poked?
<james_w> cjwatson, ok, thanks
<quadrispro> ScottK, waiting for a signal from you and I'll push audiofile to precise
 * quadrispro reminds: "At my signal, unleash hell"
<slangasek> pitti: I don't know that there's been discussion of kmod; I've assumed our answer is we don't want it due to the newness
<pitti> slangasek: ok, thanks; that's all I wanted to know; so I'll check if the kmod bits can be reverted in udev and we upgrade to 179, or I'll try to cherrypick the interesting bits
<pitti> the latter won't be any easier, so I'll try the former first
<slangasek> are there good reasons to upgrade to 179, even?
<pitti> slangasek: the biggest change is replacing the external blkid, path_id, input_id etc. calls (and also modprobe, with libkmod) with internal libraries
<pitti> slangasek: if you look at a bootchart like http://people.canonical.com/~pitti/bootcharts/daniel-oneiric-20111027.png (mini 10), that'll should speed it up quite nicely
<pitti> slangasek: and then the usual set of keymap quirks, but these are easily backported
<pitti> there's also some bug fixes, but nothing major AFAIK
<slangasek> pitti: aren't we doing ok right now with boot speed target?  not sure it makes sense to me to change udev just for this... also, has anyone run tests to show the speed improvement is actually significant?
<pitti> slangasek: no, as we don't yet have an udev version with this
<pitti> we can't build > 175 right now
<pitti> slangasek: well, I wouldn't call it 'ok', but the speed regressions in natty/oneiric are certainly not udev's fault
<pitti> (in the sense that it didn't get worse)
<pitti> it's relatively low-hanging fruit
<stokachu_> pitti, ping
<pitti> stokachu_: hello
<stokachu_> pitti, hey there :) was curious about LP#860765, was there any particular reason it was set to wont fix for natty?
<pitti> stokachu_: it's not a high-priority bug, and natty has been out long enough for it to not matter any more
<pitti> if someone wants to prepare an SRU, it'd be alright, but there is little to be gained
<TREllis> slangasek: thanks for the cpp:any tip - works. Lintian doesn't like it, guess that's lintian bug tho
<apw> pitti, would you be able to tickle the linux-ti-omap4 through for me
<cjwatson> mvo: so I'm trying auto-upgrade-tester again, this time with apt-cacher-ng set up so that it doesn't spend eons re-downloading stuff
<pitti> apw: ah, sure; already looked this morning, but the armel builds were still missing for both that and linux
<cjwatson> mvo: however it fails on the apt-clone file from bug 917173 because apt-clone wasn't in lucid
<ubottu> Launchpad bug 917173 in update-manager (Ubuntu Precise) "lucid -> precise upgrade failed: Resolver failed to calculate the upgrade - dpkg-dev held back" [High,Confirmed] https://launchpad.net/bugs/917173
<cjwatson> mvo: do you know any way around this?
<apw> pitti, thanks, i think linux is still lacking powerpc
<pitti> apw: yep; omap4 done
<apw> pitti, thanks a lot
<mvo> cjwatson: jibel put it into a PPA afaik, jibel - if so, could you please tell colin what ppa that is?
<slangasek> pitti: so the reason I'm pushing back a bit on udev 179 is that I don't think it's a slam dunk to take a new upstream version of udev; we spent about half a cycle chasing regressions in oneiric due to udev behavior changes, and still have one we haven't closed the gap on.  So I'm really not sure that fruit feels "low-hanging" to me
<ScottK> Riddell: re python-qt4: That's the first time it's been built against Qt 4.8 on arm*, but it built before that with 4.7.4.  The function with the error isn't a new one, so I'm inclined to blame Qt 4.8.  sip: QPainterPathStroker::setDashPattern() unsupported function argument type - provide %MethodCode and a valid C++ signature - Thoughts?
<cjwatson> mvo: how do I force auto-upgrade-tester to use that?
<ScottK> Oops.  Wrong channel.
<jibel> mvo, I didn't, sorry.
<barry> ScottK: python-qt4 on arm is giving us headaches
<ScottK> barry: Yeah.  Riddell and I are discussing on #kubuntu-devel.  Feel free to join.
<mvo> jibel: oh, sorry then, I misremembered
<mvo> cjwatson: so if there is a apt-clone in a PPA then you can do:
<mvo> +AddRepo=local_testing.list
<mvo> +AddRepoUpgradeImmediately=true
<mvo> to [NonInteractive] (to e.g. profile/server-amd64/DistUpgrade.cfg)
<mvo> and the file "local_testing.list" would contain something like deb http://ppa.launchpad.net/mvo/apt-precise/ubuntu oneiric main
<mvo> cjwatson: there is even a branch for the backport https://code.launchpad.net/~mvo/apt-clone/lucid-backport but apparently I did not upload it into a ppa :/
<cjwatson> do you think you could, if you already have that?
<mvo> cjwatson: sure
<cjwatson> mvo: do I need to do anything special if I'm testing e.g. DistUpgrade.cfg changes?
<mvo> cjwatson: anything special when using a apt-clone file? I'm not sure, its pretty new (the integration) and jibel did those bits, IIRC its just a matter of pointing to the right apt-clone file and I guess a bit of hackery to ensure that the ppa with the apt-clone is actually in the sources.list
<cjwatson> well, I mean inserting a different DistUpgrade.cfg file and seeing what would have happened to the upgrade if it had been done with that ...
<cjwatson> (DistUpgrade.cfg doesn't seem to be in the apt-clone file anyway)
<mvo> cjwatson: if you simply modify the one in the profile directory that should have the desired effect, e.g. if you want to test with a additional "KeepInstalledPkgs=" line you can just add it and it will "win" over the default value from the upgrader
<mvo> https://launchpad.net/~mvo/+archive/apt-clone-lucid - but it neeeds to build first
<cjwatson> oh, the profile directory, right
<cjwatson> mvo: does it inherit from DistUpgrade.cfg.lucid on the fly or something?
<cjwatson> sorry for asking so many questions, just finding it really hard to get going on this
<mvo> cjwatson: it should inherit, yes (unless there is a bug somewhere)
<mvo> cjwatson: no worries about the questions, I know its a tricky piece :/
<cjwatson> OK
<cjwatson> the last time I played with this I couldn't make it pick up code changes to DistUpgrade (not .cfg), and found that rather baffling
<cjwatson> I expect I'll give that another go ...
<mvo> cjwatson: ohhh
<mvo> cjwatson: please set "UseUpgraderFromBzr=false" to "true" in [NonInteractive]
<mvo> cjwatson: in AutoUpgradeTester/profile/defaults.cfg.d/defaults.cfg
<mvo> cjwatson: or in your individual profile
<cjwatson> ah!
<mvo> cjwatson: otherwise it uses the version of the upgrader code from the archive
<cjwatson> marvellous, thank you
<mvo> yw
<pitti> barry: dbus-python (1.0.0-1) UNRELEASED; urgency=low
<pitti> o_O
<barry> pitti: it's basically what we had in 0.84.0-2ubuntu3 anyway ;)
<pitti> barry: I mean, was this uploaded prematurely?
<barry> pitti: sync'd from experimental, but i think it's safe
<pitti> oh, http://packages.qa.debian.org/d/dbus-python/news/20120124T214728Z.html has the same problem
<pitti> barry: I mean "UNRELEASED" as target; it shoudl certainly be "experimental" or "unstable"
<pitti> anyway, just looked odd
<barry> pitti: yeah, it does, and probably should.  i'll drop a message to simon about it, but i debdiff'd the .debs and tested in a chroot.  all seemed okay, modulo http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657488
<ubottu> Debian bug 657488 in dbus-python "dbus-python: A few packaging anomolies in the -dbg packages" [Normal,Open]
<pitti> barry: ok, thanks
<barry> pitti: thanks
<ericbee> can anyone point me to some documentation about creating applets for the systray?
<cjwatson> The following packages have unmet dependencies.
<cjwatson>   apt-clone: Depends: python-argparse but it is not installable
<cjwatson>              Recommends: dpkg-repack but it is not installable
<cjwatson> mvo: ^-
<cjwatson> (from your PPA)
<SpamapS> Could someone offer some guidance on how this needs to be fixed:
<SpamapS> https://launchpadlibrarian.net/90939944/buildlog_ubuntu-precise-amd64.gearmand_0.27-1_FAILEDTOBUILD.txt.gz
<SpamapS> Looks like an ABI bump is needed upstream..
<cjwatson> SpamapS: using the syntax for filtered C++ symbols files rather than raw ones would be a good start
<cjwatson> SpamapS: but C++ symbols are difficult; there's a thread on debian-devel about them at the moment ...
<cjwatson> you might just find those symbols are inlined on some architectures or something
<mvo> cjwatson: meh, this sounds like universe is not enabled (which is the default). you will have to tweak it and add "Components=main,restricted,universe" to the AutoupgradeTester/profile/defaults.cfg.d/defaults.cfg or the individual profile
<mvo> cjwatson: the easier option is to start the image manually (its in /var/cache/auto-upgrade-tester/test-image.$name.lucid and add it manually there
<mvo> cjwatson: probably a quicker solution
<cjwatson> mvo: oh right
 * mvo is away for a bit
<mpt> mvo, hi, what do I need to know before doing this? "[mpt] Invite people to port release-upgrader to aptdaemon"
<mpt> d'oh
<manish> where is federico?
<manish> sorry, wrong channel :)
<kenvandine> anyone around that can re-score a ppa build?  indicator-appmenu in the unity-team/hud ppa has a pretty critical fix and it is estimating 20 hours
<kenvandine> infinity or stgraber ^^
<stgraber> kenvandine: url?
<infinity> kenvandine: Done
<kenvandine> thanks!
<bryceh> @pilot in
<slangasek> jibel: hi, should I see the effects of your job rearranging on https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/ ?  I still see all red at the top level
<smoser> can i get someone to approve dbus-python's new 'python-dbus-dev' at https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text=
<slangasek> jibel: oh n/m, you said "published to the public instance on the next run" :)
<jibel> slangasek, the jobs are still running/queued
<slangasek> jibel: ack - sorry for reading with my manager glasses on
<smoser> it is depends of python-dbus with is depended on by a lot of things and is currently not installable
<jibel> slangasek, np
<slangasek> smoser: looking
<slangasek> smoser: python-dbus depends on python-dbus-dev, though?  That's surely broken
<smoser> changelog says
<smoser> make python-dbus depend on python-dbus-dev for now, to preserve istorical functionality (but packages which use it, like PyQt, should  switch to depending on it explicitly)
<smoser> so it was by design
<slangasek> ah, so it's a package splitting
<slangasek> ok
<slangasek> jibel: oh, also - did you catch my note that the prompting for service restart on glibc upgrade on server installs is by design and shouldn't be counted as a test failure?
<slangasek> smoser: accepted
<smoser> gracias
<jibel> slangasek, yes, I'll add the prompt to the whitelist.
<smoser> slangasek, how fast does that take affect? every 1/2 hour?
<cjwatson> smoser: should start publishing in one minute and finish in about half an hour from now
<smoser> thank you cjwatson
<bryceh> @pilot in
<arges> bryce, hello patch pilot. have a patch that needs reviewing. this is my first one so i probably have it all wrong
<arges> bryce, tried to follow the directions in the wiki. its a patch to fix https://bugs.launchpad.net/ubuntu/+source/rhythmbox/+bug/885502.
<ubottu> Ubuntu bug 885502 in rhythmbox (Ubuntu) "Rhythmbox crash with SIGSEGV (Segmentation fault) when trying to use mp3 player" [Medium,In progress]
<slangasek> smoser: every half hour, yes
<smoser> its in now
<slangasek> jibel: oh, is that whitelist somewhere I could see it?  (Mostly out of curiosity)
<smoser> my build is going
<slangasek> smoser: yay
<stgraber> slangasek: trying to refresh ubuntu-meta, I'm getting "Skipping package resolvconf (package not in debootstrap)". Do you know what needs to happen for germinate to be happy and add it to -minimal?
<stgraber> slangasek: <cjwatson> It probably means that the package isn't Priority: required/important yet.  An archive admin who isn't in the pub can fix that based on priority-mismatches output.
<stgraber> slangasek: priority-mismatches says it should be moved from optional to important
<hallyn> jdstrand: this is getting ridiculous.  I ran 'make check' in netcf in a precise chroot on hardy.  Pass.
<Daviey> doko: Hey, had a chance to look at bug 914160 ?
<ubottu> Launchpad bug 914160 in openvswitch (Ubuntu) "[MIR] openvswitch" [Medium,New] https://launchpad.net/bugs/914160
<infinity> hallyn: So, it's not the kernel version either? :/
<hallyn> infinity: (GAH!) so it seems...
<infinity> hallyn: Did you try it in that configuration, but with sbuild?
<hallyn> infinity: so i'm at a loss
<infinity> Not that I'd expect sbuild's FD buggery to behave differently on a hardy kernel, but...
<hallyn> no, i don't know how to do that
<hallyn> debootstrap wouldn't do precise.  that's hwy i scp'd over a precise chroot
<infinity> debootstrap is an arch:all package with no deps, you can install the precise version on hardy.
<hallyn> install precise version of debootstrap?  just 'dpkg -i' it?
<infinity> https://launchpad.net/ubuntu/+source/debootstrap/1.0.38/+build/2945367/+files/debootstrap_1.0.38_all.deb
<infinity> Yeah.
<hallyn> all right lemme try, thanks
<hallyn> lack of aufs and ext4 is really annoying
<hallyn> infinity: build... successful
<hallyn> and with that, i'm pulling 'make check' from the build
<infinity> hallyn: Wasn't it only one test that was failing?  Surely you can disable that one.
<infinity> hallyn: test-debian, or whatever it was.
<hallyn> infinity: all the other tests are just gnulib tests.  and one of those (test-float) actually fails on powerpc
<hallyn> that is, there is only one test supplied by netcf itself
<infinity> Oh.
<infinity> Special.
<hallyn> infinity: is there any way to get a shell in an *exact* replica of buildd env?
<htorque> hi all! on ask ubuntu someone asked when btrfs-tools will see an update. is there anything else than bug 894456 i can tell that user?
<ubottu> Launchpad bug 894456 in btrfs-tools (Ubuntu) "Old version of btrfs-tools in ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/894456
<micahg> htorque: needs a merge from Debian
<infinity> hallyn: Well, you can download the buildd chroots from launchpad.
<hallyn> oh?
<htorque> micahg: is that planned for precise (or is it a case of "someone needs to do it")?
<infinity> hallyn: https://api.launchpad.net/1.0/ubuntu/precise/armhf/ for example.
<infinity> hallyn: (replace armhf with the arch you want)
<hallyn> infinity: thanks.
<infinity> hallyn: That said, I tried reproducing it in a buildd chroot, and got nowhere.
<micahg> htorque: someone needs to do it, cjwatson touched it last, I don't know if he's interested in doing it though
<htorque> micahg: ok, thanks for the info! :-)
<slangasek> jcastro: who has access to delete pages from help.ubuntu.com?
<stgraber> slangasek: can you override the priority of resolvconf to important? that needs to happen before I can upload a new ubuntu-meta
<jibel> slangasek, that will be quick, the list empty.
<jibel> the code of the debconf test is there http://bazaar.launchpad.net/~ubuntu-core-dev/update-manager/main/view/head:/AutoUpgradeTester/post_upgrade_tests/debconf_test.py
<hallyn> infinity: you say the netcf 'make check' passed when you ran it in the buildd chroot right?
<slangasek> jibel: heh, ok :)
<slangasek> stgraber: yes, looking
<slangasek> stgraber: done
<stgraber> slangasek: thanks
<micahg> I'm guessing pitti isn't around anymore at this hour
<micahg> stgraber: I think you forgot to set DEBEMAIL :)
<stgraber> micahg: yeah, I just noticed in -changes ;)
<stgraber> micahg: should have checked the output of that script a bit more carefully
<stgraber> micahg: will make a note to fix the changelog entry next time I upload it... (and fixed that chroot to have a decent environment)
<Laney> ah I heard about this 'root' fellow somewhere
<ajmitch> pretty dangerous person, I heard
<stgraber> ;)
<pp7> root is a badass!
#ubuntu-devel 2012-01-27
<slangasek> jibel: hmm, https://jenkins.qa.ubuntu.com/view/Precise%20Upgrade%20Testing%20Dashboard/ shows no updates?
<stgraber> slangasek: doh, daily builds are breaking because of resolvconf :(
<stgraber> slangasek: if I interpret the log correctly, live-build is trying to copy something to /etc/resolv.conf at a time where it's a dangling symlink
<slangasek> stgraber: hmm
<slangasek> stgraber: are you looking into it?
<stgraber> slangasek: not really, I've people over at the moment, just got e-mail notifications for Edubuntu build failures on my phone. I can have a look at it possibly later today (in 3-4 hours) otherwise it'll have to wait till tomorrow
<stgraber> I'm not familiar with what live-build try to do exactly, my guess is that it wants to copy the builder's resolv.conf when building the livefs which could be done by first removing /etc/resolv.conf, then copying it and making sure to turn it back into a symlink at the end of the build
<slangasek> stgraber: ok; I'll have a look, but it's going to be a couple hours for me as well
<stgraber> slangasek: just found a few minutes to hack around what looks like a potential fix: http://paste.ubuntu.com/818363/
<stgraber> I think that should work but I wouldn't mind someone reviewing (even better if someone can actually test)
<infinity> hallyn: It passed for me back when this first came up, yeah.
<slangasek> stgraber: looks sane to me (reviewed, not tested)
<stgraber> slangasek: k. I'm going to assume it can't get worse than what we have currently anyway, uploading now
<stgraber> slangasek: do you know if updating live-build on the builders need some manual action or if it's always using whatever is in the archive?
<slangasek> stgraber: it's supposed to be automatic
<stgraber> slangasek: ok, uploaded. Hopefully most of the other livefs will build with the new version. IIRC Edubuntu is one of the first livefs to build, the others build much later.
<stgraber> pitti: Would be nice if you could trigger manual rebuilds of what failed when you're around (at least Edubuntu, maybe some others). thanks
<infinity> stgraber: The live chroots are upgraded as the first step in a build, no need to worry about intervention.
<infinity> stgraber: (The exception to that rule being if you update BuildLiveCD from livecd-rootfs, because it lives outside the chroot)
<stgraber> infinity: ah right, that was the one I was thinking about. Last time I had to poke at the LiveFS builders was to add an LTSP chroot to the Edubuntu DVDs (which needed some copying of stuff outside the chroot)
<timothyja> Hi guys can someone tell me how I can get the latest gtk+3 ubuntu source?
<hyperair> apt-get source gtk+3.0
<timothyja> I mean from bzr
<hyperair> oh
<timothyja> the current list sources here: https://code.launchpad.net/ubuntu/+source/gtk+3.0
 * hyperair shrugs
<hyperair> how about lp:ubuntu/gtk+3.0?
<timothyja> the current trunk is old
 * hyperair shrugs
<hyperair> i don't use bzr personally
<timothyja> I've wasted many hours compiling old code, the oneiric code is old also
<hyperair> define old.
<ajmitch> https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk3
<timothyja> it seems to have only been updated to 3.1.8
<hyperair> hmm
<ajmitch> 'apt-cache showsrc gtk+3.0' shows that branch as the one to use, with changes made to it 7 hours ago
<hyperair> weird, isn't lp:ubuntu/$pkg supposed to automatically update itself?
<ajmitch> hyperair: only if that's the branch used, somehow some teams set it differently
 * hyperair sighs
<ajmitch> which leads to issues like this where you have to look up the branch from the source package record
<hyperair> debcheckout ftw.
<hyperair> imo we should just ditch bzr and go git.
<hyperair> but that's probably not going to happen.
<ajmitch> yeah,  good luck with that :)
<hyperair> :)
<timothyja> ok so that the precise version thanks
<timothyja> any idea where I can get the oneiric branch?
<RAOF> lp:ubuntu/oneiric/gtk+3.0?  That *should* work, if all the infrastructure is working right.
<ajmitch> RAOF: should, but gtk+3.0 is one of the failures on the package importer status page
<RAOF> Ah.  Boo.
<timothyja> nar its old
<timothyja> ok looks like I'll have to use the source package for now, thanks guys
<pitti> Good morning
<pitti> micahg: I'm here now
<RAOF> Morning pitti!
<ajmitch> hi pitti
<pitti> micahg: ah, so time to copy over all langpacks as well now
<pitti> micahg: ... or not; the tracking bug has the firefox task closed, but I don't see it in -updates
<ScottK> pitti: There are a couple of KDE lang packs hung up in component mismatches: kde-l10n-fa/vi.  It'd be nice if you couple promote them.
<ScottK> Thanks and good night.
<pitti> ScottK: sure; seems they were NEWed wrongly
<pitti> ScottK: good night!
<pitti> I also do the binary-only calligra stuff
<pitti> stgraber: I still get incoming image build failures due to resolv.conf, so either that live-build update didn't do the trick, or it does need manual action to get deployed to the builders?
<pitti> micahg: I'm confused -- https://launchpad.net/ubuntu/+source/firefox/+changelog says that firefox 9.0 is in lucid/maverick -updates; published for maverick and pending for lucid
<pitti> micahg: something wrong with the publisher?
<pitti> "Pending in lucid-updates since 2012-01-27 04:31:40 CET"
<pitti> ah, for maverick it's published on cocoplum now, copying maverick langpacks
<pitti> stgraber: ah, same publisher problem that affected lucid's firefox? it just got published 19 mins ago
<tkamppeter> pitti, hi
<pitti> micahg: it's in now for lucid, copying langpacks
<pitti> hey tkamppeter
<tkamppeter> pitti, cups-filters is released upstream now.
<tkamppeter> pitti, but I have another problem, LightDM does not start any more on my Precise VM.
<dholbach> good morning
<pitti> hey dholbach
<pitti> tkamppeter: what do you see exactly? do you land in a text VT?
<dholbach> hi pitti
<tkamppeter> pitti, it tries to restart repeatedly, the screen is flickering all the time until I SSH in and do "sudo stop lightdm".
<pitti> tkamppeter: could you copy/pastebin /var/log/lightdm/lightdm.log and /var/log/Xorg.0.log somewhere?
<pitti> the latter is probably more interesting
<tkamppeter> pitti, "sudo startx" from a text console opens a desktop though.
<soren> How can I tell do-release-upgrade to never ask me any questions? I've tested the upgrade on an identical system, I know it'll ask me about a conffile change, and I just want it to accept the one from the updated package.
<pitti> tkamppeter: ok, lightdm.log then
<tkamppeter> pitti http://pastebin.ubuntu.com/818557/
<pitti> tkamppeter: ok, no error there; let's look at lightdm.log
<tkamppeter> pitti, http://pastebin.ubuntu.com/818561/
<pitti> Got signal 15 from process 1
<pitti> seems some upstart job is killing it immediately again!?
<tkamppeter> pitti, probably the first Xorg.0.log was wrong, here is a new one: http://paste.ubuntu.com/818564/
<pitti> tkamppeter: no error there, either
<pitti> tkamppeter: does a manual "start lightdm" also give this effect?
<tkamppeter> pitti, yes.
<pitti> tkamppeter: at this point I don't know how to debug upstart and check where the "stop" signal comes from
<pitti> tkamppeter: jhunt should come online soon, perhaps you can debug it with him?
<tkamppeter> pitti, who is the expert?
<pitti> tkamppeter: in the meantime, "startx" should give you a desktop
<pitti> tkamppeter: jhunt is our upstart maintainer
<pitti> stop on runlevel [016]
<pitti> this seems fairly normal
<pitti> tkamppeter: does "runlevel" say "N 2"?
<pitti> tkamppeter: if you just do "sudo lightdm", does it still happen?
<tkamppeter> pitti, a simple "startx" as normal user falls into an infinte loop, showing "No protocol specified".
<tkamppeter> pitti, it is messed up now, I reboot the VM.
<tkamppeter> pitti, "runlevel" is "N 2".
<pitti> tkamppeter: ok, that's fine; can you try "sudo stop lightdm" and then "sudo lightdm"?
<pitti> the latter avoids upstart
<tkamppeter> pitti, I tried this now, lightdm tries to start X repeatedly again and does not succeed.
<tkamppeter> pitti, like with upstart-started lightdm.
<pitti> tkamppeter: can you please pastebin lightdm.log again?
<tkamppeter> pitti, ssh -X 192.168.122.228 (the VM) gives
<tkamppeter> /usr/bin/xauth:  error in locking authority file /home/till/.Xauthority
<tkamppeter> pitti, how do I fix that?
<pitti> tkamppeter: perhaps it's owned by root? or at leats not by you?
<pitti> tkamppeter: sudo chown till:till ~/.Xauthority should help
<tkamppeter> pitti, thanks. Does an X startup switch it to root and if it fails not switch back to original ownership?
<pitti> tkamppeter: ah, perhaps because you did "sudo startx" before, that created a root-owned .Xauthority?
<pitti> that started an X session as root with your $HOME
<tkamppeter> pitti, http://pastebin.ubuntu.com/818574/
<tkamppeter> pitti, that is possible.
<pitti> Got signal 15 from process 3875
<pitti> what is pid 3875?
<pitti> tkamppeter: do you have autologin enabled on this?
<pitti> tkamppeter: and if not, do you see the greeter?
<pitti> i. e. does it fail to display the greeter, or fail to start a session for you?
<tkamppeter> no autologin, normally I get the greeter.
<tkamppeter> PID 3875 does not exist any more.
<tkamppeter> pitti, trying again.
<tkamppeter> pitti, http://paste.ubuntu.com/818578/
<tkamppeter> Note that I have killed the process in the end due to the infinite loop (from an SSH console).
<tkamppeter> pitti, give me the PID of the offending process quickly, perhaps it is still living.
<pitti> Got signal 15 from process 5453
<pitti> it's not the X.org process (that was 5449)
<pitti> I guess it's something else that gets started in between
<pitti> tkamppeter: so, I guess at this point this needs robert_ancell to debug, but he's already offline
<pitti> somethign is sending a sigterm to it, but I don't know which
<pitti> tkamppeter: you could try
<pitti> sudo strace -fvvs1024 -o /tmp/trace lightdm
<pitti> tkamppeter: then look at the log again ("got signal 15 from..."), and then /tmp/trace will tell us what that process was
<pitti> and perhaps a whole lot of other things
<tkamppeter> pitti, I will send you the /tmp/trace by e-mail, pasting through a browser does not work, a browser seems to turn each byte into 1 MB of local RAM ...
<pitti> tkamppeter: put it on chinstrap?
<pitti> micahg: seems ubufox is uninstallable now, was that missed in the transition?
<pitti> micahg: same for mozvoikko
<pitti> (see http://people.canonical.com/~ubuntu-archive/testing/lucid-updates_probs.html)
<tkamppeter> pitti, needed to reboot, my Firefox had eaten up all memory.
<tkamppeter> pitti, sent bzipped trace by mail.
<tkamppeter> pitti, is chinstrap Canonical-internal or also publicly available?
<pitti> tkamppeter: Canonical internal
<tkamppeter> pitti, perhaps in 2 weeks I will have chinstrap access then ...
<bkerensa> https://code.launchpad.net/~bkerensa/ubuntu/natty/libnotify4/fix-for-748560/+merge/90292
<tkamppeter> pitti, did you receive the trace?
<pitti> yes, got it
<pitti> tkamppeter: still a mystery; nowhere in the strace is a process 5958, which is the one sending theh SIGTERM that time
<ppisati> pitti: apt-get says linux-omap4 is "kept back", what's up?
<pitti> ppisati: which release and component?
<pitti> err, pocket?
<ppisati> pitti: P/omap4
<pitti> I don't know, looks okay from here
<pitti> (just by rmadison)
<pitti> not on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html eithe
<pitti> ppisati: whats' the apt output if you sudo apt-get install linux-image-omap4 ?
<ppisati> pitti: now it works...
<ppisati> pitti: sorry
<ppisati> pitti: but shoudln't an "upgrade" handle it?
<pitti> no
<pitti> dist-upgrade should
<pitti> upgrade will never install new or remove existing packages
<pitti> "upgrade" is not very useful in most cases
<pitti> it is if dist-upgrade wnats to remove half of your desktop due to archive skew, then "upgrade" will give you a safe subset
<ppisati> uhm ok, thanks
<tkamppeter> pitti, is the SIGTERM from process 5958 at the end of the trace? Then this would be my manual breaking of the infinite loop via "killall lightdm" command.
<pitti> tkamppeter: aah; that would be it then
<tkamppeter> pitti, you must find an irregularity happening in every round of the loop.
<pitti> I don't see any other message which looks weird; it's all just "DEBUG"
<pitti> this needs robert now, I think; I'm out of ideas :(
<pitti> tkamppeter: it seems the unity-greeter process starts, but then stops immediately again with exit code 0
<pitti> tkamppeter: ah, could you pastebin /var/log/lightdm/x-0-greeter.log ?
<pitti> maybe that has an error message
 * pitti learning this as he goes, by reading lightdm.log
<Daviey> probably not the most exciting of reads.
<tkamppeter> pitti, here we go: http://paste.ubuntu.com/818650/
<pitti> WARNING: File '/usr/lib/indicators3/7/libdatetime.so' does not exist.
<pitti> tkamppeter: are you sure this VM is up to date?
<pitti> looks like a half-broken upgrade
<pitti> tkamppeter: try dist-upgrade and then sudo apt-get install ubuntu-desktop?
<tkamppeter> pitti, solved. indicator-datetime was not installed, probably a missing dependency in some package.
<tkamppeter> dist-upgrade I did before, and ubuntu-desktop was already installed.
<pitti> tkamppeter: ah, unity-greeter should probably depend on it
<seb128> pitti, it should rather handle it fine when it's not there
<pitti> or that
<pitti> right now it trips over a NULL pointer and then exits with 0 (!)
<seb128> not good
<seb128> could be bug #918401
<ubottu> Launchpad bug 918401 in lubuntu-meta (Ubuntu) "Unity-greeter installed by default on Lubuntu, crashing on start" [Undecided,Confirmed] https://launchpad.net/bugs/918401
<cjwatson> @pilot in
<cjwatson> I guess the bot is asleep
* cjwatson changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cjwatson
<Mez> Anyone have any idea how sslv2 is somehow enabled in lucid?  Even though the package has it set so it's not even compiled with sslv2
<hrw> if package has -dbg and -dbgsym (like zlib) then which one has higher value for debugging?
<seb128> hrw, they should be identic in most cases but I guess "dbg" since those might be special builds
<seb128> where the dbgsym are just stripped symbols
<hrw> thx
<dholbach> can somebody please reject https://code.launchpad.net/~wibblymat/ubuntu/oneiric/ettercap/merge-debian-0.7.3-2.2/+merge/71435? we synced a newer version into Ubuntu already
<cjwatson> dholbach: done
<dholbach> thanks cjwatson
<hrw> I wrote small python script to generate list of -dbgsym/-dbg packages for list of packages. someone need?
<DoctorPepper> hi guys !!!
<RAOF> hrw: What benefits does it have over the script on the wiki?
<DoctorPepper> is anyone from the appmenu/debusmenu  team in here ?
<hrw> RAOF: different usecase - I needed a way to get lsit of dbgsym for all packages to create sick rootfs images
<RAOF> hrw: Aah.  Cool!
<apw> pitti, i wonder if you might be able to look over the precise linux pending in the new queue
<pitti> apw: sure! NEWed
<mpt> mvo!
<mvo> hey mpt
<mpt> mvo, so, I have this work item: "[mpt] Invite people to port release-upgrader to aptdaemon"
<mpt> mvo, what good things would happen if someone did that porting?
<mpt> One, that I've just observed (informal usability test), is that it would no longer use the ugly gksudo prompt
<mpt> I'm sure there are others though :-)
<mvo> mpt: right, there are few direct benefits, one if the gksu prompt, the other is that its more inline with the tools we use these days, but its mostly under-the-hood
<mpt> Would the upgrade start queueing nicely if someone happens to be installing/uninstalling an application at the moment they choose to do the upgrade?
<mvo> mpt: yes!
<mpt> (i.e. wait for that to finish)
<mpt> ok
<mpt> mvo, and if someone wants to do it, which project should they be branching? Is it part of update-manager?
<mvo> mpt: yes, branching u-m and possible creating a new repository too to make it more seperate (as its really its own project nowdays)
<mvo> mpt: sorry, I have to leave for lunch now, but I will read scrollback and answer when I'm back
<mpt> ok, thanks mvo
<mvo> yw
<doko> smoser, pitti: please could you recheck http://people.canonical.com/~doko/tmp/eglibc-2.15/install/ (lightdm on amd64 works for me with this one)
<pitti> doko: sure
<doko> I might just have a cpu which doesn't expose this
<pitti> doko: meh, seems I need the :i386 variants as well; multiarch..
<doko> ahh, ok. then building in the ppa
<pitti> doko: but at least in installed/unpacked state, it doesn't crash any more
<doko> pitti: so you did see that dlopen issue on i386?
<pitti> doko: unknown; I'm on amd64
<doko> ok, building in the ppa
<pitti> doko: I'm just purging all :i386 bits from my system, then it should configure
<pitti> easier than waiting
<doko> hijacking the fast buildds
<ScottK> pitti: Thanks.
<pitti> doko: ok, i386 stuff purged, your versino configured, libpixbufloader-svg crash seems fixed
<pitti> doko: I'll keep that version installed, and yell if I see other problems
<tkamppeter> pitti, I am currently working on the packaging of cups-filters. While doing that I have found out that CUPS ships a lot of filters, like ooopstops, textonly, ... which never shipped in CUPS usptream and also are not added by me. Now there is the question whether I should add them to cups-filters upstream and independent of this move them from the cups Debian package to the cups-filters Debian package?
<pitti> tkamppeter: I think we can leave them in cups' debian/local for now
<pitti> tkamppeter: one step at a time
<tkamppeter> pitti, I have somewhat reorganized them and get http://pastebin.ubuntu.com/818724/
<tkamppeter> pitti, I could aply this organizing also to the cups package.
<pitti> tkamppeter: I have no idea about oopstops; textonly might be something which could eventually go into cups-filters
<pitti> tkamppeter: but for now, I'd suggest to not put anything into cups-filters whic looks suspicious or obsolete
<tkamppeter> pitti, advantage of moving them now is to only once have the complex dependencies when spinning out a part of the cups package.
<pitti> tkamppeter: moving one more filter to cups-filters is easy; we just need to bump the Breaks/Replaces: version
<pitti> tkamppeter: so, your call in the end, doesn't make much difference
<tkamppeter> pitti, I can do the move distro-only for now and later on make the decision about upstreamize or drop altogether.
<pitti> tkamppeter: but are the *tops filters still that relevant, given that we are using PDF now?
<tkamppeter> pitti, yes, I see, 3 of them are .../tops.
<pitti> # oopstops      prefilter to sanitize PostScript jobs generated by OpenOffice 2.x
<tkamppeter> pitti, oopstops is already obsolete as LO emits PDF.
<pitti> tkamppeter: I think we should first try whether this is still actually relevant with LibO 3.4
<pitti> tkamppeter: so, let's just kill that one
<tkamppeter> pitti, dvipipetops is not installed with cups' binary packages, also not samba-to-ps ...
<tkamppeter> So from the filters only textonly stays ...
<pitti> tkamppeter: yay spring cleaning :)
<tkamppeter> pitti, early spring, but FF requires it ...
<tkamppeter> pitti, the mailto backend is also not installed, not even in /usr/lib/cups/backend-available/.
<tkamppeter> pitti, after throughing all this awy, we stay with
<hrw> does someone know does germinate is able to track ddebs or not?
<tkamppeter> debian/local/filter/textonly
<tkamppeter> debian/local/mime/text.convs
<tkamppeter> debian/local/ppd: pdf.ppd  postscript.ppd  textonly.ppd
<highvoltage> qmc
<highvoltage> (sorry)
<tkamppeter> pitti, from these debian/local/ppd/pdf.ppd will also die as it is a sample for a PDF printer PPD in the PS workflow, obsolete.
<tkamppeter> pitti, so only the files of the textonly printer driver stay, which could move into cups-filters upstream and postscript.ppd, the generic PostScript PPD of CUPS, there we must check whether CUPS is not also shipping its own.
<pitti> tkamppeter: right, if cups ships its own in the meantime, I think we should use that
<pitti> tkamppeter: text seems harmless and useful enough to include in cups-filters/
 * pitti lunch, bbl
<tkamppeter> pitti, CUPS has one, in sample.drv (PPD generator), so good bye postscript.ppd, textonly goes to cups-filters upstream, cups package cleaned up!
<diwic> pitti, could you sponsor lp:~ubuntu-audio-dev/pulseaudio/ubuntu.precise for me some time today?
<pitti> diwic: sure! want to do/commit the dch -r/debcommit -r now, as I can't push?
<diwic> pitti, you can push
<diwic> pitti, core-devs are audio-devs
<pitti> ah, good
<diwic> pitti, but I can do it anyway if you like?
<pitti> diwic: pushed and uploaded, thanks!
<diwic> pitti, \o/ thanks
<scott-work> diwic: i have to go to 1/2 day meeting, but in about four hours can we talk about pulseaudio <-> jack integration and hand-off later?
<scott-work> i just want to understand the current state and what we need to test and/or do to improve it
<diwic> scott-work, hmm, I'm in a european time zone, but I'll try to be around
<scott-work> diwic: tomorrow morning (my time, about +24 hours) would be fine as well :)
<diwic> 4 hours from now works better
<stgraber> pitti: hi! yeah, I figured it might take a while because of jdstrand playing with the publisher ;) did my fix work once it actually got published?
<cjwatson> doesn't look like pitti tried again
<cjwatson> I rebuilt Ubuntu desktop, apparently successfully
<cjwatson> I guess I can try the others in a bit ...
<stgraber> cool, yeah, that'd be great. thanks
<pitti> stgraber: looks like, http://cdimage.ubuntu.com/mythbuntu/daily-live/20120127/ built
<pitti> (that was auto-launched)
<pitti> stgraber: sorry, forgot to check/try again
<stgraber> slangasek: that didn't take long: bug 922578 :)
<ubottu> Launchpad bug 922578 in ubuntu-meta (Ubuntu) "please remove 'resolvconf' from ubuntu-minimal Depends" [High,New] https://launchpad.net/bugs/922578
<siretart> stgraber: what do you think about importing/syncing nx-libs-lite from unstable to precise?
<cjwatson> ubuntu-mir: would appreciate a quick look at bug 922631, since there are packages currently uninstallable in main because of this (I didn't notice the new dependency before syncing libbsf-java, sorry)
<ubottu> Launchpad bug 922631 in apache-pom (Ubuntu) "[MIR] apache-pom" [Undecided,New] https://launchpad.net/bugs/922631
<siretart> stgraber: If things work out, I'll upload x2goclient to unstable later today
<stgraber> siretart: I think that'd be a good idea, as they are new packages, they won't break anything and will likely be useful for quite a few people
<siretart> stgraber: they replace the existing libxcomp3* and nxproxy packages
<stgraber> siretart: ah, now you're starting to scare me ;)
<stgraber> siretart: are they compatible with NX? (mostly interested in qtnx)
<stgraber> (as in, they were tested with it)
<siretart> stgraber: I've never tried qtnx myself, but Mike (the x2go mike) integrated a lot of patches so that you can install both x2go and freenx on the server using these libs
<siretart> stgraber: so AFAIUI, yes, they are supposed to be compatible with NX
<stgraber> siretart: can you push just the packages you want to sync into Ubuntu to a PPA, I can then do a quick test run of weblive with both x2go and qtnx and make sure everything works before that lands in the archive.
<siretart> stgraber: I can try
<cjwatson> mvo: I could use help or workaround suggestions with bug 922639, if you have a moment ...
<ubottu> Launchpad bug 922639 in apt-clone (Ubuntu) "apt-clone: "Could not exec dpkg"" [Undecided,New] https://launchpad.net/bugs/922639
<mvo> cjwatson: looking
<mvo> cjwatson: this is with the apt-clone from lucid-backports? or the current one in precise ?
<cjwatson> mvo: precise
<cjwatson> 0.2.2
<hallyn> hi - this morning my virbr0 didn't show up, and log showed that adding msq rule got -EINTR (not sure if that was cause or effect).  anyone ever seen that?
<mvo> cjwatson: thanks, let me try to reproduce
<cjwatson> mvo: I'm guessing any 'apt-clone restore --destination=/blah' should do it ...
<hallyn> oops - sorry, wrong chan
<micahg> pitti: neither one should be uninstallable (except for maybe on ia64/sparc)
 * micahg checks in a chroot
<mvo> cjwatson: yeah, this should be covered by the tests actually :/
<mvo> cjwatson: heh :) I actually suspect its a apt bug
<micahg> pitti: not sure, a chroot seems to be fine
<pitti> micahg: oh, I know; it's in universe, promoting
<micahg> ah, right, new binary
<pitti> same for xul-ext-ubufox
<micahg> right, same for xul-ext-mozvoikko in lucid/maverick
<cjwatson> mvo: yeah, I thought it might be given that it already has some workarounds for this kind of thing; but I couldn't work out why it was getting that path for Dir::Bin::dpkg
<micahg> pitti: can you also please promote firefox-locale-* in both lucid and maverick
<pitti> running
<siretart> stgraber: testpackages uploaded to ppa:siretart/x2go
<mvo> cjwatson: I think I commited a fix (lp:apt-clone) - I'm testing it right now, will take a moment
<pitti> micahg: done
<stgraber> siretart: thanks
<siretart> stgraber: O
<siretart> stgraber: I've just talked to mike on jabber. it seems that there are no patches to nxcomp and nxproxy at all, so the packages should be pretty safe wrt. qtnx/nxclient
<micahg> pitti: thanks
<siretart> stgraber: it's more or less "just" an update to the latest nomachine upstream release
<stgraber> siretart: ok, bumped the score on these builds so I can test now :)
<siretart> :-)
<cjwatson> mvo: python-apt seems to set Dir::Bin::dpkg, not Dir::Bin - is that important?
<ScottK> cjwatson: I've got some germinate/seed confusion when you have a moment.  According to http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.precise/_germinate_output python-gi is being pulled in to satisfy python-dbus, but python-dbus dropped that as a recommends 10 days ago.
<ScottK> Is the p.c.c output out of date or ???
<mvo> cjwatson: good catch, I think we need to do both
<cjwatson> ScottK: Doesn't look out of date; check the timestamp
<cjwatson> ScottK: that "to satisfy" message means that it's satisfying a Provides, usually
<ScottK> Hmm. OK.
<ScottK> cjwatson: On http://people.canonical.com/~ubuntu-archive/germinate-output/kubuntu.precise/all it also lists python-gi as being pulled in by python-dbus.
<cjwatson> or rather a virtual dep
<ScottK> So I'm confused.
<ScottK> Ah, wait.
<tgardner> Precise resolvconf is breaking my rice bowl on  precise schroots. /etc/schroot/setup.d/20copyfiles breaks when it tries to copy the host /etc/resolv.conf to the schroot. Maybe its because the schroot hasn't got a mount for /run ? Has anyone else encountered this yet ?
<cjwatson> Recommends: python-gi | python-gobject-2 | python-qt4-dbus
<ScottK> Yeah.
<cjwatson> (so not virtual, sorry, the message indicates alternatives)
<ScottK> So i just need to seed the Qt one.
<cjwatson> Yep, that would do it.
<ScottK> I forgot Debian solved the problem a bit differently than we did.
<debfx> ScottK: apport depends on python-gi so we can't get rid of it
<ScottK> Thanks.
 * apw notes that the link in the chroot is /etc/resolv.conf -> /run/resolvconf/resolv.conf ... is that allowed to be absolute rather then -> ../run/resolvconf/resolv.conf ?
<ScottK> debfx: I'm picking them apart one at a time.
<cjwatson> It is required to be absolute
<cjwatson>      In general, symbolic links within a top-level directory should be
<cjwatson>      relative, and symbolic links pointing from one top-level directory
<cjwatson>      into another should be absolute.  (A top-level directory is a
<cjwatson>      sub-directory of the root directory `/'.)
<cjwatson> policy 10.5
<apw> that makes life very painful with chroots ...
<apw> if you touch the chroot from outside
<cjwatson> stgraber: ^- looks like schroot should be adjusted
<cjwatson> apw: in this case I think it's generally *desirable* when touching the chroot from outside, because you get current name server resolution data without having to copy things manually
<cjwatson> apw: but schroot will need to cope
<tgardner> it seems like its a namespace collision on the symlink
<apw> cjwatson, though from outside you'd use the real /etc/resolv.conf link, and inside you'd get the inside one
<cjwatson> and generally speaking inside you ought to have /run bind-mounted
<cjwatson> it's just the setup that breaks
<apw> ahh so we are just missing /run mount rather than anything else
<cjwatson> are we, or is this setup code that runs before the bind-mounts?
<apw> though of course, if you don't have precise outside you will pollute your real /run
<apw> which doesn't seem desirable
<cjwatson> how will you pollute it by having a symlink into it?
<apw> because outside doesn't have resolvconf at all cause we don't use it before precise by default
<cjwatson> oh, if resolvconf runs.  but who cares, nothing will touch it ...
<apw> which is why rtg even noticed
<apw> and the copy in will still fail as the link points to somethign which doesn't exist
 * cjwatson bows out of this conversation, I'll let stgraber/slangasek fix it
<apw> even if we are happy to have real /run end up polited
<apw> sounds fair to me :)
<stgraber> tgardner,apw,cjwatson: would removing /etc/resolv.conf and replace it by the content of /etc/resolv.conf (so cat /etc/resolv.conf > $target/etc/resolv.conf, instead of a cp), work for you or do we want to bind-mount /run/resolvconf (sounds like a bad idea to me)?
<apw> stgraber, i don't think we care what happens as long as its safe in the inside chroot
<apw> stgraber, as in our case outside is older than precise and doesn't have /run/resolvconf at all
<tgardner> and /run isn't bind mounted within the chroot
<tgardner> only /proc
<stgraber> apw: right, safest way is to rm /etc/resolv.conf in the chroot and replace by the content of /etc/resolv.conf outside of it. This will work whatever the release is outside the chroot.
<stgraber> slangasek: thoughts ^
<apw> sounds safe assuming resolvconf inside will do something sensible should it get run/upgraded/etc after the link is replaced
<tgardner> stgraber, won't /bin/resolvconf complain? It checks that /etc/resolv.conf is a symlink
<apw> stgraber, i guess we could check if the filename is a link, and if so resolve it, and then fix the result to point to the chroot, and ...
<stgraber> tgardner, apw: the reason why we made resolvconf a depends and not a recommends of ubuntu-minimal is because it's supposed to properly deal with /etc/resolv.conf being converted back to a file and never try to make it a symlink again. It's the "supported" way of disabling it.
<stgraber> if that fails for some reason, we need to fix it then :)
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<apw> stgraber, the other way to copy the file might be:   cat source | chroot chroot_dir tee destination >/dev/null
<apw> stgraber, ahh see what you mean about disabling, if thats what its meant to do, then that should work indeed
<tgardner> apw, the symlink check in /sbin/resolvconf looks unequivocal. not that resolvconf is even run in  achroot.
<psusi> I don't suppose anyone could run a sync real quick for me?  I've worked with the debian dev to merge ubuntu's changes there and a new upstream.  Paperwork is in bug #922654
<ubottu> Launchpad bug 922654 in gparted (Ubuntu) "please sync gparted 0.11.0-1 from debian unstable" [Undecided,Incomplete] https://launchpad.net/bugs/922654
<micahg> psusi: no, I just NACKd that
<psusi> ack... why?
<micahg> psusi: new upstream with no testing, alpha 2 next week
<micahg> we're syncing from testing by default
<psusi> I've tested it ;)
<micahg> that's fine, but I think it can wait until alpha 2 (that'll give it time to bake in unstable as well)
<psusi> it also fixes an outstanding bug
<cjwatson> mvo: it also strikes me that apt-clone could do with bind-mounting at least /proc and /sys into the chroot, maybe emore
<cjwatson> *more
<psusi> hrm.... ok... so next week?  just wanted to make sure it got in before freeze... been working on it since before the new year, building, testing, merging in debian and ubuntu
<micahg> psusi: oh, yeah, I think we want it for precise, just not before alpha 2, the Monday after barring any RC bugs would be fine :)
<psusi> ok
<micahg> unless the bug it fixes is extremely bad
<cjwatson> oh yes
<cjwatson> @pilot out
* cjwatson changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<psusi> I guess it isn't extrememly bad... just fails to resize ntfs sometimes
<micahg> cjwatson: I think the channels got set to +t somehow a few days go
<cjwatson> yes, I noticed.  will investigate at some point :)
 * psusi goes back to working on patches for upstream gparted...
<kirkland> any idea if ubumirror (or any of the other archive mirror tools) can mirror PPAs?
<kirkland> or, what's the best way to mirror a PPA?
<mvo> cjwatson: thanks, a good point, I look into it next
 * smb got a plymouth-upstart-bridge going mad after upgrading precise today (on a server install). Not sure exactly what is going wrong
<smb> epoll_wait(3, {}, 64, 0)                = 0 (repeated constantly)
<smb> init similarly bad
<smb> read(24, 0x7f515e650c50, 8192)          = -1 EAGAIN (Resource temporarily unavailable)
<smb> lrwx------ 1 root root 64 Jan 27 17:51 24 -> /dev/ptmx
<apw> if i am decoding that epoll_wait correctly then it is passing a timeout of 0, which is:
<apw> "... while specifying
<apw>        a timeout equal to zero makes epoll_wait() to return  immediately  even
<apw>        if no events are available (return code equal to zero).
<apw> ", and we are returning 0 as expected.
 * apw is suspicious of this upstart upload, 5 hours ago.
<apw> cjwatson, ^^
<smb> right. went back two kernel versions to make sure we did not do evil and its still the same
<cjwatson> apw: -> jodh
<cjwatson> assuming he's still around
<apw> jodh, when did you change your nick!?!
 * smb though hom to be jhunt...
<cjwatson> month or two back
<jodh> apw: keep up :)
<cjwatson> um, the epoll_wait in upstart is in upstart-socket-bridge, not plymouth-upstart-bridge as smb cited above
<cjwatson> now, plymouth calls epoll_wait itself, but it hasn't been uploaded recently
<smb> cjwatson, The process I straced was upstart-udev-bridge
<cjwatson> why did you say plymouth-upstart-bridge?
<smb> I mean plymouth-...
<cjwatson> please can you be accurate
<smb> Just mistyped now
<cjwatson> pick one
<mvo> cjwatson: trunk does the bind mounting now
<cjwatson> mvo: thanks
<smb>  1662 root      20   0 19236  892  704 R   99  0.0   0:12.95 plymouth-upstar
<mvo> yw
 * mvo gets some dinner
<cjwatson> ok.  but plymouth-upstart-bridge has not changed recently
<cjwatson> that's just plymouth's stock event loop code
<smb> cjwatson, Cannot say for sure what package exactly but those two processes seem to end up running wild now
<smb>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
<smb>  1662 root      20   0 19236  892  704 R  100  0.0   7:25.38 plymouth-upstar
<smb>     1 root      20   0 24212 2228 1272 R  100  0.0   7:52.06 init
<jodh> smb: eek!
<jodh> smb: are you running upstart 1.4-0ubuntu3?
<cjwatson> common factor: the kernel
<cjwatson> ;-)
<smb> cjwatson, no
<apw> cjwatson, luckily smb testing very old kernels to confirm
<smb> cjwatson, tried tree different ones
 * apw wonders if we had a libc update
<cjwatson> upstart is a more likely candidate
<cjwatson> /dev/ptmx - I wonder if there's a missing cloexec
<smb> jodh, yes
<jodh> smb: try rebooting with "--no-log"
<cjwatson> try with ... what he said
<smb> one min
<smb> ipmi reset running
<cjwatson> jodh: is it possible that pty_master is being inappropriately leaked to child processes?
<cjwatson> that could have amusing effects
<smb> jodh, improbability factor 1:1 (we're back to normal)
<cjwatson> jodh: the log file seems to be O_CLOEXEC but not the pty master
<apw> smb, so that fixes it huh
<jodh> ? "545:  nih_io_set_cloexec (pty_master);"
<smb> apw, yo!
<smb> So no process at 100%, and I do not see defunct processes anymore
<cjwatson> jodh: ah, sorry, missed that
<smb> which means boot completes and I get a console on ttyS0 as well
<jodh> smb: did you get any log files written in /var/log/upstart?
<cjwatson> jodh: but that's only done in the child - what happens if some other process is spawned between that log object being created and it being destroyed?
<smb> jodh, before or after?
<cjwatson> jodh: afaics any other process spawned will end up with a copy of that pty_master
<smb> jodh, I mean do I need to boot back into without --no-log?
<cjwatson> the nih_io_set_cloexec should be right after opening
<smb> jodh, btw  yes, there are several files in /var/log/upstart
<jodh> smb: could you try reproducting the problem again?
<hallyn> kees: bug 912493, any plans/ideas?
<ubottu> Launchpad bug 912493 in libcap2 (Ubuntu) "libpam-cap: /etc/security/capability.conf reported as obsolete config" [Low,Confirmed] https://launchpad.net/bugs/912493
<smb> jodh, Simple, just have to reboot without --no-log :)
<smb> jodh, Ok, computer is back to bad state
<dobey> anyone else having problems with X after latest update?
<dobey> really need my workstation back :(
<slangasek> cjwatson: jodh tells me you guys have a prospective fix?
<cjwatson> slangasek: I think a cloexec fix (jodh has a patch in hand) is at the very least worth testing
<slangasek> ok
<cjwatson> seems like a very plausible source of trouble
 * slangasek nods
<cjwatson> the way that plymouth-upstart-bridge is suffering indicates that it's some kind of leakage between upstart and child jobs
<bryce> arges, hiya; missed your message yesterday, but I can look into it right now
<arges> bryce, thanks! yea i'm new to this, so please let me know if anything needs to be fixed.
<bryce> arges, certainly.  Do you want feedback here in irc or on the bug report?
<jodh> cjwatson, slangasek, smb: lp:~jamesodhunt/ubuntu/precise/upstart/pty_master-cloexec-fix, https://launchpad.net/~jamesodhunt/+archive/upstart-testing
<jodh> cjwatson, slangasek, smb: I've dput to the upstart-testing ppa, but the page hasn't updated yet...
<smb> jodh, I will pull as soon as I find it there and let you know
<arges> bryce, bug reports fine
<bryce> right, will do
<smb> jodh, or .... start to build in 7 hrs... hmmm
<dobey> hrmm, the -10 kernel at least tells me low graphics mode
<jodh> smb: thx.
<jodh> smb: hey, that's better than the 11hrs for i386.
<dobey> but now dpkg-reconfigure tells me nvidia-current is broken or not fully installed :(
<jodh> cjwatson: could you rescore this one pretty please?
<infinity> jodh: On it.
<jodh> infinity: awesome, thanks.
<dobey> weird
<smb> jodh, Still would be zzz time for smb :)
<infinity> smb: No zzz for you, the jobs are rescored. :P
<smb> infinity, bah! At least its beer time. :)
<infinity> smb: No beer either!
<smb> infinity, too late
<infinity> ;)
<smb> infinity, you know us. right on time with that one. ;)
<dobey> beer doesn't sound like a bad idea right now
<infinity> I need to move to Europe so that when smb starts beering, I don't realise I still have the entire day ahead of me.
<smb> Best move even a bit more east. Then it is not only at least the same time but even cheap. :)
<infinity> smb: Yeah, I'm not sure cheap beer is easter Europe's biggest selling feature, but it's definitely one of them...
<infinity> s/easter/eastern/
<jodh> smb: amd64 has now built.
<infinity> (both have)
<jodh> infinity: thanks again for the prompt action.
<smb> package installed... power reset
 * jodh starts to sweat
<smb> still seems to be in badlands
<smb> I think to be sure I need to boot with --no-logs and re-install
<smb> jodh, No, sorry situation without --no-log has not improved with the new package
<jodh> smb: ok, I guess we'll have to disable logging until we can identify the actual cause.
<jodh> smb: thanks for testing.
<cjwatson> ok
<smb> jodh, ok. welcome
<dobey> and i thought nvidia wasn't going to get broken this time :(
<diwic> scott-work, was it now you wanted to talk to me?
<jodh> smb: could you raise a bug on this issue? It would be interesting to know which log files get created and if there's anything interesting there too.
<jodh> smb: also would be interesting to see the output of "ls /etc/init/"
<smb> jodh, ok can do and add that output.
<jodh> smb: thanks.
<slangasek> patrickmw: there are some very strange outliers in the results on http://reports.qa.ubuntu.com/reports/boot-speed/acer-veriton-01/index.html; are these tests 100% automated and non-interactive?
<slangasek> patrickmw: wondering about http://reports.qa.ubuntu.com/reports/boot-speed/acer-veriton-01/2012-01-24_16-58-22/bootchart.png in particular, which took twice as long to start the desktop as normal
<slangasek> (but it's not the only one)
<cjwatson> jodh: are you going to send me a branch to disable logging again, or do you want me to do it?
<cjwatson> I have a few minutes before dinner ...
<kees> hallyn: hrm, weird. let me take a look.
<smb> jodh, bug 922754
<ubottu> Launchpad bug 922754 in upstart (Ubuntu) "booting without --no-log causes init and plymouth-upstard-bridge to spin at 100%" [Undecided,New] https://launchpad.net/bugs/922754
<smb> bah upstart ... cannot write anymore... :-P
<slangasek> cjwatson: I'm taking it
<cjwatson> slangasek: ah good, thanks
<slangasek> jibel: bug #903137 - heh, you didn't reopen the bug?
<ubottu> Launchpad bug 903137 in base-files (Ubuntu Precise) "lucid->precise upgrade - prompt to update unmodified conf files in /etc/update-motd.d: 00-header, 10-help-text, 99-footer" [Medium,Fix released] https://launchpad.net/bugs/903137
<slangasek> E: base-files: file-in-etc-not-marked-as-conffile etc/legal
<slangasek> sigh
<SpamapS> slangasek: hey, you did a trick once where you imported a missing upstream into a branch.. how did you do that?
<slangasek> SpamapS: possibly bzr import-upstream?
<SpamapS> reading..
<slangasek> or bzr merge-upstream
<slangasek> depends on the context :)
<cjwatson> psusi: pretty sure that parted patch broke LVM handling in d-i; bug 922646
<ubottu> Launchpad bug 922646 in parted (Ubuntu Precise) "precise alternate LVM failed to install: no root file system" [High,Triaged] https://launchpad.net/bugs/922646
<cjwatson> psusi: will try to figure it out if you don't beat me to it ...
<SpamapS> slangasek: I think import-upstream was what I was missing
 * slangasek nods
<SpamapS> upstream-2.6.1       ?
<SpamapS> hm, ? tho..
<slangasek> that means bzr knows about the tag but can't find a revision id for it in the current branch
<slangasek> are you in a subdir of a bzr repo?
<cjwatson> ++               if (_is_dm_major(major(st.st_rdev)) && _is_dmraid_device (buf)
<cjwatson> ++                   && !_dm_is_part(buf))
<cjwatson> I think that has arranged not to probe non-dmraid DM devices, which is definitely wrong
<SpamapS> slangasek: I'm in the root of a working tree underneath a shared repo.
<SpamapS> Imported ../rabbitmq-server_2.6.1.orig.tar.gz as tag:upstream-2.6.1.
<slangasek> SpamapS: ah, so that's what you're seeing after running import-upstream, sure
<slangasek> SpamapS: you probably need to do a null merge of -rtag:upstream-2.6.1 now
<slangasek> in order to graft it into the branch history where you want it
<SpamapS> null merge?
<SpamapS> thats a new concept for me. :p
<slangasek> SpamapS: 'bzr merge -rtag:upstream-2.6.1'; 'bzr diff | patch -R' :)
<slangasek> 'bzr commit'
<SpamapS> slangasek: that merge tries to find the tag in the parent branch
<slangasek> hmm
<slangasek> not sure what's happened then
<SpamapS> adding '.' worked
<slangasek> ah
<SpamapS> now, whether the package builds sanely.. thats another story
<SpamapS> slangasek: if I don't pass '--split' to bzr bd, it thinks the package is native
<slangasek> SpamapS: ummm?  that makes no sense to me
<SpamapS> ok.. after importing the next dsc.. it builds with normal mode
<slangasek> SpamapS: what's the version number in debian/changelog?
<slangasek> ah
<SpamapS> slangasek: 2.6.1-1ubuntu2
<SpamapS> slangasek: would you mind inspecting this branch to see if I did it right: lp:~clint-fewbar/ubuntu/precise/rabbitmq-server/fixed-upstream-tag
<SpamapS> bzr bd works
<SpamapS> history looks fine
<slangasek> SpamapS: yep, looks like what I've done in the past
 * slangasek carefully avoids saying "looks correct" ;D
<SpamapS> well that at least makes sense
<slangasek> cjwatson, jodh: upstart -0ubuntu4 uploaded
<SpamapS> merging the next upstream seems to have hit a lot of conflicts though
<slangasek> not necessarily illegitimate... is this source format v1, with upstream changes?
<SpamapS> probably.. doh
<slangasek> not that that's necessarily a wrong thing either
<slangasek> you may just fundamentally have conflicts that need resolving
<SpamapS> actually no
<SpamapS> no upstream changes
<slangasek> hmm, ok
<SpamapS>   Conflict adding files to plugins-src.  Moved to root.
<SpamapS> I've never seen such a conflict
<slangasek> oh fun
<slangasek> I don't have any good advice on those
<slangasek> #bzr might
 * SpamapS ponders rewinding the branch to before it was borked, and just import-dsc'ing ...
<slangasek> if it's a UDD branch you will ensure the importer will fail going forward, but I guess it's probably failing already
<SpamapS> Ugh, why's that?
<slangasek> because rewinding+overwriting changes the revision IDs associated with the tags the importer cares about
<slangasek> and the importer isn't robust in the face of such changes
<slangasek> https://bugs.launchpad.net/udd/+bug/714622
<ubottu> Ubuntu bug 714622 in Ubuntu Distributed Development "import fails when lp branch has been push --overwrite'n" [High,Confirmed]
<SpamapS> slangasek: I would have thought it just cared about the upstream-* tags and the debian / ubuntu tags.. not the revids
<slangasek> SpamapS: it's a very cautious importer
<SpamapS> ah
<lamont> so when I boot the system and it says that it's waiting for network, then waiting up to 60 seconds more, and then finally says that it's booting without full networking....
<lamont> I'm guessing that's not supposed to be the last message I ever see
<lamont> slangasek: your "fastest networking to date" claim?  I refute it
<slangasek> lamont: that means you've got garbage in /etc/network/interfaces - the system brings up all the network it can
<slangasek> and then it waits for devices you've told it should be there but aren't :)
<lamont> http://paste.ubuntu.com/819194/ <-- slangasek
<lamont> to be fair, I did just uncomment the 'auto lo'
<lamont> anything I should change before I try booting that partition again?
<slangasek> lamont: "just uncomment" as in since the failure or immediately before it?
<lamont> since booting oneiric so that I have a usable system
<slangasek> lamont: ok.  but you say you get the "booting without full networking" message, and then it still doesn't boot?
<stgraber> lamont: it looks like you could drop the pre-up on that virbr0 and replace it by "bridge-ports none", not that it'd make much of a difference though
<lamont> slangasek: it just sits there.  I'll admit, the longest I waited was 5 minutes
<slangasek> lamont: desktop, server?
<lamont> upgrade from oneiric, desktop
<lamont> specifically, my laptop
<slangasek> well, the basic logic for failsafe boot hasn't changed since oneiric
<slangasek> so I think something's wrong inside your /etc/init/rc-sysinit.conf
<slangasek> rather
<slangasek> something's wrong in your runlevel that should get kicked off by /etc/init/rc-sysinit.conf
<lamont> a50c045d9390a6e6c43c18b19cd72fe5  /mnt/etc/init/rc-sysinit.conf
<lamont> I suspect that's virgin
<stgraber> tgardner: just uploaded yet another resolvconf which should fix your schroot bug (you'll need to build a clean chroot though)
<slangasek> lamont: because with that config, your network should come up straightaway, and so /etc/init/failsafe.conf should stop almost immediately because of 'runlevel' being emitted; and runlevel comes from the 'telinit' at the bottom of rc-sysinit.conf
<slangasek> lamont: you have time to debug this?
<lamont> slangasek: I'm making time
<slangasek> lamont: things to check: - is /var/run a symlink to /run? - on boot, does /run/network contain both 'ifup.lo' stamp file and 'static-network-up-emitted' stamp dir? - when you're left with the message on-screen, can you switch vts to get a getty?
<lamont> slangasek: bonus question: how on earth do I actually make it so I can get into this beast at that point?
<slangasek> lamont: you mean if you don't have a getty?
<slangasek> lamont: you can edit /etc/init/tty2.conf (for example) to 'start on filesystem' instead of 'start on runlevel [23]'
<lamont> yeah
<lamont> no getty, no love
<slangasek> ok... but the vt switching itself works correctly?
<lamont> yes
<slangasek> ok
<slangasek> can you try booting with --no-log on the kernel commandline?
<slangasek> (just to rule out a recent upstart change as the culprit)
<tgardner> stgraber, thanks, I'll give it a try.
<SpamapS> oh awesome.. I love when people leave stuff like this in their build scripts, but not the .git dirs..
<SpamapS> echo UPSTREAM_SHORT_HASH:=`git --git-dir=eldap-wrapper/eldap-git/.git log -n 1 HEAD | grep commit | cut -b 8-14` >eldap-wrapper/build/hash.mk
<psusi> cjwatson: so where do you think it failed?
<stgraber> tgardner: might take a while until ubuntu5 is published
<tgardner> stgraber, can I pull the source and build it for myself ?
<james_w> barry, hi, there's a nice fresh wadllib release with py3 support, Colin told me you were going to shepherd that in to the archive?
<cjwatson> psusi: I'm currently testing http://paste.ubuntu.com/819225/
<lamont> slangasek: do I care about stop on runlevel [!23] ?
<stgraber> tgardner: not too easily as you need to have debootstrap use the new one :)
<slangasek> lamont: not at the moment
<lamont> as in it's ok if it's there?
<slangasek> lamont: not unless you think something in /etc/rc2.d is going to telinit you to a different runlevel
<slangasek> lamont: yep
<lamont> ah, ok
<stgraber> tgardner: though the new one should be published in the next 30min to an hour
<tgardner> stgraber, thats soon enough. I've got a few other things on my todo list.
<slangasek> lamont: note that this is not an impossible failure condition, as some people have wound up with links to /etc/init.d/single in /etc/rc2.d before due to insserv unpleasantness
<psusi> cjwatson: ohh shit... d-i depends on ped_probe_all() showing logical volumes?  I removed those intentionally beacuse I've always thought it was a bug that parted -l shows logical volumes, which are really akin to partitions
<jodh> smb, slangasek: thanks both.
<lamont> slangasek: and boot twice, once with and once without --no-log ?
<lamont> ls: cannot access /mnt/etc/rc2.d/*single*: No such file or directory
<slangasek> lamont: sure
<lamont> ok.  back after I finish beating on this box a few times.
<psusi> cjwatson: hrm... I think you want a ! on the _dm_is_part() as well
<psusi> or maybe not... hrm...
<psusi> wait, yea, that's screwwy
<psusi> cjwatson: yea, you want the ! on _dm_is_part too ;)
<psusi> cjwatson: so that if it is a dmraid, it shows it if it is the whole disk, not if it is a partition
<psusi> cjwatson: shouldn't d-i be figuring out what logical volumes there are from lvs though, not parted?
<lamont> slangasek: so... --no-log produces happier me
<lamont> still unhappy me, but happier
<lamont> without --no-log, init winds up at 99-100% busy reading from fd14 and getting EINVAL... fd14 is /dev/ptmx
<lamont> with --no-log, we get all the way to the point where X tries to start, manages to display a cursor, and then falls over. eventually, we hit something hard enough to wedge the display completely, and then all that is left is the rebooting and the crying
<lamont> chmod a-x /usr/bin/X was sufficient to get to a shell prompt where I could get back into irssi and scream
<slangasek> lamont: right, that's the same bug smb reported earlier today
<lamont> slangasek: the --no-log, or the fact that X hates me?
<slangasek> lamont: --no-log
<lamont> more to the point, how do I make X love me again
<slangasek> lamont: so what do you and smb have in common
<slangasek> X> no idea :/
<stgraber> siretart: it's a no-go for these packages. They break qtnx (session init works but the actual NX window never appears and eventually the server cuts the connection), reverting to current Precise packages fixes it.
<lamont> slangasek: 3.2.0-11-generic kernel in a whole disk encrypted root on lvm disk
<lamont> at least in my case
<lamont> the only error in X is failing to setup the touchpad device
<lamont> dell inspiron 15R if that means anything
<slangasek> lamont: seems unlikely to be the touchpad failure that's preventing X from starting, but I don't know.  Desktop team just landed a new X stack this week.
<slangasek> bryce: ^^ lamont's X is broken after upgrading from oneiric to precise
<lamont> was working on 21 jan, probably with 20th bits
<slangasek> lamont: oh, so you were already running precise?
<slangasek> sorry, thought this was a recent o->p upgrade
<lamont> slangasek: yes
 * bryce looking
<lamont> actually, running precise.  was fine after updating and rebooting on 21st, failed when I finally rebooted again today after dist-upgrading
<lamont> 21st had a minor annoyance going that I needed to rootcause before filing the bug, but was otherwise working
<bryce> lamont, /var/log/dpkg.log please?
<lamont> in fact, I'm thinking I'll afk just long enough to reboot into the state I had right before rebooting today, just to see if it makes a good difference
<lamont> bryce: sure
<infinity> ...with log object freed on process exit
<infinity> BAD: block 0x405f0b90 (job) not freed as expected at tests/test_job_process.c:2982 (test_run).
<infinity> /bin/bash: line 5: 28676 Aborted                 ${dir}$tst
<infinity> FAIL: test_job_process
<infinity> ^-- upstart testsuite failure on armhf...
<slangasek> yes
<infinity> I wonder if that relates to the same issue that's making us turn logging off in that upload.
<slangasek> no
<infinity> Mmkay.
<slangasek> at least not AFAICT
<lamont> bryce: chinstrap:~lamont/dplg.log
<slangasek> currently I'm throwing the builds back at the builders until they stick
<infinity> builds, plural?  It's failed elsewhere too?
<slangasek> will worry about debugging the intermittent test failure afterwards
<lamont> bryce: everything since the last working reboot 20120121 1445 -0700 is significant
<slangasek> yes, it failed amd64, armhf, armel; then it succeeded amd64
<infinity> Special.
<infinity> Kay, then I can at least not worry about it being arm-specific.
<slangasek> yep
<slangasek> infinity: has anyone kubuntuish followed up with you about the buildd kernel question?
<cjwatson> psusi: ah, yeah, I overnegated
<infinity> slangasek: Regarding qtwebkit-source, for instance?
<cjwatson> psusi: d-i uses parted to probe all volumes, lvm or not.  deal with it. :)
<slangasek> infinity: yeah. AIUI we've had solid confirmation that the kernel fix, if actually applied, does raise the memory split to 3G/1G as designed
<infinity> slangasek: Yeah, and still doesn't fix the build failures that were attributed to said split issue.
<slangasek> yep
<slangasek> infinity: and the kubuntu team said in the release meeting today that they were "waiting for a kernel fix"
<infinity> slangasek: Which makes some sense, as testing that mmap testcase on other platforms (like ppc) shows that they don't all have 3G available anyway.
<slangasek> which seems, um, incorrect
<slangasek> (or, maybe correct that they're waiting, but an ineffectual strategy)
<ScottK> It's correct we're waiting.  Time will tell if it's ineffectual or not.
<infinity> slangasek: Yeah.  I need to find someone with available round tuits (or push some things to the side on my plate) and figure out what's really going on here.
<infinity> slangasek: I'm sort of beginning to suspect it might be a binutils bug or something.  But I need to investigate.
<lamont> also have I mentioned that the apparent hardcoding of the root device in the initramfs is quite frustrating?
<cjwatson> psusi: btw ... intentionally removing things without mentioning that in the merge proposal?  um, yeah.  don't do that. :-)  I could have seen that in the cover letter and then QA wouldn't have needed to track down a regression ...
<infinity> slangasek: (It could still be a kernel issue too, but I'm getting to the point where I'm suspecting that binutils might just be using RAM very poorly and/or leaking on ARM.  Need some sane testing to confirm, tough)
<cjwatson> (yes, I should have spotted it in code review)
<slangasek> infinity: right
<tgardner> who can I get to punch linux-firmware through the unapproved queues for Lucid and Oneiric ?
<lamont> bryce: need anything else before I try rebooting into last week's world?
<lamont> brb (hopefully), rebooting
<infinity> slangasek: The other angle I need to test (I'll kick off a testbuild this afternoon) is that it might still be a kernel issue, and fixed in precise.  And if it is, I think I might need your help in escalating the "doogfooding precise on a couple of buildds" thing.
<infinity> slangasek: Because I think it would be time pretty solidly wasted to keep trying to figure out what needs to be backported if we could just upgrade a Panda or two, and re-route the problem builds there.
<psusi> cjwatson: I guess I didn't explicitly mention removing logical volumes... I just said in the patch header: don't probe dm devices unless they are dmraid whole disk devices... guess I should have made that more clear
<cjwatson> psusi: yeah, I probably should've read it into that; oh well
 * lamont has successfully reverted to pre-reboot state.
<lamont> though I can see some serious script writing in my weekend to make that less painful for the next time
<psusi> lamont: btrfs snapshots?
<lamont> lvm
<psusi> ahh... I mucked with that last year... yea... very painful..
<psusi> it's so much smoother with btrfs
<lamont> mixed with hard coded ROOT= in places in the initramfs, and an fstab that wasn't changed to reflect the snapshot name, and well, pain
<lamont> psusi: /dev/mapper/rover3-20120125 / ext3 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0
<lamont> I hear ext4 came out a while ago
<lamont> bryce: I don't have running state any more, but can certainly scrape files off of the disk trivially now, and can reboot into the broken world if you want me to try anything
<psusi> the problem with lvm snapshots is they have to copy all blocks that get touched to the snapshot store, even if they are later freed... then when you revert, all of the touched blocks, even the freed ones, have to be copied back.. also can't do more than one snapshot.. with btrfs, it's just an mv to rename the snapshot of your choice to the normal root name and reboot... no copying...
<lamont> psusi: 2 lvrenames have the same effect
<psusi> lvrename has nothing to do with snapshots.... you lvconvert --merge to roll back a snapshot
<lamont> who cares about rolling it back?
<lamont> the snapshot (in my case) is the as-was filesystem
<psusi> ohh, you just want to boot from it temporarily?  yea... you can do that too I guess...
<lamont>  /home is on its own partition, specifically to let me bounce around without paying _too_ much attention
<psusi> until the snapshot exception store fills up anyhow, then your root fs dies ;)
<lamont> that's why both are 20GB
<patrickmw> slangasek, boot speed tests are still running for todays ISOs.   There have been multiple spins today and its catching up as they take a while to run.  As for the 26th's results- yes they are fully non-interactive.  From the time the cd drops to publishing results.
<lamont> my pain this go-round was making it possible to "just boot" from the snapshot, without needing to do all the renames
<slangasek> patrickmw: the ones I was looking at with the weird numbers are from the 24th
<slangasek> patrickmw: I'm not concerned with being caught up, I'm concerned with having 100% variation between successive runs with what should be the same image...
<patrickmw> slangasek, yeah that variance was dramatic.
<slangasek> patrickmw: are all three runs on a given day guaranteed to be done with the same image?
<slangasek> (they need to be, for our purposes)
<patrickmw> slangasek, yes
<slangasek> ok
<slangasek> so something's very strange there, but it doesn't sound like a methodology problem
<slangasek> which means it must be a desktop startup bug, so thanks for revealing it :-)
<patrickmw> I don't typically review these results, I just get them published for those that understand what they are looking for
<broder> the tests are running a vm, right? is the vm's host subject to interesting load?
<patrickmw> no, they are running on slow hardware. acer veritons
<broder> oh, cool. nvm, then
<patrickmw> I would also expect a little variance, but the 24th is odd.
<patrickmw> these have been running "unmanned" for months now
<bryce> lamont, sorry, got several people asking for help all at once :-)
<bryce> lamont, so your issue is likely not an X issue.
<bryce> lamont, looking at your dpkg.log for the 20th/21st there are no X packages changed
<lamont> _since_ 21st 1445 local
<lamont> _that_ boot worked just fine
<lamont> and is, in fact, what I'm running now
<lamont> if need be, I can go bisect the upgrade, but I'd rather not... that way lies work
<bryce> lamont, possibly you're seeing bug #921998
<ubottu> Launchpad bug 921998 in unity-greeter (Ubuntu Precise) "unity-greeter crashed with SIGSEGV in indicator_object_get_entries()" [High,Confirmed] https://launchpad.net/bugs/921998
<lamont> hrm... I suppose that could be verified by simply reverting that package, yes?
<lamont> should I see a tombstone in kernel logging for that segv?
<dobey> lamont: would think, though i seem to still get that crash with the old version as well :-/
 * bryce gets off phone troubleshooting monitor problems with his mother
<bryce> ("Oh, honey, I noticed the cord was just loose.  I plugged it in and it everything works."  Ugh)
<lamont> unity-greeter 0.2.0-0ubuntu4 vs 0.2.0-0ubuntu5
<lamont> heh
<bryce> lamont, symptoms include no errors in your X logs, X just appears to shut down normally; switching to gdm works around it; should be a segfault in dmesg
<dobey> lamont: yeah, rebuild of new libindicate i think
<bryce> lamont, did you file a bug report?
<dobey> unfortunately the new xserver-xorg-core and/or new kernel, seems to also break compat with the nvidia-current driver :(
<lamont> bryce: hadn't yet - where should I file it against?
<lamont> Jan 27 13:00:48 rover3 kernel: [   81.530390] unity-greeter[5105]: segfault at 18 ip 00007fec4b0a4f6c sp 00007fffb061d390 error 4 in libindicator3.so.7.0.0[7fec4b0a0000+d000]
<lamont> oh yeah, that's the badger
<bryce> lamont, don't worry about it, if you had I'd say dupe it to the one I mentioned
<cjwatson> bryce: heh, I rarely get familial tech support for my actual area of expertise since who installs an OS that often - I just get stuff I have no idea about and have to guess
<bryce> lamont, apparently the branch associated with the bug does not fix it
<lamont> bryce: nice
<bryce> cjwatson, yeah it came down to, "Mom, the software all shows the monitor is not being detected right, so either your dog broke the monitor when he knocked it over, or the cable is not connected right, or a pin bent when you plugged it back in."
 * lamont clicks the AOL link on 921998, just for giggles
<slangasek> stgraber: man, bug #922491 ftw
<bryce> 20 minutes later...  "No, it's plugged in solidly... oh wait, when I did earlier, that the other end came loose."
<ubottu> Launchpad bug 922491 in resolvconf (Ubuntu Precise) "lucid to precise server upgrade: resolvconf failed to upgrade: cp cannot create regular file `/run/resolvconf/resolv.conf': No such file or directory" [High,New] https://launchpad.net/bugs/922491
<slangasek> stgraber: this fails because resolvconf creates the directory in the *preinst*, then initscripts is configured and clobbers it with a bind mount :P
<bryce> next HW refresh mom's getting a plain old desktop with >one< monitor.
<slangasek> I think this is another case of fixing a resolvconf bug by removing code
<bryce> while doing this, my 2 1/2 year old son comes in.  "Hi Dutch, do you want to talk to grandma?"  "No, no thanks."
 * lamont reboots to play with today's precise and 921998
<slangasek> omgubuntu: Ubuntu X maintainer rejects multimonitor support
<lamont> slangasek: his son is not a monitor. just sayin
<cjwatson> do not degauss small child
<stgraber> slangasek: oh fun ...
<slangasek> stgraber: easy enough to fix the case of resolvconf being installed on upgrade, because that just requires us to create the directory in the postinst.  But I need to think some more about how to handle the case of the lucid version of resolvconf already being installed.
<kees> random... why is "discard" not a default mount option for ext4 filesystems?
<slangasek> infinity: so armhf and powerpc are failing the new upstart consistently, whereas armel has managed to build it; since armhf and powerpc also failed to build the *previous* version, they're not affected by --log anyway, so I'm punting this for now
<broder> kees: Documentation/whatever claims that they didn't trust it to be completely safe
<cjwatson> yeesh, unpacking multipath-udeb into the d-i environment breaks LVM
<kees> broder: oh...heh.
 * cjwatson takes a hatchet to ... something
<broder> kees: i don't know that it's actually true in practice
<kees> broder: "but it is off
<kees>                         by default until sufficient testing has been done."
<kees> (Documentation/filesystems/ext4.txt)
<kees> only one way I know of to get lots of testing!! ;)
<broder> heg
<broder> *heh
<slangasek> cjwatson: do you know any reason it wouldn't be safe to have resolvconf pre-depends: initscripts (>= /run) ?
<cjwatson> unless it's circular, can't see why not; lots of other stuff does
<cjwatson> well, initscripts Depends: upstart Depends: ifupdown
<cjwatson> so maybe be a little careful
<siretart> stgraber: any idea what's going wrong, and does the server use NX 3.5 as well, or some earlier version?
<cjwatson> iirc Pre-Depends/Depends loops are just about ok though?
<psusi> cjwatson: is that from my merge today too? ;(
<cjwatson> psusi: in that I changed your patch to depend on multipath-udeb rather than kpartx-udeb because the latter didn't exist, yes; but it was only exposing a latent bug anyway
<cjwatson> I'd rather have that kind of thing front-and-centre so it's easy to notice and fix
<psusi> cjwatson: ok ;)
<stgraber> siretart: really not sure, the only difference in behaviour is the lack of actual NX window with the new version. All the console output looks identical
<psusi> so installing kpartx-udeb before also caused the breakage?
<stgraber> siretart: the server is running a mix of old freenx (from freenx-team PPA) and x2go
<psusi> err, multipath-udeb rather
<stgraber> siretart: I can't really try to touch anything on the server as that's the production weblive servers and they need to work with natty, oneiric and precise
<cjwatson> psusi: well, I haven't actually tried, but AFAICS yes - it's because it emits log junk to *stdout* when dm-multipath isn't loaded
<cjwatson> stupid thing
<psusi> ahh, fun
<cjwatson> hmm, but if hw-detect loads multipath-udeb, it modprobes dm-multipath at the same time
<cjwatson> maybe the easiest fix is just to create a kpartx-udeb then
<siretart> stgraber: well, too bad then.
<cjwatson> and say that multipath-udeb should only ever be loaded by hw-detect
<cjwatson> not as robust but it's looking pretty twisty to fix otherwise
<psusi> or move the modprobe from hw-detect to the multipath-udeb postinst?
<cjwatson> postinsts in udebs are different from postinsts in debs
<cjwatson> they imply having a menu item
<stgraber> siretart: server is on nxlibs 3.3 and nxproxy 3.4. With x2goserver 3.0.99.6-0~343 and freenx 0.7.3.git100327.e224628-0~ppa6~natty1.5ubuntu1
<siretart> stgraber:  so a mixture of NX 3.3 and NX 3.4? interesting that this works at all
<slangasek> cjwatson: pre-dep+dep loop could be a bit dicey, but ifupdown doesn't depend on resolvconf in any event.  I'll watch out for loops
<siretart> stgraber: did you try to keep the old x2goserver and only update the libxcomp* and nxproxy stuff?
<siretart> stgraber: or did you upgrade everything?
<stgraber> siretart: I didn't touch anything server side, I only upgraded the client side (as that's the only part I actually care about. The server I have full control of the packages that are installed there)
<siretart> I see
<stgraber> siretart: so on my laptop I upgraded from Precise using your PPA and tried to connect => failed, reverted to clea Precise => worked.
<siretart> stgraber: and I guess that you don't actually use x2go, but stick with a 'plain' NX server, right?
<stgraber> siretart: people using weblive on Natty (by default in Edubuntu's software center) are using qtnx to connect, these using Oneiric or Precise are using python-x2go
<stgraber> siretart: that's why I have that weird mix on the server side, needed to find something that works with all the client versions :)
<siretart> good luck maintaining that mix
<slangasek> stgraber, cjwatson: ok, resolvconf ubuntu6 uploaded with the initscripts dep changed to a pre-dep; hopefully that's the last upload before EOD
<stgraber> well, so far, copying the exact same packages seems to work fine. Eventually natty will be end of support and I'll be able to drop NX and just support x2go.
<siretart> oh, nice, x2goclient just got accepted into unstable
<stgraber> slangasek: yeah, I think that was the last bug discovered today that had to be fixed :) I still think LTSP is broken but I haven't tested it yet and haven't got a bug report yet. Planning on testing and fixing that over the weekend.
<em> Isn't it an obvious bug that the pyopencl package in Ubuntu depends on the Nvidia driver package?
<em> Why would it be set up that way?
<em> It means that there is no way for people who don't use Nvidia to install pyopencl from the repos.
<micahg> IIRC, only the nvidia binary driver have an opencl implementation
<micahg> s/have/has/
<RAOF> micahg: I'm pretty sure fglrx also has an opencl implementation; in fact, given AMD pushes OpenCL harder than nvidia, I'd guess they had it first.
<jtaylor> it has
<jtaylor> but you have to build pyopencl from source to use it with fglrx
<infinity> That seems entirely counter to what OpenCL is meant to promise. :P
<jtaylor> though maybe I only did that to avoid pulling in nvidia stuff which the package depends on
<RAOF> Mesa's growing OpenCL support, so we'll probably see some sensible packaging once that happens :P
<infinity> You may well be right.  I haven't looked at it at all.  I just find it somewhat ironic if our opencl implementation doesn't actually do what opencl is meant to do (provide a generic interface to GPUs and CPUs) without rebuilding it for each target.
<jtaylor> you'll have rebuilding in any case, opencl is all about just in time compiling
<infinity> Well, yes.
<infinity> I suppose we could JIT the JIT.
<infinity> Problem solved.
<RAOF> Huh, yeah.
<RAOF> pyopencl has a dependency on nvidia-current.  That's a barefaced lie!
<infinity> RAOF: If that's demonstrably untrue, then perhaps demote it to a Recommends on nvidia|fglrx?
<infinity> RAOF: I mean, I'd assume it doesn't actually depend on a GPU at all, but I don't know pyopencl.
<jtaylor> I'm not sure if fglrx includes libopencl
<infinity> RAOF: I just know that opencl should, if implemented sanely, also run on the host CPU just fine.
<RAOF> fglrx: /usr/lib/fglrx/libOpenCL.so.1
<infinity> (And maybe this pipe dream is waiting for Mesa to catch up, at least on Linux)
<jtaylor> ah great
<jtaylor> its been a while since I last set it up
<RAOF> infinity: Yeah, but we don't (yet) have a CPU-bound OpenCL library.
<infinity> RAOF: So, Mesa will make everything better?
<RAOF> infinity: Well, mesa will trigger us to actually do OpenCL packaging properly :)
<lamont> I have now progressed to new and different levels of pain
<lamont> bryce: the workaround for bug 921998 is: apt-get install indicator-{datetime,power}
<ubottu> Launchpad bug 921998 in unity-greeter (Ubuntu Precise) "unity-greeter crashed with SIGSEGV in indicator_object_get_entries()" [High,Confirmed] https://launchpad.net/bugs/921998
<lamont> which I will so note shortly.
<lamont> otoh, now it just won't let me log in, since it cannot launch session ubuntu-td
<lamont> ubuntu-2d, even
<RAOF> Ah, there we go.  Debian has fixed python-pyopencl, and we just need to merge & stuff.
 * lamont reinstalls unity-2d
 * cjwatson idly notes that there's something on the FTBFS list called "viennacl" which is dep-wait on libopencl1
<cjwatson> which looks like it comes from some nvidia package in Debian IIRC
<cjwatson> but it'd be awfully nice if somebody with a clue about this stuff could fix that up
<lamont> slangasek: you are forgiven. all is better now in my world.  bugs updated, time for a new snapshot partition
<lamont> should I be concerned that when the window goes full screen (which I didn't tell it to - old bug), that the icons for kill, minimize, and unfullscreen are all indistinguishable from the background of the panel, and require guessing placement for added fun?
<kees> smoser: say, any chance you can resync e2fsprogs from debian? I like having an actually-released version. :)
<infinity> kees: You're so picky.
 * kees bows
#ubuntu-devel 2012-01-28
<kees> hallyn: oh, this is from the multiarchification
<kees> hallyn: I'll figure out a fix
<kees> hallyn: (912493)
<hallyn> kees: thanks
<barry> james_w: just saw your message, fantastic!  i'll add that to the blueprint
<haraldj> Hello a quick question from a Debian packager: Does Ubuntu maintain any repositories for packages which are synced from Debian - specifically openswan
<Ampelbein> haraldj: You can access any package in Ubuntu via bzr: 'bzr branch lp:ubuntu/<packagename>'
 * haraldj is back. 
<haraldj> Ampelbein: well what does this branch contain?
<haraldj> Ampelbein: A source package?
<Ampelbein> haraldj: Yes, the complete source package.
<haraldj> Ampelbein: is it updated for new security or SRU releases?
<Ampelbein> haraldj: No, that's always the current development package, for other versions, use 'lp:ubuntu/<series>/<packagename', where series is for example 'oneiric' or 'oneiric-security' or 'oneiric-updates'.
<haraldj> Ampelbein: So there is no need to create seperate Ubuntu Branches in alioth repository for tracking changes in Ubuntu?
<Ampelbein> haraldj: I guess it would be nice if the alioth repository has both a Debian and Ubuntu branch to ease working on both packages. The lp-repository is mostly a automatically created/updated repository based on the uploaded packages.
<jtaylor> lp has deiban and ubuntu branche
<jtaylor> lp:debian/
<haraldj> jtaylor: Well but this are imported source package not a normal repository correct?
<jtaylor> yes
<jtaylor> but you can host your debian pacakge repository on launchpad if you like
<jtaylor> probably also get it mirrored from a remote place
<unixpro1970> Wondering if someone can recommend a book that demonstrates complete C/C++ code for Message Queues, Async IO, Concurrent Sockets, etc. Â I am not talking your typical 1-5 client examples, I am seeking code that handles 10000+ clients, etc. Â I am not seeking a framework book like ACE, etc but something like ACE demonstrated without the framework would be ideal.
<unixpro1970> Topics like Check Pointing, passing file descriptors between processes, etc. Â Trying to avoid re-eventing the wheel.
<haraldj> jtaylor: thanks for the idea but we already host this project on alioth
<jtaylor> unixpro1970: have a look at zeromq
<jtaylor> quite low level, but still very easy to use
<jtaylor> the guide also is a quite nice learning source
<haraldj> jtaylor: I'm just not sure how to best deal with the Ubuntu packaging - I was thinking of adding branches to alioth to work on the Ubuntu packages
<haraldj> jtaylor: For keeping a development history (mainly for the security and sru releases)
<jtaylor> haraldj: thats how its usually done
<jtaylor> see e.g. http://anonscm.debian.org/gitweb/?p=pkg-cli-apps/packages/banshee.git
<jtaylor> if its git branches are easy
<haraldj> jtaylor: Ok then I will just make branches trying to keep all the changes to Ubuntu packages in VCS :-)
<haraldj> jtaylor: I just did not want to interfere with any Ubuntu internal processes regarding such a procedure
<unixpro1970> thanks jtaylor, but zeromq isn't what I am seeking.
<jtaylor> not? "Message Queues, Async IO, Concurrent Sockets, etc" is pretty much exactly what zmq is
<unixpro1970> Actually something like zeromq without the framework would be great
<jtaylor> zeromq has no framework
<jtaylor> thats what the zero stands for
<jtaylor> zeromq are just sockets
<jtaylor> on steroids ;)
<unixpro1970> is zeromq in C/C++
<unixpro1970> or is it java
<jtaylor> it has bindings in every language
<jtaylor> or almost
<jtaylor> I think the core is c++
<jtaylor> or c
<unixpro1970> Is it open source?
<jtaylor> yes
<jtaylor> lgpl
<unixpro1970> thanks, looked at the example and assumed it was java based
<unixpro1970> actually the more I look at it zeromq seems pretty cool
<unixpro1970> how does it compare to ace?
<unixpro1970> Ace is a framework, but is zeromq pretty  popular and well supported?
<jtaylor> I'm not familiar with ace, but it looks like its higher level
<unixpro1970> any commercial books on zeromq?
<jtaylor> don't know, but the guide is good
<jtaylor> should be around 200 pages
<jtaylor> and free
<jtaylor> goes into quite good detail on the concepts of designing reliable networks (though its hard for me to judge, I'm not in that field)
<mrkennie> I'm looking for a way to get a list of active sessions? I think there was something in gnome 2 using dbus but that has been removed for gnome 3 it seems. Are there other ways to do this?
<mrkennie> org.gnome.SessionManager.GetClients I believe it was but no go anymore :(
<mrkennie> unless I'm barking up the wrong tree because unity is what's being used anyway. Um.
<mrkennie> sorry, going by the silence and having just read the topic, I got the  wrong channel. My bad.
<YokoZar> Debian has deprecated defoma, what's the status of defoma in 12.04?
#ubuntu-devel 2012-01-29
<slangasek> it's been deprecated in Ubuntu and Debian both for a long time, we're just not quite rid of it yet
<YokoZar> slangasek: Thanks.  I'm working on merging msttcorefonts cause of bug 905055
<ubottu> Launchpad bug 905055 in msttcorefonts (Ubuntu) "Package needs to be Multi-Arch enabled so Multi-Arch packages can depend on it" [Undecided,New] https://launchpad.net/bugs/905055
<S-I4> Is it possible to get tax deductions for donations made to ubuntu?
<micahg> cjwatson: so, the Ubuntu Studio images are failing to build due to being unable to find the task for ubuntustudio-font-meta, I think I found the issue, but wanted to check with you, it seems that font-meta depends on the graphics task, but it should really be the other way around, does that sound sane?  Also, if there's no dependent task, is something just dropped from STRUCTURE?
<cjwatson> micahg: yeah, I was meaning to ask about that - it does kind of look as though graphics ought to inherit from font-meta, to me
<cjwatson> bah
<cjwatson> micahg: yeah, I was meaning to ask about that - it does kind of look as though graphics ought to inherit from font-meta, to me
<cjwatson> micahg: no, don't drop it from STRUCTURE - you can have an empty list of inheritees, but it's probably more sane to have it inherit from minimal or something
<cjwatson> or maybe even desktop-common
<micahg> ok, thanks, will make the change, would you be able to rerun it after?
<cjwatson> sure
<cjwatson> (if you drop it entirely from STRUCTURE, the effect will be as if it's just a random file lying around in that branch, not a seed)
<micahg> ah, ok, good to know, I pushed up a new revision with the fixes
<slangasek> cjwatson: do you know why x-ttcidfont-conf is in the desktop-common seed?  It dates back to the founding of rome^W^W^W revid 1, and seems to be the only thing still keeping defoma in ubuntu-desktop... and is removed in Debian
<cjwatson> slangasek: absolutely no idea; it probably seemed like a good idea at the time
<slangasek> k
<cjwatson> I'd have thought anything that actually needed it would depend on it
<slangasek> I think I'll pull it and see if anyone screams then; if something actually needs it it ought to depend directly
 * slangasek nods
<micahg> cjwatson: can you respin Ubuntu Studio please
<slangasek> the package seems to be primarily a defoma hook anyway
<cjwatson> micahg: running
<micahg> thanks
<cjwatson> slangasek: it might have been needed in warty for some reason; but probably not worth figuring out now except destructively :-)
 * slangasek grins
<stgraber> anyone knows what's happening to language-pack-kde-wae? it's currently uninstallable (because language-pack-kde-wae-base doesn't exist at the same version) and so broke Edubuntu DVD builds for the last two days
<cjwatson> I'd look through the pre-revision-control wiki history but somebody has either helpfully deleted it or hidden it VERY well
<cjwatson> https://wiki.canonical.com/WartyWarthogDesktopSeed?action=info is the best I can do
<cjwatson> https://wiki.canonical.com/WartyWarthogDesktopSeed?action=diff&rev1=74&rev2=75 - editor sabdfl, comment "sort out fonts"
<cjwatson> slangasek: ^-
<cjwatson> so I suspect the answer is "it looked font-related" :-)
<slangasek> heh, fair 'nuff
<cjwatson> micahg: failed, might be a slight delay on bzr+ssh -> http propagation or something
<cjwatson> oh, no, it needs a publisher run
<micahg> cjwatson: ah, ok, can you retry in an hour then?
<cjwatson> micahg: more like half an hour but yes
<micahg> ok, thanks
<micahg> cjwatson: do I need a new meta upload for a STRUCTURE change?
<cjwatson> micahg: not unless it results in metapackage dependency changes
<cjwatson> micahg: it might be worth experimentally updating to see what happens, though; my suspicion is that you may need to change ubuntustudio-graphics to explicitly depend on ubuntustudio-font-meta (i.e. in debian/control) if you intend that dependency to persist
<cjwatson> germinate-update-metapackage isn't great (partly deliberately) at inter-metapackage dependencies
<micahg> ah, looks like it'll just update the Task
<micahg> oh, wait, that's done separately, nevermind
<micahg> cjwatson: it already was that way in the seed
<micahg> ah the dependency shows up properly in the generated package
<ricotz> hi, is there a proper way to define a build-dep in debian/control like this "libstdc++6:i386 [amd64]"
<slangasek> ricotz: cross-arch build-dependencies are not permitted at this time; you can however build-depend on lib32stdc++6 [amd64]
<slangasek> which may or may not have the desired result
<ricotz> slangasek, i see, the reason doing this is i am having trouble to build-depend on "ia32-libs-multiarch [amd64]"
<ricotz> slangasek, https://launchpadlibrarian.net/91366230/buildlog_ubuntu-precise-amd64.fglrx-installer_2%3A8.930-0ubuntu1~xedgers~precise1_FAILEDTOBUILD.txt.gz
<ricotz> this might get solved by the next apt update
<slangasek> ricotz: split the package based on the architecture of the contents, build the i386 bits only when building the i386 package, and structure the binary package dependencies to pull in the 32-bit-only package when needed
<slangasek> consider it an accident that build-depending on ia32-libs-multiarch is working at the moment - one that infinity was encouraging us to fix
<ricotz> slangasek, i know, debian is doing this more properly here for fglrx, but i am not the maintainer of the ubuntu packaging here
<ricotz> so i not so confident changing it while not be able to actually test this driver myself
<slangasek> but you care about the build failure, so I'm telling you the right way for it to be fixed :)
<ricotz> slangasek, ok, maybe exp16 will work?
<slangasek> no
<ricotz> you are right ;)
<slangasek> in general, build-depending on ia32-libs-multiarch is going to be fragile because it requires i386 and amd64 versions of your build-dependencies to be in sync in the archive at the time of build
<slangasek> so it'll "sometimes" work... at least until the buildds are neutered to not allow pulling i386 packages in
<ricotz> slangasek, yeah, i was hoping i have found a calm moment here
<ricotz> but this could be a resolver issue as well
<ricotz> thanks
<slangasek> if you can show that it's a resolver issue, I'm certainly interested to know that
<slangasek> but even so, the end goal is to make this configuration *not* work on the buildds :)
<ricotz> slangasek, ;)
<cjwatson> micahg: I know it was that way in the seed, but a package that's also in an inherited seed will get pruned from the dependencies ...
 * cjwatson retries that build
<micahg> cjwatson: I looked at the package in the archive and it seemed to have the proper dependency, are you suggesting that respinning will drop it?
<cjwatson> micahg: that's what I was saying needed to be tested, yes, and perhaps replaced with an explicit dependency in debian/control if so rather than relying on the substvar
<micahg> ah, ok, will test, thanks
<slangasek> ricotz: the fglrx-installer package in the archive doesn't appear to have this ia32-libs-multiarch build-dependency?
<ricotz> slangasek, i added it to fix resolving shlibs
<slangasek> ricotz: ah
<ricotz> slangasek, only the stdc++6 libs was still missing
<slangasek> yeah, and libstdc++6 is available as a biarch package (lib32stdc++6), so that's the simple route
<slangasek> long term, it's better to split the binary packages on architecture lines
<ricotz> oh, i see
<ricotz> right, i will replace it then
<ricotz> for the time being
<micahg> cjwatson: you were right about ubuntustudio-font-meta being removed from graphics
<infinity> slangasek, ricotz: Worth noting that said neutering (ie: making amd64 buildds no longer multiarch) will be happening the next time the chroots are refreshed, the change to the scripts is already committed.
<slangasek> ricotz: oh, in fact looking at the package I believe this is entirely due to an upstream bug
<slangasek> $ file arch/x86*/usr/lib*/libSlot*.so
<slangasek> arch/x86/usr/lib/libSlotMaximizerAg.so:      ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
<slangasek> arch/x86/usr/lib/libSlotMaximizerBe.so:      ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
<slangasek> arch/x86_64/usr/lib64/libSlotMaximizerAg.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
<slangasek> arch/x86_64/usr/lib64/libSlotMaximizerBe.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped
<slangasek> $
<slangasek> ricotz: upstream seems to have simply included a 32-bit library where a 64-bit library should have been
<cjwatson> micahg: and the ubuntustudio DVDs built cleanly
<slangasek> ricotz: so having it depend on lib32stdc++6 doesn't actually do anybody any good, AFAICS
<astraljava> cjwatson: micahg: Thanks, guys! :)
<ricotz> slangasek, ah, i see, this is bad :\
#ubuntu-devel 2013-01-21
<Bluefoxicy> is it possible to get apt to authenticate via certificate?
<Bluefoxicy> http://lists.debian.org/debian-user/2011/06/msg02273.html never mind, apparently it is.
<Bluefoxicy> oops it looks like Pulp can do that :)
<Bluefoxicy> just needs a DEB/APT plug-in.
<pitti> Good morning
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<mitya57> hi dholbach & pitti
<mlankhorst> cjwatson: doesn't look like I can drop more space than the shared libgallium thing :(
<ogra_> does anyone know if there is something similar to udev-acl for sysfs files ?
<ogra_> i could just use an upstart job to "chgrp users" but wonder if there isnt a more elegant way
<xnox> well udev runs as root, and it can haz RUN stanza......
<ogra_> but it only acts on devices, not sure there are matching devs at all
<ogra_> (i'll check, running chgrp from udev isnt much diferent to upstart though)
<cjwatson> mlankhorst: OK, well, it's a start anyway; thanks
 * cjwatson is somewhat tempted to drop sl-modem-daemon from 12.04.2 images.  It costs 5MB on amd64 due to dragging in libc6-i386 ...
<mlankhorst> cjwatson: should I re-upload the mesa (unrenamed) sru to put in a build fix against the new libdrm, and remove the references in the sru to libdrm-dev renamed?
<cjwatson> Don't remove any existing changelog entries, please
<cjwatson> But feel free to reupload with the shared libgallium fix
<mlankhorst> I mean the unrenamed one, mesa 8.0.4
<mlankhorst> the renamed mesa-lts-quantal is currently building https://launchpad.net/~mlankhorst/+archive/ppa/+packages
<mlankhorst> I want to test it first
<cjwatson> So what's the problem - mesa in precise-proposed fails to build against libdrm in precise-proposed?
<mlankhorst> yes :)
<cjwatson> I don't get what you mean by removing references in the SRU, since bug 1098215 doesn't mention libdrm
<ubottu> bug 1098215 in mesa (Ubuntu Precise) "installing libqt4-opengl-dev uninstalls renamed stack" [Critical,Fix committed] https://launchpad.net/bugs/1098215
<mlankhorst> well to be able to work right libdrm-dev-renamed had to be added to the list of packages that could satisfy the libdrm-dev dependency, else things would still break in some circumstances, but now that libdrm is no longer renamed, it could be dropped. But it should be harmless to keep the references to the renamed versions of libdrm-dev
<cjwatson> Oh, right
<cjwatson> I don't really mind which you do
<mlankhorst> I think I'll commit the fix to our git repository only for now then, next sru could pick it up
<tjaalton> why isn't armhf an "official" port in archive.u.c, but instead uses ports.u.c?
<micahg> tjaalton: see https://wiki.ubuntu.com/SecurityTeam/FAQ#Architectures , it's been this way for a while
<tjaalton> micahg: doesn't answer the question though :)
<micahg> I would think so the world doesn't have to mirror less used archs
<tjaalton> that's just a matter of doing proper mirroring
<tjaalton> I'm not mirroring i386..
<micahg> yes, but most mirrors are
<micahg> (at least the public ones)
<xnox> tjaalton: e.g. we'd rather mirrors mirror everything, instead of dropping out because there is too much data there.
<xnox> same story is why lpia was on ports.
<xnox> I guess one day i386 will move to ports & armhf/aarm64 might move into archive.
<tjaalton> right
<cjwatson> tjaalton: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Ports
<cjwatson> armhf gets massively fewer downloads than i386
<tjaalton> cjwatson: yeah, understood
<cjwatson> Note https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Official_Architectures - armhf is still official even though it's on ports
<Brogrammin> Morning guys. Python programmer looking to get involved with Ubuntu, any opportunities with Python?
<brendand> Brogrammin, python is everywhere in ubuntu
<mlankhorst> well the renamed mesa ran glxgears with shared libgallium so it can't be that broken for i915/nouveau, I'll test on radeon too to be sure
<mlankhorst> ok radeon works too, uploaded..
<hallyn> infinity: hey - the CVE patch you pushed to raring qemu...  does that actually do anything?  it seems to only add a check for 'size > 16384' when it already is triggering on 'size > 1522' ?
<cjwatson> Most i386/amd64 Ubuntu (i.e. not PPA) builders going down soon for a hardware move, lasting about 30 minutes
<Laney> hallyn: Hey ;-) Don't suppose you know anything about this: https://ubuntuone.com/27Vn82hay9zqxyL3O98V1k do you?
<hallyn> Laney: hm.  brings up https://bugzilla.redhat.com/show_bug.cgi?id=885464
<ubottu> bugzilla.redhat.com bug 885464 in qemu "qemu 1.3.0 error: unsupported configuration: hda-duplex not supported in this QEMU binary" [High,Closed: nextrelease]
<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 dicussion 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
<Laney> hallyn: Indeed I found that but the responses aren't so helpful
<stgraber> hallyn: ah yeah, I've got quite a few problems with qemu/kvm with libvirt yesterday. It was complaining quite a bit about the hda-duplex stuff, also about the usb2 devices and then about CPU flags and types.
<stgraber> hallyn: as I needed it working, I simply wiped all matching entries from the libvirt xml file and it worked, but it wasn't a smooth upgrade ;)
<hallyn> I don't see anything in upstream changelog...
<hallyn> Laney: stgraber: does it by any chance help if you set cpu type to -cpu kvm64 ?
<stgraber> hallyn: not really, I had to switch to kvm64 + remove all the list of flags that libvirt had stored in the xml file
<stgraber> hallyn: I think I have a copy of the xml I can paste somewhere, hold on
<Laney> Cannot find suitable CPU model for given data
<hallyn> stgraber: Laney: a hacky workaround for now could be to use spice :)  that would use the old qemu-kvm-spice binary whic his still based on the old source tree.
<stgraber> hallyn: http://paste.ubuntu.com/1555743/
<hallyn> i'm not sure yet what the long term solution will be.  debian group is talking about a kvm wrapper to emulate the old behavior...
<Laney> hmm if I change the audio device model to something else (leaving cpu type alone) I get permission denied errors
<stgraber> so yeah, libvirt worked again after I removed all those "<feature>" tags, switched to kvm64, dropped all the "ich9-uhci*" entries and all the sound cards
<hallyn> stgraber: that was a windwos vm, or ubuntu?  can you paste the /var/log/libvirt/qemu/<vm>.log ?
<hallyn> It's possible the sound cards just erred because of the sound options being re-ordered (alsa first, pa at the end)
<stgraber> hallyn: I first had the problem with a win8 VM yesterday, but the one I pasted above is an Ubuntu one
<stgraber> hallyn: http://paste.ubuntu.com/1555758/
<hallyn> stgraber:  so then what if you *only* switch out the cpu definition for -cpu kvm64 ?
<stgraber> hallyn: hmm, it starts ;) which is vaguely surprising as that's what I tried to do with virt-manager yesteday but didn't work... anyway, I'll just blame virt-manager for now ;)
<hallyn> stgraber: and does it give you sound?
<stgraber> hallyn: ah, that VM doesn't appear to have a soundcard, might explain why just changing the CPU did the trick
<Laney> hallyn: /dev/kvm was root:root for me until I rebooted - it's now root:kvm
<hallyn> Laney: stgraber: what i said before was wrong - qemu-kvm-spice was always built on (modified) qemu, not qemu-kvm source.
<Laney> Changing sound ich6âac97 gets it to boot
<Laney> and I still can't select kvm64 "Cannot find suitable CPU model for given data"
<hallyn> Laney: you're on raring right?  if it was root:root then at this point i dunno, udev is borked
<Laney> well it's right after a reboot ...
<hallyn> what is your rootfs?  (wondering if inotify is not working)
<Laney> ext4
<hallyn> Laney: it shouldn't need a reboot.  qemu-kvm postinst calls udevadm trigger to force it to reread the udev rules for /dev/kvm
<hallyn> Laney: is anything in your /var/log/syslog or /var/log/udev to show why it failed?  (group kvm not existing, or someting)?
<Laney> should it be root:root if qemu isn't installed?
<stgraber> hallyn: bah, I really used the wrong VM for an example didn't I? ;)
<hallyn> Laney: yes, that's how the default udev rules set it up
<stgraber> hallyn: let me switch to standard kvm and give you the other errors then :)
<Laney> alright, so it's like that on my laptop now
<Laney> let me apt-get install qemu and see what happens
<stgraber> hallyn: right, now it fails to start even with kvm64, so similar to what I had with my other VM yesterday
<Laney> yeah still root:root
<Laney> Jan 21 16:44:56 iota udevd[357]: specified group 'kvm' unknown
<hallyn> Laney: intersting, ich6 depends on hda-duplex.
<hallyn> stgraber: is that due to ich6 audio?
<stgraber> hallyn: nope, it's back to CPU problems
<stgraber> hallyn: I don't have audio in that VM
<stgraber> hallyn: I'm getting "error: internal error Cannot find suitable CPU model for given data" even with kvm64, probably because of the feature flags
<hallyn> Laney: I wonder udev needs to be totally restarted, i.e. maybe it has cached a copy of /etc/group
<hallyn> Laney: bc we very clearly, explicitly add group kvm long before we call udevadm trigger, in qemu-system.postinst
<Laney> yeah I have the group now (didn't have it before)
<hallyn> Laney: what do you mean by before?  before qemu was installed, right?
<Laney> yes
<Laney> so that part is as expected
<Laney> sorry that we've ended up debugging three bugs at once
<Laney> is it https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1092715 ?
<ubottu> Ubuntu bug 1092715 in qemu-kvm (Ubuntu Raring) "udevadm trigger --action=change not working in quantal and raring" [High,Confirmed]
<hallyn> i don't understand, hda-duplex *should* be qemu...
<hallyn> Laney: sort of, except that one describes symptoms due to several things
<hallyn> Laney: one cause was the udev rule in qemu not explictly removing the group acl
<hallyn> (which in debian gets set to group::rw-, and i think should in ubuntu as well - but i don't even know where that gets set)
<hallyn> Laney: adam_g ran into the one where udev didn't see the new rule, some inotify failure
<hallyn> Laney: and now you're seeing something i've occasionally seen, where udev for some idiotic reason doesn't yet know about group kvm
<hallyn> i could add a sleep 2 to the qemu-system.postinst :)
<hallyn> or 'while [ ! group-exists kvm ]; do : done
<Laney> heh
<Laney> so I touched 40-qemu-system.rules and then re-ran udevadm trigger and it's set it now
<hallyn> stgraber: can you file a bug and attach the xml for the failing vm?
<hallyn> stgraber: With luck we can have libvirt automatically do the appropriate update of xml contents...
<stgraber> hallyn: yep, will do
<hallyn> stgraber: thanks
<Laney> what's responsible for displaying the bootdegraded prompt?
<Laney> (changing the topic ...)
<stgraber> hallyn: bug 1102487
<ubottu> bug 1102487 in libvirt (Ubuntu) "VM won't boot after recent qemu upgrade" [Undecided,New] https://launchpad.net/bugs/1102487
<stgraber> hallyn: sorry for the pretty short description but I have to run to a meeting
 * Laney adds some info
<hallyn> stgraber: thanks :)
<jodh> on the topic of kvm, anyone else having major vm performance degradation after recent update?
 * Laney gets far enough to find out
<hallyn> jodh: make sure to add '-enable-kvm' to cmdline if you're running byhand
<hallyn> (libvirt always does it for you)
<jodh> hallyn: I get the following when modprobing kvm_intel (which used to work for me): 'kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround'
<Laney> it's hard to tell
<jodh> hallyn: thanks - that did it! Must be a behavioural change as kvm worked fine last week without that option.
<hallyn> jodh: yes, it's due to the switch from qemu-kvm to qemu upstream source
<hallyn> unfortunately that's the simplest change to fix, it seems :(
<hallyn> s/fix/work around
<jodh> hallyn: but hey, one down... ;)
<hallyn> jodh: I'm afraid that one is going to weird out a lot of ppl.  I noted it in README.debian, but that really isn't very discoveraable imo
<GuidoPallemans> where can I find all the GIcon icons?
<infinity> hallyn: The patch is from upstream.  I agree that the initial || looks odd, but the rest makes sense.
<hallyn> infinity: but it doesn't make any effective change...
<cjwatson> amd64/i386 builders are back
<infinity> hallyn: Did you follow the brackets?
<cjwatson> ... or not
<infinity> hallyn: if (size > BIG || (size > SMALL && register_set)) && other_register_set)
<infinity> hallyn: The brackets are important.
<jodh> hallyn: invocation now certainly has a tautological element to it :)
<hallyn> infinity: ah, there it is :)  yes somehow i didn't see those.  i don't know how.  thanks
<infinity> mlankhorst: Do we get that mesa/libdri linkage fix in Q and R as well, or just lts-quantal?
<infinity> hallyn: I'm with you, I find nested brackets REALLY hard to track across line breaks.
<infinity> hallyn: Which is why I copy and pasted it out and removed all the \n
<hallyn> infinity: i was goign to blame the transparent terms.
<mlankhorst> infinity: it's just for lts-quantal probably, which one do you mean?
<hallyn> stgraber: Laney: good news, I see how I messed up the audio card list in packaging.
<hallyn> I can't however reproduce problems with the cpu lists
<hallyn> so let's see if when i uplaod a new version, maybe magically it'll fix it all
<hallyn> (for me adding all those features to sandybridge cpu works fine)
<Laney> nice, i'll try that tomorrow
<infinity> mlankhorst: The libcricore static linkage thing.  It's just as much a bug in raring as it is in precise-lts-quantal, IMO.
<Laney> night!
<mlankhorst> infinity: yes but for raring we're moving to a new mesa, in which case we can do it in a much cleaner way
<infinity> mlankhorst: Mmkay.
<mlankhorst> there have been some patches on the mailing list, but with build system still in flux I've been holding it off
<mlankhorst> as for quantal, well we could enable it if you want to, but size hasn't been as much as a concern with the cd requirement lifted, so we felt that it wasn't appropriate to enable close to release
<infinity> mlankhorst: For Q, it would be more about keeping the Q and lts-Q packages in sync, since the latter is meant to just be a backport of the former.
<mlankhorst> yeah I'm aware, but quantal didn't have the size considerations lts-q does
<mlankhorst> so while I originally made the patch for q, being close to release time meant I didn't want to risk enabling it.
<infinity> mlankhorst: Sure, but that was months ago, and this is now.  No release pending, just an SRU.
 * infinity shrugs.
<mlankhorst> I suppose if you really want one. :P
<infinity> I'm not wildly picky, to be fair.  Will the next lts-backport stack in .3 also be Q, or will it be R by then?
<mlankhorst> r
<infinity> Okay, then if this is fixed properly in R, that's probably fine, if you'll never need to backport the Q mesa again.
<mlankhorst> I can easily make it part of the scripts to uncomment it for quantal
<infinity> (Of course, if the Q mesa has a CVE or other reason for SRU, it's way less effort in the future to apply fix to Q, backport with scripts to lts-q, done)
<infinity> I guess what I'm driving at is that I see this as a real bug, not as a "we're pretending it's a bug due to ISO space constraints").
<mlankhorst> the script could be made to do the same transformation
<infinity> mlankhorst: Yes, but why?  The backport script shouldn't be fixing bugs, only mangling things needed to backport successfully.
<infinity> mlankhorst: If there are bugs, they should be fixed in the source being backported, not the target backported to.
<mlankhorst> we're already doing something like that for xorg-server, since lightdm passes -nc to the xserver, instead of -background none
<infinity> mlankhorst: And is that a bug that should have been fixed in Q, or something that's P-specific?
<mlankhorst> p specific
<infinity> mlankhorst: Right, so script mangling that is fine.
<infinity> mlankhorst: This is what I'm arguing for the mesa thing, it's not P-specific.
<infinity> mlankhorst: We *noticed* it because of the P images being large and going hunting for the cause(s), but that doesn't make it any less a bug in Q/R.
<infinity> Recklessly shipping tons of copies of something statically linked is always a bug (sure, not a hugely critical one, if it's all from the same source package, but still sloppy)
<infinity> And while a single package maintainer can say "so what, it's only 10MB?", if every package had the same attitude, your installed system would be twice as big, or more. :P
<infinity> Hence, bug.
<mlankhorst> it's going to be fixed in raring
<infinity> Check.
<mlankhorst> infinity: http://lists.freedesktop.org/archives/mesa-dev/2012-August/026040.html
<infinity> mlankhorst: So, in that latest mesa-lts-quantal build, the sizes of /usr/lib/<triplet>/dri/*.so are still huge compared to the P versions...
<infinity> mlankhorst: Did your patch build things shared, but not actually link to the shared versions?
<mlankhorst> it is actually smaller
<infinity> -rw-r--r-- 1 root root 1284072 Mar 30  2012 r600_dri.so
<infinity> -rw-r--r-- root/root   3405324 2013-01-21 18:16 ./usr/lib/i386-linux-gnu/dri/r600_dri.so
<infinity> Old and new.
<mlankhorst> but I mean smaller than it was before
<mlankhorst> I'm unsure since the build system changed and I think the drivers started using llvm, is there any way to check what's causing the size?
<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 dicussion 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:
<infinity> mlankhorst: Okay, yeah, you're right, the size did drop a little.  But it certainly isn't as much as I'd been hoping, given the previous size of these modules.
<infinity> mlankhorst: Err, and the original complaint (linking statically against libdricore) is still there.
<mlankhorst> oh ok, I'll try to see if I can get libdricore dynamic too, then
<infinity> mlankhorst: http://paste.ubuntu.com/1556311/
<mlankhorst> hmz indeed
<mlankhorst> but there is no libdricore.a..
<infinity> I'm sure there is during the build.
<mlankhorst> nope :/
<infinity> libtool: install: (cd /build/buildd/mesa-lts-quantal-9.0/build/dri/src/mesa/drivers/dri/i915; /bin/bash /build/buildd/mesa-lts-quantal-9.0/build/dri/libtool  --silent --tag CC --mode=relink gcc -DI915 -I../../../../../../../include -I../../../../../../../src/ -I../../../../../../../src/mapi -I../../../../../../../src/mesa/ -I../../../../../../../src/mesa/drivers/dri/common -I../../../../../../../src/mesa/drivers/dri/intel -I../../../../../../../src/
<infinity> Gah.
<infinity> LONG LINE IS LONG.
<infinity> Sorry about that.
<Laney> it got cut off anyway
<infinity> mlankhorst: Anyhow, I bet you'll find that, at that point in the build, ../../../../../src/mesa/libdricore/libdricore9.0.0.la references a bunch of static objects instead of a shared linking script.
<infinity> Laney: Phew.
<infinity> mlankhorst: So, we go to all the trouble to build a proper shared library and then fail to use it, it would seem.
<mlankhorst> it might appear to be so
<roadmr> hey folks, what's the proper way to get bugs unlinked from an SRU? Deleting the link from the merge request? One of my SRUs failed one verification, I removed the code and resubmitted, but that bug still shows in the SRU queue
<infinity> mlankhorst: And, indeed, the link lines on 8.0.x include an -ldricore (and an appropriate -L, I assume), which makes it all better.
<infinity> roadmr: Hrm?  Which SRU?
<mlankhorst> upstream fail :/
<roadmr> infinity: checkbox 0.13.9, the fix for bug 990133 was bad so I removed it, yet it still shows in the pending-sru thing
<ubottu> bug 990133 in checkbox (Ubuntu Precise) "[camera/still] window that opens to display still image doesn't close" [Undecided,Fix committed] https://launchpad.net/bugs/990133
<mlankhorst> oh i guess not
<infinity> roadmr: That's because you uploaded with -v
<infinity> roadmr: This is one of those rare cases where you don't want to do that. :P
<infinity> roadmr: But we can work around it, if all the other bugs verify fine.
<mlankhorst> must have missed it during the rebase of that patch
<roadmr> infinity: I didn't do the upload myself :( -v to which tool?
<infinity> roadmr: Poke me when every other bug is (re)verified, and we'll make it go.
<roadmr> infinity: thanks so much, I'll do that and get back to you (probably tomorrow, some of those bugs are a bit time-consuming to verify)
<infinity> roadmr: Well, it's not just about who did the upload.  In this case, you would have had to drastically change the changelog.  I wouldn't worry about it, personally.  There are humans involved in this process for a reason.  We're generally smarter than the tools.
<infinity> (Generally)
<roadmr> infinity: heheh :) nice comment about humans. OK, I'll get a-verifying and trouble you for help once all verifiable bugs are done
<infinity> roadmr: The SRU is only 2 days old, no huge rush.  Get back to me when it's all happy.
<roadmr> will do, thanks :)
<stgraber> cjwatson: and one more of my e-mails for you to let through ubuntu-devel-announce ;)
<cjwatson> my kingdom for listadmin bash completion
<cjwatson> done
<stgraber> thanks :)
<infinity> cjwatson: You could always share the u-d-a moderation burden.
<cjwatson> 'cos it's so hard :)
<cjwatson> I thought at least a couple of other people had them, but maybe they're all mostly-emeritus by now
<slangasek> I suspect that's the case
<infinity> cjwatson: You, mdz, and Keybuk.
<slangasek> I think I have access to said queue, but receive no notifications :)
<infinity> cjwatson: So, yeah.  Just you.
<cjwatson> Do I smell two volunteers?
<infinity> cjwatson: You could always give it the same password as ubuntu-archive@ and those of us who care could add ourselves to the admin notifications.
<slangasek> I have no problem being added to the list of suckers
<cjwatson> Meh, or I could just give you the current password
<infinity> Or that.
<infinity> But then I need to remember it.  Which is sooo haaard.
<Laney> you need to teach it to listadmin ;-)
<roaksoax> soren: howdy! yeah i removed it from the agenda as its US Holiday today and wasnt gonna be able to make it!! cheers
#ubuntu-devel 2013-01-22
<Bluefoxicy> Error! Bad return status for module build on kernel: 3.5.0-22-generic (x86_64)
<Bluefoxicy> Consult /var/lib/dkms/virtualbox/4.1.18/build/make.log for more information.
<Bluefoxicy> run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.5.0-22-generic /boot/vmlinuz-3.5.0-22-generic
<Bluefoxicy> include/linux/device.h:116:2: error: invalid preprocessing directive #lefine
<Bluefoxicy> include/linux/device.h:121:40: error: unknown type name âstzuctâ
<Bluefoxicy> lol what
<infinity> Bluefoxicy: Looks like filesystem corruption or bad RAM.
<hyperair> #lefine indeed.
<Bluefoxicy> infinity: it just installed that
<Bluefoxicy> it downloaded a linux kernel image/header package I think
<hyperair> infinity: bad RAM sounds more likely. it's the 4th bit being flipped consistently.
<Bluefoxicy> weird.
<Bluefoxicy> wait, how would that happen
<Bluefoxicy> doesn't the kernel hash blocks it buffers?
 * hyperair shrugs
<hyperair> i've had memory corruption from using zcache before.
 * Bluefoxicy unpacks it again.
<Bluefoxicy> exact same result hum.
<hyperair> if you're using that you might like to disable it and see if it helps matters.
<hyperair> also try sysctl vm/drop_caches=2
<Bluefoxicy> KiB Mem:  15747100 total, 10308472 used,  5438628 free,   342340 buffers
<Bluefoxicy> KiB Swap:  7873520 total,        0 used,  7873520 free,  6556008 cached
<hyperair> eh well mem usage doesn't say anything.
<hyperair> check if dmesg complains about bad memory
<hyperair> sometimes the kernel notices.
<Bluefoxicy> odd  Segfaults a lot everywhere.
<hyperair> heh
<hyperair> have fun
<micahg> Bluefoxicy: go for memtest
<hyperair> yeah memtest
<hyperair> it sounds very much like bad mem now.
<Bluefoxicy> dropping caches seems to have fixed it.
<Bluefoxicy> I think I need a file system check.  :|
<Bluefoxicy> why oh why didn't i use lvm
<Bluefoxicy> i would take a snapshot and fsck it now.
<hyperair> nah
<hyperair> not fsck
<hyperair> if dropping caches fixes it, it's not a filesystem issue
<hyperair> it's a memory issue
<Bluefoxicy> i mean to make sure the disk doesn't have corruption from prior issues
<hyperair> do you have zcache enabled?
<hyperair> ah
<Bluefoxicy> no I have zswap but it's not swapping to it
<Bluefoxicy> zcache was terrible
<Bluefoxicy> it caused abberant behavior so I don't use it.
<Bluefoxicy> so on a completely different note
<Bluefoxicy> have you folks seen Pulp?
<hyperair> haha i had issues with zcache too.
<Bluefoxicy> (zcache was making Linux keep tiny, tiny file system caches so it was slow as hell)
<hyperair> hrmm, i didn't have that issue.
<hyperair> what i did get was weird intermittent short hangs
<Bluefoxicy> I was in the #pulp channel earlier
<hyperair> and dpkg corruption
<Bluefoxicy> they were discussing the plug-in to handle apt/deb repos
<Bluefoxicy> apparently that's coming soon.
<Bluefoxicy> so it'll be able to centralize both yum and apt repository caches and mirrors and push updates and software installation to Debian-based systems and yum/rpm systems
<Bluefoxicy> That should probably be a tasksel task on Ubuntu Server in the future ;|
<infinity> Bluefoxicy: fsck isn't going to catch the sort of corruption that bit-flipping causes.  Not in any way that won't do more damage when trying to fix it.
<infinity> Bluefoxicy: The best solution if you suspect this sort of pain is to back up immediately, fix the hardware problem, reinstall, and selectively restore/verify data you care about.
<Chipzz> Bluefoxicy: I doubt LVM would have helped in this case
<pitti> Good morning
<dholbach> good morning
<Laney> @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 dicussion 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: Laney
 * dholbach hugs Laney
<Laney> :-)
<Laney> 79 items :O
<dholbach> I'll join you in a bit - got some other stuff to take care of first
<dholbach> brb
<Laney> xnox: what did you find out about app-install-data-partner?
<xnox> Laney: I found out that it is, "just do it". But the next round of SRUs affects quantal, but quantal has one app-install-data-partner in -proposed (last time I checked) it would be great to verify and publish that first.
<mlankhorst> heh
<mlankhorst> infinity: last patch before 9.0 "configure.ac: Don't link gallium drivers with libdricore"
<xnox> Laney: the item to be sponsored is one of them (2 bugs) but they need to be applied on all supported releases.
<Laney> sounds like you're on it ;-)
<infinity> xnox: app-install-data-partner has some curious SRU exceptions.
<xnox> infinity: sure. but if it's fixing a bug of something not installing correctly because of it, I'd rather see somebody actually open software centre and verify that it does the right thing now =)
<infinity> xnox: That someone could be you.
<xnox> infinity: sure =)
 * xnox didn't get around to it, just yet.
<Laney> infinity: while you're here, bug #1064475 could do with an ubuntu-sru voice
<ubottu> bug 1064475 in crash (Ubuntu Quantal) "crash version is outdated. Needs to import Debian version of the package" [Medium,In progress] https://launchpad.net/bugs/1064475
<infinity> I could have sworn I gave smb or arges or someone an opinion on that months ago.
 * mlankhorst tries reverting don't build gallium against libdricore patch
<smb> infinity, We always get lots of opinion. :-P But yes, you did. I was about to get back and ask about some more specific steps forward.
<infinity> smb: Kay.  Catch me in the morning (well, your evening)?
<smb> infinity, I thought to do it via email which is a bit more persistent and asynchronous
<Laney> Can someone update the bug with a quick status update? It's the top item on the queue so I imagine people keep spending precious minutes looking at it.
<smb> Evenings and mornings are relative... right now an hour off but back to normal soon
<Laney> or remove the sponsors altogether if you're sorting it out between yourselves
<smb> Laney, I will add a comment
<Laney> merci
<mlankhorst> infinity: adding dricore makes zero difference to size for nouveau_dri.so (I measured it, it's actually 0 difference, which is amazing :D)
<infinity> mlankhorst: Uhm.  Then it's being linked both statically *and* dynamically.  Or nouveau_dri.so uses no dricore symbols (which seems impossible).
<infinity> smb: Sure.  Mail away.
<mlankhorst> well afaict the original patch also created a glsl.so
<mlankhorst> maybe libmesagallium.a needs to be shared
 * mlankhorst tries evil hack
 * jackyalcine watches and studies mlankhorst's evil hack
<OdyX> tkamppeter_: can you hint me about Debian #697970 and LP #872483 Apparently the Oki fix is in cups, but some users have a problem with an Epson Stylus Color 670; what would be the correct fix ?
<ubottu> Debian bug 697970 in cups "cups: printing gets wrong after some pages on Epson Stylus Photo 750" [Important,Open] http://bugs.debian.org/697970
<ubottu> Launchpad bug 872483 in cups (Ubuntu Oneiric) "laser printer only prints first job correct" [Medium,Fix committed] https://launchpad.net/bugs/872483
<mlankhorst> infinity: ok an evil hack that made libmesagallium shared did the trick, back to normal sizes
<mlankhorst> -rwxr-xr-x 1 mlankhorst mlankhorst 1,2M jan 22 11:05 nouveau_dri.so
<mlankhorst> I'll try to do a proper version now
<infinity> mlankhorst: \o/
<Laney> more SRU team comments requested in bug #1014732 - proxying: can an SRU change a conffile?
<ubottu> bug 1014732 in mysql-5.5 (Ubuntu Precise) "log_error not set in my.cnf, errors not written anywhere" [High,Triaged] https://launchpad.net/bugs/1014732
<mlankhorst> hm maybe that's why the dricore patch did what it did..
<rbasak> Laney: I discussed it with SpamapS and I believe he wanted it. SpamapS, around?
<Laney> rbasak: Righto; I'm happy to sponsor when someone decides so
 * rbasak writes to -devel
<mlankhorst> Ok with some hacking I don't need to build another shared object, and I can link gallium drivers against libdricore again by just including the missing gallium parts. It should decrease size slightly more compared to just building another object.
<xnox> stgraber: lxc is pure awesome.
<mlankhorst> 12M     shared2/
<mlankhorst> /tmp$ du -sh static
<mlankhorst> 34M     static
<mlankhorst> so, from 34m to 25m for shared gallium, and 25m to 12m for shared dricore re-enable :)
<zyga> kirkland: ping
<xnox> mlankhorst: you rock!!!!!
<mpt> jelmer, bug 680833 should be reopened for bzr-git, but I don't have permission to do it myself.
<ubottu> bug 680833 in bzr-git (Ubuntu) ""git-apply" does not add new files" [Medium,Triaged] https://launchpad.net/bugs/680833
<cjwatson> didrocks: would you mind sorting out bug 1102713?  I know it wasn't your upload that broke it, but barry isn't here ...
<ubottu> bug 1102713 in oneconf (Ubuntu) "package oneconf-common (not installed) failed to install/upgrade: trying to overwrite '/usr/share/oneconf/data/images/computer.png', which is also in package oneconf 0.2.9.1" [High,Triaged] https://launchpad.net/bugs/1102713
<didrocks> cjwatson: sure, doing that one now.
<cjwatson> ta
<didrocks> yw
<mlankhorst> woops, broke i915 with the patch. Good thing I test :)
<notgary_> Does anyone know how I can add events to the Fridge calendar http://fridge.ubuntu.com/calendars/
<mlankhorst> woops, the fix increases size from 11336 to 12708K, I'll see if I can get it back by building the thing shared
<cjwatson> ahasenack: bug 1060404 - does the instance in which you successfully tested the new grub-pc contain /boot/grub/grub.cfg?
<ubottu> bug 1060404 in lxc (Ubuntu Precise) "update-grub runs and fails in containers" [High,Triaged] https://launchpad.net/bugs/1060404
<cjwatson> (I'm trying to narrow down another report)
<Laney> @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 dicussion 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:
<ahasenack> cjwatson: the lxc container you mean?
<ahasenack> cjwatson: the linode machine does have /boot/grub/grub.cfg (my last comment in the bug), let me check the lxc one
<ahasenack> cjwatson: the lxc instance does NOT have /boot/grub/grub.cfg
<ahasenack> cjwatson: looking at /etc/init/container-detect.conf, I wonder if we shouldn't check for lxc specifically. Would grub fail on, say, openvz too?
<cjwatson> It will fail in any context where it can't figure out a full path to the filesystem that will work from bare metal
<cjwatson> So it will probably fail in any container
<cjwatson> ahasenack: Does your Linode machine actually use GRUB to boot?
<ahasenack> cjwatson: it uses "grub-pv" iirc
<cjwatson> (Well, where I say "bare metal", I mean "from the context where GRUB will actually boot")
<cjwatson> ahasenack: Right, so that's not Sebastian's case
<ahasenack> cjwatson: he didn't give more info yet, did he?
<cjwatson> Privately
<cjwatson> In your Linode instance, GRUB can evidently figure out a halfway plausible route to /boot/grub and thus succeeds
<ahasenack> ah
<cjwatson> Anyway, thanks, I have enough information from you to narrow things down no
<cjwatson> w
<ahasenack> as far as I understood it, pv-grub is an external grub what will eventually call the one inside the linode, or something like that
<cjwatson> Kiiiiiiiiiind of
<cjwatson> The details are complex and not important here :)
<ahasenack> :)
<mlankhorst> ok with shared-mesagallium back to good size
<mlankhorst> 11436 kb, vs broken 11336, and working 12708 kb
<jelmer> mpt: Fixed, thanks
<mlankhorst> cjwatson: ok it's ugly, but I think I can reduce the size of mesa again by using libdricore in the gallium drivers. saves about 5 mb on gzip
<cjwatson> nice
<mlankhorst> took a while to come up with a cleaner approach, it's still kind of messy. mesa is a mess between its old style hand-rolled makefiles and halfway through a conversion to autotools :/
<wjtaylor_> Sorry if this is the wrong forum. Are there any known issues with XT2 touchpads? I'm having issues in 12.04 clicking in nautilus. No one else can reproduce, so wanted to check with you all.
<seb128> jodh, hey, just for info https://wiki.ubuntu.com/FoundationsTeam/Specs/RaringUpstartUserSessions?action=diff&rev1=76&rev2=77 is wrong, X-GNOME-Autostart-Delay is used on login to delay start of a command, not on logout
<jodh> seb128: yeah, I did wonder about that :) Is there a way for an application to delay the logout then?
<seb128> jodh, no "delay" I think, there are at least 2 mechanism supported
<seb128> - the xorg session registration protocol
<seb128> but I guess that's going away when xorg is going away
<seb128> - http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.Inhibit
<seb128> gnome-session has an inhibit api which allows to inhibit logout
<seb128> that's useful for things like e.g cd recording are in progress
<xnox> what's the best way to talk to udev from python?
<xnox> pitti: ^ any recommendations?!
<seb128> jodh, ah, found back the name of the xorg protocol, "xsmp" ... it's implemented in http://git.gnome.org/browse/gnome-session/tree/gnome-session/gsm-xsmp-client.c
<seb128> jodh, that's what is used by e.g gedit to display the "you have unsaved work, do you want to save it before logging out"
<mlankhorst> cjwatson: is it ok to break building in parallel? what I'm doing is a bit of a hack and I don't see a clean way to declare a dependency
<pitti> xnox: use gudev, and its gir through introspection; hang on, digging out an example
<pitti> xnox: hah, it's right on https://live.gnome.org/PyGObject/IntrospectionPorting
<pitti> xnox: http://www.michaelwood.me.uk/blag/2012/11/23/python-pygi-gudev-example/ is another one
<pitti> xnox: it's really the C API from http://www.freedesktop.org/software/systemd/gudev/
<jodh> seb128: ok, thanks. We need to find a way to tie this into the design as by default Upstart is only going to wait for up to 5 seconds for gnome-session to after the initial SIGTERM.
<xnox> pitti: thanks. I was about to dive into pyudev....
<seb128> jodh, good point, do you think there is any way to block on gnome-session to exit/send a signal?
<jodh> seb128: actually, it's not a problem assuming gnome-session only calls ConsoleKit to request system shutdown after its shut down its clients.
<pitti> xnox: <jedi wave>that's not the library you are looking for
<xnox> pitti: yes, master.
<pitti> xnox: the Source is strong in you, young Jedi!
<hrw> hello
<hrw> guys: in normal (X)Ubuntu installation when kernel is booted with 'quiet splash' when should splash appear?
<hrw> I have acer aspire one 722 here (amd c-60 with radeon integrated) and I have: black, off, black, lightdm
<cjwatson> mlankhorst: Yes
<xnox> hrw: as far as I remember the xubuntu one "splash" is missing, hence it's black (the second black I believe).
<hrw> on shutdown I have xubuntu splash
<cjwatson> mlankhorst: As long as your debian/rules doesn't honour DEB_BUILD_OPTIONS=parallel (either directly or via dh --parallel)
<xnox> hrw: funny.
<hrw> xnox: yeah. but my wife will use this machine...
<xnox> hrw: I only have limited knowledge of plymouth/boot stack & I am not interested in digging into xubuntu vs ubuntu. It works in ubuntu so check what's missing / different =/
<hrw> sure
<ogra_> hrw, what release ?
<hrw> ogra_: 12.10
<hrw> ogra_: will all recent updates
<xnox> hrw: as far as I remember the studio splash works correctly, and that's based on top of xubuntu........
<hrw> xnox: I am installing ubuntulogo theme now
<xnox> hrw: but studio have their own plymouth theme.
<ogra_> hrw, try something: add FRAMEBUFFER=Y to /etc/initramfs-tools/initramfs.conf, re-roll the initrd and see if that changes something
<hrw> ogra_: thanks, will check after reboot
<mlankhorst> cjwatson: hm I guess I'll spend some more time investigating then
<ogra_> i'm hunting down a race between console-setup and plymouth on arm since some time that manifests with similar issues
<hrw> ogra_: arm curse ;D
<ogra_> adding FRAMEBUFFER=Y forsec the initrd to run console-setup first and plymouth survives
<cjwatson> mlankhorst: Well, if you don't see parallel anywhere in debian/rules then it should be fine
<ogra_> at least here
<ogra_> *forces
<mlankhorst> it's been a bit of a mess though, I think I got a cleaner solution now
<hallyn> slangasek: do you object to bug 1103022 ?
<ubottu> bug 1103022 in udev (Ubuntu) "70-udev-acl.rules needs to put g+rw on /dev/kvm" [High,Confirmed] https://launchpad.net/bugs/1103022
<hrw> ogra_: no changes
<ogra_> hrw, thx, i had some hope
 * hallyn biab
<mlankhorst> yay local build finished correctly
<hrw> added 'break=modules', landed in busybox on framebuffer. ctrl-d then. black, splash, lightdm
<ogra_> hrw, weird, thats what i meant to fix with the FRAMEBUFFER option
<ogra_> break calls console-setup forcefully
<hrw> booting with plymouth:debug == splash
<ogra_> hrw, yeah, points to a similar race i think
<hrw> looks like
<hrw> the worst part is that after big ACER logo you have no idea is it booting or crashed. have to wait ~minute to get lightdm
<ogra_> ogra@nexus7:~$ cat /etc/initramfs-tools/conf.d/framebuffer
<ogra_> FRAMEBUFFER=y
<ogra_> thats how i fix it on the nexus7
<ogra_> FSVO "fix"
<ogra_> i dont get why that didnt work for you when adding it to initramfs.conf
<ogra_> should have the same effect as "break=" (which calls "panic()" which in turn runs console-setup)
<hrw> btw - how to get rid of most of kernel drivers from initramfs?
<mlankhorst> cjwatson: http://paste.ubuntu.com/1559853/ is the final patch I have in mind, but I want to test some more locally first in a ppa so all drivers at least load correctly :P
<hrw> anyway - food
<mlankhorst> full debdiff just enables that patch and adds back a missing rm -f libgallium.so since it wasn't meant to be linked outside of mesa
<mdeslaur> Is there a way for a package to state that it would prefer to keep a user modified conffile, to prevent the user from getting a conffile prompt?
<xnox> mdeslaur: maybe it should be a config file instead then.
<xnox> (aka generated with postinst script)
<xnox> and not touched if upgrading...
<mdeslaur> xnox: yeah, but then you lose the nice conffile handling if you do have an important change in a subsequent update
<cjwatson> conffiles don't have the sophistication you're asking for
<mdeslaur> cjwatson: ok, thanks...that's what I suspected
<xnox> pitti: it's very nice, thank you =)
<mlankhorst> ok i915 unbroken :)
<mlankhorst> cjwatson: uploaded mesa precise4, should hopefully fix all size issues with mesa, won't spend more time on it unless it's broken :P
<cjwatson> cool, thanks
<dobey> barry: software-center doesn't need the >= 0.3 does it? it doesn't use new API, it's just that the oneconf packaging changed, so it needs to explicitly require the python-oneconf bit, right?
<barry> dobey: good point, yes, that should be enough
<dobey> barry: great; the >= 0.3 made the daily builds not installable on older ubuntus
<barry> dobey: cool.  will you fix that or should i?
<ev> apw: https://launchpad.net/ubuntu/+bugs?field.tag=apport-kerneloops
<dobey> barry: i will
<barry> thanks
<dobey> i'll also probably convert it to a non-native package soon
* cjwatson changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<barry> dobey: nice
<kirkland> zyga: howdy!
<zyga> kirkland: hey, I have a question for you, how do you manage byobu sources to allow it to live both in git and bzr sensibly?
<xnox> kirkland: manpages.ubuntu.com is now deployed from lp:~ubuntu-core-dev/ubuntu-manpage-repository/ubuntu such that more people have commit rights.
<xnox> kirkland: and it only has distro name updates & font name change s/UbuntuBeta/Ubuntu/
<kirkland> xnox: that's great!
<kirkland> xnox: I'm very happy about that :-)
<kirkland> zyga: I'm using github as basically a co-lo for my launchpad projects
<dobey> has anything changed in pbuilder (or pbuilder-dist) in raring with regards to ~/.pbuilderrc? i've put OTHERMIRROR= in ~/.pbuilderrc, but "pbuilder-oneiric update" doesn't seem to be picking up that value
<zyga> kirkland: could you be more specific? can you accept merge/pull requests from both? which one is primary?
<xnox> kirkland: if only you can mark it "devel series" or like set a team as the project driver/maintainer. Something like core dev. But I guess there is no pressing issues with that service now..... e.g. it runs and all releases are up to date.
<kirkland> zyga: I have a new script in bikeshed called "dual-push";  when I push to bzr, I also push to git
<kirkland> zyga: bzr is primary
<kirkland> zyga: I haven't yet accepted a merge/pull from github, but that's the general idea -- I'd like to encourage contributions from both
<kirkland> zyga: if you have a pull request, I'm interested in testing out that workflow?
<kirkland> zyga: http://bazaar.launchpad.net/~bikeshed/bikeshed/trunk/view/head:/dual-push
<kirkland> zyga: pretty simple functionality right now
<zyga> thanks, I'm interested in that a lot
<kirkland> zyga: but my goal is to be able to accept merges/pulls from either github or lp
<zyga> kirkland: I use git-lp that I wrote to collaborate, so to speak
<Laney> xnox: auto deployed?
<kirkland> zyga: awesome -- I'd love to fork out dual-push to a separate project, outside of bikeshed, and use it to manage this
<wjtaylor_> http://paste.ubuntu.com/1560076/
<zyga> kirkland: there are some issues with making that possible
<kirkland> zyga: oh, yeah?
<kirkland> zyga: let me take a look at that
<zyga> kirkland: the bzr pieces were not finished
<zyga> kirkland: and with the state of bzr maintenence it's not likely they ever will
<xnox> Laney: well. almost =)
<zyga> kirkland: but if you find out about anything related to this topic I would appreciate if you could ping me about it
<kirkland> zyga: yeah, I've always had a ton of trouble with LP autoimporting other vcs's
<kirkland> zyga: the only thing that's ever worked for me
<xnox> Laney: in the end I just updated the configs by hand, but they have raring already.
<zyga> kirkland: I remember using experimental mode in bzr-git a few years ago where I could push/pull to git repos from bzr with all meta-data
<kirkland> zyga: is fast-export | fast-import
<zyga> but that code was never enabled
<Laney> heh
<zyga> kirkland: don't get me started, bzr-fastimport is so broken today
<zyga> kirkland: the only reason I wrote git-lp is to work around the bugs in bzr-fastimport so that I get a subset which works
<zyga> kirkland: I tried fixing it but I am unable to write tests that would be accepted upstream, bzr's internals are too complex for my limited time now
<zyga> kirkland: https://github.com/zyga/git-lp/blob/master/git-lp
<xnox> zyga: github has a lot of git-[bzr|lp[-ng]] wrappers and forks..... =/
<zyga> xnox: I looked at many of those, they all depend on fastexport
<zyga> xnox: so far, only bzr-git is actually genuinely different
<zyga> xnox: and unfinished
<xnox> zyga: how does your's work?
<xnox> zyga: or is it still fastimport but with hacks and what not
<zyga> xnox: it also uses fastexport but 1) only in a very limited way (with rationale) and 2) I carry a small patch for bzr (that I am unable to upstream), I don't know about anyone that uses bzr+git without a patch like that
<zyga> xnox: my code is really small, I encourage you to read it
<cjwatson> Mm, I used fastexport for several things a while back and accumulated a giant patch stack
<zyga> kirkland: have you ever seen bzr crashing on anything you do?
<cjwatson> Some of which I managed to upstream but I think not all of it, because damn it was complex
<xnox> zyga: cjwatson: I too have a small stack of patches.....
<zyga> cjwatson: which parts were complex? bzr?
<cjwatson> I like the idea, it's much easier to debug something like fastexport
<cjwatson> no, fast*port itself
<zyga> could you guys share patches please?
<zyga> I'm totally interested
<xnox> maybe we should push them somewhere and create a robust bzr2git.....
<rbasak> What's bad about fastexport? I have yet another tool (unpublished) that uses fastexport as minimally as I could and just works. But it currently works in one direction only
<xnox> (and reverse, if there is a desire to push things back to launchpad)
<cjwatson> I think mine ended up on https://code.launchpad.net/bzr-fastimport
<cjwatson> Hopefully
<zyga> the problem that I see is that some of those need to get into bzr tree and that is hard without someone that is willing to spend effort on getting to know bzr internals to write proper tests
<zyga> cjwatson: so have all of your patches landed upstream or are they just pushed as a branch of bzr-fastexport?
<cjwatson> If it's at all useful, my big-blob-of-stuff patch appears to be http://paste.ubuntu.com/1560105/
 * zyga looks
<cjwatson> I don't really remember any more how much got upstream and don't think I have the time to look right now
<cjwatson> But maybe you can take it from there if you care ...
<zyga> cjwatson: too bad it's not a bunch of commits with rationale, it's harder to track that
<cjwatson> Some of that's probably backporting to whatever version of bzr I was using at the time
<zyga> cjwatson: but still valuable, I'll read it in detail
<cjwatson> Yeah, the problem with this kind of thing was that I was using it one-shot
<zyga> cjwatson: what was your main use case?
<cjwatson> So didn't have a lot of motivation to tidy up later
<zyga> cjwatson: and is it something that you still use often?
<cjwatson> Generally, one-shot conversions of my various Debian package repositories from other formats (usually svn)
<cjwatson> Not the sort of thing you tend to use much after you're finished
<zyga> I see
<cjwatson> The existence of https://code.launchpad.net/~cjwatson/bzr-fastimport/git-directories (merged) suggests that I used it for git at least once
<zyga> my main use case is git-bzr co-existence (I wish lp had support for git)
<cjwatson> I don't use fast*port anywhere in any kind of continuous mode at the moment
<zyga> I see, thanks
<zyga> xnox: how about your patches?
<rbasak> zyga: I have a git native remote for bzr that seems to work perfectly in the bzr->git direction. My problem with existing tools was that they didn't integrate with git properly, and the whole point of me wanting git is for more advanced stuff that the existing tools broke for.
<cjwatson> +        if dirname == 'openbsd-compat/regress' and '200912' in dir_file_id:
<cjwatson> +            assert False
<cjwatson> *cough* spot the hack for openssh ...
<cjwatson> That must have been some kind of insane CVS weirdness, I guess
<zyga> rbasak: git-native remote for bzr, so you use bzr repos with git, correct?
<zyga> rbasak: what is the name of your remote?
<rbasak> zyga: I called it git-bzr-nih, but not published anything
<zyga> rbasak: what tech is it using?
<rbasak> bzr fastexport with a bit of hackery. It maintains a map of git commit hash to bzr revid, and only calls bzr fastexport for revids it doesn't already have
<rbasak> (it parses the map file out that bzr fastexport emits)
<zyga> rbasak: ah, sane, I always could not understand why bzr-fastexport used revno (which is totally useless in face of history edits)
<zyga> rbasak: cool, would you mind sharing that?
<zyga> rbasak: have you encountered anything that you had to patch in bzr/bzr-fastexport?
<zyga> (apart from the obvious feature you've mentioned)
<zyga> obviously
<rbasak> To go the other way I use git format-patch and a bzr-am script I wrote that does the same thing as git-am. No patching in bzr/fastexport needed
<rbasak> I also have a working git cache mechanism since bzr fast-export is so slow
<zyga> ah, cool
<rbasak> It's not assembled in a way that's easy for others to use since I've not spent time on it, but you can have the pieces :)
<zyga> does it work with stuff like merges? using raw bzr-am means that you loose parent hashes
<zyga> rbasak: cool, I'll take them please
<rbasak> Merges work in the bzr->git direction. But the git->bzr direction is completely manual - I've not done anything about it apart from the bzr-am I was using before. So in that direction only linear commits work, but that's enough for me since anything I want to submit as an MP tends to be linear anyway
<rbasak> I might write something to do git->bzr properly one day
<toabctl> Laney, I try to play mp3s with raring but I get: Error: Your GStreamer installation is missing a plug-in.
<Laney> play them with what?
<toabctl> Laney, with gst123
<Laney> do you have the recommends installed?
<toabctl> Laney, I changed nothing in /etc/apt/ so recommends should be installed
<toabctl> Laney, sorry. my fault. I'm in an jhbuild session. the problem has nothing to do with ubuntu.
<Laney> heh
<jdstrand> @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: jdstrand
<fm__> i would appreciate any comment on http://askubuntu.com/questions/245875/how-do-i-get-high-resolution-icons-in-unity-for-my-application-without-a-deskto
<sarnold> fm__: I think you ought to stick the source code of your reproducer (comment 5) into the question on askubuntu -- source code often helps lubricate discussions
<fm__> sarnold, source is in the upstream bugreport. see https://www.willuhn.de/bugzilla/show_bug.cgi?id=1310#c5
<sarnold> fm__: .. that's the source that I think should be in the askubuntu question :)
<fm__> sarnold, sorry now i understand ...
<sarnold> hehe :)
<fm__> sarnold, ok i added the code
<fm__> thanks for looking at it
<sarnold> fm__: woot :) good luck :)
<dobey> barry: hrmm, is oneconf-query in raring supposed to be using python3 now, or still python 2.7?
<achiang> infinity: hi, is this bug arch specific? #1081734
<infinity> achiang: Shouldn't be.
<achiang> infinity: so we could test that package on precise/amd64 and it would be valid for SRU testing?
<achiang> infinity: i guess i'm asking because this was brought to my attention in the context of tegra3, and i'm seeing if i can punt the testing to our x86 team, as we have no cycles here to test.
<infinity> achiang: I'll be SRUing for that (and other bugs) today or tomorrow, and yeah, it should be reproducible on x86, I believe.
<achiang> infinity: ok, do you need me to go find someone to test it or do you have it covered?
<infinity> achiang: Always happy to have testers.
<achiang> infinity: alright, let me go see what i can do
<dkessel> testing what? :) i am on x86...
<infinity> achiang: It's not actually uploaded yet, so don't get too ahead of ourselves. :)
<achiang> infinity: right, but i actually need to find victims^Whelpers *before* it's uploaded anyway. :)
<achiang> infinity: one more dumb question, do you want me to find testers for before the upload or after for SRU verification?
<infinity> achiang: Well, I'll need to get it accepted first, so I dunno.  If that goes quickly, timing doesn't matter much.  If the review process takes a while, you could be jumping the gun.
<achiang> infinity: ok, thanks.
<achiang> infinity: i guess just poke me when you need testers
 * infinity nods.
<micahg> could someone with better knowledge of initramfs tell me if I should worry about backporting amd64-microcode to precise since it might be affected by debian 688794, here's the diff from the workaround in raring: http://launchpadlibrarian.net/129138637/amd64-microcode_1.20120910-2_1.20120910-1~ubuntu12.04.1.diff.gz
<ubottu> Debian bug 688794 in initramfs-tools "[initramfs] scripts/hook-functions: breaks boot if /tmp noexec" [Important,Open] http://bugs.debian.org/688794
<dobey> how can i tell sbuild to pull packages from a PPA, for a single build?
<micahg> I use --chroot-setup-commands='apt-get install -y python-software-properties' --chroot-setup-commands='add-apt-repository ppa:foo/bar' --chroot-setup-commands='apt-get purge -y python-software-properties' --chroot-setup-commands='apt-get update'
<micahg> dobey: ^^
<dobey> micahg: thanks, trying that now
<dobey> hrmm, sbuild --build=i386 -A seems to keep failing for me on amd64 host with i386 schroot :-/
<micahg> dobey: --arch i386 -A
<dobey> micahg: ah, looking at the man page i didn't see --arch; adding --host=i386 helped though. but now it's failing to build for other reasonsâ¦ any idea what this means? http://pastebin.ubuntu.com/1560824/
<micahg> dobey: nope
<micahg> I don't have host on sbuild in precise
<dobey> ah i'm on raring
<dobey> --arch i386 seems to work as well; i think that's unrelated to the failure there though
<dobey> anyway, brb; gotta run for a few
<cjwatson> dobey: You definitely don't want --host.  That's for multiarch cross-building, not for a case where you have a full chroot for the other architecture and can execute all its binaries.
<cjwatson> dobey: For example, --build=amd64 --host=armhf is for cross-building to ARM.
<zykes-> can anyone help me on the differences on a rpm repo vs a debian repo in regards to structures ?
<zykes-> like http://ubuntu.uib.no/archive/dists/hardy/ < is one repo I guess vs http://centos.uib.no/6/centosplus/x86_64/ in a yum format ?
<cjwatson> zykes-: I don't know the RPM terms.  In conventional aptish terms, http://ubuntu.uib.no/archive/ is a repository while http://ubuntu.uib.no/archive/dists/hardy/ is a suite
<zykes-> cjwatson: how's suite compared into a yum repo ?
<cjwatson> A suite being a combination of release series (hardy) and the nature of the upload stream (so hardy is the release itself, hardy-updates for recommended updates, etc.)
<cjwatson> I have no experience with yum repositories
<cjwatson> There may not be a single URL equating to the example you gave - there'll be .../main/binary-amd64/, .../restricted/binary-amd64/, etc.  main and restricted (etc.) there are called "components", and slice up the set of packages into very broad licensing/support categories
<cjwatson> The division into architectures goes underneath components
<zykes-> yeh
<zykes-> i'm wondering a bit because of https://github.com/ekarlso/pulp_deb
<zykes-> if you wondered why
<cjwatson> I remembered you had a project to try to present a unified view, yes
<zykes-> trying to hook in debian support for pulp, but pulp thinks of 1 repo as 1 thing and doesn't care for components, arches etc
<cjwatson> Well, what does it expect a repo to be able to do?
<cjwatson> (BTW I'm about to go to bed, perhaps could continue this by mail, cjwatson@u.c)
<bdrung> Laney: will you deal with bug #954352?
<ubottu> bug 954352 in gtk+3.0 (Ubuntu Raring) "Enable wayland backend" [Wishlist,Triaged] https://launchpad.net/bugs/954352
<dobey> cjwatson: ok. any idea about the error from dh_auto_build that i'm getting? i wonder why it's trying to create '/sbuild-nonexistent'; and why it isn't failing like that on the lp builders
<jdstrand> @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:
<dobey> or anyone else? am a bit stumped with http://pastebin.ubuntu.com/1560824/ right now
<micahg> dobey: a little gooogling got me this: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682641#15
<ubottu> Debian bug 682641 in src:pycode-browser "pycode-browser: FTBFS: LyX: Creating directory /sbuild-nonexistent/.lyx/" [Serious,Fixed]
<RAOF> dobey: I suspect something is trying to log to $HOME, which deliberately isn't there under sbuild?
<dobey> hrmm
<dobey> but don't the launchpad buildds runn under sbuild? do they have $HOME set to a real directory?
<micahg> nothing should be using $HOME in a build anyways
<micahg> jdstrand: apparently imagemagick needs a rebuild and could use a merge from Debian, I was wondering as you TIL if you're working on that
<dobey> micahg: i generally agree, but i'm just taking a source package from a ppa on launchpad, which failed to build for another reason, and trying to build it locally under sbuild, since pbuilder apparently won't let me use OTHERMIRROR on oneiric
<micahg> dobey: try setting $HOME in the invocation line to temporarily work around it
<cjwatson> dobey: IME on Debian buildds HOME has been arbitrarily set or not.  You shouldn't assume anything either way
<slangasek> in fact, they used to be permuted across architectures to catch different classes of misuse
<cjwatson> dobey: The launchpad buildds use an old version of sbuild, to be found in lp:launchpad-buildd
<dobey> cjwatson: i'm not assuming anything either way. i just want to solve the problem i'm trying to solve, and not spend 3 days fixing other problems so i can finally get to debugging my original problem :)
<cjwatson> This could be a detail that differs
<cjwatson> There won't be many such details - honestly you might as well just fix it and get it out of the way
<slangasek> (HOME unset; HOME pointing to a root-only directory; HOME pointing to a non-existent directory; etc.  Moral: fix your packages to not rely on the environment's HOME)
<cjwatson> It'll be a lot easier than trying to get a pedantically correct lp-buildd setup locally
<cjwatson> Since modern sbuild is so much better in other ways
<cjwatson> (And maybe one of these days LP will get an upgraded sbuild ...)
<bdrung> cjwatson: what do you think about my patch for bug #1012439?
<ubottu> bug 1012439 in debootstrap (Ubuntu) "carve out distro information to distro-info package" [Undecided,Confirmed] https://launchpad.net/bugs/1012439
<cjwatson> bdrung: Please do not upload that to Ubuntu.  I'll have a look when I'm not going to bed, but I must warn you that I'm not keen on this.
<cjwatson> There's no guarantee at all that a future release won't require a change in the debootstrap scripts.  Past performance (and only since gutsy) is no guide to future performance.
<bdrung> cjwatson: i wasn't going to upload the change soon, but getting a review before.
<bdrung> cjwatson: so a warning should be printed?
<cjwatson> And in that case using distro-info will make it look like it will work but create possibly very subtle and hard to fix bugs.
<cjwatson> Or you could just leave well alone :)
<cjwatson> I don't really see a bug to be fixed other than "we should SRU debootstrap more vigorously".
<cjwatson> But bed.
<dobey> so this code isn't exactly using HOME at this stage. it's that python-distutils-extra's auto setup stuff imports *all* of the modules, and some of those modules do things on import
<infinity> micahg: That amd64-microcode backport should be fine, but we really might want to look at gettting the kernel team involved in SRUing rather than backporting microcode packages.
<micahg> infinity: it's not in precise
<infinity> micahg: Sort of falls into the same general realm as linux-firmware, which we SRU for enablement and fixes.
<infinity> micahg: Yeah, I know it's not.
<micahg> infinity: ok, should I talk to the kernel team or accept the backport
<infinity> Well, I guess since they're both in multiverse anyway, maybe they're not all that often used/referenced.
 * infinity shrugs.
<infinity> It still feels like something that falls under enablement SRUs rather than backports, but...
<micahg> infinity: it's in multiverse since it's free to distribute, but not modify AIUI
<micahg> well, in either case, it'll show up the same way in software center since there's no previous version
<infinity> Right, I was pointing out that it's in multiverse rather than restricted.  ie: we don't support or rely on it in any way.
<micahg> ah, ok
<infinity> Err, wait.
<infinity> Why are you backporting an older version without the workaround?
<micahg> infinity: the workaround would need to be SRUd to quantal or backported to quantal (would vote for SRU in this case), but if it's not an issue in Ubuntu, I wouldn't bother
<infinity> It should be SRUd to Q, yes.
<infinity> I forgot you can't backport from devel releases.
<infinity> s/can't/don't/
<micahg> it sounds like it only affects people that know how to break their systems (i.e. not default)
<slangasek> you don't?  I thought that was the norm
<infinity> The bug is quite real and just as valid on Ubuntu.  We should SRU it back.
<micahg> we backport through releases with an upgrade path
<infinity> Given the dependencies of the package, I'd almost be tempted to just copy it to quantal-proposed from raring, honestly.
<micahg> infinity: I don't mind preparing an SRU, I'll get it retested once that's in then, thanks
<infinity> The only change between Q and R is that one bugfix, and the package doesn't have any compiled code.
<micahg> infinity: ok, you just want the paperwork then?
<infinity> micahg: I'm not even convinced I want the paperwork (can't do a bug closure on a copy with nothing in the changelog anyway), if you can actually test before/after in any meaningful way.
<infinity> micahg: If it's going to need third-party drive-by testing then, yeah, a formal SRU will be better.
<micahg> infinity: well, if your SRU hat tells you the copy is fine, it sounds like it makes sense
<infinity> micahg: I have many hats agreeing that the copy is just fine, so long as we can get a quick test that the package DTRT.
<infinity> (And, honestly, if it has users at all, they'd be telling us that the raring one, with its 4 lines of bugfix, is broken)
<micahg> infinity: as I don't use the package, I couldn't say one way or the other
#ubuntu-devel 2013-01-23
<jdstrand> micahg: re imagemagick> hi! no, I'm not actively working on it
<pitti> Good morning
<stgraber> good morning pitti (my usual reminder that going to sleep for a bit might be a good idea ;))
<pitti> stgraber: heh, happy to be of service :)
<randimiller> Are there any mentor programs for someone that wants to start contributing?
<randimiller> Looking to challenge myself a bit more, so looking at contributing to a linux distro.
<xxtjaxx_> Quick question: Ubuntu uses update-alternatives right?
<infinity> xxtjaxx_: Yes.
<xxtjaxx_> infinity: Thanks
<magn3ts> Would it be possible to tie into dbusmenu to dynamically insert an entry in GtkMenus across applications to create a special menu that would enable HUD like functionalities in non-Unity environments?
<magn3ts> I'm assuming the same way GTK was patched to push stuff into dbusmenu, one could also patch it to create a new menu that can scrape back from dbusmenu and then provide search functionality? Or maybe if there is a libhud or something that one could directly tie into ?
<magn3ts> Of course the "Developing for the HUD" sections of the wiki are bone-dry :(
<dholbach> good morning
<scientes> the raring daily build for 1-22 doesn't boot
<scientes> live cd
<scientes> or rather, mouse but no installation windows
<scientes> oh wait, nvm.....just taking forever
<Laney> bdrung: feel free to do it
<Laney> don't forget to commit to the ubuntu-desktop VCS
<doko> jodh, about 1103414, is this reproducible for you locally?
<jodh> doko: I'll retry my build...
<doko> jodh, please attach the preprocessed source, and the command line options used (and please make the build verbose by default)
<jodh> doko: ack.
<dholbach> @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: dholbach
<ev> jodh: do you think we'll get upstart inotify events in raring?
<jodh> ev: well, it is in plan, but more teetering on the edge than centre-stage atm.
<ev> jodh: noted; thanks!
<ev> mpt: whenever you have a free moment, I'd appreciate your thoughts on whether we should modify the firefox crash reporting dialog: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1064395
<ubottu> Ubuntu bug 1064395 in apport (Ubuntu) "Apport should still send reports to daisy.ubuntu.com for binaries in the blacklist" [Undecided,New]
<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, dholbach
<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, dholbach, mdeslaur
 * dholbach hugs mdeslaur and herton
 * mdeslaur hugs dholbach
<dholbach> :-)
<sveinse> How does the dpkg trigger work? On an ubuntu-arm precise target I see a few "Processing triggers for initramfs-tools" and often the update-initramfs is run multiple times duing the same apt-get update. Isn't the trigger mechanism built to avoid exactly that?
<sveinse> And just now I installed a custom package which installs something into initramfs-tools. dpkg reports that "Processing triggers for initramfs-tools" like it should, but it does not run update-initramfs
<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: dholbach, mdeslaur
<mpt> ev, done
<ev> mpt:  thanks
<k-s> doko: hi, do you have some minutes to query about ubuntu's linker?
<k-s> doko: I'm trying to get our project (EFL) to behave in an uniform way in multiple systems, but seems I cannot get as strict as Ubuntu's linker
<k-s> doko: even giving -Wl,--no-copy-dt-needed-entries -Wl,--as-needed everywhere, just on Ubunut it fails with DSO, while on Fedora, Arch and others it compiles without errors
<k-s> doko: so if you know how to force the DSO everywhere, I'd like to apply this to our project
<k-s> doko: is ubuntu using gold or the traditional linker? Any changes to libtool?
<rbasak> k-s: I'm not confident in the answers I'd give for your questions, so best to wait for someone else. But in the meantime, are you familiar with http://wiki.debian.org/ToolChain/DSOLinking? It's what I use as a reference to fix lots of build failures.
<k-s> rbasak: yeah, did look into it.
<k-s> rbasak: and in the one from fedora as well
<k-s> strange part is that fedora works, ubuntu doesn't (to cause the error)
<rbasak> k-s: pastebin the error please?
<rbasak> (and the linker command line)
<k-s> rbasak: http://pastebin.com/ZnmkASs0 from an user
<k-s> rbasak: the same configure/Makefile worked for Fefora, Arch and Gentoo
<k-s> oops, he said there is another log, I'm waiting for his new pastebin
<dholbach> can somebody please reject https://code.launchpad.net/~ben-kietzman/ubuntu/quantal/yasm/fix-for-1064341/+merge/140267?
<stgraber> dholbach: done
<dholbach> thanks stgraber
<k-s> rbasak: http://pastebin.com/QiU4fcRp using libeet.la http://pastebin.com/CxFL0cNZ
<k-s> rbasak: basically from my logs, Ubuntu's libtool isn't emitting the 'dependency_libs' parts. Although it IS used by 'relink_command' at the end, it's not being used to compile
<k-s> rbasak: then I wonder: any patch to libtool?
<rbasak> k-s: is eina_iterator_next defined in libeina.so.1 as it says? In that case don't you need a -leina? This is on the edge of my knowledge so I might be missing something here.
<k-s> rbasak: it is
<k-s> rbasak: it is in libeina, which is a dependency for libeet.la as stated in the second pastebin
<k-s> rbasak: I'm not even getting in the merit if it should or not emit libeina because it's a dependency of libeet
<k-s> rbasak: I'm trying to understand why your libtool is different from all other distro
<k-s> rbasak: if it's a flag I can turn on, or it's a patch
<dholbach> @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
<k-s> rbasak: will have to go for 30 min or so, please reply to my nick so I can find it when I'm back.
<k-s> rbasak: thanks!
<stokachu> cjwatson: i am attempting to do a merge/fix conflicts for console-setup, is that ok with you?
<rbasak> k-s: I think we're just less liberal in accepting input that isn't quite right, which other distros (currently) don't mind about. I guess this is a libtool issue rather than directly a linker one? Now we're past the edge of my knowledge and I'll have to let someone else answer - sorry. If you don't get an answer here, please try ubuntu-devel@lists.ubuntu.com. It's moderated but you've got an on-topic Ubuntu-specific issue so it's the right venue an
<rbasak> d someone should let it through.
<cjwatson> stokachu: TBH I'd prefer you didn't, it's really complicated and full of very delicate interactions with the rest of the installer
<cjwatson> stokachu: For many packages I'd be fine, but console-setup is one where experience has taught me I need to line-by-line the whole thing
<stokachu> ok no worries, so ill just pick another package then
<stokachu> cjwatson: how about aptitude? looks to be only diff changes
<stokachu> mterry: do you mind if i work on the merge fixes for aptitude?
<mterry> stokachu, please do  :)
<stokachu> cool thanks!
<mterry> stokachu, it might be complicated too, I don't recall
<stokachu> mterry: the report shows 2 files needing change
<mterry> stokachu, k
<cjwatson> stokachu: "only diff changes"?
<cjwatson> stokachu: But it's fine by me
<doko> k-s, rbasak: the .la file references a file i n /home/<something> while you /opt/lib/<something> is searched. are these incompatible libs? looks like a local issue
<stokachu> cjwatson: yea the report just showed 2 files with diff conflicts
<rbasak> doko: BTW, while you're here, when do you next plan to merge python2.7 please? Bug 1097783 causes a genshi FTBFS, now fixed (trivially) in upstream 2.7 tip. Nothing urgent, but there's a second cause for the genshi FTBFS there's no point in fixing until python is fixed.
<ubottu> bug 1097783 in genshi (Ubuntu) "re module apis return longs now" [High,Triaged] https://launchpad.net/bugs/1097783
<rbasak> Or we could cherry-pick it I suppose. Not worth it if you're planning another merge though.
<mdeslaur> do we still need to set the pocket to -proposed for SRUs to stable releases, or does that get handled automatically now?
<Laney> it'll get rewritten
<cjwatson> Yeah, you can do either
<cjwatson> I've been getting into the habit of just writing "precise"
<stokachu> mterry: so when i do a merge with bzr merge debianlp:aptitude everything applies cleanly :\
<stokachu> but the report shows conflicts so is the report outdated on merges.ubuntu.com?
<cjwatson> merges.ubuntu.com is not necessarily as smart as bzr
<mterry> Yeah.  I don't typically use bzr for merges, so I'm not as familiar with its workflow, but I could believe it knows better.  Still probably good to double check that the changes you would have made are in the merged bzr branch too
<stokachu> ok ill use the grab-merge tool and compare, if everything is good ill create a merge bug for this ok/
<stokachu> *?
<cjwatson> Daviey: do you think somebody on the server team could verify that the fix for bug 901600 meets your needs?
<ubottu> bug 901600 in grub2 (Ubuntu Precise) "Allow /etc/default/grub overriding via /etc/default/grub.d/" [High,Fix committed] https://launchpad.net/bugs/901600
<cjwatson> shouldn't take very long
<stokachu> mterry: interesting, doing grab-merge has the latest changes but debianlp does not
<cjwatson> You might want to just ignore bzr for this if it's out of date
<stokachu> ok
<xnox> stokachu: do bzr merge => generate debdiffs against debian & compare with previous old ubuntu to old debian debdiff.
<xnox> stokachu: sometimes bzr is smart and actually does merge everything right.
<cjwatson> xnox: bzr merge doesn't help when the import into lp:debian/... has failed :)
<xnox> =))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
<cjwatson> Hmm, but it looks up to date
<cjwatson> stokachu: So, I'm not sure what you mean; debianlp:aptitude is version 0.6.8.2-1 which is what's in Debian unstable
<cjwatson> stokachu: I think you must have misread someething ...
<stokachu> cjwatson: yea i did :\
<stokachu> i did check the diff again just to make sure. and since no changes are needed do i still need to go through creating a merge bug?
<xnox> lp:debian/experimental/aptitude is also up to date with what's idling in the experimental.
<xnox> stokachu: are you implying aptitude is now insync?!
<xnox> stokachu: or the debdiff is the same, sans new changelog entry.
<stokachu> xnox: so basically when doign a grab-merge it shows 2 file conflicts, bug when i did a bzr merge from debianlp it applied cleanly
<stokachu> so i dont think i need a new changelog entry or anything
<stokachu> unless I need to specify that this was a correct merge through bzr and not through merges.u.c
<Laney> You will do; it likely means that it (thinks it) figured out how to merge everything by itself.
<xnox> stokachu: we upload package into ubuntu. new upload must be higher version, and it needs to have a changelog entry.
<Laney> Do double check that what it did is what you expect though
<xnox> stokachu: and the changelog entry should still document remaining (same as before) ubuntu delta.
<stokachu> ok gotcha
<doko> jodh, new upstart still doesn't configure with --disable-silent-rules
<k-s> doko: back, the /opt is the ./configure --prefix=/opt. It should look just into build
<doko> but apparently it doesn't
<k-s> doko: the command 'libtool  --tag=CC   --mode=link gcc -std=gnu99  -Wall -Wextra -Wl,--copy-dt-needed-entries,--no-as-needed   -o bin/eet/eet bin/eet/bin_eet_eet-eet_main.o -fvisibility=hidden -fdata-sections -ffunction-sections -Wl,--gc-sections -fno-strict-aliasing -Wl,--as-needed -Wl,--no-copy-dt-needed-entries    lib/eet/libeet.la' just references the local file
<k-s> doko: do you patch libtool or something like that?
<doko> afaik, no. and the diff to debian is available too
<k-s> doko: diff of my libtool and ubuntu's is quite relevant
<k-s> doko: thins like link_all_deplibs. Do you think it's an option or is it a patch?
<doko> k-s, if you know that it's relevant, then please don't speculate, just point to a particular thing, and maybe fix it
<k-s> doko: I'm checking with the ubuntu user if that's the problem. :-)
<k-s> doko: then i still don't know
<k-s> doko: he acks that changing link_all_deplibs from no to unknown fixes it
<k-s> doko: unknown = yes according to libtool info page.
<doko> then it really looks like an issue with --as-needed. is the software packaged? then I could have a look, but not without it
<k-s> doko: but I wonder why this ends as 'no' in ubuntu, not in other
<k-s> doko: not packaged yet, it's still under development
<k-s> doko: as for the libtool, I'm more interested to know why the variable has different value
<k-s> doko: and how I can force it to be the same everywhere, be it no (like in ubuntu) or yes/unknown (like in fedora/arch)
<doko> k-s: look at the changelog.
<stokachu> is the changelogs url still http://changelogs.ubuntu.com/changelogs?
<doko> bah, just get the source
<stokachu> looks like aptitude needs a small modification to point to ubuntu's changelog server
<cjwatson> it's a very old Debian patch
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=191425 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199423 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=238681
<ubottu> Debian bug 191425 in libtool "Links explicitly with dependent shared libraries" [Wishlist,Fixed]
<ubottu> Debian bug 199423 in libtool "libtool tries (unnecessarily) to link explicitly with dependent shared libraries" [Wishlist,Fixed]
<ubottu> Debian bug 238681 in libtool "librrd0-dev: libtool cannot link to librrd because of bad dependencies" [Wishlist,Fixed]
<cjwatson> (I think.)  Predates Ubuntu.
<cjwatson> And makes a big difference to the huge pile of unnecessary (and sometimes harmful) DT_NEEDED entries you end up with on other systems.
<cjwatson> harmful> particularly in cases where the indirectly-linked library changes its SONAME, which does happen
<k-s> doko: it's confirmed to be 'debian/patches/link_all_deplibs.patch'
<cjwatson> stokachu: It already had that modification in the Ubuntu delta against Dbian
<cjwatson> *Debian
<doko> k-s: I think it's an upstream bug.
<k-s> doko: interesting enough there is one changelog entry disabling some tests because applying this patch breaks libtool's testsuite, the author mentions it is a bug in testsuite
<doko> /usr/bin/ld: bin/eet/bin_eet_eet-eet_main.o: undefined reference to symbol 'eina_iterator_next'
<doko> /usr/bin/ld: note: 'eina_iterator_next' is defined in DSO /opt/lib/libeina.so.1 so try adding it to the linker command line
<doko> /opt/lib/libeina.so.1: could not read symbols: Invalid operation
<k-s> doko: indeed, I can solve this by adding lib/eina/libeina.la to LIBADD
<doko> but you don't explicitly link against -leina. you rely on libeet linked against -leina
<k-s> doko: but as I said I'm more interested to know why this was being done in Ubunut/Debian and not on other distros
<k-s> doko: seems this patch is the reason
<doko> which is expected with no-add-needed
<doko> k-s, no, the default behaviour is just hiding the upstream bug
<cjwatson> Debian has a history of caring very deeply about incremental upgradeability, and that's the sort of thing that tends to make it more likely that you'll encounter problems with indirect linkage
<cjwatson> If you don't care about that you can just rebuild everything and mask the problem
<k-s> doko: yes, this is true. But the major issue is the libtool script being different.
<cjwatson> k-s: Do I understand correctly that you're using eina functions in the objects that you're linking with libeet, as well as in libeet itself?
<k-s> doko: what I wanted to do is to force every builder to get the same results with the same flags
<xnox> k-s: with --add-needed --no-as-needed LDFLAGS you can override ubuntu/debian default behaviour. which will not hurt to guarantee if you wish to use that everywhere.
<k-s> doko: so if some other !ubuntu developer commits... he will do it right and not break ubuntu-ers
<xnox> k-s: run buildbots on ubuntu which revert/reject commits ;-)
<k-s> xnox: unfortunately not, because link_all_deplibs=no is being set independently of that linker flag
<xnox> (launchpad daily builds can be used as well)
<xnox> hmm...
<k-s> xnox: maybe a better libtool patch would be to check for this flag? (and maybe it would be accepted upstream?)
<doko> xnox, doesn't look an as-needed issue on first sight
<doko> k-s: no better fix upstream
<k-s> doko: as i said?
<cjwatson> copy-dt-needed-entries/as-needed can't really influence this because the problem is whether libtool passes excess objects to the linker or not
<doko> right, but if it passes these excess objects, then it hides thecopy-dt-needed-entries issue
<cjwatson> indeed
<cjwatson> libtool's autoconf support doesn't appear to provide a way to e.g. override that behaviour on the configure command line
<doko> and this seems to happen with the upstream libtool, not with the debian one. I can't find any upstream forwarding for this issue
<cjwatson> so I think the only way to do what k-s is asking for (an upstream build forced to link_all_deplibs=no - which of course would only work at all on certain architectures) would be to patch libtool before generating configure, or patch configure, or patch config.status after generating configure and then re-run
<k-s> I wonder if there was any discussion, because 2 patches at least are quite old: link_all_deplibs.patch and deplibs_binary.patch
<cjwatson> google brings up e.g. http://www.mail-archive.com/libtool@gnu.org/msg06328.html
<cjwatson> https://lists.gnu.org/archive/html/libtool/2004-11/msg00455.html better link
<cjwatson> at the time the Debian maintainer was either libtool upstream or one of them
<cjwatson> it would've been around that time, anyway
<cjwatson> I can understand why they might be conservative about changing it, though; it's the sort of thing that needs a degree of coordination and distro support
<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:
<dobey> barry: eww; why did you hack the oneconf setup.py that way instead of fixing the broken debian/rules?
<dobey> doko: could i get you to look at https://code.launchpad.net/~dobey/ubuntu/raring/twisted/fix-pygtkcompat/+merge/144550 please? the new twisted combined with new pygobject is causing ubuntuone pieces to crash on start. thanks
<doko> dobey, sure, looks fine
<barry> dobey: well, the problem was that the executables were getting installed by setup.py into /tmp/usr/bin for both py2 and py3, so the last one installed would "win", and i didn't want to be order dependent.  this way, it's explicit in the setup.py, which makes sense to me since the executables should only be expected to work with py3
<dobey> barry: but working around the problem by hacking setup.py means people who want to use it with python2 (say people who want to backport the new version to older ubuntu), get no scripts. and order dependence is a big part of packaging, so it should be dealt with there. this is a problem with the reocmmended packaging for something to support both 2 and 3, and so oneconf isn't the only thing that's going to hit this issue.
<barry> dobey: in that case, consider the setup.py hack to be a quick fix for a critical problem.  the real fix will probably entail changing the --root on the install and fixing the .install paths.  however, you'll still have the issue that the change can't be completely backported anyway since something in debian/ will have to be changed anyway.  so, is it better to change debian/rules (probably to change which executables are deleted) or
<barry> better to change setup.py?
<xnox> dobey: inherintly easy to backport should not be a priority, but rather a nice to have criteria though. The amount of stuff ported to python3 since precise is enormous, including leaf packages dropping python2 support.
<xnox> barry: artificially limiting package in setup.py is not nice.
<dobey> xnox: i'm not talking about backporting the package. i'm talking about pulling the bzr branch and doing ./setup.py install
<xnox> barry: in devscripts, I run full build machinery for python3, but for python2 I simply use dh_install to move the one python2 module r-dependencies need into correct installation location.
<barry> xnox: i'm not convinced its artificial though
<xnox> barry: is the new pybuild stuff uploaded into raring? and how does that deal with py2&3 scripts.
<dobey> xnox: whether or not it is a priority, hacking setup.py in such a way is not good practice and should be generally discouraged; fixing the debian/rules would be the better fix
<barry> xnox: not yet.  i was trying to get feedback on mitya's branch from doko first
<barry> fwiw, the only reason we re-enabled py2 support at all is for s-c and we're trying to rectify that
<xnox> doko: do you want to review the new features of python-defaults (pybuild) or are you ok for that being sponsored (since nothing in the archive depends on it ;-) )
<xnox> barry: well same way I had to reenable devscripts python2, because of ubuntu-dev-tools ;-)
<barry> xnox: perhaps :)  anyway, once s-c is fully on py3, i would like to eliminate py2 support for oneconf
<xnox> barry: https://launchpadlibrarian.net/128484331/devscripts_2.12.6ubuntu1_2.12.6ubuntu2.diff.gz
<xnox> The "meat" of this patch is in the one line "+scripts/devscripts /usr/lib/python2.7/dist-packages/" in the debian/install.
<xnox> Note how I totally disregard 2.6 and lower. The other extra bit I did is call dh_python2 helper and clean up __pycache__ and that was it.
<barry> xnox: the problem here is that setup.py installs scripts (i.e. executables) for both py2 and py3 into the same location.  the bug was because py2 got installed after py3 so "won" but the scripts are not intended to work with py2, only py3.  so i still think it's reasonable to make that explicit in the setup.py
<xnox> barry: does s-c need python2 scripts?
<xnox> or just python modules?
<barry> xnox: just 'import oneconf'
<xnox> hence don't run setup.py with python2 at all.
<barry> xnox: because if it was shelling out to run the scripts, it wouldn't care :)
<dobey> barry: i don't think that's appropriate for the setup.py; i think it's appropriate to fix the ordering in debian/rules :)
<xnox> forget about all the best python2 packaging practices and do hacks instead =)
<barry> xnox: that seems more radical than making the compatibility explicit in setup.py, doesn't it?
 * xnox goes to make a merge proposal.
<dobey> barry: it's a packaging problem; not an upstream source problem
<xnox> barry: you just broke python4 support =)
 * barry shudders
<xnox> actually a real problem, each python transition we have to fix packages that hard-coded << X.Y for no reason.
<stokachu> mterry: I uploaded a merge request (bug 1103541) if you've got time for any comments on it etc
<ubottu> bug 1103541 in aptitude (Ubuntu) "Please merge aptitude 0.6.8.2-1(main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1103541
<barry> dobey: i disagree.  as i say, the scripts are (currently) not intended to work with py2, only py3.  isn't that an "upstream" issue (i won't say "problem")
<xnox> barry: not intended or do not work at all.
<xnox> ?
<barry> xnox: yes, that's a real problem, and i'm not holding my breath for py4 :)
<dobey> barry: surely they are intende to work with it; they do work with it; the intent is from the packaging side (you don't want to package the python2 bits), not from the upstream side (if python2 isn't intendted to work upstream, then it should just sys.exit() if python3 isn't used, and put /usr/bin/python3 in all the hashbangs)
<barry> xnox: not tested, and i don't think they need to work with py2.  maybe didrocks has a different opinion, but he seemed fine with that when we talked about it previously.  the re-porting to py2 of the library was just a concession (and hopefully temporary) to s-c's current state of affairs
<dobey> is oneconf even useful outside the context of software-center?
<barry> dobey: /usr/bin/python3 *is* in the shebangs.  dh_python2 overwrites them.  yes, we can fix that, but no, the scripts *don't* work with py2 which is why the bug was filed
<barry> dobey: yes, but only s-c imports the oneconf library
<barry> dobey: and anything shelling the oneconf executables doesn't care, as long as the executables have the right shebang lines, which they now do :)
<didrocks> barry: we don't really care for the binary to run python3 or python2, so just whatever is the best in your opinion, I guess py3 ;)
<barry> didrocks: agreed!  and now they do. :)
<barry> my point being: the executables do not need to run py2, and running them with py2 doesn't work.  the *only* reason the package even cares about py2 is because s-c does 'import oneconf' so we have to support that in the library (only) for now
<dobey> why doesn't running them with py2 work?
<barry> it's untested :)
<xnox> in that case a well written script will fail verbosely in the users face if they do try to run in py2, despite "not being intended".
<dobey> python /usr/bin/oneconf-query works fine here :)
<barry> dobey: head /usr/bin/oneconf-query
<dobey> barry: yes it has the 3.3 shebang; but what has that got to do with anything if i'm running a specific python version explicitly? :)
<dobey> why is it 3.3 instead of just "python3" btw?
<xnox> yeah 3.3 is wrong as well ;-)
<barry> dobey: ah, nothing then.  i still say that the we should not claim to support running those scripts under py2
<barry> fwiw, upstream shebang is `/usr/bin/env python3` as it should be.  it gets rewritten
<barry> by the build process
<seb128> barry, didrocks: I guess that apport triggering for oneconf-query every time I install a package is a known issue?
<didrocks> seb128: I assigned the bug to barry
<seb128> didrocks, thanks, I assumed it would be a known issue ;-)
<seb128> barry, any ETA on the fix?
<barry> seb128: what's the bug #?
<didrocks> I guess is was what he uploaded yesterday evening though
<dobey> well, given that python practice is generally to not have any logic in the scripts, and that all the logic is in modules, and scripts are supposed to just do from foo import main; main(); then there is no claim to make or not to make :)
<seb128> barry, dunno, look to the bugs assigned to you? ;-)
<dobey> seb128: the new oneconf is in the archive; upgrade? :)
<dobey> or are you using a slow mirror?
<barry> dobey: that's not how oneconf-query is currently written
<seb128> the error is: /usr/bin/oneconf-query: 'GNUTranslations' object has no attribute 'ugettext'
<barry> but i agree it's good practice.  a total rewrite wasn't on my radar :)
<seb128> let me try to upgrade
<seb128> dobey, I upgraded this morning, let me retry
<dobey> barry: i see that, but having setup.py install scripts doesn't have anything to do with making a claim to support something, either :)
 * xnox is going for a oneline fix.
<dobey> seb128: oh, that's a different crash
<LIDH> Hello, I have Ubuntu 12.10 and a POS system EBN X-950 with touchscreen (EgalaxyTouch according to the manual), so, i tried $lsusb and it doesn't list the touchscreen controller. If I do a screen /dev/ttyS[0-4] can't get any input from the touchscreen. Already did $ modprobe -r usbtouchscreen and still doesn't detect, any ideas what's the problem?
<dobey> seb128: i am not seeing that though
 * xnox just saw that with tests while building oneconf.
<seb128> barry, bug #1103192
<ubottu> Error: Launchpad bug 1103192 could not be found
<seb128> dobey, ii  oneconf        0.3.2        all          synchronize your configuration da
<seb128> dobey, seems the current version
<seb128> barry, bug #1103192
<barry> seb128: got it.  i'll work on that
<seb128> ubottu, wake up bot ;-)
<ubottu> seb128: I am only a bot, please don't think I'm intelligent :)
<dobey> barry: anyway, i think doing what you did to setup.py in order to "fix" the issue, sets a bad example for what people should do when they encounter the same issue with other packages that need to install both py2 and py3 versions of modules, and which have scripts
<seb128> barry, thanks
<bdmurray> seb128: is there someone on the desktop team who can look at bug 1101326?
<ubottu> bug 1101326 in consolekit (Ubuntu) "console-kit-daemon appears to consume 2GB of memory" [High,New] https://launchpad.net/bugs/1101326
<xnox> dobey: i have a merge proposal with a simpler fix comming shortly.
<seb128> bdmurray, consolekit is a foundation bit, maybe ask slangasek?
<slangasek> heh, ok
<barry> dobey: i'm not so sure.  let's take ubuntu packaging out of the picture.  just say you're writing an upstream package where the library supports py2 and py3, but the executables it creates only supports one version or the other.  how would you solve that?
<xnox> seb128: we were hoping somebody might want that hot potato on the desktop side =)
<seb128> no, the last one who was enough into plumbing for those issue in desktop was pitti
<seb128> we don't have anyone with ck clues atm
<slangasek> understood
<LIDH> anyone to help me with the touchscreen?
<seb128> slangasek, xnox: sorry about that...
<xnox> barry: if only setup.py metadata and pypi tags supported "supported versions per-module & scripts"
<dobey> barry: if the modules support both, the scripts should support both; all code, whether in scripts or modules, should be tested, and the tests should past under all versions of python you claim to support, regardless of whether it's scripts or modules. all code should adhere to the same standards
<xnox> in a standard way.
<dobey> barry: but then again, all the ubuntuone packages are maintained in this way :)
<barry> dobey: maybe, but that's an upstream decision, and there may be reasons why they don't or can't or won't do that.  again, for callers of the cli, the shebang python version should never matter
<stokachu> barry: would python-tz be something I could help on?
<dobey> barry: well it does, because "/usr/bin/env python[3]" breaks virtualenv and is bad practice, no?
<barry> stokachu: hi.  what would you like to work on?  python3-tz is in the archive currently
<tion_> how do i dist-upgrade to 12.10?
<stokachu> barry: i was just looking at the outstanding merges and python-tz shows debian at 2012c-1 and last upload 2011k-0ubuntu6
<xnox> tion_: support for stable release (12.10) is in the #ubuntu channel.
<barry> dobey: right, but fwiw, /usr/bin/env should never be in the shebang for production scripts.  it's a known issue for virtualenvs, but there isn't any common solution for it.  folks just hack around such things when they need to
<barry> stokachu: that would be great!
<stokachu> barry: ok cool ill work on that today
<dobey> barry: anyway, i didn't want to have a lengthy argument about it. just point out that it seems like the wrong fix and sets bad precedence. it would seem very odd to me for any upstream to decide to only support python2 with only part of their code, and python3 with all of it. if upstream doesn't want to support python2 then don't ship any python2 bits and only package it as requiring python3 :)
<toabctl> jbicha, can you have a look at lp:1102096 please?
 * dobey has enough problems to deal with right now from other upstreams doing some dumb things
<dobey> and need to get lunch. bbiab
<barry> dobey: originally oneconf was a pure py3 port that dropped py2, but then i realized s-c still imported it.  but i get what you're saying, and sorry to be so obstinate about it.  do feel free to at least file a bug, and if we don't just drop py2 support before then, i'll keep it on the radar
<LIDH> How do I get Ubuntu 12.10 to detect more than 4 COM Ports?
<barry> dobey: i think that's a constant of the universe (upstreams doing dumb things :).  and i speak of course as one of those dumb upstreamers :)
<dobey> :)
<LIDH> How do I get Ubuntu 12.10 to detect more than 4 COM Ports?
<barry> anyway, i'd rather put the effort into getting s-c on py3, but i certainly would be happy to review a m-p :)
<ogra_> LIDH, this is not a support channel, try #ubuntu
<xnox> LIDH: support is in #ubuntu . Also please be patient and don't repost your question that often.
<xnox> LIDH: also don't post in multiple channels simultaniously ;-)
<bdmurray> slangasek: looking at bug 1096022 I'm trying to use the apt-clone file to recreate it and running into issues with either apt-clone or aptdaemon...
<ubottu> bug 1096022 in update-manager (Ubuntu) ""E:Error, pkgProblemResolver::Resolve generated breaks" during lucid->precise universe upgrade of amd64" [Medium,Triaged] https://launchpad.net/bugs/1096022
<jbicha> toabctl: yes I saw the bug but I'm not able to duplicate it here
<jbicha> toabctl: maybe you could post your graphics driver & hardware and whether you're using PPAs
<stokachu> stupid question, i ran a bzr merge and it renamed files to filename.BASE|THIS i assume THIS is from the merged repo?
<stokachu> and they aren't exactly diffs but are they meant to replace the whole file?
<bdmurray> barry: about that software-center merge proposal...
<barry> bdmurray: i was just going to ask you about that :)
<toabctl> jbicha, I don't use any relevant ppas. I also posted my graphics hardware (Intel Corporation Mobile 4 Series Chipset) to the bug report
<barry> bdmurray, xnox do you just need it merged or do you need it uploaded?
<bdmurray> barry: merged, I can do the uploading and SRU work
<barry> bdmurray: nod
<slangasek> bdmurray: what kind of issues?
<bdmurray> segfaults in apt-clone
<slangasek> fun
<bdmurray> er or libpat-pkg-libc6.10-6
<bdmurray> oh psivaa do you a script to setup the system in bug 1096022 I could use?
<ubottu> bug 1096022 in update-manager (Ubuntu) ""E:Error, pkgProblemResolver::Resolve generated breaks" during lucid->precise universe upgrade of amd64" [Medium,Triaged] https://launchpad.net/bugs/1096022
<slangasek> bdmurray: backtraces?
<barry> bdmurray: crap. i also have insufficient permissions to push it after the team reassignment.  i suggest bugging dobey (only direct team member currently on this channel afaict)
<dobey> barry, bdmurray: merged
<jrr> Does apt-get build-dep generally work for ubuntu packages?  I'm getting a bunch of missing libraries when trying to rebuild gnome-control-center.
<bdmurray> dobey: thanks
<sarnold> jrr: do you also have the build-essential package installed?
<xnox> jrr: it should. unless your source package != distro you are running.
<jrr> 12.10, and whatever "apt-get source gnome-control-center" pulled down
<xnox> jrr: e.g. apt-get build-dep only gives you build-deps as declared in the highest version of the source package from deb-src lines, it doesn't know about unreleased changes in the distro / upstream.
<dobey> barry: if you feel like merging/uploading something though, https://code.launchpad.net/~dobey/ubuntu/raring/twisted/fix-pygtkcompat/+merge/144550 could use it :)
<xnox> jrr: do you have full build-log?
<jrr> yeah, hold on I'll redo the whole flow and pastebin it
<stgraber> kees: hey, are you around?
<dobey> hmm, what's the best way to go about converting a native package in ubuntu, to not be a native package?
<jrr> xnox: forgive the syntax highlighting http://pastebin.com/t396MTJM
<jrr> first time trying to rebuild a package; naively trying to ./configure and make
<jrr> if that's not the correct way to do it, I welcome correction =]
<xnox> jrr: that's not how one rebuilds a package.
<xnox> jjr: ./debian/rules build
<xnox> jrr: fakeroot ./debian/rules binary
<xnox> run these two commands in clean unpacked source.
<xnox> ... or there is a helper to do that.
<dobey> or set up pbuilder or sbuild, so you can build it in a clean chroot
<xnox> $ debuild
<xnox> jrr: note that debian/rules is just a makefile, although usually uses black magic (cdbs or dh)
<stokachu> jrr: I like to use http://askubuntu.com/questions/53014/why-use-sbuild-over-pbuilder as reference
<stokachu> just for the commands not for which is better :P
<jrr> "./debian/rules build" ends in the same "/usr/bin/ld.bfd.real: cannot find -lgtk-3" etc
<jrr> this was after a fresh apt-get source
<jrr> here's a new pastebin http://pastebin.com/iD7sT4Hd
<stokachu> barry: i uploaded a merge for bug 1103644, though i think this could easily be a sync but the documentation on sync's didnt state it had to be since it is before debian import freeze
<ubottu> bug 1103644 in python-tz (Ubuntu) "Please merge python-tz 2012c-1 (main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1103644
<stokachu> unless im reading it wrong
<infinity> dobey: Native -> non-native is simple.  Have your unpacked source, put the orig.tar.gz in the parent directory, make sure the new version in debian/changelog is sane, debuild -S.  Boom non-native.
<seb128> hum, ubuntu-defaults-image hangs for me
<seb128> does anyone knows where are the sources it tries to use defined?
<seb128> strace indicates it hangs trying to contact 91.189.88.40 which is drescher.canonical.com
<dobey> infinity: right; that bit is easy; i mean more in the context of how it may break the world with respect to UDD
<infinity> jrr: What does "dpkg-checkbuilddeps" say?
<infinity> dobey: Sneezing breaks UDD.  I'm not sure I'd care much. :P
<jrr> infinity: nothing
<infinity> dobey: (But, in this case, I don't see why it should break, UDD imports unpacked sources, not diffs, how it's unpacked should be irrelevant)
<dobey> infinity: right, but some branches are special, no? when Vcs-Bzr: is used and such?
<jrr> with return code of zero
<dobey> of course, the branch that Vcs-Bzr: points to, is currently not there, so i guess it won't be too bad
<seb128> hum, great, I simply can't contact archive.ubuntu.com ... is that working for others?
<xnox> jrr: are you cross-coompilng or using some funny linker?
<xnox> jrr: it works fine here on quantal for me.
<sarnold> seb128: responds to ping, http
<barry> dobey: sure.  i've got it in my browser tab now :)
<xnox> jrr: e.g. why is it .real linker =/
<xnox> dobey: UDD handles source package format changes just fine.
<seb128> sarnold, can brower http://archive.ubuntu.com in a web browser?
<seb128> bah, it works for chinstrap, I guess it's my connection
<sarnold> seb128: ubuntu/  ..
<seb128> sarnold, thanks
<jrr> xnox: I have arm-linux-gnueabi-gcc installed.. maybe it messed with some symlinks?
<xnox> jrr: it shouldn't.
<jrr> ohhhh I know what it is
<jrr> I had my gcc and g++ replaced with hacky scripts calling inserting -m32
<jrr> sorry about that!
<xnox> that makes sense......
<jtaylor> mterry: you (co-)wrote the pycurl py3 test?
<jtaylor> I've got a few issues/questions with it
<jrr> I was building some stuff that didn't respect env CFLAGS
<mterry> jtaylor, I may have helped port it to py3, IIRC
<jtaylor> mterry: tornados testsuite fails on it
<jtaylor> invalid arguments to: curl.setopt(pycurl.URL, utf8(request.url))
<jtaylor> where utf8 outputs bytes
<jtaylor> it works if it would pass in unicode, I guess thats an issue of tornados testsuite#?
<jrr> xnox: okay, got it rebuilt.  Time to start chasing the bug.. thanks!
<jtaylor> also something crashes when one tab completes Curl() from ipython, still need to check what goes wrong there
<seb128> hum
<seb128> it failed with that error, this time
<seb128> chroot: failed to run command '/usr/bin/env': No such file or directory
<seb128> wth
<mterry> jtaylor, hm
<mterry> jtaylor, it's been a while, let me look at code real quik
<jtaylor> mterry: ipythons issue: hasattr(pycurl.Curl(), "trait_names"), throws SystemError
<jtaylor> on quantal, I'll quickly test raring
<mterry> jtaylor, ah I just grabbed this patch from upstream's tracker, and maybe modified it a bit to work.  But still, let me dig into why it's failing
<jtaylor> there too
<jtaylor> filed bug 1103667 for the latter issue
<ubottu> bug 1103667 in pycurl (Ubuntu) "python3 pycurl hasattr throws SystemError" [Undecided,New] https://launchpad.net/bugs/1103667
<mterry> jtaylor, so I'm thinking that the utf8 issue is a fault with tornado's testsuite, and I'm confused about the ipythons thing.  So 'trait_names' is a method that ipython looks for to provide tab-complete info?  Why would it not being there throw an error?
<jtaylor> don't know, thats pycurls issue
<jtaylor> hasattr must not throw an exception
<jtaylor> (I think it even eats them in python2)
<jtaylor> hasattr works if it actually has the attribute
<jtaylor> it only fails if it doesn't exist
<mterry> jtaylor, ah yeah I see it in python console, hasattr is bogus
<stgraber> kees: unping. Sent an e-mail to the Debian BTS instead (libseccomp related)
<mterry> jtaylor, working on a patch
<stgraber> jdstrand: if you have a few minutes for a quick re-review, I updated the state of bug 1082431
<ubottu> bug 1082431 in libseccomp (Ubuntu) "[MIR] libseccomp" [Undecided,In progress] https://launchpad.net/bugs/1082431
<jtaylor> mterry: concerning the setopt, aparently the python2 variant accepts utf8
<jtaylor> mterry: wouldn't it make sense when the python3 wrapper accepts python unicode and decodes that to utf8?
<jtaylor> instead of having people do that before calling setopt
<mterry> jtaylor, you mean accept utf8 and decode it to unicode?
<mterry> jtaylor, the way this patch is written, the python3 API is all native strings (i.e. unicode)
<jtaylor> mterry: no, accept python3 string (which is (any?') unicode encoding and pass it to curl in what it expects (utf)
<jtaylor> mterry: but in which encoding? and what does curl want?
<mterry> jtaylor, python3 strings are not utf8 (bytes) but rather 'pure' unicode
<jtaylor> is python3 string encoding even fixed? python3.3 has variable internal encoding
<jtaylor> what do you understand as pure unicode?
<dobey> py3 strings are unicode. they can be utf-8, utf-16, ucs-2, or whatever, as long as it's unicode. for pure bytes, there's the bytes object still
<jtaylor> I'd be surprised when curl accepts a PyUnicodeString (or whatever its named)
<mterry> jtaylor, I don't know the internals, but Python3 makes a distinction between bytes and strings.  You said the utf8() function is returning strings, so that's the problem (at least assuming this Python3 patch's API is sensible)
<mterry> Which is what we're discussing I guess
<jtaylor> no, utf8 returns bytes
<mterry> jtaylor, I'm sorry.  I meant bytes there
<mterry> jtaylor, rest of the sentence is the same
<jtaylor> wait now I get it
<mterry> dobey, right.  But 's'.encode('utf8') is no longer a Python3 string, but a bytes object
<jtaylor> hm ok it looks like a tornado issue
<jtaylor> I'll file a bug
<mterry> Despite being utf8 under the hood.  That's what I meant
<mterry> jtaylor, again, this python3 patch's API may not be 'official'.  It's not yet accepted upstream
<mterry> jtaylor, but it's what we're using for now anyway
<jtaylor> yeah, I'll just file it so upstream knows about the issue
<mterry> jtaylor, is there a bug for the ipython issue?  I believe I've fixed it
<jtaylor> mterry: bug 1103667
<ubottu> bug 1103667 in pycurl (Ubuntu) "python3 pycurl hasattr throws SystemError" [Undecided,New] https://launchpad.net/bugs/1103667
<mterry> jtaylor, upload pending for that one
<jtaylor> thx
<stgraber> kees, hallyn: I guess I should have test built on i386 too (just did amd64), anyway, looks like we have a test failure with libseccomp on i386. I'm really not familiar with that stuff, so if one of you has a clue as to exactly what's failling and whether we should care: https://launchpadlibrarian.net/129232657/buildlog_ubuntu-raring-i386.libseccomp_1.0.1-1ubuntu1_FAILEDTOBUILD.txt.gz
<stgraber> I'll try to reproduce here in a minute to make sure it's not somehow buildd-related, though if it was, I'd have expected amd64 to fail too, which it didn't.
<stgraber> kees, hallyn: note that ERRORs are ignored, only FAILURE are considered fatal
<jdstrand> stgraber: I've got it on my list, but I'll wait for this to get resolved
<jtaylor> mterry: will you comment on the upstream bug?
<stgraber> jdstrand: thanks.
<mterry> jtaylor, the python3 one or did you file a separate bug for the issue?
<jtaylor> mterry: I was thinking adding it to the python3 patch in upstreams bug
<jtaylor> where it originates from in the first place
<mterry> jtaylor, makes sense, will do
<hallyn> stgraber: will look in a min
<hallyn> stgraber: is that the libseccomp i'll get with pull-lp-source right now?
<stgraber> hallyn: yep
<hallyn> k
<stgraber> hallyn: the only change I pushed in that last version is running tests/regression post-build and that's what found a failure on i386
<stgraber> so if there's an actual bug, then we already have it in the archive...
<hallyn> stgraber: (hopefully kees sees it and looks at it, but i'm waiting on a raring i386 install to test on)
<stgraber> hallyn: I'm running the build here in a raring container (on the raring kernel though, so should be similar to the buildd)
<kees> hallyn, stgraber: already testing it for a -2 upload ;)
<kees> it takes tooooo long to build now ;)
<dupondje> It should be possible to copy files from 1 gvfs mount to another no?
<stgraber> kees: hehe, yeah, it's making the build at least 10x slower :)
<stgraber> hallyn, kees: reproduced the test failure on i386 here, so it doesn't appear to be buildd-specific at least
<kees> stgraber: oh! let me try too...
<stgraber> hallyn, kees: if you don't want to wait 10min for the tests to run, "./regression -b 17-reset" will run just the failing batch. There should be a single failure at 14-reset%%007-00001
<stgraber> s/17/14/ ^
<kees> stgraber: confirmed
<kees> Test 14-reset%%007-00001 result:   FAILURE bpf_sim resulted in ALLOW
<stgraber> kees: was that on a Debian or Ubuntu system? (just curious on whether it's the distro that somehow broke something)
<kees> stgraber: that's on debian unstable i386
<kees> may be a missing dep, though, since I also see errors about missing /usr/include/asm/unistd.h
<stgraber> yeah we've got those on Ubuntu too, though they result on ERROR lines as those tests fail to run (or so is my interpretation at least) and I've got those on amd64 too without the failure
 * kees scratches his head
<kees> it should be part of linux-libc-dev
<kees> oh, debian is missing the symlink for /usr/include/asm
<stgraber> kees: manually making the symlink between /usr/include/asm-generic and /usr/include/asm gets me an extra FAILURE in 14-reset
<stgraber> "4-reset%%002-00000 result:   FAILURE bpf_sim resulted in KILL"
<kees> whee
<kees> okay, found the bad use of /usr/include/asm/unistd.h
<kees> stgraber: fixing that got rid of the errors for me, but 007-0001 still failed. I'll keep digging
<slangasek> Sweetshark: hi, I talked with seb128 yesterday about the libreoffice precise SRU needing changelog fixups and a reupload; I've rejected the previous upload based on this, when a new version hits the queue feel free to ping me for an expedited review
<hunnicutt> Hello
<hunnicutt> I would like to compile nm-applet from source using the same command-line for "configure" used to compile with Ubuntu 12.04
<hunnicutt> I have the nm-applet 0.9.4.1, fetched from git.  But I don't know how to build this for GTK-2, it seems to create a shared library which pulls in GTK 3
<hunnicutt> I've searched for a Wiki page telling me what arguments I might provide to configure, but not found one.
<cjwatson> Not the sort of thing that goes in wiki pages, really
<hunnicutt> where does it go?
<stgraber> in the packaging (debian/rules)
<cjwatson> The package's debian/rules is responsible for deciding how to configure the package
<cjwatson> You can either try to run the packaging against git, or you can look at a build log to see what it did
<barry> is anybody successfully using r145 of lp:auto-package-testing on raring today?
<cjwatson> https://launchpadlibrarian.net/99824547/buildlog_ubuntu-precise-i386.network-manager-applet_0.9.4.1-0ubuntu2_BUILDING.txt.gz in this case
<cjwatson> So that's --libexecdir=/usr/lib/NetworkManager --enable-more-warnings=no --enable-indicator added to a batch of reasonably default options - unfortunately dh_auto_configure doesn't print what it's doing by default, so let me find it for you
<hunnicutt> Thanks this is really helpful.
<dobey> gah, so the new glib breaks anything trying to build docs with gtk-doc :(
<hunnicutt> It's possible I should give you a higher-level overview.  I'm trying to figure out the best way to fix an upstream bug in gnome.org sources and make the patch available to Ubuntu 12.04
<cjwatson> Well, most of the default options in dh_auto_configure are filesystem layout stuff
<cjwatson> --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-maintainer-mode --disable-dependency-tracking
<cjwatson> If you just want to install to the default of /usr/local or some prefix in your home directory, then you can omit that and just use the package-specific options I gave above
<hunnicutt> I tried to build with no special arguments and as a result (after sudo make install) I had built a libnm-gtk which produces the following GTK warning and dies:
<cjwatson> You should learn how to build packages in general if you're planning on fixing them, though - https://wiki.ubuntu.com/UbuntuDevelopment#Packaging has a bunch of links
<hunnicutt> gtk-error that is
<hunnicutt> Gtk-ERROR **: GTK+ 2.x symbols detected. Using GTK+ 2.x and GTK+ 3 in the same process is not supported
<cjwatson> I doubt there's any guarantee that an unmodified nm-applet from git will work on 12.04
<hunnicutt> OK thanks
<cjwatson> Or an unmodified anything in general, particularly across GTK+ 2/3 porting
<hunnicutt> Interesting, that makes it more difficult to fix in upstream.
<hunnicutt> But I will go read this info about packages.
<hunnicutt> Thanks.  Mostly I don't have a lot of time to expend on this right now, but a particular papercut is wasting enough time that I want to patch it.
<cjwatson> Though this does seem backwards, since nm-applet in precise was GTK+ 3
<hunnicutt> oh wait is this simply b/c I have gtk-2.0-dev on my machine and not gtk-3.0-dev?
<cjwatson> Quite possibly; you *must* satisfy build-dependencies of a package
<cjwatson> It may be worth a little up-front investment to learn how to use a proper "build package in clean chroot with just its build-dependencies" tool such as sbuild
<sarnold> cjwatson++
<cjwatson> But failing that (and it is certainly some investment to figure out how to use that kind of workflow against upstream, and may be painful for desktop-ish things in particular where you might want to have your X session handy), at least do 'sudo apt-get build-dep network-manager-gnome'
<cjwatson> Certainly for stuff I work on upstream I only do chroot builds when I'm building packages to install and test, not for routine development
<hunnicutt> I'll look at sbuild, thanks.  and that apt-get is fabulous.  Who knows, maybe I will just put a unified diff in the bug report.  I just want nm-applet to cease with so many open dialogs.  :)  Long-term I'd love to contribute more effectively but for now I am mostly trying to make money  with this system involving desktop apps, so that's where my focus is.
<hunnicutt> hmm apt-get build-dep says I lacked as follows:
<hunnicutt> dh-autoreconf dh-translations libappindicator3-dev libdbusmenu-glib-dev
<hunnicutt>   libgnome-bluetooth-dev libgtk-3-dev
<hunnicutt> let that be a lesson to me.
<cjwatson> Looks like nm-applet tries to autodetect GTK+ 2 or 3 at build time by default (unless you use --with-gtkver=3), so build-dependencies would certainly explain it.  It defaults to trying 3 then 2.
<cjwatson> I should also say that the network-manager-applet package has a number of patches against upstream.
<hunnicutt> ruh ro
<cjwatson> If you're trying to get a working tree you can experiment with rather than "compare against upstream behaviour", you'd be better served building the actual Ubuntu package
<infinity> kees: Err, wait.  What?  What's trying to include /usr/include/asm/* ?
<infinity> kees: I mean, instead of including <asm/*> which will let the compiler not be silly.
<hunnicutt> that's great to know.
<cjwatson> Install ubuntu-dev-tools and run 'pull-lp-source network-manager-applet precise' and you'll get an unpacked source tree with the Ubuntu patches auto-applied - they're in debian/patches/ and managed using quilt
<hunnicutt> I won't be sad to compare with upstream, but I see that I want to learn about the packaging system much more.
<kees> infinity: yes, a testsuite was doing gcc -E -dM /path/ instead of echo ".h" | gcc -E -dM -
<kees> (I've found and fixed it now)
<hunnicutt> wut it's that easy?
<hunnicutt> thanks
<infinity> kees: Oh, good.  I didn't get all the context on a quick backscroll skim, I was just gearing up for some sort of protracted battle wherein I got to call someone names for blaming headers and/or toolchains.
<infinity> kees: Thanks for ruining my fun.
<infinity> kees: Jerk.
<infinity> kees: :)
<cjwatson> Getting a proper version-controlled tree is rather more package-specific and I wouldn't want to guess in this case without more investigation, but you can always blat it into a DVCS locally.
<cjwatson> Patch application varies among packages, unfortunately; network-manager-applet is using the current best practice for patch management in source packages, though.
<cjwatson> So you will see some other methods if you do lots of packaging work, but the older ones are gradually dying out.
<cjwatson> (Sorry if this is way too much information.)
<hunnicutt> nope this was excellent.  I had been looking for a brain-dump on how to do this, but didn't expect there to be this command line that pulled the ubuntu source.  I mean; that's perfect, mostly.
<hunnicutt> Also did not realize this channel was the place to get started...
<infinity> Yeah, pull-{lp,debian}-source are awesome, now that I've trained my fingers to use them.
<infinity> hunnicutt: This channel isn't the place to get started, #ubuntu-motu is.  But it seems Colin was feeling helpful. :)
<hunnicutt> motu?
<cjwatson> stupid name :)
<cjwatson> "masters of the universe".  (I think there's actually #ubuntu-packaging nowadays.)
<infinity> There may also be an ubuntu-mentors or similar.
<infinity> Arguably, this needs a looking at and consolodation. :P
<hunnicutt> well I wouldn't want to wind up some place too pedantic-sounding.
<cjwatson> The problem is we keep doing half of a consolidation - the half that goes "OK, let's create a new thing with a better name"
<cjwatson> This is arguably less than totally ideal
<infinity> cjwatson: Dude, we can totally solve it with one last rename.
<cjwatson> One more layer of indirection, right?
<infinity> Absolutely.
<mwhudson> maybe a bot that forwards conversation from one place to another?
<mwhudson> maybe multiple bots?
<mwhudson> nothing can go wrong there right?
<infinity> mwhudson: On a scale of one to things you shouldn't joke about, that rates an argh.
<slangasek> an argh, plus or minus fwibble
<hunnicutt> tsk it seems like I have some different gcc version, while I'm at it.  I had forgotten that I needed to turn off warnings-as-errors to compile this nm-applet
<hunnicutt> Whereas the right way is perhaps to correct these warnings before fixing the bug which affects me.
<hunnicutt> oh, joy
<hunnicutt> ahh, not the problem is that I lack libindicator-3-dev and therefor ENABLE_INDICATOR is not defined and therefore compile error due to actual bug that doesn't appear for a compile with all the needed dependencies.
<kees> infinity: heheh :)
<dobey> anyone care to sponsor https://code.launchpad.net/~dobey/ubuntu/raring/gtk-doc/fix-type-init/+merge/144605 please?
#ubuntu-devel 2013-01-24
<EagleScreen> hello, we have *again* bluetooth obex broken in gvfs in quantal and raring, please fix it
<TheMuso> EagleScreen: Please file a bug.
<EagleScreen> TheMuso: there are two bugs filled
<TheMuso> Ok then thats fine.
<EagleScreen> TheMuso: quantal was released with this bug, and I do not see activity to fux it before raring, I think having a working bluetooth is an important feature nowadays
<sladen> EagleScreen: what are the bug numbers?
<EagleScreen> Bug #1103253 and Bug #899858
<ubottu> Error: Launchpad bug 1103253 could not be found
<ubottu> bug 899858 in gvfs "regression in gvfs to connect/browse using obex" [Medium,Confirmed] https://launchpad.net/bugs/899858
<sarnold> EagleScreen: probably 1103253 is dead because your packages were out-of-date and the retracer only supports tracing on current.. I doubt there will be any movement there. You should update the old packages, re-create the crash, and file a new bug as the robot asks...
<EagleScreen> sarnold: I amon it
<EagleScreen> I have reported it again in Bug #1103770
<ubottu> Error: Launchpad bug 1103770 could not be found
<sarnold> woot. now just wait for the retracer...
<wjtaylor_> Is touch fully supported in 12.04. I started using it and my cursor jumps all over now. Didn't want to fill out a bug report, if it's not supported.
<sladen> wjtaylor_: if it doesn't work, it's a bug.  Please file it.  The most important bit is which /exact/ hardware you're using and which programme(s)
<wjtaylor_> yeah, np.  Dell XT2 and  whatever the stock Document Viewer (pdf view) in 12.04
<Snow-Man> pitti: around..?
<Snow-Man> pitti: was hoping to chat w/ you about possibly having a per-cluster directory under /var/run for sockets and then modifying pg_lsclusters (and friends) to add and support listen_addresses which might not overlap.
<Snow-Man> pitti: in an ideal world, I'd like to be able to run 2 clusters on the same physical box, both using the default port of 5432 but with different IPs
<Snow-Man> pitti: and still have psql --cluster x.y/whatever and friends work.
<Snow-Man> and not error out when there are conflicting ports for two clusters, when they have different IPs.
<TheMuso> Snow-Man: pitti is not likely to be on for another few hours.
<Snow-Man> np
<Snow-Man> I expect he reads scrollback. :)
<lifeless> are dates for UDS Q available yet ?
<lifeless> even approx ?
<lifeless> grr, I mean 'S'
<sladen> wjtaylor_: Evince is the PDF viewer.  please could you file a bug with exactly what actions (gestures)
<infinity> lifeless: Approximately a week after release, if history is anything to go by, but nothing officially announced yet.
<lifeless> infinity: thanks
<infinity> lifeless: Well, a week and a half, since release is a Thursday.  But you know what I meant, I assume.
<lifeless> indeed :)
<pitti> Good morning
<infinity> pitti: Yo.
<infinity> pitti: When do we plan on doing langpacks for precise.2 (or do you at all)?
<pitti> Snow-Man: hm, that requires psql to iterate through the server configs and map IP/port ranges to find out which one it really wants to talk to?
<infinity> pitti: And, if you do, shall we escalate that "upgrade the chroot, pleeeease" ticket first?
<pitti> Snow-Man: with unix ports that's easier of course, but that pretty much is guaranteed to break client apps which are not using p-common (i. e. pretty much all of them), as they can't find the socket any more
<pitti> infinity: ah, for that I'm pretty much in "poke me when you need it" mode
<pitti> infinity: yeah, I guess we should do some escalation there
<pitti> infinity: when is precise.2 due?
<infinity> pitti: Kay.  I'll apply some pressure from a few angles.
<infinity> pitti: Freeze was meant to be (and nominally still is) today, though we're delaying the release by two weeks, so we have some wiggle room on the freezy bit too.
<pitti> infinity: ah, ok; I requested a full langpack export from Launchpad now
<infinity> pitti: Alright, but we'll hold off on magically turning that into source packages while we escalate the ticket?
<pitti> infinity: the next regular one will arrive on Jan 28, so that we could build/upload the packs on Jan 29; is that enough, or do we need to poke webops to do a manual export?
<infinity> pitti: (I assume this could be done in any chroot, is there a reason it's on that specific host?)
<pitti> infinity: it's not very host specific, it just needs some space to run this stuff
<pitti> infinity: but as this will be a fresh -base rebuild, I don't even need the previous packages
<infinity> pitti: The 29th still gives us ~2w before freeze, so that would be fine.
<infinity> Err, before release.
<pitti> infinity: so in theory I could even build them at a porter box
<infinity> Brain no workie tonight.  Too much glibc.
<infinity> pitti: Yeah, that's what I was thinking, given that porter boxes have lucid/precise/raring chroots (whatever you want to use, precise probably makes mose sense), and a reasonable chunk of space and bandwidth.
<pitti> glibc? eek, that suppurates out of your brain only very slowly
<pitti> infinity: macquarie just has all the "langpack group ACL"/"space for permanently storing the files" etc. set up, that's all
<infinity> Well, we can and should escalate the ticket too.
<infinity> So, if I can get that done before the 29th, you're golden.
 * pitti adds the 29th to his calendar
<infinity> Log for successful build of eglibc_2.17-0experimental0 on i386
<infinity> Well, this is promising.
<infinity> If only I hadn't thought of three more things to fix while it was building.
<pitti> infinity: OOI, does that already include the magic patch which makes gstreamer apps not be sad and hang most of the time?
<pitti> (no, I never watch videos during lunch break, this is is totally not an egoistic question)
<pitti> *cough*
<infinity> pitti: Yes, you can upgrade from my PPA right now and tell me if it solves that bug for you.
<infinity> https://launchpad.net/~adconrad/+archive/ppa/+packages
<pitti> https://launchpad.net/~adconrad/+archive/ppa/+packages ?
<pitti> ah, that very
<infinity> There are a few small multiarch-related bugs in that, but nothing that affects x86.
<infinity> Just fixing up some armhf/armel stuff right now, and nailing down something that affects cross-machine multiarch while I'm in there.
<pitti> infinity: that seems to work beautifully!
<infinity> pitti: Oh wow.  The bug is THAT reproducible that you can tell it's fixed that quickly?
<infinity> pitti: I don't think the severity of it was quite made clear to me, then.
<pitti> infinity: I usually had to open a video two or three times before totem would stop hanging and star playing
<infinity> pitti: Anyhow, one or two more fixes, and mulling over if I want to rewrite a patch from doko or save that for later, and I'll be uploading to experimental and raring tonight/tomorrow.
<pitti> infinity: I could usually search within music or a video once, but it would again hang when doing it multiple times
<infinity> pitti: Ouch.  That's pretty rough.
<infinity> pitti: Glad to hear it's all gooder with those packages, then.
<pitti> thanks!
<dholbach> good morning
<ritz> Hi, How do I instruct debuild to use "-j3" for build process
<ritz> for build on smp system
<slangasek> ritz: DEB_BUILD_OPTIONS=parallel=3
<slangasek> however, the majority of packages don't honor this
<pitti> you can actually call "debuild -j3"
<pitti> that will additionally parallelize dh_builddeb and perhaps some others
<slangasek> ah, hmm
<ritz> slangasek++ pitti++ thanks
<pitti> that sets above D_B_O option plus MAKEFLAGS=-j3
<pitti> actually, D_B_O will already parallelize dh_builddeb, sorry
<SpamapS> hallyn: FYI, had to reject your qemu-kvm upload to quantal-proposed. No bug reference, and the version has been superseded by security.
<SpamapS> tkamppeter_: FYI, had to reject cups upload to quantal-proposed because it has no bug reference.
<tkamppeter_> SpamapS, the cups upload is also not rlevant any more. I have proposed a better approach and I am waiting for user feedback, if no user reacts there will be no SRU att all.
<SpamapS> tkamppeter_: great, thanks for the clarification.
<Sweetsha1k> slangasek: yes, heard that from seb128. I uploaded a new package on http://people.canonical.com/~bjoern/precise/ and a ppaified version was build in https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-oneirictest-20110718?field.series_filter=precise. I have to smoketest that one and then it should be good for review. the changes are minimal and described in bug 1037111 and should address all concerns.
<ubottu> bug 1037111 in libreoffice (Ubuntu Precise) "[SRU] LibreOffice 3.5.7 for precise" [High,In progress] https://launchpad.net/bugs/1037111
<psivaa> bdmurray: there is no single script to do the set up for the auto -upgrade testing. I have now given the automation set-up information in the bug description.
<rbasak> grab-merge is giving me a conflict in debian/patches/series. This I understand. But the working directory it gives me to resolve this conflict seems to have patches applied but no .pc directory. Is this expected? I can fix this up by hand but don't understand the expected workflow here. What am I missing, and how does everyone else deal with this?
<toabctl> someone familiar with pulseaudio? see #1103948
<seb128> bug #1103948
<ubottu> bug 1103948 in pulseaudio (Ubuntu) "Rhythmbox hangs in pa_threaded_mainloop_wait () from /usr/lib/x86_64-linux-gnu/libpulse.so.0" [Undecided,New] https://launchpad.net/bugs/1103948
<seb128> TheMuso, ^
<toabctl> seb128, thx
<seb128> toabctl, yw
<Laney> seb128: toabctl: that's bug #1085342 in eglibc
<ubottu> bug 1085342 in totem (Ubuntu) "Pulseaudio applications hang (Totem, GNOME Shell etc.)" [Undecided,Confirmed] https://launchpad.net/bugs/1085342
<seb128> Laney, thanks
<Laney> pthread_cond_wait at the top of the trace is the clue for that one
 * Laney dupes a few
<toabctl> Laney, thx!
<jemadux> i have dual boot ubuntu lts and ubuntu daily .. i am using chroot to update the 13.04 but now i cant .. .any way to do that?
<ogra_> @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: ogra_
<k-s>  /wc
<OdyX> tkamppeter: can you hint me about Debian #697970 and LP #872483 ? A proper fix would be a quirk in backend/libusb*, right ?
<ubottu> Debian bug 697970 in cups "cups: printing gets wrong after some pages on Epson Stylus Photo 750" [Important,Open] http://bugs.debian.org/697970
<ubottu> Launchpad bug 872483 in cups (Ubuntu Oneiric) "laser printer only prints first job correct" [Medium,Fix committed] https://launchpad.net/bugs/872483
<tkamppeter> OdyX, yes, the printers need quirk rules in th usb backend.
<tkamppeter> OdyX, the user needs to supply the USB VID/PID from libusb and also the usb backend option which solves the problem for him.
<OdyX> tkamppeter: that's in the Debian bugreport
<tkamppeter> OdyX, with this info it is easy to add the new rule to the backend.
<hallyn> SpamapS: i have no idea waht that was about, will have to look at the diff in the rejected queue, thanks
<hallyn> oh, that one
<ogra_> hmm, do we have a versioning policy for package SRUs where the debian version didnt change over several releases but SRUs have to be uploaded to multiple of them ?
<ogra_> s/multiple of them/multiple releases/
<cjwatson> ogra_: https://wiki.ubuntu.com/StableReleaseUpdates links to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging for that
<ogra_> cjwatson, heh, that doesnt really solve my issue
<Laney> 2.0-2ubuntu1 in two releases  2.0-2ubuntu1.11.10.1 and 2.0-2ubuntu1.12.04.1
<cjwatson> ogra_: it doesn't?
<cjwatson> "2.0-2 in two releases         2.0-2ubuntu0.11.10.1 and 2.0-2ubuntu0.12.04.1"
<cjwatson> e.g.
<ogra_> cjwatson, release 1+2 have $package_0.1-0ubuntu1.debian.tar.gz ... the dev release has ubuntu2 ... now an SRU to release 1+2 having exactly the same content as ubuntu2 cant be named ubuntu2 for the SRUs
<cjwatson> (and following one for if it already has ubuntuN)
<ogra_> simply because the ubuntu1.debian.tar.gz differs in the changelog entry
<ogra_> err ubuntu2, sorry
<ogra_> oh, i see
<cjwatson> um, so then it should be ubuntu1.12.04.1 and ubuntu1.12.10.1 if ubuntu2 is in raring - I don't see the problem here
<ogra_> yeah, sorry, missed the bottom line of the table
<barry> mitya57: i'm going to look at your mp again today.  thanks for updating it
<mitya57> barry: thank you!
 * mitya57 will probably also announce pybuild to ubuntu-devel
<dholbach> stgraber, highvoltage: I just found out that the hangout we planned will conflict with UDW :-/
<dholbach> stgraber, highvoltage: would it be OK if we move a week later?
<barry> mitya57: +1!
<stgraber> dholbach: A week later is fine for me, assuming we keep it on the same day and time
<dholbach> stgraber, yep
<dholbach> thanks a bunch!
<ogra_> jtaylor, looks like merge 141288 was long merged, could you cancel the request (or target it to the -updates branch, i guess that would auto close it)
<ogra_> it still shows up in the sponsoring queue
<xnox> what was the name of a package with useful little utilities, like `runone`?
<xnox> bikeshed, watershed or something....?!
<micahg> bikeshed
<xnox> micahg: thanks.
<xnox> although there also is watershed...
<micahg> xnox: it's actually its own source, run-one
<xnox> micahg: now i wonder the difference between run-one and watershed packages....
<micahg> xnox: NIH syndrome?
<xnox> micahg: =Dunno
<xnox> NIH vs :Dustin
<ogra_> urgh, do we have the basics of merging a new upstream releases written down somewhere ?
 * ogra_ glares at a 19MB debdiff that patches 3 new upstream releases on top of orig.tar.gz
<psusi> lol
<Laney> doesn't look like the packaging guide has that for non-UDD
<psusi> debian packaging guide?
<Laney> http://developer.ubuntu.com/packaging/html/
<roaksoax> bdmurray: howdy! DO you mind taking care of bug #1049177 (Precise SRU). It'
<ubottu> bug 1049177 in maas (Ubuntu Precise) "isc-dhcp-server apparmor profile should have include ".d" " [Undecided,New] https://launchpad.net/bugs/1049177
<roaksoax> bdmurray: howdy! DO you mind taking care of bug #1049177 (Precise SRU). It's been sitting in the queue for a loooooooong time!!. Thank you :)
<Snow-Man> pitti: I was thinking some kind of 'default' value for the socket location which would point to the 'primary' instance on the system
<Snow-Man> pitti: but p-common using apps could override that with --cluster
<highvoltage> dholbach: regarding the postponement, +1
<dholbach> highvoltage, gracias!
<mpt> ev, https://wiki.ubuntu.com/ErrorTracker#extra-info
<ev> thanks mpt!
<ogra_> @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:
 * dholbach hugs ogra_
<dholbach> can somebody please moderate my u-d-a mail?
 * ogra_ hugs dholbach back
<cjwatson> dholbach: done
<Sweetshark> slangasek: bug refs cleaned on http://people.canonical.com/~bjoern/precise/
<dholbach> thanks cjwatson
<cjwatson> Most of the half of the world you're looking at is pandabox relocation.
<cjwatson> Err
<cjwatson> ECHAN
 * mlankhorst tries to guess context, fails
<jtaylor> mterry: pycurl, https://github.com/facebook/tornado/issues/671#issuecomment-12635147
<mterry> jtaylor, oh nice
<slangasek> gema: ping
<gema> slangasek: pong
<slangasek> gema: hey - so stgraber and xnox are telling me that on the boot speed profiling box that's having install problems, there's an intermittent X hang, unrelated to the installer itself
<slangasek> gema: have you (QA) talked to the desktop team about this at all yet?
<slangasek> I think we need to bring their expertise to bear
<gema> slangasek: they told us we had to get some logs and reproduce the problem for them to be able to fix
<slangasek> hmm
<gema> can they fix this hang, it may be what's killing the machines
<xnox> there was full syslog in the bug with x hang in it....
<xnox> i'm not sure if xerrors or other interesting things got into it as well or not.
<gema> xnox: can you fix the hang?
<slangasek> gema: we need someone on bryce's team to look at the hang
<doko> bryce, tjaalton: are you planning a xserver upload? want to make xvfb m-a foreign
<tjaalton> doko: got a diff?
<gema> bryce: could you have an engineer look at a hang we have on one of the testing machines that may be killing bootspeed and other HW testing?
<doko> tjaalton, well, it's a one liner
<tjaalton> doko: ah, I can add it
<doko> tjaalton, estimated upload?
<tjaalton> gema: what kind of a hang? I suspect there is an issue with lightdm and the way it interacts with plymouth..
<tjaalton> doko: in a hurry?
<tjaalton> :)
<doko> no, but next week would be nice
<gema> tjaalton: it hangs a ubiquity install as far as we can tell, not sure if we even get to lightdm
<stgraber> tjaalton: the screen completely stops refreshing after a few minutes (which usually ends up being the middle of an install)
<gema> tjaalton: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1096943
<ubottu> Ubuntu bug 1096943 in ubiquity (Ubuntu) "Ubiquity freezes during nfs-based desktop install from recent live destkop images on physical hardware" [High,Confirmed]
<stgraber> tjaalton: none of the two heads show any change even though the machine is still responsive and clearly doing things
<stgraber> tjaalton: attaching with x11vnc to X shows me the same stuck video output, so X isn't completely dead either
<tjaalton> gema: ah, so it's not a boot issue..
<gema> tjaalton: it could be if we managed to get the system installed, but it is not yet
<slangasek> gema: so this causes install failures /consistently/?  I understood it was intermittent
<gema> slangasek: we have all sorts of intermittent issues, this is one hitting bootspeed hardware and PS HW
<gema> slangasek: clearing this would help us make some progress
<slangasek> gema: yes - but you said "if we managed to get the system installed", which I thought was possible
<slangasek> just not reliable
<gema> slangasek: it was at some point
<slangasek> ok
<gema> slangasek: one install out of 7 or 8 will succeed
<slangasek> ah
<slangasek> those are not quite the ratios I was led to understand
<gema> slangasek: some other jobs fail when it reboots randomly
<gema> which can also be due to this bug
<gema> slangasek: 5th boot, 17th boot, 18th boot
<gema> it depends
<gema> slangasek: I hadn't considered before now that it could be X hanging those times also
<gema> slangasek: so we were exploring HW overheating and/or fsck getting on the way
 * slangasek nods
<gema> slangasek: https://bugs.launchpad.net/utah/+bug/1099519
<ubottu> Ubuntu bug 1099519 in UTAH "Bootspeed completes 16-17 runs and then fails to connect to machine" [High,Fix released]
<gema> it's not really fixed, we put togehter a workaround that cannot verify without reliable installs
 * slangasek nods
<tjaalton> gema, stgraber: ok.. can't really look into it now, I'll check it out tomorrow
<gema> tjaalton: ack, thanks
<mterry> @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: mterry
<roadmr> infinity: hello! I finished verifying the bugs for checkbox 0.13.9 (remember?) but the SRU is only 5 days old. Should we wait until it reaches 7 days in -proposed?
<infinity> roadmr: What about http://pad.lv/1061198 ?
<ubottu> Launchpad bug 1061198 in checkbox (Ubuntu) "Candidate revision checkbox_0.13.8" [Undecided,New]
<infinity> roadmr: Oh, which I guess is just a meta-bug, now that I look at it.  Still should have a v-done. :P
<roadmr> infinity: yep, metabug, 0.13.8 failed verification for one of the bugs :/
<roadmr> infinity: which is why we superseded it with 0.13.9
<infinity> roadmr: Yeahp, I remember.  I'm not THAT old.  Yet.
<infinity> roadmr: Anyhow, releasing it now.  Thanks.
<roadmr> infinity: on the contrary, thank you for helping!
<stgraber> kees: had any luck with that seccomp testsuite failure?
<kees> stgraber: yeah, already fixed and sent upstream
<kees> stgraber: http://sourceforge.net/mailarchive/forum.php?thread_name=20130123221333.GN26411%40outflux.net&forum_name=libseccomp-discuss
<kees> stgraber: http://sourceforge.net/mailarchive/forum.php?thread_name=20130123225538.GP26411%40outflux.net&forum_name=libseccomp-discuss
<stgraber> kees: nice!
<hallyn> slangasek: adam_g and jamespage have both noticed /dev/kvm perms not being updated...  and it is seeming to me like i need to do 'restart udev' before the udevadm trigger --action-change in qemu-kvm.postinst.  Do i understand right that inotify should be causing udev to see the new config file without a 'restart udev'?
<infinity> hallyn: Are they running the most recent SRU kernels for precise or raring, by any chance?
<stgraber> kees: doing a quick test build with your patches applied here. If that succeeds on both i386 and amd64, I'll push that to Ubuntu and sync from Debian once you have those there too.
<kees> stgraber: if you want to wait a few hours, -2 should be in Debian unstable once my build finishes.
<stgraber> kees: that'd work too :)
<stgraber> I can certainly wait a few more hours
<kees> cool :)
<slangasek> hallyn: I'm not certain if it's inotify or not, but it's certainly always been the case before that udev picks up new rules automatically.  You should absolutely /not/ be calling 'restart udev'
<infinity> hallyn: (I only ask because inotify's kinda slightly busted right now, and there's a new SRU coming to fix that)
<slangasek> (restarting udev considered harmful)
<stgraber> "restart udev" is clearly wrong, "udevadm control --reload-rules" will do what you want if inotify fails
<hallyn> infinity: ok, *i* am seeing it on very latest raring kernel, yes
<hallyn> jamespage: was on quantal, maybe quantal-proposed
<hallyn> slangasek: stgraber: ok then i won't add that :)
<Snow-Man> pitti: so, yea, using a symlink for the current 'primary' cluster per-port would work fine, imv.
<stgraber> cjwatson, hallyn: I just got that one when upgrading a desktop from 12.10 to 13.04 in LXC. Isn't that the one the grub upload was supposed to fix? http://paste.ubuntu.com/1567189/
<hallyn> stgraber: i don't think so
<hallyn> oh.   yes :)
<stgraber> well, doesn't look like it's completely fixed :)
<hallyn> i bet you broke it.  on purpose.
<hallyn> stgraber: d'oh,
<hallyn> it looks like the latest merge from debian may have dropped the fix
<hallyn> no, there it is, in postinst.in
<infinity> stgraber: Is this a container issue, or...?
<infinity> /usr/sbin/grub-probe: error: failed to get canonical path of /dev/mapper/castiana-home
<hallyn> infinity: yes, grub is not supposed to try to install in a continer (not safe)
<infinity> ^-- Surely, that shouldn't happen.
<hallyn> and yes, /dev/mapper isn't set up in the containers :)
<hallyn> but even if it resovled to /dev/dm*, it would still fail update-grub
<infinity> hallyn: Okay, then whatever logic was added to postinst.in needs to be elsewhere, since zz-update-grub doesn't use that. :P
<hallyn> infinity: doh! :)
<hallyn> what is zz-update-grub
<stgraber> yeah, I think we cover it for the case where we just install grub-pc but not for when upgrading kernels which is what I was doing here (12.10 -> 13.04 dist-upgrade)
<infinity> hallyn: /etc/kernel/postinst.d/zz-update-grub
<hallyn> yeah under debian/kernel.  pshaw
<stgraber> so it sounds like we'll need another round of SRUs to get rid of the problem for good
<hallyn> well, is zz-update-grub a new thing in raring?
<infinity> hallyn: No.
<hallyn> nope
<hallyn> S i g h
<hallyn> stgraber: have you filed the bug?
<stgraber> hallyn: not yet, but I can do that now
<hallyn> stgraber: was this an ubuntu-cloud-based container?
<hallyn> just twondering why you had a kernel image installed otherwise
<stgraber> hallyn: I was working on the auto-dist-upgrader which does Ubuntu Desktop dist-upgrade testing (and so has a kernel and grub installed)
<hallyn> stgraber: it looks like taking a full ubuntu desktop iso install and upgrading it might oughta be a regular lxc test
<stgraber> hallyn: well, once I have the dist-uprader running again with LXC, it'll be doing a dozen of those a day on my box, so we'll catch any regression for sure ;)
<infinity> stgraber: The problem here is that if we skip update-grub altogether, your grub config will be wrong.
<hallyn> stgraber: cool :)
<infinity> stgraber: So, if you use a container to do your upgrade, then reboot that into a VM or bare metal, it... Won't.
<hallyn> well we could try to get fancy and (a) (as discusssed before) set up /dev/mapper entries inthe container at startup and (b) let apparmor/userns be the one to stop update-grub from writing to the host's /
<infinity> In the update-grub case, it's not actually trying to write anything to boot records, just probe values to update the config.
<stgraber> hallyn: I don't know why, but I'm not fond of the idea of having /dev/mapper in my container, even if apparmor is supposed to prevent me from accessing it :)
<hallyn> but that has the problem,
<hallyn> stgraber: right, and we'd be accomodating a veyr rare special case while making update-grub fail and break upgrades in the common case
<hallyn> (common case being /var/lib/lxc/r1/rootfs is jsut a directory on host's /)
<stgraber> infinity: In my case I don't expect the container to ever be bootable in a VM without re-running update-grub anyway as the container is just a directory on my laptop and so doesn't have a partition which means no real UUID
<stgraber> infinity: so as far as I'm concerned, it's fine skipping update-grub entirely in this case and the weird case of people booting a VM image in a container, then dist-upgrading in the container and finally booting in the VM, well, they'll just get the old kernel, that should still be bootable
<infinity> stgraber: Well, we could make update-grub exit 0 at the top for containers, I'm just trying to determine if that's a good or a bad thing for all usecases.  As a non-container-user, I have no idea.
<hallyn> infinity: i think cjwatson had in the past rejected that, but i could be wrong or, if i'm not, don't recall why
<stgraber> one fix would be to check if the backing device exists and is writable. If it's, then go ahead, if it's not, then skip it. That should work fine with any container and non-container paths and if someone really wants grub to read/write to the partitions and MBR, then they just have to create those entries, update apparmor and update the device cgroup settings.
<infinity> stgraber: That's kinda broken for grub-probe's obviously useful failure mode of "your system is actually broken, doofus".
<infinity> stgraber: (eg: a desktop system with a broken /dev, or other such possibilities)
<infinity> stgraber: Papering over the failure because some systems are broken by design feels wrong.
<stgraber> hmm, indeed. Though if that specific check was done only for containers, it'd be half-decent I guess
<hallyn> empowered by design
<infinity> stgraber: Well, that goes back to the "if it's a container, just exit" thing. :P
<hallyn> <chuckle>
<hallyn> right.
<infinity> stgraber: But yeah, I guess probe itself could learn about containers and... I don't know what.  Return bogus info?
<hallyn> i think 'if it's a container, just exit' is ok until we have device namespaces (or something like it)
<hallyn> after all, once we have device ns, we can run udev in the container and /dev/mapper will be there
<infinity> I assume flask-kernel in ARM containers suffers similar pain.
<infinity> s/flask/flash/
<infinity> Obviously, I need a drink.
<mterry> @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:
<hallyn> minor slip :)
<stgraber> bug 1104463
<ubottu> bug 1104463 in grub2 (Ubuntu) "/etc/kernel/postinst.d/zz-update-grub triggers a grub update in lxc containers" [Undecided,New] https://launchpad.net/bugs/1104463
<infinity> stgraber: Alright, expanded on your summary of the discussion a bit.
<stgraber> infinity: thanks
<bdmurray> bryce: do you have an opinion on removing xserver-xorg-video-intel from oneiric -proposed?
<bryce> bdmurray, huh, that's the old libreoffice start screen fix, jeez that's ancient
<bryce> bdmurray, that was an easy fix, and quite safe, and very straightforward to reproduce/verify, but it's just a minor cosmetic problem.  If no one is complaining about it, it probably doesn't matter.  It's hard to care much about oneiric issues at this point.
<bryce> bdmurray, sort of a shame to toss the sru after all the work that went into it though.
<bryce> it annoys me we lose so many X SRUs because people don't verify them.  :-(
<infinity> bryce: If it's easy to reproduce/verify, someone should have done so.
<sarnold> it feels like I see an SRU expiry every day or two. tat feels like an astonishing amonut of work to lose..
<infinity> I might have to actually document this somewhere other than the heads of me, cjwatson, and wgrant, but we can actually rescue deleted SRUs (binaries and all).
<infinity> So, if someone suddenly feels the urge to verify something, we don't need to redo the work.
<infinity> We can just copy it back in over itself.
<infinity> But having stuff sitting in proposed for a year isn't doing anyone any favours.
<bryce> infinity, yes someone should have; that was a trivially easy one to reproduce.  I did the verification myself for precise IIRC.
<sarnold> infinity: nice to know it isn't immediately fatal :) but still... *sniff*
<infinity> bryce: I tend to try to verify most of my own uploads these days, just to avoid the frustration of others not doing so.
<bryce> infinity, I'm tempted to install an oneiric build just to do the same here, but not a great use of a couple hours...
<infinity> (I realize as I say this that I currently have an unverified SRU in precise that I need to do something about...)
<bryce> infinity, yeah me too where I can.  With X, so many problems are HW-specific though
<bdmurray> I guess with X bugs its harder to verify them yourself
<hallyn> infinity: though i thought technically the rules, uh, 'encouraged' the bug fixer not doing the verifications?
<infinity> Yeah, X and kernel are both problematic that way.
<hallyn> still i try to give it a week and then go and verify
<infinity> hallyn: I have zero issues with the fixer actually verifying.  I have issues with the fixer rubber-stamping it without actually testing the binaries.
<hallyn> infinity: that's good to know
<infinity> hallyn: The latter case is the reason I *prefer* the submitter verifying, only because he has a vested interest in actually testing it instead of lying.
<bryce> infinity, also in solving the bugs we often identify some work around for the user to test, and often the user is just fine sticking with that workaround, so we lose them for testing the "real" fix.
<infinity> hallyn: But it comes down to trust, to a certain degree.  And I trust some uploaders not to lie to me or cut corners. :P
<hallyn> infinity: haha, given the embarassment of the fix not fixing it, i do feel like as fixer i ahve a vested interest :)  but i understand
<infinity> hallyn: It's generally a combination of laziness and hubris.  If you're *sure* your change was correct, you'll feel like you can totally fudge the paperwork and no one will notice.
<infinity> hallyn: And then when you're wrong, well.  Grr.
<infinity> hallyn: So, just don't do that (which I'm pretty sure *you* don't), and it's all good.
<infinity> bryce: Yeah, the workaround thing can be doubly problematic, if you get them to mangle a conffile or something, and they forever are unable to correctly test the upgraded package against an unmodified setup due to a subsequent communication failure.
<infinity> bryce: But, such is life.  Oh how I wish we had a massive community QA team who could independently repro/verify half these bugs.
<infinity> (On the other hand, I'd also like to see fewer SRUs, so...)
<infinity> I do think the knee-jerk of "I fixed a bug in release X, and I must not backport it to A, B, and C is just not scaleable at all.
<infinity> s/C/C"/
<infinity> I don't have issues with us adding a ton of polish to LTS releases, but we could do with a lot fewer SRUs to interim releases for non-critical bugs, IMO.
<infinity> s/must not/must now/ up there.  Man, I can't type today.
<hallyn> infinity: actually openstack and juju are making that worse i think - everyone wants the fixes backproted to precise so it'll work in juju.  Which is understandable, but more work.
<infinity> hallyn: Well, like I said, I don't mind the precise SRUs, per se.  But we have a ton of quantal ones, and even a fair few oneirics still, and the reason is because uploaders say "well, this patch applies cleanly to all three releases, it's almost zero effort for me to SRU them all".
<infinity> hallyn: And that's true.  But they're not thinking of the burden of post-upload verification and release for what is, 99% of the time, not a critical bug.
<infinity> IMO, for non-LTS releases, if it install, boots, doesn't blow up your hardware, and gets security fixes, we're more or less done.
<infinity> (Yes, there are ciritcal bugs that don't fit in that broad scope, but you get the idea)
<hallyn> infinity: yeah
<infinity> hallyn: Now, we don't want to cause massive regressions when upgrading through releases, of course, but "this image is a bit less pretty than I think it should be" or "there's a typo in this thing over here" or whatever isn't really much of a regression.  And the answer is always "well, upgrade to the next release, then, it's fixed there, because all SRUs have to be fixed in our current devel release".
<infinity> All of this is probably just me accidentally arguing for getting rid of interim releases altogether and only doing LTSes, but let's pretend I didn't say that out loud, cause we're not even ready to discuss that sort of thing yet, and I'm also not sure which side of that fence I'm personally on. :P
<slangasek> or better yet: "hey, you know we have a constantly-usable trunk in our devel release now"
<infinity> slangasek: Jinx.  Ish.
<infinity> A curious side-effect of ditching interim releases (if we were to do so) is that LTSes might get better support from the usual SRU overachievers.
<infinity> Cause the people who currently feel they need to SRU to quantal/precise/oneiric would instead look into backporting to precise/lucid/hardy.
<dobey> 2 years is a very long time; some of the differences are just not reconcilable with simple SRUs
<infinity> dobey: Sure, and that's almost a positive.  Cause many bugs aren't worth SRUing back to old LTSes when the answer should be "sorry, upgrade to precise if you want that fixed".
<dobey> shipping unity on lucid would be fun though
<infinity> dobey: But there are also a lot of bugs that probably SHOULD be fixed in older LTSes that get ignored in favour of people fixing things in oneiric for very little benefit.
<dobey> probably
<infinity> dobey: So, meh.  It's hard to debate how it would actually turn out.  But I suspect less focus on interim releases would both reduce the SRU workload and accidentally produce a few more fixes for old LTSes in the process.
<dobey> but i wouldn't say that is entirely becuase interim releases exist
<infinity> dobey: No.  There are any number of reasons people don't fix bugs in older releases.  Sometimes, it's too hard, sometimes it's easy but they just don't personally see the value, etc, etc.
<infinity> But hey, I don't see the value in fixing anything but hardware-exploding critical bugs in oneiric either, and people do it.
<dobey> there'd probably be a few more fixes making it back, but i wouldn't guess that it would be a significantly useful increase
<infinity> If those same people had oneiric taken away from them, they'd need an outlet, right? :)
<infinity> dobey: Anyhow, all just random stream of consciousness faff.  It's not like we're planning to announce the end of the 6 month release cycle any time soon.
<dobey> yeah i know
<infinity> (Though, I suspect you'll hear more discussion about it off and on leading up to 14.04)
<dobey> have heard plenty of faffing about it over the past several cycles already as well :)
<bryce> infinity, I'm coming to be of the same opinion vis a vis SRUs for interim releases, although usually once you've sorted out the backport for A (stable) and C (LTS), the fix for B is almost for free anyway.
<slangasek> bryce: the uploading is almost for free, the verification is a huge cost
<dobey> although i'd also presume that if we do kill off interim releases and only do LTS, that we'll end up just doing LTS every 12 or 6 months, and have similar problems with getting more fixes backported; especially with LTS being 5 years across the board now
<slangasek> "LTS every 12 or 6 months" - certainly not :)
<hallyn> lts every 6 months?
<hallyn> :)
<hallyn> phew
<bryce> slangasek, exactly - the verification cost is why I'm coming to this opinion.
<dobey> 18-24 month releases are nice for having more development time, but also a huge drain. spending a year doing a bunch of work and then having all your requirements change for the release, is not fun :)
<bdmurray> roaksoax: isc-dhcp has been sitting in precise-proposed for a long time because bug 974284 and bug 727837 are unverified
<ubottu> bug 974284 in isc-dhcp (Ubuntu Precise) "invoking dhclient3 with -1 causes issue if no dhcp server available" [High,Fix committed] https://launchpad.net/bugs/974284
<ubottu> bug 727837 in dhcp3 (Ubuntu Hardy) "dhcp3-server fails to drop privileges properly" [Undecided,Confirmed] https://launchpad.net/bugs/727837
<cjwatson> stgraber,hallyn,infinity: this is all already fixed in Debian/experimental/bzr and precise-proposed, just not yet in raring
<Kano> hi, who works on secure boot? just got a board with it but kubuntu did not boot but fedora did
<stgraber> bdmurray: I guess I can confirm those two if you want. But I'm the author for both patches and the uploader, so not ideal :)
<bdmurray> stgraber: I thought infinity was just saying that was fine
<stgraber> bdmurray: yeah, I tend to self-verify my SRUs when nobody else does it and I actually care about the fixes, those two I really don't care about so didn't bother verifying :)
<stgraber> bdmurray: marked both verification-done
<infinity> cjwatson: Ahh, I think stgraber's assumption was that raring and precise-proposed had the same behaviour, if that's not true, yay.
<stgraber> infinity: that was my assumption based on the, upload to dev before sruing habit, I didn't actually diff the scripts to check :)
<cjwatson> Right, I make sure it's committed *somewhere* so it doesn't get lost, but I consider "repository that will definitely end up in raring at some point before release" as acceptable
<cjwatson> I'm doing an experimental build now anyway
#ubuntu-devel 2013-01-25
<Kano> cjwatson: why is grub2-signed not build against current grub2-11?
<Kano> interestingly it shows 2.00-11ubuntu1 but the changelog shows 2.00-7ubuntu13??
<Kano> http://changelogs.ubuntu.com/changelogs/pool/main/g/grub2-signed/grub2-signed_1.10/changelog
<Kano> cjwatson: btw. you should check kubuntu, ubuntu boots but kubuntu does not
<vagrantc> cjwatson: do you know if the current process for building live CDs on ubuntu is basically: https://lists.debian.org/debian-live/2011/06/msg00152.html ?
<vagrantc> or anyone, really...
<slangasek> vagrantc: that's not a complete description of our build process, but it's accurate as far as the livefs /on/ the CD is concerned
<slangasek> (there's an extra layer of indirection, where the livefs is fed to a different build server that puts it into a hybrid filesystem along with the bootloader, on-disk package archive, etc)
<vagrantc> slangasek: is it expected to build self-hosting... i.e. precise can build a precise live image?
 * vagrantc was hoping to create customized images through an automated process, but most of the docs recommend using uck
<slangasek> vagrantc: wrt the livecd-rootfs and live-build packages, yes
<vagrantc> slangasek: i must be missing something(s)... it flounders at many steps along the way.
<vanhoof> vagrantc: perhaps http://paste.ubuntu.com/1567760/ will help
<slangasek> vagrantc: well, again since we only use live-build for the livefs creation, it's possible the packages don't work OOTB when you use them to create a full ISO
<vanhoof> vagrantc: that yields good results for me
<vagrantc> vanhoof: thanks, will give it a go.
<vagrantc> slangasek: i can get it to create a squashfs, but no ISO image.
<slangasek> vagrantc: right, which is exactly how we're using it ;)
<vagrantc> so it "works"
<slangasek> and the ISO image creation scripts are unfortunately not sorted out for releasing
 * vagrantc hrms
<vagrantc> hopefully vanhoof's suggestion will get me what i need.
<pitti> Good morning
<dholbach> good morning
<BWMerlin> Nvidia has released new stable drivers, what is the process for these to be included into the ubuntu repositories?
<tjaalton> siretart: hey, are libva & intel-vaapi-driver syncable from experimental?
<tjaalton> at what time UTC are the daily-live images getting built? and is there a build-log available somewhere?
<xnox> tjaalton: people.canonical.com/~ubuntu-archive/
<xnox> livefs-build-logs/
<xnox> and
<tjaalton> thanks
<xnox> cd-build-logs/
<xnox> depends which stage you are after.
<xnox> tjaalton: sometime around now, but it takes time to sync and publish the iso tracker can give you an overview.
<xnox> http://iso.qa.ubuntu.com/qatracker/milestones/243/builds
<xnox> e.g. some stuff is from today other isn't (some have failed)
<jibel> tjaalton, if you're searching with version of -intel was in there, you'll have it in the manifest http://cdimage.ubuntu.com/daily-live/20130124/raring-desktop-amd64.manifest
<xnox> ubuntu desktop builds failed due to missing python-oneconf, which has been resolved now as far as I can see.
<jibel> *which
<tjaalton> jibel: ah, yeah
<jibel> xserver-xorg-video-intel	2:2.20.19-0ubuntu1
<tjaalton> didn't think of that :)
<tjaalton> so not the snapshot from yesterday then
<tjaalton> wonder what else changed so the installations passed..
<apw> pitti, we seem to be missing the amd64 ddebs for linux-3.2.0-36.57, can we tell why ?
<pitti> apw: sorry, that got built 8 days ago, so they are already gone from the buildds :(
<pitti> apw: for debugging that it would be good if you could poke me the next time an upload/accept/build happens, so that I can save the ddebs from the buildds some where and then debug how they appear/disappear on ddebs.u.c.?
<apw> pitti, well i think we did some new ones in the last two days
<apw> pitti, the latest P and Q kernels
<apw> pitti, some support folks mirror these and they say it never appeared as they don't have them
<pitti> apw: no, they were built on January 8 and 9 respectively
<pitti> https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4200994
<pitti> https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4200999
<pitti> apw: checking if lamiak and panlong respond to ddeb fetching
<pitti> apw: one important difference is that they are being built in a PPA instead of the normal distro; that might play into it
<apw> pitti, i am saying that their non-deleting mirror of ddebs.u.c never got a copy of them, so more than likely they were not added to ddebs rather than deleted
<pitti> *nod*
<pitti> hm, htey do use the normal distro builders (blessed PPA), so it's not that
<pitti> so raring's ddebs are there; I'll copy them in case they disappear as well
<pitti> (for investigation)
<Kano> hi, where is the script that creates the current iso images incl. shim?
<pitti> apw: ok, I made a hardlink backup tree of http://ddebs.ubuntu.com/pool/main/l/linux/
<pitti> apw: but I'm afraid we really need a fresh (i. e. < 7 days) build from the PPA in order to investigate this :(
<pitti> or get ddebs into Launchpad properly
<Kano> 12.10 kubuntu was not bootable, only grub showed with secureboot
<Kano> ubuntu worked
<Kano> the linux command did not succeed there
<apw> pitti, we built two like yesterday
<Kano> cjwatson: can you help?
<apw> pitti, in fact linux - 3.2.0-37.58 is building still for armhf, but built on x86
<pitti> apw: ah, great; looking at that one
<pitti> oooh! I have an idea
<pitti> apw: so the build happens in the PPA at day 1; the ddebs are fetched, but they aren't put into the Packages.gz indexes as they are not in the distro yet
<infinity> pitti: Oh, is it the delay of the SRU process that's getting them killed/lost? :/
<pitti> apw: then on a day > 5 the kernel is copied to the distro
<pitti> apw: at that point ddeb-retriever will have them cleaned up, as they appear nowhere in the distro
<infinity> (Though, I usually do my copies in under 5 days, that's certainly not guaranteed)
<pitti> it isn't really built with that "copy from PPA" model in mind
<pitti> but let me check the ddebs on the buildds
<apw> and that would explain amd64 as that is typically done the quickest
<apw> so would hit 5 days soonest
<pitti> so 3.2.0-37.58 isn't on https://launchpad.net/ubuntu/+source/linux/+publishinghistory yet, as expected
<infinity> pitti: This could also explain random complaints about security updates without ddebs, since they follow the same PPA->archive model, and VERY often have a testing delay of a week or more before unembargoing.
<pitti> but http://ddebs.ubuntu.com/pool/main/l/linux/ has them
<BWMerlin> Nvidia has released new stable drivers, what is the process for these to be included into the ubuntu repositories?
<infinity> BWMerlin: tseliot tends to be on top of this.
<pitti> apw: ok, I think we nailed it; I'll bump the "max age" of unowned kernel debs to a month
<apw> pitti, could we perhaps add a " version <= newest pocket version "
<pitti> we have the space now
<apw> well that cannot hurt for sure
<infinity> pitti: Special-casing kernels doesn't help security.
<infinity> pitti: But I suspect kernels are the major use-case people notice.
<infinity> pitti: (And this should all go away sooner, rather than later...)
<pitti> yeah, we'll need some ">=" version comparison as apw suggests
<apw> i would think not removing a .ddeb which represents a version in the future ever would fix it right for everything
<pitti> ah, since we switched to germanium the "max age" is back to 14 days
<infinity> apw: Except then we would have ddeb cruft ~forever for people who build test packages in devirt PPAs, or kernel/security/etc building something that doesn't get copied, or even package removals from -proposed.
 * pitti bumps to a month
<pitti> ^ for all packages
<pitti> /dev/cciss/c1d0p1     393G   19G  370G   5% /
<pitti> *shrug* :)
<infinity> pitti: Shiny.
<pitti> err, that actually:
<pitti> /dev/mapper/ddebs_vg  2.8T  517G  2.3T  19% /srv
<apw> heh
<infinity> pitti: I'm going to try to find the time next week to look into the librarian solution (again), so maybe we can stop worrying about the hackish attempts at aging, and you can just do 1:1 mapping from published binaries to their matching ddebs.
<BWMerlin> infinity: I am trying to find information about it's progress, I have checked the bug tracker but couldn't find any mention of it
<infinity> BWMerlin: That was a hint to, perhaps, ask tseliot, who does these updates.  What version is this new stable version?
<pitti> infinity: that'd be great indeed; that doesn't relieve germanium of the two hours that it takes to produce indexes, but at least it would solve the "data loss" problem
<BWMerlin> 313
<tjaalton> BWMerlin: it's an experimental version..
<infinity> BWMerlin: Ahh, yeah, we still seem to be at 310ish.  But ping tseliot if you're curious.  I suspect he already knows about the new upstream, but it doesn't hurt to politely ask.
<infinity> (keyword: politely)
<BWMerlin> tjaalton: there are new 310 and 313 drivers
<tjaalton> 310 is the stable one
<tjaalton> which raring has
<infinity> tjaalton: Though, not the same version as upstream.
<infinity> tjaalton: (310.19 vs 310.32)
<tjaalton> ok
<tjaalton> released on monday, so quite fresh
<BWMerlin> yes, I have some errors with the current version that I am hoping that new version corrects
<tjaalton> ubuntu-bug nvidia-graphics-drivers-310
<tjaalton> maybe not necessary though
<siretart> tjaalton: I would think so, but testing it beforehand wouldn't hurt
<tseliot> infinity: I only have to upload the latest nvidia driver (310.32). I worked on it yesterday and I hope to upload it today
<siretart> tjaalton: I think I have even testbuilt them, but nothing more
<tjaalton> siretart: what can it be tested with? :)
<tjaalton> I tried a year ago and it was a disaster back then
<siretart> tjaalton: that's a good point :-)
<Kano> kubuntu raring does not start with secure boot and quantal does not too
<tjaalton> siretart: I could try with the mplayer port with va-api support
<Kano> why not?
<tjaalton> siretart: the gstreamer situation is a bit weird still, with all the various branches etc
<Riddell> Kano: hmm I think we have some things missing from our seeds
<xnox> Kano: as far as I know #kubuntu is not SB enabled.
<siretart> tjaalton: neither mplayer nor mplayer2 support vaapi
<cjwatson> Riddell: if you want it done for 12.04.2, let me know and I should be able to sort it out on Monday.  (But it ought to be done for 13.04 first, really.)
<Kano> xnox: but it starts grub, so shim must be there
<Kano> it just can not load the kernel/initrd then
<infinity> Kano: Missing linux-signed-generic, I assume?
<Kano> no idea
<Kano> i got my efi enabled board yesterday
<tjaalton> siretart: there is a ppa which has a version that does
<tjaalton> apparently
<siretart> tjaalton: that's some bastardized fork of an outdated codebase, whose create seems to have no interest in submitting his work upstream.
<siretart> s/create/creator/
<tjaalton> siretart: ah, well I'm interested to see if I can reproduce a bug in the driver :)
<siretart> tjaalton: :-)
<tjaalton> not really interested in the player itself
<siretart> i would appreciate if people would stop calling it mplayer, the mplayer 'situation' is already way too confusing as it is right now.
<siretart> with 'it', I mean that vaapi fork
<Kano> siretart: did you get it compiled? i only saw 3 branches
<siretart> Kano: i'm not interested in outdated, stale code branches, so no.
<Kano> siretart: there is a git repo, did you look there?
<siretart> no
<Kano> http://gitorious.org/vaapi/mplayer
<Kano> but somehow you would need all 3 branches merged
<siretart> last activity, August 20, 2012.
<tjaalton> siretart: is there some other player with vaapi support?
<Kano> tjaalton: sure, xbmc
<Kano> tjaalton: and vlc
<siretart> tjaalton: vlc exists, and I'm told gstreamer can do vaapi as well (but I haven't tested that)
<tjaalton> vlc is fine
<Kano> no compared to xbmc vlc is bad
<siretart> Kano: too bad that we do not have xbmc in ubuntu
<Kano> then compile it
<Kano> 5 min on a new box
<tjaalton> not that interested
<tjaalton> vlc is fine if it allows me to repro the bug
<ogra_> we do have xbmc
<Kano> has too high cpu load
<ogra_> in raring at least
<siretart> ogra_: omg. how did this pass ftp-master license review?
<Kano> it is even in debian
<Kano> because it is build without internal ffmpeg
<Kano> i prefer the normal xbmc with builtin ffmpeg
<ogra_> siretart, dunno,didnt check, i just know it is famous on arm recently
<siretart> Kano: that's my main concern with it. in debian/experimental it is built against internal ffmpeg, which makes it IMO unsuitable for a distribution usage.
<siretart> ogra_: well, not my call anyways.
<siretart> gotta work to do, bbl
<Kano> there are so many branches that i build it directly anyway
<Kano> you need a different branch for xvba
<Kano> does not take long to compile, maybe it takes longer to dl the code ;)
 * xnox crashed software center =)
<xnox> ... i'm one of 2298 times who managed it.
<mvo> xnox: whats the bugnumber?
<davmor2> mvo: how do
<xnox> mvo: created from errors bug 1105021 , I have a fix for it already, testing now + will propose a merge. It only affects raring (based on errors data)
<ubottu> bug 1105021 in software-center (Ubuntu Raring) "/usr/share/software-center/update-software-center-channels:NameError:<module>:check_for_channel_updates_and_trigger_axi:trigger_axi_update_and_wait" [High,Confirmed] https://launchpad.net/bugs/1105021
<mvo> xnox: are you on it already?
<xnox> mvo: yeah. It's just missing an import =)
<mvo> cool
<xnox> and I know how to trigger it ;-)
 * mvo hugs xnox
 * xnox hugs ev for giving me data to react to this
<mitya57> hi barry :)
<bdrung> Sweetshark: mail responded. when will be the latest time to send you stuff before you leave for vacation?
<Sweetshark> bdrung: today is my last day, and while I leave at ~midnight, I still have some packing to do.
<bdrung> okay
<ev> xnox: yay!
<xnox> mvo: so how does one install i386 packages only, via software center? do I must provide a :amd64 package that simply depends on :i386 package? (e.g. like skype & skype-bin) cause VMware view client is in the app-install-data now (i fixed it localy) & yet it is "not found"
<infinity> xnox: Oh, have you hijacked vmware-view-client from me?
<infinity> xnox: Not that I mind if the answer is yes. :P
<xnox> infinity: no, I haven't. I'm trying to teach software center that one can install vmware-view-client on amd64 machines.
<xnox> via app-install-data-partner.
<infinity> xnox: If software-center can't see multiarch binaries from secondary arches, that seems like an SC bug.  Pretty please don't work around it with dummy amd64->i386 packages. :/
<xnox> ev: I've used errors to fix a crasher, I even made a merge proposal for errors to fix a small bug there. Clearly you should code review my usb-creator branch in return =))))
<infinity> (We could repackage vmware-view-client like Skype, but we really shouldn't have to)
<xnox> infinity: ok, i'll just mark it i386 only in app-install-data, but then like most desktops that want to use vmware-view-client won't be able to install it via usual ways.
<xnox> infinity: it's not fair to hour office building buddies.
<xnox> s/hour/our/
<infinity> xnox: Well, it *is* i386-only.  The point I'm making is that software-center should still show it anyway if you have i386 enabled.
<infinity> xnox: Does this fiddling mean that its stack is actually installable now?
<infinity> Ahh, it is in raring now, at least.
<xnox> yeah, it is =)
<infinity> xnox: I vaguely remember not caring before because its dependencies weren't all multiarched.  Looks like that's been fixed in precise too now.  Shiny.
<infinity> xnox: So, yeah.  I *could* repackage it with a foo/foo-bin approach like skype, but I'd rather you get mvo's opinion on why SC doesn't display it in the current state, and how/if that should be fixed.
<infinity> xnox: Cause cross-arch deps like that are a hackish workaround, not something we should be doing just cause.
<infinity> xnox: (For skype, it was to enable smooth upgrades, since there used to be a skype:amd64 that depended on ia32-libs, there never was such a thing for vmware-view-client)
<xnox> for enough earl gray tea & biscuits foo/foo-bin in -partner is not that hard =)
<infinity> xnox: No, it's not hard, it's *wrong*.
 * xnox makes a sad face, starts crying and says "but i like biscuits" =))))))
<infinity> xnox: skype should be the exception here (due to the upgrade path issue), not the rule.
<xnox> ok.
<xnox> let me experiment and see if there is a regular reproducer in the archive.
<xnox> well. i guess partner kind of is, but i'm sure there was something like that synced from debian as well
<infinity> You'll be hard-pressed to find things in the regular archive that only exist on one arch and are sensibly multiarched.
<infinity> Some kernels, perhaps, but they don't show up in SC anyway.
<infinity> vmware-view-client seems like a good enough testcase, don't see why you'd need another.
<xnox> true.
<infinity> xnox: I doubt SC understands multiarch at all, but if it does, it might be accidentally assuming that packages without MA headers aren't valid candidates?
<xnox> infinity: on the other hand one should not see 2 gnome-terminals.
<infinity> xnox: More realistically, though, it's probably just not even looking at foreign arches.
<infinity> xnox: Why would you?
<janimo> pitti, hi, are we following udev in systemd currently?
<infinity> xnox: apt-cache search gnome-terminal && apt-cache search vmware-view-client : you only see one of each, it picks the best candidate.
<infinity> xnox: This is no different than having more than one candidate in, say, release, updates, security, and proposed.  SC only shows you the "best", not all of them, I hope. :P
<xnox> hmm...
<janimo> pitti, as in backporting changes from it but not rebuilding from that source tarball?
<infinity> janimo: I was pretty sure slangasek had master plans to start building udev directly from the systemd sources at some point.
<infinity> janimo: It was one of the driving factors for me getting kmod in the archive.
<infinity> janimo: But something may have stalled there.
<bdrung> Sweetshark: do you have SRU plans for bug #628105?
<ubottu> bug 628105 in libreoffice (Ubuntu) "[Upstream] Text not black in LibreOffice" [Undecided,Confirmed] https://launchpad.net/bugs/628105
 * janimo just made a local change to udev only to discover it being already added in systemd/udev two weeks ago
<infinity> bdrung: Did you get that cherrypicked to upstream stable branches, or only land it on trunk?
<infinity> bdrung: (If you'd had it cherrypicked, SweetShark would be picking it up 'for free' in SRUs)
<pitti> janimo: no, we don't right now
<infinity> bdrung: Otherwise, you may have missed the boat for precise for now, as he just did a big point release update. :/
<pitti> janimo: I have the most current standalone udev release in the raring bzr branch, but it doesn't work right now
<pitti> janimo: I also built some test packages with systemd's udev, which do seem to work
<pitti> but I didn't spend much time on it, as it bumps soname, requires changing our ConsoleKit, and I don't have enough time to do all that
<bdrung> infinity: in landed only in trunk (and will be part of 4.0). i saw that a sru upload landed in proposed. the question is if there are other outstanding fixes that will be bundled for after the point release
<bdrung> s/in/it/
<infinity> bdrung: Well, I'm sure he'll do another micro release at some point, so just making sure this is queued up for that would be reasonable.
<infinity> bdrung: (Shame that didn't happen for this current upload)
<ev> xnox: will do :)
<bdrung> infinity: IIRC, the currently accepted sru upload stuck in the unapproved queue for some time
<infinity> bdrung: I could kill off the two ARM builds of LibreOffice if you and SweetShark can agree on a quick follow-up with one or two small bugfixes. :P
<bdrung> Sweetshark: ^
<infinity> bdrung: The current one was only in unapproved for an hour or two.  The previous one was in for a while until it was rejected, yeah.
<janimo> pitti, for udev package changes should I file a bzr merge req on https://code.launchpad.net/~ubuntu-branches/ubuntu/raring/udev/raring ?
<pitti> janimo: please don't for now, as that's the new version which is failing horribly
<pitti> janimo: i. e. either just push --overwrite it with what's actually in raring (I have a local copy of teh branch here, it's fine), or just dput
<bdrung> infinity: i am busy with university stuff. so please poke sweetshark (or me in a few hours)
<janimo> pitti, ah dput  without touching bzr branches? I am fine with that
<infinity> bdrung: I should be busy napping.  It's 6:30am and I haven't done that yet.
<infinity> bdrung: But if you guys agree on replacing the current proposed version with something with one (or a few) small, auditable bugfix(es), I'm okay with that, and likely to accept it.
<infinity> bdrung: Shame about the buildd resources, but life's like that sometimes.
<infinity> bdrung: Beats pushing two rapid updates to end users.
<bdrung> infinity: i would go for replacing the current proposed version, but let's wait for Sweetshark's comment. the diff is auditable: https://launchpadlibrarian.net/129007971/autocolor.debdiff
<infinity> bdrung: Yeah, that diff is totally auditable, and I'm happy with it.  I was implying that there may be other forgotten fixes one might want to sneak in too.  Given the age of this one, that seems like a likely scenario. :P
<bdrung> infinity: IIRC, the other one or two bug fixes landed in the proposed version
<infinity> Anyhow.  Quick nap time.
<seb128> bdrung, infinity: please let libreoffice where it is
<seb128> it tooks us 1.5 months to get that version accepted in proposed
<seb128> we will do follow up uploads
<seb128> but we need to get that one through, and I'm not wanting to play "let's kick it out and replace it"
<seb128> especially that Sweetshark is off for 2 weeks starting tonight
<mpt> ev, is backporting the error tracker to 11.10 or earlier still a realistic possibility, or shall I drop that from the spec?
<ogra_> 11.10 goes out of support in april ...
<mpt> So does 10.04, right?
<ogra_> sounds pretty pointless unless you want a catchall for 11.10->12.04 upgrade errors
<ogra_> 10.04 on the desktop
<mpt> yeah
<ogra_> server still stays for 2 years
<mpt> and we don't have server error tracking yet anyway
<mpt> Dropped: https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=142&rev1=141
<mpt> ev, for these developer settings for the error tracking, I wonder if we could/should offer blacklisting of any package that you have installed from a PPA
<mpt> I guess "could" depends on bug 1091228
<ubottu> bug 1091228 in apt (Ubuntu) "No record of which repository a package was installed from" [Medium,New] https://launchpad.net/bugs/1091228
<cjwatson> Not really
<cjwatson> I mean, it doesn't matter if you've installed it from a PPA and it has since been copied into the primary archive, does it?
<mpt> sure it does
<cjwatson> Well, I guess if it's been superseded by a later version then it might be hard to tell
<mpt> Well, it depends on the motivation I guess
<cjwatson> But I'd have thought a reasonable first cut would just be to check the current origins (analogous to apt-cache policy)
<mpt> If the motivation for not wanting to report PPA errors is to avoid spamming the error tracker with errors Ubuntu developers can't fix, then as soon as it's copied into the primary archive, they can fix them
<mpt> but I was thinking more developers who are using a PPA for testing before going to MyApps/ARB
<mpt> Even then, for both us and them, it would be more interesting if we could give the developers access to those error reports, than to spend time letting their beta testers block just those error reports...
<BWMerlin> I keep getting the following error when I try to install glx-alternative-nvidia The following packages have unmet dependencies: glx-alternative-nvidia : Depends: glx-diversions (= 0.2.2) Depends: glx-alternative-mesa E: Unable to correct problems, you have held broken packages.
<BWMerlin> Is this a bug I need a report or am I doing something wrong?
<xnox> mpt: an error or a bug in the software is still an error and a bug. no matter where it was installed from. and it's better to fix everything in ppa before it hits MyAPps/ARB/archive.
<mpt> yeah
<xnox> i guess it's screws with the statistics and graphs.
<mpt> For example, we're just hooking up Firefox errors so that we'll count them before sending them on to Mozilla, (almost) purely for statistical rigor
 * xnox so wants to see chromium vs firefox stability. But I guess regardless, the $default browser will always crash more.
<mpt> We'd have to measure program running time to know that
<mpt> but we don't even know Ubuntu running time at the moment (which is why the 12.04 graph has a weekly pulse)
<barry> mitya57: hi
<infinity> BWMerlin: We don't use glx-alternative-nvidia with the Ubuntu shipped drivers.
<mitya57> barry: we wanted to discuss something about the docs
<barry> mitya57: yep, debian wiki page and pybuild
<mitya57> barry: I'm also interested in packaging-guide page, it will be good to merge those two at some point
<barry> mitya57: +1
<mitya57> barry: ideally the main section should tell about pybuild (I would take p1otr's announcement as a base), and then "Other approaches"
<mitya57> section which will describe the old way
<barry> mitya57: in the packaging guide or wiki or both?
<mitya57> I've stolen some text from Debian wiki (both your article and p1otr's) when writing the u-p-g page, the things I added are
<mitya57> sphinx stuff, debian/rules snippet and a list of requirements
<mitya57> both
<mitya57> ... and info about lintian4py
<lantizia> Hi, I've noticed that the kernels shipping with 12.04 and 12.10 are coming compiled with a setting turned on that wasn't present in the config file of the kernel that shipped with 11.10
<lantizia> that setting is CONFIG_SOUND_OSS_CORE_PRECLAIM=y
<lantizia> also CONFIG_SOUND_OSS_CORE=y
<lantizia> now given OSS was completely removed in the kernel back in 11.04 release was it?
<lantizia> Why has settings for it re-emerged in 12.04 onwards?   That setting it seems preserves OSS device numbers in case you have OSS compatibility compiled in to the kernel - which clearly it doesn't any longer
<lantizia> But whilst the setting is there, it prevents people from using OSS proxy/emulation techniques such as osspd (which uses fuse/cuse to fake /dev/dsp and redirects it to pulseaudio)
<infinity> lantizia: You want #ubuntu-kernel
<lantizia> lol - I did ask in #ubuntu which channel would be best, nevermind I'll reask there
<lantizia> but if anyone does know how I can do about looking for a rationale of why that was re-included let me know :D
<slangasek> seb128: hey, do you know if there's a reason we still have the gnome-power-manager package in the desktop seed?  It looks to me like the only things it still contains are a pointless GUI tool and some icons which I think we're not using
<psusi> it has been annoying me for some time now that the gui tool has had features removed to the point of becoming pointless
<seb128> slangasek, for the "pointless GUI tool" :p
<stgraber> slangasek: gnome-power-statistics is called by the power indicator
<psusi> I tried last year to put some back, but upstream didn't seem to want to
<stgraber> slangasek: that's what you see when you click on a batter in the indicator
<psusi> ohh, right... -manager, not -settings
<stgraber> (and FWIW I actually use that "pointless GUI tool" ;))
<slangasek> seb128, stgraber: oh, sure enough - I was only clicking on 'settings' which showed something different :)
<mdeslaur> s/pointless/confusing/
<stgraber> jdstrand: libseccomp has now built on both i386 and amd64, including the testsuite run (thanks to kees who fixed the testsuite failure)
<jdstrand> stgraber: ack
<amigadave> jcastro: hey, i am an upstream developer (of Vino) and would like to see error reports for that project on errors.ubuntu.com
<amigadave> jcastro: poking you as per https://wiki.ubuntu.com/UbuntuBugControl#Application :-)
<ev> amigadave: unfortunately that's not possible yet. We're working with Canonical's legal team to come up with an NDA that will allow us to share that information with trusted third-party developers like yourself.
<ev> Really glad you're interested in getting at it though! :) Hopefully we'll have something together soon.
<ev> slangasek: ^
<amigadave> ev: thanks for the information
<ev> amigadave: sure thing
<jtaylor> is this a gcc bug or me doing something I shouldn't: http://paste.ubuntu.com/1570281/
<jtaylor> I know complex is not c++ but why should it stop working?
<slangasek> ev: ack :)
<barry> xnox: hah! i had the same s-c automerge failures.
<xnox> hm?! =)
<mterry> Is there a bug status that makes status.ubuntu.com treat it as postponed?
<xnox> unlink from blueprint
 * xnox hides =))))
<slangasek> mterry: target bug to release, mark 'wontfix' for that release
<mterry> xnox, :)
<mterry> slangasek, ah hmm.  OK thanks
<kirkland> sladen: ping
<kirkland> sladen: what would it take to get the Apple unicode logo &#xF8FF into the Ubuntu font?
<bluefoxxx> why is the Apple logo a Unicode symbol
<sarnold> bluefoxxx: the ubuntu logo also has a spot in the 'private extensions' space, it's in at least one font shipped by ubuntu..
<bluefoxxx> aha
<slangasek> kirkland: other than Apple tendering an offer for Canonical? ;)
<robru> mterry, oops, I'm late for a lunch date. gotta run! chat about this later?
<robru> mterry, whoops, wrong channel too. so scattered! ;-)
<dobey> barry: ping, i've added the dep3 headers, and pushed the patch to an upstream bug report, for https://code.launchpad.net/~dobey/ubuntu/raring/twisted/fix-pygtkcompat/+merge/144550 can you re-review/sponsor it now? :)
<barry> dobey: i'll do it before cob today (probably in an hour or so)
<dobey> barry: thanks, it fixes a pretty critical crash happening in ubuntuone-client, and is blocking me uploading a new version of that, or rhythmbox-ubuntuone, at least. :)
 * barry nods
<barry> dobey: actually, nm.  i'll do it now, thanks
<dobey> ah ok, thanks much!
<stokachu> barry: if you get a moment could you look over bug 1103644 and let me know what issues you see (if any of course :)
<ubottu> bug 1103644 in python-tz (Ubuntu) "Please merge python-tz 2012c-1 (main) from Debian unstable (main)" [Wishlist,In progress] https://launchpad.net/bugs/1103644
<barry> stokachu: that one will have to wait til later today ;)
<stokachu> barry: thats cool man
<stokachu> anyone have any experience packaging stuff that requires google test? (libgtest-dev) i couldnt find any documentation that describes the proper way to make sure those source files are built when an application depends on it
<stokachu> only stuff i could find was manually running cmake and copying over the static libs to our library path
<jamin> any chance of getting some attention on this report: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/1075478
<ubottu> Ubuntu bug 1075478 in xserver-xorg-input-evdev (Ubuntu) "bluetooth keyboards and mice not working after suspend/resume" [Undecided,Confirmed]
<jamin> there have been several similar reports, the referenced report has an functional work around for the issue
<slangasek> plars: ping
<plars> slangasek: hi
<slangasek> plars: hey there!
<plars> slangasek: heya, good to talk to you again :)
<slangasek> plars: :) have you seen the mail thread with the questions about whether we're profiling memory at the right point in these new jenkins jobs?
<slangasek> plars: would be great if we could have this profiling a logged-in desktop session before Monday
<plars> slangasek: yes, just saw that and I'm updating the job so that it auto logs in
<slangasek> ok cool
<plars> slangasek: from what I'm seeing, 'd-i passwd/auto-login boolean true' ought to work for that right?
<slangasek> plars: I confess that I don't know
<slangasek> plars: it /sounds/ plausible ;)
<plars> d-i preseeding is a bit of a dark art
 * plars is hoping for a 'd-i everything/just-freaking-work boolean true'
<plars> :)
<roadmr_> plars: that's the correct d-i setting, I think at some point it didn't actually result in lightdm auto-logging in, but these days it should
<plars> roadmr_: ok, good to know. It ought to be real obvious if that breaks in this instance since the main output of the test is a process list
<roadmr_> plars: back when that problem was spotted, we worked around it by plastering this in the success_command: http://paste.ubuntu.com/1571093/
<plars> roadmr_: ok, good to know
<roadmr_> plars: there was a bug about this, fix-released by now: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/819624
<ubottu> Ubuntu bug 819624 in casper (Ubuntu Oneiric) "casper doesn't configure autologin for lightdm properly" [High,Fix released]
<dylan-m> Hey, mpt, I think that Technical description pane in Software Updater feels a little clunky and out of place, so I'm thinking of fooling with the thing to maybe get rid of those tabs. Did you have any plans for it already?
<barry> stokachu: still around?
<slangasek> cyphermox: I have now seen the dnsmasq debian/rules as a result of this SRU and am now very sad
#ubuntu-devel 2013-01-26
<cyphermox> slangasek: sad because of what I did or sad because of the initial state of it? it's initial state made me sad, too
<Kano> whats the command used to create the efi binaries you find at http://de.archive.ubuntu.com/ubuntu/dists/raring/main/uefi/grub2-amd64/current/
<Kano> signed is clear, i mean the other ones
<slangasek> cyphermox: the initial state, of course :)
<Kano> slangasek: do you work on secure boot?
<slangasek> Kano: yes.  The unsigned binaries there are generated from the grub2 source package and handled as a custom upload type in .changes
<Kano> in that _amd64.tar.gz
<Kano> btw. did you notice that kubuntu does not support secure boot
<infinity> Kano: We left it up to the flavours to add SB support, rather than doing it across the board.
<Kano> its still weird when you get grub but can not start the kenrel
<sarnold> hrm, how do the flavours get different sb support than the main distro? I'd have thought the same grub* would be used on all..
<Kano> does the default grub installed in secure boot env support booting unsigned kernels?
<infinity> sarnold: It's the same grub, not everyone has twiddles seeds and installers to have signed kernels.
<Kano> the grub most likely and shim too but not the signed kernel
<infinity> s/twiddles/twiddled/
<sarnold> infinity: aha, thanks :)
<Kano> some might want to use other kernels
<Kano> grub2-signed (1.5) quantal; urgency=low
<Kano> does not have this check it seems
<Kano> launchpad has it...
<Kano> whats the tool to create the iso images now?
<Kano> it does not seem to work with the normal live config
<Kano> i see no references to grub
<Kano> for better bsd support: http://people.freebsd.org/~nox/tmp/grub2-paste_180121.patch
<Kano> this patch should be added to grub2
<Kano> was commited to grub2 a bit later
<infinity> If it's committed upstream, raring or later will get it.
<Kano> i just dont like bzr
<infinity> I'm not sure how deep our concern for bsd support is, as far as SRUing such things back.
<Kano> it was just a typo
<Kano> i would prefer when grub would use git
<sarnold> I'm a bit dissapointed the patch didn't #define the magic number
<Kano> checking out bzr takes ages
<infinity> Kano: No one's making you use bzr...
<Kano> and where is git for grub?
<infinity> Kano: If your goal is just to file a bug and provide a patch, you could just grab the source package and work a patch against it.
<Kano> its already commited
<Kano> i just want to search the commit
<Kano> revno: 4556
<Kano> must it be
<infinity> http://bzr.savannah.gnu.org/lh/grub/trunk/grub/revision/4556
<infinity> Looks like.
<Kano> is there a better way to show the commit instead of
<Kano> bzr diff -r4555..4556
<infinity> That's what I use.  There doesn't seem to be a "bzr show".
<infinity> Though I guess it would be trivial to alias "bzr show $n" to "bzr diff -r$((n-1)..$n"
<stgraber> I've been using "bzr log -p" lately, which shows you the commit message, author and the diff
<sarnold> "better" .. maybe bzr log -p ?
<Kano> but with git you see the log entry
<Kano> ah -pr
<Kano> why does bzr always create patches with -p0?
<infinity> Indeed, bzr log -pr is pretty much exactly git show.
<infinity> Slightly less friendly to find, but whatever.
<infinity> Now I know, at least.
<Kano> and it is p0 not p1
<infinity> Kano: And that, yeah.
<Kano> for diff you can use -p1 i see
<Kano> whatever you use, please add it
<stgraber> if you have bzr-git installed, you can also do "bzr diff --format=git" which will give you an output identical to that of "git diff" (so -p1 by default)
<Kano> btw. that was the original bug report: http://people.freebsd.org/~nox/tmp/grub-bugmail.mbox.txt
<Kano> but it seems it never appeared on the mailing list
<Kano> (bzr log -r 4556;echo;bzr diff -r4555..4556 --format=git)
<Kano> maybe something like that
<bdrung> tumbleweed: will you take care of the testing for bug #1068019?
<ubottu> bug 1068019 in distro-info (Ubuntu Oneiric) "distro-info needs to be updated for Raring" [High,Fix committed] https://launchpad.net/bugs/1068019
<gkcn> #ubuntu-x
<rawplayer> hello
<rawplayer> how can i remove the black line after removing the top bar from unity-greeter?
<rawplayer> maybe its an idea to provide an option for the gsettings schema related to unity-greeter to hide the bar or disable it entirly
<Bluefoxicy> sigh this is ridiculous.
<Bluefoxicy> we need a system like dkms for friggin' nginx
<TheLordOfTime> Bluefoxicy, uh... what?
 * TheLordOfTime only responded because 'nginx' is on highlight for him
<Bluefoxicy> TheLordOfTime:  there is no dynamic module loader for nginx
<Bluefoxicy> want to get a module into Debian/Ubuntu?  You have to convince them to include it and build nginx with the module.  Possibly as an additional package.
<Bluefoxicy> TheLordOfTime: if you want to generally include modules with nginx, you need an nginx package that brings in the source code; and you need a package that knows about all the module packages brought in and rebuilds nginx with all that stuff as a trigger when you install or update any of them.
<TheLordOfTime> Bluefoxicy, err, yeah, that's how they designed it...
<TheLordOfTime> Bluefoxicy, and afaik there's no dynamic module loading slated for any release in the near future
 * TheLordOfTime double checks upstream trac
<TheLordOfTime> Bluefoxicy, that, and if such a system is created, it has to be created upstream first.
<TheLordOfTime> which afaik will result in a complete redesign
<Bluefoxicy> yes
<TheLordOfTime> that, and since nginx is universe here...
<Bluefoxicy> which is why we need something like dkms if we want to include outstream modules
<Bluefoxicy> it's ridiculous.
<TheLordOfTime> Bluefoxicy, let me reiterate nginx is universe.
<Bluefoxicy> Yes I saw that part.
<TheLordOfTime> so unless upstream redesigns nginx (which is unlikely to happen) there's not going to be a dynamic nginx module loader
<Bluefoxicy> I'm not entirely sure why.
<Bluefoxicy> ...
<TheLordOfTime> because the way nginx is designed does not currently support such things.
<Bluefoxicy> were you not paying attention?
<TheLordOfTime> and nginx is in universe because its community maintained
<TheLordOfTime>  if you want to generally include modules with nginx, you need an nginx package that brings in the source code; and you need a package that knows about all the module packages brought in and rebuilds nginx with all that stuff as a trigger when you install or update any of them.  <-- aka "do it by hand"
<TheLordOfTime> Bluefoxicy, such a package as well i *think* would need a conflicts: nginx-*
<Bluefoxicy> yes
<Bluefoxicy> that's not a redesign
<TheLordOfTime> or at lleast nginx, nginx-full, nginx-light, nginx-...
<TheLordOfTime> Bluefoxicy, if you make a package, i'll test it
<Bluefoxicy> that's a pile of stupid crap to work around the non-existent dynamic loader
<TheLordOfTime> but until you make such a package... its an upstream-resolve issue.
<Bluefoxicy> nod
<TheLordOfTime> so... *goes back to standard bug triaging*
<Bluefoxicy> Poor design considerations aside, I'm not sure why nginx isn't considered a main package
<Bluefoxicy> (though I may be biased, since I found if I replace Apache on a production Web server with nginx it only needs 2GB of RAM instead of 8GB ... Apache itself uses 5.8GB of RAM for 250 concurrent connections serving static files with SSI)
<TheLordOfTime> trust me, its good where it is in universe.
<TheLordOfTime> Bluefoxicy, the same question could be made about lighttpd
<TheLordOfTime> since its also widely used
<TheLordOfTime> i just gave up the arguing.  its irrelevant - since most NGINX bugs end up being SRU'd by me when upstream has patches/fixes
<TheLordOfTime> :P
<TheLordOfTime> (at least nowadays they're sru'd by me... ;P)
<Bluefoxicy> TheLordOfTime:  you know if there's any truth to the rumor that MySQL is being replaced?
<Bluefoxicy> I have been hearing that it's being seriously discussed to throw it completely out of Debian, Ubuntu, Fedora, etc.
<TheLordOfTime> Bluefoxicy, why don't you ask the release team?
<TheLordOfTime> or debian
<TheLordOfTime> :P
<Bluefoxicy> heh
<Bluefoxicy> well the MySQL release team says there are no replacements for MySQL and that all distros who are using MySQL will continue to use and supply it because there is nothing better.
<Bluefoxicy> :P
<Bluefoxicy> But of course Oracle would say that.
<jtaylor> given that mariadb is a recent fork it is certainly able to replace it
<TheLordOfTime> jtaylor, is the sql syntax still the same?
<jtaylor> of course
<Bluefoxicy> http://www.zdnet.com/opensuse-also-considers-switching-from-mysql-to-mariadb-7000010223/ hmm latest news i can find
<TheLordOfTime> i ask because CREATE DATABASE dbname; works in mysql and mssql, but not oracledb unless you have a lot of other stuff with it
<Bluefoxicy> TheLordOfTime: i in-place replaced mysql with percona so...
<TheLordOfTime> are any of the forks in raring yet?
<Bluefoxicy> which folks?
<Bluefoxicy> Us folks?
<Bluefoxicy> oh, forks.  Can't read.
<TheLordOfTime> :P
<Bluefoxicy> TheLordOfTime:  apparently Debian doesn't have any of them.  Which is strange to my senses
<Bluefoxicy> I mean it's like, you know.
<TheLordOfTime> might be stuck in the freeze
<TheLordOfTime> or in the "We can't process because frozen" queue
<Bluefoxicy> they supply repositories which I'm pretty sure have a deb-src
<Bluefoxicy> yeah debian is weird about freezing sid
<TheLordOfTime> Bluefoxicy, they don't have to
<TheLordOfTime> :P
 * TheLordOfTime points at his local private debian repositories which only have the binaries
<Bluefoxicy> Well I mean, you can just pull the debs from somewhere else and build them yourself, and import them
<TheLordOfTime> note two things: (1) private repositories, and (2) they're private and binary-only because i'm paranoid about my source code.
<Bluefoxicy> it's not like there's licensing problems
<TheLordOfTime> true
<Bluefoxicy> define 'paranoid about your source code'
<Bluefoxicy> you're a crappy programmer?
<TheLordOfTime> no, just paranoid.
<Bluefoxicy> that seems strange in this crowd
<TheLordOfTime> :P
<Bluefoxicy> i'm not sure your source code can be used against you effectively
<Bluefoxicy> man i still don't understand what is going on with upgrading from 2.7 to 3.0 puppet on ubuntu.
<Bluefoxicy> every time I move up, apt breaks everything.
#ubuntu-devel 2013-01-27
<Bluefoxicy> well
<livefree424_> Hello all I am trying to get into Ubuntu development and having some issues I'm following the Ubuntu tutorial on setting up a Currency Converter app and when I run it all I get is a Hello World here is my code http://pastebin.com/46U8hsAq if anyone can look over it and let me know what I did wrong I would be grateful thanks
<livefree424_> anybody ^^^
<livefree424_> is anyone even here
<TheLordOfTime> have patience
<TheLordOfTime> it can take a while to get responses sometimes
 * TheLordOfTime goes back to his bug triaging home at -bugs
<livefree424_> ya i know just didnt see any other chat goin on so i was wondering
<micahg> livefree424_: maybe #ubuntu-app-devel is more appropriate for this?
<nigelb> Laney: Happy Birthday!
<Laney> heh
<Laney> nigelb: thanks
<nigelb> Laney: :D Are you in the UK?
<Laney> yep
<sladen> kirkland: U+F8FF is in the Private use area.  I guess we could map it to the Ubuntu logo which is in other places
<sladen> kirkland: in the (non-standardised) encoding for Klingon it's also the Empire Symbol
<hyperair> ooh, a utf8 ubuntu symbol.
<zykes-> how can I debug these ? "Jan 27 13:19:56 svc02 kernel: [175799.587970] init: ceilometer-api main process (31797) terminated with status 2" ?
<Phonequer> Hello. Should I use bzr dh-make to create a package? If so then why it puts "root@unknown" into various files, while I've had set bzr whoami correctly?
<Phonequer> If I have a git repo, and a autotools build system. Is it OK to use bzr dh-make. Or should I have bzr repo from the beginning?
#ubuntu-devel 2014-01-20
<Unit193> qengho: Howdy!  Is there a chance you can rename chromium-browser (at least the binary package) to chromium to follow the rename in Debian?  It'd make some deps sync better and packages like pepperflashplugin-nonfree syncable (reason for naming it chromium-browser is no longer current, the game is now chromium-bsu)
<TheMuso> c
<pitti> Good morning
<pitti> Noskcaj: gthread.patch> it looked like it was an Ubuntu delta
<pitti> Noskcaj: will do, thanks
<Noskcaj> Logan__, You around?
<Noskcaj> Any chance you could sponsor xubuntu's current biggest bugfix? https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-power-manager/systemd/+merge/202226
<didrocks> xnox: hey, your nux/unity rebuild against new glew is making my system crashing here
<didrocks> xnox: I have an unity stacktrace, (and it's an upload outside of our test system, can you please really stop doing that, not the first timeâ¦)
<dholbach> good morning
<Noskcaj> hey dholbach. ANy chance you could take a look at https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-power-manager/systemd/+merge/202226 ? It's xubuntu's biggest bug currently
<dholbach> hi Noskcaj
<dholbach> Noskcaj, do you know if the libstatgrab situation is resolved now?
<Noskcaj> i'll check now
<dholbach> Noskcaj, Conflict adding file src/gsd-media-keys-window.c.  Moved existing file to src/gsd-media-keys-window.c.moved.
<dholbach> Conflict adding file src/gsd-media-keys-window.h.  Moved existing file to src/gsd-media-keys-window.h.moved.
<dholbach> hey mvo
<mvo> hey dholbach, good morning
<Noskcaj> strange. Is there a different way you could sponsor it?
<Unit193> mvo: Howdy.
<Noskcaj> No progress on libstatgrab, still very broken and i don't know how to fix
<dholbach> Noskcaj, can you bring it up on the mailing list then and ask for help there?
<Noskcaj> dholbach, Which list? There's already a bug in debian for it.
<Noskcaj> Also, is there anything you can do to make my MOTU application happen faster? No one replies
<mvo> hey Unit193
<dholbach> Noskcaj, seems like nobody responded to https://lists.ubuntu.com/archives/devel-permissions/2014-January/000562.html yet - you could try pinging anyone of these: https://launchpad.net/~developer-membership-board/+members
<Unit193> I ended up commenting before you responded because I already saw several marked as dupes of that bug, then noticed I couldn't re-open.
<Noskcaj> bdrung, micahg, ScottK: Any progress on my MOTU application?
<dholbach> Sweetshark, jamespage: happy birthday! :)
<pitti> Noskcaj: hm, I don't see g-s-t on http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html ?
<Noskcaj> pitti, I hadn't changed the status back because i wanted your opinion on if i needed to do those other changes
<Noskcaj> It's at https://code.launchpad.net/~noskcaj/ubuntu/trusty/gnome-system-tools/merge still
<pitti> Noskcaj: status back? oh, on the (wrong) UDD branch
 * pitti looks at that again
<Noskcaj> status to "needs review"
<pitti> no, it needs to be done against https://code.launchpad.net/~ubuntu-desktop/gnome-system-tools/ubuntu, as in Vcs-Bzr:; desktop packages don't use UDD
<Noskcaj> ok
<pitti> Noskcaj: indeed, gthread is from Debian; sorry for the noise
<pitti> Noskcaj: you need to add Breaks:/Replaces: for network/time-admin for (<< 3.0.0-3ubuntu1), and add transitional packages, for upgrades
<pitti> that part can be dropped after trusty's release
<pitti> but is necessary to move people who only have those installed to g-s-t
<Noskcaj> ok
<pitti> and the B:/R: for telling apt to unpack them  in the right order, to avoid file conflicts
<pitti> as g-s-t now ships files that previously time/net-admin shipped
<pitti> Noskcaj: debian/rules additionally does --disable-services; not sure where that came  from
<pitti> ah, "don't build services admin"
<pitti> yes, makes no sense with upstart
<Noskcaj> makes sense, if my internet will let me, i'll fix it now
<Noskcaj> And if you've got some spare time, i've got two SRUs xubuntu really needs waiting
 * pitti isn't in ~ubuntu-sru
<pitti> I can sponsor them, of course
<Noskcaj> makes sense, if my internet will let me, i'll fix it now
<Noskcaj>  And if you've got some spare time, i've got two SRUs xubuntu really needs waiting
<Noskcaj> stupid internet crash
 * pitti isn't in ~ubuntu-sru
<pitti> I can sponsor them, of course
<Noskcaj> https://code.launchpad.net/~noskcaj/update-notifier/tray-notification/+merge/202210 and https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-power-manager/systemd/+merge/202226
<Noskcaj> sponsor is what i need currently, we can't SRU till it's in trusty
<Noskcaj> And maybe https://code.launchpad.net/~noskcaj/ubuntu/trusty/xfce4-session/light-locker/+merge/196436
<pitti> Noskcaj: seems dholbach just did the power-manager one, without closing the MP
<zyga> good morning
 * pitti sets to "merged" (â dholback, FYI)
<Noskcaj> ty dholbach, helps a lot
<pitti> Noskcaj: wrt. update-notifier, I thought popping up u-m was a design decision
<pitti> (instead of the tray notification)
<Noskcaj> pitti, Might be. I'm not sure, just trying to remove bug 1246364
<ubottu> bug 1246364 in update-notifier (Ubuntu) "update-notifier does not show a tray icon in xubuntu 13.10" [Undecided,Confirmed] https://launchpad.net/bugs/1246364
<Noskcaj> But if so, i'll set it to won't fix or invalid
<pitti> well, the "appears minimized" is still a bug
<pitti> it should just open; in the background if you are busy typing
<Noskcaj> ok, i'll add that info to the bug and remove the MP
<jamespage> thanks dholbach
<didrocks> ev: hey, any idea why there is no retrace on this trusty crash report? https://errors.ubuntu.com/oops/a8ea9f18-8068-11e3-a0f6-2c768aafd08c
<ev> didrocks: we don't have a mapping backwards from crashes to problems (stupidly on my part, but it's not terribly difficult to add for future reports), so it's hard to answer your question.
<didrocks> ev: ah, so there is no (easy) way for me to get from my report to a retraced version?
<ev> lp:daisy if anyone wants to add that. Just stick the ProblemIdentifier field in OOPS during bucketing
<ev> didrocks: correct :-/
<didrocks> ah ok
<ev> adding it is easy, back populating it not terribly hard, but time consuming (probably about a few weeks of compute time).
<ev> actually, not even
<ev> because it just has to iterate the Bucket CF and populate the bucket identifier into each OOPS report for each oopid in bucket
<ev> sorry, I realise none of this helps you right now
<didrocks> ev: no worry, was more coming to a "is it normal thatâ¦" ? ;)
<didrocks> so I have my answer now
<ev> :)
<didrocks> I don't miss any obvious link :p
<pitti> seb128: ah, you uploaded e-d-s; I'll upload evolution then?
<pitti> (well, and of course build/test it locally first)
<seb128> pitti, oh, I forgot about evo, sorry about that ... if you want to do it that would be nice, thanks!
<Sweetshark> dholbach: oh, thanks!
<Sweetshark> jamespage: Happy birthday then, I guess ;)
<jamespage> Sweetshark, happy birthday!
<dholbach> :)
<dholbach> can somebody reply to https://twitter.com/derEremit/status/424250853747216384 please?
<ogra_> dholbach, i guess thats a cjwatson/xnox question
<ogra_> Sweetshark, hey old man ... happy bithday !
<pitti> seb128: building/working fine here, uploading
<seb128> pitti, danke
<Sweetshark> ogra_: thx. now get off my lawn. /me shakes angryoldmanfist
 * ogra_ waves with his cane to Sweetshark 
<ogra_> :)
<didrocks> happy birthday Sweetshark!
<xnox> dholbach: ogra_: that boot-repair is not suitable for default inclusion. Whilst it does a few things right, it does a few things wrong as well and has caused mass-bug reports in the past.
<xnox> dholbach: ogra_: ideally it needs integration into ubiquity.
<ogra_> xnox, yeah, thats kind of the answer i expected ... though i disagree about ubiquity
<ogra_> (the purpose of the app seems to be to not need live media to repair the bootloader setup
<ogra_> )
<dholbach> xnox, ok
<xnox> ogra_: correct, the purpose of ubiquity designs from mpt, had the 3 options: Try Ubuntu, Install Ubuntu, Fix Ubuntu. The later does most common repairs - e.g. out of disk-space, fsck, reinstall boot-loader, etc.
<ogra_> xnox, right, but that still forces you to use live media ...
<xnox> ogra_: that repair tool modifies configuration files automatically which ends up behaving very bad on upgrade.
<xnox> ogra_: not necesseraly. One doesn't need live media to launch ubiquity - see oem-config.
<xnox> ogra_: so a stand-alone repair launcher for repair mode can also be easily added.
<ogra_> if people edit the grub cmdline by hand to get back into their system or ise another bootloader and want the overwritten grub back they could use an in-system tool instead
<ogra_> s/ise/use/
<xnox> ogra_: or e.g. see lp:dell-recovery which does only repair/factory-reinstall
<xnox> ogra_: people didn't edit the grub cmdline by hand, that boot-repair tool however did modify grub.cfg without asking causing user distress on grub upgrades thereafter.
<xnox> (and modified grub.cfg pointlessly / as in when not needed)
<xnox> it's a very heavy hammer.
<ogra_> yeah, i dont say the tool is good :)
<xnox> =)
<ogra_> but i understand its purpose
<ogra_> and i think we dont want to install ubiquity by default, so a standalone tool would be better if we would think such a thing is needed
<pitti> seb128: nice, the libgweather/evolution/e-d-s/gnome-clocks/gnome-panel combo just migrated \o/
<seb128> pitti, great!
 * Laney lookss at libwebp as he's planning a webkitgtk upload anwyay
<mpt> xnox, ogra_: The âFix Ubuntuâ button in Ubiquity could be merely a launcher for that standalone tool
<ogra_> mpt, yeah, something like that
<ogra_> i really dont know how important that use case actually is ... do we actually have so many people with broken MBR that it even justifies to have such a tool
<ogra_> but yeah, it should be a standalone tool that can be also used from a repair CD
<mpt> compare https://wiki.ubuntu.com/StartupSettings
<ogra_> oh, cool
<ogra_> dholbach, ^^ that seems like a good page to point to in an answer
<xnox> ogra_: note that none of that hand drawing is implemented =)
<ogra_> xnox, heh, i wouldnt have expected so
<ogra_> :)
<pitti> cjwatson: did you ever happen to see dpkg erroring with "unable to move aside [...]: Invalid cross-device link" when replacing a directory with a file?
<pitti> cjwatson: I'm investigating bug 1220681, one of the first results of our new automatic dist-upgrade testing; and that bug was sent by an actual user, so it doesn't just seem to be an artifact from our test rig
<ubottu> bug 1220681 in espeak (Ubuntu) "package espeak-data 1.46.02-2ubuntu1 failed to install/upgrade: unable to move aside `./usr/lib/i386-linux-gnu/espeak-data/voices/en' to install new version: Invalid cross-device link" [Undecided,Confirmed] https://launchpad.net/bugs/1220681
<cjwatson> no
<doko> seb128, according to the version number, pyruntest seems to be a package which desktop or phone should be subscribed tob. see lp #1270812
<ubottu> Launchpad bug 1270812 in pyruntest (Ubuntu Trusty) "pyruntest fails to build from source in trusty" [High,Confirmed] https://launchpad.net/bugs/1270812
<doko> Mirv, ^^^
<doko> xnox, https://launchpad.net/ubuntu/+archive/test-rebuild-20140108/+build/5430771 (you are Debian "upstream" ;p )
<seb128> doko, seems like part of the autopilot stack, e.g rather a QA team thing
<doko> jibel, pitti: ^^^
<xnox> doko: thanks.
<Mirv> doko: ok, I'll assign that to thomi who is behind the code
<doko> thanks
<xnox> Sweetshark: Laney: Riddell: do you remember the bug in Libreoffice or was it KDE (?! or maybe somewhere else) where with Ubuntu default fonts, the bold (fat) version was loaded instead of the correct "normal" one?
<Laney> it was libreoffice
<Laney> I think there was a bug which I attached screenshots to?
<Laney> was quite a while ago :-)
<xnox> looks like there is another bug like that with openjdk, https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/937200 and a /possibly/ plausible patch to fix it https://launchpadlibrarian.net/162036139/openjdk-7_7u25-2.3.12-4ubuntu3_7u25-2.3.12-4ubuntu3ppa1.diff.gz
<ubottu> Ubuntu bug 937200 in openjdk-7 (Ubuntu) "Fat fonts in Swing applications" [Low,Triaged]
<Laney> check the changelog
<xnox> Laney: and i'd rather have some font-guru insight if that's the right way to fix it or not.
<Laney> doko was pinging about that last week & talked to s_laden a bit
<Laney> I didn't follow the outcome
<xnox> Laney: well doko is pinging me about it now, as I independantly filed an issue long time ago to "make default latin font be Ubuntu" in fontconfig package, which is "won't fix" due to Ubuntu font have different height from other fonts.
<Laney> right
<xnox> (or some such other dimention / proper typography term)
<Sweetshark> xnox: I remember argueing viciously on that one that I dont like the idea of vendorpatching that as "LO renders it different on Ubuntu as on Windows" is worse from the users perspective that "LO renders it wrong consistently" ...
<Sweetshark> (users mostly wouldnt even notice the second one)
<xnox> Sweetshark: i see, even if "Ubuntu Font is installed on Windows" ? I thought the core issue was that "ubuntu font provides too many weights like no other: normal, normal+bold, light, light+bold" and since there was no other widely used fonts that did that, the font-code was failing to select "normal" and instead picked "normal+bold".
<doko> Sweetshark, but how do you solve this with DejaVu?
<Laney> doko: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-pillow/35/ARCH=amd64,label=adt/console is that failing test sensible? I see http://sources.debian.net/src/pillow/2.2.1-3/Tests/test_file_webp.py#L54 ...
<Sweetshark> xnox, doko: I would need to dig into that code again -- there was quite some rework on font stuff by Christina upstream recently.
<xnox> Sweetshark: a pointer into the rigth direction would be enough, i think. For me to validate if the "font-selection-logic" in openjdk is affected in a similar way, and wether the proposed fix is the "sensible way" to pick between "more than 2 weights".
<Laney> We fixed that issue by altering the font itself
<xnox> Laney: you mean - as in default font in libreoffice? or by fixing ubuntu-font?
<Laney> the latter
<xnox> hm....
<Laney> Doing $something to the font's metadata fixed it
<Laney> so this java issue might be something different
<xnox> Laney: unless it doesn't read the $something portions of the font's metadata.
<xnox> =))))
<Sweetshark> xnox: we are not using Ubuntu-fonts in LibreOffice defaults. As Ubuntu fonts are not shipped on Windows/OS X, every document generated on Ubuntu would use a font fallback (with a different metric) and thus possibly look horrible. Pitchforks and torches stuff.
<xnox> Sweetshark: right, sounds reasonable. I wonder what to do with openjdk then - e.g. swig apps looking horrible with ubuntu-font due to selecting bold / possibly miss-aligned, making openjdk pick the right weight / possibly miss-aligned, switch to same font as libreoffice.
<xnox> Sweetshark: which one do you use? DejaVu?
<Sweetshark> xnox: We might consider using Ubuntu fonts in defaults, as LibreOffice now is able to embed fonts in the ODF. Such stuff would then look fine on recent LibreOffice versions  everywhere (but not e.g. on OOo). However, fontembedding is opt-in and not the default as embedding fonts might need a license. For the Ubuntu font, that might not be an issue, but other fonts might get you into legal fun.
<xnox> Sweetshark: i thought that e.g. PDF-A standard mandates font embedding (those that are not part of standard well-defined set) and that most / all fonts are ok to be embedded, as "you shall not extract fonts from the document"
<Sweetshark> xnox: as default fonts? LibreOffice 4.1 has Liberation family as defaults. But someone made new defaults for 4.2. lemme check.
<Sweetshark> xnox: All I know that nobody bothered with releasing with that upstream. Feel free to let the Canonical legal team have an expensive meditation about it.
<Sweetshark> seems to still be liberation (which is natural, as IIRC liberation font are metric compatible with corefonts). (IIRC we also grew ourselves some free fonts from google, but the details escape me right now).
<Sweetshark> (caladea and carlito)
<xnox> Sweetshark: i wonder why ubuntu-restricted-common (or whatever it's called ) metapackage still recommends  / installs MS corefonts instead of installing just liberation fonts.
<Sweetshark> (those two fonts above are metric compatible to Cambria and Calibri)
<pitti> hm, since today, apt's "reading package lists.." takes aaaages (every percent takes 2 s, so about two minutes in total); does anyone else get this as well?
<pitti> I see the same in a saucy container, so perhaps some weird regression in 3.13.0-4?
<seb128> pitti, no such issue here but I didn't reboot with -4 yet
<pitti> I'll re-check with both after meeting
<pitti> meh, after next apt-get update every percent now takes 10 s
<pitti> hmm, fast again after a reboot
<seb128> pitti, were you under io load from some other process maybe?
<pitti> seb128: no, there was nothing else running
<seb128> I had very slow everything while doing an install in a VM earlier, IO load handling still sucks under linux
<doko> pitti, jibel: how do I get the autopkg tests of a package run when eglibc is uploaded?
<pitti> doko: in theory they should almost all run then, as almost all packages depend on libc6
<pitti> doko: in practice this seems to "forget" a few rdeps; we can manually trigger runs of particular packages if you are interested in a specific one
<doko> and is there a chance to run autopkg tests on armhf?
<pitti> not in CI at the moment, as there is no viable virtualization :/
<doko> pitti, well, I would have to write these tests first ;p
<pitti> they can of course be run manually on a G4 or so, but each test basically requires a reinstall
<pitti> "nexus 4" I meant
<cjwatson> well, they might be runnable in the emulator somehow
<cjwatson> Steve has asked me to look into that
<pitti> in qemu-system-* might be viable, yes
<pitti> qemu-user in LXC doesn't quite cut it
<cjwatson> well, specifically, Steve asked me to look into hooking autopilot tests up to autopkgtest in the Android emulator
<cjwatson> (which isn't quite the same thing as the above, though it's sort of related)
<cjwatson> I'm juggling this with 12.04.4 and GRUB 2.02 though ...
<doko> the tests in question are: run java -version for openjdk builds, and run the libffi tests with an install environment
<cjwatson> I think for any armhf testing we'll have to look into limiting it somehow
<pitti> cjwatson: I think a first good limitation would be to only run tests without "needs-root"
<cjwatson> otherwise I'd be worried that we'll slow the whole process right down
<pitti> those are usually the simpler kinds which don't make strong assumptions about the machine
<pitti> (i. e. not things like upstart or udisks)
<mitya57> zyga: FYI: https://code.launchpad.net/~mitya57/ubuntu/trusty/python-coverage/add-preinst-script/+merge/202323
<mitya57> It turned out that indeed that was Ubuntu-specific issue
<zyga> mitya57: thanks!
<Laney> doko: did you see my message about pillow?
<mitya57> Laney: I think that pillow comment is related to "#assert_image_equal(image, target)" (which is commented out), not to the next test (which is the failing one)
<Laney> yes
<Laney> I was more linking to the comment
<Laney> "shouldn't this logic apply to that other test too?"
<mitya57> That doesn't mean we can't disable both, though :)
<mitya57> similar != equal, so it doesn't necessarily apply
<mitya57> maybe bumping 20 to something higher will work, if not, then it's a real bug
<Laney> umm
<Laney> It's assert_image_equal not assert_image_similar
<Laney> http://sources.debian.net/src/pillow/2.2.1-3/Tests/test_file_webp.py#L31 that's the line
<doko> pitti, what's the status of the postgres 9.1 deps, http://people.canonical.com/~ubuntu-archive/nbs.html
<pitti> oh, I thought I caught them all
<cjwatson> tseliot: so, what's the status of the nvidia stuff in precise-proposed?  it's currently v-failed, but your last comment in bug 1268027 suggests that maybe it should be OK?
<ubottu> bug 1268027 in nvidia-settings (Ubuntu) "nvidia-settings crashes on exit" [Medium,Incomplete] https://launchpad.net/bugs/1268027
<pitti> doko: thanks for pointing out, will fix ASAP
<tseliot> cjwatson: yes, I don't think it's a regression. It seems to me like a bug that can be reproduced only on very specific configurations
<tseliot> cjwatson: also the nvidia-prime in the queue fixes some issues in the same SRU
<pitti> cking: FYI, https://launchpad.net/ubuntu/+source/util-linux/2.20.1-5.1ubuntu14
<cking> pitti, nice, thanks for that
<pitti> cking: nasty h4ck :/
<cking> pitti, well, if it stops eating data, it's worth the ugh factor
<pitti> cking: yes, absolutely; thanks for pointing out that bug
<cking> np
<cking> thanks for fixing it :-)
<doko> xnox, will you care about the libav rebuilds?
<doko> http://people.canonical.com/~ubuntu-archive/nbs.html
<xnox> doko: all is done, mass removal of ffmpeg is required, i believe it was already removed from testing in debian. See the RM bug that ubuntu-archive is subscribed to.
<xnox> https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/1253071
<ubottu> Ubuntu bug 1253071 in mplayer (Ubuntu) "block migration & demote to proposed & decruft NBS libav/ffmpeg (removed from testing in Debian)" [Undecided,Triaged]
<xnox> there are a few packages affected.
<xnox> doko: i believe the only things that needs doing are: remove binary packages, demote source packages to -proposed.
<doko> xnox, why keep the source?
<cjwatson> tseliot: Right.  Looking at that queued upload
<xnox> doko: some of them may (e.g. libavg, libnfo, libvalhalla, etc) might get ported to libav9 in debian, and then it will just sync.
<tarpman> xnox: hi, about bug 937200: the bug is (imo) in openjdk, anything with fontconfig or fontconfig.properties is just a workaround. still waiting for feedback from upstream about my patch; not happy to propose for ubuntu before getting a review from someone who knows that code
<ubottu> bug 937200 in openjdk-7 (Ubuntu) "Fat fonts in Swing applications" [Low,Triaged] https://launchpad.net/bugs/937200
<xnox> doko: otherwise, it will need to manually noticed that autosync is not considering something due to "trying sync from debian, but removed from ubuntu"
<cjwatson> tseliot: I'm pretty sure the HOST_ARCH_OTHER stuff could've been done more clearly with make conditionals, but not a blocker
<xnox> tarpman: i see. Do you have link to upstream submitted patch?
<tarpman> xnox: mmf. you know what, I actually just sent information to their list, not the patch itself. I will follow up with that, thanks for reminding
<tseliot> cjwatson: right
<tarpman> xnox: is there anyone at ubuntu or canonical who has already gone through their copyright signing thing? I am not really interested in paperwork :)
<tarpman> and separately, http://cdimage.ubuntu.com/daily-live/ is looking a little bit out of date...?
<cjwatson> tarpman: the builds failed until this morning - fixed earlier today, should work tomorrow
<tarpman> thanks :)
<xnox> tarpman: if it's your patch, and you are not canonical employee, it's hard to steal and impersonate your copyright =) but I thought your patch is trivial and doesn't need copyright... maybe ask doko, as I'd think he might have openjdk commits.
<tarpman> xnox: ok. I am going to email the list again (with the patch this time), and also cc the person the upstream bug is assigned to. will report back on the LP bug.
<xnox> tarpman: cool, thanks.
<doko> pitti, jibel, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html show the owncloud-client autopkg tests failing, however the status is green ...
<pitti> doko: where is it green? https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-owncloud-client/ all failed
<doko> pitti, the trend is all green: https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-owncloud-client/
<pitti> doko: btw, I uploaded everything for the psql 9.1 NBSes
<doko> looking at this rules file ...
<doko> override_dh_auto_test:
<doko>         mkdir obj-$(DEB_HOST_GNU_TYPE)/config
<pitti> doko: ah yeah; no idea about tha ttrend thing
<doko> so why is DEB_HOST_GNU_TYPE not set during the adt run?
<doko> pitti, ^^^
<pitti> it's a bug in debian/rules
<pitti> hm, this is a dÃ©ja-vu, I remember fixing a missing DEB_HOST_GNU_TYPE last Thursday or so
<pitti> ah right, I filed that as debian bug 735535
<ubottu> Debian bug 735535 in owncloud-client "autopkgtest fails" [Normal,Open] http://bugs.debian.org/735535
<pitti> doko: I must have forgotten to upload it or so; doing
<pitti> doko: ah no, even after fixing that and another bug, the tests still fail
<pitti> doko: and at that point I didn't know any more what the DD's intention was, so I asked on that bug
<pitti> doko: FYI, I usertag those: http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=autopkgtest;users=autopkgtest-devel@lists.alioth.debian.org (in case you wonder about another autopkgtest failure)
<doko> pitti: I usually use severity serious for broken autopkg tests by design. it's nice if people add them, but things like this should never happen in the first place
<doko> pitti, please overwrite this test. blocks a package removal
 * apw wonders if there is any way to suppress: dpkg-source: error: can't build with source format '3.0 (native)': native package version may not have a revision
<apw> it is preventing me fro building my signed packages
<xnox> apw: use '3.0 (quilt)' with "echo create-empty-orig  > debian/format/options"
<xnox> apw: which is "3.0 (native)" with any version number I like.
<apw> xnox, nice thanks
<pitti> doko: release team can do that; OOI, which package do you want removed? (how does a failed test prevent that?)
<doko> pitti, libocsync-plugin-owncloud, waits for owncloud-client to go to trusty
<pitti> infinity, Laney, slangasek, stgraber: can one of you please ignore the autopkgtest failure of owncloud-client? (test is broken in multiple ways, I filed a Debian bug)
<pitti> infinity: if you are online, TB meeting is starting now in #ubuntu-meeting
<pitti> but with the US national holiday there probably won't be too many people anyway
<Noskcaj> pitti, If you're still around, i've got the g-s-t merge in the right place now
<xnox> doko: pyflakes uploaded with fixes/support for 3.4
<xnox> (into debian, should autosync into ubuntu)
#ubuntu-devel 2014-01-21
<slangasek> pitti: did you still need an owncloud-client ignore?
<slangasek> pitti: seems so - hint added now
<lolcat> Has it ever been considered to make aptitude use bitorrent?
<tarpman> lolcat: https://wiki.debian.org/DebTorrent
<lolcat> cool
<lolcat> tarpman: So it isn't feasible?
<lolcat> I would love for it to use bittorrent on the local network in addittion to a web seed. SO if bandwidth is thight it gets it from local computers
<RAOF> lolcat: In the meantime, running an apt-proxy is pretty simple.
<RAOF> lolcat: See squid-deb-proxy-client + squid-deb-proxy/apt-cacher-ng etc.
<lolcat> Hard to install on freeBSD
<RAOF> Why would you install it on freeBSD?
<RAOF> (And I'd be amazed if squid was hard to install on FreeBSD!)
<lolcat> Because I have three computers with ubuntu
<lolcat> They are not on at the same time always
<lolcat> How would I set it up so they know which has the package?
<lifeless> lolcat: pkg_add squid; done - no ?
<RAOF> There's apt-zeroconf for that, if you don't have a machine that'd be mostly-on.
<lifeless> lolcat: squid-deb-proxy uses zeroconf
<RAOF> Welcome, squid-highlighting friends!
<RAOF> :)
<lolcat> ah
<lolcat> I guess Ill just upgrade to 100mbps and forget about it
<lifeless> *blink*
<RAOF> Oh, apt-zeroconf is dead-dead. That's a bit of a shame; the other caching solutions don't quite cover the distributed-cache usecase.
<RAOF> lifeless: There's no trivial configuration to turns squid into a distributed cache solution, right? (ie: multiple squid caches on the network, dispatch to appropriate cache if cache has file, otherwise download locally and cache)
<RAOF> (I've probably asked that before)
<lifeless> RAOF: cache_peer and list all the peers
<lifeless> RAOF: IIRC digests (bloom filter API) are on by default, so you'll get that behaviour
<lifeless> should be easy enough to wire a config generator into zeroconf and do that
<RAOF> Hm, yeah. Interesting.
<lifeless> of course, trust is an issue, as you're basically saying 'hey, use me for transit!'
<RAOF> Well, there's apt's signing mechanism on top.
<lifeless> for the special case of safe-over-http content, sure
<RAOF> So you shouldn't be able to silently break stuff.
<lifeless> just saying :)
<lifeless> you could silently withhold security updates
<RAOF> Don't we https:// them yet?
<RAOF> No, we don't. Sadface (:
<lifeless> and also they don't exist for the open release
<RAOF> True.
<RAOF> We could always turn off proxying for Packages.gz
<RAOF> Actually, I suspect the default config works for that; setting all 0s for refresh_pattern on Packages should do that?
<lifeless> no
<lifeless> that affects heuristics
<lifeless> explicit timing data from servers takes precedence
<lifeless> unless you actually explicitly override which IIRC requires a compile time option to enable RFC violations
<lifeless> I'm not really worried about someone withholding updates
<RAOF> There's presumably a squid key to disable caching and always got to the server?
<lifeless> it was just an observation
<lifeless> yes
<RAOF> Well, if I were to, say, update the default squid-deb-proxy configuration to handle this I'd want to make sure it's approximately as secure :)
<lifeless> its not secure now
<lifeless> in this sense
<lifeless> because I can plug an unprivileged machine in and advertise
<lifeless> so - no new hole
<lifeless> the difference is that you want to share the cache
<pitti> Good morning
<pitti> slangasek: yes, doko_ asked for it; thanks
<Noskcaj> pitti, The g-s-t merge should be ready for you to look at
<Noskcaj> (finally)
<pitti> Noskcaj: yes, thanks muchly! I have it in a tab to review this morning
<Noskcaj> :) Then i can nag you about the other 50 packages i have that need sponsoring
<darkxst> hey pitti
<pitti> hey darkxst, how are you?
<darkxst> yeh good, finally it has cooled down here!
<Unit193> mvo: Howdy.  Did you happen to see my comment before you left last night?
<darkxst> pitti, would you be able to add an endorsment to my PPU/MOTU application? (Planning on attending the next meeting 27th)
<pitti> darkxst: sure, will do
<darkxst> thanks
<pitti> Noskcaj: hm, did you update debian/control manually? curious how the "XSBC-Original-Maintainer: Maintainer:  [...]" oddity came in here (will fix that during merge)
<Noskcaj> Probably. I think bzr had a conflict there that i must have done wrong. oops
<pitti> Noskcaj: FYI, debclean will update debian/control from control.in
<Noskcaj> This is why i hate packaging one thing over many days
<Noskcaj> ok
<pitti> (no worries)
<mvo> Unit193: i didn't, sorry - could you please paste it to me again?
<Unit193> I ended up commenting before you responded.  I saw several marked as dupes of that bug so just figured there was proper, then noticed I couldn't re-open.  Is there a chance you can do that?
<mvo> Unit193: I think I can, could you please give me the bugnumber again?
<Unit193> mvo: https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1060543
<ubottu> Ubuntu bug 1060543 in software-properties (Ubuntu) "Additional Drivers is not discoverable in Quantal" [Critical,Fix released]
<Noskcaj> Could someone help me with refreshing a patch to argyll?
<Noskcaj> ty for the syncs pitti
<pitti> Noskcaj: yw
<Noskcaj> I need help re-adding a patch to https://code.launchpad.net/~noskcaj/ubuntu/trusty/argyll/merge
<Noskcaj> xnox, I think you made the  original
<Noskcaj> drop-usb-db.patch
<Unit193> mvo: Danke!
<mvo> Unit193: your welcome .)
<mvo> Unit193: I will try to look at your diff today, if nothing has happend by lunchtime please gently nudge me again (have to do some other stuff first)
<Unit193> mvo: Heh, it's 01:55, I'm watching Castle then going to bed. :P  But sure, next time.
<mvo> Unit193: wehh, these timezones .) yeah, lets talk tomorrow, have a good night
<Unit193> Indeed.
<dholbach> good morning
<xnox> Noskcaj: be careful, in debian I think they dropped the db usage completely, which I don't think is correct.
<Noskcaj> xnox, ok. Is there any chance you could try and finish the merge, since it's beyond my understanding
<xnox> yeah, i will.
<Noskcaj> thanks
<apw> pitti, autopkgtests ... the one we did for linux ... this is a compile test basically which is great when gcc changes, but makes no sense to fire when the package in question is linux itself as we just did that.  is this something we can codify in the test?
<pitti> apw: not really in linux itself, as that autopkgtest has no idea when/why it gets called
<apw> pitti, so i don't get offered the name of the trigger'er or anything
<pitti> apw: we could perhaps change eglibc's autopkgtest to try and build linux, not itself
<pitti> apw: no, britney/jenkins are way higher up in the stack than autopkgtest, I'm afraid
<apw> pitti, i thought that way lay madness or something, as every package had to list all possible packages
<pitti> apw: i. e. instead of trying to build itself, packages could try and build the others in the "toolchain" set except themselves
<pitti> right
<pitti> and it doesn't parallelize that way
<pitti> which is why we did it this way around and live with the overhead
<brendand> ponder - launchpadlib in python3
<apw> so it sounds like something fundamental to the /control level to say "but not for me"
<brendand> rebuilt on requests
<pitti> apw: we have enough build slaves, after all; the unnerving thing are the failures
 * apw has yet to see a kernel make it through testing i think
<pitti> apw: we recently found a too small copy timeout for linux (on one node, copying the sources takes more than 5 mins, yay slow disks); so it ought to get better now
<pitti> and fail less often
<pitti> apw: how do you mean?
<pitti> apw: they succeed often, but also used to timeout often
<pitti> https://jenkins.qa.ubuntu.com/job/trusty-adt-linux/?
<apw> pitti, all the ones i have followed through have failed on one arch out of the two i think
<apw> but that would be only on upload, not ones triggered say but eglibc or whatever
<pitti> ah, tar freaking out again with "File removed before we read it
<apw> pitti, so you pointed me at a jenkins page which is like shoving hot needles in my brain, but making the foolish assumption that red == bad and green == good down the left there, my head says <half worked
<pitti> apw: exactly
<apw> ok so by my cound 60% are failing
<jibel> apw, timeout increased to 2000s. It may still fail depending on IO contention on the servers.
* Laney changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: alpha 2 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:
<pitti> apw: ah, that's still the timeout apparently
<pitti> from copyupdown
<pitti> jibel: thanks
<pitti> jibel, apw: retried
<jibel> pitti, yes, now set to 2000s we could as well drop it completely
<apw> pitti, what is this copy, is it someting i need and can i ask for it not to be so copied in my test stanza
<pitti> apw: no, unfortuantely not
<pitti> apw: that's autopkgtest copying the source package/source tree into its temp dir in the runner
<pitti> apw: and aldebaran's disk is just awfully slow
<pitti> apw: most tests are run on tmpfs (this machine has 64 GB RAM or so), but it's not enough to build linux; so linux and libreoffice run on a disk overlay instead of RAM
<directhex> pitti, exclusively on disk? or ram overflowing to disk?
<jibel> pitti, this machine is quite good but if at the same time it runs smoke tests they eat all resources available
<pitti> ah
<pitti> directhex: exclusively on disk; can qemu-img do this kind of hybrid mode?
<directhex> pitti, i think we hammered it into working for a project at work. trying to remember the details. it involved using nbd to create a ram block device (not using tmpfs) but i don't remember which service was used to overflow to an LV
<directhex> maybe bcache
<pitti> apw: hey, perhaps you have an idea about that: since recently (few days, could be with the new -4 kernel), preparing our autopkgtest VMs fail due to ENOSPC
<pitti> apw: the issue is that df says that /dev/vda1 (which is root) is 100% full, it's 5.9 GB
<directhex> am asking the engineer who did it if he documented it anywhere
<pitti> apw: but du -hcx / only reports some 800 MB being used
<pitti> apw: I already checked /proc/*/fd/ and lsof for deleted files, there are none at all; and tune2fs says the journal is only 32 MB
<pitti> apw: do you happen to know anything else which could eat up disk space which doesn't appear in df or in deleted files?
<lifeless> pitti: out of inodes?
<pitti> lifeless: nope, checked that already
<pitti> Block count:              1572608
<pitti> Free blocks:              1340686
<pitti> Free inodes:              332101
<Laney> jodh: just got the reboot again
<pitti> # du -hsx /
<lifeless> pitti: so clearly has free blocks
<pitti> 832M/
<lifeless> pitti: what about quotas?
<pitti> /dev/vda1       5.9G  5.9G     0 100% /
<pitti> lifeless: they aren't set up
<lifeless> oh, I see, df thinks its full
<pitti> but even if they were, they shouldn't affect root and df?
<lifeless> the free blocks is what 80%
<pitti> lifeless: yes, and everything else fails on ENOSPC too
<pitti> lifeless: right
<pitti> I'm running out of ideas what could be wrong
<lifeless> I smell a bug :)
<pitti> neither cloud-init nor cloud-utils changed recently, nor the ext tools
<pitti> I suspected hidden or deleted files, but I don't find any
<lifeless> pitti: they would use up free blocks
<lifeless> pitti: so it can't be that
<pitti> true that
<TJ-> pitti: sparse allocation maybe?
<Laney> jodh: what logs do you want?
<Laney> I was doing an apt update in the host and inside an lxc container simultaneously
<jibel> pitti, lifeless and after a reboot used space on /dev/vda1 is 15%
<pitti> TJ-: perhaps; I'm not entirely sure how the cloud images' root fs are put together
<pitti> qemu-img resize $DISKPATH +${DISKSIZE}
<pitti> jibel: ^ is that it?
<jibel> pitti, yes
<pitti> last qemu update was on Jan 3, the next upload is still stuck in -proposed, so not that either
<jibel> then cloud-init resizes it to the maximum size available
<jibel> it = rootfs
<Laney> jodh: the last thing in my apt log is Setting up libselinux1:amd64 (2.2.2-1) ...
<Laney> libselinux1's postinst does telinit u
<jodh> Laney: I think you'll find that you have an invalid conf file that is triggering the crash. alsa-utils is the most recent package that had invalid jobs, but that has now been fixed.
<Laney> would it be logged?
<Laney> anyway, that should certainly not cause the machine to reboot
<jodh> Laney: yes, if you're running in debug mode (--debug).
<jodh> Laney: of course :) I've now fixed the bug but am awaiting an upstart developer to review the fix: lp:~jamesodhunt/upstart/bug-1269731. Maybe xnox or cjwatson could take a look?
<TJ-> pitti: doesn't make sense though; df uses the block allocation maps, so if it reports 100% the host is using sparse allocation and has run out of space
<cjwatson> jodh: looking shortly
<jodh> cjwatson: thanks!
<lifeless> pitti: jibel: is it possible that online resize is being used, and is broken ?
<jibel> pitti, I reprovisioned a VM with a disk size of 12G and df is still reporting it is full on first boot. /dev/vda1        12G   12G     0 100% /
<lifeless> anything in dmsg
<pitti> TJ-: I just wanted to check this, and I made an interesting observation
<pitti> $ sudo du -hsxc /tmp
<pitti> 4,0K/tmp
<pitti> tmpfs                  7,8G    5,7G  2,1G   74% /tmp
<pitti> that's on my workstation (not in qemu)
<pitti> $ sudo du -hsxc /run
<pitti> 1,3M/run
<pitti> tmpfs                  1,6G    1,2M  1,6G    1% /run
<pitti> err, no, run-adt-test is using /run/shm, right?
<pitti> anyway, I have 4K files in /tmp/, but df says 5.7 GB are used in /tmp
<cjwatson> jodh: r=me, sorry for the delay
<pitti> so it might very well be that qemu has no space because on my host /dev/shm/ is full
<pitti> although it isn't, /run/shm/ has 7.3 GB free
<pitti> just /tmp/ is really wrong
<Laney> jodh: oh cool, thanks
<pitti> jibel: ^ does prepare-testbed use /tmp? that might explain why it's full during prepare-testbed, but works after a reboot when it uses /run/shm
<Laney> grr
<pitti> jibel: well, I'll try booting with 3.13.0-3 and compare
<Laney> stgraber: got any ideas how we can make the ssh-agent script less racy?
<jodh> cjwatson: thanks!
<jibel> pitti, it uses what you set as BASEDIR in ~/.adtrc and defaults to /tmp
<pitti> BASEDIR=/home/martin-scratch/adt
<TJ-> pitti: Isn't it pressure on RAM? tmpfs is backed by swap space
<pitti> TJ-: well, I still don't know why it would run out of RAM; but the lost 5.7 GB in my /tmp/ are certainly curious
<pitti> (/tmp is on tmpfs)
<smb> pitti, jibel Note that the 3.13.0-3 kernel very likely has an accounting bug for tmpfs
<pitti> smb: I didn't have the cloud-init problem on -3; it just started maybe two days ago
<smb> 3.13.0-4 (currently in proposed is believed to fix this)
<pitti> could coincide with -4
<pitti> smb: you mean -3 â -4 and -4 â -5 ?
<pitti> smb: I'm currently downloading -5 from -proposed and will test that
<smb> pitti, Err yeah I probably do
<smb> pitti, Versions changing so quickly, sorry.
<cjwatson> what's up with the linux autopkgtest?
<pitti> that at least would also explain why we don't get that problem in the DC where we have precise or saucy as a host OS
<pitti> cjwatson: it keeps timing out on copying the sources into its tmp dir; jibel just bumped the timeout again
<cjwatson> ah, /me reads scrollback.  so is somebody retrying the test?
<cjwatson> we need to get this in for the alpha
<pitti> cjwatson: already did
<cjwatson> ok, good
<cjwatson> sorting d-i now
<pitti> jibel: ok, so with -5 on the host I still get the bug in the VM; we might need to get -5 into the cloud image
<pitti> at least df now looks sensible in my hosts' /tmp/
<pitti> smb: ^
<darkxst> cjohnston, hey, I am applying for upload rights on ubuntu GNOME packageset but there isnt one!
<cjwatson> pitti: good, hopefully it'll fix d-i too
<darkxst> cjwatson, ^^
<cjwatson> darkxst: I'm no longer on the TB so I don't operate packagesets any more
<cjwatson> darkxst: though you probably actually want to ask the DMB
<darkxst> cjwatson, Laney told me to ask you
<cjwatson> darkxst: Laney is wrong :)
<Laney> haha
<Laney> Can we drive those scripts?
<smb> pitti, Probably needs to move to updates. But then I should read more scrollback on what exactly your tmpfs problem is after changing the latest kernel
<cjwatson> I *think* it needs the TB, but you can try
<cjwatson> lp:~cjwatson/+junk/packageset - there's a component you need to run on lillypilly
<pitti> smb: right, let's wait until this is in trusty and we have a cloud-image with -5
<Laney> == All uploaders for package set 'ubuntugnome' in 'trusty' (owned by 'Ubuntu Technical Board') ==
<cjwatson> (or I suppose just anywhere with a full mirror)
<Laney> DMB cannot manage that
<pitti> smb: it's all very confusing ATM, and tests on various host and guest configurations give contradicting results
<smb> pitti, With the tmpfs bug, anything that actually makes use of it has a chance to fail. So it could be something ending up in tmpfs on the host but also and probably more often when using anything inside the guest
<darkxst> Laney, cjwatson, so I am applying for a non-existent packageset ? atlest MOTU will be useful ;)
<Laney> stgraber is in the intersection
<apw> if it is the percpu fix we are talking about you would need that everywhere, as /dev is one
<Laney> he might be interested in learning how to run this process
<cjwatson> Laney: I was planning to hand it over at the core sprint next week
<pitti> apw: originally it was the "/dev/vda1 is 100% full although it isn't" issue in qemu, then I noticed the "df gives bogus tmpfs usage" on my host; they might or might not be releated
<pitti> apw: so I guess we'll let -5 propoagate and get a cloud image with it, then I'll try again; let's hope it's all good then
<Laney> cjwatson: nod
<cjwatson> Laney: when people can throw tomatoes at me for it in person
<cjwatson> (it's really dreadful code)
<apw> pitti, indeed, but i would test with everything updated rather than hurt your mind with the infinite possibilities
<pitti> apw: right; apparently -5 on the host and -4 in the qemu guest doesn't fix it yet
<smb> pitti, Quite expectedly
<pitti> apw: conversely, with a raring kernel on the host and -4 as a qemu guest it seems to work
<pitti> apw: but curiously this is on a qemu-img backed on ext4, not tmpfs
<pitti> oh well *shrug* kernel mystics .. /me goes and investigates the equally mysterious bug 1220681
<ubottu> bug 1220681 in espeak (Ubuntu) "package espeak-data 1.46.02-2ubuntu1 failed to install/upgrade: unable to move aside `./usr/lib/i386-linux-gnu/espeak-data/voices/en' to install new version: Invalid cross-device link" [Undecided,Confirmed] https://launchpad.net/bugs/1220681
<apw> the issue is in per cpu counters, its not tmpfs related just that is very sensitive to it
<apw> given the bug, i am amazed the kernel boots with it at all under any circumstances
<pitti> apw: ah, so it could break just about anything
<cjwatson> apw: I guess it effectively means it never clears any references to anything
<cjwatson> probably uses a shitload of memory
<apw> and pretty much everything, i had all sorts of random things going on on -4, -5 seems better to me
<pitti> that now also explains why my apt-get was so glacially slow yesterday
<apw> leaking like hell at least i recon
<pitti> apw: hm, something isn't quite  right -- why does the autopkgtest build it *twice*?
<pitti> apw: nevermind, I mislooked; all good (i386 succeeded)
<pitti> stgraber: is it possible to set a different default container dir (than /var/lib/lxc) in /etc/lxc/default.conf or ~/.lxc<something>? man lxc.conf doesn't mention it, nor does it mention what the actual config files are
<pitti> stgraber: so that I don't need to use -P all the time
<pitti> apw, cjwatson: linux autopkgtest succeeded now, BTW
<pitti> "Not touching package due to block request by freeze "
<pitti> but excuses still says "autopkgtest for linux 3.13.0-5.20: FAIL"; I hope it's just out of date
<apw> pitti, i don't think it ever notices when you rerun a test does it ?
<pitti> apw: actually I think jibel fixed that a while ago
<apw> it just need ignoring the test i think there
<pitti> apw: if it didn't update after the next run, I'll fix the history file
<pitti> apw: ah, it just did
<pitti> apw: all good now, it's just the release team blocker that holds it back now
<pitti> (a2 freeze)
<apw> and possibly d-i
<apw> oh no that is there too ... ok
<cjwatson> I uploaded d-i
<pitti> not blocked by itself, it' sjust waiting on linux
<apw> thanks
<xnox> jibel: (i think we discussed this ~1.5 weeks ago) have you tried running tests under utah with this change applied to the base image: sudo sh -c "echo exec su - -c adbd > $OUT/mnt/etc/init/android-tools-adbd.override"
<xnox> ?
<xnox> sudo sh -c "echo exec su - -c adbd > /etc/init/android-tools-adbd.override"
<xnox> that actually?
<jibel> xnox, it was not with me, sorry.
<xnox> ok. i'll search my logs then...
<shadeslayer> is there a reason why I would not have com.upstart.Ubuntu?
<shadeslayer> over dbus that is
<Laney> shadeslayer: firstly it's com.ubuntu.Upstart
<Laney> assuming you just typoed, then I don't know :-)
<shadeslayer> qdbus com.ubuntu.Upstart gives me Service 'com.ubuntu.Upstart' does not exist.
<shadeslayer> Laney: I don't suppose there's a way to actually start that interface by hand?
<shadeslayer> Laney: also, i'm on Kubuntu if that makes a difference
<Laney> shadeslayer: sorry, I don't know - I was under the impression that it should always be there
<Laney> maybe #upstart can help you
<shadeslayer> aha, I'll ask
<smoser> cjwatson,  i'm thinking about  memtest86+ as part of ubuntu standard.  how would you recommend re-ordering things so that I can get that out of cloud images?
<cjwatson> smoser: will follow up to the dormant mail thread, this IRC channel is too narrow
<smoser> ok thank you.
<pitti> cjwatson: FYI, ubiquity autopkgtest failed on i386 FTBFS of webkit-gtk (causing uninstallability)
<doko> pitti: I usually use severity serious for broken autopkg tests by design. it's nice if people add them, but things like this should never happen in the first place
<doko> pitti, please overwrite this test. blocks a package removal
<doko> pitti, libocsync-plugin-owncloud, waits for owncloud-client to go to trusty
<pitti> doko: err, yes, I know -- that looks like a replay?
<pitti> doko: slangasek added the override, it's in trusty
<doko> pitti, oh, is it overwritten?
<xnox> doko: any ~ubuntu-release can commit adt overrides in britney hints.
<pitti>  libocsync-plugin-owncloud | 0.90.4-1        | trusty/universe | amd64, arm64, armhf, i386, powerpc, ppc64el
<doko> still see
<doko> libocsync-plugin-owncloud
<doko>    	python-owncloud	universe	amd64 i386 arm64 armhf powerpc ppc64el
<pitti> doko: ^ is that the version you are looking for? (nothign in -proposed)
<cjwatson> pitti: is that something we (ubiquity developers) need to do anything about?  I'd expect it to be retried once webkitgtk is fixed
<pitti> I don't see any "croc" in component-mismatches, NBS, or britney
<pitti> cjwatson: no, it was just a FYI (as you probably got the mail)
<pitti> ah no, xnox got it
<cjwatson> that explains my confusion :)
<pitti> cjwatson: sorry, in my mind "ubiquity" is still "Colin"
<pitti> so for once an autopkgtest failure today was not due to the test machinery *sigh*
<xnox> pitti: i'm not on top of my post-vacation unread mail threads yet, especially those from robots =)
<pitti> xnox: no worries, and welcome back :)
<xnox> pitti: re:autopilot. last time i was talking with thomi & barry, we were thinking to add a "python2" flag to all existing clicks (cause their tests run from $PWD), and for deb tests simply try module import with python3 to see if it should be run with python3.
<xnox> pitti: once all tests are converted to python3. A python2 flag can be dropped from clicks (one by one) and for deb tests try python3 import will no longer be needed.
<pitti> xnox: right; I just don't quite like the metapackage pulling in both the py2 and py3 stacks, as that's quite some overhead for the phone
<xnox> pitti: thus we should arrive at not having any "X-Run-Me-Python3" in the long term, once all is converted. Without an explicit flag day.
<pitti> so we need to do that transition for trusty now
<xnox> pitti: which should be all done and dusted next week, at the core sprint when barry will be there + the rest of CI etc peoples =)
<xnox> pitti: barry did submit a few merge proposals, but not all of them are merged yet.
<pitti> xnox: right, I added it to the agenda of our QA sprint as well (mid-Feb)
<pitti> xnox: I have patches for dialer-app and messaging-app here, but when I did them they were blocked on splitting out emulators for python3 for some packages
<pitti> which in turn was blocked by some discussion how to package/name them
<xnox> pitti: i think the next piece that is missing, is for phablet-test-run / utah-runners to do the "try python3" tests. And there is a rejected merge proposal that I saw in my emails.
<pitti> doko: in our precise â trusty upgrade tests, several packages failed due to a missing python:any; what particularly provides that :any magic, new dpkg?
<xnox> pitti: once we have ability to run tests under python3 in jenkins it should be all easy and quick to transition things one by one.
<doko> pitti, yes
<pitti> doko: or new python metapackages? it seems python:any deps now get autogenerated, but there is no Pre-Depends: or somethign like that on dpkg/python-defaults/etc.
<doko> it's dpkg
<pitti> xnox: still needs things like bug 1253627 fixed first
<ubottu> bug 1253627 in ubuntu-ui-toolkit (Ubuntu) "Needs to provide emulators for Python3" [Undecided,New] https://launchpad.net/bugs/1253627
<pitti> doko: ah, so perhaps dh_python[23] need to generate pre-depends for that?
<pitti> doko: well, this is rather complex, I'll create a bug report and a small reproducer first
<doko> pitti, won't help, I don't that any python-* module has misc:pre-depends
<pitti> yeah, we'd need to either add them, or don't use misc:pre-depends
<pitti> bbiab, will investigate this in detail later
<pitti> doko: thanks, will try with old and new dpkg then
<stgraber> pitti: lxc.lxcpath = in /etc/lxc/lxc.conf or ~/.config/lxc/lxc.conf
<stgraber> pitti: those are currently undocumented because lxc.conf refers to the container's configuration, not the system config... I have a todo item for this week to create lxc.system.conf and lxc.container.conf manpages and have the lxc.conf one just explain what the two files are for and what their respective manpage is
<mdeslaur> chiluk: unfortunately, I once again superseded your mysql packages in -proposed. Sorry.
<pitti> stgraber: works perfectly, merci !
<mdeslaur> barry: quick question: would this be the right way to run 'python setup.py configure' in a rules file? http://paste.ubuntu.com/6792046/
<mdeslaur> or is there something better?
<mdeslaur> (with dh_python2)
<xnox> mdeslaur: there is "pybuild" which will run stock: configure, build, test, install for all python2 / 3 versions et.al.
<barry> mdeslaur: interesting.  configure isn't a standard command, so i'm guessing the setup.py has added this.  in that case, dh_python2 probably won't help
<xnox> mdeslaur: dh_python2, is a pure packaging helper that does correct extension renaming at the end.
<xnox> mdeslaur: and you are playing with highly non-standard libvirt build machinery, so i'm not sure there is anything better for you than what you wrote.
<xnox> (dh_python2 doesn't build/configure/install anything)
<xnox>  * mostly true.
<mdeslaur> xnox, barry: ok, thanks, so I'll stick with what I used
<mdeslaur> thanks!
<barry> sure!
<ara> hello!
<ara> any member of the sru team could have a look to these two verified bugs, please?
<ara> https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/404658
<ubottu> Ubuntu bug 404658 in OEM Priority Project precise "notification summary doesn't change for synchronous messages" [Critical,In progress]
<ara> https://bugs.launchpad.net/oem-priority/+bug/1253591
<ara> thanks!
<ubottu> Ubuntu bug 1253591 in OEM Priority Project "Display switch and Radio enable/disable hotkey icons" [High,In progress]
<caribou> infinity: did you notice the email I sent a while ago about the merging of makedumpfile ,
<caribou> ?
<caribou> infinity: if it's ok with you, I'll merge it & do my best to get the debian side I package in sync
<pitti> jibel: FYI, I filed bug 1271237 to track investigations
<ubottu> bug 1271237 in python-defaults (Ubuntu) "precise â trusty upgrade; several packages fail due to python:any dependency" [Undecided,New] https://launchpad.net/bugs/1271237
<cjwatson> pitti: followed up with what might be a useful link
<pitti> cjwatson: right, it very much sounds like that
<pitti> python:any isn't satisfied yet, but apt doesn't upgrade python to satisfy it
<pitti> cjwatson: many thanks for the link
<cjwatson> np
<cjwatson> seb128: could you check that the newer grub in trusty-proposed fixes your timeout problem?
<pitti> cjwatson: I'll backport that and test an upgrade with that; the next question is of course whether apt gets upgraded before that
<cjwatson> pitti: similarly, could you check that grub in trusty-proposed still works with SB for you?  another commenter spotted a bug that would affect from-scratch installs on SB
<cjwatson> pitti: right, but that's more tractable, u-m could force that
<cjwatson> (if it doesn't already)
<pitti> *nod*
<cjwatson> I guess I mean u-r-u
<pitti> cjwatson: yes, I'm happy to update grub again, but it'd be an upgrade, not from scratch
<cjwatson> right, just want to check that I didn't break anything else in the process
<pitti> cjwatson: unless I can emulate a new installation by purging and reinstalling grub? (I can do that)
<seb128> cjwatson, sure
<cjwatson> no, you'd have to do manual stuff to your EFI System Partition - an upgrade is fine for this purpose
<cjwatson> you could maybe run "sudo grub-install -v" after the upgrade to check that it copies shim to the right place
<pitti> cjwatson: ah, that's -4 now -- that should also get rid of the menu again, right?
<cjwatson> i.e. /boot/efi/EFI/ubuntu/shimx64.efi not /boot/efi/EFI/ubuntu/grubx64.efi
<cjwatson> pitti: yep
<pitti> argh, laggy german mirror
<pitti>  *** 2.02~beta2-2 0
<pitti>         500 http://archive.ubuntu.com/ubuntu/ trusty-proposed/main amd64 Packages
<pitti> WTH
<pitti> cjwatson: downloaded debs from LP, installed; no failure; with -v: http://paste.ubuntu.com/6792642/
<pitti> grub-install: Info: copying `/usr/lib/shim/shim.efi.signed' -> `/boot/efi/EFI/ubuntu/shimx64.efi'.
<pitti> grub-install: Info: copying `/usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed' -> `/boot/efi/EFI/ubuntu/grubx64.efi'.
<alkisg> Hi, I'm seeing 100% usage of overlayfs (squashfs nbd + tmpfs) file systems, while it should be 0%, it happened in some of the latest trusty kernels, and I'm guessing it should also affect the live CDs (other than LTSP), is it a known issue or should I try to pinpoint it more precisely?
<cjwatson> pitti: great, thanks
<cjwatson> alkisg: 3.13.0-5 will fix it
<pitti> cjwatson: I'll reboot once my container upgrades are done
<alkisg> Thank you cjwatson
<pitti> cjwatson: booted fine, menu gone \o/
<cjwatson> great
<cjwatson> it's not totally without reported glitches but I think it's close enough that I'm inclined to push it to trusty after alpha-2
<cjwatson> so far
<jibel> pitti, postgresql upgrade fails from P>T, I'll file a bug. http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-precise-trusty-server-tasks-amd64/5/
<pitti> jibel: thanks
<Laney> are those tests on public jenkins?
<pitti> there certainly ought to be; it's a bit hard to link to logs ATM
<jibel> Laney, they should be, I'll check the configuration.
<pitti> update-alternatives: error: alternative pg_basebackup.1.gz can't be slave of psql.1.gz: it is a slave of postmaster.1.gz
<Laney> I usually try s/<private host>/jenkins.qa.u.c/ but it failed in this case
<Laney> thanks jibel
<pitti> jibel: ^ ah, that, rings a bell
<jibel> pitti, and a false positive http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-precise-trusty-server-lts-saucy-amd64/6
<pitti> jibel: I thought that was fixed already, but apparently it needs some further nudging
<jibel> ^ fails during the removal phase
<pitti> jibel: I don't see a psql bug there?
<pitti> jibel: oh nice, that's precise with an LTS enablement stack; I guess these fall over pretty hard still
<jibel> pitti, last bug is not postgresql, it is in xserver-common-lts-saucy and u-r-u
<pitti> jibel: right, I discussed that with mlankhorst the other day; we need these -lts-* metapackags as transitionals in trusty, which move back to the standard stack
<jibel> because upgrade aborted but the release-upgrader terminates without error
<mlankhorst> pitti: oh right I need to create some
<pitti> good night everyone!
<cff> I'm trying to dual boot CM Android 4.2.2 on a Galaxy Nexus with Ubuntu but after I downloaded the Ubuntu image with the Android app and click reboot to Ubuntu I'm rebooted to recovery mode. What can I do to see what's wrong?
<cff> (is this the right channel to ask this question?)
<cff> ah, didn't realize there is an #ubuntu-touch channel
<chiluk> mdeslaur
<chiluk> mdeslaur can you have a look at 1121874
<chiluk> mdeslaur it looks like your recent security update for mysql-5.5 updated the package
<chiluk> mdeslaur, and maintained the fix for 1121874, but removed it's changelog entry..
<chiluk> mdeslaur... I really think you should add the changelog entry back *(not sure if that's really doable.)
<chiluk> I'm verifying s, and t right now.
<mdeslaur> chiluk: what release are you talking about?
<chiluk> p,q,s,t
<mdeslaur> trusty has the fix, and includes the changelog
<chiluk> I just looked at p and q... and they have the fix... but not the changelog entry.
<mdeslaur> chiluk: not sure what you're looking at, but my packages definitely don't contain the fix
<chiluk> the fix is in debian/mysql*.init
<chiluk> mdeslaur also why did you just blindly remove the fix like that
<mdeslaur> chiluk: huh? https://launchpadlibrarian.net/159968670/lp1121874.saucy.debdiff
<mdeslaur> chiluk: no fix in .init there
<chiluk> mdeslaur.. one sec... I think I missed the series arg to pull-lp-sourcfe
<mdeslaur> chiluk: your package was in -proposed, I can't include a fix that hasen't been qa verified
<chiluk> mdeslaur, I guess I'm just pissed because this is the third time that I'm having to rebase debdiffs because of security team.
<chiluk> and the sru team taking too long to upload/sru approve this fix.
<chiluk> this is insane.
<mdeslaur> chiluk: yeah, the -proposed process sucks
<infinity> (The SRU team doesn't do uploads)
<mdeslaur> chiluk: I'll rebase and upload them today
<mdeslaur> chiluk: and I'll get someone from SRU team to push them to -proposed right away
<chiluk> thanks.
<chiluk> i was going to verify them today.
<chiluk> so I guess I'll get that done as soon as this gets figured out..
<mdeslaur> chiluk: again, sorry about that...bad timing
<chiluk> mdeslaur, it's always bad timing... this bug has been fixed since October, and it's wasted too much of a lot of peoples time.
<mdeslaur> I definitely agree
<mdeslaur> chiluk: mind if I keep your name in the changelog, and just change the version and date?
<chiluk> that's fine.
<chiluk> mdeslaur.. I just checked precise.. and the fix is definitely in the precise version just not in the changelog
<infinity> caribou: I don't see much point in merging makedumpfile in Ubuntu at all.  Looking at the changes, those are all things you should want in Debian, so I'd merge in the other direction, if I were you, and then just sync-with-force back to Ubuntu.
<mdeslaur> chiluk: I don't see it
<rbasak> chiluk: if it's any consolation, I have also found it hard to get any SRUs into mysql in the past. I think I went round three times once.
<chiluk> mdeslaur the fix is mostly thesse lines   # check for diskspace shortage
<chiluk>   datadir=`mysqld_get_param datadir`
<chiluk>   if LC_ALL=C BLOCKSIZE= df --portability $datadir/. | tail -n 1 | awk '{ exit ($4>4096) }'; then
<chiluk>     log_failure_msg "$0: ERROR: The partition with $datadir is too full!"
<chiluk>     echo                "ERROR: The partition with $datadir is too full!" | $ERR_LOGGER
<chiluk>     exit 1
<chiluk>   fi
<mdeslaur> chiluk: yeah, I don't see that in the precise package
<chiluk> one of us is doing something wrong *(probably me)
<chiluk> mdeslaur .. I run pull-lp-source mysql-5.5 precise, and look at debian/mysql-server-5.5.mysql.init
<chiluk> and the fix is definitely sitting there.
<chiluk> mdeslaur is there a chance the fix got pushed back into debian, as is now coming full circle?
<mdeslaur> chiluk: you're looking at the .init file, you need to look at the .upstart file
<mdeslaur> chiluk: that's where the bug is
<chiluk> crap...
<chiluk> see it's been so long ..
<mdeslaur> hehe :)
<chiluk> mdeslaur..see I knew i was doing something wrong..
<chiluk> mdeslaur... the debdiffs should still mostly just apply ... aside from the changelog entries.. do you need anything from me to get that uploaded?  or are you just going to take care of it.
<mdeslaur> chiluk: I'm almost done uploading, and then I'll ping someone from SRU to get it pushed to -proposed right away
<chiluk> cool thanks.
<mdeslaur> chiluk: np
<chiluk> well at least it looks like the debian people have been paying attention and pulled my fix into the init script.
<chiluk> and I use the term "fix" loosely ... I just want to see this thing gone.
<mdeslaur> bdmurray: I just uploaded updated mysql packages to -proposed for bug 1121874, do you think you could push them today, please?
<ubottu> bug 1121874 in mysql-5.5 (Ubuntu Saucy) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Fix committed] https://launchpad.net/bugs/1121874
<bdmurray> mdeslaur: sure
<mdeslaur> bdmurray: thanks!
<xnox> tkamppeter: recently I was able to use llvmpipe / gallium 3d on an openstack instance. But with current trusty I can't.
<xnox> I get:
<xnox> $ LIBGL_DEBUG=verbose xvfb-run glxinfo
<xnox> name of display: :99
<xnox> libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/tls/swrast_dri.so
<xnox> libGL: OpenDriver: trying /usr/lib/i386-linux-gnu/dri/swrast_dri.so
<xnox> libGL: driver does not expose __driDriverGetExtensions_swrast(): /usr/lib/i386-linux-gnu/dri/swrast_dri.so: undefined symbol: __driDriverGetExtensions_swrast
<xnox> libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory.
<xnox> libGL: Can't open configuration file /home/ubuntu/.drirc: No such file or directory.
<xnox> libGL error: failed to load driver: swrast
<xnox> Error: couldn't find RGB GLX visual or fbconfig
<xnox> Error: couldn't find RGB GLX visual or fbconfig
<xnox> tkamppeter: is that known?
<seb128> xnox, hum, why do you ping our printer maintainer about graphic stack issues? are you sure you don't want mlankhorst or tjaalton?
<xnox> seb128: good catch!
<xnox> tkamppeter: sorry about that.
<xnox> mlankhorst: tjaalton: any idea about above ^^^
<seb128> xnox, btw I get the same output on my desktop (but followed by the glxinfo one)
<xnox> and there haven't been any changes to mesa recently...
<xnox> seb128: does it tell you "Vendor" ?
<seb128> xnox, no
<xnox> seb128: in my case, i don't GPU acceleration, so the swrast better load....
<seb128> xnox, that undef symbol looks wrong in any case
<xnox> seb128: well on my desktop i get:
<xnox> OpenGL vendor string: Intel Open Source Technology Center
<xnox> OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Desktop x86/MMX/SSE2
<xnox> (among the rest of the stuff glxinfo prints)
<seb128> $ ldd -r /usr/lib/i386-linux-gnu/dri/swrast_dri.so
<seb128> ..
<xnox> seb128: and on headless systems I used to get "Gallium 3D vendor" now I get nothing.
<seb128> undefined symbol: _glapi_tls_Dispatch	(/usr/lib/i386-linux-gnu/dri/swrast_dri.so)
<seb128> etc
<seb128> xnox, seems like the software rendering backend is having issues
<xnox> seb128: here is full, working pastebin from my computer http://paste.ubuntu.com/6793108/
<seb128> xnox, right, that has hardware support
<seb128> though "LIBGL_ALWAYS_SOFTWARE=1 glxinfo" works on my desktop
<xnox> seb128: mlankhorst: tjaalton: actually nevermind me it does work after all.
<kees> doko: why was debian bug 27363 re-opened? I added --with autoreconf and a dep on dh-autoreconf. what is missing?
<ubottu> Error: Debian bug 27363 could not be found
<kees> sorry, debian bug 727363
<ubottu> Debian bug 727363 in src:duo-unix "duo-unix: run dh-autoreconf to update config.{sub,guess} and {libtool,aclocal}.m4" [Normal,Open] http://bugs.debian.org/727363
<cjwatson> that looks like a mistake - it builds just fine on ppc64el
<kees> okay, cool
<cjwatson> I think doko was mass-operating on all those bugs and hadn't noticed that that one had already been fixed in the more comprehensive way
<kees> yeah, that's what I suspected, but I wanted to double-check. thanks!
<Noskcaj> Could someone help me fix an FTBFS in xchat-gnome? just get https://code.launchpad.net/~noskcaj/ubuntu/trusty/xchat-gnome/merge and build it
<Noskcaj> doko, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727373 can be closed, ppc64el builds fine
<ubottu> Debian bug 727373 in src:enblend-enfuse "enblend-enfuse: run dh-autoreconf to update config.{sub,guess} and {libtool,aclocal}.m4" [Normal,Open]
<Noskcaj> and i'm doing the merge now
<Ampelbein> Noskcaj: What failure do you get?
<Ampelbein> (with xchat-gnome)
<Noskcaj> Ampelbein, just let me re-branch it. It's been a few days since i worked on it
<hallyn> infinity: mdeslaur is asking about qemu in trusty's ftbfs on powerpc.  have you had any luck there?  or should we just dump the aarch64 patchset?
<infinity> hallyn: I was sick all weekend and yesterday, haven't had a chance to look at all.
<hallyn> infinity: ok;  i'm out today;  maybe i can use a qemu-ppc to try the build tomorrow :)
<hallyn> mdeslaur: so if you need the debdiff reverted to have it build please do so;  i'll then push when we figure out what went wrong
<infinity> hallyn: I shouldn't think you'd need a PPC machine to build on.  I imagine if you build that ppc64-softmmu target on *any* arch, it will fail the same.
<infinity> THough maybe not.  Hrm.
<infinity> No, okay, that gets built on x86 and works.  That makes this so much more confusing.
<hallyn> infinity: all right well maybe it'll be obvious to me once i take a closer look tomorrow.  thanks, get better!  /me out
<Noskcaj> Ampelbein, http://paste.ubuntu.com/6793607/
<Ampelbein> Noskcaj: gnome-doc-utils.make is missing, are you running autogen.sh ? That should call gnome-doc-prepare and create it.
<Ampelbein> Noskcaj: Just checked out the branch (unrelated: What switch can I use to tell bzr that I only want to checkout the files at current state, not the entire history?).
<Ampelbein> Noskcaj: I'd do it like in debian, with DEB_CONFIGURE_SCRIPT := ./autogen.sh
<Noskcaj> I'll test that now
<tarpman> Ampelbein: are you looking for 'bzr checkout --lightweight'?
<Noskcaj> Ampelbein, The error still appears
<Ampelbein> tarpman: Well, basically the equivalent of git clone --depth=!
<Ampelbein> *depth=1
<Ampelbein> Noskcaj: mc
<Ampelbein> ups
<Noskcaj> ?
<Ampelbein> clumsy fingers.
<Ampelbein> Noskcaj: http://paste.debian.net/77688/ makes it build.
<Ampelbein> You probably still had autoreconf.mk in your rules file.
<Noskcaj> yeah
<Noskcaj> Can i drop the autoreconf build dep then?
<Ampelbein> No, it still gets run.
<Noskcaj> ok. thanks. I'll just test build it myself then propose the merge
<Logan_> how can I add extra usertags with submittodebian? (cc doko)
<doko> Logan_, I didn't check, sorry. never used that
<Logan_> hmm, alright
<Logan_> I might have to tag retroactively for every bug :/
<doko> Logan_, see my email, you can do this with a single email to control@bugs.debian.org
<Logan_> okay, I'll do that
<Noskcaj> Can someone please sync xfce4-weather-plugin from debian stable to precise? it would fix bug 1244629
<ubottu> bug 1244629 in xfce4-weather-plugin (Ubuntu Precise) "SRU xfce4-weather-plugin, currently showing 'No Data'" [Undecided,In progress] https://launchpad.net/bugs/1244629
<Noskcaj> which is making it unusable
<Logan_> Un momento.
<Logan_> Oh, precise?
<Noskcaj> yeah
<Logan_> You didn't subscribe ~ubuntu-sru.
<Logan_> Er. Hold up. There was already an SRU upload?
<Noskcaj> no, and no
<Logan_> http://launchpadlibrarian.net/162524610/xfce4-weather-plugin_0.7.4-3ubuntu1_source.changes
<Noskcaj> i've just subscribed SRU
<Logan_> It hasn't been approved yet.
<Noskcaj> and it shouldn't be approved. It's broken
<Logan_> Oh.
<infinity> Broken how?
<Noskcaj> which is why i was waiting for -5 to ask
<Noskcaj> https://bugs.launchpad.net/ubuntu/precise/+source/xfce4-weather-plugin/+bug/1244629/comments/23
<ubottu> Ubuntu bug 1244629 in xfce4-weather-plugin (Ubuntu Precise) "SRU xfce4-weather-plugin, currently showing 'No Data'" [Undecided,In progress]
<infinity> Noskcaj: We're not going to sync a new upstream from Debian to precise.
<Noskcaj> Not a new upstream. two new debian stable uploads
<Noskcaj> although i can change that to one ubuntu upload if you'd prefer
<infinity> Erm.  0.7.4-3 in precise, versus.  Oh, I see, you mean from wheezy.
<infinity> I misread.
<Noskcaj> :)
<infinity> We, we *could* sync that, though it wouldn't have the LP bug reference in it, which makes it a bit harder to track.
<infinity> If someone's willing to verify the SRU as soon as it's built, I wouldn't be against just syncing it.  I just wouldn't want it to get lost/forgotten in proposed forever.
<infinity> Noskcaj: Would you be okay with doing a verification pretty much immediately?
<Noskcaj> we've got a fair few affected users. We'll find people
<Logan_> shouldn't we get rid of the current one in the queue first?
<Noskcaj> I think some of the other xubuntu devs have a precise machine
<Noskcaj> Logan_, yes
<infinity> Logan_: This would supersede that, so meh.
<infinity> But I can reject it right now.
<Logan_> sweet
<infinity> LP hasn't picked up the new wheezy upload yet, so couldn't sync it even if I wanted to.
<Noskcaj> ok, let me know when it does and i'll find some people to test
#ubuntu-devel 2014-01-22
<Noskcaj> thanks for the syncs Logan_. There should be a fair few more there
<Noskcaj> And another SRU
<Logan_> Noskcaj: lol, you should be happy I'm doing this now. first day of the new semester tomorrow :O
<Noskcaj> :)
<Noskcaj> I've got another week still
<Logan_> unfortunately there aren't any Ubuntu packaging classes I could TA
<Logan_> it's a shame
<Noskcaj> Are there any ubuntu packaging classes ever now?
<Logan_> if there were one, that would be awesome
<Logan_> make it happen!
<Noskcaj> i'll try. First i need all the xubuntu 14.01 stuff sponsored and to finish adopting xsane
<pitti> Good morning
<jibel> pitti, provisioning of VMs for adt is working with kernel -5
<pitti> jibel: indeed, I verified this morning
<dholbach> good morning
<pitti> erk, since when do we switch consoles using Alt+Left/Right? that's very confusing, and I use these for other things already
<pitti> is that a kernel thing, or X.org?
<pitti> apw, RAOF ^
<mlankhorst> morning
<pitti> stgraber: if I may bother you again: I use apt-cacher-ng on my workstation; is it possible to tell lxc to set an apt proxy for creation of a container? or is that  something you'd set up manually for each container after its created?
<smb> pitti, Courtesy of unity default keybindings I would guess. The kernel does not care about that
<pitti> smb: I can switch between VTs with Alt+left/right as well
<didrocks> (nothing related to unity keybindings)
<pitti> gah, it's only now that I realize how often I use Alt+left/right
<pitti> switching between channels in IRC, going back and forth in firefox
<pitti> I'm fairly sure this is new from today
<pitti> or new with kernel -5, I was running the saucy kernel yesterday afternoon to test something else
<pitti> I'll bisect
<didrocks> pitti: I didn't update yet and alt + left/right works here to switch IRC channels
<didrocks> pitti: let me see what I didn't update since yesterday
<smb> pitti, I woul d be pretty sure that the changes between those kernels did not contain something to change that
<didrocks> pitti: http://paste.ubuntu.com/6796175/
<didrocks> quite a lot
<didrocks> want me to try upgrading to latest kernel first?
<pitti> didrocks: yeah, fortunately most packages are unrelated to that
<smb> didrocks, that at reast would rule out the that or not
<pitti> didrocks: if you want; I'll try downgrading the kernel first, and then some other updates
<apw> pitti, using -5 kernel here and Alt+Left/Right is working as expected
<smb> pitti, Thats still installed, no?
<didrocks> pitti: as you wish, I can apt-get install linux-image
<pitti> smb: "still installed"> I'm running that, if you mean that
<smb> pitti, I mean downgrading to -4
<smb> Both should be installed if you upgraded
<smb> via grub
<pitti> smb: apt-get autoremove already cleaned it up, but I'll get it from LP
<pitti> sec
<smb> apw, Isn't autoremove supposed to leave at least the previous one?
<pitti> smb, didrocks: ah, a mere reboot fixed it apparently (without changing packages)
<apw> the last three, plus the current kernel if it isn't one of those
<pitti> so it was either some funny thing that qemu or LXC did this morning, or some transient thing from dist-upgrading without rebooting
<pitti> smb, apw: I had -5 installed and running, plus the saucy kernel, so -4 got autocleaned
<pitti> which I was quite happy about, given how leaky -4 was
<pitti> perhaps booting precise in LXC does some funny console setup or so?
<smb> pitti, It surely was not the best one. Though I would not expect autoremove to be that smart ;)
<pitti> smb: ah, it doesn't have a "remove dangerous kernels" mode? :-)
<apw> no indeed :)
<pitti> reminds me of http://www.youtube.com/watch?v=ytVdBLMmRno
<pitti> (watch it till the end)
<apw> perhaps you were running the saucy kernel when you autoremoved
<smb> pitti, Maybe if we flag them as broken when we send them out. Like all those we do especially to check whether qa is paying attention. ;-P
<pitti> apw: no, that was this morning when I ran -5
<didrocks> pitti: oh :)
<pitti> apw: anyway, I had the current, running, and a previous kernel
<jibel> pitti, re proxy for LXC, set HTTP_PROXY to your apt proxy or to 'apt'
<jibel> pitti, ie sudo HTTP_PROXY=apt lxc-create ....
<pitti> jibel: ah, nice
<jibel> or or sudo HTTP_PROXY="http://.../" lxc-create....
<pitti> hm, doesn't seem to work
<pitti> I can stop apt-cacher-ng and it still works; and there's nothing in the container's apt.conf.d/ to set it?
<pitti> jibel: ^
<pitti> jibel: or perhaps this doesn't work as it's using a cached base system already
<jibel> pitti, yes, you may need to flush the cache with option -F of the template
<pitti> jibel: trying
<jibel> pitti, "sudo HTTP_PROXY=apt lxc-create -n test_proxy -t ubuntu -- -F -d" works here and it creates /var/lib/lxc/test_proxy/rootfs/etc/apt/apt.conf.d/70proxy with the right proxy
<pitti> jibel: ah, so I suppose it doesn't create that file when using a cached base fs
<pitti> jibel: ah, now it's using apt-cacher-ng even during creation
<pitti> jibel: merci
<pitti> stgraber: ^
<pitti> jibel: ah, HTTP_PROXY=apt would use 127.0.0.1, which doesn't work in a container; but it proves that it did configure a proxy :)
 * pitti updates it to 10.0.3.1
<jibel> pitti, right, =apt gets the configuration from apt, alternatively you can specify the IP or hostname of your host instead of apt
<jibel> if it is on the same machine
<pitti> ah, hostname sounds like a nice idea, avoids hardcoding the IP
<pitti> so 70proxy is *not* in  /var/cache/lxc/precise/, so lxc-create does create it after copying; but apparently not if it's using a cache
 * pitti files a bug, that doesn't sound hard to fix
<oskie> hello. it seems cloud-init or something is bricking my machines if I set up my own ephemeral...
<pitti> stgraber, jibel: FYI, filed bug 1271455
<ubottu> bug 1271455 in lxc (Ubuntu) "lxc-create does not honor $HTTP_PROXY when using a cached base image" [Undecided,New] https://launchpad.net/bugs/1271455
<pitti> yay, now my host ubuntu, schroots, autopkgtest, and now lxc are all using the same apt-cacher-ng; this thing rocks :-)
<darkxst> pitti, any chance you could take a look at https://code.launchpad.net/~darkxst/ubuntu/trusty/gdm/nokill/+merge/202393
<pitti> darkxst: sure
<darkxst> note debian does not kill gdm in postinst, except in the case where they transition from gdm -> gdm3
<darkxst> thanks
<pitti> darkxst: hm, not in the recent big upload though, it seems? (http://launchpadlibrarian.net/162697567/gdm_3.8.4-0ubuntu2_3.10.0.1-0ubuntu1.diff.gz)
<pitti> darkxst: uploaded
<darkxst> pitti, thanks, that code has been there for a while, but only just started triggering a kill
<TuxBrother> I'm trying to build the suPHP package updated to 0.7.2 with uupdate
<TuxBrother> But it seems the libtool patch is causing the build package command to fail
<TuxBrother> Can someone look into this? 0.7.1 Has an exploit
<mitya57> TuxBrother: try filing a bug :)
<mitya57> Is that an Ubuntu-specific patch?
<TuxBrother> I don't know
<mitya57> What patch then?
<TuxBrother> http://www.suphp.org/Home.html < FYI The patch: 02_libtool.dpatch in debian/rules/patches
<TuxBrother> mitya57: Do I need to post the contents on pastebin?
<mitya57> TuxBrother: Err, what package is that patch in? Is suPHP packaged in Ubuntu?
<mitya57> I thought it was not.
<mitya57> Ah, it is, let me look then.
<TuxBrother> mitya57: Any luck so far?
<mitya57> TuxBrother: https://launchpad.net/ubuntu/+source/suphp/0.7.2-0ubuntu1
<TuxBrother> Great1
<TuxBrother> mitya57: Any chance to see this backported to precise?
<mitya57> TuxBrother: please file a bug first.
<mitya57> Then I'll attach a debdiff for security team review.
<mitya57> TuxBrother: http://paste.ubuntu.com/6797026/ â this is the relevant part of the diff, right?
<TuxBrother> mitya57: I'm not a developer, only a sysop
<TuxBrother> I will file a bug report later today
<mitya57> OK, feel free to subscribe me (~mitya57) there
<mitya57> zyga: Any reason why you plainbox autopkgtest is redirecting output to /dev/null? It makes it harder to figure out what happens.
<mitya57> Also, maybe you are going to fix the failure yourself? :)
<zyga> mitya57: my ignorance while writing the initial tests, it's on my TODO list, just swamped with other tasks
<zyga> mitya57: it prints to stderr and I just need to add that flag to make that safe
<zyga> mitya57: if you remember how to do it could you please fix it in debian SVN? I'll make my life easier with the next release
<zyga> it'll
<mitya57> zyga: OK, actually I've already found the failure and am looking at that
<zyga> mitya57: what is the failure?
<mitya57> FAIL: test_perfect_match (impl.exporter.test_html.HTMLExporterTests)
<mitya57> ----------------------------------------------------------------------
<mitya57> Traceback (most recent call last):
<mitya57>   File "/usr/lib/python3/dist-packages/plainbox/impl/exporter/test_html.py", line 142, in test_perfect_match
<mitya57>     self.assertEqual(self.actual_result, expected_result)
<zyga> mitya57: hmm, interesting!
<mitya57> (LOTS of HTML output below)
<zyga> mitya57: can you pastebin that somewhere? alternatively, can you open a bug on lp:checkbox with that output?
<mitya57> Will do
<smb> infinity, something for your "amusement" (as you seem to be touching eglibc quite often): bug 1271534
<ubottu> bug 1271534 in eglibc (Ubuntu) "libc6-xen:i386 installation can cause panics on boot" [High,Confirmed] https://launchpad.net/bugs/1271534
<mitya57> Let me try assertMultiLineEqual first
<zyga> mitya57: many thanks!
<zyga> mitya57: perhaps self.maxDiff = None will help
<mitya57> Ah, that is bytes, not str, so assertMultiLineEqual doesn't much help
<mitya57> zyga: filed bug 1271542 and attached output there
<ubottu> bug 1271542 in checkbox "Plainbox self-test failing on test_perfect_match" [Undecided,New] https://launchpad.net/bugs/1271542
<zyga> mitya57: thanks, we'll take it from there
<zyga> mitya57: I love how launchpad renders graphics in that log :)
<mitya57> Yes, my Firefox also thinks it's HTML file ;)
<zyga> mitya57: yeah, that test is checking our our HTML inliner injects various resources
<zyga> this might be a security issue, we probably can inject js into launchpad.net domain and do XSS
<mitya57> zyga: here's the first non-matching lines: https://launchpadlibrarian.net/163098330/plainbox.diff
<zyga> mitya57: ohhh
<zyga> mitya57: I just did the same :)
<zyga> mitya57: thanks :)
<zyga> mitya57: yeah, I wonder why that happens, I cannot reproduce that failure
<mitya57> I also can't reproduce it locally, but can in trusty chroot
<zyga> I meant in trunk, I'll check out that debian release though, this is curious
<zyga> or better, I'll let roadmr do it, I'm busy wity something else :/
<zyga> mitya57: ideally we'd re-render those images and see what they really look like
<zyga> mitya57: do you know how to do that?
<mitya57> They look the same
<zyga> mitya57: hmm, maybe base64 is somehow not deterministic? (though that would be odd)
<zyga> mitya57: like some junk or seed?
<mitya57> Just copy-paste the data:... URI into the adress bar
<zyga> oh!
<zyga> good idea
<mitya57> No, base64 is deterministic :)
<zyga> mitya57: maybe different encodings are possible? python has b64 and standard_b64?
<zyga> mitya57: theory, the images are the same, the encoding has junk in both versions, that junk is not used by the the png decoder, the junk is a reused buffer of some kind?
 * mitya57 looks
 * zyga looks at the source
<mitya57> zyga: I think when you encode PNG, it is in bytes, not in unicode, so encoding shouldn't matter here
<zyga> mitya57: encoding as in "this is how png bitstream looks like"
<zyga> mitya57: maybe there's fixed-lenght buffer and the stuff "afte the end" of the real data is irrelevant
 * zyga imagines interesting data injection capabilities in "identical" PNGs
<zyga> the part that converts a file to data URI looks sane to me
<mitya57> zyga: No, the images are not equal. I can spot "Created with GIMP" comment in the second one but not in the first one
<zyga> ohhh
<zyga> wow, cool
<zyga> so somehow, the images got changed
<mitya57> Ah, pngbinarymangler
<zyga> I wonder when that happened, everything that lands to trunk runs the full test suite
<zyga> !!!
<mitya57> *pkgbinarymangler
<zyga> cool :D
<zyga> why does it do that?
<zyga> I mean, why does it strip the comment
<mitya57> In Ubuntu all PNGs are stripped
<zyga> hmmmm
<zyga> I see
<mitya57> I think there is some env variable to disable that
<zyga> interesting, thanks for solving this bug then
<zyga> mitya57: I'll add this to the bug report
<mitya57> zyga: export NO_PNG_PKG_MANGLE=1 in debian/rules should fix that
<zyga> mitya57: interestingly, we also run the test suite at build time, but obviously adt runs it after the build, that's really tricky thing to find
<mitya57> Should I commit that to SVN?
<zyga> mitya57: do you want to patch it in svn?
<zyga> mitya57: yes please!
<zyga> mitya57: if you can, do a changelog and I'll ask our sponsort to release it
<zyga> changelog bump
<mitya57> zyga: feel free to ask p1otr now :)
<zyga> mitya57: thanks, just sending email
<zyga> mitya57: thanks a lot, you fixed that instantly :)
<mitya57> zyga: You are welcome :)
<xnox> ev: bdmurray: cjwatson: looks like 12.04 installer still has the "creepy" webcam step, which was removed in raring and up. Should the webcam step be removed / disabled for 12.04.4, or let it be.
<xnox> stgraber: ^
<cjwatson> xnox: I don't like it, but I would let it be at this stage
<cjwatson> Maybe a month or two ago ...
 * zyga liked the webcam step
<zyga> why did we think it's creepy?
<brendand> zyga, because photographs steal your soul
<zyga> brendand: that's okay, we sold ours to get the mortage ;)
<brendand> zyga, and ubuntu installer photographs assign copyright of your soul to canonical
<xnox> brendand: don't spread rumours.
<zyga> even better, after sending my photo to facebook, google and amazon I really need canonical to own a copy ;)
<ev> xnox: creepy? :(
 * zyga mutters something about CLA, photos and forking
<zyga> and gets back to wokr
<xnox> zyga: creepy, cause you get to see your own face whilst installing ubuntu =) (and apw used that term) but in fact it's mostly useless as the pics didn't actually propagate anywhere.
<xnox> (and places it did propagate to, got removed / changed since webcam introduction)
<zyga> xnox: yeah but that's not the reason not to use it, my only complaint was that the "live feed" was much brighter, more naturally exposed, than the picture it took, but I guess that's related to video/still pic transition
<zyga> xnox: I'd love if it could be my u1 user photo and if u1 had more features around users later
<brendand> and SSO for login!
<zyga> brendand: yeah
<hallyn> jodh: regarding unusable kvm for you;  kvm really works splendidly on both my amd and intel based trusty laptops;  can you bring the laptop you're having trouble on next week so I can take a look?
<pitti> ogra_: hey Oliver, how are you? do you have a sec for an arm kernel install question?
<ogra_> pitti, sure, shoot (and i'm fine)
<pitti> ogra_: so, I dist-upgraded a raring arm calxeda node in the lab from raring to saucy
<pitti> ogra_: it didn't come back when booting, so I suspect it might not like the 3.11.0-15 kernel
<pitti> ogra_: I did the same upgrade to another node, but didn't reboot yet
<pitti> ogra_: I'd like to tell the boot loader to boot with the raring kernel
<pitti> ogra_: I suppose I'll change the symlinks in /boot (vmlinuz, initrd.img) to point back to the 3.8 raring kernel
<ogra_> pitti, ah, i havent dont much with server recently ... usually flash-kernel should do the right thing though ...
<pitti> ogra_: is there something I need to runa fter that, like flash-kernel?
<ogra_> pitti, try dannf or rbasak
<jodh> hallyn: are you referring to bug 1268906 or bug 1257352? The former kernel issue occurs on 2 systems I have. I'll be bringing one with me.
<ogra_> pitti, the package postinst should have run flash-kernel
<pitti> ogra_: ack, talking to rbasak
<ubottu> bug 1268906 in linux (Ubuntu) "cpu soft lockup running kvm" [Medium,Confirmed] https://launchpad.net/bugs/1268906
<ubottu> bug 1257352 in qemu (Ubuntu) "kvm hangs occasionally when switching out of the qemu console" [Medium,Confirmed] https://launchpad.net/bugs/1257352
<pitti> ogra_: right, but I suppose that flashed 3.11 (saucy kernel) on dist-upgrade
<ogra_> yeah
<ogra_> pitti, i remember a bug where flash-kernel forcefully always flashes the latest kernel ... newer f-k versions use linux-version for that iirc
<hallyn> jodh: the former
<jodh> hallyn: right. It's entirely repeatable with every image I throw at kvm.
<ogra_> pitti, you might need to remove the 3.11 kernel completely and then run f-k manually
<pitti> ogra_: ah, might be safer
<ogra_> (make sure to clean up /boot manually, iirc there is stuff left behind)
<pitti> ogra_: ah, it also seems that it wasn't due to the kernel but due to a net interface problem
<ogra_> oh
<apw> phew, i thought ppisati tested those
<pitti> rbasak, ogra_: FTR, merely changing the symlinks is sufficient; boot.scr has the symlinks and the boot loader reads/resolves those
<ogra_> good
<rbasak> Thanks
 * ogra_ wonders why highbank uses boot.scr though ... dont we use uEnv.txt ?
<rbasak> flash-kernel writes out boot.scr, doesn't it?
<rbasak> That happened when we synced to Debian. Some time around the 12.10 timeframe IIRC.
<ogra_> well, for anda we switched to uEnv.txt long ago
<ogra_> ah, k
<ogra_> so its lool's fault then
<ogra_> :P
<stgraber> pitti: I've never tried that part of the Ubuntu template myself because I use a transparent proxy, but try setting HTTP_PROXY=apt before running lxc-create
<pitti> stgraber: bonjour
<stgraber> pitti: looking at the code, that should query apt-config for the current proxy value and use it for the container
<pitti> stgraber: right, that's what I did at last; works except for said bug
<pitti> stgraber: not quite as my proxy is 127.0.0.1, but HTTP_PROXY=http://`hostname`:3142 worked
<stgraber> pitti: ah yeah, sounds like the proxy stuff isn't done at the right stage of lxc-ubuntu...
<jibel> stgraber, the proxy is set when sources.list is written ie during initial download _or_ if the arch of the host and the container are diffrent
<pitti> stgraber: do you have an idea about http://paste.ubuntu.com/6797756/?
<pitti> stgraber: in particular "confused by argument: armhf"?
<pitti> stgraber: that's from an arm machine
<pitti> which is runnning saucy
<stgraber> pitti: you're running an old version of the cloudimg query tool which doesn't know about armhf
<stgraber> pitti: the same on trusty should work (at least it did last week)
<pitti> stgraber: ok; I'll try upgrading this node to trusty
<pitti> stgraber: or perhaps the cloud query tool first; which package is that?
<stgraber> cloud-image-utils
<pitti> arch: all, how nice
<pitti> stgraber: merci
<zul> doko:  which package needed porting to bs4 again?
<doko> zul, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<zul> doko:  cool thanks
<jodh> hallyn: can we wait until the next upstart release (next week) for a fix for bug 1263738 to land in trusty?
<ubottu> bug 1263738 in lxc (Ubuntu Trusty) "login console 0 in user namespace container is not configured right" [High,Triaged] https://launchpad.net/bugs/1263738
<hallyn> jodh: yeah that's fine
<hallyn> jodh: i wanted it fixed by feature freeze if possible.  containers are useful without the fix
<hallyn> jodh: thanks!
<jodh> hallyn: ok, thanks. shouldn't be a problem as we've fixed it upstream now.
<Noskcaj> infinity, xfce4-weather-plugin 0.7.4-5 is now in s-p-u, is that enough to sync to precise?
<Noskcaj> Is there anything i can do do make my motu application happen faster? It's three weeks since i sent the email
<tumbleweed> Noskcaj: the DMB isn't particularly good at e-mail applications. I'll poke people again
<Noskcaj> tumbleweed, thanks.
<Noskcaj> There's a heap of stuff xubuntu needs uploaded, and not many sponsors.
<jtaylor> Noskcaj: just saw you want to merge xfwm4
<jtaylor> is that a stable release?
<jtaylor> its not mentioned on their homepage
<jtaylor> they might be using old gnome versioning, odd unstable, even stable
<jtaylor> so we probably don't want .11 in trusty
<Noskcaj> jtaylor, We try ro use the old gnome versioning, but everything is very stable anyway and contains stuff we need for xubuntu
<Noskcaj> 4.11 is mostly the same as 4.12, just 4.12 has to have everything released at once, but panel isn't fully ready
<jtaylor> when is it expected to be ready?
<Noskcaj> jtaylor, No one really knows. Probably before trusty's final release, probably not before feature freeze
<infinity> smb: Ew.  Stop flipping your dom0 from Xen to bare metal.
<infinity> smb: (But yes, good catch.  I wonder why no one else has noticed this for years...)
<Noskcaj> robert_ancell, Any chance you could do the packaging for lightdm (and greeter) in debian? We've got a pointless duplication of work currently
<robert_ancell> Noskcaj, no, I want to release fast into Ubuntu. You can copy changes into Debian
<Noskcaj> ok. debian is pretty fast to upload though
<infinity> smb: So, that's probably something I should fix in Debian but, also, worth noting that you don't need libc6-xen on Ubuntu at all, our default i386 flavour is also built with -mno-tls-direct-seg-refs
<infinity> smb: (In other words, we shouldn't ship libc6-xen in Ubuntu at all, and I'm trying to decide if it's worth coming up with a migration plan to make that more obvious)
<Unit193> Meh, since I was updating the packaging for myself, it was trivial to generate the merge too: https://unit193.net/dropbear_2012.55-1.4ubuntu1_dropbear_2013.60-1ubuntu1.debdiff  https://unit193.net/dropbear_2013.60-1_dropbear_2013.60-1ubuntu1.debdiff
<smoser> ok. so in live-build, i have a package-lists/ubuntu-cloud that works for 12.04-13.10.
<smoser> but in trusty, i want to *not* include the 'Task' of 'server^'.
<smoser> anyone know how to put logic like that in there:
<Noskcaj> jtaylor, Are you able to sponsor xfwm4?
<smoser> ok.
 * seb128 wonders wth with dch in trusty
<seb128>  $ dch -i "Rebuild for the new poppler soname"
<seb128>  $ dch -r
<seb128> -> gives "the" as a release
<seb128> $ dch -i "Rebuild"
<seb128> -> works fine
<seb128> does anyone see anything wrong in there? (or feel like debugging dch? ;-)
<dobey> https://ubuntuone.com/3vkRPzVaPpF8p6xferyRnT <- wtf. why i am on a vt with a mouse cursor, and unable to get back into my running xorg session, which btw, is still responding to presses of the multimedia keys?!
<Laney> bahaha
<dobey> happened during dist-ugprade, i think during configuration of the new kernel. my screeens just went dead but X was still running, and i could still control rhythmbox with my keyboard
<Laney> seb128: check /usr/bin/dch line 1375
<seb128> Laney, shrug, is that a feature?! (and how did you debug that? ;-)
<Laney> sk1llz
 * seb128 is impressed by Laney p0wers
<Laney> yeah I can trace perl code, that's why they pay me the big bucks
<seb128> hehe
 * seb128 notes to recommend that Laney gets more bucks in the next review
<Laney> :>
<Laney> I wonder if anyone even knows that feature exists any more
<Laney> on the other hand, you now know how to work around it ...
<Laney> desire to patch... slipping...
<seb128> Riddell, could you get calligra rebuild for the new poppler soname change? (there is one small api change, http://cgit.freedesktop.org/poppler/poppler/commit/?h=poppler-0.24&id=ebe49d597a62aa94601c2e4595dbad1895ea7ef0 ... it's not likely it requires change but it would be good to test build still)
<seb128> slangasek, it would be nice if you would fwd you upgrade fixes to Debian ;-)
<slangasek> seb128: if you mean mutter, the new upstream version was a -0ubuntu1 change...
<seb128> slangasek, no, it just made me think of https://launchpad.net/ubuntu/+source/harfbuzz/0.9.24-2ubuntu2 which is our only diff on that source (crossed that this week because we were a version behind and it's our only diff and it's not forwarded)
<slangasek> seb128: ah, ok.  yes, that should be forwarded; I'm just getting a little tired of having to garden these kinds of issues in libraries in Ubuntu, because they break update-manager in the devel series, which means either nobody's using update-manager or nobody minds being prompted about partial upgrades
<slangasek> so my motivation to forward these to Debian, who aren't affected by this update-manager code, is low
<seb128> can we fix update-manager if the issue is limited to it? (or would it affect and "apt-get update" upgrade as well?)
<seb128> slangasek, well, I would be fine fixing some of those/forwarding them if I understood the issue enough to explain the impact in a bug fwd to Debian (or is that just a "it's how it should be done")?
<seb128> slangasek, (and yeah, I've to admit I'm one of those who don't pay attention to the partial upgrade dialog during unstable serie because we have enough transitions happening that's not un-usual, even if we didn't have bugs)
<slangasek> seb128: yeah, the issue is update-manager knows what Conflicts/Replaces means and will accept removing a package for that reason, but Breaks/Replaces (or Conflicts without Replaces) means something different according to policy so won't silently allow it
<seb128> slangasek, I see
<slangasek> so yeah, long explanation for a patch that doesn't make any practical difference in Debian
<seb128> having to maintain the diff/rebase is annoying as well
<seb128> not sure that's worth the diff in fact, it only impact users who follow unstable and updated before that version
<seb128> those changing series now are going to dist-upgrade anyway
<seb128> so it could be dropped?
<seb128> well, it doesn't hurt to keep that one until the LTS...
<seb128> on that note, calling in a day
<seb128> good night everyone
<Laney> I usually commit those if I see them and can
<Laney> as I did do for harfbuzz, IIRC
#ubuntu-devel 2014-01-23
<slangasek> Laney: ah, kudos :)
<Noskcaj> robert_ancell, is it ok with you if i prepare light-locker 1.1 for trusty?
<robert_ancell> Noskcaj, sure
<Noskcaj> Can someone explain what i have to do to fix http://paste.ubuntu.com/6800659/ ?
<sarnold> hey jackson_, you didn't miss any replies while you were timedout
<pitti> Good morning
<dholbach> good morning
<smb> infinity, Apparently I, too do not switch back and forth enough. Trusty was was the first time I realized the issue. To be honest, I did not really do much with i386 and Xen (before trying to figure out how to cope without the i386 HV).
<smb> infinity, And I guess not many other people did, or at least stick with one side of the force
<smb> infinity, I guess we can probably think about it next week a bit more. I am not minding not having libc-xen if it does make no difference
<infinity> smb: Yeah, it's literally useless in Ubuntu.
<infinity> smb: Might make sense in Debian to roll the functionality into libc6-i686, and get rid of -xen in both distros.
<smb> infinity, True, if I manage to ever get any reply again
<mitya57> dholbach: I like your new name: http://bazaar.launchpad.net/~click-reviewers/click-reviewers-tools/trunk/view/head:/debian/control#L4 :D
<dholbach> haha
<dholbach> mitya57, fixed :)
<mitya57> thanks :)
<infinity> smb: Get a reply from whom?  Me?
<smb> infinity, Not for a change not. :-P More waldi
<infinity> smb: Oh, this has nothing to do with waldi, though.  I just need to confer with the other debian glibc maintainers, and then drop libc6-xen, which seems like the right thing to do, IMO.
<smb> infinity, Ah well then. So changing Xen would be a necessity after :)
<dholbach> davidcalle, happy birthday!
<davidcalle> dholbach, thanks :)
<doko> rbasak, ruby-rgen MIR required (puppet recommends it)
<doko> rbasak, and can you make puppet using ruby2.0 by default?
<rbasak> doko: noted. I created bug 1271857 earlier but I need to fill it out.
<ubottu> bug 1271857 in ruby-rgen (Ubuntu) "[MIR] ruby-rgen" [Undecided,Incomplete] https://launchpad.net/bugs/1271857
<rbasak> Not sure about ruby2.0. That seems like a big ask until upstream switch.
<doko> ahh
<zequence> Hi. Need a sponsor to upload lp:ubuntustudio-default-settings to fix lightdm bug #1259525
<ubottu> bug 1259525 in ubuntukylin-default-settings (Ubuntu) "Lubuntu & Xubuntu & Ubuntu Kylin lightdm session fails to start. user-session is not set" [Undecided,Confirmed] https://launchpad.net/bugs/1259525
<rbasak> Any quick tips on rebuilding a python module with debugging symbols for debugging purposes? Is there a simple switch somewhere, or do I have to mess with flags manually?
<pitti> zequence: can do
<pitti> zequence: uploaded, and I pushed the dch -rm / release tag to bzr
<zequence> pitti: Thanks!
<rbasak> Answer: CFLAGS and DEB_BUILD_OPTIONS=nostrip did the trick.
<rbasak> cjwatson: could you add src:libvirt-python to the server packageset, please?
<cjwatson> rbasak: I no longer have the power.  Ask the DMB
<rbasak> Oh, OK. Will any DMB member do? Or do I need to ask the DMB formally?
<cjwatson> Probably just any member.  But I also haven't properly handed over the scripts yet (was planning to sort that out with somebody next week) so you might need to mail them.
<cjwatson> i.e. they won't yet have anything they can commit the exception to
<xnox> rbasak: people email devel-permissions mailing to add packages to packagesets. (spotted those in the past for like input-methods packageset, and others)
<xnox> list.
<cjwatson> xnox: the autogenerated packagesets are special.
<cjwatson> not part of the same process
<xnox> cjwatson: oh.
<rbasak> I'll email the DMB seeing as it sounds non-trivial. Thanks!
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 1 released! | Archive: alpha 2 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: dholbach
<jamespage> rbasak: I thought the server packageset was automagically generated
<cjwatson> jamespage: it is, there's a list of exceptions
<rbasak> jamespage: it is, but AIUI if other seeds also pull in server packages, then the packages don't get attributed to server, and thus don't end up in the packageset. Or something like that.
<cjwatson> it would probably be best for the DMB to run an auto-refresh first and then see whether the package in question is in a further-in seed than server
<cjwatson> s/seed/packageset/
<rbasak> I emailed the DMB: https://lists.ubuntu.com/archives/devel-permissions/2014-January/000576.html
<rbasak> Many (most?) packages I uploaded hit this issue. I try and ask rather than get every one sponsored - hopefully then future ubuntu-server uploaders won't be affected as much.
<markav> Hello, can someone help me. My application (Commericial) on ubuntu software center pending review for a week. given the usual?
<ogra_> markav, ask in #ubuntu-app-devel
<markav> thx
<seb128> hum
<seb128> https://launchpadlibrarian.net/163197609/upload_5491603_log.txt
<seb128> does anyone knows what happened there?
<seb128> libreoffice build failed to upload on i386
<seb128> is there a way to retry upload or do we need to retry a full build?
<cjwatson> seb128: it's transient bad luck, I'm afraid you have to retry
<cjwatson> the whole thing
<seb128> cjwatson, ok, thanks :/
<cjwatson> sometimes the librarian server fails to respond properly, I don't know why
<seb128> sorry for the buildd DoS people ;-)
<cjwatson> AIUI that's basically "Server said: <EOF>"
<cjwatson> we're not short of x86 buildd resources at the moment
<seb128> good
<mdeslaur> doko: mind if I merge nss?
<doko> mdeslaur, not at all
* Riddell changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 nearly 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
<mdeslaur> doko: thanks
<xnox> ChickenCutlass: cmake in trusty is now fixed again, and correct cross-compiler is used. So powerd now can cross-compile, sans 's/python/python:any/' change.
<ChickenCutlass> xnox, fantastic, thanks
<xnox> ChickenCutlass: https://code.launchpad.net/~xnox/powerd/ftxbfs/+merge/202891
<jodh> xnox: can we now safely re-enable abi-compliance-checker for upstart?
<ChickenCutlass> xnox, great
<xnox> jodh: once it propagates from debian -> trusty, yeah
<jodh> xnox: what version do we require then? the changelog suggests 1.99.8-1 would work?
<dholbach> more sponsoring tomorrow
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Trusty Tahr Alpha 2 nearly 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:
<juliank> doko: I'm wondering why you changed the apt package to install the APT binary. I mean, it was not an oversight not to include it in the package.
<doko> juliank, talked with mvo about it. should go in before ff
<juliank> doko: OK, thanks.
<jtaylor> I found a fun way to break your amd64 system today: apt-get install libc6-amd64; apt-get remove libc6-amd64
<jtaylor> no more lib64/ld.so = broken system
<Laney> known
<jtaylor> k, didn't find a bug in lp
<Laney> I was under the impression that it was fixed
<Laney> I only know of https://wiki.ubuntu.com/Touch/Emulator#A.2BAC8.21.2BAFw_If_you_are_on_amd64
<jtaylor> I still can reproduce it on trusty
<jtaylor> chroot works fine
<jtaylor> to reproduce it
<xnox> jtaylor: yes, it is known.
<xnox> Laney: no it wasn't fixed, it's just emulator was taught to not have libc6-amd64 dependency.
<Laney> yeah I see
<xnox> jtaylor: the bug is against libc6 in debian I believe, as it affects it there as well.
<Laney> didn't really follow it
* Riddell 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:
<Noskcaj> Can someone please sync weather-plugin for bug 1244629 ?
<ubottu> bug 1244629 in xfce4-weather-plugin (Ubuntu Precise) "SRU xfce4-weather-plugin, currently showing 'No Data'" [Undecided,In progress] https://launchpad.net/bugs/1244629
<Noskcaj> It needs to be fixed in time for the point release of precise
<brendand> hi, we want to replace the checkbox-qt package with checkbox-gui which will provide the same functionality, but with a different implementation. does this in any way affect the process to get checkbox-gui into universe or do we need to follow the same process?
<brendand> replace as in dpkg Replaces: checkbox-qt
<tedg> So I'm having some trouble trying to get some Python bindings into a package.
<tedg> The branch I'm trying to do is here: https://code.launchpad.net/~ted/+recipe/babeltrace-daily-python
<tedg> But it's causing stuff to be put in site-packages
<tedg> and it seems like I need dist-packages?
<tedg> Oops, that's not the branch :-)
<tedg> https://code.launchpad.net/~ted/babeltrace/python-binding-packaging
<kentb> can I get someone to review and sponsor a fix for:  https://bugs.launchpad.net/ubuntu/+source/wsmancli/+bug/1272059?
<ubottu> Ubuntu bug 1272059 in wsmancli (Ubuntu) "wsmancli needs to be rebuilt against openwsman-2.4.3" [Undecided,Confirmed]
<infinity> kentb: Versioning the build-dep isn't really necessary.
<kentb> infinity: ok. I can change that.
<infinity> Might also be nice to know *why* the ABI broke for libopenwsman1 before just blindly rebuilding things, but meh...
<Noskcaj> infinity, Is s-p-u enough to sync xfce4-weather-plugin? bug 1244629
<ubottu> bug 1244629 in xfce4-weather-plugin (Ubuntu Precise) "SRU xfce4-weather-plugin, currently showing 'No Data'" [Undecided,In progress] https://launchpad.net/bugs/1244629
<Noskcaj> I've found a few people willing to test
<infinity> Noskcaj: Looks like we don't import proposed-updates.
<Noskcaj> ok. Should i make a merge now instead?
<infinity> kentb: Generally, when you've broken ABI in a library, you've done something wrong...
<kentb> infinity: anything I can read over that'll help me root that out or figure out what got busted?
<infinity> kentb: http://paste.ubuntu.com/6804964/
<infinity> kentb: What's busted is that you should have changed the package name to libopenwsman2
<kentb> infinity: ok. got it. thank you.  so the 'right' way would be to fix that in libopenwsman then also change the build dep in wsmancli?
<infinity> kentb: *then* the rdeps need no-change rebuilds to depend on the newer package.  But at least you could then have done it without panicking. ;)
<infinity> kentb: No need to change the build-dep.
<kentb> infinity: ok. so I'll fix openwsman then
<kentb> err libopenwsman
<infinity> kentb: Don't forget to update all the references in the openwsman packaging too.
<kentb> ok
<infinity> kentb: And to smooth upgrades over your breakage, you might want libopenwsman2 to "Replaces: libopenwsman1 (= 2.4.3-0ubuntu1)"
<infinity> kentb: Which you can drop later in the cycle, or in 14.10.
<infinity> (That wouldn't have been necessary without the screwup, since lib1 and lib2 shouldn't actually have file overlaps, ever...)
<mwhudson> soo
<mwhudson> after x does that "eating the font bitmap cache" thing
<mwhudson> is there a way to reset it short of restarting?
<kentb> infinity: ok. just to make sure it's 1) fix the package name 2) add the "replaces" line 3) all references in the control file to libopenwsman1 need to be changed.  is that right?
<infinity> kentb: Should do.  You'll need to rename debian/libfoo1.* to libfoo2.*
<infinity> mwhudson: "Have you tried turning it off and on again?"
<dobey> anyone have any recommendations for how to use multiple build systems during the same build in debian/rules? have a project that is transitioning from autotools to cmake, and now i need to install some stuff with cmake. i already have overrides for configure/build/test to make sure the new cmake bits and new code don't break, but just doing "make install" doesn't seem like it'll cut it
<infinity> dobey: Override dh_auto_install too?
<kentb> infinity: alright. I'll cook that up now.
<dobey> infinity: right. but i'm not sure what to use for the "make install" itself
<dobey> because if i just do "make install" it'll try to install to /usr/local or something i guess
<infinity> dobey: Well, hard to say without a lot more context, I guess.
<dobey> hrmm, i guess i need to fix the configure state too, to use the right prefix
<infinity> dobey: In theory, your configure (or whatever) should be setting DESTDIR.
<infinity> (Or doing whatever prefixy things make install needs)
<dobey> infinity: https://bazaar.launchpad.net/~ubuntuone-hackers/unity-scope-click/trunk/view/head:/debian/rules is what i currently have
<dobey> infinity: or alternatively, is it possible to do "(cd build && dh_auto_configure --buildsystem cmake)" ? or does dh require running cmake in the source tree?
<infinity> dobey: dh generally expects to be running in the parent of debian/
<Laney> there's a --builddirectory option that might be your thing
<Laney> Haven't used it myself
<dobey> i think i have something that should work now
<jtaylor> can someone provide me with a backtrace of the numpy python-dbg testsuite failure on ppc64el?
<jtaylor> I'm willing to debug it but don't have the nerve now for running qemu (if that even works)
<Laney> dh_auto_* --builddir=build
<Laney> directory, ykwim
<kentb> infinity: here's what I got for openwsman...anything else?:  http://people.canonical.com/~kentb/openwsman.debdiff
<infinity> kentb: Looks good.
<kentb> infinity: ok. thanks. I'll flie a separate bug for that and fix the changelog for wsmancli to just say 'no-change rebuild
<infinity> kentb: Could just track them all on the same bug.
<kentb> infinity: ok. will do that then
<infinity> kentb: If you need a sponsor, I can do them all in a bit.
<kentb> infinity: ok. if you would, please.  I'll let you know when ready.
<kentb> infinity: ok. debdiffs are uploaded.
<infinity> kentb: Refresh my memory on the bug number?  I'll review and sponsor those right now before I get distracted.
<infinity> Well, I'll sponsor the library one, and wait until it's built, and do the other. :P
<kentb> infinity: thanks, it's https://bugs.launchpad.net/ubuntu/+source/wsmancli/+bug/1272059
<ubottu> Ubuntu bug 1272059 in wsmancli (Ubuntu) "wsmancli needs to be rebuilt against openwsman-2.4.3" [Undecided,Confirmed]
<infinity> kentb: Ta.
<infinity> kentb: A no-change rebuild probably shouldn't bump standards-version.  I'll revert that. ;)
<kentb> infinity: whoops, you're right
<infinity> kentb: Oh, hrm, I should have looked closer.  This ships multiple libraries in one package, and only one bumped SOVER.  Ick.
<infinity> kentb: This really should be split.
<kentb> infinity: ok. so new bug and I guess the other stuff with a "1" in the name should be converted over?
<infinity> kentb: Yeah, looking at this, libopenwsman1 (or 2) shouldn't exist at all.
<infinity> kentb: All those libs should be broken out to libwsman1, libwsman-client1, etc.
<infinity> Err, client2
<infinity> kentb: You can still have one bit -dev package that depends on all of the little libs, though.
<infinity> kentb: But shipping all the libs together is a recipe for disaster if upstream doesn't bump SOVER on all of them together.
<infinity> s/one bit/one big/
<infinity> Glad I did a test build and looked at the output, I guess.
<kentb> infinity: lovely...ok. so what did you see in the output that allowed you to catch that?
<infinity> kentb: I just looked at the package contents listing vomit at the end of sbuild.
<infinity> kentb: "less foo.deb" would have worked as well.
<infinity> kentb: But, basically, a bunch of libraries in a single package is generally only sane if you have an upstream guarantee that they'll always have lockstep SONAMEs.
<infinity> (Or if you're libc, and get to be a unique snowflake about the dynamic linker)
 * Snow-Man is a whole collection of unique snowflakes.
<infinity> Snow-Man: Do you highlight on "snow"?
<Snow-Man> maybe?
<Snow-Man> :D
<slangasek> he highlights on infinity; he's your Internet Friend
<Snow-Man> hahaha
<infinity> Overly-attached Snow-Man?
<infinity> Also, it's that time of year again: http://www.youtube.com/watch?v=LDWJn3IwiaM
<teward> anyone seen xnox or knows when they'll be alive?
<Snow-Man> I love that when she says 'blood is red' the advertisment that came up was 'PHP'
<Snow-Man> â¦ followed by 'JAVA'
<infinity> Snow-Man: PHP is the blood, Java's the bruises?
<infinity> teward: He's on London time, so probably escaped work hours ago.
<teward> infinity: ah, i see.  meh, he's got enough pings elsewhere, he'll probably see them when he connects.
<Snow-Man> infinity: that's certainly been my experience..
<kentb> infinity: so, pretty much anything with a unique library name under /usr/lib needs a package?
<slangasek> kentb: unless there's some very specific reason to believe the sonames will change in lockstep, yes
<kentb> slangasek: ok. got it. I'll work on this tonight, then and then have someone review it tomorrow
#ubuntu-devel 2014-01-24
<Logan_> Noskcaj: If a Debian (or Ubuntu) UDD branch is broken, you can use grab-merge to do it traditionally.
<Logan_> (re: your comment on rygel on MoM)
<Logan_> If it's too much of a pain to generate the proper debdiffs for a merge bug (believe me, I don't even bother), let me know, and I can just upload a merge.
<Noskcaj> Logan_, Could you? It's as much effort to review rygel as it is to merge
<Logan_> Sure.
<Logan_> Just keep the patch, right?
<Noskcaj> yep. thanks
<Logan_> No worries. Feel free to ask me to do it in those kinds of situations.
<Noskcaj> Should only be a few more days before i get MOTU anyway.
<Noskcaj> I'll just have to try and wake up early on monday, since applying by email doesn't work
<Logan_> Noskcaj: There's some weird thing going on with quilt.
<Logan_> I'm perplexed.
<Noskcaj> Is it possible to have a package dropped from main?
<Noskcaj> xchat-gnome, xchat-gnome-indicator, and xchat-indicator in this case
<Noskcaj> xchat-indicator is seeded in xubuntu and studio, the other two in nothing
<Noskcaj> They have no main reverse-depends
<Logan_> Noskcaj: Yes. For an example of a bug for demotion to universe, see Bug 1243235.
<ubottu> bug 1243235 in libav (Ubuntu) "Please demote libav to universe" [Medium,Fix released] https://launchpad.net/bugs/1243235
<Logan_> Just subscribe ~ubuntu-archive.
<Noskcaj> ok
<pitti> Good morning
<Snow-Man> morning. :)
<Orrin_Fox> Hello there everyone.
<Orrin_Fox> so I was thinking of helping out with ubuntu core.
<Unit193> mvo: Poooooke. :)
<dholbach> good morning
<dbarth> doko: hey, good morning
<dbarth> i'm looking for some tips to accelerate arm builds and thought you could have some with the packages you're maintaining
<dbarth> do you have a magic formula?
<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
<doko> dbarth, sorry, did skip the dark arts lessons at school
<Laney> slacker
<ogra_> dbarth, cant you do it in universe directly ? the distro builders are faster than the PPA ones
<dbarth> hi
<dbarth> doko: eh ;)
<dbarth> ogra_: well, that's for developer builds, for oxide
<ogra_> dbarth, right ... it wont help you for local builds indeed, but generally the distro builders are a lot faster than using PPAs for uploads
<dbarth> ie, ways to have either a way to cross-build or spread on 2-3 phones to speed tihngs up maybe
<doko> dbarth, isn't chrisccoulson building this anyway in a ppa on a regular basis?
<ogra_> and i dont see a reson why youo couldnt do development uploads to universe, given we expect oxide to be ready by release
<dbarth> doko: he is, but he can't wait on the ppa to do his own development, as its a 10h round trip every time
<dbarth> ogra_: how faster are they? ie, if ppa builds take 10h or so
<dbarth> can that be a 3 or 4x factor?
<ogra_> PPAs = pandas ... (or even qemu builders) ... distro builders = highbank ... iirc 4x faster than panda
<dbarth> hmm
<dbarth> sounds interesting indeed
<chrisccoulson> ogra_, which ones are used for canonical-arm-dev/ppa?
<dbarth> do you have one of those to loan? ;)
<ogra_> chrisccoulson, pandas
<dbarth> hey chrisccoulson
<chrisccoulson> dbarth, i might have cross-builds working next week anyway ;)
<ogra_> c-arm-dev is a non virtual PPA ... these are all pandas
<ogra_> public PPAs are qemu iirc
<cjwatson> We have no panda builders any more
<cjwatson> Thank goodness
<ogra_> oh then c-arm-dev is also qemu
<cjwatson> The non-virtual PPAs are Calxeda nodes
<cjwatson> Virtual ARM PPAs are qemu-user
<cjwatson> canonical-arm-dev is devirt, so builds on Calxeda
<ogra_> oh, i thought we held back calxeda for PPAs
<cjwatson> No
<ogra_> ok
<ogra_> dbarth, then my statement is moot, sorry
<cjwatson> Don't use Pandas for building even if you do find one under a rock
<chrisccoulson> i guess that means 12 hours is about as fast as we're going to get
<doko> dbarth, afaik he is using the non-virtualized ppa's. the last time I looked at least qt didn't use parallel builds, so that would be the first thing to improve if hd didn't already
<cjwatson> I would expect Calxeda (e.g. canonical-arm-dev) to be lots faster than qemu-user in virtual PPAs
<ogra_> chrisccoulson, right ...
<cjwatson> ogra_: you'd probably notice if we were still building things on Pandas, because you'd be seeing random one-bit errors in builds
<ogra_> yeah, i gave up building on pandas ages ago ... chromebook FTW :)
<ogra_> USB 3.0 ++
<dbarth> and distcc,icecc,whatevercc?
<dbarth> i mean chris could spawn 1-2 cloud instances to get more cores to crunch the build
<dbarth> dev. builds, not necessarily ppa builds
<cjwatson> if you happen to have an ARM cloud in your back pocket then by all means ...
<dbarth> cjwatson: i imagined the cores would run a cross gcc/g++
<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:
<cjwatson> dbarth: I would expect that cross-building would be significantly faster already without having to bother with distcc etc.
<dbarth> ok
<dbarth> well chrisccoulson let's see when you get cross-builds working then
<dbarth> thanks all for the feedback
<xnox> dbarth: which package?
<xnox> dbarth: looking at lp:oxide - it neither has ./debian/ nor is using CMake
<xnox> dbarth: at the moment, one needs to use at least cmake or autotools-based build-systems to have cross-compilation support.
<xnox> dbarth: is lp:oxide our upstream project?
<xnox> or a fork of something upstream?
<cjwatson> well, or a simple build system where you can just tell it the compiler to use and it gets on with it.  oxide probably isn't a simple enough package for that though
<xnox> cjwatson: looking at lp:oxide it looks like qmake(?!) wrapped around chromium buildsystem.  Oh, I see lp:~chrisccoulson/oxide/cmake looks promising.
<xnox> looks like chromium / oxide / cmake should be easy, just needs a few exports for arm-cross for gyp.
<xnox> https://code.google.com/p/chromium/wiki/LinuxChromiumArm
<lesshaste> hi... I reported https://bugs.launchpad.net/ubuntu/+source/scratch/+bug/1270194 but am a little worried there may be no ubuntu maintainer
<ubottu> Ubuntu bug 1270194 in scratch (Ubuntu) "scratch gives blank page when returning from presentation mode" [Undecided,New]
<brendand> dholbach, hey - sorry to ping you directly, but i have a question about MOTU
<brendand> dholbach, do you know do we still need to go through the process if the package we want in universe replaces one already in universe?
<lesshaste> apt-cache show scratch shows
<lesshaste> Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
<lesshaste> Original-Maintainer: Miriam Ruiz <little_miry@yahoo.es>
<lesshaste> does this mean there is no specific maintainer any more?
<jpds> lesshaste: As is the case with all Ubuntu packages.
<jpds> lesshaste: That bug should be forwarded to the programmer authors.
<brendand> lesshaste, probably pointless to package scratch now
<brendand> lesshaste, scratch have converted to pure web implementation
<brendand> lesshaste, see - http://scratch.mit.edu/
<jibel> pitti, similar problem to espeak with libcups2-dev
<jibel> dpkg: error processing /var/cache/apt/archives/libcups2-dev_1.7.1-2_amd64.deb (--unpack):
<jibel>  unable to move aside `./usr/include/cups/i18n.h' to install new version: Invalid cross-device link
<pitti> meh
<pitti> jibel: from which version? precise/quantal/saucy?
<jibel> pitti, P > T amd64 with all of main
<jibel> bug 1272285
<pitti> jibel: ah, so in precise /usr/include/cups/i18n.h/ was a directory, too
<ubottu> bug 1272285 in cups (Ubuntu) "package libcups2-dev 1.5.3-0ubuntu8 failed to install/upgrade: ErrorMessage: unable to move aside `./usr/include/cups/i18n.h' to install new version: Invalid cross-device link" [Undecided,New] https://launchpad.net/bugs/1272285
<lesshaste> brendand, oh..what about http://scratch.mit.edu/scratch2download/ ?
<brendand> lesshaste, oh i didn't know about that - interesting
<brendand> lesshaste, but that's an air application anyway
<lesshaste> jpds, ok.. I don't know how to forward it to them
<brendand> lesshaste, so i doubt it's equivalent to the debian package
<lesshaste> brendand, you mean it can't be packaged for legal reasons on ubuntu?
<lesshaste> brendand, or that it just hasn't been yet
<jpds> lesshaste: It uses an [old?] platform from Adobe.
<lesshaste> yes... AIR 2.6.0 for Linux
<brendand> jpds, i think air is still actively supported (might be wrong)
<brendand> jpds, although it seems the linux version is not supported
<lesshaste> "Note: Beginning June 14 2011, Adobe AIR is no longer supported for desktop Linux distributions. Users can install and run AIR 2.6 and earlier applications but can't install or update to AIR 2.7"
<lesshaste> http://helpx.adobe.com/air/kb/install-32-bit-air-linux.html
<lesshaste> how annoying :(
<lesshaste> "Adobe's efforts are focused on supporting operating systems that are most important to its customers, and that demonstrate the greatest opportunity for future growth for its partners and developers"
<lesshaste> that is... no more linux
<lesshaste> in any case..2.6 works apparently (http://orkultus.wordpress.com/2013/03/23/installing-adobe-air-2-6-on-64bit-linux-mint-ubuntu/)
<darkxst> lesshaste, AIR was a disaster no matter which way you look at, we arent really loosing anything by not having it
<brendand> lesshaste, adobe don't support ios or android
<Laney> tjaalton: Looks like your adding of libnss3-nssdb broke multi-arch upgrades/installs: libnss3:i386 : Depends: libnss3-nssdb:i386 but it is not installable
<lesshaste> darkxst, it's just a pain that scratch doesn't work
<lesshaste> darkbasic, given that a) it is free b) linux is free and c) it is for kids
<lesshaste> bregma, i have no idea why mit went for this solution
<darkxst> lesshaste, even if it was supported, it still wouldn't work most likely!
<lesshaste> darkxst, why is that?
<tjaalton> Laney: on debian? aiui the current version ftbfs'd on !amd64, since it's racy
<tjaalton> the build
<darkxst> lesshaste, it was always broken
<Laney> tjaalton: ubuntu
<tjaalton> oh i see now
<tjaalton> I'll have a look..
<Laney> it's in trusty release
<Laney> I noticed because dist-upgrade is complaining ...
<tjaalton> well there's also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736061 but it's not clear where the actual bug is
<ubottu> Debian bug 736061 in libnss3 "libnss3: system shared db enabled leads to local overrides being ignored" [Important,Open]
<tjaalton> would Multi-Arch: foreign fix it?
<mitya57> Can somebody please reject mikutter from Saucy SRU queue? I forgot to update the Maintainer field...
<tjaalton> Laney: i'll test that and upload if so
<MacSlow> seb128, there you go ... https://code.launchpad.net/~macslow/notify-osd/notify-osd.fix-1092905/+merge/203047
<seb128> MacSlow|lunch, hey, thanks! let me test that ;-)
<MacSlow|lunch> seb128, :)
<seb128> MacSlow|lunch, enjoy your lunch!
<MacSlow|lunch> thx
<mitya57> pitti: Can you please remove python-imaging autopkgtest? That package has been renamed to pillow.
<pitti> mitya57: I already did a while ago
<pitti> ah, not from public jenkins
<Laney> tjaalton: okay, if it's technically correct to do that (I don't know) then that should work
<pitti> mitya57: yep, I'll file a request, thanks for pointing out
<mitya57> Thanks.
<tjaalton> Laney: aiui it tells that a foreign-arch package fulfills the dep, in this case the libnss-nssdb:amd64 for libnss:i386
<tjaalton> *libnss3:i386
<Laney> yes
<Laney> so it's whether libnss3:i386 can work with libnss-nssdb:amd64
<tjaalton> well
<tjaalton> actually, libnss3-nssdb could probably be arch:all
<tjaalton> since http://stackoverflow.com/questions/15024658/are-sqlite3-databases-are-platform-independent
<dholbach> brendand, is your question resolved?
<tjaalton> meh, it is arch:all
<Laney> You still need the annotation
<knome> seb128, the lp:xubuntu-docs/precise branch seems to be as it should
<seb128> knome, do you have any idea what went wrong there?
<knome> seb128, well, the original bug is fixed... we now have the 12.04 *content*
<knome> seb128, but some image files are missing, and some css files aren't updated
<seb128> knome, I apt-get sourced the precise version and applied the debdiff from the bug on it, then did debuild -S ...
 * knome looks at the debdiff
<seb128> knome, is that a regression? not that diff can't include binary changes, like images
<knome> i was looking for the .css file changes, and it does look like the debdiff is faulty
<knome> seb128, yep, it's a regression
<seb128> knome, ok, well, if you get a non buggy debdiff feel free to ping me and I can sponsor that one
<knome> seb128, i'm not a very technical person myself, but i'll delegate that to somebody; do you want the new debdiff against 11.10.0 or 12.04.0?
<seb128> knome, either works
<knome> seb128, ok, cheers
<seb128> whatever is easier
<Peace-> i would like create a package that will overwirte bashrc from canonical  is there a way to do that ?
<seb128> knome, yw, sorry for not catching those issues before sponsoring
<knome> seb128, np, that happens
<Peace-> i need to do that with skel ?
<tjaalton> Laney: looks like adding M-A: foreign works
<Laney> tjaalton: neat
<brendand> dholbach, no
<dholbach> brendand, ok... so you want to replace a package that is already in the archive
<dholbach> brendand, can you elaborate?
<dholbach> brendand, the package will have the same name but different contents later on? is it like an update? or you add a patch to it? or what exactly happens?
<brendand> dholbach, no it's changing name. checkbox-qt is the existing package. checkbox-gui is the new one
<brendand> dholbach, it will provide the same type of functionality
<brendand> dholbach, different implementation and updated ui
<dholbach> brendand, will it be built from the same source and it's just the binary package (.deb package) name which changes?
<dholbach> ok
<dholbach> sure that's possible
<dholbach> just make the changes in checkbox trunk and ask for it to be uploaded as usual (https://wiki.ubuntu.com/SponsorshipProcess) - basically file a bug with ubuntu-sponsors subscribed
<ggvaberi> hello. Can anyone tell from where gsettings read data? for example icon-theme. where is real database? is it text/xmp data or some binary in cash?
<geser> dholbach: brendand should also add a transitional package (with the old name), right?
<brendand> geser, how does that work?
<brendand> geser, i haven't heard the term transitional package before
<geser> brendand: the old package (checkbox-qt) just depends on checkbox-gui and is otherwise empty. This ease the transition for people who have the old one already installed.
<brendand> geser, oh right
<geser> brendand: see also https://wiki.debian.org/Renaming_a_Package
<MacSlow> seb128, I've pushed a more robust version of the fix... have another look.
<kentb> xnox: is there anything else you need from me to help clean up sblim-sfcc on trusty?
<xnox> kentb: bah, didn't look at your last .dsc yet. Let me diff it and upload.
<xnox> kentb: i think it was all good.
<kentb> xnox: ok. no problem. thanks.
<seb128> MacSlow, thanks, commented on it
<popey> bug 1272338
<ubottu> bug 1272338 in xorg (Ubuntu) "Xorg memory leak on trusty" [Undecided,New] https://launchpad.net/bugs/1272338
<popey> anyone else seeing lots of memory use from xorg on intel?
<popey> i recently upgraded to 16GB in my laptop, glad I did!
<xnox> kentb: uploaded. I really shouldn't read sponsorship request emails on my phone ;-)
<kentb> xnox: heheh. thanks!
<pitti> doko: FYI, py3.4 autopkgtest runs done; raw logs are at http://people.canonical.com/~pitti/tmp/autopkgtest-py34/, I'll analyze them now
<MacSlow> seb128, I digged deeper into the whole defaults_get_top_corner() ... looks like it's just a one-line change after all... please test it again. Looks good here (even desktop-environment neutral)
<seb128> MacSlow, thanks for looking a bit more, let me test that
<seb128> MacSlow, works fine here, and I like that version better I've to say ;-)
<MacSlow> seb128, sure... I knew you can't resist the charms of a one-line change ;)
<seb128> hehe
<MacSlow> seb128, you'll also top-approve it?
<seb128> MacSlow, yes, just giving it a try out of Unity first
<MacSlow> seb128, ah ok sure
<seb128> Riddell, hey, did you see my ping about calligra/needing a rebuild for new poppler the other day?
<Riddell> seb128: yeah I'm onto it now
<seb128> Riddell, thanks ;-)
<Riddell> seb128: there's a new release of calligra I'm packaging and it's a beast of a package so still sorting out the new/removed files
<sergiusens> jamespage, hey, by any chance, will you or did you package launchpad.net/go-dbus/v1 ?
<jamespage> sergiusens, neither I'm afraid
<sergiusens> jamespage, I'll take that then :-)
<jamespage> sergiusens, is your work targetted to ubuntu main?
<sergiusens> jamespage, this one should eventually land in main
<sergiusens> jamespage, it's for phone/touch stuff so yes
<jamespage> sergiusens, well its probably pertinent to talk about go toolchain then
<jamespage> we've been having quite a bit of discussion around that for juju-core -> main this cycle
<sergiusens> jamespage, gcc versus go?
<jamespage> sergiusens, you got it
<sergiusens> jamespage, I'm just using the default tbh; and I saw you did a dual thing
<jamespage> sergiusens, the plan for supporting juju-core is to use gccgo - which is working ok
<jamespage> main driver is server platforms that don't have golang-go support
<jamespage> sergiusens, right now the juju-core package still bundles its dependencies - still not convinced go libraries are stable enough for general release in distro
<jamespage> *that might not apply everywhere....
<sergiusens> jamespage, are you using dh-golang?
<jamespage> sergiusens, no
<sergiusens> jamespage, right; we have dbus-go embedded into our tree currently
<sergiusens> jamespage, but all others I've pushed to debian
<jamespage> sergiusens, yeah - i saw - nice work
<sergiusens> ty
<jamespage> I started on mgo and gnuflags but I'm not pushing that hard due to bundling stuff
<sergiusens> jamespage, ok, I'll check on doing the compiler select with dh-golang
<sergiusens> for libs it's not really important yet luckily :-)
<jamespage> sergiusens, right now is golang-go; I've got a gccgo-go package in progress which provides the go tool built just using gccgo
<jamespage> so the idea is you can swap golang-go for gccgo-go and it *just works*
<sergiusens> that would indeed solve all our problems sans a rebuild if we don't provide both :-)
<pitti> doko: ok, done; I sent the results to u-devel@, you are CCed; https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python3.4 doesn't look too bad, but it's some work
<doko> pitti, thanks. python-csb already always fails with 3.3, aptdaemon is ftbfs in -proposed
<doko> didn't check for the others
<pitti> doko: yes, I didn't file a bug for -csb
<pitti> doko: there are a lot of failures which are unrelated to the -3.4 change
<kentb> can someone please have a look at my debdiff for openwsman to make sure I got transitional packages correct as well as the 'breaks' and 'replaces' directives?  Thanks in advance:  https://bugs.launchpad.net/ubuntu/+source/wsmancli/+bug/1272059/comments/6
<ubottu> Ubuntu bug 1272059 in wsmancli (Ubuntu) "wsmancli needs to be rebuilt against openwsman-2.4.3" [Undecided,Incomplete]
<dobey> anyone else still using evolution? it is *very* crashy on trusty :(
<seb128> tedg is (I thinkÃ 
<seb128> )
<tedg> Yeah, I am.  And it is more crashy.
<dobey> (not to mention the other UX bugs i've already filed against it)
<seb128> dobey, do you file your bugs upstream?
<jtaylor> pitti: how was the py3.4 default test performed?
<seb128> I doubt anyone is looking at evolution bugs for Ubuntu, you probably have a better chance upstream if you want to report issues
<jtaylor> symlinkin py3.3 to py3.4?
<dobey> no, i filed them in launchpad
<dobey> i have no idea if they're upstream bugs or not
<seb128> we have very little distro patching in evo nowadays
<dobey> and for the crashing, i just clicked the "send this error report" button
<seb128> dobey, do you have a link to the error pages for those?
<seb128> https://errors.ubuntu.com/?release=Ubuntu%2014.04&package=evolution&period=month is quite small
<dobey> seb128: no, i never got any link from the apport ui or anything. and i don't know what the traceback was
<seb128> dobey, you can go to gnome-control-center -> privacy, there is a link to your reported errors webpage
<dobey> and my /var/crash is empty
<seb128> though e.u.c summary is not really nice
<seb128> you just get a list ids
<dobey> seb128: i can't do that, because i removed zeitgeist
<seb128> you need to click through to find the ones you need
<seb128> dobey, $browser 'http://errors.ubuntu.com/user/'$(printf $(sudo cat /sys/class/dmi/id/product_uuid) | sha512sum)
<seb128> dobey, that should do it :p
<dobey> well that's empty page
<dobey> thanks a lot apport :(
<seb128> dobey, sorry, xchat-gnome segfaulted
<dobey> seb128: empty page
<mdeslaur> I can't believe how broken this new xchat-gnome is
<dobey> it's almost as bad as evolution, i bet
<seb128> mdeslaur, oh, you found as well?
<seb128> mdeslaur, I'm pondering reverting the update, I didn't have issues for ages with the old one
<mdeslaur> yeah, it's not properly handling the channel positions, it's scrolling windows when loading scrollback, etc.
<mdeslaur> seb128: I would agree with that, this one is _really_ broken to the point of almost being unusable for the time being
<dobey> irssi is your friend
<mdeslaur> dobey: haha, good one :)
<dobey> wtf, i just did ubuntu-bug on a .crash file, and chose "send this error report" but there is no .upload file in /var/crash for it
<seb128> dobey, we didn't re-enable apport yet
<dobey> seb128: then why is it popping up?
<seb128> it's whoopsie which is
<seb128> we didn't enable report to launchpad if you prefer
<seb128> just to e.u.c
<dobey> then where the heck are my "error reports" going?
<seb128> e.u.c
<seb128> dobey, http://launchpadlibrarian.net/153485340/apport_2.12.5-0ubuntu1_2.12.5-0ubuntu2.diff.gz
<dobey> apparently not, based on the product_uuid-based url
<seb128> dobey, revert that change if you want to enable the reporting to launchpad
<dobey> how do i know if it actually made it to e.u.c or not?
<seb128> not sure, that's a question for ev
<seb128> the command I copied earlier wfm
<mdeslaur> ok, that's it... /me switches back to old xchat-gnome
<dobey> seb128: i get an otherwise empty page with it
<seb128> mdeslaur, can you open a bug listing your issues, so we can assign to "Jackson Doak" who did the update
<dobey> just the "Error tracker" at the top and <address> bits at the bottom
<seb128> dobey, yeah, well that's about as much I know about whoopsie/e.u.c, you need ev or bdmurray
<dobey> and nothing in between
<sarnold> mdeslaur: < seb128> mdeslaur, can you open a bug listing your issues, so we can assign to "Jackson Doak" who did the update
<mdeslaur> I did, one sec
<seb128> shrug
<seb128> mdeslaur, the indicator integration is also borked
<mdeslaur> sarnold, seb128: bug 1272455
<ubottu> bug 1272455 in xchat-gnome (Ubuntu) "window scrolling is broken" [Undecided,New] https://launchpad.net/bugs/1272455
<mdeslaur> I think reverting it would be best for now
<mdeslaur> fixing these issues is likely to be a substantial task
<seb128> mdeslaur, yeah, the indicator doesn't clear the count as it should and when you click on a channel with a wrong status it segfaults
<seb128> mdeslaur, do you want to do the revert? just take the previous version and bump the changelog to new+revert
<mdeslaur> seb128: sure
<seb128> shrug
<seb128> it doesn't even scroll correctly to the bottom of a channel when new messages are added
<seb128> mdeslaur, thanks
<bdmurray> dobey: in the upper right hand corner does it say "logged in as "?
<dobey> bdmurray: no
<dobey> now it does, and still empty list
 * mdeslaur chuckles at insane xchat-gnome version
<mdeslaur> 1:0.30.0~git20131003.d20b8d-2ubuntu11+really0.30.0~git20110821.e2a400-0.2ubuntu13
<mdeslaur> lol
<bdmurray> dobey: I'll look at the server logs to see if there is an oops at all.  Does /var/log/syslog show the crash being uploaded by whoopsie?  Is there a .uploaded file corresponding to the crash in /var/crash?
<tarpman> mdeslaur: that must be some kind of record
<dobey> bdmurray: there's no uploaded file, no
<mdeslaur> I'm still thinking about it :)
<bdmurray> dobey: this week I uploaded a new version of whoopsie that fixed when crash files were uploaded (every 2 hours vs immediately)
<seb128> mdeslaur, how that version could be uploaded is behind me
<seb128> mdeslaur, not the version number, but the buggy xchat-gnome code
<seb128> mdeslaur, I'm using it for 15 min and it's already driving me nuts
<cjwatson> I'm still confused at why people think abbreviated git sha-1s are a sensible thing to put in version numbers, given that they are NOT MONOTONICALLY INCREASING
<mdeslaur> If anyone has an idea for a sane version, I'm all ears :)
<cjwatson> if you need a sequence number in case you upload more than one snapshot on the same day, use .1 .2 etc.; if you want to store the git sha-1 somewhere, put it somewhere other than your version ...
<cjwatson> mdeslaur: it's obviously not your fault :)
<dobey> bdmurray: how am i supposed to guess when it will be uploaded exactly?
<xnox> seb128: i've switched to pure xchat with xchat-indicator long time ago. it actually integrates into unity better than xchat-gnome, imho.
<xnox> seb128: poke the uploader about it =)
<bdmurray> dobey: if you restart whoopsie it will do an initial scan for .crash files and upload it then
<seb128> xnox, how so?
<seb128> xnox, the upload is dholbach (sponsoring), the updater has been poked through assigned launchpad bug ;-)
<xnox> seb128: it actually picks up font sizes for me at least =) and messaging menu / (n) on the icon works properly, and i've uploaded useful functional patches to xchat ;-)
<xnox> there is a new fork of xchat as well, haven't tried it yet.
<xnox> xchat is kind of like xemacs 21 ;-)
<seb128> xnox, launchpad/messaging menu integration works fine with xchat-gnome
<xnox> and back then, xchat-gnome was crashing for me a lot =/ whereas xchat is rock-solid for me.
<seb128> I didn't have an xchat-gnome segfault in years
<seb128> well, both options are good ones, choice for everyone ;-)
<mdeslaur> yeah, the last bad one was the copy/paste thingy
<mdeslaur> but I think that's solved now
<seb128> iirc it is
<jdstrand> @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: jdstrand
 * mdeslaur considers (1:0.30.0~git20131003.d20b8d-2ubuntu1+really20110821ubuntu13)
<seb128> mdeslaur, just do "(1:0.30.0~git20131003.d20b8d-2ubuntu1+revert)" ;-)
<dobey> bdmurray: hmm, restarted whoopsie service and still no upload afaict
 * mdeslaur fights with orig tarball
<mdeslaur> seb128: how the heck do I handle the orig tarball?
<bdmurray> dobey: hmm, I'm looking into whoopsie now thanks
<dobey> bdmurray: ok, thanks
 * mdeslaur tries 1:0.30.0~git20131003.d20b8d+really20110821-0.2ubuntu12
<mdeslaur> seb128: uploaded
<kentb> slangasek: (or any AA for that matter) kirkland and I worked on some fixes for wsmancli / openwsman and there are some new openwsman binaries in the trusty upload queue.  If we could get those promoted before Monday that'd be much appreciated. Thanks in advance.
<bdmurray> dobey: thanks again for bringing that up, I discovered the problem
<dobey> bdmurray: is it server side? or client?
<bdmurray> dobey: its apport - bug 1272505
<ubottu> bug 1272505 in apport (Ubuntu Trusty) "chaning MarkForUpload to _MarkForUpload causes crashes never to be uploaded to errors.ubuntu.com" [Critical,Triaged] https://launchpad.net/bugs/1272505
<dobey> bdmurray: ah ok. i'll wait for the update then
<tester56> has anyone an idea how to block a user from recording audio? (disallow access to microphone)
<tarpman> jdstrand: replied to your comment on #976100 (not sure it emailed you, looks like you aren't subscribed)
<jdstrand> tarpman: ack
<jdstrand> @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:
#ubuntu-devel 2014-01-25
<phoenixcoder> hello?
<sarnold> hey phoenixcoder :)
<phoenixcoder> hey sarnold, just finished setting up my irc client so taking it for a test run.
<sarnold> phoenixcoder: oh, nice :)
<phoenixcoder> I guess it's working since you can see this, :-)
<sarnold> indeed!
<sarnold> if you haven't set up certfp yet, that might be a nice next step: http://freenode.net/certfp/ and  http://www.oftc.net/NickServ/CertFP/
<phoenixcoder> okay, I'll see what I can do with that.
<phoenixcoder> So what is this channel about?  The ubuntu channel was a bit vague about what's done here.
<phoenixcoder> ubuntu site*
<sarnold> coordination among packagers, mostly; bug discussion, divvying up work
<phoenixcoder> Is it for community members looking to get involved too?
<sarnold> it sure is :)
<Noskcaj> What is it you'd like to help with?
<sarnold> though at the moment it'll be quiet for a while -- europe is asleep, north america is in the pub, and apac is waking up soon, but it'll be saturday for them when they do :)
<sarnold> oh hey Noskcaj :) just the man
 * sarnold -> dinner :)
<phoenixcoder> That is great (!).
<phoenixcoder> Noskcaj, I thought I'd observe for a while and see what I can help with.
<phoenixcoder> I just got done learning about OS development so I am just starting out.
<Noskcaj> Are there any particular packages you're interested in or skills you have?
<Noskcaj> Our work is mostly split into: Quality Assurance, Packaging, Bug triage, Bug fixing, Translation, and support
<phoenixcoder> No packages of interest yet.  Skills-wise; what would count as a skill for you?
<Noskcaj> Know multiple languages, know programming languages, lot's of experience in a particular area.
<Noskcaj> But you'll learn a lot, trust me
<phoenixcoder> In that case, I know C, Java, C++, and Python.  That's in order of strengths from left-to-right.
<Noskcaj> Then you will do very well.
<phoenixcoder> I hope to learn a lot.
<phoenixcoder> That's the exciting part.
<Noskcaj> If i may ask, what country are you from?
<phoenixcoder> US, East Coast
<Noskcaj> ok, so nowhere near me
<phoenixcoder> And you?
<Noskcaj> Australia
<phoenixcoder> Half a world away.
<phoenixcoder> :)
<Noskcaj> yeah
<Noskcaj> If you'd like to start with some bug fixing, some easy (ish) ones can be found at https://bugs.launchpad.net/hundredpapercuts
<Noskcaj> It's a meta-project for finding simple bugs
<phoenixcoder> Okay, and what do you mean exactly by a meta-project?
<Noskcaj> It's not a real program or code, it just is something you make bugs affect if they are easy fixes
<Noskcaj> And like i said above, if there's a program you use a lot or find interesting, say so.
<phoenixcoder> Okay, sure.  What packages fall into this group's domain?
<Noskcaj> ubuntu-devel is where everyone is. Any package is relevant here.
<Noskcaj> things like #kubuntu-devel or #ubuntu-quality are where you'll find more specific things
<phoenixcoder> Noskcaj and sarnold, thank you for your help; before I get disconnected or logoff.
<Noskcaj> phoenixcoder, No problem. It's always good to see someone new join
<bluesabre> seb128: I've uploaded a fresh debdiff to https://launchpad.net/bugs/1207493 on behalf of xubuntu-team
<ubottu> Ubuntu bug 1207493 in xubuntu-docs (Ubuntu Precise) "[SRU] Documentation does not match shipped system version (11.10 shipped with 12.04)" [High,Fix committed]
<bluesabre> Please take a moment to review it :)
<Logan_> Noskcaj: > Syncable, requestsync not working
<Logan_> Lemme guess who that was. :P
<Noskcaj> :)
<Noskcaj> Wasn't fetching changelogs, and my internet is dropping out more regularly than normal
<Noskcaj> also, mia is syncable, i just don'thave a spare two hours to build it (tried last night)
<Noskcaj> wow, i only have one package on the sponsoring queue
 * Noskcaj begins fixing that
<Noskcaj> Logan_, Can you take a look at syncing rawstudio? provided libgphoto2-dev is acceptable, we should be able to sync.
#ubuntu-devel 2014-01-26
<Logan__> Jackson later
<Noskcaj> thanks
<pvl1> if i want to compile my own kernel, should i use ubuntu kernel source or can i use kernel.org's
<xnox> pvl1: #ubuntu-kernel is a better channel. BTW ubuntu-kernel team provides vanilla ubuntu kernel sources in a daily ppa, you can try those.
<pvl1> thank you xnox
<xnox> pvl1: on wiki.ubuntu.com under kernel team there are instructions on how to compile / use both vanilla upstream and ubuntu-sauce kernels.
<xnox> pvl1: so depending what you need/want there are a few options of prebuild, or compile from source that you can use.
<pvl1> oh wow
<pvl1> google didnt bring that up
<pvl1> rather the first two results
<pvl1> lol
<pvl1> thanks again xnox
 * Logan_ pokes infinity
<Logan_> infinity: could you please look into why v-sim is still failing on ppc64el after an autoreconf at some point?
<xnox> Logan_: checking for netcdf 3 interface... yes
<xnox> configure: WARNING: "No 'netcdf.h' header file, libetsf.so will not be built."
<xnox> Logan_: seems like it all built, but one plugin.
<Logan_> ugh, that netcdf issue is affecting so many packages
<Logan_> I'd love to get to the root of that
<Noskcaj> tumbleweed, Still no progress on my motu application?
<Noskcaj> I'd rather not have to try and be awake in time for the meeting tomorrow
<phoenixcoder> Hi, new person here.  I notice there are people present, but not much chatter.  Just wondering whether there's a reason for that?
<jtaylor> its often quit here during weekends
<phoenixcoder> jtayler, thank you.  Just making sure I didn't have messages blocked.
<infinity> Logan_: configure: WARNING: "No 'netcdf.h' header file, libetsf.so will not be built."
<Logan_> infinity: netcdf-related issues are causing a number of ppc64el packages to FTBFS
<infinity> Logan_: Curious.  libnetcdf-dev contains the right header.  But maybe the configure test breaks.
<Logan_> yeah, I think that's the problem
<Logan_> I'll try to pull up an FTBFS that has a configure.log
<Logan_> *config
<Logan_> pulling up my Ubuntu VM to get rbdeps
<Logan_> infinity: https://launchpadlibrarian.net/162313053/buildlog_ubuntu-trusty-ppc64el.adios_1.5.0-1_FAILEDTOBUILD.txt.gz this one failed with undefined references
<Logan_> well, most of them fail with undefined references
<infinity> Logan_: Hrm.  Could be that netcdf on ppc64el got caught in the middle of some unrelated breakage and misbuilt.  I'll have to play with it in the morning.
<Logan_> should I do a no-change rebuild and see if it fixes it?
<Logan_> I guess I should probably do that locally, not in the repo
<Logan_> although it wouldn't hurt
<infinity> Logan_: I'd rather test a bit more scientifically.
<Logan_> ok
<infinity> Better to understand the problem than just guess, IMO.
<infinity> Logan_: What timezone do you live in?
<Logan_> EST
<infinity> Logan_: Ahh.  Well, I'm on London time now, and just spent the last day in airports.  Can you ping me in 8+ hours as a reminder? :)
<Logan_> I'll be asleep probably
<Logan_> but I can ping you when I wake up
<infinity> Logan_: Works for me.
<Logan_> sweet
<phoenixcoder> Can anyone offer advice on where to put the testing environment?  Right now I'm looking at running 13.10 on vbox vs TestDrive and Chroots based on online documentation.
#ubuntu-devel 2015-01-19
<aeoril> Hello! I am interested in becoming an Ubuntu developer - not apps, but Ubuntu itself
<aeoril> I have bought the book "Tanenbaum, Andrew S.; Bos, Herbert (2014-04-02). Modern Operating Systems (4th Edition). Prentice Hall. Kindle Edition." to start learning OS theory
<aeoril> but it has lots of typos and I am not sure of how accurate it is.  I am interested in low-level stuff, like kernel, module, vm, etc.
<aeoril> What are good resources to get a background in theory to work my way into this type of development?  I have a background in C programming in embedded real time systems and simulation systems, as well as dabbling in Unix/Linux drivers, modules, etc.
<aeoril> kernel, module, drivers, vms, etc*
<aeoril> Note that I am currently reading the Ubuntu documentation on development (based on the link in the topic of this channel).  My question above is more geared toward theory, architecture and design of operating systems such as one might get in a computer science curriculum
<hyperair> what's the equivalent for udisksctl power-off -b /dev/sdb on a machine without udisks?
<hyperair> none of the /sbin/eject modes seem to do the right thing
<pitti> Good morning
<pitti> hyperair: correct, ther is no equivalent; eject is the closest thing to it
<RAOF> pitti: Is a vivid machine booted with systemd expected to be able to shutdown at the moment?
<pitti> RAOF: yes, of course
<RAOF> In a related query, what are the interesting logs when it doesn't? :)
<pitti> RAOF: /usr/share/doc/systemd/README.Debian has a section "Debugging boot/shutdown problems"
<RAOF> Also, systemd dramatically regresses boot speed for me, because it seems to want to write 0s to my 8GB swapfile in /var/cache/swapfile each boot. But that's a simple bug report.
<RAOF> pitti: Ta.
<pitti> RAOF: i. e. enable the debugging shell, shut down, then switch to it, and see which job is hanging
<hyperair> pitti: ugh really
<pitti> hyperair: why "ugh"?
<hyperair> pitti: because there's no proper eject tool aside from udisks?
<hyperair> someone was asking on ##linux about usb_modeswitch
<pitti> eject works fine
<hyperair> and i was trying to get him to manually eject it, but there wasn't udisks so...
<pitti> the "power down the host controller" of udisks does even more, but it's more like a goodie than a required thing
<hyperair> hmm
<pitti> e. g. for ipods and stuff which still warn if you merely eject
<hyperair> kinda odd that we don't have an actual mass-storage eject tool though
<hyperair> you'd think that eject would get that functionality
<hyperair> instead of just doing a cdrom eject
<pitti> what's missing in eject?
<pitti> it doesn't just cd-rom eject
<pitti> it also disconnects USB sticks, SD cards and the like, but just the medium
<hyperair> oh yeah it does a scsi eject, which for some reason isn't the right kind of eject either
<pitti> not the usb host controller
<hyperair> it doesn't actually do a usb disconnect, does it?
<pitti> usb-modeswitch is a special case for 3G sticks and the like
<hyperair> yeah it is
<hyperair> except sometimes it doesn't work, and all that's needed is a simple udisksctl power-off
<pitti> eject doesn't do an USB disconnect, no (as I said); it merely ejects the medium
<hyperair> that's the thing. i was kinda hoping for the usb disconnect stuff
<hyperair> seems to be the kind of eject that usb devices actually expect
<pitti> most of them don't
<pitti> ipods are pretty much the only one I know
<pitti> (bbl)
<hyperair> hmm okay
<darkxst> apw, what is the status of bug 1410480? this completely breaks installing via ubiquity  on Ubuntu GNOME and probably most other flavours
<ubottu> bug 1410480 in linux (Ubuntu) "overlayfs v1: renaming existing file uses chardev whiteout (should be symlink)" [High,In progress] https://launchpad.net/bugs/1410480
<darkxst> and its alpha2 this week as well
<pitti> yes, it's not flavor specific, happens for ubuntu as well
<darkxst> pitti, how did it get though the automated tests then?
<darkxst> hmm ubiquity autopilot tests havent run in 6weeks?
<pitti> apparently yes, then
<dholbach> good morning
<maclin> Hi,  Ubuntu Installer Team,  could someone help to review the merge request: https://code.launchpad.net/~maclin.jun/ubiquity/fix_1304410/+merge/246064
<ngaio> is it reasonable to assume Ubuntu vivid will feature QT 5.4?
<LocutusOfBorg1> hi people!
<Unit193> Howdy.
<LocutusOfBorg1> hi folks, quick question: I'm trying to fix 1411507
<LocutusOfBorg1> the problem: now the version in trusty is 4.3.10-1
<LocutusOfBorg1> since I'm the maintainer I'm preparing the debdiff with 4.3.10-1ubuntu1 rather than ubuntu0.1 as suffix
<LocutusOfBorg1> is that ok?
<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
<ochosi> dholbach: in case you'll be reviewing xdg-utils MRs and you have any questions just lemme know!
<dholbach> ochosi, there is nothing for xdg-utils on http://reqorts.qa.ubuntu.com/reports/sponsoring/?
<ochosi> oh, i guess i need to subscribe ubuntu-sponsors on https://code.launchpad.net/~ubuntu-branches/ubuntu/vivid/xdg-utils/vivid/+activereviews
<dholbach> no, that shouldn't be necessary - that's just for bug reports
<dholbach> let me see
<pitti> it's already approved, maybe that's why?
<dholbach> yes, but it wasn't landed
<dholbach> seb128,  can you comment on https://code.launchpad.net/~ochosi/ubuntu/vivid/xdg-utils/drop_xserver_patch/+merge/246101?
<dholbach> https://code.launchpad.net/~thad-fisch/ubuntu/vivid/xdg-utils/lp1363540/+merge/246820 was approved by ochosi (who doesn't have upload rights)
<seb128> dholbach, I already did?
<dholbach> seb128, it wasn't landed AFAICS
<seb128> dholbach, no, just approved
<dholbach> right
<dholbach> that got it off the sponsoring list
<seb128> feel free to upload it
<seb128> I just didn't get to it yet
<seb128> what, approving?
<dholbach> I wasn't complaining
<dholbach> yes
<seb128> why?
<seb128> the intend was to say "it's ready to be sponsored"
<dholbach> I tried to point out a workflow issue
<seb128> to "it has been uploaded"
<seb128> thanks for that
<seb128> I though that only "merged" would get it out of the list
<dholbach> right
<dholbach> I'll take a look at the sponsoring script and see what the result would look like if we had "approved" MPs on there too
<seb128> thanks
 * ochosi apologizes if he has caused any sort of inconvenience here
<seb128> sorry for the mistake, and thanks for pointing it out
<seb128> ochosi, no, not at all
<dholbach> no worries
<seb128> I just assumed that if I reviewed without having the slot for actual upload it would still be useful
<seb128> I didn't get that it would get it out of the list
<ochosi> actually that's good to know
<ochosi> i'll keep that in mind too
<ochosi> i obviously made a similar mistake (even without having upload rights, i thought reviewing/commenting the code/MR would be useful)
<dholbach> I'll play around with the sponsoring script now and let you know if the world breaks, if we add 'Approved' MPs as well.
<dholbach> ochosi, no, I think it's great that you added your support for it
<ochosi> oh ok, so just to get the most out of this: was it ok (procedure-wise) to come here and ask the current pilot? or what could i have done differently not to disrupt your workflow
<dholbach> ochosi, yes, that was perfectly fine :)
<dholbach> ochosi, I didn't expect the MP to fall off the radar when seb and you set it to 'Approved'
<dholbach> so I'm just checking if there's a good way to fix the sponsoring overview :)
<ochosi> sounds good :)
<Laney> There's probably loads of approved-not-merged UDD branches
<dholbach> Laney, yes, probably
<dholbach> seb128, Laney, http://paste.ubuntu.com/9783833/ changed our list from 57 to 69 requests, with no xdg-utils MPs among them.......
<dholbach> hum
<apw> darkxst, still broken at the moment, working on it
<seb128> dholbach, seems like a managable difference, do you know why xdg is missing still?
<dholbach> no, no idea
<dholbach> Laney, seb128, could it be that "review requested from <ubuntu-branches or something>" is missing on both xdg-utils MPs?
<dholbach> like on https://code.launchpad.net/~xnox/upstart/systemd-local-bridge/+merge/246772 for example
<seb128> could be
<seb128> shouldn't that be added by default though?
<dholbach> yeah
<Laney> I think that a person takes over a team's review when they perform it
<seb128> or is that because ochosi added me specifically for review?
<Laney> maybe
<Laney> ?
<seb128> oh?
<dholbach> ochosi, do you remember if you changed something in the "reviewer" settings or requested a particular review from somebody?
<dholbach> Laney, I always thought that it was added
<ochosi> dholbach: yes, because i had worked with seb128 on xdg-utils merges before, i specifically requested his review
<dholbach> let me see what happens if I can add jodh to xnox' MP
<ochosi> and it's possible that brainwash (aka thaddÃ¤us tintentfisch) directly requested my review
<seb128> ochosi, but did you remove the team from reviewers?
<ochosi> seb128: no, not actively/willingly
<seb128> k
<Laney> for example https://code.launchpad.net/~laney/ubuntu-system-settings/as-activation/+merge/225953
<dholbach> Laney, seb128: looks like it's added and not replacing ubuntu-branches: https://code.launchpad.net/~xnox/upstart/systemd-local-bridge/+merge/246772
<Laney> there's no team review
<Laney> but I wouldn't have requested seb128 explicitly there
<dholbach> Laney, maybe because it's not source package branch?
<dholbach> s/not/no
<Laney> doubt it
<Laney> one sec
<seb128> dholbach, I think what Laney is saying is that if a member of the team does a review and set approve, launchpad considers the review done and replace the team by the reviewer
<seb128> Laney, something like that?
<dholbach> ahh ok
<Laney> ya
<dholbach> which.... for https://code.launchpad.net/~thad-fisch/ubuntu/vivid/xdg-utils/lp1363540/+merge/246820 wouldn't quite explain it
<dholbach> it's even still in "Needs review"
<Laney> if you're looking for all MPs which ubuntu-branches has a requested review on then that won't be returned
<Laney> is that what the queue is doing?
<dholbach> Laney, yes - I think that's the only way how we can get a list of MPs
<seb128> dholbach, Laney, one other possibility is that when you file a mp and directly put the reviewer on the filing page, then it leads to not have the default reviewers added
<seb128> rather than filing and adding a reviewer then
<dholbach> might be, yes
<Laney> https://code.launchpad.net/~laney/ubuntu/vivid/0ad/test/+merge/246873
<Laney> review that please
 * seb128 tries
<seb128> ja
<seb128> that replaced the team
<seb128> Laney, also, https://code.launchpad.net/~seb128/gallery-app/some-translations-tweaks/+merge/246874
<seb128> that's buggy but I picked one of my vcs and mp it selecting you as reviewer in the optional entry on the mp filing page
<seb128> the team is not there, only you
<Laney> that replaces the default
<Laney> it's probably by design there
<Guest67718> That's correct.
<seb128> right
<xnox> dholbach: ubuntu-branches is default, at proposal time one can choose someone else to review (in that case ubuntu-branches is removed)
<wgrant> It's rather odd, but that's the way it is.
<seb128> which I guess is what happened on those xdg-utils reviews
<xnox> dholbach: i typically keep ubuntu-branches and add extra people, that I would like to notify
<ochosi> so, i should have not requested a reviewer when filing the MR but instead added one on top of the default?
<seb128> ochosi, correct
<xnox> dholbach: however, i have the benefit of knowing plenty of relevant people to notify.
<ochosi> ok, good to know
<Guest24387> The field on the MP form replaces the default reviewer, and once a team member reviews it the team request is replaced with a review from that person.
<dholbach> hum, so we don't have a good way of finding MPs which have had ubuntu-branches removed :)
<seb128> ochosi, yeah, some of us learnt something today ;-)
<xnox> dholbach: apart from iterating across all open MPs..... not really
<ochosi> seb128: hehe, indeed. i'll see that knowledge gets passed on in the xubuntu team
<Laney> Is there an API way to find all ubuntu-branches MPs which are 'Needs Review'?
<seb128> ochosi, thanks
<dholbach> Laney, yes, that's what we're using
<wgrant_> Laney: ubuntu-branches in which sense?
<Laney> As target
<wgrant_> As branch owner, or as reviewer?
<Laney> that's what lp:ubuntu/... is an alias too, right?
<Laney> to
<xnox> pitti: i'm failing to create or start ubuntu-emulator on vivid, with a vivid image.
<xnox> am I missing something obvious?
<xnox> https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1412261
<ubottu> Launchpad bug 1412261 in goget-ubuntu-touch (Ubuntu) "can't create emulator instance on vivid" [Undecided,New]
<xnox> "Can't create tempfile to create emulator instance"
<xnox> $ sudo ubuntu-emulator create --arch armhf --channel ubuntu-touch/devel-proposed --revision 68 vivid2
<pitti> xnox: oh, it's been ages since I tried armhf; it's utterly slow, I only use i386 (the defualt)
<xnox> pitti: i386 also fails
 * xnox ponders if i need to create a magic directory somewhere for it to work.
<pitti> xnox: creating one again
<pitti> it was working just fine until Friday, for months anyway; but maybe something broke over the weekend
<pitti> xnox: do you have a full /tmp/ or anything like thatZ?
<LocutusOfBorg1> dholbach, pitti do you have time for a virtualbox/trusty review?
<LocutusOfBorg1> https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1411507
<ubottu> Launchpad bug 1411507 in virtualbox (Ubuntu) "virtualbox-guest-dkms 4.3.10-dfsg-1: virtualbox-guest kernel module failed to build [error: 'generic_file_aio_read' undeclared here (not in a function)]" [Undecided,New]
<LocutusOfBorg1> I fixed the bug ;)
<dholbach> I'll check it out in a bit
<LocutusOfBorg1> oh and BTW I added some packages here https://bugs.launchpad.net/ubuntu/+source/poedit/+bug/1408285
<ubottu> Launchpad bug 1408285 in kbuild (Ubuntu) "Please sync kbuild, virtualbox and virtualbox-guest-additions-iso from debian/experimental" [Undecided,Incomplete]
<LocutusOfBorg1> (kbuild is still being worked in debian by me)
<dholbach> hum... ok
<dholbach> ubuntu-sponsors is not subscribed, let me re-add it
<LocutusOfBorg1> thanks! :)
<LocutusOfBorg1> dholbach, did you test virtualbox? :)
<dholbach> LocutusOfBorg1, it's taking a bit longer to set up everything with trusty
<dholbach> are you in a hurry?
<LocutusOfBorg1> nope, just wonderinf if you were taking a look or not, sorry but I'm currently working on other 10 packages, and I forgot really soon things :)
<dholbach> sure, take your time
<LocutusOfBorg1> so can I forget about that bug, right? (until I get some mails)
<dholbach> yes
<LocutusOfBorg1> wonderful thanks
<LocutusOfBorg1> do you think 3.18 will be backported to trusty too? just to cherry-pick something more, to step ahead the next build failure :)
<apw> LocutusOfBorg1, v3.18 likely will not be backported to trusty, there will be an lts-vivid with whatever vivid has at release
<apw> (which is looking currently like it would be v3.19)
<LocutusOfBorg1> so apw the answer was "yes", but the question was "wrong" :)
<LocutusOfBorg1> I mean, somebody will have that kernel and the build failure with virtualbox then
<apw> LocutusOfBorg1, heh, very likely yes in the future, cirtainly i do already :)
<LocutusOfBorg1> do you have any ppa for it? this way I can proactively fix also that build failure :)
<dholbach> LocutusOfBorg1, so I created a trusty chroot, updated to the latest, installed virtualbox and linux-generic-lts-utopic (which has 3.16), but I don't see the issue happening......
<dholbach> did you try this too?
<LocutusOfBorg1> dholbach, nope I have a real machine and a virtualbox machine
<LocutusOfBorg1> I tried and it failed
<LocutusOfBorg1> chroot might not be enough ( pitti has something to say about the topic :p )
<dholbach> ok... how do you reproduce the issue?
<LocutusOfBorg1> try uname -a in the chroot, you will likely have the "host" kernel
<pitti> of course, chroots don't have their own kernel; but you can install various linux-headers-* packages to build against
<LocutusOfBorg1> I install trusty in a VM, update the kernel, reboot with the new one and install
<LocutusOfBorg1> I found that having a VM, was easiest for testing and reproducing the issue ;)
<LocutusOfBorg1> pitti, I tried also this solution, but for some reasons I didn't investigate virtualbox-dkms was picking the wrong kernel
<LocutusOfBorg1> maybe because it does an "uname -a" to know the version to build modules against?
<dholbach> ah ok
<pitti> yeah, probably
<LocutusOfBorg1> I think you can force the version somewhere, but again, I didn't investigate since setting up a VM takes less time :)
<pitti> it might only build against the current kernel, not all instlaled linux-header-* ones
<LocutusOfBorg1> and I think makes me more confident about the issue
<apw> LocutusOfBorg1, dkms should build against the kernel version of the headers/image you are installing, not the runnnig kernel
<apw> LocutusOfBorg1, that is passed into the dkms incantation, and dkms packages themsleves should not be using uname to work out the version to use
<apw> LocutusOfBorg1, or is this on upgrade of the dkms package itself
<LocutusOfBorg1> apw, yes, but "uname -a" was just a guess, I don't know what are they actually using, so your solution might be perfectly correct
<apw> dholbach, you do need to install the dkms package before the headers to get the right version build
<LocutusOfBorg1> nope apw I'm talking about virtualbox-guest-dkms
<LocutusOfBorg1> not dkms itself
<apw> in a chroot context
<LocutusOfBorg1> wonderful apw :)
<tseliot> apw, LocutusOfBorg1: if dkms packages call the right DKMS template (/usr/lib/dkms/common.postinst), they will pick up the correct kernel version
<tseliot> even in a chroot
<tseliot> (nvidia and fglrx do this in their postinst scripts)
<apw> tseliot, so they would, that is a postinst and 3/4
<tseliot> apw: I'm not sure I follow you
<apw> (oh i was just agreeing and saying, "man that is a long postinst fragment"
<tseliot> apw: hah, thanks, I worked on it myself :)
<apw> tseliot, i noticed :)
<apw> darkxst, ok ... i've just uploaded a casper change to move to proper overlay, which should avoid the overlayfs issue which is breaking live boot
<apw> darkxst, i am still working the original issue in the kernel
<sitter> cyphermox: upstream plasma-networkmanager dev asks when we are going to land networkmanager 1.0. will it be 15.04 or 15.10?
<mlankhorst> do I need a MIR for clang? because the llvm source package is already in main..
<seb128> mlankhorst, if it's a binary from a source already in main, no
<mlankhorst> ok
<rsalveti> pitti: I'm getting a race when starting whoopsie on latest ubuntu-touch image (vivid)
<rsalveti> pitti: seems it's not started by the upstart job
<rsalveti> removed the start line from the upstart job and it still got started, which would explain the race
<pitti> rsalveti: so there's something else that runs "start whoopsie"?
<pitti> or service whoopsie start or whatever
<rsalveti> pitti: from ps it's not running with -f, just get /usr/bin/whoopsie
<rsalveti> wonder if https://launchpadlibrarian.net/195012178/whoopsie_0.2.43_0.2.44.diff.gz made any difference
<rsalveti> right
<pitti> rsalveti: oh, it could actually do
<ogra_> pitti, seb128 suggested there would perhaps be some dbus activation
<pitti> rsalveti: I uploaded that as I started the emulator and saw the error message from init-d-script
<seb128> ogra_, in fact not likely, just checked
<ogra_> ah, k
<pitti> rsalveti: no, whoopsie doesn't listen on dbus
<ogra_> just wanted to carry the info along
<pitti> rsalveti: so something indeed starts the init.d script
<rsalveti> pitti: hm, what was the emulator error?
<seb128> whoopsie-preference is the one which has a dbus service
<rsalveti> pitti: yeah
<pitti> rsalveti: I just saw init-d-script complaining about a malformed $DAEMON
<rsalveti> oh, ok
<pitti> but not what tried to start it
<rsalveti> so you fixed the script and that caused the race
<pitti> rsalveti: so, we've had the broken init.d script for ages, and indeed it's not supposed to be started in the first place
<rsalveti> right
<pitti> the phone does have the LSB hook to divert calling /etc/init.d/whoopsie to upstart, which makes this thing even weirder
<pitti> /lib/lsb/init-functions.d/01-upstart-lsb
<pitti> so, we can certainly "break" the init.d script again, or even drop it, but this might happen to other init.d scripts too
<rsalveti> yeah
<pitti> rsalveti: initially I thought this was just a side effect of running with systemd (which I did on Friday), I wasn't aware it also happens under upstart
<rsalveti> maybe something is broken with that LSB hook
<rsalveti> but guess that would cause some other bad side effects
<pitti> yeah, it would mean that other init.d scripts woudl run too
<pitti> I can't imagine something specifically calling the whoopsie init.d hook outside the boot process itself
<pitti> i. e. /etc/rc2.d/*
<pitti> s/hook/script/
<xnox> and whoopsie-preferences does not start whoopsie?
<shadeslayer> mvo: pitti could one of you approve https://code.launchpad.net/~rohangarg/synaptic/bug1375786/+merge/244005
<shadeslayer> been over a month
<rsalveti> pitti: added a debug line in /lib/lsb/init-functions.d/01-upstart-lsb and it didn't check for the whoopsie job (it did for quite a few others)
<mvo> shadeslayer: ups, sorry, let me merge/upload
<shadeslayer> mvo: thanks alot, can we also get a SRU fix for Utopic?
<shadeslayer> would be supremely awesome
<shadeslayer> mvo: tbh I'm not entirely sure if we need 2 desktop files
<shadeslayer> http://paste.ubuntu.com/9785018/ < diff between the 2 desktop files
<shadeslayer> not sure what X-KDE-SubstituteUID is
<mvo> shadeslayer: I think that had the effect to start it with sudo, but I have little knowledge of kde, so if kde can use the normal file, that would rock
<shadeslayer> mvo: we do have a pkexec helper
<shadeslayer> mvo: just a sec, just let me use the normal file and see what happens
<mvo> shadeslayer: ok
<dholbach> LocutusOfBorg1, I'll change the version number to 4.3.10-dfsg-1ubuntu1, ok?
<dholbach> apart from that it looks good to me
<shadeslayer> mvo: yeah , I'd just nuke the kde desktop file, the regular one works in Plasma 5 on vivid
<mvo> cool, I will push that to vivid
<shadeslayer> mvo: thoughts about what to do for utopic ? just use the synaptic-pkexec patch?
<shadeslayer> ( Also, just throwing it out there, you probably want to remove the NotShownIn line in the regular desktop file )
<mvo> shadeslayer: if someone could test if dropping the synaptic-kde.desktop file (and removing the "not-show-in=kde" works for utopic as well I would prefer to also drop the file there
<mvo> shadeslayer: http://bazaar.launchpad.net/~synaptic-developers/synaptic/trunk/revision/2167 :)
<shadeslayer> mvo: I can do that
<mvo> shadeslayer: great, please let me know and I can do the SRU
<shadeslayer> awesome, give me 20 mins
<Riddell> armhf builders all broken?
<shadeslayer> Riddell: seems to be working fine https://launchpad.net/ubuntu/+source/kio-extras/4:5.1.95-0ubuntu3/+build/6731015
<Riddell> ooh they just caught up, good good
<cjwatson> Riddell: There was a power issue earlier that took them all out, but they've been back for most of an hour now.
<shadeslayer> cjwatson: did someone trip over a power strip :P
<cjwatson> shadeslayer: Not as far as I know :-P
<rbasak> I think they're all in one chassis, aren't they?
<rbasak> No need for a power strip :-)
<cjwatson> There was some scheduled power maintenance but then some systems weren't quite as dual-power as one might hope.
<cjwatson> And yes, the LP non-virt ARM builders are all in one chassis.
<shadeslayer> curious, does anyone know how to pass a env var to the schroot setup scripts? I have a script that needs to read a env var that Jenkins sets
<svenx> shadeslayer: schroot(1) explains it in its ENVIRONMENT section (bottom)
<svenx> ref environment-filter
<shadeslayer> svenx: isn't that explcitly to filter out env variables
<shadeslayer> I want to whitelist something
<svenx> hm, true
<svenx> the text is ambiguous
<shadeslayer> quite :)
<svenx> related: https://bugs.debian.org/666274
<ubottu> Debian bug 666274 in schroot "schroot complains about unknow source-root-groups config entry" [Minor,Fixed]
<svenx> "Arbitrary options may now be set in a chroot definition in schroot.conf.  These options are also set in the environment when running setup scripts, making this a simple means by which setup scripts may be customised without writing code."
<xnox> cjwatson: i'm not going into the datacentre this time around.... i did leave a note that most things are single-power.
<shadeslayer> svenx: aha figured it out
<shadeslayer> thx
<shadeslayer> this is awesome :3
<ngaio> hi everyone! Is it safe to assume that Qt 5.4 is a certainty for inclusion in Vivid?
<pitti> rsalveti: ok, that indicates that something was calling it as /etc/init.d/whoopsie instead of /etc/rc2.d/S??whoopsie
<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:
<shadeslayer> mvo:  seems to work in utopic as well
<shadeslayer> plz go ahead and nuke it
<cyphermox> sitter: I am landing 0.9.10 today; will get started on 1.0 right after that's done
<sitter> cyphermox: awesome. do you think 1.0 is going to make it into 15.04?
<sturmflut-work> If anybody has ideas about https://sturmflut.github.io/linux/ubuntu/2015/01/17/unprivileged-icmp-sockets-on-linux/ or https://sturmflut.github.io/linux/wireless/2015/01/19/designing-a-wifi-analyzer-app-for-ubuntu-touch/, please do let me hear them
<sturmflut-work> Would be nice to know that I am completely wrong and there are other solutions
<cyphermox> sitter: yes
<sitter> cyphermox: groovy, thanks for the info :)
 * xnox ponders to switch to CIRC irc client
<didrocks> xnox: hey! so, on your email about systemd local bridgeâ¦ I guess you will have to create virtual units for value then. (that's what I told you on the hangout on Friday, that I doubted * would work)
<xnox> didrocks: correct, if there are virtual values in fact. cause in other places it seems like a forward-looking glob rather than a required one.
<xnox> didrocks: but that means someone needs data/values for those, and then in the hw-override tarball or the android config do
<didrocks> xnox: yeah, it doesn't reevaluate
<xnox> postinst
<xnox> systemctl enable android-container@foo.bar=val1.target
<xnox> systemctl enable android-container@foo.bar=val2.target
<xnox> systemctl enable android-container@foo.bar=val3.target
<xnox> as needed.
<didrocks> yeah :/
<xnox> .... adn then template the job as well....
<didrocks> (btw, I would prefer android-property, as the property is accessible outside the containerâ¦ but it's just a matter of taste ;))
<didrocks> yeah, quite trickyâ¦
<xnox> i guess one only needs systemctl enable adb@val1.target, which should have wanted by = android-container@foo.bar=%i.target
<xnox> didrocks: "android-container" is a configurable string. In the upstart job it was "upstart-local-bridge --event android-container"
<didrocks> ah ok, it's the parameter :)
<xnox> didrocks: we can totally change the systemd unit to do "--event android-property"
<didrocks> well, just a suggestion, but great it's easy to change
<xnox> which in systemd world means "the name of the template target"
<didrocks> yeah
<xnox> didrocks: however ogra_ didn't get back to me with names of targets. And i don't have all the phones to check / test these.
<xnox> didrocks: unless come CI thing has a dump of all the "getprops"
<xnox> s/come/some/
<didrocks> xnox: actually, we can go the other way around, units knows what property they expect
<didrocks> and so, you scan the .service with WantedBy=
<didrocks> and only expose/enable them dynamically?
<didrocks> that would avoid creating tons of unwanted unit propertiesâ¦
 * didrocks tries to create a WantedBy= on unexisting target
<xnox> didrocks: if the wanted by has the full name of the target, that one gets enabled, yes.
<xnox> didrocks: that's how it currently works, it's just one cannot have a glob in it.
<xnox> like what's currently used in upstart: maybe with, maybe without reason.
<xnox> adbd.service should list all the wantedby's it wants to trigger on. If we need globbing, then I guess the upstart-local-bridge can
<xnox> instead of activating: a-c@a.b.c.d=foo1.target
<xnox> activate:
<xnox> a-c@a.b.c.d=foo1.target a-c@a.b.c.d=foo.target a-c@a.b.c.d=.target a-c@a.b.c.target a-c@a.b.target a-c@a=foo1.target
<xnox> but imho that's ugly.
<didrocks> yeah, it is :/
<xnox> i think it would be ok for, e.g. adbd.service if it needs "a-c@propery=adb[0-9]*.target" to make itself adbd@.service "WantedBy = a-c@property=adb%i.target" and do systemctl enable adbd@`seq 0 100`.service
<xnox> templated instance .service <- 1 to 1 -> templated property instances
<didrocks> xnox: I don't get why you don't rather do that:
<xnox> ?
<didrocks> adb.service -> WantedBy=a-c@adb.target
<didrocks> then, the bridge look at the target in systemd memory
<didrocks> sorry WantedBy=a-c@property=adb.target
<xnox> and do the globbing on the bridge?
<didrocks> get that it needs to fetch and monitor "property"
<didrocks> yeah
<didrocks> and so, create that target/start/stop it as needed
<didrocks> that way, you only create the targets that are needed on the system
<xnox> i'm ok to implement that, however i would adb.service then list:
 * xnox has no systemd-escape on this machine
<didrocks> don't worry ;)
<didrocks> I know about it
<xnox> WantedBy=a-c@property=adb*.target
<xnox> where * is the systemd-escaped code.
<didrocks> and you escape the *
<didrocks> yeah
<xnox> then the bridge can tell appart what should and shouldn't be globbed
<didrocks> right
<xnox> and it will start a-c@property=adb*.target & a-c@property=adb75.target
<didrocks> and create and start the target
<xnox> .... stars escaped.
<didrocks> which will then bring the unit
<didrocks> (sure)
<xnox> yeah, the whole thing.
<didrocks> not sure if the API is good to list WantedBy targets
 * didrocks looks at what status says
<didrocks>    Loaded: not-found (Reason: No such file or directory)
<didrocks>    Active: inactive (dead)
<LocutusOfBorg1> thanks dholbach
<LocutusOfBorg1> :)
<didrocks> not sure, status doesn't know about it even if I enabled a unit which WantedBy= against it
<dholbach> anytime
<xnox> didrocks: correct.
<xnox> didrocks: that's fine.
<xnox> didrocks: as it's not loaded, start & stop the .target, then status will know about it.
<didrocks> xnox: right, but how would you detect those patterns then?
<xnox> didrocks: wantedby installs a file on disk, it's static and evaluated on the the instance start.
<didrocks> xnox: you don't want to scan /etc/systemd/system/*target.d? :)
<xnox> didrocks: i would have hoped systemd dbus api exposes wantedby's of the units themself.
<xnox> didrocks: a-c@property=adb*.target
<didrocks> xnox: yeah, I hope as well. I can just tell you status (which is talking through the dbus api to systemd) doesn't know :/
<xnox> didrocks: readonly as WantedBy = ['multi-user.target'];
<xnox> didrocks: so with d-feet  / gdbus one can query iterate all units (e.g. adbd.service) and check theirs wantedby=a-c@
<xnox> we do parsing of all jobs a lot in bridges.
<didrocks> xnox: oh, we have the WantedBy fields over dbus for each units?
<xnox> e.g. upstart-systemd-bridge & upstart-file-bridge iterates through all units and caches their start on / stop on.
<didrocks> yeah, sounds good :)
<xnox> to do things with file & socket events.
<xnox> similar thing will be here.
<didrocks> yeah
<xnox> also will subscribe to NewUnit signal.
<didrocks> and I guess on the android side, you have an event in the container when a property changes?
<xnox> didrocks: there is no events  inside the android container.
<didrocks> how do you track changes then?
<didrocks> like I'm enabling developer mode
<xnox> setprop -> changes shared bionic memory, we have a property-watcher daemon (bionic binary) running under android-init, that thing writes key=value pairs into the socket.
<xnox> the socket is the one created by the upstart-local-bridge, and bind-mounted into the lxc container by lxc-android-config
<xnox> and that's how propery changes arrive at upstart-local-bridge.
<didrocks> ahah, tricky ;)
<xnox> didrocks: upstart-local-bridge only listens to the container.
<xnox> didrocks: as it's entirely android thing.
<xnox> didrocks: ideally, we'd make systemd bionic aware and memory map android properities and expose them as native conditions.....
<xnox> but my left half of the brain says that's crazy
<didrocks> xnox: I guess for the transition period, reusing the local bridge is what makes more sense
<didrocks> xnox: so, I guess we are mostly set on the solution in the least intrusive way? do you need any help on this?
<didrocks> no hurry anyway, as Touch on systemd isn't for this cycle anyway (activation of it, we can have it nicely running in advance though :p)
<xnox> didrocks: non-globbing bridge is in silo 0001, however i need it tested on the phone/emulator "does not explode under upstart, may do nothing under systemd"
<xnox> didrocks: before i land it.
<xnox> and emulator is not giving me any joy at the moment
<didrocks> xnox: yeah, I saw that, works nicely (amd64) here, freshly created on Friday
<xnox> didrocks: do you mind dist-upgrade with silo 1, and boot with upstart / boot with android? and verify that it generally works?
<xnox> and e.g. you can see event with upstart-monitor when you do setprop under upstart
<xnox> and target under systemd?
<didrocks> xnox: can do in ~20 minutes, finishing up some plymouth stuff first
<didrocks> will get back to you then :)
<sturmflut-work> I'm on 15.04 and at random times a day a popup will appear, requesting me to enter my password to change my user data. The "Details" section states "Action: org.freedesktop.accounts.change-own-user-data" and "Vendor:". I have now idea where this comes from, and if I just cancel it nothing happens. Any ideas?
<sturmflut-work> Couldn't find a matching bug report, but it seems to be the same issue as mentioned in http://askubuntu.com/questions/562355/seemingly-random-authentication-is-required-to-change-your-own-user-data
<didrocks> xnox: after a "sudo setprop persist.sys.usb.config mtp", I see no new target with systemctl
<xnox> didrocks: can you do that from inside android container?
<xnox> didrocks: or for example boot emulator with upstart and "--debug" on the kernel command line and check that android events are generated with upstart
<xnox> didrocks: are there any targets generated at all? systemctl status android-container@*.target ?
<xnox> didrocks: possibly property watcher only works from container....
<xnox> didrocks: i know that you can do $ socat - UNIX-CONNECT:/dev/socket/* persist.sys.usb.config=mtp
<xnox> didrocks: maybe things explicitely echo stuff into the socket inside the android container.
<mvo> shadeslayer: thanks,  I am very busy right now, would you mind reminding me again tomorrow if I haven't acted on this by then? sorry, work is very busy right now
<shadeslayer> mvo: sure, I understand, it'd just be nice to have it fixed soonish, one of our downstreams has a release soon and would be nice to get it in
<didrocks> xnox: actually, the bridge isn't startedâ¦ what is supposed to start it? I don't see any upstart job doing that
<pitti> apw: oh, "overlay" != "overlayfs" :) thanks for the casper fix/workaround!
<pitti> apw: that avoids the weird char dev issue on renaming?
<mvo> shadeslayer: yeah, if someone could prepare the sru diff (should be really) easy that would make it much simpler for me, a review/dput is quick for me
<shadeslayer> mvo: sure, I can do that
<apw> pitti, yes it should avoid it for new overlays such as those which the installer makes
<apw> pitti, i am working on, actually testing the heck out of, a fix for the V1 support separatly from that
<pitti> apw, the rescuer of alpha-2!
<apw> pitti, the breaker of perhaps :)
<apw> pitti, dunno if someone can respin something to test it sooner than tonight
<mvo> shadeslayer: \o/
<pitti> apw: heh -- I hope that overlay isn't an entirely new thing, but just the evolution of overlayfs?
<xnox> didrocks: there are systemd unit and upstart job in lxc-android-config package
<pitti> apw: the release team should be able to
<didrocks> xnox: hum, I didn't see the upstart job, looking
<xnox> didrocks: there is no stock upstart-job, as the user configures their own job with the required socket path & event name.
<didrocks> xnox: I did the systemd unit in lxc-android-config, and I only started the container, (to mirror the upstart one)
<xnox>  /etc/init/upstart-local-bridge.conf
<xnox> and i don't see unit one sec.
<apw> pitti, ack, have asked on #u-release ... it seems prudent to get ahead
<pitti> apw: yes, absolutely
<pitti> apw: it could in theory be hacked into break=casper-top, but that quickly gets tiresome
<xnox> didrocks: and i did not upload lxc-android-config 0.215 well that's a fail.
<didrocks> xnox: :)
<xnox> didrocks: no idea where that upload is at now though.
<xnox> didrocks: cause e.g. one needs upstart-bin to have local-bridge binary
<pitti> stgraber: you are TIL for ifupdown; do you plan to merge it?
<pitti> stgraber: if not, I'll upload it soon to provide the static-network-up counterpart for systemd
<didrocks> xnox: works with the daemon started manually
<pitti> stgraber: (i. e. I'll add those as a network-online.target dependency)
<xnox> didrocks: systemd or upstart or both?
<stgraber> pitti: merging it is on my todo but not extremely high on it at the moment
<didrocks> xnox: systemd only for now
<xnox> didrocks: that's cool.
<didrocks> xnox: how do I try the upstart ones? I'm not as upstart-savy than systemd :)
<didrocks> as you create an event
<xnox> didrocks: sudo upstart-monitor; trigger the same way you triggered for systemd -> should see things from upstart-monitor stdou
<xnox> didrocks: sudo upstart-monitor; trigger the same way you triggered for systemd -> should see things from upstart-monitor stdout
<didrocks> ok :) uno memento!
<xnox> however i think it's fine to let upstart in, and then i'll upload fixed up lxc-android-config
<xnox> i don't have it locally anymore, so i'll have recreate
<didrocks> xnox: hum, upstart-monitor is a gtk app?
<didrocks> ah, it's telling it's fallbacking to cli
<didrocks> but traceback :p
<didrocks>     class UpstartEventsGui(Gtk.Window):
<didrocks> NameError: name 'Gtk' is not defined
 * didrocks edits to avoid the traceback
<xnox> didrocks: sudo upstart-monitor -n
<xnox> for the non-gui version
<xnox> sorry forgot.
<didrocks> xnox: yeah, it's puzzling that it's telling that it's fallbacking though :)
<didrocks> even with -n, traceback
<didrocks> so really an issue with the app/
 * didrocks fires vi
<xnox> didrocks: yeah..... =/
<shadeslayer> mvo: https://launchpadlibrarian.net/195323505/patch
<didrocks> xnox: hum, interesting, can't import Glib, despite having gir1.2-glib-2.0 installed on the phone
<xnox> didrocks: apt-get install python -gi
<xnox> didrocks: apt-get install python-gi
<xnox> no?
<didrocks> xnox: not that, you are trying to import Gtk first
<didrocks> then, it bails out
<didrocks> and so don't import the rest :p
 * didrocks will do some patches to upstart-monitor :)
<xnox> didrocks: option easier = boot emulator with "--debug" on the kernel command line
<didrocks> xnox: too late, running ;)
<xnox> didrocks: that your emulator console will be full of upstart events.
<xnox> didrocks: than your emulator console will be full of upstart events.
<didrocks> xnox: 2015-01-19 16:59:14.398513android-container SOCKET_TYPE='unix' SOCKET_VARIANT='named' CLIENT_UID='0' CLIENT_GID='0' CLIENT_PID='17531' SOCKET_PATH='/dev/socket/upstart-text-bridge' persist.sys.usb.config='mtp'
<didrocks> \o/
<xnox> cool.
<didrocks> (needed to use socat, for some reason, couldn't lxc-attach to the container)
<didrocks> xnox: so, seems to be good from my limited testing
<xnox> didrocks: lxc-attach does not quite work on the android container - it's rootfs is unpacked into private tmpfs, which one cannot get into.
<xnox> didrocks: so now i need to figure out which buttons to push for release.
<didrocks> xnox: yeah, when I saw the "couldn't access to <mount point>", I reckoned that was the case :)
<didrocks> xnox: ahah, I guess the publish one ;)
<didrocks> or ask on #ubuntu-ci-eng
<didrocks> xnox: so, filtering and globbing for the longer term solution, but seems like a nice step forward!
<xnox> didrocks: well if https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/75/ fails then i'll ask stuff
<xnox> Finished: SUCCESS
<didrocks> sweet
<xnox> looking good http://people.canonical.com/~platform/citrain_dashboard//#?distro=ubuntu&q=landing-001
 * didrocks waves good evening
<xnox> slangasek: looks like you are admin of ~ci-train-ppa-service can I get added to that team, such that I can dput packages into silos that are assigned to me?
<LocutusOfBorg1> mdeslaur, hi, do you plan to merge openssl?
<LocutusOfBorg1> I think we can almost drop all, since debian merged some ubuntu stuff
<mdeslaur> LocutusOfBorg1: no, I'm waiting for when W opens
<mdeslaur> LocutusOfBorg1: there are regressions and big changes in the current debian versions that I don't want for V
<LocutusOfBorg1> ack, thanks for the reply! so I won't touch anything
<LocutusOfBorg1> wonderful :)
<apw> pitti, ok, a respin looks good, booted and installed ok here, so i think we are good should there be a milestone
<Laney> cjwatson / someone else: could you moderate my mail to u-d-a please? The one with the correct subject line spelling, not the other one. :)
<Laney> Oh right, I can cancel it can't I
<rsalveti> xnox: hey, mind updating lp:ubuntu/upstart with the content from the latest version that got uploaded?
<rsalveti> seem to be https://code.launchpad.net/~xnox/upstart/systemd-local-bridge/+merge/246772, but there is a conflict in there
<asac> cjwatson: do you know if its normal that sshd doesnt start if one of the host keys referenced in /etc/ssh/sshd+_config is not avail?
<asac> wonder because seems we gen these ed2... keys in openssh serer
<asac> but seems that cloud-init doesnt generate them :/
<asac> e.g. in code they only generate three
<asac> so wonder how noone coudl have noticed and suspect there is a flag i am missing that will make sshd start ignoring that missing key
<asac> seems you landed that key in trusty a year ago :)
<asac> anyone else? :)
<asac> kirkland: you around?
<cjwatson> asac: not at a proper computer right now, but from what I can make out from browsing sshd.c on my phone, that should result in an error being logged but the server otherwise continuing to start up fine, as long as you have *some* protocol-2-suitable host key available.  this is not behaviour governed by any flag as far as I can see.  I would need to see logs to tell you any more.
<cjwatson> Laney: done
#ubuntu-devel 2015-01-20
<pitti> Good morning
<Unit193> Howja.
<pitti> hey Unit193!
<pitti> shadeslayer, Riddell: so what's the deal with kde-sc-dev-latest? all KDEish autopkgtests fail now as tests want to install that package, but it's not available
<pitti> e. g. https://jenkins.qa.ubuntu.com/job/vivid-adt-ksystemlog/25/ARCH=amd64,label=adt/console
<pitti> and 24 others
<dholbach> good morning
<LocutusOfBorg1> hi developerz!
<pitti> xnox: hmm, is upstart-monitor supposed to work? I'm running it to see the update-notifier events (:sys:block-device-changed), but I don't get any event
<pitti> and apparently update-notifier's job also doesn't trigger
<pitti> xnox: oh wait, my fault -- running VM under systemd, sorry
<pitti> xnox: typical "find the solution after you ask", sorry
<pitti> xnox: hm, it doesn't work under upstart either; neither in default mode nor with -d system-socket
<pitti> and the update-notifier job still isn't started
<pitti> ah, with sudo I do get the events
<pitti> block-device-changed KERNEL='sr0' ID_FS_TYPE='iso9660'
<pitti> that's what update-notifier-cds.conf matches on, but it never actually fires
<pitti> presumably because upstart-monitor as user also doesn't see those? is there some kind of ACL?
<pitti> jodh: ^ is the session upstart supposed  to see events like the above?
<alkisg_web> pitti, hi, would you mind if I pinged you about your opinion in https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/453605/comments/13 ?
<ubottu> Launchpad bug 453605 in udisks2 (Ubuntu) "Make default mount umasks configurable" [Undecided,Confirmed]
<jodh> pitti: at the session level, they should be prefixed with ':sys:'.
 * alkisg_web proposed to just drop dmask=0077 there, not to make it configurable...
<pitti> jodh: right, that's how I understood it; but they never seem to actually arrive
<pitti> jodh: i. e. if I see them in "sudo upstart-monitor", but not in "upstart-monitor" or "upstart-monitor -d session-socket", it smells like there's something wrong?
<pitti> jodh: likewise, /usr/share/upstart/sessions/update-notifier-cds.conf never fires, i. e. it's not seeing these events either
<pitti> alkisg_web: at first sight this seems sensible; I need to look into this more closely, I'll keep the tab open
<alkisg_web> pitti, thanks a lot
<jodh> pitti: sounds like a problem with the upstart-event-bridge. I believe xnox made changes to a number of the bridges recently so he might want to check the behaviour.
<pitti> jodh: ack, I'll wait for him then
<pitti> jodh: thanks
<pitti> xnox: on that note:
<pitti> /usr/share/upstart/sessions/update-notifier-cds.conf
<pitti> err
<pitti> MOUNTPOINT=$(udisks --show-info $DEVNAME | grep 'mount paths' | awk -F: {'print $2'} | sed -e 's/^ *//')
<pitti> how much more shell/grepping commands can you put into one line... :-)
<alkisg_web> Haha
<jamespage> morning all
<pitti> hey jamespage
<jamespage> any archive admins around with a spare hour? I have three new neutron-* source packages in the NEW queue for vivid which are refactorings of drivers from the main neutron codebase
<jamespage> I'd like to get them into vivid so we can complete testing of the openstack kilo-1 milestone :-)
<pitti> jamespage: I'll have a look
<jamespage> pitti, thankyou - much appreciated!
<pitti> mmmh, lintian clean
<pitti> â¥
<pitti> jamespage: btw, please stop using http://dep.debian.net/deps/dep5 as Format: field in d/copyright -- use http://dep.debian.net/deps/dep5/#format-field (it's an official standard now)
<pitti> jamespage: I mean, use what's written ther ( http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/), not literally the above :)
<jamespage> pitti, erg - sorry - that's probably just a copy paste error - I'll fix that up on next upload (doing some work on enabling the test suites atm)
<pitti> thanks
<pitti> jamespage: can you please also add Depends: ${python:Depends}?
<pitti> jamespage: reviewing neutron-fwaas ATM (might be similar in the other three)
<jamespage> pitti, ack
<pitti> jamespage: ok, if you show me a commit with the missing dep (which is quite serious), I'll accept this
<pitti> rest looks good; moving to vpnaas
<pitti> jamespage: vpaas is similar; except that neutron-vpn-agent has ${python:Depends} which is almost surely a no-op there (and should be on python-neutron-vpnaas)
<jamespage> pitti, http://paste.ubuntu.com/9793034/
<jamespage> pitti, that was for fwaas
<pitti> jamespage: ack, thanks; accepted fwaas
<pitti> jamespage: ok, no other issues found in vpnaas, exact same two as above
<jamespage> pitti, ok fixing in the same way
<pitti> jamespage: lbaas> same old, ok otherwise
<jamespage> pitti, ack - I have the same fix ready to go for both of those
<pitti> jamespage: ack, source-NEWed
<jamespage> pitti, is there a nice way to pull the source package from the NEW queue?
<jamespage> dget whinges alot
<pitti> jamespage: not that I'm aware of, I just usually grab all three files
<pitti> jamespage: yeah, each component has a different librarian ID :/
<jamespage> pitti, thanks for the review - very much appreciated - I owe you one (or three)
<pitti> jamespage: no worries :)
<jamespage> pitti, did the strongswan systemd compat get fixed?
<pitti> jamespage: let me know when you uploaded the fixes, then I'll binNEW them
 * jamespage looks
<pitti> jamespage: trying to remember if I uploaded that, hang on
<pitti> it's an utterly messy package, but I thought I did
<pitti> jamespage: yes, https://launchpad.net/ubuntu/+source/strongswan/5.1.2-0ubuntu5
<pitti> I'm now "touched it last", but I'm really not going to merge it
<pitti> nobody has bothered to merge it in ages :(
<pitti> and I don't nearly know enough about this to test a merge properly
<jamespage> pitti, urgh - I hate that
<jamespage> jpds has been its custodian in ubuntu - maybe he might like todo that merge :-)
<jamespage> pitti, ok - all three of those updates uploaded and built
<pitti> jamespage: ah, now that's a presentable Depends: now :)
<pitti> jamespage: all done
<jamespage> pitti, thanks!
<jpds> jamespage: The whole package has a revamp coming up, and there's nothing to "merge" from Debian.
<pitti> well, we have an enormous diff which looks quite noisy; essentially, we maintain it ourselves
<pitti> i. e. we have to do things like the systemd migration or other packaging updates ourselves
<pitti> and we are behind on the upstream version too
<jpds> pitti: Hence the revamp.
<pitti> I don't mind much, I just don't want to be held accountable for doing the next merge :)
<pitti> (as TIL)
<jpds> pitti: I talked to the Debian guys and they weren't interested in enabling half of the things strongSwan offers.
<pitti> jpds: if nobody expects us to merge, that's fine then :)
 * xnox loves ppc64el "wrong value for kill (job_pid, SIGKILL), expected -1 got -1"
<xnox> hits retry button
<LocutusOfBorg1> LOL
<pitti> xnox: hm, I was  about to test your new upstart silo, but I don't see it any more?
<pitti> xnox: oh, I figure that was https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu6 and it's in already; nice!
<xnox> pitti: didrocks tested it and we landed it. uploaded ubuntu7 now with correct session udev bridge job.
 * pitti hugs xnox and diddledan
<pitti> ... and didrocks too
<pitti> no cookies for me for laziness and tab completion damage
<xnox> pitti: however we want to implement globbing as well, such that one can wantedby android-container@foo.bar=val*.target (where "*" is actually systemd-escape'ed value \x3d or some such)
<xnox> pitti: and then the bridge will iterate through all jobs, and store globs, and upon glob match of event it will start: android-container@foo.bar=val*.target AND android-container@foo.bar=valfull_value_that_was_there.target
<pitti> xnox: so is https://code.launchpad.net/~xnox/upstart/no-classes/+merge/245948 "merged" now?
<xnox> pitti: yes.
<xnox> pitti: well superseeded by systemd-local-bridge branch and merged into different target - lp:ubuntu/upstart
<pitti> oh, it's not merged into trunk, but the ubuntu package
<xnox> pitti: jodh didn't want systemd silliness in lp:upstart
<pitti> *nod*, fair enough
<shadeslayer> pitti: errr .. hmm
<ricotz> xnox, hi, i guess ubuntu-dev-tools is missing a dependency on python-ubuntutools
<xnox> ricotz: possibly
<ricotz> meaning it broke here since python-ubuntutools isnt installed ;)
<xnox> uploaded
<ricotz> thanks
<teward> dobey: thanks for responding to http://askubuntu.com/questions/575775/is-it-possible-to-retire-packages-that-dont-stand-up-to-modern-usability-standa - i had initially popped into -release to have that answered, and they stated also that packages don't get removed unless it's legally compelled as such...
<dobey> packages only get removed from stable releases if legally compelled to do so. they can be removed from the in-developement archive for lesser reasons, but one guy saying "this is hard to use" is not a good reason
<dobey> especially for stuff that's just synced from debian and is in universe
<teward> dobey: indeed.
<cjwatson> Right, I said "for old releases" in #-release.
<teward> dobey: i saw a special-case, bitcoin, once - think it was a "too volatile to be updated" and such
<teward> but that was special-case
<cjwatson> teward: Please could you edit your misquoting comment that says "they don't remove any packages, unless compelled to for legal reasons"?
<dobey> teward: i think that was updated to be an empty package
<teward> cjwatson: i would have to delete the comment entirely - you would have to restate.
<cjwatson> I'm not going to get involved, but I want you not to be misquoting me.
<teward> cjwatson: granted i have 2% power on my laptop
<dobey> which is certainly doable if it makes sense to do
<teward> so it's deleted
<cjwatson> (I mean I'm not going to get involved on askubuntu)
<cjwatson> thanks
<teward> cjwatson: i know what you meant, it's deleted, problem solved, lets move on.
<teward> back in a bit, gotta find a power outlet
<teward> ... and coffee
<teward> so, the DMB made a suggestion when I got my PPU rights for nginx that there be an Ubuntu specific index.html for the nginx package, which would be installed based on $DEB_VENDOR - my question is, would such a test be automatic or need to be scripted into the install file(s)?
<teward> (part of the always-learning-the-system experience is asking questions when one is unsure, hopefully you don't mind the question)
<rbasak> teward: good question :)
<rbasak> teward: AFAIK, it needs to be scripted in debian/rules
<rbasak> Though maybe someone will come along and tell me about a debhelper feature that is better than that :)
<rbasak> Apache has a similar need, and the Debian maintainer did offer to do something similar. I was happy to maintain it as a delta though.
<rbasak> (so I don't have that for Apache currently)
<teward> mhm
<teward> rbasak: the issue with nginx is that they ship a Debian-specific index.html
<teward> pointing back to BTS and Debian bug reporting methods
<rbasak> Yeah, same with Apache.
<teward> rather than ours - hence the DMB recommendation
<teward> (the latest merge, just went and hacked away at the shipped index.hml)
<teward> index.html*
<rbasak> teward: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1288690
<ubottu> Launchpad bug 1288690 in apache2 (Ubuntu Trusty) "default page is debian branded" [High,Fix released]
<teward> ooo i should probably check trusty and utopic for this bug... if it exists, make it for nginx
<teward> rbasak: darn it, you're adding to my bugs lists!  >.<
<teward> (just kidding)
<teward> rbasak: thank goodness only vivid is affected by this
<teward> and the PPAs, but i'm lazy with updating those considering i spent almost a month hammering out code issues >.<
<rbasak> ScottK: can I have an opinion from you on bug 1412830 please? sa-update or SRU?
<ubottu> bug 1412830 in spamassassin (Ubuntu) "[AHBL] spamassassin is returning false positives by default" [Critical,Confirmed] https://launchpad.net/bugs/1412830
<ScottK> Looking
<ScottK> rbasak: sa-update is disabled by default, so I think an SRU is appropriate.
<rbasak> ScottK: OK, thanks. I'll arrange it.
<ScottK> (Note: the Debian SA maintainer is considering changing that default for a future release)
<ScottK> great
<shadeslayer> mvo: any news wrt the synaptic SRU?
<pitti> slangasek, stgraber, kees: TB meeting in 9 mins; mdeslaur and infinity sent their apologies; I'm still in a hangout, but I'll watch with half an eye
 * slangasek nods
<slangasek> who's the chair today?
<Riddell> pitti: kde-sc-dev-latest back in the archive now
<pitti> Riddell: ah, was it removed? that explains why they suddenly started failng without there being an upload for it
<Riddell> pitti: yes sorry, I removed meta-kde but I've put it back now with only kde-sc-dev-latest
<Riddell> (which we don't use but we need it to stop a muckle diff from debian)
<pitti> Riddell: ack, thanks! I'll wait  until it's published and then retry all the tests
* cjwatson changed the topic of #ubuntu-devel to: Archive: open | upload.ubuntu.com maintenance 1800-1805 UTC | 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:
<cjwatson> (hopefully will be more like seconds, but just in case anything goes wrong)
<teward> repots of my question just in case someone knows another method other than scripting in debian/rules... teward> so, the DMB made a suggestion when I got my PPU rights for nginx that there be an Ubuntu specific index.html for the nginx package, which would be installed based on $DEB_VENDOR - my question is, would such a test be automatic or need to be scripted into the install file(s)?  (I admit I don't know everything, but I wish to learn
<teward> best practices)
<teward> grah, evil irc truncation!  *shakes fist*
* cjwatson 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:
<mvo> shadeslayer: I have uploaded it, its wating in the utopic-proposed queue
<shadeslayer> yay
<shadeslayer> mvo: thx :)
<mvo> thank you for preparing the diff!
<shadeslayer> :)
#ubuntu-devel 2015-01-21
<pitti> Good morning
<dholbach> good morning
<pitti> jamespage: the neutron regression looks real (ERROR: HYPERV PLUGIN IS NOT RUNNING); maybe some glitch with the new generated init.d/upstart job scripts?
<pitti> the other tests succeeded
<jamespage> pitti, looking at that now
<pitti> jamespage: if you think it's a race, I'm happy to restart, but so far they seemed pretty stable
<jamespage> pitti, interesting
<jamespage> pitti, the package in updates also does the same thing; installs and then shutsdown straight away due to missing configuration
<jamespage> pitti, I guess we where race lucky before :-(
<pitti> jamespage: you mean s/updates/vivid/, I presume? ah, so it didn't wait long enough for the startup to actually finish?
<jamespage> pitti, quite possibly
<jamespage> pitti, I'll look at test tests again
<sladen> I'm out of touch, who holds the keys for developer.ubuntu.com?
<sladen> ...there's a broken example that I'd love to just-fix in 30 seconds
<sladen> instead of begging other people to do
<sil2100> mitya57: hey! So I made qtserialport-opensource-src buildable on amd64, which made qtdoc-opensource-src buildable and made other things buildable as well - waiting for pyqt5 to finish now
<sil2100> mitya57: my fix for qtserialport-opensource-src was really really dumb but I confirmed that it was actually working on a chroot
<zyga> stgraber: hi, what's the most Ubuntu-portable way of using the freezer subsystem?
<zyga> stgraber: I want to run a process in a new cgroup and once it terminates, freeze that cgroup, inspect any children if may have created (and kill them)
<LocutusOfBorg1> hi developerz!
<zyga> stgraber: I'd like to support Ubuntu 14.04+ but 12.04 (with LTS kernels) would be also nice
<zyga> stgraber: is there a intermediate service I should be talking?
<zyga> stgraber: systemd / cgroupmgr / something else?
<mitya57> sil2100: o_O, I can't believe that simply swapping two lines fixed it
<mitya57> Is it a bug in debhelper?
<mitya57> I thought that file was not generated at all (even reported that as https://bugreports.qt.io/browse/QTBUG-43846)
<sil2100> mitya57: now this is something I don't understand - from my various experiments in an chroot this is actually what fixed it
<sil2100> mitya57: as after removing it completely from the .install it was mentioning that it's there but not installed
<mitya57> Weird
<mitya57> Anyway, thanks for finding the solution!
<mitya57> Now I need to do something with qtwebsockets failure on powerpc
<sil2100> mitya57: and really - in the original order it wasn't generated, but when the -index one is first, is magically gets built - I wonder if that's not some race somewhere, but yeah...
<sil2100> Maybe there would be a better solution, but at least this one works ;p
<mitya57> In the report I linked upstream also suggested that it's a race condition
<mitya57> sil2100: FYI: https://codereview.qt-project.org/103701
<mitya57> Maybe at some point in the future we'll be able to drop appmenu-qt5 completely
<sil2100> mitya57: huh, that's something new!
<sil2100> mitya57: need to see how they're trying to do that, but yeah, I wouldn't mind this being upstream
<alexbligh1> rbasak, I hate to bug you, but have you had a chance to look at LP#1366174 ?
<mitya57> sil2100: that is a very early WIP, no real code yet.
<rbasak> alexbligh1: sorry. I haven't forgotten. I'm still working on MySQL :-(
<alexbligh1> rbasak, my commiserations ...
<rbasak> I don't mind you pinging me though. Please do lest I forget. I will get to it eventually.
<alexbligh1> rbasak, you may regret saying that ...
<rbasak> I'm also spending an hour a day now on mentoring others to remove me as a bottleneck for this stuff.
<alexbligh1> Did ubottu die, or does he no longer like decoding bugs in LP#1366174 format?
<Unit193> LP #1366174
<ubottu> Launchpad bug 1366174 in apache2 (Ubuntu Trusty) "apache2 SEGV with multiple SSL sites" [High,Triaged] https://launchpad.net/bugs/1366174
<alexbligh1> I could have sworn that worked without the space before.
<Unit193> Nope.
<alexbligh1> I stand corrected then.
<Unit193> There's a couple different formats it likes, but it likes the space.  It'll do links too of course.
<LocutusOfBorg1> arges, thanks!
<arges> LocutusOfBorg1: no problem
<mdeslaur> pitti: "Note that I'm not claiming the merging for this package" - lol, nice try :)
<pitti> mdeslaur: which one was that?
<mdeslaur> pitti: samba...it made me chuckle, that's all :)
 * rbasak ponders adding a disclaimer to every changelog of every upload :-P
<pitti> well, I don't think it's unfair; I earn a ton of merges already because people don't merge their's; I don't want to be penalized even further by fixing the archive with no-change uploads :)
<LocutusOfBorg1> pitti, can I merge samba then? the merge is easy, no conflicts
<pitti> if you want to, please
<LocutusOfBorg1> as soon as I finish testing for bug 1411507
<ubottu> bug 1411507 in virtualbox (Ubuntu) "[SRU] virtualbox-guest-dkms 4.3.10-dfsg-1: virtualbox-guest kernel module failed to build [error: 'generic_file_aio_read' undeclared here (not in a function)]" [Undecided,New] https://launchpad.net/bugs/1411507
<LocutusOfBorg1> pitti can you sponsor it or should I open a bug?
<LocutusOfBorg1> I can send the debdiff by mail
<pitti> LocutusOfBorg1: bug probably works better in case some other sponsor gets to it earlier, but mail WFM too
<stgraber> zyga-afk: cgmanager is your best bet for that I think
* Laney changed the topic of #ubuntu-devel to: Archive: open (alpha 2 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:
<arges> Laney: hey. mind if I merge virt-manager? it will fix a bug for me.
<LocutusOfBorg1> I think I send it, I can open a bug if needed
<Laney> arges: no attachment there, go wild
<arges> Laney: yay. thanks
<hallyn> pitti: hey.  on bug 1411978, others have reported this.  It seems to happen when you switch to systemd and then back again.  maybe dbus ges removed?  i personally don't think cgmanager is to blame but i could be wrong
<ubottu> bug 1411978 in cgmanager (Ubuntu) "cgmanager and udev 208-8ubuntu8.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Low,Confirmed] https://launchpad.net/bugs/1411978
 * hallyn tries in a container
<pitti> hallyn: yeah, I followed up there explaining that booting and upgrading with systemd in utopic is unsupported and known broken, so feel free to just invalidate
<hallyn> pitti: you actually said "with upstart", so i got confused
<pitti> hallyn: oh, did I? argh
<hallyn> :)
<pitti> followed up
<pitti> hallyn: wah, wah, hate init systems! :-)
<hallyn> pitti: see bug 1407954 for a dup
<ubottu> bug 1407954 in cgmanager (Ubuntu) "package cgmanager 0.32-4ubuntu1.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1407954
<pitti> hallyn: AFAIK cgmanager isn't even using the system d-bus, is it? it implements its own server
<hallyn> no, but the upstart init job starting does
<hallyn> so i htink it's a pakcaging bug with systemd or more likely upstart
<hallyn> though, hm, dbus shouldn't be required
<hallyn> worthwhile question might be "how did you switch back to upstart'
<seb128> apw, hey, your most recent casper upload doesn't seem to be in the vcs, is that a push omission?
<apw> seb128, that'd be me doing it wrong i recon
<apw> seb128, shall i repair that ?
<seb128> apw, that would be great, thanks :-)
 * apw slaps self
<apw> seb128, ok i think that is repaired
<seb128> apw, looks so, thanks!
<apw> seb128, thanks for catching, and checking
<hallyn> stgraber: weren't there autogenerated docs on the lxc api posted somewhere?  (they're no tlinked on https://linuxcontainers.org/lxc/introduction/)
<stgraber> hallyn: they're linked from the documentation page
<stgraber> hallyn: https://linuxcontainers.org/lxc/apidoc/
<hallyn> awesome, thanks
<hallyn> stgraber: oh, i see.  ihave to use menus to find the docs page :)
<hallyn> iow, my non-javascript browser is sol
<stgraber> hallyn: works in w3m :)
<hallyn> course the apidoc page itself requires js so just as well
<stgraber> but yeah, I guess a graphical browser which does CSS but no JS would be a problem
<zyga> stgraber: can I use cgmanager on 12.04 as well?
<zyga> stgraber: or can I just do wild-west manual cgroup poking there and don't look back>?
<stgraber> zyga: cgmanager works fine on 12.04 though it's not in the archive so you'll need a backport (like the ones we maintain in ppa:ubuntu-lxc/stable)
<zyga> stgraber: that sounds okay
<zyga> stgraber: how about on the phone, the codebase I work on supports 12.04+ and the phone
<stgraber> cgmanager is on the phone and used by default by upstart and the app launcher
<zyga> excellent, thanks
<zyga> I'll google for the API and see what we can do with it
<zyga> stgraber: just one last question, how does it cooperate with systemd?
<stgraber> works fine alongside it, they usually don't touch the same cgroups
<zyga> stgraber: ok
<zyga> stgraber: my use case is to put a process in a new cgroup and freeze it at some point time later (to reliably kill all children)
<jamespage> anyone know which bit of systemd populates /etc/machine-id ? and what should happen on a upstart based system?
<mitya57> sil2100, returning to appmenu-qt5: can I land it?
<jamespage> context: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1413293
<ubottu> Launchpad bug 1413293 in nova (Ubuntu) "Unable to start instances, empty /etc/machine-id file." [Undecided,New]
<sil2100> mitya57: yeah, it should be fine to do so - I double tested that all works fine even without Qt 5.4
<mitya57> sil2100, then I will now land three my branches :)
<jamespage> utlemming, smoser: reading http://www.freedesktop.org/software/systemd/man/systemd-machine-id-setup.html is this something we need todo for vivid on first boot for cloud-images?
<jamespage> ^^ see above bug for context
<utlemming> jamespage: looking
<jamespage> utlemming, 14.04 deploys don't get that file, so I'm wondering whether its a bit of cruft from the build process for vivid
<jamespage> esp as vivid is still upstart right now
<utlemming> jamespage: I think this is an artifact of us switching from cloud image custom live build to using a stock live build
<smoser> reading
<smoser> it would seem, yes. that we shoudl set that
<xnox> jamespage: at the moment /etccc/machine-id is borked up on ubuntu
<xnox> jamespage: it should be done by "first boot job" or the "installer", in practice it's done on the livefs builder and thus all ubuntu desktops have the same one.
<xnox> dito dbus machine-id
<Odd_Bloke> xnox: jamespage: Am I right in thinking that we would (ideally) not have /etc/machine-id on the images at all (so it'll be generated at boot time)?
<xnox> jamespage: smoser: ideally, the livefs builder should be fixed to delete/omit those. But then something should be enabled to generate it properly.
<jamespage> Odd_Bloke, xnox: on a systemd boot, if its empty it gets populated automatically
<xnox> Odd_Bloke: yes.
<jamespage> just not under upstart
<jamespage> so removal for now might be best
<xnox> jamespage: cool. needs an upstart job + removal on the image builder
<jamespage> dumb here just thought he'd try a complete openstack deploy with systemd
<jamespage> however forgot that juju only installs upstart configs right now :-)
<jamespage> bang!
<xnox> =)))))
<SpamapS> smoser: https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1413279 <-- I won't have time to fix until about 3 weeks from now, but it might be a pretty easy fix for you to slam in there... just sayin.
<ubottu> Launchpad bug 1413279 in ifupdown (Ubuntu) "upstart event static-network-up emited to early" [High,Triaged]
<Odd_Bloke> We intentionally truncate /etc/machine-id at the moment (rather than deleting it).
<smoser> SpamapS, well, isn't bug 1413279 a dupe of bug 1379427 ?
<ubottu> bug 1413279 in ifupdown (Ubuntu) "upstart event static-network-up emited to early" [High,Triaged] https://launchpad.net/bugs/1413279
<ubottu> bug 1379427 in ifupdown (Ubuntu) "/etc/network/if-up.d/upstart emits static-network-up to early" [High,Triaged] https://launchpad.net/bugs/1379427
<smoser> second, "family" isn't really enough... as i could quite reasonably have 2 or more ipv6 addresses configured for an nic, couldn't i?
<SpamapS> smoser: first: yes. second: yes you can, but ifup won't return until they're all assigned.
<smoser> ah. that would seem to make sense then.
<SpamapS> man page is somewhat silent on duplicate sections
<SpamapS> smoser: unfortunately I think this might mean you have to touch ifquery :-/
<SpamapS> smoser: as it makes no distinction on family
<LocutusOfBorg1> pitti, sorry, mdeslaur pushed a samba update, should I redo the merge?
<mdeslaur> LocutusOfBorg1: sorry about that
<LocutusOfBorg1> no need to be sorry, I'm just asking how to proceed :)
<LocutusOfBorg1> I think you will override also another upload because of CVEs (virtualbox)
<LocutusOfBorg1> I'm preparing the debdiff right now (this week I hope)
<Odd_Bloke> jamespage: xnox: So mvo added a patch to (just) truncate /etc/machine-id on 2014-10-29; his comment reads "truncate, do not remove otherwise systemd is unhappy". Has systemd learned to cope with it missing since then?
<jamespage> Odd_Bloke, not sure
<xnox> Odd_Bloke: no. something should generate it. systemd can cope with it not being there, only when the whole /etc is empty as far as i can tell.
<xnox> (well precisely condition first boot is satisfied)
<xnox> Odd_Bloke: mvo: actually looking at recent source code from systemd, if /etc/machine-id is not present conditionfirstboot is satisifed and then units that have conditionfirstboot are triggered
<xnox> e.g. set presets, generate machine id, etc....
<pfsmorigo_> cjwatson, hi, some of the fixes in grub2 needs to be added to 14.04 as well. 14.04 seems to be using release 9 and all our fixes are after that...
<cjwatson> slangasek,infinity: ^- could one of you help pfsmorigo_ out?
<cjwatson> pfsmorigo_: I moved to the Launchpad team at the start of the year - I'm still maintaining grub2 in Debian, but hopefully slangasek can give you a new routine contact for Ubuntu grub2 things
<pfsmorigo_> cjwatson, I see
<cjwatson> There's an ubuntu/trusty branch in the Debian git repository, which ideally would be kept up to date; infinity has access or I can give it to others
<infinity> I do indeed have access, haven't looked at it since the switch to the new patch system.
<cjwatson> http://lists.alioth.debian.org/pipermail/pkg-grub-devel/2014-January/013883.html has some recipes.
<infinity> pfsmorigo_: Can you highlight the fixes that need SRUing, file some bugs (or if bugs already existed and were closed, point them out to me), etc?
<pfsmorigo_> infinity, LP#: 1334793, 1338471, 1295255...
<pfsmorigo_> infinity, do you prefer that I open a new lauchpad with all patches so you can apply it?
<pfsmorigo_> infinity, there are two fixes without launchpad
<infinity> pfsmorigo_: One bug that points at all the fixes might be helpful.
<pfsmorigo_> infinity, ok, will do that
<pfsmorigo_> infinity, tks
<hallyn> say, https://bugs.launchpad.net/bugs/1412671 is telling me i took a wrong turn.  but that's the buglink in the bug email i'm looking at.  is launchpad having trouble?
<ubottu> Error: launchpad bug 1412671 not found
<hallyn> exactly
<infinity> hallyn: Could be a private bug you're not subscribed to.
<hallyn> d'oh, right.  i thought i was logged in, but maybe i'm not
<hallyn> hm, i am
<sarnold> I can't see it either; it's marked private
<hallyn> well that's a shame :)
<hallyn> i figured if it ws marked private, package owners would still be able to se eit
<hallyn> looks like i misunderstood
<sarnold> I always get a giggle when I see someone file a bug report Private Security then beg for help then mark it Private -- and no one else will ever see that bug again...
<hallyn> but i often see private bugs tha i can open.  i'm confused.  what is one supposed to do then?  is the bug submitter supposed to add people s/he trusts?
<sarnold> good question :/
<hallyn> ok completely separate question - libvirt needs libcurl-dev to build --with-esx.  apt is telling me i have to choose between openssl, nss, and gnutls versions.  which do we recommend?  all 3 are in main...
<mdeslaur> hallyn: it's a licensing issue
<hallyn> oh gah
<hallyn> now that you mention it i recall libvirt having to deal with that
<teward> any way to achieve distro-specific pages (for default pages in a webserver) without scripting debian/rules to specify the file to copy over?  (maybe in the .install file, or some other method with debhelper or such?)
<hallyn> mdeslaur: so do you know offhand whichone to use with lgpl code?
<mdeslaur> hallyn: is there an openssl exception in that lgpl code? if not, I think gnutls
<mdeslaur> hallyn: this is what, libvirt?
<mdeslaur> since libvirt already build-deps on libgnutls-dev, I'm guessing the curl gnutls backend would be appropriate
<hallyn> mdeslaur: yeah libvirt, and gnutls is mentione din configure.ac, so i'm going with that - thanks
<infinity> teward: Doing it in Debian rules based on dpkg-vendor is probably your best option.
 * Snow-Man is really anxious for a new kernel which fixes #1404558. :(
<infinity> Snow-Man: Test out the kernel in -proposed, pretty please?
<infinity> Snow-Man: Enable trusty-proposed, apt-get install linux-image-generic, disable proposed.
<Snow-Man> it was tested and confiirmed?
<infinity> Snow-Man: Since it seems to be an intermittent issue, more testing would be nice.
<infinity> Snow-Man: But stgraber's testing has been good.
 * Snow-Man sighs.
<Snow-Man> having a bug that completely breaks ipv6 be released is pretty terrible and that it's taking this long to get it fixed is extremely frustrating. :(
<infinity> stgraber: It's been 5 more days since you commented, are you still confident that LP: #1404558 is fixed?
<ubottu> Launchpad bug 1404558 in linux (Ubuntu Trusty) "IPv6 related kernel panic following upgrade to 3.13.0-43" [Critical,Fix committed] https://launchpad.net/bugs/1404558
<infinity> Snow-Man: Our kernel SRU process really doesn't allow for rapid turnaround of every single patch and bugfix (we pull out all the stops and burn a lot of hours to do emergency security updates, but we can't push a new kernel every two days for every bug).
<infinity> Snow-Man: So, frustrating, yes, but the alternatives are worse. :/
<Snow-Man> infinity: How about a bit more testing w/ ipv6 before releasing it to the masses? :/
<infinity> Snow-Man: I'm all for that.  Though, in this case, it seemed to need a 24h burn test w/ IPv6.  Most testsuites are geared to testing specific functionality.
<Snow-Man> it definitely didn't take that long to trigger here
<infinity> Snow-Man: Not saying testing can't be improved, it always can be, but bugs happen. :(
<Snow-Man> it was more about the amount of ipv6 activity.
<stgraber> infinity: yep, still no kernel panic
<infinity> Snow-Man: Anyhow, based on stgraber's comment, and his lack of followup in 5 days, I'm assuming the -proposed kernel will make your machine happy.
<infinity> Snow-Man: Oh, and look, even better. :)
<infinity> stgraber: Thanks.
<Snow-Man> I'm going through and installing the kernel from proposed on my various VMs, but it'll take me a few hours to get it done.
<Snow-Man> I would have preferred to not deal with pulling in -proposed and then having to do another round of upgrades in the relative near-term, but it is what it is.
<infinity> Snow-Man: The testing versus reactive thing is a bit of a rock and a hard place.  The reason the kernel in proposed isn't released yet is because we do a bunch of testing, and it's not all done yet.  The reason the bug happened is because we need more testing, always.  Never seems to be enough.
<Snow-Man> ugh.  I dunno why, but v6 from the ubuntu mirrors isn't working out too well for me either atm. :/
<stgraber> Snow-Man: us.archive ?
<Snow-Man> yes
<stgraber> Snow-Man: over an HE.net tunnel?
<Snow-Man> sixxs, but with an HE pop
<stgraber> ok, so yeah, known issue, it's been broken for over a week now
<stgraber> the route goes through Internap and they've got some bad config which drops everything on the floor at the moment
<Snow-Man> :(
<stgraber> there are Canonical, HE.net and Internap tickets open about the issue
<JanC> the problem with bugs that only happen "once in a while" is often that they may happen more often for one test environment than for another; they may happen once every minute for the user and once every month for the developer trying to fix it...  :-/
<pfsmorigo_> is there a way to access shell directly when I do a ssh into the installation?
<pfsmorigo_> ssh installer@ip shows me a menu directly
<sarnold> pfsmorigo_: try "ssh installer@ip /bin/bash"  ?
<pfsmorigo_> sarnold, nope, it still shows the meny
<pfsmorigo_> *menu
<pfsmorigo_> sarnold, maybe if I log as root@
#ubuntu-devel 2015-01-22
<bdmurray> arges: the state of bug 1401523 is rather odd? comment #8 mentions precsie but the lucid task was change and comment #9 mentions lucid and no task was changed. Do you know what might have happened?
<ubottu> bug 1401523 in Landscape Client "Update lucid, precise, trusty, utopic to landscape-client 14.12" [Medium,New] https://launchpad.net/bugs/1401523
<slangasek> mlankhorst: hi, I've been looking over the last of the LTS stack uploads for 14.04.2, and noticed that xorg-server-lts-utopic is at version 1.16.2.901... when utopic itself is only at 1.16.0.  Can you explain the discrepancy?
<slangasek> RAOF: ^^ or maybe you have some context for this
<RAOF> Hm. Did I fail to question mlankhorst about that?
<RAOF> Huh. Seems I didn't include that with my other queries.
<slangasek> RAOF: ah, do you have outstanding queries?
<slangasek> RAOF: I just reviewed the mesa one and it looked to me like it checked out, hope I haven't screwed anything up
<RAOF> A couple of nitpicks.
<slangasek> nitpicks can presumably be fixed post-accept then
<RAOF> Stuff like the empty Conflicts: stanzas and such.
<RAOF> Yeah, can be fixed post-accept.
<RAOF> I think I may be missing something, though. Maarten was resistant to fixing some clearly-incorrect things that I queried. They might be difficult to entirely script, but seemed like they could be trivial to fix (and quicker to fix than to argue about âº) before uploading.
<slangasek> right, AIUI the lts-* package translations are completely automatic at this point
<slangasek> so if he fixed them by hand this time, would it just regress with the next upload etc
<RAOF> Well, it'd be something that would need to be done for each upload, yes.
<infinity> Or fix the tools.
<infinity> Because that's the only road to consistency.
<infinity> "It's hard" isn't a good enough excuse to not fix something.
<RAOF> The ability to easily fix sed is limited :)
<infinity> RAOF: Fix sed? :P
<RAOF> :)
<infinity> RAOF: Oh, like empty Conflicts?  That'll wash out in dpkg-gencontrol (it won't show up in the binary).
<infinity> Fairly sure, anyway.
<infinity> That said, line deletion in sed isn't rocket science.
<RAOF> And I guess won't show up in further debdiffs.
<RAOF> But an incorrect Homepage: field will.
<infinity> An incorrect Homepage would be incorrect in both the source and the destination of the backport, no?
<infinity> So, it should be fixed in both or neither.
<infinity> Not worth a nitpick for just the backport.
<RAOF> No, the backport script *changes* the Homepage field so as to be incorrect.
<infinity> RAOF: ...
<infinity> Why would it even touch it?
<RAOF> Because it doesn't understand debian/control at all, it just runs sed s/xf86-video-mtrack/xf86-video-mtrack-lts-utopic/g over it?
<infinity> RAOF: Oh, is it some overexhuberant "s/$package/lts-$package/" across all of debian/control?
<infinity> Yeah.
<infinity> That's silly.
<RAOF> Right.
<infinity> For 1-line fields, that's easy to limit scope, but I can see if he wants to hit up descriptions or line-wrapped deps, it gets tougher without actually processing rfc822 properly.
<infinity> Which would stop being a job for sed and start being a job for awk, at the leanest, or a perl or python module, at the heaviest.
<slangasek> '/Homepage/ ! { [...] }'
<slangasek> fixed
<infinity> slangasek: Oh, sure, EXCLUDING fields is easy, I meant limiting inclusion to only certain ones can be tough.
<slangasek> true
<slangasek> but if the only bug so far is with Homepage, JFDI and move on
<infinity> Yeah.
<infinity> slangasek: Though, the Homepage thing is a cosmetic bug, the worrying bug is the unbounded replacement, which could theoretically have other consequences $later.
<slangasek> RAOF: and xf86-input-wacom-lts-utopic looks fine to me, have I missed something?
<infinity> Not that I'd reject an upload because of a tooling bug that might break on a subsequent upload. :P
<RAOF> slangasek: No, I must have just missed that in my batch clicking.
<slangasek> infinity: right, well, you could also fix it by fixing the sed to word boundaries, since the package name isn't going to appear on its own in other fields
<slangasek> RAOF: ok, accepted
<slangasek> RAOF: did xserver-xorg-video-intel-lts-utopic also get reviewed?
<RAOF> slangasek: No.
<infinity> slangasek: Right, and that fixes the most obvious potential bug, which is "what if your package name is a substring of another package name that happens to also show up in debian/control?"
<slangasek> q fetch xserver-xorg-video-intel-lts-utopic-antidisestablishmentarianism
<RAOF> Oh, you have some extra tools not in ubuntu-archive-tools?
<infinity> mlankhorst: Fixing RAOF's Homepage complaint, and the above potential bug could be done by implementing slangasek's suggestion to make your packagename substitutions bound on word separators.
 * RAOF was meaning to ask about that; it was somewhat cumbersome to review those things
<infinity> RAOF: q is queue.
<slangasek> yeah
<infinity> RAOF: For hysterical raisins, many people have it aliased.
<slangasek> cjwatson brand raisins
<slangasek> (I'm sure he'll appreciate that highlight)
<RAOF> Ah, I'm missing pytz so didn't get the help for that.
<slangasek> mlankhorst, RAOF: similar issue with xserver-xorg-video-intel; the version in the SRU queue doesn't match the version in utopic (2.99.916 vs. 2.99.914)
<infinity> Also, I haven't checked the fallout yet, but were these all being overridden to the right component (main/universe, as appropriate, based on their location in utopic) before accepting?
<RAOF> infinity: I'm pretty sure I got the overrides right
<infinity> RAOF: Kay.  I'll be double-checking anyway, but saves a bunch of pain if it turns out to be right. :)
<infinity> mesa-lts-utopic is wrong.
<infinity> Was that vorlon's fault just now?
<RAOF> Yes :P
<infinity> I wonder if he highlights on vorlon on networks where here's slangasek.
<slangasek> infinity: what did I miss?  oh, the component?
<slangasek> yeah sorry
<infinity> slangasek: I'll fix.
<infinity> slangasek: Did you miss any others too?
<Snow-Man> infinity: alright, I'm up on the new -45 w/ all my boxen.
<Snow-Man> Nothing's crashed yet.
<slangasek> infinity: xf86-input-wacom-lts-utopic
<slangasek> infinity: I'm consistent
<infinity> slangasek: I'll just override the rest in the queue now.
<slangasek> ack
<infinity> And done.
<cjwatson> slangasek: I thiiiiink 'q' was a Keybuk thing, but not sure
<elmo> infinity: he does
<infinity> elmo: And so do you?
<cjwatson> would've been back when new-cycle auto-syncs were a multi-day nightmare
<cjwatson> infinity: elmo just highlights on everything, to save time
<infinity> Smart.
<infinity> cjwatson: Hey, launchpad guy.  If a source is accepted in universe, goes dep-wait, and is overriden to main before the dep-wait clears, will the build happen in main or universe?
<infinity> cjwatson: I'm pretty sure it does the lookup at dispatch time, and that's what buildd-manager feeds to the slave, but I can never remember if that's fact or wishful thinking.
<infinity> wgrant: Since it's more your working hours. ^
<cjwatson> dispatch time, yes
<wgrant> As Colin says.
<infinity> cjwatson: Also, I'd be inclined to blame pitti, since I think his entire life revolves around single-char aliases.  But that might not work, cause 'q' might predate him being an AA.
<infinity> The best gift we could give him would be a keyboard with twice as many keys.
<cjwatson> could be
<slangasek> y
<cjwatson> I think m for madison-lite was my fault though
<arges> bdmurray: i reviewed it for precise/lucid; When I did the precise 'sru-review' I ctrl-c'd the window accidentally and forgot to flip the bugstate after adding the message.
<bdmurray> arges: okay, just wanted to make sure some tool wasn't broken
<Unit193> pitti: Howdy.
<pitti> LocutusOfBorg1: samba merge> if you want to, please :) Happy to sponsor
<pitti> hey Unit193
<pitti> Good morning
<pitti> infinity: h!
<pitti> xnox: \o/ lazr.restfulclient, thanks! I took the liberty of syncing it from exp
<mlankhorst> morning
<dholbach> good morning
<LocutusOfBorg1> hi dear folks
<ochosi> hey dholbach
<dholbach> hi ochosi
<ochosi> may i bug you for a sec?
<dholbach> sure
<ochosi> thanks!
<ochosi> ok, so just quickly, because i'm going away over the weekend...
<ochosi> since you approved the MR https://code.launchpad.net/~thad-fisch/ubuntu/vivid/xdg-utils/lp1363540/+merge/246820
<dholbach> I don't think I'm the best person to make a decision about this one
<ochosi> i wanted to mention that we plan to SRU this to trusty, so it'd be great to get it into the archive soonish
<ochosi> ah
<dholbach> seb128, ^ do you think somebody on the desktop team can review this?
<ochosi> right, i mean it's not too problematic, all in all it's just a shell script ;)
<dholbach> well....
<ochosi> but sure, if we need somebody else to review it, that's fine and good to know
<seb128> dholbach, sure, I was sort of hopping that didrocks would get to it during his sponsoring shift on tuesday, but it seems that didn't happen there
<ochosi> thanks seb128 (and dholbach)!
<ochosi> since i'm going to be away for a week after today, i just felt like following up on a few things
<didrocks> dholbach: yeah, I was quite busy yesterday, but as told early this morning to seb128, I'm going to shift with today (this afternoon, to be precise)
<dholbach> yoohoo
<seb128> didrocks, ok, letting it to you then, thanks ;-)
<didrocks> yep :)
<ochosi> didrocks: if there are any questions about it, feel free to bug me!
<ochosi> at least today i should be aroundish
<didrocks> ochosi: will do!
<didrocks> thanks
<mlankhorst> infinity: afaict word bounaries don't include hyphens, which are used in package names..
<mlankhorst> meh weird.. dpkg-control looks like it should be smart enough
<mlankhorst> hm, description, vcs-git and vcs-browser are unmodified, i should do the same for homepage then
<mlankhorst> that was easy to fix..
<mlankhorst> the reason it was renamed was because xf86-input-mtrack was in the mapping file, and I didn't special case homepage. Not because it was the source name.
<mlankhorst> something like -lts-utopic-lts-utopic could never have happened on the debian/control file, because dpkg-control parses it
<mlankhorst> -        elif 'Description' == prop or 'Vcs-Git' == prop or 'Vcs-Browser' == prop:
<mlankhorst> +        elif 'Description' == prop or 'Vcs-Git' == prop or 'Vcs-Browser' == prop or 'Homepage' == prop:
<mlankhorst>              print orig_line
<cjwatson> prop.lower() in ("description", "vcs-git", "vcs-browser", "homepage")
<cjwatson> you know it makes sense
<mlankhorst> none of the affected packages have that :P
<cjwatson> You can still make the code less repetitive :)
<mlankhorst> it's code that runs once every 6 months, cost/effort analysis points to keep it like it is
<Odd_Bloke> Hmph, removing /etc/machine-id doesn't seem to work: http://paste.ubuntu.com/9816701/
<Odd_Bloke> (I'm switching to systemd by doing https://wiki.ubuntu.com/systemd#Installing_systemd without the PPA bit; is that correct?)
<pitti> Odd_Bloke: please rather use https://wiki.ubuntu.com/SystemdForUpstartUsers#Switching_init_systems
<pitti> Odd_Bloke: don't bother with trying this on anything < 14.10; on 14.10 you can experiment with systemd but there are lots of known failures especially on package upgrades
<pitti> Odd_Bloke: it's only really supported on vivid
<Odd_Bloke> pitti: OK, cool.
<mlankhorst> huh?
<mlankhorst> how did mesa build without llvm 3.5
<mlankhorst> oh right, only on archs without llvm
<pitti> Odd_Bloke: I added an outdated warning and a ref to the above page
<Odd_Bloke> pitti: Thanks!
<LocutusOfBorg1> pitti I feel stupid, but doesn't MoM grab the proposed stuff automatically?
<LocutusOfBorg1> https://merges.ubuntu.com/s/samba/
<LocutusOfBorg1> still listing ubuntu3
<pitti> LocutusOfBorg1: it might be a bit behind; but indeed I don't believe it's looking at -proposed at all
<LocutusOfBorg1> and I don't see it http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#samba
<LocutusOfBorg1> what is blocking the migration?
<pitti> ah, held by freeze
<Laney> look at excuses first, then output
<LocutusOfBorg1> ah, yes, the html page is more comphrensive
<LocutusOfBorg1> so what should I do? just wait for -release, wait for MoM and ping you?
<pitti> LocutusOfBorg1: or grab the diff from proposed and apply it to your merge
<pitti> http://launchpadlibrarian.net/195481264/samba_2%3A4.1.11%2Bdfsg-1ubuntu3_2%3A4.1.11%2Bdfsg-1ubuntu4.diff.gz
<pitti> dear LP developers, I love this feature
<LocutusOfBorg1> mmm yes, but how? patch -p1 and resolve?
<pitti> LocutusOfBorg1: pretty much, yes; there's a chance that the security fix is already applied in Debian, in which case it's only adding the new changelog
<pitti> hm, no, it's not
<pitti> or maybe it's fixed in 4.1.13 already?
<LocutusOfBorg1> nope
<LocutusOfBorg1> seems not fixed
<LocutusOfBorg1> but I'm trying to apply right now
<LocutusOfBorg1> at least in source.debian seems not applied
<LocutusOfBorg1> https://sources.debian.net/src/samba/2:4.1.13%2Bdfsg-4/librpc/idl/security.idl/
<LocutusOfBorg1> nope 4.1.13 is from 3 months ago
<LocutusOfBorg1> the git commit id is from two days ago
<LocutusOfBorg1> done!
<LocutusOfBorg1> mail sent, can I forget about samba?
<LocutusOfBorg1> looking to fix the 6 virtualbox CVEs now
<Odd_Bloke> xnox: jamespage: So it looks like removing /etc/machine-id from the image makes systemd sad because /etc isn't writable when it wants to re-create it.
<pitti> Odd_Bloke: you aren't using vivid, right?
<pitti> Odd_Bloke: because that got fixed there
<Odd_Bloke> pitti: "that" being /etc/machine-id being missing, or /etc not being writable?
<pitti> Odd_Bloke: having a more clever mechanism to create /etc/machine-id, and write it to disk after it becomes writable
<pitti> Odd_Bloke: i. e. "first boot" initi
<Odd_Bloke> pitti: I am on vivid, but I'm looking at creating cloud images (which we build from scratch). How was the fix introduced?  (We might just have missed it)
<pitti> Odd_Bloke: didrocks wrote a systemd-machine-id-setup helper (http://cgit.freedesktop.org/systemd/systemd/tree/src/core/machine-id-setup.c); at boot, systemd creates a tmpfs one while the root fs isn't writable yet, and then later on once it becomes writable that helper writes it to the root partition
<pitti> didrocks: ^ BTW, you missed to put a correct copyright there :)
<pitti> Odd_Bloke, didrocks: erk, sorry, wrong file: http://cgit.freedesktop.org/systemd/systemd/tree/src/machine-id-commit/machine-id-commit.c
<pitti> Odd_Bloke: supposedly the cloud images shouldn't have a machine-id, it should be created on first boot?
<abhinav_> Hey, I want to make some developmental contribution to ubuntu foundation. How should i get started?
<Odd_Bloke> pitti: Yeah, we want to create it on first boot (otherwise all cloud instances will have the same machine-id).
<pitti> Odd_Bloke: right, that's pretty much what we do on the desktop install images too
<Odd_Bloke> pitti: So if /etc/machine-id is _empty_, we seem to be fine.
<didrocks> Odd_Bloke: pitti: if the systemd is read-only at boot, you need still to have the file created, by empty
<didrocks> so that you can machine-id-setup can mount it
<Odd_Bloke> It's just if it's not present at all that we hit issues.
<pitti> didrocks: I thought with that fix we wouldn't need an empty file any more?
<didrocks> yeah
<didrocks> pitti: we need to have it empty if the system is read-only
<didrocks> however, the id is then committed once it's rw
<didrocks> and you keep the same
<didrocks> (which wasn't the case before)
<pitti> didrocks: oh, I see -- to have a mountpoint
<didrocks> exactly
<xnox> didrocks: interesting. does it make it persistent?
<didrocks> xnox: yeah, it does
 * xnox is confused why systemd can't remount the fs rw without a machine-id....
<xnox> it's not like firstboot is *that* interesting
<xnox> oh, that's recent only been done in december...
<jpds> abhinav_: Find something that interests you to hack on?
<Odd_Bloke> xnox: You said something about writing an upstart job to create machine-id if missing; are we going to be supporting both upstart and systemd in vivid?
<abhinav_> And from where to get that list of things to hack on?
<Odd_Bloke> (Or, more generally, is there anywhere I can read a summary of the init system decisions/roadmap?)
<pitti> Odd_Bloke: we don't want to support more than one init system in a release if we can help it
<pitti> Odd_Bloke: that said, for vivid we might need to support upstart on the phone and systemd on desktop/server/cloud
<pitti> Odd_Bloke: it depends on getting the remaining porting done: http://pad.ubuntu.com/systemd-porting-sprint
<pitti> Odd_Bloke: https://blueprints.launchpad.net/ubuntu/+spec/core-1411-systemd-migration is the current roadmap
<xnox> Odd_Bloke: pitti: imho we need machine-id under upstart for the benefit of dropping dbus-machine-id and making the rest of things work correctly. E.g. doesn't logind under upstart need it? and things like that.
<xnox> however I do hope that juju would be complete and we will be able to switch to systemd across the board
<xnox> and possibly even the phone as well.
<jpds> abhinav_: It's far easier if you go for something that already interests you.
<abhinav_> jpds : and i m doing the same
<jamespage> Odd_Bloke, do you want to assign the machine-id bug somewhere else other than nova?
<Odd_Bloke> jamespage: Just posted a comment; nova should _potentially_ treat an empty machine-id the same way it does a missing one.
<Odd_Bloke> jamespage: https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1413293/comments/3
<ubottu> Launchpad bug 1413293 in nova (Ubuntu) "Unable to start instances, empty /etc/machine-id file." [High,Triaged]
<didrocks> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: open (alpha 2 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: didrocks
<LocutusOfBorg1> dholbach, FYI usually to create USB sticks I run dd
<LocutusOfBorg1> the startup usb creator tool gives me always dbus errors
<LocutusOfBorg1> :)
<dholbach> right
<LocutusOfBorg1> I like to keep it simple ;)
* Laney 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
<ochosi> didrocks: thanks a lot, didrocks! yeah, actually i did file a second MR but since brainwash did his MR on top of mine, both ended up in one...
<didrocks> ochosi: yw ;) yeah, I saw that seb128 approved it, but didn't merge into the mainline
<ochosi> indeed :)
<didrocks> ochosi: thanks to you! uploaded now
<ochosi> phew, now we can move one step further and go for SRU
<ochosi> took us ages to realize how that problem of the screensaver timeout being reset happens and then to come up with the fix
<ochosi> i guess 14.04 users will be happy about this...
<didrocks> yeah, seems to have been complex to untangle :)
<didrocks> nice work!
<ochosi> thanks - and thanks again for the support!
<didrocks> yw
<LocutusOfBorg1> pitti, please let me know if you have troubles in the merge
<LocutusOfBorg1> I'll open a bug instead :)
<pitti> LocutusOfBorg1: I don't see it on http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html ?
<LocutusOfBorg1> nope I sent a mail privately
<pitti> LocutusOfBorg1: hm, I didn't get any
<pitti>  Subject: debdiff samba
<pitti>   Folder: spam
<pitti> LocutusOfBorg1: *blush* sorry ^
<LocutusOfBorg1> +    + debian/patches/CVE-2014-8143.patch fix CVE-2014-8143.
<ubottu> Samba 4.0.x before 4.0.24, 4.1.x before 4.1.16, and 4.2.x before 4.2rc4, when an Active Directory Domain Controller (AD DC) is configured, allows remote authenticated users to set the LDB userAccountControl UF_SERVER_TRUST_ACCOUNT bit, and consequently gain privileges, by leveraging delegation of authority for user-account or computer-account creation. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8143)
<LocutusOfBorg1> this is the last changelog line ;)
<LocutusOfBorg1> just to be sure it isn't the same as yesterday!
<LocutusOfBorg1> no problem pitti my fault
<LocutusOfBorg1> I should write more verbose mail, to avoid spam
<pitti> BAYES_80 and DNS_FROM_AHBL_RHSBL, that killed them, sorry
<pitti> oh, the first second of vivid has been released :)
<infinity> pitti: He corrected it in the u-d-a version. :)
<pitti> infinity: ah, so the first was on u-release@ only, good
<infinity> pitti: Note the subject line said A1 as well.
<pitti> yeah, I wondered
<infinity> pitti: Friends don't let friends email drunk.
<pitti> he doesn't seem to be on IRC, for saying congrats?
<infinity> pitti: He's in #-release
<mejo> hi, can somebody with a recent ubuntu installation, encrypted root fs and upstart as init system do me a favour: please post the output of '/sbin/status cryptdisks-udev DEVNAME="<ROOTFS>"'.
<mejo> I'm trying to fix a bug in cryptsetup but I don't have a ubuntu+upstart system at hand right now :-/
<smoser> bug 1383794
<ubottu> bug 1383794 in cloud-init (Ubuntu Utopic) "[SRU] GCE datasource should use the short hostname" [Undecided,New] https://launchpad.net/bugs/1383794
<LocutusOfBorg1> pitti, dholbach do you think one day I'll be ready to apply for becoming an ubuntu developer?
<LocutusOfBorg1> https://nm.debian.org/public/process/locutusofborg
<LocutusOfBorg1> the debian process is already started
<dholbach> sure, you could already start putting together an application
<dholbach> and ask your sponsors for some comments
<dholbach> it'll give you an idea how ready you are
<LocutusOfBorg1> should I become firstly a DD?
<LocutusOfBorg1> to make the process easier?
<pitti> LocutusOfBorg1: do you want me to fix little errors in your merge myself, or let you do another round for the learning experience?
<pitti> (looking at samba)
<LocutusOfBorg1> pitti, feel free to send a mail with the problems ;)
<LocutusOfBorg1> or tell them here, as you wish
<pitti> LocutusOfBorg1: sent
<LocutusOfBorg1> thanks
<LocutusOfBorg1> unfortunately the page doesn't mention DM, just DDs
<LocutusOfBorg1> so I don't know how to best apply for a Per package upload
<rbasak> Some Breaks/Replaces/Conflicts help please. I've read https://wiki.debian.org/PackageTransition carefully but not sure about this case.
<rbasak> mysql-common-5.6 ships only /etc/mysql/conf.d/my5.6.cnf, and apart from comments it's actually empty (but may have user modifications).
<rbasak> In my next upload, I'm getting rid of this binary package. mysql-common will supply /etc/mysql/conf.d/, and mysql-server-5.6 will supply server-specific configuration, including for 5.6, but not at the previous path.
<rbasak> Right now, in my testing, everything is fine and mysql-common-5.6 is suggested by apt for autoremoval.
<rbasak> Is this fine, or should the new mysql-common declare Breaks against mysql-common-5.6 (<< new) to force mysql-common-5.6 to be removed?
<rbasak> Not that this makes much difference, because the old file is a conffile and so will remain until purge, but it might help to indicate that it's no longer necessary.
<rbasak> Alternatively, maybe mysql-common Breaks+Replaces+Conflicts mysql-common-5.6 (<< new) to actually force the old package to disappear? I don't see this usage in PackageTransition though.
<rbasak> EOquesiton
<LocutusOfBorg1> thanks pitti mail sent :)
<pitti> rbasak: unless m-common actually ships a /etc/mysql/conf.d/my5.6.cnf there shouldn't be an acutal file conflict, or am I missing something?
<pitti> rbasak: what you could do is to add a .maintscript snippet to clean up the obsolete conffile on upgrades (to m-common)
<rbasak> pitti: yeah there's no actual file conflict. It'd be nice to clean up the old package though.
<pitti> rbasak: as it's comment-only it's not like it would actually hurt, but if you want to be clean :)
<pitti> rbasak: oh, for that; yes, Conflicts:/Provides: is your friend there
<rbasak> pitti: I'm not sure this counts as an obsolete conffile though. It just needs a purge of mysql-common-5.6, which the user can choose to do (or not).
<pitti> rbasak: Conflicts: for removing it, and Provides: for nudging apt that it's okay to do that instead of holding back the upgrade
<pitti> rbasak: yes, true that, so ignore that bit
<pitti> rbasak: but Breaks: mysql-common-5.6 (<< new) wouldn't be right as there is no "new"
<pitti> rbasak: if you actually want to replace an entire package, then Conflicts: is right (as per policy)
<pitti> rbasak: https://www.debian.org/doc/debian-policy/ch-relationships.html#s7.6.2
<rbasak> pitti: so Conflicts: mysql-common-5.6 and Provides: mysql-common-5.6?
<pitti> rbasak: ah, and I forgot Replaces:
<rbasak> pitti: OK. So all three, unversioned?
<pitti> rbasak: yes, that's the standard approach; Provides: *might* not be necessary, but often it is and it doesn't hurt
<rbasak> pitti: OK. Thanks!
<pitti> (wrt. nudging apt)
<rbasak> pitti: so I have a similar problem in that the mysql-server package that previously depended on mysql-server-5.5 now depends on mysql-server-5.6, and apt wants to resolve the dist-upgrade by removing mysql-server.
<rbasak> pitti: is this another case that I can fix by having mysql-server-5.6 provide+conflict+replace mysql-server-5.5? We'll be removing 5.5 this cycle if that's relevant.
<pitti> rbasak: if -5.5 goes away, then that sounds right
<pitti> rbasak: assuming that -5.6 just takes over an existing database?
<pitti> rbasak: but if that happens that means that -5.6 conflicts with -5.5 already?
 * rbasak checks
<pitti> Replaces: mysql-server-5.5, virtual-mysql-server
<pitti> Provides: virtual-mysql-server
<pitti> Breaks: mysql-server-5.5, virtual-mysql-server
<rbasak> Yeah
<pitti> yeah, that doesn't look quite right; unversioned Breaks: are not well defined
<pitti> rbasak: so changing that to C/R/P: -5.5 should work better
<rbasak> pitti: OK. Thanks!
<pitti> rbasak: if semantically -5.6 takes over an existing db and just continues working, of course
<rbasak> Yes, that's correct.
<pitti> rbasak: if that's not the case, then the upgrade should just be aborted
<pitti> ok, good
<rbasak> Thank you for your help. I'll try this and test.
<pitti> cheers
<pitti> rbasak: and yes, the above is exactly the kind of nudging that apt needs :)
<pitti> rbasak: it's rather hesitant to uninstall packages; there must be several packages depending on the replacing one until their score becomes higher than the removal penalty
<pitti> therefore Provides:, which removes that
 * pitti is sure that mvo can explain this a lot better
<pitti> rbasak: OOI, do they actually never change their on-disk format, or do newer versions just convert it on the fly?
<rbasak> pitti: yeah - the dependency tree is a little altered now. I think that's swinging the balance a little the wrong way. Hopefully C/R/P will fix it.
<pitti> IOW, once you ran 5.6, could you go back to 5.5?
<rbasak> I'm not sure. I'd need to check with upstream.
<rbasak> I think it'll refuse to let you and fail the maintainer script after a critical debconf prompt.
<rbasak> Or at least that's what we resolved it should do.
<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:
<pitti> LocutusOfBorg1: hm, now you entirely dropped the logrotate changelog entry?
<bdmurray> pitti: I'm curious about the decision not to run package hooks on the phone. Was it because Errors didn't accept all fields or for performance reasons?
<LocutusOfBorg1> yes, sorry
<LocutusOfBorg1> my bad
<pitti> LocutusOfBorg1: replied
<LocutusOfBorg1> thanks
<teward> random question: is it possible to configure a system to have something init at boot time *after* some other process?
<teward> s/process/process does/
<infinity> rbasak: It shouldn't provide 5.5, that's a lie.  Just C/R.
<infinity> rbasak: C/R is the magic that tells apt "prefer this one over the other one".
<infinity> rbasak: Which you do with virtual-mysql-server
<LocutusOfBorg1> pitti, "debian/samba.logrotate: use systemd to restart smbd service."
<LocutusOfBorg1> do you like it?
<teward> s/a system/an init script for a given package/
<pitti> LocutusOfBorg1: no, not systemd -- "service" :)
 * teward fails at typing apparently.
<LocutusOfBorg1>     + debian/samba.logrotate: use service to restart smbd.
<LocutusOfBorg1> maybe "service"
<pitti> LocutusOfBorg1: I'd keep xnox' original rationale, too: such that it works under both upstart and systemd.
<pitti> LocutusOfBorg1: the point of the changelog is not to say *what* changed -- that's obvious from the diff; it should give a rationale why it changed
<infinity> pitti: MySQL upstream changes the formats occasionally, but newer versions are smart enough to be able to upgrade formats on the fly during a DB fsck, which happens on first run.
<pitti> +    + debian/samba-common.config:
<pitti> +      - Do not change prioritiy to high if dhclient3 is installed.
<pitti> e. g. that -- that still doesn't give a rationale, just descibes the patch in English
<pitti> infinity: ah, so you couldn't go back anyway, and indeed the packages shoudln't be co-installable or have a Provides:
<infinity> pitti: Right.
<infinity> pitti: Well, you might be able to downgrade from 5.6 to 5.5, I don't know, but it's not a given that you can.
<bdmurray> jamespage: last week you'd suggested rejecting heat from the utopic -proposed queue but were going to double check IIRC. Should I reject it now?
<LocutusOfBorg1> damn pitti now I got the problem
<LocutusOfBorg1> I was looking at the wrong line
<LocutusOfBorg1> :(
<LocutusOfBorg1> sorry
<rbasak> infinity: http://paste.ubuntu.com/9821906/ is what I have right now, and it doesn't work. Test in ppa:mysql-ubuntu/collab. Installing mysql-server from the archive, and then dist-upgrade with the PPA enabled, and apt wants to remove mysql-server.
<LocutusOfBorg1>     + debian/samba.logrotate: use service command to reload (send SIGHUP) the main
<LocutusOfBorg1>       processes such that it works under both upstart and systemd.
<rbasak> infinity: the only difference I see is that instead of Conflicts, I have Breaks.
<infinity> rbasak: Those Breaks don't belong.
<infinity> rbasak: Breaks/Replaces means "overwrite some files, yo".  Conflicts/Replaces means "I'm better than this package, nya nya".
<infinity> rbasak: If your Breaks/Replaces is unversioned, you know you've done something wrong.
<rbasak> infinity: OK, so I'll switch a bunch of the breaks to conflicts. Thans.
<infinity> rbasak: Basically, think of it like this:
<infinity> rbasak: Breaks: I don't get along with some versions of this package (should always be versioned)
<infinity> rbasak: Conflicts: I don't get along with this package at all, and probably never will, it's a jerk.
<infinity> rbasak: Replaces: Overwrite files from the other package.
<infinity> rbasak: Conflicts/Replaces: the logical union of the two, ie: overwrite the whole package, prefer me, I'm SPECIAL!
<infinity> rbasak: Breaks/Replaces (versioned pair): overwrite files that belong to the package version I don't like, but leave new ones alone.
<rbasak> infinity: thanks.
<infinity> rbasak: And P/C/R is a logical union of C/R and P, in that you claim to basically BE the same package entirely.  P/C/R sets are usually found mutually between packages, but sometimes also used to transition between names.
<rbasak> I more or less got that, but some of the special cases aren't completely obvious to me on the wiki
<infinity> rbasak: In your case, mysql-5.6 really isn't mysql-5.5, so a provides would be a lie (on the off chance someone really does need to depend on the exact version), but C/R seems sane, and should hint apt to DTRT.
<infinity> rbasak: If it doesn't, yell, cause I'm curious.
<infinity> rbasak: Yell later, though, I'm off to bed in a bit.
<rbasak> infinity: the awkward thing here are the binary versioned packages I think. Both mysql 5.6 and mysql 5.5 exist concurrently in multiple releases now. So whether it's a transition depends on how you look at it.
<rbasak> The wiki's wording sort of assumes that you'll be making a change entirely in one release.
<infinity> rbasak: They can't coexist, it's still right for the newer ones to C/R the older ones.
<infinity> rbasak: And that should make the metapackage transition smooth.
<rbasak> OK
<rbasak> infinity: using Conflicts didn't fix it. It still wants to remove mysql-server.
<rbasak> infinity: http://paste.ubuntu.com/9822731/
<rbasak> infinity: http://paste.ubuntu.com/9822739/
<rbasak> infinity: OTOH, if I remove vivid from sources.list and just have my test PPA, then apt is happy to upgrade as expected.
<rbasak> infinity: this is exactly what happened last cycle, and why I asked for the two to be done close together in time to avoid people following vivid from failing to follow the upgrade.
<rbasak> infinity: and you said that was broken and you wanted to dig deeper :)
<jamespage> bdmurray, +1 please reject
<rsalveti> doko: any idea why the bins produced by gcc-go are also using the multiarch env in the path? It seems instead of /usr/bin/test, it got installed as /usr/bin/DEB_HOST_ARCH/test, but only on ppc64el
<rsalveti> sergiusens: ^
<rsalveti> this made nuntium to ftbfs only on ppc64el: https://launchpadlibrarian.net/195549654/buildlog_ubuntu-vivid-ppc64el.nuntium_1.4-0ubuntu1_FAILEDTOBUILD.txt.gz
<rsalveti> sergiusens: once we know a bit more about the problem we can get the fix in place
<sergiusens> rsalveti: it's fine for now; no more hurries as I got permission to push to ubuntu-rtm
<rsalveti> right
<slangasek> why does firefox keep showing me the Ubuntu start page in Arabic instead of English?
<sarnold> slangasek: I think chrisccoulson mentioned it makes the decision based in part on the timezone you're using
<mdeslaur> slangasek: so you can learn Arabic :)
<chrisccoulson> That would be a question for someone like beuno. I'm not sure how the start page determines your locale (I guess it's using the Accept-Language header)
<chrisccoulson> But a few people have pinged me about similar issues in recent days
<chrisccoulson> mdeslaur, didn't you have the same issue?
<slangasek> sarnold: ah I knew I shouldn't have picked Europe/No-Go-Zone
<mdeslaur> yeah, mine was coming up in czech
<slangasek> chrisccoulson: ar isn't in my Accept-Language header
<chrisccoulson> slangasek, which would suggest a server-side issue
<slangasek> mdeslaur: krÃ¡snÃ½
<slangasek> chrisccoulson: righto.  It's also intermittent and only affects the title bar, not the page content
<mdeslaur> slangasek: oh? the text beside the icons was translated for me
<mdeslaur> "Ubuntu help", "Ubuntu shop", etc.
<slangasek> I don't think it was here, but can't reproduce now
<chrisccoulson> slangasek, I'd probably report a bug against ubuntu-start-page. Particularly if it's not happening with other sites (eg, Google when you're not logged in)
<slangasek> chrisccoulson: right.  will do if I manage to reproduce it again, maybe it's cleared up
<doko> rsalveti, sergiusens: ENOCLUE. I'm not familiar with nuntium. can you file a bug report with more details? (yeah for debhelper for not printing how the upstream build system is called)
<eltigre> The current documentation on Ubuntu Core seems to have one slight drawback: Ubuntu Core is said to be built for docker, but the pages don't explain how to use docker on ubuntu core
#ubuntu-devel 2015-01-23
<bryce__> On Ubuntu Core, how can I find a listing of packages that are available for `snappy install`?
<bryce__> Just guessing names hasn't gotten me very far
<bryce__> Hmm, reading through the channel description, I might be in the wrong room...sorry! Is there a better room for these questions?
<RAOF> bryce__: Not to my knowledge.
<bryce__> Gotcha! Is there a syslog package available that you know of?
<RAOF> Nah, I'm pretty out of the loop vis-a-vis Ubuntu Core.
<RAOF> Sorry. :)
<bryce__> cool -- thanks anyway :-)
<bryce__> is there a better room or place to ask ubuntu core questions?
<bryce__> it seems like an awesome project
<RAOF> bryce__: Hm, https://developer.ubuntu.com/en/snappy/ suggests âsnappy search syslogâ might be relevant to your interests.
<RAOF> bryce__: Ah! #snappy on freenode is apparently your winning ticket.
<bryce__> woot! thanks
<infinity> slangasek: It's not an Ubuntu start page bug, it's because you upgraded firefox and didn't kill/restart it.
<infinity> slangasek: The old running firefox has a hissy with the new language bits, ignores your en-us/en preference, and picks the first one in its internal list, which is Arabic.
<infinity> slangasek: Old windows and tabs are fine, entire new processes are fine (since they're the new firefox), but new windows as children to the old firefox lose their mind.
<infinity> chrisccoulson: ^
<StevenK> Given slangasek's language preferences, that make even be an excuse to learn Arabic? :-P
<infinity> Every time it happens to me, I'm reminded that I keep meaning to learn Arabic, yes.
<infinity> But man, right-to-left web browsing is confusing.
<StevenK> I don't tend to see pages in Arabic. It tends to show up for me as some elements not rendering or the interface itself having issues
<infinity> Different symptom, same bug.
<infinity> In your case, it's the old xulrunner and new xul disagreeing.
<infinity> In our case, old firefox and new firefox locales.
<infinity> In every case, "restart firefox" is the answer.
<infinity> After killing it with fire.
<infinity> Or just a reboot, for the "Adam's parents" demographic.
<StevenK> Haha
<pitti> Good morning
<dholbach> good morning
<seb128> hey dholbach, happy friday!
<dholbach> hi seb128
<dholbach> and the same to you!
<seb128> thanks :-)
<LocutusOfBorg1> hi people!
<LocutusOfBorg1> pitti, sorry did you receive the mail? ;)
<pitti> hey LocutusOfBorg1
<pitti> LocutusOfBorg1: yeah, fished it out of my spam filter this morning; I'll get to it ASAP
<LocutusOfBorg1> this is why I asked :)
<brainwash> didrocks: hey, thanks for packaging xdg-utils. sadly it looks like something broke. one of the patches was created against another one which was dropped.
<brainwash> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/xdg-utils/vivid/view/head:/debian/patches/xfce-blanking.diff
<brainwash> if you follow the upstream link in the patch header, you will see that the applied upstream patch has a case for "xfce" and for "''". however, the patch in the ubuntu package replaces the "''" one with "xfce".
<brainwash> original author is gone for a week or so :/
<didrocks> brainwash: I didn't review the first commit as it was already approved by a core dev and discussed, I thought that this was intended
<didrocks> brainwash: ok, so, the fix is to have "xfce" and "''"?
<brainwash> didrocks: yes
<didrocks> brainwash: mind giving a debdiff? I will just sponsor it then :)
<brainwash> didrocks: ok, but it will take some time
<brainwash> I'm not a packaging expert :)
<didrocks> brainwash: well, if there is no hurry as long as it's fixed for today, it's a good practice :)
<didrocks> brainwash: tell me if you need any help, sorry for the breakage :)
<brainwash> didrocks: alright. luckily we did not SRU it to trusty right away :D
<didrocks> yep!
<xnox> didrocks: totally agree with you on http://lists.freedesktop.org/archives/systemd-devel/2014-November/025288.html
<xnox> didrocks: trying to have sane /etc and sane /usr is impossible.
<didrocks> xnox: ah, you climbed that long thread! how long did it take you? :)
<didrocks> xnox: I plan to bring back the topic at the hackfest, we need to settle on something
<xnox> didrocks: well i'm eager to solve it as well.
<xnox> didrocks: imho it's outright wrong that .wants/foo.service -> actually does not matter where it points.
<xnox> didrocks: i raised same topic again yesterday on the mailing list "Unwants" and was pointed to your thread.
<didrocks> xnox: yeah, I saw your unwants one, and thought "ah, this is actually how we started this thread" ;)
<xnox> didrocks: right.
<didrocks> xnox: I think you, pitti and I should meet before the hackfest and try to summarize (I have http://pad.ubuntu.com/systemd-enablement-handling and http://pad.ubuntu.com/systemd-usr-etc)
<didrocks> so that we can think of all cases (I tried at least) and sum that up
<xnox> didrocks: note that i'm only interested in the context of system-image updates, which themself have been compiled / assembled from packages.
<xnox> didrocks: which i think is broadly the scope of the problem.
<xnox> didrocks: i'm in brussels from thursday evening.
<didrocks> xnox: I think that the 2 use cases should converge, basically, it's "we don't want cruft" :)
<didrocks> an defaults in /usr
<didrocks> and*
<didrocks> xnox: I am as well, let's wait for pitti if he can be available?
<xnox> yeah
<xnox> didrocks: i hate pad and it's insistency on doing 2fa
<pitti> didrocks, xnox: what's up?
<ogra_> pitti, did you test your systemd upload on a phone ? (stgraber: same question to you for lxc) ... seems we cant boot anymore in vivid ...
<xnox> pitti: we want a secret kabahl within the systemd kabahl.
 * pitti reads backscroll; sorry, snappy day today..
<xnox> </joking>
<ogra_> (and systemd as well as lxc look most suspicious on http://people.canonical.com/~ogra/touch-image-stats/74.changes)
<pitti> ogra_: no, I didn't test it there; what fails?
<pitti> the container? early boot?
<ogra_> dunno, i only have an unsupported phone with vivid atm, but it doesnt even seem to get to mount a rootfs here
<rsalveti> should show up on the emulator
<ogra_> which points to udev perhaps ...
<rsalveti> but it seems mako is not even starting lightdm/system-compositor
<pitti> yeah, I'm currently building an emulator image
<ogra_> (wildly guessing here)
<sil2100> rsalveti, ogra_: checking logs on my bricked device, but yeah it's either udev, lightdm, lxc or systemd
<sil2100> This image had all of them
<rsalveti> :-)
 * xnox cannot boot any ubuntu emulator with vivid, ever. can't find rootfs - either on trusty or vivid, with distro goget tools or compiled trunk (from launchpad)
<rsalveti> xnox: that was fixed with latest goget-ubuntu-touch
<rsalveti> https://launchpad.net/ubuntu/+source/goget-ubuntu-touch/0.14-0ubuntu1
<ogra_> sil2100, oh, so yours gets far enough to adb shell in ?
<xnox> rsalveti: where is that - in vivid distro, some ppa, bzr launchpad upstream?
<xnox> thanks.
<rsalveti> bug 1412495
<ubottu> bug 1412495 in goget-ubuntu-touch (Ubuntu) "ubuntu-emulator fails to start on Vivid" [Undecided,Fix released] https://launchpad.net/bugs/1412495
<rsalveti> vivid distro
<sil2100> ogra_: no... it stays on the ubuntu logo
<sil2100> (I mean, manufacturer logo)
<sil2100> But I booted up into recovery and try to see what's up
<rsalveti> yeah, ubuntu logo would mean lightdm is up
<ogra_> sil2100, ok, i see the same here
 * ogra_ rolls back to 73
<pitti> mount: mounting /dev/mtdblock2 on /root/android//cache failed: Invalid argument
<pitti> ogra_: ^ is that something to worry about, or normal?
<pitti> it still seems to be stuck in initramfs
<ogra_> if it is actually not mounted thats something to worry about indeed
<ogra_> thouh /cache is not essential for the boot
<rsalveti> for emulator that is fine
<rsalveti> afaik
<ogra_> k
<pitti> ok, thanks
<ogra_> i was only thinking about /init running set -e
<ogra_> (i wasnt sure if we shouled mount failures)
<ogra_> *shield
<rsalveti> Begin: Running /scripts/init-bottom ... done.
<rsalveti> [    1.418683] init: ureadahead-touch main process (462) terminated with status 5
<rsalveti> [    2.180823] init: no-cpu-hotplug main process (610) terminated with status 1
<rsalveti> that's all I get here
<ogra_> not gettin out of initrd means it is likely neither lightdm or lxc
<pitti> right, so most likely udev
<pitti> [    1.025651] initrd: starting adbd for USB debugging
<pitti> [    1.026668] adbd[283]: segfault at c ip 0804cb29 sp bf9aa4b8 error 4 in adbd[8048000+20000]
<rsalveti> pitti: did you remove that other rule I had a while ago?
<pitti> meh, no adb, and busybox doesn't really work either (no prompt)
<rsalveti> yeah, it seems adb is busted
<pitti> rsalveti: no, that's still there
<pitti> but adb crashed before too, that's nothing new (it doesn't seem to work that early)
<rsalveti> yeah
<pitti> rsalveti: it's now in /lib/udev/rules.d/61-persistant-storage-android.rules
<ogra_> right, we dont have any adbd binary that works in initrd anymore currently
<pitti> rsalveti: which is easier to maintain than an eternal patch
<pitti> oh, perhaps that needs to go into initramfs?
<ogra_> needs a special build
<pitti> rsalveti: if the initramfs need the PARTNAME symlink to boot, that sounds like a very plausible candidate
<rsalveti> yeah
<pitti> ogra_, rsalveti: ok, I'll see to hack the .img files to include that rule and try again; it's system.img that I want, right?
<rsalveti> yeah, we're looking for the partname userdata when mounting things around
<rsalveti> so that might indeed be it
<rsalveti> yup, the ubuntu one
<xnox> didrocks: http://lists.freedesktop.org/archives/systemd-devel/2014-November/025296.html -> are good semantics that I like. Didn't check the pad yet (need to fetch phone for 2fa)
<pitti> rsalveti: hm, system.img doesn't look like the one I want
<ogra_> no, you want the initrd
<pitti> ramdisk.img?
<pitti> boot.img?
 * pitti looks through them all
<pitti> ok, not ramdisk
<didrocks> xnox: they are some corner cases with that one (explained later in the thread I guess), but yeah, it's the closest to the best solution
<pitti> not boot.img
<pitti> ogra_, rsalveti: oh, it's system.img, that contains a system.img, which finally seems to be the fs that I need :)
<ogra_> most likely boot.img
<ogra_> oh
<ogra_> ok
<sil2100> Inception
<rsalveti> yeah
<pitti> meh no -- that boot/ is empty
<pitti> where is that darn initramfs?
<xnox> didrocks: so reading this thread - i want to start shouting at people "there is no way to upgrade preset" - I hope that comes up in the thread. Ie. if one had "enable sshd.service, disable sshd@.socket" and wants to move to reverse "disable sshd.service, enable sshd@.socket" it cannot be done at upgrade time with preset.
<xnox> sure the preset changes, but one cannot run "preset-all" without trumping local user configuration.
<xnox> in fact there is no way to specify for the admin, as the "old state" is assumed to be "distro/preset state" when in fact it's a mix of "admin & distro/preset"
<pitti> rsalveti: /boot/android-ramdisk.img  on system.img?
<pitti> nope, that's really android
<rsalveti> pitti: for emulator that is available in your host side
<rsalveti> .local/share/ubuntu-emulator/test_x86/ramdisk.img
<rsalveti> e.g.
<pitti> rsalveti: so boot.img and ramdisk.img don't contain anything, system.img is android, and sdcard.img doesn't contain an ubuntu initramfs; /me confused
<pitti> rsalveti: oh, ramdisk.img isn't a qemu img, Isee
<pitti> rsalveti: ok, that explains the confusion; thanks!
<rsalveti> the previous persistent storage rule is there
<rsalveti> ./lib/udev/rules.d/60-persistent-storage.rules
<pitti> yeah, I'll just add my new one
<pitti> phone, brb
<didrocks> xnox: I mentioned it multiple times in the thread :)
<didrocks> xnox: just be patient :p
<xnox> didrocks: and "copy the unit to /etc/ modify Install section to change wants" does not work -> that is .wants/* symlink in /usr/ is still honoured. thus as far as i can tell there is never a way to unwant.
<xnox> didrocks: my alternative idea was to make "systemctl enable/disable/mask/unmask" to write out a user preset file in /etc/systemd/system-preset
<xnox> not have any symlinks
<xnox> make systemd actually load the preset files and parse them in memory, rather than on the filesystem level.
<xnox> "but I would have thought that presets should only be applied on install-time, and not on upgrade." -> and what should you do on upgrade?! +) and imho he is confusing package install/upgrade with OS install/upgrade.
<LocutusOfBorg1> dear developers, I would like to have your opinion on bug 1413947
<ubottu> bug 1413947 in virtualbox (Ubuntu) "Official kernel.org 3.18.3 (custom config) : virtualbox-dkms 4.3.10-dfsg-1ubuntu1: virtualbox kernel module failed to build" [Undecided,Incomplete] https://launchpad.net/bugs/1413947
<didrocks> xnox: keep reading, I don't think we would go to not having symlinks, but yeah ;)
<xnox> didrocks: i would be happy if symlinks are user generated only. And system presets are applied in memory without any symlinks anywhere - neither in /usr/ nor /etc nor /run
<didrocks> xnox: that would be a nice solution
<didrocks> xnox: we still need the unwants: with this
<didrocks> or the /dev/null
<xnox> "There should be no need to "stick" some of the services as distro choices are only applied at install time, and never on upgrade." -> because RPM upgrade choices are encoded in systemd upstream.
<didrocks> xnox: well, it's more because they don't enable any service by default
<didrocks> so you install openssh-server
<xnox> didrocks: imho unwants is foo.service.wants/undesired.service -> /dev/null (symlink)
<didrocks> xnox: agreed
<didrocks> you don't have it started on install or next reboot
<xnox> yes, presets are optimized for fedora/rpm pagadim of upgrades.
<didrocks> xnox: not sure if you read that yet, but I also talk about the alternatives issue with that (and aliases)
<didrocks> xnox: like lightdm, kdm, and so onâ¦
<didrocks> and various flavors
<rbasak> infinity: could you look at this mysql apt upgrade thing for me please? My test packages are in ppa:mysql-ubuntu/collab. Easy to reproduce - just install mysql-server from vivid, then add the ppa and dist-upgrade.
<xnox> didrocks: no matter how one looks at this - current status is optimised for "disabled by default" policy. Since unit file by itself, is never considered to be enabled unless symlinks are generated. If symlinks are in /usr it's a "should not disable" unit, if in /etc -> "it's user enabled, or most-users-enable-this-distro-enabled-it-at-first-installation"
<didrocks> xnox: yeah, I guess debian/ubuntu are the first distros who wanted enabled by default
<pitti> ogra_, rsalveti: so diffing the previous and current udev debs, this is the only significant change, so I uploaded -5ubuntu2 with that fix
<didrocks> for most of the things
<ogra_> pitti, cool
<ogra_> i'll do a vivid re-build once it is in the archive then
<pitti> ogra_, rsalveti: I seem to be unable to munge the initramfs manually though, it still fails; I'll keep debugging, but if that's indeed the problem (likely) then we'll at least have a fixed package ASAP
<pitti> and if it's something else still, well it's still a valid and necessary bug fix
<xnox> didrocks: despite upstream implicit "enable *" without any preset policy
<rsalveti> pitti: yeah, failed for me here as well
<rsalveti> but cool, thanks for that
<pitti> rsalveti: the rule said it's also necessary for flash-kernel, so maybe something else depended on that during image build, which I didn't catch with the initramfs tampering?
<rsalveti> ogra_: guess we need to bump initrd and android after that, right?
<ogra_> oh, right
<ogra_> hmm
<didrocks> xnox: I think they are not in the "we can upgrade defaults to your users" mindset
<pitti> was it bumped for -5ubuntu1?
<rsalveti> nops
<ogra_> we didnt bump it between 73 and 74
<pitti> I mean, the upload broke it automatically, it shoudl fix itself automatically?
<didrocks> xnox: despite my numerous examples in the thread (and I can add more of what we needed to do in ubuntu), they just don't see that as desirable :p
<ogra_> yes, it should
<rsalveti> nothing in the initrd changed, so it would indeed still be able to boot
<pitti> rsalveti, ogra_: anyway, sorry about that! I'll see to it this afternoon if things still go haywire with this
<rsalveti> not sure why it silently fails though
<didrocks> xnox: the only point I'm unsure is "if you enable manually an unit that is already enabled by default, and then, we disable the unit as per new distro default, should that unit still be enabled?"
<ogra_> probably because the inird ships an olde udevd ?
<ogra_> *older
<didrocks> xnox: they are prons and cons to both, if the answer is "yes", then, we need a reset commandâ¦
<didrocks> there*
<pitti> rsalveti: unpackign ramdisk.img shows that this was built with the updated udev rules (i. e. droping the PARTNAME rule), but was missing the new 61-persistent-android file
<pitti> ogra_: the udev binary didn't change at all, just the PARTNAME rule moved to a separate file
<rsalveti> hm, we didn't rebuilt the initrd
<ogra_> ah, k
<pitti> (it should eventually live in some touch specific package, not udev, but I kept it there for now)
<ogra_> rsalveti, does the emulator rebuild it on image creation ?
<rsalveti> shouldn't, and I thought I still had that rule here
<rsalveti> let me extract it again
<pitti> rsalveti: oh, you are  right
<rsalveti> so the init logic, until it boots upstart, is the same
<xnox> didrocks: the answer is yes. At the moment there is no way to tell systemd "i know better" since .wants symlinks / wants dependencies are honoured from lower level directories even if the unit is outright overriden.
<pitti> it already is in the original ramdisk.img, which explains why my hand-editing didn't make a difference
<ogra_> <rsalveti> [    1.418683] init: ureadahead-touch main process (462) terminated with status 5
<ogra_> <rsalveti> [    2.180823] init: no-cpu-hotplug main process (610) terminated with status 1
<ogra_> <rsalveti> that's all I get here
<ogra_> these messages are not from /init
<pitti> yeah, same
<didrocks> xnox: right, there is no way to support that case for now, I'm unsure about the "should", I tend to answer yes as well, but I can accept counter-arguments :)
<ogra_> but already from /sbin/init
<ogra_> so we are past the initrd here
<rsalveti> yeah, already in upstart
<pitti> ogra_: oh, we are? ok
<pitti> so the PARTNAME thing woudl probably have hit us as soon as we did update the initramfs
<rsalveti> yeah
<pitti> so good that we found it, but it's not that one
<ogra_> right, unlikely to be the actual issue we see here
<ogra_> do we put the partnames into fstab at fstab creation ?
<pitti> so, ironically it does boot further with systemd; that at least proves that it does get out of the initramfs
<ogra_> right
<pitti> it fails to start the container, though
<ogra_> aha !
<pitti>          Starting ifup for lxcbr0...
<pitti> [FAILED] Failed to start ifup for lxcbr0.
<pitti> well, at least the brige, not sure how crucial that is
<ogra_> oops, i thought we had that disabled
<pitti> or if it's a red herring
<pitti> but it doesn't start lightdm either
<ogra_> right, lightdm only starts after the container is up
<rsalveti> right
<rsalveti> http://paste.ubuntu.com/9833781/ upstart with debug
<ogra_> the container initialized the graphics drivers atm
<pitti> rsalveti: oh nice, how do you do that on the kernel cmd line? I tried "debug", but that's not it
<ogra_> [    2.235346] init: lxc-android-boot state changed from waiting to starting
<ogra_> never gets out of the starting state
<rsalveti> pitti: yeah, adding --debug
<ogra_> hm, buut thats only the boot jobs
<pitti> rsalveti: where?
<rsalveti> pitti: in the kernel cmdline
<pitti> oh, how unusual; thanks
<pitti> *nnng* want shell
<rsalveti> ubuntu-emulator run test_x86 --memory=1024 --kernel-cmdline="--debug"
<rsalveti> yeah
<ogra_> [    2.003008] init: lxc-android-config state changed from post-starting to post-start
<ogra_> there we go
<ogra_> it never gets to "started"
<pitti> ogra_: you mean "running"?
<ogra_> right
<ogra_> (it never emits the started event, so lightdm doesnt fire)
<ogra_> (or adb)
<ogra_> there should be some lxc log
<pitti> I had a regression with user containers, filed as bug 1413927; maybe that somehow affects that too
<ubottu> bug 1413927 in lxc (Ubuntu) "lxc_cgmanager_enter: 694 call to cgmanager_move_pid_sync failed: invalid requestUser container fails to start: " [Undecided,New] https://launchpad.net/bugs/1413927
<ogra_> ot at least the upstart log for the job
<pitti> ogra_: well, they should be written to /var/log/upstart/ in system.img?
<pitti> on the sdcard.img qemu?
<ogra_> in the wriable equivalent, yeah
<rsalveti> yeah, better trying to find the lxc logs
<rsalveti> should be there
<pitti> userdata.img is zero bytes, /me looks in sdcard.img
<rsalveti> hm, log for lxc android is 0 bytes
<rsalveti> cat lxc-monitord.log
<rsalveti>    lxc-monitord 1422014624.322 NOTICE   lxc_monitord - lxc_monitord.c:main:416 - pid:585 monitoring lxcpath /var/lib/lxc
<rsalveti> nothing useful
<pitti> hm, I killed my workstation, I think mount /dev/nbd0 hanging forever
<pitti> can't reboot, running a snappy test for mvo..
<rsalveti> pitti: ogra_: http://paste.ubuntu.com/9833964/
<rsalveti> lxc android with debug
<ogra_> the kernel misses the network namespace ?
<ogra_> i'm pretty sure we had switched all networking off for the container in the past
<pitti> meh, no upstart log for the lxc container start?
<ogra_> there should be an lxc-android-config log
<pitti> cgmanager: Could not look up /run/cgmanager/fs/freezer/freezer.state
<pitti> cgmanager:get_value_main: Pid 506 may not access /run/cgmanager/fs/freezer/freezer.state
<pitti> not sure if that's relevant
<rsalveti> nops
<rsalveti> because what seems to be failing is lxc itself
<pitti> ogra_: no, there isn't; that's what I meant
<ogra_> only for apps perhaps :)
<rsalveti>       lxc-start 1422015012.041 WARN     lxc_confile - confile.c:config_personality:1021 - unsupported personality 'armhf'
<rsalveti> also weird, this is the x86 emulator
<rsalveti> but well, basically the container failed to start
<pitti> Jan 23 10:56:11 ubuntu-phablet kernel: [    5.028352] init: lxc-android-config post-start process (574) terminated with status 1
<pitti> ok, so definitively that, yes
<pitti> lxc-start[717]: lxc: cgmanager.c: lxc_cgmanager_escape: 329
<pitti>  call to cgmanager_move_pid_abs_sync(blkio) failed: A proxy is required
<pitti> that's the closest error I can fine
<pitti> find
<pitti> cgproxy failed due to
<pitti> cgproxy:get_value_main: Failed reading string from cgmanager: No child processes
<pitti> and cgmanager failed due to the above freezer.state thingy
<rsalveti> we should be able to get adb if you change the adb upstart job to not depend on lightdm I guess
<pitti> so, no cgmanager -> no cgproxy -> no lxc -> boom
<rsalveti> right
<ogra_> yeah
<ogra_> but cgmanager didnt change
<ogra_> nor did the kernel
<pitti> ah, maybe the new lxc makes a new type of request to cgmanager which it hadn't before?
<ogra_> might be, but then i would have expected stgraber to update them together
<rsalveti> ogra_: pitti: yeah, got rev 74, updated lxc, rebooted, boom
<ogra_> so i guess we need stgraber
<rbasak> xnox: are you planning on merging php5? Or do you want me to take it over again?
<xnox> rbasak: there was something rather upstart job about it. let me check.
<xnox> didrocks: posted my summary of that thread.
<didrocks> xnox: reading
<xnox> didrocks: talking in multiple channels is fun -> i love how nobody replied to your alternatives question.
<didrocks> xnox: :p yeahâ¦ as you can see the thread was going to be not ending, that's why I decided that the hackfest would be better to restart the discussion
<xnox> as far as i can tell, rpm distros hate supporting alternatives and the way it's done essentially is that last one wins on packaging level similar to how in debian everything does "conflicts/provides: only-one-service"
<didrocks> xnox: lennart answered on the alternatives + preset though
<xnox> didrocks: where?
 * xnox can't see
<didrocks> xnox: let me try to fetch it
<xnox> -enochan
<rbasak> xnox: did you find out about php5?
<didrocks> xnox: starting with http://lists.freedesktop.org/archives/systemd-devel/2014-December/026008.html
<xnox> rbasak: yes, please merge php5 there is nothing crazy about it.
<rbasak> xnox: OK will do, thanks.
<xnox> pitti: did lazr.restfulclient fix the bug you saw with python3 launchpadlib?
<xnox> pitti: and do you have more bugs? =)
<xnox> 0.13.4-3
<pitti> xnox: ah, I didn't get back to that yet, sorry; too much snappy :)
<xnox> pitti: snap louder...?!
 * xnox is not sure of an appropriate cheer up and a pun at the same time
<cyphermox> good morning!
<pitti> xnox: hmm, staging doesn't let me log in, seems its 2FA got out of sync
<pitti> (I tried the "enter three codes" after "having problems", but it doesn't re-sync)
<xnox> pitti: staging has differen 2fa tokens...
<pitti> oh, right
<xnox> pitti: or rather you should have a different 2fa token for staging.
<xnox> pitti: alternative is fake account, or leave 2fa-demo-group
<pitti> xnox: I actually do *blush*, just looked at the wrong one in google auth :(
<xnox> but i guess you can't leave 2fa-demo-group due to other memberships that include that one.
<pitti> so with py2 I saw the "The authorization page:..." message, which doesn't happen with py3
<pitti> xnox: so with py3 and unauth'ed, I get http://paste.ubuntu.com/9835355/
<pitti> xnox: with py2, this leads me to the LP login page, where I login
<pitti> once auth'ed, py2 works, and with py3 I now seem to get a py3 incompat in my own code, so that looks promising!
<pitti> xnox: but yes, the original bug is definitively fixed, thanks!
<xnox> pitti: keep them comming. i cannot run the full test-suite =/ as i've only ported the critical path to runtime, rather than all test-suite deps.
<xnox> all test-suite deps dig deep into lazr.* stack and pretty much a lot of launchpad.
<pitti> xnox: right, I'll file a proper bug report soon
<pitti> xnox: if this works while already being authenticated, that's a huge leap already
<stgraber> ogra_: do you have version 0.35 of cgmanager on that device?
<stgraber> ogra_: I've got a meeting in 5min but I'll go grab my nexus4 and see if I can reproduce this
<ogra_> stgraber, whatever is current in vivid
<ogra_> its today image build
<ogra_> *todays
<stgraber> oh and my nexus4 is on RTM and with my custom debug kernel, so I guess my test wasn't terribly good since it was older cgmanager and a kernel which doesn't require cgproxy
<ogra_> ah, yeah :)
<stgraber> now that we have reasonably recent kernels for touch, I should really get the kernel team to include those, it'd be one less daemon running on it and one less source of problems
<pitti> stgraber: it reproduces just fine in the emulator, might be easier than bricking your n4
<pitti> stgraber: sudo ubuntu-emulator create --channel=ubuntu-touch/devel-proposed dprop
<stgraber> pitti: well, I don't use my nexus4 so I don't mind :)
<stgraber> and it's faster than the emulator
<pitti> stgraber: really?
<pitti> stgraber: I find the emulator delightfully fast, and one has a serial console for free :)
<stgraber> ogra_: what's the bug# ?
<ogra_> i dont think anyone has opened one ... sil2100 ?
<slangasek> infinity: ok well it went away on its own regardless, without restarting the browser.
<sil2100> ogra_: I didn't hear about any, sadly
<stgraber> ok, anyway, I'm about done downloading the rootfs here, so should have a phone with the bug in about 30min
<sil2100> stgraber: thanks :)
<stgraber> I'll then work with hallyn to figure out what's going on exactly
<stgraber> since it looks like it's some odd lxc talking to cgmanager through cgproxy problem
<ogra_> stgraber, you will need to hack the adb upstart job to get in
<stgraber> (as we're not seeing the problem at all when talking straight to cgmanager on recent kernels)
<ogra_> from recovery or so
<stgraber> ogra_: yeah, I'm pretty used to doing that :)
<ogra_> (it nowadays waits for container and lightdm to be up)
<ogra_> ok
<stgraber> (since the only times I use that phone is to debug lxc on it)
<hallyn> stgraber: do we have an ysort of logs?
<stgraber> hallyn: I should have some very soon
<pitti> xnox: filed bug 1414055
<ubottu> bug 1414055 in lazr.restfulclient (Ubuntu) "urllib.unquote() does not exist in Python 3, causes crash" [Undecided,New] https://launchpad.net/bugs/1414055
<hallyn> looks like pitti and jodh are running into the same bug (which i think stgraber noticed yesterday?)
<stgraber> hallyn: http://paste.ubuntu.com/9836490/
<pitti> right, that's what I saw on the emulator
<pitti> I suppose upstart is trying to restart it, so it appears several times
<pitti> cgproxy fails on that, and lxc fails on not having a cgproxy
<jodh> hallyn: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1413922 ?
<ubottu> Launchpad bug 1413922 in lxc (Ubuntu) "lxc unprivileged containers broken" [Undecided,New]
<hallyn> jodh: yup
<stgraber> so those are two separates bugs. Touch runs privileged containers.
<stgraber> so touch is the first priority, then we can look into the other one
<stgraber> ogra_: ok, so I'm apparently failing to get adbd to start even when changing its start on condition...
<hallyn> stgraber: yeah pitti also reported failing unpriv containers, that's all
<pitti> jodh: ah, sounds like my bug 1413927 indeed, dupes?
<ubottu> bug 1413927 in lxc (Ubuntu) "lxc_cgmanager_enter: 694 call to cgmanager_move_pid_sync failed: invalid requestUser container fails to start: " [Undecided,New] https://launchpad.net/bugs/1413927
<ogra_> stgraber, well, ssh then ?
<pitti> jodh: we must have read stgraber's g+ post at the same time, we are only 5 bug IDs apart :)
<stgraber> ogra_: yeah, I'll try to set that up
<ogra_> android-gadget-service enable ssh
<ogra_> in the terminal app
<hallyn> stgraber: so this sounds like touch may be trying to do something not allowed.  Any way of getting the /proc/$$/cgroup of the proxy ?
<hallyn> iow it sounds like the security bug fixed by 6a30adc22cc05b5f9e138b8756408c64946452bc was being exploited by touch
<pitti> xnox: I'm afraid I do keep them coming :/ -- bug 1414063
<ubottu> bug 1414063 in lazr.restfulclient (Ubuntu) "bug.addAttachment() causes UnicodeEncodeError with binary data" [Undecided,New] https://launchpad.net/bugs/1414063
<xnox> pitti: tah.
<stgraber> ogra_: doesn't NM and wifi depend on android?
<ogra_> nope
<stgraber> did we find a way to get the nexus4 wifi firmware loading to happen from Ubuntu now?
<ogra_> oh, N4 might inded be special
 * ogra_ hasnt touched an N4 in months 
<stgraber> ogra_: 73 was working and 74 is broken, correct?
<ogra_> stgraber, yep
<stgraber> ok, reflashing on 73 then, will get adbd working from there and then upgrade to 74
<ogra_> ++
<stgraber> hallyn, pitti, jodh: what's odd about that unprivileged containers failing bug is that I'm running current cgmanager, current lxc and current lxcfs but on trusty and I'm not running into that problem at all
<pitti> stgraber: note that I'm currently under systemd; I haven't tried running under upstart yet, but I suppose jodh is?
<pitti> stgraber: maybe different cgroupfs layout or so?
<pitti> stgraber: btw, once that works again I'm happy to test Lennart's upstream patch for the /dev/urandom segfault
<stgraber> pitti: testing on vivid with upstart now
<stgraber> (while my phone is flashing)
<stgraber> pitti: starts fine under upstart
<stgraber> rebooting with systemd now
<jodh> stgraber: pitti: actually, running systemd on this box :)
<stgraber> good, so I didn't break default vivid :)
<bdmurray> pitti: Did you see my question the other day about package hooks on devices?
<pitti> stgraber: indeed, under vivid/upstart it starts up fine
<pitti> stgraber: so maybe jodh is also running systemd
<stgraber> pitti: he just said he did :)
<pitti> bdmurray: no, it seems I missed that completely
<pitti> stgraber: ah, missed his reply then while I was rebooting
<bdmurray> pitti: are package hooks not run because whoopsie wouldn't send all data or for performance reasons?
<pitti> bdmurray: for the former case mostly
<pitti> bdmurray: also, apport-noui doesn't provide - surprise - an UI, so everything which expects interactivity will just crash
<pitti> (but that's ok, we'll just skip those hooks)
<bdmurray> pitti: skip how?
<pitti> bdmurray: if a hook crashes, apport just goes on and calls the next one, i. e. that's not fatal for the whole bug
<bdmurray> pitti: alright, thanks
<stgraber> ogra_: starting to wonder if the nexus4 doesn't need android to setup usb or something...
<ogra_> shouldnt
<ogra_> but adbd needs a password set
<ogra_> else it will refuse to start
<stgraber> well, I got adbd working fine pre-upgrade including the modified start on condition
<stgraber> then I upgraded to 74 and now it won't start
<pitti> xnox: ... and bug 1414075; I attach reproducers for all of them
<ubottu> bug 1414075 in lazr.restfulclient (Ubuntu) "[py3] bug.lp_save() crashes with TypeError: startswith first arg must be bytes or a tuple of bytes, not str" [Undecided,New] https://launchpad.net/bugs/1414075
<xnox> pitti: thanks a lot!
<xnox> will fix.
<pitti> xnox: heh, thanks to you! :-)
<xnox> it "works" for "some" api calls =)
<pitti> xnox: but that's an useful exercise still, I got apport's lplib backend half-ported to py3 now, too
<pitti> str vs. bytes yay
<pitti> and .next()  vs. __next__(), makes the code really ugly
 * pitti waves good bye, enjoy the weekend!
<LocutusOfBorg1> bye pitti
<LocutusOfBorg1> you too
<stgraber> ogra_: ok, so I can't get a shell on the nexus4 and I can't get a shell in the emulator either, so I really don't know how I can help you with that stuff...
<hallyn> stgraber: to be clear, it's not hta tyou can't get a shell bc of cgmangaer bug right?
<hallyn> (just making sure, else i'll really panick)
<stgraber> hallyn: well, it kinda is, cgmanager is preventing the lxc container from starting and it's that lxc container which sets up the display, network, ...
<hallyn> ogra_: can you tell me what fails with that bug?  is it just an error msg on login?  failure to login?  apps failing to start?
<hallyn> stgraber: but cgproxy would be in the container, and cgproxy is having the problem, so the container must be *starting*
<stgraber> hallyn: so basically all we get is a blank screen and no way to connect to it... I can pull logs from recovery or straight from the partition but that's about it
<stgraber> hallyn: no, cgproxy runs on the host
<ogra_> hallyn, stgraber i dont really work much on the phone atm, i just jumped in to help debugging
<stgraber> hallyn: it's a very old kernel
<hallyn> still?
<stgraber> yep
<hallyn> ok well that's messed up - cgproxy on the host should be running in cgroup /
<hallyn> so, hm.
<stgraber> well, I guess we could force cgproxy to start on a recent kernel and see if the problem happens there too
<stgraber> might be simpler than trying to get a working shell on that bloody phone
<hallyn> ogra_: how can i deliver a cgmanager package to you to help debugging?  basically i'd like to print out the relevant cgroups at line 583 of cgmanager.c
<ogra_> i dont even have a phone with vivid atm
<hallyn> ok, let's do as stgraber suggested then
 * ogra_ has been fully working on snappy the last two weeks, sorry 
<gnuoy`> pitti, zul, I'm planning to look at merging python-flake8 2.1.0-1ubuntu2 -> 2.2.2-1 unless you have any objections?
<stgraber> hallyn: I've got an x86 emulator here, so if you get me an i386 build of a test cgmanager, I can install it and get you the upstart log afterwards
<stgraber> what I can't get is any kind of interactive debugging...
<zul> gnuoy`:  you know what...i dont :)
<hallyn> stgraber: ok
<stgraber> hallyn: can't reproduce the issue here by just spawning cgproxy and starting a conainer
<stgraber> *container
<hallyn> stgraber: drat.  well, maybe it's a good thing...
<stgraber> well, it shows that cgproxy isn't completely busted :)
<hallyn> stgraber: i386 build of cgmanager on vivid?
<stgraber> yep
<stgraber> I'm doing a test run now with --debug passed to cgmanager and cgproxy and -l debug -o debug to lxc
<xnox> cjwatson: are you ssh upstream? and do you have weight in https://bugzilla.mindrot.org/show_bug.cgi?id=1585 ?
<ubottu> bugzilla.mindrot.org bug 1585 in ssh "Allow an `Include' option which reads another config file in place and does not error out when `Include' file not readable" [Enhancement,New]
<stgraber> hallyn: I think I may have found the problem
<stgraber> well, we have two problems. 1) lxc's debugging sucks 2) android doesn't work with lxc.autodev
<stgraber> I just set lxc.autodev = 0 in the container config and everything works now
<stgraber> ogra_: I'll upload a new lxc-android-config now which should fix the issue (it did in the emulator anyway)
<hallyn> oh
<hallyn> stgraber: well then it may be the same problem that pitti and jodh are seeing
<ogra_> stgraber, awesome !
<hallyn> time to rewrite lxc
<stgraber> hallyn: I doubt it, seeing how I tested lxc.autodev = 1 for all supported Ubuntu releases, both privileged and unprivileged
<stgraber> hallyn: for Android, I think the problem is that we're passing it a pre-populated /dev usually and now with autodev, that gets masked
<stgraber> so not something I'd fix upstream since our default behavior still makes sense. I just should have though of setting autodev to 0 in lxc-android-config ...
<stgraber> ogra_: uploaded. I'll kick a new image as soon as it's published, and test on my nexus4
<stgraber> sorry about that, I should really make sure to test on a clean device, rather than my hacked up one :)
<hallyn> i suppose we *could* have lxc look for any devices which we don't normally created in the rootfs /dev,
<hallyn> and not do autodev if we find anything
<hallyn> (or even more work - bind-mount the old /dev to /tmpdev, bind mount devices from there to /a new tmpfs mounted on /dev, and then drop /tmp/dev
<cjwatson> xnox: no, and my track record with getting openssh upstream to do config things I want is not noticeably better than others :)
<xnox> =))))))
<xnox> cjwatson: will you be at fosdem in brussels next week?
<cjwatson> xnox: afraid not.  one of these years I will make it
<bdmurray> xnox: could you have a look at bug 1412624?
<ubottu> bug 1412624 in gnome-keyring (Ubuntu) "Fix from bug 1271591 breaks uses of ssh-agent" [Undecided,New] https://launchpad.net/bugs/1412624
<xnox> bdmurray: is this another dupe of the bug that is fixed in vivid?
<bdmurray> xnox: I don't know what bug that is.
<xnox> bug 1387303
<ubottu> bug 1387303 in gnome-keyring (Ubuntu Utopic) "regression: gnome-keyring components can't be disabled anymore" [Undecided,Confirmed] https://launchpad.net/bugs/1387303
<xnox> bdmurray: needs cherry pick of the fix from vivid.
<xnox> i guess i should do it. or anyone else can pick it up
<xnox> i guess people are not finding that bug because, default search excludes bugs fixed in latest devel series....
<bdmurray> xnox: if you do it, then I could review them for you.
<xnox> bdmurray: that is true.... =)
<xnox> and i should have finished work 7 minutes ago.
<bdmurray> I'm sure it would only take another 7 minutes. ;-)
<xnox> bdmurray: as in, i can stop working and start volunteering.
<bdmurray> xnox: ah-ha, great! I always feel bad adding more things to the SRU queue anyway, since I'm on the team that has to review them.
<bdmurray> xnox: not that it stops, I just feel like for everything I add I should take one thing away. ;-)
<xnox> =))))
<xnox> i thought you used your timedelay two pairs of eyeballs review strategy
 * xnox was reading complex bug on waitid failures the other day, only to see that the post was authored by myself year and a half ago
<bdmurray> xnox: well, yes that does happen eventually
<smoser> infinity: https://bugs.launchpad.net/ubuntu/+source/slof/+bug/1374568
<ubottu> Launchpad bug 1374568 in slof (Ubuntu Trusty) "network boot doesn't work (need newer slof.bin)" [Medium,Confirmed]
<smoser> if you're interested.
<stgraber> pitti: btw, I've got a pretty simple network config  which completely hangs systemd at boot time
<smoser> that is easy reproduce failure case.
<stgraber> hallyn: reproduced the issue here
<infinity> smoser: Ta.
<stgraber> hallyn: http://paste.ubuntu.com/9837914/
<stgraber> hallyn: looking at the cgroup setup, it looks like this may be because /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-1.scope/ doesn't actually belong to the user
<infinity> hallyn: How do you feel about backporting that "qemu-kvm on all arches" change to trusty and utopic as SRUs?
<hallyn> infinity: well, as i recall we said months ago we intended to do that
<hallyn> infinity: i'll ad dit to my list o fthings to sru
<hallyn> infinity: next 1.5 weeks i need to focus on lxc/lxd, then i need to quickly merge qemu 2.2 into v
<hallyn> (it's working fine in a ppa)
<hallyn> stgraber: that's with systemd-ssyv on the host?
<infinity> hallyn: Kay.  I'm also going to backport SLOF from U to T as an SRU and promote the version in updates to main, so you could fix that dep as well while you're in there.
<stgraber> hallyn: no, just booted with init=/lib/systemd/systemd
<hallyn> stgraber: indeed, the name=systemd cgroup is not owned by the user
<hallyn> (when i'm logged in with systemd as pid1)
<hallyn> so we need systemd to fix that
<stgraber> why did that ever work? was that because of the cgmanager bug?
<hallyn> no
<hallyn> bc the /user/user-1000.slice/session-whatever used to get created owned by the user
<hallyn> i thin kit' sbc cgmanager used to handle name=systemd when passed controller=all and now it does not
<hallyn> hm, no, we didn't change that
<hallyn> so looks like a systemdlogind change?
<hallyn> but systemd on host gives me far worse errors than that
<hallyn> i.e. if i chown the name=systemd cgroup so tha ti can start the container, al lhell breaks loose.
<stgraber> hallyn: ah?
<stgraber> hallyn: here the chown does the trick and the container starts fine
<hallyn> stgraber: then run 'top'
<hallyn> then exit and look around on the host.  /proc should be the container's proc, shutdown fails;
<stgraber> hallyn: ah yeah, that one was reported upstream a few days ago
<stgraber> hallyn: looks like an OMG-critical kernel bug to me
<hallyn> yeah
<hallyn> unless it's something we're doing wrong,
<stgraber> well, even if it's us doing it wrong, we're doing it as an unpriv user
<hallyn> haha good point
<hallyn> is apw still around? :)
<stgraber> unpriv user can destroy /proc, sounds kinda bad to me :)
<apw> hallyn, vaguly, s'up
<hallyn> apw: unpriv user on vivid with systemd can hose the host
<hallyn> ("why would anyone be doing that?"  wrong q)
<stgraber> hallyn: so looking at /proc on the host, it looks like the /proc mount in the container propagated back to the host
<apw> hallyn, well its a good job system isn't the default
<hallyn> stgraber: yes
<apw> hallyn, how are they able to do that
<hallyn> apw: yeah but i assume systemd isn't the cause
<apw> systemd is always the cause :)
<hallyn> i suspect that making / r-shared on upstart may do the same thing
 * stgraber boots that box on his trusted 3.13 kernel to see exactly how screwed we are
<stgraber> (might be worth taking this somewhere slightly more private)
<apw> stgraber, concur ...
<stgraber> sil2100, ogra_: new touch image building
<sil2100> stgraber: oh, thanks!
<stgraber> sil2100, ogra_: new image works fine here
<ogra_> stgraber, great news ! thanks a lot for fixing it
<Laney> xnox: fosdem> see you there!
<xnox> \o/ good
<xnox> Laney: and thank you for testing my desktop notifications in circ irc client
<Laney> here to help
<Bluefoxicy> shit, that wasn't the OOM sysctl key
<Bluefoxicy> Again:  Page cache is essential; if you don't OOM at low page cache, the system will lock up.  That means having 16GB RAM and 15.75GB used is a disk thrashing condition, and the only two ways out of it are OOM or powering the machine off.
#ubuntu-devel 2015-01-24
<Unit193> cyphermox: NM 1.0.0 recently hit NEW in case you didn't see.
<Majmun> sorry i just need to see yt https://www.youtube.com/watch?v=hv_ChWx1zn0 Please :)
<bekks> Majmun: It is offtopic, isnt it?
#ubuntu-devel 2015-01-25
<BenC> Anyone here a Debian dev and also happen to be in the Austin area?
<ahoneybun> is this page still good to use for helping? https://unity.ubuntu.com/getinvolved/testing/#running-the-latest
<xnox> cyphermox: looks like network-manager has test-suite regressions =(
<xnox> in auto package tests and hence is not migrating
<xnox> rsalveti: why did you push stuff to lp:ubuntu/upstart? I did a force push to use my commits instead.
#ubuntu-devel 2016-01-25
<attente> oh shoot. what's the new rest api for replacing ubuntu-sso-client?
<cpaelzer> good morning
<pitti> Good morning
<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
<flexiondotorg> Mirv, you're a star! Thank you very much for sponsoring again :-)
<Mirv> flexiondotorg: you're welcome again :) I did some sponsoring last week but it turns out today I'm actually on the calendar so continuing a bit, plus it's s good time with lts milestone coming
<LocutusOfBorg> hi, nobody is swearing at me for the libsdl2 sync?
<LocutusOfBorg> seeded-in-ubuntu returns ubuntu-mate, ubntukylin, lubuntu, going there
<xnox> LocutusOfBorg, you dropped mir support, didn't you?
<xnox> LocutusOfBorg, in general it's not nice, to forcesync things, effectively stealing a merge, and dropping ubuntu delta.
<xnox> LocutusOfBorg, it's ok for things to be ahead in debian, but a debian maintainer does not get to drop ubuntu delta for no reason.
<LocutusOfBorg> xnox, the delta is upstream
<xnox> lubuntu have been working on mir enablement, and you should have talked to e.g. Artur or Brandon.
<LocutusOfBorg> I checked and it is included upstream
<LocutusOfBorg> I asked a while ago, and nobody complained
<xnox> LocutusOfBorg, you have dropped libmirclient-dev [i386 amd64 armhf], build-dep.
<xnox> thus it's not compiled with mirclient support any more, is it?
<LocutusOfBorg> let me check, brandon answered me a few seconds ago
<xnox> LocutusOfBorg, hm, i see libmirclient-dev installed none the less in the new build.
<xnox> and it doesn't link against it.
<xnox> maybe it's actually all ok, as you say.
<LocutusOfBorg> actually I checked, checked and double checked the delta, it was patching upstream source files
<LocutusOfBorg> changing function names
<Laney> no
<LocutusOfBorg> and I dropped, because upstream actually duplicated them
<Laney> checking for Mir support... no
<xnox> Laney, yeap, found the delta.
<Laney> some mir things get pulled in, evidently transiently, but that seems to not be sufficient
<LocutusOfBorg> ok let me fix it
<xnox> LocutusOfBorg, see at the end http://paste.ubuntu.com/14662490/ there are chuncks of things from debian/rules
<xnox> LocutusOfBorg, that are dropped. Evidentaly, since libmirclient-dev is available anyway, you can add those bits to debian/rules but with extra DEB_VENDOR treatment
<Laney> it's auto detected
<xnox> to e.g. enable it only on ubuntu, whilst uploading it into debian.
<Laney> so I guess you could add that to fail the build if it doesn't get enabled
<Laney> but probably not synacble if additional BDs are needed
<xnox> then again i don't know how MIR or libsdl thing work...
<xnox> LocutusOfBorg, please work out and fix/re-enable mir support if needed =)
<LocutusOfBorg> yes, I'll probably upload it in ubuntu in a few moments (I need to check in a ppa)
<LocutusOfBorg> and then if the patch is sane enough go in debian too
<Laney> merci
<LocutusOfBorg> thanks to you both for the help
<LocutusOfBorg> but at the end, why isn't it autodetected?
<LocutusOfBorg> I think I should patch configure.ac somewhere, to fix the detection, instead of tweaking rules file
<LocutusOfBorg> "if $PKG_CONFIG --exists mirclient egl xkbcommon ; then"
<LocutusOfBorg> probably just a missing build-dependency
<LocutusOfBorg> I suspect mir support has been broken anyway also before
<LocutusOfBorg> for some little value of "broken" probably?
<Laney> broken how?
<xnox> LocutusOfBorg, it was not broken before
<xnox> checking for Mir support... yes
<xnox> -- dynamic libmirclient -> libmirclient.so.8
<xnox> -- dynamic libxkbcommon -> libxkbcommon.so.0
<xnox> https://launchpadlibrarian.net/196165225/buildlog_ubuntu-vivid-amd64.libsdl2_2.0.2+dfsg1-6ubuntu2_UPLOADING.txt.gz
<LocutusOfBorg> yes, true
<LocutusOfBorg> I'm actually checking, thanks
<LocutusOfBorg> the question is: the autodetect code never worked, but before it was forced in rules file
<LocutusOfBorg> instead of forcing it would be better to fix the configure.ac file maybe?
<tkamppeter> cjwatson, hi
<LocutusOfBorg> ok I found a clie
<LocutusOfBorg> clue
<LocutusOfBorg> autoconf tries to compile a sample program
<LocutusOfBorg>                     MirMotionToolType tool = mir_motion_tool_type_mouse;
<LocutusOfBorg>  
<LocutusOfBorg> but that enum doesn't exist, even if it is in the documentation
<cjwatson> tkamppeter: hi, hwat's up?
<cjwatson> er, what
<cjwatson> excessively Old English there
<tkamppeter> cjwatson, you told me that liblouis-bin would make it automatically into Main when I upload something which depends on liblouis-bin to Main.
<pitti> tkamppeter: not automatically, but it's a prerequisite
<pitti> tkamppeter: it's on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt , I'll promote it now
<pitti> tkamppeter: done, it now just needs a publisher run and mirror sync, so  < 1 h
<cjwatson> beat me to it
<cjwatson> indeed, I didn't explicitly say it was automatic; though I wasn't very clear
<Laney> LocutusOfBorg: looks like that's only in the check
<Laney> you can probably replace it with a version check instead?
<LocutusOfBorg> Laney, it uses the check of a common api to know if the code can be compiled
<LocutusOfBorg> so probably since somebody removed that part of api, I need to have something better-proof call?
<Laney> LocutusOfBorg: yes but it's not like the actual code itself uses API which is removed
<LocutusOfBorg> I'm looking at bzr  mir code to understand the actual replacement
<Laney> can you just pkg-config check for a recent ish version?
<LocutusOfBorg> Laney, this is true, I might also look to some calls that libsdl2 uses
<Laney> instead of try-compiling?
<LocutusOfBorg> since the api seems to change, I would like to keep a try-compile and forward upstream
<Laney> I don't understand, you might pick the wrong bit
<Laney> it's going to fail to build if the API breaks anyway
<LocutusOfBorg> so how do you suggest to fix it?
<LocutusOfBorg> "if $PKG_CONFIG --exists mirclient egl xkbcommon ; then"
<LocutusOfBorg> enable and live happy?
<Laney> If you know a lower bound on the version then you can check for that - there's a PKG_CHECK_MODULES macro
<LocutusOfBorg> I don't know a lower bound unfortunately
<Laney> it says something about 14.04
<Laney> so that's a good indicator, or maybe brandon knows
<LocutusOfBorg> precise isn't supported anymore AFAIK, so no check isn't good? :)
<LocutusOfBorg> I'm a cmake guy, autoconf syntax is obscure to me :)
<LocutusOfBorg> the fix seems to be working
<LocutusOfBorg> but I need to patch it again, because mir changed api
<Laney> LocutusOfBorg: actually it looksl ike you can pass >= to pkg-config --exists, if that's helpful
<Laney> --exists 'libmirclient >= the-version-in-trusty'
<ahasenack> hi guys, what does the SRU queue look like nowadays? I have this bug for which I uploaded packages but they need review by the sru team: https://bugs.launchpad.net/landscape-client/+bug/1508110
<ubottu> Launchpad bug 1508110 in landscape-client (Ubuntu Wily) "Users tab doesn't work as expected" [Undecided,New]
<cjwatson> ahasenack: http://people.canonical.com/~ubuntu-archive/pending-sru.html#upload-queues  I've seen worse
<LocutusOfBorg> Laney, I'll use the one from there
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1513241
<ubottu> Launchpad bug 1513241 in libsdl2 (Ubuntu) "libsdl2 No longer works with MIR 0.14 and greater (ABI/API break)" [Medium,In progress]
<pitti> cjwatson: I'm looking at bug 1537136; does it sound workable/correct if udev-udeb starts shipping a hook /usr/lib/finish-install.d/copy-persistent-net which copies /etc/udev/rules.d/70-persistent-net.rules to /target/etc/udev/rules.d/ ?
<ubottu> bug 1537136 in debian-installer (Ubuntu) "ISST-LTE: no network after install due to interface order change" [High,Triaged] https://launchpad.net/bugs/1537136
<pitti> cjwatson: (sorry, not familiar with udebs at all)
<pitti> just looked at http://d-i.alioth.debian.org/doc/internals/apb.html
<pitti> cjwatson: earlier would be better, so would post-base-installer.d/ be ok?
<pitti> cjwatson: unping, this script already exists, it just seems we aren't installing the generator
<mapreri> pitti: I believe your force for jquery & friends needs some adjustments, since jquery (and friends) are not migrating.
<LocutusOfBorg> Laney, xnox actually due to MIR api changes, libsdl2 wasn't working anymore with the new MIR protocol
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1513241
<ubottu> Launchpad bug 1513241 in libsdl2 (Ubuntu) "libsdl2 No longer works with MIR 0.14 and greater (ABI/API break)" [High,In progress]
<LocutusOfBorg> so it isn't actually a regression, but I promise I'll take care of it :)
<cjwatson> pitti: heh.  right, if the generator isn't in udev-udeb it probably won't work so well
<pitti> cjwatson: my grep apparently didn't catch the base-installer.d/05udev script, so that part should be okay
<tkamppeter> pitti, thank you very much.
<pitti> cjwatson: all the udebs are bundled in netinst's initrd.gz, right? so I could just modify that to install an updated udeb locally
<pitti> mapreri: I can't force the migration as it makes things uninstallable; see "trying: jquery" on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt
<pitti> mapreri: apparently this needs some more rebuilds or porting to the new version
<pitti>     * amd64: gitit, libghc-gitit-data, libghc-gitit-dev, libghc-gitit-prof
<cjwatson> pitti: yep
<pitti> mapreri: those packages become uninstallable with the new jquery
<pitti> cjwatson: ack, thanks
<cjwatson> oh, haskell might be improvable now that aeson is fixed
<cjwatson> (gitit)
<cjwatson> it was stuck for a while
 * cjwatson goes to poke that
<mapreri> thank you.
<mapreri> pitti: wasn't force a thing to ignore uninstallability troubles and migrate that anyway?
<cjwatson> mapreri: not force-skiptest
<cjwatson> mapreri: sure, there are hints to force things really hard but they should almost never be used
<tjaalton> pitti: nfs shares fail to get mounted on boot if using the hostname in fstab, because apparently it can't resolve the hostname yet at that point.. do you know if this is filed somewhere already, or if it's a bug at all?
<tjaalton> and would it be in nfs-utils or elsewhere
<mapreri> ah, then the "forced by pitti" in _excuses means something related to the tests...  I thought it was the same "force" hint for britney...
 * mapreri is learning stuff every time he put his nose inside this channel :D
<cjwatson> pitti: if you need more complicated initrd changes, then you can grab the debian-installer source, drop updated udebs into build/localudebs/, and run "make -C build rebuild_netboot"
<pitti> cjwatson: oh cool, thanks; that seems useful as a more reliable way to test changes
<tjaalton> also, all the hosts here that have sssd set up to use my local directory service kick me out during dist-upgrade to a new release. annoying as hell and no idea what's wrong and where
<cjwatson> mapreri: well, to be fair it does say "Should wait for tests relating to jquery 1.11.3+dfsg-4, but forced by pitti" :-)
<LocutusOfBorg> pitti, I would like to do a no change rebuild against libpodofo0.9.3. for your krename
<pitti> mapreri: right, I forced the tests, but we can't/don't want to force over uninstallability
<LocutusOfBorg> mapreri, ^^^
<pitti> LocutusOfBorg: oh, sure; I can do that with a single command, hang on
<LocutusOfBorg> I have already it pending
<cjwatson> it'll take a couple more days to work through the current ghc transition, assuming nothing else goes wrong with it
<mapreri> pitti: then please also add scribus and calibre to the list â¥
<cjwatson> but I'll try to stay on top of it
<mapreri> (same transition)
<pitti> LocutusOfBorg: krename upload
<pitti> ed
<pitti> $ rebuild-lib-transition libpodofo0.9.3 krename
<pitti> mapreri: for the same libpodofo0.9.3 transition?
<mapreri> pitti: yup.
<LocutusOfBorg> yes
<mapreri> done in debian a cople of days ago
<LocutusOfBorg> pitti, I did stole without shame from cjwatson, adding some bits http://paste.ubuntu.com/14662972/
<pitti> done
<mapreri> cool
<cjwatson> I suspect pitti's scripts are nicer than mine
<pitti> LocutusOfBorg: heh, I guess everyone has their own little helpers for this :/
<cjwatson> That is often the way
<LocutusOfBorg> yes, I'm wondering why there isn't a tool in ubuntu-dev-tools for this
<pitti> cjwatson: by and large the same: http://paste.ubuntu.com/14662976/
<cjwatson> (what LocutusOfBorg pasted isn't exactly mine though, I wouldn't have used the gratuitous/unnecessary bashism :P )
<LocutusOfBorg> :p
<cjwatson> pitti: ah yes, close enough
<LocutusOfBorg> my script should work also after xenial
<LocutusOfBorg> assuming "distro-info --devel" gets updated quickly :)
<LocutusOfBorg> bschaefer, :D
<bschaefer> hello!
 * LocutusOfBorg is waiting for a punch
<LocutusOfBorg> hello and sorry :)
 * bschaefer wonders what happened
<LocutusOfBorg> wrt libsdl2
<bschaefer> reading the comment umm
<bschaefer> LocutusOfBorg, is your patch base on the branch or the WIP branch?
 * bschaefer should just look
<bschaefer> and i would prefer to have mir enabled
<LocutusOfBorg> it is based on the patch on the bug report
<LocutusOfBorg> bschaefer, sure, this is why I would like to upload ASAP
<LocutusOfBorg> we were also talking about just doing some pkg-config --exists mir or whatever
<LocutusOfBorg> without the try-compile
<bschaefer> LocutusOfBorg, the patch needs to be based on this branch: https://code.launchpad.net/~brandontschaefer/+junk/SDL2-new-mir-ABI
<bschaefer> since it fixed quite a few bugs
<bschaefer> umm i made a ppa
<bschaefer> with a patch
<bschaefer> https://launchpad.net/~mir-team/+archive/ubuntu/staging
<LocutusOfBorg> just a question: libsdl2 was broken even before my sync, right?
<LocutusOfBorg> I mean, with a no-change rebuild I would have triggered a build failure?
<bschaefer> LocutusOfBorg, yeah its been broken since mir 0.13
<bschaefer> IIRC
<LocutusOfBorg> ok, this might explain something :D
<LocutusOfBorg> btw, with this patch you know we are enabling mir for everywhere available?
<bschaefer> yeah, just been slow to getting a patch out then saw 2.0.4 being worked
<bschaefer> on soo i waited
<LocutusOfBorg> before it was enabled for i386, amd64, armhf
<LocutusOfBorg> now we are adding arm64, and maybe more
<bschaefer> it should be i386/amd64/armhf
<bschaefer> hmm
<bschaefer> arm64 should be supported
<LocutusOfBorg> ok wonderful
<bschaefer> *should* as in, i think :)
<bschaefer> bregma, ^
<LocutusOfBorg> so can I upload that version?
<LocutusOfBorg> you added "libmirclient-dev" as dependency, in my environment it gets installed automatically
<bschaefer> LocutusOfBorg, the version you attached to the bug? (Im also not *super* excellent on debain packing soo there could be a mistake there)
<bschaefer> or the one in the ppa?
<cjwatson> direct dependencies should be explicit even if they're installed automatically via something else
<LocutusOfBorg> the one from ppa
<cjwatson> simple rule: if you use it explicitly, depend on it explicitly
<LocutusOfBorg> but I'm looking to fix something
<LocutusOfBorg> ok
<bschaefer> if we want to enable mir support by default it will be needed
<bschaefer> but its also not *required* to run SDL2
<bschaefer> but since we want to run mir with sdl2 it should be included explicitly
<bschaefer> LocutusOfBorg, let me ... install that package and test it out
<LocutusOfBorg> bschaefer, I'm uploading in a ppa
<LocutusOfBorg> please wait :D
<bschaefer> o cool
<bschaefer> LocutusOfBorg, since i pushed that patch to a ppa and i tested the source file and checked mir was built
<bschaefer> but i havent tested the ppa out it self yet
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/
<LocutusOfBorg> I did some little changes, from your package
<LocutusOfBorg> (I started from the ppa)
<LocutusOfBorg> 1) changelog merged with the debian one
<LocutusOfBorg> 2) removed the copyright patch parts (your patch was changing back copyright years, I removed the change)
<LocutusOfBorg> 3) rebased the version number
<bschaefer> nice
<LocutusOfBorg> oh I also renamed from .patch to .diff, to be the same as the other patch
<LocutusOfBorg> and I'm adding some verbosity to changelog
<LocutusOfBorg> explaining the ubuntu delta, because I presume I can't upload it on debian
<bregma> bschaefer, once the SDL 2.0.4 package is in Ubuntu, can all the changes just go upstream  so 2.0.5 can be just a plain synch?
<bschaefer> bregma, that would be ideal, and once 2.0.5 hits the patch *should* be removed and all should be well
<bschaefer> LocutusOfBorg, yup, ... once 16.04 hits ill push these changes upstream
<bschaefer> and debian will have it from upstream :)
<LocutusOfBorg> bschaefer, so I'll wait for your ack
<bschaefer> yup adding the ppa now!
<LocutusOfBorg> http://paste.ubuntu.com/14663107/
<LocutusOfBorg> this is the debdiff
<LocutusOfBorg> I just added some verbosity in changelog
<LocutusOfBorg> and as said before rebased the patch
<LocutusOfBorg> but no *useful* changes, and please note: we are enabling mir almost everywhere the test code compiles, not as before
<LocutusOfBorg> +1 for upstreaming changes
<bschaefer> cool, yeah once you see it builds with mir
<bschaefer> and it all compiles it *usually* worked out well :)
<bschaefer> LocutusOfBorg, hmm your ppa ... is losing to the archive :(
<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:
<bschaefer>  *** 2.0.4+dfsg1-2 500
<bschaefer>         500 http://us.archive.ubuntu.com/ubuntu xenial/universe amd64 Packages
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/8893186
<LocutusOfBorg> you can just grab the deb files
<LocutusOfBorg> they aren't published yet I guess
<bschaefer> o
 * bschaefer should have checked that :)
<LocutusOfBorg> checking for Mir support... yes
<LocutusOfBorg> -- dynamic libmirclient -> libmirclient.so.9
<LocutusOfBorg> -- dynamic libxkbcommon -> libxkbcommon.so.0
<LocutusOfBorg> the build seems fine
<bschaefer> cool, sooo now its down to ... did i mess the patch up somehow :)
<jamespage> this has me scratching my head:
<jamespage> old binaries left on amd64: libpe-status4, libpengine4, pacemaker-dbg (from 1.1.13-2ubuntu1)
<jamespage> I'd assumed that it was due to some transitions that needed to be done, which I think I have completed - but I can't figure out what's holding onto those...
<LocutusOfBorg> BTW bschaefer bregma if we force "libmirclient-dev" build-dependency we won't be able to sync it from debian
<LocutusOfBorg> even if the patch is upstreamed
<bschaefer> LocutusOfBorg, upstream wont have libmirclient in its control
<bschaefer> i would assume we would just have a small patch in ubuntu to have that
<LocutusOfBorg> bschaefer, neither debian
<LocutusOfBorg> ok, that was the mean
<LocutusOfBorg> so, plain sync isn't possible
<bschaefer> unless debian has libmir :)
<LocutusOfBorg> I guess not :D
<flexiondotorg> Mirv, you about?
<tkamppeter> pitti, cjwatson, CUPS has built now, thank you for the help.
<bschaefer> LocutusOfBorg, yay terria still works
<tkamppeter> pitti, cjwatson, will CUPS now get from -proposed into -release or do you have to give it a kick to do so?
<bschaefer> :| but mouse doesnt seem to work... hmm one sec
<ginggs_> hi, is there a reason we don't have ceres-solver in ubuntu ? https://tracker.debian.org/pkg/ceres-solver I don't see it in the sync blacklist and it was uploaded to unstable at the end of november.
<cjwatson> tkamppeter: the easiest way to find out is to wait and see
<cjwatson> tkamppeter: normally no manual action is needed though
<cjwatson> jamespage: corner case in the handling of -proposed as a partial suite; I've removed those
<jamespage> cjwatson, ack - thanks
<bschaefer> LocutusOfBorg, ignore my concern! Using an older client
<bschaefer> vs a newer server and i broken the server/client protocol soo no client mouse events
<bschaefer> LocutusOfBorg, patch working correctly for me! +1 to use it
<LocutusOfBorg> so can I push on ubuntu?
<LocutusOfBorg> uploaded :D
<tkamppeter> cjwatson, thanks.
<LocutusOfBorg> thanks a lot bschaefer
<bschaefer> LocutusOfBorg, awesome thanks! didnt expect to get that patch pushed so quickly :)
<bschaefer> thank you!
<LocutusOfBorg> bschaefer, I actually broke the build, so I had to :D
<LocutusOfBorg> for the next time, just ping me, and I'll take care of it
<LocutusOfBorg> BTW In debian we are planning an update of all the sdl2-* related libraries (just bugfixes)
<bschaefer> LocutusOfBorg, awesome, thats good to know
<bschaefer> all the sdl2-* shouldnt cause issues for the mir stuff?
<LocutusOfBorg> and then a question for cjwatson
<bschaefer> at lease i never had to do anything special with those
<LocutusOfBorg> In debian the libpng16 transition is mostly "done" I mean, we patched the sources except for a few build failures, and we are waiting for the release team to proceed
<LocutusOfBorg> I did ~30 NMUs and they are pending, and I'm planning to merge ubuntu whenever possible
<LocutusOfBorg> do you think we can arrange a transition for xenial?
<cjwatson> LocutusOfBorg: let's not have me be in charge of deciding whether to do transitions - I'm not sufficiently on top of things
<LocutusOfBorg> so, moving to -release maybe?
<cjwatson> sure
<LocutusOfBorg> thanks :D
<LocutusOfBorg> bschaefer, I'm also closing the #1513241 bug
<LocutusOfBorg> in changelog
<LocutusOfBorg> wow it is building awesomly fine
<bschaefer> LocutusOfBorg, awesome thanks!
<LocutusOfBorg> now mir is enabled everywhere, lets see how it goes
 * bschaefer hopes quite well
<LocutusOfBorg> thanks to you, without your patch sdl2 would have been in a bad state
<LocutusOfBorg> I should have asked before doing the sync
<bschaefer> LocutusOfBorg, :), didnt *know* anyone needed to be poked but ill know next time! (though hopefully this wont happen again!)
<bschaefer> as it'll be upstream
<LocutusOfBorg> bschaefer, it was me having to poke you before doing the sync
<LocutusOfBorg> but I actually checked the actual delta and it was upstreamed
<LocutusOfBorg> I missed the rules part change
<LocutusOfBorg> and I missed the new patch not yet uploaded
<LocutusOfBorg> but well, now we should be good
<bschaefer> LocutusOfBorg, the reason i held off on the 2.0.3 patch is it didnt cleanly go from working with 2.0.3 --> 2.0.4...
<bschaefer> for some reason
<bschaefer> sooo i figured i should wait
<LocutusOfBorg> I hope it is fine now
<sil2100> mvo_: hey! I see you're doing commits to goget-ubuntu-touch along with Sergio - could you take a look at my quick noob MP by any chance? Nothing too urgent tho! https://code.launchpad.net/~sil2100/goget-ubuntu-touch/touch-devel-warning/+merge/282045
<bschaefer> building is a good start!
<mvo_> sil2100: sure, I have a look
<sil2100> mvo_: thank you!
<doko> pitti, is this temporary? http://autopkgtest.ubuntu.com/packages/r/ruby-redcarpet/xenial/s390x/ ?
<pitti> doko: temporary how? It had been uninstallable for a while, but apparently that got resolved now?
<doko> pitti, you only answered after it passed
<pitti> doko: ah, ok; so I guess ruby 2.2.4 makes it installable?
<doko> pitti, no, that's unrelated
<tsimonq2> having a bit of a problem, trying to branch a Bazaar repo and I keep getting public key errors. But my GPG key is imported correctly in Launchpad...what should I do?
<sarnold> is the error instead in your ssh config?
<tsimonq2> sarnold: what do you mean?
<tsimonq2> keep getting:
<tsimonq2> Permission denied (publickey).
<tsimonq2> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
<tsimonq2> Permission denied (publickey).
<tsimonq2> bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist.
<tsimonq2> (sorry for the paste, it's only 4 lines)
<sarnold> tsimonq2: yeah, that looks like an ssh error instead of gnupg -- does launchpad know the ssh public key you're using?
<sarnold> (at least I think it needs your ssh key.. it's been years since I set that up)
<roadmr> yes, what you need is ssh key for that
<roadmr> tsimonq2: need to add your SSH public key (usually .ssh/id_rsa.pub) here: https://launchpad.net/~/+editsshkeys
<tsimonq2> and I did
<roadmr> tsimonq2: oh yes it's there :)
<tsimonq2> http://keyserver.ubuntu.com:11371/pks/lookup?fingerprint=on&op=index&search=0x9C6058DF83975841F42717F99F9292DB1C174C6F
<tsimonq2> this is the one on THIS computer
<roadmr> tsimonq2: hm, what you're showing is a gpg key, not ssh key
<sarnold> that looks like a gpg key, not ssh
<sarnold> it'd be one of these two https://launchpad.net/%7Etsimonq2/+sshkeys
<tsimonq2> and this is my gpg --list-keys output(taking away my private key :P):
<tsimonq2> pub   4096R/1C174C6F 2015-12-05 [expires: 2016-06-02]
<tsimonq2> uid                  Simon Quigley <sqawesome99@gmail.com>
<roadmr> tsimonq2: what happens if you try ssh bazaar.launchpad.net ? (it should reply "No shells on this server.")
<tsimonq2> Permission denied (publickey).
<tsimonq2> oh I SEE...I'll look at my ssh keys
<tsimonq2> yay thanks guys
<sarnold> hah, my ssh bazaar.launchpad.net fails too. but my bzr+ssh tree still works.. go figure.
#ubuntu-devel 2016-01-26
<doko> tumbleweed, jtaylor, barry, pitti: migration of python-numpy is needed for the python3.4 removal. any ideas?
 * tumbleweed looks
<barry> numpy itself is failing, but maybe that's shallow
<barry> (failing on py27?)
<jtaylor> doko: whats blocking it?
<jtaylor> oh the failure itself is simple
<jtaylor> too bad morph doesn't care about adt tests :(
<jtaylor> df70490874e33e1fad18720f5c74fb5e319c9e06 is the fix
<jtaylor> fwiw scipy will fail with that numpy but an upload for that is waiting on a sphinx update
<jtaylor> should be done soon
<doko> jtaylor, well, then why does he add these?
<jtaylor> doko: I added them
<doko> bad jtaylor ;-P
<tsimonq2> ok, so I really don't know who to contact so I came here. I was looking at FTBFS and I noticed hplip was failing builds. So I peeked at the logs and it had a dependency error of cups that was already in the repos. On my machine, the build was successful. Where should I file a bug? Who should I report it to?
<tsimonq2> and it builds successfully upstream
<tsimonq2> hplip is in main
<tsimonq2> should this go in #ubuntu+1-maint?
<cjwatson> tsimonq2: Probably fixed by the recent promotion of liblouis-bin to main.  I've retried the failed builds.
<tsimonq2> cjwatson: ok thanks
 * tsimonq2 watches the builds :D
<Pharaoh_Atem> woo!
<Pharaoh_Atem> I've finally made progress on the apache configs for php7.0
<tsimonq2> can this bug be attached to apt in FTBFS? thanks! https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923
<ubottu> Launchpad bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,New]
<tarpman> mdeslaur: don't suppose you would have any insight into bug 1537762...? bit short on details unfortunately
<ubottu> bug 1537762 in openldap (Ubuntu) "syncrepl does not work when using tls" [Undecided,Incomplete] https://launchpad.net/bugs/1537762
<sarnold> tarpman: it reminds me a little of https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1534230  -- the openssl s_client and openssl x509 advice there may help debug that
<ubottu> Launchpad bug 1534230 in gnutls26 (Ubuntu) "LDAP TLS connection stopped working" [Undecided,Invalid]
<sarnold> pity these bugs elide the useful details; it'd take one of us a few seconds to check.. oh well.
<tarpman> to be fair, slapd's logging of tls errors leaves something (a lot) to be desired... I have a wishlist bug for that around here somewhere :)
<sarnold> hehe :)
<tarpman> yeah, that definitely looks relevant. thanks, posting the link now (unless you beat me to it)
<sarnold> go ahead
<tarpman> I always have to /whois you to remind myself you're not my former coworker with the same first initial last name :P
<sarnold> the guy who's been stealing my username!
<tarpman> heh, I don't think he IRCs...
<tsimonq2> I looked into devscripts on FTBFS, it seems like there is no longer a dependency problem but a build problem. Can someone please do a build to confirm this and to get bugs filed? Thanks!
<tsimonq2> It also seems like this is a problem on our part, since Debian's autobuilders succeed: https://buildd.debian.org/status/fetch.php?pkg=devscripts&arch=i386&ver=2.15.10&stamp=1451535039
<tsimonq2> looking at FTBFS again, can graphite2 be rebuilt? I might have some local problems but I know the dependency problems are fixed...
<cpaelzer> good morning
<pitti> Good morning
<lathiat> morning
<pitti> hey lathiat, good morning!
<pitti> doko: looking at the regessions; I uploaded the fix for numexpr
<pitti> doko: the "Specified path is invalid." warning in python-numpy is real, and does not happen with 1.8.2
<pitti> doko: it tries to os.path.isdir('') which is the value of runtime_library_dirs which gets initialized to []
<pitti> doko: this whole system_info code is new in 1.10 apparently
<pitti> doko: I mean the part with the default_runtime_dirs, there's a few other default_*_dirs already
<LocutusOfBorg> hi cjwatson a question wrt iulib
<LocutusOfBorg> can I steal your merge? if so, can we fakesync it?
<LocutusOfBorg> not sure what does it mean :)
<henrix> pitti: may i have some tests lxc tests re-run please: run-autopkgtest -s trusty -a ppc64el --trigger linux-meta/3.13.0.77.83 lxc
<pitti> henrix: started
<henrix> pitti: awesome, thanks!
<pitti> mdeslaur: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php5 apparently regresses php-crypt-gpg and php-horde-icalendar, can you please have a look? (the other regressions are already overridden)
<doko> that blocks the python3.4 removal
<pitti> cjwatson: do you know a trick how to get the -images tarball from https://launchpad.net/~pitti/+archive/ubuntu/sru-test/+build/8897111 ?
<pitti> or do PPAs simply not do that?
<jamespage> cking, are the zfs package bits aiming for main inclusion for 16.04? I was pondering enabling support in ceph for zfs but would need libzfslinux-dev in main for that
<cking> jamespage, we hoping to get it into main, I've filed a MIR, so it's Work-in-Progress
<mitya57> pitti, can you please make qbzr autopkgtest not blocking pygments migration? It's not a regression, but rather something seasonal (https://bugs.debian.org/776188#10)
<ubottu> Debian bug 776188 in src:qbzr "qbzr: autopkgtest fails since 2015-01-01" [Normal,Open]
<mitya57> (and I've just fixed sphinx which was a real regression)
<Laney> mitya57: wtf at that
<Laney> but can't it be fixed?
<mitya57> I quickly looked at it, and didn't see an easy way to fix it.
<mitya57> And I don't have much time today to dig into that code.
<henrix> pitti: can i also have this please? run-autopkgtest -s wily -a armhf --trigger linux-meta/4.2.0.27.30 flashcache
<pitti> henrix: done
<henrix> pitti: thanks
<pitti> mitya57: "the tests
<pitti> fail on months containing J, that is Januarys, Junes and Julys"
<pitti> !
<pitti> mitya57: it's not nearly as good as the infamous "OpenOffice does not print on Tuesdays" bug, but still fun :)
<mitya57> :)
<pitti> mitya57: but the sphinx regression is really recent (it started failing on the new pygments), so that needs looking into
<mitya57> pitti, I've uploaded new sphinx fixing the issue
<pitti> mitya57: ah great! I hinted qbzr
<mitya57> Thanks!
<mdeslaur> pitti: yes, I'll look today (php5 migration failure)
<pitti> mdeslaur: thanks
<pitti> cjwatson: unping; the build log plus local build are sufficient
<cjwatson> LocutusOfBorg: Feel free to steal my iulib merge, don't mind what you do with it after that
<quadrisp1o> pitti, no need to say that I trust you, so next time on libmtp you want to fix something, just fix it :)
<pitti> quadrisp1o: ok :)
<quadrisp1o> feel free to add yourself to Uploaders
<pitti> quadrisp1o: we don't need an upload just for this, but good to know that we don't have a permanent delta because of this now
<cjwatson> pitti: I don't think you can get the tarball as such, but it's unpacked and published to your PPA in the usual place - http://ppa.launchpad.net/pitti/sru-test/ubuntu/dists/trusty/main/installer-amd64/20101020ubuntu318.34/images/
<pitti> cjwatson: oh! I guess that was too obvious, thanks!
<tjaalton> doko: hi, llvm 3.8-rc1 got released, do you know if sylvestre plans to work on it soon?
<doko> tjaalton, no
<tjaalton> doko: ok, I'll ask him
<doko> ta
<LocutusOfBorg> cjwatson, question: the delta is now dropped, unfortunately the version naming is strange 0.4+is+0.3-3ubuntu2
<LocutusOfBorg> so I don't think I can sync
<LocutusOfBorg> do you have any advice? just rename the last entry and upload?
<pitti> apw: do you still remember what we meant in bug 1497291?
<tjaalton> doko: turns out it's already uploaded to experimental, but in NEW
<ubottu> bug 1497291 in Auto Package Testing "britney is requesting/reporting test results for reverse-depends architectures even when used in forward context" [Undecided,New] https://launchpad.net/bugs/1497291
<cjwatson> LocutusOfBorg: I would probably apply the same changes so that it's effectively in sync and call it 0.4+is+0.3-3ubuntu3; not much else we can do until the version in Debian increases to something past ours
<LocutusOfBorg> thanks, I was wondering about epoch in debian and sync :)
<LocutusOfBorg> anyhow, I just changed the last changelog entry and uploaded
<LocutusOfBorg> thanks
<apw> pitti, i am reading that as when running a test for foo which triggers linux-keystone that it triggers tests for all of foo's architectures not all of linux-keystones'
<rbasak> LocutusOfBorg: an epoch would be permenant. At least this way the mess is temporary.
<apw> pitti, but ... it is rather vague
<LocutusOfBorg> rbasak, sure, I really don't like epoch too
 * LocutusOfBorg never bumped an epoch
<pitti> apw: hm, I thought that got fixed a long time ago already
<apw> pitti, may well so
<pitti> apw: the bug says that http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#linux-meta-keystone was wrong, but it currently looks right, doesn't it?
<apw> pitti, yep looks right.  i'd be inclined to call it fixed as we'll never know anyhow now :)(
<apw> :)
<pitti> apw: ack
<LocutusOfBorg> question, an ubuntu delta about renaming library for gcc5 transition ( pitti ), can be dropped after wily?
<LocutusOfBorg> package: libclaw
<pitti> LocutusOfBorg: no, after xenial only, as we need to support trusty â xenial upgrades
<LocutusOfBorg> if not: can I steal your merge?
<pitti> LocutusOfBorg: please do steal, thanks!
<LocutusOfBorg> :D
<LocutusOfBorg> thanks to you
 * tsimonq2 wonders if he should repost wht he said yesterday, following up on some FTBFS issues...
<pitti> apw: FYI, we have a slight technical hitch (aka "we kill all instances"): http://paste.ubuntu.com/14671742/
<apw> pitti, that doesn't look good
<apw> pitti, any idea what is triggering that ?
<pitti> Laney: let's move here, to have everyone on the same channel
<pitti> apw: I figure apt pinning + dist-upgrade again, let me check
<apw> pitti, oh it might not be a real issue, one we are generating in the test environment
<LocutusOfBorg> pitti, it can be syncd
<LocutusOfBorg> I missed that debian renamed the library too
<pitti> LocutusOfBorg: heh, they better did; nice
<LocutusOfBorg> I was looking at the latest changelog entry, missing the previous one
<LocutusOfBorg> and complaining about "why the hell the patch doesn't apply", when I discovered it was already there :p
<pitti> LocutusOfBorg: someone (you?) already synced
<LocutusOfBorg> me
<tsimonq2> After using an schroot, is there anything I have to do to clean it?
<LocutusOfBorg> as you have noted, I'm merging all the libpng-dev packages from debian
<tsimonq2> For building a package
<pitti> apw, Laney: yep, --apt-pocket=proposed=src:init-system-helpers does that; yay apt pinning being too clumsy :/
<pitti> I'll disable it for a moment, let the i-s-h tests  run, and re-enable it
<LocutusOfBorg> mterry, can I steal your xaos merge?
<cjwatson> LocutusOfBorg: doesn't need an epoch; the version in experimental is already greater than what we have, so we should be fine when it gets to unstable
<LocutusOfBorg> cjwatson, yes, sure
<LocutusOfBorg> BTW the revert was back to oneiric
<LocutusOfBorg> when a reverse-dependency that now disappeared was needing the old version
<LocutusOfBorg> so I presume without it, we might also push experimental to unstable and force-sync
<LocutusOfBorg> but I prefer to concentrate to fixing libpng
<mterry> LocutusOfBorg, sure thanks
<apw> pitti, phew (in a way)
<pitti> dear apt: pinning priority of 800 does not mean "OMG stay away from it like the plague!"
<pitti> Laney: so *now* it will test everything with kernel 4.4 too (without apt pinning, I mean) :)
<Laney> pitti: heh
<Laney> pitti: there's a forced lockstep upgrade of i-s-h and sysvinit-utils
<LocutusOfBorg> xaos can be syncd
<Laney> I guess this explodes apt
<pitti> Laney: right
<pitti> Laney: well, it's fine without pinning, but if you say "prefer the i-s-h binaries from -proposed" it doesn't grok that it should use proposed for the necessary dependencies too
<pitti> Laney: it seems like it's either "ish binary deps are completely satisfiable in -release" or "I refuse"
<apw> pitti, i thought that when things failed with pinning it fell back to enabling -proposed en-toto ?
<pitti> apw: yes, but that's the early dist-upgrade
<apw> oh heh only there, ok
<pitti> way before installing the test deps
<pitti> and it doesn't technically fail
<pitti> it "just" removes openss..
<pitti> h
<apw> pitti, hehe that must be a little bit disruptive to results gathering :)
<pitti> since apt pinning is so completely useless for every nontrivial case, I wonder if there's a different approach that we can take
<apw> pitti, we know the versions of them don't we, can we not install foo=version
<pitti> perhaps, first install everything from -release, *then* add -proposed apt source, and install everything again
<pitti> then it should not upgrade stuff unless dependencies mandate it
<apw> that sounds feasable
<pitti> I don't want to rewrite apt's resolver, no
<pitti> just make it less greedy with picking stuff from -proposed, or alternatively fix the apt pinning to actually fall back from 900 -proposed to 800 -release
 * apw doesn't even want to look at apt's resolver :)
<pitti> that sounds like a nice thing to look at tomorrow morning in the train
<tsimonq2> in FTBFS, libsecret is failing due to gjs not being in main but Universe, and there is no Mir bug filed...should *I* file one, not being the maintainer?
<apw> i think upgrade from !-proposed, install triggers, add -proposed, install triggers would do pretty well, and better than it does now
<apw> pitti, and remember thats not -release but -updates in the older releases
<pitti> yeah, but same thing in this context
<Laney> I guess that would improve things, yeah
<tsimonq2> same situation with appstream-glib depending on libgcab-dev...
<pitti> apw: so in the second step we would iterate over all binaries of the triggers, check if they are instaslled, and if so, apt-get install them again
<Laney> The other thing is to move testing to another phase after _output
<pitti> (as we don't want to blindly install all binaries of the trigger -- that might not even be possible)
<Laney> and do it per transaction
<pitti> I wonder how that  would fail with library transitions
<apw> pitti, yeah good point
<pitti> and for binNEW, or even source NEW, etc. (the trigger might not even *be* in teh release yeat)
<pitti> yet
<pitti> so, it's not going to become any easier (the contrary), just perhaps more useful
<Laney> (Then you test the set of things you're trying to migrate)
<pitti> Laney: "move testing to another phase after _output" â can't parse, sorry
<Laney> excuses -> output -> test -> migrate
<Laney> i.e. test things after they become a candidatge
<pitti> Laney: ah, to avoid running into uninstallability
<Laney> because britney has then worked out the transactions already
<Laney> and those are the units of migration
<pitti> interesting idea
<Laney> so you'd make a fake Packages file or something which represents those
<pitti> Laney: or we could pin all binaries involved in that transaction
<pitti> Laney: which should work again, as that ought to be a closed set
<pitti> Laney: sounds elegant, but we would then start depending on being able to download update_output.txt from everywhere
<pitti> and more importantly, depending on that it is actually current
<LocutusOfBorg> sarnold, can I sync flogwatch? your security update seems icluded in the debian version (new release)
<Laney> pitti: Hm? I imagine you'd feed the requests from britney still, just at a later phase
<Laney> pitti: can't use update_output now as the packages we're testing aren't candidates yet so they don't appear there
<pitti> Laney: oh right, you mean britney will forward the set of packages as test parameter, so that the worker can just add them to --apt-pocket=proposed=src:a,src:b, etc.
<pitti> so, this is quite a heavy piece of reengineering, but sounds interesting indeed
<Laney> pitti: I would ditch the pinning and just make a fake release as this is more robust
<Laney> but it might work either way
<Laney> definitely a lot of reworking
<pitti> Laney: oh, you mean: apt-get update, create fake _Packages from the complete proposed_Packages and the sources we want, and replace -proposed apt source withthat
<pitti> that doesn't work, as dependencies from the ones "we want" might also just be in -proposed
<Laney> pitti: britney is saying that it wants to remove the -release package and all its binaries and put the -proposed one(s) and all its binaries in
<pitti> so for that we need the britney "give me the complet set" features
<Laney> yes
<pitti> Laney: but once we have that, apt pinning works equally well :)
<Laney> that's what update_output knows
<Laney> pitti: I don't think that's the most important part of the proposal, so whichever way you like
<Laney> The other way feels more like "this is the state we are trying to mutate -release into" to me
<Laney> no possibility of an unclean environment
<Laney> but, doesn't matter that much
 * Laney goes to write weekly report
<LocutusOfBorg> mitya57, can you please merge tracker from debian?
<mitya57> LocutusOfBorg, sure
<smoser> hey, do we have a plan for signed firefox addons ?
<smoser> just upgraded and see that 'Uubntu Online Accounts', 'Unity Desktop Integration', 'Unity Websites integration' have all been disabled.
<smoser> in addition to pentadactyl which i actually care about (https://github.com/5digits/dactyl/issues/99)
<mitya57> LocutusOfBorg, done
<LocutusOfBorg> mitya57, <3
<smoser> barry, we are close https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1538198
<ubottu> Launchpad bug 1538198 in python-defaults (Ubuntu) "python in xenial cloud image" [Undecided,New]
<smoser> no real digging yet as to what is getting the remaining bits pulled in.
<barry> smoser: cool, thanks.  i'm subscribed now.
<slangasek> pitti: hi, re: bug #1537211, your changelog makes it sound like you're dropping the attachment of /var/log/udev rather than replacing it with attaching the udevadm info output?
<ubottu> bug 1537211 in libmtp (Debian) "clean up /var/log/udev.log" [Unknown,New] https://launchpad.net/bugs/1537211
<pitti> slangasek: attaching udevadm dump already has happened for a long time (UdevDb: field)
<slangasek> pitti: hah ok
<slangasek> pitti: thanks :)
<smoser> lamont, around ?
<smoser> you're postfix maintainer... postfix seems to be what is pulling in python in cloud image http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.xenial/cloud-image.depends
<lamont> smoser: sigh
<smoser> https://bugs.launchpad.net/ubuntu/+source/python-defaults/+bug/1538198
<ubottu> Launchpad bug 1538198 in python-defaults (Ubuntu) "python in xenial cloud image" [Undecided,New]
<lamont> otp
<smoser> its Recommends.
<smoser> i'll poke a bit, but if you know why, and if we could do anything, that'd be good.
<lamont> smoser: looks like https://bugs.launchpad.net/bugs/1538198 and some scripts that need to be taught about python3, and a change in Recommends
<ubottu> Launchpad bug 1538198 in postfix (Ubuntu) "python in xenial cloud image" [High,Confirmed]
<lamont> bah
<lamont> smoser: rather, * Recommend: python for postfix-add-* scripts. <-- that change
<lamont> so postfix-add-* scripts need to learn about pytho3n
<smoser> lamont, yeah. see bug, i posted a hack/quick 10 minute try
<lamont> I expect to have some time on the plane this weekend, which is doubtlessly not soon enough for your happiness.
<smoser> well, thats fine with me. we're down to just that in the image to my knowledge.
<lamont> oh, cool
 * lamont adds it to his plane-fun
<lamont> though, tbf, it's more airport-fun, I plan to sleep on at least the first leg
<smoser> if you want, you can give my patch a try. i just verified running 'python3 <path>.py' worked for everything.
<lamont> smoser: uh... you do the ubuntu1 version and I'll merge it upstream?
<lamont> bounus if the hacked file runs under both :D
<smoser> well, want to test it . i just verrified compiles
<smoser> SHIP IT!
<rbasak> I think "mk-sbuild sid" may be broken on Xenial. Not confirmed fresh yet. /dev/null inside the chroot ends up 644. Anyone else seen this?
<rbasak> "mk-sbuild xenial" is fine.
<mdeslaur> xnox: did you get nodejs to build on s390x?
<smoser> lamont, anoterh patch there now. this one passes pylint's checker
<lamont> heh
<lamont> thanks
<lamont> I wonder, does launchpad bugs have anything like debian's bts (cli) for offline bug processing and perusal?  thinking "wut? no..."
<rbasak> Launchpad has an API, so you could write a CLI I guess, if nobody's done that.
<rbasak> You can change bug statuses via email.
<lamont> rbasak: the question was one of totally not wanting to write it, just wanting to be able to read the bug while wifi-disconneted. :/
<lamont> so no worries, I guess
<mdeslaur> lamont: what's this "offline" thing you talk about?
<lamont> mdeslaur: sometimes, it's my life. :(
<rbasak> mdeslaur: says the security guy :-P
<lamont> rbasak: to the security guy :D
<mdeslaur> you don't get security updates when you're offline! :P
<rbasak> Tell me that when you show me a CVE that affects my offline single-user machine :)
 * rbasak half expects one to exist
<Odd_Bloke> CVE-2016-0123: rbasak left his front door unlocked
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-0123)
<lamont> lol
<mdeslaur> hehehe
<tedg> hallyn: So if I add a dep on libpam-cgm, should that be a "libpam-cgm | libpam-cgfs" ?
<hallyn> tedg: or rather libpam-cgfs | libpam-cgm
<tedg> K
<rbasak> It's debootstrap that's broken I think. It now creates /dev/null as 644 because it runs mknod directly and doesn't set permissions.
 * rbasak files a bug.
<sarnold> maybe try with umask 0 to see if that unblocks you?
<rbasak> sarnold: I'm just reverting the upstream commit that caused the regression - http://anonscm.debian.org/cgit/d-i/debootstrap.git/commit/?id=5518b79792dd93a416464c0744b87eb1a32ff770
<rbasak> I just patched the functions file in reverse, and I think I'm good for now.
<sarnold> rbasak: hah, nice fix..
<Pharaoh_Atem> rbasak: so I've got a question
<rbasak> Pharaoh_Atem: o/
<rbasak> Sure
<Pharaoh_Atem> I've got working dep8 tests for php7.0 now
<rbasak> \o/
<Pharaoh_Atem> and I've even added an fpm one
<Pharaoh_Atem> but my problem is how to handle adding the php-fpm httpd config to the php package
<Pharaoh_Atem> because right now, the php package does not provide one
<nacc> Pharaoh_Atem: heya!
<Pharaoh_Atem> nacc: yo!
<Pharaoh_Atem> I saw your post on LP
<rbasak> If I understand you correctly, you can just drop it into the test
<rbasak> You don't need the package to provide one specifically; the test can have a local copy of what it needs.
<Pharaoh_Atem> well, the config doesn't exist _at all_ in the php package, so there's no a2enconf or whatever for making php-fpm receive httpd input
<rbasak> You have some way of making it work, right?
<rbasak> If you can script that way, then the test is just that script.
<Pharaoh_Atem> I wrote a config file and dropped it onto my local xenial install
<Pharaoh_Atem> but it might make sense to actually provide it as something people could use, too
<rbasak> Sure
<Pharaoh_Atem> that's what I need your advice on
<Pharaoh_Atem> I don't know how to go about this
<rbasak> Until it provides it, you can write the test as you like. Either "cat > /foo <<EOT\nconfig_here\nEOT" within the script, or ship the file in debian/tests/foo.conf and have the script copy it in.
<Pharaoh_Atem> ah
<Pharaoh_Atem> well, then, I guess I'll do that
<Pharaoh_Atem> I'll prepare a git patch for you in a bit
<rbasak> The test should declare "needs-root breaks-testbed" and the dep8 runner will do the right thing.
<rbasak> (revert the VM or container before running the next test, etc)
<Pharaoh_Atem> ah
<rbasak> If it makes sense for the package to ship some configs, then that'd probably be best to send in a patch to Ondrej, and coordinate with him on what he thinks is suitable, etc.
<ximion1> robert_ancell: you really want to MIR AppStream itself: https://packages.debian.org/source/sid/appstream
<robert_ancell> ximion1, ta, will do that one too
<ximion1> if Protobuf and Qt5Core are in main for Ubuntu, it should have no dependencies on stuff which isn't already there
<ximion1> let me know if if you need any help :)
<juliank> Meanwhile APT 1.2/1.2.1 and squashfs-tools are still in depwait due to lz4 MIR bug 1531923
<ubottu> bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,Confirmed] https://launchpad.net/bugs/1531923
<xnox> mdeslaur, nope. it's strange it build on debian but not on ubuntu. Even if I, e.g. disable pie too. And i don't see anything obvious. I shall engage upstream on that.
<xnox> mdeslaur, well porters in question.
#ubuntu-devel 2016-01-27
<doko> finally, python-support removed from Debian
<doko> barry, jtaylor tumbleweed: now let's ditch it for xenial ;-P
<doko> cyphermox, one more shadow upload without a merge :-/
<cyphermox> hrm?
<cyphermox> that was an upload to trusty...
<doko> cyphermox, ohh, trusty only
<tumbleweed> doko: IIRC we're ready for that
<cyphermox> I'll get back to merges soon, but for now 14.04.4 takes priority
<tumbleweed> ginggs filed a RM bug, I think?
<doko> tumbleweed, reverse-depends tells otherwise
<tumbleweed> doko: LP: #1535318
<ubottu> Launchpad bug 1535318 in lernid (Ubuntu) "deprecation of python-support" [Undecided,In progress] https://launchpad.net/bugs/1535318
<doko> ahh, cool
<tumbleweed> doko: basically, everything that's left was either removed from testing or is ubuntu cruft
<kees> slangasek: openssh in proposed. wat? collided? do I need to reupload?
<kees> oh, I see. no need to reupload.
<pitti> Good morning
<alkisg> bdrung, bdrung_work, hi, adblock from the xul ppa has stopped working, a signed version is now needed with firefox 44. Would it be possible to upload adblock 2.7.1? Thank you very much for maintaining this!
<lukesoft> Hi Guys, Really trying to get going with contributing to ubuntu......but iam getting some bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/tomboy/"
<lukesoft> can you please point me in the right direction
<pitti> lukesoft: don't use the UDD branches any more; they are not maintained any more and don't exist for xenial
<pitti> lukesoft: just use "apt-get source tomboy" (there is no Ubuntu VCS for tomboy)
<lukesoft> oooh ok thanks...let me try that
<lukesoft> pitti: so when can i get the new tutorials, coz i was following the one on ubuntu packacking...Is this now obsolete
<lukesoft> *where
<pitti> lukesoft: the existing one mentions apt-get source; but we are currently working on providing git branches for all packages, until then I don't think that the tutorial will be changed
<bdrung_work> alkisg, i'll put updating adblock-plus on my todo list
<bdrung_work> alkisg, a new release won't fix the problem with the signature: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1532484
<ubottu> Launchpad bug 1532484 in iceweasel (Debian) "Don't warn about unsigned extension installed via Debian packages" [Unknown,Fix released]
<lukemadzedze> Guys which programming languages are used if want to contribute to the so called MOTU
<lukemadzedze> or it depends on the package
<lukemadzedze> Do all packages use the same language
<alkisg> bdrung_work: ouch, does that mean that the patch you proposed there won't be integrated in Ubuntu unless it's accepted by chrisccoulson or someone else?
<alkisg> The patch does seem pretty simple and safe...
<alkisg> Or should we spend effort on trying to convince upstream mozilla instead?
<bdrung_work> alkisg, it's on my todo list to write a mail to ubuntu-devel to start a discussion about it. convincing upstream would be the best option (they should provide a configure switch for it)
<alkisg> Thank you very much bdrung_work, I'll put that bug in the affects me too list and wish for the best :)
<bdrung_work> alkisg, feel free to open an upstream bug and link it to the lp bug
 * alkisg reads the debian bug to see if the folks there already filed an upstream bug...
<cjwatson> lukemadzedze: depends entirely on the package; a wide variety of languages is used; the most common would probably be C, C++, Python, Perl, some Java and some of various functional languages, and various bits of shell and make and such in build systems.  Most important to be flexible
<lukemadzedze> member:cjwatson: thanks a lot
<LocutusOfBorg> sil2100, seems like a new ppp has been uploaded in debian
<LocutusOfBorg> do you care to merge it?
<sil2100> Oh, sure thing o/
<LocutusOfBorg> thanks
<lukesoft> guys is there a way to find out which language a package is developed in, before i start trying to fixing its bug...or even downloading the sorces
<lukesoft> sources
<dx> hi! how long do "debian imports" take? i see a freeze deadline in february 18 and i'm wondering when i should get the packages in debian testing to ensure they get in 16.04
<cjwatson> dx: the auto-sync process runs from unstable, not testing; and it takes at worst around half a day from Debian upload, depending on the vagaries of dinstall timing and other similar cron jobs
<dx> excellent
<dx> it's like you just replied "-7 days"
<gpiccoli> Hello, sorry to bother. I want to download kernel 4.4 for xenial, but it seems this kernel is not present in ppa unstable anymore
<gpiccoli> Can someone help me with this?
<bjf> gpiccoli, it's in -proposed
<gpiccoli> Can you point me the URL bjf?
<bjf> gpiccoli, https://launchpad.net/ubuntu/+source/linux/4.4.0-1.15/+build/8880824
<gpiccoli> Thanks bjf! But I'm on ppc64el.
<gpiccoli> Do you have a generic PPA or something like this?
<bjf> gpiccoli, https://launchpad.net/ubuntu/+source/linux/4.4.0-1.15/+build/8880829
<gpiccoli> Thanks very much bjf
<cjwatson> dx: heh
<dx> also, pidgin released 2.10.12, the debian package maintainer doesn't seem to be active and the pidgin in wily has buggy patches. what should i do to ensure the buggy package doesn't get in xenial?
<dx> more launchpad tickets?
<dx> the bug i'm referring to: https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/1479715
<ubottu> Launchpad bug 1479715 in pidgin (Ubuntu) "Crash due to fd leak when playing sounds in pidgin" [High,Confirmed]
<seb128> dx, no, more tickets isn't helping to get work done, send rather a debdiff for the update if you want to help with it
<dx> seb128: a debdiff with the version bump + removal of local patches?
<dx> and attach it to that bug?
<bdmurray> didrocks: Could you have a look at bug 1532355 since you've touched plymouth a fair bit recently?
<ubottu> bug 1532355 in initramfs-tools (Ubuntu Xenial) "package linux-image-4.3.0-5-generic 4.3.0-5.16 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 2" [High,Triaged] https://launchpad.net/bugs/1532355
<didrocks> bdmurray: this shouldn't hang up boot anyway, on the warning, do you have a way to reproduce this setup?
<Laney> did anyone look at gradle/component-mismatches yet?
 * Laney doesn't see what is pulilng it into main immediately
<pitti> Laney: ugh @ http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<Laney> pitti: I know right
<Laney> I ran the dmb packageset script and it wanted to add haskell-* to "core"
<Laney> "um, nope"
<pitti>    [Reverse-Build-Depends: libspring-java]
<pitti> hm, which is itself universe
<Laney> indeed
<bdmurray> didrocks: Some of the duplicates look like dist upgrades from Wily
<Laney> I got approximately that far
<Laney> germinate took me in a circle
<cjwatson> Laney: pretty sure I looked through that a while back, let me find the log
<pitti> looks like pandoc pulls in gradle?
<cjwatson> the actual answer is higher up than that I think
<cjwatson> aha
<cjwatson> 02:16 <cjwatson>   "libcommons-net-java" -> "build-helper-maven-plugin" [label=" B" color="blue" fontcolor="blue"]
<cjwatson> that ends up pulling in all the things via a tortuous path
<cjwatson> infinity and I had to resort to crawling through graphviz output to find that
<pitti> wow, that pulls in haskell now?
<cjwatson> pandoc is haskell
<cjwatson> and something wants that
<Laney>  libcommons-net-java | 3.4-2         | xenial          | all
<Laney>  libcommons-net-java | 3.4-2         | xenial/universe | source
<cjwatson> but libcommons-net-java was the root of it last I looked
<pitti> there must still be a bug somewhere -- there should be one green ("already in main") package somewhere in that cluster, but isn't
<cjwatson> I think it's that way because of incomplete promotions/demotions
<pitti> oh, source in uninverse, binary in main
<cjwatson> I forget the exact reasoning but it made sense once I unpicked it
<awe_> seb128, do you have some time to check out mp for bluez; it bumps us to 5.37 & syncs us with the fixes in touch...
<Laney> It looks like libcommons-net-java took over from libcommons-net1-java
<Laney> and has all the build-depends
<Odd_Bloke> cjwatson: Do you have a minute for a livecd-rootfs merge and upload?  (https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/ppc64el/+merge/284152)
<Odd_Bloke> cjwatson: Oh, actually, hold on; might need to tweak that slightly.
<cjwatson> Odd_Bloke: urr.  too late
<cjwatson> (rather, I saw that too late due to uploading rather than watching IRC)
<Odd_Bloke> cjwatson: No worries, it's not broken, there's just another issue that needs fixing too.  Sorry for jumping the gun on the request. :(
<rharper> rbasak: for https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1511735 ; what am I missing for SRU to trusty, next steps?
<ubottu> Launchpad bug 1511735 in libnl3 (Ubuntu Trusty) "libnl: fail to bind() netlink sockets" [Undecided,New]
<rbasak> rharper: looks good process-wise. Just need review and sponsorship. How do you feel about the regression risk? Are you confident about the patches and their impact?
 * rharper reviews what he wrote a while ago
<rbasak> rharper: I'm swamped with MySQL now, and then we'll be straight into the sprint next week. So I'm really struggling on the review side right now.
<rbasak> Maybe kirkland could help review and sponsor? I think he offered before and this one is nice and independent.
<rharper> rbasak: sure; do I just need to find a sponser then ?
<rbasak> I think so, yes.
<rharper> cool
<rharper> I'll poke around
<teward> maybe you would subscribe the ubuntu sponsors team?
<teward> (that way it gets on the list of stuff that needs poked?)
<rharper> teward: good idea
<LocutusOfBorg> mdeslaur, please merge libwmf with my debian upload, to ease libpng transition, thanks :)
<mdeslaur> LocutusOfBorg: sure
<LocutusOfBorg> thanks :)
<LocutusOfBorg> yofel, can you please update khtml with my latest debian upload?
<LocutusOfBorg> I fixed the libpng12-dev to libpng-dev :)
<LocutusOfBorg> xnox, can you please update gdk-pixbuf the same libpng fix in debian :)
<bdmurray> kenvandine: Could you have a look at https://code.launchpad.net/~vorlon/lxc-android-config/apport-job-cleanup/+merge/274497?
<Shock> hello
<Shock> I'm getting a warning that some packages cannot be authenticated (libgmpxx4ldbl libp11-kit-dev libidn11-dev libgmp-dev nettle-dev). is this normal?
<slangasek> Shock: this question would be more appropriate for #ubuntu.  For the record, it is not normal, and it is strongly recommended that you not install unauthenticated packages on your system.  It probably does not indicate an active attack, you may just need to re-run 'apt-get update'; but you can't be sure unless you actually get rid of the message
<kenvandine> bdmurray, i can have a look
<Shock> slangasek: I'm asking here because this is the second time it's happened and went the #ubuntu->#ubuntu-dev route once
<Shock> slangasek: last time the error was fixed by switching to the main server instead of mirror. now I'm using the main server and getting the error
<Shock> slangasek: there's not much help #ubuntu can provide if the main archive is at fault :(
<rww> re-run sudo apt-get update, try again, see if it still happens
<rww> and odds are the main archive is not at fault, hence the #ubuntu recommendation
<Shock> rww: already did that a couple of times
<rbasak> Shock: is it possible that your connection is behind a bad caching proxy, perhaps a transparent one? Some ISPs are known to do that.
<rbasak> I would check the sha256sums and sizes in the packages file (/var/lib/apt/lists) against the downloaded files (/var/cache/apt/archives/partial) manually.
<Shock> I'm getting the following warnings http://paste.ubuntu.com/14681447/
<sarnold> "unauthenticated" makes me think there's another configured archive; does apt-cache policy libgmpxx4ldbl   etc look sane?
<Shock> sarnold: apt-cache madison listed only the main archive, I'll check policy
<Shock> policy also lists only the main archive
<rbasak> That's odd. Looks like your verification public keys are broken.
<Shock> rbasak: how could that happen?
<ogra_> or someone on the way to the archive has a transparent proxy in the line
<rbasak> Shock: pastebin "apt-key list"
<Shock> http://paste.ubuntu.com/14681507/
<Shock> rbasak: done
<sarnold> gpg: keyblock resource `/etc/apt/trusted.gpg.d/zulcss-libvirt.gpg': resource limit   -- well that's odd..
<sarnold> and there's the keys that it reported missing a few minutes earlier.
<rbasak> It is odd. Looks like the keys are there but apt sees something different from apt-key.
<rbasak> Either that or you have a man in the middle. Unless you check the full key fingerprints you can't be sure.
<rbasak> (PGP key IDs are easy to duplicate)
<Shock> rbasak: how do I do that?
<rbasak> I'm not sure exactly, and I have to run now, sorry. You can certainly use gpg directly. There may be an easier way.
<Shock> rbasak: thanks!
<Shock> I've run apt-get update again, it's still showing signature verification errors. I'm not sure how to proceed further, any help would be welcome
<sarnold> check /var/lib/apt/lists/*InRelease  and see if those reflect the apt-get update you ran a few seconds ago; run gpg --verify  on those, that should include the full fingerprint of the keys that signed those files
<Shock> am I right in assuming that "W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/trusty-updates/InRelease" is because the signature couldn't be verified? I can open the url just fine in the browser
<sarnold> the fingerprints should match the first two here https://wiki.ubuntu.com/SecurityTeam/FAQ#GPG_Keys_used_by_Ubuntu
<rbasak> Shock: I think so, yes.
<Shock> gpg --verify says "gpg: Can't check signature: public key not found"
<cjwatson> gpg --verify will only work if you happen to have the right key in your *own* keyring
<cjwatson> try "apt-key adv --verify" instead
<cjwatson> (you can ignore any "gpg: WARNING: Using untrusted key!" warnings)
<cjwatson> http://paste.ubuntu.com/14681623/ <- good output
<cjwatson> in your position I would look more closely at /etc/apt/trusted.gpg.d/zulcss-libvirt.gpg
<cjwatson> is it a huge file or something?
<Shock> 362 bytes
<doko> bdmurray, could you review two changes for whoopsie? #1538705 and #1508653 ?
<Shock> cjwatson: all I'm seeing is "Good signature"
<Shock> cjwatson: I can remove the libvirt ppa, will that also remove the key?
<cjwatson> depends on the method you use ...
<cjwatson> you could try just moving that file aside though, and seeing what happens
<Shock> software-properties-gtk
<cjwatson> I think software-properties will remove the key, yes
<Shock> cjwatson: I've moved the file aside and re-ran apt-get update -- now the only gpg error I'm getting is for a ppa, presumably the ppa I've removed the key for
<cjwatson> right, so I guess remove the PPA properly with s-p, and then re-add it (which should refetch the key)?
<Shock> cjwatson: I don't need it anymore, I'm gonna build the packages manually. Should I re-add it in this case or just remove it?
<cjwatson> that's sounding like you want to remove it, but up to you
<Shock> cjwatson: thanks
<Shock> I've removed the ppa and now apt-get update finishes successfully without any errors
<Shock> thank you everyone for your help!
<Shock> is this a bug in apt-get or gpg?
<bdmurray> doko: I'll have a look.
<cjwatson> bug> pass, best way to tell would be to figure out how to reproduce it reliably; hope you kept a copy of that zulcss-libvirt.gpg key file, I should have mentioned that
<Shock> cjwatson: damn, I've just deleted it
<Shock> cjwatson: do you want me to re-add the ppa and see if it's reproducible?
<cjwatson> Shock: I'm just driving by here; perhaps that would be a useful thing to try, but I'm not a relevant package maintainer or anything here
<cjwatson> (I mean, I'm a developer, just not of either apt or gnupg)
<rbasak> Shock: it sounds to me that the zulcss-libvirt.gpg was truncated or corrupted somehow. I suspect it'll be really hard to pin down what happened there.
<teward> anyone know how frequently the autopkgtests pages update?
<teward> nevermind, i have different questions now
<wolsen> bdmurray, thx for the feedback on the patch for bug 1089013, I've updated the patch fwiw
<ubottu> bug 1089013 in lvm2 (Ubuntu Wily) "clvm startup script requires cman" [Medium,Triaged] https://launchpad.net/bugs/1089013
<smoser> anyone have an idea what would be triggering /usr/lib/update-notifier/update-motd-updates-available to run
<smoser> bug 1527710
<ubottu> bug 1527710 in update-notifier (Ubuntu) "apt-get update triggers asynchronous task" [Medium,Confirmed] https://launchpad.net/bugs/1527710
<smoser> i dont think its an apt-get udpate. but i think that thing is responsible for failures i was seeing in curtin installs and also for failures we're seeing in d-i server installs
<smoser> such as the one seen https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-server-amd64-smoke-default/28/console
<smoser> i believe d-i is refusing to unmount the target filesystem because something is running inside, and i belive update-motd to be that thing.
<chiluk> mterry do you want to do an upload for pad.lv/1535349
<tedg> How do I find out the same as "lsb_release --codename" for a package that is building, for which target it is building to?
<kenvandine> bdmurray, that branch looks good, but i need to test it on a device
<kenvandine> bdmurray, i'll make sure I do that tomorrow morning
<chiluk> mterry, arges, pitti would any of you be interested in sponsoring an upload for bug 1535349
<ubottu> bug 1535349 in coreutils (Ubuntu Trusty) "`df /dev/sda1` no longer reports information for /dev/sda1" [Medium,Confirmed] https://launchpad.net/bugs/1535349
<arges> chiluk: i can take a look
<chiluk> thanks arges.
<chiluk> or at least reviewing.
<lukesoft>  is there a way of know the language used in a package, before downloading the sources....i want to try out fixing a bug or 2 but only if its a java application...but i dont seem to see any other way to know its a java programm before downloading the sources
<TheMuso> lukesoft: You could check the package dependencies. That can probably give you a clue, particularly if its a java application.
<Shock> cjwatson & rbasak: I've re-added the ppa and now I'm getting the signature verification errors again
<lukesoft> TheMuso: thanks for the response, iam sorry that iam probably asking stupid questions as all this is still confusing.
<smoser> ok... so now i'm 99% certain that the apt-check thing is indeed caused by 'apt-get update' (
<smoser>  /etc/apt/apt.conf.d/99update-notifier:APT::Update::Post-Invoke-Success
<Shock> cjwatson & rbasak: and the gpg error is the same "gpg: keyblock resource `/etc/apt/trusted.gpg.d/zulcss-libvirt.gpg': resource limit"
<doko> so what am I doing wrong here? https://launchpad.net/ubuntu/+source/tbb/4.4~20151115-0ubuntu2  this builds locally ...
<bdmurray> smoser: Why did you change update-notifier the way you did when you mentioned 99update-notifier being the issue?
<infinity> doko: Looks like a missing build-dep on dh-exec to me.
<doko> infinity, oh, of course
<kirkland> smoser: did you get to the bottom of the update-motd / d-i / umount problem?
#ubuntu-devel 2016-01-28
<CarlFK> stgraber  cyphermox - tumbleweed says you might be able help with a Network Manager install issue: I don't want it to create "Wired Connection 1"  which seems to be created when the box first boots, not during the di
<pitti> Good morning
<damascene> Any Idea why Ubuntu still have the deb-src enabled by default in source.list? I've never used them in my 5+ years with Ubuntu
<damascene> sources.list
<damascene> commenting deb-src remove
<damascene> sorry, commenting deb-src saved Ubuntu servers 15 hit at least in my simple test.
<pitti> slangasek: FTR, julia/i386 is known broken, don't bother retrying
<pitti> slangasek: suitesparse is blocked by uninstallability, not tests
<Odd_Bloke> cjwatson: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/ppc64el/+merge/284229 is the other part of yesterday's change, if you get a minute. :)
<Odd_Bloke> cjwatson: (I've just pushed another unrelated minor fix to that branch as well, to save on the overhead of another MP etc.)
<cpaelzer_> I surely can come up with one, but I wanted to ask if there is a common way that should be used in d/rules to make decisions based on the arch?
<cpaelzer_> like if arch=ppc64el, ...
<cpaelzer_> CPU_TARGET=$(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
<cpaelzer_> ifeq ($(CPU_TARGET),ppc64el)
<cpaelzer_> is what I chose for my first try
<pitti> stgraber, hallyn: ooh, bash completion on image names with "lxc launch"! â¥
<hallyn> you and your unicode :)
<stgraber> pitti: haha, yeah, we've had the problem for a while but elmo reminded us that actually installing it would be a good idea :)
<pitti> hallyn: 2665 is one of the few numbers I actually remember âº  most fancy chars (like the smiley) have compose key combinations, but I don't know one for "heart"
<cjwatson> Odd_Bloke: thanks, uploaded
<cjwatson> cpaelzer_: you usually don't need to use _CPU etc., just compare against DEB_HOST_ARCH
<caribou> When one creates an initscript that accepts DAEMON_OPTS modifications, should these be done in /etc/default/{package} or directly in the initscript ?
<caribou> in other words : is it better to have the conffile in /etc/default ?
<cpaelzer_> cjwatson: ok thanks
<doko> Logan, I see you merged sphinxbase, but not pocketsphinx. now stuck in -proposed
<pitti> caribou: TBH it'd be best to configure such things in /etc/yourdaemon.conf, not in the init script
<pitti> caribou: the general pattern has been to put tweakable stuff into /etc/default/ -- init scripts should not ever be touched
<pitti> caribou: (by admins, I mean)
<pitti> caribou: but modifying command lines to change a service's configuration is a bit icky
<caribou> pitti: so what is the rationale in choosing /etc/yourdaemon.conf or /etc/default ? The debian doc seems to point toward /etc/default
<pitti> caribou: what I meant is, that you should start /usr/sbin/foo and *that* should read its configuratoin from /etc/foo.conf
<caribou> pitti: ah, ok get it
<pitti> caribou: it's conceptually wrong that each distro has to come up with its own schema of "how do I configure foo?"
<pitti> as that makes it impossible for upstreams to document this
<pitti> and it looks different everywhere
<caribou> true
<pitti> caribou: i. e. "how to configure a daemon" is not conceptually a distro question, it's an upstream questoin
<cjwatson> cpaelzer_: also, those variables are often exported to the environment although not always; so the best way to acquire them is usually "DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)"
<cjwatson> i.e. keep the name of your make variable in sync
<pitti> caribou: so if possible, please don't introduce new /etc/default files -- we should instead get rid of them in the long run..
<xnox> cjwatson, cpaelzer_: and i prefer to do: include /usr/share/dpkg/default.mk
<pitti> caribou: also, perhaps don't write new sysvinit scripts -- we stopped using sysvinit like 10 years ago
<xnox> and that gives me all DEB_*_* variables
<cjwatson> cpaelzer_: and definitely don't use terms like TARGET if you don't have to, because those have different associations in this context and you'll just get confused
<xnox> and a bunch of other useful stuff.
<cjwatson> xnox: right, or that
<caribou> pitti: thanks; it's not a new one, just adapting a failing one
<xnox> cpaelzer_, DEB_HOST_ARCH is by far the most common one to key on. and it's the short debian arch tag: i386, s390x, etc...
<pitti> caribou: working on merging rsyslog by any chance? :-) (just saw the latest responses on bug 1534106)
<ubottu> bug 1534106 in rsyslog (Ubuntu) "rsyslogd crashed with SIGSEGV with juju-local configuration" [High,Triaged] https://launchpad.net/bugs/1534106
<caribou> pitti: not at the moment, but looks like I will do another round at it if this solves that bug
<xnox> pitti, i also see that on s390x. Also discovered that debugging tools are a bit odd on s390x.
<caribou> pitti: my sysinit question was about LP: 1248054
<ubottu> Launchpad bug 1248054 in dlm (Ubuntu Wily) "[SRU] dlm package installation fails" [High,Triaged] https://launchpad.net/bugs/1248054
<pitti> xnox: the rsyslog crash with juju, you meaN?
<cpaelzer_> xnox: cjwatson: thanks for the further guidance
<xnox> pitti, yeap.
<caribou> the current script fails so wolsen has debianized the upstream script
<pitti> caribou: oh -- no new conffiles in SRUs please
<xnox> pitti, caribou: see other recently reported bugs on rsyslog.
<xnox> bug 1538723
<ubottu> bug 1538723 in rsyslog (Ubuntu) "rsyslog user process faults on s390x" [High,New] https://launchpad.net/bugs/1538723
<caribou> pitti: I'm fine with it
<LocutusOfBorg> jrwren_, can you please merge pngnq from debian?
<xnox> caribou, i have extra gdb dump there....
<pitti> caribou: ah, this is also for xenial, I see (cofusing bug title), sory
<LocutusOfBorg> or can I steal your merge?
<caribou> pitti: it will be SRUed so it still applies
<cpaelzer_> xnox: I already sourced and didn't realize it would fill these env yet, and by that I also get rid of the misleading cariable name cjwatson mentioned - great
<xnox> cpaelzer_, yeah, it does crazy caching and queries them on demand. but yeah, DEB_HOST_ARCH is available as a make variable if sourced. And you can export them, to make them environment variables if you need to.
<cjwatson> (which is rare)
<elijah> Was chatting with davmor2 in #ubuntu-app-devel and they mentioned that there is work being done between Ubuntu Touch and the Gnome devs to fix the network scan refresh for Network Manager. Does anyone know the issue links for those?
<elijah> Been searching for 10 minutes and can't find them
<davmor2> elijah: https://bugs.launchpad.net/ubuntu/+source/indicator-network and https://bugs.launchpad.net/ubuntu/+source/network-manager  it'll be among these
<davmor2> elijah: your best bet will be awe but he is in the US so won't be on for a bit
<elijah> davmor2: Thanks, maybe I will ping him later (ps. I am in the US too, on a train to NYC right now :D)
<elijah> davmor2: This is gold - https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1529294/comments/2
<ubottu> Launchpad bug 1529294 in network-manager (Ubuntu) "Merge network-manager 1.0.10-1 (main) from Debian unstable (main)" [Wishlist,Confirmed]
<elijah> Says NM 1.2 scans when a Wi-Fi network list is displayed - https://blogs.gnome.org/dcbw/2016/01/18/networkmanager-1-2-has-better-wi-fi-scanning/
<flexiondotorg> gnome-schedule is no longer in the Xenial archive - http://packages.ubuntu.com/wily/gnome-schedule
<flexiondotorg> Is there any way of finding why a package is no longer present?
<flexiondotorg> Also, how can I go about getting it re-instated?
<pitti> flexiondotorg: yes, on https://launchpad.net/ubuntu/+source/gnome-schedule/+publishinghistory
<pitti> Deleted on 2015-12-19 by Colin Watson
<pitti> (From Debian) ROM; unmaintained, dead upstream, RC buggy, depends on obsolete libs; Debian bug #808060
<ubottu> Debian bug 808060 in ftp.debian.org "RM: gnome-schedule -- ROM; unmaintained, dead upstream, RC buggy, depends on obsolete libs" [Normal,Open] http://bugs.debian.org/808060
<flexiondotorg> pitti, Thanks.
<cjwatson> and the best way to get something reinstated that's been removed from Debian is to get it back into Debian
<flexiondotorg> cjwatson, Yep.
<flexiondotorg> The problem with removing it from Debian is that the RC bugs alluded to the the removal bug report are now gone.
<LocutusOfBorg> doko, can I merge itk4?
<doko> LocutusOfBorg, sure
<LocutusOfBorg> thanks
<LocutusOfBorg> I tried to steal ghostscript, but I failed
<LocutusOfBorg> can you please help?
<doko> tkamppeter, ^^^
<flexiondotorg> cjwatson, Will new packages introduced to Debian unstable automatically sync to Ubuntu xenial archive?
<cyphermox> good morning!
<pitti> hey cyphermox, how are you?
<cyphermox> pitti: doing alright, you?
<pitti> cyphermox: quite fine too, thanks
<cjwatson> flexiondotorg: yes
<pitti> cyphermox: greetings from Belgium! (FOSDEM this weekend)
<cyphermox> oh, nice, lucky you
<cjwatson> flexiondotorg: well, up to Debian import freeze; and with some caveats, things that have previously been removed from Ubuntu (or some other conditions) require manual review
<cyphermox> pitti: I'm a little cold and in multipath hell ;)
<flexiondotorg> cjwatson, Thanks.
<pitti> cyphermox: multiple pathogens? :)
<flexiondotorg> gnome-schedule does have newer upstream versions.
<flexiondotorg> Will take a look.
<pitti> cyphermox: urgh, get better soon then!
<cyphermox> ah, not at all
<cyphermox> it's just generally cold here, weatherwise ;)
<pitti> oh, ok :)
<pitti> cyphermox: stay healthy then! :)
<cyphermox> well, you too. stay safe from the FOSFLU ;)
<LocutusOfBorg> cjwatson, doko can I steal log4cxx merge?
 * pitti believes LocutusOfBorg is the new Merge-O-Matic!
<tkamppeter> LocutusOfBorg, what do you mean with "I tried to steal ghostscript, but I failed"?
<LocutusOfBorg> tkamppeter, I would like to merge ghostscript, but the packaging diverged a little bit
<LocutusOfBorg> and I'm not sure I can handle it
<LocutusOfBorg> pitti, I would like to have packages ready for png1.6
<LocutusOfBorg> :)
<cjwatson> LocutusOfBorg: sure
<tkamppeter> LocutusOfBorg, I know and I already investigated. You can go ahead with merging, but give a kick to the security team to solve bug 711061 (and not that we have already mid or end January).
<ubottu> bug 711061 in openjpeg (Ubuntu) "[MIR] openjpeg" [High,Confirmed] https://launchpad.net/bugs/711061
<LocutusOfBorg> tkamppeter, I don't know how to merge it, I'm not sure everything will be correct
<tkamppeter> LocutusOfBorg, you can even sync that package, which is my intention to not need separate maintenance of Ghostscript in Ubuntu and Debian. Most of the rest of the printing stack is already synced.
<LocutusOfBorg> I can try however
<jrwren_> LocutusOfBorg: I think you misdirected that message. I don't know about pngnq
<jrwren_> LocutusOfBorg: if i have a merge, please steal i.
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/pngnq/1.0-2ubuntu2
<tkamppeter> LocutusOfBorg, what I plan to do is to simply sync it, as soon as the MIR for openjpeg gets solved.
<LocutusOfBorg> jrwren_, ^^^
<LocutusOfBorg> tkamppeter, wonderful then, I'll leave it to you
<tkamppeter> LocutusOfBorg, OK.
<LocutusOfBorg> jrwren_, I uploaded the delta in debian/deferred queue, will be syncd in 10 days
<hallyn> pitti: adt-build-lxc, is there a way to make it use the download or ubuntu-cloud templates?
<hallyn> or is there something else i should use which maybe makes it use lxd?
<hallyn> (or is this my fault for being on wily)
<pitti> hallyn: for LXD, use adt-build-lxd :)
<pitti> hallyn: wily> ah, I suppose I shold update the autopkgtest backports, then the wily backport will get teh new LXD backend and tools
<pitti> hallyn: adt-build-lxc only works with debootstrap (it's meant as a convenience wrapper around it)
<pitti> hallyn: locally I have entirely stopped using adt-virt-lxc, lxd is so much nicer
<hallyn> hm, so i can't use adt-build-lxd :(  maybe i should build it locally
<pitti> hallyn: just dowlnoad and install http://archive.ubuntu.com/ubuntu/pool/main/a/autopkgtest/autopkgtest_3.19.2_all.deb
<pitti> hallyn: I update the backports now
<hallyn> cool thanks :)
<pitti> hallyn: adt-build-lxd is more or less just "take a standard LXD image and run the setup script", which adds deb-src, eatmydata, and a few tweaks
<jrwren_> LocutusOfBorg: I have poor memory. this was over a year ago and I don't remember doing it. Sorry. Thank you for mergine
<LocutusOfBorg> thanks for allowing me to merge it :)
<pitti> hallyn: so with lxd you don't necessarily need to use adt-build-lxd at all, but if you use it often it's still more convenient/faster
<hallyn> oh, hm.  well i don't know if i'll be using it often - i probably should :)
<pitti> hallyn: see man adt-virt-lxd for some details
<hallyn> and then to run adt-run against it,
<hallyn> pitti: http://paste.ubuntu.com/14688283/  i'm messing up
<pitti> hallyn: you need to specify an image -- adt-run [...] --- lxd lco:ubuntu/xenial/amd64
 * pitti whispers "adt-virt-lxd(1)" again
<hallyn> adt-build-lxd built an image, but i dont' knwo what it was called
<hallyn> (lxc list doesn't show it)
<pitti> hallyn: lxc image list
<pitti> hallyn: ah, then presumably adt/ubuntu/xenial/amd64
<hallyn> hm, not showing up.  wtf
<pitti> or whichever release you built it from
<smoser> bdmurray, i modified update-notifier so that it doesn't background a task after you run 'apt-get update'
<smoser> as that task was what was keeping /dev busy and making the installer fail to unmount
<smoser> kirkland, ^
<hallyn> pitti: ok, i'll just lxc:ubuntu/xenial/amd64 i guess...  will adt-virt-lxd then cache what it built for me locally?
<hallyn> (would make sense for it not to, just asking)
<pitti> hallyn: it does, as it creates the image locally
<pitti> hallyn: did adt-build-lxc fail? do you still have the output in scrollback?
<hallyn> pitti: cool, thx
<pitti> (and what you called it with)
<hallyn> i dstopped the adt-biuld-lxc.  the adt-build-lxd did not fail i don't think, but i don't have scrollback.
<hallyn> hm, now i get "Test dependencies are unsatisfiable."
 * hallyn tries -U
<pitti> hallyn: maybe you need to call it with -U (--apt-upgrade) if the image is a bit outdated
<pitti> ... that
<hallyn> it should'nt be outdated - it just d/led it :)
<pitti> that's a matter of when it was built, not when you downloaded it, but indeed they shold get rebuilt every day
<hallyn> no, -U doesn't help
<pitti> or maybe your local package changes dependencies somehow
<pitti> hallyn: which package does it complain about?
<hallyn> it doesn't say.  do i say -v or -d ?
<pitti> hallyn: the log should say -- can you pastebin it?
<hallyn> re-running with -d
<pitti> apt's -o Debug::PkgProblemResolver
<pitti> hallyn: -d doesn't make apt any more verbose
<hallyn> pitti: http://paste.ubuntu.com/14688316/
<pitti>   Removing adt-satdep:amd64 because I can't find libpam-cgfs:amd64
<pitti> hallyn: ah! it's in -proposed only
<pitti> hallyn: so re-run with --apt-pocket=proposed -U
<hallyn> where is that dep coming from...
<pitti> hallyn: from your debian/tests/control Depends:
<pitti> hallyn: I suppose you tell it to run with the binaries from the archive instead of building the package locally and using those debs
<hallyn> i didn't add that
<hallyn> i want it to build locally
<hallyn> but also that isn't in debian/test/control - or does '@' expand to that
<pitti> hallyn: run it against the .dsc then, not the source.changes
<hallyn> why would the .changes not cause it to be built?  that seems weird
<pitti> that's a bit of a grey area right now -- Debian folks run against .changes with .debs, so they *don't* want to rebuild
<hallyn> huh
<pitti> and it currenlty just doesn't make enough checks on it to realize that there are no debs in it and you probably want a build
<hallyn> heh, ok
<pitti> hallyn: so, simply, you are the first person I'm aware of who tried to run against a source.changes :)
<hallyn> ok this seem sto be getting further
<pitti> (that's not currently documented/defined)
<pitti> .dsc should do what you mean
<hallyn> pitti: i actually pondered which to use, then the manpage showed using .changes so i used that
 * pitti makes a note to clarify that
<hallyn> meh, ran alo tlonger, but Khttp://paste.ubuntu.com/14688362/
<pitti> the log is cut off
<pitti> i. e. the apt error message isn't there
<pitti> pmerror:cgmanager:81.7308:subprocess installed post-installation script returned error exit status 1
<pitti> ah
<pitti> hallyn: does cgmanager work in a container?
<hallyn> no.  shouldn't really be needed for this...
<pitti> hallyn: you can try with
<pitti> lxd adt/ubuntu/xenial/amd64 -- --config raw.lxc=lxc.aa_profile=unconfined
<pitti> disabling apparmor might help
<pitti>  lxc launch adt/ubuntu/xenial/amd64 x1
<hallyn> pitti: actually it'll fail in lxd anyway bc i'tll want to run fuse.  i was being silly.
<pitti> $ lxc exec x1 -- apt-get install -y cgmanager
<pitti> that semes to work
<pitti> hallyn: so, qemu then?
<hallyn> i dunno, do i want to wait an hour for all that to get setup
<pitti> hallyn: it's primarily the time that it takes to download the > 300 MB cloud image indeed
 * hallyn starts it and goes to get a coffee
<kenvandine> pitti, i see you just landed a change to lxc-android-config to xenial, any reason that shouldn't land in the vivid overlay too?
<pitti> kenvandine: it's not necessary at all in vivid
<kenvandine> pitti, i was about to create a landing for slangasek's branch and would rather dual land
<hallyn> pitti: so after i do sudo adt-buildvm-ubuntu-cloud -a amd64 -r xenial , do i have to pass the full rootfs pathname to adt-run, or is there some short name i can provide?
<pitti> kenvandine: ah; well it doesn't *hurt* in vivid
<smoser> bdmurray, i put a very long winded explanation of my beliefs in bug 1527710 if you're interested.
<ubottu> bug 1527710 in update-notifier (Ubuntu) "apt-get update triggers asynchronous task" [Medium,Fix released] https://launchpad.net/bugs/1527710
<pitti> hallyn: no sudo please
<kenvandine> pitti, cool
<pitti> hallyn: you have to pass the complete path to the image
<hallyn> pitti: huh...  i don't think adt-run let me do it without
<kenvandine> there aren't separate vivid and xenial branches
<hallyn> ok
<pitti> kenvandine: ok; I just checked vivid and systemd-detect-virt --container --quiet works there
<kenvandine> great
<ogra_> pitti, eeek
<pitti> hallyn: no, pretty much only virt-chroot (nobody uses that)
<pitti> hallyn: nothing else needs root
<ogra_> pitti, i think you want to revert the lxc-android-config upload ... at least until we see any traces of systemd on phones
<pitti> ogra_: we have logind on the phone, so it's quite obviously installed (and I checked that)
<ogra_> does it also work without systemd as init ?
<pitti> yes, it doesn't care
<pitti> I tested with upstart and sysvinit
<pitti> it just does a couple of tests in /proc and /sys
<ogra_> ah, k, i thought it calls a specific init function
<ogra_> then ignore me ;)
 * pitti watches ogra's blood pressure go back to normal :)
<kenvandine> :)
<ogra_> lol, no high pressure here ... i only sound like it ;)
<kenvandine> pitti, once i get it built in the silo, mind testing it as well to be certain it works before i send it to QA?
<kenvandine> i'll test slangasek's fix
<kenvandine> ugh... not there's a conflict
<mdeslaur> xnox: are you working on virt-manager?
<kenvandine> slangasek, can you please refresh https://code.launchpad.net/~vorlon/lxc-android-config/apport-job-cleanup/+merge/274497
<kenvandine> slangasek, now there's a merge conflict...
<pitti> kenvandine: meh, it conflicts merely because the file that got removed anyway is now slightly different?
<kenvandine> i guess
<pitti> kenvandine: wait
<kenvandine> i didn't look closely
<pitti> kenvandine: I can just remove my pakcage from -proposed and uncommit, then you can retry to land
<pitti> seems easier
<kenvandine> ok...
<kenvandine> :)
<kenvandine> pitti, we can land your's togther
<pitti> kenvandine: after slangasek's there's nothing of mine left
<kenvandine> ah!
<kenvandine> :)
<hallyn> pitti: ung.   http://paste.ubuntu.com/14688473/
<pitti> kenvandine: done -- try again?
<kenvandine> ok
<kenvandine> thx
<pitti> hallyn: you didn't build that with adt-buildvm-ubuntu-cloud apparently?
<pitti> hallyn: adt qemu images need some preparation to get a "foot into the door", the qemu equivalent of lxc-attach
<pitti> hallyn: if that's just the stock xenial image, you can avoid re-downloading, though
<xnox> mdeslaur, well i must have the new one, to stop endless fiddling inside it when connecting to s390x libvirt.
<pitti> hallyn: although the name matches, so I wonder how you built that
<xnox> mdeslaur, i'm happy for others to update it =)
<xnox> mdeslaur, has it been in progress for you?
<kenvandine> pitti, one conflict left... Text conflict in debian/lxc-android-config.maintscript
<pitti> kenvandine: ok, I didn't touch that (now in fact there's no trace of my commit left)
<kenvandine> right
<pitti> kenvandine: oha, that MP is from october already
<kenvandine> yeah...
<kenvandine> pitti, i'll need to get slangasek to refresh it
<mdeslaur> xnox: I haven't looked at it yet. If I get time, I'll let you know, and if you start it before me, let me know.
<hallyn> pitti: ?   yes, i built that with adt-buildvm-ubuntu-cloud
<kenvandine> i guess nobody's really looking after lxc-android-config anymore
<hallyn> pitti: "adt-buildvm-ubuntu-cloud -a amd64 -r xenial"
<pitti> hallyn: hmm -- can you please append --show-boot?
<pitti> hallyn: that's an entirely new error now, I'm afraid
<hallyn> pitti: will do
<mdeslaur> xnox: any truth to the rumour that the "x" in s390x stands for xnox?
<ogra_> kenvandine, hmm, i thought morphis actually planned to bring it into bzr at least (note it waqs always source package only, there isnt a tree for it)
<pitti> hallyn: I suppose something went wrong during the image build (maybe setup-testbed errored out early before it got to installing that magic init.d script); I'll try here
<pitti> I ran it this morning successfully, but who knows
<morphis> ogra_: what exactly?
<kenvandine> ogra_, i had it so it was landable from bzr branches
<s390x> mdeslaur, no way
<ogra_> morphis, lxc-android-config
<mdeslaur> lol
<hallyn> pitti: http://paste.ubuntu.com/14688510/
<ogra_> kenvandine, it never was in any bzr branches afaik
<kenvandine> it wasn't...
<kenvandine> we fixed that :)
<ogra_> ah, k
<ogra_> so it is now ...
<kenvandine> yup
<ogra_> ignore me even more then :P
<kenvandine> haha
<Laney> who said that?
<dpm> sil2100, seb128, the new "Custom Ringtone" string for ubuntu-system-settings that came with ota9... seems to be only translatable on Xenial?
<dpm> Or am I looking at the wrong place in LP? I could only see it here: https://translations.launchpad.net/ubuntu/xenial/+sources/ubuntu-system-settings/+translations
<pitti> hallyn: WTH, reproduced with a current run of buildvm-u-c; I'll look
<pitti> this morning's was still okay, so whatever broke can't yet be that long ago
<pitti> ooh
<pitti> hallyn: yes, I know
<seb128> dpm, https://translations.launchpad.net/ubuntu-rtm/15.04/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/370/+translate
<dpm> aha! thanks
<seb128> yw
<seb128> is that the one you need?
<pitti> hallyn: this was a regression in init-system-helpers 1.26ubuntu1, which got fixed in https://launchpad.net/ubuntu/+source/init-system-helpers/1.26ubuntu2
<pitti> hallyn: but the current cloud image has ubuntu1 still, so it had that bug that update-rc.d enable failed
<pitti> hallyn: so tomorrow's cloud image should be good again
<dpm> seb128, yes, I was expecting it to appear under the list of "translatable distros", but I was looking at ubuntu, forgot about ubuntu-rtm for a sec
<seb128> dpm, ok, good that it's there ;-)
<pitti> hallyn: this isn't your testing day :/
<hallyn> pitti: heh, ok thanks :)
<dgadomski> pitti: hey, do you have any idea what may be holding back the release of fix to bug 1337873?
<ubottu> bug 1337873 in ifupdown (Debian) "ifupdown initialization problems caused by race condition" [Unknown,New] https://launchpad.net/bugs/1337873
<hallyn> pitti: but so can i do a adt-build that says update with what is in proposed?
<slangasek> pitti: yeah, I noticed your notes on julia after I had hit retry, sorry.  The issue again of the test results and the override message being so far from each other (I was looking at jquery, not suitesparse)
<slangasek> kenvandine: I probably won't get to refreshing that branch today
<kenvandine> slangasek, ok
<kenvandine> slangasek, please ping me when you do, i have a silo ready for it
<slangasek> ok
<kenvandine> slangasek, thx
<pitti> slangasek: no problem, just wanted to explain that it's going to fail again
<LocutusOfBorg> tkamppeter, thanks for opening debian bugs against ghostscripts :)
<Odd_Bloke> apw: We're seeing /boot/initrd.img end up as an LZMA-compressed empty regular file when building s390x images using live-build; do you think that might be related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536810?
<ubottu> Launchpad bug 1536810 in linux (Ubuntu) "kernel install failed /bin/cp: cannot stat â/boot/initrd.img-4.3.0-7-genericâ: No such file or directory" [High,Confirmed]
<ginggs> slangasek, pitti: julia needs a no-change rebuild for suitesparse, but it started FBTFS on armhf on the Ubuntu buildds and I don't know why
<bdmurray> didrocks: I recreated bug 1532355 just by upgrading from Wily to Xenial.
<ubottu> bug 1532355 in initramfs-tools (Ubuntu Xenial) "package linux-image-4.3.0-5-generic 4.3.0-5.16 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 2" [High,Triaged] https://launchpad.net/bugs/1532355
<didrocks> bdmurray: I did see that, I retried this morning and got a lot of other script failures, but not that one though :/
<didrocks> bdmurray: that was an up to date ubuntu wily desktop
<didrocks> bdmurray: I guess it depends on the package order, and the other failures shadowed it, I think the other should be fixed first so that we can reproduce that one more rigorously
<Odd_Bloke> apw: Huh, we're also seeing that in our arm64 images, so there's definitely a problem somewhere; I'm going to file a separate bug and we can dupe it if necessary.
<pitti> hallyn: doesn't --apt-pocket=proposed do that for builds?
<hallyn> pitti: but that needs your cloud init updated package in order to be able to do the update to -proposed right? :)
<pitti> hallyn: err, yes; that, or you use yesterday's cloud image
<apw> Odd_Bloke, nope that doesn't sounds like i'd expect that particular bug to relate
<apw> Odd_Bloke, i'd expect that to mean you have no /boot/initrd.img or it be a link to the wrong place, not be emtpy anything
<apw> Odd_Bloke, let me know the number pls
<Odd_Bloke> apw: OK, thanks; will do.
<LocutusOfBorg> cjwatson, now that we have virtual architectures, why can't we have ppas with them too?
<LocutusOfBorg> BTW about the arm64 virtual issues, I found some other packages having troubles, llvm-toolchain-3.7, insighttoolkit4 just today, I retried, and not sure if by chance, they went in a real machine and successful
<cjwatson> LocutusOfBorg: you can, with ppc64el
<cjwatson> LocutusOfBorg: but the others aren't reliable enough yet
<LocutusOfBorg> ok, thanks!
<LocutusOfBorg> I probably won't ask to enable ppc64el ATM
<cjwatson> LocutusOfBorg: as soon as they're reliable enough, we'll add them for self-service enablement in PPAs, like ppc64el already is
<cjwatson> LocutusOfBorg: (http://blog.launchpad.net/ppa/ppas-for-ppc64el)
<LocutusOfBorg> :D wonderful! I was wondering about arm64 as example
<cjwatson> LocutusOfBorg: right, the thing with arm64 is, the builders stay up provided they aren't being used much ;-)
<cjwatson> LocutusOfBorg: the failure rate on reset is ridiculous
<Odd_Bloke> apw: I've filed https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1539157; it's against live-build for now, because I didn't really know which package to point the finger at. :p
<ubottu> Launchpad bug 1539157 in live-build (Ubuntu) "Images built with "link_in_boot = yes" in /etc/kernel-img.conf end up with a broken /boot/initrd.img" [Undecided,New]
<cjwatson> LocutusOfBorg: or at least was - it seems to have improved recently but it's currently hard to tell whether that's just chance
<cjwatson> LocutusOfBorg: and yeah, bumping memory to 8GiB is something we'll need to look at for arm64 virt builders
<Odd_Bloke> xnox: (See above filed bug for the issue we're seeing)
<rharper> if I need to have a build dep for ppc64el only, does foo [powerpc] cover that? or is powerpc different DEB_HOST_ARCH than ppc64el ?   is there a more general power arch string that ppc64el would match to ?
<rbasak> They're separate architectures, and no general term. At packaging level, anyway.
<apw> rharper, debian ppc64el and powerpc are separate
<rharper> apw: ok, thanks
<rharper> rbasak: ok, thanks
<nacc> rharper: BE vs. LE
<nacc> v.v. rather
<rharper> nacc: yep
<kirkland> smoser: ah, interesting, good to know
<caribou> Does someone have an idea what could cause "insserv: Service mountdevsubfs has to be enabled to start service lvm2"
<caribou> in autopkgtests ? I see that in many Regressions flagged (including lvm2 that I uploaded earlier today)
<caribou> I only see that for other services (cgmanager)
<doko> barry, do you know how to look for libpeas dependencies?
<pitti> caribou: could be some more fallout of the upgrade-rc.d failure (fixed in init-system-helpers this morning)
<pitti> caribou: although mountdevsubfs.sh is just a no-op shim for init.d dependencies, so not really sure that's related
<caribou> pitti: ah, wasn't aware of this one.
<caribou> pitti: the only thing that changed in lvm2 is a script in clvm which is not touched by anyone; I doubt it comes from that
<pitti> caribou: right, that sounds harmless; I guess the change that cuased that landed earlier, and it just surfaced now that lvm2 got built again
<pitti> caribou: I won't get to it today or tomorrow (hackfest), next week there's a sprint, but I hope I can squeeze it in on Monday
<pitti> caribou: unless you want to investigate yourself of course
<pitti> caribou: if not, can you please file a bug with some pointers and assign to me?
<caribou> pitti: I spent a good portion of my day looking for that
<pitti> lrwxrwxrwx 1 root root   26 Nov 20  2014 /etc/rcS.d/S04mountdevsubfs.sh -> ../init.d/mountdevsubfs.sh
<pitti> ooh
<pitti> caribou: right, there *should* be an enablement symlink for that
<pitti> caribou: so, the broken update-rc.d explains that after all
<pitti> caribou: just retry them
<caribou> pitti: just did with the magic button :)
<pitti> caribou: if it still fails, then I guess I'll need to rebuild the base xenial images
<pitti> caribou: yay!
<pitti> caribou: ok, retry won't help I'm afraid
<pitti> caribou: ganeti is broken differently, but overridden
<pitti> caribou: so it's those arm/s390 failures for libvirt and cinder
<caribou> pitti: yes
<pitti> I guess I need to rebuild the containers for that
<caribou> pitti: I've tried to run cinder & libvirt autopkgtests locally; been running for hours
<pitti> oh, wow -- cinder sohld be quick
<caribou> not sure that running them in schroots will work though,
<caribou> pitti: I was dumb enough to run a build; unit tests take forever
<pitti> ah :)
<caribou> pitti: libvirt runs faster and seems ok
<pitti> caribou: so, started container rebuilds, I'll then retry the bits
<caribou> pitti: thanks!
<smoser> just looking for some help... anyone else use pentadactyl ? firefox 44 seems to have killed it for me, i assume there is some way to make it go again, but...
<smoser> pitti, wrt https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1539016
<ubottu> Launchpad bug 1539016 in init-system-helpers (Ubuntu) "Remove /bin/running-in-container" [Low,In progress]
<smoser> i recently had to convince grub not to run grub-probe when installing a kernel via chroot.
<smoser> i did so by making running-in-container a link to /bin/true
<xnox> smoser, systemd-virt-detect should be used instead, no?
<xnox> sorry systemd-detect-virt
<pitti> smoser: ah, you are saying we should fix grub to skip those bits in chroots too, not only containers?
<pitti> xnox: yeah, see bug 1539016
<ubottu> bug 1539016 in init-system-helpers (Ubuntu) "Remove /bin/running-in-container" [Low,In progress] https://launchpad.net/bugs/1539016
<cjwatson> it's much more ambiguous for chroots
<smoser> hm..i guess i can do both. running-in-container actually works all the way back to precise.
<cjwatson> recovery via chroot is a common use case
<xnox> smoser, systemd-detect-virt -r and check exit code.
 * pitti will read scrollback tomorrow, I need some food now -- been sitting here for too long, sorry
<barry> doko: the trick is libpeas deps that actually have python in them.  bryan quigley did an initial search: https://bugs.launchpad.net/debian/+source/libpeas/+bug/1440504/comments/6
<ubottu> Launchpad bug 1440504 in libpeas (Ubuntu) "libpeas-1.0-0 depends on both libpython2.7 and libpython3.4" [Medium,In progress]
<barry> doko: then i tried to look at deps to see if they were py2 or py3: https://bugs.launchpad.net/debian/+source/libpeas/+bug/1440504/comments/9
<dobey> barry: oh fun, i guess you need to split the plug-ins into separate packages
<barry> doko: it's possible we missed some, but that should be a good start
<barry> dobey: yes, exactly
<barry> and then update deps
<dobey> barry: well, i'd just shove the py2 loader into a separate package, and leave the py3 one in the main package, and then only tweak the deps that require the py2 one still; to make life easier
<barry> dobey: that could work too
<barry> not a bad idea
<dobey> much less work for you that way :)
<doko> yes, that looks good.
<doko> dobey, barry: do you know offhand if it's ok to move the loader into a multiarch subdir?
<dobey> doko: that might be problematic, but i haven't looked deep enough into it to be sure; i know there are plenty of plug-in using things that make multi-arch hard to do for them, though
<barry> doko: i don't know
<cjwatson> pitti: could we get a retry request button for "always failed" tests as well?
<doko> ohh, and a retry all button
<doko> I mean, all archs
<pitti> cjwatson: technically yes; practically I'm afraid of people hammering those without any chance of success
<cjwatson> fair
<ancaemanuel> cjwatson: why nobody care about apt ? https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923
<ubottu> Launchpad bug 1531923 in lz4 (Ubuntu) "[MIR] lz4" [Undecided,Confirmed]
<pitti> doko: you can run "run-autopkgtest" and thus use retry-autopkgtest-regressions :)
<ancaemanuel> pitti, can you merge lz4 ?
<ancaemanuel> from debian ?
<cjwatson> ancaemanuel: Please stop harassing me.  I assume Seth is busy at the moment; I'm very wary about rushing security review.
<doko> caribou, sil2100, Laney: who is driving unity-settings-daemon and libunity-webapps these days?
<sil2100> doko: hey! libunity-webapps I suppose it would be something for dbarth or someone from his team
<sil2100> doko: not sure about unity-settings-daemon, but answering the earlier question: it's a CI Train managed package
<ancaemanuel> cjwatson: oh, I do not want to harassing you.
<ancaemanuel> I waited several days
<ancaemanuel> more than a week
<cjwatson> ancaemanuel: but it's not my problem so I've no idea why you're even asking me.  I just answered you once on IRC
<cjwatson> MIR review is not a thing I do; MIR review is not a thing I even have permission to do
<cjwatson> so asking me is pointless
<ancaemanuel> ok, thank you for looking.
<smoser> interestingly, in probably the most likely scenario of a chroot, 'systemd-detect-virt --chroot' exits 1 (not running in a chroot).
<smoser> it only works if /proc is mounted. but in many, many chroot cases, that is not going to be so.
<ancaemanuel> cjwatson: any ideea to what person to ping ?
<sarnold> ancaemanuel: there's multiple packages in line before lz4. sorry.
<mdeslaur> xnox: I'm doing virt-manager now
<xnox> mdeslaur, \o/
<mdeslaur> xnox: I found a 3/4 done 1.3.1 package in my scratch directory...apparently something shinier came up and I had forgotten about it :P
 * xnox rapidly turns all the lights off, and hides all the blikies
 * xnox rapidly turns all the lights off, and hides all the blinkies
 * mdeslaur gets distracted by lights suddenly going out
<pitti> caribou: looking much better
<NikTh> UPod ? https://twitter.com/ubuntu/status/692739548107927553 :-)
<jtaylor> are there plans on updating docker for xenial? I think we might be better of removing it than shipping 1.6 and confusing users
<jtaylor> I expect in a year or two even 1.8 will be unusable because all tooling is updated to the new networking stuff in 1.9
<sarnold> even if it gets updated to $latest_in_march it'll probably look pretty comical in 2021.
<sarnold> I get the impression their idea of "backwards compatability" is measured in weeks, not years :)
<jtaylor> actually its decently backward compatible, the issue are all the tools around it
<jtaylor> they tend to use the latest stuff and remove old stuff quickly
<jtaylor> e.g. compose won't even start unless the version matches the latest one, for no really good reason
<jtaylor> (but at least there are hidden env variables to get it to work regardless)
<xnox> mpt, i shall go down in history as freedom hater
<smoser> how can i tell 'rrecommends'
<smoser> the analog of apt-cache rdepends
<smoser> cyphermox, wonder if you might know this.
<smoser> a wily server install ended up with ubuntu-standard metapackage installed. but same preseed for xenial does not have that meta-package installed.
<cjwatson> apt-cache rdepends shows both Depends and Recommends.  grep-aptavail/grep-dctrl is a good Swiss army knife for more detailed exploration.
<smoser> yeah, i saw that.
<smoser> thank you cjwatson.
<cyphermox> smoser: cjwatson is quicker to respond. I blame the alphabet :)
<smoser> me too. but he d idn't answer my second queestion
<smoser> so you can still try
<smoser> although unlikely you'll be able to beat cjwatson
<cyphermox> ahah
<smoser> :)
<cyphermox> did we not discuss that last week?
<smoser> i dotn know. maybe we did.
<cyphermox> oh wait, no. I remember the change was in quantal
<smoser> so... https://platform-qa-jenkins.ubuntu.com/view/smoke-default/ .
<cyphermox> I suspect it's a matter of picking minimal or not when installing, if you're installing utah
<smoser> smoke-default for xenial is insisting that 'irqbalance' is installed. and failing because it is not in xenial.
<cyphermox> right, that's what we'd been discussing last week
<cyphermox> or maybe you weren't around then
<smoser> using the same preseed in both cases
<smoser> so some behavior changed by design in d-i that would select minimal rather than standard ?
<cyphermox> also, irqbalance seems to be in xenial?
<smoser> (i also notice int he installed package lists, ubuntu-standard is not present in xenial, but is in wily)
<smoser> and it is the only thing i see in 'rdepends' of irqbalance... ie, the only reason that package would be in there
<cyphermox> yes
<cyphermox> http://paste.ubuntu.com/14691070/
<smoser> above "failing because it is not in xenial" meant failing because it is not installed by the preseeded install.
<cyphermox> ^ looks like ubuntu-standard is installed here, this wasn't a preseeded install though
<cyphermox> ok
<cyphermox> smoser: could you show me the preseed?
<smoser> http://bazaar.launchpad.net/~ubuntu-server-dev/ubuntu-test-cases/server-tests-raring/view/head:/preseeds/default.preseed
<smoser> same preseed, same utah. run with wily, ubuntu-standard gets isntalled (and thus irqbalance). but run with xenial, there is no ubuntu-standard installed.
<smoser> xenial: http://paste.ubuntu.com/14691083/
<smoser> wily: http://paste.ubuntu.com/14691086/
<cyphermox> oh, interesting
<cyphermox> I might have broken tasksel after all
<cyphermox> or not
<cyphermox> smoser: I think the behavior changed: https://launchpad.net/ubuntu/+source/tasksel/3.34ubuntu3
<cyphermox> smoser: try just 'server' rather than 'Basic Ubuntu Server'
<smoser> well, fiddle though./
<smoser> i'll have to have wily specific preseeds then ?
<smoser> s/wily/xenial/
<cyphermox> it's going to be like this from now on
<cyphermox> it makes more sense to have the task name rahter than its short description anyway
<smoser> it does, yes.
<smoser> nuclearbob, ok. so that would seem to likely be it.
<nuclearbob> smoser: okay
<smoser> but we'll then need to generate those preseeds at utah-runtime from their templates based on input release.
<nuclearbob> do we need to do that, or can we have different preseeds/jobs based on release?
<nuclearbob> we have some scripts that select which preseed to use
<nuclearbob> if we pass those options, we can have the scripts generate or select a preseed based on release
<smoser> you're rigth. i guess we do not have to generate entirely.
<smoser> cyphermox, i dont think this change worked.
<smoser> -tasksel tasksel/first multiselect Basic Ubuntu server
<smoser> +tasksel tasksel/first multiselect server
<cyphermox> I can try in a bit.. just trying to get my parted SRU finished
<smoser> is it perhaps the 'Task-Key' ?
<smoser> which woudl be quite unfortunate. as ait is 'screen' for ubuntu.xenial/server task.
<smoser> i'm testing that now.
<doko> jtaylor, https://launchpad.net/ubuntu/+source/python-scientific/2.9.4-3build2 ?
<jtaylor> doko: oldnumeric is gone from numpy since a while
<jtaylor> 1.9 I think
<jtaylor> if we are lucky that is just a renamespacing
<smoser> cyphermox, i dont htink its the tasksel thing.
<smoser> that preseed did in fact have 'Basic Ubuntu Server'
<smoser>  tasksel tasksel/first multiselect Basic Ubuntu server
<smoser> but changing that to 'server' didnt help.  and even with it as it was, grep shows
#ubuntu-devel 2016-01-29
<smoser> http://paste.ubuntu.com/14691689/
<smoser> but wily shows:
<smoser> http://paste.ubuntu.com/14691702/
<smoser> the key difference there is that its the 'standard^' seed that is getting irqbalance, not the tasksel 'Basic Ubuntu Server' or 'server'
<smoser> nuclearbob, ^
<smoser> i've not been successful getting it to dtrt
<smoser> and i have to go
<doko> pitti, the visp autopkg test are run against the release version of libzbar-dev and therefore fail. that doesn't sound correct
<nuclearbob> smoser: dang
<roaksoax-brb> pitti: howdy! I have a quick question. I have a debian/rules file with dh-systemd, where I'm passing: dh_systemd_enable, dh_installinit --no-start, dh_systemd_start --no-start , however, I see this in debian/rules: http://pastebin.ubuntu.com/14691933/, which is starting the service... is there a bug that you know of or am I doing something wrong?
<roaksoax-brb> I see the pb in the .postinst*
<smoser> cyphermox, i've filed bug 1539329
<ubottu> bug 1539329 in Ubuntu "server install does not have 'standard' task installed" [Undecided,New] https://launchpad.net/bugs/1539329
<smoser> I'd appreciate your time to at least triage it to the right package
<teward> who's the apport hooks expert?
<teward> i keep forgetting who it is, but I could use some help debugging things
<smoser> i'm sure that pitti knows some things about it, teward but i'm not sure if he's who you've worked with before.
<sarnold> he's probably also a few more hours before he returns..
<teward> i'll be asleep by then, it'll be a case where I'll have to intercept pitti then, because apport errored out on one Xenial bug
<teward> and I mean errored out at the generic apport hooks
<teward> didn't even get to nginx's hooks heh
<teward> i think it was pitti who helped previously, too
<teward> i'll just show up tomorrow morning and see if pitti's around, and see if they can help debug the issue i'm seeing in Xenial where it's not triggering the apport hooks in the package.
<teward> thanks
<pitti> doko: visp> for which package? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#zbar is meant to run against the released visp, for isolating -proposed packages against each other
<pitti> doko: and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#visp ran against the proposed version
<pitti> doko: I can run zbar against the -proposed visp if that helps
<pitti> roaksoax-brb: can you show me debian/rules for that? --no-start should indeed not do that
<pitti> roaksoax-brb: I have a hunch what's wrong (we had a similar error in libvirt)
<pitti> teward: it's more useful if you just directly ask what's wrong, avoids another day of roundtrip :)
<pitti> teward: what's the particular error that you see?
<doko> pitti, no, still run against 0.10+doc-10build2
<pitti> Get:335 http://ftpmaster.internal/ubuntu xenial-proposed/universe amd64 libvisp-ar3.0 amd64 3.0.0-2build1 [29.7 kB]
<doko> this visp pkgconfig file is crazy, recording the absolute library name
<pitti> doko: in e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/v/visp/20160128_220555@/log.gz I see the -proposed version both for the source and the binaries ??
<pitti> oh, you do mean against zbar
<pitti> yes, it's mean to run against the released visp
<pitti> or -proposed visp against released zbar
<pitti> (as there are no dependencies which would force it otherwise
<doko> but for the test to succeed it must run against the one in -proposed: https://launchpad.net/ubuntu/+source/zbar/0.10+doc-10ubuntu1
<pitti> if they need to go in together, I can run them with both packages from -proposed
<pitti> doko: ok, I started that
<pitti> this is a case of "dependencies are not strict enough" (but meh)
<doko> ta
<doko> well, would a break in zbar help?
<pitti> yes, that will do too
<pitti> doko: not that we care much about partial upgrades, it just causes hitches like that with testing -proposde bits in isolation
<pitti> doko: so I guess let's not worry too much for now -- this test run should succeed, and then all is good
<doko> ok
 * pitti toddles off to Brussels to the systemd hackfest, bbl
<doko> me too
<doko> just to Brussels
<dholbach> good morning
<seb128> doko, hey, do you plan to mp your multiarch changes to the proper vcs?
<doko> seb128, have a wonderful morning. did you really check before starting with general complaints?
<seb128> doko, shrug, it seems you pushed your update to the vcs but without using the vcs, e.g there was unreleased changes and you didn't include them in the release...
<seb128> speaking about nautilus
<doko> and for others I had to check in your very own non-checked in changes
<doko> and please address your dep-waits for main
<seb128> is there a page listing those?
<seb128> dep-wait doesn't trigger any email afaik
<doko> http://qa.ubuntuwire.com/ftbfs/ isn't that new
<seb128> that's not only depwait
<seb128> and there is no filter for "your own packages"
<mpt> xnox, since you fixed the bug, I assume âI disagreeâ meant âI agreeâ. If so, yay. \o/
<caribou> pitti: thanks! any reason why the ganeti tests are all failing ?
<pitti> caribou: they are overridden; I don't remember what's broken with them, but not related to lvm
<caribou> pitti: thought so, just wanted to confirm
<pitti> caribou: oh, it migrated, good
<caribou> pitti: next time I won't wait so long before asking
<infinity> Laney: Is it possible that https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1521302 is gnome-terminal's fault, not unity?
<ubottu> Launchpad bug 1521302 in unity (Ubuntu) "gnome-terminal maximize than un-maximize behaves odd" [Medium,Confirmed]
<LocutusOfBorg> hi folks, can anybody pretty please
<LocutusOfBorg> "syncpackage libnatpmp --force"
<LocutusOfBorg> it is in main
<LocutusOfBorg> mapreri, ^^^
<jemadux> in ubuntu devel , nautilus has both buttons on global bar and his own window ?
<infinity> LocutusOfBorg: Will do.
<LocutusOfBorg> <3 infinity
<LocutusOfBorg> please give also mapreri the -s switch
<LocutusOfBorg> he asked me to do it
<infinity> LocutusOfBorg: Oh.  Too late.
<LocutusOfBorg> no problem :)
<LocutusOfBorg> Laney, I'm gonna sync herwig++ soon I think
<LocutusOfBorg> same for gjay
<LocutusOfBorg> mapreri, for marble I already did the change in ubuntu a few days ago
<LocutusOfBorg> everything is syncd, thanks for merging the ubuntu work in debian
<Saviq> popey, hey, so I've been trying to restart http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mir but it says I can't upload, so I can't "use this service", what badges would I need to earn to be able to use this?
<Saviq> OTOH this looks like a real fail :/
<popey> I have no idea.
<popey> dholbach, ^ any idea?
<popey> looks like a motu thing
<LocutusOfBorg> You submitted an invalid request: You are not allowed to upload qtmir or mir to Ubuntu, thus you are not allowed to use this service.
<LocutusOfBorg> nope, I'm MOTU and I couldn't do it
<LocutusOfBorg> core-dev can I think
<Saviq> sounds like it
<LocutusOfBorg> mir is in main, I guess only core-devs can retry builds
<Saviq> popey, on another note, those regressions are there for a version of qtmir previous to what just got uploaded to proposed from the same silo along with the mir that triggered them...
 * Saviq not sure where the chicken'n'egg thing broke
<LocutusOfBorg> so you need somebody that retries the testsuite against the proposed version?
<Saviq> yeah, well, I'd have expected that to happen automagically
<LocutusOfBorg> nope, but did I already bothered infinity today? ^^^ :)
<infinity> LocutusOfBorg: Literally anyone with upload rights for the package.
<infinity> Saviq: ^
<LocutusOfBorg> :D
<Saviq> right, but what does that actually mean :)
<infinity> It means exactly what I typed?
<infinity> People who can upload the package to Ubuntu.
<infinity> Note that "using a silo as a backdoor" doesn't count.
<Saviq> ok, so not me, will have to work on that
<Saviq> infinity, can I ask for the qtmir{,-gles} regressions triggered by mir be restarted for the qtmir{,-gles} versions that are there in proposed, please?
<infinity> Anyhow, retried them all for you.
<Saviq> oh thanks
<infinity> Oh.  You want them as a set?  That's more complicated.
<infinity> britney intentionally doesn't do that by default.
<infinity> Saviq: Do you have appropriate Breaks in place to note that the new mir doesn't work with old qtmir?
<Saviq> infinity, no, only Build-Depends
<Saviq> infinity, and well, for binaries, whatever dpkg finds
<infinity> Saviq: So, binary upgrades *could* be partial, and britney's test is entirely valid by saying "you let me install these two together, and they don't work".
<infinity> Although, that failure doesn't look binary related at all, it's source..
<Saviq> infinity, I think this behaviour change and our dummy "does qtmir build still" autopkgtest makes no sense now
<Saviq> it's very likely we're doing something wrong there
<infinity> Saviq: A "does it build" autopkgtest never makes sense, really, unless you're testing a toolchain, or that's literally the only way you can run a testsuite.
<infinity> Saviq: Given that you just built it, you're testing that it still builds a few hours later.
<Saviq> infinity, well, the point was that if a dependency of qtmir is going into proposed, we'd know if it broke its build
<infinity> Saviq: However, this also highlights that your build-deps are probably wrong.
<infinity> Saviq: If they need to be versioned and aren't, we can't read your mind.
<Saviq> infinity, well, yeah, they are versioned, but with >=, not ==
<infinity> Saviq: Oh, indeed.  It's the old source failing.  Derp.
<infinity> Saviq: Sorry, brain not entirely on.
<Saviq> yeah I was thinking you shouldn't be here yet
<infinity> Saviq: Anyhow, autopkgtest is meant to be a test of binaries, not source.  We do rebuild tests and the like for source regressions.
 * popey tucks infinity back into bed
<infinity> Saviq: Obviously, we do source tests for compilers and such, cause how else do you test a compiler, but if every package in the archive tested rebuilding itself anytime a dep was uploaded, we'd be setting a lot more computers on fire.
<Saviq> infinity, agreed, we'll be dropping that test from there soon, then
<Saviq> infinity, so here's a related question - for unity8's autopkgtest we need some mocks that have no use anywhere else, we've been building those (and the test binaries themselves) during autopkgtest, should we package all those up instead after all?
<Saviq> that felt like a waste of archive to some extent
<infinity> Saviq: Nothing wrong with packaging them up in mir-tests or something and making your tests pull them in.
<Saviq> infinity, ack, thanks
<infinity> Or unity8-tests or whatever.  I can't read. ;)
<cjwatson> pitti: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/h/haskell-hoogle/20160129_083554@/log.gz - not the friendliest response to this from haddock, but is HOME meant to be entirely unset here?
<cjwatson> pitti: (I think this has started failing in Debian too, not obviously related to any change in the packages under test that I can see)
<jamespage> pitti, hey - just hit a problem with lvm2 upgrades: https://launchpad.net/bugs/1539546
<ubottu> Launchpad bug 1539546 in lvm2 (Ubuntu) "Service mountdevsubfs has to be enabled to start service lvm2" [Undecided,New]
<jamespage> pitti, the systemd package is masking that job - when the lvm2 maintainer script tries to update-rc.d, it throws that problem
<jamespage> any ideas? correct that its masked? do we need to tweak lvm2 to not require that to be enabled....
<infinity> cjwatson: I think a postinst wanting HOME is a bit sketchy.  But I guess if it's readonly to pick up a user prefs file or something, the fault lies in not catching it.
<infinity> cjwatson: Unless POSIX says HOME must always be set, but I'm betting it doesn't.
<pitti> jamespage: hey
<pitti> jamespage: this looks like fallout from the update-rc.d breakage
<pitti> jamespage: it should have been fixed by yesterday morning's init-system-helpers
<pitti> cjwatson: tests set $HOME, but this is the apt-get install
<pitti> cjwatson: what would $HOME be there, /root?
<infinity> pitti: Usually, yeah.
<pitti> cjwatson: first time someone reported that; if that's legitimate (I think it's not), I can set it to /tmp or /root or so
<ricotz> rharper, hi, fyi, libnl3 3.2.21-1ubuntu1 breaks network-manager causing it to crash
<infinity> But I don't think apt or dpkg should rely on being run in a login session, which implies postinsts shouldn't, which implies that anything run in a postinst shouldn't.
<pitti> jamespage: the masking is correct, it was just insserv not seeing the /etc/rcS.d/S04mountdevsubfs.sh symlink
<teward> pitti: are there any Xenial bugs against the general Ubuntu apport hooks at all?  Seeing a HookError failure on one of the bugs that landed on my radar, not sure whether it completely errored and that's why it didn't execute the package specific hooks, or whether something else is going on...
<cjwatson> infinity,pitti: Yeah, possibly I should look at working around this in ghc-doc or something
<infinity> cjwatson: Or haddock itself.  If it's trying to read a user prefs file (I'm assuming?), it must already have a test for if it exists, it probably just needs to wrap that in a test for HOME being set.
<cjwatson> infinity: Yeah but I was hoping not to have to change the actual Haskell code :P
<infinity>   -- getAppUserDataDirectory can fail (e.g. if $HOME isn't set)
<infinity>   e_appdir <- tryIO $ getAppUserDataDirectory "ghc"
<infinity> Looks like this is worked around in some places, but not all?
<infinity> Or just worked around poorly.
<Celphish> Elo! Just popped in to say that I'm really happy with how Ubuntu works on my work-laptop atm and I'm really impressed that it can handle everything I can throw at it without too much Hassle :)
<Saviq> didrocks, hey, can you please add lukas-kde to ~ci-train-users? also, is it on purpose you still own that team?
<roaksoax-brb> pitti: http://pastebin.com/iwr9xsNi
<pitti> roaksoax-brb: yes, what I thought; in an override of dh_foo you must not call any dh_* commands other than dh_foo
<pitti> roaksoax-brb: so your override_dh_install currently calls dh_systemd_start, and then the default debhelper dh_systemd_start runs without arguments
<pitti> roaksoax-brb: so, move the dh_systemd* out of override_dh_install into override_dh_{enable,start}
<roaksoax-brb> pitti: what about the requirement where dh_systemd_enable needs to go before dh_instaliinit, and override_dh_start after it ?
<roaksoax-brb> pitti: or is that no longer the case, as in, i no longer need dh_installinit
<cjwatson> Surely that's already handled by the default sequencing
<cjwatson> insert_before("dh_installinit", "dh_systemd_enable");
<cjwatson> insert_after("dh_installinit", "dh_systemd_start");
<cjwatson> in /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm
<roaksoax-brb> cjwatson: ah nice! ok cool! thanks!
<roaksoax-brb> pitti: thank you!
<pitti> roaksoax-brb: yw! it's a bit of a subtle trap indeed, two weeks ago I debugged that with hallyn on libvirt (and then it took considerably longer :) )
<roaksoax-brb> hehe :)
<caribou> is there someone from the backport team who could  help me with LP: #1494141
<ubottu> Launchpad bug 1494141 in trusty-backports "HAProxy 1.5 init script does not terminate processes" [Medium,In progress] https://launchpad.net/bugs/1494141
<caribou> this has been fixed everywhere but for Trusty-backports
<rharper> ricotz: hi; thanks;  saw a bug report as well; reproduced and looking at a fix right now;  I've updated the bug: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1511735
<ubottu> Launchpad bug 1511735 in libnl3 (Debian) "libnl: fail to bind() netlink sockets" [Unknown,New]
<ricotz> rharper, thanks, make sure it doesn't leave -proposed ;)
<ricotz> aka "verification-done" is not a good idea yet
<rharper> yep, updated the tag
<rharper> the 6wind folks added that but don't have NM on their tests;
<Saviq> infinity, hrm a simple re-run won't work then, will it? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir
<kgunn> hey there, i was happily working with lxd/lxc sometime ago....and just yesterday had need to work with it again
<kgunn> ran into this
<kgunn> https://pastebin.canonical.com/148727/
<rharper> ricotz: I've tested a fix, filed bug 1539634 for the NM side;
<ubottu> bug 1539634 in network-manager (Ubuntu) "network-manager crashes when using libnl-3-200-3.21.1-1ubuntu1" [Undecided,New] https://launchpad.net/bugs/1539634
<kgunn> it could very well be me, but just in case...any ideas?
<Saviq> infinity, so unless you have a way to make it re-run with qtmir from proposed, we might need to force it through (you can see just below that the new version is fine - pulled new mir in by way of autodeps and bumped build-depends)
<ancaemanuel> the new glibc https://tracker.debian.org/pkg/glibc https://www.sourceware.org/ml/libc-alpha/2015-08/msg00609.html was going for wily release but for some regression is not.
<ubottu> sourceware.org bug 2015 in binutils "Segfault in setlocale() call makes programs unusable" [Normal,Resolved: invalid]
<ancaemanuel> somebody promised that we will have the latest version "next week"
<ancaemanuel> "next week" is now and we do not have any new version.
<ancaemanuel> remember that we have an feature freeze on 18 february, less than 20 days from now
<infinity> ancaemanuel: I'm well aware.
<kgunn> hmmm,blowing everything away, starting over seemed to solve my problem
<bdmurray> pitti: Can you bump the version of ubuntu-release-upgrader in your britney hint?
<tedg> Yesterday I upgraded to Xenial, now witih a 4.3 kernel my computer doesn't think it has a touchpad. Trying to figure out what's up, welcome ideas :-)
<infinity> tedg: A) What kind of computer, B) Try the 4.4 kernel from -proposed before filing a bug, C) file a bug. :)
<infinity> tedg: D) Check settings->Mouse&Touchpad to make sure it's not disabled in userspace.
<ogra_> tedg, so the thinkpad nipple addicts finally won !
<tedg> infinity: XPS 13, a couple generations old. I think it's a PS/2 touchpad though.
<ricotz> rharper, thanks
<cjwatson> infinity,pitti: All right, https://anonscm.debian.org/cgit/pkg-haskell/DHG_packages.git/commit/?id=e03850adc13e0887e3e45f666b05b4be1e4f5b8d should fix Haskell's autopkgtest woes.
<cjwatson> Fingers crossed.
<tedg> Nope, same with 4.4
<sil2100> Saviq: hey! I can add someone to the ci-train-users team if needed
<LocutusOfBorg> sil2100, me me me :)
<LocutusOfBorg> I'm not a core-dev, but I usually look at the transition page, and I really would like to be able to retry testsuite failures
<sil2100> LocutusOfBorg: ah, members of this team don't have such power IIRC ;)
<sil2100> LocutusOfBorg: the ci-train-users are those that can fill silos and do landings through the train
<LocutusOfBorg> oh, I don't even understand what does it mean :)
<LocutusOfBorg> so don't care ;)
<superm1> tedg: can you get the model number (eg 9343, 9333, 9350)?  I might be able to give you some pointer on what touchpad was in there that might aide in you tracking down what happened in 4.3 that broke it
<superm1> but really filing a kernel bug might be best to get dmesg, lsinput and all that various stuff included for the kernel guys to track down further too
<sil2100> Saviq: lukas-kde was that, right?
<sil2100> Saviq: adding
<pitti> cjwatson: yay thanks
<slangasek> hallyn: any objections to me merging slof?
<hallyn> slangasek: no i had my heart set on it!
<hallyn> j/k - no objections ,thanks :)
<slangasek> :)
<slangasek> hallyn: good news, I've adjusted the cross-compiling support for slof to something that should be upstreamable to Debian
<hallyn> slangasek: cool
<slangasek> hallyn: bad news, the Debian git repo is out of date ;P
<hallyn> wrt the Debian pkg?
<hallyn> odd
<rsalveti> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813141 (had that when updating just the systemd package)
<ubottu> Debian bug 813141 in systemd "chroot upgrade from jessie to stretch disables predictable network interface names" [Normal,Open]
<teward> I'm doing some server ISO tests, and I noticed that the 'manual package selection' item in Tasksel during the installer doesn't operate - in older ISOs, it launches aptitude to allow for package selection, but it does nothing on the dailies, is this a known issue?
<teward> oops bleh wrong channel
 * teward kicks his laptop
<teward> (evil touchpad is evil)
<sarnold> not dselect? man kids these days getting  soft. in my day we had dselect and we were happy to have it! both ways uphill in the snow!
<teward> sarnold: i actually couldn't tell what it launched
<teward> looked a little like aptitude to me in 14.04 but I may be wrong
<teward> in either case, it does nothing on the dailies
#ubuntu-devel 2016-01-30
<Laibsch> can I ping the devs here about a simple SRU fix for bug 1287424?
<ubottu> bug 1287424 in mysql-workbench (Ubuntu Trusty) "Cannot install mysql-workbench with mysql-server 5.6 or mariadb" [High,Triaged] https://launchpad.net/bugs/1287424
<elbrus> just for those that care about arm64, today I uploaded the free pascal compiler fpc 3.0.0 to Debian which includes suppport for arm64
<elbrus> I guess Ubuntu needs to bootstrap that somehow.
<elbrus> it is done for Debian already
<elbrus> also, because of the upload of fpc 3.0.0, lazarus and castle-game-engine need to be rebuild
 * elbrus has no clue nowadays how to request that
<elbrus> I guess it requires a debdiff and a sponsor, right?
 * elbrus is not going to work on fixing Ubuntu right now, Debian has already to much work involved, but I thought to let it be known here.
<marlinc> ogasawara what would https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1532198 mean for ZFS on Ubuntu?
<ubottu> Launchpad bug 1532198 in zfs-linux (Ubuntu) "[MIR] zfs-linux" [High,New]
#ubuntu-devel 2016-01-31
<cjwatson> elbrus: Thanks!  I'll sort out a bootstrap once xenial is a bit happier about building things in general again
<cjwatson> elbrus: And a couple of rebuilds will be easy enough after that.
<teward> was a decision ever made on what Lua versions are being kept in Main for Xenial?  (I never bothered to check o.o)
<tsimonq2> !info lua xenial
<ubottu> Package lua does not exist in xenial
<tsimonq2> !info lua xenial-proposed
<ubottu> Package lua does not exist in xenial-proposed
<tsimonq2> ?
<teward> doesn't get answered that easy heh
<tsimonq2> lol
<elbrus> cjwatson: you're welcome
<mitya57> Mirv, can you please remind me what our Qt plan is for X? Expected upstream release date is Feb 24th, while our FF is on 18th.
<mitya57> Does this mean we'll FFe it?
<cjwatson> elbrus: fpc/arm64 bootstrapped; rebuilds of castle-game-engine and lazarus uploaded.  Thanks for the work and the heads-up
<cjwatson> elbrus: https://launchpad.net/ubuntu/+source/castle-game-engine/5.2.0-1build1 doesn't look very healthy - would you mind having a look?
<elbrus> cjwatson: will have a look tomorrow
<elbrus> cjwatson: seems like we need to sourcefully upload (should be done for other reasons as well) to include a new build dependency, or we should fix this in fpc. I'll investigate and fix in Debian.
#ubuntu-devel 2017-01-23
<cpaelzer> good morning!
<Snow-Man> HI!
<pitti> good morning!
<Snow-Man> pitti: hey there! :)
<Snow-Man> pitti: there were multiple comments wrt you in the PG community of late, btw...
<Snow-Man> pitti: I'll summarize them real quick, in case you're interested (it's ok if you are not, of course):
<Snow-Man> pitti: Why does purge remvoe the data directory too?  Seems a bit dangerous, and a bug was filed about it.
<Snow-Man> *remove
<Snow-Man> pitti: Why does a purge (or just remove?) stop *all* databases?  That's *really* annoying when doing an upgrade.
<Snow-Man> as in you do an upgrade, and then want to remove the 'old' cluster after everything is happy, but that removal ends up shutting down the 'new' cluster. :(
<Snow-Man> â¦ I think there were other things, but not remembering atm. :)
<pitti> Snow-Man: well, it's a bit of a YAFIYGI thing IMHO -- "purge" means "leave nothing behind", unlike "remove"..
<pitti> Snow-Man: removing the wrong cluster sounds like a major bug indeed, but I haven't heard from this at all
<pitti> (unlike the "remove clusters on purge" question which comes up every now and then)
<pitti> err, stopping, not removing
<Snow-Man> yea,it's just stopping
<pitti> Snow-Man: the intention is certainly to only stop the clusters of the corresponding version
<pitti> maybe that got broken with introducing the systemd services, IIRC it's still calling the init.d script with the version arg
<Snow-Man> that seems likely.
<Snow-Man> I'll talk to Myon about it
<pitti> and the p-common scripts don't test package removal, so it could easily have slipped through
<pitti> that's saying something -- "once you install PostgreSQL, you will never want to remove it again!" âº
<Snow-Man> hahaha
<Snow-Man> :D
<Snow-Man> ohhh
<Snow-Man> there was something else
<Snow-Man> something like, you need postgresql-common to get the PG userid
<Snow-Man> but, to have that, you need a PG server version installed
<Snow-Man> something awkward like that
<pitti> hm, just -common ought to be enough
<cpaelzer> IIRC if you need users prior to package install can add them it would have to go to base-passwd package?
<Snow-Man> pitti: nah, it wasn't..  I don't remember why right now tho.
<pitti> cpaelzer: right, but that should be very rare -- normally you'd use a Pre-Depends:, or even "more" normally you create needed system users in your own maintscript
<cpaelzer> pitti: of course, I just meant if it had to exist "prior" to any related package install
<cpaelzer> and if they need to share uid/gid across systems
<pitti> right, those are the static gids (< 100)
<LocutusOfBorg> jbicha, python-imagick merge? :)
<LocutusOfBorg> s/python/php
<akxwi-dave> cyphermox:  Has anyone been looking at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1651716 this is still happening in Xubuntu land, as well as on Ubuntu  zesty iso's
<ubottu> Launchpad bug 1651716 in ubiquity (Ubuntu) "17.04 boots direct to live desktop, no option to Try or Install" [Undecided,Confirmed]
<LocutusOfBorg> I would even try a sync
<Dmitrii-Sh> Hi, could anyone please sponsor a patch for qemu in xenial? https://bugs.launchpad.net/ubuntu/xenial/+source/qemu/+bug/1656480
<ubottu> Launchpad bug 1656480 in qemu (Ubuntu Xenial) "QEMU Does not Send L2 Broadcasts After Live Migration" [High,In progress]
<cpaelzer> Dmitrii-Sh: I can look at it later today
<Dmitrii-Sh> cpaelzer: thanks!
<jbicha> LocutusOfBorg: feel free to sync it when it's available
<LocutusOfBorg> ok ta
<cpaelzer> Dmitrii-Sh: review done - looks all good
<cpaelzer> Dmitrii-Sh: not test building and running some tests on it
<cpaelzer> Dmitrii-Sh: but I'd expect it to be in the upload queue this evening
<Dmitrii-Sh> cpaelzer: thx
<LocutusOfBorg> sigh jbicha missing dot :(
<acheronuk> forensics-all seems stuck in zesty proposed as it requires https://packages.debian.org/sid/rekall-core
<acheronuk> is this syncable?
<Dmitrii-Sh> Hi, could anybody take a look at a debdiff for this one https://bugs.launchpad.net/ubuntu/+source/barbican/+bug/1570356 ?
<ubottu> Launchpad bug 1570356 in barbican (Ubuntu) "unable to load plugins in Centos" [High,Triaged]
<cpaelzer> Dmitrii-Sh: on the qemu one - tests still running but so far all green
<cpaelzer> Dmitrii-Sh: I'll collect the final all green and upload if so before going to bed today
<Dmitrii-Sh> cpaelzer: great, thx
<elopio> infinity: could you review this one, please? https://github.com/snapcore/snapcraft/pull/1060
<infinity> elopio: So, I'm guessing snapcraft doesn't support building for multiple/cross arches on one host?
<elopio> infinity: only for the kernel plugin, at the moment.
<acheronuk> ok. filed https://bugs.launchpad.net/ubuntu/+source/forensics-all/+bug/1658728
<ubottu> Launchpad bug 1658728 in forensics-all (Ubuntu) "version 1.5 in zesty proposed has unsatisfied depends on rekall-core" [Undecided,New]
<infinity> elopio: Kay.  So, I'm guessing you're avoiding just asking dpkg because you want something that works on all distros.  You'll be grumpy when you realise that GCC triplets are different on RedHat.
<infinity> elopio: Also, not sure why, in these scenarios, you care about kernel arch at all.
<infinity> elopio: Unless you're using a mismatch later to trigger invoking subproccesses with linux32/linux64 or something.
<elopio> infinity: yup, that will be sad. I'm not sure if snapcraft as a snap could bundle dpkg.
<infinity> elopio: Which is easier to just hardcode "always assume armhf/i386/powerpc are linux32".
<elopio> infinity: can you please comment that on the bug. I wanted to check with you if the approach was correct, but it seems it still needs some work.
<elopio> s/bug/pr
<infinity> elopio: I'll give it a more thorough look after I've woken up.  Still working on that.
<elopio> infinity: take your time :)
<infinity> elopio: Added one comment.  I realised my comment about the scenarios was bogus because that was the testsuite, not the actual code.
<infinity> elopio: This will probably work on Most distros, but anything with a RedHat-derived toolchain will almost certainly not work without tweaking.
<elopio> infinity: we intend to run snapcraft as a snap in other distros. So I think having gcc as a bundled would just work. But it's worth to be sure of that before we go too deep.
<elopio> thanks for the review.
<infinity> elopio: Bundling gcc with snapcraft sounds pretty gross, IMO.
<infinity> elopio: Like, I get the whole snap concept, but there should be limits, one would think. :P
<elopio> infinity: the alternative is not so bad either. Check if we are on redhat, and parse the gcc output differently, or something like that.
<infinity> elopio: Though, I suppose the flip argument of that is that if the goal is to build things that definitely work on an ubuntu-core core snap, you need both gcc and libc-dev from Ubuntu (or, really, our who build-essential).  But it would seem somewhat saner to have a build-essential snap that gets yanked in for such purposes.  Or something.  I dunno.  *handwavy*
<infinity> s/our who/our whole/
<elopio> I'm not sure what will be the approach. Just putting an # XXX comment to deal with that later generally works :)
 * infinity chokes.
<infinity> elopio: Good thing I don't know codebases with decade+ old XXX/FIXME comments. :)
<tjaalton> my laptop still has the broken n-m on zesty, what was the quick'n'dirty way to fix dns?
<jbicha> tjaalton: the new n-m migrated out of proposed so one quick'n'dirty fix is to update your laptop :)
<ScottK> Which might be tough without DNS.
<jbicha> oh, my DNS was broken with CNAMES in containers
<tsimonq2> tjaalton: install libnss-resolv...something or other :P
<tsimonq2> REALLY glad that's pretty much fixed for now
#ubuntu-devel 2017-01-24
<elopio> buffer 10
<cpaelzer> good morning
<pitti> mdeslaur, xnox: FTR: https://bugzilla.suse.com/show_bug.cgi?id=1020601 only affects systemd 228, thus no debian or ubuntu release/pocket/backports/etc.
<ubottu> bugzilla.suse.com bug 1020601 in Incidents "VUL-0: CVE-2016-10156: systemd: world writable suid files local root vulnerability" [Major,Confirmed]
<mdeslaur> thanks pitti!
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: mdeslaur
<sil2100> cpaelzer: hey! I see there's a libibverbs package on Bileto from you ready for release - you want me to release it for you?
<cpaelzer> rbasak: I have a few rather minimal merges done and in progress
<cpaelzer> rbasak: do you want to review them still, or do you think we can upload and just merge if it is really down to a trivial delta?
<rbasak> cpaelzer: I'd like to move towards getting peer review for all uploads, but I don't think there's any need for trivial things right now.
<rbasak> Might as well start with the large stuff.
<rbasak> There may be a squid3 merge review coming your way soon :-)
<cpaelzer> rbasak: makes sense - I'll go on with the trivials to get out of our way then
<cpaelzer> rbasak: I'll trade squid for a multipath review :-P
<cpaelzer> rbasak: in fact my personal timeline says I'll upload multipath on Friday as-is to get some practical testing if there is no review
<cpaelzer> sil2100: thanks for the proactive check, yeah ticket 2395 should be safe (minor upstream release, minimal delta)
<rbasak> cpaelzer: I think that's fine. If no reviewers appear after a while, just land it.
<cpaelzer> sil2100: except I wanted to try hitting publish myself and see what permissions might break
<sil2100> cpaelzer: do you have upload rights for this package?
<sil2100> cpaelzer: anyway, nothing wrong will happen if you press publish, it'll tell you if you have the rights to do it or not
<cpaelzer> sil2100: yeah I should have upload rights, let me check
<cpaelzer> sil2100: ok, it didn't reject me right away - now copying it seems
<cpaelzer> sil2100: "INFO Succeeded in 0m 6s"
<cpaelzer> sil2100: you might keep an extra eye open since this might be the first time a non core-dev hit publish - just in case anything weird comes up
<sil2100> cpaelzer: I guess all looks good!
<sil2100> \o/
<cpaelzer> \o/
<juliank> python-apt 1.4 beta is coming, but there never was a 1.2 or 1.3 (not even a final 1.1) :)
<juliank> So don't get confused, the version number is just matching the apt release series it requires!
<cpaelzer> is that a known issue of sbuild dep8 tests atm "FAIL stderr: W: Ignoring Provides line with non-equal DepCompareOp for package wine"
<cpaelzer> hitting that with an update to exim4 but I doubt to have caused that (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-ci-train-ppa-service-2394/zesty/amd64/s/sbuild/20170124_111649_92763@/log.gz)
<juliank> cpaelzer: Sounds like a bug in wine
<juliank> cpaelzer: It also happens if you run apt update on a recent zesty system
<juliank> Hmm, not sure why that happens.
<juliank> oh wait, wrong chroot
 * juliank is trying to find the broken package
<juliank> Package: wine-stable
<juliank> Version: 1.8.6-3ubuntu1
<juliank> Provides: wine (>= 1:1)
<juliank> Oh, come on
<juliank> jbicha: ^ you merged that?
<juliank> jbicha: I assume that should be wine (= ${source:Version})
<juliank> Or wine (= 1.8) or something
<cpaelzer> oh, thanks juliank for looing
<ginggs> juliank, jbicha: looking at the previous versions, it was just 'Provides: wine'
<juliank> ginggs: Oh, good to know. I'm not sure what the >= 1:1 is trying to achieve - I also just noticed the epoch
<juliank> maybe it should provide wine with an epoch?
<juliank> because some other "wine" package had an epoch
<ginggs> juliank: we are trying to get rid of the epoch
<juliank> In that case, it could Provide: wine (= 1:${source:Version})
<ginggs> juliank: hence the renaming of wine -> wine-stable until the next ubuntu LTS
<juliank> ginggs: Right, but currently the provides is broken. It either needs to become unversioned or a useful version provide.
<juliank> wine (= 1:${source:Version}) is a bit ugly, but has the advantage of simply just saying wine-stable X provides wine with the same version an epoch 1
<ginggs> juliank: shall i just revert to 'Provides: wine'?  i can upload shortly
<juliank> ginggs: Well, I think it's better than keeping it broken. I'm not sure what the intention was, or if it was intentional at all.
<ginggs> juliank: ok, reverting now. i'd better check src:wine-development too
<Laney> juliank: meow, got a second to check on my sanity?
<Laney> juliank: https://launchpadlibrarian.net/303682921/buildlog_ubuntu_zesty_amd64_kubuntu_BUILDING.txt.gz
<Laney> juliank: or schroot -c zesty-amd64 -u root --directory / -- sh -c 'apt -y install appstream; apt -o Acquire::IndexTargets::deb::DEP-11-icons-hidpi::DefaultEnabled=true -o Acquire::IndexTargets::deb::DEP-11-icons::DefaultEnabled=true update'
<juliank> Laney: Ah
<Laney> Don't undertand why the hash sum mismatch
<juliank> Have you seen http://bugs.debian.org/838441
<ubottu> Debian bug 838441 in apt "apt-get update fails with "Hash Sum mismatch", mixes hashes between tar.gz and tar file" [Normal,Open]
<juliank> there's a bug somewhere in APT causing it to take the uncompressed hashes for the compressed file, but no constant reproducer yet
<Laney> juliank: ah right, nope
<ginggs> src:wine-development has 'Provides: wine'
<Laney> that one up there works for me, let me see what you want
<Laney> sec, got to go give a weekly report
<juliank> Laney: I added zesty-sec to my Deb system, and can't reproduce it, so it's officially complicated.
<Laney> juliank: Hmmmm
<Laney> for me it happens with *only* zesty-security in there
<Laney> which is good for reducing the size of the output ...
<juliank> Laney: Hmm, not happening for me
<juliank> Ah wait
<juliank> it only downloaded the inrelease file
<juliank> Laney: The problem happens while copying the file from partial to the main directory
<Laney> juliank: you reproed it?
<juliank> APT tells the copy method it should expect uncompressed hashes for the compressed file
<juliank> Laney: No, but that's what the log say
<juliank> s
<juliank> E: Failed to fetch copy:/var/lib/apt/lists/partial/security.ubuntu.com_ubuntu_dists_zesty-security_main_dep11_icons-64x64.tar.gz  Hash Sum mismatch
<Laney> Also it only happens if I enable both the IndexTargets
<juliank> Ah
<Laney> ximion added that in https://launchpadlibrarian.net/303563290/plasma-discover_5.8.5-0ubuntu1_5.8.5-3ubuntu1.diff.gz
<Laney> bet that's why it's now happening for kubuntu
<juliank> Laney: Oh well, it might not actually be coppying but just an implementation artefact.
<juliank> Laney: Maybe talk to donkult in #debian-apt on OFTC, and add some logs with Debug::Acquire::Transaction set
<juliank> and take a copy of the repo for further debugging :)
<juliank> Debug::pkgAcquire::Auth
<juliank> Debug::Acquire::HashSumMismatch"
<juliank> Laney: ^ some more debugging options
<juliank> I'll give repro a last try
<juliank> And now I can repro :)
<Laney> oh sweet
<cpaelzer> infinity: I looked at liblockfile merge, but I wonder if dropping that old Delta would be fine - especially since this would make liblockfile a sync then.
<cpaelzer> infinity: TL;DR is just dh/dh_auto_configure cross build safe enough these days? I'm not a cross build expert so I wanted to ask and the old delta is yours.
<cpaelzer> infinity: Also it wasn't merged for a long time - if there is a hidden reason please let me know.
<cpaelzer> this is the old delta and the currend d/rules http://paste.ubuntu.com/23858458/
<cpaelzer> hmm just checked the dates on the upstream changelog - there seems to be a flurry of activity just recently
<renn0xtk9> What do you do if you have TPM_Error code 7 (i.e. you can not boot anymore ) and you have no recovery mode in boot ( Note that I never choose to deactivate it so it is a choice of the distro maker, which I would like to understand as welll....)
<cpaelzer> that explains why we had 1.09 for so long
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<barry> davmor2: howdy.  just wanted to let you know that i haven't forgotten about aptdaemon.  been having some trouble with its autopkgtests so i'm trying to suss that out so it won't fail to promote in zesty once i've uploaded it
<davmor2> barry: awesome thanks dude, seb128 flexiondotorg ^
<seb128> davmor2, barry: thanks
<barry> davmor2, flexiondotorg, seb128 you can test the change in lp:aptdaemon but the package isn't yet ready.  i added the fix as a quilt patch in the packaging because i don't think there's been an upstream release of aptdaemon in a long time (probably never will be; i think it's been more or less orphaned)
<seb128> barry, you could probably take over it/update the vcs if you wanted
<barry> seb128: it's the "if" that's the problem :)
<seb128> :-)
<seb128> barry, well in theory foundations is supposed to maintain it...
<seb128> barry, or somebody should look at deprecating it for good and replace it by e.g packagekit on the default install
<barry> seb128: true.  i certainly don't mind helping out in cases like this, i just don't want to assume ownership of the upstream and package :/
<seb128> right
<barry> seb128: yes +1 to that
<barry> pretty sure it's been dropped in debian, so we're looking at gnome-software, language-selector-gnome, oem-config-gtk, and sessioninstaller as revdeps
<barry> aaaannyway
<coreycb> bdmurray, hi can you reject the barbican upload from 2017-01-09 from the xenial review queue?  had to add a missing bug # to the changelog.
<coreycb> bdmurray, thanks
<jbicha> ginggs: thanks for fixing the wine merge
<ginggs> jbicha: np!
#ubuntu-devel 2017-01-25
<tsimonq2> Any chance I can get some help kicking imagemagick through zesty-proposed?
<tsimonq2> I'll do some more local testing, but it would help to get it through for Alpha 2.
<tsimonq2> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt - it shows it breaks things
<tsimonq2> Like I said, I'll play with it locally, but if someone has a solution, please ping.
<tsimonq2> bug 1550210 is in our release notes
<ubottu> bug 1550210 in imagemagick (Ubuntu) "Desktop file does not open ImageMagick from the menu" [Medium,Triaged] https://launchpad.net/bugs/1550210
<krytarik> tsimonq2: You should better focus your efforts on this one then though: https://launchpad.net/debian/+source/imagemagick/8:6.9.7.4+dfsg-1
<tsimonq2> krytarik: I'll file a bug tomorrow
<tsimonq2> krytarik: Thanks, nice catch.
<juliank> So, fairly close to a workaround for the APT issue.
<tsimonq2> juliank: \o/ \o/ \o/
<juliank> It turns out that the whole thing is caused by (a) by-hash producing the same URI for empty icons-128x128 and icons-64x64 and (b) apt merging targets with the same URI
<juliank> The targets then ended up in some kind of different state, and the whole thing went a bit strange.
<tsimonq2> Fun.
<juliank> So what I just tried out is only merging files for the same destination.
<juliank> That fixes the issue, but breaks a minor part in the test suite testing the merging targets works.
<juliank> I'll go to sleep now and hope DonKult has a better idea in the next hours... (it's 4 am now!)
<tsimonq2> Thanks juliank :)
<cpaelzer> hi, anybody ever hit "../sysdeps/nptl/fork.c:156: __libc_fork: Assertion `THREAD_GETMEM (self, tid) != ppid' failed." on our platforms that do container based testing?
<cpaelzer> I ran into that driving a nova test for a proposed qemu update, but from my search I'm almost convinced it is unrelated to the actual thing that you test
<cpaelzer> This is how it looks for me https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty-ci-train-ppa-service-2379/zesty/s390x/n/nova/20170124_144900_ec0dd@/log.gz
<cpaelzer> all efforts on it so far seem to have stalled to a halt https://patchwork.kernel.org/patch/9225661/ https://lkml.org/lkml/2015/2/6/470 https://sourceware.org/bugzilla/show_bug.cgi?id=15392
<ubottu> sourceware.org bug 15392 in nptl "Linux, setns, PID namespaces, fork: assert() about pid inequality hit sporadically" [Minor,New]
<cpaelzer> Since it seems to be something that might just "randomly happen" I wanted to ask if anybody else has seen that?
<cpaelzer> for now I'm rerunning it to check if it is really random for me as well
<juliank> Whoa, snapcraft tests take a long time.
<juliank> Laney, tsimonq2: OK. I got a complete workaround (the right fix?) for the icon tarball hashsum mismatch issue. I can upload that now. I wonder if that affects anyone else than kubuntu, though, and I don't know if the other workaround (do not fetch 128x128 icons) is already enabled.
<Laney> juliank: plasma-discover is the package that enables both - I don't see an upload changing that
<juliank> Laney: OK, I cherry-picked that from its branch and the fix for partial requests on sourceforge from master and uploaded it :)
<juliank> the partial request thing was #1657567
<juliank> bug 1657567
<ubottu> bug 1657567 in apt (Ubuntu) ""Content-Range: */<file size>" on non-416 responses considered invalid" [Low,Fix committed] https://launchpad.net/bugs/1657567
<Laney> juliank: many thanks ;-)
<Laney> we can kick a new kubuntu build once apt goes in
<fossfreedom_> cjwatson: re this ISO boot issue (screenshot in the bug report) - is this some sort of isolinux theming issue - if so, any ideas how we can resolve this for Ubuntu Budgie? https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/1659278
<ubottu> Launchpad bug 1659278 in syslinux (Ubuntu) "Ubuntu Budgie does not boot directly to ubiquity try/install screen" [Undecided,New]
<cjwatson> IIRC there's some horrible thing buried in debian-cd or something
<cjwatson> fossfreedom_: yeah, see lp:~ubuntu-cdimage/debian-cd/ubuntu tools/boot/zesty/boot-*, look for HIDDEN_TIMEOUT in particular
<cjwatson> the semantics are a bit of a mess but are explained in the gfxboot-theme-ubuntu changelog, items for 0.9.3 and 0.9.9
<cjwatson> (sorry ...)
<fossfreedom_> cjwatson: oh... that is making my head spin trying to understand that.
<rbasak> cyphermox: are you aware of the network-manager and network-manager-applet SRUs in Xenial?
<rbasak> Just wondered if you were still involved and/or had an opinion.
<cjwatson> fossfreedom_: it is unpleasant, sorry - but I think the above is probably enough information to fix the bug
<fossfreedom_> cjwatson: k - thanks. think I understand this.  How can I test a proposed merge request?
<cjwatson> fossfreedom_: la la la
<cjwatson> fossfreedom_: best is probably to remaster an image with hidden-timeout=2 or whatever hacked into the relevant config file, but you'll need to figure out where ...
<cpaelzer> jamespage: coreycb: I've hit THREAD_GETMEM in the nova dep8 Test triggered by the install of ca-certificates
<cpaelzer> jamespage: coreycb: I've asked about that about 5.5h before now in the chan, but nobody else responded to have seen it
<cpaelzer> jamespage: coreycb: since it shows up "again" on s390 on my retest I wonder how common that might be - have you seen those issues?
<jamespage> cpaelzer, I'll defer to coreycb and zul for that answer
<coreycb> cpaelzer, i've never seen it unfortunately
<cpaelzer> coreycb: this was my former question with a bit more details https://irclogs.ubuntu.com/2017/01/25/%23ubuntu-devel.html#t08:48
<cpaelzer> coreycb: really never - weird
<zul> cpaelzer:i dont remember seeing that either
<cpaelzer> thanks zul and coreycb
<cpaelzer> I'm just puzzled on how random it might be as I hit it on ppc&s390 at first and s390 only on the retry
<coreycb> xnox, have you come across this at all on s390? ^
<coreycb> cpaelzer, it sounds like it's container related then
<cpaelzer> seems to be able to happen on any of the autppkgtest environments that use containers
<cpaelzer> yes that is what I found from my debugging this morning
<cpaelzer> or even "pid namespace" related to be even more specific
<mitya57> Mirv, hi! Do you have any plans to update qtcreator? It currently blocks qbs migration because it was built against old version, and with new qbs it FTBFS (https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2401/+packages).
<coreycb> cpaelzer, yeah i'm surprised i haven't seen it before
<cpaelzer> for now I'll rerun it again to see how transient it is, but the 3/4 I've seen so far do not appear as "almost never" to me
<coreycb> cpaelzer, possibly related: https://groups.google.com/forum/#!msg/linux.kernel/G7aBRlEGHqw/tXT9cJV_AwAJ
<coreycb> cpaelzer, https://sourceware.org/bugzilla/show_bug.cgi?id=15392
<ubottu> sourceware.org bug 15392 in nptl "Linux, setns, PID namespaces, fork: assert() about pid inequality hit sporadically" [Minor,New]
<coreycb> cpaelzer, https://lkml.org/lkml/2015/2/6/470
<cyphermox> rbasak: sorry, I can look but I don't know off the top of my head
<cpaelzer> coreycb: yeah that is the bug I linked this morning
<coreycb> cpaelzer, oh, sorry :)
<cpaelzer> coreycb: no reason to excuse
<cpaelzer> coreycb: I just hope you didn't spend too much time to re-find that
<Mirv> mitya57: hi. not special plans, feel free to update though as the delta is smallish these days and easy to keep.
<mitya57> Mirv, OK, will try to update it.
<rbasak> xnox: please can you explain _why_ you make changes in your changelog entries? Take bug 1657909 for example, which is in limbo because we don't know why you made a change.
<ubottu> bug 1657909 in gnome-keyring (Ubuntu Yakkety) "SSH service should be hidden from Startup Applications too" [Low,In progress] https://launchpad.net/bugs/1657909
<rbasak> xnox: also if you could explain in the bug, that would be useful.
<fossfreedom_> andyrock: Hi - seb128 signed you up on this bug report affecting Ubuntu Budgie!! https://bugs.launchpad.net/ubuntu/+source/budgie-desktop/+bug/1631745  ... any chance you can have a quick glance over my proposed patch to gnome-menus please?
<ubottu> Launchpad bug 1631745 in gnome-menus (Ubuntu) "hostname-panel crashed with SIGSEGV in g_slice_alloc()" [High,In progress]
<andyrock> mmm the fix is not a real fix
<andyrock> we need a proper bt or valagrind log to solve it
<fossfreedom_> k - my intention is not to affect any other desktop like Unity - just needed to get budgie-desktop to run through the original code because the problem does not occur with that codebase
<fossfreedom_> valagrind doesnt help here - it doesnt crash - I guess its a race condition of somesort and the slow running through valgrind doesnt exercise the issue.
<andyrock> gnome-panel does not crash
<andyrock> it can be that the problem is in budgie-desktop main menu code
<andyrock> fossfreedom_ i'm ok with that patch
<andyrock> but I'm wondering why you can't just distro patch directly in budgie-desktop
<fossfreedom_> andyrock: yeah  - discussed with upstream - they couldn't reproduce this so would not deal with the issue (understandably)
<fossfreedom_> budgie-desktop is vala based.  I don't have any vala knowledge myself so can't patch it.  I only know C and python :/
<andyrock> oki
<andyrock> seb128 is not online
<andyrock> we need to talk with him
<juliank> Laney: I just received the email that apt was accepted :)
<juliank> Exciting times!
<Laney> juliank: nice to know we have solid tests :P
<Laney> when rmadison agrees, we can fire the rebuild
<nacc> cpaelzer: around?
<cjwatson> fossfreedom: I think if you know C and Python then modifying existing Vala code should be pretty straightforward (maybe harder if you have to write significant new code)
<cjwatson> to simplify, it's basically C with Javaish syntax layered over the top and approximately Python-like library bindings
<coreycb> doko, a fix for python-glanceclient is in the trusty review queue.  bug 1404227
<coreycb> https://bugs.launchpad.net/python-glanceclient/+bug/1404227
<fossfreedom> cjwatson: Myself and upstream have looked at the budgie-code, there doesnt seem to be anything wrong in the way it is coded - proper locking to stop reentrant type issues etc.  The menu code really does assume gnome-menus does all the heavy lifting - it only uses the output.  So given where this issue is I dont see a way to intercept/integrate any code without rewriting masses of gnome-menu code :/
<ubottu> bug 1404227 in python-glanceclient (Ubuntu) "Unit test failures due to changes in python 2.7.9" [Undecided,New] https://launchpad.net/bugs/1404227
<camako> Anyone know why I'm getting this?
<camako> /usr/bin/ld: cannot find -lpthreads
<camako> This is on a silo
<camako> .. trying to build qtmir
<camako> https://launchpadlibrarian.net/303893883/buildlog_ubuntu-zesty-amd64.qtmir_0.5.1+17.04.20170125.1-0ubuntu1_BUILDING.txt.gz
<mwhudson> camako: that should be -lpthread surely
<mwhudson> camako: without the s
<camako> mwhudson, oh I wonder why it's with 's'
<camako> mwhudson, I am blind... thanks for spotting it
<mwhudson> camako: np :)
<bdmurray> juliank: These apt autopkgtest failures for the SRU are false positives right?
<juliank> bdmurray: ack
<gpiccoli> Hi folks, greetings! I found a weird "bug" on libgtk/gtk2-engines-pixbuf, I manage to fix in my system, but worth the report I guess
#ubuntu-devel 2017-01-26
<gpiccoli> Did a distro-upgrade yesterday, rebooted the machine; suddenly my mate desktop was bugged and audacious player was gone! The guilty:gtk2-engines-pixbuf was not installed anymore
<gpiccoli> Tried to reinstall it, got: https://paste.ubuntu.com/23866507/
<gpiccoli> Then, I downloaded the deb package and modified the dependency to match the requested one, worked fine
<gpiccoli> So, who's "wrong", gtk2-engines-pixbuf or libgtk2, that is reporting it's version as 2.24.30-1ubuntu1.16.04.1
<gpiccoli> ?
<gpiccoli> Should I fill a LP?
<sarnold> gpiccoli: does dpkg --get-selections | grep -i hold report anything?
<gpiccoli> let me check sarnold
<gpiccoli> is this the command sarnold: "sudo dpkg --get-selections | grep -i hold" ?
<gpiccoli> it's empty
<sarnold> I didn't require sudo on mine. but that's curious, the error says something about held packages, so I expected to see one. :)
<sarnold> I have the impression the "2.24.30-1ubuntu1.16.04.1 " version should only be in -proposed; if you're not actively testing something from proposed you could disable that pocket in your apt configuration, I guess, but it might still be worth figuring out why you only got half the package update apparently :/  https://launchpad.net/ubuntu/+source/gtk%2B2.0
<gpiccoli> oh sarnold, but I manage to bypass the original error by changing the deb package control file
<gpiccoli> sarnold, enabled proposed in the past, to install kernel 4.8; then disabled right after and I expected it wouldn't mess with any packages of mine
<cking> happyaron, hi, did you get my reply to the zfs packaging review?
<happyaron> cking: yes, but not yet updated the debian packages yet
<happyaron> spl-linux was updated
<happyaron> just zfs-linux needs an upload
<cking> happyaron, ok, cool, just wondered if my email got back to you
<happyaron> but my subkey is expiring... can't do upload in the mean time
<cking> ah, oops
<zul> hi can an archive admin please review python-os-xenapi please?
<pmcgowan> Laney, hi are yous till looking at bug #1644323
<ubottu> bug 1644323 in Canonical System Image "Installing unity8-session-snap adversely effects unity7" [High,Confirmed] https://launchpad.net/bugs/1644323
<Laney> pmcgowan: no, it was done from my POV
<pmcgowan> oh, it was reverted
<Laney> there was something broken in xenial touch that made it break the session
<pmcgowan> right
<Laney> right, but sil2100 will take care of re-uploading once that is fixed
<pmcgowan> hmm, ok will look elsewhere thanks
<Laney> sorry
<sil2100> Yeah
<pmcgowan> np
<Laney> I think Saviq was looking?
<sil2100> Saviq said Robert Ancell would have to look at it probably
<sil2100> IIRC
<Saviq> Robert did say he'll have a look, yes
<pmcgowan> sil2100, this bug is a pain, and I couldnt install the old debs for some reason, screwed up my system
<Laney> you could re-apply the diff in a silo or PPA or something
<Laney> if it's just for personal usage
<pmcgowan> I can work around it by removing the unity8-session then reinstalling when I need it
<pmcgowan> Saviq, can we see that he is looking?
<Laney> well, or hack /usr/share/upstart/sessions/dbus.conf
<pmcgowan> Laney, oh?
<Laney> https://launchpadlibrarian.net/302225938/dbus_1.10.6-1ubuntu3.2_1.10.6-1ubuntu3.3.diff.gz
<Laney> just reverse apply that patch to that file
<pmcgowan> Saviq, can we add a task and have robert assigned to it
<Saviq> pmcgowan, bug #1654365
<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
<Saviq> not sure we should merge
<pmcgowan> ok
<pmcgowan> Laney, where is the patch, dont see it attached to the bug
<pmcgowan> oh
<pmcgowan> Laney, Saviq thanks
<Laney> nacc: hi, just want to poke you about https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1639962
<ubottu> Launchpad bug 1639962 in samba (Ubuntu) "smbd crashed on startup with newest libtevent" [Critical,Triaged]
<Laney> any chance you could do it soonish? :-)
<Laney> I noticed https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/g/gvfs/20170124_003147_bb0b7@/log.gz <- failing, looks to be because of this
<Laney> and then I found out that it's basically busted
<Laney> anyway, just wanted to poke, got to go - see you
<nacc> Laney: ack, it's on my todo, will bump it up to this week
<tjaalton> why do the text dialogs in launchpad flash in orange when clicking on them?
<sladen> focus?  confirmation?
<tjaalton> that's a bit too obvious confirmation
<tjaalton> this is with firefox, dunno about other browsers
<tjaalton> holding the left button on a comment box keeps the box orange
<tjaalton> seeing it on both zesty and xenial, so guess it's a firefox feature now
<dobey> tjaalton: on a bug comment box?
<sarnold> tjaalton: that's a new firefox thing
<sarnold> I never figured it out but it's damned annoying
<dobey> yeah i am not seeing what you describe, in chromium
<dobey> sounds like some a11y feature in firefox
<tjaalton> sarnold: phew, I'm not the only one then :)
<tjaalton> dobey: yep
<sarnold> same thing happens on e.g. edit text boxes on wiki.ubuntu.com and http://paste.ubuntu.com/
<mwhudson> oh wow
<fossfreedom> hi all - can I ask a question here please with regards to ubuntu's lightdm package?  I'm trying to work out why unity-greeter is being installed in Ubuntu Budgie - I think its being install by lightdm - I've never seen this syntax for the recommends section of the debian/control file - what does this mean?
<fossfreedom> Recommends: unity-greeter | lightdm-gtk-greeter
<sarnold> | seperates alternations, similar as regex https://www.debian.org/doc/debian-policy/ch-relationships.html
<fossfreedom> sarnold: so unity-greeter is always installed when you install lightdm?
<tjaalton> not if you install lightdm-gtk-greeter as well
<sarnold> fossfreedom: unless lightdm-gtk-greeter is already installed.. probably apt-get install lightdm lightdm-gtk-greeter would also skip installing unity-greeter
<fossfreedom> sarnold: so I shouldn't explicitly add a depends on lightdm?  just on lightdm-greeter when should then install lightdm but not unity-greeter?
<fossfreedom> * when which
<sarnold> fossfreedom: I'm not sure what to recommend.. (a) I'm not awesome at debian packaging, I just happened to know this one :) (b) I'm not sure what you're trying to achieve in the end
<fossfreedom> k - thanks for the hints.  our packaging has not explicitly added "unity-greeter" anywhere - but its some how being installed on the ISO.  Ubuntu Budgie uses lightdm and lightdm-gtk-greeter - so I'm trying to figure out why unity-greeter is being pulled onto the ISO.
<sarnold> fossfreedom: hrm. are you in a position to apt-get purge unity-greeter and see what else would be removed?
<krytarik> fossfreedom: I'd think it's too far down the dependency chain - adding it to the seed directly should solve it.
<fossfreedom> hmm - that sounds interesting - I guess that will mean a rebuild of our meta-package?  Yep could try that.
<clivejo> can anyone explain or point me in the direction of instruction on how to only build for certain arch?
<cjwatson> fossfreedom: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-budgie.zesty/desktop says "lightdm (Recommends)", so I'd probably suggest adding lightdm-gtk-greeter to your desktop seed and see if that helps
<cjwatson> fossfreedom: you can run germinate against a locally-modified seed branch to test the changes
<cjwatson> ... ah, krytarik got there before me too
<cjwatson> yes, it would require rebuilding the metapackage
<doko> coreycb, jamespage: looks like #1404227 was never closed for the distro package
<clivejo> doko: We are being affected by this bug - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840293 is there any chance of patching the ubuntu version or syncing with Debian?
<ubottu> Debian bug 840293 in libdpkg-perl "libdpkg-perl: Dpkg::IPC::spawn immediately closes FH after dup" [Important,Fixed]
<doko> clivejo, infinity: looks like a dpkg merge. not sure when infinity had planned that. but this merge has other nasty changes
<clivejo> doko: any chance of getting a fix?  symbol helper has been broken in zesty for months now
<vincenttc> will python 3.5.3 be backported to xenial? I'm facing a bug in the email library that is fixed in that version
<sarnold> vincenttc: it's unlikely, python whole-version backports have caused severe trouble in the past
<sarnold> vincenttc: but if you can track down a commit that addresses your bug it might be able to be SRUd
<vincenttc> sarnold: thanks, I was hoping it would be backported, since 3.5.2 was, but I'll try to find the specific commit then
<sarnold> vincenttc: oh, if 3.5.2 was backported and I don't remember any giant hassles, then maybe there's a chanve for 3.5.3. :)
<vincenttc> sarnold: any idea how long that would take?
<sarnold> no, sorry
<vincenttc> np, thanks anyways
<cjwatson> it can't be as bad as updating through python2.7 maintenance releases ;-)
#ubuntu-devel 2017-01-27
<nacc> smoser: ping
<nacc> rharper: you may be able to hel guide, if you're around, as well
<rharper> here
<nacc> rharper: hey, so i'm looking at LP: #1645515
<ubottu> Launchpad bug 1645515 in curtin "Support for ISCSI block devices" [High,Confirmed] https://launchpad.net/bugs/1645515
<nacc> i think i finally understand the code enough to know where the changes need to go
<nacc> but in reading smoser's suggestion in c1, it feels like maybe the format suggested in the bug is not exactly what would be used -- minimally because rfc4173 includes 'iscsi:...'. Did you and smoser have a plan of how to specify a iscsi disk in the yaml?
<rharper> the format is a suggestion; not a spec
<rharper> my suggestion would be to run with changes to that that make sense
<rharper> we will get to define what's required and the format
<rharper> maas will the learn to specify the format as needed
<nacc> ok, so my initial thought was to overload 'path', as the rfc2173 format is a network path (fully specified) to a disk
<nacc> rather than adding a nested iscsi config section
<rharper> hrm
<rharper> so, conceptually I would like to treat an iscsi disk as a disk generically
<nacc> agreed, rather than a special case
<rharper> basically, once we've established connection, it will show up as a block device;  would we not be able to construct whatever dictionary of config needed under the disk.iscsi namespace ?
<rharper> I imagined the iscsi.* space to include details w.r.t what is needed for establishing the connection
<nacc> right, but the rfc2173 specification is all of that in one line
<nacc> *4173
<rharper> the path would be an expected dev/disk/by-id path
<rharper> s/would/coud
<rharper> could
<rharper> ok
<nacc> and given that, it feels weird (to me) to say
<nacc> iscsi:
<nacc>   uri: iscsi:<servername>:<protocol>:...
<nacc> as it seems sort of redundant :)
<rharper> yeah;  if we can get it in a single line, that seems reasonable;  in our disk_handler, we can check on path.startswith("iscsi:" ) and spin off an iscsi_handler
<nacc> yep, that's what i was thinking
<nacc> just wanted to verify it made some sense first :)
<nacc> rharper: to be clear, that would be off in get_path_to_storage_volume? or would it be a special case in disk_handler itself? I see the former is called in multiple places
<rharper> I'm thinking we may need to spin those up first
<rharper> it could be triggered off the get_path_to_storage; but I don't like that as a side-effect of looking up a path
<nacc> ah good point
<rharper> we could introduce an iscsi_handler that's fed disk objects which have a path with 'iscsi':  at the start
<rharper> and the iscsi_handler would call disk_handler after the setup is complete
<rharper> the contract being that after iscsi_handler is done, the get_path_to_storage_volume would return the local scsi device path that can be used by disk_handler
<nacc> right
<nacc> that makes some sense to me, we pay the cost one-time, up front to setup the connection, at init time, and then from then on use the normal /dev/disk path and treat it like it's a local disk
<nacc> or whatever local /dev path makes sense, i mean
<rharper> y
<nacc> rharper: great, thanks!
<rharper> sure
<fossfreedom_> cjwatson:  thanks for the feedback with regards to using our seeds to resolve lightdm-gtk-greeter vs unity-greeter.
<fossfreedom_> I have updated our desktop seed.  I could not get germinate to run locally (kept saying 'unknown package' for various stuff) - but I noticed today that http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-budgie.zesty/_germinate_output no longer contains unity-greeter.
<fossfreedom_> So I presume I should now run ./update in our meta package and ask for an upload of our meta package with the changes?
<fossfreedom_> damn - unity-settings-daemon is still being installed - something else is pulling that in.
<caribou> Hi, what's the systemd service that is responsible for removing the /run & /var/run tmpfs ?
<cjwatson> fossfreedom_: Yep.
<ogra_> caribou, removing ? its a tmpfs ... so it is gone on reboot
<ogra_> you dont need a service for that
<caribou> ogra_:  hmm, yes true.
<caribou> ok, I go back to sleep
 * rbasak discovers that bug tasks have tooltips on Launchpad.
<rbasak> Handy!
<smoser> nacc, reading back above... see in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=804162
<ubottu> Debian bug 804162 in open-iscsi "open-iscsi: support iscsi root by format in RFC 4173 (root=iscsi:server:prot:...)" [Wishlist,Fixed]
<smoser> "Note that RFC does not cover username and password, so that would have to be done outside the spec if needed."
<smoser> it may be sufficient to use what is supported in dracut and in that debian fix
<zerous> Hi, I would like to get involved with ubuntu packaging and as I am really new I have decided to go with fixing packages which have unmet dependencies. However, I am not able to retrieve the list using debcheck.py as it throws an error "No such file or directory: debcheck.tmpl. I am running ubuntu yakkety with python 2.7.12
<zerous> Ubuntu packaging bug #1214608
<ubottu> bug 1214608 in phatch (Ubuntu) "Unnecessary thai-fonts dependency" [Low,Triaged] https://launchpad.net/bugs/1214608
<zerous> Bug #1370599
<ubottu> bug 1370599 in fontypython (Ubuntu) "Build against wxgtk 3.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1370599
<nacc> smoser: ack
<nacc> doko: would you be ok with me merging ldb? Updated samba depends on a newer version of libldb-dev than what is in zesty currently?
<zerous> nacc: I am really new to bug fixing and packaging, will you be able to walk me through the entire process of it ?
<nacc> zerous: what are you trying to do?
<zerous> nacc: Well I would like to fix bugs related to packaging.
<zerous> Hence, I wanted to know how it is done. For instance bug 1370599
<ubottu> bug 1370599 in fontypython (Ubuntu) "Build against wxgtk 3.0" [Wishlist,Confirmed] https://launchpad.net/bugs/1370599
<nacc> zerous: i don't see that source package any longer in ubuntu, do you?
<nacc> zerous: bah, nm, typo on my part
<nacc> zerous: afaict, in zesty, it already depends on wxgtk3.0
<bdmurray> barry, slangasek: will one of you be able to have a look at my apport changes?
<zerous> nacc: yeah, it is. So I guess I have to hunt for another one
<dupondje> mm firefox broke?
<dupondje> chrisccoulson: nobody reported issues on firefox or so? Since the update to 51.0.1 my pages are all blank .. :)
<dupondje> anyone else with broken firefox since 51.0.1 update on yakkety?
<jgrimm> dupondje, working for me,
<dupondje> strange... my whole page is just blank
<dupondje> downgraded, and it works fine again
<chrisccoulson> dupondje, what addons do you have installed?
<chrisccoulson> dupondje, do you see the browser chrome? Is it just the content that's blank?
<dupondje> chrisccoulson: even in safe mode its broken
<dupondje> and I see the bars etc indeed, just the content is white
<dupondje> but for example if I open a new tab, the 'history' pages are shown correctly
<dupondje> also if I browse to some site, I can click on the links etc
<dupondje> but its just all white
<chrisccoulson> dupondje, does it work if you run with MOZ_FORCE_DISABLE_E10S=1 in the environment?
<dupondje> let me test
<tjaalton> jbicha: you still have pkg-gnome packages on subversion?-)
<jbicha> tjaalton: we're moving to git soon, but that's been the case for several years, maybe in 2017?
<dupondje> chrisccoulson: yep! then it works fine again ..
<jbicha> tjaalton: I believe the main blocker all along was just making sure that svn history was preserved along with author mapping
<chrisccoulson> dupondje, awesome, thanks!
<dupondje> :)
<chrisccoulson> dupondje, can you please open a bug on bugzilla.mozilla.org?
<chrisccoulson> (it would be worth including the info from about:support too)
<tyhicks> chrisccoulson: isn't it odd that it is even broken in safe mode? when I start firefox in safe mode, e10s gets disabled
<tjaalton> jbicha: alright, was just looking at backporting libpwquality from jessie to wheezy..
<tjaalton> for sssd
<chrisccoulson> dupondje, once you've got a bug number, please let me have it :)
<chrisccoulson> and I'll make sure the right people are cc'd
<jbicha> I feel like pkg-gnome is one of the largest remaining users of svn in Debian packaging
<tsimonq2> SVN? O__o
<tsimonq2> ...why?
<sarnold> because it really was a vast improvement over CVS :)
<tsimonq2> Well I guess my question is, why are we *still* using it?
<dupondje> chrisccoulson: i'll fix later this evening or tomorrow :)
<dupondje> trying to migrate my laptop to an SSD now :)
<dupondje> and that **** livecd isn't starting correctly :(
<infinity> slangasek: "now redundant with iproute2" ... Is it though?
<infinity> slangasek: arp, rarp, and netstat are tools I use near-daily.   net-tools isn't just ifconfig and route.
<slangasek> infinity: iproute2 contains ss as a replacement for netstat; arp and rarp don't seem particularly "minimal" to me; see both the debian-devel and ubuntu-devel discussions
<infinity> slangasek: Yeah, I found the ubuntu-devel discussion.
<infinity> slangasek: Despite it never having been Essential, I suspect there are a ton of user-local scripts that depend on ifconfig existing (I know I have a few), so that'll be fun fallout.
<acheronuk> slangasek: so something like?
<acheronuk> dpkg-architecture -e s390x
<acheronuk> if [ $? -eq 0 ]
<acheronuk> then
<acheronuk>   exit 0
<acheronuk> fi
<infinity> acheronuk: "if dpkg-architecture -e s390x; then" is the compact way to write that.
<infinity> (Totally not sure of context)
<acheronuk> infinity: just wanting to put a conditional to exit a testuite with a pass exit code status, on an architecture that is borked for the test
<infinity> Understanding why it's broken would help.
<slangasek> sure. but inop'ing the test, on an architecture where the software is not actually supported, is better than making the release team repeatedly hint it
<infinity> Yeah.  Just curious if the failure has to do with s390x or with the infrastructure.
<infinity> ie: People blame s390x for gnupg-fails-on-long-paths-in-containers, for instance.
<infinity> And the solution shouldn't be "ignore s390x", but "ignore in containers", or "try to sort out how to make it less dumb".
<slangasek> if so, that should show up on both s390x and armhf
<infinity> Was just an example.
<acheronuk> asked upstream and could could maybe summarise the response as "why the *something are you building on that architecture?"
 * infinity tries to teach himself 'ss' ...
<acheronuk> anyway, I just wanted to confirm that a testuite would exit then with a 'no-op' pass with that code.
<infinity> acheronuk: Anyhow, quibbling about "why" aside, yes, that should work.
<acheronuk> infinity: thanks. still learning on these tests
<acheronuk> slangasek: and thank you too
<infinity> Or, much more compact: "dpkg-architecture -e s390x && exit 0"
<tsimonq2> infinity: Best way to check if package tests work locally? Docs are outdated.
<infinity> tsimonq2: Run them locally.
<tsimonq2> infinity: ...how?
<tsimonq2> infinity: (in a Debian-packageish way)
<infinity> tsimonq2: For anything that doesn't reboot the testbed, you can just install the deps and run the tests listed in debian/tests/control
<tsimonq2> infinity: hm k
<tsimonq2> Thanks
<infinity> For things that break the testbed, you can run them "properly" via... Stuff that is indeed documented.  But I always forget the URL.
 * tsimonq2 naps, hurt my knee and I'm tired...
<tsimonq2> Ok thanks o/
<infinity> http://packaging.ubuntu.com/html/auto-pkg-test.html looks like the place.
<acheronuk> infinity: yep running the tests locally works here. though some architectures don't seem possible to emulate here
<acheronuk> there are newer 'autopkgtest' commands to run that that wiki link as well. pitti had a blog post explaining I think?
<acheronuk> https://www.piware.de/tag/autopkgtest/
<jgrimm> nacc, did you delete any git repos for packages in usd-import-team?  asking as i'm certain their used to be an iproute2 there
<nacc> https://code.launchpad.net/~usd-import-team/ubuntu/+source/iproute2/+git/iproute2 ?
<nacc> jgrimm: --^
<jgrimm> doh
<nacc> jgrimm:  there are about 300 packages imported now, it seems like
<jgrimm> i saw! that's wild
<nacc> jgrimm: do you need me to update iproute2? it might be out of date
<jgrimm> nacc, yes it is, that's why i went looking for it
<jgrimm> thanks!
<nacc> jgrimm: np, running now
<nacc> jgrimm: it ony imported two new publishes (4.9.0-1) to debian (sid/stretch), is that what you expected? (it's also done now if you want to fetch and check)
<jgrimm> yep, 4.9 was what i wanted
<jgrimm> nacc, thanks
#ubuntu-devel 2017-01-28
<jgrimm> nacc, usd tag --deconstruct
<jgrimm> 01/27/2017 18:07:53 - ERROR:Working tree must be clean to continue.
<jgrimm> nacc, any ideas what could be going awry?
<nacc> jgrimm: `git status` ?
<jgrimm> nothing to commit, working tree clean
<nacc> `git status --ignored` ?
<nacc> jgrimm: --^
<jgrimm> ah .pc ignored
<nacc> :)
<nacc> i think `usd clone` should have warned you about that, but if you already had it cloned, it won't
<jgrimm> nacc, it did warn me ..  i didn't think of it at this stage
<jgrimm> nacc thanks sir
 * jgrimm calls it for the week
<nacc> jgrimm: np
<elopio> Laney: I know it's too late, and you are probably not going to see this. But just in case, we are getting again armv8l in the armhf autopkgtests: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20170128_025104_e10de@/log.gz
<dupondje> chrisccoulson: https://bugzilla.mozilla.org/show_bug.cgi?id=1334778
<ubottu> Mozilla bug 1334778 in Untriaged "Content of webpage blank" [Normal,Unconfirmed]
<fossfreedom> jbicha: are you testing out Nautilus 3.22 ?  Solus are telling me that if desktop-icons are enabled nautilus seg-faults.  Assuming Ubuntu is similarly affected this will affect unity 7 and budgie-desktop.
<doko> nacc: sure
<dupondje> chrisccoulson: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1627239 FYI
<ubottu> Launchpad bug 1627239 in firefox (Ubuntu) "Web pages not rendering with e10s enabled and AppArmor profile in enforce mode" [High,Confirmed]
<dupondje> think we found the cause :)
<jbicha> fossfreedom: is there a bug number for that? desktop icons seem to work here with nautilus 3.22
#ubuntu-devel 2017-01-29
<jbicha> you can try out nautilus 3.22 for yourself with the gnome3 staging ppa
<jbicha> nautilus 3.22 still needs some more work before it is ready for Ubuntu, see bug 1635988 if you're interested
<ubottu> bug 1635988 in nautilus (Ubuntu) "Update nautilus to 3.22" [Wishlist,Triaged] https://launchpad.net/bugs/1635988
<jbicha> there's also the old https://bugzilla.gnome.org/747662 but check out the duplicate bug 768303 there
<ubottu> Gnome bug 747662 in Desktop "Nautilus crashes when "Icons on Desktop" is enabled ("assertion failed: (!container->details->auto_layout)")" [Critical,New]
<ubottu> bug 768303 in ubiquity-slideshow-ubuntu (Ubuntu) "Czech version of Ubiquity installer has uncapitalised "Internet" on one of the screens" [Low,Fix released] https://launchpad.net/bugs/768303
<jbicha> the gnoem bug not the ubiquity one
<acheronuk> Hi. can maybe someone with permissions prod test re-runs for purpose with &all-proposed=1 please?
<acheronuk> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#purpose
<acheronuk> some local testing suggests that should then pass on the testsuite, but fail on the acc headers check
<acheronuk> which I think would be LP: #1660108 which I am trying to get sorted
<ubottu> Launchpad bug 1660108 in gcc-6 (Ubuntu) "Since 6.3.0-3ubuntu1 some acc autotests fail with "atomic_base.h:390:7: error: inlining failed in call to always_inline"" [Undecided,New] https://launchpad.net/bugs/1660108
<ginggs> acheronuk: requested
<acheronuk> ginggs: thanks :)
<fossfreedom> hi - a really basic bzr question - I have branched this https://code.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu
<fossfreedom> but when I try to push a branch I get the following:
<fossfreedom> bzr push lp:~fossfreedom/ubuntu-cdimage/debian-cd/ubuntu/ubuntu-budgie
<fossfreedom> bzr: ERROR: Permission denied: "~fossfreedom/ubuntu-cdimage/debian-cd/ubuntu/ubuntu-budgie/": : No such distribution: 'ubuntu-cdimage'
<fossfreedom> what have I done wrong?
<mwhudson> can i get distro-info to print out a mapping from code name to release? (i.e. trusty -> 14.04)
<mwhudson> ah /usr/share/distro-info/ubuntu.csv does the job i guess
<fossfreedom> ah - figured out my bzr issue - project name is not the same as the branch!
<tumbleweed> mwhudson: ubuntu-distro-info --series=trusty --release
<mwhudson> tumbleweed: ah thanks
#ubuntu-devel 2018-01-22
<juliank> Whoa, arms are building again?
<cjwatson> Yeah, as of Friday evening
* juliank changed the topic of #ubuntu-devel to: Launchpad build farm capacity limited, and non-{x86,arm} builds suspended | Artful Released + taken down LP#1734147 | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<juliank> cjwatson: Added that to the topic :)
<juliank> non-x86 => non-{x86,arm}
<cjwatson> ta
<lyarwood> Any libvirt package maintainers able to review https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1744758 please? Appears to be a recent regression with the UCA build.
<ubottu> Launchpad bug 1744758 in libvirt (Ubuntu) "libvirt 2.5.0-3ubuntu5.6~cloud0 appears to be compiled without gnutls" [Undecided,New]
<ricotz> chrisccoulson, hi :), are you working on ff58?
<nacc> is there an easy way for me to download a source package from the debian new queue? (for the purposes of updating PHP in ubuntu for bionic)
<nacc> nm, i found the debian git repo (it had moved)
<jbicha> cjwatson: thoughts on LP: #1738046 ?
<ubottu> Launchpad bug 1738046 in system-config-kickstart (Ubuntu) "Demote from main / thoughts on removing?" [Undecided,New] https://launchpad.net/bugs/1738046
<cjwatson> jbicha: I'd rather not remove it (I still hope to find some time to fix it up a bit), but it can be moved to universe
<jbicha> ok
<kugel> hello. What can I do to draw attention to bug #1732550 ?
<ubottu> bug 1732550 in glibc (Ubuntu) "linux ttyname{_r}: Don't bail prematurely [BZ #22145]" [Undecided,New] https://launchpad.net/bugs/1732550
#ubuntu-devel 2018-01-23
<JonelethIrenicus> who should I tell about a file that needs to be modified in order for the nvidia binary drivers to work properly with ubuntu kernels on 16.04
<sarnold> ubuntu-bug is probably the best bet
<sarnold> keeping in mind that the various kernel fixes broke out-of-tree modules in many cases, and perhaps teh fix is already available in newer packages
<JonelethIrenicus> im not sure but every time i get a kernel update i have to modify an include file and rebuild
<sarnold> JonelethIrenicus: oh? which file? what modification? that doesn't sound right
<sarnold> I had the impression it mostly Just Worked for nvidia users most of the time, I wonder if there's something funny with your config?
<JonelethIrenicus> sarnold: https://devtalk.nvidia.com/default/topic/1028016/linux/patch-for-compiling-v384-98-modules-with-linux-v4-14-9-/post/5233427/
<JonelethIrenicus> just have to add an addtional include
<JonelethIrenicus> basically
<TJ-> The nvidia-340 dkms fails to build with 4.4.0-112 as well
<sarnold> the recent changelogs https://launchpad.net/ubuntu/+source/nvidia-graphics-drivers-384/+changelog have "Drop buildfix_kernel_4.14.patch.
<sarnold> I'd expect that if the patch was brought upstream ..
<TJ-> I just did a build to check and it failed with "error: implicit declaration of function âtimer_setupâ" - the fix is in the graphics-drivers PPA but not in 'restricted'  https://paste.ubuntu.com/26441566/
<JonelethIrenicus> im using the nvidia drivers directly from nvidia's website
<FourDollars> Hi, could anyone help me to nominate https://bugs.launchpad.net/oem-priority/+bug/1713002 for xenial series?
<ubottu> Launchpad bug 1713002 in OEM Priority Project xenial "oem-config-gtk crashed when using some UTF-8 based languages" [Critical,Confirmed]
<tsimonq2> For src:ubiquity, right?
<FourDollars> yes
<tsimonq2> Needs a Core Developer (and I'm not one :) )
<FourDollars> :-(
<tsimonq2> They're around somewhere...
* wgrant changed the topic of #ubuntu-devel to: Launchpad build farm capacity limited | Artful Released + taken down LP#1734147 | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of trusty-artful | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots:
<juliank> cjwatson: strace is FTBFS only on armhf because it starts seeking on fd 3 in a test. It builds fine in Debian. Do you know if the builder do anything weird that could explain that? The program being executed as part of the test only contains a single llseek call for -1
<juliank> If anyone else has an idea, the program is http://paste.ubuntu.com/26443755/ - just a simple syscall
<juliank> build log at https://launchpadlibrarian.net/354250672/buildlog_ubuntu-bionic-armhf.strace_4.19-1ubuntu1_BUILDING.txt.gz
<juliank> It expects one syscall:  _llseek(-1, -374081421428539665, 0xffba69c8, SEEK_SET) = -1 EBADF (Bad file descriptor)
<juliank> but it also gets
<juliank> +_llseek(3, 944340, [944340], SEEK_SET)  = 0
<juliank> +_llseek(3, 937564, [937564], SEEK_SET)  = 0
 * juliank thought maybe something is preloaded, some weird libc module thing,  or something
<cjwatson> We certainly have no preloads.
<cjwatson> It's possible that fd setup is slightly different or something.  Does the test ensure that fds it thinks should be closed are actually closed before it starts?
<juliank> I don't think so.
<juliank> But there'd also have to be code doing the seeks on fd 3
<cjwatson> That is not us.
<juliank> I guess I'll run it in a PPA again but let it log all syscalls
<cjwatson> I don't believe Debian is running armhf builds on arm64 kernels (there might be some trace in the log that lets you check this), so maybe libc does something slightly different in that case.
<cjwatson> To my mind that would be the most likely cause.
<juliank> shit
<juliank> I uploaded the PPA test to proposed
<juliank> Oh well, it's guaranteed to fail anyway
<juliank> (I retyped the dput and forgot to specify the ppa)
<juliank> +openat(AT_FDCWD, "/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
<juliank> +read(3, "\177ELF\1\1\1\3\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\331k\1\0004\0\0\0"..., 512) = 512
<juliank> +_llseek(3, 944340, [944340], SEEK_SET)  = 0
<juliank> ugh
<juliank> it's seeking in the library
<juliank> Something to fix and forward upstream, awesome
<cpaelzer> lyarwood: I took a look at your bug and triaged it further
<cpaelzer> lyarwood: I'm subscribed for any further discussion on it
<lyarwood> cpaelzer: ack thanks, FWIW I was wrong, the package isn't from UCA, it appears to be the default Xenial version of libvirt AFAIK. Just writing up a reproducer now.
<rbalint> ppisati, ogra_, manjo (or anyone interested in and having armhf/arm64 board): i've prepared a merge of flash-kernel but i can't test it myself lacking the hw
<cpaelzer> ok, looking forward to look at it then
<cpaelzer> thanks lyarwood
<rbalint> could someone please test it on an armhf/arm64 system? LP: #1743771
<ubottu> Launchpad bug 1743771 in flash-kernel (Ubuntu) "Please merge flash-kernel (main) 3.90 from Debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/1743771
<ogra_> rbalint, and i dont have most of the HW the normal distro supports anymore ...
<rbalint> ogra_: ok, worst case i'll just upload it to proposed in a few days
<ogra_> i could perhaps test beaglebne black and pi2, but thats it (and i'm sure ppisati will do that anyway)
<rbalint> ogra_: that would be nice, i'm not looking for full regression on supported systems, just a single run on one
<juliank> cjwatson: got it :)
<juliank> ogra_: did your ac100 break too?
<juliank> :D
<cjwatson> juliank: great
<ogra_> haha, no idea, i havent booted it in several years (it is somewhere in a box in the basement)
<juliank> oh the times spent on that thing.
<juliank> Now I only have to wait for my about 30 uploads to migrate :)
<lyarwood> cpaelzer: updated, so as I think you have already pointed out this build is actually from the Ocata UCA, apologies about that, I was just confused by the state of an old test instance I was using :)
<cpaelzer> lyarwood: never mind, all that helps to clarify is a step in the right direction
<cpaelzer> just need to clear my brains cache before looking on it again
<cpaelzer> lyarwood: thanks for the details
<lyarwood> cpaelzer: np
<cpaelzer> lyarwood: interesting that it really is gone in 3.6 (artful / pike)
<cpaelzer> lyarwood: I remember we had odd issues with gnutls in zesty, but eventually resolved before release
<cpaelzer> I wonder if this might be a strange leftover of this
<cpaelzer> coreycb: ^^ as you are on the bug
<coreycb> cpaelzer: lyarwood: also worth noting that libvirt in the ocata uca is using gnutls from xenial
<coreycb> cpaelzer: lyarwood: well, libvirt in pike uca is also using gnutls from xenial
<cpaelzer> yep
<cpaelzer> coreycb: there are good repro steps added
<cpaelzer> coreycb: if you have ddebs for UCA you mgiht consider stepping through it
<cpaelzer> if it really fails on the suggested code section
<cpaelzer> lyarwood: was that code snippet found by review or by debugging with gdb?
<lyarwood> cpaelzer: review
<cpaelzer> tks
<cpaelzer> coreycb: so a real debug session might help to verify the theory
<cpaelzer> I don't see a much bette rstep forward
<cpaelzer> do I miss one in this case
<cpaelzer> ?
<coreycb> lyarwood: cpaelzer: i wonder if QEMU_CAPS_OBJECT_SECRET is not available
<juliank> Something is wrong with the gsequencer autopkgtest: dpkg-buildpackage fails due to missing fakeroot
<juliank> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/g/gsequencer/20180123_132702_56441@/log.gz
<juliank> (and this test is being triggered by fakeroot)
<Laney> juliank: https://tracker.debian.org/news/893466
<juliank> ah, it did run them again 1.1.4-1
<juliank> all these uploads will be a mess to sort out :)
<coreycb> lyarwood: cpaelzer: ok found a difference between the artful/zesty packages. artful has:  configure:#define HAVE_GNUTLS_CIPHER_ENCRYPT 1
<cpaelzer> interesting
<cpaelzer> coreycb: is that in the resulting config.h or where is that?
<coreycb> cpaelzer: that's just in the package from pull-lp-source
<cpaelzer> came in with 3.0.0-rc1
<cpaelzer> coreycb: the config structure of the m4 files was changed
<cpaelzer> not sure this all applies to 2.5
<cpaelzer> ha
<coreycb> cpaelzer: ok. i'm cloning from anonscm but it's taking a bit. think it's not  backportable to 2.5?
<cpaelzer> I think I found it coreycb
<cpaelzer> it is backportable semantically
<cpaelzer> let me work something out for your to test
<coreycb> cpaelzer: ok, thanks cpaelzer
<juliank> Can we turn off the stuck in proposed messages for a fww days?
<juliank> I did like 30 uploads and of course they're all stuck in proposed
<cpaelzer> coreycb: lyarwood: updated the bug
<juliank> Maybe like turn them off until Monday and everything caught up?
<cpaelzer> coreycb: added to links that should be your fix
<cpaelzer> tried to apply to latest zesty, looks good
<lyarwood> cpaelzer: cool thanks! :)
<cpaelzer> I hope it works as expected
<cpaelzer> and if it does keep the good feeling for the next openstack-rant-explosion on our libvirt/qemu :-)
<seb128> leosilva, hey, bug #1744855 claims to be a regression from your security update, could you have a look?
<ubottu> bug 1744855 in transmission (Ubuntu) "Upgrade to 2.84-3ubuntu3.1 breaks remote access (webui)" [Undecided,New] https://launchpad.net/bugs/1744855
<leosilva> seb128: tks, let me check.
<seb128> leosilva, thanks
<nacc> slangasek: i'm sure it's been discussed by the AAs separately, but I would like to point out that hte archive removal of zesty has really shown how many people running non-LTS should not be (or don't get announce e-mails) and also (I think) shows how the yakkety non-removal gave them all a false sense of security in their OS.
<nacc> between 10-15 people a day in #ubuntu (which I'm using a metric) complaining of the 404
<rbasak> Precise is presumably not removed either.
<nacc> true, but ESM makes that wonky, I assumed :)
<nacc> I'm less fussed about LTS, because there's a bit of a good story there
<nacc> it seemed like non-LTS were not removed promptly in the past, but now they are, and that led to confused/angry users
<nacc> totally their fault, admittedly, but it seems like something we should improve on
 * rbasak wonders if there's anything in the motd possible via distro-info-data.
<rbasak> Though desktop users may well never see that.
<nacc> rbasak: there's a bug open to improve it, iirc
<nacc> just trying to push on its priority
<nacc> :)
<TJ-> I've been looking at it... my idea is to teach update-manager to read an EOLdate: field in the changelogs.u.c/meta-release files and then we can trigger early warnings
<sarnold> TJ-: doesn't that already exist?
<sarnold> TJ-: .. we just don't use it, because we didn't use it last release, so there's no benefit to using it this release. goto 10.
<sarnold> TJ-: oh never mind me. sigh. sorry
<TJ-> no, there's no EOLdate in meta-release
<slangasek> nacc: what improvement do you have in mind, wrt non-LTS removals?
<nacc> slangasek: i'm not 100%; is there a policy doc as to when the archives get moved to old-releases?
<nacc> slangasek: that might be sufficient, to have it clearly stated in the release notes
<nacc> slangasek: several of the users have been reporting they were not bitten by this on the y -> z transition, but have been by the z -> aa transition
<slangasek> nacc: right, I think the lack of removal of yakkety was a complete oversight; maybe if we had just done that timely, users would be less likely to be upset?
<nacc> slangasek: yeah that is probably true
<nacc> slangasek: i guess I wasn't sure if that was oversight, or if it was somethingn that was likely to happen again (even if accidentally) in the future
<nacc> or if it become part of the EOL process, maybe?
<slangasek> nacc: policy doc> there's https://wiki.ubuntu.com/EndOfLifeProcess , which has always said that we remove it from archive.u.c at EOL
<nacc> slangasek: ah that's what i was looking for!
<nacc> slangasek: maybe the release notes page(s) can link to the same, or a cleaned up version of that (more user friedly, i mean)
<nacc> https://wiki.ubuntu.com/ZestyZapus/ReleaseNotes  Support lifespan section
<slangasek> nacc: I don't feel strongly about trying to guard against this in the release notes, I think users who are upset that the release went away at end-of-life are unlikely to have read the release notes and/or unlikely to care about further information about what happens at EOL
<slangasek> nacc: but it's a wiki and I don't mind it being edited to include such a link
<nacc> slangasek: 100% agree, just want to point them to something
<jbicha> maybe some people assumed they had until the end of January before EOL
<sarnold> maybe they usually waited for a week or two after one release EOLs before upgrading to the next, to let other people debug the transition
<jbicha> and some people were just really hesitant to upgrade to 17.10, although even before 17.04's release, it was widely reported that 17.10 would switch to GNOME
<jbicha> I think part of the EOL problem is that Ubuntu developers don't tend to see the issues since we don't usually run Ubuntu versions that old!
<slangasek> aiui the only remaining "issues" are that you'll get an error about not finding the repository, but that you will still be prompted to update to the new release
<sarnold> will do-release-update complain if they missed the last N weeks of updates?
<slangasek> it shouldn't, considering those updates are no longer available ;)
<sarnold> right :)
<sarnold> I'm glad it fails on the happier side of that fence
<TJ-> The guides tell people to alter sources.list and replace the archive.ubuntu with old-releases.ubuntu
<TJ-> then an apt-get update/dist-upgrade followed by do-release-upgrade
<slangasek> do-release-upgrade itself was fixed some time ago to not care about the current release being missing
<TJ-> hmm, tried in an LXD container and got "Cannot open your terminal '' - please check."
<nacc> TJ-: you porbably need to run ashell with a controlling tty
<nacc> TJ-: in the lxd
<jbicha> slangasek: see LP: #1744722
<ubottu> Launchpad bug 1744722 in ubuntu-release-upgrader (Ubuntu) "Unknown bad source brings up during 'zesty' to 'artful' upgrade and It break the process" [High,Triaged] https://launchpad.net/bugs/1744722
<TJ-> nacc: I wrapped it in 'script' which provides pts
<nacc> TJ-: oh ok
<nacc> Laney: can we allow request.cgi again, or is there any ETA on that for autopkgtest?
#ubuntu-devel 2018-01-24
<JonelethIrenicus> I have some remaining library I built myself and had to manually delete it from my system, but for some reason I think it still may be linked how can i get rid of it?
<cpaelzer> ahasenack: thanks for spotting my wrong targetting of released on the spamassassin SRU
<cpaelzer> I really think it is artful only
<ricotz> chrisccoulson, hi, please push your thunderbird branches
<juliank> rbasak, cpaelzer: I think my multipath-tools upload is almost ready, I dropped the uds importer merge because I was waiting for some other stuff. Can I open a new merge so one of you importer guys can merge that upload before the importer runs so we keep the log?
 * juliank does not want to lose that, there's quite a bit of stuff in there :)
<cpaelzer> juliank: yeah
<cpaelzer> juliank: so you don't want an actual review now, but instead just to save your history ?
<cpaelzer> did I get that right?
<juliank> Hey, if you want to look at it, that's fine too. I'm just cleaning this up a bit now, and will push that out in a few mins.
<cpaelzer> ok, ping me once it is up
<cpaelzer> and yes, I can do the git magic to let the history be retained
<cpaelzer> juliank: looking forward to the review - have you run tests on actual MP HW against the new code?
<cpaelzer> if not would you mind providing a ppa along the MP so that I can do some (minor) tests?
<juliank> cpaelzer: No, I don't have any.
<juliank> Sure, I can do that
<rbasak> I'm not sure I follow, but cpaelzer seems to have understood
<cpaelzer> great, post the ppa in the MP comment
<cpaelzer> juliank: and mid term get together with xnox and jfh to get you a z/VM guest with a bunch of scsi disks via multipath
<cpaelzer> or an lpar if you have a spare one left in the team
<juliank> I have no idea how to actually build a source package with git-ubuntu
<juliank> I can manually run debuild with the correct options, but the integrations seems broken
<juliank> $ git ubuntu build-source
<juliank> 01/24/2018 11:01:54 - ERROR:Unable to automatically determine importer branch: Multiple candidate branches found and they do not target the same series: pkg/debian/sid, pkg/debian/buster. Please pass --target-branch.
<cpaelzer> git ubuntu build-source --verbose --sign --for-merge
<juliank> If I do pass a --target-branch argument it just says it does not understand --target-branch
<cpaelzer> I've never seen the target-banch disambiguation on a build-source so far
<juliank> Oh well, I'll just use debuild :)
<cpaelzer> rbasak: ^^ did you?
<cpaelzer> well let us find the issue and fix it :-)
<cpaelzer> juliank: when you have pushed your MP I can try on it
<cpaelzer> if I can reproduce I can file the issue as needed
<juliank> cpaelzer: https://code.launchpad.net/~juliank/ubuntu/+source/multipath-tools/+git/multipath-tools/+merge/336526
<rbasak> nacc: ^
<juliank> cpaelzer: One thing to note is that I rebased on top of my for-debian branch, essentially, so the commit order might be a bit confusing :)
<juliank> Hopefully that'll get merged soon.
<juliank> Or rather, I'll just NMU it in delayed/7 or something
<cpaelzer> soon able to take a look
<cpaelzer> and be confused then :-)
<cpaelzer> rbasak: could you check logs why ipxe 1.0.0+git-20161027.b991c67+really20150424.a25a16d-1ubuntu2 seems not to be imported?
<cpaelzer> zesty-devel is also behind proposed, seems not recently imported at al
<cpaelzer> but is in the whitelist
<rbasak> I'm not sure the logs are working currently :(
<rbasak> I didn't find any up-to-date ones
<cpaelzer> ok, I'll kick a local import over lunchtime
<cpaelzer> maybe it pops up something
<rbasak> nacc: ^
<tseliot> sil2100: hi, are you ok with the workaround in LP: #1728547 ?
<ubottu> Launchpad bug 1728547 in OEM Priority Project "SRU: Add support for keeping the dGPU on in power saving mode" [Medium,Triaged] https://launchpad.net/bugs/1728547
<sil2100> tseliot: oh, didn't see that, I'll take a look at it after lunch but from the comment it sounds okayish
<tseliot> sil2100: ok, thanks
<ahasenack> juliank: hi, saw in irc backlog that you were uploading multipath-tools, is that still the case?
<ahasenack> request.cgi in autopkgtests is broken? I get an internal server error
<cpaelzer> ahasenack: the MP is up of juliank
<cpaelzer> I was just about to check if I can repro his build error on it
<cpaelzer> rbasak: ipxe imported fine, new versions there now
<cpaelzer> rbasak: but almost everything is a forced update now
<cpaelzer> rbasak: did you commit the import breaking changes to beta already?
<cpaelzer> (you or nacc)
<ahasenack> I was going to mention an ibm bug
<ahasenack> https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1711749
<ubottu> Launchpad bug 1711749 in multipath-tools (Ubuntu) "[18.04] multipath-tools: Backport 2 patches to Ubuntu 18.04 (NVMe disks are detected as multipath disks)" [Medium,Triaged]
<cpaelzer> ahasenack: the multipath-tools buld of juliank fails with the equivs package just as samba
<ahasenack> see if the patches they mention are in this upload, presumably to bionic
<cpaelzer> it must be something generic
<ahasenack> cpaelzer: ah, g-u
<ahasenack> cpaelzer: ok, I have something for that maybe
<ahasenack> let me see your paste again, just a sec
<cpaelzer> ahasenack: interesting
<ahasenack> cpaelzer: line 24: https://paste.ubuntu.com/26449720/
<cpaelzer> on the multiapth-build it works on try 3/6
<ahasenack> there is no fix-up patch to create
<ahasenack> unless that returns empty and is just how the code checks for it
<rbasak> cpaelzer: I've not touched the importer since nacc got back. I don't think we've bumped beta either.
<rbasak> I should sync with nacc on this.
<ahasenack> I noticed that because my build of your spamassassin backtraced with unicodedecode error near that area
<ahasenack> I wonder if it's related
<cpaelzer> weird - it seems reproducible for samba, but on multipath works on the integrated retry
<cpaelzer> nacc: could you as a clean slate approach grab both recent merges and run build-source on them?
<ahasenack> it worked for my clamav build
<ahasenack> cpaelzer: doesn't line 61 confirm that it finally installed equivs?
<ahasenack> 01/24/2018 08:59:11 - DEBUG:Executing: /snap/bin/lxc exec star-eagle -- apt-get install -y devscripts equivs sudo
<ahasenack> I think in your case it was just a missing --for-merge, now?
<ahasenack> because samba 4.7.4 is not yet in ubuntu, just in debian
<ahasenack> 01/24/2018 09:00:21 - ERROR:stderr: error: open /var/lib/snapd/hostfs/tmp/review/samba_4.7.4+dfsg.orig.tar.gz: no such file or directory
<cpaelzer> didn't work with or without
<cpaelzer> but I agree that the equivs might be a red herring
<cpaelzer> there also is the " Multiple candidate branches found" that juliank reported
<cpaelzer> I see that for the samba build as well
<cpaelzer> line 26
<ahasenack> hm, that path does look odd
<ahasenack> it's looking in /var/lib/snapd
<ahasenack> that might be a recent change in the snap indeed, there was some shuffling around with the tmp dir where the build happens
<cpaelzer> TL;DR several things are odd - @ nacc if you could (once around) try building the recent samba and multipath merge - and not related to that see if you'd see why ipxe wasn't continued to be imported
<cpaelzer> juliank: now I found what you meant with the commit order :-)
<ahasenack> cpaelzer: where is this multipath-tools mp, out of curiosity?
<cpaelzer> https://code.launchpad.net/~juliank/ubuntu/+source/multipath-tools/+git/multipath-tools/+merge/336526
<cpaelzer> I already mentioned the bug you pinged above
<cpaelzer> but I have much more and write up the answer atm
<ahasenack> it's not listed in https://code.launchpad.net/~usd-import-team/+activereviews
<ahasenack> let me check against what the mp is
<cpaelzer> ~10 minutes maybe to submit to juliank
<cpaelzer> against me :-)
<ahasenack> that's a big delta
<cpaelzer> oh yeah - I did th elast few merges
<cpaelzer> with cyphermox
<cpaelzer> I knew what I was up to :-)
<cpaelzer> juliank: review done, some cleanups requested
<cpaelzer> juliank: if you want to overrule my review and upload right away let me know so I can make it known to at least retain history
<juliank> damn, I missed notifications
<juliank> cpaelzer: Thanks for the review, I'll fix that stuff first
<juliank> Totally forgot the patch headers, ugh.
<cpaelzer> well I spotted one of them which I added - so you are in (?good?) company :-)
<juliank> cpaelzer: I'm not sure why git format-patch adds the weird date from 2001.
<juliank> but that's what it does...
<cjwatson> it's a fixed magic timestamp used by git format-patch
<cjwatson> documented in git-format-patch(1)
<juliank> ah
<cjwatson> not what I'd have gone for but there you go ...
<juliank> cjwatson is like an encyclopedia :D
<cpaelzer> well if it is magic then keep it juliank
<cpaelzer> I didn't know it was a special unicorn :-)
<Unit193> I use format patch all the time, quite useful for IRC and pastebins.
<cpaelzer> I guess we all do, but who of us have realized that the date after the hash is a magic thing
<cjwatson> I do wonder why it's that particular date rather than 681200 seconds earlier
<cjwatson> no explanation in git history AFAICS
<cpaelzer> xnox: so many other things of the chrony change are moving fast (I didn't expect it to go that fast actually), but that makes me ask if you tnhk you'll have some time for bug 1744328?
<ubottu> bug 1744328 in nss (Ubuntu) "libfreebl3.so should be public, not in the nss subdir" [Undecided,New] https://launchpad.net/bugs/1744328
<cjwatson> https://stackoverflow.com/questions/15790120/what-is-the-first-line-of-git-format-patch-output
<ricotz> chrisccoulson, you can find tb 52.6 tarball here https://launchpad.net/~mozillateam/+archive/ubuntu/ppa/+sourcepub/8739132/+listing-archive-extra
<jibel> could someone review the patch attached to bug 1744722
<ubottu> bug 1744722 in ubuntu-release-upgrader (Ubuntu) "Unknown bad source brings up during 'zesty' to 'artful' upgrade and It break the process" [Critical,In progress] https://launchpad.net/bugs/1744722
<jibel> ?
<nacc> juliank: cpaelzer: that is due to an issue with the fetch_orig logic, i believe. Feel free to open a bug (--target-branch).
<juliank> jibel: I can only say that it sounds ok, but I don't have any close insight into that part
<juliank> jibel: If I understand things correctly we could just upload it to bionic and see if upgrades from zesty to it break
<juliank> I mean, the worst thing that could happen is a few updates to bionic failing for a day or so
<nacc> rbasak: pign
<nacc> *ping, rather :)
<nacc> cpaelzer: ahasenack: samba will onnly build with -propsoed enabled, afaict?
<ahasenack> nacc: yes, it needs libldb that is in proposed
<nacc> we don't currently expose that option (you could it manually)
<nacc> or pass the correct flags to dpkg-buildpackage (-- -d)
<ahasenack> which option?
<nacc> ahasenack: is there something else i['m missing in the ping on that?
<ahasenack> I think the error was the file-not-found when fetching the orig file, was it not?
<nacc> ahasenack: what file not found?
<ahasenack> the orig tarball
<nacc> ahasenack: you need to use edge to work aroudn that
<ahasenack> let me scroll up
<nacc> ahasenack: i got too many pings to follow, and no bugs to read, so it's a bit tricky :)
<ahasenack> <cpaelzer> ahasenack: the multipath-tools buld of juliank fails with the equivs package just as samba
<ahasenack> did you also check multipath-tools?
<rbasak> nacc: pong
<nacc> multipath-tools fails for a different reason
<ahasenack> https://code.launchpad.net/~juliank/ubuntu/+source/multipath-tools/+git/multipath-tools/+merge/336526
<nacc> rbasak: do you have time to sync still today? or want to put something on the cal?
<rbasak> nacc: can sync now
<rbasak> standup HO?
<nacc> rbasak: ok, joining yep
<nacc> ahasenack: oh you could build samba with a lxd profile probably
<ahasenack> nacc: I wasn't trying to, this was cpaelzer reporting to me a problem he saw when he tried it
<ahasenack> which didn't seem to come from the missing build-dep
<nacc> cpaelzer: juliank: filed LP: #1745213 for the extraneous warning
<ubottu> Launchpad bug 1745213 in usd-importer "build: drop usage of derive_target_branch" [Undecided,New] https://launchpad.net/bugs/1745213
<nacc> warning(s)
<nacc> cpaelzer: juliank: the multipath-toosl merge builds if i pass --for-merge
<juliank> nacc: strange
<nacc> (well, it's working now, let me see if it finishes)
<nacc> juliank: where did it fail for you?
<juliank> exporting a package
<nacc> juliank: oh were you using the edge snap?
<nacc> juliank: or stable?
<juliank> installed:   0.2.2+git11.9fa9149 (291) 110MB classic
<juliank> stable apparently
<nacc> juliank: ah ok, we just landed the orig tarball fix to edge yesterday
<juliank> that one looks old
<nacc> i ened to do a release (i was out for > month last year)
 * juliank switches to edge
<nacc> juliank: yeah it works with edge (just finnished)
<juliank> I'll be fixing the needs fixing stuff tomorrow I think. I have to rebase the patches for debian and then on top of that. It's a bit annoying right now, but hopefully this gets merged there eventually.
<juliank> And I test both states, the for-debian one and the one supposed for merging in autopkgtest. Doing it right :)
<juliank> The worst part is that these are two separate git repos :)
<nacc> heh
<juliank> LocutusOfBorg: you on curl merge? Seems trivial. If not, I'd be happy to.
<juliank> It's silly merge season!
<juliank> Except well, it's not silly
<juliank> And it got so much easier now that the tarballs grab-merge fetches do not have partially applied patches in them
<jbicha> nacc: could you try importing moon-buggy into git-ubuntu? I'm curious to see how it handles the brokenness from Debian bug 887740
<ubottu> Debian bug 887740 in src:moon-buggy "moon-buggy: Please bump the Debian part of the version number" [Normal,Open] http://bugs.debian.org/887740
<jbicha> there's a new reply on the bug that hasn't been posted yet where he says it's only a LP bug that the pkgs is not syncable
<smoser> does every upload of grub2 require a grub2-signed upload ?
<LocutusOfBorg> juliank, feel free to steal :)
<juliank> :)
<juliank> I wonder if we should have build profile ubuntu for stuff like curl
<juliank> libssh2-1-dev <!ubuntu>
<juliank> build-depends would allow us to sync that stuff
<juliank> infinity: ^
 * juliank thinks curl has a weirfd test suite
<juliank> but still better than (IIRC) coreutils
<juliank> that one fails if you have a bind mount on your system
<Unit193> juliank: Last time I thought that'd be a cool idea, someone said "Build profiles aren't gentoo use flags" (which, is fun because at the time I'd never used gentoo. :P )
<infinity> juliank: See above.
<juliank> They sort of are
<infinity> juliank: The default behaviour of buildds should be to build without profiles, it's mind-numbingly confusing if we make that not true.
<Unit193> I believe I had asked either in terms of the indicators specifically, or whether PPAs could parse the *.changes file and build with the appropriate profile.
<juliank> infinity: Well, allright, I just thought it would save some work :D
<Unit193> (And someone = cjw of course. :P )
<Unit193> juliank: Yes, as far as I could tell the only way to do it was hacks that'd have #
<Unit193> $universe package | package-in-main-but-not-installed, but now you can do build-depends inj uni.
<infinity> juliank: I don't think it actually does save work.  If we built Ubuntu with a different profile, people would take advantage of that to fork packaging more often (and, sure, push that fork into more confusing rules/control in Debian, but ew) instead of either communicating with Debian about if certain deps are needed or MIRing where appropriate.
<infinity> juliank: libssh2 is a bit of an outlier there (and it may also be time to revisit if we still hate it)
<juliank> It would be interesting to see curl with libssh-2 and how that works
<juliank> I tried to use curl for dput sftp but obviously failed since we have no ssh support.
<Unit193> Yes the biggest issue for depends is annoying main packages, can say.  And while syncing would certainly be a nice gain, I do agree that having "hidden delta", that is where the version is the same but the build results aren't, isn't really my favorite idea.
<juliank> curl tests are almost complete!!!
<juliank> oh crap, it's doing the third variant now
<juliank> totally forgot about nss
<juliank> why do we spent 15 or 20 or 30 minutes running tests for all three variants and ignore the result. seems a bit pointless.
<juliank> but oh well, not going to improve that today
<juliank> merged
<juliank> I still have what, 25 merges or so stuck in autopkgtests. oh the fun.
 * juliank did not count, only guessed :)
 * juliank did 40 uploads in 2 weeks and 3 days. that's insane.
<Unit193> juliank: Merge dput?
<juliank> Unit193: dput 1.0.1 is in -proposed
<Unit193> Woah, good job.
<cjwatson> infinity: I'm not opposed to maybe having a way to configure PPAs to build with a profile (could be handy for bootstrapping, say), but I agree that it would be best not to build Ubuntu proper with one.
<cjwatson> Probably not even that hard these days; just needs changes at three or four different levels of the stack.
#ubuntu-devel 2018-01-25
<smoser> are grub2-signed uploads required for each grub2 upload ?
<NewGnuGuy> Who has the authority to move a package from multiverse to universe? https://bugs.launchpad.net/ubuntu/+source/redeclipse/+bug/1740979
<ubottu> Launchpad bug 1740979 in redeclipse-data (Ubuntu) "redeclipse should be in universe, not multiverse" [Undecided,Confirmed]
<NewGnuGuy> I would like to see this miscategorization be fixed in time for the Bionic release, but I have no idea who can make that happen.
<Unit193> !info redeclipse-data unstable
<ubottu> redeclipse-data (source: redeclipse-data): data for the Red Eclipse FPS game. In component main, is optional. Version 1.5.8-1 (unstable), package size 842212 kB, installed size 959994 kB
<infinity> smoser: Yes.
<infinity> NewGnuGuy: Done.
<NewGnuGuy> infinity: Sweet! Thanks :-)
<LocutusOfBorg> juliank, you know what is funny? your curl merge could have been a sync:p
<LocutusOfBorg> curl 7.58.0-2: Explicitly enable libssh2 support which got silently disabled in the previous update
<LocutusOfBorg> LOL
<juliank> LocutusOfBorg: Well, the build-depends were there.
<LocutusOfBorg> juliank, you can build-depend from stuff in universe, as long as you don't runtime-dep on it :)
<juliank> oh, yeah, that's true
<LocutusOfBorg> actually a little switch in Debian might make it syncable
<juliank> yup.
<seb128> wgrant, cjwatson, hey, does bug #1745210 sound like something one of you could look at? unsure how work that could be but GNOME has migrated mostly to gitlab now which means we lost bug watches support for the GNOME stack
<ubottu> bug 1745210 in Launchpad itself "Support GNOME GitLab Issues as external bugtracker" [Undecided,New] https://launchpad.net/bugs/1745210
<seb128> willcooke, ^ unsure if that's something you could raise up/get resources allocated for
<cjwatson> seb128: it's probably not a spare-time task; can you get it raised with our management?
<willcooke> I can raise it with Jamie, but easier if we can come to a friendly agreement IMO
<cjwatson> I'm not unfriendly towards it, just don't have quite the kind of casual time available to do a job of that size
<cjwatson> it's a few days, I'd say
<willcooke> kk, I will raise it
<willcooke> thanks
<cjwatson> (given that we've already done GitHub, which is likely similar in structure)
<seb128> cjwatson, willcooke, thanks
<juliank> I get "Package does not exist" error on http://autopkgtest.ubuntu.com/packages/d/dput/bionic/ppc64el
<juliank> excuses says ppc64el: Test in progress (always failed)
<LocutusOfBorg> can a package in main suggest a package in universe?
<juliank> Is that just because we ran no tests yet for dput in bionic on ppc64el?
<juliank> So I think we'll see dput migrate very soon
<cjwatson> LocutusOfBorg: yes
<ahasenack> hi, can someone guide me through what I should do with ocfs2-tools that's stuck in bionic migration due to an upstream bug on s390x?
<ahasenack> http://autopkgtest.ubuntu.com/packages/o/ocfs2-tools/bionic/s390x
<ahasenack> o2image core dumps
<ahasenack> xnox filed https://github.com/markfasheh/ocfs2-tools/issues/22
<ahasenack> last time tests passed, o2image wasn't in them as far as I can tell
<ahasenack> I'm not ready to make the statement "ocfs2-tools does not work on s390x", I'm not familiar with that arch and ocfs2-tools in it
<ahasenack> my upload is a fix for an ftbfs
<ahasenack> xnox is on holidays I think
<juliank> ahasenack: If the test was not in there before, ignore it? I mean, upstream already wrote that it only works on little endian
<ahasenack> you mean I should change the test so that if I'm on s390x, return a fake success?
<ahasenack> afaik autopkgtest can't skip arches
<juliank> Something like that
<juliank> yeah
<juliank> ahasenack: Another alternative would be to remove the 3ubuntu1 merge from proposed and just do the FTBFS fix in there.
<juliank> or I am confused or something :D
<juliank> -2 also failed, but only sometimes
<ahasenack> I'm not the maintainer, I just saw an easy win fixing the ftbfs
<ahasenack> hm
<ahasenack> the green pass was on lxc
<juliank> ahasenack: I'd just ask #ubuntu-release to mark s390x as always failed
<ahasenack> I bet this test wasn't run before
<ahasenack> and now we are in a vm
<juliank> ahasenack: It only did not fail before because yeah
<juliank> before: o2cb                 SKIP Test requires machine-level isolation but testbed does not provide that
<ahasenack> right
<juliank> So yeah get it marked as always-failed, or reset or whatever
<ahasenack> ok
<juliank> cpaelzer: uploaded
<juliank> :D
<juliank> that was a terrible merge.
<juliank> ( https://launchpad.net/ubuntu/+source/multipath-tools/0.7.4-2ubuntu1 )
<juliank> cpaelzer: thanks for reviewing :)
<cpaelzer> juliank: I did the last two, so I was less shocked as a first time visitor to that package :-)
<cpaelzer> thanks for your work on it
<juliank> I sure hope the part I submitted to Debian gets merged. It's completely broken there.
<juliank> cpaelzer: The whole question of the find_multipaths patch thing spawned like a 20-email long dicussion thread on dm-devel (actually 3 threads I think)
<juliank> well, there's a 16 patch long patch series to redefine find_multipath too
 * juliank lets the SUSE and RH people figure out some sanity
<PenguinPerk> Is anyone using Vagrant with Ansible Windows WSL (Windows Subsystem for Linux)?
<LocutusOfBorg> who broke ppa builds?
<LocutusOfBorg> # only call dh_scour for packages in main
<LocutusOfBorg> if grep -q '^Component:[[:space:]]*main' /CurrentlyBuilding 2>/dev/null; then dh_scour -plibghc-th-utilities-prof ; fi
<LocutusOfBorg> ppa is everything in main AFAIR
<LocutusOfBorg> jbicha, I blame YOU :p
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+sourcepub/8740844/+listing-archive-extra
<LocutusOfBorg> :)
<Laney> LocutusOfBorg: probably https://anonscm.debian.org/cgit/collab-maint/scour.git/commit/?id=d3a95f82d4490f1a088c7bcb058b1962c0385e41 no?
<jbicha> I blame pitti :)
<Laney> all this blame
<jbicha> http://people.canonical.com/~ubuntu-archive/component-mismatches.html stopped updating yesterday
<jbicha> hope I didn't break that too ;)
<jbicha> oh never mind
<ahasenack> are ppa builds really broken?
<ahasenack> I uploaded a package to a ppa of mine more than 1h ago and it hasn't started building, and still says "start in 1h"
<Odd_Bloke> ahasenack: Looks like there's a legit queue: https://launchpad.net/builders
<ahasenack> ok, thanks
<caravena> Hello, I'm working with Ubuntu 18.04 + repository "Proposed"
<nacc> caravena: that seems like a bold choice
<nacc> caravena: did you have a question? if support, you want #ubuntu+1
<jibel> slangasek, I proposed a fix for bug 1744722, could someone from foundations review and sponsor it while Brian is on holidays?
<ubottu> bug 1744722 in ubuntu-release-upgrader (Ubuntu) "Unknown bad source brings up during 'zesty' to 'artful' upgrade and It break the process" [Critical,In progress] https://launchpad.net/bugs/1744722
<cjwatson> caravena: where I think "bold" is nacc's polite way to say "that configuration is explicitly recommended against, even for developers"
<caravena> nacc: Ok, Thanks
<nacc> cjwatson: :)
<juliank> jibel: I forgot about this. I could take a closer look at it tomorrow if nobody wants to pick it up today.
<LocutusOfBorg> juliank, I did steal again your curl merge, and uploaded the "syncable approach" one
<juliank> LocutusOfBorg: awesome
<LocutusOfBorg> can you please have a quick look?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/curl/7.58.0-2ubuntu1
<LocutusOfBorg> if you agree, lets forward to debian
 * juliank waits for diff
<LocutusOfBorg> (I did a sync -f of the -2 version, so the autogenerated debdiff is "complete")
 * LocutusOfBorg feels so dirty
 * juliank is only half here atm :)
<LocutusOfBorg> http://launchpadlibrarian.net/354671929/curl_7.58.0-2_7.58.0-2ubuntu1.diff.gz
<juliank> looks ok
<LocutusOfBorg> thanks!
<LocutusOfBorg> the suggests libssh2-dev should be harmless
<LocutusOfBorg> my ppa build log was looking promising
<juliank> yeah
#ubuntu-devel 2018-01-26
<jibel> rbalint, hi, verification of bug 1732185 failed. It still does not work with sudo.
<ubottu> bug 1732185 in update-manager (Ubuntu Artful) "do-release-upgrade crashed with SIGSEGV under wayland" [Critical,Fix committed] https://launchpad.net/bugs/1732185
<juliank> jibel: Ugh, I almost forgot about your ubuntu-release-upgrader MP again.
<jibel> juliank, np
<juliank> I was just about to upload when I remembered
<juliank> well, test suite is failing anyway :D
<juliank> ../DistUpgrade/DistUpgradeFetcherKDE.py:34: 'PyQt5.QtCore.QUrl' imported but unused
<juliank> ../DistUpgrade/DistUpgradeFetcherKDE.py:34: 'PyQt5.QtCore.pyqtSlot' imported but unused
<juliank>                                                           
<juliank> ugh
<juliank> jibel: I'll look at it in a few minutes and include it in the upload if it looks ok
 * juliank just does a few message improvements otherwise
<jibel> juliank, okay, thanks. then i'll prepare the sru
<juliank> jibel: I don't see how you could reasonably prepare an SRU while the other one is failed.
<juliank> I mean sure, you could drop the other one, but do we want that?
<juliank> maybe it's correct though and the update-manager sru failed?
<jibel> juliank, no we don't want that.
 * juliank does not know
<jibel> we can publish update-manager but not ubuntu-release-upgrader. There is a patch missing in the diff.
<juliank> right
<juliank> so you want to update the u-r-u patch for that bug too?
<Caribou> doko: or anyone who can answer, I see that gcc 7.3 which includes retpoline has built for bionic; what are the plans for its availability on the LTS (mostly Xenial) ?
<jibel> juliank, no lets keep these fixes separated.
<cking> cjwatson, do you mind giving fwts a priority boost for amd64 and i386 builds in the https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-unstable-crack/+packages  - we're trying to get fwts out by EOD and it's getting nowhere in the PPA because of the low priority we gave it
<doko> Caribou: for now these are handled by the security team
<Caribou> doko: ah ok. thanks!
<doko> bionic-proposed has these for gcc-7
<Caribou> yep, saw that, hence my question
<juliank> jibel: I thought your MP looked fine and merged it, but it turns out it does break the test suite.
<jibel> juliank, hmm, i'll have a look
<jibel> thanks
<juliank> jibel: failure https://paste.ubuntu.com/26463412/
<cjwatson> cking: done
<cking> cjwatson, thanks! much appreciate
<cking> d
<doko> what did change that ruby now can be demoted to universe?
<coolfish> Hi, what is the (default?) size (RAM/memory) of the autopkgtest VMs. I'm asking, because http://autopkgtest.ubuntu.com/packages/g/ganeti fails for bionic/18.04. I've verified, that the autopkgtest completes successful on a 4GB machine (without swap). What should I do to request more memory for the autopkgtest VMs?
<doko> Laney: ^^^
<Laney> coolfish: you get 1536MB ram and 1 CPU by default
<Laney> there's a small list of 'big' packages that ganeti could probably be added to
<juliank> doko: I'll have a look at the lvm2 merge if you don't mind (you're last uploader) [and nacc, you did the last merge]
<juliank> I even use lvm2 so that's a bonus :)
<doko> juliank: feel free to steal any merge ... I'll be back on Monday
<juliank> might just do 2.02.177-0ubuntu1 even
<coolfish> Laney: thanks... ATM I want to make sure, that ganeti moves from proposed to release, just before freeze of 18.04. Is there something I can do to get ganeti in that list of 'big' packages? I'm just a "user", no dev.
<Laney> I did it
<Laney> It should be fine, but there's a big queue so we need to be patient now
<coolfish> Laney: thanks a lot! I'll be patient :-)
<juliank> cjwatson: I accidentally pushed a new filtering feature for MoM html outputs directly to the main branch. I can't really run the script locally. It's http://bazaar.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/revision/307. I can revert that now and do a merge proposal, or we can just see if it works, I don't know.
<juliank> I know the JavaScript html stuff works
<juliank> but I might have messed up the inclusion in Python somewhere
<juliank> ah I did
<juliank> Once that's merged we get query URIs like https://merges.ubuntu.com/main.html?query=foundations-bugs&showProposed=false&showMergeNeeded=true
<juliank> and your browser only shows the non-gray rows that contain foundations-bugs in them
<juliank> (as an example)
<juliank> tracked in https://code.launchpad.net/~juliank/merge-o-matic/javascript-query/+merge/336671 now
<cjwatson> juliank: I'm basically OK with that sort of thing.  (Minor point: you might want to use textwrap.dedent to make the inclusion in Python a bit more readable: I find blocks of triple-quoted text are easier to read when they're indented as a Python block.)
<juliank> I reverted the broken commit for now, and opened the merge proposal so we can fix it :)
<juliank> cjwatson: Good point
<juliank> cjwatson: I just did what the other large block at the bottom did :)
<juliank> cjwatson: ugh, I once again pushed to the wrong location
<juliank> Let's drop them
<juliank> why is it pushing by default there? I don't know
<cjwatson> "bzr info" will tell you more details
<juliank> I did push --remember to my branch now
<juliank> cjwatson: I thought about hiding the filters on browsers without javascript. but I'm not sure if that makes sense - people without JS won't ever discover them
<juliank> In any case, this is going to be a subtle improvement for those of us who already had bookmarklets, and hopefully a huge improvement for others :)
<cjwatson> reviewed
<juliank> cjwatson: Thanks. I adjusted the == => === thing and the empty line now.
<cjwatson> juliank: Merged and deployed, thanks.  You may want to do the same to manual-status.py at some point (which might suggest that this stuff should be in a common file somewhere).
<juliank> cjwatson: I looked at manual but the output is so short that it does not make that much sense there :)
<cjwatson> OK :)
<juliank> I have an announcement written, but I'll wait for the roll out
<juliank> s/roll out/page rebuild/
<arunkumar413> Hi All, I just built opencv. Can you please help me create a deb file
<juliank> arunkumar413: that's not really how it works.
<juliank> oh well
<juliank> cjwatson: I pushed a tiny change in merge-o-matic revision 310 to make the filter case insensitive, would be great if you could roll it out :)
<juliank> now you can search your own name if you like and case does not matter :D
<juliank> I should probably also teach it to search the comment column
<juliank> that's more difficult apparently
<cjwatson> juliank: deployed
<juliank> thanks :)
<nacc> juliank: i've got that merge assigned to me already
<nacc> juliank: if you did it, that's fine
<nacc> juliank: (lvm2)
<juliank> nacc: I already did, yeah.
<nacc> juliank: did you close LP: #1741986
<ubottu> Launchpad bug 1741986 in lvm2 (Ubuntu) "Please merge lvm2 from Debian unstable for lvmlockd and sanlock support" [Wishlist,Confirmed] https://launchpad.net/bugs/1741986
<nacc> juliank: on merges, please check all open bugs :)
<juliank> I forgot :(
<nacc> juliank: np, can you mark that as fix released with the right version in a comment?
<nacc> juliank: i had a few users waiting for that merge to come through from #ubuntu/#ubuntu-server
<juliank> nacc: It's in proposed right now, so it's only committed
<nacc> juliank: or committed and then released when it does :)
<juliank> nacc: I added it to my list
<nacc> juliank: thanks!
<nacc> i'll remove it from mine :)
<juliank> nacc: I'm mostly going by the MoM list to figure out what to merge, so it would be good to add a link to a bug there or a comment so I don't accidentally merge stuff if I don't hear back :)
<juliank> Even if I had not forgotten to look at bug reports, I'd have done that after finishing the merge
<nacc> juliank: sure, i just expect more than 6 hours notice to respond :)
<nacc> (esp. when it's an overnight ping )
<juliank> right.
<nacc> juliank: but it's nont a big deal by any means
<juliank> timezones are hard
<nacc> juliank: yep :)
<sforshee> doko: I think the binutils in bionic-proposed is breaking our arm64 kernel builds - https://launchpadlibrarian.net/354788441/buildlog_ubuntu-bionic-arm64.linux_4.14.0-17.20_BUILDING.txt.gz
<rangergord> Hi. I asked a question over the past 3 days in #ubuntu, but it appears to be too advanced and no one knows of a fix. My issue is described clearly here : https://askubuntu.com/questions/999915/getting-ubuntu-gui-apps-running-under-windows-10s-wsl-looking-better-on-hi-dpi . As a final attempt, I figured I'd come here in case a developer with broader than average understanding of how GUI
<rangergord> apps are drawn can advise me on how I can fix this. If I'm given an answer, I will post it to the communities and we can solve the problem for other users.
<nacc> rangergord: wouldn't that be a question for WSL folks?
<nacc> or in vcxsrv
<nacc> !ubuwin
<ubottu> Windows 10 has a feature called Windows Subsystem for Linux, which allows it to run Ubuntu (and other Linux distro) userspace programs without porting/recompliation. For discussion and support, see #ubuntu-on-windows or ##windows. For installation instructions, see https://msdn.microsoft.com/en-us/commandline/wsl/install_guide
<rangergord> nacc: this is explicitly not supported by WSL. The people using Ubuntu GUI are flying on their own.
<nacc> makes it quite clear it's not really supported by Ubuntu either
<nacc> rangergord: and this channel is for development of ubuntu itself
<rangergord> nacc: sometimes even though something isn't supported, tinkerers can make things work. The fact that people are even running Ubuntu GUI apps is evidence of this. Let's not limit ourselves by what Microsoft wants.
<sarnold> rangergord: maybe try a bug report at https://github.com/Microsoft/WSL/issues ?
<nacc> rangergord: right, so becuase microsoft doesn't support it, you won't ask them; but becuase ubuntu won't support it, you will ask them?
<nacc> seems a wee bit inconsistent
<rangergord> nacc: Ubuntu is a community I'm part of, by helping people in chatrooms, and occasional donations. It's more likely to support the spirit of "you're not supposed to do this, BUT". The lone MS dev on github has stated GUIs are not supported. In this case, I am not asking for developers to code something, but just to give me an idea like "have you tried changing this setting to X, and this
<rangergord> one to Y"
<rangergord> I don't mean to offend you by making it seem like your time is worthless
<rangergord> I'll drop it if that's how you feel
<nacc> rangergord: i have no idea how WSL does GUI, sorry
<rangergord> allright, no worries
<nacc> rangergord: but afaict, this is definitely not the channel for it (if someone disagrees, please correct me)
<juliank> It is not.
<juliank> I'd figure out where the vcxsrv people hide and talk to them
<juliank> that should be more useful.
<juliank> this is likely _not_ related to WSL at all - you'd have the same effect running an X11 app remotely on your vcxsrv
<rangergord> juliank: it's actually like that with all X servers I tried . vcxsrv is considered to be the one with "DPI support", and the most recommended, that's why I only mentioned that one on AskUbuntu. There's already a vcxsrv ticket from 2016 asking them to support hi-DPI, with no reply. It's a single dev that never posts on tickets. (not criticising him/her)
<rangergord> juliank: I tend to think so too, that's why I'm asking in Linux channels. Anyway, it's OK if you have no other suggestions. Have a good evening.
<juliank> You could of course also ask in some xorg channels or something
<juliank> I'm not sure how upstream the win support is
<rangergord> hey, that's a good idea!
 * juliank goes /away now. it's midnight :D
<rangergord> good night
<sunweaver> rangergord: you can try to get hold of mikedep333 on #x2go.
<sunweaver> !x2go
<sunweaver> he maintains VcXsrv for X2Go on Windows and might know something...
<rangergord> cheers sunweaver
<rangergord> before I approach him I'll remove WSL from the equation (to simplify the problem space), by confirming the issue happens with native Ubuntu installs as well
<rangergord> I think mentioning WSL turns people off
<sunweaver> VcXsrv is definitely the best freely available X server these days.
<Unit193> Heh, well ##windows-wsl only has 3 people,so that's not likely to help much.
<sarnold> not so much turns people off as a "huh I forgot that exists"  :)
<rangergord> I'm still not sure why you guys helped MS do it
<sarnold> I assume a healthy mixture of (a) because it can be done (b) because it'd share the ubuntu love with more people   :)
<rangergord> I think to convert some people, getting the GUIs working would be a good idea. Cause the sort of people who will only run bash on Windows, they can already use Ubuntu on their own. In my case it's because it's a gaming computer and my choices are dual booting or using a VM to run Ubuntu. I do the latter, but WSL seems more convenient.
<rangergord> I install Ubuntu natively on casual PCs like my relatives' desktops and such, and on non-gaming laptop
<rangergord> on that note, I hope VFIO / GPU passthrough is an opening to allow Linux to convert Windows gamers
<rangergord> it's still rough right now but maybe 3 years from now?
<wxl> that's pretty much the only hurdle it seems XD
<doko__> sforshee: I didn't see that in my test rebuild: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20171220-binutils-bionic.html
<Unit193> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888531 I think do ko was asking about this the other day.
<ubottu> Debian bug 888531 in release.debian.org "transition: ruby2.5" [Normal,Open]
<Unit193> ...I might be on the wrong network for where he asked though.
#ubuntu-devel 2018-01-27
<doko__> infinity: please merge glibc from unstable, currently blocking the binutils/gcc migration
<juliank> wow, 5 of my uploads migrated to release today. awesome
<acheronuk> juliank: Implement a new sftp method that connects via openssh and then uses paramiko's sftp support.
<acheronuk> but no dependency on paramiko?
<juliank> acheronuk: It's a Suggests
<juliank> acheronuk: Just like python-bzrlib was befor
<juliank> e
<acheronuk> juliank: well, as our CI docker containers use sftp to upload to launchpad, but do not as per standard apt install 'suggests', that brokoe our CI's ability to upload
<acheronuk> our = Kubuntu
<juliank> acheronuk: that's unfortunate, but it's just the way it was before
<acheronuk> juliank: not really, as it didn't fail without paramiko before, now it does
<juliank> acheronuk: You must have manually installed python-bzrlib earlier, now you need to manually install python3-paramiko
<acheronuk> juliank: I'm looking into. just having a maon when things break :P
<juliank> or well, maybe you pulled in bzr and got python-bzrlib by accident
<juliank> in any case, none of the default hosts use sftp so it does not seem wise to Depend on it. Recommends might make more sense, though.
<acheronuk> that is was I was going to suggest (or actually recommend :P)
<juliank> on the other hand since there are no preconfigured hosts with sftp, it does not make it a usual configuration, and thus is better suited to suggests
<acheronuk> juliank: this requires the python3 of python3-paramiko, yes, but only before the python-bzrlib?
<juliank> I can't parse that
<juliank> Basically I did s/python-bzrlib/python3-paramiko/ on debian/control :D
<acheronuk> just I have in deploy_in_container.rake python-paramiko & python-bzrlib already.
<juliank> right, now you need python3-paramiko instead of python-paramiko
<juliank> switching to python3 was the whole point of the merge
<acheronuk> yep, so maybe just need to update that
<acheronuk> right
<juliank> acheronuk: you might want python-paramiko too in case you use bzr
<juliank> depending on your bzr needs :)
<acheronuk> yes, as long as they are both there for the xenial and artful as well, I was going to have both to be on the safe side
<juliank> I have to do some followup on dput, as the error reporting on gpgme is a bit broken.
<juliank> like it shows error messages for success and tracebacks for real failures
<acheronuk> nice
<juliank> but: it works, unsigned and wrong signatures are rejected and correctly signed is accepted
<juliank> and that's an upstream bug.
<jbicha> juliank: dput-ng recommends python-paramiko, not sure if that makes a difference
<juliank> dput only suggests any non-default transport dependencies.
<juliank> I have not heard back from upstream yet on my method :(
<jbicha> or maybe ubuntu-dev-tools could recommend it?
<juliank> a recommends would generally be wrong, though, nothing uses it by default.
<juliank> you have to modify the config file to switch to sftp
<juliank> So I don't see python3-paramiko having to be installed in all but unusual situations
<jbicha> it's one less step (change this config and install this other pkg)
<jbicha> I used to have timeout problems with the default upload method with bigger uploads
<juliank> right
<juliank> I'm not really convinced yet, but I have to take care of other stuff anyway
 * acheronuk tries to update his containers
<juliank> gotta defend my master's thesis on thursday, gotta write a presentation for it
<jbicha> good job, almost done! :)
<acheronuk> juliank: good luck :)
<juliank> thanks. I'll try to do my best
<juliank> :)
<tsimonq2> juliank: I think it would be awesome if MoM could filter by uploader (or by "some" uploaders). Want some code from me, or can you do it? :)
<juliank> tsimonq2: You can filter on any text in the main row
<tsimonq2> OH
<tsimonq2> Hah :)
<juliank> tsimonq2: Excluding the comment, though, that's in an input and does not seem included somehow
<juliank> gotta fix that :/
<juliank> tsimonq2: And since it's a regex you can also search stuff like foo|bar
<tsimonq2> Right
<tsimonq2> Ok
<juliank> it's pretty awesome :D
<tsimonq2> It is :D
<acheronuk> juliank: looks like my container's upload is now fixed :)
<juliank> acheronuk: nice
<acheronuk> but I still think a recommends may be better
<acheronuk> :P
<acheronuk> but not that bothered
<juliank> I mostly want to get it merged upstream and do what ever they want :)
<tsimonq2> juliank: Also, what's up with the retro Ubuntu logo? ;)
<juliank> heh
<juliank> The whole page is a bit retro :)
<acheronuk> I like retro. for the logo, anyway
<tsimonq2> juliank: Hm, I noticed that the search doesn't search comments
<juliank> yeah, I just wrote that above
<juliank> [14:30] <juliank> tsimonq2: Excluding the comment, though, that's in an input and does not seem included somehow
<tsimonq2> Oh
<tsimonq2> Ok
<juliank> I'm matching the row's textContent
<juliank> I guess I also need to find the input in there and match against it's value too
<juliank> tsimonq2: also inputing text in there and hitting enter reloads the page with your filtering gone and you have to go back
<juliank> so it needs some more work on dtaisl
<juliank> *details
<tsimonq2> Right
<juliank> whoa, we got another 10 merges down since I last looked at it 4 hours ago
<juliank> 254 now
<juliank> it was 265 then I thinmk
<juliank> 2018-01-27 09:49 main needs-merge=262
<juliank> hmm ok
<tsimonq2> juliank: Hm, what's up with mousepad?
<tsimonq2> Am I missing something or is MoM not picking up the merge?
<juliank> tsimonq2: It shows a merge on universe.html
<juliank> ah, now I understand
<juliank> odd
<tsimonq2> juliank: Right, meant to say the opposite
<tsimonq2> Yeah
<tsimonq2> I'm the one who wrote that comment on there
<tsimonq2> And it's been like that for a while
<juliank> I'm not expert at this either, I entirely rely on cjwatson for everything :)
<juliank> It also showsa no last uploader
<juliank> probably gotta manually delete the merge or something, I don't know
<juliank> xfdesktop4 LP PTS [xubuntu-bugs]	
<juliank> xfce4-datetime-plugin LP PTS [xubuntu-bugs]	
<juliank> are also affected
<juliank> any row without an uploader name
<juliank> xfce4-session
<juliank> gcc6-cross-ports
<juliank> gcc-5-cross-ports
<juliank> xfwm4
<tsimonq2> Hmph, so there's the pattern.
<juliank> So mostly xubuntu stuff and two gcc things
<tsimonq2> juliank: One more thing... so it says "399 outstanding merges" but that number does not update when filters are applied... it should be I think
<juliank> maybe, I don't know.
<juliank> It was just a quick hack
<juliank> do you also want the graphs created dynamically?
<juliank> Eventually it should be 399 outstanding merges (... hidden)
<juliank> I guess
<tsimonq2> Dynamic graphs would be nice
<tsimonq2> And yeah, hidden works
<juliank> I'm not sure what all the different states actually mean in the graph
<juliank> like needs sync or stuff
<tsimonq2> "needs sync" is likely things that are candidates for being autosynced but haven't done so already
<tsimonq2> Look at the timeline on it, that amount went up after the autosync was turned off for Artful
<juliank> tsimonq2: I can't decide if 252 outstanding merges (XX shown) or 252 outstanding merges (XX hidden) is better
<juliank> But it's going to take some effort anyway to associate these lines with the tables and stuff
<juliank> And I think I should move the filter section below the number of merges and text
<juliank> and of course I need to add a link to the launchpad page for the version in proposed
<jbicha> RAOF: did you see that gnome-do was recently removed from Debian Testing?
<RAOF> jbicha: I did, yes. It needs to be ported to various new things ð
<jbicha> Mono GTK apps in Debian are in rough shape since only a couple use gtk3, the rest use really old stuff :(
<tsimonq2> juliank: hidden is better imho
<RAOF> jbicha: yes, curse them for using stable and perfectly working existing code!
<RAOF> (that, admittedly, doesn't support Wayland, but then again Wayland doesn't support Do either)
<jbicha> GnomeVFS and gconf?
<jbicha> I'm not worried about gtk-sharp2 (at least not for a couple more years), but gnome-sharp2 is pretty old
<RAOF> gconf works fine!
<RAOF> And we've already ported off gnome VFS to gio
#ubuntu-devel 2018-01-28
<jbicha> gconf works mostly (assuming you aren't trying to read desktop settings which switched to gsettings years ago) but is unmaintained
<ogra_> hmm
<ogra_> dpkg -S /lib/crda/pubkeys/ubuntu-devel-discuss@lists.ubuntu.com.key.pub.pem
<ogra_> wireless-regdb: /lib/crda/pubkeys/ubuntu-devel-discuss@lists.ubuntu.com.key.pub.pem
<yellabs-r2> hi there
<yellabs-r2> is libGL.so broken ? or something changed , i use MU editor for micro python programming , it stopped working after update ( 16.04 LTS )
<yellabs-r2> any tips or clue's are welcome
<yellabs-r2> ImportError: /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1: undefined symbol: drmGetDevices2
<yellabs-r2> there are several people that have the same issue, but no solution found yet
<yellabs-r2> if it rings a bell with someone , that would be nice , if not.. i will go around the problem ( not using mu )
<bdrung> cpaelzer, hi. will you merge iproute2 4.14.1-2 to Ubuntu?
<yellabs-r2> undefined symbol: drmGetDevices2
<yellabs-r2> thanks for you time, have a nice day
<NickTux> Hello, can someone point me to the right direction on how to fix this build error ? https://is.gd/H4KYHJ
<valorie> hi folks, searching the CVE db I don't see https://nvd.nist.gov/vuln/detail/CVE-2017-12379 mentioned at all
<ubottu> ClamAV AntiVirus software versions 0.99.2 and prior contain a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition or potentially execute arbitrary code on an affected device. The vulnerability is due to improper input validation checking mechanisms in the message parsing function on an affected system. An unauthenticat... (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12379)
<valorie> what is the proper way to file a bug about this?
<valorie> the KDE sysadmins want to apply the ubuntu fix but are not finding it
<valorie> The requested URL /~ubuntu-security/cve/2017/CVE-2017-12379.html was not found on this server.
<ubottu> ClamAV AntiVirus software versions 0.99.2 and prior contain a vulnerability that could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition or potentially execute arbitrary code on an affected device. The vulnerability is due to improper input validation checking mechanisms in the message parsing function on an affected system. An unauthenticat... (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12379)
#ubuntu-devel 2019-01-21
<valorie> https://twitter.com/kubuntu/status/1087208863147806720
<valorie> RT plz
<rbalint> ginggs, :-\ updating the hint for now then
<ginggs> rbalint: thanks
<ahasenack> tjaalton: hi, 'morning
<ahasenack> tjaalton: are dogtag-pki dep8 tests broken in disco? Should it be hinted?
<tjaalton> ahasenack: dogtag itself is broken.. needs upstream to port it to tls1.3/java11
<ahasenack> it's one of the failures holding back openldap in disco-proposed
<ahasenack> but only failed on amd64, weird
<tjaalton> probably best to remove and blacklist for now
<juliank> jdstrand: Still affected by https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1801338`
<ubottu> Launchpad bug 1801338 in apt (Ubuntu Cosmic) "apt fails to properly handle server-side connection closure" [Undecided,Triaged]
<juliank> ?
<juliank> i have not seen this, nor have i had any other reports, so it might be something unique to your situation
<ahasenack> hi, what's the difference between the "platform" and "ubuntu" repositories here?
<ahasenack> I've seen seed changes done to both
<cjwatson> ahasenack: platform is common to ubuntu and other flavours
<xnox> ahasenack, platform is sourced by all flavours; ubuntu is for the ubuntu flavours; kubuntu is for kubuntu flavours; xubuntu is for xubuntu flavours and so on.
<ahasenack> hm
<ahasenack> thanks
<superm1> bdmurray, regarding that SRU it still hasn't released for testing, can you check?
<superm1> the 1785165 one
<rbasak> cjwatson, xnox: how does that apply to supported-misc-servers in platform?
<rbasak> That's AIUI server "flavour" only?
<cjwatson> Probably historical reasons
<cjwatson> Whether server has had separate seeds has varied over time
<cjwatson> And there may have been fiddly germinate issues which I understood ten years ago but have forgotten
<cjwatson> I don't know of a fundamental reason why those couldn't be moved, but somebody would have to think moderately hard about the various STRUCTURE files
<cjwatson> And whether moving them is actually worth it
<rbasak> Thanks
<rbasak> The background is that ahasenack is reviewing https://code.launchpad.net/~racb/ubuntu-seeds/+git/platform/+merge/361874 for me
<rbasak> Based on that I think the location of the change is acceptable?
<cjwatson> I think so
<ahasenack> why are there sometimes no build logs when the build failed? Like with https://launchpad.net/ubuntu/+source/ruby2.5/2.5.3-3ubuntu3/+build/16305257
<ahasenack> is that still fallout from the incident a while back when files were owned by the incorrect user in the build infrastructure?
<xnox> rbasak, cjwatson - if i recall correctly edubuntu server was a server flavour. and like possibly mythbuntu was inheriting some of server things too. but both are now dead.
<cjwatson> ahasenack: you've retried so I can't see when that build finished
<cjwatson> ahasenack: do you know?
<ahasenack> cjwatson: I haven't
<cjwatson> somebody has
<cjwatson> ahasenack: unexpected out-of-disk on buildd-manager, apparently.  working on it
<ahasenack> cjwatson: ah, cool, thanks for checking
<ahasenack> cjwatson: is that the cause of the build error, or the cause of the missing build log?
<cjwatson> ahasenack: dunno
<ahasenack> k
<ahasenack> cjwatson: can I retry the failed builds already?
<cjwatson> ahasenack: you can do what you like; I have no idea if it'll work yet
<ahasenack> ok
<doko> ahasenack: https://launchpadlibrarian.net/407262137/buildlog_ubuntu-disco-amd64.ruby2.5_2.5.3-3ubuntu3_BUILDING.txt.gz
<doko> this one has a build log
<ahasenack> I'll check
<ahasenack> it built fine in a ppa
<ahasenack> did someone click retry? It's showing green now
<ahasenack> just armhf isn't, which I just retried
 * ahasenack haunted by armhf build or test failures
<cjwatson> ahasenack: given buildd-manager restarting frequently it's possible that it retried itself
<ahasenack> ok
<cjwatson> I have a theory (it could be bunnies)
<ahasenack> or gremlins
<cjwatson> (https://www.youtube.com/watch?v=gISEekxuEgk)
<ahasenack> yay, armhf built
<ahasenack> doko: ruby2.5 built now
<juliank> Is there a chance WiFi (iwlwifi) got a lot more laggy recently?
<juliank> I'm experiencing ping times to my ap from 5 to 200ms
<juliank> hmm early impression is that 4.19 improves things
<juliank> hmm no
<juliank> WiFi only gets 30 MB/s, wired gets 48/50
 * juliank is trying to figure out if the problem is laptop, router, or interference
<valorie> cjwatson: <3 for the youtube link
<TJ-> juliank: we've been getting a lot of reports of problems with various iwlwifi devices recently, including possibly causing complete system lock-ups. It seems to depend on the age of the chipset and whether firmware updates are still being provided for it
<juliank> TJ-: In my case, it's a 8265 / 8275 (rev 78), I don't think there's a lot newer stuff than that?
<juliank> TJ-: I should try 4.15 again and see how WiFi performance is there
<juliank> I was away over christmas, and when I came back new neighbours moved in; so it's either them causing interference, something else causing interference, a bug in the router, or a kernel bug
<TJ-> juliank: I was deep-diving into all this earlier today. I noticed there are some newer firmware files in the linux-firmware repo which might help you.   https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi
<TJ-> juliank: one was "Add new versions of the firmwares for 8000C, 8265." on Dec  16th
<TJ-> juliank: git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
<juliank> TJ-: hmm, those are in disco, and maybe they are the culprit, I should revert to the previous one
<TJ-> juliank: what channels/bandwidth is 'iw' reporting the device using?
<juliank> I just hope 4.19 + older firmware is working
<juliank>         channel 36 (5180 MHz), width: 80 MHz, center1: 5210 MHz
<juliank> hmm no difference
<juliank> well, potentially worse
<juliank> just down to 5 MB/s
<TJ-> juliank: can you poke the AP to move channel?
<juliank> TJ-: I've been on channels 36,40,48,64,100, and 116, and all behaved the same
<TJ-> juliank: You're ahead of my thought process then :)
<juliank> I shall try restarting the router again
<juliank> see what that brings
<TJ-> Have you tried 2.4GHz too, in case there's a difference?
<TJ-> juliank: and as a very unlikely, but possible, scenario... could the u.fl connectors on the wifi device have been dislodged so you've lost use of an antenna? Before you shake your head... I had that happen over the last few months and only figured it out when I got real agitated and opened the device (in this case it was the AP not the PC)!
<juliank> TJ-: no precise ping measurements, and throughput is about 25 Mbit/s
<juliank> TJ-: I think the AP fell down once
<TJ-> juliank: same here!
<TJ-> juliank: do all devices see the same throughput, or just the PC?
<juliank> Phone is generally slower, so can't really compare I think
<juliank> Other laptop is slower too, so
<juliank> Waiting for reboot
<TJ-> juliank: I found it only started to be noticable when the PC was some way away from the AP, particularly behind obstacles
<juliank> I could adb to the TV and see what that does I guess
<TJ-> juliank: but sitting under the AP it seemed relatively fine but, as you've observed, felt slow
<juliank> TJ-: they are like 4 meters away from each other, but even when I was right next to it, it had issues
<juliank> TJ-: phone reports 420 Mbps on fast.com, laptop 220 Mbps
<TJ-> juliank: my 'noticable' was stuttering connections and long delays, sometimes losing and regaining the association
<juliank> second run 340 Mbit/s
<juliank> third run 290
<juliank> laptop starts of at 10 Mbit/s, then increases upto 180
<TJ-> juliank: there's some trace-cmd debugging you can enable to capture firmware interactions. I've currently got it running in the background to try to capture clues if/when this PC hits the lock-up
<juliank> that's with old firmware, with new firmware I get 270 Mbit/s
<juliank> now I got 340
<TJ-> juliank: in case it helps, "Tracing", "...more switches..." command, at https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/debugging
<TJ-> juliank: that's logged ~1GB in the last 10 hours for this PC so it is quite busy
<juliank> I sometimes think I should get a docking station
<juliank> and use cables
<juliank> generally what I see is WiFi topping out at 30 MB/s
<juliank> which is not really bad
<juliank> but it's still a long cry from the 50 I'm paying my ISP for
<juliank> I need to test this somewhere outside without interference, and potentially get lenovo to check / replace parts
<TJ-> juliank: if it's using NetworkManager, what bitrate does 'nmcli dev wifi list' and 'iwlist bitrate' report maximum link rates ?
<cjwatson> valorie: :-) accidentally earwormed myself of course ...
<valorie> can't go wrong with Buffy earworms though!
#ubuntu-devel 2019-01-22
<JanC> for me "buffy" refers to Buffy Sainte-Marie instead  :)
<JanC> but then, there is a link: https://www.youtube.com/watch?v=hP-Gak9vTYU&t=513s
<JanC> Canadian native-American who became somewhat famous in the late 1960s as a folky singer-songwriter/protest-singer; but she often was ahead of her time in some ways, like starting to use computers for music recording & artwork in 1981 or so
<valorie> of course, Buffy Sainte-Marie
<JanC> already used synths in the late 1960s too
<valorie> a voice from my young teen years
<JanC> :)
<JanC> I only know her since the 1990s or so, to be fair
<JanC> early 1990s
<JanC> it's funny that she had this song âThe Vampireâ  :)
<valorie> I always noticed the Canadians
<JanC> on an album from 1969
<valorie> since my mother was raised in Alberta, and my grandfather (father's father) was born and raised in Ontario
<JanC> IIRC she released the first or one of the first music albums that was digitally recorded
<JanC> valorie: I already liked her music/songs when I first heard them in the early 1990s, but got really fascinated when I learned how she was a forerunner with electronic music--and that without obviously sounding like electronic music  :)
<TJ-> When building systemd (locally) how does one disable tests that fail (test-boot-timestamps & test-execute) ?
<cjwatson> ahasenack,doko,sil2100: OK, I think the particular issue that caused failed builds without logs from yesterday should be fixed now.  (Thread-safety bug, as far as I can make out)
<doko> cjwatson: are builds given back for test rebuilds?
<cjwatson> doko: I'm looking for builds that it's possible to retry.  Do you have an example of such a current failure that you haven't retried yet?
<cjwatson> Unfortunately the nature of the failure prevented me from using my usual log-scanning technique for this
<cjwatson> doko: So far my scans didn't find any, but I'm wondering if I made a mistake somewhere
<cjwatson> doko: ?
<doko> cjwatson: I didn't check myself yet. just wanted to ask. and I only want to retry after all were tried at least once. then I can give you the list ...
<cjwatson> doko: OK, well, if you find one that's in a failed-without-logs state, please don't retry it and instead let me know so I can figure out how to fix my scanning code.  I don't need a list as such
<doko> ok
<jdstrand> juliank: you asked if I was still affected by https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1801338 ?
<ubottu> Launchpad bug 1801338 in apt (Ubuntu Cosmic) "apt fails to properly handle server-side connection closure" [Undecided,Triaged]
<juliank> jdstrand: yes
<juliank> it's just you, I have not heard about that from anyone else
<jdstrand> that's weird since I'm not really doing anything all that weird
<jdstrand> let me check my notes to remember the issue
<smoser> xnox or rharper or Odd_Bloke , bug 1812411 should probably receive some attention.
<ubottu> bug 1812411 in cloud-init (Ubuntu) "cloud-init corrupting grub" [Undecided,Confirmed] https://launchpad.net/bugs/1812411
<juliank> TJ-: It does seem there is a regression in 4.18 and 4.19 compared to 4.15 with regards to iwlwifi - I just installed the 4.15 kernel from bionic on disco, and I get full WiFi speed now
<juliank> fast.com reports 450 Mbit/s
<TJ-> juliank: glad you've managed to confirm it
<juliank> with 4.19 it reported 80 Mbit/s
<TJ-> juliank: I've been running 5.0-rc2 and it seems OK there; might be worth testing that too?
<juliank> ah no, I'm on wired
<juliank> ah no, I'm on wired
<TJ-> juliank: hehehe did it catch you out?
<juliank> though I just unplugged wired and got 360 Mbit/s
 * juliank goes try 5.0-rc2
 * juliank has to turn of secure boot first, hope he remembers bios password
<sladen> juliank: 'admin'
<juliank> sladen: nah, it's standard passowrd #2
<juliank> so, in 5.0-rc2 it starts out at 45 MB/s, then slowly reduces to 18 MB/s
<juliank> I think it's network interference or antenna issues in the laptop
<juliank> now it's back up at 40 MB/s
<TJ-> juliank: did you manage to check for loose connectors on that end?
<juliank> I can't take apart a less than 1y old T480s...
<doko> LocutusOfBorg: https://launchpad.net/ubuntu/+source/insighttoolkit4/4.12.2-dfsg1-4ubuntu4 ?
<doko> hmm, just gave that back
<juliank> checking laptop 2
<TJ-> juliank: I guess if the v4.15 is good then it's not hardware
<juliank> (Acer Chromebook 13)
<juliank> chromebook: 100, 86, 96
<juliank> that's a useless comparison :D
<juliank> Mbit/s
<juliank> Now I got 440 Mbit/s on 5.0
<juliank> ah no
<juliank> on wired again
<juliank> I should probably just get a nice long cat6e cable and forget about WiFi
<LocutusOfBorg> doko, it sucks, we should remove everything that is not supported upstream
<LocutusOfBorg> we should *not* ignore testsuite results for insighttoolkit4, that is all
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/insighttoolkit4/+bug/1812874
<ubottu> Launchpad bug 1812874 in insighttoolkit4 (Ubuntu) "insighttolkit4: remove everywhere except amd64 and i386" [Undecided,New]
<jbicha> bdmurray: is the SRU team interested in bionic autopkgtest fixes like if I were able to fix bug 1763628?
<ubottu> bug 1763628 in colord (Ubuntu) "autopkgtests are failing on valgrind" [Undecided,New] https://launchpad.net/bugs/1763628
<bdmurray> jbicha: it depends on the package's install base etc, making a whole bunch of people update to only fix an autopkgtest is somewhat rude
<jbicha> thanks, I'll go ahead and close the bug since it's fixed in disco where we're more interested (and the bionic failures started before bionic's release)
<smoser> mwhudson: i'm curious  why 'go' snap is classic
<smoser> (low priority ping)
<juliank> sladen: so I think I agree w/ hardware is ok, I can consistently get 52-54 MB/s on 4.15
<juliank> not on later kernels
<juliank> probably on some 4.18 ones
<juliank> as disco was fine back in the day
<juliank> um, cosmic
<juliank> so there must be a regression in 4.18.y point releases
<TJ-> juliank: When I did my tests I narrowed down one issue to 4.16-4.17
<juliank> now 4.18 is fine too
<juliank> what is wrong
<jdstrand> juliank: ok, I read the irc backlog between us and tried a few things and did not reproduce. I suspect that it has to do with a particular state of the archive that is not present (at least in what I tested)...
<seb128> bdmurray, hey, thanks for the SRU reviews! could you review the new gnome-shell-extension-ubuntu-dock upload in the bionic queue? there was a change which was in the upload accepted earlier than we decide to not include after all so I bumped the version and remove that patches/entry from the changelog
<bdmurray> seb128: sure
<seb128> bdmurray, thx!
<seb128> doko, could you have a look to https://bugs.launchpad.net/ubuntu/+source/freetype/+bug/1799014 ? there is patch for openjdk which has been commited upstream in 12 which could be useful to backport to our version
<ubottu> Launchpad bug 1799014 in openjdk-lts (Ubuntu) "bold font rendeing in Java is broken in Cosmic with OpenJDK 11" [Undecided,Confirmed]
<tdaitx> seb128: thanks for the heads up, I will take a look at that
<seb128> tdaitx, thx
<bdmurray> seb128: It seems to me like the patch in update-notifier for bionic would be useful for cosmic since it helps with cleaning up other zombie processes
<seb128> bdmurray, yeah, in practice we didn't get reports from cosmic and it's not a big issue so I'm trying to not spend too much enery on that non LTS serie, but I can upload there if you feel strongly about it
<bdmurray> seb128: looking at the code my concern would be leftovers from calling software-properties-gtk from the applet. Do you recall which desktops show the update-notifier applet?
<seb128> bdmurray, no I don't, but that code is no new/a regression from the previous SRU, we didn't even had a SRU in cosmic
<seb128> I wouldn't bother SRUed a fix to cosmic, which is a non LTS, for an issue that got 0 user report
<bdmurray> Okay yeah I don't see any obvious bug reports about it.
<mwhudson> smoser: toolchain snaps more or less have to be in practice, it needs to e.g. invoke gcc
<seb128> bdmurray, anyway, let me know if you want a cosmic upload and I can do one but I think it's a waste of time
<smoser> mwhudson: why would that imply classic?
<smoser> i guess you're not putting gcc inside the snap then? you could though, no?
<smoser> oh. but i see.  the invoked thing will ultimately read files in /usr/include/ and such and you want (it seems) those to be read
<smoser> so the user can 'apt-get install libfoo-dev' and get those used.
<mwhudson> smoser: tbh i forget the details
<mwhudson> but roughly yes, you could in theory pack the entire world into the snap (gcc, dev packages) but where do you stop
<mwhudson> also presumably you are going to run the binaries the snap produces so there's a pretty strong trust relationship there
<juliank> mwhudson: also, how'd go run work properly in a non-classic snap
<mwhudson> juliank: well you shouldn't use that anyway :)
<juliank> mwhudson: but... My .go scripts in ~/bin :(
#ubuntu-devel 2019-01-23
<cpaelzer> juliank: will you take a look at multipath-tools again before FF of this cycle?
<juliank> cpaelzer: I don't think so
<juliank> I think worst case, we can keep it at the cosmic level for disco, and update it next cycle
<juliank> I think with the amount of regressions that can come from a multipath-tools update it does not really make much sense to update it late in a cycle
<cpaelzer> yes
<cpaelzer> that was what I was concerned about if it would come in very last
<cpaelzer> and I didn't hear any of the usual multipath-heavy people cry for a new version, maybe the fixes are less important than usual
<cpaelzer> I'd ack to doing it early in next cycle to be able to sort things out there
<cpaelzer> thanks for the clarification juliank
<weasel> hye.
<weasel> hey.
<weasel> any idea how to debootstrap a current ubuntu system using only https sources?
<weasel> for some reason you put apt-transport-https into universe
<weasel> which makes debootstrap break
<weasel> [ https://bugs.debian.org/920255 ]
<ubottu> Debian bug 920255 in debootstrap "tries to install apt-transport-https even if doesn't exist" [Important,Open]
<cjwatson> that was probably because apt has built-in https now
<weasel> yeah, but it breaks debootstrapping
<cjwatson> I guess debootstrap hasn't been fixed for that?
<weasel> not yet, at least not in debian
<cpaelzer> LocutusOfBorg: doko: I saw you retrying tests of "redmine" any idea what dependency is broken and why?
<cpaelzer> I saw ruby-actionpack-xml-parser and that also makes redmine from proposed hard to install in a disco container
<weasel> also, cf Debian#879755
<weasel> [ hm.  ubottu doesn't do that.  https://bugs.debian.org/879755 then ]
<ubottu> Debian bug 879755 in debootstrap "debootstrap fails with current sid without apt-transport-https and https URLs" [Minor,Open]
<cpaelzer> but I didn#t check further, but seeing your retries with "assorted triggers" was wondering if you took a look already?
<weasel> cjwatson: so, any advice on how to get any of the modern ubuntus bootstrapped?
<cpaelzer> ahasenack: ^^ FYI on current postgersql vs redmin in excuses
<cjwatson> in the short term maybe just sed apt-transport-https out of the relevant script?
<cjwatson> I'm sure somebody should fix it properly, but that somebody won't be me :)
<weasel> that's not a horrible idea.  let me try it :)
<weasel> it didn't even occur to me
<cjwatson> mwhudson,sil2100,infinity: could any of you have a look at https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/361824 and https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/361825 ?  I'd like to make progress on getting those LXD images up
<cjwatson> (I understand I may not be able to actually do the bionic SRU yet since there's other stuff in verification)
<sil2100> cjwatson: I'll try having a look in some moments
<cjwatson> Thanks
 * Laney fist bumps mwhudson for the rustc backports
<jbicha> vorlon: would you subscribe foundation-bugs to pcre2 for LP: #1636666 ?
<ubottu> Launchpad bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,Confirmed] https://launchpad.net/bugs/1636666
<LocutusOfBorg> cpaelzer, I retried a lot of stuff, nothing intentional :)
<doko> cpaelzer: redmine is scheduled for removal in debian. I wouldn't mind if you prepare a removal bug ...
<ahasenack> doko: it looks like a similar case to schleuder wrt ruby-mail:
<ahasenack> Setting up redmine (3.4.6-1) ...
<ahasenack> Could not find gem 'mail (~> 2.6.4)' in any of the gem sources listed in your Gemfile.
<ahasenack> we have ruby-mail 2.7.x
<ahasenack> https://github.com/redmine/redmine/blob/master/Gemfile seems to support 2.7.1
<teward> ahasenack: is that *latest* upstream or the version of redmine 3.4.6?
<ahasenack> I'm checking
<teward> because 'master' seems ahead of 3.4.6
<ahasenack> latest 3.4.x is 3.4.8 (tarball, just downloaded)
<teward> 'cause if I look at releases, I see us at 4.0 which I am assuming Master is at
<teward> 4.0.x *
<ahasenack> 3.4.8 still wants ruby-mail 2.6.4:
<ahasenack> gem "mail", "~> 2.6.4"
<ahasenack> it's the 4.0.x release that can use ruby-mail 2.7.1
<teward> ahasenack: right, 4.0.1 supports 2.7.1 - gem "mail", "~> 2.7.1"
<teward> yep
<teward> so it probably needs upgraded in Debian and Ubuntu then
<ahasenack> right, debian stopped at 3.4.6
<teward> (sorry I was just perusing channels and landed here and noticed your last message with the 'master' upstream link)
<ahasenack> I can file an ubuntu bug explaining this, and then someone can decide to either go ahead of debian, or drop it
<ahasenack> doko: cpaelzer: https://bugs.launchpad.net/ubuntu/+source/redmine/+bug/1813051
<ubottu> Launchpad bug 1813051 in redmine (Ubuntu) "Not installable on disco due to ruby-mail" [Undecided,New]
<teward> ahasenack: might want to link to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919805 while you're in there
<ubottu> Debian bug 919805 in src:redmine "redmine: FTBFS (Could not find gem mail)" [Serious,Open]
<teward> same problem
<teward> (and I made a note of what we found there just now)
<ahasenack> thx
<teward> i wonder how hard it would be to update that package... *is merely curious, and might try to as a thought experiment*
<ahasenack> it's ruby
<ahasenack> outside my comfort zone
<ahasenack> waaaay outside
<teward> yeah outside mine too but I've had to learn some ruby, just curiousity making me wonder :P
<teward> *is bored at work so tests things*
<teward> ahasenack: wonder if patching the gemfile to use the newer would work, or if it just breaks.
<teward> which'd be a simple bugfix patch if all we have to do is alter the gemfile.
<mwhudson> cjwatson: is there something i can do to get email about new livecd-rootfs MPs?
<mwhudson> cjwatson: approved both
<ahasenack> teward: I've seen it break in another ruby package, ruby-mail 2.7.x seems to have introduced some significant changes
<ahasenack> I hacked the gem file (schleuder was the pkg) and the tests failed
<teward> makes sense.
<teward> ahasenack: then it's safe to say we have to jump to 4.0.1 if we intend to keep it :P
<teward> wonder what Debian's going to do :P
<ahasenack> doko said debian was going to remove it
<teward> ahasenack: i didn't see a removal bug, I saw the FTBFS bug.
<teward> ahasenack: though Debian QA shows it as bieng removed from testing
<jbicha> doko: I'm having problems with dpkg shlibs on armhf now, here's an example: https://launchpad.net/ubuntu/+source/xfce4-terminal/0.8.7.4-2/+build/16313954
<mdeslaur> jbicha, doko: I'm getting that with ghostscript too
<doko> jbicha, mdeslaur: removed from -proposed. but I'm afk now
<jbicha> thank you
<mdeslaur> thanks!
<mwhudson> Laney: gotta keep the DC warm
<mwhudson> speaking of which, time to upload them all again
<cjwatson> mwhudson: thanks; https://code.launchpad.net/~ubuntu-core-dev/livecd-rootfs/+git/livecd-rootfs -> subscribe yourself, and "code review level" is the relevant one, you can turn off the rest if you want
<mwhudson> cjwatson: i'd swear that wasn't there last time i looked for it
<mwhudson> oh well
<mwhudson> maybe i was looking at branch vs repo
<cjwatson> Could be
<mwhudson> anyway, thanks :)
<jbicha> doko: ha, our pcre3-in-main count went up by one yesterday :( LP: #1459692
<ubottu> Launchpad bug 1459692 in anope (Ubuntu) "[MIR] anope" [Undecided,Fix released] https://launchpad.net/bugs/1459692
#ubuntu-devel 2019-01-24
<JackFrost> "...IRC services that is actively maintained and sane."  Uhh...Atheme anyone? :)
<debusr> this seems like a major bug in python's pip installation in debian, you might be interested as well: https://github.com/numpy/numpy/issues/12736#issuecomment-457095173
<doko> tjaalton: dogtag-pki fails autopkg tests on amd64, blocking some stuff
<tjaalton> doko: yes, best to remove and block it for now.. including all the java deps
<tjaalton> lacking support for tls1.3/java11 :/
<tjaalton> upstream won't help before fedora is on java11
<doko> hmm
<tjaalton> everything builds fine etc, but the tomcat instance can't get ssl set up
<sil2100> Trevinho: hey! The diffing in Bileto should now be fixed
<sil2100> seb128: ^
<seb128> oh nice, thx!
<sil2100> (at least my expectation should be no more 0 line diffs)
<sil2100> yw!
<cpaelzer> thanks sil2100
<LocutusOfBorg> does anybody understand why the CHANGELOG.md is not picked up automatically by debhelper?
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/node-istanbul/0.4.5+ds-4
<LocutusOfBorg> wrt https://launchpad.net/ubuntu/+source/node-istanbul/0.4.5+ds-4ubuntu1
<LocutusOfBorg> Debian, with the same debhelper version picks it up...
<LocutusOfBorg> juliank, ^^ you are my best bet, I don't want to hide a debhelper possible trouble
<juliank> LocutusOfBorg: dh_installchangelogs: Do not install upstream changelog in compat
<juliank>       level 7 and higher to avoid pointlessly bloating installed packages.
<juliank> this is one of the changes
<juliank> in our debhelper
<juliank> So, this is on purpose
<Trevinho> sil2100: great!
<LocutusOfBorg> juliank, I looked, and looked again at that delta
<LocutusOfBorg> and for some reasons I looked and thought "*lower*"
<LocutusOfBorg> I was wondering if below compat 7 the changelogs were not gzipped, so they were excluded
<LocutusOfBorg> damn :/
<LocutusOfBorg> so my fix was good I would say
<doko> tjaalton: can you file a bug report?
<tjaalton> doko: yeah
<juliank> LocutusOfBorg: I'd rather change it so it does not modify the installed changelog if there is none
<juliank> but um, don't care much
<LocutusOfBorg> juliank, I already submitted to debian, the changelog seems useful, si preferred that way...
<teward> regarding pcre2, NGINX upstream still has no intention to support pcre2; is Debian also moving to pcre2 or any of the other major distros moving?
<teward> if there's a substantial push then I can probably prod them with enough reason to make PCRE2 a goal
<teward> but until then the pcre2 for nginx is 'Wishlist / Won't Fix' because of upstream.
<rbasak> I got the impression that everyone is moving, and that nginx's upstream assessment was mistaken.
<jbicha> everyone is a very large number: https://people.canonical.com/~ubuntu-archive/transitions/html/pcre2.html
<doko> RAOF: mir ftbfs in disco, please can you fix that?
<teward> rbasak: i'll need hard evidence to back that up
<teward> because they don't track downstreams.
<teward> rbasak: auto-migration trackers, bugs for tracking, etc.
<teward> them being as stubborn as they are
<rbasak> Hopefully the MIR will help with that - you'll be able to see at a glance what the rdepends are as stuff gets moved, and whether the distribution patched it or if upstream actually had support.
<teward> rbasak: yeah, that helps considerably, but they're going to be stubborn as hell if they say "But this is only Ubuntu moving!"
<teward> which they've said in the past
<teward> which is why I need the additional support on other factors.
<teward> other distros, Debian, etc.
<rbasak> Is it possible to build nginx without pcre support?
<rbasak> Because honestly, I'm not sure it's worth the effort in trying to persuade them.
<rbasak> If they want to lag behind, we can (eventually, when we drop pcre3 from main) either build nginx without any pcre or make it modular (if that's supported) with the pcre component in universe, or kick the whole thing to universe.
<rbasak> That's what we'll have to do anyway.
<rbasak> It won't realistically happen though unless nginx really are pretty much the last ones in main without pcre2 support.
<rbasak> At that point, if it's a real problem then users will ask for upstream to sort the situation. If it isn't really a problem, then it won't by definition need addressing.
<teward> rbasak: building without PCRE is going to be dropping all regex support from NGINX
<rbasak> Understood.
<teward> which is a core critical component for rewrites, location matching, etc.
<teward> it's literally stripping out a core functionality
<teward> PCRE modularity is not going to work either because it's in core non-module functions.
<teward> and I can say with certainty that dropping that support will cause major headaches.
<rbasak> OK, so we'll have a choice between stripping out PCRE support or relegating nginx into universe.
<teward> which is where it was before 14.04.
<rbasak> Stuff in main has to be well supported by upstreams. That's one of the criteria for being in main.
<teward> yep.
<teward> rbasak: i once again dropped the request to revisit PCRE2 support in the nginx-devel mailing list
<rbasak> Thanks!
<teward> if they're still being obstinate then I'll personally request that we drop it to Universe
<kyrofa> Anyone around who can answer questions about php's packaging?
<kyrofa> Specifically, I'm curious why large file support isn't built in (http://php.net/manual/en/intro.filesystem.php)
<kyrofa> Ah, perhaps it is, using getconf LFS_CFLAGS
<rbasak> kyrofa: IIRC we had an ABI mismatch to deal with due to a switch to LFS in the past.
<rbasak> I can look up details if you need.
<kyrofa> rbasak, mostly just curious if we enable it at all-- I'm being asked to in a snap I maintain and I didn't know anything about it, so I'm trying to learn from the pros
<kyrofa> rbasak, it appears we do, if you can verify that for me though I would be thrilled
<rbasak> kyrofa: here's the bug I was recalling: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/1280044
<ubottu> Launchpad bug 1280044 in php5 (Ubuntu) "dpkg-buildflags wipes out LFS support in package build" [High,Fix released]
<kyrofa> 2014, good memory
<doko> jbicha: zlib ping?
<rbasak> kyrofa: looking at https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/15453636, the build log does show "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" so I'm pretty sure that LFS is enabled on Bionic i386.
<kyrofa> rbasak, excellent, thank you :)
<jbicha> thanks, zlib is better now
<teward> rbasak: et. al.: I'm going to say that if NGINX is the last straggler for the pcre2 migration then we'll demote NGINX to Universe again, until they make PCRE2 support.  Deb8 and Trusty and CentOS6 don't have pcre2 which is three of the examples they quote.  They're welcome to PCRE2 support patches though.  I just don't have any.
<teward> once we get PCRE2 support we can reapproach getting it into main again.  (The statement that we'd drop it from 'supported' to 'community supported' seemed to get their attentin)
<teward> 'we' in the second line being NGINX.
<smoser> paste.ubuntu.com is down ?
<wxl> works here @smoser
<sarnold> wfm
<sarnold> heh, but irc scrollback from that same minute internally is pretty crazy :) I'm not surprised it was down..
#ubuntu-devel 2019-01-25
<sparr> I need to build a kernel from https://cgit.freedesktop.org/drm-tip/tree/ with all the same options and modules that my current kernel has (https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0-rc2/). Is there a guide on how to do that?
<sarnold> sparr: is the config in /boot/config-`uname -r` ?
<sarnold> if so, copy that config to .config in your kernel tree, then make oldconfig
<sparr> sarnold: when make prompts something with (NEW) that means the option didn't exist in the previous config?
<sarnold> yeah
<sparr> ok, after make oldconfig and answering the one new thing?
<sarnold> build kernel as needed :)
<sparr> how can I find the build dependencies for my kernel(s) when none of my installed kernel packages have source packages for doing apt-get build-dep on?
<sarnold> the Documentation/Changes file lists the *programs* you need; that might not translate easily to *packages* to install, but it should be pretty close
<sarnold> installing build-essential and then starting the build and fixing errors as they occur will probably get you pretty far
<sparr> thanks, picking through dependencies like libssl now
<sparr> drives me nuts when the name of a library doesn't match the name of the package (openssl vs libssl)
<sarnold> heh, the number of times people have installed just an openssl pckage update and missed the libssl package -- which actually fixes the security bug..
<sparr> I guess I should count myself lucky that I couldn't continue without the right onw
<sparr> sarnold: if I started with source not from an ubuntu package so I don't have a debian/rules directory for fakeroot, what's the actual build step?
<sparr> the guide I'm using wants me to do "fakeroot debian/rules binary-headers binary-generic binary-perarch" but debian/rules doesn't exist
<doko> cpaelzer: qemu-system-arm/amd64 unsatisfiable Depends: libvirglrenderer0 (>= 0.7.0)
<cpaelzer> doko: that has a MIR https://bugs.launchpad.net/ubuntu/+source/virglrenderer/+bug/1657409
<ubottu> Launchpad bug 1657409 in virglrenderer (Ubuntu) "[MIR] virglrenderer" [Medium,In progress]
<cpaelzer> doko: do you have time to do the override?
<cpaelzer> I have updated the MIR bug to make clear that the upload triggering it now is intentional
<doko> cpaelzer: done
<doko> cpaelzer: libsys-virt-perl autopkg test failure
<doko> oSoMoN: lo needs https://cgit.freedesktop.org/libreoffice/core/commit/?id=635b38704594851648f359477b53f2224b9e6ee1  for openjdk 11.0.2
<oSoMoN> doko, ack
<cpaelzer> thanks doko
<cpaelzer> I'll look into test errors as usual, but it most likely will be monday until I get more time to really work on it
<oSoMoN> doko, LO 6.2.0 is due out next week, so I'll apply the patch there, I won't rebuild 6.1.4, unless really needed?
<doko> oSoMoN: there are some autopkg test failures, but nothing blocking afaics
<doko> rbasak: pacemaker would need a merge, there are some dep-waits in proposed
<rbasak> doko: how do I find the dep-waits please?
<doko> rbasak: http://qa.ubuntuwire.org/ftbfs/
<rbasak> doko: pacemaker doesn't appear there though?
<doko> no, but dlm
<rbasak> Just dlm?
<rbasak> We're looking into whether we want to merge pacemaker 2 this cycle, or if it's too close to feature freeze.
<rbasak> So knowing what's impacted would be helpful.
<LocutusOfBorg> mdeslaur, http://debomatic-amd64.debian.net/distribution#unstable/libcaca/0.99.beta19-2/buildlog can you please open a debian bug too? :)
<LocutusOfBorg> we might go back in sync :)
<mdeslaur> LocutusOfBorg: sure, debian bug 920442
<ubottu> Debian bug 920442 in libcaca "libcaca FTBFS in unstable" [Serious,Open] http://bugs.debian.org/920442
<mdeslaur> LocutusOfBorg: thanks
<doko> RAOF, xnox: mir is now back again to happily ftbfs in the tests ... trying if the version in the release pocket still works ...
<LocutusOfBorg> thanks mdeslaur :)
<RAOF> doko: thanks for checking. I'll get on to it when I'm back at work on Tuesday.
<doko> The following tests FAILED:
<doko> 	372 - mir_umock_unit_tests.EvdevInputPlatform.* (Failed)
<doko> 	376 - mir_umock_unit_tests.DeviceHandling/EvdevInputPlatform.* (Failed)
<doko> RAOF: ^^^ I'll upload with ignoring the test results, so we have something in the archive which allows me to continue with the migration stuff. btw, these fail in 0.32.1 as well
<RAOF> doko: oh! That's fixed in trunk.
<RAOF> I guess we've now got the systemd version which exposes that bug.
<LocutusOfBorg> so better upload a patch...
<doko> RAOF: could you point me to that patch?
<RAOF> Yup! The patch should apply without problems.
<RAOF> Let me get out my laptop...
<doko> and building with -DMIR_USE_PRECOMPILED_HEADERS=OFF for now ...
<RAOF> doko: https://github.com/MirServer/mir/commit/c845095f291af00d94ea3918e41a59509bd29509
<doko> RAOF: https://launchpad.net/ubuntu/+source/mir/1.0.0-0ubuntu7
<RAOF> Ta.
<RAOF> Oh! Does this mean the yaml-cpp MIR has been resolved?
<doko> no, not yet. so maybe I re-upload 0.32 this weekend. not sure
<sparr> should https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel still be accurate?
<sparr> I got to the fakeroot step and ended up with "/usr/bin/fakeroot: 175: /usr/bin/fakeroot: debian/rules: not found"
<sparr> possibly because I'm fetching a mainline kernel source instead of from the release git
<teward> rbasak: is the pcre2 thing needed before 19.04 release?  I.E. release-critcal for this cycle?
<jbicha> teward: definitely no, there are many main things that will still be using pcre3 for 19.04 and probably 19.10 too
<teward> jbicha: that's what I thought.
<teward> just checking to make sure before I ask -release to demote nginx* back to Universe because currently upstream doesn't support pcre2 and doesn't seem to want to redo all the PCRE API stuff since it changes
<teward> and I"m not familiar enough with either PCRE to do patches for thsoe changes :P
<jbicha> it it were that easy to kill pcre3 in main, the pcre2 MIR would have been approved a long time ago
<teward> indeed
<sparr> https://help.ubuntu.com/community/Kernel/Compile points to https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel which also seems to be outdated. Is there a newer guide?
<gQuigs> sparr: if you're doing mainline, another outdated guide might help: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<gQuigs> but I think it still works..
<sparr> thanks, I'll try it
<sparr> also trying to figure out how to apply https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0-rc2/0001-base-packaging.patch
<gQuigs> if it changes the packaging I wouldn't do it for Git build to work.. . if it's a normal patch just git apply...
<sparr> your wiki page wants me to do git clone git://kernel.ubuntu.com/ubuntu/ubuntu-lucid.git which fails :(
<sparr> lucid is old, no?
<sparr> oh god, is this a full kernel source? that's a 4 hour clone
<sparr> this is the fourth full copy of the kernel source I've had to download, three from git :(
<rbasak> teward: no need to demote nginx yet. I was only talking before about some eventual future time when we're ready to demote pcre3. Only at that future time will we need to care about nginx not having support.
<teward> rbasak: ack.
<teward> that's why i inquired as to the criticality of it
<teward> jbicha's note that there's a ton still using pcre3 makes sense :P
<rbasak> Yeah
<teward> i'm sure not all upstreams want to move off pcre3, too, because of different API and such
<rbasak> Before the next LTS would be nice but I'm not sure if that'll happen.
<teward> 20.04 you mean
<rbasak> Yes
<teward> by that point I can probably persuade NGINX to move on it, because the OSes they're still 'supporting' that don't have PCRE2 die in 2020 :P
<sparr> gQuigs: stuck at `cp -a /usr/share/kernel-package ubuntu-package` because I don't have /usr/share/kernel-package
<sparr> oh, sorry, I missed that that guide has a couple of extra packages to install
<sparr> then actually failing on "cp ubuntu-cosmic/debian/control-scripts/{postinst,postrm,preinst,prerm} ubuntu-package/pkg/image/"
<sparr> no such files
<sarnold> sparr: ahh, sorry, I thought you wanted to just do the make -j ... bzImage modules install step to get your kernel..
<sarnold> sparr: I haven't built my own kernel in ages but last time I did the kernel-package package's make-kpkg command was pretty useful. It's probably a lot faster than *properly* building a .deb package
<sparr> I am worried about producing a kernel or package (including initrd and grub settings) that do not well match my current kernel
<sparr> I am super annoyed at what seems to have become common practice, to distribute whole copies of the kernel source for small changes to one module :/
<cjwatson> if you just add more remotes to an existing git clone then it shouldn't be anything like as much to download
<TJ-> ^^^^ this - I have a mainline based repo with about 30 remotes, for the linux-next linux-stable and all ubuntu-XXXX releases etc.
<sparr> that would require me to have a much more broad and deep knowledge of the package building process, because I wouldn't be able to follow any guides
<sparr> not that the guides are super helpful, since even the most recent official-ish ones seem to be 3-5 years out of date
<sparr> thank you for the idea, though
<TJ-> sparr: what is it you're trying to build, is this for the i915 glitch?
<sparr> yes, for the i915 glitch
<sparr> trying to build https://cgit.freedesktop.org/drm-tip/ at commit d0757afd00d71dca98268d09884dc6248743d8ce
<sparr> which I *think* I have just started compiling, after accidentally doing a full compile of 5.0-rc3
<sparr> drm-tip on î  d0757af $ CONCURRENCY_LEVEL=`getconf _NPROCESSORS_ONLN` fakeroot make-kpkg --initrd --append-to-version=-custom --overlay-dir=../ubuntu-package kernel_image kernel_headers
<sparr> except that it's not visibly doing much and pstree reports "conf" has been running for a while now. fakerootâââmake-kpkgâââshâââmakeâââshâââmakeâââmakeâââmakeâââconf
<TJ-> sparr: I generally use the kernel's own package-build targets (e.g. bindeb-pkg) - and I disable generating the debug-symbol packages to save time/space for non-gdb testing (in scripts/package/mkdebian, removing then code for $packagename-dbg  )
<sparr> TJ-: more responses in #intel-gfx, hard to keep track of which channel you're asking in
<sparr> I can continue or repeat here?
<TJ-> sparr: hehe sorry, it is a bit difficult to decide which is more appropriate!
<sparr> I am tempted to start over
<sparr> I've downloaded and copied so many things so many places now that I've lost track
<sparr> lost track to the point that I ran an entire successful kernel build... on the wrong directory
<sparr> or to just give up
<sparr> I only have to deal with this laptop for another few weeks, then I can switch to nvidia graphics and not look back
<sparr> if someone thinks it's worth walking me through the process to get a good bug report to improve the intel drivers, I'm game, but it has passed the point where it's worth my time to keep trying alone for just my own benefit.
<sparr> I currently have 3 kernel sources checked out, drm-tip, ubuntu-cosmic, and mainline v5.0-rc2
<sparr> I actually managed to get v5.0-rc2 to build with some tweaks and skipped steps from these instructions: https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
<sparr> (oddly, it build rc3, which I don't remember checking out)
<sparr> ok, after doing some magical incantations with the moon in a slightly different phase than before, I seem to have drm-tip building
<sparr> now, back to #intel-gfx...
<hggdh> ah crap, cannot edit it here
<sladen> ?
#ubuntu-devel 2019-01-26
<joelkraehemann> doko: ping
<joelkraehemann> I just answered your email
<doko> joelkraehemann: ta
<joelkraehemann> hi doko
<joelkraehemann> ask me what you want ...
<doko> nothing more to ask. our release managers need to configure the autopkg test to run on the bigger instances
<joelkraehemann> doko: have you tried to run the tests with more than 1 GB RAM?
<doko> no, not yet. letting the autopkg testers do their work ...
<joelkraehemann> great!
<xnox> doko, one can proposed a merge proposal... the conifgs are in git and public
<xnox> doko, what package do you believe needs to be bumped to be marked as "big_packages" ?
<doko> xnox: joelkraehemann analysed the gsequencer failure
#ubuntu-devel 2019-01-27
<sladen> lee_: your connection is closing and reopening every minute.
#ubuntu-devel 2020-01-20
<Tuxist> hi i have problem ldconf overrides links to set i have set libjack.so.0 => libjack-pw.so.0 how can change this behavior ?
<ahasenack> rafaeldtinoco: IIRC this bug ended up being about adding the tests to the qa-script branch, right? https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1854529
<ubottu> Launchpad bug 1854529 in ndctl (Ubuntu) "DEP8 tests to satisfy MIR needs" [Medium,In progress]
<rafaeldtinoco> ahasenack: lemme check
<rafaeldtinoco> ahasenack: https://trello.com/c/YBnD6W2t
<rafaeldtinoco> Yes, I'll add it to qa-regression-tests
<rafaeldtinoco> adding it as autopkgtests was no good
<rafaeldtinoco> (kernel cmdline memmap didnt prove to be compatible with most of the tests)
<rafaeldtinoco> so we have to rely on KVM machines
<rafaeldtinoco> emulating nvdimms
<ahasenack> do you have something in progress?
<rafaeldtinoco> I have all tests ready, missing the QRT integration
<rafaeldtinoco> not sure ETA as this and next weeks are full of other stuff
<rafaeldtinoco> ahasenack: is this something urgent ?
<ahasenack> the mir is on our plate because of it
<ahasenack> so it's about converting https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/ndctl/+git/ndctl/+merge/376493 to qa-regression-tests?
 * rafaeldtinoco checks to confirm
<rafaeldtinoco> ahasenack: yes. to create a VM with the given XML domain, and then spin up the tests on it.
<ahasenack> let me take a look at that then
<rafaeldtinoco> id love that
<rafaeldtinoco> ahasenack: search for:
<rafaeldtinoco> nvdimm node 0 | dd if=/dev/zero of=/tmp/nvpath1 bs=1M count=2050
<rafaeldtinoco> just be sure to create those files
<rafaeldtinoco> exactly like that
<rafaeldtinoco> and keep xml for nvdimms exactly like that
<rafaeldtinoco> emulation does not like too much
<rafaeldtinoco> other values (alignment issues)
<ahasenack> why didn't the memmap trick in the kernel cmdline work?
<ahasenack> finding out the actual region you could use was tricky? like dmesg | grep?
<rafaeldtinoco> nope, it does not support label
<ahasenack> what's that?
<rafaeldtinoco> 80% of the tests need labeling
<ahasenack> did you come up with those tests?
<ahasenack> or was that upstream
<rafaeldtinoco> i got a small subset of upstream ones
<rafaeldtinoco> the important ones
<rafaeldtinoco> and labeling makes the namespace configuration
<rafaeldtinoco> persistent
<rafaeldtinoco> so when you disable a region
<rafaeldtinoco> and enables it back again
<ahasenack> and this blocked the inclusion of these tests as dep8, or was it just the inability of doing nested kvm in our dep8 infra?
<rafaeldtinoco> the namespace is configured like you did
<rafaeldtinoco> inability of doing nested kvm
<ahasenack> ok
<rafaeldtinoco> you could spin up a kvm guest as DEP8
<rafaeldtinoco> and run tests inside it afaik
<rafaeldtinoco> thanks for offloading =)
<rafaeldtinoco> let me know if you need anything else
<ahasenack> I considered a smaller test set, but if we cannot bring up nested kvm, that's a blocker
<ahasenack> for dep8, we can just keep or smoke tests then
<rafaeldtinoco> yep thus the trello card mentioning "2b" option when cpaelzer_ described what could be done
<rafaeldtinoco> being "2b" the regression tests from security team
<rafaeldtinoco> yep, for dep8 i think its already there
<rafaeldtinoco> its testing both binaries
<rafaeldtinoco> ndctl and daxctl
<rafaeldtinoco> thats all can be done without memmap
<rafaeldtinoco> or nvdimm emulation
<ahasenack> ok
<ahasenack> doko: haproxy using python3-mako (instead of python-mako) migrated
<tkamppeter> Someone here is using Open JDK and/or Oracle JDK?
<rafaeldtinoco> tkamppeter: I am
<rafaeldtinoco> (for eclipse CDT only)
<tkamppeter> rafaeldtinoco, WDYT, should one rather use Open JDK or Oracle JDK?
<rafaeldtinoco> tkamppeter: ill let our jdk maintainer to answer that -> tdaitx
<rafaeldtinoco> for eclipse CDT, using jdk 8 from oracle was always a safe move
<rafaeldtinoco> but I also used latest openjdks and did not have issues
<rafaeldtinoco> tdaitx will have more info to give you (when he is back)
<tkamppeter> rafaeldtinoco, thank you very much, I have passed it on.
<rafaeldtinoco> sure!
<fossfreedom> all - if this is already know - apologies - is anyone aware if a bug report for today (or recent) focal daily crashes instantly on logon? can logon via the wayland session though
<fossfreedom> s/know/known/
#ubuntu-devel 2020-01-21
<seb128> fossfreedom, hey, saw your message from yesterday. I don't think it's know, did you report a bug? can you share the journal from a failed login/session?
<fossfreedom> Will do tonight seb128 ... but someone else reported this to me yesterday and I suspect it may be the same issue bug #1796437 since I installed the daily with the restricted installer options in a qemu VM
<ubottu> bug 1745345 in xorg-server (Ubuntu) "duplicate for #1796437 Xorg assert failure: Xorg: /usr/include/xorg/privates.h:122: dixGetPrivateAddr: Assertion `key->initialized' failed." [Medium,Confirmed] https://launchpad.net/bugs/1745345
<seb128> fossfreedom, I see, interesting
<gpiccoli> Hi sil2100, vorlon - I'd like to ask about mdadm. As discussed last week, we should drop the dannf 's version from proposed while kernel team figures out the kernel counter-part of the raid0 layout issue. And then, if possible, upload the following verion to proposed: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1847924
<ubottu> Launchpad bug 1847924 in mdadm (Ubuntu Eoan) "Introduce broken state parsing to mdadm" [Medium,In progress]
<gpiccoli> s/verion/version
<sil2100> gpiccoli: ok, on it right now - I actually started looking at it last time but then got preempted
<gpiccoli> Awesome sil2100, really appreciated =)
<sil2100> rbasak: hey! So I'm reviewing gpiccoli's mdadm right now and I think it looks okayish now - since you were the original reviewer I wanted to know your feelings about it before I proceed
<rbasak> sil2100: o/
<rbasak> Thank you for the ping.
<rbasak> I haven't had a chance to look yet, but I think you're on the same page as me on that one so if you're happy I'm happy.
<ahasenack> I retrigger krb5/i386 dep8 with all-proposed=1. I can't reproduce that dependency error from the log in a lxd container with i386 arch added and proposed enabled
<AsciiWolf> hi, has someone here rights to sync packages from Debian? if so, could please someone sync steam and related packages? it is still on version 1.0.0.54 (even on latest Ubuntu Focal) that is really old and does not contain proper udev rules from Steam Controller or VR
<AsciiWolf> there was a proposal to remove the steam package completely from Ubuntu (see https://bugs.launchpad.net/ubuntu/+source/steam/+bug/1759715), maybe it was added to sync blacklist, but not actually removed?
<ubottu> Launchpad bug 1759715 in steam (Ubuntu) "Remove steam and add to sync blacklist" [Undecided,Triaged]
<ahasenack> AsciiWolf: it has a delta, that's why it wasn't auto-synced
<ahasenack> see changelog: https://launchpad.net/ubuntu/+source/steam/1:1.0.0.54+repack-5ubuntu1
<ahasenack> tsimonq2: you are the current TIL :)
<ahasenack> ^
<ahasenack> can anybody tell what happened to the galera-arbitrator-3 binary from https://launchpad.net/ubuntu/+source/galera-3/25.3.28-2/+build/18262764 ?
<ahasenack> I don't see it in the focal/amd64 archive
<ahasenack> rbasak: any idea? ^
<cjwatson> https://launchpad.net/ubuntu/focal/amd64/galera-arbitrator-3
<cjwatson> Deleted on 2020-01-16 by Steve Langasek: NBS
<ahasenack> hm, https://launchpad.net/ubuntu/+source/galera-3/+publishinghistory doesn't even go that far, stops in december 2019
<ahasenack> cjwatson: how did you get that link, to the binary package? From https://launchpad.net/ubuntu/+source/galera-3/25.3.28-2 somewhere?
<cjwatson> regrettably that's a URL structure you just have to know :(
<ahasenack> ok
<ahasenack> so a binary was removed, but the source is still there, and we have dep8 tests failing because galera-arbitrator-3 no longer exists
<cjwatson> although the section under "Binary packages" from e.g. https://launchpad.net/ubuntu/+source/galera-3/25.3.28-2/+build/18262764 links to under it
<ahasenack> ah, "Binary packages built by this source"
<cjwatson> A removal with the reason "NBS" implies that the source package doesn't actually build it any more
<ahasenack> that's good enough
<ahasenack> cjwatson: but then the other binary should have been removed too I think
<ahasenack> let me try to build it
<ahasenack> or maybe we want to transition to galera-4 instead of having both
<ahasenack> (different source)
<cjwatson> I admit I'm a little confused about why this was NBS
<cjwatson> https://launchpad.net/ubuntu/+source/galera-3/+publishinghistory suggests it's still there
<cjwatson> since the most recent version built that binary
<cjwatson> vorlon: ^- would you care to investigate/clarify?
<cjwatson> NBS removals are usually in bulk, but this does look a bit weird
<ahasenack> it just built fine in current focal-proposed
<ahasenack> vorlon: also, when you have a moment, I don't know how to solve https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/i386/k/krb5/20200121_135633_61618@/log.gz
<ahasenack> # apt install build-essential
<ahasenack>  build-essential : Depends: libc6-dev but it is not going to be installed or
<ahasenack>                             libc-dev
<ahasenack>                    Depends: g++ (>= 4:9.2) but it is not going to be installed
<ahasenack> goes all the way down to installing linux-libc-dev which wants to remove a bunch of :i386 packages
<Odd_Bloke> Is it Subiquity or SUbiquity?  (I'm seeing both capitalisations in places, and want to know which ones I should be proposing fixes for. :)
<ahasenack> I only saw subiquity so far
<ahasenack> rafaeldtinoco: the net-snmp update_output.txt list is smaller, did you check what is missing yet? I saw that google-cloud-print-connector migrated, that was the last one?
<rafaeldtinoco> ahasenack: i checked them all
<rafaeldtinoco> and updated the card ... but I *think*
<rafaeldtinoco> they were all done
<rafaeldtinoco> let me see the card
<ahasenack>     * i386: cluster-glue, colord, colord-tests, corosync-notifyd, libopenhpi-dev, libsane, libsane-dev, libsane1, openhpi-plugin-ipmi, openhpi-plugin-snmp-bc, openipmi, php7.3-snmp, sane-utils
<ahasenack> that is the current output
<rafaeldtinoco> frr missing s390x
<rafaeldtinoco> php7.3 arm64 3 issues
<rafaeldtinoco> s390-tools needs approval by hand
<rafaeldtinoco> sane-backends failed on gscan2pdf arm64
<rafaeldtinoco> those were the last issues i could see
<rafaeldtinoco> for the revdependencie on libsnmp35
 * ahasenack checks revdeps in focal-proposed
<ahasenack> hm, still many revdeps for libsnmp30
<ahasenack> libsnmp35 is the new one, right
<rafaeldtinoco> yep
<ahasenack> hm, reverse-depends isn't very smart, it's listing wnmd-snmp even though there is a build that doesn't depend in libsnmp30
<ahasenack> there could be an option to only consider the latest version of a package, if multiple come up
<rafaeldtinoco> yep =(
<ahasenack> rafaeldtinoco: weird, google-cloud-print-connector still depends on libsnmp30
<ahasenack> 1.12-1ubuntu1
<ahasenack> that's weird, build logs show it pulling in libsnmp35
<ahasenack> but in the end:  Depends: libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libc6 (>= 2.4), libcups2 (>= 1.7.0), libsnmp30
 * ahasenack checks if that isn't hardcoded
<ahasenack> argh
<ahasenack> rafaeldtinoco: you have a hardcoded libsnmp30 in d/control in that package
<rafaeldtinoco> =(
<rafaeldtinoco> damn
<rafaeldtinoco> i might have missed hardcoded libsnmp30
<rafaeldtinoco> you have to teach me the secret language you use to read the flags in the other excuses file
<rafaeldtinoco> =)
<ahasenack> oh, it's simple, it's always bad news
<ahasenack> :)
<ahasenack> do a rebuild of that package without that hardcoded dep and just make sure the automatic libsnmp35 dep is added, then it's good to upload
<ahasenack> and check if that came from debian
<ahasenack> might want to suggest the fix to them as well
<rafaeldtinoco> +1
<rafaeldtinoco> thx for checking all this
<rafaeldtinoco> ive been scripting for ours now
<rafaeldtinoco> need a coffee
<ahasenack> rafaeldtinoco: zabbix also needs a rebuild
<rafaeldtinoco> same issue ?
<rafaeldtinoco> i think i missed all hardcoded libsnmp30
<rafaeldtinoco> i assumed they were not hardcoded
<ahasenack> it's in your card, but shows a dep on the lib
<ahasenack> let me check d/control
<rafaeldtinoco> do not assume, check <- rule missed
<ahasenack> no, this one doesn't have libsnmp30 hardcoded
<ahasenack> where is your rebuild?
<ahasenack> https://launchpad.net/ubuntu/+source/zabbix/+publishinghistory I don't see it
 * rafaeldtinoco checks
<ahasenack> I'm going over it just because it's my triage/migration day :)
<rafaeldtinoco> AH
<ahasenack> so I see what is stuck and check why
<rafaeldtinoco> i thought the new build had fied the dep issue
<rafaeldtinoco> so I didnt upload it for a new build
<ahasenack> rafaeldtinoco: s390-tools is stuck because another source, called s390-tools-signed (https://launchpad.net/ubuntu/+source/s390-tools-signed) needs to match the same version
<ahasenack> it looks a bit weird. xnox, can you confirm? ^
<ahasenack> just needhttps://launchpad.net/ubuntu/+source/s390-tools and  need to match like that?
<ahasenack> if one is rebuilt/bumped, the other needs to as well?
<rafaeldtinoco> ahasenack: when I saw
<rafaeldtinoco> s390-tools needed autorization for migration
<ahasenack> ok
<ahasenack> right now it's "s390-tools/s390x unsatisfiable Depends: s390-tools-signed (= 2.11.0-0ubuntu2) "
<ahasenack> and it will block on openssl too
<gpiccoli> tnx a lot sil2100 and rbasak =)
<gpiccoli> sil2100, guess we should drop the current proposed for disco too
<gpiccoli> I didnt worked a debdiff for disco since the eol is in 3 days
<ahasenack> rafaeldtinoco: just so we don't overstep on each other, are you going to do those remaining net-snmp related fixes/uploads, or should I?
<ahasenack> I don't mind either way
<rafaeldtinoco> it's really low in my queue's priority ordering
<rafaeldtinoco> for now I'll consider you are doing it until you tell me to take it back
<rafaeldtinoco> sounds good ?
<rafaeldtinoco> (and tku if it does)
<ahasenack> rafaeldtinoco: cool
<vorlon> cjwatson, ahasenack: note that the galera-arbitrator-3 binary package I deleted was not built from the galera-3 source, but by a different source package which in turn had been removed from Debian unstable.  I was processing https://people.canonical.com/~ubuntu-archive/testing/focal_outdate_all.txt for $reasons and noticed this.  A no-change rebuild of galera-3 would bring it back, or I guess we
<vorlon> could do a binary copy of the current version.  This would be older than the 26.4.3-1 I deleted but that was only ever in focal
<vorlon> ahasenack: that krb5 autopkgtest failure looks similar to the ones that have been plaguing us on the gnome stack lately, and I don't know what's regressed and haven't been able to reproduce it locally
<vorlon> ahasenack: installing build-essential:amd64 is expected to work, and /does/ work, but something's gone wrong somewhere that I've not been able to see
<ahasenack> vorlon: I do see that build-essential failure locally on a container
<ahasenack> vorlon: i can do a galera-3 no-change rebuild
<vorlon> oh?
<vorlon> ahasenack: let me try to just resuscitate it first with a binary copy
<ahasenack> vorlon: https://pastebin.ubuntu.com/p/B4mfTxGGcT/
<ahasenack> valorie: ack on galera-3
<vorlon> ahasenack: ok so what does it think these conflict with?
<vorlon> ah
<ahasenack> vorlon: libc6-dev with linux-libc-dev, and linux-libc-dev tried to remove many *-dev:i386 packages
<vorlon> linux-libc-dev is missing in focal-proposed
<vorlon> so look for a linux build failure
<vorlon> tests with --all-proposed are going to fail until that's resolved
<ahasenack> https://pastebin.ubuntu.com/p/dR9c4q8CZG/
<ahasenack> yeah, linux is red
<ahasenack> vorlon: the "fix" for  s390-tools/s390x unsatisfiable Depends: s390-tools-signed (= 2.11.0-0ubuntu2) is to just do a rebuild of s390-tools-signed, now that s390-tools 2.11.0-0u2 is in f-proposed?
<vorlon> ahasenack: and for base packages that have libraries preinstalled in the autopkgtest VM image, testing /without/ all-proposed doesn't work until we fix autopkgtest to properly set pins for both the native and cross-arch packages; so maybe I'll work on that
<vorlon> ahasenack: sounds correct to me
<ahasenack> ok
<ahasenack> today is my day to chase down packages stuck in migration :)
<ahasenack> rafaeldtinoco: I'm baffled, there is no mention of snmp at all in the google-cloud-print-connector source code. I'm trying to track down why/when it was added, but this is old
<ahasenack> no binary it produces is dynamically linked with it
<rafaeldtinoco> :\
<rafaeldtinoco> lmtal
<rafaeldtinoco> commit 4edc895
<rafaeldtinoco> Merge: 5999b5a 6373ee6
<rafaeldtinoco> Author: Vitaly Buka <vitalybuka@gmail.com>
<rafaeldtinoco> Date:   Thu Feb 25 01:11:22 2016
<rafaeldtinoco>     Merge pull request #192 from jacobmarble/rm-snmp
<rafaeldtinoco>     Remove SNMP support.
<rafaeldtinoco> ahasenack: ^
<rafaeldtinoco> i guess thats because of this
<rafaeldtinoco> =)
<ahasenack> ohh
<ahasenack> good idea, check commit history
<rafaeldtinoco> i keep all upstream repos i ever played with
<rafaeldtinoco> updating in background
<rafaeldtinoco> so things like this are faster
<ahasenack> I just cloned, but didn't think of checking *that* history
<rafaeldtinoco> it was removed in 2016
<rafaeldtinoco> but this pkg wasnt touched since disco
<rafaeldtinoco> iirc
<ahasenack> thanks a lot, that makes it easier
<rafaeldtinoco> sure!
<ahasenack> rafaeldtinoco: https://pastebin.ubuntu.com/p/Y5QsK8jVvr/ ? Also submitted to debian at https://salsa.debian.org/go-team/packages/google-cloud-print-connector/merge_requests/1/diffs
 * rafaeldtinoco checks
<rafaeldtinoco> ahasenack: im +1, in doubt of big uri though
<rafaeldtinoco> would it be better commit "xxxx" ?
<ahasenack> it's within 80chars
<ahasenack> I shortened the hash
<rafaeldtinoco> yep, and its just a click away
<rafaeldtinoco> im +1
<vorlon> ahasenack: I've pushed a fix to the deployed autopkgtest branch that should correct the mis-pinning of cross packages and have retriggered krb5/i386 for openssl; let's see if this does it
<ahasenack> vorlon: nice, thanks
<vorlon> ahasenack: and galera-3 binaries are re-published now
<ahasenack> vorlon: I triggered the galera-3 tests under openssl
<vorlon> ok
<ahasenack> vorlon: I think http://autopkgtest.ubuntu.com/packages/g/gnutls28/focal/i386 is also the same problem wrt build-essential
<vorlon> ahasenack: voilÃ , krb5/i386 passed
<ahasenack> yay!
<vorlon> as did libssh
<vorlon> waiting to see results on gnutls28
<ahasenack> vorlon: so openssl will only remain stuck because of the kernel
<vorlon> ahasenack: have you talked to the kernel team about that?  I'm not sure what the failure there is (though it's clearly not caused by openssl)
<ahasenack> vorlon: no, xnox told me last week that "the kernel bug" was known and they were working on it
<ahasenack> they == kernel team
<vorlon> such tellings should come with links to bugs
<vorlon> :)
<ahasenack> yep, trust but verify :)_
<ahasenack> vorlon: "jan 16 09:37:46 <xnox>  i.e. linux => is being fixed by kernel team (python2 fallout)
<ahasenack> "
<vorlon> so anyway, I'll let openssl et al through if/when the kernel is the only blocker
<ahasenack> "jan 16 09:40:58 <xnox>  ahasenack:  i think we will be waiting on linux anyway atm. It is in progress being fixed, as per emails i got this morning."
<vorlon> right, that explains the build logs showing failures due to python-dev.  it doesn't explain the errors about linux source failing to unpack
<ahasenack> vorlon: ok, thanks
<ahasenack> autopkgtest [17:03:40]: ERROR: erroneous package: rules extract failed with exit code 1
<ahasenack> weird
<ahasenack> disk full?
<vorlon> the VMs are single-use so there shouldn't be anything else taking up space, and we test bigger sources than the kernel
<ahasenack> what was that package with a gigabyte, some latex/tetex font :)
<sarnold> 2.2 gig tarball? :)
<sarnold> -rw-r--r-- 1 lp_publish lp_publish 2261434398 Jul 23  2018 unidic-mecab_2.3.0+dfsg.orig.tar.gz
<ahasenack> wow
<ahasenack> vorlon: galera-3/arm64 is the only remaining red, and that's because the new run hasn't completed yet
<ahasenack> apart from linux, that is
<ahasenack> (this about openssl, sorry, writing it all backwards)
<WoC> oC
<WoC> Thais may be known already, but the installation iso (current version), both the 18.04.* and 19.10, the grub installation will fail when installing on a amd64 type computer with legacy BIOS and GPT partitions, even if the bios is able to handle the GPT and the special BIOS partition
<vorlon> ahasenack: could postgresql-plperl-12 be changed to Depend: perl:any instead of perl?
#ubuntu-devel 2020-01-22
<vorlon> ahasenack: hmm nevermind, wouldn't help because postgresql-server-dev-12 also Depends: clang-9 and I don't know that this could be made :any (but also, what's with dev packages specifying a compiler :P)
<WoC> Could be worse, it could be demanding cobol 1.0.1, which may be tricky to find ;)
<AsciiWolf> I have noticed that "info" package that is preinstalled on Ubuntu Focal contains a desktop file (/usr/share/applications/info.desktop) that adds a "TeXInfo" desktop entry that is shown among other (GUI) apps in Shell Overview
<AsciiWolf> this desktop item opens a terminal window with the info program
<AsciiWolf> I don't think it is a good idea to have something like this showing on a clean system installation since it is confusing for many (regular) users
<AsciiWolf> adding something like NotShowIn=GNOME; to the desktop file would solve this
<AsciiWolf> but I am not sure if info has an active maintainer in Ubuntu or is just synced from Debian
<AsciiWolf> I have made a Launchpad ticket for this: https://bugs.launchpad.net/ubuntu/+source/texinfo/+bug/1859963
<ubottu> Launchpad bug 1859963 in texinfo (Ubuntu) "Info package on Ubuntu Focal comes preinstalled with desktop file" [Undecided,New]
<rbasak> ahasenack: import complete for netcfg
<rbasak> But it looks like it hasn't changed since Feb 2019
<rbasak> So I'm not sure it actually did anything
<ahasenack> ok
<rbasak> Maybe it updated the branch pointers only
<juliank> AsciiWolf: I feel like GNOME should just hide applications with Terminal=true in a subfolder
<juliank> e.g. "Terminal applications"
<AsciiWolf> juliank, hmm, I am not sure... however the info.desktop does not have Terminal=true
<juliank> AsciiWolf: Well sure it has
<juliank> It's Exec=info\n[...]\nTerminal=true
<AsciiWolf> juliank, really? that's weird
<AsciiWolf> then I am not sure why it shows on latest Ubuntu Focal among other apps
<ahasenack> rbasak: hi, could you please give me some help in figuring out why bind9 is stuck in migration?
<ahasenack> I rebuilt every reverse-deps I could find
<ahasenack> the only ones I can't really test are the udeb ones
<ahasenack> but I did upload debian-installer, which is all that it took in the previous bind9 soname bumps I have done
<ahasenack> but now some guestfs packages are showing up in update_output.txt
<ahasenack> I installed all os those in amd64 and s390x, then removed all previous bind9 libs, and nothing else was removed. The old bind9 libs were even in the autoremove suggestion list
<ahasenack> I'm also trying now on s390x, which has nbdkit-plugin-guestfs
<ahasenack> (not available in amd64)
<ahasenack> but that also installs fine
<ahasenack> and I don't see how that relates to the bind libs
<ahasenack> or isc libs
<ahasenack> maybe it's debian-installer-udebs on s390x
 * ahasenack starts downloading individual udeb packages
<rbasak> Looking
<rbasak> Yeah I think it's udeb related
<rbasak> But amd64 also, not just s390x
<ahasenack> ok
<ahasenack> rbasak: do you know of any way to easily check udebs, other than downloading them and dpkg -i each one?
<ahasenack> i.e., something apt related
<rbasak> I was just looking in to that.
<rbasak> I want to add debian-installer to chdist
<ahasenack> I'm using pull-lp-udebs for now
<rbasak> I haven't found a way yet
<rbasak> isc-dhcp-client-udeb is one
<ahasenack> one what?
<rbasak> That'll need rebulding I think. It needs libdns-export1104-udeb for example but the new bind9 is making libdns-export1107-udeb
<ahasenack> I did rebuild isc-dhcp, isn't that where the udeb comes from?
<rbasak> Ah maybe I'm looking at the release pocket
<ahasenack> https://launchpad.net/ubuntu/+source/isc-dhcp/4.4.1-2ubuntu6 is the rebuild
<ahasenack> ubuntu6
<rbasak> ahasenack: I'm not sure if I'm just catching up with your understanding here
<rbasak> debian-installer-udebs in focal-proposed still depends on libdns-export1104-udeb and libisc-export1104-udeb
<rbasak> (amd64)
<ahasenack> hm
<ahasenack> let me see the rebuild logs
<rbasak> And also libisc-export1100-udeb
<ahasenack> maybe I uploaded it too soon :/
<rbasak> I did work out how to get chdist working with debian-installer
<rbasak> http://paste.ubuntu.com/p/WJF4SZgJHQ/ for example works
<ahasenack> Get:9 http://ftpmaster.internal/ubuntu focal/main/debian-installer amd64 isc-dhcp-client-udeb amd64 4.4.1-2ubuntu5 [210 kB]
<ahasenack> it grabbed the old one indeed
<ahasenack> same for bind
<ahasenack> ok, that explains it
<ahasenack> I'll upload again
<ahasenack> rbasak: thanks!
<rbasak> https://pastebin.ubuntu.com/p/CpKH2dYYMq/ is what gave me the answer in the end
<rbasak> You're welcome!
<ahasenack> what's chdist-if-migrated?
<rbasak> ahasenack: http://paste.ubuntu.com/p/M57JwfjFFW/
<ahasenack> cool
<AsciiWolf> juliank, I just re-checked it on latest Ubuntu Focal, TeXInfo is showing in Shell Overview although it's desktop file contains "Terminal=true"
<AsciiWolf> are you sure that desktop files for terminal applications are normally not showing in GNOME?
<juliank> AsciiWolf: No, I meant that GNOME should stop showing them
<AsciiWolf> ah :-)
<AsciiWolf> I agree
<ahasenack> rbasak: bind9 migrated, thanks again for your help
<tjaalton> I have a (non-root) zfs mirror on focal, and need to import it after each reboot.. how to fix that?
<tjaalton> seems it's bug 1850130
<ubottu> bug 1850130 in zfs-linux (Ubuntu) "zpools fail to import after reboot on fresh install of eoan" [Undecided,Confirmed] https://launchpad.net/bugs/1850130
<ahasenack> rbasak: hi, quick help again if you are still around
<ahasenack> I think doko removed nut from the archive
<ahasenack> see https://launchpad.net/ubuntu/+source/nut/+publishinghistory and the output of "rmadison nut"
<ahasenack> that only shows nut in focal-proposed
<ahasenack> which was kanashiro's upload
<ahasenack> we didn't know nut was removed
<ahasenack> it's a server package :/
<doko> ahasenack: let me look ...
<ahasenack> k
<doko> both nut and net-snmp are valid candidates
<ahasenack> I'm troubleshooting the net-snmp migration, and found this oddity about nut
<ahasenack> that is't not in the release pocket
<ahasenack> can't say yet it's what is causing the migration to fail, I just spotted it
<ahasenack> it's built with the right libsnmp35 lib, so that's good
<doko> needs a rebuild
<doko> no
<ahasenack> nut-snmp has Depends: nut (>= 1.4.1-pre1), libc6 (>= 2.28), libsnmp35 (>= 5.8+dfsg)
<doko> ok, you're right
<ahasenack> ok, and I think I found the culprit
<ahasenack> libsane
<doko> ahasenack: looking at the last occurrence of net-snmp in https://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt shows you that nut is not blocking
<doko> yes, libsane is among those
<ahasenack> and it all boils down to a dep8 failure in arm64 for gscan2pdf which blocked sane-backends in proposed (which is built with the right libsnmp35)
<ahasenack> ok
<ahasenack> what a rabbit hole
<ahasenack> sorry for the nut alarm
<doko> nuts
<ginggs> sounds more like a squirrel hole
<ahasenack> nuts at the end
<ahasenack> man, that test passed just once in 13 runs
<ahasenack> http://autopkgtest.ubuntu.com/packages/g/gscan2pdf/focal/arm64
<ahasenack> even worse if I count all runs in that page
<ahasenack> sea of red
<doko> ahasenack: the problem is the amount of triggers you need ... and all-proposed=1 doesn't work because the current arm64 kernel is broken because it was built with a bad binutils
<ahasenack> you think gscan2pdf/arm64 is failing because it needs selected packages from proposed?
<doko> hmm, no, looks more like a perl package
<ahasenack> doko: I can reproduce that hang in gscan2pdf/arm64
<ahasenack>   54751 pts/0    Sl+    0:01                                                      \_ /usr/bin/perl t/06190_Dialog_Scan_Image_Sane.t
<ahasenack>  (the next test to be run) is stuck
<ahasenack> t/0618_Dialog_Scan_Image_Sane.t ............... ok <-- last one logged in the output
<ahasenack> I can work with this, maybe even disable just that one test if it comes to it
<allquixotic> In terms of testing and bug reports, what is needed for Focal right now? I'm a developer (though not a current contributor to Ubuntu, I have an LP.net account, etc.) and I just updated my laptop from 19.10 to the latest 20.04 packages. I know testing week happened recently but I'm happy to give my 2 cents now as well, and will be on the hunt for obvious bugs while using the system.
<sarnold> allquixotic: I think it's probably a bit underwhelming as an answer -- use your system and report bugs as you find them :)
<ddstreet> rbasak any change you could import ubuntu-dev-tools into git-ubuntu?  doesn't seem to be there currently
<zyga> focal updates crash on ubuntu-release-upgrader: https://pastebin.ubuntu.com/p/zj92spzYNF/
<ahasenack> zyga: worth a bug against the release upgrader?
<zyga> yeah, I think so
<mwhudson> xnox: 57pollinate is not +x in the casper in bionic proposed :(
<zyga> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1860606
<ubottu> Launchpad bug 1860606 in ubuntu-release-upgrader (Ubuntu) "TypeError: _fetch_archives() missing 1 required positional argument: 'allow_unauthenticated'" [Undecided,New]
<bryce> allquixotic, apart from finding new bugs, as a tester another great way to help any open source project is to review existing bug reports and see if you can reproduce them, and if so add your findings to the existing bug report.  If there's patches or ppas proposed, verifying those fixes can be super helpful.
<sarnold> mdeslaur, juliank, ^^ -- this feels ever so vaguely like this may be a regression https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1860606
<mwhudson> oh well easy to fix
<allquixotic> bryce: Sure thing. So far things seem _really_ smooth on KDE Plasma. The only thing I had to go off the rails to support is my external GPU; I am using a PPA for egpu-switcher that runs on boot, detects whether the eGPU is attached, and symlinks in an appropriate Xorg.conf. Not sure if eGPU support is planned for Ubuntu-Gnome3 or KDE Plasma for 20.04.
<allquixotic> It's "supported" at a hardware level for sure, as I can get it working without issue once egpu-switcher puts in the right Xorg.conf -- my GPUs are an Intel IGP, an Nvidia dGPU in the laptop, and an Nvidia eGPU -- but there's no nice GUI for switching/selecting the GPU. I think pop! OS has that.
<mdeslaur> juliank: looks like you forgot to fix aptdaemon in focal
<mdeslaur> sarnold: fyi ^
<sarnold> mdeslaur: is this running focal code? or eoan code?
<zyga> sdhd-sascha: eoan updating to focal
<zyga> er
<mdeslaur> sarnold: focal, and I confirmed atdaemon isn't patched in focal
<zyga> sarnold:
<zyga> sarnold: I was running eaon at the time, focal update was initiated with do-release-upgrade -d
<zyga> (when it crashed and burned I did it manually)
<sdhd-sascha> hey, zyga :-)
<zyga> hey :)
<mdeslaur> sarnold: I think /me shrugs
<mdeslaur> or perhaps eoan wasn't updated before the update to focal
<zyga> eoan was freshly updated all the way
<zyga> I was going from 19.04 to 19.10 (fully including reboot)
<zyga> then to 20.04
<sdhd-sascha> zyga: hmm ... what should a distributor do... support all ... or give for each hardware, a branch....
<zyga> sdhd-sascha: ?
<sdhd-sascha> zyga: well, then all ;-)
<sarnold> the other user in #ubuntu who is reporting this same problem also said that python-apt was updated just before starting the do-release-upgrade
<sdhd-sascha> sarnold: what problem ?
<sdhd-sascha> i'm new here... and can test...
<sarnold> sdhd-sascha: when upgrading from eoan to focal, this error message https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1860606
<ubottu> Launchpad bug 1860606 in ubuntu-release-upgrader (Ubuntu) "TypeError: _fetch_archives() missing 1 required positional argument: 'allow_unauthenticated'" [Undecided,Confirmed]
<sdhd-sascha> hey, of course. But the message says, that it's sure that one argument is missing ;-
<sdhd-sascha> )
<mdeslaur> oh right, looks like ubuntu-release-upgrader needs a fix
<mdeslaur> juliank: ^
<zyga> "run focal they said"
<sarnold> still gotta admit it found a bug, right quick too :)
<mdeslaur> this is going to fail on every release
<sdhd-sascha> zyga: thank you ... really, i like to test the next version ;-)
<sdhd-sascha> zyga: but i don't remember what this python library calls... (ncurses thing)
<zyga> sdhd-sascha: I don't know what you mean
<sdhd-sascha> ...widget...
<sdhd-sascha> wait...
<bryce> allquixotic, external GPU sounds like something that would best be worked on directly upstream
<sdhd-sascha> hey, folks... how can ubuntu in future installed without be hardware aware ?
<sdhd-sascha> i don't nknow.
<sdhd-sascha> i try to build a limited snap... with seccomp and apparmor... but didn't know if the user had nvidia or amd... what should i limit or do ?
<juliank> mdeslaur: oh yes
<juliank> mdeslaur: I forgot to fix aptdaemon in focal
<mdeslaur> juliank: yeah, but unrelated in this specific issue
<sdhd-sascha> hey, i wonder, is mesa packages better - or non mesa ?
<sdhd-sascha> zyga: you can ask tomorrow. it's not your timezone;-) what version could land into 20.04?
<sdhd-sascha> hey, should i upgrade tomorrow ? or will the new kernel .... ...
<sdhd-sascha> ...
<sdhd-sascha> (i'm not kernel .. but developer)
<CarlFK> a while ago I brought up  bug #1807047
<ubottu> bug 1807047 in debian-installer (Ubuntu) "sync hd-media FLOPPY_SIZE with debian" [Undecided,Won't fix] https://launchpad.net/bugs/1807047
<CarlFK> someone said something like "ubuntu is moving away from di"
#ubuntu-devel 2020-01-23
<CarlFK> to a new thing that uses yaml ... are there images using this yet?
<tjaalton> CarlFK: it's called subiquity, and the current focal images should use it aiui
<CarlFK> tjaalton: thanks
<tjaalton> server image that is
<xnox> mwhudson:  arrrrrrrrgh
<JackFrost> International pirate day?
<mwhudson> xnox: p. much
<mwhudson> xnox: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/bionic/ubuntu-server-live/+build/200376 has new casper, not sure image has been published yet though
<mwhudson> (it hasn't)
<CarlFK> tjaalton: any idea why this is now an iso9660?  (which is RO, so I can't mount and tweek it's boot parameters) http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/images/hd-media/
<tjaalton> no
 * CarlFK crys 
<alkisg> Hi all. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792687 recommends NOT regenerating the .pot file on each build, yet python-distutils-extra's build_i18n.py does that unconditionally. Any way around it, or any other advice?
<ubottu> Debian bug 792687 in src:gettext "gettext: please support timestamps from environment" [Wishlist,Fixed]
<xnox> jibel:  bdmurray: is this critical for .4 release? https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1860559 and do we need ask kernel team to fix this; or should we promote finalrd to main and make casper depend on it. As far as I can tell it's installer failing to reboot, rather than installed systems.
<ubottu> Launchpad bug 1860559 in linux (Ubuntu Bionic) "[18.04.4] System fails to reboot after installation" [Critical,Confirmed]
<xnox> sil2100:  ^
<sil2100> xnox: I would like the kernel team to take a look and see what caused the regression, at least for now. Didn't dive into the bug so I'm not saying no to the finalrd approach, but before making a decision it would be wise to know what the fudge happened
<rbalint> update_excuses is quite outdated :-(
<rbalint> sil2100, , could you please trigger it? ^
<cjwatson> update_excuses is updated automatically as fast as it can go.  If it's outdated then it's not just a matter of triggering it.
<cjwatson> Also it's only 14 minutes old.
<cjwatson> Updated seconds after you asked, I think (the timestamp that's 14 minutes old is probably when the process started; the mtime on the filesystem is about three minutes old)
<rbalint> cjwatson, thanks!
<sil2100> rbalint: which update_excuses do you mean? Since if it's about the focal one, it's as cjwatson mentioned
<rbalint> sil2100, cjwatson when i asked it was from 2020.01.22 21:06:24 +0000
<rbalint> sil2100, cjwatson i think ~11 hours is a bit long between updates, maybe something regressed and became very slow
<sil2100> uh, sounds very unlikely, you sure you didn't have some cached version on your browser? I don't think britney ever took so long
<sil2100> I can actually check the logs, wait
<sil2100> rbalint: looking at the logs, it looks like britney was rather running as expected
<rbalint> sil2100, strange, i tried refreshing
<sil2100> rbalint: https://people.canonical.com/~ubuntu-archive/proposed-migration/log/focal/2020-01-23/
<rbalint> sil2100, i'll check with wget next time
<rbalint> sil2100, cjwatson sorry for the noise then
<sil2100> rbalint: no worries! It still might have been something fishy indeed, but at least from the britney POV it seemed to be working as intended
<bdmurray> sil2100: who will chase down the kernel team regarding that 18.04.4 bug?
<sil2100> bdmurray: if xnox didn't yet, I will poke them in a moment
<sil2100> bdmurray: jibel poked them already, I'll follow up as well
<rbasak> waveform: we should discuss this in public really, so let's chat here
<waveform> rbasak, sure
<rbasak> The planned flash-kernel change fixes a race that already sort of exists I think
<rbasak> So perhaps we can land the u-boot-rpi changes now, certainly in Focal
<waveform> rbasak, a race? Where's that?
<rbasak> That without the Depends it's possible flash-kernel will be deconfigured
<waveform> ah yes - of course, and now it'll ensure it runs anyway
<rbasak> Does the Breaks then need to be bumped to refer to the version where we fix this in flash-kernel - for Bionic or Focal or both?
<waveform> hmm - the Breaks was mostly to do with the issue that the proposed u-boot will not accept the uboot.env from older f-k's (only applicable to the bionic pi2 image, but still) - but if we're relying on the new f-k trigger behaviour then it probably would be sensible to bump it up
<rbasak> It would ensure that an older flash-kernel won't be running at the time the postinst runs
<rbasak> And flash-kernel will be upgraded if was installed at some point during a full upgrade
<waveform> yup - sounds good - I'll tweak that commit; would I be right in thinking focal will be 2019.07+dfsg-1ubuntu4 and bionic will be 2019.07+dfsg-1ubuntu3.18.04.1 ?
<rbasak> Hang on
<rbasak> I'm not certain the Breaks needs to be bumped!
<rbasak> And do we know the version of flash-kernel that will be uploaded?
<rbasak> This mess is complicated :(
<rbasak> ddstreet: ubuntu-dev-tools imported
<rbasak> It'll be manual until my whitelist change lands
<waveform> rbasak, doh! Was looking at the u-boot versions - just a mo
<waveform> rbasak, well - f-k will be jumping from 3.90<stuff> to 3.98<stuff> on bionic so presumably it would be sufficient to just have Breaks: << 3.98
<ahasenack> tribaal: hi, about your kitty tip, nice terminal, but I'm finding myself having to install kitty-terminfo in all remote servers I log into :/
<tribaal> ahasenack: for me it's only a problem if I want to tmux inside of (Ubuntu) remotes
<tribaal> just SSH seems to work out of the box
<ahasenack> tribaal: saw that with tmux, yes, but just now saw that backspace didn't work without the terminfo package
<tribaal> oh?
 * tribaal tries
<ahasenack> maybe something in focal, though. It was a focal lxd I started up
<tribaal> works fine here on a 16.04 remote
<tribaal> having the terminfo installed by default in focal would be nice
<tribaal> but I guess that'd be a thing to send to upstream terminfo if there's such a thing :)
 * tribaal tries on a focal lxd as well
<tribaal> ahasenack: silly question: how do you launch a focal LXD? I see to remember there was a special alias for in-devel distros, but I can't remember what
<ahasenack> tribaal: lxc launch ubuntu-daily:focal
<tribaal> ahhh ubuntu-daily: that's the trick :)
<tribaal> ahasenack:thanks
<tribaal> ahasenack: indeed, backspace doesn't work via SSH on eoan/focal apparently
<tribaal> works fine on bionic however
<ahasenack> interesting
 * tribaal tries disco
<tribaal> disco fails as well
<tribaal> yep, just tried on our platform as well - it's not LXD-related
<tribaal> works on bionic, but not on disco+
<ahasenack> lxd or not?
<tribaal> ahasenack: correct. For disco+ the backspace key doesn't work on LXD and on "normal" virtualisation
<tribaal> for bionci the backspace key seems to behave properly in both cases
<tribaal> (LXD and non-LXD)
<ahasenack> tribaal: I also seem to have lost my prompt colors
<ahasenack> noaha
<ahasenack> case "$TERM" in
<ahasenack>     xterm-color|*-256color) color_prompt=yes;;
<ahasenack> esac
<ahasenack> but TERM is xterm-kitty
<tribaal> ah ha
<tribaal> ahasenack: does it behave like this on bionic as well? I wonder why the backspace works there and not later
<ahasenack> I'm on eoan
<ahasenack> TERMs are complicated
<tribaal> ahasenack: I'm on eoan as well, but connecting to bionic
<rbalint> apw, could you please merge this hint for systemd? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/377998
<apw> rbalint, could you check line 14
<rbalint> apw, thanks, fixed!
<rbasak> waveform: on u-boot, give me a few minutes to think this through
<waveform> rbasak, no prob
<rbasak> Which branches exactly are ready?
<rbasak> sru-pi4 preferred for both?
<rbasak> waveform: do you have an LP bug ready? We'll need that for the SRU at a minimum
<rbasak> But probably best to write everything up there
<rbasak> Together with the required SRU paperwork
<waveform> rbasak, yup - oh, I need to update the branch links though - just a mo
<waveform> rbasak, LP: #1846329
<ubottu> Launchpad bug 1846329 in u-boot (Ubuntu Bionic) "[SRU] 2019.07 to support Pi4 boot" [Undecided,In progress] https://launchpad.net/bugs/1846329
<waveform> rbasak, and just for reference the f-k one is LP: #1847587
<ubottu> Launchpad bug 1847587 in flash-kernel (Ubuntu Bionic) "[SRU] Add entries for Pi 4" [Undecided,Fix committed] https://launchpad.net/bugs/1847587
<waveform> (should have the correct branch links in there too now)
<rbasak> waveform: you still need the trigger thing, don't you?
<rbasak> Because if flash-kernel is upgraded first and entirely, then the u-boot-rpi upgrade won't cause flash-kernel to run again otherwise?
<waveform> rbasak, that doesn't matter - u-boot copies itself into the boot partition (it shouldn't but as discussed with infinity on -release last night that's a bigger fix than we want to do right now); so if flash-kernel goes first then it'll already have updated the boot scripts, then u-boot updates (and updates itself)
<rbasak> OK, thanks.
<rbasak> Sorry, I had my head round this on Tuesday, but keeping my head around the complexities is quite difficult!
<waveform> rbasak, no prob - I know the feeling :)
<rbasak> dannf: o/
<rbasak> dannf: do you have any interest currently in u-boot or flash-kernel?
<dannf> rbasak: hi - no, i don't
<rbasak> np, thanks.
<rbasak> We're about to do a major SRU, so I thought I'd check.
 * ahasenack has a pi4 with focal
<ackk> hi, I have a tricky deb question. package A is using dbconfig-common to manage a postgres database. now I want to replace A with B (which has Breaks/Replaces/Provides: A). when A gets removed, it asks if the database should be purged. I need that not to happen, is there a way to preseed that answer from scripts in  B?
<rbasak> waveform: so I'm uploading f8f21a5 to Focal, right?
<waveform> rbasak, yup - that looks right
<rbasak> You don't mention the shebang drop in that chagnelog entry. Intentional?
<rbasak> waveform: ^
<rbasak> In Bionic, you want 2019.07+dfsg-1ubuntu3~18.04.1 instead of 2019.07+dfsg-1ubuntu3.18.04.1 since we need it to be lower than the version in Focal. I can tweak that.
<waveform> rbasak, hmm - what's the rules surrounding purely cosmetic changes?
<rbasak> waveform: fuzzy. I don't mind either way.
<rbasak> What about Disco and Eoan?
<waveform> in that case, let's say intentional (rather than "Dave forgot at whatever the unholy hour was last night" :))
<rbasak> :-)
<rbasak> Disco is EOL now
<rbasak> But usually we need to SRU Eoan too
<rbasak> Sorry I hadn't looked at that before.
<rbasak> vorlon: opinion on Eoan? ^
<rbasak> I'm happy to upload your Focal branch
<rbasak> Bionic is ready to go with that tweak.
<rbasak> Just the Eoan question. That's more of an SRU hat thing.
<waveform> Disco's already EOL and Eoan already has pi4 support so from that perspective there's no absolute requirement - but the f-k changes are probably sufficiently important to SRU; the u-boot changes may be relevant for anyone upgrading from bionic
<rbasak> Oh, the versioning is good
<rbasak> Because you're using ubuntu3
<waveform> well ... I'm using whatever dch -i gave me frankly ... really hadn't thought that hard about it
<rbasak> Let's say we land your branch as-is right now (with the minor version string tweak to ~ for Bionic)
<rbasak> Then what will happen if a user upgrades to Eoan?
<rbasak> Eoan has 2019.07+dfsg-1ubuntu3, which doesn't include your planned changes in Focal 2019.07+dfsg-1ubuntu4
<rbasak> Actually let's defer that.
<rbasak> I'll leave a note in the bug.
<waveform> just checking something ... okay, there's a potential issue in the case that they're upgrading from the weirdo pi2 image with the differing root file-system label, and the fix for the 3A+ booting is also missing
<rbasak> Let's at least put the thing in bionic-proposed assuming the SRU hat is happy. I don't think an Eoan fix will require a change to the Bionic upload.
<rbasak> You might need to backport the fixes in Focal back to Eoan in an SRU.
<rbalint> sil2100, coult you please merge this for the libnfs transition? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/378003
<waveform> okay - I'll prep and Eoan branch
<rbasak> That should be checked before the Bionic SRU is released I think.
<waveform> *an
<rbalint> doko, could you please do that? LP: #1860698
<ubottu> Launchpad bug 1860698 in skiboot (Ubuntu) " Please remove i386 binaries for 6.5-1" [Undecided,New] https://launchpad.net/bugs/1860698
<rbasak> waveform: uploaded
<rbasak> waveform: please get yourself PPU for u-boot :-P
<waveform> rbasak, thanks - will try!
<rbasak> waveform: FTBFS :-/
<rbasak> Looks like some Python thing
<rbasak> Can I leave that with you?
<waveform> rbasak, bizarre ... built in the PPA - yup, leave it with me
<rbasak> waveform: maybe a component mismatch?
<rbasak> If your PPA has universe visible. u-boot being in main does not for archive builds.
<rbasak> Although
<waveform> bah "Depends: libpython-dev but it is not going to be installed"
<rbasak> Actually, didn't that chagne a while back?
<rbasak> Anyway, I'll leave it with you :)
<ahasenack> was in main in disco, not so much for eoan
<doko> rbasak: I'll leave the i386 removals with vorlon
<ahasenack> disco and before, that is
<waveform> no idea (if that changed a while back) - but yeah, I'll dig into it
<doko> waveform: libpython2-dev
<doko> for a quick fix
<ahasenack> also in universe for eoan+
<doko> waveform: which package is this?
<waveform> doko, u-boot-rpi (from u-boot)
<doko> I'll have a look to built it
<sil2100> rbalint: ACK
<doko> waveform: https://paste.ubuntu.com/p/rhDdKKFfny/   not checked. please make sure that the binary package has the correct dependencies and uses python2 as the shebang
<waveform> doko, thanks - will do
<waveform> rbasak, I've incorporated doko's python2 patch (plus some extra fixes for any/all bare "python" shebangs I could find) into the focal-clean-up branch, rebased and pushed that - just building the pkg in a PPA again
<waveform> rbasak, okay - ignore me - still got a build failure - having a look
<ahasenack> autopkgtest is driving me nuts, why isn't it adding deb-src lines anymore?
<ahasenack> failed with stderr "E: You must put some 'source' URIs in your sources.list
<ahasenack> autopkgtest -o dep8 -U -s --apt-pocket=proposed=src:php7.3 ./php-doctrine-dbal-2.10.1/ -- lxd ubuntu-daily:focal
<ahasenack> that is my command line
<ahasenack> before I had -B, because this package doesn't need rebuilding
<ahasenack> same thing
<waveform> rbasak, if you're still around: got a u-boot version that builds in -proposed now - I've pushed the rebased branch which has one additional commit at the top to handle the python 2 switchover; all subsequent commits are unaltered
<coreycb> tjaalton: Hi, I see you're on sru rota tomorrow. if you have a chance would you be able to take a look at the the openstack uploads in unapproved queues for bug 1858933 and bug 1723030?
<ubottu> bug 1858933 in octavia (Ubuntu Eoan) "[SRU] train stable releases" [High,Triaged] https://launchpad.net/bugs/1858933
<ubottu> bug 1723030 in python-oslo.policy (Ubuntu Bionic) "Under certain conditions check_rules is very sluggish" [Medium,Triaged] https://launchpad.net/bugs/1723030
<tjaalton> coreycb: ok
<coreycb> tjaalton: thanks
 * mwhudson rubs his eyes
<mwhudson> autopkgtest --apt-pocket=proposed -U . fails in the build step
<mwhudson> sbuild -d focal passes
<mwhudson> how does that happen?>
<mwhudson> (for python-jsonschema fwiw)
<mwhudson> if this pure python test depends on the running kernel version i am going to be very angry
<mwhudson> ah i think the failing tests are skipped in the sbuild case for some reason
<mwhudson> ah because python3-json-pointer is not installed in sbuild
<mwhudson> why the heck is it in cloud-images
<mwhudson> cloud-init -> python-jsonpatch -> python-json-pointer
<vorlon> doko, rbasak: ugh why is that skiboot binary there?  looking to see why my scripts haven't already removed it
<vorlon> uh weird it's an arch: all binary
<vorlon> so that's why
<rbasak> waveform: can you give me a commit with an archive-suitable changelog please?
<rbasak> With 2019.07+dfsg-1ubuntu4 in focal-proposed, it needs to be 2019.07+dfsg-1ubuntu5 presumably
<vorlon> Laney: do you have any idea about the autopilot-gtk/arm64 autopkgtest failure with new glib2.0? autopilot-gtk itself is uninteresting and will probably be removed as unmaintained (python2), but I'm not sure whether the failure represents a glib2.0 regression
#ubuntu-devel 2020-01-24
<Eickmeyer[m]> Can we get another set of eyes on https://code.launchpad.net/~ubuntustudio-dev/+git/ardour ? teward and I are kinda stumped as to why debhelper isn't populating packages.
<Eickmeyer[m]> Log file here in my PPA: https://launchpad.net/~eeickmeyer/+archive/ubuntu/ppa/+build/18604635
<teward> or more specifically
<teward> why the built binaries aren't picked up
<teward> in the ardor package.
<teward> ardour*
<infinity> teward: You almost certainly want override_dh_auto_install, not override_dh_install.
<infinity> teward: auto_install is the one that attempts to rnu "make install" or equivalent.
<teward> Eickmeyer[m]: ^
<Eickmeyer[m]> infinity: On it. Thanks.
<teward> Eickmeyer[m]: running that in sbuild locally atm
<teward> infinity: thanks for the extra set of eyes, this package is a tad janky :P
<Eickmeyer[m]> infinity: Interestingly enough, that package came straight from Debian, and the rules file is only slightly modified.
<roadmr> is there a way to find how popular a given .deb package is? even a ballpark figure will suffice, if possible.
<Eickmeyer[m]> infinity: Per teward, that FTBFS on his system.
<teward> trying to get builds up
<Eickmeyer[m]> still testing with my PPA.
<teward> https://paste.ubuntu.com/p/D3dnpvCY9v/ <-- excerpt of the 36k lines of logs where it fails
<teward> i wonder if this indicates an issue with the *package itself*
<Laney> vorlon: suspicious that the no-change rebuild for the new libffi broke it
<Laney> seems better with everything from focal-proposed
<doko> so is the arm64 kernel working again in -proposed?
<doko> otoh I'm told that I shouldn't use all-proposed=1, but figure out the triggers ;p
<doko> the libffi build didn't break it, no
<rbalint> sil2100, i've hinted the wrong version of gvfs, could you please fix it? https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/378016
<seb128> rbalint, sil2100 , I think there is a real problem with gvfs tests now, that skip feels wrong
<rbalint> seb128, is there a problem with gvfs or just with the tests?
<seb128> rbalint, I don't know, I've been pocking a bit earlier but didn't get to the bottom of it yet
<seb128> rbalint, webdavs tests are hanging, they were failing earlier because of the libssl changes and the test certificate being too weak, but I got that fixed yrsterday
<seb128> now they are to hang
<seb128> which feels like might be another certificate/ssl problem
<rbalint> seb128, sounds like a badtest, still
<seb128> rbalint, well unless the gvfs webdav code has some real issue with recent libssl...
<seb128> and that webdav access would hang the same way on a real system than it does in the tests
<rbalint> seb128, it is reproducible locally in qemu
<rbalint> seb128, could you please find out if it is a test bug or a real issue?
<rbalint> seb128, gvfs holds back the libnfs migration and the package set keeps collecting new ones with syncs
<seb128> rbalint, trying but I'm in CapeTown and travelling back a bit later
<seb128> rbalint, I think it's fine to ignore the tests to unblock libnfs since we already did that and the current focal gvfs is already buggy so it's not like we forcing a regression in
<seb128> but then we should fix the issue/tests
<rbalint> seb128, sure, later then
<rbalint> sil2100, ^
<sil2100> seb128: thanks for looking into this
<sil2100> rbalint: ACK
<sil2100> rbalint: ah, crap, all those version numbers just blurred for me yesterday
<rbalint> sil2100, you see, i had the same problem :-)
<Laney> doko: works if I add pygobject and gobject-introspection from proposed
<doko> Laney: could you do that for the other pygobject related stuff as well?
<Laney> will I make broken stuff migrate?
<Laney> feel like we should make those two become candidates first
<Laney> or
<Laney> ?
<doko> pygobject triggered tests block libffi
<Laney> I guess they'd get blocked by the transition anyway right?
<Laney> yeah
<Laney> ok
<doko> there's still some haskell stuff
<doko> ghc encodes libffi into every package whether it needs it or not
<waveform> rbasak, what's your preference for the commit updating the changelog? Should I drop the PPA bump commits and revise the entry in a new commit at the end, or rebase the history so the changelog was "always" correct?
<rbasak> waveform: I would prefer to be given a branch tip that has everything correct including the changelog ready for upload, but I'm happy to be given a commit hash of a preceding commit instead. Personally I don't bother committing the PPA changelog bumps, leaving those in a dirty worktree instead.
<waveform> rbasak, no prob - I'll chop those PPA bumps and stick a commit on the tip that fixes up the changelog for upload
<rbasak> Thanks!
<waveform> rbasak, done - branch tip at https://code.launchpad.net/~waveform/ubuntu/+source/u-boot/+git/u-boot/+ref/focal-clean-up should be upload-ready
<juliank> doko: Ok, let's talk here, it seems that the tests are stuck in /usr/bin/mpirun -np 4 ./ams_driver -solver 5 -tol 1e-4
<juliank> Thoug stuck might be the wrong word - there are 4 ams_driver processes, each using 400% CPU
<juliank> I rebuilt the tests with -g and gdb'ed in
<juliank> and straced
<juliank> they did not make any syscalls, but were in exec_blas_async_wait
<doko> ginggs: ^^^
<doko> juliank, even with the debug build?
<juliank> doko: if you mean the -g build I made, then yes
<juliank> doko: Without -g, I could not get any backtrace at all
<rbasak> waveform: ack, will look at it shortly
<doko> juliank, so it also failed with openmpi 3
<rbasak> waveform: since 2019.07+dfsg-1ubuntu4 is in focal-proposed and that version is "burned" I believe it should remain in the changelog as its own entry, and your ubuntu5 changelog entry should only mention changes from ubuntu4.
<rbasak> Unless someone here disagrees with me?
<juliank> doko: it did?
<rbasak> Otherwise it's confusing
<rbasak> Single source of truth being Launchpad and all that
<rbasak> The changelog history should try to match Launchpad's history where possible
<rbasak> (and when it makes sense, ie. maybe not for backports etc)
<juliank> sil2100: re: your retry of hypre with openblas/0.3.7+ds-1  - that does not work, it still pulled in openblas/0.3.7+ds-7, as the version is more or less ignored
<doko> juliank: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-focal/focal/armhf/h/hypre/20200101_130655_5e13f@/log.gz  succeeded with 4.0.2
<sil2100> juliank: I know
<sil2100> juliank: that retry was a fluke
<juliank> ok
 * juliank retries that stuff with hello, usually
<juliank> :D
<juliank> doko: yes it succeeded with 4.2, but it also did with openmpi/3.1.3-11build2
<rbalint> juliank, i think apt 1.9.7 broke unattended-upgrades autopkgest :-\
<juliank> rbalint: hmm
<doko> well, yes, it's openblas
<rbalint> juliank, or .6
<juliank> last it worked with -1
<juliank> so you'd expect it to have broken between -1 and -3
<juliank> -3 is same as -2
<juliank> but all -2 did was build more variants
<juliank> We use libopenblas0-pthread on the tests
<juliank> doko: Wondering if i should recompile -1 and then retest against that, it _should_ have the same result
<juliank> 2019-11-01 13:04:11 UTC is when it started failing
<juliank> It seems to be trying to unlock a mutex in a loop
<doko> juliank: rebuilding openblas?
<juliank> yeah
<doko> but that's what ginggs already tried?
<juliank> ah?
<sil2100> I don't think he did, at least not on the bug he filled in
<sil2100> I mean, maybe he did, but not documented it on the bug
<sil2100> GunnarHj: hello o/
<GunnarHj> Hi sil2100!
<sil2100> GunnarHj: sorry to bother you in the morning, but did you see my e-mail regarding translation updates for .4? :)
<sil2100> I pushed all the langpacks to bionic-proposed already if anything
<waveform> rbasak, okay - second try - amended the changelog commit at the tip of https://code.launchpad.net/~waveform/ubuntu/+source/u-boot/+git/u-boot/+ref/focal-clean-up
<sil2100> GunnarHj: would be awesome if you could send out your usual call for testing
<sdhd-sascha> hi, does anybody know if i can use `landscape` with 20.04 ? I want to test it with 19.10 but hadn't have luck.
<GunnarHj> sil2100: I did. Planning to reply today. (Basically agree.)
<sil2100> GunnarHj: excellent, thank you!
<GunnarHj> sil2100: Sure, I can send the call, but I would like to include some info in it about the possibility that also non-tested languages might end up in -updates.
<rbasak> waveform: OK and that's build tested in your PPA, right, apart from the changelog tweak/
<rbasak> ?
<waveform> rbasak, yup - built successfully against -proposed in https://launchpad.net/~waveform/+archive/ubuntu/u-boot-focal
<sil2100> GunnarHj: thanks, yeah, that makes sense. I would still like to discuss that with other release members that were previously driving point-releases (infinity, vorlon), but it's certainly a possibility
<GunnarHj> sil2100: Don't want to risk that those who do test feel cheated.
<sil2100> +1
<rbasak> waveform: you don't want to mention your shebang changes in debian/changelog? :)
<rbasak> waveform: maybe worth mentioning that you added a quilt patch
<rbasak> waveform: up to you. I'm happy either way.
<waveform> rbasak, heh - no, I think I can live without mentioning the shebang - I suppose I could bung in something for d/p/python2.patch - just a mo
<waveform> rbasak, amended the tip
<rbasak> ack
<ddstreet> Laney I think https://code.launchpad.net/~ddstreet/autopkgtest-cloud/+git/autopkgtest-cloud/+merge/377688 is ready, let me know if you'd like to see anything else for it
<juliank> So I downgraded libopenblas basically, and that works, the test runs itertions and finishes
<juliank> with focal it does not even reach the (end of ?) the first iteration
<juliank> s/focal/proposed/
<rbasak> waveform: uploaded. Thanks!
<waveform> rbasak, thanks :)
<rbasak> bryce, kanashiro: so I'd like to publish git-ubuntu from edge into stable now. Lucas, any news on that possible regression? As it's only performance in the merge subcommand that didn't sound like it'd be too bad, any objection to us releasing to stable anyway?
<kanashiro> rbasak, it was just a performance issue, I merged another package after that using the same workflow and it was not that bad, so no objections, go ahead
<rbasak> OK thanks!
<JackFrost> Could I convince someone to merge popcon from Debian, picking up the speedup and fixing LP 1822672 while they're at it?
<ubottu> Launchpad bug 1822672 in popularity-contest (Ubuntu) "popularity-contest is broken due to a bad merge with debian" [Medium,Confirmed] https://launchpad.net/bugs/1822672
<juliank> doko, sil2100 So switching from libopenblas0-pthread to libopenblas0-openmp makes that test work
<doko> so what do we want to test?
<ahasenack> rbasak: +1
<ahasenack> rafaeldtinoco: net-snmp migrated, what's this ftbfs with frr and how is it related?
<juliank> doko: Well, we at least know the bug is somewhere in the pthread implementaiton of openblas now
<doko> juliank: I wouldn't mind the omp implemtation
<juliank> doko: Wondering if we could just force openmp for hypre on armhf
<juliank> but not sure how
<juliank> they are using alternatives
<juliank> so we could only Breaks: libopenmp0-pthread
<juliank> which seems harsh
<juliank> or just modify the test, but then systems normally end up different than that
<doko> yes, adding the break for the test for that arch, where would you modify the preferred alternative?
<juliank> We could also just ignore the failure given that probably there is nobody using hypre on armhf
<juliank> I need to get some lunch now
<doko> well, sil2100 didn't want to ignore it
<rafaeldtinoco> ahasenack: libsnmp35 rdepend only
<ahasenack> k
<sil2100> doko: I didn't say I didn't want to ignore it, I just didn't feel like I have enough info to make that call without consulting
<sil2100> This is why I asked for a second opinion/investigation
<sil2100> juliank: ok, thanks for investigating!
<sil2100> juliank: could you document that in the bug?
<juliank> yes, but let me finish eating first :)
<rbalint> juliank, unattended-upgrades autopkgtest failed only in python3-coverage and it is progressing promisingly with all proposed
<juliank> doko, sil2100: updated the bug
<juliank> rbalint: ack
 * sdhd-sascha great, could upgrade two machines with netplan, bond, bridges, zfs, libvirt, kvm, lxd and nfs server to 20.04 without any problems, today :-) +1
 * sdhd-sascha And MAAS is still in the same state as before ;-)
<rbalint> juliank, the failure is similar to the one observed when the origin collection change was in, if all-proposed lets the tests finish i'd like to include that change again :-)
<seb128> vorlon, what's the proper way to add enchant-2 to the i386 whitelist? gspell/i386 depwait on it as things are transitioning from enchant to enchant-2
<waveform> juliank, finished test-build for the SRU in LP: #1847587 - any chance you can have a look at that this afternoon? (the branch ref'd in the issue should be correct now)
<ubottu> Launchpad bug 1847587 in flash-kernel (Ubuntu Bionic) "[SRU] Add entries for Pi 4" [Undecided,Fix committed] https://launchpad.net/bugs/1847587
<juliank> waveform: So I've compared it against focal, and there seem to be a few changes compared to that, could you add a list of changes made in the backport relative to focal in the changelog?
<juliank> waveform: Because without it, I can't judge whether its intentional or not
<ahasenack> rafaeldtinoco: https://code.launchpad.net/~ahasenack/ubuntu/+source/frr/+git/frr/+merge/378042
 * rafaeldtinoco reviews right away
<juliank> waveform: Well I can for the boot loader argument, but not db/all.db
<juliank> waveform: I'd probably keep all the changelog entries between 3.90... and 3.98, then people have a better insight in what was backported, but that's just me
<rbalint> juliank, ok, with all-proposed u-u's most tests pass, except for kernel-patterns which imo is a valid bug in apt
<rafaeldtinoco> ahasenack: it will take a small while, i want to test it in s390x
<rafaeldtinoco> to make sure it works before upload
<ahasenack> np
<doko> sil2100: ok, could you comment on juliank's analysis in the issue?
<juliank> rbalint: I'm not sure what it's about, but I want to rewrite apt's kernel autoremoval handling
<rbalint> juliank, just LP: #1607845
<ubottu> Launchpad bug 1607845 in apt (Ubuntu) "List of versioned kernels is not right for Ubuntu" [Low,In progress] https://launchpad.net/bugs/1607845
<juliank> Hmm why did I not merge this into 1.9....
<rafaeldtinoco> ahasenack: +1ed
<ahasenack> rafaeldtinoco: thx
<rafaeldtinoco> nice job on net-snmp
<rafaeldtinoco> now i hope it was the golden key last issue
<rafaeldtinoco> lol
<waveform> juliank, tweaked changelog and rebased branch at https://code.launchpad.net/~waveform/ubuntu/+source/flash-kernel/+git/flash-kernel/+ref/bionic-clean-up - should hopefully make sense now (the commits that modify db/all.db and the boot options include their relevant changelog entries too)
<juliank> waveform: LGTM
<juliank> waveform: I guess I should update the changelog date to the current date before uploading, because otherwise it's a bit weird
<waveform> juliank, heh - good point
<juliank> waveform: uploaded
<waveform> juliank, thanks!
<tjaalton> coreycb: I don't see cinder 15.0.1 in focal
<tjaalton> coreycb: besides, the versioning is wrong, it should be -0ubuntu1~19.10.1 or such, -0ubuntu1 is probably what focal will eventually get?
<coreycb> tjaalton: yes you're right, we must have missed the final upload. the version for eoan will be correct once we get focal updated. thanks for looking.
<sdhd-sascha> hello,
<sdhd-sascha> why does nfs-common depends on rpcbind ?
<sdhd-sascha> In my case, i only need a nfs client. So i masked the *.service.
<Eickmeyer[m]> Can we get another set of eyes on https://code.launchpad.net/~ubuntustudio-dev/+git/ardour ? teward and I are kinda stumped as to why debhelper isn't populating packages. infinity recommended changing dh_override_install to dh_override_auto_install, but that ended in a complete FTBFS.
<Eickmeyer[m]> It uses waf as the build system, so that's part of it, but built binaries aren't being picked-up by debhelper for whatever reason.
<Eickmeyer[m]> vorlon: Perhaps you have some insight?
<teward> FTBFS logs for ^ that are available at http://people.ubuntu.com/~teward/ardour_5.12.0-3ubuntu1_amd64-2020-01-24T05:12:38Z.build btw
<Eickmeyer[m]> This is a key package for Ubuntu Studio and has been for years, if not over the past decade.
 * Eickmeyer[m] will be afk for a bit, taking son to school
<juliank> Eickmeyer[m]: I can have a quick look
<juliank> I guess
<juliank> Depends on how long it takes to build
<juliank> probably too long, seeing it's a huge load of C++
<juliank> Eickmeyer[m]: it certainly is wrong now, as override_dh_install does need to call dh_install
<juliank> and yes, override_dh_auto_install would have been the right to do
<juliank> Eickmeyer[m]: the build log looks good, it's correctly installing stuff
<juliank> or at least some of it
<juliank> Now what you can see is that all libraries are installed but dpkg-shlibdeps can't find them
<juliank> So I'd guess they had an rpath set that was removed or something, given that the libraries are in usr/lib/lib/ardour5/libardour.so.3.0.0  and not the standard search path
<juliank> A simple thing to remember is that you basically want to always call the command your override, except for the auto commands
<juliank> I see you set LD_LIBRARY_PATH += :$(DEB_DESTDIR)/usr/lib/ardour5/
<juliank> but you don't export it, so nothing can use it
<juliank> whether it would work - i don't know
<juliank> it feels wrong - how will the dynamic linker find stuff at run-time then anyway?
<juliank> Summary: The build log looks very good, it just needs fixing of the library search path or library locations or something lie that
<teward> juliank: the key problem here is that WAF is the build system, I think that's botching many of the 'standard' mechanisms at play
<juliank> teward: Only the dh_auto ones
<teward> right
<juliank> It's amazing that something in 2020 still uses waf
<Eickmeyer[m]> juliank: Just for reference, the d/rules file is almost completely unmodified from the upstream one in Debian that was building correctly for years.
<Eickmeyer[m]> I applied a proposed merge request from a month ago that I modified by adding dh_clean -d.
<juliank> I have no idea how the Debian rules files works
<Eickmeyer[m]> juliank: https://salsa.debian.org/multimedia-team/ardour/merge_requests/1
<juliank> given that it does not call dh_install, files should be ending up in debian/tmp and packages empty
<Eickmeyer[m]> That's correct, however, it should be picked-up anyhow since it defaults to looking in debian/tmp.
<juliank> But dh_install should not have been running
<juliank> it's been overridden, and not run in the override target
<Eickmeyer[m]> Right, and prior to infinity 's suggestion, it wasn't.
<Eickmeyer[m]> I'm doing a rebuild right now in my PPA to demonstrate the previous behavior (override_dh_install vs override_dh_auto_install).
<juliank> hmm
<juliank> it was called as dh_install -pardour
<juliank> now I'm confused
<juliank> (in debian
<juliank> )
<juliank> I don't know why but it sounds like a debhelper bug that was fixed
<Eickmeyer[m]> So, the logs that teward gave you are indicative of what happened when override_dh_auto_install was used.
<Eickmeyer[m]> However, when override_dh_install was used, it built the binaries but failed to populate the .deb files with said binaries built in debian/tmp.
<Eickmeyer[m]> It returned a false successful build.
<juliank> Eickmeyer[m]: Yes, as I'd expect. The log I saw that failed was failing the right way
<Eickmeyer[m]> Should I update compat to something newer than 10?
<cjwatson> When you say "it defaults to looking in debian/tmp", you're talking about a command that isn't being run
<cjwatson> AFAICS
<juliank> That's what I wrote, didn't I?
<cjwatson> Yes, dh_install defaults to looking in debian/tmp, but that doesn't mean anything if it's being overridden in such a way as to cause it not to be run
<cjwatson> Right, I'm just trying to clarify since it's not clear that Eickmeyer[m] has understood this
<juliank> that was exactly the problem, and infinity's suggestion was absolutely correct as we can see in the new build failure
<juliank> as all files are being installed
<Eickmeyer[m]> Yes, I understand this, but this wasn't an issue for YEARS before.
<juliank> It probably was a bug in debhelper that got fixed or something
<cjwatson> I haven't seen the rules file that was in use for years.  Perhaps there was some slight variation
<juliank> cjwatson: It had the same problem, but debhelper _somehow_ run dh_install -pardour
<cjwatson> https://git.launchpad.net/~ubuntustudio-dev/+git/ardour/log/debian/rules shows plenty of changes to it so it's not like it's been the same all along
<juliank> unless it was never uploaded
<cjwatson> So https://git.launchpad.net/~ubuntustudio-dev/+git/ardour/commit/debian/rules?id=c3ac15c24f25a88a0c9c7869b2d96a0634ecda82 definitely looks correct and should be put back
<juliank> Right, the last version Debian had was using cdbs
<Eickmeyer[m]> cjwatson: That one FTBFS, even though the binary packages built.
<cjwatson> Sure, but it's still more correct
<juliank> So you can't say that this worked before, as it never worked.
<juliank> The conversion to dh was essentially unfinished in the packaging repository
<juliank> it was never uploaded anywhere
<Eickmeyer[m]> That's categorically false. This application USED to be packaged upstream, but got removed 1-11-2020 by vorlon .
<cjwatson> *This generation of the packaging machinery* never worked
<juliank> Now, what you need to add is
<juliank> override_dh_shlibdeps:
<juliank>    dh_shlibdeps -l usr/lib/ardour5
<juliank> I believe
<cjwatson> The thing that was removed had a completely different rules file (I just checked)
<cjwatson> That sounds plausible
<cjwatson> (Does it need a leading slash though?  The man page example has one)
<juliank> maybe
<juliank> and maybe no space after -l
<juliank> The rules files currently sets LD_LIBRARY_PATH, but does not export it
<cjwatson> So dh_shlibdeps -l/usr/lib/ardour5
<Eickmeyer[m]> cjwatson: Check that rules file vs https://salsa.debian.org/multimedia-team/ardour vs the pending merge request there.
<juliank> It' possible that did the same in cdbs
<juliank> Eickmeyer[m]: That one was never uploaded.
<juliank> Eickmeyer[m]: this was the last one: https://salsa.debian.org/multimedia-team/ardour/blob/debian/1%255.12.0-3/debian/rules
<juliank> Eickmeyer[m]: The version you see in the current branch of the ardour repo there was a WIP
<cjwatson> Right, you seem to have branched off an unreleased thing
<cjwatson> And then found that it didn't work
<cjwatson> Which may be why it's unreleased :)
<Eickmeyer[m]> Then I'm clearly in over my head. Without this application, Ubuntu Studio loses all credibility as an operating system for audio production.
<cjwatson> Have you considered instead doing the work based on the 1:55.12.0-3 tag?
<cjwatson> Rather than based on unreleased stuff on master?
<cjwatson> Sorry, the debian/1:5.12.0-3 tag I mean
<Eickmeyer[m]> Here's the problem: waf now needs to build against Python 3, and the application itself needs to build against fluidsynth 2. I have patches in place to make that happen.
<cjwatson> It's not usual to pull in extra unreleased stuff from master unless it's required and works
<juliank> Eickmeyer[m]: Then apply those patches to 5.12.0-3 instead of the WIP master branch
<Eickmeyer[m]> I'll go ahead and bring-in the original cdbs-based rules file and see what happens.
<cjwatson> I would make a new working git branch starting from the tag corresponding to the last upload
<cjwatson> And reapply whatever patches are necessary to that
<juliank> or go back to https://salsa.debian.org/multimedia-team/ardour/commit/c7ab456c9bdd81d57f9bfff60d01fcce2e164210
<juliank> which seems to include that?
<juliank> that ~ python3 support
<cjwatson> Don't try to mutate your current master branch (if you will take my advice)
<juliank> +1
<Eickmeyer[m]> Ok, recloning then.
<cjwatson> Why recloning?
<cjwatson> git checkout -b focal debian/1:5.12.0-3
<cjwatson> or some such, assuming that you have a remote corresponding to the Debian repository
<Eickmeyer[m]> It errored, but looks like I was trying to get the wrong tag.
<cjwatson> debian/1:5.12.0-3 should be the tag name according to the URL juliank posted above
<cjwatson> I haven't actually cloned it to check because rubbish internet connection
<Eickmeyer[m]> Actually, it's coming back as debian/1%5.12.0-3
<cjwatson> Oh right of course
<cjwatson> Sorry, should have actually decoded properly :)
<cjwatson> I always tab-complete tag names ...
<sdhd-sascha> hi, have here a machine, which want to upgrade from 18.04 to 20.04 ... which has trouble with package resolution...
<Eickmeyer[m]> !support | sdhd-sascha
<ubottu> sdhd-sascha: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<sdhd-sascha> ubottu: oh, ok - what kind of `devel` is here ? i'm from `db`, `backend`, `desktop` and a little bit `web`
<sdhd-sascha> Eickmeyer[m]: no, problem -- thank you -- don't need support ;-)
<sdhd-sascha> /me just more security, like everywhere ;-)
<Eickmeyer[m]> sdhd-sascha: The point is that this is the wrong channel to address your question.
<Eickmeyer[m]> sdhd-sascha: And technically you want #ubuntu+1
<sdhd-sascha> Eickmeyer[m]: i'm sorry - it's okay. (Just happened some day ago, that i got some push, to do a update. here)
<sdhd-sascha> But, no problem. I can figure it out. The #ubuntu is ,mostly, too much talk for me ...
<SamWhited> Hi, I was hoping to get a performance fix backported to libseccomp 2.4.x in Ubuntu. Debian has done so here and the patch from 2.5 (which applies cleanly to 2.4) can be found here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913
<ubottu> Debian bug 943913 in libseccomp2 "libseccomp2: seccomp_rule_add is very slow" [Normal,Open]
<SamWhited> Would the correct procedure be to file a bug, or since the maintainers appear to overlap between Debian and Ubuntu for this package, should I just leave it and trust they'll apply the patch in both places? Thanks!
<bryce> SamWhited: For backported fixes to stable series, a bug report is generally always involved, so filing one would be a correct procedure, yes, even if the maintainers are involved in both places
<bryce> aw rats he left already
<Eickmeyer[m]> cjwatson, juliank: Thanks to you both, I now have it working. teward will be sponsoring the upload shortly, and Ubuntu Studio will not being missing its primary DAW in 20.04.
<teward> that said, it will need AA intervention because it was removed
<teward> and it'll be stuck in NEW otherwise.
#ubuntu-devel 2020-01-25
<teward> Eickmeyer[m]: because of doko's upload of -3ubuntu1 that sits in Proposed currently, your version is busted for upload because of conflicting versions.  I'm dputting a version bumped version of -3ubuntu2 to supersede doko's FTBFS upload to proposed from yesterday (which was not needed - doko do me a favor and get in touch with me please) and get things to build.  The -3ubuntu2 does NOT contain the changes in -3ubuntu1 since...
<teward> ... y'all are now divergent from each other
<teward> so -3ubuntu2 based on the Ubuntu Studio git repo for it is where it'll be sourced from.
<teward> (I didn't realize that doko uploaded -3ubuntu1 and i don't think you did either Eickmeyer[m], which just adds to what we have to do >.>)
<doko> just upload as a new version
<teward> I am.  -3ubuntu2 is in the process of being uploaded
<teward> NOT why i wanted to poke you
<teward> and, -3ubuntu2 is accepted
<teward> which means I can go back to killing demons in DOOM :P
